Network Working Group Jeffrey Haag Internet-Draft Vince Mammoliti W. Mark Townsley February 2005 cisco Systems Simple PPP over Ethernet (sPPPoE) Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (2004). All Rights Reserved. Abstract This document defines a simple method for carrying PPP frames over Ethernet. PPP control packets are carried over a PPP ethertype, while IP packets may be carried as native IP over Ethernet. This has particular application in migration of ATM access networks to Ethernet. Haag, Mammoliti, Townsley Informational [Page 1] INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005 Contents Status of this Memo.......................................... 1 1. Introduction.............................................. 2 2. Protocol Overview......................................... 4 2.1 "Upstream" (CPE to BRAS) Encapsulation................ 5 2.2 "Downstream" (BRAS to CPE) Encapsulation.............. 6 2.3 Determination of BRAS MAC Address..................... 7 2.3.1 IP-Directed...................................... 7 2.3.2 Active Discovery................................. 8 3.0 PPP Packet Flow between PPPoA and sPPPoE.............. 8 3.1 PPP LCP............................................... 8 3.2 PPP Authentication.................................... 9 3.3 PPP IPCP.............................................. 9 4. Security Considerations................................... 10 5. IANA Considerations....................................... 10 6. Acknowledgments........................................... 10 7. References................................................ 10 7.1 Normative References.................................. 10 7.2 Informative References................................ 10 8. Contacts.................................................. 10 Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1. Introduction This document defines a simple method for carrying PPP frames over Ethernet (sPPPoE). PPP control packets are carried over a PPP ethertype, while IP packets may be carried as native IP over Ethernet. Unlike PPPoE defined in [RFC2516], this protocol involves no control plane (beyond what PPP already has) and does not have any additional encapsulation between the PPP and ethernet framing. This method of PPP over Ethernet encapsulation has particular Haag, Mammoliti, Townsley Informational [Page 2] INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005 application in migration of ATM access networks to Ethernet. In one common deployment of Digital Subscriber Line (DSL) access networks, a Digital Subscriber Line Access Module (DSLAM) sits on an ATM network between a Broadband Remote Access Server (BRAS) and Customer Premise Equipment (CPE) devices. The subscriber connection between the CPE and BRAS is often PPPoA [RFC2364]. This particular migration deployment scenario is give as Figure 1 and referenced throughout this document. PPPoA sPPPoE CPE ---------- DSLAM ------------ BRAS ATM GigE Figure 1: ATM to GigE DSL Migration The ATM access network for DSL is facing a migration to switched Gigabit Ethernet (GigE) networks. As this migration occurs in stages, it is desirable to be able to keep the PPPoA CPEs and DSL connection between the CPE and DSLAM as ATM, while migrating the network between the DSLAM and the BRAS. This creates a need for the DSLAM to switch PPP frames over ATM (PPPoA) towards the CPE, PPP over GigE towards the BRAS, and vice-versa. This document focuses on a mechanism to transport PPP control and data packets across an ATM network to a GigE network, so that the PPP Session will terminate at a BRAS on the GigE network. There may be other uses for Simplified PPPoE encapsulation, but they are currently outside the scope of this document. One method for would be to create an Interworking Function (IWF) for PPPoA [RFC2364] to PPPoE [RFC2516]. Such an IWF would need to solve difficult problems, including: - 1492 Maximum MTU in PPPoE, where PPPoA CPEs are commonly deployed with a 1500 byte MRU. While PPP should negotiate down to 1492, this would not be transparent to the CPE, and could be noticable to the end-user. - Messages used in PPPoE (undocumented extensions in some cases) which the BRAS may expect to be delivered to the user, would in fact stop at the DSLAM. - Inconsistency between state of BRAS, DSLAM and CPE, exacerbated by the PPPoE PADT message sent from the BRAS being defined optional and unreliable (not retransmitted). In short, a PPPoA to PPPoE IWF may be noticeable to a PPPoA CPE, and may require changes to processing at the BRAS. Thus, the IWF is not transparent to entities on either side of the DSLAM. Haag, Mammoliti, Townsley Informational [Page 3] INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005 This document aims to define a method for transporting PPP over Ethernet that is transparent to the PPPoA CPE in this case, is far simpler for a DSLAM to implement (which may be important given that DSLAMs are traditionally simple network devices which may be short on computing resources), and relatively simple for a BRAS to implement. Compared to an IWF function between PPPoA and PPPoE, "simplified" sPPPoE: - Mitigates MRU problems, as the PPPoA CPE may retain a 1500-byte MRU, which is the most commonly used setting for PPPoA deployments. Thus it is transparent to the PPPoA CPE. - The DSLAM can utilize a very simple mapping of ATM VC to Ethernet VLAN or vMAC address. - The DSLAM does not have to implement the PPPoE PAD discovery stack. - There is no confusion between "true" PPPoE sessions and "translated" PPPoE sessions at the BRAS. 2. Protocol Overview Given the DSL migration scenario depicted in Figure 1, the DSLAM will map traffic from individual CPE PVCs on the ATM side to individual Virtual MAC (vMAC) addresses on the GigE side. There will either be a one-to-one mapping between ATM PVCs to Ethernet vMACs, or between ATM PVCs and Ethernet 802.1Q VLANs. The BRAS and DSLAM will a configured VLAN or a unique (unique at the DSLAM) source "Virtual MAC" (vMAC) address to identify an individual ATM VC, and hence an individual PPPoA session. The DSLAM will need to split incoming PPPoA traffic from the CPE into 2 categories: 1 - Data traffic (which can be transported directly over Ethernet (IPv4, IPv6, etc) 2 - PPP Control Traffic (LCP, IPCP, etc) "Upstream" PPP control packets from the CPE destined for the BRAS are stripped of all ATM encoding, and transported over the PPP Ethertype 0x880B, with PPP headers intact. PPP data packets are stripped of their PPP headers and encapsulated directly over ethernet with the corresponding ethertype for that that data. For example, IPv4 traffic is encapsulated with the native ethertype for that type of data (e.g., 0x800 for IPv4, 0x86DD for IPv6). All sPPPoE (Simplified PPPoE) traffic arriving at the BRAS is identified either by the Haag, Mammoliti, Townsley Informational [Page 4] INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005 ethernet vMAC or 802.1Q VLAN tag for a given PPP session. If a VLAN tag is used to identify PPP sessions, the VLAN value MUST be configured at the BRAS and DSLAM for each ATM VC mapping. A single source and destination ethernet MAC addresses for the DSLAM and BRAS may be dynamically discovered as described in section 3.3. If a VLAN tag is not used to identify separate PPP sessions, a unique vMAC address MUST be dynamically assigned at the DSLAM for each ATM VC carrying PPPoA. MAC addresses may still be discovered as in section 2.3, but the DSLAM MUST source each PPP session with its own vMAC address. 2.1 "Upstream" (CPE to BRAS) Encapsulation An upstream packet from the CPE will start out as a PPPoA packet and look like the following: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + + + | | CID + LI + UUI + HEC + + | | + + + + PPP Packet + CRC-16 | | + + + + (Protocol + Payload) + | | (8) + (6) + (5) + (5) + + (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The size of the fields denote bit-width The Protocol and Payload combined will contain a PPP protocol or data packet as defined [RFC1661]. The DSLAM will strip the ATM header and CRC. After applying the ethernet encapsulation, the packet will look like the following when traveling from the DSLAM to the BRAS. Haag, Mammoliti, Townsley Informational [Page 5] INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005 An Ethernet frame forwarded from ATM to GigE 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DESTINATION_ADDR | | (6 octets) | | BRAS or router MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SOURCE_ADDR | | (6 octets) | | vMAC of CPE PVC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETHER_TYPE (2 octets) | | PPP or native ether type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ Payload ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CHECKSUM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ETHERTYPE will correspond to the native type for data packets, such as 0x0800 for IP, or to the PPP ethertype 0x880B for all non- data packets, such as PPP control and authentication packets. The Payload will contain a complete PPP packet, including the PPP Header, but with address and control fields (0xFF03) removed. 2.2 "Downstream" (BRAS to CPE) Encapsulation All packets on the GigE network received on a vMAC or MAC w/VLAN at the DSLAM will be forwarded to the corresponding CPE VC on the ATM network after translating the header encapsulating the PPP control packet or data packet. The Destination Address in the ethernet frame will be used to map the packet to a particular destination CPE PVC. The Source Address will be that of the BRAS that generated the frame. If the Ethertype is PPP, then the DSLAM can simply encapsulate the received Payload in the corresponding PPPoA frame for the destination CPE. If the ethertype is that of a data packet, such as IP, then the DSLAM will have to prepend the corresponding PPP protocol field to the Payload in order to perform the necessary PPPoA encapsulation. Haag, Mammoliti, Townsley Informational [Page 6] INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005 An Ethernet frame forwarded from ATM to GigE 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DESTINATION_ADDR | | (6 octets) | | vMAC of CPE PVC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SOURCE_ADDR | | (6 octets) | | BRAS or router MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETHER_TYPE (2 octets) | | PPP or native ether type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ payload ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CHECKSUM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The PPPoA encapsulated PPP Packet on the ATM side will look like: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + + + | | CID + LI + UUI + HEC + + | | + + + + PPP Packet + CRC-16 | | + + + + (Protocol + Payload) + | | (8) + (6) + (5) + (5) + + (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The size of the fields denote bit-width 2.3 Determination of BRAS MAC Address The DSLAM SHOULD monitor PPP control packets to determine when a new PPP session has begun. When an LCP CONFREQ arrives from a CPE on a PPPoA interface that is configured to forward over sPPPoE, the DSLAM SHOULD determine the destination MAC address of the BRAS via one of the methods described in section 2.3.1 or 2.3.2. Note that it is not strictly necessary for the DSLAM to monitor when a PPP session ends. 2.3.1 IP-Directed Based on a configured IP address of the BRAS, the DSLAM performs an ARP on the given ethernet segment to determine the MAC of the BRAS Haag, Mammoliti, Townsley Informational [Page 7] INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005 and uses this as the destination address on the GigE network for the corresponding CPE PVC. Multiple IP addresses may be configured for load-balancing across multiple BRASes. 2.3.2 Active Discovery In this case, the DSLAM will send out the CPE's initial LCP CONFREQ as an ethernet broadcast on the GigE network. One or more BRASes may respond. The DSLAM will choose one of the responders as the destination MAC for sPPPoE session. The DSLAM SHOULD send an LCP TERMREQ to other BRASes that responded, but did not get chosen. Note that the CPE device may timeout and retransmit its initial CONFREQ before any BRAS responses get back to it, or the DSLAM has chosen a BRAS. The DSLAM may or may not have already chosen a BRAS. It does not matter when the DSLAM chooses the BRAS, since it will only ever transmit packets from a single BRAS to the CPE. 3.0 PPP Packet Flow between PPPoA and sPPPoE This section outlines example packet flows between a CPE, DSLAM and BRAS. For sPPPoE, source and destination MAC addresses are noted. Ethernet VLANs are not depicted, but may be present for identifying individual PPP sessions from a given DSLAM or BRAS source MAC. 3.1 PPP LCP CPE ------ PPPoA ------ DSLAM ----- sPPPoE ---- BRAS --- ----- ---- PPP LCP ConfREQ -> PPP LCP ConfREQ -> Source: vMAC Dest: B-cast <- PPP LCP ConfACK <- PPP LCP ConfACK Source: BRAS MAC Dest: vMAC <- PPP LCP ConfREQ <- PPP LCP ConfREQ Source: BRAS MAC Dest: vMAC PPP LCP ConfACK -> PPP LCP ConfACK -> Source: vMAC Dest: BRAS MAC Haag, Mammoliti, Townsley Informational [Page 8] INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005 3.2 PPP Authentication CPE ------ PPPoA ------ DSLAM ----- sPPPoE ---- BRAS --- ----- ---- <- PPP Authen <- PPP Authen Challenge Challenge Source: BRAS MAC Dest: vMAC PPP Authen -> PPP Authen -> Response Response Source: vMAC Dest: BRAS MAC 3.3 PPP IPCP CPE ------ PPPoA ------ DSLAM ----- sPPPoE ---- BRAS --- ----- ---- IPCP ConfREQ -> IPCP ConfREQ -> IP 0.0.0.0 IP 0.0.0.0 Source: vMAC Dest: BRAS MAC <- IPCP ConfNAK <- IPCP ConfNAK IP 10.2.3.5 IP 10.2.3.5 Source: BRAS MAC Dest: vMAC <- PPP IPCP ConfREQ <- PPP IPCP ConfREQ IP 10.0.0.1 Source: BRAS MAC Dest: vMAC IP 10.0.0.1 IPCP ConfREQ -> IPCP ConfREQ -> IP 10.2.3.5 IP 10.2.3.5 Source: vMAC Dest: BRAS MAC <- IPCP ConfACK <- IPCP ConfACK IP 10.2.3.5 IP 10.2.3.5 Source: BRAS MAC Dest: vMAC IPCP ConfACK -> IPCP ConfREQ -> IP 10.0.0.1 Source: vMAC Dest: BRAS MAC Haag, Mammoliti, Townsley Informational [Page 9] INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005 IP 10.0.0.1 4. Security Considerations Measures should be taken to protect any BRAS configured to accept sPPPoE packets from insertion and spoofing from a foreign source. Further, sPPPoE control packets should be rate-limited before processing at the BRAS in order to mitigate DOS attacks. 5. IANA Considerations There are no IANA considerations for this document. 6. Acknowledgments 7. References 7.1 Normative References [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2364] Gross, G., "PPP Over AAL5", Standards Track, RFC 2364, July 1998 7.2 Informative References [RFC2516] Mamakos, Lidl, Evarts, Carrel, Simone, Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. 8. Contacts Jeffrey Haag cisco Systems hagg@cisco.com Vince Mammoliti cisco Systems vince@cisco.com W. Mark Townsley cisco Systems mark@townsley.net Haag, Mammoliti, Townsley Informational [Page 10] INTERNET DRAFT Simple PPP over Ethernet (sPPPoE) February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Haag, Mammoliti, Townsley Informational [Page 11]