1 2 3 4 5 6 7Network Working Group W. Simpson, Editor 8Request for Comments: 1661 Daydreamer 9STD: 51 July 1994 10Obsoletes: 1548 11Category: Standards Track 12 13 14 The Point-to-Point Protocol (PPP) 15 16 17 18Status 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 27Abstract 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 49Table 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 59Simpson [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 114Simpson [Page ii] 115 RFC 1661 Point-to-Point Protocol July 1994 116 117 1181. 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 169Simpson [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 1961.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 224Simpson [Page 2] 225 RFC 1661 Point-to-Point Protocol July 1994 226 227 2281.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 279Simpson [Page 3] 280 RFC 1661 Point-to-Point Protocol July 1994 281 282 2832. 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 334Simpson [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 389Simpson [Page 5] 390 RFC 1661 Point-to-Point Protocol July 1994 391 392 3933. PPP Link Operation 394 3953.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 4143.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 444Simpson [Page 6] 445 RFC 1661 Point-to-Point Protocol July 1994 446 447 4483.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 4683.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 499Simpson [Page 7] 500 RFC 1661 Point-to-Point Protocol July 1994 501 502 5033.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 5423.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 554Simpson [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 5823.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 609Simpson [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 664Simpson [Page 10] 665 RFC 1661 Point-to-Point Protocol July 1994 666 667 6684. 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 719Simpson [Page 11] 720 RFC 1661 Point-to-Point Protocol July 1994 721 722 7234.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 736Events| 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 774Simpson [Page 12] 775 RFC 1661 Point-to-Point Protocol July 1994 776 777 778 779 | State 780 | 6 7 8 9 781Events| 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 829Simpson [Page 13] 830 RFC 1661 Point-to-Point Protocol July 1994 831 832 8334.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 884Simpson [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 939Simpson [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 9704.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 994Simpson [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 1049Simpson [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 1104Simpson [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 1159Simpson [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 1214Simpson [Page 20] 1215 RFC 1661 Point-to-Point Protocol July 1994 1216 1217 12184.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 1269Simpson [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 1324Simpson [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 13644.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 1379Simpson [Page 23] 1380 RFC 1661 Point-to-Point Protocol July 1994 1381 1382 13834.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 1434Simpson [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 1489Simpson [Page 25] 1490 RFC 1661 Point-to-Point Protocol July 1994 1491 1492 14935. 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 1544Simpson [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 1599Simpson [Page 27] 1600 RFC 1661 Point-to-Point Protocol July 1994 1601 1602 16035.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 1654Simpson [Page 28] 1655 RFC 1661 Point-to-Point Protocol July 1994 1656 1657 16585.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 1709Simpson [Page 29] 1710 RFC 1661 Point-to-Point Protocol July 1994 1711 1712 17135.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 1764Simpson [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 17995.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 1819Simpson [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 1874Simpson [Page 32] 1875 RFC 1661 Point-to-Point Protocol July 1994 1876 1877 18785.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 1929Simpson [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 19415.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 1984Simpson [Page 34] 1985 RFC 1661 Point-to-Point Protocol July 1994 1986 1987 1988 established MRU. 1989 1990 1991 19925.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 2039Simpson [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 20535.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 2094Simpson [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 21245.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 2149Simpson [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 2204Simpson [Page 38] 2205 RFC 1661 Point-to-Point Protocol July 1994 2206 2207 22086. 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 2259Simpson [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 2314Simpson [Page 40] 2315 RFC 1661 Point-to-Point Protocol July 1994 2316 2317 23186.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 2369Simpson [Page 41] 2370 RFC 1661 Point-to-Point Protocol July 1994 2371 2372 23736.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 2424Simpson [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 24566.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 2479Simpson [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 2534Simpson [Page 44] 2535 RFC 1661 Point-to-Point Protocol July 1994 2536 2537 25386.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 2589Simpson [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 2644Simpson [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 2699Simpson [Page 47] 2700 RFC 1661 Point-to-Point Protocol July 1994 2701 2702 27036.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 2754Simpson [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 2809Simpson [Page 49] 2810 RFC 1661 Point-to-Point Protocol July 1994 2811 2812 28136.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 2864Simpson [Page 50] 2865 RFC 1661 Point-to-Point Protocol July 1994 2866 2867 2868Security 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 2876References 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 2886Acknowledgements 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 2919Simpson [Page 51] 2920 RFC 1661 Point-to-Point Protocol July 1994 2921 2922 2923Chair'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 2936Editor'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 2974Simpson [Page 52] 2975 2976 2977