RFC 1172
Point-to-Point Protocol (PPP) initial configuration options
RFC 1172: The Point-to-Point Protocol (PPP) Initial Configuration Options 💖🎀
Okay bestie, this one is from July 1990 and it was written by D. Perkins (CMU) and R. Hobby (UC Davis) for the Network Working Group ✨. It's an IAB standards track protocol, and the header doesn't list any Obsoletes or Updates lines. So it's a clean, standalone spec 🦋
Status of This Memo 📜
This RFC specifies an IAB standards track protocol for the Internet community 🌐
For the actual standardization state and status of this protocol, go check the current edition of the "IAB Official Protocol Standards" 👀
This proposal came out of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF) 🫶 If you have comments, send them to the IETF Point-to-Point Protocol Working Group chair.
Distribution of this memo is unlimited 🌸
Abstract 🧚
The Point-to-Point Protocol (PPP) gives us a way to transmit datagrams over serial point-to-point links 🔌 PPP is made of three pieces:
- a method for encapsulating datagrams over serial links,
- an extensible Link Control Protocol (LCP), and
- a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.
The PPP encapsulating scheme, the basic LCP, and an NCP for controlling and establishing the Internet Protocol (IP) (called the IP Control Protocol, IPCP) are all defined in The Point-to-Point Protocol (PPP) [1] 📖
This document defines the initial options used by the LCP and IPCP. It also defines a method of Link Quality Monitoring and a simple authentication scheme 💅
Table of Contents 🗂️
1. Introduction .......................................... 1
2. Link Control Protocol (LCP) Configuration Options ..... 1
2.1 Maximum-Receive-Unit ............................ 2
2.2 Async-Control-Character-Map ..................... 3
2.3 Authentication-Type ............................. 5
2.4 Magic-Number .................................... 7
2.5 Link-Quality-Monitoring ......................... 10
2.6 Protocol-Field-Compression ...................... 11
2.7 Address-and-Control-Field-Compression ........... 13
3. Link Quality Monitoring ............................... 15
3.1 Design Motivation ............................... 15
3.2 Design Overview ................................. 15
3.3 Processes ....................................... 16
3.4 Counters ........................................ 18
3.5 Measurements, Calculations, State Variables ..... 19
3.6 Link-Quality-Report Packet Format ............... 21
3.7 Policy Suggestions .............................. 25
3.8 Example ......................................... 25
4. Password Authentication Protocol ...................... 27
4.1 Packet Format ................................... 27
4.2 Authenticate .................................... 29
4.3 Authenticate-Ack ................................ 31
4.4 Authenticate-Nak ................................ 32
5. IP Control Protocol (IPCP) Configuration Options ...... 33
5.1 IP-Addresses .................................... 34
5.2 Compression-Type ................................ 36
REFERENCES ................................................... 37
SECURITY CONSIDERATIONS ...................................... 37
AUTHOR'S ADDRESS ............................................. 371. Introduction ✨
PPP [1] proposes a standard method of encapsulating IP datagrams, and other Network Layer protocol information, over point-to-point links 🔗 It also proposes an extensible Option Negotiation Protocol. [1] only specifies the protocol itself, so the initial set of Configuration Options lives in this document 📝 These options let you change MTUs, dynamically assign IP addresses, turn on header compression, and so much more 💜
Here's the roadmap 🗺️ Section 2 covers Configuration Options for the Link Control Protocol. Section 3 specifies the Link Quality Monitoring option. Section 4 defines a simple Password Authentication Protocol. And finally, Section 5 specifies Configuration Options for the IP Control Protocol 💅
2. Link Control Protocol (LCP) Configuration Options 🎀
As described in [1], LCP Configuration Options let you negotiate changes to the standard characteristics of a point-to-point link 🤝 The changes this document proposes include things like the maximum receive unit, async control character mapping, the link authentication method, and so on 🌈
The initial proposed values for the LCP Configuration Option Type field (see [1]) are assigned like this 👑
1 Maximum-Receive-Unit
2 Async-Control-Character-Map
3 Authentication-Type
4 NOT ASSIGNED
5 Magic-Number
6 Link-Quality-Monitoring
7 Protocol-Field-Compression
8 Address-and-Control-Field-Compression2.1. Maximum-Receive-Unit 📦
Description
This Configuration Option lets you negotiate the maximum packet size used across one direction of a link 📏 By default, all implementations must be able to receive frames with 1500 octets of Information.
You can send this Configuration Option to tell the remote end that you can receive larger frames, or to ask the remote end to send you smaller frames 🙌 If smaller frames are requested, an implementation MUST still be able to receive 1500 octet frames in case link synchronization is lost 😭
Here's the summary of the Maximum-Receive-Unit Configuration Option format. The fields go 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 | Maximum-Receive-Unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
1
Length
4
Maximum-Receive-Unit
The Maximum-Receive-Unit field is two octets and holds the new maximum receive unit 🧁 The Maximum-Receive-Unit only covers the Data Link Layer Information field. It does not cover the header, the trailer, or any transparency bits or bytes 🫧
Default
1500
2.2. Async-Control-Character-Map 🦋
Description
This Configuration Option lets you negotiate the use of control character mapping on asynchronous links 🌊 By default, PPP maps all control characters into an appropriate two character sequence. But it's rarely necessary to map all control characters, and it's often unnecessary to map any characters at all 🙈
A PPP implementation can use this Configuration Option to tell the remote end which control characters must remain mapped, and which control characters don't need to stay mapped when the remote end sends them. The remote end may still send these control characters in mapped format if it's necessary because of constraints at its (the remote) end 🫶 This option doesn't solve problems for communications links that can only send 7-bit characters, or that can't send all non-control characters 💀
There may be some use of synchronous-to-asynchronous converters (some built into modems) on point-to-point links, which means one end can be a synchronous PPP implementation and the other end an asynchronous one 🔄 The converter is responsible for doing all the mapping conversions during operation 🧚 To make this work, synchronous PPP implementations MUST always accept an Async-Control-Character-Map Configuration Option. They MUST always respond to an LCP Configure-Request specifying this Configuration Option with an LCP Configure-Ack 💖 However, accepting this Configuration Option doesn't mean the synchronous implementation will do any character mapping, because synchronous PPP uses bit-stuffing rather than character-stuffing 🌸 Instead, all of that character mapping is done by the asynchronous-to-synchronous converter ✨
Here's the summary of the Async-Control-Character-Map Configuration Option format. The fields go 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 | Async-Control-Character-Map
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
2
Length
6
Async-Control-Character-Map
The Async-Control-Character-Map field is four octets and holds the new async control character map 🗺️ The map is encoded in big-endian fashion, where each numbered bit corresponds to the ASCII control character of the same value. If the bit is cleared to zero, that ASCII control character need not be mapped. If the bit is set to one, that ASCII control character must remain mapped. For example, if bit 19 is set to zero, then ASCII control character 19 (DC3, Control-S) may be sent in the clear 🫧
Default
All ones (0xffffffff) 👑
2.3. Authentication-Type ✨
Description
okay so sometimes a link needs the other side to prove who they are before any Network Layer data is allowed to flow 🔐 this option is how you negotiate which authentication protocol to use for that. by default, no authentication is needed. if your implementation needs the remote end to authenticate with a specific protocol, it should negotiate that protocol using this option 💅
when Authentication-Type gets successfully negotiated, it adds an extra Authentication phase to the Link Control Protocol. that phase sits after Link Quality Determination and before Network Layer Protocol Configuration Negotiation 🫶 you can't move from Authentication into Network Layer configuration until the peer has actually been authenticated with the protocol you agreed on. no skipping the bouncer, periodt 🚫
an implementation can let the remote end pick from more than one authentication protocol 🎀 to do that, it can include several Authentication-Type options in its Configure-Request packets. when an implementation gets a Configure-Request listing multiple Authentication-Types, it can accept at most one of the protocols it supports, and it should send a Configure-Reject that lists all of the other ones 🦋
Each PPP implementation is recommended to support configuring authentication parameters at least per interface, and ideally per peer entity too. these parameters should spell out which authentication techniques are the bare minimum required before a PPP connection can be set up, either for that interface or for that peer. this matters a LOT 😭 without it, an attacker could push the negotiation toward a weaker authentication protocol, or none at all, just to get around the whole authentication step 💀
if an implementation sends a Configure-Ack with this option, it's basically saying "yep, I'll authenticate with that protocol" ✨ and if an implementation receives a Configure-Ack with this option, it should expect the remote end to authenticate using the protocol that was acknowledged 🌸
authentication doesn't have to be full duplex, and both directions don't have to use the same protocol 🧚 each direction can use a different one, totally fine. it all depends on which authentication protocols were negotiated 💜
this document defines one simple Password Authentication Protocol in Section 4 🔑 the authors are very much encouraging people to build more secure protocols too 👑
here's what the Authentication-Type option looks like on the wire. fields go 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 | Authentication-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+Type
3 🍓
Length
>= 4 🍓
Authentication-Type
this is two octets and it tells you which authentication protocol you want 🎯 the values are always the same as the PPP Data Link Layer Protocol field values for that same authentication protocol. the most up-to-date values live in "Assigned Numbers" [2]. right now, the initial assignment is:
Value (in hex) Protocol
c023 Password Authentication ProtocolData
the Data field is zero or more octets, and what goes in it depends on the particular authentication protocol 🧁
Default
No authentication protocol necessary. 💖
2.4. Magic-Number 🪞
Description
this option is how you detect looped-back links and other Data Link Layer weirdness 🔁 some other options, like the Link-Quality-Monitoring option, might require it too 🫶
before you request this option, an implementation must pick its Magic-Number 🎲 the recommendation is to pick it as randomly as humanly possible, so that you're practically guaranteed to end up with a number nobody else has ✨ a solid way to do that is to start from a unique seed. good sources of uniqueness include machine serial numbers, other network hardware addresses, time-of-day clocks, and so on 🕰️ the really premium seeds are super precise measurements of random physical events, like the inter-arrival time of packets on other connected networks, server response times, or how fast a human types 😭 and it's suggested you use as many of these sources at once as you can 🌈
now, when a Configure-Request with a Magic-Number option comes in, you should compare the received Magic-Number to the Magic-Number from the last Configure-Request you sent to that peer 👀 if they're different, the link isn't looped-back, and you should acknowledge the Magic-Number. if they're the same, the link might be looped-back, and that Configure-Request might actually be the one you sent last 🙈 to find out, you should send a Configure-Nak with a different Magic-Number value. don't send a new Configure-Request to the peer until normal processing would send one anyway (so, until a Configure-Nak arrives or the Restart timer runs out) ⏳
when a Configure-Nak comes in with a Magic-Number that's different from the one in the last Configure-Nak you sent, that proves the link isn't looped-back, and it tells you the Magic-Number is unique 🎉 if the Magic-Number matches the one in the last Configure-Nak you sent, the chance of a loop-back goes up, so you should pick a new Magic-Number. either way, send a new Configure-Request with the new Magic-Number 🔄
if the link really is looped-back, this loop (send Configure-Request, receive Configure-Request, send Configure-Nak, receive Configure-Nak) just keeps going forever 🌀 if the link isn't looped-back, it might happen a few times, but it's extremely unlikely to keep happening. more likely, the Magic-Numbers at each end will quickly diverge and end the loop 💅 here's the probability of collisions, assuming both ends pick 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-29none of this divergence stuff works without good sources of uniqueness or randomness 😭 if you can't find a good source of uniqueness, it's recommended that you don't enable this option. in that case, you shouldn't send Configure-Requests with the option, and any Magic-Number options the peer sends should be either acknowledged or rejected. the implementation won't be able to reliably detect loop-backs on its own, though the peer might still be able to detect them 🫠
if an implementation does send a Configure-Request with a Magic-Number option, then it MUST NOT respond with a Configure-Reject when its peer also sends a Configure-Request with a Magic-Number option 🚫 basically, if you want to use Magic Numbers, you MUST also let your peer use them too 🤝 and if an implementation gets a Configure-Reject in response to its Configure-Request, that can only mean the link isn't looped-back and the peer won't be using Magic-Numbers. in that case, the implementation can act like the negotiation worked out (as if it had received a Configure-Ack instead) ✅
the Magic-Number can also detect loop-backs during normal operation, not just during option negotiation 🔍 all Echo-Request, Echo-Reply, Discard-Request, and Link-Quality-Report LCP packets have a Magic-Number field, which MUST normally be transmitted as zero and MUST normally be ignored on reception 🙃 but once a Magic-Number has been successfully negotiated, an LCP implementation MUST begin transmitting these packets with the Magic-Number field set to its negotiated Magic-Number 🎀 you can also inspect the Magic-Number field of these packets when they arrive. every received Magic-Number field should equal either zero or the peer's unique Magic-Number, depending on whether the peer negotiated one 🧐 if you receive a Magic-Number equal to your own negotiated local Magic-Number, that means the link is looped-back 🔁 if you receive a Magic-Number that's neither your negotiated local Magic-Number nor the peer's negotiated Magic-Number (or zero, if the peer didn't negotiate one), that means the link has been (mis)configured to talk to a different peer 📡
what to do about either of these situations isn't specified, and it can vary from implementation to implementation 🤷♀️ one fairly pessimistic approach is to assume an LCP Physical-Layer-Down event and move straight to the Closed state. then an Active-Open event starts the process of re-establishing the link, which can't finish until the loop-back condition ends and Magic-Numbers are successfully negotiated 🛑 a more optimistic approach, for the loop-back case, is to start sending LCP Echo-Request packets until a suitable Echo-Reply arrives, which tells you the loop-back condition has ended 🌤️
here's the Magic-Number option format. fields go 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
this is four octets and it's a number that's very likely unique to one end of the link 🪄 a Magic-Number of zero is illegal and must not be sent 🙅♀️
Default
None. 💜
2.5. Link-Quality-Monitoring ✨
okay so on some links it's super useful to figure out when, and how often, the link is dropping data 👀 This is called Link Quality Monitoring, and it works by sending Link-Quality-Report packets every so often (more on those in Section 3 🎀). The Link-Quality-Monitoring Configuration Option is how you turn on Link-Quality-Report packets and agree on how fast they go. By default, Link Quality Monitoring and Link-Quality-Report packets are disabled 🙅♀️
A quick peek at the Link-Quality-Monitoring Configuration Option format, read 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 | Reporting-Period
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reporting-Period (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
6 🍓
Length
6 🍓
Reporting-Period
This field is four octets and tells you the maximum time, in micro-seconds, that the remote end should wait between sending LCP Link-Quality-Report packets 🕰️ A value of zero is illegal, so it should always be nak'd or rejected 🙅♀️ Also, an LCP implementation is always free to send Link-Quality-Report packets faster than what was requested by, and acknowledged to, the remote end ⚡
Default
None 🫥
2.6. Protocol-Field-Compression 🦋
Description
This Configuration Option lets you negotiate compressing the Data Link Layer Protocol field 🗜️ By default, every implementation must send standard PPP frames with two octet Protocol fields, no shortcuts 😤 BUT, PPP Protocol field numbers are picked so that some values can squish into a single octet, and that single octet looks totally different from the two octet version 👀 You can send this Configuration Option to tell the remote end that you're able to receive those compressed single octet Protocol fields. Compressed Protocol fields can't be sent until this Configuration Option has been received 🔒
Okay, remember how the Protocol field uses an extension mechanism that matches the ISO 3309 one for the Address field? The Least Significant Bit (LSB) of each octet tells you whether the field keeps going 🧠 A binary "0" as the LSB means the Protocol field continues into the next octet. A binary "1" as the LSB marks the last octet. And here's the fun part: you can stick any number of "0" octets in front and it still means the same value (look at 3, which can be 00000011 or 00000000 00000011, same girl, different outfit 💜).
For simplicity, the standard PPP frame takes advantage of that and always sends Protocol fields in a two octet form. Protocol field values less than 256 (decimal) get a single zero octet stuck on the front, even though sending that zero octet, which is the most significant octet, isn't actually needed 🙃
On low speed links though, you want to save bandwidth and send as little extra data as possible 🐢 The Protocol Compression Configuration Option is basically a trade-off between simple code and bandwidth efficiency ⚖️ If it's successfully negotiated, the ISO 3309 extension mechanism can squish the Protocol field down to one octet instead of two 🌸 Most frames can be compressed, since data protocols usually have Protocol field values under 256 ✨
To make sure LCP packets are always recognized without confusion, the Protocol field must never be compressed when sending any LCP packet 🔐 Also, PPP implementations must keep being robust: they MUST accept PPP frames with double-octet Protocol fields as well as single-octet ones, and they MUST NOT distinguish between them 🫶
When a Protocol field is compressed, the Data Link Layer FCS field is calculated on the compressed frame, not the original uncompressed frame 🧮
A look at the Protocol-Field-Compression Configuration Option format, read left to right 💖
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
7 🎀
Length
2 🎀
Default
Disabled. 🙅♀️
2.7. Address-and-Control-Field-Compression 🧚
Description
This Configuration Option lets you negotiate compressing the Data Link Layer Address and Control fields 🪄 By default, every implementation has to send frames with Address and Control fields, and they have to use the hexadecimal values 0xff and 0x03 respectively 💅 Those fields always have the same constant values, which makes them super easy to compress 🌈 You can use this Configuration Option to tell the remote end that you can receive compressed Address and Control fields.
Compressed Address and Control fields are made by just leaving them out, but only in cases where it's not ambiguous 🕵️♀️ Ambiguous frames can't be compressed. Things get ambiguous when the two octets right after the Address and Control fields look like valid Address and Control fields (so 0xff and 0x03). That can happen when Protocol-Field-Compression is on and the Protocol field gets squished to one octet 😬 If the Protocol value is 0xff and the first octet of the Information field is 0x03, it's ambiguous, so the Address and Control fields must not be compressed when sending 🚫
When receiving, you decompress the Address and Control fields by looking at the first two octets 🔍 If they're 0xff and 0x03, those are the Address and Control fields. If not, the fields were compressed and never got sent at all 🫥
There's one more case where the Address and Control fields must never be compressed: when sending any LCP packet. That rule keeps LCP packets clearly recognizable 💜
When the Address and Control fields are compressed, the Data Link Layer FCS field is calculated on the compressed frame, not the original uncompressed frame 🧮
A look at the Address-and-Control-Field-Compression configuration option format, read left to right 🍭
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TypeType
8 🌷
Length
2 🌷
Default
Not compressed. 🫶
3. Link Quality Monitoring 🔥
Okay real talk, data links are never perfect 😭 Packets get dropped or corrupted for all kinds of reasons: line noise, equipment failing, buffers overrunning, you name it 📉 Sometimes you really want to know when, and how often, the link is dropping data. Routers, for example, might want to temporarily let another route take priority 🛣️ An implementation can also choose to disconnect and switch to an alternate link 🔀 The process of figuring out data loss is called "Link Quality Monitoring" 💖
3.1. Design Motivation 🎨
There are tons of ways to measure link quality, and even more ways to react to it 🙈 So instead of picking just one scheme, Link Quality Monitoring is split into a "mechanism" and a "policy" 🧩 PPP fully specifies the "mechanism" by defining the LCP Link-Quality-Report (LQR) packet and describing how to use it 🎀 But PPP does NOT specify a Link Quality Monitoring "policy": how to judge link quality, or what to do when it isn't good enough 🤷♀️ That part is an implementation decision, and it can be different at each end of the link 🌈 Implementations are allowed, and even encouraged, to experiment with different link quality policies 🧪 The Link Quality Monitoring mechanism is what makes sure two implementations with different policies can still talk to each other and interoperate 🫶
To let flexible policies happen, the PPP Link Quality Monitoring mechanism measures data loss in units of packets, octets, and Link-Quality-Reports 📊 Each measurement is made separately for each half of the link, inbound and outbound both ✨ All of the measurements get communicated to both ends, so each end can run its own link quality policy for its outbound and inbound links 💅
Last but not least, the Link Quality Monitoring protocol is designed to work on lots of different kinds of systems 🖥️ Sure, it's common to build PPP (especially Link Quality Monitoring) as one software process, but multi-process implementations with hardware support are also planned 🔧 The PPP Link Quality Monitoring mechanism makes that possible through a careful definition of the Link-Quality-Report packet format, and by specifying reference points for all data transmission and reception measurements 🦋
3.2. Design Overview ✨
Okay so every Link Quality Monitoring implementation keeps count of how many packets and octets it has sent and successfully received 📦, and it periodically sends that info to its peer in a Link-Quality-Report packet 💌. Each one has three sections: a Header section, a Counters section, and a Measurements section 🎀.
The Header section is just the normal LCP Link Maintenance packet header, with the Code, Identifier, Length and Magic-Number fields 🧾.
The Counters section has four counters and gives you everything you need to measure link quality 📊. The LQR transmitter fills in two of them: Out-Tx-Packets-Ctr and Out-Tx-Octets-Ctr (more on those later). The LQR receiver fills in the other two: In-Rx-Packets-Ctr and In-Rx-Octets-Ctr. These counters act kind of like sequence numbers 🔢. They keep climbing, which gives a "relative" sense of how many packets and octets have moved across the outbound link. By comparing successive Link-Quality-Reports, an LQR receiver can work out the "absolute" number of packets and octets across its inbound link, and comparing those absolute numbers tells you how healthy the inbound link is 🩺. Relative numbers get sent instead of absolute ones because they make link synchronization way easier: an implementation just waits to receive two LQR packets. Iconic, honestly 👑.
The Measurements section has six state variables: In-Tx-LQRs, Last-In-Id, In-Tx-Packets, In-Tx-Octets, In-Rx-Packets, and In-Rx-Octets (also later 🫶). This lets an implementation report its inbound link quality to its peer, who sees it as outbound link quality in the report, by sending the absolute, not relative, number of LQRs, packets, and octets across the inbound link 🦋. The values come from watching the Counters section of the Link-Quality-Report packets received on the inbound link. Absolute numbers are safe to use here with no synchronization problems, because you only need to receive one LQR packet to have valid info 💅.
The rest of the section goes deeper, in this order: the processes in the mechanism, the packet and byte counters, the measurements, calculations and state variables, the Link-Quality-Report packet format, some policy suggestions, and finally an example link quality calculation 🗺️.
3.3. Processes 🔄
The PPP Link Quality Monitoring mechanism is described using a "logical process" model. As shown below, there are five logical processes duplicated at each end of the duplex link 🪞.
+---------+ +-------+ +----+ Outbound
| |-->| Mux |-->| Tx |=========>
| Link- | +-------+ +----+
| Manager |
| | +-------+ +----+ Inbound
| |<--| Demux |<--| Rx |<=========
+---------+ +-------+ +----+Link-Manager 👑
The Link-Manager process transmits and receives Link-Quality-Reports, and it implements the desired link quality policy 🧠. LQR packets are transmitted at a constant rate, which is negotiated by the LCP Link-Quality-Monitoring Configuration Option. The Link-Manager process fills in only the Header and Measurements sections of the packet. The Counters section gets filled in by the Tx and Rx processes, so the Link-Manager is not doing that part 🙅♀️.
Mux 🧵
The Mux process multiplexes packets from the various protocols (e.g., LCP, IP, XNS, etc.) into a single, sequential, and prioritized stream of packets 🚦. Link-Quality-Report packets MUST be given the highest possible priority to insure that link quality information is communicated in a timely manner ⏰. No skipping the line for anyone else, LQR packets get the VIP pass 🎟️.
Tx 📤
The Tx process maintains the counters Out-Tx-Packets-Ctr and Out-Tx-Octets-Ctr, which measure the amount of data transmitted on the outbound link 📈. When Tx processes a Link-Quality-Report packet, it inserts the values of these counters into the Counters section of the packet. Because these counters are relative rather than absolute, the question of when to update them, before or after they are inserted into a Link-Quality-Report packet, is left as an implementation decision 🤷♀️. However, an implementation MUST make this decision the same way every time 🔁. The Tx process MUST follow the Mux process so that packets are counted in the order transmitted to the link 🎯.
Rx 📥
The Rx process maintains the counters In-Rx-Packets-Ctr and In-Rx-Octets-Ctr, which measure the amount of data received by the inbound link 📬. When Rx processes a Link-Quality-Report packet, it inserts the values of these counters into the Counters section of the packet. Again, the question of when to update the counters, before or after they are inserted into a Link-Quality-Report packet, is an implementation decision which MUST be made consistently the same way 💜.
Demux 🔀
The Demux process demultiplexes packets for the various protocols 📭. The Demux process MUST follow the Rx process so that packets are counted in the order received from the link 🙌.
3.4. Counters 🔢
In order to fill in the Counters section of a Link-Quality-Report packet, Link Quality Monitoring requires the implementation of one 8-bit unsigned counter and four 32-bit unsigned counters, all monotonically increasing ⬆️. These counters may be reset to any initial value before the first Link-Quality-Report is transmitted, but they MUST NOT be reset again until LCP has left the Open state 🔒. Counters wrap to zero when their maximum value is reached (for 32 bit counters: 0xffffffff + 1 = 0) 🔄.
Out-Identifier-Ctr 🪪
Out-Identifier-Ctr is an 8-bit counter maintained by the Link-Manager process. It increases by one for each transmitted Link-Quality-Report packet 📨.
Out-Tx-Packets-Ctr 📦
Out-Tx-Packets-Ctr is a 32-bit counter maintained by the Tx process. It increases by one for each transmitted Data Link Layer packet 🚀.
Out-Tx-Octets-Ctr 🧮
Out-Tx-Octets-Ctr is a 32-bit counter maintained by the Tx process. It increases by one for each octet in a transmitted Data Link Layer packet. All octets which are included in the FCS calculation MUST be counted, as should the FCS octets themselves. All other octets MUST NOT be counted 🙃.
In-Rx-Packets-Ctr 🎁
In-Rx-Packets-Ctr is a 32-bit counter maintained by the Rx process. It increases by one for each successfully received Data Link Layer packet. Packets with incorrect FCS fields or other problems MUST not be counted 🚫.
In-Rx-Octets-Ctr 💌
In-Rx-Octets-Ctr is a 32-bit counter maintained by the Rx process. It increases by one for each octet in a successfully received Data Link Layer packet. All octets which are included in an FCS calculation MUST be counted, as should the FCS octets themselves. All other octets MUST NOT be counted 🫧.
3.5. Measurements, Calculations, State Variables 🧪
In order to fill in the Measurements section of a Link-Quality-Report packet, Link Quality Monitoring requires the Link-Manager process to make a number of calculations and keep a number of state variables 🧑🔬. These calculations are made, and these state variables updated, each time a Link-Quality-Report packet is received from the inbound link 📥.
In-Tx-LQRs 🔁
In-Tx-LQRs is an 8-bit state variable. It indicates the number of Link-Quality-Report packets the peer had to transmit in order for the local end to receive exactly one LQR. In-Tx-LQRs defines the length of the "period" over which In-Tx-Packets, In-Tx-Octets, In-Rx-Packets, and In-Rx-Octets were measured. In-Tx-LQRs is calculated by subtracting Last-In-Id from the received Identifier. If more than 255 LQRs in a row are lost, In-Tx-LQRs will be ambiguous, since the Identifier field and all state variables based on it are only 8 bits 😬. It is assumed that the Link Quality Monitoring policy will be robust enough to handle this case (it should probably close down the link long before this happens) 🙏.
Last-In-Id 🏷️
Last-In-Id is an 8-bit state variable which stores the value of the last received Identifier. Last-In-Id should be updated after In-Tx-LQRs has been calculated 🕰️.
In-Tx-Packets 📤
In-Tx-Packets is a 32-bit state variable. It indicates the number of packets which were transmitted on the inbound link during the last period. In-Tx-Packets is calculated by subtracting Last-Out-Tx-Packets-Ctr from the received Out-Tx-Packets-Ctr 🧮.
Last-Out-Tx-Packets-Ctr 🗂️
Last-Out-Tx-Packets-Ctr is a 32-bit state variable which stores the value of the last received Out-Tx-Packets-Ctr. Last-Out-Tx-Packets-Ctr should be updated after In-Tx-Packets has been calculated 📝.
In-Tx-Octets 🫧
In-Tx-Octets is a 32-bit state variable. It indicates the number of octets which were transmitted on the inbound link during the last period. In-Tx-Octets is calculated by subtracting Last-Out-Tx-Octets-Ctr from the received Out-Tx-Octets-Ctr 🌊.
Last-Out-Tx-Octets-Ctr 📒
Last-Out-Tx-Octets-Ctr is a 32-bit state variable which stores the value of the last received Out-Tx-Octets-Ctr. Last-Out-Tx-Octets-Ctr should be updated after In-Tx-Octets has been calculated 🖊️.
In-Rx-Packets 📬
In-Rx-Packets is a 32-bit state variable. It indicates the number of packets which were received on the inbound link during the last period. In-Rx-Packets is calculated by subtracting Last-In-Rx-Packets-Ctr from the received In-Rx-Packets-Ctr 🧃.
Last-In-Rx-Packets-Ctr 🧷
Last-In-Rx-Packets-Ctr is a 32-bit state variable which stores the value of the last received In-Rx-Packets-Ctr. Last-In-Rx-Packets-Ctr should be updated after In-Rx-Packets has been calculated 💫.
In-Rx-Octets 🌸
In-Rx-Octets is a 32-bit state variable. It indicates the number of octets which were received on the inbound link during the last period. In-Rx-Octets is calculated by subtracting Last-In-Rx-Octets-Ctr from the received In-Rx-Octets-Ctr 🦩.
Last-In-Rx-Octets-Ctr 🎀
Last-In-Rx-Octets-Ctr is a 32-bit state variable which stores the value of the last received In-Rx-Octets-Ctr. Last-In-Rx-Octets-Ctr should be updated after In-Rx-Octets has been calculated 💖.
Measurements-Valid ✅
Measurements-Valid is a 1-bit boolean state variable. It indicates whether or not the In-Tx-Packets, In-Tx-Octets, In-Rx-Packets, and In-Rx-Octets state variables contain valid measurements. These measurements cannot be considered valid until two or more Link-Quality-Report packets have been received on the inbound link. This bit should be reset when LCP reaches the Open state, and should be set after the receipt of exactly two LQRs 🫶🌈.
3.6. Link-Quality-Report Packet Format ✨
okay bestie, here's the Link-Quality-Report layout 🎀 the fields go left to right. Code, Identifier, Length, and Magic-Number are the normal LCP Link Maintenance packet header 💅 then In-Tx-LQRs, Last-In-Id, V, In-Tx-Packets, In-Tx-Octets, In-Rx-Packets, and In-Rx-Octets carry digested absolute measurements (cooked, not raw 🍓). Out-Tx-Packets-Ctr, Out-Tx-Octets-Ctr, In-Rx-Packets-Ctr, and In-Rx-Octets-Ctr carry raw relative counts. ngl the tea is that In-Rx-Packets-Ctr and In-Rx-Octets-Ctr don't actually get sent over the link 🙈 the Rx process logically tacks them onto the packet after it arrives on the inbound link. iconic behaviour, no cap.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In-Tx-LQRs | Last-In-Id | Reserved |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In-Tx-Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In-Tx-Octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In-Rx-Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In-Rx-Octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-Tx-Packets-Ctr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-Tx-Octets-Ctr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/
/
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In-Rx-Packets-Ctr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In-Rx-Octets-Ctr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code
12 for Link-Quality-Report. 💖
Identifier
The Identifier field is one octet and indicates the sequence number for this Link-Quality-Report. It gets copied from the Out-Identifier-Ctr counter on transmission. On reception, the Identifier field is used to calculate In-Tx-LQRs and then gets stored in Last-In-Id. ✨
The Link-Quality-Report Identifier sequence number space MUST be separate from that of all other LCP packets. For example, sending an LCP Echo-Request must not bump the Out-Identifier-Ctr counter. the vibes need to stay separate 🫶
Length
The Length field is two octets and indicates the length of the LQM packet, counting the Code, Identifier, Length and all defined fields. Octets outside the range of the length field should be treated as Data Link Layer padding and should be ignored on reception. For the correct In-Tx-Octets and In-Rx-Octets values to get calculated, Link-Quality-Reports MUST be consistently transmitted with the same amount of padding. consistency is everything, bestie 🎀
Magic-Number
The Magic-Number field is four octets and helps detect looped-back links 🔁 Unless a Configuration Option changes it, the Magic-Number MUST always be transmitted as zero and MUST always be ignored on reception. If Magic-Numbers have been negotiated, incoming LQM packets should be checked to make sure the local end isn't seeing its own Magic-Number, which would mean a looped-back link. not the echo era 💀
In-Tx-LQRs
The In-Tx-LQRs field is one octet and indicates the number of periods covered by the Measurements section of this Link-Quality-Report. It gets copied from the In-Tx-LQRs state variable on transmission. 🌸
Last-In-Id
The Prev-In-Id field is one octet and indicates the age of the Measurements section of this Link-Quality-Report. The Last-In-Id field gets copied from the Last-In-Id field on transmission. On reception, the Last-In-Id field may be compared with the Out-Identifier-Ctr to figure out how many outbound Link-Quality-Reports, if any, got lost. 😭
aside from your bestie: the spec literally says "Prev-In-Id" right here while the field is called Last-In-Id. it's a naming slip in the original, so I've kept the wording exactly as written.
V
The V field is 1 bit and indicates whether or not the Measurements section of this Link-Quality-Report is valid. It gets copied from the Measurements-Valid state variable on transmission. If the V field is not set to 1, then the In-Tx-LQRs, Last-In-Id, In-Tx-Packets, In-Tx-Octets, In-Rx-Packets and In-Rx-Octets fields should be ignored. not valid, not invited 🙅♀️
Reserved
The Reserved field is 15 bits and exists to pad the remaining packet fields out to even four-octet boundaries, which is handy for hardware implementations 🧚 It should always be transmitted as zero and ignored on reception.
In-Tx-Packets
The In-Tx-Packets field is four octets and indicates the number of packets transmitted on the inbound link of the Link-Quality-Report transmitter during the last measured period. It gets copied from the In-Tx-Packets state variable on transmission. 📦
In-Tx-Octets
The In-Tx-Octets field is four octets and indicates the number of octets transmitted on the inbound link of the Link-Quality-Report transmitter during the last measured period. It gets copied from the In-Tx-Octets state variable on transmission. 📦
In-Rx-Packets
The In-Rx-Packets field is four octets and indicates the number of packets received on the inbound link of the Link-Quality-Report transmitter during the last measured period. It gets copied from the In-Rx-Packets state variable on transmission. 🦋
In-Rx-Octets
The In-Rx-Octets field is four octets and indicates the number of octets received on the inbound link of the Link-Quality-Report transmitter during the last measured period. It gets copied from the In-Rx-Octets state variable on transmission. 🦋
Out-Tx-Packets
The Out-Tx-Packets field is four octets and gets used to calculate the number of packets transmitted on the outbound link of the Link-Quality-Report transmitter during a period. It gets copied from the Out-Tx-Packets-Ctr counter on transmission. 🌈
Out-Tx-Octets
The Out-Tx-Octets field is four octets and gets used to calculate the number of octets transmitted on the outbound link of the Link-Quality-Report transmitter during a period. It gets copied from the Out-Tx-Octets-Ctr counter on transmission. 🌈
In-Rx-Packets
The In-Rx-Packets field is four octets and gets used to calculate the number of packets received on the inbound link of the Link-Quality-Report receiver during a period. It gets copied from the In-Rx-Packets-Ctr counter on reception. This one isn't shown in the diagram because it never actually gets transmitted over the link. Instead, the implementation's Rx process logically appends it to the packet, in an implementation dependent manner. 🪄
In-Rx-Octets
The In-Rx-Octets field is four octets and gets used to calculate the number of octets received on the inbound link of the Link-Quality-Report receiver during a period. It gets copied from the In-Rx-Octets-Ctr counter on reception. Also not shown, for the same reason: it isn't transmitted over the link, and the Rx process logically appends it to the packet in an implementation dependent manner. 🪄
3.7. Policy Suggestions 🧠
Link-Quality-Report packets give you a way to figure out the link quality, but each implementation gets to decide when the link is usable. it's giving independence 💅 It is recommended that this policy use some amount of hysteresis so the link doesn't bounce up and down, lowkey chaotic otherwise. A particularly good policy is a K out of N algorithm. In that algorithm, there must be K successes out of the last N periods for the link to count as good quality. ✨
Procedures for recovering from poor quality links are unspecified and may vary from implementation to implementation. A suggested approach is to immediately close all the other Network-Layer protocols (basically, cause IPCP to transmit a Terminate-Req) while still continuing to transmit Link-Quality-Reports. Once the link quality gets back to an acceptable level, the Network-Layer protocols can be reconfigured. the glow-up arc 🌸
3.8. Example 🍓
An example helps, so here we go 🎀 Say Link-Manager implementation A transmits a Link-Quality-Report, and Link-Manager implementation B receives it at time t0 with these values:
Out-Tx-Packets 5
Out-Tx-Octets 100
In-Rx-Packets 3
In-Rx-Octets 70Next, A transmits 20 IP packets with 200 octets, and B receives 15 of those packets and 150 octets. At time t1, A transmits another LQR, which B receives as follows:
Out-Tx-Packets 26 (5 old, plus 20 IP, plus 1 LQR)
Out-Tx-Octets 342 (42 for LQR)
In-Rx-Packets 19
In-Rx-Octets 262Implementation B can now calculate the number of packets and octets transmitted, received and lost on its inbound link like this 🧮
In-Tx-Packets = 26 - 5 = 21
In-Tx-Octets = 342 - 100 = 242
In-Rx-Packets = 10 - 3 = 16
In-Rx-Octets = 262 - 70 = 192
In-Lost-Packets = 21 - 16 = 5
In-Lost-Octets = 242 - 192 = 50After doing these calculations, B evaluates the measurements however its implemented policy says to. Also, the next time B transmits an LQR to A, it reports these values in the Measurements section, so A can evaluate those same measurements too. the group chat is fully synced now 🫶💜
4. Password Authentication Protocol ✨
okay so PAP (Password Authentication Protocol) is how you prove who you are to the other end of a link 🔐. Before you can use it, both sides have to agree on it during LCP with the Authentication-Type Configuration Option. Once that's agreed, an extra Authentication phase gets slotted into LCP, right after the Link Quality Determination phase and right before the Network Layer Protocol Configuration Negotiation phase. PAP packets that show up before the Authentication phase has started should be silently discarded 🙈. The Authentication phase ends as soon as an Authenticate-Ack packet has been sent or received.
PAP is mainly for hosts and routers that dial in over switched circuits or dial-up lines to a PPP network server 📞. The server can use who the caller is to pick options for the network layer negotiations, or it can drop the connection if the authentication fails 👋.
PAP is NOT a strong authentication method, bestie 💀. Passwords cross the circuit in the clear, and there's zero protection against repeated trial-and-error attacks. People are working on better authentication methods for PPP and other protocols right now, and it is strongly recommended to switch to those once they're available 🫶.
4.1. Packet Format
Exactly one Password Authentication Protocol packet gets encapsulated in the Information field of a PPP Data Link Layer frame whenever the protocol field says c023 (Password Authentication Protocol) 🎀. The fields go out from left to right, like reading a text 📖.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+Code
The Code field is one octet and tells you what type of PAP packet this is. PAP Codes are assigned like this:
1Authenticate2Authenticate-Ack3Authenticate-Nak
Identifier
The Identifier field is one octet, and it helps match up requests with their replies 🧩.
Length
The Length field is two octets and shows the length of the whole PAP packet, counting the Code, Identifier, Length and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding, and they should be ignored when received 🗑️.
Data
The Data field is zero or more octets. Its format depends on what's in the Code field 👀.
4.2. Authenticate
Description
The Authenticate packet is what kicks off the Password Authentication Protocol 🚀. An implementation that has sent an LCP Configure-Ack packet with an Authentication-Type Configuration Option that specifies the Password Authentication Protocol must send an Authenticate packet during the Authentication phase. An implementation that receives a Configure-Ack with that Configuration Option should expect the remote end to send an Authenticate packet during this phase 💅.
An Authenticate packet is sent with the Code field set to 1 (Authenticate), and the Peer-ID and Password fields filled in however you like ✍️.
Whenever an Authenticate comes in, some type of Authenticate reply MUST be transmitted. No ghosting allowed 😤📱.
Here's what the Authenticate packet looks like. The fields go out 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-ID Length| Peer-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+
| Passwd-Length | Password ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+Code
1 for Authenticate.
Identifier
The Identifier field is one octet and helps match requests with replies. It should be changed every time an Authenticate is transmitted that's different from the preceding request 🔄.
Peer-ID-Length
The Peer-ID-Length field is one octet and shows the length of the Peer-ID field 📏.
Peer-ID
The Peer-ID field is zero or more octets and holds the name of the peer that's about to be authenticated 🪪.
Passwd-Length
The Passwd-Length field is one octet and shows the length of the Password field 📏.
Password
The Password field is zero or more octets and holds the password used for authentication 🔑.
4.3. Authenticate-Ack
Description
If the Peer-ID/Password pair in an Authenticate is both recognizable and acceptable, then a PAP implementation should send a PAP packet with the Code field set to 2 (Authenticate-Ack), the Identifier field copied from the Authenticate it received, and the Message field optionally filled with an ASCII message ✅🎉.
Here's how the Authenticate-Ack looks:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg-Length | Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-Code
2 for Authenticate-Ack.
Identifier
The Identifier field is one octet and helps match requests with replies. The Identifier field MUST be copied from the Identifier field of the Authenticate that caused this Authenticate-Ack. No changing it, no freelancing 🙅♀️.
Msg-Length
The Msg-Length field is one octet and shows the length of the Message field 📏.
Message
The Message field is zero or more octets and holds an ASCII message 💬.
4.4. Authenticate-Nak
Description
If the Peer-ID/Password pair in an Authenticate is not recognizable or acceptable, then a PAP implementation should send a PAP packet with the Code field set to 3 (Authenticate-Nak), the Identifier field copied from the Authenticate it received, and the Message field optionally filled with an ASCII message 🙅.
Here's the Authenticate-Nak format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg-Length | Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-Code
3 for Authenticate-Nak.
Identifier
The Identifier field is one octet and helps match requests with replies. The Identifier field MUST be copied from the Identifier field of the Authenticate that caused this Authenticate-Nak. Same energy as the Ack, no exceptions 🔁.
Msg-Length
The Msg-Length field is one octet and shows the length of the Message field 📏.
Message
The Message field is zero or more octets and holds an ASCII message 💬.
5. IP Control Protocol (IPCP) Configuration Options 🌐
IPCP Configuration Options let you negotiate the Internet Protocol parameters you want 🤝. The negotiable changes proposed in this document are IP addresses and compression protocols ✨.
The initial proposed values for the IPCP Configuration Option Type field (see [1]) are assigned like this:
1IP-Addresses2Compression-Type
5.1. IP-Addresses
Description
This Configuration Option is how you negotiate the IP addresses that get used on each end of the link 🏠. By default, no IP addresses are assigned to either end. An address specified as zero shall be interpreted as a request for the remote end to specify the address 🤷♀️. If an implementation allows multiple IP addresses to be assigned, it may include multiple IP Address Configuration Options in its Configure-Request packets 📦. An implementation that receives a Configure-Request with multiple IP Address Configuration Options may send a Configure-Reject that specifies one or more of those IP Addresses. An implementation that wants no IP addresses assigned at all (like a "half-gateway") may reject all IP Address Configuration Options 🚫.
Here's the IP-Addresses Configuration Option format. The fields go out 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 | Source-IP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source-IP-Address (cont) | Destination-IP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination-IP-Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
1
Length
10
Source-IP-Address
The four octet Source-IP-Address is the local address that the sender of a Configure-Request wants to use 📍. In a Configure-Ack, Configure-Nak or Configure-Reject, the Source-IP-Address is the remote address of the sender, which makes it a local address from the point of view of the Configuration Option receiver 🔄.
Destination-IP-Address
The four octet Destination-IP-Address is the remote address from the point of view of the sender of a Configure-Request 🎯. In a Configure-Ack, Configure-Nak or Configure-Reject, the Destination-IP-Address is the local address of the sender, which makes it a remote address from the point of view of the Configuration Option receiver 🪞.
Default
No IP addresses assigned 💤.
5.2. Compression-Type 🎀
okay so bestie, this one is the compression option 🗜️✨ and honestly it's giving very "one specific thing, done well." The Compression-Type option lets two peers negotiate using one specific compression protocol. By default? No compression enabled. Nothing sneaky happening unless both sides actually agree 💅
Here's what the option looks like on the wire. Fields go left to right, no cap:
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 | Compression-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+Now the fields, one by one 🦋
Type is just 2. That's how you know it's this option. 🫶
Length has to be >= 4. So it's at least four octets, the whole thing counting the Type and Length bytes plus the two-octet Compression-Type 💖
Compression-Type is two octets and it tells you which compression protocol the sender wants. Here's the iconic part: these values are always the same as the PPP Data Link Layer Protocol field values for that same compression protocol, so it's literally one shared number system 🧚 The most up-to-date values live in "Assigned Numbers" [2]. The initial value assigned is:
Value (in hex) Protocol
0037 Van Jacobson Compressed TCP/IPYes, 0037 is Van Jacobson Compressed TCP/IP. Iconic. 👑
Data is zero or more octets, and what goes in there depends on whichever compression protocol you picked in the Compression-Type field 🌸
Default is no compression protocol enabled. Period. 🙈
Heads up bestie: the security stuff for this option is covered back in Section 2.3, so go check that out 🔒
References 📚
Here are the sources this doc leans on, you're gonna want these bookmarked 🔖
- [1] Perkins, D., "The Point-to-Point Protocol for the Transmission of Multi-Protocol of Datagrams Over Point-to-Point Links", RFC 1171, July, 1990.
- [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990.
Security Considerations 🔐
Security issues are discussed in Section 2.3. That's the whole thing, so go read it before you ship anything 💀
Author's Address 🖊️
This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the chair:
Russ Hobby
UC Davis
Computing Services
Davis, CA 95616
Phone: (916) 752-0236
EMail: rdhobby@ucdavis.eduQuestions about this memo can also be directed to:
Drew D. Perkins
Carnegie Mellon University
Networking and Communications
Pittsburgh, PA 15213
Phone: (412) 268-8576
EMail: ddp@andrew.cmu.eduAcknowledgments 🫶
Many people spent significant time helping to develop the Point-to-Point Protocol. The complete list of people is too numerous to list, but the following people deserve special thanks: Ken Adelman (TGV), Craig Fox (NSC), Phill Gross (NRI), Russ Hobby (UC Davis), David Kaufman (Proteon), John LoVerso (Xylogics), Bill Melohn (Sun Microsystems), Mike Patton (MIT), Drew Perkins (CMU), Greg Satz (cisco systems) and Asher Waldfogel (Wellfleet). Iconic cast, honestly 🌈✨
📦 where this page comes from
- ietf: rfc1172 1990-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms