From 089a88ce93e203fa05b0bf649e3e8225213cb51b Mon Sep 17 00:00:00 2001 From: Theo de Raadt Date: Mon, 20 Dec 2004 19:53:40 +0000 Subject: RFC documents are not free enough --- usr.sbin/pppoe/rfc2516.txt | 955 --------------------------------------------- 1 file changed, 955 deletions(-) delete mode 100644 usr.sbin/pppoe/rfc2516.txt (limited to 'usr.sbin/pppoe') diff --git a/usr.sbin/pppoe/rfc2516.txt b/usr.sbin/pppoe/rfc2516.txt deleted file mode 100644 index 5397c863dc3..00000000000 --- a/usr.sbin/pppoe/rfc2516.txt +++ /dev/null @@ -1,955 +0,0 @@ - - - - - - -Network Working Group L. Mamakos -Request for Comments: 2516 K. Lidl -Category: Informational J. Evarts - UUNET Technologies, Inc. - D. Carrel - D. Simone - RedBack Networks, Inc. - R. Wheeler - RouterWare, Inc. - February 1999 - - - A Method for Transmitting PPP Over Ethernet (PPPoE) - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -Abstract - - The Point-to-Point Protocol (PPP) [1] provides a standard method for - transporting multi-protocol datagrams over point-to-point links. - - This document describes how to build PPP sessions and encapsulate PPP - packets over Ethernet. - -Applicability - - This specification is intended to provide the facilities which are - defined for PPP, such as the Link Control Protocol, Network-layer - Control Protocols, authentication, and more. These capabilities - require a point-to-point relationship between the peers, and are not - designed for the multi-point relationships which are available in - Ethernet and other multi-access environments. - - This specification can be used by multiple hosts on a shared, - Ethernet to open PPP sessions to multiple destinations via one or - more bridging modems. It is intended to be used with broadband - remote access technologies that provide a bridged Ethernet topology, - when access providers wish to maintain the session abstraction - associated with PPP. - - - - -Mamakos, et. al. Informational [Page 1] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - - This document describes the PPP Over Ethernet encapsulation that is - being deployed by RedBack Networks, RouterWare, UUNET and others. - -1. Introduction - - Modern access technologies are faced with several conflicting goals. - It is desirable to connect multiple hosts at a remote site through - the same customer premise access device. It is also a goal to - provide access control and billing functionality in a manner similar - to dial-up services using PPP. In many access technologies, the most - cost effective method to attach multiple hosts to the customer - premise access device, is via Ethernet. In addition, it is desirable - to keep the cost of this device as low as possible while requiring - little or no configuration. - - PPP over Ethernet (PPPoE) provides the ability to connect a network - of hosts over a simple bridging access device to a remote Access - Concentrator. With this model, each host utilizes it's own PPP stack - and the user is presented with a familiar user interface. Access - control, billing and type of service can be done on a per-user, - rather than a per-site, basis. - - To provide a point-to-point connection over Ethernet, each PPP - session must learn the Ethernet address of the remote peer, as well - as establish a unique session identifier. PPPoE includes a discovery - protocol that provides this. - -2. Conventions - - The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, - SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this - document, are to be interpreted as described in [2]. - -3. Protocol Overview - - PPPoE has two distinct stages. There is a Discovery stage and a PPP - Session stage. When a Host wishes to initiate a PPPoE session, it - must first perform Discovery to identify the Ethernet MAC address of - the peer and establish a PPPoE SESSION_ID. While PPP defines a - peer-to-peer relationship, Discovery is inherently a client-server - relationship. In the Discovery process, a Host (the client) - discovers an Access Concentrator (the server). Based on the network - topology, there may be more than one Access Concentrator that the - Host can communicate with. The Discovery stage allows the Host to - discover all Access Concentrators and then select one. When - Discovery completes successfully, both the Host and the selected - Access Concentrator have the information they will use to build their - point-to-point connection over Ethernet. - - - -Mamakos, et. al. Informational [Page 2] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - - The Discovery stage remains stateless until a PPP session is - established. Once a PPP session is established, both the Host and - the Access Concentrator MUST allocate the resources for a PPP virtual - interface. - -4. Payloads - - The following packet formats are defined here. The payload contents - will be defined in the Discovery and PPP sections. - - An Ethernet frame is as follows: - - 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DESTINATION_ADDR | - | (6 octets) | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SOURCE_ADDR | - | (6 octets) | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ETHER_TYPE (2 octets) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ ~ - ~ payload ~ - ~ ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | CHECKSUM | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The DESTINATION_ADDR field contains either a unicast Ethernet - destination address, or the Ethernet broadcast address (0xffffffff). - For Discovery packets, the value is either a unicast or broadcast - address as defined in the Discovery section. For PPP session - traffic, this field MUST contain the peer's unicast address as - determined from the Discovery stage. - - The SOURCE_ADDR field MUST contains the Ethernet MAC address of the - source device. - - The ETHER_TYPE is set to either 0x8863 (Discovery Stage) or 0x8864 - (PPP Session Stage). - - - - - - - -Mamakos, et. al. Informational [Page 3] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - - The Ethernet payload for PPPoE is as follows: - - 1 2 3 - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | VER | TYPE | CODE | SESSION_ID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LENGTH | payload ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The VER field is four bits and MUST be set to 0x1 for this version of - the PPPoE specification. - - The TYPE field is four bits and MUST be set to 0x1 for this version - of the PPPoE specification. - - The CODE field is eight bits and is defined below for the Discovery - and PPP Session stages. - - The SESSION_ID field is sixteen bits. It is an unsigned value in - network byte order. It's value is defined below for Discovery - packets. The value is fixed for a given PPP session and, in fact, - defines a PPP session along with the Ethernet SOURCE_ADDR and - DESTINATION_ADDR. A value of 0xffff is reserved for future use and - MUST NOT be used - - The LENGTH field is sixteen bits. The value, in network byte order, - indicates the length of the PPPoE payload. It does not include the - length of the Ethernet or PPPoE headers. - -5. Discovery Stage - - There are four steps to the Discovery stage. When it completes, both - peers know the PPPoE SESSION_ID and the peer's Ethernet address, - which together define the PPPoE session uniquely. The steps consist - of the Host broadcasting an Initiation packet, one or more Access - Concentrators sending Offer packets, the Host sending a unicast - Session Request packet and the selected Access Concentrator sending a - Confirmation packet. When the Host receives the Confirmation packet, - it may proceed to the PPP Session Stage. When the Access - Concentrator sends the Confirmation packet, it may proceed to the PPP - Session Stage. - - All Discovery Ethernet frames have the ETHER_TYPE field set to the - value 0x8863. - - - - - - -Mamakos, et. al. Informational [Page 4] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - - The PPPoE payload contains zero or more TAGs. A TAG is a TLV (type- - length-value) construct and is defined as follows: - - 1 2 3 - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TAG_TYPE | TAG_LENGTH | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TAG_VALUE ... ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - TAG_TYPE is a sixteen bit field in network byte order. Appendix A - contains a list of all TAG_TYPEs and their TAG_VALUEs. - - TAG_LENGTH is a sixteen bit field. It is an unsigned number in - network byte order, indicating the length in octets of the TAG_VALUE. - - If a discovery packet is received with a TAG of unknown TAG_TYPE, the - TAG MUST be ignored unless otherwise specified in this document. - This provides for backwards compatibility if/when new TAGs are added. - If new mandatory TAGs are added, the version number will be - incremented. - - Some example Discovery packets are shown in Appendix B. - -5.1 The PPPoE Active Discovery Initiation (PADI) packet - - The Host sends the PADI packet with the DESTINATION_ADDR set to the - broadcast address. The CODE field is set to 0x09 and the SESSION_ID - MUST be set to 0x0000. - - The PADI packet MUST contain exactly one TAG of TAG_TYPE Service- - Name, indicating the service the Host is requesting, and any number - of other TAG types. An entire PADI packet (including the PPPoE - header) MUST NOT exceed 1484 octets so as to leave sufficient room - for a relay agent to add a Relay-Session-Id TAG. - -5.2 The PPPoE Active Discovery Offer (PADO) packet - - When the Access Concentrator receives a PADI that it can serve, it - replies by sending a PADO packet. The DESTINATION_ADDR is the - unicast address of the Host that sent the PADI. The CODE field is - set to 0x07 and the SESSION_ID MUST be set to 0x0000. - - - - - - - - -Mamakos, et. al. Informational [Page 5] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - - The PADO packet MUST contain one AC-Name TAG containing the Access - Concentrator's name, a Service-Name TAG identical to the one in the - PADI, and any number of other Service-Name TAGs indicating other - services that the Access Concentrator offers. If the Access - Concentrator can not serve the PADI it MUST NOT respond with a PADO. - -5.3 The PPPoE Active Discovery Request (PADR) packet - - Since the PADI was broadcast, the Host may receive more than one - PADO. The Host looks through the PADO packets it receives and - chooses one. The choice can be based on the AC-Name or the Services - offered. The Host then sends one PADR packet to the Access - Concentrator that it has chosen. The DESTINATION_ADDR field is set - to the unicast Ethernet address of the Access Concentrator that sent - the PADO. The CODE field is set to 0x19 and the SESSION_ID MUST be - set to 0x0000. - - The PADR packet MUST contain exactly one TAG of TAG_TYPE Service- - Name, indicating the service the Host is requesting, and any number - of other TAG types. - -5.4 The PPPoE Active Discovery Session-confirmation (PADS) packet - - When the Access Concentrator receives a PADR packet, it prepares to - begin a PPP session. It generates a unique SESSION_ID for the PPPoE - session and replies to the Host with a PADS packet. The - DESTINATION_ADDR field is the unicast Ethernet address of the Host - that sent the PADR. The CODE field is set to 0x65 and the SESSION_ID - MUST be set to the unique value generated for this PPPoE session. - - The PADS packet contains exactly one TAG of TAG_TYPE Service-Name, - indicating the service under which Access Concentrator has accepted - the PPPoE session, and any number of other TAG types. - - If the Access Concentrator does not like the Service-Name in the - PADR, then it MUST reply with a PADS containing a TAG of TAG_TYPE - Service-Name-Error (and any number of other TAG types). In this case - the SESSION_ID MUST be set to 0x0000. - -5.5 The PPPoE Active Discovery Terminate (PADT) packet - - This packet may be sent anytime after a session is established to - indicate that a PPPoE session has been terminated. It may be sent by - either the Host or the Access Concentrator. The DESTINATION_ADDR - field is a unicast Ethernet address, the CODE field is set to 0xa7 - and the SESSION_ID MUST be set to indicate which session is to be - terminated. No TAGs are required. - - - - -Mamakos, et. al. Informational [Page 6] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - - When a PADT is received, no further PPP traffic is allowed to be sent - using that session. Even normal PPP termination packets MUST NOT be - sent after sending or receiving a PADT. A PPP peer SHOULD use the - PPP protocol itself to bring down a PPPoE session, but the PADT MAY - be used when PPP can not be used. - -6. PPP Session Stage - - Once the PPPoE session begins, PPP data is sent as in any other PPP - encapsulation. All Ethernet packets are unicast. The ETHER_TYPE - field is set to 0x8864. The PPPoE CODE MUST be set to 0x00. The - SESSION_ID MUST NOT change for that PPPoE session and MUST be the - value assigned in the Discovery stage. The PPPoE payload contains a - PPP frame. The frame begins with the PPP Protocol-ID. - - An example packet is shown in Appendix B. - -7. LCP Considerations - - The Magic Number LCP configuration option is RECOMMENDED, and the - Protocol Field Compression (PFC) option is NOT RECOMMENDED. An - implementation MUST NOT request any of the following options, and - MUST reject a request for such an option: - - Field Check Sequence (FCS) Alternatives, - - Address-and-Control-Field-Compression (ACFC), - - Asynchronous-Control-Character-Map (ACCM) - - The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a - larger size than 1492. Since Ethernet has a maximum payload size of - 1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is - 2 octets, the PPP MTU MUST NOT be greater than 1492. - - It is RECOMMENDED that the Access Concentrator ocassionally send - Echo-Request packets to the Host to determine the state of the - session. Otherwise, if the Host terminates a session without sending - a Terminate-Request packet, the Access Concentrator will not be able - to determine that the session has gone away. - - When LCP terminates, the Host and Access concentrator MUST stop using - that PPPoE session. If the Host wishes to start another PPP session, - it MUST return to the PPPoE Discovery stage. - - - - - - - -Mamakos, et. al. Informational [Page 7] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - -8. Other Considerations - - When a host does not receive a PADO packet within a specified amount - of time, it SHOULD resend it's PADI packet and double the waiting - period. This is repeated as many times as desired. If the Host is - waiting to receive a PADS packet, a similar timeout mechanism SHOULD - be used, with the Host re-sending the PADR. After a specified number - of retries, the Host SHOULD then resend a PADI packet. - - The ETHER_TYPEs used in this document (0x8863 and 0x8864) have been - assigned by the IEEE for use by PPP Over Ethernet (PPPoE). Use of - these values and the PPPoE VER (version) field uniquely identify this - protocol. - - UTF-8 [5] is used throughout this document instead of ASCII. UTF-8 - supports the entire ASCII character set while allowing for - international character sets as well. See [5] for more details. - -9. Security Considerations - - To help protect against Denial of Service (DOS) attacks, the Access - Concentrator can employ the AC-Cookie TAG. The Access Concentrator - SHOULD be able to uniquely regenerate the TAG_VALUE based on the PADR - SOURCE_ADDR. Using this, the Access Concentrator can ensure that the - PADI SOURCE_ADDR is indeed reachable and can then limit concurrent - sessions for that address. What algorithm to use is not defined and - left as an implementation detail. An example is HMAC [3] over the - Host MAC address using a key known only to the Access > Concentrator. - While the AC-Cookie is useful against some DOS attacks, it can not - protect against all DOS attacks and an Access Concentrator MAY employ - other means to protect resources. - - While the AC-Cookie is useful against some DOS attacks, it can not - protect against all DOS attacks and an Access Concentrator MAY employ - other means to protect resources. - - Many Access Concentrators will not wish to offer information - regarding what services they offer to an unauthenticated entity. In - that case the Access Concentrator should employ one of two policies. - It SHOULD never refuse a request based on the Service-Name TAG, and - always return the TAG_VALUE that was sent to it. Or it SHOULD only - accept requests with a Service-Name TAG with a zero TAG_LENGTH - (indicating any service). The former solution is RECOMMENDED. - -10. Acknowledgments - - This document is based on concepts discussed in several forums, - including the ADSL forum. - - - -Mamakos, et. al. Informational [Page 8] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - - Copious amounts of text have been stolen from RFC 1661, RFC 1662 and - RFC 2364. - -11. References - - [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, - RFC 1661, July 1994 - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [3] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing - for Message Authentication", RFC 2104, February 1998. - - [4] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, - October 1994. See also: http://www.iana.org/numbers.html - - [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC - 2279, January 1998. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Mamakos, et. al. Informational [Page 9] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - -Appendix A - - TAG_TYPES and TAG_VALUES - - 0x0000 End-Of-List - - This TAG indicates that there are no further TAGs in the list. The - TAG_LENGTH of this TAG MUST always be zero. Use of this TAG is - not required, but remains for backwards compatibility. - - 0x0101 Service-Name - - This TAG indicates that a service name follows. The TAG_VALUE is - an UTF-8 string that is NOT NULL terminated. When the TAG_LENGTH - is zero this TAG is used to indicate that any service is - acceptable. Examples of the use of the Service-Name TAG are to - indicate an ISP name or a class or quality of service. - - 0x0102 AC-Name - - This TAG indicates that a string follows which uniquely identifies - this particular Access Concentrator unit from all others. It may - be a combination of trademark, model, and serial id information, - or simply an UTF-8 rendition of the MAC address of the box. It is - not NULL terminated. - - 0x0103 Host-Uniq - - This TAG is used by a Host to uniquely associate an Access - Concentrator response (PADO or PADS) to a particular Host request - (PADI or PADR). The TAG_VALUE is binary data of any value and - length that the Host chooses. It is not interpreted by the Access - Concentrator. The Host MAY include a Host-Uniq TAG in a PADI or - PADR. If the Access Concentrator receives this TAG, it MUST - include the TAG unmodified in the associated PADO or PADS - response. - - 0x0104 AC-Cookie - - This TAG is used by the Access Concentrator to aid in protecting - against denial of service attacks (see the Security Considerations - section for an explanation of how this works). The Access - Concentrator MAY include this TAG in a PADO packet. If a Host - receives this TAG, it MUST return the TAG unmodified in the - following PADR. The TAG_VALUE is binary data of any value and - length and is not interpreted by the Host. - - - - - -Mamakos, et. al. Informational [Page 10] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - - 0x0105 Vendor-Specific - - This TAG is used to pass vendor proprietary information. The - first four octets of the TAG_VALUE contain the vendor id and the - remainder is unspecified. The high-order octet of the vendor id - is 0 and the low-order 3 octets are the SMI Network Management - Private Enterprise Code of the Vendor in network byte order, as - defined in the Assigned Numbers RFC [4]. - - Use of this TAG is NOT RECOMMENDED. To ensure inter-operability, - an implementation MAY silently ignore a Vendor-Specific TAG. - - 0x0110 Relay-Session-Id - - This TAG MAY be added to any discovery packet by an intermediate - agent that is relaying traffic. The TAG_VALUE is opaque to both - the Host and the Access Concentrator. If either the Host or - Access Concentrator receives this TAG they MUST include it - unmodified in any discovery packet they send as a response. All - PADI packets MUST guarantee sufficient room for the addition of a - Relay-Session-Id TAG with a TAG_VALUE length of 12 octets. - - A Relay-Session-Id TAG MUST NOT be added if the discovery packet - already contains one. In that case the intermediate agent SHOULD - use the existing Relay-Session-Id TAG. If it can not use the - existing TAG or there is insufficient room to add a Relay- - Session-Id TAG, then it SHOULD return a Generic-Error TAG to the - sender. - - 0x0201 Service-Name-Error - - This TAG (typically with a zero-length data section) indicates - that for one reason or another, the requested Service-Name request - could not be honored. - - If there is data, and the first octet of the data is nonzero, then - it MUST be a printable UTF-8 string which explains why the request - was denied. This string MAY NOT be NULL terminated. - - 0x0202 AC-System-Error - - This TAG indicates that the Access Concentrator experienced some - error in performing the Host request. (For example insufficient - resources to create a virtual circuit.) It MAY be included in - PADS packets. - - - - - - -Mamakos, et. al. Informational [Page 11] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - - If there is data, and the first octet of the data is nonzero, then - it MUST be a printable UTF-8 string which explains the nature of - the error. This string MAY NOT be NULL terminated. - - 0x0203 Generic-Error - - This TAG indicates an error. It can be added to PADO, PADR or - PADS packets when an unrecoverable error occurs and no other error - TAG is appropriate. If there is data then it MUST be an UTF-8 - string which explains the nature of the error. This string MUST - NOT be NULL terminated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Mamakos, et. al. Informational [Page 12] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - -Appendix B - - The following are some example packets: - - A PADI packet: - - 1 2 3 - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 0xffffffff | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 0xffff | Host_mac_addr | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Host_mac_addr (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x09 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SESSION_ID = 0x0000 | LENGTH = 0x0004 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Mamakos, et. al. Informational [Page 13] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - - A PADO packet: - - 1 2 3 - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Host_mac_addr | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Host_mac_addr (cont) | Access_Concentrator_mac_addr | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Access_Concentrator_mac_addr (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x07 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SESSION_ID = 0x0000 | LENGTH = 0x0020 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TAG_TYPE = 0x0102 | TAG_LENGTH = 0x0018 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 0x47 | 0x6f | 0x20 | 0x52 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 0x65 | 0x64 | 0x42 | 0x61 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 0x63 | 0x6b | 0x20 | 0x2d | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 0x20 | 0x65 | 0x73 | 0x68 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 0x73 | 0x68 | 0x65 | 0x73 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 0x68 | 0x6f | 0x6f | 0x74 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - - - - - - - - - - -Mamakos, et. al. Informational [Page 14] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - - A PPP LCP packet: The PPP protocol value is shown (0xc021) but the - PPP payload is left to the reader. This is a packet from the Host to - the Access Concentrator. - - 1 2 3 - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Access_Concentrator_mac_addr | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |Access_Concentrator_mac_addr(c)| Host_mac_addr | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Host_mac_addr (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ETHER_TYPE = 0x8864 | v = 1 | t = 1 | CODE = 0x00 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SESSION_ID = 0x1234 | LENGTH = 0x???? | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | PPP PROTOCOL = 0xc021 | PPP payload ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -Authors' Addresses - - Louis Mamakos - UUNET Technologies, Inc. - 3060 Williams Drive - Fairfax, VA 22031-4648 - United States of America - - EMail: louie@uu.net - - - Kurt Lidl - UUNET Technologies, Inc. - 3060 Williams Drive - Fairfax, VA 22031-4648 - United States of America - - EMail: lidl@uu.net - - - Jeff Evarts - UUNET Technologies, Inc. - 3060 Williams Drive - Fairfax, VA 22031-4648 - United States of America - - EMail: jde@uu.net - - - - -Mamakos, et. al. Informational [Page 15] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - - David Carrel - RedBack Networks, Inc. - 1389 Moffett Park Drive - Sunnyvale, CA 94089-1134 - United States of America - - EMail: carrel@RedBack.net - - - Dan Simone - RedBack Networks, Inc. - 1389 Moffett Park Drive - Sunnyvale, CA 94089-1134 - United States of America - - EMail:dan@RedBack.net - - - Ross Wheeler - RouterWare, Inc. - 3961 MacArthur Blvd., Suite 212 - Newport Beach, CA 92660 - United States of America - - EMail: ross@routerware.com - - - - - - - - - - - - - - - - - - - - - - - - - - -Mamakos, et. al. Informational [Page 16] - -RFC 2516 Transmitting PPP Over Ethernet February 1999 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Mamakos, et. al. Informational [Page 17] - -- cgit v1.2.3