Softwires Working Group B. Storer Internet-Draft C. Pignataro, Ed. Intended status: Standards Track M. Dos Santos Expires: August 1, 2008 Cisco Systems B. Stevant, Ed. TELECOM Bretagne J. Tremblay Trellia Networks January 29, 2008 Softwire Hub & Spoke Deployment Framework with L2TPv2 draft-ietf-softwire-hs-framework-l2tpv2-08 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on August 1, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer 2 Tunneling Protocol version 2 (L2TPv2). The implementation details specified in this document should be followed Storer, et al. Expires August 1, 2008 [Page 1] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 to achieve interoperability among different vendor implementations. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 6 1.4. Considerations . . . . . . . . . . . . . . . . . . . . . . 7 2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7 2.1. Traditional Network Address Translation (NAT and NAPT) . . 7 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Authentication, Authorization and Accounting (AAA) . . . . 8 2.6. Privacy, Integrity, and Replay Protection . . . . . . . . 8 2.7. Operations and Management (OAM) . . . . . . . . . . . . . 8 2.8. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 9 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 9 3.1. IPv6 over IPv4 Softwires with L2TPv2 . . . . . . . . . . . 9 3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 9 3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 10 3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 12 3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 13 3.2. IPv4 over IPv6 Softwires with L2TPv2 . . . . . . . . . . . 14 3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 14 3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 15 3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 16 3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 16 4. Standardization Status . . . . . . . . . . . . . . . . . . . . 17 4.1. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Securing the Softwire Transport . . . . . . . . . . . . . 18 4.3. Authentication Authorization Accounting . . . . . . . . . 18 4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 19 4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 19 4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 19 5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 19 5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 22 5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 22 5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 24 5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 25 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 25 Storer, et al. Expires August 1, 2008 [Page 2] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 25 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 26 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 26 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 26 5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 27 5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 27 5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 28 6. Considerations about the Address Provisioning Model . . . . . 29 6.1. Softwire Endpoints' Addresses . . . . . . . . . . . . . . 29 6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 29 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30 6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 30 6.3. Possible Address Provisioning Scenarios . . . . . . . . . 30 6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 30 6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 31 7. Considerations about Address Stability . . . . . . . . . . . . 31 8. Considerations about RADIUS Integration . . . . . . . . . . . 31 8.1. Softwire Endpoints . . . . . . . . . . . . . . . . . . . . 32 8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 32 8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 32 8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 32 8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 32 8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 33 9. Considerations for Maintenance and Statistics . . . . . . . . 33 9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 33 9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . . 36 Storer, et al. Expires August 1, 2008 [Page 3] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . . . . 45 Storer, et al. Expires August 1, 2008 [Page 4] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 1. Introduction The Softwires Working Group has selected Layer Two Tunneling Protocol version 2 (L2TPv2) as the phase 1 protocol to be deployed in the Softwire "Hubs and Spokes" solution space. This document describes the framework for the L2TPv2 "Hubs and Spokes" solution, and the implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. In the "Hubs and Spokes" solution space, a Softwire is established to provide the home network with IPv4 connectivity across an IPv6-only access network, or IPv6 connectivity across an IPv4-only access network. When L2TPv2 is used in the Softwire context, the voluntary tunneling model applies. The Softwire Initiator (SI) at the home network takes the role of the L2TP Access Concentrator (LAC) client (initiating both the L2TP tunnel/session and the PPP link) while the Softwire Concentrator (SC) at the ISP takes the role of the L2TP Network Server (LNS). Since L2TPv2 compulsory tunneling model does not apply to Softwires, it should not be requested or honored. This document identifies all the voluntary tunneling related L2TPv2 attributes that apply to Softwires and specifies the handling mechanism for such attributes in order to avoid ambiguities in implementations. This document also identifies the set of L2TPv2 attributes specific to compulsory tunneling model that do not apply to Softwires and specifies the mechanism to ignore or nullify their effect within the Softwire context. The SI and SC must follow the L2TPv2 operations described in [RFC2661] when performing Softwire establishment, tear-down and OAM. With L2TPv2, a Softwire consists of an L2TPv2 Control Connection (also referred to as Control Channel), a single L2TPv2 Session, and the PPP link negotiated over the Session. To establish the Softwire, the SI first initiates an L2TPv2 Control Channel to the SC which accepts the request and terminates the Control Channel. L2TPv2 supports an optional mutual Control Channel authentication which allows both SI and SC to validate each other's identity at the initial phase of hand-shaking before proceeding with Control Channel establishment. After the L2TPv2 Control Channel is established between the SI and SC, the SI initiates an L2TPv2 Session to the SC. Then the PPP/IP link is negotiated over the L2TPv2 Session between the SI and SC. After the PPP/IP link is established, it acts as the Softwire between the SI and SC for tunneling IP traffic of one Address Family (AF) across the access network of another Address Family. During the life of the Softwire, both SI and SC send L2TPv2 keepalive HELLO messages to monitor the health of the Softwire and the peer LCCE, and to potentially refresh the NAT/NAPT translation entry at Storer, et al. Expires August 1, 2008 [Page 5] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 the CPE or at the other end of the access link. Optionally, LCP ECHO messages can be used as keepalives for the same purposes. In the event of keepalive timeout or administrative shutdown of the Softwire, either SI or SC may tear down the Softwire by tearing down the L2TPv2 Control Channel and Session as specified in [RFC2661]. 1.1. Abbreviations AF Address Family, IPv4 or IPv6. SC Softwire Concentrator, the node terminating the Softwire in the service provider network (See [RFC4925]). SI Softwire Initiator, the node initiating the Softwire within the customer network (See [RFC4925]). LCCE L2TP Control Connection Endpoint, an L2TP node that exists at either end of an L2TP Control Connection (See [RFC3931]). SPH Softwire Payload Header, the IP headers being carried within a softwire (See [RFC4925]). STH Softwire Transport Header, the outermost IP header of a softwire (See [RFC4925]). SW Softwire, a shared-state "tunnel" created between the SC and SI. (See [RFC4925]). 1.2. Requirements Language 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.3. Contributing Authors Following is the complete list of contributors to this document. Maria Alice Dos Santos, Cisco Systems Carlos Pignataro, Cisco Systems Bill Storer, Cisco Systems Jean-Francois Tremblay, Trellia Networks Laurent Toutain, GET/ENST Bretagne Bruno Stevant, TELECOM Bretagne Storer, et al. Expires August 1, 2008 [Page 6] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 1.4. Considerations Some sections of this document contain considerations that are not required for interoperability and correct operation of Softwire implementations. These sections are marked as "Considerations". 2. Applicability of L2TPv2 for Softwire Requirements A list of Softwire "Hubs and Spokes" requirements has been identified by the Softwire Problem Statement [RFC4925]. The following sub- sections describe how L2TPv2 fulfills each of them. 2.1. Traditional Network Address Translation (NAT and NAPT) A "Hubs and Spokes" Softwire must be able to traverse Network Address Translation (NAT) and Network Address Port Translation (NAPT, also referred to as Port Address Translation or PAT) devices [RFC3022] in case the scenario in question involves a non-upgradable pre-existing IPv4 home gateway performing NAT/NAPT or some carrier equipment at the other end of the access link performing NAT/NAPT. The L2TPv2 Softwire (i.e., Control Channel and Session) is capable of NAT/NAPT traversal since L2TPv2 can run over UDP. Since L2TPv2 does not detect NAT/NAPT along the path, L2TPv2 does not offer the option of disabling UDP. The UDP encapsulation is present regardless of NAT/NAPT presence. Both NAT/NAPT "autodetect" and UDP "bypass" are optional requirements in Section 2.3 of [RFC4925]. 2.2. Scalability In the "Hubs and Spokes" model, a carrier must be able to scale the solution to millions of Softwire Initiators by adding more hubs (i.e., Softwire Concentrators). L2TPv2 is a widely deployed protocol in broadband services, and its scalability has been proven in multiple large-scale IPv4 Virtual Private Network deployments which scale up to millions of subscribers each. 2.3. Routing There are no dynamic routing protocols between the SC and SI. A default route from the SI to the SC is used. 2.4. Multicast Multicast protocols simply run over L2TPv2 Softwires transparently together with other regular IP traffic. Storer, et al. Expires August 1, 2008 [Page 7] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 2.5. Authentication, Authorization and Accounting (AAA) L2TPv2 supports optional mutual Control Channel authentication and leverages the optional mutual PPP per-session authentication. L2TPv2 is well integrated with AAA solutions (such as RADIUS) for both authentication and authorization. Most L2TPv2 implementations available in the market support logging of authentication and authorization events. L2TPv2 integration with RADIUS accounting (RADIUS Accounting extension for tunnel [RFC2867]) allows the collection and reporting of L2TPv2 Softwire usage statistics. 2.6. Privacy, Integrity, and Replay Protection Since L2TPv2 runs over IP/UDP in the Softwire context, IPsec ESP can be used in conjunction to provide per-packet authentication, integrity, replay protection and confidentiality for both L2TPv2 control and data traffic [RFC3193] and [RFC3948]. For Softwire deployments in which full payload security is not required, the L2TPv2 built-in Control Channel authentication and the inherited PPP authentication and PPP Encryption Control Protocol can be considered. 2.7. Operations and Management (OAM) L2TPv2 supports an optional in-band keepalive mechanism which injects HELLO control messages after a specified period of time has elapsed since the last data or control message was received on a tunnel (see Section 5.5 of [RFC2661]). If the HELLO control message is not reliably delivered, then the Control Channel and its Session will be torn down. In the Softwire context, the L2TPv2 keepalive is used to monitor the connectivity status between the SI and SC and/or as a refresh mechanism for any NAT/NAPT translation entry along the access link. LCP ECHO offers a similar mechanism to monitor the connectivity status, as described in [RFC1661]. Softwire implementations SHOULD use L2TPv2 Hello keepalives and in addition MAY use PPP LCP Echo messages to ensure Dead End Detection and/or to refresh NAT/NAPT translation entries. The combination of these two mechanisms can be used as an optimization. L2TPv2 MIB [RFC3371] supports the complete suite of management operations such as configuration of Control Channel and Session, polling of Control Channel and Session status and their traffic statistics and notifications of Control Channel and Session UP/DOWN Storer, et al. Expires August 1, 2008 [Page 8] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 events. 2.8. Encapsulations L2TPv2 supports the following encapsulations: o IPv6/PPP/L2TPv2/UDP/IPv4 o IPv4/PPP/L2TPv2/UDP/IPv6 o IPv4/PPP/L2TPv2/UDP/IPv4 o IPv6/PPP/L2TPv2/UDP/IPv6 Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not support "autodetect" of NAT/NAPT. 3. Deployment Scenarios For the "Hubs and Spokes" problem space, four scenarios have been identified. In each of these four scenarios, different home equipment plays the role of the Softwire Initiator. This section elaborates each scenario with L2TPv2 as the Softwire protocol and other possible protocols involved to complete the solution. This section examines the four scenarios for both IPv6 over IPv4 (Section 3.1) and IPv4 over IPv6 (Section 3.2) encapsulations. 3.1. IPv6 over IPv4 Softwires with L2TPv2 The following subsections cover IPv6 connectivity (SPH) across an IPv4-only access network (STH) using a Softwire. 3.1.1. Host CPE as Softwire Initiator The Softwire Initiator (SI) is the host CPE (directly connected to a modem), which is dual-stack. There is no other gateway device. The IPv4 traffic SHOULD NOT traverse the softwire. See Figure 1. Storer, et al. Expires August 1, 2008 [Page 9] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 IPv6 or dual-stack IPv4-only dual-stack |------------------||-----------------||----------| I SC SI N +-----+ +----------+ T | | | v4/v6 | E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| host CPE | R [network] | | [ network ] | | N | LNS | |LAC Client| E +-----+ +----------+ T _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic PPP o L2TPv2 o UDP o IPv4 (SPH) Softwire <------------------> IPV6CP: capable of /64 Intf-Id assignment or uniqueness check |------------------>/64 prefix RA |------------------>DNS, etc. DHCPv6 Figure 1: Host CPE as Softwire Initiator In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPV6CP negotiates IPv6 over PPP which also provides the capability for the ISP to assign the 64-bit Interface-Identifier to the host CPE or perform uniqueness validation for the two interface identifiers at the two PPP ends [RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can inform the host CPE of a prefix to use for stateless address autoconfiguration through a Router Advertisement (RA) while other nonaddress configuration options (such as DNS [RFC3646] or other servers' addresses that might be available) can be conveyed to the host CPE via DHCPv6. 3.1.2. Router CPE as Softwire Initiator The Softwire Initiator (SI) is the router CPE, which is a dual-stack device. The IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 2. Storer, et al. Expires August 1, 2008 [Page 10] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 IPv6 or dual-stack IPv4-only dual-stack |------------------||-----------------||---------------------| I SC SI N +-----+ +----------+ T | | | v4/v6 | +-----+ E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| CPE |----|v4/v6| R [network] | | [ network ] | | | host| N | LNS | |LAC Client| +-----+ E +-----+ +----------+ T _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _() <-------- IPv6 traffic PPP o L2TPv2 o UDP o IPv4 (SPH) Softwire <------------------> IPV6CP: capable of /64 Intf-Id assignment or uniqueness check |------------------>/64 prefix RA |------------------>/48 prefix, DHCPv6 DNS, etc. |------->/64 prefix RA |-------> DNS, etc. DHCPv4/v6 Figure 2: Router CPE as Softwire Initiator In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPV6CP negotiates IPv6 over PPP which also provides the capability for the ISP to assign the 64-bit Interface-Identifier to the router CPE or perform uniqueness validation for the two interface identifiers at the two PPP ends [RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can inform the router CPE of a prefix to use for stateless address autoconfiguration through a Router Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g., delegating a prefix to be used within the home network [RFC3633]) and convey other nonaddress configuration options (such as DNS [RFC3646]) to the router CPE. Storer, et al. Expires August 1, 2008 [Page 11] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 3.1.3. Host behind CPE as Softwire Initiator The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack host (behind the IPv4-only CPE), which acts as an IPv6 host CPE. The IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 3. IPv6 or dual-stack IPv4-only dual-stack |------------------||----------------------------||----------| I SC SI N +-----+ +----------+ T | | +-------+ | v4/v6 | E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....|v4-only|--| host | R [network] | | [ network ] | CPE | | | N | LNS | +-------+ |LAC Client| E +-----+ +----------+ T _ _ _ _ _ _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6 PPP o L2TPv2 o UDP o IPv4 traffic Softwire (SPH) <------------------------------> IPV6CP: capable of /64 Intf-Id assignment or uniqueness check |------------------------------>/64 prefix RA |------------------------------>DNS, etc. DHCPv6 Figure 3: Host behind CPE as Softwire Initiator In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPV6CP negotiates IPv6 over PPP which also provides the capability for the ISP to assign the 64-bit Interface-Identifier to the host or perform uniqueness validation for the two interface identifiers at the two PPP ends [RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can inform the host of a prefix to use for stateless address autoconfiguration through a Router Advertisement (RA) while other nonaddress configuration options (such as DNS [RFC3646]) can be conveyed to the host via DHCPv6. Storer, et al. Expires August 1, 2008 [Page 12] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 3.1.4. Router behind CPE as Softwire Initiator The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack device (behind the IPv4-only CPE) acting as an IPv6 CPE router inside the home network. The IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 4. IPv6 or dual-stack IPv4-only dual-stack |------------------||-------------------------||-------------| I SC SI N +-----+ +----------+ T | | +-------+ | v4/v6 | E <==[ IPv6 ]....|v4/v6|..[IPv4-only]..|v4-only|---| router | R [network] | | [ network ] | CPE | | | | N | LNS | +-------+ | |LAC Client| E +-----+ | +----------+ T | ---------+-----+ |v4/v6| | host| _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ ()_ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6 PPP o L2TPv2 o UDP o IPv4 traffic Softwire (SPH) <---------------------------> IPV6CP: capable of /64 Intf-Id assignment or uniqueness check |--------------------------->/64 prefix RA |--------------------------->/48 prefix, DHCPv6 DNS, etc. |----> /64 RA prefix |----> DNS, DHCPv6 etc. Figure 4: Router behind CPE as Softwire Initiator In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPV6CP negotiates IPv6 over PPP which also provides the capability for the ISP to assign the 64-bit Interface-Identifier to the v4/v6 router or perform uniqueness Storer, et al. Expires August 1, 2008 [Page 13] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 validation for the two interface identifiers at the two PPP ends [RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can inform the v4/v6 router of a prefix to use for stateless address autoconfiguration through a Router Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g., delegating a prefix to be used within the home network [RFC3633]) and convey other nonaddress configuration options (such as DNS [RFC3646]) to the v4/v6 router. 3.2. IPv4 over IPv6 Softwires with L2TPv2 The following subsections cover IPv4 connectivity (SPH) across an IPv6-only access network (STH) using a Softwire. 3.2.1. Host CPE as Softwire Initiator The Softwire Initiator (SI) is the host CPE (directly connected to a modem), which is dual-stack. There is no other gateway device. The IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 5. IPv4 or dual-stack IPv6-only dual-stack |------------------||-----------------||----------| I SC SI N +-----+ +----------+ T | | | v4/v6 | E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| host CPE | R [network] | | [ network ] | | N | LNS | |LAC Client| E +-----+ +----------+ T _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic PPP o L2TPv2 o UDP o IPv6 (SPH) Softwire <------------------> IPCP: capable of global IP assignment and DNS, etc. Figure 5: Host CPE as Softwire Initiator In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPCP negotiates IPv4 over PPP which also provides the capability for the ISP to assign a global IPv4 address to the host CPE. A global IPv4 address can also be assigned Storer, et al. Expires August 1, 2008 [Page 14] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 via DHCP. Other configuration options (such as DNS) can be conveyed to the host CPE via IPCP [RFC1877] or DHCP [RFC2132]. 3.2.2. Router CPE as Softwire Initiator IPv4 connectivity across an IPv6-only access network (STH). The Softwire Initiator (SI) is the router CPE, which is a dual-stack device. The IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 6. IPv4 or dual-stack IPv6-only dual-stack Home |------------------||-----------------||-------------------| I SC SI N +-----+ +----------+ T | | | v4/v6 | +-----+ E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| CPE |--|v4/v6| R [network] | | [ network ] | | | host| N | LNS | |LAC Client| +-----+ E +-----+ +----------+ T _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _() <--------- IPv4 traffic PPP o L2TPv2 o UDP o IPv6 (SPH) Softwire <------------------> IPCP: capable of global IP assignment and DNS, etc. |------------------> DHCPv4: prefix, mask, PD private/ |------> global DHCP IP, DNS, etc. Figure 6: Router CPE as Softwire Initiator In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPCP negotiates IPv4 over PPP which also provides the capability for the ISP to assign a global IPv4 address to the router CPE. A global IPv4 address can also be assigned via DHCP. Other configuration options (such as DNS) can be conveyed to the router CPE via IPCP [RFC1877] or DHCP [RFC2132]. For IPv4 Prefix Delegation for the home network, DHCP Storer, et al. Expires August 1, 2008 [Page 15] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 [I-D.ietf-dhc-subnet-alloc] can be used. 3.2.3. Host behind CPE as Softwire Initiator IPv4 connectivity across an IPv6-only access network (STH). The CPE is IPv6-only. The Softwire Initiator (SI) is a dual-stack host (behind the IPv6 CPE), which acts as an IPv4 host CPE. The IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 7. IPv4 or dual-stack IPv6-only dual-stack |------------------||----------------------------||----------| I SC SI N +-----+ +----------+ T | | +-------+ | v4/v6 | E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....|v6-only|--| host | R [network] | | [ network ] | CPE | | | N | LNS | +-------+ |LAC Client| E +-----+ +----------+ T _ _ _ _ _ _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv4 PPP o L2TPv2 o UDP o IPv6 traffic Softwire (SPH) <------------------------------> IPCP: capable of global IP assignment and DNS, etc. Figure 7: Host behind CPE as Softwire Initiator In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPCP negotiates IPv4 over PPP which also provides the capability for the ISP to assign a global IPv4 address to the host. A global IPv4 address can also be assigned via DHCP. Other configuration options (such as DNS) can be conveyed to the host CPE via IPCP [RFC1877] or DHCP [RFC2132]. 3.2.4. Router behind CPE as Softwire Initiator IPv4 connectivity across an IPv6-only access network (STH). The CPE is IPv6-only. The Softwire Initiator (SI) is a dual-stack device (behind the IPv6-only CPE) acting as an IPv4 CPE router inside the home network. The IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 8. Storer, et al. Expires August 1, 2008 [Page 16] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 IPv4 or dual-stack IPv6-only dual-stack |------------------||-------------------------||------------| I SC SI N +-----+ +----------+ T | | +-------+ | v4/v6 | E <==[ IPv4 ]....|v4/v6|..[IPv6-only]..|v6-only|---| router | R [network] | | [ network ] | CPE | | | | N | LNS | +-------+ | |LAC Client| E +-----+ | +----------+ T | --------+-----+ |v4/v6| | host| _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ ()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- IPv4 PPP o L2TPv2 o UDP o IPv4 traffic Softwire (SPH) <---------------------------> IPCP: assigns global IP address and DNS, etc. |---------------------------> DHCPv4: prefix, mask, PD private/ |----> global DHCP IP, DNS, etc. Figure 8: Router behind CPE as Softwire Initiator In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPCP negotiates IPv4 over PPP which also provides the capability for the ISP to assign a global IPv4 address to the v4/v6 router. A global IPv4 address can also be assigned via DHCP. Other configuration options (such as DNS) can be conveyed to the v4/v6 router via IPCP [RFC1877] or DHCP [RFC2132]. For IPv4 Prefix Delegation for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used. 4. Standardization Status This section groups various Internet standards documents and other publications used in Softwires. Storer, et al. Expires August 1, 2008 [Page 17] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 4.1. L2TPv2 RFC 2661 "Layer Two Tunneling Protocol "L2TP"" [RFC2661]. * For both IPv4 and IPv6 payloads (SPH), support is complete. * For both IPv4 and IPv6 transports (STH), support is complete. 4.2. Securing the Softwire Transport RFC 3193 "Securing L2TP using IPsec" [RFC3193]. RFC 3948 "UDP Encapsulation of IPsec ESP Packets" [RFC3948]. * IPsec supports both IPv4 and IPv6 transports. 4.3. Authentication Authorization Accounting RFC 2865 "Remote Authentication Dial In User Service (RADIUS)" [RFC2865]. RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol Support" [RFC2867]. RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868]. RFC 3162 "RADIUS and IPv6" [RFC3162]. 4.4. MIB RFC 1471 "The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol" [RFC1471]. RFC 1473 "The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol" [RFC1473]. RFC 3371 "Layer Two Tunneling Protocol "L2TP" Management Information Base" [RFC3371]. RFC 4087 "IP Tunnel MIB" [RFC4087]. * Both IPv4 and IPv6 transports are supported. Storer, et al. Expires August 1, 2008 [Page 18] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 4.5. Softwire Payload Related 4.5.1. For IPv6 Payloads RFC 4861 "Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861]. RFC 4862 "IPv6 Stateless Address Autoconfiguration" [RFC4862]. RFC 5072 "IP Version 6 over PPP" [RFC5072]. RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3315]. RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" [RFC3633]. RFC 3646 "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3646]. RFC 3736 "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6" [RFC3736]. 4.5.2. For IPv4 Payloads RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)" [RFC1332]. RFC 1661 "The Point-to-Point Protocol (PPP)" [RFC1661]. RFC 1877 "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses" [RFC1877]. RFC 2131 "Dynamic Host Configuration Protocol" [RFC2131]. RFC 2132 "DHCP Options and BOOTP Vendor Extensions" [RFC2132]. DHCP Subnet Allocation "Subnet Allocation Option". * Work in progress, see [I-D.ietf-dhc-subnet-alloc]. 5. Softwire Establishment A Softwire is established in three distinct steps (see Figure 9). First an L2TPv2 tunnel with a single session is established from the SI to the SC. Second a PPP session is established over the L2TPv2 session and the SI obtains an address. Third the SI optionally gets other information through DHCP such as a delegated prefix and DNS Storer, et al. Expires August 1, 2008 [Page 19] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 servers. SC SI | | |<-------------L2TPv2------------>| Step 1 | | L2TPv2 Tunnel establishment | | |<-------------PPP--------------->| Step 2 |<----End Point Configuration---->| PPP and End Point | | configuration | | |<------Router Configuration----->| Step 3 | | Additional configuration | | (optional) Figure 9: Steps for the Establishment of a Softwire Figure 10 depicts details of each of the three steps required to establish a Softwire. Storer, et al. Expires August 1, 2008 [Page 20] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 SC SI | | | | Step 1 |<------------SCCRQ---------------| - |-------------SCCRP-------------->| | |<------------SCCCN---------------| | |<------------ICRQ----------------| | L2TPv2 |-------------ICRP--------------->| | |<------------ICCN----------------| - | | | | Step 2 |<-----Configuration-Request------| - |------Configuration-Request----->| | PPP |--------Configuration-Ack------->| | LCP |<-------Configuration-Ack--------| - | | |-----------Challenge------------>| - PPP Authentication |<----------Response--------------| | (Optional - CHAP) |------------Success------------->| - | | |<-----Configuration-Request------| - |------Configuration-Request----->| | PPP NCP |--------Configuration-Ack------->| | (IPV6CP or IPCP) |<-------Configuration-Ack--------| - | | |<------Router-Solicitation-------| - Neighbor Discovery |-------Router-Advertisement----->| | (IPv6 only) | | - | | | | Step3 | | DHCP (Optional) |<-----------SOLICIT--------------| - |-----------ADVERTISE------------>| | DHCPv6 |<---------- REQUEST--------------| | (IPv6 SW, Optional) |-------------REPLY-------------->| - | | or |<---------DHCPDISCOVER-----------| - |-----------DHCPOFFER------------>| | DHCPv4 |<---------DHCPREQUEST------------| | (IPv4 SW, Optional) |------------DHCPACK------------->| - Figure 10: Detailed Steps in the Establishment of a Softwire The PPP NCP negotiations in step 2 use IPV6CP for IPv6 over IPv4 Softwires, and IPCP for IPv4 over IPv6 Softwires. The optional DHCP negitiations in step 3 use DHCPv6 for IPv6 over IPv4 Softwires, and DHCPv4 for IPv4 over IPv6 Softwires. Additionally, for IPv6 over IPv4 Softwires, the DHCPv6 exchange for nonaddress configuration Storer, et al. Expires August 1, 2008 [Page 21] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 (such as DNS) can use a two message exchange with Information-Request and Reply messages (see Section 1.2 of [RFC3315] and [RFC3736]). 5.1. L2TPv2 Tunnel Setup L2TPv2 [RFC2661] was originally designed to provide private network access to end users connected to a public network. In the L2TPv2 incoming call model, the end user makes a connection to an L2TP Access Concentrator (LAC). The LAC then initiates an L2TPv2 tunnel to an L2TP Network Server (LNS). The LNS then transfers end user traffic between the L2TPv2 tunnel and the private network. In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI) assumes the role of the LAC Client and the Softwire Concentrator (SC) assumes the role of the LNS. In the Softwire model, an L2TPv2 packet MUST be carried over UDP. The underlying version of the IP protocol may be IPv4 or IPv6, depending on the Softwire scenario. In the following sections, the term "Tunnel" follows the definition from Section 1.2 of [RFC2661], namely: "The Tunnel consists of a Control Connection and zero or more L2TP Sessions". 5.1.1. Tunnel Establishment Figure 11 describes the messages exchanged and Attribute Value Pairs (AVPs) used to establish a tunnel between an SI (LAC) and an SC (LNS). The messages and AVPs described here are only a subset of those defined in [RFC2661]. This is because Softwires use only a subset of the L2TPv2 functionality. The subset of L2TP Control Connection Management AVPs that is applicable to Softwires is grouped into Mandatory AVPs and Optional AVPs (see Figure 11). Note that in the Softwire environment, the SI always initiates the tunnel. L2TPv2 AVPs SHOULD NOT be hidden. Storer, et al. Expires August 1, 2008 [Page 22] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 SC SI |<--------SCCRQ---------| Mandatory AVPs: Message Type Protocol Version Host Name Framing Capabilities Assigned Tunnel ID Optional AVPs: Receive Window Size Challenge Firmware Revision Vendor Name |---------SCCRP-------->| Mandatory AVPs: Message Type Protocol Version Framing Capabilities Host Name Assigned Tunnel ID Optional AVPs: Firmware Revision Vendor Name Receive Window Size Challenge Challenge Response |<--------SCCCN---------| Mandatory AVPs: Message Type Optional AVPs: Challenge Response Figure 11: Control Connection Establishment In L2TPv2, generally, the tunnel between an LAC and LNS may carry the data of multiple users. Each of these users is represented by an L2TPv2 session within the tunnel. In the Softwire environment, the tunnel carries the information of a single user. Consequently, there is only one L2TPv2 session per tunnel. Figure 12 describes the messages exchanged and the AVPs used to establish a session between an SI (LAC) and an SC (LNS). The messages and AVPs described here are only a subset of those defined in [RFC2661]. This is because Softwires use only a subset of the L2TPv2 functionality. The subset of L2TP Call Management AVPs that is applicable to Softwires is grouped into Mandatory AVPs and Optional AVPs (see Figure 12). Note that in the Softwire environment, the SI always initiates the Storer, et al. Expires August 1, 2008 [Page 23] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 session. No outgoing or analog calls are permitted. L2TPv2 AVPs SHOULD NOT be hidden. SC SI |<--------ICRQ---------| Mandatory AVPs: Message Type Assigned Session ID Call Serial Number |---------ICRP-------->| Mandatory AVPs: Message Type Assigned Session ID |<--------ICCN---------| Mandatory AVPs: Message Type (Tx) Connect Speed Framing Type Figure 12: Session Establishment 5.1.1.1. AVPs Required for Softwires This section prescribes specific values for AVPs used in the Softwire context that are Mandatory. Host Name AVP This AVP is mandatory in SCCRQ and SCCRP messages. This AVP may be used to authenticate users, in which case it would contain a user identification. If this AVP is not used to authenticate users, it may be used for logging purposes. Framing Capabilities AVP Both the synchronous (S) and asynchronous (A) bits SHOULD be set to 1. This AVP SHOULD be ignored by the receiver. Framing Type AVP The synchronous bit SHOULD be set to 1 and the asynchronous bit to 0. This AVP SHOULD be ignored by the receiver. (Tx) Connect Speed Storer, et al. Expires August 1, 2008 [Page 24] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 (Tx) Connect Speed is a mandatory AVP but is not meaningful in the Softwire context. Its value SHOULD be set to 0 and ignored by the receiver. Message Type AVP, Protocol Version AVP, Assigned Tunnel ID AVP, Call Serial Number AVP, and Assigned Session ID AVP As defined in [RFC2661]. 5.1.1.2. AVPs Optional for Softwires This section prescribes specific values for AVPs used in the Softwire context that are Optional. Challenge AVP and Challenge Response AVP These AVPs are not required, but are necessary to implement tunnel authentication. Since tunnel authentication happens at the beginning of L2TPv2 tunnel creation, it can be helpful in preventing DoS attacks. See Section 5.1.1 of [RFC2661]. The usage of these AVPs in L2TP messages is OPTIONAL, but SHOULD be implemented in the SC. Receive Window Size AVP, Firmware Revision AVP, and Vendor Name AVP As defined in [RFC2661]. 5.1.1.3. AVPs not Relevant for Softwires L2TPv2 specifies numerous AVPs that, while allowed for a given message, are irrelevant to Softwires. Softwire implementations SHOULD NOT send these AVPs. However, they SHOULD ignore them when they are received. This will simplify the creation of Softwire applications that build upon existing L2TPv2 implementations. 5.1.2. Tunnel Maintenance Periodically, the SI/SC MUST transmit a message to the peer to detect tunnel or peer failure and maintain NAT/NAPT contexts. The L2TPv2 HELLO message provides a simple, low overhead method of doing this. The default values specified in [RFC2661] for L2TPv2 HELLO messages could result in a dead end detection time of 83 seconds. Although these retransmission timers and counters SHOULD be configurable (see Section 5.8 of [RFC2661]), these values may not be adapted for all situations, where a quicker dead end detection is required, or where NAT/NAPT context needs to be refreshed more frequently. In such Storer, et al. Expires August 1, 2008 [Page 25] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 cases, the SI/SC MAY use, in combination with L2TPv2 HELLO, LCP ECHO messages (Echo-Request and Echo-Reply codes) described in [RFC1661]. When used, LCP ECHO messages SHOULD have a re-emission timer lower than the value for L2TPv2 HELLO hello messages. The default value recommended in Section 6.5 of [RFC2661] for the HELLO message retransmission interval is 60 seconds. When used, a set of suggested values (included here only for guidance) for the LCP ECHO message request interval is a default of 30 seconds, a minimum of 10 seconds, and a maximum of the lesser of the configured L2TPv2 HELLO retransmisison interval and 60 seconds. 5.1.3. Tunnel Teardown Either the SI or SC can teardown the session and tunnel. This is done as specified in Section 5.7 of [RFC2661], by sending a StopCCN control message. There is no action specific to Softwires in this case. 5.2. PPP Connection This section describes the PPP negotiations between the SI and SC in the Softwire context. 5.2.1. MTU The MTU of the PPP link presented to the SPH SHOULD be the link MTU minus the size of the IP, UDP, L2TPv2, and PPP headers together. On an IPv4 link with an MTU equal to 1500 bytes, this could tipically mean a PPP MTU of 1460 bytes. When the link is managed by IPsec, this MTU should be lowered to take into account the ESP encapsulation (see [I-D.ietf-softwire-security-requirements]). The value for the MTU may also vary according to the size of the L2TP header, as defined by the leading bits of the L2TP message header (see [RFC2661]). Additionally, see [RFC4623] for a detailed discussion of fragmentation issues. 5.2.2. LCP Once the L2TPv2 session is established, the SI and SC initiate the PPP connection by negotiating LCP as described in [RFC1661]. The Address-and-Control-Field-Compression configuration option (ACFC) [RFC1661] MAY be rejected. 5.2.3. Authentication After completing LCP negotiation, the SI and SC may optionally perform authentication. If authentication is chosen, CHAP [RFC1994] authentication MUST be supported by both the Softwire Initiator and Storer, et al. Expires August 1, 2008 [Page 26] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 Softwire Concentrator. Other authentication methods such as MS- CHAPv1 [RFC2433], and EAP [RFC3748] MAY be supported. A detailed discussion of Softwire security is contained in [I-D.ietf-softwire-security-requirements]. 5.2.4. IPCP The only Network Control Protocol (NCP) negotiated in the Softwire context is IPV6CP (see Section 5.2.4.1) for IPv6 as SPH, and IPCP (see Section 5.2.4.2) for IPv4 as SPH. 5.2.4.1. IPV6CP In the IPv6 over IPv4 scenarios (see Section 3.1), after the optional authentication phase, the Softwire Initiator MUST negotiate IPV6CP as defined in [RFC5072]. IPV6CP provides a way to negotiate a unique 64-bit Interface-Identifier to be used for the address autoconfiguration at the local end of the link. 5.2.4.2. IPv4CP In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain an IPv4 address from the SC. IPCP may also be used to obtain DNS information as described in [RFC1877]. 5.3. Global IPv6 Address Assignement to Endpoints In several scenarios defined in Section 3.1, Global IPv6 addresses are expected to be allocated to Softwire endpoints (in addition to the Link-Local addresses autoconfigured using the IPV6CP negotiated interface identifier). The Softwire Initiator assigns global IPv6 addresses using the IPV6CP negotiated interface identifier and using Stateless Address Autoconfiguration [RFC4862], and/or using Privacy Extensions for Stateless Address Autoconfiguration [RFC4941], (as described in Section 5 of [RFC5072]), and/or using DHCPv6 [RFC3315]. The Softwire Initiator of an IPv6 Softwire MUST send a Router Solicitation message to the Softwire Concentrator after IPV6CP is completed. The Softwire Concentrator MUST answer with a Router Advertisement. This message MUST contains the global IPv6 prefix of the PPP link if Neighbor Discovery is used to configure addresses of Softwire endpoints. If DHCPv6 is available for address delegation, the M bits of the Router Advertisement SHOULD be set. The Softwire Initiator MUST then send a DHCPv6 Request to configure the address of the Softwire Storer, et al. Expires August 1, 2008 [Page 27] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 endpoint. Duplicate Address Detection ([RFC4861]) MUST be performed on the Softwire in both cases. 5.4. DHCP The Softwire Initiator MAY use DHCP to get additional information such as delegated prefix and DNS servers. 5.4.1. DHCPv6 In the scenarions in Section 3.1, if the SI supports DHCPv6, it SHOULD send a Solicit message to verify if more information is available. If an SI establishing an IPv6 Softwire acts as a router (i.e., in the scenarios in Section 3.1.2 and Section 3.1.4) it MUST include the IA_PD option [RFC3633] in the DHCPv6 Solicit message [RFC3315] in order to request an IPv6 prefix. When delegating an IPv6 prefix to the SI by returning a DHCPv6 Advertise message with the IA_PD and IP_PD Prefix options [RFC3633], the SC SHOULD inject a route for this prefix in the IPv6 routing table in order to forward the traffic to the relevant Softwire. Configuration of DNS MUST be done as specified in [RFC3646] and transmitted according to [RFC3315] and [RFC3736]. In general, all DHCPv6 options MUST be transmitted according to [RFC3315] and [RFC3736]. 5.4.2. DHCPv4 An SI establishing an IPv4 Softwire MAY send a DHCP request containing the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc]. This practice is not common but may be used to connect IPv4 subnets using Softwires, as defined in Section 3.2.2 and Section 3.2.4. One Subnet-Request suboption MUST be configured with the 'h' bit set to '1', as the SI is expected to perform the DHCP server function. The 'i' bit of the Subnet-Request suboption SHOULD be set to '0' the first time a prefix is requested and to '1' on subsequent requests, if a prefix has been allocated. The Prefix length suboption SHOULD be 0 by default. If the SI is configured to support only specific prefix lengths, it SHOULD specify the longest (smallest) prefix length it supports. If the SI was previously assigned a prefix from that same SC, it Storer, et al. Expires August 1, 2008 [Page 28] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 SHOULD include the Subnet-Information suboption with the prefix it was previously assigned. The 'c' and 's' bits of the suboption SHOULD be set to '0'. In the scenarions in Section 3.2, when delegating an IPv4 prefix to the SI, the SC SHOULD inject a route for this prefix in the IPv4 routing table in order to forward the traffic to the relevant Softwire. 6. Considerations about the Address Provisioning Model This section describes how a Softwire Concentrator may manage delegated addresses for Softwire endpoints and for subnets behind the Softwire Initiator. One common practice is to aggregate endpoints' addresses and delegated prefixes into one prefix routed to the SC. The main benefit is to ease the routing scheme by isolating on the SC succeeding route injections (when delegating new prefixes for SI). 6.1. Softwire Endpoints' Addresses 6.1.1. IPv6 A Softwire Concentrator should provide globally routable addresses to Softwire endpoints. Other types of addresses such as Unique Local Addresses [RFC4193] may be used to address Softwire endpoints in a private network with no global connectivity. A single /64 should be assigned to the Softwire to address both Softwire endpoints. Global or ULA addresses must be assigned to endpoints when the scenario "Host CPE as Softwire Initiator" (described in Section 3.1.1) is considered to be deployed. For other scenarios, this may be optional and link local addresses should be used. 6.1.2. IPv4 A Softwire Concentrator may provide either globally routable or private IPv4 addresses. When using IPv4 private addresses [RFC1918] on the endpoints, it is not recommended to delegate an IPv4 private prefix to the SI, as it can lead to a nested-NAT situations. The endpoints of the PPP link use host addresses (i.e., /32), negotiated using IPCP. 6.2. Delegated Prefixes Storer, et al. Expires August 1, 2008 [Page 29] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 6.2.1. IPv6 Prefixes Delegated IPv6 prefixes should be of global scope if the IPv6 addresses assigned to endpoints are global. Using ULA addresses is not recommended when the subnet is connected to the global IPv6 Internet. When using ULA IPv6 address for endpoint, the delegated IPv6 prefix may be either of Global or ULA scope. Delegated IPv6 prefixes are between /48 and /64 in length. When an SI receives a prefix shorter than 64, it can assign different /64 prefixes to each of its interfaces. An SI receiving a single /64 is expected to perform bridging if more than one interface are available (e.g., wired and wireless). 6.2.2. IPv4 Prefixes Delegated IPv4 prefixes should be routable within the address space used by assigned IPv4 addresses. Delegate non-routable IPv4 prefixes (i.e., private IPv4 prefix over public IPv4 addresses or another class of private IPv4 addresses) is not recommended as a practice for provisioning and address translation should be considered in these cases. The prefix length is between /8 and /30. 6.3. Possible Address Provisioning Scenarios This section summarizes the differents scenarios for address provisioning with the considerations given in the previous sections. 6.3.1. Scenarios for IPv6 This table describes the possible combination of IPv6 address scope for endpoints and delegated prefixes. +------------------+-----------------------+------------------------+ | Endpoint IPv6 | Delegated Global IPv6 | Delegated ULA IPv6 | | Address | Prefix | Prefix | +------------------+-----------------------+------------------------+ | Link Local | Possible | Possible | | | | | | ULA | Possible | Possible | | | | | | Global | Possible | Possible, but Not | | | | Recommended | +------------------+-----------------------+------------------------+ Table 1: Scenarios for IPv6 Storer, et al. Expires August 1, 2008 [Page 30] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 6.3.2. Scenarios for IPv4 This table describes the possible combination of IPv4 address scope for endpoints and delegated prefixes. +-------------+-----------------+-----------------------------------+ | Endpoint | Delegated | Delegated Private IPv4 Prefix | | IPv4 | Public IPv4 | | | Address | Prefix | | +-------------+-----------------+-----------------------------------+ | Private | Possible | Possible, but Not Recommended | | IPv4 | | when using NAT (cf. | | | | Section 6.1.2) | | | | | | Public IPv4 | Possible | Possible, but NAT usage is | | | | recommended (cf. Section 6.2.2) | +-------------+-----------------+-----------------------------------+ Table 2: Scenarios for IPv4 7. Considerations about Address Stability A Softwire can provide stable addresses even if the underlying addressing scheme changes, by opposition to automatic tunneling. A Softwire Concentrator should always provide the same address and prefix to a reconnecting user. However, if the goal of the Softwire service is to provide a temporary address for a roaming user, it may be provisioned to provide only a temporary address. The address and prefix are expected to change when reconnecting to a different Softwire Concentrator. However an organization providing a Softwire service may provide the same address and prefix across different Softwire Concentrators at the cost of a more fragmented routing table. The routing fragmentation issue may be limited if the prefixes are aggregated in a location topologically close to the SC. This would be the case for example if several SCs are put in parallel for load-balancing purpose. 8. Considerations about RADIUS Integration The Softwire Concentrator is expected to act as a client to a AAA server, for example a RADIUS server. During the PPP authentication phase, the RADIUS server may return additional informations in the form of attributes in the Access-Accept message. The Softwire Concentrator may include the Tunnel-Type and Tunnel- Storer, et al. Expires August 1, 2008 [Page 31] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 Medium-Type attributes [RFC2868] in the Access-Request messages to provide a hint of the type of Softwire being configured. 8.1. Softwire Endpoints 8.1.1. IPv6 Softwires If the RADIUS server includes a Framed-Interface-Id attribute [RFC3162], the Softwire Concentrator must send it to the Softwire Initiator in the Interface-Identifier field of its IPV6CP Configuration Request message. If the Framed-IPv6-Prefix attribute [RFC3162] is included, that prefix must be used in the router advertisements sent to the SI. If Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC must choose a prefix with that pool to send RAs. If none of the attributes above are included but the AAA server returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] with the correct address family, these must be used in the IPV6CP Interface-Identifier and for the Router Advertisements. 8.1.2. IPv4 Softwires If the Framed-IP-Address attribute [RFC2865] is present, the Softwire Concentrator must provide that address to the Softwire Initiator during IPCP address negotiation. That is, when the Softwire Initiator requests an IP address from the Softwire Concentrator, the address provided should be the Framed-IP-Address. If the Framed-IP-Address attribute is not present and the Tunnel- Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are present and of the correct address family, these should be used in the IPCP IP-Address configuration option. 8.2. Delegated Prefixes 8.2.1. IPv6 Prefixes If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the RADIUS Access-Accept message, it must be used by the Softwire Concentrator for the delegation of the IPv6 prefix. Since the prefix delegation is performed by DHCPv6 and the attribute is linked to a username, the SC must associate the DHCP Unique Identifier (DUID) of a DHCPv6 request to the tunnel it came from and its user. Interaction between RADIUS, PPP and DHCPv6 server may follow the Storer, et al. Expires August 1, 2008 [Page 32] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. In this case, during the Softwire authentication phase, PPP collects the RADIUS attributes for the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is assigned to the Softwire. The DHCPv6 relay fills in these attributes in the Relay agent RADIUS Attribute Option (RRAO) DHCPv6 option, before forwarding the DHCPv6 requests to the DHCPv6 server. 8.2.2. IPv4 Prefixes The combination of the Framed-IP-Address and Framed-IP-Netmask attributes [RFC2865] may be used by the Softwire Concentrator to delegate an IPv4 prefix to the Softwire Initiator. 9. Considerations for Maintenance and Statistics 9.1. RADIUS Accounting RADIUS Accounting for L2TP and PPP are documented (see Section 4.3). When deploying Softwire solutions, operators may experience difficulties to differentiate the address family of the traffic reported in accounting information from RADIUS. This problem and some potential solutions are described in [I-D.stevant-softwire-accounting]. 9.2. MIBs MIB support for L2TPv2 and PPP are documented (see Section 4.4). Also see [RFC4293]. 10. Security Considerations A detailed discussion of Softwire security is contained in [I-D.ietf-softwire-security-requirements]. The L2TPv2 Softwire solution provides the following tools for security: o IPsec [RFC4301] with IKEv2 [RFC4306] provides the highest level of security. [RFC3193] describes interaction between IPsec and L2TPv2. o PPP CHAP [RFC1994] provides basic user authentication. Storer, et al. Expires August 1, 2008 [Page 33] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 o L2TP Tunnel Authentication [RFC2661] provides authentication at tunnel setup. It may be used to limit DoS attacks by authenticating the tunnel before L2TP session and PPP resources are allocated. 11. IANA Considerations This document creates no new requirements on IANA namespaces [RFC2434]. 12. Acknowledgements The authors would like to acknowledge the following contributors who provided helpful input on this document: Florent Parent, Jordi Palet Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, Francis Dupont and Ralph Droms. The authors would also like to acknowledge the participants in the Softwires interim meetings held in Hong Kong, China and Barcelona, Spain. The minutes for the interim meeting at the China University - Hong Kong (February 23-24, 2006) are at . The minutes for the interim meeting at Polytechnic University of Catalonia - Barcelona (September 14-15, 2006) are reachable at . 13. References 13.1. Normative References [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Storer, et al. Expires August 1, 2008 [Page 34] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two Tunneling Protocol "L2TP" Management Information Base", RFC 3371, August 2002. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. Storer, et al. Expires August 1, 2008 [Page 35] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007. 13.2. Informative References [I-D.ietf-dhc-subnet-alloc] Johnson, R., "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-06 (work in progress), November 2007. [I-D.ietf-dhc-v6-relay-radius] Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option", draft-ietf-dhc-v6-relay-radius-02 (work in progress), February 2006. [I-D.ietf-softwire-security-requirements] Yamamoto, S., Williams, C., Parent, F., and H. Yokota, "Softwire Security Analysis and Requirements", draft-ietf-softwire-security-requirements-05 (work in progress), December 2007. [I-D.stevant-softwire-accounting] Stevant, B., "Accounting on Softwires", draft-stevant-softwire-accounting-01 (work in progress), October 2006. [RFC1471] Kastenholz, F., "The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol", RFC 1471, June 1993. [RFC1473] Kastenholz, F., "The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol", RFC 1473, June 1993. [RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses", RFC 1877, December 1995. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998. [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting Storer, et al. Expires August 1, 2008 [Page 36] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 Modifications for Tunnel Protocol Support", RFC 2867, June 2000. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4293] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006. [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. Storer, et al. Expires August 1, 2008 [Page 37] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 Appendix A. Revision History [Note to RFC Editor: please remove this entire appendix, and the corresponding entries in the table of contents, prior to publication.] Changes between -07 and -08: o Corrected the usage of Softwire vs. Softwires throughout the document, esp. when used as an adjective. o Editorial: Re-arranged "Contributing Authors" (Section 1.3). o Miscellaneous editorial corrections, readability improvements, completed the Abbreviations Section 1.1. o Added Section 2.3 about "Routing". o In all the Deployment Scenarios (Section 3), clarified that the description is after successful LCP negotiation and optional PPP Authentication. Corrected "DHCPv6" in Figure 1 and Figure 3. o Removed /48 example from Section 3.1.2 and Section 3.1.4. o Added reference and corresponding citations to [RFC2132] in Section 3.2. o Completed the citations on Section 4.5, adding [RFC4862], [RFC3633], [RFC2131], and [RFC2132]. o Moved the last two sentences of Section 5.4 to Section 5.4.1 and Section 5.4.2 respectively. o Completed the first paragraph of Section 5.3, adding an informational reference to [RFC4941]. o Added DHCPv4 to Figure 10 for the IPv4 over IPv6 scenarios. Added a follow-on clarifying paragraph about PPP NCP and DHCP versions used in each softwire scenario. o Clarification of implementation versus usage of the optional AVPs in Section 5.1.1.2. o Added text including [RFC3736] for DHCPv6. Changes between -06 and -07: Storer, et al. Expires August 1, 2008 [Page 38] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 o Changed RFC numbers: RFC2461 and I-D 2461(bis) to [RFC4861], RFC2462 to [RFC4862], and RFC2472 and I-D.ietf-ipv6-over-ppp-v2 to [RFC5072]. Changes between -05 and -06: o Swapped Section 4.1 and Section 4.2. Renamed Section 4.2 to "Securing the Softwire Transport". o In Section 5.2.1, added a mention that the MTU should be lower that 1460 when using IPsec. o In Section 10, added pointers to [RFC4301] and [RFC4306]. Changes between -04 and -05: o Replaced "documentation" with "logging purposes" in Section 5.1.1.1. o Added suggested values (only as guidance) for Keepalives in Section 5.1.2. Changes between -03 and -04: o Added missing references to [RFC4087], [RFC4861], and [RFC3646], moved [RFC4623] to Informative. o Rephrasing in Section 6.2.2. Added pointers Section 6.1.2 and Section 6.2.2 in Table 2. o Added citations (and corresponding references) to [RFC1471] and [RFC1473] in Section 4.4, since Section 9.2 explicitly mentions: "MIB support for L2TPv2 and PPP are documented." o Fixed some RFC2119 keywords in Section 3.1.1, Section 3.1.2, Section 3.1.3, Section 3.1.4, Section 3.2.1, Section 3.2.2, Section 3.2.3, Section 3.2.4, Section 5.1.1.3, Section 5.4.2, and Section 8.1.1. o Added [RFC2868] to Section 4.3, and added missing citations to Section 4. o Added missing "Optional AVP" to Figure 11. o Updated the text in Section 6.2.2. o Added some clarifying sentences in Section 5.1.1, and completed Section 5.1.1.1 and Section 5.1.1.2. Storer, et al. Expires August 1, 2008 [Page 39] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 o Added an Informative reference to [RFC3022] for NAT/NAPT. o Corrected reference to [RFC1661] in Section 5.2.2, removed reference and citation to RFC1662. o Updated references, Delegated-IPv6-Prefix became [RFC4818] moved to Normative. o Added new address and email for J.F. Tremblay. o Added an acknowledgement to the participants, and pointer to the minutes, for the Barcelona interim meeting. o Moved the Softwire Problem Statement reference [RFC4925] to Informative. o Some additional purely editorial changes. Changes between -02 and -03: o Boiler changes in support of RFC 4748. o Added text about L2TPv2 HELLO and LCP ECHO usage in Section 1, Section 2.7 and Section 5.1.2. o Moved some downref to Informative ([RFC1877], [RFC2433], [RFC2867], [RFC2868], and [RFC3748]), and moved CHAP reference to Normative ([RFC1994]). o Removed the mention and citation for PAP authentication. Changes between -01 and -02: o Renamed all "Best Current Practices" sections as "Recommendations". See for example Section 1.4. o Moved Provisioning in Section 6. Removed intro text to new Section 7. o Removed all normative language from Section 6, Section 7, Section 8, and Section 9. o Removed empty sections "Implementation Status", and "Open Issues". o Fixed "Phase 0" in Section 1. o Small changes to Section 3.1. Storer, et al. Expires August 1, 2008 [Page 40] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 o Change L2TP -> L2TPv2 in some sections, including Section 6. o Small additions and typo fixes in Section 5.1.1.1 and Section 5.1.1.2. o Retitled Section 8 and Section 8.1, changed AAA -> RADIUS. o New paragraph in Section 9.1. o New paragraph in Section 8.2.1, including a pointer to [I-D.ietf-dhc-v6-relay-radius]. o Moved last paragraph to start of Section 10. o Moved some references from Normative to Informative. o Label the steps in Figure 9 and Figure 10. o Reword paragraph of Section 5.1. o Describe more messages than flows in Figure 11 and Figure 12. o Add text about Session Establishment between Figure 11 and Figure 12. o Section 5.1.1.1 and Section 5.1.1.2: Updates on Hostname AVP, Framing Capabilities AVP, Framing Type AVP, Connect Speed AVP and Challenge and Challenge Response AVPs. o Retitled Section 5.1.1.3. o Updates on the use of L2TP HELLO versus LCP, delay for Dead-End peer detection, and allow LCP. o Rewording in Section 5.1.3. o Section 5.2.1: Add a pointer to [RFC4623] and small updates. o Clarifications on PFC and ACFC, remove Figure 13. o Section 5.2.3: make references to RFCs for PAP, CHAP, etc. o Rewordings in Section 5.2.4.1 and Section 5.2.4.2. o Added Informative references to [RFC4623], [RFC1661], [RFC2433], and [RFC3748]. Storer, et al. Expires August 1, 2008 [Page 41] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 o Renamed the title and added more details on Section 5.3 and IPv6 ND, including a pointer to I-D.ietf-ipv6-2461bis. o Added text in Section 5.4 about IPv4 PD is non-trivial and non commonly done. o Added B. Stevant as Editor. o Clarification in Section 5.2.4.1 and Section 5.2.4.2 regarding the scope of the MUST (to the specific scenarios). o Removed considerations about reverse DNS from Section 6, agreed on Barcelona. o Clarified the NAT case in Section 6.1.2 o Added first paragraph in Section 6.2.1 regarding delegated IPv6 prefixes. o Added new Section 6.3, Section 6.3.1 and Section 6.3.2 summarizing the scenarios for address allocation. Changes between -00 and -01: o Changed alignment in all figures to be centered, and fixed Figure 9 reference. o Section 1.4: Added new section with "Best Current Practices" definition. o Marked the following sections as "Best Current Practices": Section 6, Section 8, and Section 9. o Section 6.1.1, last paragraph: Removed sentence on IPv6 link address on the PPP link. Mailing list comment from Florent Parent, 13-Jul-2006. o Section 6.1.2, last paragraph: Changed IPv4 PPP link address to use host addresses (/32) negotiated with IPCP instead of /30. Mailing list comment from Bill Storer, 5-Jul-2006. o Section 5, Figure 10: Correction, s/SCCSN/SCCCN/; added missing ICRP, and changed direction of ICCN; typo correction s/IPV6P/ IPV6CP/. Mailing list comment from Bill Storer, 5-Jul-2006. o Section 5, Figure 10: Marked CHAP as "Optional - CHAP". Storer, et al. Expires August 1, 2008 [Page 42] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 o Section 5.1, Section 5.1.1, and Section 5.1.3: Minor typographical error correction and rewording of some sentences for grammar. o Section 5.1.1.1, Host Name AVP: Removed "for debugging purposes" and added that MAY be used to authenticate users. o Section 5.1.1.1, Framing Capabilities AVP: Swapped SHOULD and MUST. Mailing list comment from Bill Storer, 5-Jul-2006, text from Laurent Toutain. o Section 5.1.1.1, (Tx) Connect Speed: Correction: "but is *not* meaningful". o Section 5.1.1.2, Challenge and Challenge Response AVPs: Removed the last sentence of the first paragraph. Mailing list comment from Bill Storer, 5-Jul-2006, text from Laurent Toutain. o Section 5.1.2: Rewrote paragraph to use L2TPv2 HELLO messages and not LCP Echo Request and Reply messages to detect tunnel failure, as redundant in Softwires. Mailing list comment from Florent Parent, 10-Jul-2006, text from Bill Storer. o Section 5.2.1, first paragraph: Fixed PPP MTU calculation. Mailing list comment from Florent Parent, 10-Jul-2006. o Section 5.2.4.2: Rewrote to generalize the address assignment failure, to be an all-zeroes address or a protocol reject in response to the IPCP CONFREQ. Mailing list comment from Bill Storer, 5-Jul-2006, text from JF Tremblay. o Section 8, second paragraph: s/Tunnel-Medium /Tunnel-Type /. Mailing list comment from Bill Storer, 5-Jul-2006. o Section 8.1.2: Added usage of Framed-IP-Address attribute, and if not present then use the Tunnel-Client-Endpoint and Tunnel-Server- Endpoint attributes. Mailing list comment from Bill Storer, 5-Jul-2006, text from JF Tremblay and Bill Storer. o Completed Section 8.2.2, Section 9.1, Section 9.2, and Section 10. Revision -00: o Initial revision. Storer, et al. Expires August 1, 2008 [Page 43] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 Authors' Addresses Bill Storer Cisco Systems 170 W Tasman Dr San Jose, CA 95134 USA Email: bstorer@cisco.com Carlos Pignataro (editor) Cisco Systems 7200 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA Email: cpignata@cisco.com Maria Alice Dos Santos Cisco Systems 170 W Tasman Dr San Jose, CA 95134 USA Email: mariados@cisco.com Bruno Stevant (editor) TELECOM Bretagne 2 rue de la Chataigneraie CS17607 Cesson Sevigne, 35576 France Email: bruno.stevant@telecom-bretagne.eu Jean-Francois Tremblay Trellia Networks 100, Alexis-Nihon, Suite 770 Montreal, QC H4M 2P3 Canada Email: jf@jftremblay.com Storer, et al. Expires August 1, 2008 [Page 44] Internet-Draft Softwire H & S Framework with L2TPv2 January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Storer, et al. Expires August 1, 2008 [Page 45]