idnits 2.17.1 draft-carrel-info-pppoe-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Working Group Louis Mamakos, Kurt Lidl, Jeff Evarts 3 INTERNET-DRAFT UUNET Technologies, Inc. 4 Category: Informational David Carrel, Dan Simone 5 Title: draft-carrel-info-pppoe-00.txt RedBack Networks, Inc. 6 Date: August 1998 Ross Wheeler 7 RouterWare, Inc. 9 PPP Over Ethernet "PPPOE" 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet Drafts as reference 22 material or to cite them other than as "working draft" or "work in 23 progress." 25 To learn the current status of any Internet Draft, please check the 26 1id-abstracts.txt listing contained in the Internet Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Australia), ftp.ietf.org (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 The distribution of this memo is unlimited. It is filed as , and expires 10 February, 1999. Please 33 send comments to the authors. 35 Abstract 37 The Point-to-Point Protocol (PPP) [1] provides a standard method for 38 transporting multi-protocol datagrams over point-to-point links. 40 This document describes the use of Ethernet framing for PPP 41 encapsulated packets. 43 Evarts, Carrel [Page1] 44 Applicability 46 PPP requires a point-to-point relationship between its peers and is 47 not designed for the multi-point relationships which are available in 48 Ethernet and other multi-access environments. This document 49 therefore defines a means for conveying PPP facilities, including the 50 Link Control Protocol, Network-layer Control Protocols, 51 authentication, compression and more, over Ethernet. 53 The protocol described in this document can be used by multiple hosts 54 on a shared, Ethernet to open PPP sessions to multiple destinations 55 via one or more bridging modems. 57 1. Introduction 59 Modern access technologies are faced with several conflicting goals. 60 It is desirable to connect multiple hosts at a remote site through 61 the same customer premise access device. It is also a goal to 62 provide access control and billing functionality in a manner similar 63 to dial-up services using PPP. 65 In many access technologies, the most cost effective method to attach 66 multiple hosts to the customer premise access device, is via 67 Ethernet. In addition, it is desirable to keep the cost of this 68 device as low as possible while requiring little or no configuration. 70 PPP over Ethernet (PPPOE) provides the ability to connect a network 71 of hosts over a simple bridging access device to a remote Access 72 Concentrator. With this model, each host utilizes it's own PPP stack 73 and the user is presented with a familiar user interface. Access 74 control, billing and type of service can be done on a per-user, 75 rather than a per-site, basis. 77 To provide a point-to-point connection over Ethernet, each PPP 78 session must learn the Ethernet address of the remote peer, as well 79 as establish a unique session identifier. PPPOE includes a discovery 80 protocol that provides this. 82 2. Conventions 84 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 85 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 86 document, are to be interpreted as described in [2]. 88 Evarts, Carrel [Page2] 89 3. Protocol Overview 91 PPPOE has two distinct stages. There is a Discovery stage and a PPP 92 Session stage. When a Host wishes to initiate a PPPOE session, it 93 must first perform Discovery to identify the Ethernet MAC address of 94 the peer and establish a PPPOE SESSION_ID. While PPP defines a peer- 95 to-peer relationship, Discovery is inherently a client-server 96 relationship. In the Discovery process, a Host (the client) 97 discovers an Access Concentrator (the server). Based on the network 98 topology, there may be more than one Access Concentrator that the 99 Host can communicate with. The Discovery stage allows the Host to 100 discover all Access Concentrators and then select one. When 101 Discovery completes successfully, both the Host and the selected 102 Access Concentrator have the information they will use to build their 103 point-to-point connection over Ethernet. 105 The Discovery stage remains stateless until a PPP session is 106 established. Once a PPP session is established, both the Host and 107 the Access Concentrator MUST allocate the resources for a PPP virtual 108 interface. 110 4. Payloads 112 The following packet formats are defined here. The payload contents 113 will be defined in the Discovery and PPP sections. 115 An Ethernet frame is as follows: 117 1 118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | DESTINATION_ADDR | 121 | (6 octets) | 122 | | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | SOURCE_ADDR | 125 | (6 octets) | 126 | | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | ETHER_TYPE (2 octets) | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 ~ ~ 131 ~ payload ~ 132 ~ ~ 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | CHECKSUM | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 Evarts, Carrel [Page3] 138 The DESTINATION_ADDR field contains either a unicast Ethernet 139 destination address, or the Ethernet broadcast address (0xffffffff). 140 For Discovery packets, the value is either a unicast or broadcast 141 address as defined in the Discovery section. For PPP session 142 traffic, this field MUST contain the peer's unicast address as 143 determined from the Discovery stage. 145 The SOURCE_ADDR field MUST contains the Ethernet MAC address of the 146 source device. 148 The Ethernet payload for PPPOE is as follows: 150 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | VER | TYPE | CODE | SESSION_ID | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | LENGTH | payload ~ 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 The VER field is four bits and MUST be set to 0x1 for this version of 159 the PPPOE specification. 161 The TYPE field is four bits and MUST be set to 0x1 for this version 162 of the PPPOE specification. 164 The CODE field is eight bits and is defined below for the Discovery 165 and PPP Session stages. 167 The SESSION_ID field is sixteen bits. It is an unsigned value in 168 network byte order. It's value is defined below for Discovery 169 packets. The value is fixed for a given PPP session and, in fact, 170 defines a PPP session along with the Ethernet SOURCE_ADDR and 171 DESTINATION_ADDR. 173 The LENGTH field is sixteen bits. The value, in network byte order, 174 indicates the length of the PPPOE payload. It does not include the 175 length of the Ethernet or PPPOE headers. 177 5. Discovery Stage 179 There are four steps to the Discovery stage. When it completes, both 180 peers know the PPPOE SESSION_ID and the peer's Ethernet address, 181 which together define the PPPOE session uniquely. The steps consist 182 of the Host broadcasting an Initiation packet, one or more Access 183 Concentrators sending Offer packets, the Host sending a unicast 184 Session Request packet and the selected Access Concentrator sending a 186 Evarts, Carrel [Page4] 187 Confirmation packet. When the Host receives the Confirmation packet, 188 it may proceed to the PPP Session Stage. When the Access 189 Concentrator sends the Confirmation packet, it may proceed to the PPP 190 Session Stage. 192 All Discovery Ethernet frames have the ETHER_TYPE field set to the 193 value 0x8863. 195 The PPPOE payload contains zero or more tags. A tag is a TLV (type- 196 length-value) construct and is defined as follows: 198 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | TAG_TYPE | TAG_LENGTH | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | TAG_VALUE ... ~ 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 TAG_TYPE is a sixteen bit field in network byte order. Appendix A 207 contains a list of all TAG_TYPEs and their TAG_VALUEs. 209 TAG_LENGTH is a sixteen bit field. It's value is an unsigned number 210 in network byte order, indicating the length in octets of the 211 TAG_VALUE. 213 Some example Discovery packets are shown in Appendix B. 215 5.1 The PPPOE Active Discovery Initiation (PADI) packet 217 The Host sends the PADI packet with the DESTINATION_ADDR set to the 218 broadcast address. The CODE field is set to 0x09 and the SESSION_ID 219 MUST be set to 0x0000. 221 The PADI packet contains exactly one tag of type Service-Name, 222 indicating the service the Host is requesting, and any number of 223 other tag types. 225 5.2 The PPPOE Active Discovery Offer (PADO) packet 227 When the Access Concentrator receives a PADI that it can serve, it 228 replies by sending a PADO packet. The DESTINATION_ADDR is the 229 unicast address of the Host that sent the PADI. The CODE field is 230 set to 0x07 and the SESSION_ID MUST be set to 0x0000. 232 The PADO packet MUST contain one AC-Name tag containing the Access 233 Concentrator's name, a Service-Name tag identical to the one in the 234 PADI, and any number of other Service-Name tags indicating other 236 Evarts, Carrel [Page5] 237 services that the Access Concentrator offers. If the Access 238 Concentrator can not serve the PADI, then it MUST NOT respond with a 239 PADO. 241 5.3 The PPPOE Active Discovery Request (PADR) packet 243 Since the PADI was broadcast, the Host may receive more than one 244 PADO. The Host looks through the PADO packets it receives and 245 chooses one. The choice can be based on the AC-Name or the Services 246 offered. The Host then sends one PADR packet to the Access 247 Concentrator that it has chosen. The DESTINATION_ADDR field is set 248 to the unicast Ethernet address of the Access Concentrator that sent 249 the PADO. The CODE field is set to 0x19 and the SESSION_ID MUST be 250 set to 0x0000. 252 The PADR packet contains exactly one tag of type Service-Name, 253 indicating the service the Host is requesting, and any number of 254 other tag types. 256 5.4 The PPPOE Active Discovery Session-confirmation (PADS) packet 258 When the Access Concentrator receives a PADR packet, it prepares to 259 begin a PPP session. It generates a unique SESSION_ID for the PPPOE 260 session and replies to the Host with a PADS packet. The 261 DESTINATION_ADDR field is the unicast Ethernet address of the Host 262 that sent the PADR. The CODE field is set to 0x65 and the SESSION_ID 263 MUST be set to the unique value generated for this PPPOE session. 265 The PADR packet contains exactly one tag of type Service-Name, 266 indicating the service under which Access Concentrator has accepted 267 the PPPOE session, and any number of other tag types. 269 If the Access Concentrator does not like the Service-Name in the 270 PADR, then it MUST reply with a PADS containing a single tag of type 271 Service-Name-Error, and the SESSION_ID MUST be set to 0x0000. 273 6. PPP Session Stage 275 Once the PPPOE session begins, PPP data is sent as in any other PPP 276 encapsulation. All Ethernet packets are unicast. The ETHER_TYPE 277 field is set to 0x8864. The PPPOE CODE MUST be set to 0x00. The 278 SESSION_ID MUST NOT change for that PPPOE session and MUST be the 279 value assigned in the Discovery stage. The PPPOE payload contains a 280 PPP frame. The frame begins with the PPP Protocol-ID. 282 An example packet is shown in Appendix B. 284 Evarts, Carrel [Page6] 285 7. LCP Considerations 287 The Magic Number LCP configuration option is RECOMMENDED, and the 288 Protocol Field Compression (PFC) option is NOT RECOMMENDED. An 289 implementation MUST NOT request any of the following options, and 290 MUST reject a request for such an option: 292 Field Check Sequence (FCS) Alternatives, 294 Address-and-Control-Field-Compression (ACFC), 296 Asynchronous-Control-Character-Map (ACCM) 298 The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a 299 larger size than 1492. Since Ethernet has a maximum payload size of 300 1500 octets, the PPPOE header is 6 octets and the PPP Protocol ID is 301 2 octets, the PPP MTU MUST NOT be greater than 1492. 303 When LCP terminates, the Host and Access concentrator MUST stop using 304 that PPPOE session. If the Host wishes to start another PPP session, 305 it MUST return to the PPPOE Discovery stage. 307 8. Other Considerations 309 When a host does not receive a PADO packet within a specified amount 310 of time, the client SHOULD resend it's PADI packet and double the 311 waiting period. This is repeated as many times as desired. If the 312 Host is waiting to receive a PADS packet, a similar timeout mechanism 313 SHOULD be used, with the Host re-sending the PADR. After a specified 314 number of retries, the Host SHOULD then resend a PADI packet. 316 The ETHER_TYPEs used in this document (0x8863 and 0x8864) have been 317 assigned by the IEEE for use by PPP Over Ethernet (PPPOE). Use of 318 these values and the PPPOE VER (version) field uniquely identify this 319 protocol. 321 9. Security Considerations 323 Denial of Service (DOS) attacks can be used against an Access 324 Concentrator that employs this protocol. A Cookie tag is currently 325 being investigated to understand if it can alleviate the threat. 326 An Access Concentrator can also employ means outside this protocol to 327 prevent against DOS attacks. 329 Many Access Concentrators will not wish to offer information 330 regarding what services they offer to an unauthenticated entity. In 332 Evarts, Carrel [Page7] 333 that case the Access Concentrator should employ one of two policies. 334 It SHOULD never refuse a request based on the Service-Name tag, and 335 always return the TAG_VALUE that was sent to it. Or it SHOULD only 336 accept requests with a Service-Name tag with a zero TAG_LENGTH 337 (indicating any service). The former solution is RECOMMENDED. 339 10. Acknowledgments 341 This document is based on concepts discussed in several forums, 342 including the ADSL forum. 344 Copious amounts of text have been stolen from RFC 1661, RFC 1662 and 345 RFC 2364. 347 11. References 349 [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 350 07/21/1994 352 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 353 Levels", BCP 14, RFC 2119, March 1997. 355 Appendix A 357 TAG_TYPES and TAG_VALUES 359 0x0000 End-Of-List 361 This tag indicates that there are no further tags in the list. The 362 TAG_LENGTH of this tag MUST always be zero. Use of this tag is 363 not required, but remains for backwards compatibility. 365 0x0101 Service-Name 367 This tag indicates that a service name follows. The TAG_VALUE is 368 an ASCII string that is NOT NULL terminated. When the TAG_LENGTH 369 is zero this tag is used to indicate that any service is 370 acceptable. Examples of the use of the Service-Name tag are to 371 indicate an ISP name or a class or quality of service. 373 0x0102 AC-Name 375 This tag indicates that a string follows which uniquely identifies 376 this particular Access Concentrator unit from all others. It may 377 be a combination of trademark, model, and serial id information, 378 or simply an ascii rendition of the MAC address of the box. 380 Evarts, Carrel [Page8] 381 0x0201 Service-Name-Error 383 This tag (typically with a zero-length data section) indicates 384 that for one reason or another, the requested Service-Name request 385 could not be honored. 387 If there is data, and the first octet of the data is nonzero, then 388 it MUST be a printable ascii string which explains why the request 389 was denied. 391 Appendix B 393 The following are some example packets: 395 A PADI packet: 397 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | 0xffffffff | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | 0xffff | Host_mac_addr | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Host_mac_addr (cont) | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x09 | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | SESSION_ID = 0x0000 | LENGTH = 0x0004 | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Evarts, Carrel [Page9] 414 A PADO packet: 416 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Host_mac_addr | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Host_mac_addr (cont) | Access_Concentrator_mac_addr | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Access_Concentrator_mac_addr (cont) | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x07 | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | SESSION_ID = 0x0000 | LENGTH = 0x0020 | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | TAG_TYPE = 0x0102 | TAG_LENGTH = 0x0018 | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | 0x47 | 0x6f | 0x20 | 0x52 | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | 0x65 | 0x64 | 0x42 | 0x61 | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | 0x63 | 0x6b | 0x20 | 0x2d | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | 0x20 | 0x65 | 0x73 | 0x68 | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | 0x73 | 0x68 | 0x65 | 0x73 | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | 0x68 | 0x6f | 0x6f | 0x74 | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Evarts, Carrel [Page10] 447 A PPP LCP packet: The PPP protocol value is shown (0xc021) but the 448 PPP payload is left to the reader. This is a packet from the Host to 449 the Access Concentrator. 451 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Access_Concentrator_mac_addr | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 |Access_Concentrator_mac_addr(c)| Host_mac_addr | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Host_mac_addr (cont) | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | ETHER_TYPE = 0x8864 | v = 1 | t = 1 | CODE = 0x00 | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | SESSION_ID = 0x1234 | LENGTH = 0x???? | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | PPP PROTOCOL = 0xc021 | PPP payload ~ 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Authors' Addresses: 469 Louis Mamakos 470 Kurt Lidl 471 Jeff Evarts 472 UUNET Technologies, Inc. 473 3060 Williams Drive 474 Fairfax, VA 22031-4648 475 United States of America 477 David Carrel 478 Dan Simone 479 RedBack Networks, Inc. 480 1389 Moffett Park Drive 481 Sunnyvale, CA 94089-1134 482 United States of America 484 Ross Wheeler 485 RouterWare, Inc. 486 3961 MacArthur Blvd., Suite 212 487 Newport Beach, CA 92660 488 United States of America 490 Evarts, Carrel [Page11]