idnits 2.17.1 draft-ietf-softwire-hs-framework-l2tpv2-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1984. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1995. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2002. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2008. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 10, 2008) is 5768 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 521, but not defined == Missing Reference: 'IPv6-only' is mentioned on line 702, 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) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-07 == Outdated reference: A later version (-09) exists of draft-ietf-softwire-security-requirements-06 == 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) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 8 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: January 11, 2009 Cisco Systems 6 B. Stevant, Ed. 7 TELECOM Bretagne 8 J. Tremblay 9 Trellia Networks 10 July 10, 2008 12 Softwire Hub & Spoke Deployment Framework with L2TPv2 13 draft-ietf-softwire-hs-framework-l2tpv2-09 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 11, 2009. 40 Abstract 42 This document describes the framework of the Softwire "Hub and Spoke" 43 solution with the Layer 2 Tunneling Protocol version 2 (L2TPv2). The 44 implementation details specified in this document should be followed 45 to achieve interoperability among different vendor implementations. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 51 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 52 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 6 53 1.4. Considerations . . . . . . . . . . . . . . . . . . . . . . 7 55 2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7 56 2.1. Traditional Network Address Translation (NAT and NAPT) . . 7 57 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 58 2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.5. Authentication, Authorization and Accounting (AAA) . . . . 8 61 2.6. Privacy, Integrity, and Replay Protection . . . . . . . . 8 62 2.7. Operations and Management (OAM) . . . . . . . . . . . . . 8 63 2.8. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 9 65 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 9 66 3.1. IPv6 over IPv4 Softwires with L2TPv2 . . . . . . . . . . . 9 67 3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 9 68 3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 10 69 3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 12 70 3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 13 71 3.2. IPv4 over IPv6 Softwires with L2TPv2 . . . . . . . . . . . 14 72 3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 14 73 3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 15 74 3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 16 75 3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 16 77 4. Standardization Status . . . . . . . . . . . . . . . . . . . . 17 78 4.1. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 4.2. Securing the Softwire Transport . . . . . . . . . . . . . 18 80 4.3. Authentication Authorization Accounting . . . . . . . . . 18 81 4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 19 83 4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 19 84 4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 19 86 5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 19 87 5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 22 88 5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 22 89 5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 24 90 5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 25 91 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 25 92 5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 25 93 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 26 94 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 26 95 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 26 96 5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 26 98 5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 99 5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 27 100 5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 27 101 5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 27 102 5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 103 5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28 104 5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 28 106 6. Considerations about the Address Provisioning Model . . . . . 29 107 6.1. Softwire Endpoints' Addresses . . . . . . . . . . . . . . 29 108 6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 29 109 6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 29 110 6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 29 111 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30 112 6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 30 113 6.3. Possible Address Provisioning Scenarios . . . . . . . . . 30 114 6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 30 115 6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 31 117 7. Considerations about Address Stability . . . . . . . . . . . . 31 119 8. Considerations about RADIUS Integration . . . . . . . . . . . 31 120 8.1. Softwire Endpoints . . . . . . . . . . . . . . . . . . . . 32 121 8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 32 122 8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 32 123 8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 32 124 8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 32 125 8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 33 127 9. Considerations for Maintenance and Statistics . . . . . . . . 33 128 9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 33 129 9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 131 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 133 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 135 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 137 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 138 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 139 13.2. Informative References . . . . . . . . . . . . . . . . . . 36 141 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 37 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 143 Intellectual Property and Copyright Statements . . . . . . . . . . 45 145 1. Introduction 147 The Softwires Working Group has selected Layer Two Tunneling Protocol 148 version 2 (L2TPv2) as the phase 1 protocol to be deployed in the 149 Softwire "Hubs and Spokes" solution space. This document describes 150 the framework for the L2TPv2 "Hubs and Spokes" solution, and the 151 implementation details specified in this document should be followed 152 to achieve interoperability among different vendor implementations. 154 In the "Hubs and Spokes" solution space, a Softwire is established to 155 provide the home network with IPv4 connectivity across an IPv6-only 156 access network, or IPv6 connectivity across an IPv4-only access 157 network. When L2TPv2 is used in the Softwire context, the voluntary 158 tunneling model applies. The Softwire Initiator (SI) at the home 159 network takes the role of the L2TP Access Concentrator (LAC) client 160 (initiating both the L2TP tunnel/session and the PPP link) while the 161 Softwire Concentrator (SC) at the ISP takes the role of the L2TP 162 Network Server (LNS). Since L2TPv2 compulsory tunneling model does 163 not apply to Softwires, it should not be requested or honored. This 164 document identifies all the voluntary tunneling related L2TPv2 165 attributes that apply to Softwires and specifies the handling 166 mechanism for such attributes in order to avoid ambiguities in 167 implementations. This document also identifies the set of L2TPv2 168 attributes specific to compulsory tunneling model that do not apply 169 to Softwires and specifies the mechanism to ignore or nullify their 170 effect within the Softwire context. 172 The SI and SC must follow the L2TPv2 operations described in 173 [RFC2661] when performing Softwire establishment, tear-down and OAM. 174 With L2TPv2, a Softwire consists of an L2TPv2 Control Connection 175 (also referred to as Control Channel), a single L2TPv2 Session, and 176 the PPP link negotiated over the Session. To establish the Softwire, 177 the SI first initiates an L2TPv2 Control Channel to the SC which 178 accepts the request and terminates the Control Channel. L2TPv2 179 supports an optional mutual Control Channel authentication which 180 allows both SI and SC to validate each other's identity at the 181 initial phase of hand-shaking before proceeding with Control Channel 182 establishment. After the L2TPv2 Control Channel is established 183 between the SI and SC, the SI initiates an L2TPv2 Session to the SC. 184 Then the PPP/IP link is negotiated over the L2TPv2 Session between 185 the SI and SC. After the PPP/IP link is established, it acts as the 186 Softwire between the SI and SC for tunneling IP traffic of one 187 Address Family (AF) across the access network of another Address 188 Family. 190 During the life of the Softwire, both SI and SC send L2TPv2 keepalive 191 HELLO messages to monitor the health of the Softwire and the peer 192 LCCE, and to potentially refresh the NAT/NAPT translation entry at 193 the CPE or at the other end of the access link. Optionally, LCP ECHO 194 messages can be used as keepalives for the same purposes. In the 195 event of keepalive timeout or administrative shutdown of the 196 Softwire, either SI or SC may tear down the Softwire by tearing down 197 the L2TPv2 Control Channel and Session as specified in [RFC2661]. 199 1.1. Abbreviations 201 AF Address Family, IPv4 or IPv6. 203 SC Softwire Concentrator, the node terminating the Softwire in 204 the service provider network (See [RFC4925]). 206 SI Softwire Initiator, the node initiating the Softwire within 207 the customer network (See [RFC4925]). 209 LCCE L2TP Control Connection Endpoint, an L2TP node that exists at 210 either end of an L2TP Control Connection (See [RFC3931]). 212 SPH Softwire Payload Header, the IP headers being carried within a 213 softwire (See [RFC4925]). 215 STH Softwire Transport Header, the outermost IP header of a 216 softwire (See [RFC4925]). 218 SW Softwire, a shared-state "tunnel" created between the SC and 219 SI. (See [RFC4925]). 221 1.2. Requirements Language 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 225 document are to be interpreted as described in [RFC2119]. 227 1.3. Contributing Authors 229 Following is the complete list of contributors to this document. 231 Maria Alice Dos Santos, Cisco Systems 232 Carlos Pignataro, Cisco Systems 233 Bill Storer, Cisco Systems 234 Jean-Francois Tremblay, Trellia Networks 235 Laurent Toutain, GET/ENST Bretagne 236 Bruno Stevant, TELECOM Bretagne 238 1.4. Considerations 240 Some sections of this document contain considerations that are not 241 required for interoperability and correct operation of Softwire 242 implementations. These sections are marked as "Considerations". 244 2. Applicability of L2TPv2 for Softwire Requirements 246 A list of Softwire "Hubs and Spokes" requirements has been identified 247 by the Softwire Problem Statement [RFC4925]. The following sub- 248 sections describe how L2TPv2 fulfills each of them. 250 2.1. Traditional Network Address Translation (NAT and NAPT) 252 A "Hubs and Spokes" Softwire must be able to traverse Network Address 253 Translation (NAT) and Network Address Port Translation (NAPT, also 254 referred to as Port Address Translation or PAT) devices [RFC3022] in 255 case the scenario in question involves a non-upgradable pre-existing 256 IPv4 home gateway performing NAT/NAPT or some carrier equipment at 257 the other end of the access link performing NAT/NAPT. The L2TPv2 258 Softwire (i.e., Control Channel and Session) is capable of NAT/NAPT 259 traversal since L2TPv2 can run over UDP. 261 Since L2TPv2 does not detect NAT/NAPT along the path, L2TPv2 does not 262 offer the option of disabling UDP. The UDP encapsulation is present 263 regardless of NAT/NAPT presence. Both NAT/NAPT "autodetect" and UDP 264 "bypass" are optional requirements in Section 2.3 of [RFC4925]. 266 2.2. Scalability 268 In the "Hubs and Spokes" model, a carrier must be able to scale the 269 solution to millions of Softwire Initiators by adding more hubs 270 (i.e., Softwire Concentrators). L2TPv2 is a widely deployed protocol 271 in broadband services, and its scalability has been proven in 272 multiple large-scale IPv4 Virtual Private Network deployments which 273 scale up to millions of subscribers each. 275 2.3. Routing 277 There are no dynamic routing protocols between the SC and SI. A 278 default route from the SI to the SC is used. 280 2.4. Multicast 282 Multicast protocols simply run over L2TPv2 Softwires transparently 283 together with other regular IP traffic. 285 2.5. Authentication, Authorization and Accounting (AAA) 287 L2TPv2 supports optional mutual Control Channel authentication and 288 leverages the optional mutual PPP per-session authentication. L2TPv2 289 is well integrated with AAA solutions (such as RADIUS) for both 290 authentication and authorization. Most L2TPv2 implementations 291 available in the market support logging of authentication and 292 authorization events. 294 L2TPv2 integration with RADIUS accounting (RADIUS Accounting 295 extension for tunnel [RFC2867]) allows the collection and reporting 296 of L2TPv2 Softwire usage statistics. 298 2.6. Privacy, Integrity, and Replay Protection 300 Since L2TPv2 runs over IP/UDP in the Softwire context, IPsec ESP can 301 be used in conjunction to provide per-packet authentication, 302 integrity, replay protection and confidentiality for both L2TPv2 303 control and data traffic [RFC3193] and [RFC3948]. 305 For Softwire deployments in which full payload security is not 306 required, the L2TPv2 built-in Control Channel authentication and the 307 inherited PPP authentication and PPP Encryption Control Protocol can 308 be considered. 310 2.7. Operations and Management (OAM) 312 L2TPv2 supports an optional in-band keepalive mechanism which injects 313 HELLO control messages after a specified period of time has elapsed 314 since the last data or control message was received on a tunnel (see 315 Section 5.5 of [RFC2661]). If the HELLO control message is not 316 reliably delivered, then the Control Channel and its Session will be 317 torn down. In the Softwire context, the L2TPv2 keepalive is used to 318 monitor the connectivity status between the SI and SC and/or as a 319 refresh mechanism for any NAT/NAPT translation entry along the access 320 link. 322 LCP ECHO offers a similar mechanism to monitor the connectivity 323 status, as described in [RFC1661]. Softwire implementations SHOULD 324 use L2TPv2 Hello keepalives and in addition MAY use PPP LCP Echo 325 messages to ensure Dead End Detection and/or to refresh NAT/NAPT 326 translation entries. The combination of these two mechanisms can be 327 used as an optimization. 329 L2TPv2 MIB [RFC3371] supports the complete suite of management 330 operations such as configuration of Control Channel and Session, 331 polling of Control Channel and Session status and their traffic 332 statistics and notifications of Control Channel and Session UP/DOWN 333 events. 335 2.8. Encapsulations 337 L2TPv2 supports the following encapsulations: 339 o IPv6/PPP/L2TPv2/UDP/IPv4 341 o IPv4/PPP/L2TPv2/UDP/IPv6 343 o IPv4/PPP/L2TPv2/UDP/IPv4 345 o IPv6/PPP/L2TPv2/UDP/IPv6 347 Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not 348 support "autodetect" of NAT/NAPT. 350 3. Deployment Scenarios 352 For the "Hubs and Spokes" problem space, four scenarios have been 353 identified. In each of these four scenarios, different home 354 equipment plays the role of the Softwire Initiator. This section 355 elaborates each scenario with L2TPv2 as the Softwire protocol and 356 other possible protocols involved to complete the solution. This 357 section examines the four scenarios for both IPv6 over IPv4 358 (Section 3.1) and IPv4 over IPv6 (Section 3.2) encapsulations. 360 3.1. IPv6 over IPv4 Softwires with L2TPv2 362 The following subsections cover IPv6 connectivity (SPH) across an 363 IPv4-only access network (STH) using a Softwire. 365 3.1.1. Host CPE as Softwire Initiator 367 The Softwire Initiator (SI) is the host CPE (directly connected to a 368 modem), which is dual-stack. There is no other gateway device. The 369 IPv4 traffic SHOULD NOT traverse the softwire. See Figure 1. 371 IPv6 or dual-stack IPv4-only dual-stack 372 |------------------||-----------------||----------| 374 I SC SI 375 N +-----+ +----------+ 376 T | | | v4/v6 | 377 E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| host CPE | 378 R [network] | | [ network ] | | 379 N | LNS | |LAC Client| 380 E +-----+ +----------+ 381 T _ _ _ _ _ _ _ _ _ 382 ()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic 383 PPP o L2TPv2 o UDP o IPv4 (SPH) 384 Softwire 386 <------------------> 387 IPV6CP: capable of /64 Intf-Id assignment or 388 uniqueness check 390 |------------------>/64 prefix 391 RA 392 |------------------>DNS, etc. 393 DHCPv6 395 Figure 1: Host CPE as Softwire Initiator 397 In this scenario, after the L2TPv2 Control Channel and Session 398 establishment and PPP LCP negotiation (and optionally PPP 399 Authentication) are successful, IPV6CP negotiates IPv6 over PPP which 400 also provides the capability for the ISP to assign the 64-bit 401 Interface-Identifier to the host CPE or perform uniqueness validation 402 for the two interface identifiers at the two PPP ends [RFC5072]. 403 After IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration / 404 Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can 405 inform the host CPE of a prefix to use for stateless address 406 autoconfiguration through a Router Advertisement (RA) while other 407 nonaddress configuration options (such as DNS [RFC3646] or other 408 servers' addresses that might be available) can be conveyed to the 409 host CPE via DHCPv6. 411 3.1.2. Router CPE as Softwire Initiator 413 The Softwire Initiator (SI) is the router CPE, which is a dual-stack 414 device. The IPv4 traffic SHOULD NOT traverse the Softwire. See 415 Figure 2. 417 IPv6 or dual-stack IPv4-only dual-stack 418 |------------------||-----------------||---------------------| 420 I SC SI 421 N +-----+ +----------+ 422 T | | | v4/v6 | +-----+ 423 E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| CPE |----|v4/v6| 424 R [network] | | [ network ] | | | host| 425 N | LNS | |LAC Client| +-----+ 426 E +-----+ +----------+ 427 T _ _ _ _ _ _ _ _ _ 428 ()_ _ _ _ _ _ _ _ _() <-------- IPv6 traffic 429 PPP o L2TPv2 o UDP o IPv4 (SPH) 430 Softwire 432 <------------------> 433 IPV6CP: capable of /64 Intf-Id assignment or 434 uniqueness check 436 |------------------>/64 prefix 437 RA 438 |------------------>/48 prefix, 439 DHCPv6 DNS, etc. 441 |------->/64 prefix 442 RA 443 |-------> DNS, etc. 444 DHCPv4/v6 446 Figure 2: Router CPE as Softwire Initiator 448 In this scenario, after the L2TPv2 Control Channel and Session 449 establishment and PPP LCP negotiation (and optionally PPP 450 Authentication) are successful, IPV6CP negotiates IPv6 over PPP which 451 also provides the capability for the ISP to assign the 64-bit 452 Interface-Identifier to the router CPE or perform uniqueness 453 validation for the two interface identifiers at the two PPP ends 454 [RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address 455 Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP 456 link, and the LNS can inform the router CPE of a prefix to use for 457 stateless address autoconfiguration through a Router Advertisement 458 (RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g., 459 delegating a prefix to be used within the home network [RFC3633]) and 460 convey other nonaddress configuration options (such as DNS [RFC3646]) 461 to the router CPE. 463 3.1.3. Host behind CPE as Softwire Initiator 465 The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack 466 host (behind the IPv4-only CPE), which acts as an IPv6 host CPE. The 467 IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 3. 469 IPv6 or dual-stack IPv4-only dual-stack 470 |------------------||----------------------------||----------| 472 I SC SI 473 N +-----+ +----------+ 474 T | | +-------+ | v4/v6 | 475 E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....|v4-only|--| host | 476 R [network] | | [ network ] | CPE | | | 477 N | LNS | +-------+ |LAC Client| 478 E +-----+ +----------+ 479 T _ _ _ _ _ _ _ _ _ _ _ _ _ _ 480 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6 481 PPP o L2TPv2 o UDP o IPv4 traffic 482 Softwire (SPH) 484 <------------------------------> 485 IPV6CP: capable of /64 Intf-Id assignment or 486 uniqueness check 488 |------------------------------>/64 prefix 489 RA 490 |------------------------------>DNS, etc. 491 DHCPv6 493 Figure 3: Host behind CPE as Softwire Initiator 495 In this scenario, after the L2TPv2 Control Channel and Session 496 establishment and PPP LCP negotiation (and optionally PPP 497 Authentication) are successful, IPV6CP negotiates IPv6 over PPP which 498 also provides the capability for the ISP to assign the 64-bit 499 Interface-Identifier to the host or perform uniqueness validation for 500 the two interface identifiers at the two PPP ends [RFC5072]. After 501 IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration / 502 Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can 503 inform the host of a prefix to use for stateless address 504 autoconfiguration through a Router Advertisement (RA) while other 505 nonaddress configuration options (such as DNS [RFC3646]) can be 506 conveyed to the host via DHCPv6. 508 3.1.4. Router behind CPE as Softwire Initiator 510 The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack 511 device (behind the IPv4-only CPE) acting as an IPv6 CPE router inside 512 the home network. The IPv4 traffic SHOULD NOT traverse the Softwire. 513 See Figure 4. 515 IPv6 or dual-stack IPv4-only dual-stack 516 |------------------||-------------------------||-------------| 518 I SC SI 519 N +-----+ +----------+ 520 T | | +-------+ | v4/v6 | 521 E <==[ IPv6 ]....|v4/v6|..[IPv4-only]..|v4-only|---| router | 522 R [network] | | [ network ] | CPE | | | | 523 N | LNS | +-------+ | |LAC Client| 524 E +-----+ | +----------+ 525 T | 526 ---------+-----+ 527 |v4/v6| 528 | host| 529 _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ 530 ()_ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6 531 PPP o L2TPv2 o UDP o IPv4 traffic 532 Softwire (SPH) 534 <---------------------------> 535 IPV6CP: capable of /64 Intf-Id assignment or 536 uniqueness check 538 |--------------------------->/64 prefix 539 RA 540 |--------------------------->/48 prefix, 541 DHCPv6 DNS, etc. 543 |----> /64 544 RA prefix 545 |----> DNS, 546 DHCPv6 etc. 548 Figure 4: Router behind CPE as Softwire Initiator 550 In this scenario, after the L2TPv2 Control Channel and Session 551 establishment and PPP LCP negotiation (and optionally PPP 552 Authentication) are successful, IPV6CP negotiates IPv6 over PPP which 553 also provides the capability for the ISP to assign the 64-bit 554 Interface-Identifier to the v4/v6 router or perform uniqueness 555 validation for the two interface identifiers at the two PPP ends 556 [RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address 557 Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP 558 link, and the LNS can inform the v4/v6 router of a prefix to use for 559 stateless address autoconfiguration through a Router Advertisement 560 (RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g., 561 delegating a prefix to be used within the home network [RFC3633]) and 562 convey other nonaddress configuration options (such as DNS [RFC3646]) 563 to the v4/v6 router. 565 3.2. IPv4 over IPv6 Softwires with L2TPv2 567 The following subsections cover IPv4 connectivity (SPH) across an 568 IPv6-only access network (STH) using a Softwire. 570 3.2.1. Host CPE as Softwire Initiator 572 The Softwire Initiator (SI) is the host CPE (directly connected to a 573 modem), which is dual-stack. There is no other gateway device. The 574 IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 5. 576 IPv4 or dual-stack IPv6-only dual-stack 577 |------------------||-----------------||----------| 579 I SC SI 580 N +-----+ +----------+ 581 T | | | v4/v6 | 582 E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| host CPE | 583 R [network] | | [ network ] | | 584 N | LNS | |LAC Client| 585 E +-----+ +----------+ 586 T _ _ _ _ _ _ _ _ _ 587 ()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic 588 PPP o L2TPv2 o UDP o IPv6 (SPH) 589 Softwire 591 <------------------> 592 IPCP: capable of global IP assignment 593 and DNS, etc. 595 Figure 5: Host CPE as Softwire Initiator 597 In this scenario, after the L2TPv2 Control Channel and Session 598 establishment and PPP LCP negotiation (and optionally PPP 599 Authentication) are successful, IPCP negotiates IPv4 over PPP which 600 also provides the capability for the ISP to assign a global IPv4 601 address to the host CPE. A global IPv4 address can also be assigned 602 via DHCP. Other configuration options (such as DNS) can be conveyed 603 to the host CPE via IPCP [RFC1877] or DHCP [RFC2132]. 605 3.2.2. Router CPE as Softwire Initiator 607 IPv4 connectivity across an IPv6-only access network (STH). The 608 Softwire Initiator (SI) is the router CPE, which is a dual-stack 609 device. The IPv6 traffic SHOULD NOT traverse the Softwire. See 610 Figure 6. 612 IPv4 or dual-stack IPv6-only dual-stack Home 613 |------------------||-----------------||-------------------| 615 I SC SI 616 N +-----+ +----------+ 617 T | | | v4/v6 | +-----+ 618 E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| CPE |--|v4/v6| 619 R [network] | | [ network ] | | | host| 620 N | LNS | |LAC Client| +-----+ 621 E +-----+ +----------+ 622 T _ _ _ _ _ _ _ _ _ 623 ()_ _ _ _ _ _ _ _ _() <--------- IPv4 traffic 624 PPP o L2TPv2 o UDP o IPv6 (SPH) 625 Softwire 627 <------------------> 628 IPCP: capable of global IP assignment 629 and DNS, etc. 631 |------------------> 632 DHCPv4: prefix, mask, PD 634 private/ 635 |------> global 636 DHCP IP, DNS, 637 etc. 639 Figure 6: Router CPE as Softwire Initiator 641 In this scenario, after the L2TPv2 Control Channel and Session 642 establishment and PPP LCP negotiation (and optionally PPP 643 Authentication) are successful, IPCP negotiates IPv4 over PPP which 644 also provides the capability for the ISP to assign a global IPv4 645 address to the router CPE. A global IPv4 address can also be 646 assigned via DHCP. Other configuration options (such as DNS) can be 647 conveyed to the router CPE via IPCP [RFC1877] or DHCP [RFC2132]. For 648 IPv4 Prefix Delegation for the home network, DHCP 650 [I-D.ietf-dhc-subnet-alloc] can be used. 652 3.2.3. Host behind CPE as Softwire Initiator 654 IPv4 connectivity across an IPv6-only access network (STH). The CPE 655 is IPv6-only. The Softwire Initiator (SI) is a dual-stack host 656 (behind the IPv6 CPE), which acts as an IPv4 host CPE. The IPv6 657 traffic SHOULD NOT traverse the Softwire. See Figure 7. 659 IPv4 or dual-stack IPv6-only dual-stack 660 |------------------||----------------------------||----------| 662 I SC SI 663 N +-----+ +----------+ 664 T | | +-------+ | v4/v6 | 665 E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....|v6-only|--| host | 666 R [network] | | [ network ] | CPE | | | 667 N | LNS | +-------+ |LAC Client| 668 E +-----+ +----------+ 669 T _ _ _ _ _ _ _ _ _ _ _ _ _ _ 670 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv4 671 PPP o L2TPv2 o UDP o IPv6 traffic 672 Softwire (SPH) 674 <------------------------------> 675 IPCP: capable of global IP assignment 676 and DNS, etc. 678 Figure 7: Host behind CPE as Softwire Initiator 680 In this scenario, after the L2TPv2 Control Channel and Session 681 establishment and PPP LCP negotiation (and optionally PPP 682 Authentication) are successful, IPCP negotiates IPv4 over PPP which 683 also provides the capability for the ISP to assign a global IPv4 684 address to the host. A global IPv4 address can also be assigned via 685 DHCP. Other configuration options (such as DNS) can be conveyed to 686 the host CPE via IPCP [RFC1877] or DHCP [RFC2132]. 688 3.2.4. Router behind CPE as Softwire Initiator 690 IPv4 connectivity across an IPv6-only access network (STH). The CPE 691 is IPv6-only. The Softwire Initiator (SI) is a dual-stack device 692 (behind the IPv6-only CPE) acting as an IPv4 CPE router inside the 693 home network. The IPv6 traffic SHOULD NOT traverse the Softwire. 694 See Figure 8. 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|---| router | 703 R [network] | | [ network ] | CPE | | | | 704 N | LNS | +-------+ | |LAC Client| 705 E +-----+ | +----------+ 706 T | 707 --------+-----+ 708 |v4/v6| 709 | host| 710 _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ 711 ()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- IPv4 712 PPP o L2TPv2 o UDP o IPv4 traffic 713 Softwire (SPH) 715 <---------------------------> 716 IPCP: assigns global IP address and DNS, etc. 718 |---------------------------> 719 DHCPv4: prefix, mask, PD 721 private/ 722 |----> global 723 DHCP IP, DNS, 724 etc. 726 Figure 8: Router behind CPE as Softwire Initiator 728 In this scenario, after the L2TPv2 Control Channel and Session 729 establishment and PPP LCP negotiation (and optionally PPP 730 Authentication) are successful, IPCP negotiates IPv4 over PPP which 731 also provides the capability for the ISP to assign a global IPv4 732 address to the v4/v6 router. A global IPv4 address can also be 733 assigned via DHCP. Other configuration options (such as DNS) can be 734 conveyed to the v4/v6 router via IPCP [RFC1877] or DHCP [RFC2132]. 735 For IPv4 Prefix Delegation for the home network, DHCP 736 [I-D.ietf-dhc-subnet-alloc] can be used. 738 4. Standardization Status 740 This section groups various Internet standards documents and other 741 publications used in Softwires. 743 4.1. L2TPv2 745 RFC 2661 "Layer Two Tunneling Protocol "L2TP"" [RFC2661]. 747 * For both IPv4 and IPv6 payloads (SPH), support is 748 complete. 750 * For both IPv4 and IPv6 transports (STH), support is 751 complete. 753 4.2. Securing the Softwire Transport 755 RFC 3193 "Securing L2TP using IPsec" [RFC3193]. 757 RFC 3948 "UDP Encapsulation of IPsec ESP Packets" [RFC3948]. 759 * IPsec supports both IPv4 and IPv6 transports. 761 4.3. Authentication Authorization Accounting 763 RFC 2865 "Remote Authentication Dial In User Service (RADIUS)" 764 [RFC2865]. 766 RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol 767 Support" [RFC2867]. 769 RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868]. 771 RFC 3162 "RADIUS and IPv6" [RFC3162]. 773 4.4. MIB 775 RFC 1471 "The Definitions of Managed Objects for the Link Control 776 Protocol of the Point-to-Point Protocol" [RFC1471]. 778 RFC 1473 "The Definitions of Managed Objects for the IP Network 779 Control Protocol of the Point-to-Point Protocol" 780 [RFC1473]. 782 RFC 3371 "Layer Two Tunneling Protocol "L2TP" Management 783 Information Base" [RFC3371]. 785 RFC 4087 "IP Tunnel MIB" [RFC4087]. 787 * Both IPv4 and IPv6 transports are supported. 789 4.5. Softwire Payload Related 791 4.5.1. For IPv6 Payloads 793 RFC 4861 "Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861]. 795 RFC 4862 "IPv6 Stateless Address Autoconfiguration" [RFC4862]. 797 RFC 5072 "IP Version 6 over PPP" [RFC5072]. 799 RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" 800 [RFC3315]. 802 RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration 803 Protocol (DHCP) version 6" [RFC3633]. 805 RFC 3646 "DNS Configuration options for Dynamic Host Configuration 806 Protocol for IPv6 (DHCPv6)" [RFC3646]. 808 RFC 3736 "Stateless Dynamic Host Configuration Protocol (DHCP) 809 Service for IPv6" [RFC3736]. 811 4.5.2. For IPv4 Payloads 813 RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)" 814 [RFC1332]. 816 RFC 1661 "The Point-to-Point Protocol (PPP)" [RFC1661]. 818 RFC 1877 "PPP Internet Protocol Control Protocol Extensions for 819 Name Server Addresses" [RFC1877]. 821 RFC 2131 "Dynamic Host Configuration Protocol" [RFC2131]. 823 RFC 2132 "DHCP Options and BOOTP Vendor Extensions" [RFC2132]. 825 DHCP Subnet Allocation "Subnet Allocation Option". 827 * Work in progress, see [I-D.ietf-dhc-subnet-alloc]. 829 5. Softwire Establishment 831 A Softwire is established in three distinct steps (see Figure 9). 832 First an L2TPv2 tunnel with a single session is established from the 833 SI to the SC. Second a PPP session is established over the L2TPv2 834 session and the SI obtains an address. Third the SI optionally gets 835 other information through DHCP such as a delegated prefix and DNS 836 servers. 838 SC SI 839 | | 840 |<-------------L2TPv2------------>| Step 1 841 | | L2TPv2 Tunnel establishment 842 | | 843 |<-------------PPP--------------->| Step 2 844 |<----End Point Configuration---->| PPP and End Point 845 | | configuration 846 | | 847 |<------Router Configuration----->| Step 3 848 | | Additional configuration 849 | | (optional) 851 Figure 9: Steps for the Establishment of a Softwire 853 Figure 10 depicts details of each of the three steps required to 854 establish a Softwire. 856 SC SI 857 | | 858 | | Step 1 859 |<------------SCCRQ---------------| - 860 |-------------SCCRP-------------->| | 861 |<------------SCCCN---------------| | 862 |<------------ICRQ----------------| | L2TPv2 863 |-------------ICRP--------------->| | 864 |<------------ICCN----------------| - 865 | | 866 | | Step 2 867 |<-----Configuration-Request------| - 868 |------Configuration-Request----->| | PPP 869 |--------Configuration-Ack------->| | LCP 870 |<-------Configuration-Ack--------| - 871 | | 872 |-----------Challenge------------>| - PPP Authentication 873 |<----------Response--------------| | (Optional - CHAP) 874 |------------Success------------->| - 875 | | 876 |<-----Configuration-Request------| - 877 |------Configuration-Request----->| | PPP NCP 878 |--------Configuration-Ack------->| | (IPV6CP or IPCP) 879 |<-------Configuration-Ack--------| - 880 | | 881 |<------Router-Solicitation-------| - Neighbor Discovery 882 |-------Router-Advertisement----->| | (IPv6 only) 883 | | - 884 | | 885 | | Step3 886 | | DHCP (Optional) 887 |<-----------SOLICIT--------------| - 888 |-----------ADVERTISE------------>| | DHCPv6 889 |<---------- REQUEST--------------| | (IPv6 SW, Optional) 890 |-------------REPLY-------------->| - 891 | | or 892 |<---------DHCPDISCOVER-----------| - 893 |-----------DHCPOFFER------------>| | DHCPv4 894 |<---------DHCPREQUEST------------| | (IPv4 SW, Optional) 895 |------------DHCPACK------------->| - 897 Figure 10: Detailed Steps in the Establishment of a Softwire 899 The PPP NCP negotiations in step 2 use IPV6CP for IPv6 over IPv4 900 Softwires, and IPCP for IPv4 over IPv6 Softwires. The optional DHCP 901 negitiations in step 3 use DHCPv6 for IPv6 over IPv4 Softwires, and 902 DHCPv4 for IPv4 over IPv6 Softwires. Additionally, for IPv6 over 903 IPv4 Softwires, the DHCPv6 exchange for nonaddress configuration 904 (such as DNS) can use a two message exchange with Information-Request 905 and Reply messages (see Section 1.2 of [RFC3315] and [RFC3736]). 907 5.1. L2TPv2 Tunnel Setup 909 L2TPv2 [RFC2661] was originally designed to provide private network 910 access to end users connected to a public network. In the L2TPv2 911 incoming call model, the end user makes a connection to an L2TP 912 Access Concentrator (LAC). The LAC then initiates an L2TPv2 tunnel 913 to an L2TP Network Server (LNS). The LNS then transfers end user 914 traffic between the L2TPv2 tunnel and the private network. 916 In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI) 917 assumes the role of the LAC Client and the Softwire Concentrator (SC) 918 assumes the role of the LNS. 920 In the Softwire model, an L2TPv2 packet MUST be carried over UDP. 921 The underlying version of the IP protocol may be IPv4 or IPv6, 922 depending on the Softwire scenario. 924 In the following sections, the term "Tunnel" follows the definition 925 from Section 1.2 of [RFC2661], namely: "The Tunnel consists of a 926 Control Connection and zero or more L2TP Sessions". 928 5.1.1. Tunnel Establishment 930 Figure 11 describes the messages exchanged and Attribute Value Pairs 931 (AVPs) used to establish a tunnel between an SI (LAC) and an SC 932 (LNS). The messages and AVPs described here are only a subset of 933 those defined in [RFC2661]. This is because Softwires use only a 934 subset of the L2TPv2 functionality. The subset of L2TP Control 935 Connection Management AVPs that is applicable to Softwires is grouped 936 into Mandatory AVPs and Optional AVPs (see Figure 11). Note that in 937 the Softwire environment, the SI always initiates the tunnel. L2TPv2 938 AVPs SHOULD NOT be hidden. 940 SC SI 941 |<--------SCCRQ---------| 942 Mandatory AVPs: 943 Message Type 944 Protocol Version 945 Host Name 946 Framing Capabilities 947 Assigned Tunnel ID 948 Optional AVPs: 949 Receive Window Size 950 Challenge 951 Firmware Revision 952 Vendor Name 954 |---------SCCRP-------->| 955 Mandatory AVPs: 956 Message Type 957 Protocol Version 958 Framing Capabilities 959 Host Name 960 Assigned Tunnel ID 961 Optional AVPs: 962 Firmware Revision 963 Vendor Name 964 Receive Window Size 965 Challenge 966 Challenge Response 968 |<--------SCCCN---------| 969 Mandatory AVPs: 970 Message Type 971 Optional AVPs: 972 Challenge Response 974 Figure 11: Control Connection Establishment 976 In L2TPv2, generally, the tunnel between an LAC and LNS may carry the 977 data of multiple users. Each of these users is represented by an 978 L2TPv2 session within the tunnel. In the Softwire environment, the 979 tunnel carries the information of a single user. Consequently, there 980 is only one L2TPv2 session per tunnel. Figure 12 describes the 981 messages exchanged and the AVPs used to establish a session between 982 an SI (LAC) and an SC (LNS). The messages and AVPs described here 983 are only a subset of those defined in [RFC2661]. This is because 984 Softwires use only a subset of the L2TPv2 functionality. The subset 985 of L2TP Call Management AVPs that is applicable to Softwires is 986 grouped into Mandatory AVPs and Optional AVPs (see Figure 12). Note 987 that in the Softwire environment, the SI always initiates the 988 session. No outgoing or analog calls are permitted. L2TPv2 AVPs 989 SHOULD NOT be hidden. 991 SC SI 992 |<--------ICRQ---------| 993 Mandatory AVPs: 994 Message Type 995 Assigned Session ID 996 Call Serial Number 998 |---------ICRP-------->| 999 Mandatory AVPs: 1000 Message Type 1001 Assigned Session ID 1003 |<--------ICCN---------| 1004 Mandatory AVPs: 1005 Message Type 1006 (Tx) Connect Speed 1007 Framing Type 1009 Figure 12: Session Establishment 1011 5.1.1.1. AVPs Required for Softwires 1013 This section prescribes specific values for AVPs used in the Softwire 1014 context that are Mandatory. 1016 Host Name AVP 1018 This AVP is mandatory in SCCRQ and SCCRP messages. This AVP may 1019 be used to authenticate users, in which case it would contain a 1020 user identification. If this AVP is not used to authenticate 1021 users, it may be used for logging purposes. 1023 Framing Capabilities AVP 1025 Both the synchronous (S) and asynchronous (A) bits SHOULD be set 1026 to 1. This AVP SHOULD be ignored by the receiver. 1028 Framing Type AVP 1030 The synchronous bit SHOULD be set to 1 and the asynchronous bit to 1031 0. This AVP SHOULD be ignored by the receiver. 1033 (Tx) Connect Speed 1034 (Tx) Connect Speed is a mandatory AVP but is not meaningful in the 1035 Softwire context. Its value SHOULD be set to 0 and ignored by the 1036 receiver. 1038 Message Type AVP, Protocol Version AVP, Assigned Tunnel ID AVP, Call 1039 Serial Number AVP, and Assigned Session ID AVP 1041 As defined in [RFC2661]. 1043 5.1.1.2. AVPs Optional for Softwires 1045 This section prescribes specific values for AVPs used in the Softwire 1046 context that are Optional. 1048 Challenge AVP and Challenge Response AVP 1050 These AVPs are not required, but are necessary to implement tunnel 1051 authentication. Since tunnel authentication happens at the 1052 beginning of L2TPv2 tunnel creation, it can be helpful in 1053 preventing DoS attacks. See Section 5.1.1 of [RFC2661]. 1055 The usage of these AVPs in L2TP messages is OPTIONAL, but SHOULD 1056 be implemented in the SC. 1058 Receive Window Size AVP, Firmware Revision AVP, and Vendor Name AVP 1060 As defined in [RFC2661]. 1062 5.1.1.3. AVPs not Relevant for Softwires 1064 L2TPv2 specifies numerous AVPs that, while allowed for a given 1065 message, are irrelevant to Softwires. Softwire implementations 1066 SHOULD NOT send these AVPs. However, they SHOULD ignore them when 1067 they are received. This will simplify the creation of Softwire 1068 applications that build upon existing L2TPv2 implementations. 1070 5.1.2. Tunnel Maintenance 1072 Periodically, the SI/SC MUST transmit a message to the peer to detect 1073 tunnel or peer failure and maintain NAT/NAPT contexts. The L2TPv2 1074 HELLO message provides a simple, low overhead method of doing this. 1076 The default values specified in [RFC2661] for L2TPv2 HELLO messages 1077 could result in a dead end detection time of 83 seconds. Although 1078 these retransmission timers and counters SHOULD be configurable (see 1079 Section 5.8 of [RFC2661]), these values may not be adapted for all 1080 situations, where a quicker dead end detection is required, or where 1081 NAT/NAPT context needs to be refreshed more frequently. In such 1082 cases, the SI/SC MAY use, in combination with L2TPv2 HELLO, LCP ECHO 1083 messages (Echo-Request and Echo-Reply codes) described in [RFC1661]. 1084 When used, LCP ECHO messages SHOULD have a re-emission timer lower 1085 than the value for L2TPv2 HELLO hello messages. The default value 1086 recommended in Section 6.5 of [RFC2661] for the HELLO message 1087 retransmission interval is 60 seconds. When used, a set of suggested 1088 values (included here only for guidance) for the LCP ECHO message 1089 request interval is a default of 30 seconds, a minimum of 10 seconds, 1090 and a maximum of the lesser of the configured L2TPv2 HELLO 1091 retransmisison interval and 60 seconds. 1093 5.1.3. Tunnel Teardown 1095 Either the SI or SC can teardown the session and tunnel. This is 1096 done as specified in Section 5.7 of [RFC2661], by sending a StopCCN 1097 control message. There is no action specific to Softwires in this 1098 case. 1100 5.2. PPP Connection 1102 This section describes the PPP negotiations between the SI and SC in 1103 the Softwire context. 1105 5.2.1. MTU 1107 The MTU of the PPP link presented to the SPH SHOULD be the link MTU 1108 minus the size of the IP, UDP, L2TPv2, and PPP headers together. On 1109 an IPv4 link with an MTU equal to 1500 bytes, this could tipically 1110 mean a PPP MTU of 1460 bytes. When the link is managed by IPsec, 1111 this MTU should be lowered to take into account the ESP encapsulation 1112 (see [I-D.ietf-softwire-security-requirements]). The value for the 1113 MTU may also vary according to the size of the L2TP header, as 1114 defined by the leading bits of the L2TP message header (see 1115 [RFC2661]). Additionally, see [RFC4623] for a detailed discussion of 1116 fragmentation issues. 1118 5.2.2. LCP 1120 Once the L2TPv2 session is established, the SI and SC initiate the 1121 PPP connection by negotiating LCP as described in [RFC1661]. The 1122 Address-and-Control-Field-Compression configuration option (ACFC) 1123 [RFC1661] MAY be rejected. 1125 5.2.3. Authentication 1127 After completing LCP negotiation, the SI and SC may optionally 1128 perform authentication. If authentication is chosen, CHAP [RFC1994] 1129 authentication MUST be supported by both the Softwire Initiator and 1130 Softwire Concentrator. Other authentication methods such as MS- 1131 CHAPv1 [RFC2433], and EAP [RFC3748] MAY be supported. 1133 A detailed discussion of Softwire security is contained in 1134 [I-D.ietf-softwire-security-requirements]. 1136 5.2.4. IPCP 1138 The only Network Control Protocol (NCP) negotiated in the Softwire 1139 context is IPV6CP (see Section 5.2.4.1) for IPv6 as SPH, and IPCP 1140 (see Section 5.2.4.2) for IPv4 as SPH. 1142 5.2.4.1. IPV6CP 1144 In the IPv6 over IPv4 scenarios (see Section 3.1), after the optional 1145 authentication phase, the Softwire Initiator MUST negotiate IPV6CP as 1146 defined in [RFC5072]. IPV6CP provides a way to negotiate a unique 1147 64-bit Interface-Identifier to be used for the address 1148 autoconfiguration at the local end of the link. 1150 5.2.4.2. IPv4CP 1152 In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire 1153 Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain 1154 an IPv4 address from the SC. IPCP may also be used to obtain DNS 1155 information as described in [RFC1877]. 1157 5.3. Global IPv6 Address Assignement to Endpoints 1159 In several scenarios defined in Section 3.1, Global IPv6 addresses 1160 are expected to be allocated to Softwire endpoints (in addition to 1161 the Link-Local addresses autoconfigured using the IPV6CP negotiated 1162 interface identifier). The Softwire Initiator assigns global IPv6 1163 addresses using the IPV6CP negotiated interface identifier and using 1164 Stateless Address Autoconfiguration [RFC4862], and/or using Privacy 1165 Extensions for Stateless Address Autoconfiguration [RFC4941], (as 1166 described in Section 5 of [RFC5072]), and/or using DHCPv6 [RFC3315]. 1168 The Softwire Initiator of an IPv6 Softwire MUST send a Router 1169 Solicitation message to the Softwire Concentrator after IPV6CP is 1170 completed. The Softwire Concentrator MUST answer with a Router 1171 Advertisement. This message MUST contains the global IPv6 prefix of 1172 the PPP link if Neighbor Discovery is used to configure addresses of 1173 Softwire endpoints. 1175 If DHCPv6 is available for address delegation, the M bits of the 1176 Router Advertisement SHOULD be set. The Softwire Initiator MUST then 1177 send a DHCPv6 Request to configure the address of the Softwire 1178 endpoint. 1180 Duplicate Address Detection ([RFC4861]) MUST be performed on the 1181 Softwire in both cases. 1183 5.4. DHCP 1185 The Softwire Initiator MAY use DHCP to get additional information 1186 such as delegated prefix and DNS servers. 1188 5.4.1. DHCPv6 1190 In the scenarions in Section 3.1, if the SI supports DHCPv6, it 1191 SHOULD send a Solicit message to verify if more information is 1192 available. 1194 If an SI establishing an IPv6 Softwire acts as a router (i.e., in the 1195 scenarios in Section 3.1.2 and Section 3.1.4) it MUST include the 1196 IA_PD option [RFC3633] in the DHCPv6 Solicit message [RFC3315] in 1197 order to request an IPv6 prefix. 1199 When delegating an IPv6 prefix to the SI by returning a DHCPv6 1200 Advertise message with the IA_PD and IP_PD Prefix options [RFC3633], 1201 the SC SHOULD inject a route for this prefix in the IPv6 routing 1202 table in order to forward the traffic to the relevant Softwire. 1204 Configuration of DNS MUST be done as specified in [RFC3646] and 1205 transmitted according to [RFC3315] and [RFC3736]. In general, all 1206 DHCPv6 options MUST be transmitted according to [RFC3315] and 1207 [RFC3736]. 1209 5.4.2. DHCPv4 1211 An SI establishing an IPv4 Softwire MAY send a DHCP request 1212 containing the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc]. 1213 This practice is not common but may be used to connect IPv4 subnets 1214 using Softwires, as defined in Section 3.2.2 and Section 3.2.4. 1216 One Subnet-Request suboption MUST be configured with the 'h' bit set 1217 to '1', as the SI is expected to perform the DHCP server function. 1218 The 'i' bit of the Subnet-Request suboption SHOULD be set to '0' the 1219 first time a prefix is requested and to '1' on subsequent requests, 1220 if a prefix has been allocated. The Prefix length suboption SHOULD 1221 be 0 by default. If the SI is configured to support only specific 1222 prefix lengths, it SHOULD specify the longest (smallest) prefix 1223 length it supports. 1225 If the SI was previously assigned a prefix from that same SC, it 1226 SHOULD include the Subnet-Information suboption with the prefix it 1227 was previously assigned. The 'c' and 's' bits of the suboption 1228 SHOULD be set to '0'. 1230 In the scenarions in Section 3.2, when delegating an IPv4 prefix to 1231 the SI, the SC SHOULD inject a route for this prefix in the IPv4 1232 routing table in order to forward the traffic to the relevant 1233 Softwire. 1235 6. Considerations about the Address Provisioning Model 1237 This section describes how a Softwire Concentrator may manage 1238 delegated addresses for Softwire endpoints and for subnets behind the 1239 Softwire Initiator. One common practice is to aggregate endpoints' 1240 addresses and delegated prefixes into one prefix routed to the SC. 1241 The main benefit is to ease the routing scheme by isolating on the SC 1242 succeeding route injections (when delegating new prefixes for SI). 1244 6.1. Softwire Endpoints' Addresses 1246 6.1.1. IPv6 1248 A Softwire Concentrator should provide globally routable addresses to 1249 Softwire endpoints. Other types of addresses such as Unique Local 1250 Addresses [RFC4193] may be used to address Softwire endpoints in a 1251 private network with no global connectivity. A single /64 should be 1252 assigned to the Softwire to address both Softwire endpoints. 1254 Global or ULA addresses must be assigned to endpoints when the 1255 scenario "Host CPE as Softwire Initiator" (described in 1256 Section 3.1.1) is considered to be deployed. For other scenarios, 1257 this may be optional and link local addresses should be used. 1259 6.1.2. IPv4 1261 A Softwire Concentrator may provide either globally routable or 1262 private IPv4 addresses. When using IPv4 private addresses [RFC1918] 1263 on the endpoints, it is not recommended to delegate an IPv4 private 1264 prefix to the SI, as it can lead to a nested-NAT situations. 1266 The endpoints of the PPP link use host addresses (i.e., /32), 1267 negotiated using IPCP. 1269 6.2. Delegated Prefixes 1270 6.2.1. IPv6 Prefixes 1272 Delegated IPv6 prefixes should be of global scope if the IPv6 1273 addresses assigned to endpoints are global. Using ULA addresses is 1274 not recommended when the subnet is connected to the global IPv6 1275 Internet. When using ULA IPv6 address for endpoint, the delegated 1276 IPv6 prefix may be either of Global or ULA scope. 1278 Delegated IPv6 prefixes are between /48 and /64 in length. When an 1279 SI receives a prefix shorter than 64, it can assign different /64 1280 prefixes to each of its interfaces. An SI receiving a single /64 is 1281 expected to perform bridging if more than one interface are available 1282 (e.g., wired and wireless). 1284 6.2.2. IPv4 Prefixes 1286 Delegated IPv4 prefixes should be routable within the address space 1287 used by assigned IPv4 addresses. Delegate non-routable IPv4 prefixes 1288 (i.e., private IPv4 prefix over public IPv4 addresses or another 1289 class of private IPv4 addresses) is not recommended as a practice for 1290 provisioning and address translation should be considered in these 1291 cases. The prefix length is between /8 and /30. 1293 6.3. Possible Address Provisioning Scenarios 1295 This section summarizes the differents scenarios for address 1296 provisioning with the considerations given in the previous sections. 1298 6.3.1. Scenarios for IPv6 1300 This table describes the possible combination of IPv6 address scope 1301 for endpoints and delegated prefixes. 1303 +------------------+-----------------------+------------------------+ 1304 | Endpoint IPv6 | Delegated Global IPv6 | Delegated ULA IPv6 | 1305 | Address | Prefix | Prefix | 1306 +------------------+-----------------------+------------------------+ 1307 | Link Local | Possible | Possible | 1308 | | | | 1309 | ULA | Possible | Possible | 1310 | | | | 1311 | Global | Possible | Possible, but Not | 1312 | | | Recommended | 1313 +------------------+-----------------------+------------------------+ 1315 Table 1: Scenarios for IPv6 1317 6.3.2. Scenarios for IPv4 1319 This table describes the possible combination of IPv4 address scope 1320 for endpoints and delegated prefixes. 1322 +-------------+-----------------+-----------------------------------+ 1323 | Endpoint | Delegated | Delegated Private IPv4 Prefix | 1324 | IPv4 | Public IPv4 | | 1325 | Address | Prefix | | 1326 +-------------+-----------------+-----------------------------------+ 1327 | Private | Possible | Possible, but Not Recommended | 1328 | IPv4 | | when using NAT (cf. | 1329 | | | Section 6.1.2) | 1330 | | | | 1331 | Public IPv4 | Possible | Possible, but NAT usage is | 1332 | | | recommended (cf. Section 6.2.2) | 1333 +-------------+-----------------+-----------------------------------+ 1335 Table 2: Scenarios for IPv4 1337 7. Considerations about Address Stability 1339 A Softwire can provide stable addresses even if the underlying 1340 addressing scheme changes, by opposition to automatic tunneling. A 1341 Softwire Concentrator should always provide the same address and 1342 prefix to a reconnecting user. However, if the goal of the Softwire 1343 service is to provide a temporary address for a roaming user, it may 1344 be provisioned to provide only a temporary address. 1346 The address and prefix are expected to change when reconnecting to a 1347 different Softwire Concentrator. However an organization providing a 1348 Softwire service may provide the same address and prefix across 1349 different Softwire Concentrators at the cost of a more fragmented 1350 routing table. The routing fragmentation issue may be limited if the 1351 prefixes are aggregated in a location topologically close to the SC. 1352 This would be the case for example if several SCs are put in parallel 1353 for load-balancing purpose. 1355 8. Considerations about RADIUS Integration 1357 The Softwire Concentrator is expected to act as a client to a AAA 1358 server, for example a RADIUS server. During the PPP authentication 1359 phase, the RADIUS server may return additional informations in the 1360 form of attributes in the Access-Accept message. 1362 The Softwire Concentrator may include the Tunnel-Type and Tunnel- 1363 Medium-Type attributes [RFC2868] in the Access-Request messages to 1364 provide a hint of the type of Softwire being configured. 1366 8.1. Softwire Endpoints 1368 8.1.1. IPv6 Softwires 1370 If the RADIUS server includes a Framed-Interface-Id attribute 1371 [RFC3162], the Softwire Concentrator must send it to the Softwire 1372 Initiator in the Interface-Identifier field of its IPV6CP 1373 Configuration Request message. 1375 If the Framed-IPv6-Prefix attribute [RFC3162] is included, that 1376 prefix must be used in the router advertisements sent to the SI. If 1377 Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC 1378 must choose a prefix with that pool to send RAs. 1380 If none of the attributes above are included but the AAA server 1381 returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint 1382 attributes [RFC2868] with the correct address family, these must be 1383 used in the IPV6CP Interface-Identifier and for the Router 1384 Advertisements. 1386 8.1.2. IPv4 Softwires 1388 If the Framed-IP-Address attribute [RFC2865] is present, the Softwire 1389 Concentrator must provide that address to the Softwire Initiator 1390 during IPCP address negotiation. That is, when the Softwire 1391 Initiator requests an IP address from the Softwire Concentrator, the 1392 address provided should be the Framed-IP-Address. 1394 If the Framed-IP-Address attribute is not present and the Tunnel- 1395 Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are 1396 present and of the correct address family, these should be used in 1397 the IPCP IP-Address configuration option. 1399 8.2. Delegated Prefixes 1401 8.2.1. IPv6 Prefixes 1403 If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the 1404 RADIUS Access-Accept message, it must be used by the Softwire 1405 Concentrator for the delegation of the IPv6 prefix. Since the prefix 1406 delegation is performed by DHCPv6 and the attribute is linked to a 1407 username, the SC must associate the DHCP Unique Identifier (DUID) of 1408 a DHCPv6 request to the tunnel it came from and its user. 1410 Interaction between RADIUS, PPP and DHCPv6 server may follow the 1411 mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. In this case, 1412 during the Softwire authentication phase, PPP collects the RADIUS 1413 attributes for the user such as Delegated-IPv6-Prefix. A specific 1414 DHCPv6 relay is assigned to the Softwire. The DHCPv6 relay fills in 1415 these attributes in the Relay agent RADIUS Attribute Option (RRAO) 1416 DHCPv6 option, before forwarding the DHCPv6 requests to the DHCPv6 1417 server. 1419 8.2.2. IPv4 Prefixes 1421 The combination of the Framed-IP-Address and Framed-IP-Netmask 1422 attributes [RFC2865] may be used by the Softwire Concentrator to 1423 delegate an IPv4 prefix to the Softwire Initiator. 1425 9. Considerations for Maintenance and Statistics 1427 9.1. RADIUS Accounting 1429 RADIUS Accounting for L2TP and PPP are documented (see Section 4.3). 1431 When deploying Softwire solutions, operators may experience 1432 difficulties to differentiate the address family of the traffic 1433 reported in accounting information from RADIUS. This problem and 1434 some potential solutions are described in 1435 [I-D.stevant-softwire-accounting]. 1437 9.2. MIBs 1439 MIB support for L2TPv2 and PPP are documented (see Section 4.4). 1440 Also see [RFC4293]. 1442 10. Security Considerations 1444 A detailed discussion of Softwire security is contained in 1445 [I-D.ietf-softwire-security-requirements]. 1447 The L2TPv2 Softwire solution provides the following tools for 1448 security: 1450 o IPsec [RFC4301] with IKEv2 [RFC4306] provides the highest level of 1451 security. [RFC3193] describes interaction between IPsec and 1452 L2TPv2. 1454 o PPP CHAP [RFC1994] provides basic user authentication. 1456 o L2TP Tunnel Authentication [RFC2661] provides authentication at 1457 tunnel setup. It may be used to limit DoS attacks by 1458 authenticating the tunnel before L2TP session and PPP resources 1459 are allocated. 1461 11. IANA Considerations 1463 [RFC Editor: please remove this section prior to publication.] 1465 This document creates no new requirements on IANA namespaces. 1467 12. Acknowledgements 1469 The authors would like to acknowledge the following contributors who 1470 provided helpful input on this document: Florent Parent, Jordi Palet 1471 Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, 1472 Francis Dupont and Ralph Droms. 1474 The authors would also like to acknowledge the participants in the 1475 Softwires interim meetings held in Hong Kong, China and Barcelona, 1476 Spain. The minutes for the interim meeting at the China University - 1477 Hong Kong (February 23-24, 2006) are at 1478 . The 1479 minutes for the interim meeting at Polytechnic University of 1480 Catalonia - Barcelona (September 14-15, 2006) are reachable at . 1483 13. References 1485 13.1. Normative References 1487 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 1488 (IPCP)", RFC 1332, May 1992. 1490 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1491 RFC 1661, July 1994. 1493 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1494 E. Lear, "Address Allocation for Private Internets", 1495 BCP 5, RFC 1918, February 1996. 1497 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1498 Protocol (CHAP)", RFC 1994, August 1996. 1500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1501 Requirement Levels", BCP 14, RFC 2119, March 1997. 1503 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1504 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1505 RFC 2661, August 1999. 1507 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1508 "Remote Authentication Dial In User Service (RADIUS)", 1509 RFC 2865, June 2000. 1511 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1512 RFC 3162, August 2001. 1514 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 1515 "Securing L2TP using IPsec", RFC 3193, November 2001. 1517 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1518 and M. Carney, "Dynamic Host Configuration Protocol for 1519 IPv6 (DHCPv6)", RFC 3315, July 2003. 1521 [RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two 1522 Tunneling Protocol "L2TP" Management Information Base", 1523 RFC 3371, August 2002. 1525 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1526 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1527 December 2003. 1529 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1530 (DHCP) Service for IPv6", RFC 3736, April 2004. 1532 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1533 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1534 RFC 3948, January 2005. 1536 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1537 Internet Protocol", RFC 4301, December 2005. 1539 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1540 RFC 4306, December 2005. 1542 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1543 Attribute", RFC 4818, April 2007. 1545 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1546 Address Autoconfiguration", RFC 4862, September 2007. 1548 [RFC5072] S.Varada, Haskin, D., and E. Allen, "IP Version 6 over 1549 PPP", RFC 5072, September 2007. 1551 13.2. Informative References 1553 [I-D.ietf-dhc-subnet-alloc] 1554 Johnson, R., "Subnet Allocation Option", 1555 draft-ietf-dhc-subnet-alloc-07 (work in progress), 1556 July 2008. 1558 [I-D.ietf-dhc-v6-relay-radius] 1559 Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option", 1560 draft-ietf-dhc-v6-relay-radius-02 (work in progress), 1561 February 2006. 1563 [I-D.ietf-softwire-security-requirements] 1564 Yamamoto, S., Williams, C., Parent, F., and H. Yokota, 1565 "Softwire Security Analysis and Requirements", 1566 draft-ietf-softwire-security-requirements-06 (work in 1567 progress), February 2008. 1569 [I-D.stevant-softwire-accounting] 1570 Stevant, B., "Accounting on Softwires", 1571 draft-stevant-softwire-accounting-01 (work in progress), 1572 October 2006. 1574 [RFC1471] Kastenholz, F., "The Definitions of Managed Objects for 1575 the Link Control Protocol of the Point-to-Point Protocol", 1576 RFC 1471, June 1993. 1578 [RFC1473] Kastenholz, F., "The Definitions of Managed Objects for 1579 the IP Network Control Protocol of the Point-to-Point 1580 Protocol", RFC 1473, June 1993. 1582 [RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control 1583 Protocol Extensions for Name Server Addresses", RFC 1877, 1584 December 1995. 1586 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1587 RFC 2131, March 1997. 1589 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1590 Extensions", RFC 2132, March 1997. 1592 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 1593 RFC 2433, October 1998. 1595 [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting 1596 Modifications for Tunnel Protocol Support", RFC 2867, 1597 June 2000. 1599 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, 1600 M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1601 Support", RFC 2868, June 2000. 1603 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1604 Address Translator (Traditional NAT)", RFC 3022, 1605 January 2001. 1607 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1608 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1609 December 2003. 1611 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1612 Levkowetz, "Extensible Authentication Protocol (EAP)", 1613 RFC 3748, June 2004. 1615 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 1616 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1618 [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005. 1620 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1621 Addresses", RFC 4193, October 2005. 1623 [RFC4293] Routhier, S., "Management Information Base for the 1624 Internet Protocol (IP)", RFC 4293, April 2006. 1626 [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- 1627 Edge (PWE3) Fragmentation and Reassembly", RFC 4623, 1628 August 2006. 1630 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1631 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1632 September 2007. 1634 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 1635 Problem Statement", RFC 4925, July 2007. 1637 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1638 Extensions for Stateless Address Autoconfiguration in 1639 IPv6", RFC 4941, September 2007. 1641 Appendix A. Revision History 1643 [Note to RFC Editor: please remove this entire appendix, and the 1644 corresponding entries in the table of contents, prior to 1645 publication.] 1647 Changes between -08 and -09: 1649 o Refresh version about to expire, no other changes. 1651 Changes between -07 and -08: 1653 o Corrected the usage of Softwire vs. Softwires throughout the 1654 document, esp. when used as an adjective. 1656 o Editorial: Re-arranged "Contributing Authors" (Section 1.3). 1658 o Miscellaneous editorial corrections, readability improvements, 1659 completed the Abbreviations Section 1.1. 1661 o Added Section 2.3 about "Routing". 1663 o In all the Deployment Scenarios (Section 3), clarified that the 1664 description is after successful LCP negotiation and optional PPP 1665 Authentication. Corrected "DHCPv6" in Figure 1 and Figure 3. 1667 o Removed /48 example from Section 3.1.2 and Section 3.1.4. 1669 o Added reference and corresponding citations to [RFC2132] in 1670 Section 3.2. 1672 o Completed the citations on Section 4.5, adding [RFC4862], 1673 [RFC3633], [RFC2131], and [RFC2132]. 1675 o Moved the last two sentences of Section 5.4 to Section 5.4.1 and 1676 Section 5.4.2 respectively. 1678 o Completed the first paragraph of Section 5.3, adding an 1679 informational reference to [RFC4941]. 1681 o Added DHCPv4 to Figure 10 for the IPv4 over IPv6 scenarios. Added 1682 a follow-on clarifying paragraph about PPP NCP and DHCP versions 1683 used in each softwire scenario. 1685 o Clarification of implementation versus usage of the optional AVPs 1686 in Section 5.1.1.2. 1688 o Added text including [RFC3736] for DHCPv6. 1690 Changes between -06 and -07: 1692 o Changed RFC numbers: RFC2461 and I-D 2461(bis) to [RFC4861], 1693 RFC2462 to [RFC4862], and RFC2472 and I-D.ietf-ipv6-over-ppp-v2 to 1694 [RFC5072]. 1696 Changes between -05 and -06: 1698 o Swapped Section 4.1 and Section 4.2. Renamed Section 4.2 to 1699 "Securing the Softwire Transport". 1701 o In Section 5.2.1, added a mention that the MTU should be lower 1702 that 1460 when using IPsec. 1704 o In Section 10, added pointers to [RFC4301] and [RFC4306]. 1706 Changes between -04 and -05: 1708 o Replaced "documentation" with "logging purposes" in 1709 Section 5.1.1.1. 1711 o Added suggested values (only as guidance) for Keepalives in 1712 Section 5.1.2. 1714 Changes between -03 and -04: 1716 o Added missing references to [RFC4087], [RFC4861], and [RFC3646], 1717 moved [RFC4623] to Informative. 1719 o Rephrasing in Section 6.2.2. Added pointers Section 6.1.2 and 1720 Section 6.2.2 in Table 2. 1722 o Added citations (and corresponding references) to [RFC1471] and 1723 [RFC1473] in Section 4.4, since Section 9.2 explicitly mentions: 1724 "MIB support for L2TPv2 and PPP are documented." 1726 o Fixed some RFC2119 keywords in Section 3.1.1, Section 3.1.2, 1727 Section 3.1.3, Section 3.1.4, Section 3.2.1, Section 3.2.2, 1728 Section 3.2.3, Section 3.2.4, Section 5.1.1.3, Section 5.4.2, and 1729 Section 8.1.1. 1731 o Added [RFC2868] to Section 4.3, and added missing citations to 1732 Section 4. 1734 o Added missing "Optional AVP" to Figure 11. 1736 o Updated the text in Section 6.2.2. 1738 o Added some clarifying sentences in Section 5.1.1, and completed 1739 Section 5.1.1.1 and Section 5.1.1.2. 1741 o Added an Informative reference to [RFC3022] for NAT/NAPT. 1743 o Corrected reference to [RFC1661] in Section 5.2.2, removed 1744 reference and citation to RFC1662. 1746 o Updated references, Delegated-IPv6-Prefix became [RFC4818] moved 1747 to Normative. 1749 o Added new address and email for J.F. Tremblay. 1751 o Added an acknowledgement to the participants, and pointer to the 1752 minutes, for the Barcelona interim meeting. 1754 o Moved the Softwire Problem Statement reference [RFC4925] to 1755 Informative. 1757 o Some additional purely editorial changes. 1759 Changes between -02 and -03: 1761 o Boiler changes in support of RFC 4748. 1763 o Added text about L2TPv2 HELLO and LCP ECHO usage in Section 1, 1764 Section 2.7 and Section 5.1.2. 1766 o Moved some downref to Informative ([RFC1877], [RFC2433], 1767 [RFC2867], [RFC2868], and [RFC3748]), and moved CHAP reference to 1768 Normative ([RFC1994]). 1770 o Removed the mention and citation for PAP authentication. 1772 Changes between -01 and -02: 1774 o Renamed all "Best Current Practices" sections as 1775 "Recommendations". See for example Section 1.4. 1777 o Moved Provisioning in Section 6. Removed intro text to new 1778 Section 7. 1780 o Removed all normative language from Section 6, Section 7, 1781 Section 8, and Section 9. 1783 o Removed empty sections "Implementation Status", and "Open Issues". 1785 o Fixed "Phase 0" in Section 1. 1787 o Small changes to Section 3.1. 1789 o Change L2TP -> L2TPv2 in some sections, including Section 6. 1791 o Small additions and typo fixes in Section 5.1.1.1 and 1792 Section 5.1.1.2. 1794 o Retitled Section 8 and Section 8.1, changed AAA -> RADIUS. 1796 o New paragraph in Section 9.1. 1798 o New paragraph in Section 8.2.1, including a pointer to 1799 [I-D.ietf-dhc-v6-relay-radius]. 1801 o Moved last paragraph to start of Section 10. 1803 o Moved some references from Normative to Informative. 1805 o Label the steps in Figure 9 and Figure 10. 1807 o Reword paragraph of Section 5.1. 1809 o Describe more messages than flows in Figure 11 and Figure 12. 1811 o Add text about Session Establishment between Figure 11 and 1812 Figure 12. 1814 o Section 5.1.1.1 and Section 5.1.1.2: Updates on Hostname AVP, 1815 Framing Capabilities AVP, Framing Type AVP, Connect Speed AVP and 1816 Challenge and Challenge Response AVPs. 1818 o Retitled Section 5.1.1.3. 1820 o Updates on the use of L2TP HELLO versus LCP, delay for Dead-End 1821 peer detection, and allow LCP. 1823 o Rewording in Section 5.1.3. 1825 o Section 5.2.1: Add a pointer to [RFC4623] and small updates. 1827 o Clarifications on PFC and ACFC, remove Figure 13. 1829 o Section 5.2.3: make references to RFCs for PAP, CHAP, etc. 1831 o Rewordings in Section 5.2.4.1 and Section 5.2.4.2. 1833 o Added Informative references to [RFC4623], [RFC1661], [RFC2433], 1834 and [RFC3748]. 1836 o Renamed the title and added more details on Section 5.3 and IPv6 1837 ND, including a pointer to I-D.ietf-ipv6-2461bis. 1839 o Added text in Section 5.4 about IPv4 PD is non-trivial and non 1840 commonly done. 1842 o Added B. Stevant as Editor. 1844 o Clarification in Section 5.2.4.1 and Section 5.2.4.2 regarding the 1845 scope of the MUST (to the specific scenarios). 1847 o Removed considerations about reverse DNS from Section 6, agreed on 1848 Barcelona. 1850 o Clarified the NAT case in Section 6.1.2 1852 o Added first paragraph in Section 6.2.1 regarding delegated IPv6 1853 prefixes. 1855 o Added new Section 6.3, Section 6.3.1 and Section 6.3.2 summarizing 1856 the scenarios for address allocation. 1858 Changes between -00 and -01: 1860 o Changed alignment in all figures to be centered, and fixed 1861 Figure 9 reference. 1863 o Section 1.4: Added new section with "Best Current Practices" 1864 definition. 1866 o Marked the following sections as "Best Current Practices": 1867 Section 6, Section 8, and Section 9. 1869 o Section 6.1.1, last paragraph: Removed sentence on IPv6 link 1870 address on the PPP link. Mailing list comment from Florent 1871 Parent, 13-Jul-2006. 1873 o Section 6.1.2, last paragraph: Changed IPv4 PPP link address to 1874 use host addresses (/32) negotiated with IPCP instead of /30. 1875 Mailing list comment from Bill Storer, 5-Jul-2006. 1877 o Section 5, Figure 10: Correction, s/SCCSN/SCCCN/; added missing 1878 ICRP, and changed direction of ICCN; typo correction s/IPV6P/ 1879 IPV6CP/. Mailing list comment from Bill Storer, 5-Jul-2006. 1881 o Section 5, Figure 10: Marked CHAP as "Optional - CHAP". 1883 o Section 5.1, Section 5.1.1, and Section 5.1.3: Minor typographical 1884 error correction and rewording of some sentences for grammar. 1886 o Section 5.1.1.1, Host Name AVP: Removed "for debugging purposes" 1887 and added that MAY be used to authenticate users. 1889 o Section 5.1.1.1, Framing Capabilities AVP: Swapped SHOULD and 1890 MUST. Mailing list comment from Bill Storer, 5-Jul-2006, text 1891 from Laurent Toutain. 1893 o Section 5.1.1.1, (Tx) Connect Speed: Correction: "but is *not* 1894 meaningful". 1896 o Section 5.1.1.2, Challenge and Challenge Response AVPs: Removed 1897 the last sentence of the first paragraph. Mailing list comment 1898 from Bill Storer, 5-Jul-2006, text from Laurent Toutain. 1900 o Section 5.1.2: Rewrote paragraph to use L2TPv2 HELLO messages and 1901 not LCP Echo Request and Reply messages to detect tunnel failure, 1902 as redundant in Softwires. Mailing list comment from Florent 1903 Parent, 10-Jul-2006, text from Bill Storer. 1905 o Section 5.2.1, first paragraph: Fixed PPP MTU calculation. 1906 Mailing list comment from Florent Parent, 10-Jul-2006. 1908 o Section 5.2.4.2: Rewrote to generalize the address assignment 1909 failure, to be an all-zeroes address or a protocol reject in 1910 response to the IPCP CONFREQ. Mailing list comment from Bill 1911 Storer, 5-Jul-2006, text from JF Tremblay. 1913 o Section 8, second paragraph: s/Tunnel-Medium /Tunnel-Type /. 1914 Mailing list comment from Bill Storer, 5-Jul-2006. 1916 o Section 8.1.2: Added usage of Framed-IP-Address attribute, and if 1917 not present then use the Tunnel-Client-Endpoint and Tunnel-Server- 1918 Endpoint attributes. Mailing list comment from Bill Storer, 1919 5-Jul-2006, text from JF Tremblay and Bill Storer. 1921 o Completed Section 8.2.2, Section 9.1, Section 9.2, and Section 10. 1923 Revision -00: 1925 o Initial revision. 1927 Authors' Addresses 1929 Bill Storer 1930 Cisco Systems 1931 170 W Tasman Dr 1932 San Jose, CA 95134 1933 USA 1935 Email: bstorer@cisco.com 1937 Carlos Pignataro (editor) 1938 Cisco Systems 1939 7200 Kit Creek Road 1940 PO Box 14987 1941 Research Triangle Park, NC 27709 1942 USA 1944 Email: cpignata@cisco.com 1946 Maria Alice Dos Santos 1947 Cisco Systems 1948 170 W Tasman Dr 1949 San Jose, CA 95134 1950 USA 1952 Email: mariados@cisco.com 1954 Bruno Stevant (editor) 1955 TELECOM Bretagne 1956 2 rue de la Chataigneraie CS17607 1957 Cesson Sevigne, 35576 1958 France 1960 Email: bruno.stevant@telecom-bretagne.eu 1962 Jean-Francois Tremblay 1963 Trellia Networks 1964 100, Alexis-Nihon, Suite 770 1965 Montreal, QC H4M 2P3 1966 Canada 1968 Email: jf@jftremblay.com 1970 Full Copyright Statement 1972 Copyright (C) The IETF Trust (2008). 1974 This document is subject to the rights, licenses and restrictions 1975 contained in BCP 78, and except as set forth therein, the authors 1976 retain all their rights. 1978 This document and the information contained herein are provided on an 1979 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1980 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1981 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1982 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1983 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1984 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1986 Intellectual Property 1988 The IETF takes no position regarding the validity or scope of any 1989 Intellectual Property Rights or other rights that might be claimed to 1990 pertain to the implementation or use of the technology described in 1991 this document or the extent to which any license under such rights 1992 might or might not be available; nor does it represent that it has 1993 made any independent effort to identify any such rights. Information 1994 on the procedures with respect to rights in RFC documents can be 1995 found in BCP 78 and BCP 79. 1997 Copies of IPR disclosures made to the IETF Secretariat and any 1998 assurances of licenses to be made available, or the result of an 1999 attempt made to obtain a general license or permission for the use of 2000 such proprietary rights by implementers or users of this 2001 specification can be obtained from the IETF on-line IPR repository at 2002 http://www.ietf.org/ipr. 2004 The IETF invites any interested party to bring to its attention any 2005 copyrights, patents or patent applications, or other proprietary 2006 rights that may cover technology that may be required to implement 2007 this standard. Please address the information to the IETF at 2008 ietf-ipr@ietf.org.