idnits 2.17.1 draft-carrel-info-pppoe-02.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-24) 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 14 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-02.txt RedBack Networks, Inc. 6 Date: November 1998 Ross Wheeler 7 RouterWare, Inc. 9 A Method for Transmitting 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 May, 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 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 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 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 Carrel [Page4] 186 5. Discovery Stage 188 There are four steps to the Discovery stage. When it completes, both 189 peers know the PPPoE SESSION_ID and the peer's Ethernet address, 190 which together define the PPPoE session uniquely. The steps consist 191 of the Host broadcasting an Initiation packet, one or more Access 192 Concentrators sending Offer packets, the Host sending a unicast 193 Session Request packet and the selected Access Concentrator sending a 194 Confirmation packet. When the Host receives the Confirmation packet, 195 it may proceed to the PPP Session Stage. When the Access 196 Concentrator sends the Confirmation packet, it may proceed to the PPP 197 Session Stage. 199 All Discovery Ethernet frames have the ETHER_TYPE field set to the 200 value 0x8863. 202 The PPPoE payload contains zero or more TAGs. A TAG is a TLV (type- 203 length-value) construct and is defined as follows: 205 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | TAG_TYPE | TAG_LENGTH | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | TAG_VALUE ... ~ 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 TAG_TYPE is a sixteen bit field in network byte order. Appendix A 214 contains a list of all TAG_TYPEs and their TAG_VALUEs. 216 TAG_LENGTH is a sixteen bit field. It is an unsigned number in 217 network byte order, indicating the length in octets of the TAG_VALUE. 219 If a discovery packet is received with a TAG of unknown TAG_TYPE, the 220 TAG MUST be ignored unless otherwise specified in this document. 221 This provides for backwards compatibility if/when new TAGs are added. 222 If new mandatory TAGs are added, the version number will be 223 incremented. 225 Some example Discovery packets are shown in Appendix B. 227 Carrel [Page5] 228 5.1 The PPPoE Active Discovery Initiation (PADI) packet 230 The Host sends the PADI packet with the DESTINATION_ADDR set to the 231 broadcast address. The CODE field is set to 0x09 and the SESSION_ID 232 MUST be set to 0x0000. 234 The PADI packet MUST contain exactly one TAG of TAG_TYPE Service- 235 Name, indicating the service the Host is requesting, and any number 236 of other TAG types. An entire PADI packet (including the PPPoE 237 header) MUST NOT exceed 1484 octets so as to leave sufficient room 238 for a relay agent to add a Relay-Session-Id TAG. 240 5.2 The PPPoE Active Discovery Offer (PADO) packet 242 When the Access Concentrator receives a PADI that it can serve, it 243 replies by sending a PADO packet. The DESTINATION_ADDR is the 244 unicast address of the Host that sent the PADI. The CODE field is 245 set to 0x07 and the SESSION_ID MUST be set to 0x0000. 247 The PADO packet MUST contain one AC-Name TAG containing the Access 248 Concentrator's name, a Service-Name TAG identical to the one in the 249 PADI, and any number of other Service-Name TAGs indicating other 250 services that the Access Concentrator offers. If the Access 251 Concentrator can not serve the PADI it MUST NOT respond with a PADO. 253 5.3 The PPPoE Active Discovery Request (PADR) packet 255 Since the PADI was broadcast, the Host may receive more than one 256 PADO. The Host looks through the PADO packets it receives and 257 chooses one. The choice can be based on the AC-Name or the Services 258 offered. The Host then sends one PADR packet to the Access 259 Concentrator that it has chosen. The DESTINATION_ADDR field is set 260 to the unicast Ethernet address of the Access Concentrator that sent 261 the PADO. The CODE field is set to 0x19 and the SESSION_ID MUST be 262 set to 0x0000. 264 The PADR packet MUST contain exactly one TAG of TAG_TYPE Service- 265 Name, indicating the service the Host is requesting, and any number 266 of other TAG types. 268 5.4 The PPPoE Active Discovery Session-confirmation (PADS) packet 270 When the Access Concentrator receives a PADR packet, it prepares to 271 begin a PPP session. It generates a unique SESSION_ID for the PPPoE 272 session and replies to the Host with a PADS packet. The 273 DESTINATION_ADDR field is the unicast Ethernet address of the Host 274 that sent the PADR. The CODE field is set to 0x65 and the SESSION_ID 275 MUST be set to the unique value generated for this PPPoE session. 277 Carrel [Page6] 278 The PADS packet contains exactly one TAG of TAG_TYPE Service-Name, 279 indicating the service under which Access Concentrator has accepted 280 the PPPoE session, and any number of other TAG types. 282 If the Access Concentrator does not like the Service-Name in the 283 PADR, then it MUST reply with a PADS containing a TAG of TAG_TYPE 284 Service-Name-Error (and any number of other TAG types). In this case 285 the SESSION_ID MUST be set to 0x0000. 287 6. PPP Session Stage 289 Once the PPPoE session begins, PPP data is sent as in any other PPP 290 encapsulation. All Ethernet packets are unicast. The ETHER_TYPE 291 field is set to 0x8864. The PPPoE CODE MUST be set to 0x00. The 292 SESSION_ID MUST NOT change for that PPPoE session and MUST be the 293 value assigned in the Discovery stage. The PPPoE payload contains a 294 PPP frame. The frame begins with the PPP Protocol-ID. 296 An example packet is shown in Appendix B. 298 Carrel [Page7] 299 7. LCP Considerations 301 The Magic Number LCP configuration option is RECOMMENDED, and the 302 Protocol Field Compression (PFC) option is NOT RECOMMENDED. An 303 implementation MUST NOT request any of the following options, and 304 MUST reject a request for such an option: 306 Field Check Sequence (FCS) Alternatives, 308 Address-and-Control-Field-Compression (ACFC), 310 Asynchronous-Control-Character-Map (ACCM) 312 The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a 313 larger size than 1492. Since Ethernet has a maximum payload size of 314 1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is 315 2 octets, the PPP MTU MUST NOT be greater than 1492. 317 It is RECOMMENDED that the Access Concentrator ocassionally send 318 Echo-Request packets to the Host to determine the state of the 319 session. Otherwise, if the Host terminates a session without sending 320 a Terminate-Request packet, the Access Concentrator will not be able 321 to determine that the session has gone away. 323 When LCP terminates, the Host and Access concentrator MUST stop using 324 that PPPoE session. If the Host wishes to start another PPP session, 325 it MUST return to the PPPoE Discovery stage. 327 8. Other Considerations 329 When a host does not receive a PADO packet within a specified amount 330 of time, it SHOULD resend it's PADI packet and double the waiting 331 period. This is repeated as many times as desired. If the Host is 332 waiting to receive a PADS packet, a similar timeout mechanism SHOULD 333 be used, with the Host re-sending the PADR. After a specified number 334 of retries, the Host SHOULD then resend a PADI packet. 336 The ETHER_TYPEs used in this document (0x8863 and 0x8864) have been 337 assigned by the IEEE for use by PPP Over Ethernet (PPPoE). Use of 338 these values and the PPPoE VER (version) field uniquely identify this 339 protocol. 341 Carrel [Page8] 342 9. Security Considerations 344 To help protect against Denial of Service (DOS) attacks, the Access 345 Concentrator can employ the AC-Cookie TAG. The TAG_VALUE should be 346 something that the Access Concentrator can uniquely regenerate based 347 on the Host's MAC address. Using this, the Access Concentrator can 348 ensure that the Host MAC address used in the PADI is indeed reachable 349 and can then limit concurrent sessions for that address. What 350 algorithm to use is not defined and left as an implementation detail. 351 An example is HMAC [3] over the Host MAC address using a key known 352 only to the Access Concentrator. 354 While the AC-Cookie is useful against some DOS attacks, it can not 355 protect against all DOS attacks and an Access Concentrator MAY employ 356 other means to protect resources. 358 Many Access Concentrators will not wish to offer information 359 regarding what services they offer to an unauthenticated entity. In 360 that case the Access Concentrator should employ one of two policies. 361 It SHOULD never refuse a request based on the Service-Name TAG, and 362 always return the TAG_VALUE that was sent to it. Or it SHOULD only 363 accept requests with a Service-Name TAG with a zero TAG_LENGTH 364 (indicating any service). The former solution is RECOMMENDED. 366 10. Acknowledgments 368 This document is based on concepts discussed in several forums, 369 including the ADSL forum. 371 Copious amounts of text have been stolen from RFC 2153, RFC 1662 and 372 RFC 2364. 374 11. References 376 [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 2153, May 377 1997 379 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 380 Levels", BCP 14, RFC 2119, March 1997. 382 [3] Krawczyk, H., Bellare, M., Canetti, R. "HMAC: Keyed-Hashing for 383 Message Authentication", RFC 2104, February 1998 385 [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 386 October 1994. 388 Carrel [Page9] 389 Appendix A 391 TAG_TYPES and TAG_VALUES 393 0x0000 End-Of-List 395 This TAG indicates that there are no further TAGs in the list. The 396 TAG_LENGTH of this TAG MUST always be zero. Use of this TAG is 397 not required, but remains for backwards compatibility. 399 0x0101 Service-Name 401 This TAG indicates that a service name follows. The TAG_VALUE is 402 an ASCII string that is NOT NULL terminated. When the TAG_LENGTH 403 is zero this TAG is used to indicate that any service is 404 acceptable. Examples of the use of the Service-Name TAG are to 405 indicate an ISP name or a class or quality of service. 407 0x0102 AC-Name 409 This TAG indicates that a string follows which uniquely identifies 410 this particular Access Concentrator unit from all others. It may 411 be a combination of trademark, model, and serial id information, 412 or simply an ascii rendition of the MAC address of the box. It is 413 not NULL terminated. 415 0x0103 Host-Uniq 417 This TAG is used by a Host to uniquely associate an Access 418 Concentrator response (PADO or PADS) to a particular Host request 419 (PADI or PADR). The TAG_VALUE is binary data of any value and 420 length that the Host chooses. It is not interpreted by the Access 421 Concentrator. The Host MAY include a Host-Uniq TAG in a PADI or 422 PADR. If the Access Concentrator receives this TAG, it MUST 423 include the TAG unmodified in the associated PADO or PADS 424 response. 426 0x0104 AC-Cookie 428 This TAG is used by the Access Concentrator to aid in protecting 429 against denial of service attacks (see the Security Considerations 430 section for an explanation of how this works). The Access 431 Concentrator MAY include this TAG in a PADO packet. If a Host 432 receives this TAG, it MUST return the TAG unmodified in the 433 following PADR. The TAG_VALUE is binary data of any value and 434 length and is not interpreted by the Host. 436 Carrel [Page10] 437 0x0105 Vendor-Specific 439 This TAG is used to pass vendor proprietary information. The 440 first four octets of the TAG_VALUE contain the vendor id and the 441 remainder is unspecified. The high-order octet of the vendor id 442 is 0 and the low-order 3 octets are the SMI Network Management 443 Private Enterprise Code of the Vendor in network byte order, as 444 defined in the Assigned Numbers RFC [4]. 446 Use of this TAG is NOT RECOMMENDED. To ensure inter-operability, 447 an implementation MAY silently ignore a Vendor-Specific TAG. 449 0x0110 Relay-Session-Id 451 This TAG MAY be added to any discovery packet by a intermediate 452 agent that is relaying traffic. The TAG_VALUE is opaque to both 453 the Host and the Access Concentrator. If either the Host or 454 Access Concentrator receives this TAG they MUST include it 455 unmodified in any discovery packet they send as a response. All 456 PADI packets MUST guarantee sufficient room for the addition of a 457 Relay-Session-Id TAG with a TAG_VALUE length of 12 octets. 459 0x0201 Service-Name-Error 461 This TAG (typically with a zero-length data section) indicates 462 that for one reason or another, the requested Service-Name request 463 could not be honored. 465 If there is data, and the first octet of the data is nonzero, then 466 it MUST be a printable ascii string which explains why the request 467 was denied. This string MAY NOT be NULL terminated. 469 0x0202 AC-System-Error 471 This TAG indicates that the Access Concentrator experienced some 472 error in performing the Host request. (For example insufficient 473 resources to create a virtual circuit.) It MAY be included in 474 PADS packets. 476 If there is data, and the first octet of the data is nonzero, then 477 it MUST be a printable ascii string which explains the nature of 478 the error. This string MAY NOT be NULL terminated. 480 Carrel [Page11] 481 Appendix B 483 The following are some example packets: 485 A PADI packet: 487 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | 0xffffffff | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | 0xffff | Host_mac_addr | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Host_mac_addr (cont) | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x09 | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | SESSION_ID = 0x0000 | LENGTH = 0x0004 | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Carrel [Page12] 504 A PADO packet: 506 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Host_mac_addr | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Host_mac_addr (cont) | Access_Concentrator_mac_addr | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Access_Concentrator_mac_addr (cont) | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x07 | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | SESSION_ID = 0x0000 | LENGTH = 0x0020 | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | TAG_TYPE = 0x0102 | TAG_LENGTH = 0x0018 | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | 0x47 | 0x6f | 0x20 | 0x52 | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | 0x65 | 0x64 | 0x42 | 0x61 | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | 0x63 | 0x6b | 0x20 | 0x2d | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | 0x20 | 0x65 | 0x73 | 0x68 | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | 0x73 | 0x68 | 0x65 | 0x73 | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | 0x68 | 0x6f | 0x6f | 0x74 | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Carrel [Page13] 537 A PPP LCP packet: The PPP protocol value is shown (0xc021) but the 538 PPP payload is left to the reader. This is a packet from the Host to 539 the Access Concentrator. 541 1 2 3 542 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Access_Concentrator_mac_addr | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 |Access_Concentrator_mac_addr(c)| Host_mac_addr | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Host_mac_addr (cont) | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | ETHER_TYPE = 0x8864 | v = 1 | t = 1 | CODE = 0x00 | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | SESSION_ID = 0x1234 | LENGTH = 0x???? | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | PPP PROTOCOL = 0xc021 | PPP payload ~ 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Authors' Addresses: 559 Louis Mamakos 560 Kurt Lidl 561 Jeff Evarts 562 UUNET Technologies, Inc. 563 3060 Williams Drive 564 Fairfax, VA 22031-4648 565 United States of America 567 David Carrel 568 Dan Simone 569 RedBack Networks, Inc. 570 1389 Moffett Park Drive 571 Sunnyvale, CA 94089-1134 572 United States of America 574 Ross Wheeler 575 RouterWare, Inc. 576 3961 MacArthur Blvd., Suite 212 577 Newport Beach, CA 92660 578 United States of America 580 Carrel [Page14]