RFC1661 - часть 37

the most recent "Assigned Numbers" RFC [2]. Current values are

assigned as follows:

Value (in hex) Protocol

c025 Link Quality Report

Data

The Data field is zero or more octets, and contains additional

data as determined by the particular protocol.

Simpson [Page 44]

RFC 1661 Point-to-Point Protocol July 1994

6.4. Magic-Number

Description

This Configuration Option provides a method to detect looped-back

links and other Data Link Layer anomalies. This Configuration

Option MAY be required by some other Configuration Options such as

the Quality-Protocol Configuration Option. By default, the

Magic-Number is not negotiated, and zero is inserted where a

Magic-Number might otherwise be used.

Before this Configuration Option is requested, an implementation

MUST choose its Magic-Number. It is recommended that the Magic-

Number be chosen in the most random manner possible in order to

guarantee with very high probability that an implementation will

arrive at a unique number. A good way to choose a unique random

number is to start with a unique seed. Suggested sources of

uniqueness include machine serial numbers, other network hardware

addresses, time-of-day clocks, etc. Particularly good random

number seeds are precise measurements of the inter-arrival time of

physical events such as packet reception on other connected

networks, server response time, or the typing rate of a human

user. It is also suggested that as many sources as possible be

used simultaneously.

When a Configure-Request is received with a Magic-Number

Configuration Option, the received Magic-Number is compared with

the Magic-Number of the last Configure-Request sent to the peer.

If the two Magic-Numbers are different, then the link is not

looped-back, and the Magic-Number SHOULD be acknowledged. If the

two Magic-Numbers are equal, then it is possible, but not certain,

that the link is looped-back and that this Configure-Request is

actually the one last sent. To determine this, a Configure-Nak