« back to all changes in this revision
Viewing changes to Reference/rfc1661.txt
- browse files at revision 1
- compare with another revision
- download diff
- download tarball
- view history from revision 1
- Committer: Bazaar Package Importer
- Author(s): Thomas Quinot
- Date: 2002-03-20 11:30:55 UTC
- Revision ID: james.westby@ubuntu.com-20020320113055-2b5isjpm74is3yno
Tags: upstream-1.1.0
Import upstream version 1.1.0
- files added:
- Documentation
- Reference
- debian
added
removed
Reference/rfc1661.txt
1
2
3
4
5
6
7
Network Working Group W. Simpson, Editor
8
Request for Comments: 1661 Daydreamer
9
STD: 51 July 1994
10
Obsoletes: 1548
11
Category: Standards Track
12
13
14
The Point-to-Point Protocol (PPP)
15
16
17
18
Status of this Memo
19
20
This document specifies an Internet standards track protocol for the
21
Internet community, and requests discussion and suggestions for
22
improvements. Please refer to the current edition of the "Internet
23
Official Protocol Standards" (STD 1) for the standardization state
24
and status of this protocol. Distribution of this memo is unlimited.
25
26
27
Abstract
28
29
The Point-to-Point Protocol (PPP) provides a standard method for
30
transporting multi-protocol datagrams over point-to-point links. PPP
31
is comprised of three main components:
32
33
1. A method for encapsulating multi-protocol datagrams.
34
35
2. A Link Control Protocol (LCP) for establishing, configuring,
36
and testing the data-link connection.
37
38
3. A family of Network Control Protocols (NCPs) for establishing
39
and configuring different network-layer protocols.
40
41
This document defines the PPP organization and methodology, and the
42
PPP encapsulation, together with an extensible option negotiation
43
mechanism which is able to negotiate a rich assortment of
44
configuration parameters and provides additional management
45
functions. The PPP Link Control Protocol (LCP) is described in terms
46
of this mechanism.
47
48
49
Table of Contents
50
51
52
1. Introduction .......................................... 1
53
1.1 Specification of Requirements ................... 2
54
1.2 Terminology ..................................... 3
55
56
2. PPP Encapsulation ..................................... 4
57
58
59
Simpson [Page i]
60
RFC 1661 Point-to-Point Protocol July 1994
61
62
63
3. PPP Link Operation .................................... 6
64
3.1 Overview ........................................ 6
65
3.2 Phase Diagram ................................... 6
66
3.3 Link Dead (physical-layer not ready) ............ 7
67
3.4 Link Establishment Phase ........................ 7
68
3.5 Authentication Phase ............................ 8
69
3.6 Network-Layer Protocol Phase .................... 8
70
3.7 Link Termination Phase .......................... 9
71
72
4. The Option Negotiation Automaton ...................... 11
73
4.1 State Transition Table .......................... 12
74
4.2 States .......................................... 14
75
4.3 Events .......................................... 16
76
4.4 Actions ......................................... 21
77
4.5 Loop Avoidance .................................. 23
78
4.6 Counters and Timers ............................. 24
79
80
5. LCP Packet Formats .................................... 26
81
5.1 Configure-Request ............................... 28
82
5.2 Configure-Ack ................................... 29
83
5.3 Configure-Nak ................................... 30
84
5.4 Configure-Reject ................................ 31
85
5.5 Terminate-Request and Terminate-Ack ............. 33
86
5.6 Code-Reject ..................................... 34
87
5.7 Protocol-Reject ................................. 35
88
5.8 Echo-Request and Echo-Reply ..................... 36
89
5.9 Discard-Request ................................. 37
90
91
6. LCP Configuration Options ............................. 39
92
6.1 Maximum-Receive-Unit (MRU) ...................... 41
93
6.2 Authentication-Protocol ......................... 42
94
6.3 Quality-Protocol ................................ 43
95
6.4 Magic-Number .................................... 45
96
6.5 Protocol-Field-Compression (PFC) ................ 48
97
6.6 Address-and-Control-Field-Compression (ACFC)
98
99
SECURITY CONSIDERATIONS ...................................... 51
100
REFERENCES ................................................... 51
101
ACKNOWLEDGEMENTS ............................................. 51
102
CHAIR'S ADDRESS .............................................. 52
103
EDITOR'S ADDRESS ............................................. 52
104
105
106
107
108
109
110
111
112
113
114
Simpson [Page ii]
115
RFC 1661 Point-to-Point Protocol July 1994
116
117
118
1. Introduction
119
120
The Point-to-Point Protocol is designed for simple links which
121
transport packets between two peers. These links provide full-duplex
122
simultaneous bi-directional operation, and are assumed to deliver
123
packets in order. It is intended that PPP provide a common solution
124
for easy connection of a wide variety of hosts, bridges and routers
125
[1].
126
127
Encapsulation
128
129
The PPP encapsulation provides for multiplexing of different
130
network-layer protocols simultaneously over the same link. The
131
PPP encapsulation has been carefully designed to retain
132
compatibility with most commonly used supporting hardware.
133
134
Only 8 additional octets are necessary to form the encapsulation
135
when used within the default HDLC-like framing. In environments
136
where bandwidth is at a premium, the encapsulation and framing may
137
be shortened to 2 or 4 octets.
138
139
To support high speed implementations, the default encapsulation
140
uses only simple fields, only one of which needs to be examined
141
for demultiplexing. The default header and information fields
142
fall on 32-bit boundaries, and the trailer may be padded to an
143
arbitrary boundary.
144
145
Link Control Protocol
146
147
In order to be sufficiently versatile to be portable to a wide
148
variety of environments, PPP provides a Link Control Protocol
149
(LCP). The LCP is used to automatically agree upon the
150
encapsulation format options, handle varying limits on sizes of
151
packets, detect a looped-back link and other common
152
misconfiguration errors, and terminate the link. Other optional
153
facilities provided are authentication of the identity of its peer
154
on the link, and determination when a link is functioning properly
155
and when it is failing.
156
157
Network Control Protocols
158
159
Point-to-Point links tend to exacerbate many problems with the
160
current family of network protocols. For instance, assignment and
161
management of IP addresses, which is a problem even in LAN
162
environments, is especially difficult over circuit-switched
163
point-to-point links (such as dial-up modem servers). These
164
problems are handled by a family of Network Control Protocols
165
(NCPs), which each manage the specific needs required by their
166
167
168
169
Simpson [Page 1]
170
RFC 1661 Point-to-Point Protocol July 1994
171
172
173
respective network-layer protocols. These NCPs are defined in
174
companion documents.
175
176
Configuration
177
178
It is intended that PPP links be easy to configure. By design,
179
the standard defaults handle all common configurations. The
180
implementor can specify improvements to the default configuration,
181
which are automatically communicated to the peer without operator
182
intervention. Finally, the operator may explicitly configure
183
options for the link which enable the link to operate in
184
environments where it would otherwise be impossible.
185
186
This self-configuration is implemented through an extensible
187
option negotiation mechanism, wherein each end of the link
188
describes to the other its capabilities and requirements.
189
Although the option negotiation mechanism described in this
190
document is specified in terms of the Link Control Protocol (LCP),
191
the same facilities are designed to be used by other control
192
protocols, especially the family of NCPs.
193
194
195
196
1.1. Specification of Requirements
197
198
In this document, several words are used to signify the requirements
199
of the specification. These words are often capitalized.
200
201
MUST This word, or the adjective "required", means that the
202
definition is an absolute requirement of the specification.
203
204
MUST NOT This phrase means that the definition is an absolute
205
prohibition of the specification.
206
207
SHOULD This word, or the adjective "recommended", means that there
208
may exist valid reasons in particular circumstances to
209
ignore this item, but the full implications must be
210
understood and carefully weighed before choosing a
211
different course.
212
213
MAY This word, or the adjective "optional", means that this
214
item is one of an allowed set of alternatives. An
215
implementation which does not include this option MUST be
216
prepared to interoperate with another implementation which
217
does include the option.
218
219
220
221
222
223
224
Simpson [Page 2]
225
RFC 1661 Point-to-Point Protocol July 1994
226
227
228
1.2. Terminology
229
230
This document frequently uses the following terms:
231
232
datagram The unit of transmission in the network layer (such as IP).
233
A datagram may be encapsulated in one or more packets
234
passed to the data link layer.
235
236
frame The unit of transmission at the data link layer. A frame
237
may include a header and/or a trailer, along with some
238
number of units of data.
239
240
packet The basic unit of encapsulation, which is passed across the
241
interface between the network layer and the data link
242
layer. A packet is usually mapped to a frame; the
243
exceptions are when data link layer fragmentation is being
244
performed, or when multiple packets are incorporated into a
245
single frame.
246
247
peer The other end of the point-to-point link.
248
249
silently discard
250
The implementation discards the packet without further
251
processing. The implementation SHOULD provide the
252
capability of logging the error, including the contents of
253
the silently discarded packet, and SHOULD record the event
254
in a statistics counter.
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
Simpson [Page 3]
280
RFC 1661 Point-to-Point Protocol July 1994
281
282
283
2. PPP Encapsulation
284
285
The PPP encapsulation is used to disambiguate multiprotocol
286
datagrams. This encapsulation requires framing to indicate the
287
beginning and end of the encapsulation. Methods of providing framing
288
are specified in companion documents.
289
290
A summary of the PPP encapsulation is shown below. The fields are
291
transmitted from left to right.
292
293
+----------+-------------+---------+
294
| Protocol | Information | Padding |
295
| 8/16 bits| * | * |
296
+----------+-------------+---------+
297
298
299
Protocol Field
300
301
The Protocol field is one or two octets, and its value identifies
302
the datagram encapsulated in the Information field of the packet.
303
The field is transmitted and received most significant octet
304
first.
305
306
The structure of this field is consistent with the ISO 3309
307
extension mechanism for address fields. All Protocols MUST be
308
odd; the least significant bit of the least significant octet MUST
309
equal "1". Also, all Protocols MUST be assigned such that the
310
least significant bit of the most significant octet equals "0".
311
Frames received which don't comply with these rules MUST be
312
treated as having an unrecognized Protocol.
313
314
Protocol field values in the "0***" to "3***" range identify the
315
network-layer protocol of specific packets, and values in the
316
"8***" to "b***" range identify packets belonging to the
317
associated Network Control Protocols (NCPs), if any.
318
319
Protocol field values in the "4***" to "7***" range are used for
320
protocols with low volume traffic which have no associated NCP.
321
Protocol field values in the "c***" to "f***" range identify
322
packets as link-layer Control Protocols (such as LCP).
323
324
325
326
327
328
329
330
331
332
333
334
Simpson [Page 4]
335
RFC 1661 Point-to-Point Protocol July 1994
336
337
338
Up-to-date values of the Protocol field are specified in the most
339
recent "Assigned Numbers" RFC [2]. This specification reserves
340
the following values:
341
342
Value (in hex) Protocol Name
343
344
0001 Padding Protocol
345
0003 to 001f reserved (transparency inefficient)
346
007d reserved (Control Escape)
347
00cf reserved (PPP NLPID)
348
00ff reserved (compression inefficient)
349
350
8001 to 801f unused
351
807d unused
352
80cf unused
353
80ff unused
354
355
c021 Link Control Protocol
356
c023 Password Authentication Protocol
357
c025 Link Quality Report
358
c223 Challenge Handshake Authentication Protocol
359
360
Developers of new protocols MUST obtain a number from the Internet
361
Assigned Numbers Authority (IANA), at IANA@isi.edu.
362
363
364
Information Field
365
366
The Information field is zero or more octets. The Information
367
field contains the datagram for the protocol specified in the
368
Protocol field.
369
370
The maximum length for the Information field, including Padding,
371
but not including the Protocol field, is termed the Maximum
372
Receive Unit (MRU), which defaults to 1500 octets. By
373
negotiation, consenting PPP implementations may use other values
374
for the MRU.
375
376
377
Padding
378
379
On transmission, the Information field MAY be padded with an
380
arbitrary number of octets up to the MRU. It is the
381
responsibility of each protocol to distinguish padding octets from
382
real information.
383
384
385
386
387
388
389
Simpson [Page 5]
390
RFC 1661 Point-to-Point Protocol July 1994
391
392
393
3. PPP Link Operation
394
395
3.1. Overview
396
397
In order to establish communications over a point-to-point link, each
398
end of the PPP link MUST first send LCP packets to configure and test
399
the data link. After the link has been established, the peer MAY be
400
authenticated.
401
402
Then, PPP MUST send NCP packets to choose and configure one or more
403
network-layer protocols. Once each of the chosen network-layer
404
protocols has been configured, datagrams from each network-layer
405
protocol can be sent over the link.
406
407
The link will remain configured for communications until explicit LCP
408
or NCP packets close the link down, or until some external event
409
occurs (an inactivity timer expires or network administrator
410
intervention).
411
412
413
414
3.2. Phase Diagram
415
416
In the process of configuring, maintaining and terminating the
417
point-to-point link, the PPP link goes through several distinct
418
phases which are specified in the following simplified state diagram:
419
420
+------+ +-----------+ +--------------+
421
| | UP | | OPENED | | SUCCESS/NONE
422
| Dead |------->| Establish |---------->| Authenticate |--+
423
| | | | | | |
424
+------+ +-----------+ +--------------+ |
425
^ | | |
426
| FAIL | FAIL | |
427
+<--------------+ +----------+ |
428
| | |
429
| +-----------+ | +---------+ |
430
| DOWN | | | CLOSING | | |
431
+------------| Terminate |<---+<----------| Network |<-+
432
| | | |
433
+-----------+ +---------+
434
435
Not all transitions are specified in this diagram. The following
436
semantics MUST be followed.
437
438
439
440
441
442
443
444
Simpson [Page 6]
445
RFC 1661 Point-to-Point Protocol July 1994
446
447
448
3.3. Link Dead (physical-layer not ready)
449
450
The link necessarily begins and ends with this phase. When an
451
external event (such as carrier detection or network administrator
452
configuration) indicates that the physical-layer is ready to be used,
453
PPP will proceed to the Link Establishment phase.
454
455
During this phase, the LCP automaton (described later) will be in the
456
Initial or Starting states. The transition to the Link Establishment
457
phase will signal an Up event to the LCP automaton.
458
459
Implementation Note:
460
461
Typically, a link will return to this phase automatically after
462
the disconnection of a modem. In the case of a hard-wired link,
463
this phase may be extremely short -- merely long enough to detect
464
the presence of the device.
465
466
467
468
3.4. Link Establishment Phase
469
470
The Link Control Protocol (LCP) is used to establish the connection
471
through an exchange of Configure packets. This exchange is complete,
472
and the LCP Opened state entered, once a Configure-Ack packet
473
(described later) has been both sent and received.
474
475
All Configuration Options are assumed to be at default values unless
476
altered by the configuration exchange. See the chapter on LCP
477
Configuration Options for further discussion.
478
479
It is important to note that only Configuration Options which are
480
independent of particular network-layer protocols are configured by
481
LCP. Configuration of individual network-layer protocols is handled
482
by separate Network Control Protocols (NCPs) during the Network-Layer
483
Protocol phase.
484
485
Any non-LCP packets received during this phase MUST be silently
486
discarded.
487
488
The receipt of the LCP Configure-Request causes a return to the Link
489
Establishment phase from the Network-Layer Protocol phase or
490
Authentication phase.
491
492
493
494
495
496
497
498
499
Simpson [Page 7]
500
RFC 1661 Point-to-Point Protocol July 1994
501
502
503
3.5. Authentication Phase
504
505
On some links it may be desirable to require a peer to authenticate
506
itself before allowing network-layer protocol packets to be
507
exchanged.
508
509
By default, authentication is not mandatory. If an implementation
510
desires that the peer authenticate with some specific authentication
511
protocol, then it MUST request the use of that authentication
512
protocol during Link Establishment phase.
513
514
Authentication SHOULD take place as soon as possible after link
515
establishment. However, link quality determination MAY occur
516
concurrently. An implementation MUST NOT allow the exchange of link
517
quality determination packets to delay authentication indefinitely.
518
519
Advancement from the Authentication phase to the Network-Layer
520
Protocol phase MUST NOT occur until authentication has completed. If
521
authentication fails, the authenticator SHOULD proceed instead to the
522
Link Termination phase.
523
524
Only Link Control Protocol, authentication protocol, and link quality
525
monitoring packets are allowed during this phase. All other packets
526
received during this phase MUST be silently discarded.
527
528
Implementation Notes:
529
530
An implementation SHOULD NOT fail authentication simply due to
531
timeout or lack of response. The authentication SHOULD allow some
532
method of retransmission, and proceed to the Link Termination
533
phase only after a number of authentication attempts has been
534
exceeded.
535
536
The implementation responsible for commencing Link Termination
537
phase is the implementation which has refused authentication to
538
its peer.
539
540
541
542
3.6. Network-Layer Protocol Phase
543
544
Once PPP has finished the previous phases, each network-layer
545
protocol (such as IP, IPX, or AppleTalk) MUST be separately
546
configured by the appropriate Network Control Protocol (NCP).
547
548
Each NCP MAY be Opened and Closed at any time.
549
550
551
552
553
554
Simpson [Page 8]
555
RFC 1661 Point-to-Point Protocol July 1994
556
557
558
Implementation Note:
559
560
Because an implementation may initially use a significant amount
561
of time for link quality determination, implementations SHOULD
562
avoid fixed timeouts when waiting for their peers to configure a
563
NCP.
564
565
After a NCP has reached the Opened state, PPP will carry the
566
corresponding network-layer protocol packets. Any supported
567
network-layer protocol packets received when the corresponding NCP is
568
not in the Opened state MUST be silently discarded.
569
570
Implementation Note:
571
572
While LCP is in the Opened state, any protocol packet which is
573
unsupported by the implementation MUST be returned in a Protocol-
574
Reject (described later). Only protocols which are supported are
575
silently discarded.
576
577
During this phase, link traffic consists of any possible combination
578
of LCP, NCP, and network-layer protocol packets.
579
580
581
582
3.7. Link Termination Phase
583
584
PPP can terminate the link at any time. This might happen because of
585
the loss of carrier, authentication failure, link quality failure,
586
the expiration of an idle-period timer, or the administrative closing
587
of the link.
588
589
LCP is used to close the link through an exchange of Terminate
590
packets. When the link is closing, PPP informs the network-layer
591
protocols so that they may take appropriate action.
592
593
After the exchange of Terminate packets, the implementation SHOULD
594
signal the physical-layer to disconnect in order to enforce the
595
termination of the link, particularly in the case of an
596
authentication failure. The sender of the Terminate-Request SHOULD
597
disconnect after receiving a Terminate-Ack, or after the Restart
598
counter expires. The receiver of a Terminate-Request SHOULD wait for
599
the peer to disconnect, and MUST NOT disconnect until at least one
600
Restart time has passed after sending a Terminate-Ack. PPP SHOULD
601
proceed to the Link Dead phase.
602
603
Any non-LCP packets received during this phase MUST be silently
604
discarded.
605
606
607
608
609
Simpson [Page 9]
610
RFC 1661 Point-to-Point Protocol July 1994
611
612
613
Implementation Note:
614
615
The closing of the link by LCP is sufficient. There is no need
616
for each NCP to send a flurry of Terminate packets. Conversely,
617
the fact that one NCP has Closed is not sufficient reason to cause
618
the termination of the PPP link, even if that NCP was the only NCP
619
currently in the Opened state.
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
Simpson [Page 10]
665
RFC 1661 Point-to-Point Protocol July 1994
666
667
668
4. The Option Negotiation Automaton
669
670
The finite-state automaton is defined by events, actions and state
671
transitions. Events include reception of external commands such as
672
Open and Close, expiration of the Restart timer, and reception of
673
packets from a peer. Actions include the starting of the Restart
674
timer and transmission of packets to the peer.
675
676
Some types of packets -- Configure-Naks and Configure-Rejects, or
677
Code-Rejects and Protocol-Rejects, or Echo-Requests, Echo-Replies and
678
Discard-Requests -- are not differentiated in the automaton
679
descriptions. As will be described later, these packets do indeed
680
serve different functions. However, they always cause the same
681
transitions.
682
683
Events Actions
684
685
Up = lower layer is Up tlu = This-Layer-Up
686
Down = lower layer is Down tld = This-Layer-Down
687
Open = administrative Open tls = This-Layer-Started
688
Close= administrative Close tlf = This-Layer-Finished
689
690
TO+ = Timeout with counter > 0 irc = Initialize-Restart-Count
691
TO- = Timeout with counter expired zrc = Zero-Restart-Count
692
693
RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-Request
694
RCR- = Receive-Configure-Request (Bad)
695
RCA = Receive-Configure-Ack sca = Send-Configure-Ack
696
RCN = Receive-Configure-Nak/Rej scn = Send-Configure-Nak/Rej
697
698
RTR = Receive-Terminate-Request str = Send-Terminate-Request
699
RTA = Receive-Terminate-Ack sta = Send-Terminate-Ack
700
701
RUC = Receive-Unknown-Code scj = Send-Code-Reject
702
RXJ+ = Receive-Code-Reject (permitted)
703
or Receive-Protocol-Reject
704
RXJ- = Receive-Code-Reject (catastrophic)
705
or Receive-Protocol-Reject
706
RXR = Receive-Echo-Request ser = Send-Echo-Reply
707
or Receive-Echo-Reply
708
or Receive-Discard-Request
709
710
711
712
713
714
715
716
717
718
719
Simpson [Page 11]
720
RFC 1661 Point-to-Point Protocol July 1994
721
722
723
4.1. State Transition Table
724
725
The complete state transition table follows. States are indicated
726
horizontally, and events are read vertically. State transitions and
727
actions are represented in the form action/new-state. Multiple
728
actions are separated by commas, and may continue on succeeding lines
729
as space requires; multiple actions may be implemented in any
730
convenient order. The state may be followed by a letter, which
731
indicates an explanatory footnote. The dash ('-') indicates an
732
illegal transition.
733
734
| State
735
| 0 1 2 3 4 5
736
Events| Initial Starting Closed Stopped Closing Stopping
737
------+-----------------------------------------------------------
738
Up | 2 irc,scr/6 - - - -
739
Down | - - 0 tls/1 0 1
740
Open | tls/1 1 irc,scr/6 3r 5r 5r
741
Close| 0 tlf/0 2 2 4 4
742
|
743
TO+ | - - - - str/4 str/5
744
TO- | - - - - tlf/2 tlf/3
745
|
746
RCR+ | - - sta/2 irc,scr,sca/8 4 5
747
RCR- | - - sta/2 irc,scr,scn/6 4 5
748
RCA | - - sta/2 sta/3 4 5
749
RCN | - - sta/2 sta/3 4 5
750
|
751
RTR | - - sta/2 sta/3 sta/4 sta/5
752
RTA | - - 2 3 tlf/2 tlf/3
753
|
754
RUC | - - scj/2 scj/3 scj/4 scj/5
755
RXJ+ | - - 2 3 4 5
756
RXJ- | - - tlf/2 tlf/3 tlf/2 tlf/3
757
|
758
RXR | - - 2 3 4 5
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
Simpson [Page 12]
775
RFC 1661 Point-to-Point Protocol July 1994
776
777
778
779
| State
780
| 6 7 8 9
781
Events| Req-Sent Ack-Rcvd Ack-Sent Opened
782
------+-----------------------------------------
783
Up | - - - -
784
Down | 1 1 1 tld/1
785
Open | 6 7 8 9r
786
Close|irc,str/4 irc,str/4 irc,str/4 tld,irc,str/4
787
|
788
TO+ | scr/6 scr/6 scr/8 -
789
TO- | tlf/3p tlf/3p tlf/3p -
790
|
791
RCR+ | sca/8 sca,tlu/9 sca/8 tld,scr,sca/8
792
RCR- | scn/6 scn/7 scn/6 tld,scr,scn/6
793
RCA | irc/7 scr/6x irc,tlu/9 tld,scr/6x
794
RCN |irc,scr/6 scr/6x irc,scr/8 tld,scr/6x
795
|
796
RTR | sta/6 sta/6 sta/6 tld,zrc,sta/5
797
RTA | 6 6 8 tld,scr/6
798
|
799
RUC | scj/6 scj/7 scj/8 scj/9
800
RXJ+ | 6 6 8 9
801
RXJ- | tlf/3 tlf/3 tlf/3 tld,irc,str/5
802
|
803
RXR | 6 7 8 ser/9
804
805
806
The states in which the Restart timer is running are identifiable by
807
the presence of TO events. Only the Send-Configure-Request, Send-
808
Terminate-Request and Zero-Restart-Count actions start or re-start
809
the Restart timer. The Restart timer is stopped when transitioning
810
from any state where the timer is running to a state where the timer
811
is not running.
812
813
The events and actions are defined according to a message passing
814
architecture, rather than a signalling architecture. If an action is
815
desired to control specific signals (such as DTR), additional actions
816
are likely to be required.
817
818
[p] Passive option; see Stopped state discussion.
819
820
[r] Restart option; see Open event discussion.
821
822
[x] Crossed connection; see RCA event discussion.
823
824
825
826
827
828
829
Simpson [Page 13]
830
RFC 1661 Point-to-Point Protocol July 1994
831
832
833
4.2. States
834
835
Following is a more detailed description of each automaton state.
836
837
Initial
838
839
In the Initial state, the lower layer is unavailable (Down), and
840
no Open has occurred. The Restart timer is not running in the
841
Initial state.
842
843
Starting
844
845
The Starting state is the Open counterpart to the Initial state.
846
An administrative Open has been initiated, but the lower layer is
847
still unavailable (Down). The Restart timer is not running in the
848
Starting state.
849
850
When the lower layer becomes available (Up), a Configure-Request
851
is sent.
852
853
Closed
854
855
In the Closed state, the link is available (Up), but no Open has
856
occurred. The Restart timer is not running in the Closed state.
857
858
Upon reception of Configure-Request packets, a Terminate-Ack is
859
sent. Terminate-Acks are silently discarded to avoid creating a
860
loop.
861
862
Stopped
863
864
The Stopped state is the Open counterpart to the Closed state. It
865
is entered when the automaton is waiting for a Down event after
866
the This-Layer-Finished action, or after sending a Terminate-Ack.
867
The Restart timer is not running in the Stopped state.
868
869
Upon reception of Configure-Request packets, an appropriate
870
response is sent. Upon reception of other packets, a Terminate-
871
Ack is sent. Terminate-Acks are silently discarded to avoid
872
creating a loop.
873
874
Rationale:
875
876
The Stopped state is a junction state for link termination,
877
link configuration failure, and other automaton failure modes.
878
These potentially separate states have been combined.
879
880
There is a race condition between the Down event response (from
881
882
883
884
Simpson [Page 14]
885
RFC 1661 Point-to-Point Protocol July 1994
886
887
888
the This-Layer-Finished action) and the Receive-Configure-
889
Request event. When a Configure-Request arrives before the
890
Down event, the Down event will supercede by returning the
891
automaton to the Starting state. This prevents attack by
892
repetition.
893
894
Implementation Option:
895
896
After the peer fails to respond to Configure-Requests, an
897
implementation MAY wait passively for the peer to send
898
Configure-Requests. In this case, the This-Layer-Finished
899
action is not used for the TO- event in states Req-Sent, Ack-
900
Rcvd and Ack-Sent.
901
902
This option is useful for dedicated circuits, or circuits which
903
have no status signals available, but SHOULD NOT be used for
904
switched circuits.
905
906
Closing
907
908
In the Closing state, an attempt is made to terminate the
909
connection. A Terminate-Request has been sent and the Restart
910
timer is running, but a Terminate-Ack has not yet been received.
911
912
Upon reception of a Terminate-Ack, the Closed state is entered.
913
Upon the expiration of the Restart timer, a new Terminate-Request
914
is transmitted, and the Restart timer is restarted. After the
915
Restart timer has expired Max-Terminate times, the Closed state is
916
entered.
917
918
Stopping
919
920
The Stopping state is the Open counterpart to the Closing state.
921
A Terminate-Request has been sent and the Restart timer is
922
running, but a Terminate-Ack has not yet been received.
923
924
Rationale:
925
926
The Stopping state provides a well defined opportunity to
927
terminate a link before allowing new traffic. After the link
928
has terminated, a new configuration may occur via the Stopped
929
or Starting states.
930
931
Request-Sent
932
933
In the Request-Sent state an attempt is made to configure the
934
connection. A Configure-Request has been sent and the Restart
935
timer is running, but a Configure-Ack has not yet been received
936
937
938
939
Simpson [Page 15]
940
RFC 1661 Point-to-Point Protocol July 1994
941
942
943
nor has one been sent.
944
945
Ack-Received
946
947
In the Ack-Received state, a Configure-Request has been sent and a
948
Configure-Ack has been received. The Restart timer is still
949
running, since a Configure-Ack has not yet been sent.
950
951
Ack-Sent
952
953
In the Ack-Sent state, a Configure-Request and a Configure-Ack
954
have both been sent, but a Configure-Ack has not yet been
955
received. The Restart timer is running, since a Configure-Ack has
956
not yet been received.
957
958
Opened
959
960
In the Opened state, a Configure-Ack has been both sent and
961
received. The Restart timer is not running.
962
963
When entering the Opened state, the implementation SHOULD signal
964
the upper layers that it is now Up. Conversely, when leaving the
965
Opened state, the implementation SHOULD signal the upper layers
966
that it is now Down.
967
968
969
970
4.3. Events
971
972
Transitions and actions in the automaton are caused by events.
973
974
Up
975
976
This event occurs when a lower layer indicates that it is ready to
977
carry packets.
978
979
Typically, this event is used by a modem handling or calling
980
process, or by some other coupling of the PPP link to the physical
981
media, to signal LCP that the link is entering Link Establishment
982
phase.
983
984
It also can be used by LCP to signal each NCP that the link is
985
entering Network-Layer Protocol phase. That is, the This-Layer-Up
986
action from LCP triggers the Up event in the NCP.
987
988
Down
989
990
This event occurs when a lower layer indicates that it is no
991
992
993
994
Simpson [Page 16]
995
RFC 1661 Point-to-Point Protocol July 1994
996
997
998
longer ready to carry packets.
999
1000
Typically, this event is used by a modem handling or calling
1001
process, or by some other coupling of the PPP link to the physical
1002
media, to signal LCP that the link is entering Link Dead phase.
1003
1004
It also can be used by LCP to signal each NCP that the link is
1005
leaving Network-Layer Protocol phase. That is, the This-Layer-
1006
Down action from LCP triggers the Down event in the NCP.
1007
1008
Open
1009
1010
This event indicates that the link is administratively available
1011
for traffic; that is, the network administrator (human or program)
1012
has indicated that the link is allowed to be Opened. When this
1013
event occurs, and the link is not in the Opened state, the
1014
automaton attempts to send configuration packets to the peer.
1015
1016
If the automaton is not able to begin configuration (the lower
1017
layer is Down, or a previous Close event has not completed), the
1018
establishment of the link is automatically delayed.
1019
1020
When a Terminate-Request is received, or other events occur which
1021
cause the link to become unavailable, the automaton will progress
1022
to a state where the link is ready to re-open. No additional
1023
administrative intervention is necessary.
1024
1025
Implementation Option:
1026
1027
Experience has shown that users will execute an additional Open
1028
command when they want to renegotiate the link. This might
1029
indicate that new values are to be negotiated.
1030
1031
Since this is not the meaning of the Open event, it is
1032
suggested that when an Open user command is executed in the
1033
Opened, Closing, Stopping, or Stopped states, the
1034
implementation issue a Down event, immediately followed by an
1035
Up event. Care must be taken that an intervening Down event
1036
cannot occur from another source.
1037
1038
The Down followed by an Up will cause an orderly renegotiation
1039
of the link, by progressing through the Starting to the
1040
Request-Sent state. This will cause the renegotiation of the
1041
link, without any harmful side effects.
1042
1043
Close
1044
1045
This event indicates that the link is not available for traffic;
1046
1047
1048
1049
Simpson [Page 17]
1050
RFC 1661 Point-to-Point Protocol July 1994
1051
1052
1053
that is, the network administrator (human or program) has
1054
indicated that the link is not allowed to be Opened. When this
1055
event occurs, and the link is not in the Closed state, the
1056
automaton attempts to terminate the connection. Futher attempts
1057
to re-configure the link are denied until a new Open event occurs.
1058
1059
Implementation Note:
1060
1061
When authentication fails, the link SHOULD be terminated, to
1062
prevent attack by repetition and denial of service to other
1063
users. Since the link is administratively available (by
1064
definition), this can be accomplished by simulating a Close
1065
event to the LCP, immediately followed by an Open event. Care
1066
must be taken that an intervening Close event cannot occur from
1067
another source.
1068
1069
The Close followed by an Open will cause an orderly termination
1070
of the link, by progressing through the Closing to the Stopping
1071
state, and the This-Layer-Finished action can disconnect the
1072
link. The automaton waits in the Stopped or Starting states
1073
for the next connection attempt.
1074
1075
Timeout (TO+,TO-)
1076
1077
This event indicates the expiration of the Restart timer. The
1078
Restart timer is used to time responses to Configure-Request and
1079
Terminate-Request packets.
1080
1081
The TO+ event indicates that the Restart counter continues to be
1082
greater than zero, which triggers the corresponding Configure-
1083
Request or Terminate-Request packet to be retransmitted.
1084
1085
The TO- event indicates that the Restart counter is not greater
1086
than zero, and no more packets need to be retransmitted.
1087
1088
Receive-Configure-Request (RCR+,RCR-)
1089
1090
This event occurs when a Configure-Request packet is received from
1091
the peer. The Configure-Request packet indicates the desire to
1092
open a connection and may specify Configuration Options. The
1093
Configure-Request packet is more fully described in a later
1094
section.
1095
1096
The RCR+ event indicates that the Configure-Request was
1097
acceptable, and triggers the transmission of a corresponding
1098
Configure-Ack.
1099
1100
The RCR- event indicates that the Configure-Request was
1101
1102
1103
1104
Simpson [Page 18]
1105
RFC 1661 Point-to-Point Protocol July 1994
1106
1107
1108
unacceptable, and triggers the transmission of a corresponding
1109
Configure-Nak or Configure-Reject.
1110
1111
Implementation Note:
1112
1113
These events may occur on a connection which is already in the
1114
Opened state. The implementation MUST be prepared to
1115
immediately renegotiate the Configuration Options.
1116
1117
Receive-Configure-Ack (RCA)
1118
1119
This event occurs when a valid Configure-Ack packet is received
1120
from the peer. The Configure-Ack packet is a positive response to
1121
a Configure-Request packet. An out of sequence or otherwise
1122
invalid packet is silently discarded.
1123
1124
Implementation Note:
1125
1126
Since the correct packet has already been received before
1127
reaching the Ack-Rcvd or Opened states, it is extremely
1128
unlikely that another such packet will arrive. As specified,
1129
all invalid Ack/Nak/Rej packets are silently discarded, and do
1130
not affect the transitions of the automaton.
1131
1132
However, it is not impossible that a correctly formed packet
1133
will arrive through a coincidentally-timed cross-connection.
1134
It is more likely to be the result of an implementation error.
1135
At the very least, this occurance SHOULD be logged.
1136
1137
Receive-Configure-Nak/Rej (RCN)
1138
1139
This event occurs when a valid Configure-Nak or Configure-Reject
1140
packet is received from the peer. The Configure-Nak and
1141
Configure-Reject packets are negative responses to a Configure-
1142
Request packet. An out of sequence or otherwise invalid packet is
1143
silently discarded.
1144
1145
Implementation Note:
1146
1147
Although the Configure-Nak and Configure-Reject cause the same
1148
state transition in the automaton, these packets have
1149
significantly different effects on the Configuration Options
1150
sent in the resulting Configure-Request packet.
1151
1152
Receive-Terminate-Request (RTR)
1153
1154
This event occurs when a Terminate-Request packet is received.
1155
The Terminate-Request packet indicates the desire of the peer to
1156
1157
1158
1159
Simpson [Page 19]
1160
RFC 1661 Point-to-Point Protocol July 1994
1161
1162
1163
close the connection.
1164
1165
Implementation Note:
1166
1167
This event is not identical to the Close event (see above), and
1168
does not override the Open commands of the local network
1169
administrator. The implementation MUST be prepared to receive
1170
a new Configure-Request without network administrator
1171
intervention.
1172
1173
Receive-Terminate-Ack (RTA)
1174
1175
This event occurs when a Terminate-Ack packet is received from the
1176
peer. The Terminate-Ack packet is usually a response to a
1177
Terminate-Request packet. The Terminate-Ack packet may also
1178
indicate that the peer is in Closed or Stopped states, and serves
1179
to re-synchronize the link configuration.
1180
1181
Receive-Unknown-Code (RUC)
1182
1183
This event occurs when an un-interpretable packet is received from
1184
the peer. A Code-Reject packet is sent in response.
1185
1186
Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-)
1187
1188
This event occurs when a Code-Reject or a Protocol-Reject packet
1189
is received from the peer.
1190
1191
The RXJ+ event arises when the rejected value is acceptable, such
1192
as a Code-Reject of an extended code, or a Protocol-Reject of a
1193
NCP. These are within the scope of normal operation. The
1194
implementation MUST stop sending the offending packet type.
1195
1196
The RXJ- event arises when the rejected value is catastrophic,
1197
such as a Code-Reject of Configure-Request, or a Protocol-Reject
1198
of LCP! This event communicates an unrecoverable error that
1199
terminates the connection.
1200
1201
Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request
1202
(RXR)
1203
1204
This event occurs when an Echo-Request, Echo-Reply or Discard-
1205
Request packet is received from the peer. The Echo-Reply packet
1206
is a response to an Echo-Request packet. There is no reply to an
1207
Echo-Reply or Discard-Request packet.
1208
1209
1210
1211
1212
1213
1214
Simpson [Page 20]
1215
RFC 1661 Point-to-Point Protocol July 1994
1216
1217
1218
4.4. Actions
1219
1220
Actions in the automaton are caused by events and typically indicate
1221
the transmission of packets and/or the starting or stopping of the
1222
Restart timer.
1223
1224
Illegal-Event (-)
1225
1226
This indicates an event that cannot occur in a properly
1227
implemented automaton. The implementation has an internal error,
1228
which should be reported and logged. No transition is taken, and
1229
the implementation SHOULD NOT reset or freeze.
1230
1231
This-Layer-Up (tlu)
1232
1233
This action indicates to the upper layers that the automaton is
1234
entering the Opened state.
1235
1236
Typically, this action is used by the LCP to signal the Up event
1237
to a NCP, Authentication Protocol, or Link Quality Protocol, or
1238
MAY be used by a NCP to indicate that the link is available for
1239
its network layer traffic.
1240
1241
This-Layer-Down (tld)
1242
1243
This action indicates to the upper layers that the automaton is
1244
leaving the Opened state.
1245
1246
Typically, this action is used by the LCP to signal the Down event
1247
to a NCP, Authentication Protocol, or Link Quality Protocol, or
1248
MAY be used by a NCP to indicate that the link is no longer
1249
available for its network layer traffic.
1250
1251
This-Layer-Started (tls)
1252
1253
This action indicates to the lower layers that the automaton is
1254
entering the Starting state, and the lower layer is needed for the
1255
link. The lower layer SHOULD respond with an Up event when the
1256
lower layer is available.
1257
1258
This results of this action are highly implementation dependent.
1259
1260
This-Layer-Finished (tlf)
1261
1262
This action indicates to the lower layers that the automaton is
1263
entering the Initial, Closed or Stopped states, and the lower
1264
layer is no longer needed for the link. The lower layer SHOULD
1265
respond with a Down event when the lower layer has terminated.
1266
1267
1268
1269
Simpson [Page 21]
1270
RFC 1661 Point-to-Point Protocol July 1994
1271
1272
1273
Typically, this action MAY be used by the LCP to advance to the
1274
Link Dead phase, or MAY be used by a NCP to indicate to the LCP
1275
that the link may terminate when there are no other NCPs open.
1276
1277
This results of this action are highly implementation dependent.
1278
1279
Initialize-Restart-Count (irc)
1280
1281
This action sets the Restart counter to the appropriate value
1282
(Max-Terminate or Max-Configure). The counter is decremented for
1283
each transmission, including the first.
1284
1285
Implementation Note:
1286
1287
In addition to setting the Restart counter, the implementation
1288
MUST set the timeout period to the initial value when Restart
1289
timer backoff is used.
1290
1291
Zero-Restart-Count (zrc)
1292
1293
This action sets the Restart counter to zero.
1294
1295
Implementation Note:
1296
1297
This action enables the FSA to pause before proceeding to the
1298
desired final state, allowing traffic to be processed by the
1299
peer. In addition to zeroing the Restart counter, the
1300
implementation MUST set the timeout period to an appropriate
1301
value.
1302
1303
Send-Configure-Request (scr)
1304
1305
A Configure-Request packet is transmitted. This indicates the
1306
desire to open a connection with a specified set of Configuration
1307
Options. The Restart timer is started when the Configure-Request
1308
packet is transmitted, to guard against packet loss. The Restart
1309
counter is decremented each time a Configure-Request is sent.
1310
1311
Send-Configure-Ack (sca)
1312
1313
A Configure-Ack packet is transmitted. This acknowledges the
1314
reception of a Configure-Request packet with an acceptable set of
1315
Configuration Options.
1316
1317
Send-Configure-Nak (scn)
1318
1319
A Configure-Nak or Configure-Reject packet is transmitted, as
1320
appropriate. This negative response reports the reception of a
1321
1322
1323
1324
Simpson [Page 22]
1325
RFC 1661 Point-to-Point Protocol July 1994
1326
1327
1328
Configure-Request packet with an unacceptable set of Configuration
1329
Options.
1330
1331
Configure-Nak packets are used to refuse a Configuration Option
1332
value, and to suggest a new, acceptable value. Configure-Reject
1333
packets are used to refuse all negotiation about a Configuration
1334
Option, typically because it is not recognized or implemented.
1335
The use of Configure-Nak versus Configure-Reject is more fully
1336
described in the chapter on LCP Packet Formats.
1337
1338
Send-Terminate-Request (str)
1339
1340
A Terminate-Request packet is transmitted. This indicates the
1341
desire to close a connection. The Restart timer is started when
1342
the Terminate-Request packet is transmitted, to guard against
1343
packet loss. The Restart counter is decremented each time a
1344
Terminate-Request is sent.
1345
1346
Send-Terminate-Ack (sta)
1347
1348
A Terminate-Ack packet is transmitted. This acknowledges the
1349
reception of a Terminate-Request packet or otherwise serves to
1350
synchronize the automatons.
1351
1352
Send-Code-Reject (scj)
1353
1354
A Code-Reject packet is transmitted. This indicates the reception
1355
of an unknown type of packet.
1356
1357
Send-Echo-Reply (ser)
1358
1359
An Echo-Reply packet is transmitted. This acknowledges the
1360
reception of an Echo-Request packet.
1361
1362
1363
1364
4.5. Loop Avoidance
1365
1366
The protocol makes a reasonable attempt at avoiding Configuration
1367
Option negotiation loops. However, the protocol does NOT guarantee
1368
that loops will not happen. As with any negotiation, it is possible
1369
to configure two PPP implementations with conflicting policies that
1370
will never converge. It is also possible to configure policies which
1371
do converge, but which take significant time to do so. Implementors
1372
should keep this in mind and SHOULD implement loop detection
1373
mechanisms or higher level timeouts.
1374
1375
1376
1377
1378
1379
Simpson [Page 23]
1380
RFC 1661 Point-to-Point Protocol July 1994
1381
1382
1383
4.6. Counters and Timers
1384
1385
Restart Timer
1386
1387
There is one special timer used by the automaton. The Restart
1388
timer is used to time transmissions of Configure-Request and
1389
Terminate-Request packets. Expiration of the Restart timer causes
1390
a Timeout event, and retransmission of the corresponding
1391
Configure-Request or Terminate-Request packet. The Restart timer
1392
MUST be configurable, but SHOULD default to three (3) seconds.
1393
1394
Implementation Note:
1395
1396
The Restart timer SHOULD be based on the speed of the link.
1397
The default value is designed for low speed (2,400 to 9,600
1398
bps), high switching latency links (typical telephone lines).
1399
Higher speed links, or links with low switching latency, SHOULD
1400
have correspondingly faster retransmission times.
1401
1402
Instead of a constant value, the Restart timer MAY begin at an
1403
initial small value and increase to the configured final value.
1404
Each successive value less than the final value SHOULD be at
1405
least twice the previous value. The initial value SHOULD be
1406
large enough to account for the size of the packets, twice the
1407
round trip time for transmission at the link speed, and at
1408
least an additional 100 milliseconds to allow the peer to
1409
process the packets before responding. Some circuits add
1410
another 200 milliseconds of satellite delay. Round trip times
1411
for modems operating at 14,400 bps have been measured in the
1412
range of 160 to more than 600 milliseconds.
1413
1414
Max-Terminate
1415
1416
There is one required restart counter for Terminate-Requests.
1417
Max-Terminate indicates the number of Terminate-Request packets
1418
sent without receiving a Terminate-Ack before assuming that the
1419
peer is unable to respond. Max-Terminate MUST be configurable,
1420
but SHOULD default to two (2) transmissions.
1421
1422
Max-Configure
1423
1424
A similar counter is recommended for Configure-Requests. Max-
1425
Configure indicates the number of Configure-Request packets sent
1426
without receiving a valid Configure-Ack, Configure-Nak or
1427
Configure-Reject before assuming that the peer is unable to
1428
respond. Max-Configure MUST be configurable, but SHOULD default
1429
to ten (10) transmissions.
1430
1431
1432
1433
1434
Simpson [Page 24]
1435
RFC 1661 Point-to-Point Protocol July 1994
1436
1437
1438
Max-Failure
1439
1440
A related counter is recommended for Configure-Nak. Max-Failure
1441
indicates the number of Configure-Nak packets sent without sending
1442
a Configure-Ack before assuming that configuration is not
1443
converging. Any further Configure-Nak packets for peer requested
1444
options are converted to Configure-Reject packets, and locally
1445
desired options are no longer appended. Max-Failure MUST be
1446
configurable, but SHOULD default to five (5) transmissions.
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
Simpson [Page 25]
1490
RFC 1661 Point-to-Point Protocol July 1994
1491
1492
1493
5. LCP Packet Formats
1494
1495
There are three classes of LCP packets:
1496
1497
1. Link Configuration packets used to establish and configure a
1498
link (Configure-Request, Configure-Ack, Configure-Nak and
1499
Configure-Reject).
1500
1501
2. Link Termination packets used to terminate a link (Terminate-
1502
Request and Terminate-Ack).
1503
1504
3. Link Maintenance packets used to manage and debug a link
1505
(Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, and
1506
Discard-Request).
1507
1508
In the interest of simplicity, there is no version field in the LCP
1509
packet. A correctly functioning LCP implementation will always
1510
respond to unknown Protocols and Codes with an easily recognizable
1511
LCP packet, thus providing a deterministic fallback mechanism for
1512
implementations of other versions.
1513
1514
Regardless of which Configuration Options are enabled, all LCP Link
1515
Configuration, Link Termination, and Code-Reject packets (codes 1
1516
through 7) are always sent as if no Configuration Options were
1517
negotiated. In particular, each Configuration Option specifies a
1518
default value. This ensures that such LCP packets are always
1519
recognizable, even when one end of the link mistakenly believes the
1520
link to be open.
1521
1522
Exactly one LCP packet is encapsulated in the PPP Information field,
1523
where the PPP Protocol field indicates type hex c021 (Link Control
1524
Protocol).
1525
1526
A summary of the Link Control Protocol packet format is shown below.
1527
The fields are transmitted from left to right.
1528
1529
0 1 2 3
1530
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
1531
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1532
| Code | Identifier | Length |
1533
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1534
| Data ...
1535
+-+-+-+-+
1536
1537
1538
Code
1539
1540
The Code field is one octet, and identifies the kind of LCP
1541
1542
1543
1544
Simpson [Page 26]
1545
RFC 1661 Point-to-Point Protocol July 1994
1546
1547
1548
packet. When a packet is received with an unknown Code field, a
1549
Code-Reject packet is transmitted.
1550
1551
Up-to-date values of the LCP Code field are specified in the most
1552
recent "Assigned Numbers" RFC [2]. This document concerns the
1553
following values:
1554
1555
1 Configure-Request
1556
2 Configure-Ack
1557
3 Configure-Nak
1558
4 Configure-Reject
1559
5 Terminate-Request
1560
6 Terminate-Ack
1561
7 Code-Reject
1562
8 Protocol-Reject
1563
9 Echo-Request
1564
10 Echo-Reply
1565
11 Discard-Request
1566
1567
1568
Identifier
1569
1570
The Identifier field is one octet, and aids in matching requests
1571
and replies. When a packet is received with an invalid Identifier
1572
field, the packet is silently discarded without affecting the
1573
automaton.
1574
1575
Length
1576
1577
The Length field is two octets, and indicates the length of the
1578
LCP packet, including the Code, Identifier, Length and Data
1579
fields. The Length MUST NOT exceed the MRU of the link.
1580
1581
Octets outside the range of the Length field are treated as
1582
padding and are ignored on reception. When a packet is received
1583
with an invalid Length field, the packet is silently discarded
1584
without affecting the automaton.
1585
1586
Data
1587
1588
The Data field is zero or more octets, as indicated by the Length
1589
field. The format of the Data field is determined by the Code
1590
field.
1591
1592
1593
1594
1595
1596
1597
1598
1599
Simpson [Page 27]
1600
RFC 1661 Point-to-Point Protocol July 1994
1601
1602
1603
5.1. Configure-Request
1604
1605
Description
1606
1607
An implementation wishing to open a connection MUST transmit a
1608
Configure-Request. The Options field is filled with any desired
1609
changes to the link defaults. Configuration Options SHOULD NOT be
1610
included with default values.
1611
1612
Upon reception of a Configure-Request, an appropriate reply MUST
1613
be transmitted.
1614
1615
A summary of the Configure-Request packet format is shown below. The
1616
fields are transmitted from left to right.
1617
1618
0 1 2 3
1619
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
1620
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1621
| Code | Identifier | Length |
1622
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1623
| Options ...
1624
+-+-+-+-+
1625
1626
1627
Code
1628
1629
1 for Configure-Request.
1630
1631
Identifier
1632
1633
The Identifier field MUST be changed whenever the contents of the
1634
Options field changes, and whenever a valid reply has been
1635
received for a previous request. For retransmissions, the
1636
Identifier MAY remain unchanged.
1637
1638
Options
1639
1640
The options field is variable in length, and contains the list of
1641
zero or more Configuration Options that the sender desires to
1642
negotiate. All Configuration Options are always negotiated
1643
simultaneously. The format of Configuration Options is further
1644
described in a later chapter.
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
Simpson [Page 28]
1655
RFC 1661 Point-to-Point Protocol July 1994
1656
1657
1658
5.2. Configure-Ack
1659
1660
Description
1661
1662
If every Configuration Option received in a Configure-Request is
1663
recognizable and all values are acceptable, then the
1664
implementation MUST transmit a Configure-Ack. The acknowledged
1665
Configuration Options MUST NOT be reordered or modified in any
1666
way.
1667
1668
On reception of a Configure-Ack, the Identifier field MUST match
1669
that of the last transmitted Configure-Request. Additionally, the
1670
Configuration Options in a Configure-Ack MUST exactly match those
1671
of the last transmitted Configure-Request. Invalid packets are
1672
silently discarded.
1673
1674
A summary of the Configure-Ack packet format is shown below. The
1675
fields are transmitted from left to right.
1676
1677
0 1 2 3
1678
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
1679
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1680
| Code | Identifier | Length |
1681
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1682
| Options ...
1683
+-+-+-+-+
1684
1685
1686
Code
1687
1688
2 for Configure-Ack.
1689
1690
Identifier
1691
1692
The Identifier field is a copy of the Identifier field of the
1693
Configure-Request which caused this Configure-Ack.
1694
1695
Options
1696
1697
The Options field is variable in length, and contains the list of
1698
zero or more Configuration Options that the sender is
1699
acknowledging. All Configuration Options are always acknowledged
1700
simultaneously.
1701
1702
1703
1704
1705
1706
1707
1708
1709
Simpson [Page 29]
1710
RFC 1661 Point-to-Point Protocol July 1994
1711
1712
1713
5.3. Configure-Nak
1714
1715
Description
1716
1717
If every instance of the received Configuration Options is
1718
recognizable, but some values are not acceptable, then the
1719
implementation MUST transmit a Configure-Nak. The Options field
1720
is filled with only the unacceptable Configuration Options from
1721
the Configure-Request. All acceptable Configuration Options are
1722
filtered out of the Configure-Nak, but otherwise the Configuration
1723
Options from the Configure-Request MUST NOT be reordered.
1724
1725
Options which have no value fields (boolean options) MUST use the
1726
Configure-Reject reply instead.
1727
1728
Each Configuration Option which is allowed only a single instance
1729
MUST be modified to a value acceptable to the Configure-Nak
1730
sender. The default value MAY be used, when this differs from the
1731
requested value.
1732
1733
When a particular type of Configuration Option can be listed more
1734
than once with different values, the Configure-Nak MUST include a
1735
list of all values for that option which are acceptable to the
1736
Configure-Nak sender. This includes acceptable values that were
1737
present in the Configure-Request.
1738
1739
Finally, an implementation may be configured to request the
1740
negotiation of a specific Configuration Option. If that option is
1741
not listed, then that option MAY be appended to the list of Nak'd
1742
Configuration Options, in order to prompt the peer to include that
1743
option in its next Configure-Request packet. Any value fields for
1744
the option MUST indicate values acceptable to the Configure-Nak
1745
sender.
1746
1747
On reception of a Configure-Nak, the Identifier field MUST match
1748
that of the last transmitted Configure-Request. Invalid packets
1749
are silently discarded.
1750
1751
Reception of a valid Configure-Nak indicates that when a new
1752
Configure-Request is sent, the Configuration Options MAY be
1753
modified as specified in the Configure-Nak. When multiple
1754
instances of a Configuration Option are present, the peer SHOULD
1755
select a single value to include in its next Configure-Request
1756
packet.
1757
1758
Some Configuration Options have a variable length. Since the
1759
Nak'd Option has been modified by the peer, the implementation
1760
MUST be able to handle an Option length which is different from
1761
1762
1763
1764
Simpson [Page 30]
1765
RFC 1661 Point-to-Point Protocol July 1994
1766
1767
1768
the original Configure-Request.
1769
1770
A summary of the Configure-Nak packet format is shown below. The
1771
fields are transmitted from left to right.
1772
1773
0 1 2 3
1774
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
1775
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1776
| Code | Identifier | Length |
1777
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1778
| Options ...
1779
+-+-+-+-+
1780
1781
1782
Code
1783
1784
3 for Configure-Nak.
1785
1786
Identifier
1787
1788
The Identifier field is a copy of the Identifier field of the
1789
Configure-Request which caused this Configure-Nak.
1790
1791
Options
1792
1793
The Options field is variable in length, and contains the list of
1794
zero or more Configuration Options that the sender is Nak'ing.
1795
All Configuration Options are always Nak'd simultaneously.
1796
1797
1798
1799
5.4. Configure-Reject
1800
1801
Description
1802
1803
If some Configuration Options received in a Configure-Request are
1804
not recognizable or are not acceptable for negotiation (as
1805
configured by a network administrator), then the implementation
1806
MUST transmit a Configure-Reject. The Options field is filled
1807
with only the unacceptable Configuration Options from the
1808
Configure-Request. All recognizable and negotiable Configuration
1809
Options are filtered out of the Configure-Reject, but otherwise
1810
the Configuration Options MUST NOT be reordered or modified in any
1811
way.
1812
1813
On reception of a Configure-Reject, the Identifier field MUST
1814
match that of the last transmitted Configure-Request.
1815
Additionally, the Configuration Options in a Configure-Reject MUST
1816
1817
1818
1819
Simpson [Page 31]
1820
RFC 1661 Point-to-Point Protocol July 1994
1821
1822
1823
be a proper subset of those in the last transmitted Configure-
1824
Request. Invalid packets are silently discarded.
1825
1826
Reception of a valid Configure-Reject indicates that when a new
1827
Configure-Request is sent, it MUST NOT include any of the
1828
Configuration Options listed in the Configure-Reject.
1829
1830
A summary of the Configure-Reject packet format is shown below. The
1831
fields are transmitted from left to right.
1832
1833
0 1 2 3
1834
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
1835
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1836
| Code | Identifier | Length |
1837
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1838
| Options ...
1839
+-+-+-+-+
1840
1841
1842
Code
1843
1844
4 for Configure-Reject.
1845
1846
Identifier
1847
1848
The Identifier field is a copy of the Identifier field of the
1849
Configure-Request which caused this Configure-Reject.
1850
1851
Options
1852
1853
The Options field is variable in length, and contains the list of
1854
zero or more Configuration Options that the sender is rejecting.
1855
All Configuration Options are always rejected simultaneously.
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
Simpson [Page 32]
1875
RFC 1661 Point-to-Point Protocol July 1994
1876
1877
1878
5.5. Terminate-Request and Terminate-Ack
1879
1880
Description
1881
1882
LCP includes Terminate-Request and Terminate-Ack Codes in order to
1883
provide a mechanism for closing a connection.
1884
1885
An implementation wishing to close a connection SHOULD transmit a
1886
Terminate-Request. Terminate-Request packets SHOULD continue to
1887
be sent until Terminate-Ack is received, the lower layer indicates
1888
that it has gone down, or a sufficiently large number have been
1889
transmitted such that the peer is down with reasonable certainty.
1890
1891
Upon reception of a Terminate-Request, a Terminate-Ack MUST be
1892
transmitted.
1893
1894
Reception of an unelicited Terminate-Ack indicates that the peer
1895
is in the Closed or Stopped states, or is otherwise in need of
1896
re-negotiation.
1897
1898
A summary of the Terminate-Request and Terminate-Ack packet formats
1899
is shown below. The fields are transmitted from left to right.
1900
1901
0 1 2 3
1902
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
1903
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1904
| Code | Identifier | Length |
1905
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1906
| Data ...
1907
+-+-+-+-+
1908
1909
1910
Code
1911
1912
5 for Terminate-Request;
1913
1914
6 for Terminate-Ack.
1915
1916
Identifier
1917
1918
On transmission, the Identifier field MUST be changed whenever the
1919
content of the Data field changes, and whenever a valid reply has
1920
been received for a previous request. For retransmissions, the
1921
Identifier MAY remain unchanged.
1922
1923
On reception, the Identifier field of the Terminate-Request is
1924
copied into the Identifier field of the Terminate-Ack packet.
1925
1926
1927
1928
1929
Simpson [Page 33]
1930
RFC 1661 Point-to-Point Protocol July 1994
1931
1932
1933
Data
1934
1935
The Data field is zero or more octets, and contains uninterpreted
1936
data for use by the sender. The data may consist of any binary
1937
value. The end of the field is indicated by the Length.
1938
1939
1940
1941
5.6. Code-Reject
1942
1943
Description
1944
1945
Reception of a LCP packet with an unknown Code indicates that the
1946
peer is operating with a different version. This MUST be reported
1947
back to the sender of the unknown Code by transmitting a Code-
1948
Reject.
1949
1950
Upon reception of the Code-Reject of a code which is fundamental
1951
to this version of the protocol, the implementation SHOULD report
1952
the problem and drop the connection, since it is unlikely that the
1953
situation can be rectified automatically.
1954
1955
A summary of the Code-Reject packet format is shown below. The
1956
fields are transmitted from left to right.
1957
1958
0 1 2 3
1959
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
1960
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1961
| Code | Identifier | Length |
1962
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1963
| Rejected-Packet ...
1964
+-+-+-+-+-+-+-+-+
1965
1966
1967
Code
1968
1969
7 for Code-Reject.
1970
1971
Identifier
1972
1973
The Identifier field MUST be changed for each Code-Reject sent.
1974
1975
Rejected-Packet
1976
1977
The Rejected-Packet field contains a copy of the LCP packet which
1978
is being rejected. It begins with the Information field, and does
1979
not include any Data Link Layer headers nor an FCS. The
1980
Rejected-Packet MUST be truncated to comply with the peer's
1981
1982
1983
1984
Simpson [Page 34]
1985
RFC 1661 Point-to-Point Protocol July 1994
1986
1987
1988
established MRU.
1989
1990
1991
1992
5.7. Protocol-Reject
1993
1994
Description
1995
1996
Reception of a PPP packet with an unknown Protocol field indicates
1997
that the peer is attempting to use a protocol which is
1998
unsupported. This usually occurs when the peer attempts to
1999
configure a new protocol. If the LCP automaton is in the Opened
2000
state, then this MUST be reported back to the peer by transmitting
2001
a Protocol-Reject.
2002
2003
Upon reception of a Protocol-Reject, the implementation MUST stop
2004
sending packets of the indicated protocol at the earliest
2005
opportunity.
2006
2007
Protocol-Reject packets can only be sent in the LCP Opened state.
2008
Protocol-Reject packets received in any state other than the LCP
2009
Opened state SHOULD be silently discarded.
2010
2011
A summary of the Protocol-Reject packet format is shown below. The
2012
fields are transmitted from left to right.
2013
2014
0 1 2 3
2015
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
2016
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2017
| Code | Identifier | Length |
2018
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2019
| Rejected-Protocol | Rejected-Information ...
2020
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2021
2022
2023
Code
2024
2025
8 for Protocol-Reject.
2026
2027
Identifier
2028
2029
The Identifier field MUST be changed for each Protocol-Reject
2030
sent.
2031
2032
Rejected-Protocol
2033
2034
The Rejected-Protocol field is two octets, and contains the PPP
2035
Protocol field of the packet which is being rejected.
2036
2037
2038
2039
Simpson [Page 35]
2040
RFC 1661 Point-to-Point Protocol July 1994
2041
2042
2043
Rejected-Information
2044
2045
The Rejected-Information field contains a copy of the packet which
2046
is being rejected. It begins with the Information field, and does
2047
not include any Data Link Layer headers nor an FCS. The
2048
Rejected-Information MUST be truncated to comply with the peer's
2049
established MRU.
2050
2051
2052
2053
5.8. Echo-Request and Echo-Reply
2054
2055
Description
2056
2057
LCP includes Echo-Request and Echo-Reply Codes in order to provide
2058
a Data Link Layer loopback mechanism for use in exercising both
2059
directions of the link. This is useful as an aid in debugging,
2060
link quality determination, performance testing, and for numerous
2061
other functions.
2062
2063
Upon reception of an Echo-Request in the LCP Opened state, an
2064
Echo-Reply MUST be transmitted.
2065
2066
Echo-Request and Echo-Reply packets MUST only be sent in the LCP
2067
Opened state. Echo-Request and Echo-Reply packets received in any
2068
state other than the LCP Opened state SHOULD be silently
2069
discarded.
2070
2071
2072
A summary of the Echo-Request and Echo-Reply packet formats is shown
2073
below. The fields are transmitted from left to right.
2074
2075
0 1 2 3
2076
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
2077
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2078
| Code | Identifier | Length |
2079
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2080
| Magic-Number |
2081
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2082
| Data ...
2083
+-+-+-+-+
2084
2085
2086
Code
2087
2088
9 for Echo-Request;
2089
2090
10 for Echo-Reply.
2091
2092
2093
2094
Simpson [Page 36]
2095
RFC 1661 Point-to-Point Protocol July 1994
2096
2097
2098
Identifier
2099
2100
On transmission, the Identifier field MUST be changed whenever the
2101
content of the Data field changes, and whenever a valid reply has
2102
been received for a previous request. For retransmissions, the
2103
Identifier MAY remain unchanged.
2104
2105
On reception, the Identifier field of the Echo-Request is copied
2106
into the Identifier field of the Echo-Reply packet.
2107
2108
Magic-Number
2109
2110
The Magic-Number field is four octets, and aids in detecting links
2111
which are in the looped-back condition. Until the Magic-Number
2112
Configuration Option has been successfully negotiated, the Magic-
2113
Number MUST be transmitted as zero. See the Magic-Number
2114
Configuration Option for further explanation.
2115
2116
Data
2117
2118
The Data field is zero or more octets, and contains uninterpreted
2119
data for use by the sender. The data may consist of any binary
2120
value. The end of the field is indicated by the Length.
2121
2122
2123
2124
5.9. Discard-Request
2125
2126
Description
2127
2128
LCP includes a Discard-Request Code in order to provide a Data
2129
Link Layer sink mechanism for use in exercising the local to
2130
remote direction of the link. This is useful as an aid in
2131
debugging, performance testing, and for numerous other functions.
2132
2133
Discard-Request packets MUST only be sent in the LCP Opened state.
2134
On reception, the receiver MUST silently discard any Discard-
2135
Request that it receives.
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
Simpson [Page 37]
2150
RFC 1661 Point-to-Point Protocol July 1994
2151
2152
2153
A summary of the Discard-Request packet format is shown below. The
2154
fields are transmitted from left to right.
2155
2156
0 1 2 3
2157
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
2158
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2159
| Code | Identifier | Length |
2160
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2161
| Magic-Number |
2162
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2163
| Data ...
2164
+-+-+-+-+
2165
2166
Code
2167
2168
11 for Discard-Request.
2169
2170
Identifier
2171
2172
The Identifier field MUST be changed for each Discard-Request
2173
sent.
2174
2175
Magic-Number
2176
2177
The Magic-Number field is four octets, and aids in detecting links
2178
which are in the looped-back condition. Until the Magic-Number
2179
Configuration Option has been successfully negotiated, the Magic-
2180
Number MUST be transmitted as zero. See the Magic-Number
2181
Configuration Option for further explanation.
2182
2183
Data
2184
2185
The Data field is zero or more octets, and contains uninterpreted
2186
data for use by the sender. The data may consist of any binary
2187
value. The end of the field is indicated by the Length.
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
Simpson [Page 38]
2205
RFC 1661 Point-to-Point Protocol July 1994
2206
2207
2208
6. LCP Configuration Options
2209
2210
LCP Configuration Options allow negotiation of modifications to the
2211
default characteristics of a point-to-point link. If a Configuration
2212
Option is not included in a Configure-Request packet, the default
2213
value for that Configuration Option is assumed.
2214
2215
Some Configuration Options MAY be listed more than once. The effect
2216
of this is Configuration Option specific, and is specified by each
2217
such Configuration Option description. (None of the Configuration
2218
Options in this specification can be listed more than once.)
2219
2220
The end of the list of Configuration Options is indicated by the
2221
Length field of the LCP packet.
2222
2223
Unless otherwise specified, all Configuration Options apply in a
2224
half-duplex fashion; typically, in the receive direction of the link
2225
from the point of view of the Configure-Request sender.
2226
2227
Design Philosophy
2228
2229
The options indicate additional capabilities or requirements of
2230
the implementation that is requesting the option. An
2231
implementation which does not understand any option SHOULD
2232
interoperate with one which implements every option.
2233
2234
A default is specified for each option which allows the link to
2235
correctly function without negotiation of the option, although
2236
perhaps with less than optimal performance.
2237
2238
Except where explicitly specified, acknowledgement of an option
2239
does not require the peer to take any additional action other than
2240
the default.
2241
2242
It is not necessary to send the default values for the options in
2243
a Configure-Request.
2244
2245
2246
A summary of the Configuration Option format is shown below. The
2247
fields are transmitted from left to right.
2248
2249
0 1
2250
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
2251
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2252
| Type | Length | Data ...
2253
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2254
2255
2256
2257
2258
2259
Simpson [Page 39]
2260
RFC 1661 Point-to-Point Protocol July 1994
2261
2262
2263
Type
2264
2265
The Type field is one octet, and indicates the type of
2266
Configuration Option. Up-to-date values of the LCP Option Type
2267
field are specified in the most recent "Assigned Numbers" RFC [2].
2268
This document concerns the following values:
2269
2270
0 RESERVED
2271
1 Maximum-Receive-Unit
2272
3 Authentication-Protocol
2273
4 Quality-Protocol
2274
5 Magic-Number
2275
7 Protocol-Field-Compression
2276
8 Address-and-Control-Field-Compression
2277
2278
2279
Length
2280
2281
The Length field is one octet, and indicates the length of this
2282
Configuration Option including the Type, Length and Data fields.
2283
2284
If a negotiable Configuration Option is received in a Configure-
2285
Request, but with an invalid or unrecognized Length, a Configure-
2286
Nak SHOULD be transmitted which includes the desired Configuration
2287
Option with an appropriate Length and Data.
2288
2289
Data
2290
2291
The Data field is zero or more octets, and contains information
2292
specific to the Configuration Option. The format and length of
2293
the Data field is determined by the Type and Length fields.
2294
2295
When the Data field is indicated by the Length to extend beyond
2296
the end of the Information field, the entire packet is silently
2297
discarded without affecting the automaton.
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
Simpson [Page 40]
2315
RFC 1661 Point-to-Point Protocol July 1994
2316
2317
2318
6.1. Maximum-Receive-Unit (MRU)
2319
2320
Description
2321
2322
This Configuration Option may be sent to inform the peer that the
2323
implementation can receive larger packets, or to request that the
2324
peer send smaller packets.
2325
2326
The default value is 1500 octets. If smaller packets are
2327
requested, an implementation MUST still be able to receive the
2328
full 1500 octet information field in case link synchronization is
2329
lost.
2330
2331
Implementation Note:
2332
2333
This option is used to indicate an implementation capability.
2334
The peer is not required to maximize the use of the capacity.
2335
For example, when a MRU is indicated which is 2048 octets, the
2336
peer is not required to send any packet with 2048 octets. The
2337
peer need not Configure-Nak to indicate that it will only send
2338
smaller packets, since the implementation will always require
2339
support for at least 1500 octets.
2340
2341
A summary of the Maximum-Receive-Unit Configuration Option format is
2342
shown below. The fields are transmitted from left to right.
2343
2344
0 1 2 3
2345
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
2346
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2347
| Type | Length | Maximum-Receive-Unit |
2348
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2349
2350
2351
Type
2352
2353
1
2354
2355
Length
2356
2357
4
2358
2359
Maximum-Receive-Unit
2360
2361
The Maximum-Receive-Unit field is two octets, and specifies the
2362
maximum number of octets in the Information and Padding fields.
2363
It does not include the framing, Protocol field, FCS, nor any
2364
transparency bits or bytes.
2365
2366
2367
2368
2369
Simpson [Page 41]
2370
RFC 1661 Point-to-Point Protocol July 1994
2371
2372
2373
6.2. Authentication-Protocol
2374
2375
Description
2376
2377
On some links it may be desirable to require a peer to
2378
authenticate itself before allowing network-layer protocol packets
2379
to be exchanged.
2380
2381
This Configuration Option provides a method to negotiate the use
2382
of a specific protocol for authentication. By default,
2383
authentication is not required.
2384
2385
An implementation MUST NOT include multiple Authentication-
2386
Protocol Configuration Options in its Configure-Request packets.
2387
Instead, it SHOULD attempt to configure the most desirable
2388
protocol first. If that protocol is Configure-Nak'd, then the
2389
implementation SHOULD attempt the next most desirable protocol in
2390
the next Configure-Request.
2391
2392
The implementation sending the Configure-Request is indicating
2393
that it expects authentication from its peer. If an
2394
implementation sends a Configure-Ack, then it is agreeing to
2395
authenticate with the specified protocol. An implementation
2396
receiving a Configure-Ack SHOULD expect the peer to authenticate
2397
with the acknowledged protocol.
2398
2399
There is no requirement that authentication be full-duplex or that
2400
the same protocol be used in both directions. It is perfectly
2401
acceptable for different protocols to be used in each direction.
2402
This will, of course, depend on the specific protocols negotiated.
2403
2404
A summary of the Authentication-Protocol Configuration Option format
2405
is shown below. The fields are transmitted from left to right.
2406
2407
0 1 2 3
2408
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
2409
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2410
| Type | Length | Authentication-Protocol |
2411
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2412
| Data ...
2413
+-+-+-+-+
2414
2415
2416
Type
2417
2418
3
2419
2420
2421
2422
2423
2424
Simpson [Page 42]
2425
RFC 1661 Point-to-Point Protocol July 1994
2426
2427
2428
Length
2429
2430
>= 4
2431
2432
Authentication-Protocol
2433
2434
The Authentication-Protocol field is two octets, and indicates the
2435
authentication protocol desired. Values for this field are always
2436
the same as the PPP Protocol field values for that same
2437
authentication protocol.
2438
2439
Up-to-date values of the Authentication-Protocol field are
2440
specified in the most recent "Assigned Numbers" RFC [2]. Current
2441
values are assigned as follows:
2442
2443
Value (in hex) Protocol
2444
2445
c023 Password Authentication Protocol
2446
c223 Challenge Handshake Authentication Protocol
2447
2448
2449
Data
2450
2451
The Data field is zero or more octets, and contains additional
2452
data as determined by the particular protocol.
2453
2454
2455
2456
6.3. Quality-Protocol
2457
2458
Description
2459
2460
On some links it may be desirable to determine when, and how
2461
often, the link is dropping data. This process is called link
2462
quality monitoring.
2463
2464
This Configuration Option provides a method to negotiate the use
2465
of a specific protocol for link quality monitoring. By default,
2466
link quality monitoring is disabled.
2467
2468
The implementation sending the Configure-Request is indicating
2469
that it expects to receive monitoring information from its peer.
2470
If an implementation sends a Configure-Ack, then it is agreeing to
2471
send the specified protocol. An implementation receiving a
2472
Configure-Ack SHOULD expect the peer to send the acknowledged
2473
protocol.
2474
2475
There is no requirement that quality monitoring be full-duplex or
2476
2477
2478
2479
Simpson [Page 43]
2480
RFC 1661 Point-to-Point Protocol July 1994
2481
2482
2483
that the same protocol be used in both directions. It is
2484
perfectly acceptable for different protocols to be used in each
2485
direction. This will, of course, depend on the specific protocols
2486
negotiated.
2487
2488
A summary of the Quality-Protocol Configuration Option format is
2489
shown below. The fields are transmitted from left to right.
2490
2491
0 1 2 3
2492
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
2493
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2494
| Type | Length | Quality-Protocol |
2495
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2496
| Data ...
2497
+-+-+-+-+
2498
2499
2500
Type
2501
2502
4
2503
2504
Length
2505
2506
>= 4
2507
2508
Quality-Protocol
2509
2510
The Quality-Protocol field is two octets, and indicates the link
2511
quality monitoring protocol desired. Values for this field are
2512
always the same as the PPP Protocol field values for that same
2513
monitoring protocol.
2514
2515
Up-to-date values of the Quality-Protocol field are specified in
2516
the most recent "Assigned Numbers" RFC [2]. Current values are
2517
assigned as follows:
2518
2519
Value (in hex) Protocol
2520
2521
c025 Link Quality Report
2522
2523
2524
Data
2525
2526
The Data field is zero or more octets, and contains additional
2527
data as determined by the particular protocol.
2528
2529
2530
2531
2532
2533
2534
Simpson [Page 44]
2535
RFC 1661 Point-to-Point Protocol July 1994
2536
2537
2538
6.4. Magic-Number
2539
2540
Description
2541
2542
This Configuration Option provides a method to detect looped-back
2543
links and other Data Link Layer anomalies. This Configuration
2544
Option MAY be required by some other Configuration Options such as
2545
the Quality-Protocol Configuration Option. By default, the
2546
Magic-Number is not negotiated, and zero is inserted where a
2547
Magic-Number might otherwise be used.
2548
2549
Before this Configuration Option is requested, an implementation
2550
MUST choose its Magic-Number. It is recommended that the Magic-
2551
Number be chosen in the most random manner possible in order to
2552
guarantee with very high probability that an implementation will
2553
arrive at a unique number. A good way to choose a unique random
2554
number is to start with a unique seed. Suggested sources of
2555
uniqueness include machine serial numbers, other network hardware
2556
addresses, time-of-day clocks, etc. Particularly good random
2557
number seeds are precise measurements of the inter-arrival time of
2558
physical events such as packet reception on other connected
2559
networks, server response time, or the typing rate of a human
2560
user. It is also suggested that as many sources as possible be
2561
used simultaneously.
2562
2563
When a Configure-Request is received with a Magic-Number
2564
Configuration Option, the received Magic-Number is compared with
2565
the Magic-Number of the last Configure-Request sent to the peer.
2566
If the two Magic-Numbers are different, then the link is not
2567
looped-back, and the Magic-Number SHOULD be acknowledged. If the
2568
two Magic-Numbers are equal, then it is possible, but not certain,
2569
that the link is looped-back and that this Configure-Request is
2570
actually the one last sent. To determine this, a Configure-Nak
2571
MUST be sent specifying a different Magic-Number value. A new
2572
Configure-Request SHOULD NOT be sent to the peer until normal
2573
processing would cause it to be sent (that is, until a Configure-
2574
Nak is received or the Restart timer runs out).
2575
2576
Reception of a Configure-Nak with a Magic-Number different from
2577
that of the last Configure-Nak sent to the peer proves that a link
2578
is not looped-back, and indicates a unique Magic-Number. If the
2579
Magic-Number is equal to the one sent in the last Configure-Nak,
2580
the possibility of a looped-back link is increased, and a new
2581
Magic-Number MUST be chosen. In either case, a new Configure-
2582
Request SHOULD be sent with the new Magic-Number.
2583
2584
If the link is indeed looped-back, this sequence (transmit
2585
Configure-Request, receive Configure-Request, transmit Configure-
2586
2587
2588
2589
Simpson [Page 45]
2590
RFC 1661 Point-to-Point Protocol July 1994
2591
2592
2593
Nak, receive Configure-Nak) will repeat over and over again. If
2594
the link is not looped-back, this sequence might occur a few
2595
times, but it is extremely unlikely to occur repeatedly. More
2596
likely, the Magic-Numbers chosen at either end will quickly
2597
diverge, terminating the sequence. The following table shows the
2598
probability of collisions assuming that both ends of the link
2599
select Magic-Numbers with a perfectly uniform distribution:
2600
2601
Number of Collisions Probability
2602
-------------------- ---------------------
2603
1 1/2**32 = 2.3 E-10
2604
2 1/2**32**2 = 5.4 E-20
2605
3 1/2**32**3 = 1.3 E-29
2606
2607
2608
Good sources of uniqueness or randomness are required for this
2609
divergence to occur. If a good source of uniqueness cannot be
2610
found, it is recommended that this Configuration Option not be
2611
enabled; Configure-Requests with the option SHOULD NOT be
2612
transmitted and any Magic-Number Configuration Options which the
2613
peer sends SHOULD be either acknowledged or rejected. In this
2614
case, looped-back links cannot be reliably detected by the
2615
implementation, although they may still be detectable by the peer.
2616
2617
If an implementation does transmit a Configure-Request with a
2618
Magic-Number Configuration Option, then it MUST NOT respond with a
2619
Configure-Reject when it receives a Configure-Request with a
2620
Magic-Number Configuration Option. That is, if an implementation
2621
desires to use Magic Numbers, then it MUST also allow its peer to
2622
do so. If an implementation does receive a Configure-Reject in
2623
response to a Configure-Request, it can only mean that the link is
2624
not looped-back, and that its peer will not be using Magic-
2625
Numbers. In this case, an implementation SHOULD act as if the
2626
negotiation had been successful (as if it had instead received a
2627
Configure-Ack).
2628
2629
The Magic-Number also may be used to detect looped-back links
2630
during normal operation, as well as during Configuration Option
2631
negotiation. All LCP Echo-Request, Echo-Reply, and Discard-
2632
Request packets have a Magic-Number field. If Magic-Number has
2633
been successfully negotiated, an implementation MUST transmit
2634
these packets with the Magic-Number field set to its negotiated
2635
Magic-Number.
2636
2637
The Magic-Number field of these packets SHOULD be inspected on
2638
reception. All received Magic-Number fields MUST be equal to
2639
either zero or the peer's unique Magic-Number, depending on
2640
whether or not the peer negotiated a Magic-Number.
2641
2642
2643
2644
Simpson [Page 46]
2645
RFC 1661 Point-to-Point Protocol July 1994
2646
2647
2648
Reception of a Magic-Number field equal to the negotiated local
2649
Magic-Number indicates a looped-back link. Reception of a Magic-
2650
Number other than the negotiated local Magic-Number, the peer's
2651
negotiated Magic-Number, or zero if the peer didn't negotiate one,
2652
indicates a link which has been (mis)configured for communications
2653
with a different peer.
2654
2655
Procedures for recovery from either case are unspecified, and may
2656
vary from implementation to implementation. A somewhat
2657
pessimistic procedure is to assume a LCP Down event. A further
2658
Open event will begin the process of re-establishing the link,
2659
which can't complete until the looped-back condition is
2660
terminated, and Magic-Numbers are successfully negotiated. A more
2661
optimistic procedure (in the case of a looped-back link) is to
2662
begin transmitting LCP Echo-Request packets until an appropriate
2663
Echo-Reply is received, indicating a termination of the looped-
2664
back condition.
2665
2666
A summary of the Magic-Number Configuration Option format is shown
2667
below. The fields are transmitted from left to right.
2668
2669
0 1 2 3
2670
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
2671
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2672
| Type | Length | Magic-Number
2673
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2674
Magic-Number (cont) |
2675
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2676
2677
2678
Type
2679
2680
5
2681
2682
Length
2683
2684
6
2685
2686
Magic-Number
2687
2688
The Magic-Number field is four octets, and indicates a number
2689
which is very likely to be unique to one end of the link. A
2690
Magic-Number of zero is illegal and MUST always be Nak'd, if it is
2691
not Rejected outright.
2692
2693
2694
2695
2696
2697
2698
2699
Simpson [Page 47]
2700
RFC 1661 Point-to-Point Protocol July 1994
2701
2702
2703
6.5. Protocol-Field-Compression (PFC)
2704
2705
Description
2706
2707
This Configuration Option provides a method to negotiate the
2708
compression of the PPP Protocol field. By default, all
2709
implementations MUST transmit packets with two octet PPP Protocol
2710
fields.
2711
2712
PPP Protocol field numbers are chosen such that some values may be
2713
compressed into a single octet form which is clearly
2714
distinguishable from the two octet form. This Configuration
2715
Option is sent to inform the peer that the implementation can
2716
receive such single octet Protocol fields.
2717
2718
As previously mentioned, the Protocol field uses an extension
2719
mechanism consistent with the ISO 3309 extension mechanism for the
2720
Address field; the Least Significant Bit (LSB) of each octet is
2721
used to indicate extension of the Protocol field. A binary "0" as
2722
the LSB indicates that the Protocol field continues with the
2723
following octet. The presence of a binary "1" as the LSB marks
2724
the last octet of the Protocol field. Notice that any number of
2725
"0" octets may be prepended to the field, and will still indicate
2726
the same value (consider the two binary representations for 3,
2727
00000011 and 00000000 00000011).
2728
2729
When using low speed links, it is desirable to conserve bandwidth
2730
by sending as little redundant data as possible. The Protocol-
2731
Field-Compression Configuration Option allows a trade-off between
2732
implementation simplicity and bandwidth efficiency. If
2733
successfully negotiated, the ISO 3309 extension mechanism may be
2734
used to compress the Protocol field to one octet instead of two.
2735
The large majority of packets are compressible since data
2736
protocols are typically assigned with Protocol field values less
2737
than 256.
2738
2739
Compressed Protocol fields MUST NOT be transmitted unless this
2740
Configuration Option has been negotiated. When negotiated, PPP
2741
implementations MUST accept PPP packets with either double-octet
2742
or single-octet Protocol fields, and MUST NOT distinguish between
2743
them.
2744
2745
The Protocol field is never compressed when sending any LCP
2746
packet. This rule guarantees unambiguous recognition of LCP
2747
packets.
2748
2749
When a Protocol field is compressed, the Data Link Layer FCS field
2750
is calculated on the compressed frame, not the original
2751
2752
2753
2754
Simpson [Page 48]
2755
RFC 1661 Point-to-Point Protocol July 1994
2756
2757
2758
uncompressed frame.
2759
2760
A summary of the Protocol-Field-Compression Configuration Option
2761
format is shown below. The fields are transmitted from left to
2762
right.
2763
2764
0 1
2765
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
2766
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2767
| Type | Length |
2768
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2769
2770
2771
Type
2772
2773
7
2774
2775
Length
2776
2777
2
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
Simpson [Page 49]
2810
RFC 1661 Point-to-Point Protocol July 1994
2811
2812
2813
6.6. Address-and-Control-Field-Compression (ACFC)
2814
2815
Description
2816
2817
This Configuration Option provides a method to negotiate the
2818
compression of the Data Link Layer Address and Control fields. By
2819
default, all implementations MUST transmit frames with Address and
2820
Control fields appropriate to the link framing.
2821
2822
Since these fields usually have constant values for point-to-point
2823
links, they are easily compressed. This Configuration Option is
2824
sent to inform the peer that the implementation can receive
2825
compressed Address and Control fields.
2826
2827
If a compressed frame is received when Address-and-Control-Field-
2828
Compression has not been negotiated, the implementation MAY
2829
silently discard the frame.
2830
2831
The Address and Control fields MUST NOT be compressed when sending
2832
any LCP packet. This rule guarantees unambiguous recognition of
2833
LCP packets.
2834
2835
When the Address and Control fields are compressed, the Data Link
2836
Layer FCS field is calculated on the compressed frame, not the
2837
original uncompressed frame.
2838
2839
A summary of the Address-and-Control-Field-Compression configuration
2840
option format is shown below. The fields are transmitted from left
2841
to right.
2842
2843
0 1
2844
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
2845
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2846
| Type | Length |
2847
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2848
2849
2850
Type
2851
2852
8
2853
2854
Length
2855
2856
2
2857
2858
2859
2860
2861
2862
2863
2864
Simpson [Page 50]
2865
RFC 1661 Point-to-Point Protocol July 1994
2866
2867
2868
Security Considerations
2869
2870
Security issues are briefly discussed in sections concerning the
2871
Authentication Phase, the Close event, and the Authentication-
2872
Protocol Configuration Option.
2873
2874
2875
2876
References
2877
2878
[1] Perkins, D., "Requirements for an Internet Standard Point-to-
2879
Point Protocol", RFC 1547, Carnegie Mellon University,
2880
December 1993.
2881
2882
[2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
2883
1340, USC/Information Sciences Institute, July 1992.
2884
2885
2886
Acknowledgements
2887
2888
This document is the product of the Point-to-Point Protocol Working
2889
Group of the Internet Engineering Task Force (IETF). Comments should
2890
be submitted to the ietf-ppp@merit.edu mailing list.
2891
2892
Much of the text in this document is taken from the working group
2893
requirements [1]; and RFCs 1171 & 1172, by Drew Perkins while at
2894
Carnegie Mellon University, and by Russ Hobby of the University of
2895
California at Davis.
2896
2897
William Simpson was principally responsible for introducing
2898
consistent terminology and philosophy, and the re-design of the phase
2899
and negotiation state machines.
2900
2901
Many people spent significant time helping to develop the Point-to-
2902
Point Protocol. The complete list of people is too numerous to list,
2903
but the following people deserve special thanks: Rick Adams, Ken
2904
Adelman, Fred Baker, Mike Ballard, Craig Fox, Karl Fox, Phill Gross,
2905
Kory Hamzeh, former WG chair Russ Hobby, David Kaufman, former WG
2906
chair Steve Knowles, Mark Lewis, former WG chair Brian Lloyd, John
2907
LoVerso, Bill Melohn, Mike Patton, former WG chair Drew Perkins, Greg
2908
Satz, John Shriver, Vernon Schryver, and Asher Waldfogel.
2909
2910
Special thanks to Morning Star Technologies for providing computing
2911
resources and network access support for writing this specification.
2912
2913
2914
2915
2916
2917
2918
2919
Simpson [Page 51]
2920
RFC 1661 Point-to-Point Protocol July 1994
2921
2922
2923
Chair's Address
2924
2925
The working group can be contacted via the current chair:
2926
2927
Fred Baker
2928
Advanced Computer Communications
2929
315 Bollay Drive
2930
Santa Barbara, California 93117
2931
2932
fbaker@acc.com
2933
2934
2935
2936
Editor's Address
2937
2938
Questions about this memo can also be directed to:
2939
2940
William Allen Simpson
2941
Daydreamer
2942
Computer Systems Consulting Services
2943
1384 Fontaine
2944
Madison Heights, Michigan 48071
2945
2946
Bill.Simpson@um.cc.umich.edu
2947
bsimpson@MorningStar.com
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
Simpson [Page 52]
2975
2976
Loggerhead is a web-based interface for Breezy
Version: 2.0.1