idnits 2.17.1 draft-ietf-softwire-hs-framework-l2tpv2-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 13, 2009) is 5490 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IPv4-only' is mentioned on line 558, but not defined == Missing Reference: 'IPv6-only' is mentioned on line 739, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-09 == Outdated reference: A later version (-09) exists of draft-ietf-softwire-security-requirements-07 == Outdated reference: A later version (-02) exists of draft-stevant-softwire-accounting-01 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwires Working Group B. Storer 3 Internet-Draft C. Pignataro, Ed. 4 Intended status: Standards Track M. Dos Santos 5 Expires: October 15, 2009 Cisco Systems 6 B. Stevant, Ed. 7 TELECOM Bretagne 8 J. Tremblay 9 Videotron Ltd. 10 April 13, 2009 12 Softwire Hub & Spoke Deployment Framework with L2TPv2 13 draft-ietf-softwire-hs-framework-l2tpv2-13 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on October 15, 2009. 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Abstract 60 This document describes the framework of the Softwire "Hub and Spoke" 61 solution with the Layer 2 Tunneling Protocol version 2 (L2TPv2). The 62 implementation details specified in this document should be followed 63 to achieve interoperability among different vendor implementations. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 69 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 70 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 6 71 1.4. Considerations . . . . . . . . . . . . . . . . . . . . . . 7 73 2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7 74 2.1. Traditional Network Address Translation (NAT and NAPT) . . 7 75 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 8 76 2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 8 78 2.5. Authentication, Authorization and Accounting (AAA) . . . . 8 79 2.6. Privacy, Integrity, and Replay Protection . . . . . . . . 8 80 2.7. Operations and Management . . . . . . . . . . . . . . . . 8 81 2.8. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 9 83 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 9 84 3.1. IPv6 over IPv4 Softwires with L2TPv2 . . . . . . . . . . . 10 85 3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 10 86 3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 11 87 3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 12 88 3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 13 89 3.2. IPv4 over IPv6 Softwires with L2TPv2 . . . . . . . . . . . 15 90 3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 15 91 3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 15 92 3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 16 93 3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 17 95 4. References to standardization documents . . . . . . . . . . . 18 96 4.1. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 4.2. Securing the Softwire Transport . . . . . . . . . . . . . 19 98 4.3. Authentication Authorization Accounting . . . . . . . . . 19 99 4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 20 101 4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 20 102 4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 20 104 5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 21 105 5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 23 106 5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 23 107 5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 26 108 5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 26 109 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 27 110 5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 27 111 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 28 112 5.1.4. Additional L2TPv2 Considerations . . . . . . . . . . . 28 113 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 28 114 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 28 115 5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 28 116 5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 28 117 5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 29 118 5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 29 119 5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 29 120 5.3. Global IPv6 Address Assignment to Endpoints . . . . . . . 29 121 5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 122 5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 30 123 5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 30 125 6. Considerations about the Address Provisioning Model . . . . . 31 126 6.1. Softwire Endpoints' Addresses . . . . . . . . . . . . . . 31 127 6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 31 128 6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 31 129 6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 32 130 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 32 131 6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 32 132 6.3. Possible Address Provisioning Scenarios . . . . . . . . . 32 133 6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 32 134 6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 33 136 7. Considerations about Address Stability . . . . . . . . . . . . 33 138 8. Considerations about RADIUS Integration . . . . . . . . . . . 34 139 8.1. Softwire Endpoints . . . . . . . . . . . . . . . . . . . . 34 140 8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 34 141 8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 34 142 8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 34 143 8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 34 144 8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 35 146 9. Considerations for Maintenance and Statistics . . . . . . . . 35 147 9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 35 148 9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 150 10. Security Considerations . . . . . . . . . . . . . . . . . . . 36 152 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 154 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 156 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 157 13.1. Normative References . . . . . . . . . . . . . . . . . . . 37 158 13.2. Informative References . . . . . . . . . . . . . . . . . . 39 160 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 162 1. Introduction 164 The Softwires Working Group has selected Layer Two Tunneling Protocol 165 version 2 (L2TPv2) as the phase 1 protocol to be deployed in the 166 Softwire "Hub and Spoke" solution space. This document describes the 167 framework for the L2TPv2 "Hub and Spoke" solution, and the 168 implementation details specified in this document should be followed 169 to achieve interoperability among different vendor implementations. 171 In the "Hub and Spoke" solution space, a Softwire is established to 172 provide the home network with IPv4 connectivity across an IPv6-only 173 access network, or IPv6 connectivity across an IPv4-only access 174 network. When L2TPv2 is used in the Softwire context, the voluntary 175 tunneling model applies. The Softwire Initiator (SI) at the home 176 network takes the role of the L2TP Access Concentrator (LAC) client 177 (initiating both the L2TP tunnel/session and the PPP link) while the 178 Softwire Concentrator (SC) at the ISP takes the role of the L2TP 179 Network Server (LNS). The terms voluntary tunneling and compulsory 180 tunneling are defined in Section 1.1 of [RFC3193]. Since L2TPv2 181 compulsory tunneling model does not apply to Softwires, it SHOULD NOT 182 be requested or honored. This document identifies all the voluntary 183 tunneling related L2TPv2 attributes that apply to Softwires and 184 specifies the handling mechanism for such attributes in order to 185 avoid ambiguities in implementations. This document also identifies 186 the set of L2TPv2 attributes specific to compulsory tunneling model 187 that do not apply to Softwires and specifies the mechanism to ignore 188 or nullify their effect within the Softwire context. 190 The SI and SC MUST follow the L2TPv2 operations described in 191 [RFC2661] when performing Softwire establishment, tear-down and OAM. 192 With L2TPv2, a Softwire consists of an L2TPv2 Control Connection 193 (also referred to as Control Channel), a single L2TPv2 Session, and 194 the PPP link negotiated over the Session. To establish the Softwire, 195 the SI first initiates an L2TPv2 Control Channel to the SC which 196 accepts the request and terminates the Control Channel. L2TPv2 197 supports an optional mutual Control Channel authentication which 198 allows both SI and SC to validate each other's identity at the 199 initial phase of hand-shaking before proceeding with Control Channel 200 establishment. After the L2TPv2 Control Channel is established 201 between the SI and SC, the SI initiates an L2TPv2 Session to the SC. 202 Then the PPP/IP link is negotiated over the L2TPv2 Session between 203 the SI and SC. After the PPP/IP link is established, it acts as the 204 Softwire between the SI and SC for tunneling IP traffic of one 205 Address Family (AF) across the access network of another Address 206 Family. 208 During the life of the Softwire, both SI and SC send L2TPv2 keepalive 209 HELLO messages to monitor the health of the Softwire and the peer 210 LCCE, and to potentially refresh the NAT/NAPT translation entry at 211 the CPE or at the other end of the access link. Optionally, LCP ECHO 212 messages can be used as keepalives for the same purposes. In the 213 event of keepalive timeout or administrative shutdown of the 214 Softwire, either SI or SC MAY tear down the Softwire by tearing down 215 the L2TPv2 Control Channel and Session as specified in [RFC2661]. 217 1.1. Abbreviations 219 AF Address Family, IPv4 or IPv6. 221 CPE Customer Premises Equipment. 223 LCCE L2TP Control Connection Endpoint, an L2TP node that exists at 224 either end of an L2TP Control Connection. (See [RFC3931].) 226 LNS L2TP Network Server, a node that acts as one side of an L2TP 227 tunnel (Control Connection) endpoint. The LNS is the logical 228 termination point of a PPP session that is being tunneled from 229 the remote system by the peer LCCE. (See [RFC2661].) 231 SC Softwire Concentrator, the node terminating the Softwire in 232 the service provider network. (See [RFC4925].) 234 SI Softwire Initiator, the node initiating the Softwire within 235 the customer network. (See [RFC4925].) 237 SPH Softwire Payload Header, the IP headers being carried within a 238 Softwire. (See [RFC4925].) 240 STH Softwire Transport Header, the outermost IP header of a 241 Softwire. (See [RFC4925].) 243 SW Softwire, a shared-state "tunnel" created between the SC and 244 SI. (See [RFC4925].) 246 1.2. Requirements Language 248 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 249 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 250 document are to be interpreted as described in [RFC2119]. 252 1.3. Contributing Authors 254 Following is the complete list of contributors to this document. 256 Maria Alice Dos Santos, Cisco Systems 257 Carlos Pignataro, Cisco Systems 258 Bill Storer, Cisco Systems 259 Jean-Francois Tremblay, Videotron Ltd. 260 Laurent Toutain, TELECOM Bretagne 261 Bruno Stevant, TELECOM Bretagne 263 1.4. Considerations 265 Some sections of this document contain considerations that are not 266 required for interoperability and correct operation of Softwire 267 implementations. These sections are marked as "Considerations". 269 2. Applicability of L2TPv2 for Softwire Requirements 271 A list of Softwire "Hub and Spoke" requirements has been identified 272 by the Softwire Problem Statement [RFC4925]. The following sub- 273 sections describe how L2TPv2 fulfills each of them. 275 2.1. Traditional Network Address Translation (NAT and NAPT) 277 A "Hub and Spoke" Softwire must be able to traverse Network Address 278 Translation (NAT) and Network Address Port Translation (NAPT, also 279 referred to as Port Address Translation or PAT) devices [RFC3022] in 280 case the scenario in question involves a non-upgradable pre-existing 281 IPv4 home gateway performing NAT/NAPT or some carrier equipment at 282 the other end of the access link performing NAT/NAPT. The L2TPv2 283 Softwire (i.e., Control Channel and Session) is capable of NAT/NAPT 284 traversal since L2TPv2 can run over UDP. 286 Since L2TPv2 does not detect NAT/NAPT along the path, L2TPv2 does not 287 offer the option of disabling UDP. The UDP encapsulation is present 288 regardless of NAT/NAPT presence. Both NAT/NAPT "autodetect" and UDP 289 "bypass" are optional requirements in Section 2.3 of [RFC4925]. 291 As mentioned in Section 8.1 of [RFC2661] and Section 4 of [RFC3193], 292 an L2TP SCCRP responder (SC) can chose a different IP address and/or 293 UDP port than those from the initiator's SCCRQ (SI). This may or may 294 not traverse a NAT/NAPT depending on the NAT/NAPT's Filtering 295 Behavior (see Section 5 of [RFC4787]). Specifically, any IP address 296 and port combination will work with Endpoint-Independent Filtering, 297 but changing IP address and port will not work through Address- 298 Dependent or Address and Port-Dependent Filtering. Given this, 299 responding from a different IP address and/or UDP port is NOT 300 RECOMMENDED. 302 2.2. Scalability 304 In the "Hub and Spoke" model, a carrier must be able to scale the 305 solution to millions of Softwire Initiators by adding more hubs 306 (i.e., Softwire Concentrators). L2TPv2 is a widely deployed protocol 307 in broadband services, and its scalability has been proven in 308 multiple large-scale IPv4 Virtual Private Network deployments which 309 scale up to millions of subscribers each. 311 2.3. Routing 313 There are no dynamic routing protocols between the SC and SI. A 314 default route from the SI to the SC is used. 316 2.4. Multicast 318 Multicast protocols simply run over L2TPv2 Softwires transparently 319 together with other regular IP traffic. 321 2.5. Authentication, Authorization and Accounting (AAA) 323 L2TPv2 supports optional mutual Control Channel authentication and 324 leverages the optional mutual PPP per-session authentication. L2TPv2 325 is well integrated with AAA solutions (such as RADIUS) for both 326 authentication and authorization. Most L2TPv2 implementations 327 available in the market support logging of authentication and 328 authorization events. 330 L2TPv2 integration with RADIUS accounting (RADIUS Accounting 331 extension for tunnel [RFC2867]) allows the collection and reporting 332 of L2TPv2 Softwire usage statistics. 334 2.6. Privacy, Integrity, and Replay Protection 336 Since L2TPv2 runs over IP/UDP in the Softwire context, IPsec ESP can 337 be used in conjunction to provide per-packet authentication, 338 integrity, replay protection and confidentiality for both L2TPv2 339 control and data traffic [RFC3193] and [RFC3948]. 341 For Softwire deployments in which full payload security is not 342 required, the L2TPv2 built-in Control Channel authentication and the 343 inherited PPP authentication and PPP Encryption Control Protocol can 344 be considered. 346 2.7. Operations and Management 348 L2TPv2 supports an optional in-band keepalive mechanism which injects 349 HELLO control messages after a specified period of time has elapsed 350 since the last data or control message was received on a tunnel (see 351 Section 5.5 of [RFC2661]). If the HELLO control message is not 352 reliably delivered, then the Control Channel and its Session will be 353 torn down. In the Softwire context, the L2TPv2 keepalive is used to 354 monitor the connectivity status between the SI and SC and/or as a 355 refresh mechanism for any NAT/NAPT translation entry along the access 356 link. 358 LCP ECHO offers a similar mechanism to monitor the connectivity 359 status, as described in [RFC1661]. Softwire implementations SHOULD 360 use L2TPv2 Hello keepalives and in addition MAY use PPP LCP Echo 361 messages to ensure Dead End Detection and/or to refresh NAT/NAPT 362 translation entries. The combination of these two mechanisms can be 363 used as an optimization. 365 L2TPv2 MIB [RFC3371] supports the complete suite of management 366 operations such as configuration of Control Channel and Session, 367 polling of Control Channel and Session status and their traffic 368 statistics and notifications of Control Channel and Session UP/DOWN 369 events. 371 2.8. Encapsulations 373 L2TPv2 supports the following encapsulations: 375 o IPv6/PPP/L2TPv2/UDP/IPv4 377 o IPv4/PPP/L2TPv2/UDP/IPv6 379 o IPv4/PPP/L2TPv2/UDP/IPv4 381 o IPv6/PPP/L2TPv2/UDP/IPv6 383 Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not 384 support "autodetect" of NAT/NAPT. 386 3. Deployment Scenarios 388 For the "Hub and Spoke" problem space, four scenarios have been 389 identified. In each of these four scenarios, different home 390 equipment plays the role of the Softwire Initiator. This section 391 elaborates each scenario with L2TPv2 as the Softwire protocol and 392 other possible protocols involved to complete the solution. This 393 section examines the four scenarios for both IPv6 over IPv4 394 (Section 3.1) and IPv4 over IPv6 (Section 3.2) encapsulations. 396 3.1. IPv6 over IPv4 Softwires with L2TPv2 398 The following subsections cover IPv6 connectivity (SPH) across an 399 IPv4-only access network (STH) using a Softwire. 401 3.1.1. Host CPE as Softwire Initiator 403 The Softwire Initiator (SI) is the host CPE (directly connected to a 404 modem), which is dual-stack. There is no other gateway device. The 405 IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 1. 407 IPv6 or dual-stack IPv4-only dual-stack 408 |------------------||-----------------||----------| 410 I SC SI 411 N +-----+ +----------+ 412 T | | | v4/v6 | 413 E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| host CPE | 414 R [network] | | [ network ] | | 415 N | LNS | |LAC Client| 416 E +-----+ +----------+ 417 T _ _ _ _ _ _ _ _ _ 418 ()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic 419 PPP o L2TPv2 o UDP o IPv4 (SPH) 420 Softwire 422 <------------------> 423 IPV6CP: capable of /64 Intf-Id assignment or 424 uniqueness check 426 |------------------>/64 prefix 427 RA 428 |------------------>DNS, etc. 429 DHCPv6 431 Figure 1: Host CPE as Softwire Initiator 433 In this scenario, after the L2TPv2 Control Channel and Session 434 establishment and PPP LCP negotiation (and optionally PPP 435 Authentication) are successful, IPV6CP negotiates IPv6 over PPP which 436 also provides the capability for the ISP to assign the 64-bit 437 Interface-Identifier to the host CPE or perform uniqueness validation 438 for the two interface identifiers at the two PPP ends [RFC5072]. 439 After IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration / 440 Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can 441 inform the host CPE of a prefix to use for stateless address 442 autoconfiguration through a Router Advertisement (RA) while other 443 non-address configuration options (such as DNS [RFC3646] or other 444 servers' addresses that might be available) can be conveyed to the 445 host CPE via DHCPv6. 447 3.1.2. Router CPE as Softwire Initiator 449 The Softwire Initiator (SI) is the router CPE, which is a dual-stack 450 device. The IPv4 traffic SHOULD NOT traverse the Softwire. See 451 Figure 2. 453 IPv6 or dual-stack IPv4-only dual-stack 454 |------------------||-----------------||---------------------| 456 I SC SI 457 N +-----+ +----------+ 458 T | | | v4/v6 | +-----+ 459 E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| CPE |----|v4/v6| 460 R [network] | | [ network ] | | | host| 461 N | LNS | |LAC Client| +-----+ 462 E +-----+ +----------+ 463 T _ _ _ _ _ _ _ _ _ 464 ()_ _ _ _ _ _ _ _ _() <-------- IPv6 traffic 465 PPP o L2TPv2 o UDP o IPv4 (SPH) 466 Softwire 468 <------------------> 469 IPV6CP: capable of /64 Intf-Id assignment or 470 uniqueness check 472 |------------------>/64 prefix 473 RA 474 |------------------>/48 prefix, 475 DHCPv6 DNS, etc. 477 |------->/64 prefix 478 RA 479 |-------> DNS, etc. 480 DHCPv4/v6 482 Figure 2: Router CPE as Softwire Initiator 484 In this scenario, after the L2TPv2 Control Channel and Session 485 establishment and PPP LCP negotiation (and optionally PPP 486 Authentication) are successful, IPV6CP negotiates IPv6 over PPP which 487 also provides the capability for the ISP to assign the 64-bit 488 Interface-Identifier to the router CPE or perform uniqueness 489 validation for the two interface identifiers at the two PPP ends 491 [RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address 492 Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP 493 link, and the LNS can inform the router CPE of a prefix to use for 494 stateless address autoconfiguration through a Router Advertisement 495 (RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g., 496 delegating a prefix to be used within the home network [RFC3633]) and 497 convey other non-address configuration options (such as DNS 498 [RFC3646]) to the router CPE. 500 3.1.3. Host behind CPE as Softwire Initiator 502 The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack 503 host (behind the IPv4-only CPE), which acts as an IPv6 host CPE. The 504 IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 3. 506 IPv6 or dual-stack IPv4-only dual-stack 507 |------------------||----------------------------||----------| 509 I SC SI 510 N +-----+ +----------+ 511 T | | +-------+ | v4/v6 | 512 E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....|v4-only|--| host | 513 R [network] | | [ network ] | CPE | | | 514 N | LNS | +-------+ |LAC Client| 515 E +-----+ +----------+ 516 T _ _ _ _ _ _ _ _ _ _ _ _ _ _ 517 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6 518 PPP o L2TPv2 o UDP o IPv4 traffic 519 Softwire (SPH) 521 <------------------------------> 522 IPV6CP: capable of /64 Intf-Id assignment or 523 uniqueness check 525 |------------------------------>/64 prefix 526 RA 527 |------------------------------>DNS, etc. 528 DHCPv6 530 Figure 3: Host behind CPE as Softwire Initiator 532 In this scenario, after the L2TPv2 Control Channel and Session 533 establishment and PPP LCP negotiation (and optionally PPP 534 Authentication) are successful, IPV6CP negotiates IPv6 over PPP which 535 also provides the capability for the ISP to assign the 64-bit 536 Interface-Identifier to the host or perform uniqueness validation for 537 the two interface identifiers at the two PPP ends [RFC5072]. After 538 IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration / 539 Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can 540 inform the host of a prefix to use for stateless address 541 autoconfiguration through a Router Advertisement (RA) while other 542 non-address configuration options (such as DNS [RFC3646]) can be 543 conveyed to the host via DHCPv6. 545 3.1.4. Router behind CPE as Softwire Initiator 547 The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack 548 device (behind the IPv4-only CPE) acting as an IPv6 CPE router inside 549 the home network. The IPv4 traffic SHOULD NOT traverse the Softwire. 550 See Figure 4. 552 IPv6 or dual-stack IPv4-only dual-stack 553 |------------------||-------------------------||-------------| 555 I SC SI 556 N +-----+ +----------+ 557 T | | +-------+ | v4/v6 | 558 E <==[ IPv6 ]....|v4/v6|..[IPv4-only]..|v4-only|---| router | 559 R [network] | | [ network ] | CPE | | | | 560 N | LNS | +-------+ | |LAC Client| 561 E +-----+ | +----------+ 562 T | 563 ---------+-----+ 564 |v4/v6| 565 | host| 566 _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ 567 ()_ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6 568 PPP o L2TPv2 o UDP o IPv4 traffic 569 Softwire (SPH) 571 <---------------------------> 572 IPV6CP: capable of /64 Intf-Id assignment or 573 uniqueness check 575 |--------------------------->/64 prefix 576 RA 577 |--------------------------->/48 prefix, 578 DHCPv6 DNS, etc. 580 |----> /64 581 RA prefix 582 |----> DNS, 583 DHCPv6 etc. 585 Figure 4: Router behind CPE as Softwire Initiator 587 In this scenario, after the L2TPv2 Control Channel and Session 588 establishment and PPP LCP negotiation (and optionally PPP 589 Authentication) are successful, IPV6CP negotiates IPv6 over PPP which 590 also provides the capability for the ISP to assign the 64-bit 591 Interface-Identifier to the v4/v6 router or perform uniqueness 592 validation for the two interface identifiers at the two PPP ends 593 [RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address 594 Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP 595 link, and the LNS can inform the v4/v6 router of a prefix to use for 596 stateless address autoconfiguration through a Router Advertisement 597 (RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g., 598 delegating a prefix to be used within the home network [RFC3633]) and 599 convey other non-address configuration options (such as DNS 601 [RFC3646]) to the v4/v6 router. 603 3.2. IPv4 over IPv6 Softwires with L2TPv2 605 The following subsections cover IPv4 connectivity (SPH) across an 606 IPv6-only access network (STH) using a Softwire. 608 3.2.1. Host CPE as Softwire Initiator 610 The Softwire Initiator (SI) is the host CPE (directly connected to a 611 modem), which is dual-stack. There is no other gateway device. The 612 IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 5. 614 IPv4 or dual-stack IPv6-only dual-stack 615 |------------------||-----------------||----------| 617 I SC SI 618 N +-----+ +----------+ 619 T | | | v4/v6 | 620 E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| host CPE | 621 R [network] | | [ network ] | | 622 N | LNS | |LAC Client| 623 E +-----+ +----------+ 624 T _ _ _ _ _ _ _ _ _ 625 ()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic 626 PPP o L2TPv2 o UDP o IPv6 (SPH) 627 Softwire 629 <------------------> 630 IPCP: capable of global IP assignment 631 and DNS, etc. 633 Figure 5: Host CPE as Softwire Initiator 635 In this scenario, after the L2TPv2 Control Channel and Session 636 establishment and PPP LCP negotiation (and optionally PPP 637 Authentication) are successful, IPCP negotiates IPv4 over PPP which 638 also provides the capability for the ISP to assign a global IPv4 639 address to the host CPE. A global IPv4 address can also be assigned 640 via DHCP. Other configuration options (such as DNS) can be conveyed 641 to the host CPE via IPCP [RFC1877] or DHCP [RFC2132]. 643 3.2.2. Router CPE as Softwire Initiator 645 IPv4 connectivity across an IPv6-only access network (STH). The 646 Softwire Initiator (SI) is the router CPE, which is a dual-stack 647 device. The IPv6 traffic SHOULD NOT traverse the Softwire. See 648 Figure 6. 650 IPv4 or dual-stack IPv6-only dual-stack Home 651 |------------------||-----------------||-------------------| 653 I SC SI 654 N +-----+ +----------+ 655 T | | | v4/v6 | +-----+ 656 E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| CPE |--|v4/v6| 657 R [network] | | [ network ] | | | host| 658 N | LNS | |LAC Client| +-----+ 659 E +-----+ +----------+ 660 T _ _ _ _ _ _ _ _ _ 661 ()_ _ _ _ _ _ _ _ _() <--------- IPv4 traffic 662 PPP o L2TPv2 o UDP o IPv6 (SPH) 663 Softwire 665 <------------------> 666 IPCP: capable of global IP assignment 667 and DNS, etc. 669 |------------------> 670 DHCPv4: prefix, mask, PD 672 private/ 673 |------> global 674 DHCP IP, DNS, 675 etc. 677 Figure 6: Router CPE as Softwire Initiator 679 In this scenario, after the L2TPv2 Control Channel and Session 680 establishment and PPP LCP negotiation (and optionally PPP 681 Authentication) are successful, IPCP negotiates IPv4 over PPP which 682 also provides the capability for the ISP to assign a global IPv4 683 address to the router CPE. A global IPv4 address can also be 684 assigned via DHCP. Other configuration options (such as DNS) can be 685 conveyed to the router CPE via IPCP [RFC1877] or DHCP [RFC2132]. For 686 IPv4 Prefix Delegation for the home network, DHCP 687 [I-D.ietf-dhc-subnet-alloc] can be used. 689 3.2.3. Host behind CPE as Softwire Initiator 691 IPv4 connectivity across an IPv6-only access network (STH). The CPE 692 is IPv6-only. The Softwire Initiator (SI) is a dual-stack host 693 (behind the IPv6 CPE), which acts as an IPv4 host CPE. The IPv6 694 traffic SHOULD NOT traverse the Softwire. See Figure 7. 696 IPv4 or dual-stack IPv6-only dual-stack 697 |------------------||----------------------------||----------| 699 I SC SI 700 N +-----+ +----------+ 701 T | | +-------+ | v4/v6 | 702 E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....|v6-only|--| host | 703 R [network] | | [ network ] | CPE | | | 704 N | LNS | +-------+ |LAC Client| 705 E +-----+ +----------+ 706 T _ _ _ _ _ _ _ _ _ _ _ _ _ _ 707 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv4 708 PPP o L2TPv2 o UDP o IPv6 traffic 709 Softwire (SPH) 711 <------------------------------> 712 IPCP: capable of global IP assignment 713 and DNS, etc. 715 Figure 7: Host behind CPE as Softwire Initiator 717 In this scenario, after the L2TPv2 Control Channel and Session 718 establishment and PPP LCP negotiation (and optionally PPP 719 Authentication) are successful, IPCP negotiates IPv4 over PPP which 720 also provides the capability for the ISP to assign a global IPv4 721 address to the host. A global IPv4 address can also be assigned via 722 DHCP. Other configuration options (such as DNS) can be conveyed to 723 the host CPE via IPCP [RFC1877] or DHCP [RFC2132]. 725 3.2.4. Router behind CPE as Softwire Initiator 727 IPv4 connectivity across an IPv6-only access network (STH). The CPE 728 is IPv6-only. The Softwire Initiator (SI) is a dual-stack device 729 (behind the IPv6-only CPE) acting as an IPv4 CPE router inside the 730 home network. The IPv6 traffic SHOULD NOT traverse the Softwire. 731 See Figure 8. 733 IPv4 or dual-stack IPv6-only dual-stack 734 |------------------||-------------------------||------------| 736 I SC SI 737 N +-----+ +----------+ 738 T | | +-------+ | v4/v6 | 739 E <==[ IPv4 ]....|v4/v6|..[IPv6-only]..|v6-only|---| router | 740 R [network] | | [ network ] | CPE | | | | 741 N | LNS | +-------+ | |LAC Client| 742 E +-----+ | +----------+ 743 T | 744 --------+-----+ 745 |v4/v6| 746 | host| 747 _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ 748 ()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- IPv4 749 PPP o L2TPv2 o UDP o IPv4 traffic 750 Softwire (SPH) 752 <---------------------------> 753 IPCP: assigns global IP address and DNS, etc. 755 |---------------------------> 756 DHCPv4: prefix, mask, PD 758 private/ 759 |----> global 760 DHCP IP, DNS, 761 etc. 763 Figure 8: Router behind CPE as Softwire Initiator 765 In this scenario, after the L2TPv2 Control Channel and Session 766 establishment and PPP LCP negotiation (and optionally PPP 767 Authentication) are successful, IPCP negotiates IPv4 over PPP which 768 also provides the capability for the ISP to assign a global IPv4 769 address to the v4/v6 router. A global IPv4 address can also be 770 assigned via DHCP. Other configuration options (such as DNS) can be 771 conveyed to the v4/v6 router via IPCP [RFC1877] or DHCP [RFC2132]. 772 For IPv4 Prefix Delegation for the home network, DHCP 773 [I-D.ietf-dhc-subnet-alloc] can be used. 775 4. References to standardization documents 777 This section lists and groups documents from the Internet 778 standardization describing technologies used to design the framework 779 of the Softwire "Hub and Spoke" solution. This emphasizes the 780 motivation of Softwire to reuse as many existing standards as 781 possible. This list contains both Standards Track (Proposed 782 Standard, Draft Standard, and Internet Standard) and Informational 783 documents. The list of documents and their status should only be 784 only used for description purposes. 786 4.1. L2TPv2 788 RFC 2661 "Layer Two Tunneling Protocol "L2TP"" [RFC2661]. 790 * For both IPv4 and IPv6 payloads (SPH), support is 791 complete. 793 * For both IPv4 and IPv6 transports (STH), support is 794 complete. 796 4.2. Securing the Softwire Transport 798 RFC 3193 "Securing L2TP using IPsec" [RFC3193]. 800 RFC 3948 "UDP Encapsulation of IPsec ESP Packets" [RFC3948]. 802 * IPsec supports both IPv4 and IPv6 transports. 804 4.3. Authentication Authorization Accounting 806 RFC 2865 "Remote Authentication Dial In User Service (RADIUS)" 807 [RFC2865]. 809 * Updated by [RFC2868], [RFC3575], and [RFC5080]. 811 RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol 812 Support" [RFC2867]. 814 RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868]. 816 RFC 3162 "RADIUS and IPv6" [RFC3162]. 818 4.4. MIB 820 RFC 1471 "The Definitions of Managed Objects for the Link Control 821 Protocol of the Point-to-Point Protocol" [RFC1471]. 823 RFC 1473 "The Definitions of Managed Objects for the IP Network 824 Control Protocol of the Point-to-Point Protocol" 825 [RFC1473]. 827 RFC 3371 "Layer Two Tunneling Protocol "L2TP" Management 828 Information Base" [RFC3371]. 830 RFC 4087 "IP Tunnel MIB" [RFC4087]. 832 * Both IPv4 and IPv6 transports are supported. 834 4.5. Softwire Payload Related 836 4.5.1. For IPv6 Payloads 838 RFC 4861 "Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861]. 840 RFC 4862 "IPv6 Stateless Address Autoconfiguration" [RFC4862]. 842 RFC 5072 "IP Version 6 over PPP" [RFC5072]. 844 RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" 845 [RFC3315]. 847 RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration 848 Protocol (DHCP) version 6" [RFC3633]. 850 RFC 3646 "DNS Configuration options for Dynamic Host Configuration 851 Protocol for IPv6 (DHCPv6)" [RFC3646]. 853 RFC 3736 "Stateless Dynamic Host Configuration Protocol (DHCP) 854 Service for IPv6" [RFC3736]. 856 4.5.2. For IPv4 Payloads 858 RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)" 859 [RFC1332]. 861 RFC 1661 "The Point-to-Point Protocol (PPP)" [RFC1661]. 863 RFC 1877 "PPP Internet Protocol Control Protocol Extensions for 864 Name Server Addresses" [RFC1877]. 866 RFC 2131 "Dynamic Host Configuration Protocol" [RFC2131]. 868 RFC 2132 "DHCP Options and BOOTP Vendor Extensions" [RFC2132]. 870 DHCP Subnet Allocation "Subnet Allocation Option". 872 * Work in progress, see [I-D.ietf-dhc-subnet-alloc]. 874 5. Softwire Establishment 876 A Softwire is established in three distinct steps, potentially 877 preceded by an optional IPsec-related step 0 (see Figure 9). First 878 an L2TPv2 tunnel with a single session is established from the SI to 879 the SC. Second a PPP session is established over the L2TPv2 session 880 and the SI obtains an address. Third the SI optionally gets other 881 information through DHCP such as a delegated prefix and DNS servers. 883 SC SI 884 | | 885 |<-------------IKEv1------------->| Step 0 886 | | IPsec SA establishment 887 | | (optional) 888 | | 889 |<-------------L2TPv2------------>| Step 1 890 | | L2TPv2 Tunnel establishment 891 | | 892 |<--------------PPP-------------->| Step 2 893 |<----End Point Configuration---->| PPP and End Point 894 | | configuration 895 | | 896 |<------Router Configuration----->| Step 3 897 | | Additional configuration 898 | | (optional) 900 Figure 9: Steps for the Establishment of a Softwire 902 Figure 10 depicts details of each of these steps required to 903 establish a Softwire. 905 SC SI 906 | | 907 | | Step 0 908 |<------------IKEv1-------------->| = IKEv1 (Optional) 909 | | 910 | | Step 1 911 |<------------SCCRQ---------------| - 912 |-------------SCCRP-------------->| | 913 |<------------SCCCN---------------| | 914 |<------------ICRQ----------------| | L2TPv2 915 |-------------ICRP--------------->| | 916 |<------------ICCN----------------| - 917 | | 918 | | Step 2 919 |<-----Configuration-Request------| - 920 |------Configuration-Request----->| | PPP 921 |--------Configuration-Ack------->| | LCP 922 |<-------Configuration-Ack--------| - 923 | | 924 |-----------Challenge------------>| - PPP Authentication 925 |<----------Response--------------| | (Optional - CHAP) 926 |------------Success------------->| - 927 | | 928 |<-----Configuration-Request------| - 929 |------Configuration-Request----->| | PPP NCP 930 |--------Configuration-Ack------->| | (IPV6CP or IPCP) 931 |<-------Configuration-Ack--------| - 932 | | 933 |<------Router-Solicitation-------| - Neighbor Discovery 934 |-------Router-Advertisement----->| | (IPv6 only) 935 | | - 936 | | 937 | | Step3 938 | | DHCP (Optional) 939 |<-----------SOLICIT--------------| - 940 |-----------ADVERTISE------------>| | DHCPv6 941 |<---------- REQUEST--------------| | (IPv6 SW, Optional) 942 |-------------REPLY-------------->| - 943 | | or 944 |<---------DHCPDISCOVER-----------| - 945 |-----------DHCPOFFER------------>| | DHCPv4 946 |<---------DHCPREQUEST------------| | (IPv4 SW, Optional) 947 |------------DHCPACK------------->| - 949 Figure 10: Detailed Steps in the Establishment of a Softwire 951 The IPsec-related negotiations in step 0 are optional. The L2TPv2 952 negotiations in step 1 are described in Section 5.1. The PPP NCP 953 negotiations in step 2 use IPV6CP for IPv6 over IPv4 Softwires, and 954 IPCP for IPv4 over IPv6 Softwires (see Section 5.2.4). The optional 955 DHCP negotiations in step 3 use DHCPv6 for IPv6 over IPv4 Softwires, 956 and DHCPv4 for IPv4 over IPv6 Softwires (see Section 5.4). 957 Additionally, for IPv6 over IPv4 Softwires, the DHCPv6 exchange for 958 non-address configuration (such as DNS) can use Stateless DHCPv6, the 959 two message exchange with Information-Request and Reply messages (see 960 Section 1.2 of [RFC3315] and [RFC3736]). 962 5.1. L2TPv2 Tunnel Setup 964 L2TPv2 [RFC2661] was originally designed to provide private network 965 access to end users connected to a public network. In the L2TPv2 966 incoming call model, the end user makes a connection to an L2TP 967 Access Concentrator (LAC). The LAC then initiates an L2TPv2 tunnel 968 to an L2TP Network Server (LNS). The LNS then transfers end user 969 traffic between the L2TPv2 tunnel and the private network. 971 In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI) 972 assumes the role of the LAC Client and the Softwire Concentrator (SC) 973 assumes the role of the LNS. 975 In the Softwire model, an L2TPv2 packet MUST be carried over UDP. 976 The underlying version of the IP protocol may be IPv4 or IPv6, 977 depending on the Softwire scenario. 979 In the following sections, the term "Tunnel" follows the definition 980 from Section 1.2 of [RFC2661], namely: "The Tunnel consists of a 981 Control Connection and zero or more L2TP Sessions". 983 5.1.1. Tunnel Establishment 985 Figure 11 describes the messages exchanged and Attribute Value Pairs 986 (AVPs) used to establish a tunnel between an SI (LAC) and an SC 987 (LNS). The messages and AVPs described here are only a subset of 988 those defined in [RFC2661]. This is because Softwires use only a 989 subset of the L2TPv2 functionality. The subset of L2TP Control 990 Connection Management AVPs that is applicable to Softwires is grouped 991 into Required AVPs and Optional AVPs on a per control message basis 992 (see Figure 11). For each control message, Required AVPs include all 993 the "MUST be present" AVPs from [RFC2661] for that control message, 994 and Optional AVPs include the "MAY be present" AVPs from [RFC2661] 995 that are used in the Softwire context on that control message. Note 996 that in the Softwire environment, the SI always initiates the tunnel. 997 L2TPv2 AVPs SHOULD NOT be hidden. 999 SC SI 1000 |<--------SCCRQ---------| 1001 Required AVPs: 1002 Message Type 1003 Protocol Version 1004 Host Name 1005 Framing Capabilities 1006 Assigned Tunnel ID 1007 Optional AVPs: 1008 Receive Window Size 1009 Challenge 1010 Firmware Revision 1011 Vendor Name 1013 |---------SCCRP-------->| 1014 Required AVPs: 1015 Message Type 1016 Protocol Version 1017 Framing Capabilities 1018 Host Name 1019 Assigned Tunnel ID 1020 Optional AVPs: 1021 Firmware Revision 1022 Vendor Name 1023 Receive Window Size 1024 Challenge 1025 Challenge Response 1027 |<--------SCCCN---------| 1028 Required AVPs: 1029 Message Type 1030 Optional AVPs: 1031 Challenge Response 1033 Figure 11: Control Connection Establishment 1035 In L2TPv2, generally, the tunnel between an LAC and LNS may carry the 1036 data of multiple users. Each of these users is represented by an 1037 L2TPv2 session within the tunnel. In the Softwire environment, the 1038 tunnel carries the information of a single user. Consequently, there 1039 is only one L2TPv2 session per tunnel. Figure 12 describes the 1040 messages exchanged and the AVPs used to establish a session between 1041 an SI (LAC) and an SC (LNS). The messages and AVPs described here 1042 are only a subset of those defined in [RFC2661]. This is because 1043 Softwires use only a subset of the L2TPv2 functionality. The subset 1044 of L2TP Call Management (i.e., Session Management) AVPs that is 1045 applicable to Softwires is grouped into Required AVPs and Optional 1046 AVPs on a per control message basis (see Figure 12). For each 1047 control message, Required AVPs include all the "MUST be present" AVPs 1048 from [RFC2661] for that control message, and Optional AVPs include 1049 the "MAY be present" AVPs from [RFC2661] that are used in the 1050 Softwire context on that control message. Note that in the Softwire 1051 environment, the SI always initiates the session. An L2TPv2 session 1052 setup for a softwire uses only the incoming call model. No outgoing 1053 or analog calls (sessions) are permitted. L2TPv2 AVPs SHOULD NOT be 1054 hidden. 1056 SC SI 1057 |<--------ICRQ---------| 1058 Required AVPs: 1059 Message Type 1060 Assigned Session ID 1061 Call Serial Number 1063 |---------ICRP-------->| 1064 Required AVPs: 1065 Message Type 1066 Assigned Session ID 1068 |<--------ICCN---------| 1069 Required AVPs: 1070 Message Type 1071 (Tx) Connect Speed 1072 Framing Type 1074 Figure 12: Session Establishment 1076 The following sub-sections 5.1.1.1 through 5.1.1.3 describe in more 1077 detail the Control Connection and Session establishment AVPs (see 1078 message flows in Figures 11 and 12 respectively) that are required, 1079 optional and not relevant for the L2TPv2 Tunnel establishment of a 1080 Softwire. Specific L2TPv2 protocol messages and flows that are not 1081 explicitly described in these sections are handled as defined in 1082 [RFC2661]. 1084 The mechanism for hiding AVP Attribute values is used, as describred 1085 in Section 4.3 of [RFC2661], to hide sensitive control message data 1086 such as usernames, user passwords or IDs, instead of sending the AVP 1087 contents in the clear. Since AVPs used in L2TP messages for the 1088 Softwire establishment do not transport such sensitive data, L2TPv2 1089 AVPs SHOULD NOT be hidden. 1091 5.1.1.1. AVPs Required for Softwires 1093 This section prescribes specific values for AVPs that are required 1094 (by [RFC2661]) to be present in one or more of the messages used for 1095 the Softwire establishment, as they are used in the Softwire context. 1096 It combines all the Required AVPs from all the control messages on 1097 Section 5.1.1, and provides Softwire-specific use guidance. 1099 Host Name AVP 1101 This AVP is required in SCCRQ and SCCRP messages. This AVP MAY be 1102 used to authenticate users, in which case it would contain a user 1103 identification. If this AVP is not used to authenticate users, it 1104 may be used for logging purposes. 1106 Framing Capabilities AVP 1108 Both the synchronous (S) and asynchronous (A) bits SHOULD be set 1109 to 1. This AVP SHOULD be ignored by the receiver. 1111 Framing Type AVP 1113 The synchronous bit SHOULD be set to 1 and the asynchronous bit to 1114 0. This AVP SHOULD be ignored by the receiver. 1116 (Tx) Connect Speed 1118 (Tx) Connect Speed is a required AVP but is not meaningful in the 1119 Softwire context. Its value SHOULD be set to 0 and ignored by the 1120 receiver. 1122 Message Type AVP, Protocol Version AVP, Assigned Tunnel ID AVP, Call 1123 Serial Number AVP, and Assigned Session ID AVP 1125 As defined in [RFC2661]. 1127 5.1.1.2. AVPs Optional for Softwires 1129 This section prescribes specific values for AVPs that are Optional 1130 (not required by [RFC2661]) but used in the Softwire context. It 1131 combines all the Optional AVPs from all the control messages on 1132 Section 5.1.1, and provides Softwire-specific use guidance. 1134 Challenge AVP and Challenge Response AVP 1136 These AVPs are not required, but are necessary to implement tunnel 1137 authentication. Since tunnel authentication happens at the 1138 beginning of L2TPv2 tunnel creation, it can be helpful in 1139 preventing DoS attacks. See Section 5.1.1 of [RFC2661]. 1141 The usage of these AVPs in L2TP messages is OPTIONAL, but SHOULD 1142 be implemented in the SC. 1144 Receive Window Size AVP, Firmware Revision AVP, and Vendor Name AVP 1146 As defined in [RFC2661]. 1148 5.1.1.3. AVPs not Relevant for Softwires 1150 L2TPv2 specifies numerous AVPs that, while allowed for a given 1151 message, are irrelevant to Softwires. They can be irrelevant to 1152 Softwires because they do not apply to the Softwire establishment 1153 flow (e.g., they are only used in the Outgoing Call establishment 1154 message exchange, while Softwires only use the Incoming Call message 1155 flow), or because they are Optional AVPs that are not used. L2TPv2 1156 AVPs that are relevant to Softwires were covered in Section 5.1.1, 1157 Section 5.1.1.1, and Section 5.1.1.2. Softwire implementations 1158 SHOULD NOT send AVPs that are not relevant to Softwires. However, 1159 they SHOULD ignore them when they are received. This will simplify 1160 the creation of Softwire applications that build upon existing L2TPv2 1161 implementations. 1163 5.1.2. Tunnel Maintenance 1165 Periodically, the SI/SC MUST transmit a message to the peer to detect 1166 tunnel or peer failure and maintain NAT/NAPT contexts. The L2TPv2 1167 HELLO message provides a simple, low overhead method of doing this. 1169 The default values specified in [RFC2661] for L2TPv2 HELLO messages 1170 could result in a dead end detection time of 83 seconds. Although 1171 these retransmission timers and counters SHOULD be configurable (see 1172 Section 5.8 of [RFC2661]), these values may not be adapted for all 1173 situations, where a quicker dead end detection is required, or where 1174 NAT/NAPT context needs to be refreshed more frequently. In such 1175 cases, the SI/SC MAY use, in combination with L2TPv2 HELLO, LCP ECHO 1176 messages (Echo-Request and Echo-Reply codes) described in [RFC1661]. 1177 When used, LCP ECHO messages SHOULD have a re-emission timer lower 1178 than the value for L2TPv2 HELLO messages. The default value 1179 recommended in Section 6.5 of [RFC2661] for the HELLO message 1180 retransmission interval is 60 seconds. When used, a set of suggested 1181 values (included here only for guidance) for the LCP ECHO message 1182 request interval is a default of 30 seconds, a minimum of 10 seconds, 1183 and a maximum of the lesser of the configured L2TPv2 HELLO 1184 retransmission interval and 60 seconds. 1186 5.1.3. Tunnel Teardown 1188 Either the SI or SC can teardown the session and tunnel. This is 1189 done as specified in Section 5.7 of [RFC2661], by sending a StopCCN 1190 control message. There is no action specific to Softwires in this 1191 case. 1193 5.1.4. Additional L2TPv2 Considerations 1195 In the Softwire "Hub and Spoke" framework, L2TPv2 is layered on top 1196 of UDP, as part of an IP-in-IP tunnel; Section 8.1 of [RFC2661] 1197 describes L2TP over UDP/IP. Therefore, the UDP guidelines specified 1198 in [RFC5405] apply, as they pertain to the UDP tunneling scenarios 1199 carrying IP-based traffic. Section 3.1.3 of [RFC5405] specifies that 1200 for this case, specific congestion control mechanisms for the tunnel 1201 are not necessary. Additionally, Section 3.2 of [RFC5405] provides 1202 message size guidelines for the encapsulating (outer) datagrams, 1203 including the recommendation to implement Path MTU Discovery (PMTUD). 1205 5.2. PPP Connection 1207 This section describes the PPP negotiations between the SI and SC in 1208 the Softwire context. 1210 5.2.1. MTU 1212 The MTU of the PPP link presented to the SPH SHOULD be the link MTU 1213 minus the size of the IP, UDP, L2TPv2, and PPP headers together. On 1214 an IPv4 link with an MTU equal to 1500 bytes, this could typically 1215 mean a PPP MTU of 1460 bytes. When the link is managed by IPsec, 1216 this MTU SHOULD be lowered to take into account the ESP encapsulation 1217 (see [I-D.ietf-softwire-security-requirements]). The value for the 1218 MTU may also vary according to the size of the L2TP header, as 1219 defined by the leading bits of the L2TP message header (see 1220 [RFC2661]). Additionally, see [RFC4623] for a detailed discussion of 1221 fragmentation issues. 1223 5.2.2. LCP 1225 Once the L2TPv2 session is established, the SI and SC initiate the 1226 PPP connection by negotiating LCP as described in [RFC1661]. The 1227 Address-and-Control-Field-Compression configuration option (ACFC) 1228 [RFC1661] MAY be rejected. 1230 5.2.3. Authentication 1232 After completing LCP negotiation, the SI and SC MAY optionally 1233 perform authentication. If authentication is chosen, CHAP [RFC1994] 1234 authentication MUST be supported by both the Softwire Initiator and 1235 Softwire Concentrator. Other authentication methods such as MS- 1236 CHAPv1 [RFC2433], and EAP [RFC3748] MAY be supported. 1238 A detailed discussion of Softwire security is contained in 1239 [I-D.ietf-softwire-security-requirements]. 1241 5.2.4. IPCP 1243 The only Network Control Protocol (NCP) negotiated in the Softwire 1244 context is IPV6CP (see Section 5.2.4.1) for IPv6 as SPH, and IPCP 1245 (see Section 5.2.4.2) for IPv4 as SPH. 1247 5.2.4.1. IPV6CP 1249 In the IPv6 over IPv4 scenarios (see Section 3.1), after the optional 1250 authentication phase, the Softwire Initiator MUST negotiate IPV6CP as 1251 defined in [RFC5072]. IPV6CP provides a way to negotiate a unique 1252 64-bit Interface-Identifier to be used for the address 1253 autoconfiguration at the local end of the link. 1255 5.2.4.2. IPv4CP 1257 In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire 1258 Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain 1259 an IPv4 address from the SC. IPCP MAY also be used to obtain DNS 1260 information as described in [RFC1877]. 1262 5.3. Global IPv6 Address Assignment to Endpoints 1264 In several scenarios defined in Section 3.1, Global IPv6 addresses 1265 are expected to be allocated to Softwire endpoints (in addition to 1266 the Link-Local addresses autoconfigured using the IPV6CP negotiated 1267 interface identifier). The Softwire Initiator assigns global IPv6 1268 addresses using the IPV6CP negotiated interface identifier and using 1269 Stateless Address Autoconfiguration [RFC4862], and/or using Privacy 1270 Extensions for Stateless Address Autoconfiguration [RFC4941], (as 1271 described in Section 5 of [RFC5072]), and/or using DHCPv6 [RFC3315]. 1273 The Softwire Initiator of an IPv6 Softwire MUST send a Router 1274 Solicitation message to the Softwire Concentrator after IPV6CP is 1275 completed. The Softwire Concentrator MUST answer with a Router 1276 Advertisement. This message MUST contains the global IPv6 prefix of 1277 the PPP link if Neighbor Discovery is used to configure addresses of 1278 Softwire endpoints. 1280 If DHCPv6 is available for address delegation, the M bits of the 1281 Router Advertisement SHOULD be set. The Softwire Initiator MUST then 1282 send a DHCPv6 Request to configure the address of the Softwire 1283 endpoint. 1285 Duplicate Address Detection ([RFC4861]) MUST be performed on the 1286 Softwire in both cases. 1288 5.4. DHCP 1290 The Softwire Initiator MAY use DHCP to get additional information 1291 such as delegated prefix and DNS servers. 1293 5.4.1. DHCPv6 1295 In the scenarios in Section 3.1, if the SI supports DHCPv6, it SHOULD 1296 send a Solicit message to verify if more information is available. 1298 If an SI establishing an IPv6 Softwire acts as a router (i.e., in the 1299 scenarios in Section 3.1.2 and Section 3.1.4) it MUST include the 1300 IA_PD option [RFC3633] in the DHCPv6 Solicit message [RFC3315] in 1301 order to request an IPv6 prefix. 1303 When delegating an IPv6 prefix to the SI by returning a DHCPv6 1304 Advertise message with the IA_PD and IP_PD Prefix options [RFC3633], 1305 the SC SHOULD inject a route for this prefix in the IPv6 routing 1306 table in order to forward the traffic to the relevant Softwire. 1308 Configuration of DNS MUST be done as specified in [RFC3646] and 1309 transmitted according to [RFC3315] and [RFC3736]. In general, all 1310 DHCPv6 options MUST be transmitted according to [RFC3315] and 1311 [RFC3736]. 1313 5.4.2. DHCPv4 1315 An SI establishing an IPv4 Softwire MAY send a DHCP request 1316 containing the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc]. 1317 This practice is not common but may be used to connect IPv4 subnets 1318 using Softwires, as defined in Section 3.2.2 and Section 3.2.4. 1320 One Subnet-Request suboption MUST be configured with the 'h' bit set 1321 to '1', as the SI is expected to perform the DHCP server function. 1322 The 'i' bit of the Subnet-Request suboption SHOULD be set to '0' the 1323 first time a prefix is requested and to '1' on subsequent requests, 1324 if a prefix has been allocated. The Prefix length suboption SHOULD 1325 be 0 by default. If the SI is configured to support only specific 1326 prefix lengths, it SHOULD specify the longest (smallest) prefix 1327 length it supports. 1329 If the SI was previously assigned a prefix from that same SC, it 1330 SHOULD include the Subnet-Information suboption with the prefix it 1331 was previously assigned. The 'c' and 's' bits of the suboption 1332 SHOULD be set to '0'. 1334 In the scenarios in Section 3.2, when delegating an IPv4 prefix to 1335 the SI, the SC SHOULD inject a route for this prefix in the IPv4 1336 routing table in order to forward the traffic to the relevant 1337 Softwire. 1339 6. Considerations about the Address Provisioning Model 1341 This section describes how a Softwire Concentrator may manage 1342 delegated addresses for Softwire endpoints and for subnets behind the 1343 Softwire Initiator. One common practice is to aggregate endpoints' 1344 addresses and delegated prefixes into one prefix routed to the SC. 1345 The main benefit is to ease the routing scheme by isolating on the SC 1346 succeeding route injections (when delegating new prefixes for SI). 1348 6.1. Softwire Endpoints' Addresses 1350 6.1.1. IPv6 1352 A Softwire Concentrator should provide globally routable addresses to 1353 Softwire endpoints. Other types of addresses such as Unique Local 1354 Addresses (ULA) [RFC4193] may be used to address Softwire endpoints 1355 in a private network with no global connectivity. A single /64 1356 should be assigned to the Softwire to address both Softwire 1357 endpoints. 1359 Global or ULA addresses must be assigned to endpoints when the 1360 scenario "Host CPE as Softwire Initiator" (described in 1361 Section 3.1.1) is considered to be deployed. For other scenarios, 1362 link local addresses may also be used. 1364 6.1.2. IPv4 1366 A Softwire Concentrator may provide either globally routable or 1367 private IPv4 addresses. When using IPv4 private addresses [RFC1918] 1368 on the endpoints, it is not recommended to delegate an IPv4 private 1369 prefix to the SI, as it can lead to a nested-NAT situations. 1371 The endpoints of the PPP link use host addresses (i.e., /32), 1372 negotiated using IPCP. 1374 6.2. Delegated Prefixes 1376 6.2.1. IPv6 Prefixes 1378 Delegated IPv6 prefixes should be of global scope if the IPv6 1379 addresses assigned to endpoints are global. Using ULA addresses is 1380 not recommended when the subnet is connected to the global IPv6 1381 Internet. When using ULA IPv6 address for endpoint, the delegated 1382 IPv6 prefix may be either of Global or ULA scope. 1384 Delegated IPv6 prefixes are between /48 and /64 in length. When an 1385 SI receives a prefix shorter than 64, it can assign different /64 1386 prefixes to each of its interfaces. An SI receiving a single /64 is 1387 expected to perform bridging if more than one interface are available 1388 (e.g., wired and wireless). 1390 6.2.2. IPv4 Prefixes 1392 Delegated IPv4 prefixes should be routable within the address space 1393 used by assigned IPv4 addresses. Delegate non-routable IPv4 prefixes 1394 (i.e., private IPv4 prefix over public IPv4 addresses or another 1395 class of private IPv4 addresses) is not recommended as a practice for 1396 provisioning and address translation should be considered in these 1397 cases. The prefix length is between /8 and /30. 1399 6.3. Possible Address Provisioning Scenarios 1401 This section summarizes the different scenarios for address 1402 provisioning with the considerations given in the previous sections. 1404 6.3.1. Scenarios for IPv6 1406 This table describes the possible combination of IPv6 address scope 1407 for endpoints and delegated prefixes. 1409 +------------------+-----------------------+------------------------+ 1410 | Endpoint IPv6 | Delegated Global IPv6 | Delegated ULA IPv6 | 1411 | Address | Prefix | Prefix | 1412 +------------------+-----------------------+------------------------+ 1413 | Link Local | Possible | Possible | 1414 | | | | 1415 | ULA | Possible | Possible | 1416 | | | | 1417 | Global | Possible | Possible, but Not | 1418 | | | Recommended | 1419 +------------------+-----------------------+------------------------+ 1421 Table 1: Scenarios for IPv6 1423 6.3.2. Scenarios for IPv4 1425 This table describes the possible combination of IPv4 address scope 1426 for endpoints and delegated prefixes. 1428 +-------------+-----------------+-----------------------------------+ 1429 | Endpoint | Delegated | Delegated Private IPv4 Prefix | 1430 | IPv4 | Public IPv4 | | 1431 | Address | Prefix | | 1432 +-------------+-----------------+-----------------------------------+ 1433 | Private | Possible | Possible, but Not Recommended | 1434 | IPv4 | | when using NAT (cf. | 1435 | | | Section 6.1.2) | 1436 | | | | 1437 | Public IPv4 | Possible | Possible, but NAT usage is | 1438 | | | recommended (cf. Section 6.2.2) | 1439 +-------------+-----------------+-----------------------------------+ 1441 Table 2: Scenarios for IPv4 1443 7. Considerations about Address Stability 1445 A Softwire can provide stable addresses even if the underlying 1446 addressing scheme changes, by opposition to automatic tunneling. A 1447 Softwire Concentrator should always provide the same address and 1448 prefix to a reconnecting user. However, if the goal of the Softwire 1449 service is to provide a temporary address for a roaming user, it may 1450 be provisioned to provide only a temporary address. 1452 The address and prefix are expected to change when reconnecting to a 1453 different Softwire Concentrator. However an organization providing a 1454 Softwire service may provide the same address and prefix across 1455 different Softwire Concentrators at the cost of a more fragmented 1456 routing table. The routing fragmentation issue may be limited if the 1457 prefixes are aggregated in a location topologically close to the SC. 1458 This would be the case for example if several SCs are put in parallel 1459 for load-balancing purpose. 1461 8. Considerations about RADIUS Integration 1463 The Softwire Concentrator is expected to act as a client to a AAA 1464 server, for example a RADIUS server. During the PPP authentication 1465 phase, the RADIUS server may return additional information in the 1466 form of attributes in the Access-Accept message. 1468 The Softwire Concentrator may include the Tunnel-Type and Tunnel- 1469 Medium-Type attributes [RFC2868] in the Access-Request messages to 1470 provide a hint of the type of Softwire being configured. 1472 8.1. Softwire Endpoints 1474 8.1.1. IPv6 Softwires 1476 If the RADIUS server includes a Framed-Interface-Id attribute 1477 [RFC3162], the Softwire Concentrator must send it to the Softwire 1478 Initiator in the Interface-Identifier field of its IPV6CP 1479 Configuration Request message. 1481 If the Framed-IPv6-Prefix attribute [RFC3162] is included, that 1482 prefix must be used in the router advertisements sent to the SI. If 1483 Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC 1484 must choose a prefix from that pool to send RAs. 1486 8.1.2. IPv4 Softwires 1488 If the Framed-IP-Address attribute [RFC2865] is present, the Softwire 1489 Concentrator must provide that address to the Softwire Initiator 1490 during IPCP address negotiation. That is, when the Softwire 1491 Initiator requests an IP address from the Softwire Concentrator, the 1492 address provided should be the Framed-IP-Address. 1494 8.2. Delegated Prefixes 1496 8.2.1. IPv6 Prefixes 1498 If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the 1499 RADIUS Access-Accept message, it must be used by the Softwire 1500 Concentrator for the delegation of the IPv6 prefix. Since the prefix 1501 delegation is performed by DHCPv6 and the attribute is linked to a 1502 username, the SC must associate the DHCP Unique Identifier (DUID) of 1503 a DHCPv6 request to the tunnel it came from and its user. 1505 Interaction between RADIUS, PPP and DHCPv6 server may follow the 1506 mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. In this case, 1507 during the Softwire authentication phase, PPP collects the RADIUS 1508 attributes for the user such as Delegated-IPv6-Prefix. A specific 1509 DHCPv6 relay is assigned to the Softwire. The DHCPv6 relay fills in 1510 these attributes in the Relay agent RADIUS Attribute Option (RRAO) 1511 DHCPv6 option, before forwarding the DHCPv6 requests to the DHCPv6 1512 server. 1514 8.2.2. IPv4 Prefixes 1516 RADIUS does not define an attribute for the delegated IPv4 Prefix. 1517 Attributes indicating an IPv4 prefix and its length (for instance the 1518 combination of the Framed-IP-Address and Framed-IP-Netmask attributes 1519 [RFC2865]) may be used by the Softwire Concentrator to delegate an 1520 IPv4 prefix to the Softwire Initiator. The Softwire Concentrator 1521 must add a corresponding route with the Softwire Initiator as next- 1522 hop. 1524 As this practice had been used, the inclusion of the Framed-IP- 1525 Netmask attribute along with the Framed-IP-Address attribute tells 1526 the Softwire Concentrator to delegate an IPv4 prefix to the Softwire 1527 Initiator (e.g., in the IPv4 over IPv6 scenarios where the Softwire 1528 Initiator is a router, see Section 3.2.2 and Section 3.2.4), as the 1529 SC should forward packets destined to any IPv4 address in the prefix 1530 to the SI. 1532 9. Considerations for Maintenance and Statistics 1534 Existing protocol mechanics for conveying adjunct or accessory 1535 information for logging purposes, including L2TPv2 and RADIUS 1536 methods, can include informational text that the behavior is 1537 according to the Softwire "Hub and Spoke" framework (following the 1538 implementation details specified in this document). 1540 9.1. RADIUS Accounting 1542 RADIUS Accounting for L2TP and PPP are documented (see Section 4.3). 1544 When deploying Softwire solutions, operators may experience 1545 difficulties to differentiate the address family of the traffic 1546 reported in accounting information from RADIUS. This problem and 1547 some potential solutions are described in 1548 [I-D.stevant-softwire-accounting]. 1550 9.2. MIBs 1552 MIB support for L2TPv2 and PPP are documented (see Section 4.4). 1553 Also see [RFC4293]. 1555 10. Security Considerations 1557 One design goal of the "Hub and Spoke" problem is to very strongly 1558 consider the reuse of already deployed protocols (see [RFC4925]). 1559 Another design goal is a solution with very high scaling properties. 1560 L2TPv2 [RFC2661] is the phase 1 protocol used in the Softwire "Hub 1561 and Spoke" solution space, and the L2TPv2 security considerations 1562 apply to this document (see Section 9 of [RFC2661]). 1564 The L2TPv2 Softwire solution adds the following considerations: 1566 o L2TP Tunnel Authentication (see Sections 5.1.1 and 9.1 of 1567 [RFC2661]) provides authentication at tunnel setup. It may be 1568 used to limit DoS attacks by authenticating the tunnel before L2TP 1569 and PPP resources are allocated. 1571 o In a Softwire environment, L2TPv2 AVPs do not transport sensitive 1572 data, and thus the L2TPv2 AVP hiding mechanism is not used (see 1573 Section 5.1.1). 1575 o PPP CHAP [RFC1994] provides basic user authentication. Other 1576 authentication protocols may additionally be supported (see 1577 Section 5.2.3). 1579 L2TPv2 can also be secured with IPsec, to provide privacy, integrity, 1580 and replay protection. Currently, there are two different solutions 1581 for security L2TPv2 with IPsec: 1583 o Securing L2TPv2 using IPsec "version 2" (RFC 24xx/IKEv1) is 1584 specified in [RFC3193], [RFC3947] and [RFC3948]. When L2TPv2 is 1585 used in the Softwire context, the voluntary tunneling model 1586 applies. [RFC3193] describes the interaction between IPsec and 1587 L2TPv2, and is deployed. [RFC3193] MUST be supported, given that 1588 deployed technology must be very strongly considered [RFC4925] for 1589 this 'time-to-market' solution. 1591 o [I-D.ietf-softwire-security-requirements] also specifies a new 1592 (incompatible) solution for securing L2TPv2 with IPsec "version 3" 1593 (RFC 43xx/IKEv2). Section 3.5 of 1594 [I-D.ietf-softwire-security-requirements] describes the 1595 advantanges of using IKEv2, and this solution needs to be 1596 considered for future phases. 1598 Additional discussion of Softwire security is contained in 1599 [I-D.ietf-softwire-security-requirements]. 1601 11. IANA Considerations 1603 [RFC Editor: please remove this section prior to publication.] 1605 This document creates no new requirements on IANA namespaces. 1607 12. Acknowledgements 1609 The authors would like to acknowledge the following contributors who 1610 provided helpful input on this document: Florent Parent, Jordi Palet 1611 Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, 1612 Francis Dupont, Ralph Droms, Hemant Singh, and Alain Durand. 1614 The authors would also like to acknowledge the participants in the 1615 Softwires interim meetings held in Hong Kong, China, and Barcelona, 1616 Spain. The minutes for the interim meeting at the China University - 1617 Hong Kong (February 23-24, 2006) are at 1618 . The minutes 1619 for the interim meeting at Polytechnic University of Catalonia - 1620 Barcelona (September 14-15, 2006) are reachable at 1621 . The 1622 Softwires auxiliary page at 1623 contains additional meeting information. 1625 During and after the IETF Last Call, useful comments and discussion 1626 were provided by Jari Arkko, David Black, Lars Eggert, Pasi Eronen, 1627 and Dan Romascanu. 1629 13. References 1631 13.1. Normative References 1633 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 1634 (IPCP)", RFC 1332, May 1992. 1636 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1637 RFC 1661, July 1994. 1639 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1640 E. Lear, "Address Allocation for Private Internets", 1641 BCP 5, RFC 1918, February 1996. 1643 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1644 Protocol (CHAP)", RFC 1994, August 1996. 1646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1647 Requirement Levels", BCP 14, RFC 2119, March 1997. 1649 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1650 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1651 RFC 2661, August 1999. 1653 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1654 "Remote Authentication Dial In User Service (RADIUS)", 1655 RFC 2865, June 2000. 1657 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1658 RFC 3162, August 2001. 1660 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 1661 "Securing L2TP using IPsec", RFC 3193, November 2001. 1663 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1664 and M. Carney, "Dynamic Host Configuration Protocol for 1665 IPv6 (DHCPv6)", RFC 3315, July 2003. 1667 [RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two 1668 Tunneling Protocol "L2TP" Management Information Base", 1669 RFC 3371, August 2002. 1671 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1672 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1673 December 2003. 1675 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1676 (DHCP) Service for IPv6", RFC 3736, April 2004. 1678 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1679 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1680 January 2005. 1682 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1683 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1684 RFC 3948, January 2005. 1686 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1687 Attribute", RFC 4818, April 2007. 1689 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1690 Address Autoconfiguration", RFC 4862, September 2007. 1692 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 1693 PPP", RFC 5072, September 2007. 1695 13.2. Informative References 1697 [I-D.ietf-dhc-subnet-alloc] 1698 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 1699 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-09 1700 (work in progress), March 2009. 1702 [I-D.ietf-dhc-v6-relay-radius] 1703 Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option", 1704 draft-ietf-dhc-v6-relay-radius-02 (work in progress), 1705 February 2006. 1707 [I-D.ietf-softwire-security-requirements] 1708 Yamamoto, S., Williams, C., Parent, F., and H. Yokota, 1709 "Softwire Security Analysis and Requirements", 1710 draft-ietf-softwire-security-requirements-07 (work in 1711 progress), March 2009. 1713 [I-D.stevant-softwire-accounting] 1714 Stevant, B., "Accounting on Softwires", 1715 draft-stevant-softwire-accounting-01 (work in progress), 1716 October 2006. 1718 [RFC1471] Kastenholz, F., "The Definitions of Managed Objects for 1719 the Link Control Protocol of the Point-to-Point Protocol", 1720 RFC 1471, June 1993. 1722 [RFC1473] Kastenholz, F., "The Definitions of Managed Objects for 1723 the IP Network Control Protocol of the Point-to-Point 1724 Protocol", RFC 1473, June 1993. 1726 [RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control 1727 Protocol Extensions for Name Server Addresses", RFC 1877, 1728 December 1995. 1730 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1731 RFC 2131, March 1997. 1733 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1734 Extensions", RFC 2132, March 1997. 1736 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 1737 RFC 2433, October 1998. 1739 [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting 1740 Modifications for Tunnel Protocol Support", RFC 2867, 1741 June 2000. 1743 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, 1744 M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1745 Support", RFC 2868, June 2000. 1747 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1748 Address Translator (Traditional NAT)", RFC 3022, 1749 January 2001. 1751 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1752 Authentication Dial In User Service)", RFC 3575, 1753 July 2003. 1755 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1756 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1757 December 2003. 1759 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1760 Levkowetz, "Extensible Authentication Protocol (EAP)", 1761 RFC 3748, June 2004. 1763 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 1764 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1766 [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005. 1768 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1769 Addresses", RFC 4193, October 2005. 1771 [RFC4293] Routhier, S., "Management Information Base for the 1772 Internet Protocol (IP)", RFC 4293, April 2006. 1774 [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- 1775 Edge (PWE3) Fragmentation and Reassembly", RFC 4623, 1776 August 2006. 1778 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1779 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1780 RFC 4787, January 2007. 1782 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1783 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1784 September 2007. 1786 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 1787 Problem Statement", RFC 4925, July 2007. 1789 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1790 Extensions for Stateless Address Autoconfiguration in 1791 IPv6", RFC 4941, September 2007. 1793 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 1794 Dial In User Service (RADIUS) Implementation Issues and 1795 Suggested Fixes", RFC 5080, December 2007. 1797 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1798 for Application Designers", BCP 145, RFC 5405, 1799 November 2008. 1801 Authors' Addresses 1803 Bill Storer 1804 Cisco Systems 1805 170 W Tasman Dr 1806 San Jose, CA 95134 1807 USA 1809 Email: bstorer@cisco.com 1811 Carlos Pignataro (editor) 1812 Cisco Systems 1813 7200 Kit Creek Road 1814 PO Box 14987 1815 Research Triangle Park, NC 27709 1816 USA 1818 Email: cpignata@cisco.com 1820 Maria Alice Dos Santos 1821 Cisco Systems 1822 170 W Tasman Dr 1823 San Jose, CA 95134 1824 USA 1826 Email: mariados@cisco.com 1827 Bruno Stevant (editor) 1828 TELECOM Bretagne 1829 2 rue de la Chataigneraie CS17607 1830 Cesson Sevigne, 35576 1831 France 1833 Email: bruno.stevant@telecom-bretagne.eu 1835 Jean-Francois Tremblay 1836 Videotron Ltd. 1837 612 Saint-Jacques 1838 Montreal, QC H3C 4M8 1839 Canada 1841 Email: jf@jftremblay.com