view Side-By-Side changes
Softwires Working Group B. Storer, Ed. Internet-Draft C. Pignataro, Ed. Intended status: Standards Track M. DosSantos, Ed.Santos Expires:February 26,May 21, 2007 Cisco Systems J.Tremblay, Ed.Tremblay HexagoL. Toutain,B. Stevant, Ed. GET/ENST BretagneAugust 25,November 17, 2006 Softwires Hub & Spoke Deployment Framework with L2TPv2draft-ietf-softwire-hs-framework-l2tpv2-01.txtdraft-ietf-softwire-hs-framework-l2tpv2-02 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 onFebruary 26,May 21, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the framework of the Softwire"Hubs"Hub andSpokes"Spoke" solution with Layer 2 Tunneling Protocol (L2TPv2), and the implementation details specified in this document should be followed Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 1] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 to achieve inter-operability 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.Best Current PracticesConsiderations . . . . . . . . . . . . . . . . . . . . . . 6 2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7 2.1. Network and Port Address Translation (NAT/PAT) . . . . . . 7 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Authentication, Authorization and Accounting . . . . . . . 7 2.5. Privacy, Integrity, and Replay Protection . . . . . . . . 8 2.6. Operations and Management (OAM) . . . . . . . . . . . . . 8 2.7. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 8 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 8 3.1. IPv6 over IPv4 Softwire 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 . . . . . . . . 11 3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 12 3.2. IPv4 over IPv6 Softwire with L2TPv2 . . . . . . . . . . . 13 3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 13 3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 14 3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 15 3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 16 4. Standardisation Status . . . . . . . . . . . . . . . . . . . . 17 4.1. Softwire Transport Related . . . . . . . . . . . . . . . . 17 4.2. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Authentication Authorization Accounting . . . . . . . . . 18 4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 18 4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 18 4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 18 5.Provisioning Model - Best Current Practices . . .Softwire Establishment . . . . . .19 5.1. Link Addresses. . . . . . . . . . . . . . 18 5.1. L2TPv2 Tunnel Setup . . . . . . . .19 5.1.1. IPv6. . . . . . . . . . . 20 5.1.1. Tunnel Establishment . . . . . . . . . . . . . .19 5.1.2. IPv4. . . 21 5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 23 5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . .19 5.2. Delegated Prefixes24 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 24 5.1.2. Tunnel Maintenance . . . . . . . . . . .20 5.2.1. IPv6 Prefixes. . . . . . . 24 Storer, et al. Expires May 21, 2007 [Page 2] Internet-Draft Softwires H & S Framework with L2TPv2 November 2006 5.1.3. Tunnel Teardown . . . . . . . . . . . . .20 5.2.2. IPv4 Prefixes. . . . . . 24 5.2. PPP Connection . . . . . . . . . . . . . .20 Storer, et al. Expires February 26, 2007 [Page 2] Internet-Draft Softwires H & S Framework with L2TPv2 August 2006 6. Softwire Establishment. . . . . . . . 24 5.2.1. MTU . . . . . . . . . . . .21 6.1. L2TP Tunnel Setup. . . . . . . . . . . . . 24 5.2.2. LCP . . . . . . .22 6.1.1. Tunnel Establishment. . . . . . . . . . . . . . . . .23 6.1.1.1. AVPs Required for Sotftwires. 25 5.2.3. Authentication . . . . . . . . . .25 6.1.1.2. AVPs Optional for Sotftwires. . . . . . . . . . 25 5.2.4. IPCP .26 6.1.1.3. AVPs not Required for Softwires. . . . . . . . .26 6.1.2. Tunnel Maintenance. . . . . . . . . . . . . . . 25 5.2.4.1. IPv6CP . . .26 6.1.3. Tunnel Teardown. . . . . . . . . . . . . . . . . . .27 6.2. PPP Connection25 5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . .27 6.2.1. MTU25 5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 25 5.4. DHCP . . . . . . . . . . . . . . . . . .27 6.2.2. LCP. . . . . . . . . 26 5.4.1. DHCPv6 . . . . . . . . . . . . . . . .27 6.2.3. Authentication. . . . . . . . 26 5.4.2. DHCPv4 . . . . . . . . . . . .28 6.2.4. IPCP. . . . . . . . . . . . 26 6. Considerations about the Address Provisioning Model . . . . . 27 6.1. Softwire Endpoints Addresses . . . . . . . .28 6.2.4.1. IPv6CP. . . . . . . 27 6.1.1. IPv6 . . . . . . . . . . . . . . .28 6.2.4.2. IPv4CP. . . . . . . . . . 27 6.1.2. IPv4 . . . . . . . . . . . .29 6.3. Neighbor Discovery. . . . . . . . . . . . . 27 6.2. Delegated Prefixes . . . . . . .29 6.4. DHCP. . . . . . . . . . . . . 27 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . .29 6.4.1. DHCPv6. . . . . . 27 6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . .29 6.4.2. DHCPv4. . 28 6.3. Possible scenarios . . . . . . . . . . . . . . . . . . . . 28 6.3.1. Scenarios for IPv6 . .29 7. AAA - Best Current Practices. . . . . . . . . . . . . . . .. 30 7.1. Tunnel Endpoints28 6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 28 7. Considerations about Address Stability . . .30 7.1.1. IPv6 Softwires. . . . . . . . . 29 8. Considerations about RADIUS Integration . . . . . . . . . . .30 7.1.2. IPv429 8.1. Softwires Endpoints . . . . . . . . . . . . . . . . . . .. 30 7.2. Delegated Prefixes29 8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . .31 7.2.1. IPv6 Prefixes30 8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . .31 7.2.2. IPv430 8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . .31 8. Maintenance and Statistics - Best Current Practices . . . . . 31 8.1. Radius Accounting . . . . . . .30 8.2.1. IPv6 Prefixes . . . . . . . . . . . . .31 8.2. MIBs. . . . . . . 30 8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 31 9.SecurityConsiderations. . . . . . . . . . .for Maintenance and Statistics . . . . . . . . 3110. Implementation status . . . . . . . . . . . .9.1. RADIUS Accounting . . . . . . . .32 11. Open issues. . . . . . . . . . . . 31 9.2. MIBs . . . . . . . . . . . . .32 11.1. Fragmentation and MTU. . . . . . . . . . . . . . 31 10. Security Considerations . . . .32 11.2. AAA Accounting (other draft). . . . . . . . . . . . . . .32 12.31 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3213.12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3214.13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3214.1.13.1. Normative References . . . . . . . . . . . . . . . . . . . 3214.2.13.2. Informative References . . . . . . . . . . . . . . . . . . 34 Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 3] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .3638 Intellectual Property and Copyright Statements . . . . . . . . . .3840 Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 4] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 1. Introduction The Softwires Working Group has selected Layer Two Tunneling Protocol version 2 (L2TPv2) as the phaseI1 protocol to be deployed in the Softwires "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 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 Softwires 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 Channel, a single 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 across the access network of another Address Family. During the life of the Softwire, both SI and SC may send L2TPv2 keepalive HELLO messages to monitor the health of the Softwire and the peer LCCE or to refresh the NAT/PAT translation entry at the CPE or at the other end of the access link. In the event of keepalive Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 5] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 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 LCCE L2TP Control Connection Endpoint (See [RFC3931]) SC Softwire Concentrator, the node terminating thesoftwireSoftwire in the service provider network (See [I-D.ietf-softwire-problem-statement]) SI Softwire Initiator, the node initiating thesoftwireSoftwire within the customer network (See [I-D.ietf-softwire-problem-statement]) STH Softwire Transport Header (See [I-D.ietf-softwire-problem-statement]) SPH Softwire Payload Header (See [I-D.ietf-softwire-problem-statement]) 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 Carlos Pignataro Bill Storer Cisco Systems Jean-Francois Tremblay Hexago Laurent Toutain Bruno Stevant GET/ENST Bretagne 1.4.Best Current PracticesConsiderations Some sections of this document containrecommendationsconsiderations that are not required for interoperability and correct operation ofsoftwiresSoftwire implementations. These sections are marked as"Best Current Practices"."Considerations". Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 6] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 2. Applicability of L2TPv2 for Softwire Requirements A list of Softwire "Hubs and Spokes" requirements have been identified by the Softwire Problem Statement [I-D.ietf-softwire-problem-statement]. The following section describes how L2TPv2 fulfills each of them. 2.1. Network and Port Address Translation (NAT/PAT) A "Hubs and Spokes" Softwire must be able to traverse NAT/PAT in case the scenario in question involves a non-upgradable pre-existing IPv4 home gateway performing NAT/PAT or some carrier equipment at the other end of the access link performing NAT/PAT. The L2TPv2 Softwire (i.e. Control Channel and Session) is capable of NAT/PAT traversal since L2TPv2 can run over UDP. Since L2TPv2 does not "autodetect" NAT/PAT along the path, L2TPv2 does not offer UDP bypass regardless of NAT/PAT presence. Both NAT/ PAT "autodetect" and UDP bypass are optional requirements. 2.2. Scalability In the "Hubs and Spokes" model, a carrier must be able to scale the solution to millions ofsoftwireSoftwire initiators by adding more hubs (i.e.softwireSoftwire 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. Multicast Multicast protocols simply run over L2TPv2 Softwires transparently together with other regular IP traffic. 2.4. Authentication, Authorization and Accounting 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. Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 7] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 2.5. 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.6. 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. 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 can be used to monitor connectivity status between the SI and SC and/or as a refresh mechanism for any NAT/PAT translation entry along the access link. 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 events. 2.7. 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/PAT. 3. Deployment Scenarios For the "Hubs and Spokes" problem space, four scenarios have been Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 8] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 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 and IPv4 over IPv6 encapsulations. 3.1. IPv6 over IPv4 Softwire with L2TPv23.1.1. Host CPE as Softwire InitiatorThe following subsections cover IPv6 connectivity across an IPv4-only access network using a Softwire. 3.1.1. Host CPE as SoftwireTransport Header (STH).Initiator Softwire initiator 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. In this scenario, IPv6CP negotiates IPv6 over PPP which also provides the capability for the ISP to assign the 64-bit Interface Id to the host CPE or perform uniqueness validation for the two Interface Ids at the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can assign a 64-bit global prefix to the host CPE via Router Advertisement (RA) while other configuration options (such as DNS) can be conveyed to the host CPE via DHCPv6/v4. Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 9] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 IPv6 or dual-stack IPv4-only dual-stack |------------------||-----------------||----------| I SC SI N +-----+ +----------+ T | | | v4/v6 | E <==[ IPv6]....|v4/v6|....[IPv4-only]....|]....|v4/v6|....[IPv4~only]....| host CPE | R [network] | | [ network ] | | N | LNS | |LAC Client| E +-----+ +----------+ T _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic PPP o L2TPv2 o UDP o IPv4"softwire"Softwire <------------------> IPv6CP: capable of /64 intf Id assignment or uniqueness check |------------------>/64 prefix RA |------------------>DNS, etc. DHCPv6/v4 Figure 1: Host CPE as Softwire Initiator 3.1.2. Router CPE as Softwire InitiatorIPv6 connectivity across an IPv4-only access network (STH).Softwire initiator is the router CPE, which is a dual-stack device. The IPv4 traffic should not traverse thesoftwire.Softwire. In this scenario, IPv6CP negotiates IPv6 over PPP which also provides the capability for the ISP to assign the 64-bit Interface Id to the router CPE or perform uniqueness validation for the two Interface Ids at the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can assign a 64-bit global prefix to the router CPE via Router Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g. delegating a 48-bit prefix to be used within the home network) and convey other configuration options (such as DNS) to the router CPE. Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 10] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 IPv6 or dual-stack IPv4-only dual-stack |------------------||-----------------||---------------------| I SC SI N +-----+ +----------+ T | | | v4/v6 | +-----+ E <==[ IPv6]....|v4/v6|....[IPv4-only]....|]....|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"softwire"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 3.1.3. Host behind CPE as Softwire InitiatorIPv6 connectivity across an IPv4-only access network (STH).The CPE is IPv4-only. Softwire initiator is a dual-stack host (behind IPv4- only CPE), which acts as an IPv6 host CPE. The IPv4 traffic should not traverse thesoftwire.Softwire. In this scenario, IPv6CP negotiates IPv6 over PPP which also provides the capability for the ISP to assign the 64-bit Interface Id to the host or perform uniqueness validation for the two Interface Ids at the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can assign a 64-bit global prefix to the host via Router Advertisement (RA) while other configuration options (such as DNS) can be conveyed to the host via DHCPv6/v4. Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 11] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 IPv6 or dual-stack IPv4-only dual-stack |------------------||----------------------------||----------| I SC SI N +-----+ +----------+ T | | +-------+ | v4/v6 | E <==[ IPv6]....|v4/v6|....[IPv4-only]....|v4-only|--|]....|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"Softwire <------------------------------> IPv6CP: capable of /64 intf Id assignment or uniqueness check |------------------------------>/64 prefix RA |------------------------------>DNS, etc. DHCPv4/v6 Figure 3: Host behind CPE as Softwire Initiator 3.1.4. Router behind CPE as Softwire InitiatorIPv6 connectivity across an IPv4-only access network (STH).The CPE is IPv4-only. Softwire initiator 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 thesoftwire.Softwire. In this scenario, IPv6CP negotiates IPv6 over PPP which also provides the capability for the ISP to assign the 64-bit Interface Id to the v4/v6 router or perform uniqueness validation for the two Interface Ids at the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can assign a 64-bit global prefix to the v4/v6 router via Router Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (for example, delegating a 48-bit prefix to be used within the home network) and convey other configuration options (such as DNS) to the v4/v6 router. Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 12] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 IPv6 or dual-stack IPv4-only dual-stack |------------------||-------------------------||-------------| I SC SI N +-----+ +----------+ T | | +-------+ | v4/v6 | E <==[ IPv6]....|v4/v6|..[IPv4-only]..|v4-only|---|]....|v4/v6|..[IPv4~only]..|v4-only|---| router | R [network] | | [ network ] | CPE | | | | N | LNS | +-------+ | |LAC Client| E +-----+ | +----------+ T | ---------+-----+ |v4/v6| | host| _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ ()_ _ _ _ _ _ _ _ _ _ _ _ _() <--IPv6 traffic PPP o L2TPv2 o UDP o IPv4"softwire"Softwire <---------------------------> IPv6CP: capable of /64 intf Id assignment or uniqueness check |--------------------------->/64 prefix RA |--------------------------->/48 prefix, DHCPv6 DNS, etc. |----> /64 RA prefix |----> DNS, DHCPv4/v6 etc. Figure 4: Router behind CPE as Softwire Initiator 3.2. IPv4 over IPv6 Softwire with L2TPv23.2.1. Host CPE as Softwire InitiatorThe following subsections cover IPv4 connectivity across an IPv6-only access network(STH).using a Softwire. 3.2.1. Host CPE as Softwire Initiator Softwire initiator 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 thesoftwire.Softwire. In this scenario, IPCP negotiates IPv4 over PPP which also provides the capability for the ISP to assign a global IPv4 address to thehostStorer, et al. Expires May 21, 2007 [Page 13] Internet-Draft Softwires H & S Framework with L2TPv2 November 2006 host CPE. Global IPv4 address can also be assigned via DHCP. Other configuration options (such as DNS) can be conveyed to the host CPEStorer, et al. Expires February 26, 2007 [Page 13] Internet-Draft Softwires H & S Framework with L2TPv2 August 2006via IPCP [RFC1877] or DHCP. IPv4 or dual-stack IPv6-only dual-stack |------------------||-----------------||---------| I SC SI N +-----+ +----------+ T | | | v4/v6 | E <==[ IPv4]....|v4/v6|....[IPv6-only]....|]....|v4/v6|....[IPv6~only]....| host CPE | R [network] | | [ network ] | | N | LNS | |LAC Client| E +-----+ +----------+ T _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic PPP o L2TPv2 o UDP o IPv6"softwire"Softwire <------------------> IPCP: capable of global IP assignment and DNS, etc. Figure 5: Host CPE as Softwire Initiator 3.2.2. Router CPE as Softwire Initiator IPv4 connectivity across an IPv6-only access network (STH). Softwire initiator is the router CPE, which is a dual-stack device. The IPv6 traffic should not traverse thesoftwire.Softwire. In this scenario, IPCP negotiates IPv4 over PPP which also provides the capability for the ISP to assign a global IPv4 address to the router CPE. 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. For IPv4 Prefix Delegation for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used. Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 14] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 IPv4 or dual-stack IPv6-only dual-stack Home |------------------||-----------------||-------------------| I SC SI N +-----+ +----------+ T | | | v4/v6 | +-----+ E <==[ IPv4]....|v4/v6|....[IPv6-only]....|]....|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"softwire"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 3.2.3. Host behind CPE as Softwire Initiator IPv4 connectivity across an IPv6-only access network (STH). The CPE is IPv6-only. Softwire initiator is a dual-stack host (behind the IPv6 CPE), which acts as an IPv4 host CPE. The IPv6 traffic should not traverse thesoftwire.Softwire. In this scenario, IPCP negotiates IPv4 over PPP which also provides the capability for the ISP to assign a global IPv4 address to the host. 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. Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 15] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 IPv4 or dual-stack IPv6-only dual-stack |------------------||----------------------------||----------| I SC SI N +-----+ +----------+ T | | +-------+ | v4/v6 | E <==[ IPv4]....|v4/v6|....[IPv6-only]....|v6-only|--|]....|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"Softwire <------------------------------> IPCP: capable of global IP assignment and DNS, etc. Figure 7: Host behind CPE as Softwire Initiator 3.2.4. Router behind CPE as Softwire Initiator IPv4 connectivity across an IPv6-only access network (STH). The CPE is IPv6-only. Softwire initiator 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 thesoftwire.Softwire. In this scenario, IPCP negotiates IPv4 over PPP which also provides the capability for the ISP to assign a global IPv4 IP address to the v4/v6 router. 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. For IPv4 Prefix Delegation for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used. Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 16] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 IPv4 or dual-stack IPv6-only dual-stack |------------------||-------------------------||------------| I SC SI N +-----+ +----------+ T | | +-------+ | v4/v6 | E <==[ IPv4]....|v4/v6|..[IPv6-only]..|v6-only|---|]....|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"Softwire <---------------------------> 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 4. Standardisation Status 4.1. Softwire Transport Related RFC 3193 Securing L2TP using IPsec. RFC 3948 UDP Encapsulation of IPsec ESP Packets. IPSec supports both IPv4 and IPv6 transports. 4.2. L2TPv2 Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 17] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 RFC 2661 Layer Two Tunneling Protocol "L2TP". For both IPv4 and IPv6 payloads, support is complete. For both IPv4 and IPv6 transport, support is complete. 4.3. Authentication Authorization Accounting RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol Support.Need new extensions for IPv6 traffic accounting [I-D.stevant-softwire-accounting].RFC 2865 Remote Authentication Dial In User Service (RADIUS). RFC 3162 RADIUS and IPv6. 4.4. MIB RFC 3371 Layer Two Tunneling Protocol "L2TP" Management Information Base. RFC 4087 IP Tunnel MIB. Both IPv4 and IPv6 transport is supported.Do we need a new set of counters for IPv6 Payloads? l2tpDomainStatsPayloadHCRxOctets l2tpDomainStatsPayloadHCRxPkts l2tpDomainStatsPayloadHCRxDiscs l2tpDomainStatsPayloadHCTxOctets l2tpDomainStatsPayloadHCTxPkts4.5. Softwire Payload Related 4.5.1. For IPv6 Payloads RFC 2472 IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2]. RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). RFC 2461 Neighbor Discovery for IP Version 6 (IPv6). 4.5.2. For IPv4 PayloadsStorer, et al. Expires February 26, 2007 [Page 18] Internet-Draft Softwires H & S Framework with L2TPv2 August 2006RFC 1661 The Point-to-Point Protocol (PPP). RFC 1332 The PPP Internet Protocol Control Protocol (IPCP). DHCP Subnet Allocation Work in progress [I-D.ietf-dhc-subnet-alloc]. 5.Provisioning Model - Best Current Practices A softwire can provide stable addressing even if the underlying addressing scheme changes, by opposition to automatic tunneling.Softwire Establishment A SoftwireConcentrator SHOULD always provide the same address and prefix to a reconnecting user. However, if the goal of the softwire serviceisto provide a temporary address forestablished in 3 distinct steps (Figure 9). First aroaming user, it MAY be provisioned to provide onlyL2TPv2 tunnel with atemporary address. The address and prefixsingle session isexpected to change when reconnectingestablished from the SI to the Storer, et al. Expires May 21, 2007 [Page 18] Internet-Draft Softwires H & S Framework with L2TPv2 November 2006 SC. Second adifferent Softwire Concentrator. However an organization providing a softwire service MAY providePPP session is established over thesame addressL2TPv2 session andprefix across different Softwire Concentrators atthecost of a more fragmented routing table. The routing fragmentation issue may be limited ifSI obtains an address. Third theprefixes 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. 5.1. Link Addresses 5.1.1. IPv6 A Softwire Concentrator SHOULD provide globally routable addresses and prefixes to Softwire Initiators. Other types of addressesSI optionally gets other information through DHCP such asUnique Local Addresses [RFC4193] MAY be used to connect toaprivate network with no global connectivity. A single /64 SHOULD be reserveddelegated prefix and DNS 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 thePPP link. 5.1.2. IPv4 AEstablishment of a SoftwireConcentrator MAY provide either globally routable or private IPv4 addresses. If private addresses are used, the delegated prefix should be inIn thesame address space thanfollowing diagram (Figure 10), each of thePPP endpointthree steps required toavoid nested NAT configurations. A globally routable addressestablish a Softwire ispreferable, sincedescribed inmost cases, it is expected the CPE device will perform the IPv4 NAT function. The endpoints of the PPP link use host addresses (i.e., /32), negotiated using IPCP.detail. Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page 19] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 20065.2. Delegated Prefixes 5.2.1. IPv6 Prefixes Delegated IPv6 prefixes are between /48 and /64 in length. A CPE device receiving a /64 is expected to perform bridging if more than one interface is available (wired and wireless for example). The length of delegated IPv6 prefixes SHOULD be a multiple of 4. Reverse DNS delegation of IPv6 prefixes that are not multiples of 4 is more complex since more than one record must be inserted in the zone file. In the worst case, up to 8 records have to be entered for one prefix if the prefix length is equal to a multiple of 4 plus 1 (/61 for example). Example: One NS record is required for the reverse DNS delegation of 2001: db8:1:10::/60 NS 1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com Several (8) NS records are required for the reverse DNS delegation of 2001:db8:1:10::/61 NS 0.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com NS 1.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com NS 2.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com NS 3.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com NS 4.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com NS 5.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com NS 6.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com NS 7.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com 5.2.2. IPv4 Prefixes Delegated IPv4 prefixes should be of the same scope than the assigned IPv4 addresses and be routable within that address space. Prefix length is between /8 and /30. However, the DNS reverse delegation of prefixes that are not multiples of 8 may be problematic. In the worst case of a one bit difference, for example a /25, 128 NS records Storer, et al. Expires February 26, 2007 [Page 20] Internet-Draft Softwires H & S Framework with L2TPv2 August 2006 must be configured in the reverse zone file. 6. Softwire Establishment A softwire is established in 3 distinct steps (Figure 9). First a L2TP tunnel with a single session is established from the SI to the SC. Second a PPP session is established over the L2TP session and the SI get an address. Third the SI optionally gets other information through DHCP such as a delegated prefix and DNS servers.SC SI | ||<-------------L2TP-------------->| L2TP | | |<-------------PPP--------------->| PPP and |<-------Neighbor Discovery------>| configuration | | |<-------------DHCP-------------->| Additional | | configuration | | (optional) Figure 9: Steps for the Establishment of a Softwire Storer, et al. Expires February 26, 2007 [Page 21] Internet-Draft Softwires H & S Framework with L2TPv2 August 2006 SC SI| | Step 1 |<------------SCCRQ---------------| - |-------------SCCRP-------------->| | |<------------SCCCN---------------| | |<------------ICRQ----------------| |L2TPL2TPv2 |-------------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 |<-----------Solicit--------------| - |-----------Advertise------------>| | DHCP |<---------- Request--------------| | (Optional) |-------------Reply-------------->| - Figure 10: Detailed Steps in the Establishment of a Softwire6.1. L2TP5.1. L2TPv2 Tunnel Setup L2TPv2 [RFC2661] wasinitiallyoriginally designed toconnect a Network Access Server (NAS) concentrating traffic from multipleprovide private network access to end users connected todifferent Internet Access Providers (IAP).a public network. InL2TP terminology, an L2TP Network Server (LNS) isthe L2TPv2 model, the end user makes adevice concentrating L2TP connections coming fromconnection to an L2TP Access Concentrator(LAC) dispatched on(LAC). The LAC then initiates an L2TPv2 tunnel to an L2TP Network Server (LNS). The LNS then transfers end user traffic between theIPL2TPv2 tunnel and the private network. In theSoftwires HubSoftwire "Hub andSpokeSpoke" model, theLAC will act as the SoftwiresSoftwire Initiator (SI)and the LNS asassumes theSoftwires Concentrator (SC). The SI can be located onrole of theend user equipment, a special gateway dedicated to handle IPv6 traffic, or directly onLAC and thehome gateway. An L2TP packet, inSoftwire Concentrator assumes thesoftwires model, MUST be carried over UDP.Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page22]20] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 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 thetransition scenario deployed. 6.1.1.Softwires scenario. 5.1.1. Tunnel Establishment The followingdiagramdiagram, (Figure 11), describes messages exchanged and AVPs used to establishcommunicationa tunnel between an SI (LAC) and an SC (LNS).They representThe messages and AVPs described here are only a subset ofexchangesthose defined in[RFC2661] mostly to limit implementation complexity on[RFC2661]. This is because Softwires uses only a subset of theSI side.L2TPv2 functionality. One session per tunnel isonly needed, sinceneeded. Note that in theLAC does not act as a PPP session concentrator. The LAC MUSTSoftwires environment, the SI alwaysestablishinitiates thesession.tunnel. No outgoing or analog calls are permitted.L2TPL2TPv2 attributes SHOULD NOT be hidden. Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page23]21] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006LAC (SI) LAC (SC) ---------- ----------SCCRQ->Mandatory AVP Message Type Protocol Version Host Name Framing Capabilities Assigned Tunnel ID Optional AVP: Receive Window Size Firmware Revision Vendor Name (Challenge)<-SCCRP Mandatory AVP: Message Type Protocol Version Framing Capabilities Host Name Assigned Tunnel ID Optional AVP: Firmware Revision Vendor Name Receive Window Size (Challenge Response) (Challenge) SCCCN->Mandatory AVP: Message Type (Challenge Response)<- ZLB ACKFigure 11: Tunnel EstablishmentStorer, et al. Expires February 26, 2007 [Page 24] Internet-DraftIn L2TPv2, the tunnel between a LAC and LNS may carry the data of multiple users. Each of these user's is represented by an L2TPv2 session within the tunnel. In the SoftwiresH & S Framework withenvironment, the tunnel carries the information of a single user. So, there is only one L2TPv2August 2006 LAC (SI) LAC (SC) ---------- ---------- ICRQ -> Mandatory AVP: Message Type Assigned Session ID Callsession per tunnel. The following diagram, (Figure 12), describes messages exchanged and 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 uses only a subset of the L2TPv2 functionality. Note that in the Softwires environment, the SI always initiates the session. No outgoing or analog calls are permitted. L2TPv2 attributes SHOULD NOT be hidden. Storer, et al. Expires May 21, 2007 [Page 22] Internet-Draft Softwires H & S Framework with L2TPv2 November 2006 ICRQ Mandatory AVP: Message Type Assigned Session ID Call Serial Number<-ICRP Mandatory AVP: Message Type Assigned Session ID ICCN->Mandatory AVP: Message Type (Tx) Connect Speed Framing Type<- ZLB ACKFigure 12: Session Establishment 5.1.1.1. AVPs Required for Softwires This paragraph specifies specific values for AVPs used in the Softwires context.6.1.1.1. AVPs Required for SotftwiresHost Name AVP This AVP is mandatory and is present in SCCRQ and SCCRP messages. This AVPMAYmay be used to authenticateusers. For the LNS, the hostname COULD be the server name with the fully qualified domain. For the LAC, the name COULD be user-id@name.fully-qualified-domain. If name or fully-qualified- domain is not configured (since the equipment isusers, inthe bootstrap phase)which case it would contain a user identification. If thispart CAN be left blank. User-idAVP isthe valuenot used to authenticatethe user. If user-id is not defined, "Softwires" COULDusers, it may beused.used for documention. Framing Capabilities AVP Synchronous bit SHOULD be set to 1 and Asynchronous bit to0.1. This AVPMUSTSHOULD be ignored by the receiver. Framing Type AVPStorer, et al. Expires February 26, 2007 [Page 25] Internet-Draft Softwires H & S Framework with L2TPv2 August 2006Synchronous bitMUSTSHOULD be set to 1 and Asynchronous bit to 0. This AVP SHOULD be ignored by the receiver. (Tx) Connect Speed (Tx) Connect Speed is a mandatory AVP but is not meaningful in the Softwires context.Value shouldIt SHOULD be left to 0 and ignored by the receiver. Assigned Tunnel ID, Receive Window Size, Firmware Revision, Vendor Storer, et al. Expires May 21, 2007 [Page 23] Internet-Draft Softwires H & S Framework with L2TPv2 November 2006 Name, Call Serial Number, and Assigned Session ID As defined in [RFC2661]6.1.1.2.5.1.1.2. AVPs Optional forSotftwiresSoftwires Challenge and Challenge Response AVPsSession authentication as defined in [RFC2661] is based on a shared secret known by LACs and LNSs, and isThese AVPs are notdesignedrequired, but are necessary toauthenticate a specific user. This AVP is not required since security enhancement is not guaranteed. While userimplement tunnel authentication. Since tunnel authenticationis typically donehappens at thePPP level,beginning of L2TPv2 tunnelauthentication maycreation, it can be helpful in preventing DoS attacks.6.1.1.3.5.1.1.3. AVPs notRequiredRelevant for SoftwiresL2TPL2TPv2 specifies numerous AVPs that, while allowed for a given command, are irrelevant to a Softwires. Softwires implementations should not send these AVPs. However, they should ignore them when they are received. This will make it easier to create Softwires applications on top of existingL2TPL2TPv2 implementations.6.1.2.5.1.2. Tunnel Maintenance Periodically, the SI must transit a message to the SC to maintain NAT contextin the NATand detect tunnel failure. TheLNS and LAC SHOULD useL2TPv2 HELLOmessages for this purpose. Asmessage provides a simple, low overhead method of doing this. However, using the default values specified in [RFC2661]HELLO messages SHOULD be generated if no other messages are sent forcould result in aperiod of time. The valuedead end detection time of60 seconds recommended by [RFC2661] fulfills Softwires constraints.83 seconds. If this is not acceptable, LCP Echo Request and Reply messagesSHOULD NOTmay be used forthis purpose. The use of both LCP Echo and L2TPv2 HELLO messages is redundant in the Softwires environment. Storer, et al. Expires February 26, 2007 [Page 26] Internet-Draft Softwires H & S Framework with L2TPv2 August 2006 6.1.3.quicker dead end detection. 5.1.3. Tunnel Teardown Either the SIandor SC can teardown the session andthen thetunnel.No change orThis is done as specified in [RFC2661]. There is no action specificparameter are required comparedto[RFC2661]. The SI or the SC sends an CDN message, acknowledged by ZLB message. The initiator of the tunnel teardown, MUST immediately after close the tunnel by sending a StopCCN message, acknowledged by a ZLB message. 6.2.Softwires in this case. 5.2. PPP Connection6.2.1.5.2.1. MTU The MTU of the PPP link SHOULD be the link MTU minus the size of the IP, UDP,L2TP,L2TPv2, and PPP headers together. On an IPv4 link with an MTU equal to 1500 bytes, this would usually mean a PPP MTU of 1460 bytes. This may vary according to the size of the L2TP header.In order to optimize the link efficiency and prevent fragmentation,See [RFC4623] for apath MTU discovery algorithm may be used to detect the maximum MTU on the path between the SI and the SC. However path MTU discovery is outdetailed discussion ofscope for this document. 6.2.2.fragmentation issues. Storer, et al. Expires May 21, 2007 [Page 24] Internet-Draft Softwires H & S Framework with L2TPv2 November 2006 5.2.2. LCP Once theL2TPL2TPv2 session is established, the SIinitiatesand SC initiate the PPP connection bysending anegotiating LCPConfiguration Request message. The SC also sends aas described in [RFC1661]. ACFC [RFC1662] SHOULD be rejected. 5.2.3. Authentication After completing LCPConfiguration Request containing at leastnegotiation, theMaximum Receive Unit option, authentication protocolSI andMagic Number.SC may optionally perform authentication. Ifnoauthenticationprotocol optionispresent, the SI considerschosen, CHAP [RFC1994] authentication MUST be supported by both theserviceSoftwire Initiator and Softwire Concentrator. Other authentication methods such asunauthenticatedPAP [RFC1994], MS-CHAP [RFC2433], and EAP [RFC3748] MAY be supported. A detailed discussion of Softwires security is contained in [I-D.ietf-softwire-security-requirements] 5.2.4. IPCP 5.2.4.1. IPv6CP In the IPv6 over IPv4 scenarios (see Section6.2.3). Each party answers with3.1), after the authentication phase, the Softwire Initiator MUST negotiate IPv6CP as defined in [RFC2472]. IPv6CP provides aConfiguration Ack messageway to negotiate a unique 64-bit interface identifier tofinishbe used for thelink configuration. Negotiations in both directions MUST reject compression ofaddress autoconfiguration at theProtocol field (PFC), and compressionlocal 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 Addressand Control fields (ACFC). Link Quality ReportAssignement to Endpoints In several scenario defined in Section 3, Global IPv6 addresses are expected to be allocated to Softwires end points. Since IPv6CP only provide Link-Local addresses (see [RFC2472]), IPv6 Neighbor Discovery [RFC2462] or DHCPv6 [RFC3315] SHOULD bedisabled on both sides.used to configure these addresses. TheMagic Number option MAY be partSoftwire Initiator of an IPv6 Softwire MUST send a Router Solicitation message to thenegotiation. The MRU valueSoftwire Concentrator after IPV6CP isby default 1500 and can be changed by negotiation. Figure 13 gives an example ofcompleted. The Softwire Concentrator MUST answer with a Router Advertisement. This message MUST contains theLCP exchange between an SI and an SC;global IPv6 prefix of themessage orderPPP link if Neighbor discovery isnot significant since both negotiations may start concurrently.used to configure addresses of Softwire end points. Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page27]25] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006SC: SI: -- -- LCP Conf-Request MRU 1500 Magic Number 0x5c35721e LCP Conf-Ack MRU 1500 Magic Number 0x5c35721e LCP Conf-Request MRU 1500, Magic-Num 0xcd7f0041, Auth-Prot CHAP, MD5 LCP Conf-ack MRU 1500, Magic-Num 0xcd7f0041, Auth-Prot CHAP, MD5 Figure 13: LCP Exchange between SI and SC 6.2.3. Authentication After sendingIf DHCPv6 is available for address delegation, theLCP Configuration Ack,M bits of theSC proceeds with the PPP authentication phase. CHAP [RFC1994] authentication MUSTRouter Advertisement SHOULD besupported by both theset. The Softwire InitiatorandMUST then send a DHCPv6 Request to configure the address of the SoftwireConcentrator. Optionally, other authentication methods such as PAP, MS-CHAP EAP MAYendpoint. Duplicate Address Detection ([I-D.ietf-ipv6-2461bis]) MUST besupported.performed on the Softwire in both cases. 5.4. DHCP The SoftwireConcentratorInitiator MAYallow non-authenticated connection. In that case, the SC actsuse DHCP to get additional information such as delegated prefix and DNS servers. If the SI supports DHCP, it SHOULD send agateway for anonymous connections. This approachSolicit message to verify if more information isbetter thanavailable. When delegating anopen relay implementation since ingress filtering is performed on established tunnels (see Section 9). If non-authenticated connections are supported byIPv4 prefix to theSC, enabling this function MUST be configurable bySI, the SCadministrator. 6.2.4. IPCP 6.2.4.1. IPv6CP AfterSHOULD inject a route for this prefix in theauthentication phase,IPv4 routing table in order to forward the traffic to the relevant Softwire. 5.4.1. DHCPv6 IF a SI establishing an IPv6 SoftwireInitiatoracts as a router (scenarios 3.1.2 and 3.1.4) it MUSTsend an IPV6CP Configuration-Requestinclude the IA_PD option [RFC3633] in the DHCPv6 Solicit message[RFC2472] containing[RFC3315] in order to request anInterface Identifier. The Interface Identifier SHOULD be ofIPv6 prefix. When delegating an IPv6 prefix to theIEEE EUI-64 format. A Configuration-Request message is also sent bySI, theSC. If that message constrains a different Interface Identifier, it MUST be accepted throughSC SHOULD inject aConfigure-Ack message. Storer, et al. Expires February 26, 2007 [Page 28] Internet-Draft Softwires H & S Framework with L2TPv2 August 2006 6.2.4.2. IPv4CProute for this prefix in the IPv4 routing table in order to forward the traffic to the relevant Softwire. 5.4.2. DHCPv4 ASoftwire InitiatorSI establishing an IPv4softwire SHOULDSoftwire MAY send aConfiguration-Request with all four octets ofDHCP request containing theIP-Address configurationSubnet Allocation optionset to 0 (see [RFC1332]). If the Softwire Concentrator does[I-D.ietf-dhc-subnet-alloc]. This practice is notassign an address to the Softwire Initiator, the SI MUST request an address through DHCP. The SCcommon but mayindicate a failure to assign an address by sending back an address with all octets set to 0 or by sending a protocol reject in response to the IPCP CONFREQ. 6.3. Neighbor Discovery The Softwire Initiator of an IPv6 softwire MUST send a Router Sollicitation message to the Softwire Concentrator after IPV6CP is completed. The Softwire Concentrator MUST answer with a Router Advertisement containing the global IPv6 prefix of the PPP link. Duplicate Address Detection (DAD) is redundant in that context and doesn't have to be performed. For that purpose, DupAddrDetectTransmits autoconfiguration variable to zero [RFC2472] [RFC2462]. If DHCPv6 is available, the M bits of the Router Advertisement SHOULDbeset. 6.4. DHCP The Softwire Initiator MAY use DHCP to get additional information such as delegated prefix and DNS servers. If the SI supports DHCP, it SHOULD send a Solicit messageused toverify if more information is available. 6.4.1. DHCPv6 IF a SI establishing an IPv6 Softwire actsconnect IPv4 subnets using Softwires, asa router (scenarios 3.1.2 and 3.1.4) it MUST include the IA_PD option [RFC3633] in the DHCPv6 Solicit message [RFC3315]defined inorder to request an IPv6 prefix. 6.4.2. DHCPv4 A SI establishing an IPv4 softwire MAY send a DHCP request containing the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc].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 SHOULDStorer, et al. Expires February 26, 2007 [Page 29] Internet-Draft Softwires H & S Framework with L2TPv2 August 2006be 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 SHOULD include the Subnet Information suboption with the prefix it was previously assigned. The 'c' and 's' bits of the suboptionSHOULD be set to '0'. 7. AAA - Best Current Practices The Softwire Concentrator is expected to act as a clientStorer, et al. Expires May 21, 2007 [Page 26] Internet-Draft Softwires H & S Framework with L2TPv2 November 2006 SHOULD be set toa AAA server, for example a Radius server. During the PPP authentication phase, the AAA server may return additional information in the form of attributes in'0'. 6. Considerations about theAccess Accept message. TheAddress Provisioning Model This section describes how a Softwire ConcentratorMAY includemay manage delegated addresses for Softwire endpoints and for subnets behind theTunnel-TypeSoftwire Initiator. One common practice is to aggregate endpoints addresses andTunnel- Medium-Type attributes [RFC2868] indelegated prefixes into one prefix routed to theAccess Request messagesSC. The main benefit is toprovide a hint ofease thetype of softwire being configured. 7.1. Tunnelrouting scheme by isolating on the SC succeeding route injections (when delegating new prefixes for SI). 6.1. Softwire Endpoints7.1.1.Addresses 6.1.1. IPv6Softwires If the AAA server includes a Framed-Interface-Id attribute [RFC3162], theA Softwire ConcentratorMUST send itshould provide globally routable addresses totheSoftwireInitiator in the Interface Identifier fieldendpoints. Other types ofits IPV6CP Configuration Request message. If the Framed-IPv6-Prefix attribute is mentioned [RFC3162], that prefix MUSTaddresses such as Unique Local Addresses [RFC4193] may be usedin the router advertisements senttothe SI. If Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC MUST chooseaddress Softwire end points in aprefixprivate network withthat poolno global connectivity. A single /64 should be assigned tosend router advertisements. If none of the attributes above are included but the AAA server returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are present and ofthecorrectSoftwire to addressfamily, these MUSTboth Softwire endpoints. Global or ULA addresses must beused in the IPV6CP Interface Identifier and for the router advertisements. 7.1.2. IPv4 Softwires Ifassigned to endpoints when theFramed-IP-Address attribute [RFC2865]scenario "Host CPE as Softwire Initiator" (described in Section 3.1.1) ispresent, theconsidered to be deployed. For other scenarios, this may be optional and link local addresses should be used. 6.1.2. IPv4 A Softwire ConcentratorMUSTmay providethat address to the Softwire Initiator during IPCP address negotiation. That is, wheneither globally routable or private IPv4 addresses. When using IPv4 private addresses [RFC1918] on theSoftwire Initiator requestsendpoints, it is not not recommended to delegate anIP address fromIPv4 private prefix to theSoftwire Concentrator,SI, as it can lead to a nested-NAT situations. The endpoints of theaddress providedPPP link use host addresses (i.e., /32), negotiated using IPCP. 6.2. Delegated Prefixes 6.2.1. IPv6 Prefixes Delegated IPv6 should be of global scope if assigned IPv6 addresses for endpoints are global. Using ULA addresses is not recommended when subnet is connected to theFramed-IP-Address.global IPv6 Internet. When using ULA IPv6 address for endpoint, Delegated IPv6 prefix may be either of Global or ULA scope. Delegated IPv6 prefixes are between /48 and /64 in length. When a SI Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page30]27] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006If the Framed-IP-Address attributereceives a prefix shorter than 64, it can assign different /64 prefixes to each of its interfaces. A SI receiving a single /64 isnot present and the Tunnel- Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868]expected to perform bridging if more than one interface arepresentavailable (wired andof the correct address family, these SHOULDwireless for example). 6.2.2. IPv4 Prefixes Delegated IPv4 prefixes should beused inof theIPCP IP-Address configuration option. 7.2. Delegated Prefixes 7.2.1. IPv6 Prefixes Ifsame scope than theattribute Delegated-IPv6-Prefix [I-D.ietf-radext-delegated-prefix] is present in the Radius Access Accept message, it mustassigned IPv4 addresses and beused byroutable within that address space. Prefix length is between /8 and /30. 6.3. Possible scenarios This section summarizes theSoftwire Concentratordifferents scenarios for address provisioning with thedelegation ofconsiderations given in the previous sections. 6.3.1. Scenarios for IPv6prefix. Since the prefix delegation is performed by DHCPv6 and the attribute is linked to a username, the SC MUST associateThis table describes theDUID of a DHCPv6 request to tunnel it came from and its user. 7.2.2. IPv4 Prefixes Thepossible combination ofthe 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. 8. Maintenance and Statistics - Best Current Practices 8.1. Radius Accounting Radius Accounting for L2TPv2 is well documented (see Section 4.3). Softwires implementers may use the existing RFCs as appropriate for their business environment. 8.2. MIBs MIB supportIPv6 address scope forL2TPv2 is well documented (see Section 4.4). Softwires implementers may use the existing RFCs as appropriateendpoints 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 fortheir business environment. Also see [RFC4293] 9. Security Considerations The L2PTv2 softwires solution provides the following toolsIPv6 6.3.2. Scenarios forsecurity: o IPsec [RFC3193] providesIPv4 This table describes thehighest levelpossible combination ofsecurity. o PPP CHAP [RFC1994] provides basic user authentication.IPv6 address scope for endpoints and delegated prefixes. Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page31]28] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006o L2TP Tunnel Authentication [RFC2661] provides authentication at tunnel setup. It+------------------+-----------------------+------------------------+ | Endpoint IPv4 | Delegated Public IPv4 | Delegated Private IPv4 | | Address | Prefix | Prefix | +------------------+-----------------------+------------------------+ | Private IPv4 | Possible | Possible, but Not | | | | Recommended | | | | | | Public IPv4 | Possible | Possible | +------------------+-----------------------+------------------------+ 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 beusedprovisioned tolimit DoS attacks by authenticating the tunnel before L2TP sessionprovide only a temporary address. The address andPPP resourcesprefix areallocated. A detailed discussionexpected 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 ofsoftwires security is containeda more fragmented routing table. The routing fragmentation issue may be limited if the prefixes are aggregated in[I-D.ietf-softwire-security-requirements]. 10. Implementation status 11. Open issues 11.1. Fragmentation and MTU 11.2. AAA Accounting (other draft) 12. IANA Considerationsa location topologically close to the SC. Thisdocument creates no new requirements on IANA namespaces [RFC2434]. 13. Acknowledgements The authorswouldlikebe 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 toacknowledgeact as a client to a AAA server, for example a RADIUS server. During thefollowing contributors whoPPP 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- Medium-Type attributes [RFC2868] in the Access Request messages to provide a hint of the type of Softwire being configured. 8.1. Softwires Endpoints Storer, et al. Expires May 21, 2007 [Page 29] Internet-Draft Softwires H & S Framework with L2TPv2 November 2006 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 is mentioned [RFC3162], 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] are present and of 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 providedhelpful input on this document: Florent Parent, Jordi Palet Martinez, Oleshould 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 [I-D.ietf-radext-delegated-prefix] 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 DUID of a DHCPv6 request to tunnel it came from and its user. Interaction between RADIUS, PPP and DHCPv6 server may follow the mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. 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 and fill these attributes in RRAO (Relay Storer, et al. Expires May 21, 2007 [Page 30] Internet-Draft Softwires H & S Framework with L2TPv2 November 2006 Agent RADIUS Attribute Option) into succeeding DHCPv6 requests from the client before forwarding them 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 Softwires 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 Softwires security is contained in [I-D.ietf-softwire-security-requirements]. The L2TPv2 Softwires solution provides the following tools for security: o IPsec [RFC3193] provides the highest level of security. o PPP CHAP [RFC1994] provides basic user authentication. 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. Storer, et al. Expires May 21, 2007 [Page 31] Internet-Draft Softwires H & S Framework with L2TPv2 November 2006 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, and Francis Dupont. The authors would also like to acknowledge the participants in the Softwires interim meeting at China University - Hong Kong (February 23-24, 2006). The minutes for this meeting are at <http://www3.ietf.org/proceedings/06mar/minutes/isoftwire.html>. ### Point to minutes of Barcelona meeting 13. References 13.1. Normative References [I-D.ietf-softwire-problem-statement] Li, X., "Softwire Problem Statement", draft-ietf-softwire-problem-statement-02 (work in progress), May 2006. [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. [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994. [RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses", RFC 1877, December 1995. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Storer, et al. Expires May 21, 2007 [Page 32] Internet-Draft Softwires H & S Framework with L2TPv2 November 2006 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 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. [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting 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. [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,Shin Miyakawa, Carl Williams, Mark Townsley, Francis Dupont,O. andBruno Stevant. The authors would also like to acknowledge the participants in the Softwires interim meeting at China University - Hong Kong (February 23-24, 2006). The minutesR. Droms, "IPv6 Prefix Options forthis meeting are at <http://www3.ietf.org/proceedings/06mar/minutes/isoftwire.html>. 14. References 14.1. Normative References [I-D.ietf-dhc-subnet-alloc] Johnson, R., "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-03 (work in progress), June 2005. [I-D.ietf-radext-delegated-prefix]Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page32]33] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006. 13.2. Informative References [I-D.ietf-dhc-subnet-alloc] Johnson, R., "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-04 (work in progress), October 2006. [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-ipv6-2461bis] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-09 (work in progress), October 2006. [I-D.ietf-ipv6-over-ppp-v2] Varada, S., "IP Version 6 over PPP", draft-ietf-ipv6-over-ppp-v2-02 (work in progress), June 2005. [I-D.ietf-radext-delegated-prefix] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute",draft-ietf-radext-delegated-prefix-02 (work in progress), July 2006. [I-D.ietf-softwire-problem-statement] Li, X., "Softwire Problem Statement", draft-ietf-softwire-problem-statement-02draft-ietf-radext-delegated-prefix-05 (work in progress),MayOctober 2006. [I-D.ietf-softwire-security-requirements] Yamamoto, S., "Softwire Security Analysis and Requirements",draft-ietf-softwire-security-requirements-00draft-ietf-softwire-security-requirements-01 (work in progress),JuneOctober 2006.[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332,[I-D.stevant-softwire-accounting] Stevant, B., "Accounting on Softwires", draft-stevant-softwire-accounting-01 (work in progress), Storer, et al. Expires May1992. [RFC1877] Cobb, S. and F. Baker,21, 2007 [Page 34] Internet-Draft Softwires H & S Framework with L2TPv2 November 2006 October 2006. [RFC1994] Simpson, W., "PPPInternetChallenge Handshake Authentication ProtocolControl(CHAP)", RFC 1994, August 1996. [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling ProtocolExtensions for Name Server- Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC1877, December 1995. [RFC2119] Bradner,4193, October 2005. [RFC4293] Routhier, S.,"Key words"Management Information Base foruse in RFCsthe Internet Protocol (IP)", RFC 4293, April 2006. Appendix A. Revision History [Note toIndicate Requirement Levels", BCP 14,RFC2119, March 1997. [RFC2434] Narten, T.Editor: please remove this entire appendix, andH. Alvestrand, "Guidelinesthe corresponding entries in the table of contents, prior to publication.] Changes between -01 and -02: o Renamed all "Best Current Practices" sections as "Recommendations". See forWriting an IANA Considerationsexample Section 1.4. o Moved Provisioning inRFCs", BCP 26, RFC 2434, October 1998. [RFC2462] Thomson, S.Section 6. Removed intro text to new Section 7. o Removed all normative language from Section 6, Section 7, Section 8, andT. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2472] Haskin, D.Section 9. o Removed empty sections "Implementation Status", andE. Allen, "IP Version 6 over PPP", RFC 2472, December 1998. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.,"Open Issues". o Fixed "Phase 0" in Section 1. o Small changes to Section 3.1. o Change L2TP -> L2TPv2 in some sections, including Section 6. o Small additions andB. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A.,typo fixes in Section 5.1.1.1 andW. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2867] Zorn, G., Aboba, B.,Section 5.1.1.2. o Retitled Section 8 andD. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,Section 8.1, changed AAA -> RADIUS. o New paragraph in Section 9.1. Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page33]35] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC3162] Aboba, B., Zorn, G.,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 andD. Mitton, "RADIUSFigure 10. o Reword paragraph of Section 5.1. o Describe more messages than flows in Figure 11 andIPv6", RFC 3162, August 2001. [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G.,Figure 12. o Add text about Session Establishment between Figure 11 andS. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,Figure 12. o Section 5.1.1.1 andM. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3371] Caves, E., Calhoun, P.,Section 5.1.1.2: Updates on Hostname AVP, Framing Capabilities AVP, Framing Type AVP, Connect Speed AVP andR. Wheeler, "Layer Two Tunneling Protocol "L2TP" Management Information Base", RFC 3371, August 2002. [RFC3633] Troan, O.Challenge andR. Droms, "IPv6 Prefix OptionsChallenge Response AVPs. o Retitled Section 5.1.1.3. o Updates on the use of L2TP HELLO versus LCP, delay forDynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L.,Dead-End peer detection, andM. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. 14.2. Informative References [I-D.ietf-ipv6-over-ppp-v2] Varada, S., "IP Version 6 over PPP", draft-ietf-ipv6-over-ppp-v2-02 (workallow LCP. o Rewording inprogress), June 2005. [I-D.stevant-softwire-accounting] Stevant, B., "AccountingSection 5.1.3. o Section 5.2.1: Add a pointer to [RFC4623] and small updates. o Clarifications onSoftwires", draft-stevant-softwire-accounting-00 (workPFC and ACFC, remove Figure 13. o Section 5.2.3: make references to RFCs for PAP, CHAP, etc. o Rewordings inprogress), February 2006. [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [RFC3931] Lau, J., Townsley, M.,Section 5.2.4.1 andI. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC4193] Hinden, R.Section 5.2.4.2. o Added Informative references to [RFC4623], [RFC1661], [RFC1662], [RFC2433], and [RFC3748]. o Renamed the title and added more details on Section 5.3 andB. Haberman, "Unique LocalIPv6Unicast Addresses", RFC 4193, October 2005. [RFC4293] Routhier, S., "Management Information Base forND, 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 theInternet Protocol (IP)", RFC 4293, April 2006.scope of the MUST (to the specific scenarios). Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page34]36] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006Appendix A. Revision History [Note to RFC Editor: please remove this entire appendix, ando Removed considerations about reverse DNS from Section 6, agreed on Barcelona. o Clarified thecorresponding entriesNAT 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 thetable of contents, prior to publication.]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": Section5,6, Section7,8, and Section8.9. o Section5.1.1,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 Section5.1.2,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 Section6,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 Section6,5, Figure 10: Marked CHAP as "Optional - CHAP". o Section6.1,5.1, Section6.1.1,5.1.1, and Section6.1.3:5.1.3: Minor typographical error correction and rewording of some sentences for grammar. o Section6.1.1.1,5.1.1.1, Host Name AVP: Removed "for debugging purposes" and added that MAY be used to authenticate users. o Section6.1.1.1,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 Section6.1.1.1,5.1.1.1, (Tx) Connect Speed: Correction: "but is *not* meaningful". Storer, et al. Expires May 21, 2007 [Page 37] Internet-Draft Softwires H & S Framework with L2TPv2 November 2006 o Section6.1.1.2,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.Storer, et al. Expires February 26, 2007 [Page 35] Internet-Draft Softwires H & S Framework with L2TPv2 August 2006o Section6.1.2: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 Section6.2.1,5.2.1, first paragraph: Fixed PPP MTU calculation. Mailing list comment from Florent Parent, 10-Jul-2006. o Section6.2.2: Updated and augmented the text, and added Figure 13. o Section 6.2.4.2: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 Section7,8, second paragraph: s/Tunnel-Medium /Tunnel-Type /. Mailing list comment from Bill Storer, 5-Jul-2006. o Section7.1.2: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 Section7.2.2,8.2.2, Section8.1,9.1, Section8.2,9.2, and Section9.10. Revision -00: o Initial revision. Authors' Addresses Bill Storer (editor) Cisco Systems 170 W Tasman Dr San Jose, CA 95134 USA Email: bstorer@cisco.com Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page36]38] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 Carlos Pignataro (editor) Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA Email: cpignata@cisco.com Maria Alice Dos Santos(editor)Cisco Systems 170 W Tasman Dr San Jose, CA 95134 USA Email: mariados@cisco.com Jean-Francois Tremblay(editor)Hexago 1470 Peel, suite 910 Montreal, QC J4B 2Z5 Canada Email: jean-francois.tremblay@hexago.comLaurent ToutainBruno Stevant (editor) GET/ENST Bretagne 2 rue de la Chataigneraie CS17607 Cesson Sevigne, 35576 France Email:Laurent.Toutain@enst-bretagne.frbruno.stevant@enst-bretagne.fr Storer, et al. ExpiresFebruary 26,May 21, 2007 [Page37]39] Internet-Draft Softwires H & S Framework with L2TPv2AugustNovember 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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. ExpiresFebruary 26,May 21, 2007 [Page38]40] ----