Network Working Group Reinaldo Penno Internet-Draft Nortel Networks Expires: October, 2001 David F. Skoll Roaring Penguin April, 2001 PPPoE Extensions For Seamless Service Selection draft-penno-pppoe-ext-service-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract In the year following the publication of the PPPoE protocol much operational experience and customer feedback was gathered. One problem that access providers usually mention is that in order for users to change ISPs or Service they need to manually disconnect and reconnect their PPPoE client. We propose here a extension to the PPPoE protocol in which through a new packet type a access concentrator can request a PPPoE client to disconnect and reconnect to a new ISP or Service in a manner transparent to the user Penno, R. [Page 1] Internet-Draft draft-penno-pppoe-ext-service-01.txt February,2001 Specification of Requirements 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 RFC 2119 [1]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction to the PPPoE Protocol. . . . . . . . . . . . .3 3. AC-Address TAG_TYPE and TAG_VALUE. . . . . . . . . . . . . 3 4. The PPPoE Active Service Change (PADC) packet . . . . . . .3 5. Deployment Examples. . . . . . . . . . . . . . . . . . . . 4 6. Compatibility with previous PPPoE Clients. . . . . . . . . 5 7. Security Considerations. . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . 5 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . 5 Full Copyright Statement. . . . . . . . . . . . . . . . . .6 Penno, R. [Page 2] Internet-Draft draft-penno-pppoe-ext-service-01.txt February,2001 1. Introduction In the year following the publication of the PPPoE protocol much operational experience and customer feedback was gathered. One problem that access providers usually mention is that in order for users to change ISPs or Service they need to manually disconnect and reconnect their PPPoE client. We propose here a extension to the PPPoE protocol in which through a new packet type a access concentrator can request a PPPoE client to disconnect and reconnect to a new ISP, Service or Device in a manner transparent to the user. 2. Introduction to the PPPoE Protocol The PPPoE protocol is relatively new, but its basic function is to encapsulate PPP packets into Ethernet frames that will be de- encapsulated by the tunnel termination device. The PPPoE protocol has two stages; session and discover. PPP session packets are encapsulated in the Ethernet frame with the Ethertype equal to 0x8864. The Ethertype 0x8863 is used during the discovering stage, where the user's PPPoE client tries to identify the device that will terminate the PPPoE session. To obtain further and more in depth information on the PPPoE protocol refer to [RFC2516]. 3. AC-Address TAG_TYPE and TAG_VALUE We introduce a new TAG_TYPE called AC-Address. The description follows. 0x0111 AC-Address This TAG indicates the UTF-8 rendition of the MAC address of a Access concentrator. It is not NULL terminated. 4. The PPPoE Active Service Change (PADC) packet This packet may be sent anytime after a session is established if the AC has reason to believe the subscriber has requested a change in service. It may be sent by Access Concentrator only. The DESTINATION_ADDR field is the unicast Ethernet address of the Host, the CODE field is set to 0xb9 and the SESSION_ID MUST be set to indicate which session is to be terminated. Penno, R. [Page 3] Internet-Draft draft-penno-pppoe-ext-service-01.txt February,2001 If the subscriber requested a change in service, the AC sends the client a PADC frame with a suggested-service and suggested-AC tag. However, the AC MUST NOT make any changes to the state of the current PPPoE session. Upon receipt of a PADC frame, if the PPPoE client decides that it agrees with the service switch, it MUST send a PADT to the AC to terminate the current session. It MUST then send a PADI with the indicated service name to the indicated AC. If it receives no answer, it MAY fall back to sending a PADI with the indicated service name to the broadcast Ethernet address. If the client decides that it does not agree with the service switch, it simply ignores the PADC and the existing PPPoE session continues unhindered. The PADC packet MUST contain at least one TAG of TAG_TYPE Service- Name or AC-Address, indicating the Service or the the address of a different Access Concentrator to which the new session MUST be established. 5. Deployment Scenarios Here we discuss deployment scenarios and how the PADC message with the respective AC-Address and Service-Name TAG-TYPES could be used in a network. o Service or ISP Change In this model the user request to change his service profile or ISP, usually through some web page, and Access concentrator then sends a PADC message with a Service-Name TAG_TYPE. The web server and the Access concentrator usually communicate with each other through some out-of-band mechanism. o Access Concentrator Change If the Access concentrator experiences a problem, is schedule for downtime maintenance, or the access provider wants to provide some form of load balancing, it can send a PADC message to all connected hosts asking them to reconnect to a different Access Concentrator. In this case the PADC message would include just the AC-Address TAG_TYPE. o Service and Access Concentrator Change If the user request a new service or ISP that is not available in the Access Concentrator that it is currently connected, the Access concentrator can send a PADC message to the host indicating the Address of a Access Concentrator where the requested service is available Penno, R. [Page 4] Internet-Draft draft-penno-pppoe-ext-service-01.txt February,2001 6. Compatibility with previous PPPoE Clients [RFC2516] If the AC wants to push the client to another AC for maintenance or load-balancing purposes, the AC SHOULD send a PADT frame with a suggested-service and suggested-AC tag. The client MUST terminate its PPPoE session. It SHOULD try to establish a new session. It MAY use the suggested-service and suggested-AC tags to guide it in the selection of a new AC, or it MAY ignore them and perform a normal discovery phase. The AC which originally send the PADT frame MUST NOT respond with a PADO unless it is actually willing to establish a session. 7. Security Considerations This is a extension to the PPPoE protocol, so the security considerations mentioned therein also apply to this document. This extension was made in a way that the PPPoE client is the final arbiter of whether or not to change services. It can base its decision on many factors: Maybe it has a database of services it is allowed to switch to. Maybe when the user goes to the Web site to switch services, the Web page communicates in some way with the PPPoE client telling it to expect a change to a new service. The PPPoE client will then accept a PADC to the new service if it arrives within a short time. This makes it harder for outsiders to spoof your identity -- the request for new service must come from the same machine running the PPPoE client. 8. References [RFC2516] Mamakos, et. al., "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999 9. Author's Addresses Reinaldo Penno Nortel Networks, Inc. 2305 Mission College Boulevard Building SC9 Santa Clara, CA 95134 Email: rpenno@nortelnetworks.com David F. Skoll Roaring Penguin Software Inc. 986 Eiffel Avenue Ottawa, Ontario K2C 0J2 Canada Email: dfs@roaringpenguin.com Penno, R. [Page 5] Internet-Draft draft-penno-pppoe-ext-service-01.txt February,2001 Full Copyright Statement Copyright (C) The Internet Society (2000). 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society.