RFC 1990                     PPP Multilink                   August 1996        Class 4 - PPP Magic-Number Block             Maximum Length: 20             Content:             This is not an address but a block of 1 to 5 concatenated             32 bit PPP Magic-Numbers as defined in [2].  This class             provides for automatic generation of a value likely but not             guaranteed to be unique.  The same block MUST be used by an             endpoint continuously during any period in which at least             one link is in the LCP Open state.  The use of this class             is deprecated.             Note that PPP Magic-Numbers are used in [2] to detect             unexpected loopbacks of a link from an endpoint to itself.             There is a small probability that two distinct endpoints             will generate matching magic-numbers.  This probability is             geometrically reduced when the LCP negotiation is repeated             in search of the desired mismatch, if a peer can generate             uncorrelated magic-numbers.             As used here, magic-numbers are used to determine if two             links are in fact from the same peer endpoint or from two             distinct endpoints.  The numbers always match when there is             one endpoint.  There is a small probability that the             numbers will match even if there are two endpoints.  To             achieve the same confidence that there is not a false match             as for LCP loopback detection, several uncorrelated magic-             numbers can be combined in one block.        Class 5 - Public Switched Network Directory Number             Maximum Length: 15             Content:             An address in this class contains an octet sequence as             defined by I.331 (E.164) representing an international             telephone directory number suitable for use to access the             endpoint via the public switched telephone network [10].6.  Initiating use of Multilink Headers   When the use of the Multilink protocol has been negotiated on a link   (say Y), and the link is being added to a bundle which currently   contains a single existing link (say X), a system MUST transmit a   Multilink-encapsulated packet on X before transmitting any Multilink-Sklower, et. al.            Standards Track                    [Page 19]RFC 1990                     PPP Multilink                   August 1996   encapsulated packets on Y.   Since links may be added and removed from a bundle without destroying   the state associated with it, the fragment should be assigned the   appropriate (next) fragment number.  As noted earlier, the first   fragment transmitted in the life of a bundle is assigned fragment   number 0.7.  Closing Member links   Member links may be terminated according to normal PPP LCP procedures   using LCP Terminate-Request and Terminate-Ack packets on that member   link.  Since it is assumed that member links usually do not reorder   packets, receipt of a terminate ack is sufficient to assume that any   multilink protocol packets ahead of it are at no special risk of   loss.   Receipt of an LCP Terminate-Request on one link does not conclude the   procedure on the remaining links.   So long as any member links in the bundle are active, the PPP state   for the bundle persists as a separate entity.  However, if the there   is a unique link in the bundle, and all the other links were closed   gracefully (with Terminate-Ack), an implementation MAY cease using   multilink   headers.   If the multilink procedure is used in conjunction with PPP reliable   transmission, and a member link is not closed gracefully, the   implementation should expect to receive packets which violate the   increasing sequence number rule.8.  Interaction with Other Protocols   In the common case, LCP, and the Authentication Control Protocol   would be negotiated  over each member link.  The Network Protocols   themselves and associated control exchanges would normally have been   conducted once, on the bundle.   In some instances it may be desirable for some Network Protocols to   be exempted from sequencing requirements, and if the MRU sizes of the   link did not cause fragmentation, those protocols could be sent   directly over the member links.   Although explicitly discouraged above, if there were several member   links connecting two implementations, and independent sequencing of   two protocol sets were desired, but blocking of one by the other was   not, one could describe two multilink procedures by assigningSklower, et. al.            Standards Track                    [Page 20]RFC 1990                     PPP Multilink                   August 1996   multiple endpoint identifiers to a given system.  Each member link,   however, would only belong to one bundle.  One could think of a   physical router as housing two logically separate implementations,   each of which is independently configured.   A simpler solution would be to have one link refuse to join the   bundle, by sending a Configure-Reject in response to the Multilink   LCP option.9.  Security Considerations   Operation of this protocol is no more and no less secure than   operation of the PPP authentication protocols [3].  The reader is   directed there for further discussion.10.  References   [1] Leifer, D., Sheldon, S., and B. Gorsline, "A Subnetwork Control       Protocol for ISDN Circuit-Switching", University of Michigan       (unpublished), March 1991.   [2] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,       RFC 1661, Daydreamer, July 1994.   [3] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC       1334, Lloyd Internetworking, Daydreamer, October 1992.   [4] International Organisation for Standardization, "HDLC -       Description of the X.25 LAPB-Compatible DTE Data Link       Procedures", International Standard 7776, 1988   [5] Rand, D., "The PPP Compression Control Protocol (CCP)", PPP       Extensions Working Group, RFC 1962, June 1996.   [6] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July       1994   [7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,       USC/Information Sciences Institute, October 1994.   [8] Postel, J., Editor, "Internet Protocol - DARPA Internet Program       Protocol Specification", STD 5, RFC 791, USC/Information Sciences       Institute, September 1981.   [9] Institute of Electrical and Electronics Engineers, Inc., "IEEE       Local and Metropolitan Area Networks: Overview and Architecture",       IEEE Std. 802-1990, 1990.Sklower, et. al.            Standards Track                    [Page 21]RFC 1990                     PPP Multilink                   August 1996  [10] The International Telegraph and Telephone Consultative Committee       (CCITT), "Numbering Plan for the ISDN Area", Recommendation I.331       (E.164), 1988.  [11] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer,       January 1994.11.  Differences from RFC 1717   This section documents differences from RFC 1717.  There are   restrictions placed on implementations that were absent in RFC 1717;   systems obeying these restrictions are fully interoperable with RFC   1717 - compliant systems.11.1.  Negotiating Multilink, per se   RFC 1717 permitted either the use of the Short Sequence Number Header   Format (SSNHF) or the Maximum Reconstructed Receive Unit (MRRU)   options by themselves to indicate the intent to negotiate multilink.   This specification forbids the use of the SSNHF option by itself; but   does permit the specific of both options together.  Any   implementation which otherwise conforms to rfc1717 and also obeys   this restriction will interoperate with any RFC 1717 implementation.11.2.  Initial Sequence Number defined   This specification requires that the first sequence number   transmitted after the virtual link has reached to open state be 0.11.3.  Default Value of the MRRU   This specfication removes the default value for the MRRU, (since it   must always be negotiated with some value), and specifies that an   implementation must be support an MRRU with same value as the default   MRU size for PPP.11.4.  Config-Nak of EID prohibited   This specification forbids the config-Naking of an EID for any   reason.11.5.  Uniformity of Sequence Space   This specification requires that the same sequence format be employed   on all links in a bundle.Sklower, et. al.            Standards Track                    [Page 22]RFC 1990                     PPP Multilink                   August 199611.6.  Commencing and Abating use of Multilink Headers   This memo specifies how one should start the use of Multilink Headers   when a link is added, and under what circumstances it is safe to   discontinue their use.11.7.  Manual Configuration and Bundle Assignment   The document explicitly permits multiple bundles to be manually   configured in the absence of both the Endpoint Descriminator and any   form of authentication.Sklower, et. al.            Standards Track                    [Page 23]RFC 1990                     PPP Multilink                   August 199613.  Authors' Addresses   Keith Sklower   Computer Science Department   384 Soda Hall, Mail Stop 1776   University of California   Berkeley, CA 94720-1776   Phone:  (510) 642-9587   EMail:  sklower@CS.Berkeley.EDU   Brian Lloyd   Lloyd Internetworking   3031 Alhambra Drive   Cameron Park, CA 95682   Phone: (916) 676-1147   EMail:  brian@lloyd.com   Glenn McGregor   Lloyd Internetworking   3031 Alhambra Drive   Cameron Park, CA 95682   Phone: (916) 676-1147   EMail: glenn@lloyd.com   Dave Carr   Newbridge Networks Corporation   600 March Road   P.O. Box 13600   Kanata, Ontario,   Canada, K2K 2E6   Phone:  (613) 591-3600   EMail:  dcarr@Newbridge.COM   Tom Coradetti   Sidewalk Software   1190 Josephine Road   Roseville, MN 55113   Phone: (612) 490 7856   EMail: 70761.1664@compuserve.comSklower, et. al.            Standards Track                    [Page 24]