PPP Working Group David Carrel, Dan Simone, INTERNET DRAFT Che-Lin Ho, Tom Stoner Category: Informational Redback Networks, Inc. Title: draft-carrel-info-pppoe-ext-00.txt Date: May 2000 Extensions to a Method for Transmitting PPP Over Ethernet (PPPoE) <draft-carrel-info-pppoe-ext-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The distribution of this memo is unlimited. It is filed as <draft- carrel-info-pppoe-ext-00.txt>, and expires 30 November, 2000. Please send comments to the authors. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPPoE [2] describes how to build PPP sessions and encapsulate PPP packets over Ethernet. This document describes extensions to PPPoE. These extensions provide added functionality, but are optional and preserve compatibility. Carrel [Page1] INTERNET DRAFT May 2000 1. Introduction PPP over Ethernet (PPPoE) [2] provides the ability to connect a network of hosts over a simple Ethernet 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. The flexibility provided by PPPoE has inspired the development of several extensions to the protocol. These extensions provide for networking level enhancements as well as session level enhancements aimed at the user experience. These enhancements maintain backwards compatibility with the core PPPoE protocol. 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 [3]. 3. Discovery Stage The PADI, PADO, PADR, PADS and PADT defined in [2] are unchanged. The following discovery packets have been added. Since this is the Discovery Stage, an ETHER_TYPE of 0x8863 MUST be used. 3.1 The PPPoE Active Discovery Message (PADM) packet An Access Concentrator MAY send a PADM at any time while a session is active to convey informational messages to the Host. The DESTINATION_ADDR is the unicast address of the Host. The CODE field is set to 0xd3 and the SESSION_ID MUST be set to the current (active) SESSION_ID value. Use of this packet is optional for both the Access Concentrator and the Host. A PADM packet MUST contain at least one TAG of type HURL or MOTM and SHOULD NOT contain any other TAGs. Additional messaging TAGs may be defined in the future that are appropriate for PADM packets. Carrel [Page2] INTERNET DRAFT May 2000 3.2 The PPPoE Active Discovery Network (PADN) packet An Access Concentrator MAY send a PADN at any time while a session is active to convey network level information to the Host. The DESTINATION_ADDR is the unicast address of the Host. The CODE field is set to 0xd4 and the SESSION_ID MUST be set to the current (active) SESSION_ID value. An Access Concentrator SHOULD send a PADN as soon as possible after an NCP completes negotiation. That PADN SHOULD only contain TAGs that are appropriate for that NCP. Since there is no limit on the number of PADNs that may be sent, it is appropriate to send a PADN for each NCP. Use of this packet is optional for both the Access Concentrator and the Host, though in general it is expected that it will only be sent by the Access Concentrator. A PADN packet MUST contain at least one TAG of type IP_ROUTE_ADD and SHOULD NOT contain any other TAGs. Additional network TAGs may be defined in the future that are appropriate for PADN packets. 4. PPPoE Clarifications Since publication of [2], discussions have taken place which have identified some areas of ambiguity. To avoid confusion and inter- operability problems, we are providing further clarification. This is a clarification of [2] and does not change [2] in any way. Carrel [Page3] INTERNET DRAFT May 2000 4.1 Service Selection Service Selection is a key feature of PPPoE. It allows for the Host to request a specific service and it also allows for the Access Concentrator to "advertise" a list of services. Service Selection is optional, but if the Host and Access Concentrator wish to participate in it, they should operate as indicated below. User Interface (UI) issues are discussed as well. If either the Host or Access Concentrator does not wish to participate in Service Selection, then they SHOULD use a Service-Name TAG with zero length, indicating that any service is acceptable. This can be done in the PADI, PADO, PADR and PADS packets to indicate that PPPoE Service Selection is not being used and PPP authentication should be used to determine the user's "service". In this case, no UI is needed beyond the PPP UI. Occasionally the Host will know in advance that it wishes to use a specific PPPoE Service. In that case, it MAY put that service in a Service-Name TAG in both the PADI and PADR. For this case, the UI should allow the Service-Name to be specified prior to beginning PPPoE Discovery. Our anticipation is that this case will be very rare. Since PPPoE has no security, Service Selection should be considered informational. PPP Authentication can be trusted and should be used to identify the user when there is no desire to "discover" services. Dynamic Service Selection happens when the Host wishes to "discover" what services are out there. The Host does not put a specific Service-Name value in the PADI and waits for a list of Service-Name TAGs from the Access Concentrator(s). This is accomplished by sending a PADI with a zero length Service-Name TAG. This indicates that the Host is trying to discover all services that are available. Each Access-Concentrator MAY then reply with a PADO listing multiple services. If the Host is capable of doing Service Selection, it SHOULD send a PADI and receive the PADO(s) before accepting any user input. It SHOULD then present the list of Services to the user and wait for the user to select one prior to sending the PADR. The PADR is the point where the Host "selects" its service. The UI should display the list of discovered Services. As an added value, it could remember commonly chosen Services and could even remember the last PPP username used for each Service. The Host MUST remember which Access Concentrator sent which Service-Name TAGs so that the PADR is sent to the correct Access Concentrator. Carrel [Page4] INTERNET DRAFT May 2000 5. PPP Considerations PADM packets SHOULD be sent after PPP authentication has completed in order to provide per-user messaging. Also PADM packets containing HURL TAGs SHOULD be sent after an NCP is established so that network connectivity is available for the web browser. However a Host implementation MUST be able to receive one at any time after PPPoE session establishment. 6. Security Considerations All data confidentiality and authenticity issues are left to higher layers such as PPP or IP. As such, any information sent in a PADM packet can not be protected. To present data to a user in a secure manner, HURLs can be used to establish a connection over higher layers that do provide security. Service Selection is NOT secure and should only be used informationally. 7. Acknowledgments Copious amounts of text were stolen from RFC 2516. 8. References [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994 [2] Mamakos, et. al., "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [5] Berners-Lee, T., Masinter, L., and McCahill, M. "Uniform Resource Locators (URL)", RFC 1738, December 1994 Carrel [Page5] INTERNET DRAFT May 2000 Appendix A TAG_TYPES and TAG_VALUES 0x0111 HURL This TAG MAY be added to PADM packets by the Access Concentrator. It contains a URL that the Host MAY pass to a web browser for presentation to the user. The TAG_VALUE contains a standard URL [5]. It is an UTF-8 string which is not NULL terminated. 0x0112 MOTM This TAG MAY be added to PADM packets by the Access Concentrator. It contains a Message Of The Minute (MOTM) that the Host MAY display to the user. The TAG_VALUE contains an UTF-8 string which is not NULL terminated. It is a text message that is presentable to the user on the Host. 0x0121 IP_ROUTE_ADD This TAG MAY be added to PADN packets by the Access Concentrator. It contains a IP route that MAY be used by the Host to populate it's routing table. The behavior of PPP is not defined in terms of what routes should be installed if multiple concurrent PPP sessions exist. Many client implementations will install a default route but that only works if one PPP session is active. When multiple PPPoE sessions are active, the IP_ROUTE_ADD TAG can provide a more granular set of routes to the client. The TAG_VALUE contains four 32 bit integers in network byte order. The first integer contains a destination network number and the second contains a destination network mask. The third integer contains the gateway IP address. The fourth integer contains a metric value. The destination of the route is always assumed to be the remote end of the PPP link. If the first two integers are zero this indicates a default route. In general the gateway IP address will be the same as the Access Concentrator's IP address on that PPP session, because use of this tag is only intended to provide routing information about the first hop (ie. which PPP interface the client should use). Any routes installed as a result of the IP_ROUTE_ADD TAG being received, SHOULD be removed when the PPPoE session terminates. Carrel [Page6] INTERNET DRAFT May 2000 Appendix B The following are some example packets: A PADM 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 = 0xd3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SESSION_ID = 0xNNNN | LENGTH = 0x001a | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAG_TYPE = 0x0111 | TAG_LENGTH = 0x0016 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x68 | 0x74 | 0x74 | 0x70 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x3a | 0x2f | 0x2f | 0x77 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x77 | 0x77 | 0x2e | 0x72 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x65 | 0x64 | 0x62 | 0x61 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x63 | 0x6b | 0x2e | 0x63 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x6f | 0x6d | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Carrel [Page7] INTERNET DRAFT May 2000 A PADN packet: This contains two IP_ROUTE_ADD TAGs. The first is the route "10.1.1.0 255.255.255.0". The second is "20.2.0.0 255.255.0.0". The Access Concentrator's IP address for the PPPoE session is 10.1.1.1. 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 = 0xd4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SESSION_ID = 0xNNNN | LENGTH = 0x0028 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAG_TYPE = 0x0121 | TAG_LENGTH = 0x0010 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0a010100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xffffff00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0a010101 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00000001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAG_TYPE = 0x0121 | TAG_LENGTH = 0x0010 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x14020000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xffff0000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0a010101 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00000001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Carrel [Page8] INTERNET DRAFT May 2000 Authors' Addresses: David Carrel <carrel@redback.com> Dan Simone <dan@redback.com> Che-Lin Ho <che@redback.com> Tom Stoner <tstoner@redback.com> Redback Networks, Inc. 350 Holger Way San Jose, CA 95134 United States of America Carrel [Page9]