RFC 1717
The PPP Multilink Protocol (MP)
RFC 1717: The PPP Multilink Protocol (MP) ✨
okay bestie, so this is RFC 1717 and it's called "The PPP Multilink Protocol (MP)" 🎀. It came out in November 1994 from the Network Working Group, and it's on the Standards Track, so it's the real deal 👑. The authors are K. Sklower from the University of California, Berkeley, B. Lloyd and G. McGregor from Lloyd Internetworking, and D. Carr from Newbridge Networks Corporation 🫶. The title block doesn't list anything it obsoletes or updates, so no drama there 💅.
Status of This Memo 📮
okay so this doc specifies an Internet standards track protocol for the whole Internet community, and it's literally begging for discussion and suggestions for improvements 🥹. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🦋.
Abstract 🌈
this doc proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links ✨. It was originally motivated by the desire to exploit multiple bearer channels in ISDN, but it's equally applicable to any situation where multiple PPP links connect two systems, including async links 💖. This is accomplished by means of new PPP [2] options and protocols 🧚.
Acknowledgements 💜
the authors specifically wanted to thank Fred Baker of ACC, Craig Fox of Network Systems, Gerry Meyer of Spider Systems, Tom Coradetti of Digiboard (for the Endpoint Discriminator option), Dan Brennan of Penril Datability Networks, Vernon Schryver of SGI (for the comprehensive discussion of padding), and the members of the IP over Large Public Data Networks and PPP Extensions working groups 🫶. They were all super helpful with the discussion on the subject, and that's so iconic of them 🙌.
Table of Contents 🗂️
1. Introduction ................................................ 2
1.1. Motivation ................................................ 2
1.2. Functional Description .................................... 3
1.3. Conventions ............................................... 3
2. General Overview ............................................ 4
3. Packet Formats .............................................. 6
3.1. Padding Considerations .................................... 9
4. Trading Buffer Space Against Fragment Loss .................. 9
4.1. Detecting Fragment Loss ................................... 10
4.2. Buffer Space Requirements ................................. 11
5. PPP Link Control Protocol Extensions ........................ 12
5.1. Configuration Option Types ................................ 12
5.1.1. Multilink MRRU LCP option ............................... 13
5.1.2. Short Sequence Number Header Format Option .............. 13
5.1.3. Endpoint Discriminator Option ........................... 14
6. Closing Member links ........................................ 18
7. Interaction with Other Protocols ............................ 19
8. Security Considerations ..................................... 19
9. References .................................................. 20
10. Authors' Addresses ......................................... 211. Introduction ✨
1.1. Motivation 🌸
okay so Basic Rate and Primary Rate ISDN both let you open multiple simultaneous channels between systems, which gives users extra bandwidth on demand (for additional cost) 💸. Earlier proposals for running internet protocols over ISDN listed being able to use this as a goal, e.g., Leifer et al., [1] 📝.
there are proposals out there for syncing multiple streams at the bit level (the BONDING proposals) 🔗. Those features aren't widely deployed yet, though, and they may need extra hardware on the end system 🙈. So it may be useful to have a purely software solution, or at least an interim measure 💜.
there are other cases where bandwidth on demand is useful too, like using a dialup async line at 28,800 baud to back up a leased synchronous line 📞, or opening extra X.25 SVCs where the window size is limited to two by international agreement 🌍.
the simplest possible algorithm is alternating packets between channels whenever a channel has space (which might be called the Bank Teller's algorithm) 🏦. It can have some messy side effects because the packets get reordered 😭.
by using a four-byte sequencing header and simple synchronization rules, you can split packets among parallel virtual circuits between systems so that packets don't get reordered, or at least the chance of that is greatly reduced 🎀✨.
1.2. Functional Description 🧚
this method is similar to the multilink protocol described in ISO 7776 [4], but it adds the ability to split and recombine packets, which reduces latency and could also increase the effective maximum receive unit (MRU) 🚀. Also, there's no requirement here for acknowledged-mode operation on the link layer, although that's allowed as an option 🦋.
Multilink is based on an LCP option negotiation that lets a system tell its peer that it can combine multiple physical links into a "bundle" 🫧. Only under exceptional conditions would a given pair of systems need more than one bundle connecting them 👀.
Multilink gets negotiated during the initial LCP option negotiation. A system says to its peer that it's up for multilink by sending the multilink option as part of that initial LCP option negotiation 💅. This negotiation tells the peer three things:
- The system offering the option is capable of combining multiple physical links into one logical link;
- The system is capable of receiving upper layer protocol data units (PDU) fragmented using the multilink header (described later) and reassembling the fragments back into the original PDU for processing;
- The system is capable of receiving PDUs of size N octets where N is specified as part of the option even if N is larger than the maximum receive unit (MRU) for a single physical link.
Once multilink has been successfully negotiated, the sending system is free to send PDUs encapsulated and/or fragmented with the multilink header 🎉.
1.3. Conventions 📖
okay so here's how the language conventions work in the items of specification in this doc 🤓:
- MUST, SHALL or MANDATORY: the item is an absolute requirement of the specification 🔥.
- SHOULD or RECOMMENDED: the item should generally be followed for all but exceptional circumstances 💖.
- MAY or OPTIONAL: the item is truly optional and may be followed or ignored according to the needs of the implementor 🌈.
2. General Overview 🌸
okay so before the fun stuff happens, each end of a PPP link has to send LCP packets to set up the data link during the Link Establishment phase 🔧. Once the link is up, PPP moves into an Authentication phase, where the authentication protocols can figure out the identifiers tied to each system on the link [3]. it's giving organized 💅
the goal of multilink is to coordinate multiple independent links between one fixed pair of systems, so you get a virtual link with more bandwidth than any single member link 🦋. the aggregate link (aka the bundle) is named by the pair of identifiers for the two systems. a system identifier can include info from PPP Authentication [3] and from LCP negotiation. the bundled links can be totally different physical links, like multiple async lines, or they can be multiplexed links like ISDN, X.25 or Frame Relay. they can even be different kinds of links, like dialup async paired with leased synchronous. iconic, honestly ✨
here's how we suggest picturing it: multilink can be modeled as a virtual PPP link-layer entity. packets that show up over different physical link-layer entities get tagged as belonging to a separate PPP network protocol (the Multilink Protocol, or MP), then recombined and sequenced using info in a multilink fragmentation header 🧚. every packet received over links in the multilink arrangement goes to the same network-layer protocol processing machine, whether it has a multilink header or not. main character energy 👑
packets sent through the multilink procedure get encapsulated using the normal PPP rules, as if these options were manually configured:
- No async control character Map
- No Magic Number
- No Link Quality Monitoring
- Address and Control Field Compression
- Protocol Field Compression
- No Compound Frames
- No Self-Describing-Padding
of course, individual links are permitted to have different settings for these options 🌈. as described below, member links SHOULD negotiate Self-Describing-Padding, even though pre-fragmented packets MUST NOT be padded 🫶.
LCP negotiations are not permitted on the bundle itself 🙈. an implementation MUST NOT transmit LCP Configure-Request, -Reject, -Ack, -Nak, Terminate-Request or -Ack packets via the multilink procedure, and an implementation receiving them MUST silently discard them. (by "silently discard" we mean don't generate any PPP packets in response. an implementation is free to log the reception of the unexpected packet, though 📝.) by contrast, other LCP packets with control functions that aren't about changing the defaults for the bundle itself are permitted. an implementation MAY transmit LCP Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply and Discard-Request packets 💖.
the effective MRU for the logical-link entity is negotiated via an LCP option. it's irrelevant whether Network Control Protocol packets are encapsulated in multilink headers or not, or even which link they're sent over, once that link identifies itself as belonging to a multilink arrangement 💅.
note that network protocols that are not sent using multilink headers cannot be sequenced. (and consequently will be delivered in any convenient way) 🍓
let's look at the example in Figure 1 🔥. Link 1 has negotiated network layers NL 1, NL 2, and MP between two systems. the two systems then negotiate MP over Link 2.
frames received on Link 1 get demultiplexed at the data link layer according to the PPP network protocol identifier, and they can be sent to NL 1, NL 2, or MP. Link 2 will accept frames with all the network protocol identifiers that Link 1 does ✨.
frames received by MP get further demultiplexed at the network layer according to the PPP network protocol identifier and sent to NL 1 or NL 2. any frames received by MP for any other network layer protocols are rejected using the normal protocol reject mechanism 🙅♀️.
Figure 1. Multilink Overview.
Network Layer
-------------
______ ______
/ \ / \
| NL 1 | | NL 2 |
\______/ \______/
| | | | | |
| | +-------------o-o-o-+
| +------+ +-----+ | | |
| | | | | |
| +------o--o-------+ + |
| | |__|_ | |
| | / \ | |
| | | MLCP | <--- Link Layer
| | \______/ Demultiplexing
| | | | |
| | | | |
| | | <--- Virtual Link
| | | | |
| | | | |
| | | | |
| | + | |
___|_| | ___|_|
/ \ | / \
| LCP |------+-----| LCP | <--- Link Layer
\______/ \______/ Demultiplexing
| |
| |
Link 1 Link 23. Packet Formats 🧁
in this section we break down the layout of individual fragments, which are the "packets" in the Multilink Protocol 🎀. Network Protocol packets get encapsulated first (but not framed) using normal PPP procedures, and large packets get broken up into multiple segments sized appropriately for the multiple physical links. a new PPP header, made of the Multilink Protocol Identifier and the Multilink header, gets inserted before each section. (so the first fragment of a multilink packet in PPP will have two headers: one for the fragment, followed by the header for the packet itself 🤯.)
systems implementing the multilink procedure are not required to fragment small packets. there's also no requirement that the segments be equal in size, or that packets have to be broken up at all 🌸. a possible strategy for dealing with member links of differing transmission rates would be to divide packets into segments proportional to the transmission rates. another strategy might be to divide them into many equal fragments and distribute multiple fragments per link, with the numbers proportional to the relative speeds of the links 🚀.
PPP multilink fragments are encapsulated using the protocol identifier 0x00-0x3d. following the protocol identifier is a four byte header containing a sequence number, plus two one bit fields that indicate whether the fragment begins a packet or terminates one. after negotiation of an additional PPP LCP option, the four byte header may optionally be replaced by a two byte header with only a 12 bit sequence space 🦋. Address & Control and Protocol ID compression are assumed to be in effect. so individual fragments will have the following format 💜:
Figure 2: Long Sequence Number Fragment Format.
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-+-+-+-+---------------+
MP Header: |B|E|0|0|0|0|0|0|sequence number|
+-+-+-+-+-+-+-+-+---------------+
| sequence number (L) |
+---------------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+Figure 3: Short Sequence Number Fragment Format.
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-------+---------------+
MP Header: |B|E|0|0| sequence number |
+-+-+-+-+-------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+the (B)eginning fragment bit is a one bit field set to 1 on the first fragment derived from a PPP packet, and set to 0 for all other fragments from the same PPP packet 🌟.
the (E)nding fragment bit is a one bit field set to 1 on the last fragment and set to 0 for all other fragments. a fragment may have both the (B)eginning and (E)nding fragment bits set to 1 💖.
the sequence field is a 24 bit or 12 bit number that gets incremented for every fragment transmitted. by default the sequence field is 24 bits long, but it can be negotiated to be only 12 bits with an LCP configuration option described below 🔢.
between the (E)nding fragment bit and the sequence number is a reserved field, whose use is not currently defined, which MUST be set to zero 🙅♀️. it's 2 bits long when short sequence numbers have been negotiated, and 6 bits otherwise.
in this multilink protocol, a single reassembly structure is associated with the bundle. the multilink headers get interpreted in the context of this structure 🧩.
the FCS field shown in the diagram is inherited from the normal framing mechanism of the member link the packet is transmitted on. there is no separate FCS applied to the reconstituted packet as a whole if it's transmitted in more than one fragment 🫶.
3.1. Padding Considerations 🎀
Okay bestie, let's talk padding 🧚 Systems that support the multilink protocol SHOULD implement Self-Describing-Padding ✨ A system that does this will, by definition, either put the padding option in its very first LCP Configure-Requests, or (so it doesn't have to sit around waiting for a Configure-Reject 😭) add the padding option after it gets a NAK that contains the option.
A system that has to pad its own transmissions but doesn't use Self-Describing-Padding when it's not doing multilink MAY keep skipping it, as long as it makes sure, by carefully picking fragment lengths, that only the (E)nding fragments of packets get padded 💅 A system MUST NOT add padding to any packet that its peer can't recognize as padded. Non-terminal fragments MUST NOT be padded with trailing material by any method other than Self-Describing-Padding. Not okay, not okay 🙈
A system MUST ensure that Self-Describing-Padding as described in RFC 1570 [11] is negotiated on the individual link before transmitting any multilink data packets if it might pad non-terminal fragments, or if it would use network or compression protocols that are vulnerable to padding, as described in RFC 1570. If necessary, the system that adds padding MUST use LCP Configure-NAK's to elicit a Configure-Request for Self-Describing-Padding from the peer. The vibe is: get the negotiation sorted first 🫶
Note that LCP Configure-Requests can be sent at any time on any link, and the peer will always respond with a Configure-Request of its own. A system that pads its transmissions but uses no protocols other than multilink that are vulnerable to padding MAY delay making sure the peer has Configure-Requested Self-Describing-Padding until it seems desirable to negotiate the use of Multilink itself. This is what keeps things interoperable with older peers that support neither Multilink nor Self-Describing-Padding. Such a considerate system 🌸
4. Trading Buffer Space Against Fragment Loss ✨
Okay so, in a multilink setup, one channel might run behind the others in the bundle 🐢 That means fragments can show up out of order, which makes it harder to tell when a fragment has actually gone missing. Figuring out how much buffer space the receiver needs gets way more complicated too. In this section we talk about a technique for declaring a fragment lost, with the goal of keeping the buffer small while also keeping avoidable packet losses to a minimum 🎀
4.1. Detecting Fragment Loss 🔍
On each member link in a bundle, the sender MUST transmit fragments with strictly increasing sequence numbers (modulo the size of the sequence space). This requirement is what lets the receiver detect lost fragments by comparing sequence numbers ✨ The sequence number is not reset upon each new PPP packet. A sequence number is also used up even by fragments that hold an entire PPP packet, i.e., one where both the (B)eginning and (E)nding bits are set. Yes, even the solo ones count 💖
An implementation MUST set the sequence number of the first fragment transmitted on a newly-constructed bundle to zero. (Joining a secondary link to an existing bundle is invisible to the protocol, and an implementation MUST NOT reset the sequence number space in this situation.) So joining a new link doesn't mean starting over, bestie 🧚
The receiver keeps track of the incoming sequence numbers on each link in a bundle, and maintains the current minimum of the most recently received sequence number over all the member links in the bundle (call this M). The receiver detects the end of a packet when it receives a fragment bearing the (E)nding bit. Reassembly of the packet is complete if all sequence numbers up to that fragment have been received. Main character energy 👑
A lost fragment is detected when M advances past the sequence number of a fragment bearing an (E)nding bit of a packet that hasn't been completely reassembled (i.e., not all the sequence numbers between the fragment bearing the (B)eginning bit and the fragment bearing the (E)nding bit have been received). This works because of the increasing sequence number rule over the bundle 🦋
An implementation MUST assume that if a fragment bears a (B)eginning bit, the previously numbered fragment bore an (E)nding bit. So if a packet is lost bearing the (E)nding bit, and the packet whose fragment number is M contains a (B)eginning bit, the implementation MUST discard fragments for all unassembled packets through M-1. It SHOULD NOT discard the fragment bearing the new (B)eginning bit on this basis alone, though 🙃
Quick recap: the detection of a lost fragment makes the receiver throw out everything up to M. If the fragment with sequence number M has the (B)eginning bit set, the receiver starts reassembling the new packet. Otherwise, it resynchronizes on the next fragment bearing the (B)eginning bit. Any fragments that arrive while the receiver is trying to resync and don't bear the (B)eginning bit SHOULD be discarded. Resync era 🔄
Fragments can get lost because individual packets get corrupted, or because the link goes down catastrophically (which might happen in only one direction). This version of the multilink protocol mandates no specific procedures for detecting failed links 🥲 The PPP link quality management facility, or the periodic sending of LCP echo-requests, could be used to achieve this.
Senders SHOULD avoid keeping any member links idle, to maximize early detection of lost fragments by the receiver, since the value of M is not incremented on idle links. Senders SHOULD also rotate traffic among the member links if there isn't enough traffic to overflow the capacity of one link, so idle links are avoided. Spread the love across the links 💜
Losing the final fragment of a transmission can leave the receiver stalled until new packets arrive. You can lower the odds of this by sending a null fragment on each member link in a bundle that would otherwise go idle right after transmitting a fragment bearing the (E)nding bit. A null fragment is one that consists only of a multilink header bearing both the (B)egin and (E)nding bits (so, no payload). Implementations that are worried about wasting bandwidth or per-packet costs are not required to send null fragments, and may choose to defer sending them until a timer expires, with the slightly increased chance of longer stalls in the receiver 🫠 The receiver SHOULD implement some type of link idle timer to guard against indefinite stalls.
The increasing sequence per link rule prohibits reallocating fragments queued up behind a failing link to a working one. That's not unusual for implementations of ISO multilink over LAPB [4], so it's a known vibe 🙈
4.2. Buffer Space Requirements 📦
There is no amount of buffering that will guarantee correct detection of fragment loss, since an adversarial peer may withhold a fragment on one channel and send arbitrary amounts on the others. Scary, I know 😭 For the usual case where all channels are transmitting, you can show that there is a minimum amount below which you couldn't correctly detect packet loss. That amount depends on the relative delay between the channels (D[channel-i,channel-j]), the data rate of each channel (R[c]), the maximum fragment size permitted on each channel (F[c]), and the total amount of buffering the transmitter has allocated among the channels.
When using PPP, the delay between channels could be estimated by using LCP echo request and echo reply packets. (For links with different transmission rates, the round trip times should be adjusted to account for this.) The slippage for each channel is defined as the bandwidth times the delay for that channel relative to the channel with the longest delay: S[c] = R[c] * D[c,c-worst]. (S[c-worst] will be zero, of course!) 🧮
A situation that would make sequence number skew worse is extremely bursty traffic, where the channels almost all drain. The transmitter first queues up as many consecutively numbered packets on one link as it can, then queues the next batch on a second link, and so on 🌪️ Since transmitters must be able to buffer at least a maximum-sized fragment for each link (and will usually buffer at least two), a receiver that allocates any less than S[1] + S[2] + ... + S[N] + F[1] + ... + F[N] will be at risk of incorrectly assuming packet loss. So it SHOULD allocate at least twice that 🫶
5. PPP Link Control Protocol Extensions 🔗
If reliable multilink operation is desired, PPP Reliable Transmission [6] (essentially the use of ISO LAPB) MUST be negotiated prior to using the Multilink Protocol on each member link. Order matters here, babe 💅
Whether or not reliable delivery is employed over member links, an implementation MUST present a signal to the NCP's running over the multilink arrangement that a loss has occurred. The NCPs need to know when something got lost 😤
Compression may be used separately on each member link, or run over the bundle (as a logical group link). Using multiple compression streams under the bundle (i.e., on each link separately) is indicated by running the Compression Control Protocol [5], but with an alternative PPP protocol ID. Different vibes, different ID 🌈
5.1. Configuration Option Types 🎀
The Multilink Protocol introduces some additional LCP Configuration Options:
- Multilink Maximum Received Reconstructed Unit
- Multilink Short Sequence Number Header Format
- Endpoint Discriminator
5.1.1. Multilink MRRU LCP option ✨
Figure 4: Multilink MRRU LCP option
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 = 17 | Length = 4 | Max-Receive-Reconstructed-Unit|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The presence of this option tells the peer that the system sending it implements the PPP Multilink Protocol. Unless it's rejected, the system will treat all packets received on this link as things a common protocol machine can process alongside any other packets received from the same peer on any other link where this option has been accepted. A system MUST NOT accept the Multilink MRRU LCP Option if it isn't willing to have the packets it sends interpreted in the same fashion, symmetrically. Fair is fair 🤝
This option also advises the peer that the implementation will be able to reconstruct a PPP packet whose payload will contain the number of bytes given as Max-Receive-Reconstructed-Unit. Big reconstruction energy 🧩
A system MAY indicate the desire to conduct multilink operation solely by using the Multilink Short Sequence Number Header Format LCP option (discussed next). The default value for the MRRU option is 1600 bytes if it isn't otherwise explicitly negotiated 🍓
Note: this option corresponds to what would have been the MRU of the bundle when conceptualized as a PPP-like entity. 🧚
5.1.2. Short Sequence Number Header Format Option 🎀
Okay so, this option is basically the implementation going "hey bestie, I'd love to receive fragments with short 12-bit sequence numbers 🦋." By default, sequence numbers are 24 bits long ✨ so this is the glow-up option.
Figure 5: Short Sequence Number Header Format Option
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 18 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+When this option is received, an implementation MUST either transmit all subsequent multilink packets on all links of the bundle with 12-bit sequence numbers, or configure-NAK or configure-Reject the option. No cap, it's one or the other 💅
An implementation that wants to transmit multilink fragments with short sequence numbers MAY include the multilink short sequence number in a configure-NAK to ask the peer to respond with a request to receive short sequence numbers 🧚. The peer is not compelled to respond with the option, so no pressure 🙈
5.1.3. Endpoint Discriminator Option 💜
The Endpoint Discriminator Option is how a system says who it is 🪪 It's giving identity.
Figure 7: Endpoint Discriminator Option
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 = 19 | Length | Class | Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This option tells a system that the peer on this link could be the same peer as one on another existing link. If the option distinguishes this peer from all others, a new bundle MUST be established from the link being negotiated. If the option matches the class and address of some other peer on an existing link, the new link MUST be joined to the bundle containing the link to the matching peer, or MUST establish a new bundle. Which one depends on the decision tree in (1) through (4) below. Main character decision-making ✨
To securely join an existing bundle, a PPP authentication protocol [3] must be used to get authenticated information from the peer. Without it, a hostile peer could join an existing bundle just by presenting a falsified discriminator option 😭 not on my watch.
This option is not required for multilink operation. If a system doesn't receive either the Multilink MRRU or Short Sequence options, but does receive the Endpoint Discriminator Option, and there's no manual configuration providing outside information, the implementation MUST NOT assume that multilink operation is being requested based on this alone 🙅♀️
Since there's also no requirement for authentication, there are four sets of scenarios:
(1) No authentication, no discriminator:
All new links MUST be joined to one bundle.
(2) Discriminator, no authentication:
Discriminator match -> MUST join matching bundle,
discriminator mismatch -> MUST establish new bundle.
(3) No discriminator, authentication:
Authenticated match -> MUST join matching bundle,
authenticated mismatch -> MUST establish new bundle.
(4) Discriminator, authentication:
Discriminator match and authenticated match -> MUST join bundle,
discriminator mismatch -> MUST establish new bundle,
authenticated mismatch -> MUST establish new bundle.The option contains a Class, which picks an identifier address space, and an Address, which picks a unique identifier within that class's address space ✨
This identifier is expected to refer to the mechanical equipment associated with the transmitting system. For some classes, the identifier is globally unique and isn't limited to a particular administrative domain. Within each class, uniqueness of the address values is controlled by a class-dependent policy for assigning values 🌸
Each endpoint may choose an identifier class without restriction. The goal is to catch mismatches between endpoints that were wrongly assumed to be alike, so a mismatch on class alone is enough 🎯 No single class is recommended, but classes with universally unique values are preferred.
This option doesn't have to be supported by the system or the peer. If the option is not present in a Configure-Request, the system MUST NOT generate a Configure-Nak of this option. Instead, it SHOULD behave as if it had received the option with Class = 0, Address = 0. If a system receives a Configure-Nak or Configure-Reject of this option, it MUST remove it from any additional Configure-Request.
The size comes from the Length field of the element. For some classes the length is fixed, and for others it's variable. The option is invalid if the Length field indicates a size below the minimum for the class.
An implementation MAY use the Endpoint Discriminator to look up administration or authentication records in a local database. That use is incidental to the option's purpose, and it's deprecated when a PPP Authentication protocol [3] can be used instead. Some classes let the peer generate random or locally assigned address values, so using this option as a database key requires prior agreement between the peer administrators 🤝
The subfields are specified as follows:
Type
19 = for Endpoint Discriminator
Length
3 + length of Address
Class
The Class field is one octet and indicates the identifier address space. The most up-to-date values of the LCP Endpoint Discriminator Class field are specified in the most recent "Assigned Numbers" RFC [7]. The current values are:
0 Null Class
1 Locally Assigned Address
2 Internet Protocol (IP) Address
3 IEEE 802.1 Globally Assigned MAC Address
4 PPP Magic-Number Block
5 Public Switched Network Directory NumberAddress
The Address field is one or more octets and indicates the identifier address within the selected class. The length and content depend on the Class value, as follows 💖
Class 0 - Null Class
- Maximum Length: 0
- Content: This class is the default value if the option is not present in a received Configure-Request.
Class 1 - Locally Assigned Address
- Maximum Length: 20
- Content: This class lets you do a local assignment when using one of the globally unique classes isn't possible. Using a device serial number is suggested. The use of this class is deprecated since uniqueness is not guaranteed 🙃
Class 2 - Internet Protocol (IP) Address
- Fixed Length: 4
- Content: An address in this class contains an IP host address as defined in [8].
Class 3 - IEEE 802.1 Globally Assigned MAC Address
- Fixed Length: 6
- Content: An address in this class contains an IEEE 802.1 MAC address in canonical (802.3) format [9]. The address MUST have the global/local assignment bit clear and MUST have the multicast/specific bit clear. Locally assigned MAC addresses should be represented using Class 1.
Class 4 - PPP Magic-Number Block
- Maximum Length: 20
- Content: This isn't an address, it's a block of 1 to 5 concatenated 32-bit PPP Magic-Numbers as defined in [2]. This class gives you automatic generation of a value that's 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 back to itself. There's a small probability that two distinct endpoints will generate matching magic-numbers. That probability drops geometrically when the LCP negotiation is repeated in search of the desired mismatch, as long as a peer can generate uncorrelated magic-numbers 📉
As used here, magic-numbers determine whether two links come from the same peer endpoint or from two distinct endpoints. The numbers always match when there's only one endpoint. There's a small probability that they'll match even with two endpoints. To get the same confidence against a false match as you get for LCP loopback detection, you can combine several uncorrelated magic-numbers 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). It represents an international telephone directory number suitable for reaching the endpoint over the public switched telephone network [10] 📞
6. 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 member links usually don't reorder packets, receiving a terminate ack is enough to assume that any multilink protocol packets ahead of it are at no special risk of loss ✨
Receiving an LCP terminate-request on one link does not conclude the procedure on the remaining links. It's not a breakup, it's a one-link exit 🫶
As long as any member links in the bundle are active, the PPP state for the bundle persists as a separate entity 💅
If the multilink procedure is used together with PPP reliable transmission, and a member link is not closed gracefully, the implementation should expect to receive packets that violate the increasing sequence number rule 😬
7. Interaction with Other Protocols 🧚
In the common case, LCP and the Authentication Control Protocol would be negotiated over each member link. The Network Protocols and their 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 exempt from sequencing requirements. If the MRU sizes of the link didn't 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 you wanted independent sequencing of two protocol sets without one blocking the other, you could describe two multilink procedures by assigning multiple endpoint identifiers to one system. Each member link, however, would only belong to one bundle. Think of a physical router housing two logically separate implementations, each configured independently 🤖
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. Easy peasy 🍓
8. Security Considerations 🔒
This section is short, but it is NOT a vibe to skip. Security is serious business, bestie 🔥
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.
9. References ✨
okay bestie, here's the full reading list 📚💖 every source the spec leans on, with all the details, no skipping 💅
[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, Work in Progress.
[6] Rand, D., "PPP Reliable Transmission", PPP Extensions Working Group, Work in Progress.
[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.
[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.
10. Authors' Addresses 💌
the crew behind this spec 🫶 here's where to find them
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.EDUBrian Lloyd
Lloyd Internetworking
3031 Alhambra Drive
Cameron Park, CA 95682
Phone: (916) 676-1147
EMail: brian@lloyd.comGlenn McGregor
Lloyd Internetworking
3031 Alhambra Drive
Cameron Park, CA 95682
Phone: (916) 676-1147
EMail: glenn@lloyd.comDave Carr
Newbridge Networks Corporation
600 March Road
P.O. Box 13600
Kanata, Ontario,
Canada, K2K 2E6
Phone: (613) 591-3600
EMail: dcarr@Newbridge.COM📦 where this page comes from
- ietf: rfc1717 1994-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms