RFC 5571: Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)
- B. Storer,
- C. Pignataro, Ed.,
- M. Dos Santos,
- B. Stevant, Ed.,
- L. Toutain,
- J. Tremblay
Proposed Standard
Network Working Group B. Storer
Request for Comments: 5571 C. Pignataro, Ed.
Category: Standards Track M. Dos Santos
Cisco Systems
B. Stevant, Ed.
L. Toutain
TELECOM Bretagne
J. Tremblay
Videotron Ltd.
June 2009
Softwire Hub and Spoke Deployment Framework
with Layer Two Tunneling Protocol Version 2 (L2TPv2)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Storer, et al. Standards Track [Page 1]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 Abstract This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer Two Tunneling Protocol version 2 (L2TPv2). The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. Table of Contents 1. Introduction ....................................................4 1.1. Abbreviations ..............................................5 1.2. Requirements Language ......................................5 1.3. Considerations .............................................6 2. Applicability of L2TPv2 for Softwire Requirements ...............6 2.1. Traditional Network Address Translation (NAT and NAPT) .....6 2.2. Scalability ................................................7 2.3. Routing ....................................................7 2.4. Multicast ..................................................7 2.5. Authentication, Authorization, and Accounting (AAA) ........7 2.6. Privacy, Integrity, and Replay Protection ..................7 2.7. Operations and Management ..................................8 2.8. Encapsulations .............................................8 3. Deployment Scenarios ............................................8 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 ..............11 3.1.4. Router behind CPE as Softwire Initiator ............12 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. References to Standardization Documents ........................17 4.1. L2TPv2 ....................................................18 4.2. Securing the Softwire Transport ...........................18 4.3. Authentication, Authorization, and 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 .........................................20 5.1. L2TPv2 Tunnel Setup .......................................22 5.1.1. Tunnel Establishment ...............................22 5.1.1.1. AVPs Required for Softwires ...............25 5.1.1.2. AVPs Optional for Softwires ...............25 5.1.1.3. AVPs Not Relevant for Softwires ...........26 Storer, et al. Standards Track [Page 2]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 5.1.2. Tunnel Maintenance .................................26 5.1.3. Tunnel Teardown ....................................27 5.1.4. Additional L2TPv2 Considerations ...................27 5.2. PPP Connection ............................................27 5.2.1. MTU ................................................27 5.2.2. LCP ................................................27 5.2.3. Authentication .....................................28 5.2.4. IPCP ...............................................28 5.2.4.1. IPV6CP ....................................28 5.2.4.2. IPv4CP ....................................28 5.3. Global IPv6 Address Assignment to Endpoints ...............28 5.4. DHCP ......................................................29 5.4.1. DHCPv6 .............................................29 5.4.2. DHCPv4 .............................................29 6. Considerations about the Address Provisioning Model ............30 6.1. Softwire Endpoints' Addresses .............................30 6.1.1. IPv6 ...............................................30 6.1.2. IPv4 ...............................................31 6.2. Delegated Prefixes ........................................31 6.2.1. IPv6 Prefixes ......................................31 6.2.2. IPv4 Prefixes ......................................31 6.3. Possible Address Provisioning Scenarios ...................31 6.3.1. Scenarios for IPv6 .................................32 6.3.2. Scenarios for IPv4 .................................32 7. Considerations about Address Stability .........................32 8. Considerations about RADIUS Integration ........................33 8.1. Softwire Endpoints ........................................33 8.1.1. IPv6 Softwires .....................................33 8.1.2. IPv4 Softwires .....................................33 8.2. Delegated Prefixes ........................................34 8.2.1. IPv6 Prefixes ......................................34 8.2.2. IPv4 Prefixes ......................................34 9. Considerations for Maintenance and Statistics ..................34 9.1. RADIUS Accounting .........................................35 9.2. MIBs ......................................................35 10. Security Considerations .......................................35 11. Acknowledgements ..............................................36 12. References ....................................................37 12.1. Normative References .....................................37 12.2. Informative References ...................................38 Storer, et al. Standards Track [Page 3]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 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 "Hub and Spoke" solution space. This document describes the framework for the L2TPv2 "Hub and Spoke" solution, and the implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. In the "Hub and Spoke" 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). The terms voluntary tunneling and compulsory tunneling are defined in Section 1.1 of [RFC3193]. Since the 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 the compulsory tunneling model that does 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, teardown, and Operations, Administration, and Management (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 that 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. Storer, et al. Standards Track [Page 4]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 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 L2TP Control Connection Endpoint (LCCE), and to potentially refresh the NAT/NAPT (Network Address Translation / Network Address Port Translation) entry at the CPE or at the other end of the access link. Optionally, Link Control Protocol (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 the SI or the 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. CPE Customer Premises Equipment. LCCE L2TP Control Connection Endpoint, an L2TP node that exists at either end of an L2TP Control Connection. (See [RFC3931].) LNS L2TP Network Server, a node that acts as one side of an L2TP tunnel (Control Connection) endpoint. The LNS is the logical termination point of a PPP session that is being tunneled from the remote system by the peer LCCE. (See [RFC2661].) 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].) 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]. Storer, et al. Standards Track [Page 5]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 1.3. Considerations Some sections of this document contain considerations that are not required for interoperability and correct operation of Softwire implementations. These sections' titles are marked beginning with "Considerations". 2. Applicability of L2TPv2 for Softwire Requirements A list of Softwire "Hub and Spoke" 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 "Hub and Spoke" 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, preexisting 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]. As mentioned in Section 8.1 of [RFC2661] and Section 4 of [RFC3193], an L2TP Start-Control-Connection-Reply (SCCRP) responder (SC) can chose a different IP address and/or UDP port than those from the initiator's Start-Control-Connection-Request (SCCRQ) (SI). This may or may not traverse a NAT/NAPT depending on the NAT/NAPT's Filtering Behavior (see Section 5 of [RFC4787]). Specifically, any IP address and port combination will work with Endpoint-Independent Filtering, but changing the IP address and port will not work through Address- Dependent or Address-and-Port-Dependent Filtering. Given this, responding from a different IP address and/or UDP port is NOT RECOMMENDED. Storer, et al. Standards Track [Page 6]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 2.2. Scalability In the "Hub and Spoke" 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 transparently over L2TPv2 Softwires together with other regular IP traffic. 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 the 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 Encapsulating Security Payload (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. Storer, et al. Standards Track [Page 7]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 2.7. Operations and Management L2TPv2 supports an optional in-band keepalive mechanism that 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. The 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.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 "Hub and Spoke" 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 Storer, et al. Standards Track [Page 8]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 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 sub-sections 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. 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, the IPv6 Control Protocol (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 Storer, et al. Standards Track [Page 9]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 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 non-address 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. 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 Storer, et al. Standards Track [Page 10]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 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 non-address configuration options (such as DNS [RFC3646]) to the router CPE. 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 Storer, et al. Standards Track [Page 11]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 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 non-address configuration options (such as DNS [RFC3646]) can be conveyed to the host via DHCPv6. 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. Storer, et al. Standards Track [Page 12]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 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 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 Storer, et al. Standards Track [Page 13]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 (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 non-address configuration options (such as DNS [RFC3646]) to the v4/v6 router. 3.2. IPv4-over-IPv6 Softwires with L2TPv2 The following sub-sections 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, the IP Control Protocol (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 via DHCP. Other configuration options (such as DNS) can be conveyed to the host CPE via IPCP [RFC1877] or DHCP [RFC2132]. Storer, et al. Standards Track [Page 14]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 3.2.2. Router CPE as Softwire Initiator 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 [SUBNET-ALL] can be used. Storer, et al. Standards Track [Page 15]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 3.2.3. Host behind CPE as Softwire Initiator 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 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. Standards Track [Page 16]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 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 [SUBNET-ALL] can be used. 4. References to Standardization Documents This section lists and groups documents from the Internet standardization describing technologies used to design the framework of the Softwire "Hub and Spoke" solution. This emphasizes the motivation of Softwire to reuse as many existing standards as Storer, et al. Standards Track [Page 17]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 possible. This list contains both Standards Track (Proposed Standard, Draft Standard, and Standard) and Informational documents. The list of documents and their status should only be only used for description purposes. 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, and Accounting RFC 2865 "Remote Authentication Dial In User Service (RADIUS)" [RFC2865]. * Updated by [RFC2868], [RFC3575], and [RFC5080]. 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]. Storer, et al. Standards Track [Page 18]
RFC 5571 Softwire H & S Framework with L2TPv2 June 2009 RFC 3371 "Layer Two Tunneling Protocol "L2TP" Management Information Base" [RFC3371]. RFC 4087 "IP Tunnel MIB" [RFC4087]. * Both IPv4 and IPv6 transports are supported. 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].