idnits 2.17.1 draft-carrel-info-pppoe-01.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-26) 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 13 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: If there is data, and the first octet of the data is nonzero, then it MUST be a printable ascii string which explains why the request was denied. This string MAY NOT be NULL terminated. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: If there is data, and the first octet of the data is nonzero, then it MUST be a printable ascii string which explains the nature of the error. This string MAY NOT be NULL terminated. -- 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 ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1700 (ref. '4') (Obsoleted by RFC 3232) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 3 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-01.txt RedBack Networks, Inc. 6 Date: September 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 1 March, 1999. Please send 33 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 how to build PPP sessions and encapsulate PPP 41 packets over Ethernet 43 Evarts, Carrel [Page1] 44 Applicability 46 This specification is intended to provide the facilities which are 47 defined for PPP, such as the Link Control Protocol, Network-layer 48 Control Protocols, authentication, and more. These capabilities 49 require a point-to-point relationship between the peers, and are not 50 designed for the multi-point relationships which are available in 51 Ethernet and other multi-access environments. 53 This specification can be used by multiple hosts on a shared, 54 Ethernet to open PPP sessions to multiple destinations via one or 55 more bridging modems. It is intended to be used with broadband 56 remote access technologies that provide a bridged Ethernet topology, 57 when access providers wish to maintain the session abstraction 58 associated with PPP. 60 This document describes the PPP Over Ethernet encapsulation that is 61 being deployed by RedBack Networks, RouterWare, UUNET and others. 63 1. Introduction 65 Modern access technologies are faced with several conflicting goals. 66 It is desirable to connect multiple hosts at a remote site through 67 the same customer premise access device. It is also a goal to 68 provide access control and billing functionality in a manner similar 69 to dial-up services using PPP. In many access technologies, the most 70 cost effective method to attach multiple hosts to the customer 71 premise access device, is via Ethernet. In addition, it is desirable 72 to keep the cost of this device as low as possible while requiring 73 little or no configuration. 75 PPP over Ethernet (PPPOE) provides the ability to connect a network 76 of hosts over a simple bridging access device to a remote Access 77 Concentrator. With this model, each host utilizes it's own PPP stack 78 and the user is presented with a familiar user interface. Access 79 control, billing and type of service can be done on a per-user, 80 rather than a per-site, basis. 82 To provide a point-to-point connection over Ethernet, each PPP 83 session must learn the Ethernet address of the remote peer, as well 84 as establish a unique session identifier. PPPOE includes a discovery 85 protocol that provides this. 87 2. Conventions 89 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 90 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 91 document, are to be interpreted as described in [2]. 93 Evarts, Carrel [Page2] 94 3. Protocol Overview 96 PPPOE has two distinct stages. There is a Discovery stage and a PPP 97 Session stage. When a Host wishes to initiate a PPPOE session, it 98 must first perform Discovery to identify the Ethernet MAC address of 99 the peer and establish a PPPOE SESSION_ID. While PPP defines a peer- 100 to-peer relationship, Discovery is inherently a client-server 101 relationship. In the Discovery process, a Host (the client) 102 discovers an Access Concentrator (the server). Based on the network 103 topology, there may be more than one Access Concentrator that the 104 Host can communicate with. The Discovery stage allows the Host to 105 discover all Access Concentrators and then select one. When 106 Discovery completes successfully, both the Host and the selected 107 Access Concentrator have the information they will use to build their 108 point-to-point connection over Ethernet. 110 The Discovery stage remains stateless until a PPP session is 111 established. Once a PPP session is established, both the Host and 112 the Access Concentrator MUST allocate the resources for a PPP virtual 113 interface. 115 4. Payloads 117 The following packet formats are defined here. The payload contents 118 will be defined in the Discovery and PPP sections. 120 An Ethernet frame is as follows: 122 1 123 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | DESTINATION_ADDR | 126 | (6 octets) | 127 | | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | SOURCE_ADDR | 130 | (6 octets) | 131 | | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | ETHER_TYPE (2 octets) | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 ~ ~ 136 ~ payload ~ 137 ~ ~ 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | CHECKSUM | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Evarts, Carrel [Page3] 143 The DESTINATION_ADDR field contains either a unicast Ethernet 144 destination address, or the Ethernet broadcast address (0xffffffff). 145 For Discovery packets, the value is either a unicast or broadcast 146 address as defined in the Discovery section. For PPP session 147 traffic, this field MUST contain the peer's unicast address as 148 determined from the Discovery stage. 150 The SOURCE_ADDR field MUST contains the Ethernet MAC address of the 151 source device. 153 The ETHER_TYPE is set to either 0x8863 (Discovery Stage) or 0x8864 154 (PPP Session Stage). 156 The Ethernet payload for PPPOE is as follows: 158 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | VER | TYPE | CODE | SESSION_ID | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | LENGTH | payload ~ 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 The VER field is four bits and MUST be set to 0x1 for this version of 167 the PPPOE specification. 169 The TYPE field is four bits and MUST be set to 0x1 for this version 170 of the PPPOE specification. 172 The CODE field is eight bits and is defined below for the Discovery 173 and PPP Session stages. 175 The SESSION_ID field is sixteen bits. It is an unsigned value in 176 network byte order. It's value is defined below for Discovery 177 packets. The value is fixed for a given PPP session and, in fact, 178 defines a PPP session along with the Ethernet SOURCE_ADDR and 179 DESTINATION_ADDR. 181 The LENGTH field is sixteen bits. The value, in network byte order, 182 indicates the length of the PPPOE payload. It does not include the 183 length of the Ethernet or PPPOE headers. 185 5. Discovery Stage 187 There are four steps to the Discovery stage. When it completes, both 188 peers know the PPPOE SESSION_ID and the peer's Ethernet address, 189 which together define the PPPOE session uniquely. The steps consist 191 Evarts, Carrel [Page4] 192 of the Host broadcasting an Initiation packet, one or more Access 193 Concentrators sending Offer packets, the Host sending a unicast 194 Session Request packet and the selected Access Concentrator sending a 195 Confirmation packet. When the Host receives the Confirmation packet, 196 it may proceed to the PPP Session Stage. When the Access 197 Concentrator sends the Confirmation packet, it may proceed to the PPP 198 Session Stage. 200 All Discovery Ethernet frames have the ETHER_TYPE field set to the 201 value 0x8863. 203 The PPPOE payload contains zero or more tags. A tag is a TLV (type- 204 length-value) construct and is defined as follows: 206 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | TAG_TYPE | TAG_LENGTH | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | TAG_VALUE ... ~ 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 TAG_TYPE is a sixteen bit field in network byte order. Appendix A 215 contains a list of all TAG_TYPEs and their TAG_VALUEs. 217 TAG_LENGTH is a sixteen bit field. It is an unsigned number in 218 network byte order, indicating the length in octets of the TAG_VALUE. 220 Some example Discovery packets are shown in Appendix B. 222 5.1 The PPPOE Active Discovery Initiation (PADI) packet 224 The Host sends the PADI packet with the DESTINATION_ADDR set to the 225 broadcast address. The CODE field is set to 0x09 and the SESSION_ID 226 MUST be set to 0x0000. 228 The PADI packet contains exactly one tag of type Service-Name, 229 indicating the service the Host is requesting, and any number of 230 other tag types. 232 5.2 The PPPOE Active Discovery Offer (PADO) packet 234 When the Access Concentrator receives a PADI that it can serve, it 235 replies by sending a PADO packet. The DESTINATION_ADDR is the 236 unicast address of the Host that sent the PADI. The CODE field is 237 set to 0x07 and the SESSION_ID MUST be set to 0x0000. 239 The PADO packet MUST contain one AC-Name tag containing the Access 241 Evarts, Carrel [Page5] 242 Concentrator's name, a Service-Name tag identical to the one in the 243 PADI, and any number of other Service-Name tags indicating other 244 services that the Access Concentrator offers. If the Access 245 Concentrator can not serve the PADI it MUST NOT respond with a PADO. 247 5.3 The PPPOE Active Discovery Request (PADR) packet 249 Since the PADI was broadcast, the Host may receive more than one 250 PADO. The Host looks through the PADO packets it receives and 251 chooses one. The choice can be based on the AC-Name or the Services 252 offered. The Host then sends one PADR packet to the Access 253 Concentrator that it has chosen. The DESTINATION_ADDR field is set 254 to the unicast Ethernet address of the Access Concentrator that sent 255 the PADO. The CODE field is set to 0x19 and the SESSION_ID MUST be 256 set to 0x0000. 258 The PADR packet contains exactly one tag of type Service-Name, 259 indicating the service the Host is requesting, and any number of 260 other tag types. 262 5.4 The PPPOE Active Discovery Session-confirmation (PADS) packet 264 When the Access Concentrator receives a PADR packet, it prepares to 265 begin a PPP session. It generates a unique SESSION_ID for the PPPOE 266 session and replies to the Host with a PADS packet. The 267 DESTINATION_ADDR field is the unicast Ethernet address of the Host 268 that sent the PADR. The CODE field is set to 0x65 and the SESSION_ID 269 MUST be set to the unique value generated for this PPPOE session. 271 The PADS packet contains exactly one tag of type Service-Name, 272 indicating the service under which Access Concentrator has accepted 273 the PPPOE session, and any number of other tag types. 275 If the Access Concentrator does not like the Service-Name in the 276 PADR, then it MUST reply with a PADS containing a single tag of type 277 Service-Name-Error, and the SESSION_ID MUST be set to 0x0000. 279 6. PPP Session Stage 281 Once the PPPOE session begins, PPP data is sent as in any other PPP 282 encapsulation. All Ethernet packets are unicast. The ETHER_TYPE 283 field is set to 0x8864. The PPPOE CODE MUST be set to 0x00. The 284 SESSION_ID MUST NOT change for that PPPOE session and MUST be the 285 value assigned in the Discovery stage. The PPPOE payload contains a 286 PPP frame. The frame begins with the PPP Protocol-ID. 288 An example packet is shown in Appendix B. 290 Evarts, Carrel [Page6] 291 7. LCP Considerations 293 The Magic Number LCP configuration option is RECOMMENDED, and the 294 Protocol Field Compression (PFC) option is NOT RECOMMENDED. An 295 implementation MUST NOT request any of the following options, and 296 MUST reject a request for such an option: 298 Field Check Sequence (FCS) Alternatives, 300 Address-and-Control-Field-Compression (ACFC), 302 Asynchronous-Control-Character-Map (ACCM) 304 The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a 305 larger size than 1492. Since Ethernet has a maximum payload size of 306 1500 octets, the PPPOE header is 6 octets and the PPP Protocol ID is 307 2 octets, the PPP MTU MUST NOT be greater than 1492. 309 It is RECOMMENDED that the Access Concentrator ocassionally send 310 Echo-Request packets to the Host to determine the state of the 311 session. Otherwise, if the Host terminates a session without sending 312 a Terminate-Request packet, the Access Concentrator will not be able 313 to determine that the session has gone away. 315 When LCP terminates, the Host and Access concentrator MUST stop using 316 that PPPOE session. If the Host wishes to start another PPP session, 317 it MUST return to the PPPOE Discovery stage. 319 8. Other Considerations 321 When a host does not receive a PADO packet within a specified amount 322 of time, it SHOULD resend it's PADI packet and double the waiting 323 period. This is repeated as many times as desired. If the Host is 324 waiting to receive a PADS packet, a similar timeout mechanism SHOULD 325 be used, with the Host re-sending the PADR. After a specified number 326 of retries, the Host SHOULD then resend a PADI packet. 328 The ETHER_TYPEs used in this document (0x8863 and 0x8864) have been 329 assigned by the IEEE for use by PPP Over Ethernet (PPPOE). Use of 330 these values and the PPPOE VER (version) field uniquely identify this 331 protocol. 333 Evarts, Carrel [Page7] 334 9. Security Considerations 336 To help protect against Denial of Service (DOS) attacks, the Access 337 Concentrator can employ the AC-Cookie tag. The TAG_VALUE should be 338 something that the Access Concentrator can uniquely regenerate based 339 on the Host's MAC address. Using this, the Access Concentrator can 340 ensure that the Host MAC address used in the PADI is indeed reachable 341 and can then limit concurrent sessions for that address. What 342 algorithm to use is not defined and left as an implementation detail. 343 An example is HMAC [3] over the Host MAC address using a key known 344 only to the Access Concentrator. 346 While the AC-Cookie is useful against some DOS attacks, it can not 347 protect against all DOS attacks and an Access Concentrator MAY employ 348 other means to protect resources. 350 Many Access Concentrators will not wish to offer information 351 regarding what services they offer to an unauthenticated entity. In 352 that case the Access Concentrator should employ one of two policies. 353 It SHOULD never refuse a request based on the Service-Name tag, and 354 always return the TAG_VALUE that was sent to it. Or it SHOULD only 355 accept requests with a Service-Name tag with a zero TAG_LENGTH 356 (indicating any service). The former solution is RECOMMENDED. 358 10. Acknowledgments 360 This document is based on concepts discussed in several forums, 361 including the ADSL forum. 363 Copious amounts of text have been stolen from RFC 1661, RFC 1662 and 364 RFC 2364. 366 11. References 368 [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 369 07/21/1994 371 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 372 Levels", BCP 14, RFC 2119, March 1997. 374 [3] Krawczyk, H., Bellare, M., Canetti, R. "HMAC: Keyed-Hashing for 375 Message Authentication", RFC 2104, February 1998 377 [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 378 October 1994. 380 Evarts, Carrel [Page8] 381 Appendix A 383 TAG_TYPES and TAG_VALUES 385 0x0000 End-Of-List 387 This tag indicates that there are no further tags in the list. The 388 TAG_LENGTH of this tag MUST always be zero. Use of this tag is 389 not required, but remains for backwards compatibility. 391 0x0101 Service-Name 393 This tag indicates that a service name follows. The TAG_VALUE is 394 an ASCII string that is NOT NULL terminated. When the TAG_LENGTH 395 is zero this tag is used to indicate that any service is 396 acceptable. Examples of the use of the Service-Name tag are to 397 indicate an ISP name or a class or quality of service. 399 0x0102 AC-Name 401 This tag indicates that a string follows which uniquely identifies 402 this particular Access Concentrator unit from all others. It may 403 be a combination of trademark, model, and serial id information, 404 or simply an ascii rendition of the MAC address of the box. It is 405 not NULL terminated. 407 0x0103 Host-Uniq 409 This tag is used by a Host to uniquely associate an Access 410 Concentrator response (PADO or PADS) to a particular Host request 411 (PADI or PADR). The TAG_VALUE is binary data of any value and 412 length that the Host chooses. It is not interpreted by the Access 413 Concentrator. The Host MAY include a Host-Uniq tag in a PADI or 414 PADR. If the Access Concentrator receives this tag, it MUST 415 include the tag unmodified in the associated PADO or PADS 416 response. 418 0x0104 AC-Cookie 420 This tag is used by the Access Concentrator to aid in protecting 421 against denial of service attacks (see the Security Considerations 422 section for an explanation of how this works). The Access 423 Concentrator MAY include this tag in a PADO packet. If a Host 424 receives this tag, it MUST return the tag unmodified in the 425 following PADR. The TAG_VALUE is binary data of any value and 426 length and is not interpreted by the Host. 428 Evarts, Carrel [Page9] 429 0x0105 Vendor-Specific 431 This tag is used to pass vendor proprietary information. The 432 first four octets of the TAG_VALUE contain the vendor id and the 433 remainder is unspecified. The high-order octet of the vendor id 434 is 0 and the low-order 3 octets are the SMI Network Management 435 Private Enterprise Code of the Vendor in network byte order, as 436 defined in the Assigned Numbers RFC [4]. 438 Use of this tag is NOT RECOMMENDED. To ensure inter-operability, 439 an implementation MAY silently ignore a Vendor-Specific tag. 441 0x0201 Service-Name-Error 443 This tag (typically with a zero-length data section) indicates 444 that for one reason or another, the requested Service-Name request 445 could not be honored. 447 If there is data, and the first octet of the data is nonzero, then 448 it MUST be a printable ascii string which explains why the request 449 was denied. This string MAY NOT be NULL terminated. 451 0x0202 AC-System-Error 453 This tag indicates that the Access Concentrator experienced some 454 error in performing the Host request. (For example insufficient 455 resources to create a virtual circuit.) It MAY be included in 456 PADS packets. 458 If there is data, and the first octet of the data is nonzero, then 459 it MUST be a printable ascii string which explains the nature of 460 the error. This string MAY NOT be NULL terminated. 462 Evarts, Carrel [Page10] 463 Appendix B 465 The following are some example packets: 467 A PADI packet: 469 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | 0xffffffff | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | 0xffff | Host_mac_addr | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Host_mac_addr (cont) | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x09 | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | SESSION_ID = 0x0000 | LENGTH = 0x0004 | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 Evarts, Carrel [Page11] 486 A PADO packet: 488 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Host_mac_addr | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Host_mac_addr (cont) | Access_Concentrator_mac_addr | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Access_Concentrator_mac_addr (cont) | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x07 | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | SESSION_ID = 0x0000 | LENGTH = 0x0020 | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | TAG_TYPE = 0x0102 | TAG_LENGTH = 0x0018 | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | 0x47 | 0x6f | 0x20 | 0x52 | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | 0x65 | 0x64 | 0x42 | 0x61 | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | 0x63 | 0x6b | 0x20 | 0x2d | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | 0x20 | 0x65 | 0x73 | 0x68 | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | 0x73 | 0x68 | 0x65 | 0x73 | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | 0x68 | 0x6f | 0x6f | 0x74 | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 Evarts, Carrel [Page12] 519 A PPP LCP packet: The PPP protocol value is shown (0xc021) but the 520 PPP payload is left to the reader. This is a packet from the Host to 521 the Access Concentrator. 523 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Access_Concentrator_mac_addr | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 |Access_Concentrator_mac_addr(c)| Host_mac_addr | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Host_mac_addr (cont) | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | ETHER_TYPE = 0x8864 | v = 1 | t = 1 | CODE = 0x00 | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | SESSION_ID = 0x1234 | LENGTH = 0x???? | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | PPP PROTOCOL = 0xc021 | PPP payload ~ 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Authors' Addresses: 541 Louis Mamakos 542 Kurt Lidl 543 Jeff Evarts 544 UUNET Technologies, Inc. 545 3060 Williams Drive 546 Fairfax, VA 22031-4648 547 United States of America 549 David Carrel 550 Dan Simone 551 RedBack Networks, Inc. 552 1389 Moffett Park Drive 553 Sunnyvale, CA 94089-1134 554 United States of America 556 Ross Wheeler 557 RouterWare, Inc. 558 3961 MacArthur Blvd., Suite 212 559 Newport Beach, CA 92660 560 United States of America 562 Evarts, Carrel [Page13]