idnits 2.17.1 draft-ietf-softwire-hs-framework-l2tpv2-08.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 1989. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2000. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2007. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2013. 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 (January 29, 2008) is 5932 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 527, but not defined == Missing Reference: 'IPv6-only' is mentioned on line 708, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** 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-06 == Outdated reference: A later version (-09) exists of draft-ietf-softwire-security-requirements-05 == 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: 6 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: August 1, 2008 Cisco Systems 6 B. Stevant, Ed. 7 TELECOM Bretagne 8 J. Tremblay 9 Trellia Networks 10 January 29, 2008 12 Softwire Hub & Spoke Deployment Framework with L2TPv2 13 draft-ietf-softwire-hs-framework-l2tpv2-08 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 August 1, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document describes the framework of the Softwire "Hub and Spoke" 47 solution with the Layer 2 Tunneling Protocol version 2 (L2TPv2). The 48 implementation details specified in this document should be followed 49 to achieve interoperability among different vendor implementations. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 55 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 56 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 6 57 1.4. Considerations . . . . . . . . . . . . . . . . . . . . . . 7 59 2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7 60 2.1. Traditional Network Address Translation (NAT and NAPT) . . 7 61 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.5. Authentication, Authorization and Accounting (AAA) . . . . 8 65 2.6. Privacy, Integrity, and Replay Protection . . . . . . . . 8 66 2.7. Operations and Management (OAM) . . . . . . . . . . . . . 8 67 2.8. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 9 69 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 9 70 3.1. IPv6 over IPv4 Softwires with L2TPv2 . . . . . . . . . . . 9 71 3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 9 72 3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 10 73 3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 12 74 3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 13 75 3.2. IPv4 over IPv6 Softwires with L2TPv2 . . . . . . . . . . . 14 76 3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 14 77 3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 15 78 3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 16 79 3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 16 81 4. Standardization Status . . . . . . . . . . . . . . . . . . . . 17 82 4.1. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 4.2. Securing the Softwire Transport . . . . . . . . . . . . . 18 84 4.3. Authentication Authorization Accounting . . . . . . . . . 18 85 4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 19 87 4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 19 88 4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 19 90 5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 19 91 5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 22 92 5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 22 93 5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 24 94 5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 25 95 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 25 97 5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 25 98 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 26 99 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 26 100 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 26 101 5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 26 103 5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 104 5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 27 105 5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 27 106 5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 27 107 5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 108 5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28 109 5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 28 111 6. Considerations about the Address Provisioning Model . . . . . 29 112 6.1. Softwire Endpoints' Addresses . . . . . . . . . . . . . . 29 113 6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 29 114 6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 29 115 6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 29 116 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30 117 6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 30 118 6.3. Possible Address Provisioning Scenarios . . . . . . . . . 30 119 6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 30 120 6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 31 122 7. Considerations about Address Stability . . . . . . . . . . . . 31 124 8. Considerations about RADIUS Integration . . . . . . . . . . . 31 125 8.1. Softwire Endpoints . . . . . . . . . . . . . . . . . . . . 32 126 8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 32 127 8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 32 128 8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 32 129 8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 32 130 8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 33 132 9. Considerations for Maintenance and Statistics . . . . . . . . 33 133 9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 33 134 9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 136 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 138 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 140 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 142 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 143 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 144 13.2. Informative References . . . . . . . . . . . . . . . . . . 36 146 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 38 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 149 Intellectual Property and Copyright Statements . . . . . . . . . . 45 151 1. Introduction 153 The Softwires Working Group has selected Layer Two Tunneling Protocol 154 version 2 (L2TPv2) as the phase 1 protocol to be deployed in the 155 Softwire "Hubs and Spokes" solution space. This document describes 156 the framework for the L2TPv2 "Hubs and Spokes" solution, and the 157 implementation details specified in this document should be followed 158 to achieve interoperability among different vendor implementations. 160 In the "Hubs and Spokes" solution space, a Softwire is established to 161 provide the home network with IPv4 connectivity across an IPv6-only 162 access network, or IPv6 connectivity across an IPv4-only access 163 network. When L2TPv2 is used in the Softwire context, the voluntary 164 tunneling model applies. The Softwire Initiator (SI) at the home 165 network takes the role of the L2TP Access Concentrator (LAC) client 166 (initiating both the L2TP tunnel/session and the PPP link) while the 167 Softwire Concentrator (SC) at the ISP takes the role of the L2TP 168 Network Server (LNS). Since L2TPv2 compulsory tunneling model does 169 not apply to Softwires, it should not be requested or honored. This 170 document identifies all the voluntary tunneling related L2TPv2 171 attributes that apply to Softwires and specifies the handling 172 mechanism for such attributes in order to avoid ambiguities in 173 implementations. This document also identifies the set of L2TPv2 174 attributes specific to compulsory tunneling model that do not apply 175 to Softwires and specifies the mechanism to ignore or nullify their 176 effect within the Softwire context. 178 The SI and SC must follow the L2TPv2 operations described in 179 [RFC2661] when performing Softwire establishment, tear-down and OAM. 180 With L2TPv2, a Softwire consists of an L2TPv2 Control Connection 181 (also referred to as Control Channel), a single L2TPv2 Session, and 182 the PPP link negotiated over the Session. To establish the Softwire, 183 the SI first initiates an L2TPv2 Control Channel to the SC which 184 accepts the request and terminates the Control Channel. L2TPv2 185 supports an optional mutual Control Channel authentication which 186 allows both SI and SC to validate each other's identity at the 187 initial phase of hand-shaking before proceeding with Control Channel 188 establishment. After the L2TPv2 Control Channel is established 189 between the SI and SC, the SI initiates an L2TPv2 Session to the SC. 190 Then the PPP/IP link is negotiated over the L2TPv2 Session between 191 the SI and SC. After the PPP/IP link is established, it acts as the 192 Softwire between the SI and SC for tunneling IP traffic of one 193 Address Family (AF) across the access network of another Address 194 Family. 196 During the life of the Softwire, both SI and SC send L2TPv2 keepalive 197 HELLO messages to monitor the health of the Softwire and the peer 198 LCCE, and to potentially refresh the NAT/NAPT translation entry at 199 the CPE or at the other end of the access link. Optionally, LCP ECHO 200 messages can be used as keepalives for the same purposes. In the 201 event of keepalive timeout or administrative shutdown of the 202 Softwire, either SI or SC may tear down the Softwire by tearing down 203 the L2TPv2 Control Channel and Session as specified in [RFC2661]. 205 1.1. Abbreviations 207 AF Address Family, IPv4 or IPv6. 209 SC Softwire Concentrator, the node terminating the Softwire in 210 the service provider network (See [RFC4925]). 212 SI Softwire Initiator, the node initiating the Softwire within 213 the customer network (See [RFC4925]). 215 LCCE L2TP Control Connection Endpoint, an L2TP node that exists at 216 either end of an L2TP Control Connection (See [RFC3931]). 218 SPH Softwire Payload Header, the IP headers being carried within a 219 softwire (See [RFC4925]). 221 STH Softwire Transport Header, the outermost IP header of a 222 softwire (See [RFC4925]). 224 SW Softwire, a shared-state "tunnel" created between the SC and 225 SI. (See [RFC4925]). 227 1.2. Requirements Language 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 231 document are to be interpreted as described in [RFC2119]. 233 1.3. Contributing Authors 235 Following is the complete list of contributors to this document. 237 Maria Alice Dos Santos, Cisco Systems 238 Carlos Pignataro, Cisco Systems 239 Bill Storer, Cisco Systems 240 Jean-Francois Tremblay, Trellia Networks 241 Laurent Toutain, GET/ENST Bretagne 242 Bruno Stevant, TELECOM Bretagne 244 1.4. Considerations 246 Some sections of this document contain considerations that are not 247 required for interoperability and correct operation of Softwire 248 implementations. These sections are marked as "Considerations". 250 2. Applicability of L2TPv2 for Softwire Requirements 252 A list of Softwire "Hubs and Spokes" requirements has been identified 253 by the Softwire Problem Statement [RFC4925]. The following sub- 254 sections describe how L2TPv2 fulfills each of them. 256 2.1. Traditional Network Address Translation (NAT and NAPT) 258 A "Hubs and Spokes" Softwire must be able to traverse Network Address 259 Translation (NAT) and Network Address Port Translation (NAPT, also 260 referred to as Port Address Translation or PAT) devices [RFC3022] in 261 case the scenario in question involves a non-upgradable pre-existing 262 IPv4 home gateway performing NAT/NAPT or some carrier equipment at 263 the other end of the access link performing NAT/NAPT. The L2TPv2 264 Softwire (i.e., Control Channel and Session) is capable of NAT/NAPT 265 traversal since L2TPv2 can run over UDP. 267 Since L2TPv2 does not detect NAT/NAPT along the path, L2TPv2 does not 268 offer the option of disabling UDP. The UDP encapsulation is present 269 regardless of NAT/NAPT presence. Both NAT/NAPT "autodetect" and UDP 270 "bypass" are optional requirements in Section 2.3 of [RFC4925]. 272 2.2. Scalability 274 In the "Hubs and Spokes" model, a carrier must be able to scale the 275 solution to millions of Softwire Initiators by adding more hubs 276 (i.e., Softwire Concentrators). L2TPv2 is a widely deployed protocol 277 in broadband services, and its scalability has been proven in 278 multiple large-scale IPv4 Virtual Private Network deployments which 279 scale up to millions of subscribers each. 281 2.3. Routing 283 There are no dynamic routing protocols between the SC and SI. A 284 default route from the SI to the SC is used. 286 2.4. Multicast 288 Multicast protocols simply run over L2TPv2 Softwires transparently 289 together with other regular IP traffic. 291 2.5. Authentication, Authorization and Accounting (AAA) 293 L2TPv2 supports optional mutual Control Channel authentication and 294 leverages the optional mutual PPP per-session authentication. L2TPv2 295 is well integrated with AAA solutions (such as RADIUS) for both 296 authentication and authorization. Most L2TPv2 implementations 297 available in the market support logging of authentication and 298 authorization events. 300 L2TPv2 integration with RADIUS accounting (RADIUS Accounting 301 extension for tunnel [RFC2867]) allows the collection and reporting 302 of L2TPv2 Softwire usage statistics. 304 2.6. Privacy, Integrity, and Replay Protection 306 Since L2TPv2 runs over IP/UDP in the Softwire context, IPsec ESP can 307 be used in conjunction to provide per-packet authentication, 308 integrity, replay protection and confidentiality for both L2TPv2 309 control and data traffic [RFC3193] and [RFC3948]. 311 For Softwire deployments in which full payload security is not 312 required, the L2TPv2 built-in Control Channel authentication and the 313 inherited PPP authentication and PPP Encryption Control Protocol can 314 be considered. 316 2.7. Operations and Management (OAM) 318 L2TPv2 supports an optional in-band keepalive mechanism which injects 319 HELLO control messages after a specified period of time has elapsed 320 since the last data or control message was received on a tunnel (see 321 Section 5.5 of [RFC2661]). If the HELLO control message is not 322 reliably delivered, then the Control Channel and its Session will be 323 torn down. In the Softwire context, the L2TPv2 keepalive is used to 324 monitor the connectivity status between the SI and SC and/or as a 325 refresh mechanism for any NAT/NAPT translation entry along the access 326 link. 328 LCP ECHO offers a similar mechanism to monitor the connectivity 329 status, as described in [RFC1661]. Softwire implementations SHOULD 330 use L2TPv2 Hello keepalives and in addition MAY use PPP LCP Echo 331 messages to ensure Dead End Detection and/or to refresh NAT/NAPT 332 translation entries. The combination of these two mechanisms can be 333 used as an optimization. 335 L2TPv2 MIB [RFC3371] supports the complete suite of management 336 operations such as configuration of Control Channel and Session, 337 polling of Control Channel and Session status and their traffic 338 statistics and notifications of Control Channel and Session UP/DOWN 339 events. 341 2.8. Encapsulations 343 L2TPv2 supports the following encapsulations: 345 o IPv6/PPP/L2TPv2/UDP/IPv4 347 o IPv4/PPP/L2TPv2/UDP/IPv6 349 o IPv4/PPP/L2TPv2/UDP/IPv4 351 o IPv6/PPP/L2TPv2/UDP/IPv6 353 Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not 354 support "autodetect" of NAT/NAPT. 356 3. Deployment Scenarios 358 For the "Hubs and Spokes" problem space, four scenarios have been 359 identified. In each of these four scenarios, different home 360 equipment plays the role of the Softwire Initiator. This section 361 elaborates each scenario with L2TPv2 as the Softwire protocol and 362 other possible protocols involved to complete the solution. This 363 section examines the four scenarios for both IPv6 over IPv4 364 (Section 3.1) and IPv4 over IPv6 (Section 3.2) encapsulations. 366 3.1. IPv6 over IPv4 Softwires with L2TPv2 368 The following subsections cover IPv6 connectivity (SPH) across an 369 IPv4-only access network (STH) using a Softwire. 371 3.1.1. Host CPE as Softwire Initiator 373 The Softwire Initiator (SI) is the host CPE (directly connected to a 374 modem), which is dual-stack. There is no other gateway device. The 375 IPv4 traffic SHOULD NOT traverse the softwire. See Figure 1. 377 IPv6 or dual-stack IPv4-only dual-stack 378 |------------------||-----------------||----------| 380 I SC SI 381 N +-----+ +----------+ 382 T | | | v4/v6 | 383 E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| host CPE | 384 R [network] | | [ network ] | | 385 N | LNS | |LAC Client| 386 E +-----+ +----------+ 387 T _ _ _ _ _ _ _ _ _ 388 ()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic 389 PPP o L2TPv2 o UDP o IPv4 (SPH) 390 Softwire 392 <------------------> 393 IPV6CP: capable of /64 Intf-Id assignment or 394 uniqueness check 396 |------------------>/64 prefix 397 RA 398 |------------------>DNS, etc. 399 DHCPv6 401 Figure 1: Host CPE as Softwire Initiator 403 In this scenario, after the L2TPv2 Control Channel and Session 404 establishment and PPP LCP negotiation (and optionally PPP 405 Authentication) are successful, IPV6CP negotiates IPv6 over PPP which 406 also provides the capability for the ISP to assign the 64-bit 407 Interface-Identifier to the host CPE or perform uniqueness validation 408 for the two interface identifiers at the two PPP ends [RFC5072]. 409 After IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration / 410 Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can 411 inform the host CPE of a prefix to use for stateless address 412 autoconfiguration through a Router Advertisement (RA) while other 413 nonaddress configuration options (such as DNS [RFC3646] or other 414 servers' addresses that might be available) can be conveyed to the 415 host CPE via DHCPv6. 417 3.1.2. Router CPE as Softwire Initiator 419 The Softwire Initiator (SI) is the router CPE, which is a dual-stack 420 device. The IPv4 traffic SHOULD NOT traverse the Softwire. See 421 Figure 2. 423 IPv6 or dual-stack IPv4-only dual-stack 424 |------------------||-----------------||---------------------| 426 I SC SI 427 N +-----+ +----------+ 428 T | | | v4/v6 | +-----+ 429 E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| CPE |----|v4/v6| 430 R [network] | | [ network ] | | | host| 431 N | LNS | |LAC Client| +-----+ 432 E +-----+ +----------+ 433 T _ _ _ _ _ _ _ _ _ 434 ()_ _ _ _ _ _ _ _ _() <-------- IPv6 traffic 435 PPP o L2TPv2 o UDP o IPv4 (SPH) 436 Softwire 438 <------------------> 439 IPV6CP: capable of /64 Intf-Id assignment or 440 uniqueness check 442 |------------------>/64 prefix 443 RA 444 |------------------>/48 prefix, 445 DHCPv6 DNS, etc. 447 |------->/64 prefix 448 RA 449 |-------> DNS, etc. 450 DHCPv4/v6 452 Figure 2: Router CPE as Softwire Initiator 454 In this scenario, after the L2TPv2 Control Channel and Session 455 establishment and PPP LCP negotiation (and optionally PPP 456 Authentication) are successful, IPV6CP negotiates IPv6 over PPP which 457 also provides the capability for the ISP to assign the 64-bit 458 Interface-Identifier to the router CPE or perform uniqueness 459 validation for the two interface identifiers at the two PPP ends 460 [RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address 461 Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP 462 link, and the LNS can inform the router CPE of a prefix to use for 463 stateless address autoconfiguration through a Router Advertisement 464 (RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g., 465 delegating a prefix to be used within the home network [RFC3633]) and 466 convey other nonaddress configuration options (such as DNS [RFC3646]) 467 to the router CPE. 469 3.1.3. Host behind CPE as Softwire Initiator 471 The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack 472 host (behind the IPv4-only CPE), which acts as an IPv6 host CPE. The 473 IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 3. 475 IPv6 or dual-stack IPv4-only dual-stack 476 |------------------||----------------------------||----------| 478 I SC SI 479 N +-----+ +----------+ 480 T | | +-------+ | v4/v6 | 481 E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....|v4-only|--| host | 482 R [network] | | [ network ] | CPE | | | 483 N | LNS | +-------+ |LAC Client| 484 E +-----+ +----------+ 485 T _ _ _ _ _ _ _ _ _ _ _ _ _ _ 486 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6 487 PPP o L2TPv2 o UDP o IPv4 traffic 488 Softwire (SPH) 490 <------------------------------> 491 IPV6CP: capable of /64 Intf-Id assignment or 492 uniqueness check 494 |------------------------------>/64 prefix 495 RA 496 |------------------------------>DNS, etc. 497 DHCPv6 499 Figure 3: Host behind CPE as Softwire Initiator 501 In this scenario, after the L2TPv2 Control Channel and Session 502 establishment and PPP LCP negotiation (and optionally PPP 503 Authentication) are successful, IPV6CP negotiates IPv6 over PPP which 504 also provides the capability for the ISP to assign the 64-bit 505 Interface-Identifier to the host or perform uniqueness validation for 506 the two interface identifiers at the two PPP ends [RFC5072]. After 507 IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration / 508 Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can 509 inform the host of a prefix to use for stateless address 510 autoconfiguration through a Router Advertisement (RA) while other 511 nonaddress configuration options (such as DNS [RFC3646]) can be 512 conveyed to the host via DHCPv6. 514 3.1.4. Router behind CPE as Softwire Initiator 516 The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack 517 device (behind the IPv4-only CPE) acting as an IPv6 CPE router inside 518 the home network. The IPv4 traffic SHOULD NOT traverse the Softwire. 519 See Figure 4. 521 IPv6 or dual-stack IPv4-only dual-stack 522 |------------------||-------------------------||-------------| 524 I SC SI 525 N +-----+ +----------+ 526 T | | +-------+ | v4/v6 | 527 E <==[ IPv6 ]....|v4/v6|..[IPv4-only]..|v4-only|---| router | 528 R [network] | | [ network ] | CPE | | | | 529 N | LNS | +-------+ | |LAC Client| 530 E +-----+ | +----------+ 531 T | 532 ---------+-----+ 533 |v4/v6| 534 | host| 535 _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ 536 ()_ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6 537 PPP o L2TPv2 o UDP o IPv4 traffic 538 Softwire (SPH) 540 <---------------------------> 541 IPV6CP: capable of /64 Intf-Id assignment or 542 uniqueness check 544 |--------------------------->/64 prefix 545 RA 546 |--------------------------->/48 prefix, 547 DHCPv6 DNS, etc. 549 |----> /64 550 RA prefix 551 |----> DNS, 552 DHCPv6 etc. 554 Figure 4: Router behind CPE as Softwire Initiator 556 In this scenario, after the L2TPv2 Control Channel and Session 557 establishment and PPP LCP negotiation (and optionally PPP 558 Authentication) are successful, IPV6CP negotiates IPv6 over PPP which 559 also provides the capability for the ISP to assign the 64-bit 560 Interface-Identifier to the v4/v6 router or perform uniqueness 561 validation for the two interface identifiers at the two PPP ends 562 [RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address 563 Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP 564 link, and the LNS can inform the v4/v6 router of a prefix to use for 565 stateless address autoconfiguration through a Router Advertisement 566 (RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g., 567 delegating a prefix to be used within the home network [RFC3633]) and 568 convey other nonaddress configuration options (such as DNS [RFC3646]) 569 to the v4/v6 router. 571 3.2. IPv4 over IPv6 Softwires with L2TPv2 573 The following subsections cover IPv4 connectivity (SPH) across an 574 IPv6-only access network (STH) using a Softwire. 576 3.2.1. Host CPE as Softwire Initiator 578 The Softwire Initiator (SI) is the host CPE (directly connected to a 579 modem), which is dual-stack. There is no other gateway device. The 580 IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 5. 582 IPv4 or dual-stack IPv6-only dual-stack 583 |------------------||-----------------||----------| 585 I SC SI 586 N +-----+ +----------+ 587 T | | | v4/v6 | 588 E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| host CPE | 589 R [network] | | [ network ] | | 590 N | LNS | |LAC Client| 591 E +-----+ +----------+ 592 T _ _ _ _ _ _ _ _ _ 593 ()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic 594 PPP o L2TPv2 o UDP o IPv6 (SPH) 595 Softwire 597 <------------------> 598 IPCP: capable of global IP assignment 599 and DNS, etc. 601 Figure 5: Host CPE as Softwire Initiator 603 In this scenario, after the L2TPv2 Control Channel and Session 604 establishment and PPP LCP negotiation (and optionally PPP 605 Authentication) are successful, IPCP negotiates IPv4 over PPP which 606 also provides the capability for the ISP to assign a global IPv4 607 address to the host CPE. A global IPv4 address can also be assigned 608 via DHCP. Other configuration options (such as DNS) can be conveyed 609 to the host CPE via IPCP [RFC1877] or DHCP [RFC2132]. 611 3.2.2. Router CPE as Softwire Initiator 613 IPv4 connectivity across an IPv6-only access network (STH). The 614 Softwire Initiator (SI) is the router CPE, which is a dual-stack 615 device. The IPv6 traffic SHOULD NOT traverse the Softwire. See 616 Figure 6. 618 IPv4 or dual-stack IPv6-only dual-stack Home 619 |------------------||-----------------||-------------------| 621 I SC SI 622 N +-----+ +----------+ 623 T | | | v4/v6 | +-----+ 624 E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| CPE |--|v4/v6| 625 R [network] | | [ network ] | | | host| 626 N | LNS | |LAC Client| +-----+ 627 E +-----+ +----------+ 628 T _ _ _ _ _ _ _ _ _ 629 ()_ _ _ _ _ _ _ _ _() <--------- IPv4 traffic 630 PPP o L2TPv2 o UDP o IPv6 (SPH) 631 Softwire 633 <------------------> 634 IPCP: capable of global IP assignment 635 and DNS, etc. 637 |------------------> 638 DHCPv4: prefix, mask, PD 640 private/ 641 |------> global 642 DHCP IP, DNS, 643 etc. 645 Figure 6: Router CPE as Softwire Initiator 647 In this scenario, after the L2TPv2 Control Channel and Session 648 establishment and PPP LCP negotiation (and optionally PPP 649 Authentication) are successful, IPCP negotiates IPv4 over PPP which 650 also provides the capability for the ISP to assign a global IPv4 651 address to the router CPE. A global IPv4 address can also be 652 assigned via DHCP. Other configuration options (such as DNS) can be 653 conveyed to the router CPE via IPCP [RFC1877] or DHCP [RFC2132]. For 654 IPv4 Prefix Delegation for the home network, DHCP 656 [I-D.ietf-dhc-subnet-alloc] can be used. 658 3.2.3. Host behind CPE as Softwire Initiator 660 IPv4 connectivity across an IPv6-only access network (STH). The CPE 661 is IPv6-only. The Softwire Initiator (SI) is a dual-stack host 662 (behind the IPv6 CPE), which acts as an IPv4 host CPE. The IPv6 663 traffic SHOULD NOT traverse the Softwire. See Figure 7. 665 IPv4 or dual-stack IPv6-only dual-stack 666 |------------------||----------------------------||----------| 668 I SC SI 669 N +-----+ +----------+ 670 T | | +-------+ | v4/v6 | 671 E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....|v6-only|--| host | 672 R [network] | | [ network ] | CPE | | | 673 N | LNS | +-------+ |LAC Client| 674 E +-----+ +----------+ 675 T _ _ _ _ _ _ _ _ _ _ _ _ _ _ 676 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv4 677 PPP o L2TPv2 o UDP o IPv6 traffic 678 Softwire (SPH) 680 <------------------------------> 681 IPCP: capable of global IP assignment 682 and DNS, etc. 684 Figure 7: Host behind CPE as Softwire Initiator 686 In this scenario, after the L2TPv2 Control Channel and Session 687 establishment and PPP LCP negotiation (and optionally PPP 688 Authentication) are successful, IPCP negotiates IPv4 over PPP which 689 also provides the capability for the ISP to assign a global IPv4 690 address to the host. A global IPv4 address can also be assigned via 691 DHCP. Other configuration options (such as DNS) can be conveyed to 692 the host CPE via IPCP [RFC1877] or DHCP [RFC2132]. 694 3.2.4. Router behind CPE as Softwire Initiator 696 IPv4 connectivity across an IPv6-only access network (STH). The CPE 697 is IPv6-only. The Softwire Initiator (SI) is a dual-stack device 698 (behind the IPv6-only CPE) acting as an IPv4 CPE router inside the 699 home network. The IPv6 traffic SHOULD NOT traverse the Softwire. 700 See Figure 8. 702 IPv4 or dual-stack IPv6-only dual-stack 703 |------------------||-------------------------||------------| 705 I SC SI 706 N +-----+ +----------+ 707 T | | +-------+ | v4/v6 | 708 E <==[ IPv4 ]....|v4/v6|..[IPv6-only]..|v6-only|---| router | 709 R [network] | | [ network ] | CPE | | | | 710 N | LNS | +-------+ | |LAC Client| 711 E +-----+ | +----------+ 712 T | 713 --------+-----+ 714 |v4/v6| 715 | host| 716 _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ 717 ()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- IPv4 718 PPP o L2TPv2 o UDP o IPv4 traffic 719 Softwire (SPH) 721 <---------------------------> 722 IPCP: assigns global IP address and DNS, etc. 724 |---------------------------> 725 DHCPv4: prefix, mask, PD 727 private/ 728 |----> global 729 DHCP IP, DNS, 730 etc. 732 Figure 8: Router behind CPE as Softwire Initiator 734 In this scenario, after the L2TPv2 Control Channel and Session 735 establishment and PPP LCP negotiation (and optionally PPP 736 Authentication) are successful, IPCP negotiates IPv4 over PPP which 737 also provides the capability for the ISP to assign a global IPv4 738 address to the v4/v6 router. A global IPv4 address can also be 739 assigned via DHCP. Other configuration options (such as DNS) can be 740 conveyed to the v4/v6 router via IPCP [RFC1877] or DHCP [RFC2132]. 741 For IPv4 Prefix Delegation for the home network, DHCP 742 [I-D.ietf-dhc-subnet-alloc] can be used. 744 4. Standardization Status 746 This section groups various Internet standards documents and other 747 publications used in Softwires. 749 4.1. L2TPv2 751 RFC 2661 "Layer Two Tunneling Protocol "L2TP"" [RFC2661]. 753 * For both IPv4 and IPv6 payloads (SPH), support is 754 complete. 756 * For both IPv4 and IPv6 transports (STH), support is 757 complete. 759 4.2. Securing the Softwire Transport 761 RFC 3193 "Securing L2TP using IPsec" [RFC3193]. 763 RFC 3948 "UDP Encapsulation of IPsec ESP Packets" [RFC3948]. 765 * IPsec supports both IPv4 and IPv6 transports. 767 4.3. Authentication Authorization Accounting 769 RFC 2865 "Remote Authentication Dial In User Service (RADIUS)" 770 [RFC2865]. 772 RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol 773 Support" [RFC2867]. 775 RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868]. 777 RFC 3162 "RADIUS and IPv6" [RFC3162]. 779 4.4. MIB 781 RFC 1471 "The Definitions of Managed Objects for the Link Control 782 Protocol of the Point-to-Point Protocol" [RFC1471]. 784 RFC 1473 "The Definitions of Managed Objects for the IP Network 785 Control Protocol of the Point-to-Point Protocol" 786 [RFC1473]. 788 RFC 3371 "Layer Two Tunneling Protocol "L2TP" Management 789 Information Base" [RFC3371]. 791 RFC 4087 "IP Tunnel MIB" [RFC4087]. 793 * Both IPv4 and IPv6 transports are supported. 795 4.5. Softwire Payload Related 797 4.5.1. For IPv6 Payloads 799 RFC 4861 "Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861]. 801 RFC 4862 "IPv6 Stateless Address Autoconfiguration" [RFC4862]. 803 RFC 5072 "IP Version 6 over PPP" [RFC5072]. 805 RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" 806 [RFC3315]. 808 RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration 809 Protocol (DHCP) version 6" [RFC3633]. 811 RFC 3646 "DNS Configuration options for Dynamic Host Configuration 812 Protocol for IPv6 (DHCPv6)" [RFC3646]. 814 RFC 3736 "Stateless Dynamic Host Configuration Protocol (DHCP) 815 Service for IPv6" [RFC3736]. 817 4.5.2. For IPv4 Payloads 819 RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)" 820 [RFC1332]. 822 RFC 1661 "The Point-to-Point Protocol (PPP)" [RFC1661]. 824 RFC 1877 "PPP Internet Protocol Control Protocol Extensions for 825 Name Server Addresses" [RFC1877]. 827 RFC 2131 "Dynamic Host Configuration Protocol" [RFC2131]. 829 RFC 2132 "DHCP Options and BOOTP Vendor Extensions" [RFC2132]. 831 DHCP Subnet Allocation "Subnet Allocation Option". 833 * Work in progress, see [I-D.ietf-dhc-subnet-alloc]. 835 5. Softwire Establishment 837 A Softwire is established in three distinct steps (see Figure 9). 838 First an L2TPv2 tunnel with a single session is established from the 839 SI to the SC. Second a PPP session is established over the L2TPv2 840 session and the SI obtains an address. Third the SI optionally gets 841 other information through DHCP such as a delegated prefix and DNS 842 servers. 844 SC SI 845 | | 846 |<-------------L2TPv2------------>| Step 1 847 | | L2TPv2 Tunnel establishment 848 | | 849 |<-------------PPP--------------->| Step 2 850 |<----End Point Configuration---->| PPP and End Point 851 | | configuration 852 | | 853 |<------Router Configuration----->| Step 3 854 | | Additional configuration 855 | | (optional) 857 Figure 9: Steps for the Establishment of a Softwire 859 Figure 10 depicts details of each of the three steps required to 860 establish a Softwire. 862 SC SI 863 | | 864 | | Step 1 865 |<------------SCCRQ---------------| - 866 |-------------SCCRP-------------->| | 867 |<------------SCCCN---------------| | 868 |<------------ICRQ----------------| | L2TPv2 869 |-------------ICRP--------------->| | 870 |<------------ICCN----------------| - 871 | | 872 | | Step 2 873 |<-----Configuration-Request------| - 874 |------Configuration-Request----->| | PPP 875 |--------Configuration-Ack------->| | LCP 876 |<-------Configuration-Ack--------| - 877 | | 878 |-----------Challenge------------>| - PPP Authentication 879 |<----------Response--------------| | (Optional - CHAP) 880 |------------Success------------->| - 881 | | 882 |<-----Configuration-Request------| - 883 |------Configuration-Request----->| | PPP NCP 884 |--------Configuration-Ack------->| | (IPV6CP or IPCP) 885 |<-------Configuration-Ack--------| - 886 | | 887 |<------Router-Solicitation-------| - Neighbor Discovery 888 |-------Router-Advertisement----->| | (IPv6 only) 889 | | - 890 | | 891 | | Step3 892 | | DHCP (Optional) 893 |<-----------SOLICIT--------------| - 894 |-----------ADVERTISE------------>| | DHCPv6 895 |<---------- REQUEST--------------| | (IPv6 SW, Optional) 896 |-------------REPLY-------------->| - 897 | | or 898 |<---------DHCPDISCOVER-----------| - 899 |-----------DHCPOFFER------------>| | DHCPv4 900 |<---------DHCPREQUEST------------| | (IPv4 SW, Optional) 901 |------------DHCPACK------------->| - 903 Figure 10: Detailed Steps in the Establishment of a Softwire 905 The PPP NCP negotiations in step 2 use IPV6CP for IPv6 over IPv4 906 Softwires, and IPCP for IPv4 over IPv6 Softwires. The optional DHCP 907 negitiations in step 3 use DHCPv6 for IPv6 over IPv4 Softwires, and 908 DHCPv4 for IPv4 over IPv6 Softwires. Additionally, for IPv6 over 909 IPv4 Softwires, the DHCPv6 exchange for nonaddress configuration 910 (such as DNS) can use a two message exchange with Information-Request 911 and Reply messages (see Section 1.2 of [RFC3315] and [RFC3736]). 913 5.1. L2TPv2 Tunnel Setup 915 L2TPv2 [RFC2661] was originally designed to provide private network 916 access to end users connected to a public network. In the L2TPv2 917 incoming call model, the end user makes a connection to an L2TP 918 Access Concentrator (LAC). The LAC then initiates an L2TPv2 tunnel 919 to an L2TP Network Server (LNS). The LNS then transfers end user 920 traffic between the L2TPv2 tunnel and the private network. 922 In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI) 923 assumes the role of the LAC Client and the Softwire Concentrator (SC) 924 assumes the role of the LNS. 926 In the Softwire model, an L2TPv2 packet MUST be carried over UDP. 927 The underlying version of the IP protocol may be IPv4 or IPv6, 928 depending on the Softwire scenario. 930 In the following sections, the term "Tunnel" follows the definition 931 from Section 1.2 of [RFC2661], namely: "The Tunnel consists of a 932 Control Connection and zero or more L2TP Sessions". 934 5.1.1. Tunnel Establishment 936 Figure 11 describes the messages exchanged and Attribute Value Pairs 937 (AVPs) used to establish a tunnel between an SI (LAC) and an SC 938 (LNS). The messages and AVPs described here are only a subset of 939 those defined in [RFC2661]. This is because Softwires use only a 940 subset of the L2TPv2 functionality. The subset of L2TP Control 941 Connection Management AVPs that is applicable to Softwires is grouped 942 into Mandatory AVPs and Optional AVPs (see Figure 11). Note that in 943 the Softwire environment, the SI always initiates the tunnel. L2TPv2 944 AVPs SHOULD NOT be hidden. 946 SC SI 947 |<--------SCCRQ---------| 948 Mandatory AVPs: 949 Message Type 950 Protocol Version 951 Host Name 952 Framing Capabilities 953 Assigned Tunnel ID 954 Optional AVPs: 955 Receive Window Size 956 Challenge 957 Firmware Revision 958 Vendor Name 960 |---------SCCRP-------->| 961 Mandatory AVPs: 962 Message Type 963 Protocol Version 964 Framing Capabilities 965 Host Name 966 Assigned Tunnel ID 967 Optional AVPs: 968 Firmware Revision 969 Vendor Name 970 Receive Window Size 971 Challenge 972 Challenge Response 974 |<--------SCCCN---------| 975 Mandatory AVPs: 976 Message Type 977 Optional AVPs: 978 Challenge Response 980 Figure 11: Control Connection Establishment 982 In L2TPv2, generally, the tunnel between an LAC and LNS may carry the 983 data of multiple users. Each of these users is represented by an 984 L2TPv2 session within the tunnel. In the Softwire environment, the 985 tunnel carries the information of a single user. Consequently, there 986 is only one L2TPv2 session per tunnel. Figure 12 describes the 987 messages exchanged and the AVPs used to establish a session between 988 an SI (LAC) and an SC (LNS). The messages and AVPs described here 989 are only a subset of those defined in [RFC2661]. This is because 990 Softwires use only a subset of the L2TPv2 functionality. The subset 991 of L2TP Call Management AVPs that is applicable to Softwires is 992 grouped into Mandatory AVPs and Optional AVPs (see Figure 12). Note 993 that in the Softwire environment, the SI always initiates the 994 session. No outgoing or analog calls are permitted. L2TPv2 AVPs 995 SHOULD NOT be hidden. 997 SC SI 998 |<--------ICRQ---------| 999 Mandatory AVPs: 1000 Message Type 1001 Assigned Session ID 1002 Call Serial Number 1004 |---------ICRP-------->| 1005 Mandatory AVPs: 1006 Message Type 1007 Assigned Session ID 1009 |<--------ICCN---------| 1010 Mandatory AVPs: 1011 Message Type 1012 (Tx) Connect Speed 1013 Framing Type 1015 Figure 12: Session Establishment 1017 5.1.1.1. AVPs Required for Softwires 1019 This section prescribes specific values for AVPs used in the Softwire 1020 context that are Mandatory. 1022 Host Name AVP 1024 This AVP is mandatory in SCCRQ and SCCRP messages. This AVP may 1025 be used to authenticate users, in which case it would contain a 1026 user identification. If this AVP is not used to authenticate 1027 users, it may be used for logging purposes. 1029 Framing Capabilities AVP 1031 Both the synchronous (S) and asynchronous (A) bits SHOULD be set 1032 to 1. This AVP SHOULD be ignored by the receiver. 1034 Framing Type AVP 1036 The synchronous bit SHOULD be set to 1 and the asynchronous bit to 1037 0. This AVP SHOULD be ignored by the receiver. 1039 (Tx) Connect Speed 1040 (Tx) Connect Speed is a mandatory AVP but is not meaningful in the 1041 Softwire context. Its value SHOULD be set to 0 and ignored by the 1042 receiver. 1044 Message Type AVP, Protocol Version AVP, Assigned Tunnel ID AVP, Call 1045 Serial Number AVP, and Assigned Session ID AVP 1047 As defined in [RFC2661]. 1049 5.1.1.2. AVPs Optional for Softwires 1051 This section prescribes specific values for AVPs used in the Softwire 1052 context that are Optional. 1054 Challenge AVP and Challenge Response AVP 1056 These AVPs are not required, but are necessary to implement tunnel 1057 authentication. Since tunnel authentication happens at the 1058 beginning of L2TPv2 tunnel creation, it can be helpful in 1059 preventing DoS attacks. See Section 5.1.1 of [RFC2661]. 1061 The usage of these AVPs in L2TP messages is OPTIONAL, but SHOULD 1062 be implemented in the SC. 1064 Receive Window Size AVP, Firmware Revision AVP, and Vendor Name AVP 1066 As defined in [RFC2661]. 1068 5.1.1.3. AVPs not Relevant for Softwires 1070 L2TPv2 specifies numerous AVPs that, while allowed for a given 1071 message, are irrelevant to Softwires. Softwire implementations 1072 SHOULD NOT send these AVPs. However, they SHOULD ignore them when 1073 they are received. This will simplify the creation of Softwire 1074 applications that build upon existing L2TPv2 implementations. 1076 5.1.2. Tunnel Maintenance 1078 Periodically, the SI/SC MUST transmit a message to the peer to detect 1079 tunnel or peer failure and maintain NAT/NAPT contexts. The L2TPv2 1080 HELLO message provides a simple, low overhead method of doing this. 1082 The default values specified in [RFC2661] for L2TPv2 HELLO messages 1083 could result in a dead end detection time of 83 seconds. Although 1084 these retransmission timers and counters SHOULD be configurable (see 1085 Section 5.8 of [RFC2661]), these values may not be adapted for all 1086 situations, where a quicker dead end detection is required, or where 1087 NAT/NAPT context needs to be refreshed more frequently. In such 1088 cases, the SI/SC MAY use, in combination with L2TPv2 HELLO, LCP ECHO 1089 messages (Echo-Request and Echo-Reply codes) described in [RFC1661]. 1090 When used, LCP ECHO messages SHOULD have a re-emission timer lower 1091 than the value for L2TPv2 HELLO hello messages. The default value 1092 recommended in Section 6.5 of [RFC2661] for the HELLO message 1093 retransmission interval is 60 seconds. When used, a set of suggested 1094 values (included here only for guidance) for the LCP ECHO message 1095 request interval is a default of 30 seconds, a minimum of 10 seconds, 1096 and a maximum of the lesser of the configured L2TPv2 HELLO 1097 retransmisison interval and 60 seconds. 1099 5.1.3. Tunnel Teardown 1101 Either the SI or SC can teardown the session and tunnel. This is 1102 done as specified in Section 5.7 of [RFC2661], by sending a StopCCN 1103 control message. There is no action specific to Softwires in this 1104 case. 1106 5.2. PPP Connection 1108 This section describes the PPP negotiations between the SI and SC in 1109 the Softwire context. 1111 5.2.1. MTU 1113 The MTU of the PPP link presented to the SPH SHOULD be the link MTU 1114 minus the size of the IP, UDP, L2TPv2, and PPP headers together. On 1115 an IPv4 link with an MTU equal to 1500 bytes, this could tipically 1116 mean a PPP MTU of 1460 bytes. When the link is managed by IPsec, 1117 this MTU should be lowered to take into account the ESP encapsulation 1118 (see [I-D.ietf-softwire-security-requirements]). The value for the 1119 MTU may also vary according to the size of the L2TP header, as 1120 defined by the leading bits of the L2TP message header (see 1121 [RFC2661]). Additionally, see [RFC4623] for a detailed discussion of 1122 fragmentation issues. 1124 5.2.2. LCP 1126 Once the L2TPv2 session is established, the SI and SC initiate the 1127 PPP connection by negotiating LCP as described in [RFC1661]. The 1128 Address-and-Control-Field-Compression configuration option (ACFC) 1129 [RFC1661] MAY be rejected. 1131 5.2.3. Authentication 1133 After completing LCP negotiation, the SI and SC may optionally 1134 perform authentication. If authentication is chosen, CHAP [RFC1994] 1135 authentication MUST be supported by both the Softwire Initiator and 1136 Softwire Concentrator. Other authentication methods such as MS- 1137 CHAPv1 [RFC2433], and EAP [RFC3748] MAY be supported. 1139 A detailed discussion of Softwire security is contained in 1140 [I-D.ietf-softwire-security-requirements]. 1142 5.2.4. IPCP 1144 The only Network Control Protocol (NCP) negotiated in the Softwire 1145 context is IPV6CP (see Section 5.2.4.1) for IPv6 as SPH, and IPCP 1146 (see Section 5.2.4.2) for IPv4 as SPH. 1148 5.2.4.1. IPV6CP 1150 In the IPv6 over IPv4 scenarios (see Section 3.1), after the optional 1151 authentication phase, the Softwire Initiator MUST negotiate IPV6CP as 1152 defined in [RFC5072]. IPV6CP provides a way to negotiate a unique 1153 64-bit Interface-Identifier to be used for the address 1154 autoconfiguration at the local end of the link. 1156 5.2.4.2. IPv4CP 1158 In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire 1159 Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain 1160 an IPv4 address from the SC. IPCP may also be used to obtain DNS 1161 information as described in [RFC1877]. 1163 5.3. Global IPv6 Address Assignement to Endpoints 1165 In several scenarios defined in Section 3.1, Global IPv6 addresses 1166 are expected to be allocated to Softwire endpoints (in addition to 1167 the Link-Local addresses autoconfigured using the IPV6CP negotiated 1168 interface identifier). The Softwire Initiator assigns global IPv6 1169 addresses using the IPV6CP negotiated interface identifier and using 1170 Stateless Address Autoconfiguration [RFC4862], and/or using Privacy 1171 Extensions for Stateless Address Autoconfiguration [RFC4941], (as 1172 described in Section 5 of [RFC5072]), and/or using DHCPv6 [RFC3315]. 1174 The Softwire Initiator of an IPv6 Softwire MUST send a Router 1175 Solicitation message to the Softwire Concentrator after IPV6CP is 1176 completed. The Softwire Concentrator MUST answer with a Router 1177 Advertisement. This message MUST contains the global IPv6 prefix of 1178 the PPP link if Neighbor Discovery is used to configure addresses of 1179 Softwire endpoints. 1181 If DHCPv6 is available for address delegation, the M bits of the 1182 Router Advertisement SHOULD be set. The Softwire Initiator MUST then 1183 send a DHCPv6 Request to configure the address of the Softwire 1184 endpoint. 1186 Duplicate Address Detection ([RFC4861]) MUST be performed on the 1187 Softwire in both cases. 1189 5.4. DHCP 1191 The Softwire Initiator MAY use DHCP to get additional information 1192 such as delegated prefix and DNS servers. 1194 5.4.1. DHCPv6 1196 In the scenarions in Section 3.1, if the SI supports DHCPv6, it 1197 SHOULD send a Solicit message to verify if more information is 1198 available. 1200 If an SI establishing an IPv6 Softwire acts as a router (i.e., in the 1201 scenarios in Section 3.1.2 and Section 3.1.4) it MUST include the 1202 IA_PD option [RFC3633] in the DHCPv6 Solicit message [RFC3315] in 1203 order to request an IPv6 prefix. 1205 When delegating an IPv6 prefix to the SI by returning a DHCPv6 1206 Advertise message with the IA_PD and IP_PD Prefix options [RFC3633], 1207 the SC SHOULD inject a route for this prefix in the IPv6 routing 1208 table in order to forward the traffic to the relevant Softwire. 1210 Configuration of DNS MUST be done as specified in [RFC3646] and 1211 transmitted according to [RFC3315] and [RFC3736]. In general, all 1212 DHCPv6 options MUST be transmitted according to [RFC3315] and 1213 [RFC3736]. 1215 5.4.2. DHCPv4 1217 An SI establishing an IPv4 Softwire MAY send a DHCP request 1218 containing the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc]. 1219 This practice is not common but may be used to connect IPv4 subnets 1220 using Softwires, as defined in Section 3.2.2 and Section 3.2.4. 1222 One Subnet-Request suboption MUST be configured with the 'h' bit set 1223 to '1', as the SI is expected to perform the DHCP server function. 1224 The 'i' bit of the Subnet-Request suboption SHOULD be set to '0' the 1225 first time a prefix is requested and to '1' on subsequent requests, 1226 if a prefix has been allocated. The Prefix length suboption SHOULD 1227 be 0 by default. If the SI is configured to support only specific 1228 prefix lengths, it SHOULD specify the longest (smallest) prefix 1229 length it supports. 1231 If the SI was previously assigned a prefix from that same SC, it 1232 SHOULD include the Subnet-Information suboption with the prefix it 1233 was previously assigned. The 'c' and 's' bits of the suboption 1234 SHOULD be set to '0'. 1236 In the scenarions in Section 3.2, when delegating an IPv4 prefix to 1237 the SI, the SC SHOULD inject a route for this prefix in the IPv4 1238 routing table in order to forward the traffic to the relevant 1239 Softwire. 1241 6. Considerations about the Address Provisioning Model 1243 This section describes how a Softwire Concentrator may manage 1244 delegated addresses for Softwire endpoints and for subnets behind the 1245 Softwire Initiator. One common practice is to aggregate endpoints' 1246 addresses and delegated prefixes into one prefix routed to the SC. 1247 The main benefit is to ease the routing scheme by isolating on the SC 1248 succeeding route injections (when delegating new prefixes for SI). 1250 6.1. Softwire Endpoints' Addresses 1252 6.1.1. IPv6 1254 A Softwire Concentrator should provide globally routable addresses to 1255 Softwire endpoints. Other types of addresses such as Unique Local 1256 Addresses [RFC4193] may be used to address Softwire endpoints in a 1257 private network with no global connectivity. A single /64 should be 1258 assigned to the Softwire to address both Softwire endpoints. 1260 Global or ULA addresses must be assigned to endpoints when the 1261 scenario "Host CPE as Softwire Initiator" (described in 1262 Section 3.1.1) is considered to be deployed. For other scenarios, 1263 this may be optional and link local addresses should be used. 1265 6.1.2. IPv4 1267 A Softwire Concentrator may provide either globally routable or 1268 private IPv4 addresses. When using IPv4 private addresses [RFC1918] 1269 on the endpoints, it is not recommended to delegate an IPv4 private 1270 prefix to the SI, as it can lead to a nested-NAT situations. 1272 The endpoints of the PPP link use host addresses (i.e., /32), 1273 negotiated using IPCP. 1275 6.2. Delegated Prefixes 1276 6.2.1. IPv6 Prefixes 1278 Delegated IPv6 prefixes should be of global scope if the IPv6 1279 addresses assigned to endpoints are global. Using ULA addresses is 1280 not recommended when the subnet is connected to the global IPv6 1281 Internet. When using ULA IPv6 address for endpoint, the delegated 1282 IPv6 prefix may be either of Global or ULA scope. 1284 Delegated IPv6 prefixes are between /48 and /64 in length. When an 1285 SI receives a prefix shorter than 64, it can assign different /64 1286 prefixes to each of its interfaces. An SI receiving a single /64 is 1287 expected to perform bridging if more than one interface are available 1288 (e.g., wired and wireless). 1290 6.2.2. IPv4 Prefixes 1292 Delegated IPv4 prefixes should be routable within the address space 1293 used by assigned IPv4 addresses. Delegate non-routable IPv4 prefixes 1294 (i.e., private IPv4 prefix over public IPv4 addresses or another 1295 class of private IPv4 addresses) is not recommended as a practice for 1296 provisioning and address translation should be considered in these 1297 cases. The prefix length is between /8 and /30. 1299 6.3. Possible Address Provisioning Scenarios 1301 This section summarizes the differents scenarios for address 1302 provisioning with the considerations given in the previous sections. 1304 6.3.1. Scenarios for IPv6 1306 This table describes the possible combination of IPv6 address scope 1307 for endpoints and delegated prefixes. 1309 +------------------+-----------------------+------------------------+ 1310 | Endpoint IPv6 | Delegated Global IPv6 | Delegated ULA IPv6 | 1311 | Address | Prefix | Prefix | 1312 +------------------+-----------------------+------------------------+ 1313 | Link Local | Possible | Possible | 1314 | | | | 1315 | ULA | Possible | Possible | 1316 | | | | 1317 | Global | Possible | Possible, but Not | 1318 | | | Recommended | 1319 +------------------+-----------------------+------------------------+ 1321 Table 1: Scenarios for IPv6 1323 6.3.2. Scenarios for IPv4 1325 This table describes the possible combination of IPv4 address scope 1326 for endpoints and delegated prefixes. 1328 +-------------+-----------------+-----------------------------------+ 1329 | Endpoint | Delegated | Delegated Private IPv4 Prefix | 1330 | IPv4 | Public IPv4 | | 1331 | Address | Prefix | | 1332 +-------------+-----------------+-----------------------------------+ 1333 | Private | Possible | Possible, but Not Recommended | 1334 | IPv4 | | when using NAT (cf. | 1335 | | | Section 6.1.2) | 1336 | | | | 1337 | Public IPv4 | Possible | Possible, but NAT usage is | 1338 | | | recommended (cf. Section 6.2.2) | 1339 +-------------+-----------------+-----------------------------------+ 1341 Table 2: Scenarios for IPv4 1343 7. Considerations about Address Stability 1345 A Softwire can provide stable addresses even if the underlying 1346 addressing scheme changes, by opposition to automatic tunneling. A 1347 Softwire Concentrator should always provide the same address and 1348 prefix to a reconnecting user. However, if the goal of the Softwire 1349 service is to provide a temporary address for a roaming user, it may 1350 be provisioned to provide only a temporary address. 1352 The address and prefix are expected to change when reconnecting to a 1353 different Softwire Concentrator. However an organization providing a 1354 Softwire service may provide the same address and prefix across 1355 different Softwire Concentrators at the cost of a more fragmented 1356 routing table. The routing fragmentation issue may be limited if the 1357 prefixes are aggregated in a location topologically close to the SC. 1358 This would be the case for example if several SCs are put in parallel 1359 for load-balancing purpose. 1361 8. Considerations about RADIUS Integration 1363 The Softwire Concentrator is expected to act as a client to a AAA 1364 server, for example a RADIUS server. During the PPP authentication 1365 phase, the RADIUS server may return additional informations in the 1366 form of attributes in the Access-Accept message. 1368 The Softwire Concentrator may include the Tunnel-Type and Tunnel- 1369 Medium-Type attributes [RFC2868] in the Access-Request messages to 1370 provide a hint of the type of Softwire being configured. 1372 8.1. Softwire Endpoints 1374 8.1.1. IPv6 Softwires 1376 If the RADIUS server includes a Framed-Interface-Id attribute 1377 [RFC3162], the Softwire Concentrator must send it to the Softwire 1378 Initiator in the Interface-Identifier field of its IPV6CP 1379 Configuration Request message. 1381 If the Framed-IPv6-Prefix attribute [RFC3162] is included, that 1382 prefix must be used in the router advertisements sent to the SI. If 1383 Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC 1384 must choose a prefix with that pool to send RAs. 1386 If none of the attributes above are included but the AAA server 1387 returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint 1388 attributes [RFC2868] with the correct address family, these must be 1389 used in the IPV6CP Interface-Identifier and for the Router 1390 Advertisements. 1392 8.1.2. IPv4 Softwires 1394 If the Framed-IP-Address attribute [RFC2865] is present, the Softwire 1395 Concentrator must provide that address to the Softwire Initiator 1396 during IPCP address negotiation. That is, when the Softwire 1397 Initiator requests an IP address from the Softwire Concentrator, the 1398 address provided should be the Framed-IP-Address. 1400 If the Framed-IP-Address attribute is not present and the Tunnel- 1401 Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are 1402 present and of the correct address family, these should be used in 1403 the IPCP IP-Address configuration option. 1405 8.2. Delegated Prefixes 1407 8.2.1. IPv6 Prefixes 1409 If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the 1410 RADIUS Access-Accept message, it must be used by the Softwire 1411 Concentrator for the delegation of the IPv6 prefix. Since the prefix 1412 delegation is performed by DHCPv6 and the attribute is linked to a 1413 username, the SC must associate the DHCP Unique Identifier (DUID) of 1414 a DHCPv6 request to the tunnel it came from and its user. 1416 Interaction between RADIUS, PPP and DHCPv6 server may follow the 1417 mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. In this case, 1418 during the Softwire authentication phase, PPP collects the RADIUS 1419 attributes for the user such as Delegated-IPv6-Prefix. A specific 1420 DHCPv6 relay is assigned to the Softwire. The DHCPv6 relay fills in 1421 these attributes in the Relay agent RADIUS Attribute Option (RRAO) 1422 DHCPv6 option, before forwarding the DHCPv6 requests to the DHCPv6 1423 server. 1425 8.2.2. IPv4 Prefixes 1427 The combination of the Framed-IP-Address and Framed-IP-Netmask 1428 attributes [RFC2865] may be used by the Softwire Concentrator to 1429 delegate an IPv4 prefix to the Softwire Initiator. 1431 9. Considerations for Maintenance and Statistics 1433 9.1. RADIUS Accounting 1435 RADIUS Accounting for L2TP and PPP are documented (see Section 4.3). 1437 When deploying Softwire solutions, operators may experience 1438 difficulties to differentiate the address family of the traffic 1439 reported in accounting information from RADIUS. This problem and 1440 some potential solutions are described in 1441 [I-D.stevant-softwire-accounting]. 1443 9.2. MIBs 1445 MIB support for L2TPv2 and PPP are documented (see Section 4.4). 1446 Also see [RFC4293]. 1448 10. Security Considerations 1450 A detailed discussion of Softwire security is contained in 1451 [I-D.ietf-softwire-security-requirements]. 1453 The L2TPv2 Softwire solution provides the following tools for 1454 security: 1456 o IPsec [RFC4301] with IKEv2 [RFC4306] provides the highest level of 1457 security. [RFC3193] describes interaction between IPsec and 1458 L2TPv2. 1460 o PPP CHAP [RFC1994] provides basic user authentication. 1462 o L2TP Tunnel Authentication [RFC2661] provides authentication at 1463 tunnel setup. It may be used to limit DoS attacks by 1464 authenticating the tunnel before L2TP session and PPP resources 1465 are allocated. 1467 11. IANA Considerations 1469 This document creates no new requirements on IANA namespaces 1470 [RFC2434]. 1472 12. Acknowledgements 1474 The authors would like to acknowledge the following contributors who 1475 provided helpful input on this document: Florent Parent, Jordi Palet 1476 Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, 1477 Francis Dupont and Ralph Droms. 1479 The authors would also like to acknowledge the participants in the 1480 Softwires interim meetings held in Hong Kong, China and Barcelona, 1481 Spain. The minutes for the interim meeting at the China University - 1482 Hong Kong (February 23-24, 2006) are at 1483 . The 1484 minutes for the interim meeting at Polytechnic University of 1485 Catalonia - Barcelona (September 14-15, 2006) are reachable at . 1488 13. References 1490 13.1. Normative References 1492 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 1493 (IPCP)", RFC 1332, May 1992. 1495 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1496 RFC 1661, July 1994. 1498 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1499 E. Lear, "Address Allocation for Private Internets", 1500 BCP 5, RFC 1918, February 1996. 1502 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1503 Protocol (CHAP)", RFC 1994, August 1996. 1505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1506 Requirement Levels", BCP 14, RFC 2119, March 1997. 1508 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1509 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1510 October 1998. 1512 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1513 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1514 RFC 2661, August 1999. 1516 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1517 "Remote Authentication Dial In User Service (RADIUS)", 1518 RFC 2865, June 2000. 1520 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1521 RFC 3162, August 2001. 1523 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 1524 "Securing L2TP using IPsec", RFC 3193, November 2001. 1526 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1527 and M. Carney, "Dynamic Host Configuration Protocol for 1528 IPv6 (DHCPv6)", RFC 3315, July 2003. 1530 [RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two 1531 Tunneling Protocol "L2TP" Management Information Base", 1532 RFC 3371, August 2002. 1534 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1535 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1536 December 2003. 1538 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1539 (DHCP) Service for IPv6", RFC 3736, April 2004. 1541 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1542 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1543 RFC 3948, January 2005. 1545 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1546 Internet Protocol", RFC 4301, December 2005. 1548 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1549 RFC 4306, December 2005. 1551 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1552 Attribute", RFC 4818, April 2007. 1554 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1555 Address Autoconfiguration", RFC 4862, September 2007. 1557 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 1558 PPP", RFC 5072, September 2007. 1560 13.2. Informative References 1562 [I-D.ietf-dhc-subnet-alloc] 1563 Johnson, R., "Subnet Allocation Option", 1564 draft-ietf-dhc-subnet-alloc-06 (work in progress), 1565 November 2007. 1567 [I-D.ietf-dhc-v6-relay-radius] 1568 Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option", 1569 draft-ietf-dhc-v6-relay-radius-02 (work in progress), 1570 February 2006. 1572 [I-D.ietf-softwire-security-requirements] 1573 Yamamoto, S., Williams, C., Parent, F., and H. Yokota, 1574 "Softwire Security Analysis and Requirements", 1575 draft-ietf-softwire-security-requirements-05 (work in 1576 progress), December 2007. 1578 [I-D.stevant-softwire-accounting] 1579 Stevant, B., "Accounting on Softwires", 1580 draft-stevant-softwire-accounting-01 (work in progress), 1581 October 2006. 1583 [RFC1471] Kastenholz, F., "The Definitions of Managed Objects for 1584 the Link Control Protocol of the Point-to-Point Protocol", 1585 RFC 1471, June 1993. 1587 [RFC1473] Kastenholz, F., "The Definitions of Managed Objects for 1588 the IP Network Control Protocol of the Point-to-Point 1589 Protocol", RFC 1473, June 1993. 1591 [RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control 1592 Protocol Extensions for Name Server Addresses", RFC 1877, 1593 December 1995. 1595 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1596 RFC 2131, March 1997. 1598 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1599 Extensions", RFC 2132, March 1997. 1601 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 1602 RFC 2433, October 1998. 1604 [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting 1605 Modifications for Tunnel Protocol Support", RFC 2867, 1606 June 2000. 1608 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, 1609 M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1610 Support", RFC 2868, June 2000. 1612 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1613 Address Translator (Traditional NAT)", RFC 3022, 1614 January 2001. 1616 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1617 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1618 December 2003. 1620 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1621 Levkowetz, "Extensible Authentication Protocol (EAP)", 1622 RFC 3748, June 2004. 1624 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 1625 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1627 [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005. 1629 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1630 Addresses", RFC 4193, October 2005. 1632 [RFC4293] Routhier, S., "Management Information Base for the 1633 Internet Protocol (IP)", RFC 4293, April 2006. 1635 [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- 1636 Edge (PWE3) Fragmentation and Reassembly", RFC 4623, 1637 August 2006. 1639 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1640 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1641 September 2007. 1643 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 1644 Problem Statement", RFC 4925, July 2007. 1646 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1647 Extensions for Stateless Address Autoconfiguration in 1648 IPv6", RFC 4941, September 2007. 1650 Appendix A. Revision History 1652 [Note to RFC Editor: please remove this entire appendix, and the 1653 corresponding entries in the table of contents, prior to 1654 publication.] 1656 Changes between -07 and -08: 1658 o Corrected the usage of Softwire vs. Softwires throughout the 1659 document, esp. when used as an adjective. 1661 o Editorial: Re-arranged "Contributing Authors" (Section 1.3). 1663 o Miscellaneous editorial corrections, readability improvements, 1664 completed the Abbreviations Section 1.1. 1666 o Added Section 2.3 about "Routing". 1668 o In all the Deployment Scenarios (Section 3), clarified that the 1669 description is after successful LCP negotiation and optional PPP 1670 Authentication. Corrected "DHCPv6" in Figure 1 and Figure 3. 1672 o Removed /48 example from Section 3.1.2 and Section 3.1.4. 1674 o Added reference and corresponding citations to [RFC2132] in 1675 Section 3.2. 1677 o Completed the citations on Section 4.5, adding [RFC4862], 1678 [RFC3633], [RFC2131], and [RFC2132]. 1680 o Moved the last two sentences of Section 5.4 to Section 5.4.1 and 1681 Section 5.4.2 respectively. 1683 o Completed the first paragraph of Section 5.3, adding an 1684 informational reference to [RFC4941]. 1686 o Added DHCPv4 to Figure 10 for the IPv4 over IPv6 scenarios. Added 1687 a follow-on clarifying paragraph about PPP NCP and DHCP versions 1688 used in each softwire scenario. 1690 o Clarification of implementation versus usage of the optional AVPs 1691 in Section 5.1.1.2. 1693 o Added text including [RFC3736] for DHCPv6. 1695 Changes between -06 and -07: 1697 o Changed RFC numbers: RFC2461 and I-D 2461(bis) to [RFC4861], 1698 RFC2462 to [RFC4862], and RFC2472 and I-D.ietf-ipv6-over-ppp-v2 to 1699 [RFC5072]. 1701 Changes between -05 and -06: 1703 o Swapped Section 4.1 and Section 4.2. Renamed Section 4.2 to 1704 "Securing the Softwire Transport". 1706 o In Section 5.2.1, added a mention that the MTU should be lower 1707 that 1460 when using IPsec. 1709 o In Section 10, added pointers to [RFC4301] and [RFC4306]. 1711 Changes between -04 and -05: 1713 o Replaced "documentation" with "logging purposes" in 1714 Section 5.1.1.1. 1716 o Added suggested values (only as guidance) for Keepalives in 1717 Section 5.1.2. 1719 Changes between -03 and -04: 1721 o Added missing references to [RFC4087], [RFC4861], and [RFC3646], 1722 moved [RFC4623] to Informative. 1724 o Rephrasing in Section 6.2.2. Added pointers Section 6.1.2 and 1725 Section 6.2.2 in Table 2. 1727 o Added citations (and corresponding references) to [RFC1471] and 1728 [RFC1473] in Section 4.4, since Section 9.2 explicitly mentions: 1729 "MIB support for L2TPv2 and PPP are documented." 1731 o Fixed some RFC2119 keywords in Section 3.1.1, Section 3.1.2, 1732 Section 3.1.3, Section 3.1.4, Section 3.2.1, Section 3.2.2, 1733 Section 3.2.3, Section 3.2.4, Section 5.1.1.3, Section 5.4.2, and 1734 Section 8.1.1. 1736 o Added [RFC2868] to Section 4.3, and added missing citations to 1737 Section 4. 1739 o Added missing "Optional AVP" to Figure 11. 1741 o Updated the text in Section 6.2.2. 1743 o Added some clarifying sentences in Section 5.1.1, and completed 1744 Section 5.1.1.1 and Section 5.1.1.2. 1746 o Added an Informative reference to [RFC3022] for NAT/NAPT. 1748 o Corrected reference to [RFC1661] in Section 5.2.2, removed 1749 reference and citation to RFC1662. 1751 o Updated references, Delegated-IPv6-Prefix became [RFC4818] moved 1752 to Normative. 1754 o Added new address and email for J.F. Tremblay. 1756 o Added an acknowledgement to the participants, and pointer to the 1757 minutes, for the Barcelona interim meeting. 1759 o Moved the Softwire Problem Statement reference [RFC4925] to 1760 Informative. 1762 o Some additional purely editorial changes. 1764 Changes between -02 and -03: 1766 o Boiler changes in support of RFC 4748. 1768 o Added text about L2TPv2 HELLO and LCP ECHO usage in Section 1, 1769 Section 2.7 and Section 5.1.2. 1771 o Moved some downref to Informative ([RFC1877], [RFC2433], 1772 [RFC2867], [RFC2868], and [RFC3748]), and moved CHAP reference to 1773 Normative ([RFC1994]). 1775 o Removed the mention and citation for PAP authentication. 1777 Changes between -01 and -02: 1779 o Renamed all "Best Current Practices" sections as 1780 "Recommendations". See for example Section 1.4. 1782 o Moved Provisioning in Section 6. Removed intro text to new 1783 Section 7. 1785 o Removed all normative language from Section 6, Section 7, 1786 Section 8, and Section 9. 1788 o Removed empty sections "Implementation Status", and "Open Issues". 1790 o Fixed "Phase 0" in Section 1. 1792 o Small changes to Section 3.1. 1794 o Change L2TP -> L2TPv2 in some sections, including Section 6. 1796 o Small additions and typo fixes in Section 5.1.1.1 and 1797 Section 5.1.1.2. 1799 o Retitled Section 8 and Section 8.1, changed AAA -> RADIUS. 1801 o New paragraph in Section 9.1. 1803 o New paragraph in Section 8.2.1, including a pointer to 1804 [I-D.ietf-dhc-v6-relay-radius]. 1806 o Moved last paragraph to start of Section 10. 1808 o Moved some references from Normative to Informative. 1810 o Label the steps in Figure 9 and Figure 10. 1812 o Reword paragraph of Section 5.1. 1814 o Describe more messages than flows in Figure 11 and Figure 12. 1816 o Add text about Session Establishment between Figure 11 and 1817 Figure 12. 1819 o Section 5.1.1.1 and Section 5.1.1.2: Updates on Hostname AVP, 1820 Framing Capabilities AVP, Framing Type AVP, Connect Speed AVP and 1821 Challenge and Challenge Response AVPs. 1823 o Retitled Section 5.1.1.3. 1825 o Updates on the use of L2TP HELLO versus LCP, delay for Dead-End 1826 peer detection, and allow LCP. 1828 o Rewording in Section 5.1.3. 1830 o Section 5.2.1: Add a pointer to [RFC4623] and small updates. 1832 o Clarifications on PFC and ACFC, remove Figure 13. 1834 o Section 5.2.3: make references to RFCs for PAP, CHAP, etc. 1836 o Rewordings in Section 5.2.4.1 and Section 5.2.4.2. 1838 o Added Informative references to [RFC4623], [RFC1661], [RFC2433], 1839 and [RFC3748]. 1841 o Renamed the title and added more details on Section 5.3 and IPv6 1842 ND, including a pointer to I-D.ietf-ipv6-2461bis. 1844 o Added text in Section 5.4 about IPv4 PD is non-trivial and non 1845 commonly done. 1847 o Added B. Stevant as Editor. 1849 o Clarification in Section 5.2.4.1 and Section 5.2.4.2 regarding the 1850 scope of the MUST (to the specific scenarios). 1852 o Removed considerations about reverse DNS from Section 6, agreed on 1853 Barcelona. 1855 o Clarified the NAT case in Section 6.1.2 1857 o Added first paragraph in Section 6.2.1 regarding delegated IPv6 1858 prefixes. 1860 o Added new Section 6.3, Section 6.3.1 and Section 6.3.2 summarizing 1861 the scenarios for address allocation. 1863 Changes between -00 and -01: 1865 o Changed alignment in all figures to be centered, and fixed 1866 Figure 9 reference. 1868 o Section 1.4: Added new section with "Best Current Practices" 1869 definition. 1871 o Marked the following sections as "Best Current Practices": 1872 Section 6, Section 8, and Section 9. 1874 o Section 6.1.1, last paragraph: Removed sentence on IPv6 link 1875 address on the PPP link. Mailing list comment from Florent 1876 Parent, 13-Jul-2006. 1878 o Section 6.1.2, last paragraph: Changed IPv4 PPP link address to 1879 use host addresses (/32) negotiated with IPCP instead of /30. 1880 Mailing list comment from Bill Storer, 5-Jul-2006. 1882 o Section 5, Figure 10: Correction, s/SCCSN/SCCCN/; added missing 1883 ICRP, and changed direction of ICCN; typo correction s/IPV6P/ 1884 IPV6CP/. Mailing list comment from Bill Storer, 5-Jul-2006. 1886 o Section 5, Figure 10: Marked CHAP as "Optional - CHAP". 1888 o Section 5.1, Section 5.1.1, and Section 5.1.3: Minor typographical 1889 error correction and rewording of some sentences for grammar. 1891 o Section 5.1.1.1, Host Name AVP: Removed "for debugging purposes" 1892 and added that MAY be used to authenticate users. 1894 o Section 5.1.1.1, Framing Capabilities AVP: Swapped SHOULD and 1895 MUST. Mailing list comment from Bill Storer, 5-Jul-2006, text 1896 from Laurent Toutain. 1898 o Section 5.1.1.1, (Tx) Connect Speed: Correction: "but is *not* 1899 meaningful". 1901 o Section 5.1.1.2, Challenge and Challenge Response AVPs: Removed 1902 the last sentence of the first paragraph. Mailing list comment 1903 from Bill Storer, 5-Jul-2006, text from Laurent Toutain. 1905 o Section 5.1.2: Rewrote paragraph to use L2TPv2 HELLO messages and 1906 not LCP Echo Request and Reply messages to detect tunnel failure, 1907 as redundant in Softwires. Mailing list comment from Florent 1908 Parent, 10-Jul-2006, text from Bill Storer. 1910 o Section 5.2.1, first paragraph: Fixed PPP MTU calculation. 1911 Mailing list comment from Florent Parent, 10-Jul-2006. 1913 o Section 5.2.4.2: Rewrote to generalize the address assignment 1914 failure, to be an all-zeroes address or a protocol reject in 1915 response to the IPCP CONFREQ. Mailing list comment from Bill 1916 Storer, 5-Jul-2006, text from JF Tremblay. 1918 o Section 8, second paragraph: s/Tunnel-Medium /Tunnel-Type /. 1919 Mailing list comment from Bill Storer, 5-Jul-2006. 1921 o Section 8.1.2: Added usage of Framed-IP-Address attribute, and if 1922 not present then use the Tunnel-Client-Endpoint and Tunnel-Server- 1923 Endpoint attributes. Mailing list comment from Bill Storer, 1924 5-Jul-2006, text from JF Tremblay and Bill Storer. 1926 o Completed Section 8.2.2, Section 9.1, Section 9.2, and Section 10. 1928 Revision -00: 1930 o Initial revision. 1932 Authors' Addresses 1934 Bill Storer 1935 Cisco Systems 1936 170 W Tasman Dr 1937 San Jose, CA 95134 1938 USA 1940 Email: bstorer@cisco.com 1942 Carlos Pignataro (editor) 1943 Cisco Systems 1944 7200 Kit Creek Road 1945 PO Box 14987 1946 Research Triangle Park, NC 27709 1947 USA 1949 Email: cpignata@cisco.com 1951 Maria Alice Dos Santos 1952 Cisco Systems 1953 170 W Tasman Dr 1954 San Jose, CA 95134 1955 USA 1957 Email: mariados@cisco.com 1959 Bruno Stevant (editor) 1960 TELECOM Bretagne 1961 2 rue de la Chataigneraie CS17607 1962 Cesson Sevigne, 35576 1963 France 1965 Email: bruno.stevant@telecom-bretagne.eu 1967 Jean-Francois Tremblay 1968 Trellia Networks 1969 100, Alexis-Nihon, Suite 770 1970 Montreal, QC H4M 2P3 1971 Canada 1973 Email: jf@jftremblay.com 1975 Full Copyright Statement 1977 Copyright (C) The IETF Trust (2008). 1979 This document is subject to the rights, licenses and restrictions 1980 contained in BCP 78, and except as set forth therein, the authors 1981 retain all their rights. 1983 This document and the information contained herein are provided on an 1984 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1985 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1986 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1987 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1988 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1989 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1991 Intellectual Property 1993 The IETF takes no position regarding the validity or scope of any 1994 Intellectual Property Rights or other rights that might be claimed to 1995 pertain to the implementation or use of the technology described in 1996 this document or the extent to which any license under such rights 1997 might or might not be available; nor does it represent that it has 1998 made any independent effort to identify any such rights. Information 1999 on the procedures with respect to rights in RFC documents can be 2000 found in BCP 78 and BCP 79. 2002 Copies of IPR disclosures made to the IETF Secretariat and any 2003 assurances of licenses to be made available, or the result of an 2004 attempt made to obtain a general license or permission for the use of 2005 such proprietary rights by implementers or users of this 2006 specification can be obtained from the IETF on-line IPR repository at 2007 http://www.ietf.org/ipr. 2009 The IETF invites any interested party to bring to its attention any 2010 copyrights, patents or patent applications, or other proprietary 2011 rights that may cover technology that may be required to implement 2012 this standard. Please address the information to the IETF at 2013 ietf-ipr@ietf.org. 2015 Acknowledgment 2017 Funding for the RFC Editor function is provided by the IETF 2018 Administrative Support Activity (IASA).