Connected: An Internet Encyclopedia
RFC 1661 - 6.4. Magic-Number

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1661
Up: 6. LCP Configuration Options
Prev: 6.3. Quality-Protocol
Next: 6.5. Protocol-Field-Compression (PFC)

### 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 MUST be sent specifying a different Magic-Number value. A new Configure-Request SHOULD NOT be sent to the peer until normal processing would cause it to be sent (that is, until a Configure- Nak is received or the Restart timer runs out).

  Reception of a Configure-Nak with a Magic-Number different from that of the last Configure-Nak sent to the peer proves that a link is not looped-back, and indicates a unique Magic-Number. If the Magic-Number is equal to the one sent in the last Configure-Nak, the possibility of a looped-back link is increased, and a new Magic-Number MUST be chosen. In either case, a new Configure- Request SHOULD be sent with the new Magic-Number.

  If the link is indeed looped-back, this sequence (transmit Configure-Request, receive Configure-Request, transmit Configure- Nak, receive Configure-Nak) will repeat over and over again. If the link is not looped-back, this sequence might occur a few times, but it is extremely unlikely to occur repeatedly. More likely, the Magic-Numbers chosen at either end will quickly diverge, terminating the sequence. The following table shows the probability of collisions assuming that both ends of the link select Magic-Numbers with a perfectly uniform distribution:

          Number of Collisions        Probability
          --------------------   ---------------------
                  1              1/2**32    = 2.3 E-10
                  2              1/2**32**2 = 5.4 E-20
                  3              1/2**32**3 = 1.3 E-29

  Good sources of uniqueness or randomness are required for this divergence to occur. If a good source of uniqueness cannot be found, it is recommended that this Configuration Option not be enabled; Configure-Requests with the option SHOULD NOT be transmitted and any Magic-Number Configuration Options which the peer sends SHOULD be either acknowledged or rejected. In this case, looped-back links cannot be reliably detected by the implementation, although they may still be detectable by the peer.

  If an implementation does transmit a Configure-Request with a Magic-Number Configuration Option, then it MUST NOT respond with a Configure-Reject when it receives a Configure-Request with a Magic-Number Configuration Option. That is, if an implementation desires to use Magic Numbers, then it MUST also allow its peer to do so. If an implementation does receive a Configure-Reject in response to a Configure-Request, it can only mean that the link is not looped-back, and that its peer will not be using Magic- Numbers. In this case, an implementation SHOULD act as if the negotiation had been successful (as if it had instead received a Configure-Ack).

  The Magic-Number also may be used to detect looped-back links during normal operation, as well as during Configuration Option negotiation. All LCP Echo-Request, Echo-Reply, and Discard- Request packets have a Magic-Number field. If Magic-Number has been successfully negotiated, an implementation MUST transmit these packets with the Magic-Number field set to its negotiated Magic-Number.

  The Magic-Number field of these packets SHOULD be inspected on reception. All received Magic-Number fields MUST be equal to either zero or the peer's unique Magic-Number, depending on whether or not the peer negotiated a Magic-Number. Reception of a Magic-Number field equal to the negotiated local Magic-Number indicates a looped-back link. Reception of a Magic- Number other than the negotiated local Magic-Number, the peer's negotiated Magic-Number, or zero if the peer didn't negotiate one, indicates a link which has been (mis)configured for communications with a different peer.

  Procedures for recovery from either case are unspecified, and may vary from implementation to implementation. A somewhat pessimistic procedure is to assume a LCP Down event. A further Open event will begin the process of re-establishing the link, which can't complete until the looped-back condition is terminated, and Magic-Numbers are successfully negotiated. A more optimistic procedure (in the case of a looped-back link) is to begin transmitting LCP Echo-Request packets until an appropriate Echo-Reply is received, indicating a termination of the looped- back condition.

A summary of the Magic-Number Configuration Option format is shown below. The fields are transmitted from left to right.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |    Length     |          Magic-Number
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Magic-Number (cont)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

  5

Length

  6

Magic-Number

  The Magic-Number field is four octets, and indicates a number which is very likely to be unique to one end of the link. A Magic-Number of zero is illegal and MUST always be Nak'd, if it is not Rejected outright.

Next: 6.5. Protocol-Field-Compression (PFC)

Connected: An Internet Encyclopedia
RFC 1661 - 6.4. Magic-Number