idnits 2.17.1 draft-ietf-softwire-hs-framework-l2tpv2-06.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 1847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1858. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1865. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1871. 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 (August 15, 2007) is 6099 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) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2472 (Obsoleted by RFC 5072, RFC 5172) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (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-05 == Outdated reference: A later version (-09) exists of draft-ietf-softwire-security-requirements-03 == Outdated reference: A later version (-02) exists of draft-stevant-softwire-accounting-01 -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) Summary: 7 errors (**), 0 flaws (~~), 4 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: February 16, 2008 Cisco Systems 6 B. Stevant, Ed. 7 GET/ENST Bretagne 8 J. Tremblay 9 Trellia Networks 10 August 15, 2007 12 Softwires Hub & Spoke Deployment Framework with L2TPv2 13 draft-ietf-softwire-hs-framework-l2tpv2-06 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 February 16, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document describes the framework of the Softwire "Hub and Spoke" 47 solution with Layer 2 Tunneling Protocol (L2TPv2), and the 48 implementation details specified in this document should be followed 49 to achieve inter-operability 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 . . . . . . . . . . . . . . . . . . . . . . 6 59 2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7 60 2.1. Network Address Translation (NAT and NAPT) . . . . . . . . 7 61 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.4. Authentication, Authorization and Accounting . . . . . . . 7 64 2.5. Privacy, Integrity, and Replay Protection . . . . . . . . 8 65 2.6. Operations and Management (OAM) . . . . . . . . . . . . . 8 66 2.7. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 8 68 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 9 69 3.1. IPv6 over IPv4 Softwire with L2TPv2 . . . . . . . . . . . 9 70 3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 9 71 3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 10 72 3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 11 73 3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 12 74 3.2. IPv4 over IPv6 Softwire with L2TPv2 . . . . . . . . . . . 14 75 3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 14 76 3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 14 77 3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 15 78 3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 16 80 4. Standardisation Status . . . . . . . . . . . . . . . . . . . . 17 81 4.1. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 4.2. Securing the Softwire Transport . . . . . . . . . . . . . 18 83 4.3. Authentication Authorization Accounting . . . . . . . . . 18 84 4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 19 86 4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 19 87 4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 19 89 5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 19 90 5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 21 91 5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 22 92 5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 24 93 5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 25 94 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 25 95 5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 25 96 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 26 97 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 26 98 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 26 100 5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 26 101 5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 27 103 5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 27 104 5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 27 105 5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 106 5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28 107 5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 28 109 6. Considerations about the Address Provisioning Model . . . . . 28 110 6.1. Softwire Endpoints Addresses . . . . . . . . . . . . . . . 29 111 6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 29 112 6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 29 113 6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 29 114 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 29 115 6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 29 116 6.3. Possible scenarios . . . . . . . . . . . . . . . . . . . . 30 117 6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 30 118 6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 30 120 7. Considerations about Address Stability . . . . . . . . . . . . 31 122 8. Considerations about RADIUS Integration . . . . . . . . . . . 31 123 8.1. Softwires Endpoints . . . . . . . . . . . . . . . . . . . 31 124 8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 31 125 8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 32 126 8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 32 127 8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 32 128 8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 32 130 9. Considerations for Maintenance and Statistics . . . . . . . . 32 131 9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 32 132 9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 134 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 136 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 138 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 140 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 141 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 142 13.2. Informative References . . . . . . . . . . . . . . . . . . 35 144 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 37 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 147 Intellectual Property and Copyright Statements . . . . . . . . . . 44 149 1. Introduction 151 The Softwires Working Group has selected Layer Two Tunneling Protocol 152 version 2 (L2TPv2) as the phase 1 protocol to be deployed in the 153 Softwires "Hubs and Spokes" solution space. This document describes 154 the framework for the L2TPv2 "Hubs and Spokes" solution, and the 155 implementation details specified in this document should be followed 156 to achieve interoperability among different vendor implementations. 158 In the "Hubs and Spokes" solution space, a Softwire is established to 159 provide the home network with IPv4 connectivity across an IPv6-only 160 access network or IPv6 connectivity across an IPv4-only access 161 network. When L2TPv2 is used in the Softwire context, the voluntary 162 tunneling model applies. The Softwire Initiator (SI) at the home 163 network takes the role of the L2TP Access Concentrator (LAC) client 164 (initiating both the L2TP tunnel/session and PPP link) while the 165 Softwire Concentrator (SC) at the ISP takes the role of the L2TP 166 Network Server (LNS). Since L2TPv2 compulsory tunneling model does 167 not apply to Softwires, it should not be requested or honored. This 168 document identifies all the voluntary tunneling related L2TPv2 169 attributes that apply to Softwires and specifies the handling 170 mechanism for such attributes in order to avoid ambiguities in 171 implementations. This document also identifies the set of L2TPv2 172 attributes specific to compulsory tunneling model that do not apply 173 to Softwires and specifies the mechanism to ignore or nullify their 174 effect within the Softwires context. 176 The SI and SC must follow the L2TPv2 operations described in 177 [RFC2661] when performing Softwire establishment, tear-down and OAM. 178 With L2TPv2, a Softwire consists of an L2TPv2 Control Channel, a 179 single Session, and the PPP link negotiated over the Session. To 180 establish the Softwire, the SI first initiates an L2TPv2 Control 181 Channel to the SC which accepts the request and terminates the 182 Control Channel. L2TPv2 supports an optional mutual Control Channel 183 authentication which allows both SI and SC to validate each other's 184 identity at the initial phase of hand-shaking before proceeding with 185 Control Channel establishment. After the L2TPv2 Control Channel is 186 established between the SI and SC, the SI initiates an L2TPv2 Session 187 to the SC. Then the PPP/IP link is negotiated over the L2TPv2 188 Session between the SI and SC. After the PPP/IP link is established, 189 it acts as the Softwire between the SI and SC for tunneling IP 190 traffic of one Address Family across the access network of another 191 Address Family. 193 During the life of the Softwire, both SI and SC send L2TPv2 keepalive 194 HELLO messages to monitor the health of the Softwire and the peer 195 LCCE, and to potentially refresh the NAT/NAPT translation entry at 196 the CPE or at the other end of the access link. Optionally, LCP ECHO 197 messages can be used as keepalives for the same purposes. In the 198 event of keepalive timeout or administrative shutdown of the 199 Softwire, either SI or SC may tear down the Softwire by tearing down 200 the L2TPv2 Control Channel and Session as specified in [RFC2661]. 202 1.1. Abbreviations 204 LCCE L2TP Control Connection Endpoint (See [RFC3931]) 206 SC Softwire Concentrator, the node terminating the Softwire in 207 the service provider network (See [RFC4925]) 209 SI Softwire Initiator, the node initiating the Softwire within 210 the customer network (See [RFC4925]) 212 STH Softwire Transport Header, the outermost IP header of a 213 softwire (See [RFC4925]) 215 SPH Softwire Payload Header, the IP headers being carried within a 216 softwire (See [RFC4925]) 218 1.2. Requirements Language 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 222 document are to be interpreted as described in [RFC2119]. 224 1.3. Contributing Authors 226 Following is the complete list of contributors to this document. 228 Maria Alice Dos Santos 229 Carlos Pignataro 230 Bill Storer 231 Cisco Systems 232 Jean-Francois Tremblay 233 Trellia Networks 234 Laurent Toutain 235 Bruno Stevant 236 GET/ENST 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 have been 247 identified by the Softwire Problem Statement [RFC4925]. The 248 following section describes how L2TPv2 fulfills each of them. 250 2.1. Network Address Translation (NAT and NAPT) 252 A "Hubs and Spokes" Softwire must be able to traverse Network Address 253 Translation and Network Address Port Translation (NAT and NAPT) 254 devices [RFC3022] in case the scenario in question involves a non- 255 upgradable pre-existing IPv4 home gateway performing NAT/NAPT or some 256 carrier equipment at the other end of the access link performing NAT/ 257 NAPT. The L2TPv2 Softwire (i.e., Control Channel and Session) is 258 capable of NAT/NAPT traversal since L2TPv2 can run over UDP. 260 Since L2TPv2 does not "autodetect" NAT/NAPT along the path, L2TPv2 261 does not offer UDP bypass regardless of NAT/NAPT presence. Both NAT/ 262 NAPT "autodetect" and UDP bypass are optional requirements. 264 2.2. Scalability 266 In the "Hubs and Spokes" model, a carrier must be able to scale the 267 solution to millions of Softwire initiators by adding more hubs 268 (i.e., Softwire concentrators). L2TPv2 is a widely deployed protocol 269 in broadband services, and its scalability has been proven in 270 multiple large-scale IPv4 Virtual Private Network deployments which 271 scale up to millions of subscribers each. 273 2.3. Multicast 275 Multicast protocols simply run over L2TPv2 Softwires transparently 276 together with other regular IP traffic. 278 2.4. Authentication, Authorization and Accounting 280 L2TPv2 supports optional mutual Control Channel authentication and 281 leverages the optional mutual PPP per-session authentication. L2TPv2 282 is well integrated with AAA solutions (such as RADIUS) for both 283 authentication and authorization. Most L2TPv2 implementations 284 available in the market support logging of authentication and 285 authorization events. 287 L2TPv2 integration with RADIUS accounting (RADIUS Accounting 288 extension for tunnel [RFC2867]) allows the collection and reporting 289 of L2TPv2 Softwire usage statistics. 291 2.5. Privacy, Integrity, and Replay Protection 293 Since L2TPv2 runs over IP/UDP in the Softwire context, IPSec ESP can 294 be used in conjunction to provide per-packet authentication, 295 integrity, replay protection and confidentiality for both L2TPv2 296 control and data traffic [RFC3193] and [RFC3948]. 298 For Softwire deployments in which full payload security is not 299 required, the L2TPv2 built-in Control Channel authentication and the 300 inherited PPP authentication and PPP Encryption Control Protocol can 301 be considered. 303 2.6. Operations and Management (OAM) 305 L2TPv2 supports an optional in-band keepalive mechanism which injects 306 HELLO control messages after a specified period of time has elapsed 307 since the last data or control message was received on a tunnel. If 308 the HELLO control message is not reliably delivered, then the Control 309 Channel and its session will be torn down. In the Softwire context, 310 the L2TPv2 keepalive is used to monitor the connectivity status 311 between the SI and SC and/or as a refresh mechanism for any NAT/NAPT 312 translation entry along the access link. 314 LCP ECHO offers a similar mechanism to monitor the connectivity 315 status, as described in [RFC1661]. Softwires implementations SHOULD 316 use L2TPv2 Hello keepalives and in addition MAY use PPP LCP Echo 317 messages to ensure Dead End Detection and/or to refresh NAT/NAPT 318 translation entries. The combination of these two mechanisms can be 319 used as an optimization. 321 L2TPv2 MIB [RFC3371] supports the complete suite of management 322 operations such as configuration of Control Channel and Session, 323 polling of Control Channel and Session status and their traffic 324 statistics and notifications of Control Channel and Session UP/DOWN 325 events. 327 2.7. Encapsulations 329 L2TPv2 supports the following encapsulations: 331 o IPv6/PPP/L2TPv2/UDP/IPv4 333 o IPv4/PPP/L2TPv2/UDP/IPv6 335 o IPv4/PPP/L2TPv2/UDP/IPv4 337 o IPv6/PPP/L2TPv2/UDP/IPv6 338 Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not 339 support "autodetect" of NAT/NAPT. 341 3. Deployment Scenarios 343 For the "Hubs and Spokes" problem space, four scenarios have been 344 identified. In each of these four scenarios, different home 345 equipment plays the role of the Softwire Initiator. This section 346 elaborates each scenario with L2TPv2 as the Softwire protocol and 347 other possible protocols involved to complete the solution. This 348 section examines the four scenarios for both IPv6 over IPv4 and IPv4 349 over IPv6 encapsulations. 351 3.1. IPv6 over IPv4 Softwire with L2TPv2 353 The following subsections cover IPv6 connectivity across an IPv4-only 354 access network (STH) using a Softwire. 356 3.1.1. Host CPE as Softwire Initiator 358 The Softwire Initiator (SI) is the host CPE (directly connected to a 359 modem), which is dual-stack. There is no other gateway device. The 360 IPv4 traffic SHOULD NOT traverse the softwire. See Figure 1. 362 IPv6 or dual-stack IPv4-only dual-stack 363 |------------------||-----------------||----------| 365 I SC SI 366 N +-----+ +----------+ 367 T | | | v4/v6 | 368 E <==[ IPv6 ]....|v4/v6|....[IPv4~only]....| host CPE | 369 R [network] | | [ network ] | | 370 N | LNS | |LAC Client| 371 E +-----+ +----------+ 372 T _ _ _ _ _ _ _ _ _ 373 ()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic 374 PPP o L2TPv2 o UDP o IPv4 (SPH) 375 Softwire 377 <------------------> 378 IPV6CP: capable of /64 Intf-Id assignment or 379 uniqueness check 381 |------------------>/64 prefix 382 RA 383 |------------------>DNS, etc. 384 DHCPv6/v4 386 Figure 1: Host CPE as Softwire Initiator 388 In this scenario, IPV6CP negotiates IPv6 over PPP which also provides 389 the capability for the ISP to assign the 64-bit Interface-Identifier 390 to the host CPE or perform uniqueness validation for the two 391 Interface-IDs at the two PPP ends [RFC2472]. After IPv6 over PPP is 392 up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS 393 can assign a 64-bit global prefix to the host CPE via Router 394 Advertisement (RA) while other configuration options (such as DNS) 395 can be conveyed to the host CPE via DHCPv6/v4. 397 3.1.2. Router CPE as Softwire Initiator 399 The Softwire Initiator (SI) is the router CPE, which is a dual-stack 400 device. The IPv4 traffic SHOULD NOT traverse the Softwire. See 401 Figure 2. 403 IPv6 or dual-stack IPv4-only dual-stack 404 |------------------||-----------------||---------------------| 406 I SC SI 407 N +-----+ +----------+ 408 T | | | v4/v6 | +-----+ 409 E <==[ IPv6 ]....|v4/v6|....[IPv4~only]....| CPE |----|v4/v6| 410 R [network] | | [ network ] | | | host| 411 N | LNS | |LAC Client| +-----+ 412 E +-----+ +----------+ 413 T _ _ _ _ _ _ _ _ _ 414 ()_ _ _ _ _ _ _ _ _() <-------- IPv6 traffic 415 PPP o L2TPv2 o UDP o IPv4 (SPH) 416 Softwire 418 <------------------> 419 IPV6CP: capable of /64 Intf-Id assignment or 420 uniqueness check 422 |------------------>/64 prefix 423 RA 424 |------------------>/48 prefix, 425 DHCPv6 DNS, etc. 427 |------->/64 prefix 428 RA 429 |-------> DNS, etc. 430 DHCPv4/v6 432 Figure 2: Router CPE as Softwire Initiator 434 In this scenario, IPV6CP negotiates IPv6 over PPP which also provides 435 the capability for the ISP to assign the 64-bit Interface-Identifier 436 to the router CPE or perform uniqueness validation for the two 437 Interface-IDs at the two PPP ends [RFC2472]. After IPv6 over PPP is 438 up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS 439 can assign a 64-bit global prefix to the router CPE via Router 440 Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix 441 Delegation (e.g., delegating a 48-bit prefix to be used within the 442 home network) and convey other configuration options (such as DNS) to 443 the router CPE. 445 3.1.3. Host behind CPE as Softwire Initiator 447 The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack 448 host (behind the IPv4-only CPE), which acts as an IPv6 host CPE. The 449 IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 3. 451 IPv6 or dual-stack IPv4-only dual-stack 452 |------------------||----------------------------||----------| 454 I SC SI 455 N +-----+ +----------+ 456 T | | +-------+ | v4/v6 | 457 E <==[ IPv6 ]....|v4/v6|....[IPv4~only]....|v4-only|--| host | 458 R [network] | | [ network ] | CPE | | | 459 N | LNS | +-------+ |LAC Client| 460 E +-----+ +----------+ 461 T _ _ _ _ _ _ _ _ _ _ _ _ _ _ 462 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6 463 PPP o L2TPv2 o UDP o IPv4 traffic 464 Softwire (SPH) 466 <------------------------------> 467 IPV6CP: capable of /64 Intf-Id assignment or 468 uniqueness check 470 |------------------------------>/64 prefix 471 RA 472 |------------------------------>DNS, etc. 473 DHCPv4/v6 475 Figure 3: Host behind CPE as Softwire Initiator 477 In this scenario, IPV6CP negotiates IPv6 over PPP which also provides 478 the capability for the ISP to assign the 64-bit Interface-Identifier 479 to the host or perform uniqueness validation for the two Interface- 480 IDs at the two PPP ends [RFC2472]. After IPv6 over PPP is up, 481 Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can 482 assign a 64-bit global prefix to the host via Router Advertisement 483 (RA) while other configuration options (such as DNS) can be conveyed 484 to the host via DHCPv6/v4. 486 3.1.4. Router behind CPE as Softwire Initiator 488 The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack 489 device (behind the IPv4-only CPE) acting as an IPv6 CPE router inside 490 the home network. The IPv4 traffic SHOULD NOT traverse the Softwire. 491 See Figure 4. 493 IPv6 or dual-stack IPv4-only dual-stack 494 |------------------||-------------------------||-------------| 496 I SC SI 497 N +-----+ +----------+ 498 T | | +-------+ | v4/v6 | 499 E <==[ IPv6 ]....|v4/v6|..[IPv4~only]..|v4-only|---| router | 500 R [network] | | [ network ] | CPE | | | | 501 N | LNS | +-------+ | |LAC Client| 502 E +-----+ | +----------+ 503 T | 504 ---------+-----+ 505 |v4/v6| 506 | host| 507 _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ 508 ()_ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6 509 PPP o L2TPv2 o UDP o IPv4 traffic 510 Softwire (SPH) 512 <---------------------------> 513 IPV6CP: capable of /64 Intf-Id assignment or 514 uniqueness check 516 |--------------------------->/64 prefix 517 RA 518 |--------------------------->/48 prefix, 519 DHCPv6 DNS, etc. 521 |----> /64 522 RA prefix 523 |----> DNS, 524 DHCPv4/v6 etc. 526 Figure 4: Router behind CPE as Softwire Initiator 528 In this scenario, IPV6CP negotiates IPv6 over PPP which also provides 529 the capability for the ISP to assign the 64-bit Interface-Identifier 530 to the v4/v6 router or perform uniqueness validation for the two 531 Interface-IDs at the two PPP ends [RFC2472]. After IPv6 over PPP is 532 up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS 533 can assign a 64-bit global prefix to the v4/v6 router via Router 534 Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix 535 Delegation (e.g., delegating a 48-bit prefix to be used within the 536 home network) and convey other configuration options (such as DNS) to 537 the v4/v6 router. 539 3.2. IPv4 over IPv6 Softwire with L2TPv2 541 The following subsections cover IPv4 connectivity across an IPv6-only 542 access network (STH) using a Softwire. 544 3.2.1. Host CPE as Softwire Initiator 546 The Softwire Initiator (SI) is the host CPE (directly connected to a 547 modem), which is dual-stack. There is no other gateway device. The 548 IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 5. 550 IPv4 or dual-stack IPv6-only dual-stack 551 |------------------||-----------------||---------| 553 I SC SI 554 N +-----+ +----------+ 555 T | | | v4/v6 | 556 E <==[ IPv4 ]....|v4/v6|....[IPv6~only]....| host CPE | 557 R [network] | | [ network ] | | 558 N | LNS | |LAC Client| 559 E +-----+ +----------+ 560 T _ _ _ _ _ _ _ _ _ 561 ()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic 562 PPP o L2TPv2 o UDP o IPv6 (SPH) 563 Softwire 565 <------------------> 566 IPCP: capable of global IP assignment 567 and DNS, etc. 569 Figure 5: Host CPE as Softwire Initiator 571 In this scenario, IPCP negotiates IPv4 over PPP which also provides 572 the capability for the ISP to assign a global IPv4 address to the 573 host CPE. A global IPv4 address can also be assigned via DHCP. 574 Other configuration options (such as DNS) can be conveyed to the host 575 CPE via IPCP [RFC1877] or DHCP. 577 3.2.2. Router CPE as Softwire Initiator 579 IPv4 connectivity across an IPv6-only access network (STH). The 580 Softwire Initiator (SI) is the router CPE, which is a dual-stack 581 device. The IPv6 traffic SHOULD NOT traverse the Softwire. See 582 Figure 6. 584 IPv4 or dual-stack IPv6-only dual-stack Home 585 |------------------||-----------------||-------------------| 587 I SC SI 588 N +-----+ +----------+ 589 T | | | v4/v6 | +-----+ 590 E <==[ IPv4 ]....|v4/v6|....[IPv6~only]....| CPE |--|v4/v6| 591 R [network] | | [ network ] | | | host| 592 N | LNS | |LAC Client| +-----+ 593 E +-----+ +----------+ 594 T _ _ _ _ _ _ _ _ _ 595 ()_ _ _ _ _ _ _ _ _() <--------- IPv4 traffic 596 PPP o L2TPv2 o UDP o IPv6 (SPH) 597 Softwire 599 <------------------> 600 IPCP: capable of global IP assignment 601 and DNS, etc. 603 |------------------> 604 DHCPv4: prefix, mask, PD 606 private/ 607 |------> global 608 DHCP IP, DNS, 609 etc. 611 Figure 6: Router CPE as Softwire Initiator 613 In this scenario, IPCP negotiates IPv4 over PPP which also provides 614 the capability for the ISP to assign a global IPv4 address to the 615 router CPE. A global IPv4 address can also be assigned via DHCP. 616 Other configuration options (such as DNS) can be conveyed to the 617 router CPE via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation 618 for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used. 620 3.2.3. Host behind CPE as Softwire Initiator 622 IPv4 connectivity across an IPv6-only access network (STH). The CPE 623 is IPv6-only. The Softwire Initiator (SI) is a dual-stack host 624 (behind the IPv6 CPE), which acts as an IPv4 host CPE. The IPv6 625 traffic SHOULD NOT traverse the Softwire. See Figure 7. 627 IPv4 or dual-stack IPv6-only dual-stack 628 |------------------||----------------------------||----------| 630 I SC SI 631 N +-----+ +----------+ 632 T | | +-------+ | v4/v6 | 633 E <==[ IPv4 ]....|v4/v6|....[IPv6~only]....|v6-only|--| host | 634 R [network] | | [ network ] | CPE | | | 635 N | LNS | +-------+ |LAC Client| 636 E +-----+ +----------+ 637 T _ _ _ _ _ _ _ _ _ _ _ _ _ _ 638 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv4 639 PPP o L2TPv2 o UDP o IPv6 traffic 640 Softwire (SPH) 642 <------------------------------> 643 IPCP: capable of global IP assignment 644 and DNS, etc. 646 Figure 7: Host behind CPE as Softwire Initiator 648 In this scenario, IPCP negotiates IPv4 over PPP which also provides 649 the capability for the ISP to assign a global IPv4 address to the 650 host. A global IPv4 address can also be assigned via DHCP. Other 651 configuration options (such as DNS) can be conveyed to the host CPE 652 via IPCP [RFC1877] or DHCP. 654 3.2.4. Router behind CPE as Softwire Initiator 656 IPv4 connectivity across an IPv6-only access network (STH). The CPE 657 is IPv6-only. The Softwire Initiator (SI) is a dual-stack device 658 (behind the IPv6-only CPE) acting as an IPv4 CPE router inside the 659 home network. The IPv6 traffic SHOULD NOT traverse the Softwire. 660 See Figure 8. 662 IPv4 or dual-stack IPv6-only dual-stack 663 |------------------||-------------------------||------------| 665 I SC SI 666 N +-----+ +----------+ 667 T | | +-------+ | v4/v6 | 668 E <==[ IPv4 ]....|v4/v6|..[IPv6~only]..|v6-only|---| router | 669 R [network] | | [ network ] | CPE | | | | 670 N | LNS | +-------+ | |LAC Client| 671 E +-----+ | +----------+ 672 T | 673 --------+-----+ 674 |v4/v6| 675 | host| 676 _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ 677 ()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- IPv4 678 PPP o L2TPv2 o UDP o IPv4 traffic 679 Softwire (SPH) 681 <---------------------------> 682 IPCP: assigns global IP address and DNS, etc. 684 |---------------------------> 685 DHCPv4: prefix, mask, PD 687 private/ 688 |----> global 689 DHCP IP, DNS, 690 etc. 692 Figure 8: Router behind CPE as Softwire Initiator 694 In this scenario, IPCP negotiates IPv4 over PPP which also provides 695 the capability for the ISP to assign a global IPv4 address to the 696 v4/v6 router. A global IPv4 address can also be assigned via DHCP. 697 Other configuration options (such as DNS) can be conveyed to the 698 v4/v6 router via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation 699 for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used. 701 4. Standardisation Status 703 This section groups various Internet standards documents and other 704 publications used in Softwires. 706 4.1. L2TPv2 708 RFC 2661 "Layer Two Tunneling Protocol "L2TP"" [RFC2661]. 710 * For both IPv4 and IPv6 payloads (SPH), support is 711 complete. 713 * For both IPv4 and IPv6 transports (STH), support is 714 complete. 716 4.2. Securing the Softwire Transport 718 RFC 3193 "Securing L2TP using IPsec" [RFC3193]. 720 RFC 3948 "UDP Encapsulation of IPsec ESP Packets" [RFC3948]. 722 * IPSec supports both IPv4 and IPv6 transports. 724 4.3. Authentication Authorization Accounting 726 RFC 2865 "Remote Authentication Dial In User Service (RADIUS)" 727 [RFC2865]. 729 RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol 730 Support" [RFC2867]. 732 RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868]. 734 RFC 3162 "RADIUS and IPv6" [RFC3162]. 736 4.4. MIB 738 RFC 1471 "The Definitions of Managed Objects for the Link Control 739 Protocol of the Point-to-Point Protocol" [RFC1471]. 741 RFC 1473 "The Definitions of Managed Objects for the IP Network 742 Control Protocol of the Point-to-Point Protocol" 743 [RFC1473]. 745 RFC 3371 "Layer Two Tunneling Protocol "L2TP" Management 746 Information Base" [RFC3371]. 748 RFC 4087 "IP Tunnel MIB" [RFC4087]. 750 * Both IPv4 and IPv6 transports are supported. 752 4.5. Softwire Payload Related 754 4.5.1. For IPv6 Payloads 756 RFC 2461 "Neighbor Discovery for IP Version 6 (IPv6)" [RFC2461]. 758 RFC 2472 "IP Version 6 over PPP" [RFC2472]. 760 * See also [I-D.ietf-ipv6-over-ppp-v2]. 762 RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" 763 [RFC3315]. 765 RFC 3646 "DNS Configuration options for Dynamic Host Configuration 766 Protocol for IPv6 (DHCPv6)" [RFC3646]. 768 4.5.2. For IPv4 Payloads 770 RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)" 771 [RFC1332]. 773 RFC 1661 "The Point-to-Point Protocol (PPP)" [RFC1661]. 775 RFC 1877 "PPP Internet Protocol Control Protocol Extensions for 776 Name Server Addresses" [RFC1877]. 778 DHCP Subnet Allocation "Subnet Allocation Option". 780 * Work in progress, see [I-D.ietf-dhc-subnet-alloc]. 782 5. Softwire Establishment 784 A Softwire is established in three distinct steps (see Figure 9). 785 First an L2TPv2 tunnel with a single session is established from the 786 SI to the SC. Second a PPP session is established over the L2TPv2 787 session and the SI obtains an address. Third the SI optionally gets 788 other information through DHCP such as a delegated prefix and DNS 789 servers. 791 SC SI 792 | | 793 |<-------------L2TPv2------------>| Step 1 794 | | L2TPv2 Tunnel establishment 795 | | 796 |<-------------PPP--------------->| Step 2 797 |<----End Point Configuration---->| PPP and End Point 798 | | configuration 799 | | 800 |<------Router Configuration----->| Step 3 801 | | Additional configuration 802 | | (optional) 804 Figure 9: Steps for the Establishment of a Softwire 806 In the following diagram (see Figure 10), each of the three steps 807 required to establish a Softwire is described in detail. 809 SC SI 810 | | 811 | | Step 1 812 |<------------SCCRQ---------------| - 813 |-------------SCCRP-------------->| | 814 |<------------SCCCN---------------| | 815 |<------------ICRQ----------------| | L2TPv2 816 |-------------ICRP--------------->| | 817 |<------------ICCN----------------| - 818 | | 819 | | Step 2 820 |<-----Configuration-Request------| - 821 |------Configuration-Request----->| | PPP 822 |<-------Configuration-Ack--------| | LCP 823 |--------Configuration-Ack------->| - 824 | | 825 |-----------Challenge------------>| - PPP Authentication 826 |<----------Response--------------| | (Optional - CHAP) 827 |------------Success------------->| - 828 | | 829 |<-----Configuration-Request------| - 830 |------Configuration-Request----->| | PPP NCP 831 |<-------Configuration-Ack--------| | (IPV6CP or IPCP) 832 |--------Configuration-Ack------->| - 833 | | 834 |<------Router-Solicitation-------| - Neighbor Discovery 835 |-------Router-Advertisement----->| | (IPv6 only) 836 | | - 837 | | 838 | | Step3 839 |<-----------Solicit--------------| - 840 |-----------Advertise------------>| | DHCP 841 |<---------- Request--------------| | (Optional) 842 |-------------Reply-------------->| - 844 Figure 10: Detailed Steps in the Establishment of a Softwire 846 5.1. L2TPv2 Tunnel Setup 848 L2TPv2 [RFC2661] was originally designed to provide private network 849 access to end users connected to a public network. In the L2TPv2 850 model, the end user makes a connection to an L2TP Access Concentrator 851 (LAC). The LAC then initiates an L2TPv2 tunnel to an L2TP Network 852 Server (LNS). The LNS then transfers end user traffic between the 853 L2TPv2 tunnel and the private network. 855 In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI) 856 assumes the role of the LAC and the Softwire Concentrator assumes the 857 role of the LNS. 859 In the Softwire model, an L2TPv2 packet MUST be carried over UDP. 860 The underlying version of the IP protocol may be IPv4 or IPv6, 861 depending on the Softwires scenario. 863 In the following sections, the term "Tunnel" follows the definition 864 from [RFC2661], namely: "The Tunnel consists of a Control Connection 865 and zero or more L2TP Sessions". 867 5.1.1. Tunnel Establishment 869 Figure 11 describes the messages exchanged and AVPs used to establish 870 a tunnel between an SI (LAC) and an SC (LNS). The messages and AVPs 871 described here are only a subset of those defined in [RFC2661]. This 872 is because Softwires uses only a subset of the L2TPv2 functionality. 873 The subset of L2TP Control Connection Management AVPs that is 874 applicable to Softwires is grouped into Mandatory AVPs and Optional 875 AVPs (see Figure 11). Note that in the Softwires environment, the SI 876 always initiates the tunnel. L2TPv2 attributes SHOULD NOT be hidden. 878 SCCRQ 879 Mandatory AVP 880 Message Type 881 Protocol Version 882 Host Name 883 Framing Capabilities 884 Assigned Tunnel ID 885 Optional AVP: 886 Receive Window Size 887 Firmware Revision 888 Vendor Name 889 Challenge 891 SCCRP 892 Mandatory AVP: 893 Message Type 894 Protocol Version 895 Framing Capabilities 896 Host Name 897 Assigned Tunnel ID 898 Optional AVP: 899 Firmware Revision 900 Vendor Name 901 Receive Window Size 902 Challenge Response 903 Challenge 905 SCCCN 906 Mandatory AVP: 907 Message Type 908 Optional AVP: 909 Challenge Response 911 Figure 11: Control Connection Establishment 913 In L2TPv2, the tunnel between an LAC and LNS may carry the data of 914 multiple users. Each of these user's is represented by an L2TPv2 915 session within the tunnel. In the Softwires environment, the tunnel 916 carries the information of a single user. So, there is only one 917 L2TPv2 session per tunnel. Figure 12 describes the messages 918 exchanged and the AVPs used to establish a session between an SI 919 (LAC) and an SC (LNS). The messages and AVPs described here are only 920 a subset of those defined in [RFC2661]. This is because Softwires 921 uses only a subset of the L2TPv2 functionality. The subset of L2TP 922 Call Management AVPs that is applicable to Softwires is grouped into 923 Mandatory AVPs and Optional AVPs (see Figure 12). Note that in the 924 Softwires environment, the SI always initiates the session. No 925 outgoing or analog calls are permitted. L2TPv2 attributes SHOULD NOT 926 be hidden. 928 ICRQ 929 Mandatory AVP: 930 Message Type 931 Assigned Session ID 932 Call Serial Number 934 ICRP 935 Mandatory AVP: 936 Message Type 937 Assigned Session ID 939 ICCN 940 Mandatory AVP: 941 Message Type 942 (Tx) Connect Speed 943 Framing Type 945 Figure 12: Session Establishment 947 5.1.1.1. AVPs Required for Softwires 949 This section prescribes specific values for AVPs used in the 950 Softwires context that are Mandatory. 952 Host Name AVP 954 This AVP is mandatory and is present in SCCRQ and SCCRP messages. 955 This AVP may be used to authenticate users, in which case it would 956 contain a user identification. If this AVP is not used to 957 authenticate users, it may be used for logging purposes. 959 Framing Capabilities AVP 961 Synchronous bit SHOULD be set to 1 and Asynchronous bit to 1. 962 This AVP SHOULD be ignored by the receiver. 964 Framing Type AVP 966 Synchronous bit SHOULD be set to 1 and Asynchronous bit to 0. 967 This AVP SHOULD be ignored by the receiver. 969 (Tx) Connect Speed 971 (Tx) Connect Speed is a mandatory AVP but is not meaningful in the 972 Softwires context. It SHOULD be left to 0 and ignored by the 973 receiver. 975 Message Type AVP, Protocol Version AVP, Assigned Tunnel ID AVP, Call 976 Serial Number AVP, and Assigned Session ID AVP 978 As defined in [RFC2661] 980 5.1.1.2. AVPs Optional for Softwires 982 This section prescribes specific values for AVPs used in the 983 Softwires context that are Optional. 985 Challenge AVP and Challenge Response AVP 987 These AVPs are not required, but are necessary to implement tunnel 988 authentication. Since tunnel authentication happens at the 989 beginning of L2TPv2 tunnel creation, it can be helpful in 990 preventing DoS attacks. 992 Receive Window Size AVP, Firmware Revision AVP, and Vendor Name AVP 994 As defined in [RFC2661] 996 5.1.1.3. AVPs not Relevant for Softwires 998 L2TPv2 specifies numerous AVPs that, while allowed for a given 999 command, are irrelevant to a Softwires. Softwires implementations 1000 SHOULD NOT send these AVPs. However, they SHOULD ignore them when 1001 they are received. This will make it easier to create Softwires 1002 applications on top of existing L2TPv2 implementations. 1004 5.1.2. Tunnel Maintenance 1006 Periodically, the SI MUST transmit a message to the SC to maintain 1007 NAT/NAPT contexts and detect tunnel failure. The L2TPv2 HELLO 1008 message provides a simple, low overhead method of doing this. 1010 The default values specified in [RFC2661] for L2TPv2 HELLO messages 1011 could result in a dead end detection time of 83 seconds. Although 1012 these retransmission timers and counters SHOULD be configurable (see 1013 Section 5.8 of [RFC2661]), these values may not be adapted for all 1014 situations, where a quicker dead end detection is required, or where 1015 NAT/NAPT context needs to be refreshed more frequently. In such 1016 cases, the SI MAY use, in combination with L2TPv2 HELLO, LCP ECHO 1017 messages (Echo-Request and Echo-Reply codes) described in [RFC1661]. 1018 When used, LCP ECHO messages SHOULD have a re-emission timer lower 1019 than the value for L2TPv2 HELLO hello messages. The default value 1020 recommended in Section 6.5 of [RFC2661] for the HELLO message 1021 retransmission interval is 60 seconds. When used, a set of suggested 1022 values (included here only for guidance) for the LCP ECHO message 1023 request interval is a default of 30 seconds, a minimum of 10 seconds, 1024 and a maximum of the lesser of the configured L2TPv2 HELLO 1025 retransmisison interval and 60 seconds. 1027 5.1.3. Tunnel Teardown 1029 Either the SI or SC can teardown the session and tunnel. This is 1030 done as specified in [RFC2661]. There is no action specific to 1031 Softwires in this case. 1033 5.2. PPP Connection 1035 5.2.1. MTU 1037 The MTU of the PPP link SHOULD be the link MTU minus the size of the 1038 IP, UDP, L2TPv2, and PPP headers together. On an IPv4 link with an 1039 MTU equal to 1500 bytes, this could tipically mean a PPP MTU of 1460 1040 bytes. When the link is managed by IPsec, this MTU should be lowered 1041 to take into account the ESP encapsulation (see 1042 [I-D.ietf-softwire-security-requirements]). The value for the MTU 1043 may also vary according to the size of the L2TP header, as defined by 1044 the leading bits of the L2TP message header (see [RFC2661]). 1045 Additionally, see [RFC4623] for a detailed discussion of 1046 fragmentation issues. 1048 5.2.2. LCP 1050 Once the L2TPv2 session is established, the SI and SC initiate the 1051 PPP connection by negotiating LCP as described in [RFC1661]. The 1052 Address-and-Control-Field-Compression configuration option (ACFC) 1053 [RFC1661] SHOULD be rejected. 1055 5.2.3. Authentication 1057 After completing LCP negotiation, the SI and SC may optionally 1058 perform authentication. If authentication is chosen, CHAP [RFC1994] 1059 authentication MUST be supported by both the Softwire Initiator and 1060 Softwire Concentrator. Other authentication methods such as MS- 1061 CHAPv1 [RFC2433], and EAP [RFC3748] MAY be supported. 1063 A detailed discussion of Softwires security is contained in 1064 [I-D.ietf-softwire-security-requirements]. 1066 5.2.4. IPCP 1068 5.2.4.1. IPV6CP 1070 In the IPv6 over IPv4 scenarios (see Section 3.1), after the 1071 authentication phase, the Softwire Initiator MUST negotiate IPV6CP as 1072 defined in [RFC2472]. IPV6CP provides a way to negotiate a unique 1073 64-bit Interface-Identifier to be used for the address 1074 autoconfiguration at the local end of the link. 1076 5.2.4.2. IPv4CP 1078 In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire 1079 Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain 1080 an IPv4 address from the SC. IPCP may also be used to obtain DNS 1081 information as described in [RFC1877]. 1083 5.3. Global IPv6 Address Assignement to Endpoints 1085 In several scenarios defined in Section 3, Global IPv6 addresses are 1086 expected to be allocated to Softwires end points. Since IPV6CP only 1087 provide Link-Local addresses (see [RFC2472]), IPv6 Neighbor Discovery 1088 [RFC2462] or DHCPv6 [RFC3315] SHOULD be used to configure these 1089 addresses. 1091 The Softwire Initiator of an IPv6 Softwire MUST send a Router 1092 Solicitation message to the Softwire Concentrator after IPV6CP is 1093 completed. The Softwire Concentrator MUST answer with a Router 1094 Advertisement. This message MUST contains the global IPv6 prefix of 1095 the PPP link if Neighbor discovery is used to configure addresses of 1096 Softwire end points. 1098 If DHCPv6 is available for address delegation, the M bits of the 1099 Router Advertisement SHOULD be set. The Softwire Initiator MUST then 1100 send a DHCPv6 Request to configure the address of the Softwire 1101 endpoint. 1103 Duplicate Address Detection ([I-D.ietf-ipv6-2461bis]) MUST be 1104 performed on the Softwire in both cases. 1106 5.4. DHCP 1108 The Softwire Initiator MAY use DHCP to get additional information 1109 such as delegated prefix and DNS servers. If the SI supports DHCP, 1110 it SHOULD send a Solicit message to verify if more information is 1111 available. 1113 When delegating an IPv4 prefix to the SI, the SC SHOULD inject a 1114 route for this prefix in the IPv4 routing table in order to forward 1115 the traffic to the relevant Softwire. 1117 5.4.1. DHCPv6 1119 If an SI establishing an IPv6 Softwire acts as a router (i.e., in the 1120 scenarios in Section 3.1.2 and Section 3.1.4) it MUST include the 1121 IA_PD option [RFC3633] in the DHCPv6 Solicit message [RFC3315] in 1122 order to request an IPv6 prefix. 1124 When delegating an IPv6 prefix to the SI, the SC SHOULD inject a 1125 route for this prefix in the IPv4 routing table in order to forward 1126 the traffic to the relevant Softwire. 1128 5.4.2. DHCPv4 1130 An SI establishing an IPv4 Softwire MAY send a DHCP request 1131 containing the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc]. 1132 This practice is not common but may be used to connect IPv4 subnets 1133 using Softwires, as defined in Section 3.2.2 and Section 3.2.4. 1135 One Subnet-Request suboption MUST be configured with the 'h' bit set 1136 to '1', as the SI is expected to perform the DHCP server function. 1137 The 'i' bit of the Subnet-Request suboption SHOULD be set to '0' the 1138 first time a prefix is requested and to '1' on subsequent requests, 1139 if a prefix has been allocated. The Prefix length suboption SHOULD 1140 be 0 by default. If the SI is configured to support only specific 1141 prefix lengths, it SHOULD specify the longest (smallest) prefix 1142 length it supports. 1144 If the SI was previously assigned a prefix from that same SC, it 1145 SHOULD include the Subnet Information suboption with the prefix it 1146 was previously assigned. The 'c' and 's' bits of the suboption 1147 SHOULD be set to '0'. 1149 6. Considerations about the Address Provisioning Model 1151 This section describes how a Softwire Concentrator may manage 1152 delegated addresses for Softwire endpoints and for subnets behind the 1153 Softwire Initiator. One common practice is to aggregate endpoints 1154 addresses and delegated prefixes into one prefix routed to the SC. 1155 The main benefit is to ease the routing scheme by isolating on the SC 1156 succeeding route injections (when delegating new prefixes for SI). 1158 6.1. Softwire Endpoints Addresses 1160 6.1.1. IPv6 1162 A Softwire Concentrator should provide globally routable addresses to 1163 Softwire endpoints. Other types of addresses such as Unique Local 1164 Addresses [RFC4193] may be used to address Softwire end points in a 1165 private network with no global connectivity. A single /64 should be 1166 assigned to the Softwire to address both Softwire endpoints. 1168 Global or ULA addresses must be assigned to endpoints when the 1169 scenario "Host CPE as Softwire Initiator" (described in 1170 Section 3.1.1) is considered to be deployed. For other scenarios, 1171 this may be optional and link local addresses should be used. 1173 6.1.2. IPv4 1175 A Softwire Concentrator may provide either globally routable or 1176 private IPv4 addresses. When using IPv4 private addresses [RFC1918] 1177 on the endpoints, it is not recommended to delegate an IPv4 private 1178 prefix to the SI, as it can lead to a nested-NAT situations. 1180 The endpoints of the PPP link use host addresses (i.e., /32), 1181 negotiated using IPCP. 1183 6.2. Delegated Prefixes 1185 6.2.1. IPv6 Prefixes 1187 Delegated IPv6 should be of global scope if the IPv6 addresses 1188 assigned to endpoints are global. Using ULA addresses is not 1189 recommended when the subnet is connected to the global IPv6 Internet. 1190 When using ULA IPv6 address for endpoint, the delegated IPv6 prefix 1191 may be either of Global or ULA scope. 1193 Delegated IPv6 prefixes are between /48 and /64 in length. When an 1194 SI receives a prefix shorter than 64, it can assign different /64 1195 prefixes to each of its interfaces. An SI receiving a single /64 is 1196 expected to perform bridging if more than one interface are available 1197 (wired and wireless for example). 1199 6.2.2. IPv4 Prefixes 1201 Delegated IPv4 prefixes should be routable within the address space 1202 used by assigned IPv4 addresses. Delegate non-routable IPv4 prefixes 1203 (i.e. private IPv4 prefix over public IPv4 addresses or another class 1204 of private IPv4 addresses) is not recommended as a practice for 1205 provisioning and address translation should be considered in these 1206 cases. The prefix length is between /8 and /30. 1208 6.3. Possible scenarios 1210 This section summarizes the differents scenarios for address 1211 provisioning with the considerations given in the previous sections. 1213 6.3.1. Scenarios for IPv6 1215 This table describes the possible combination of IPv6 address scope 1216 for endpoints and delegated prefixes. 1218 +------------------+-----------------------+------------------------+ 1219 | Endpoint IPv6 | Delegated Global IPv6 | Delegated ULA IPv6 | 1220 | Address | Prefix | Prefix | 1221 +------------------+-----------------------+------------------------+ 1222 | Link Local | Possible | Possible | 1223 | | | | 1224 | ULA | Possible | Possible | 1225 | | | | 1226 | Global | Possible | Possible, but Not | 1227 | | | Recommended | 1228 +------------------+-----------------------+------------------------+ 1230 Table 1: Scenarios for IPv6 1232 6.3.2. Scenarios for IPv4 1234 This table describes the possible combination of IPv4 address scope 1235 for endpoints and delegated prefixes. 1237 +-------------+-----------------+-----------------------------------+ 1238 | Endpoint | Delegated | Delegated Private IPv4 Prefix | 1239 | IPv4 | Public IPv4 | | 1240 | Address | Prefix | | 1241 +-------------+-----------------+-----------------------------------+ 1242 | Private | Possible | Possible, but Not Recommended | 1243 | IPv4 | | when using NAT (cf. | 1244 | | | Section 6.1.2) | 1245 | | | | 1246 | Public IPv4 | Possible | Possible, but NAT usage is | 1247 | | | recommended (cf. Section 6.2.2) | 1248 +-------------+-----------------+-----------------------------------+ 1250 Table 2: Scenarios for IPv4 1252 7. Considerations about Address Stability 1254 A Softwire can provide stable addresses even if the underlying 1255 addressing scheme changes, by opposition to automatic tunneling. A 1256 Softwire Concentrator should always provide the same address and 1257 prefix to a reconnecting user. However, if the goal of the Softwire 1258 service is to provide a temporary address for a roaming user, it may 1259 be provisioned to provide only a temporary address. 1261 The address and prefix are expected to change when reconnecting to a 1262 different Softwire Concentrator. However an organization providing a 1263 Softwire service may provide the same address and prefix across 1264 different Softwire Concentrators at the cost of a more fragmented 1265 routing table. The routing fragmentation issue may be limited if the 1266 prefixes are aggregated in a location topologically close to the SC. 1267 This would be the case for example if several SCs are put in parallel 1268 for load-balancing purpose. 1270 8. Considerations about RADIUS Integration 1272 The Softwire Concentrator is expected to act as a client to a AAA 1273 server, for example a RADIUS server. During the PPP authentication 1274 phase, the RADIUS server may return additional informations in the 1275 form of attributes in the Access Accept message. 1277 The Softwire Concentrator may include the Tunnel-Type and Tunnel- 1278 Medium-Type attributes [RFC2868] in the Access Request messages to 1279 provide a hint of the type of Softwire being configured. 1281 8.1. Softwires Endpoints 1283 8.1.1. IPv6 Softwires 1285 If the RADIUS server includes a Framed-Interface-Id attribute 1286 [RFC3162], the Softwire Concentrator must send it to the Softwire 1287 Initiator in the Interface-Identifier field of its IPV6CP 1288 Configuration Request message. 1290 If the Framed-IPv6-Prefix attribute is mentioned [RFC3162], that 1291 prefix must be used in the router advertisements sent to the SI. If 1292 Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC 1293 must choose a prefix with that pool to send RAs. 1295 If none of the attributes above are included but the AAA server 1296 returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint 1297 attributes [RFC2868] with the correct address family, these must be 1298 used in the IPV6CP Interface-Identifier and for the router 1299 advertisements. 1301 8.1.2. IPv4 Softwires 1303 If the Framed-IP-Address attribute [RFC2865] is present, the Softwire 1304 Concentrator must provide that address to the Softwire Initiator 1305 during IPCP address negotiation. That is, when the Softwire 1306 Initiator requests an IP address from the Softwire Concentrator, the 1307 address provided should be the Framed-IP-Address. 1309 If the Framed-IP-Address attribute is not present and the Tunnel- 1310 Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are 1311 present and of the correct address family, these should be used in 1312 the IPCP IP-Address configuration option. 1314 8.2. Delegated Prefixes 1316 8.2.1. IPv6 Prefixes 1318 If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the 1319 RADIUS Access Accept message, it must be used by the Softwire 1320 Concentrator for the delegation of the IPv6 prefix. Since the prefix 1321 delegation is performed by DHCPv6 and the attribute is linked to a 1322 username, the SC must associate the DHCP Unique Identifier (DUID) of 1323 a DHCPv6 request to the tunnel it came from and its user. 1325 Interaction between RADIUS, PPP and DHCPv6 server may follow the 1326 mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. During the 1327 Softwire authentication phase, PPP collects the RADIUS attributes for 1328 the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is 1329 assigned to the Softwire. The DHCPv6 relay fills in these attributes 1330 in the Relay agent RADIUS Attribute Option (RRAO) DHCPv6 option, 1331 before forwarding the DHCPv6 requests to the DHCPv6 server. 1333 8.2.2. IPv4 Prefixes 1335 The combination of the Framed-IP-Address and Framed-IP-Netmask 1336 attributes [RFC2865] may be used by the Softwire Concentrator to 1337 delegate an IPv4 prefix to the Softwire Initiator. 1339 9. Considerations for Maintenance and Statistics 1341 9.1. RADIUS Accounting 1343 RADIUS Accounting for L2TP and PPP are documented (see Section 4.3). 1345 When deploying Softwires solutions, operators may experience 1346 difficulties to differentiate the address family of the traffic 1347 reported in accounting information from RADIUS. This problem and 1348 some potential solutions are described in 1349 [I-D.stevant-softwire-accounting]. 1351 9.2. MIBs 1353 MIB support for L2TPv2 and PPP are documented (see Section 4.4). 1354 Also see [RFC4293]. 1356 10. Security Considerations 1358 A detailed discussion of Softwires security is contained in 1359 [I-D.ietf-softwire-security-requirements]. 1361 The L2TPv2 Softwires solution provides the following tools for 1362 security: 1364 o IPsec [RFC4301] with IKEv2 [RFC4306] provides the highest level of 1365 security. [RFC3193] describes interaction between IPsec and 1366 L2TPv2. 1368 o PPP CHAP [RFC1994] provides basic user authentication. 1370 o L2TP Tunnel Authentication [RFC2661] provides authentication at 1371 tunnel setup. It may be used to limit DoS attacks by 1372 authenticating the tunnel before L2TP session and PPP resources 1373 are allocated. 1375 11. IANA Considerations 1377 This document creates no new requirements on IANA namespaces 1378 [RFC2434]. 1380 12. Acknowledgements 1382 The authors would like to acknowledge the following contributors who 1383 provided helpful input on this document: Florent Parent, Jordi Palet 1384 Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, and 1385 Francis Dupont. 1387 The authors would also like to acknowledge the participants in the 1388 Softwires interim meetings held in Hong Kong, China and Barcelona, 1389 Spain. The minutes for the interim meeting at the China University - 1390 Hong Kong (February 23-24, 2006) are at 1391 . The 1392 minutes for the interim meeting at Polytechnic University of 1393 Catalonia - Barcelona (September 14-15, 2006) are reachable at . 1396 13. References 1398 13.1. Normative References 1400 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 1401 (IPCP)", RFC 1332, May 1992. 1403 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1404 RFC 1661, July 1994. 1406 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1407 E. Lear, "Address Allocation for Private Internets", 1408 BCP 5, RFC 1918, February 1996. 1410 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1411 Protocol (CHAP)", RFC 1994, August 1996. 1413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1414 Requirement Levels", BCP 14, RFC 2119, March 1997. 1416 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1417 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1418 October 1998. 1420 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1421 Autoconfiguration", RFC 2462, December 1998. 1423 [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", 1424 RFC 2472, December 1998. 1426 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1427 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1428 RFC 2661, August 1999. 1430 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1431 "Remote Authentication Dial In User Service (RADIUS)", 1432 RFC 2865, June 2000. 1434 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1435 RFC 3162, August 2001. 1437 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 1438 "Securing L2TP using IPsec", RFC 3193, November 2001. 1440 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1441 and M. Carney, "Dynamic Host Configuration Protocol for 1442 IPv6 (DHCPv6)", RFC 3315, July 2003. 1444 [RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two 1445 Tunneling Protocol "L2TP" Management Information Base", 1446 RFC 3371, August 2002. 1448 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1449 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1450 December 2003. 1452 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1453 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1454 RFC 3948, January 2005. 1456 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1457 Internet Protocol", RFC 4301, December 2005. 1459 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1460 RFC 4306, December 2005. 1462 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1463 Attribute", RFC 4818, April 2007. 1465 13.2. Informative References 1467 [I-D.ietf-dhc-subnet-alloc] 1468 Johnson, R., "Subnet Allocation Option", 1469 draft-ietf-dhc-subnet-alloc-05 (work in progress), 1470 June 2007. 1472 [I-D.ietf-dhc-v6-relay-radius] 1473 Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option", 1474 draft-ietf-dhc-v6-relay-radius-02 (work in progress), 1475 February 2006. 1477 [I-D.ietf-ipv6-2461bis] 1478 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 1479 draft-ietf-ipv6-2461bis-11 (work in progress), March 2007. 1481 [I-D.ietf-ipv6-over-ppp-v2] 1482 Varada, S., "IP Version 6 over PPP", 1483 draft-ietf-ipv6-over-ppp-v2-03 (work in progress), 1484 May 2007. 1486 [I-D.ietf-softwire-security-requirements] 1487 Yamamoto, S., "Softwire Security Analysis and 1488 Requirements", 1489 draft-ietf-softwire-security-requirements-03 (work in 1490 progress), July 2007. 1492 [I-D.stevant-softwire-accounting] 1493 Stevant, B., "Accounting on Softwires", 1494 draft-stevant-softwire-accounting-01 (work in progress), 1495 October 2006. 1497 [RFC1471] Kastenholz, F., "The Definitions of Managed Objects for 1498 the Link Control Protocol of the Point-to-Point Protocol", 1499 RFC 1471, June 1993. 1501 [RFC1473] Kastenholz, F., "The Definitions of Managed Objects for 1502 the IP Network Control Protocol of the Point-to-Point 1503 Protocol", RFC 1473, June 1993. 1505 [RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control 1506 Protocol Extensions for Name Server Addresses", RFC 1877, 1507 December 1995. 1509 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 1510 RFC 2433, October 1998. 1512 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1513 Discovery for IP Version 6 (IPv6)", RFC 2461, 1514 December 1998. 1516 [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting 1517 Modifications for Tunnel Protocol Support", RFC 2867, 1518 June 2000. 1520 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, 1521 M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1522 Support", RFC 2868, June 2000. 1524 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1525 Address Translator (Traditional NAT)", RFC 3022, 1526 January 2001. 1528 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1529 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1530 December 2003. 1532 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1533 Levkowetz, "Extensible Authentication Protocol (EAP)", 1534 RFC 3748, June 2004. 1536 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 1537 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1539 [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005. 1541 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1542 Addresses", RFC 4193, October 2005. 1544 [RFC4293] Routhier, S., "Management Information Base for the 1545 Internet Protocol (IP)", RFC 4293, April 2006. 1547 [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- 1548 Edge (PWE3) Fragmentation and Reassembly", RFC 4623, 1549 August 2006. 1551 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 1552 Problem Statement", RFC 4925, July 2007. 1554 Appendix A. Revision History 1556 [Note to RFC Editor: please remove this entire appendix, and the 1557 corresponding entries in the table of contents, prior to 1558 publication.] 1560 Changes between -05 and -06: 1562 o Swapped Section 4.1 and Section 4.2. Renamed Section 4.2 to 1563 "Securing the Softwire Transport". 1565 o In Section 5.2.1, added a mention that the MTU should be lower 1566 that 1460 when using IPsec. 1568 o In Section 10, added pointers to [RFC4301] and [RFC4306]. 1570 Changes between -04 and -05: 1572 o Replaced "documentation" with "logging purposes" in 1573 Section 5.1.1.1. 1575 o Added suggested values (only as guidance) for Keepalives in 1576 Section 5.1.2. 1578 Changes between -03 and -04: 1580 o Added missing references to [RFC4087], [RFC2461], and [RFC3646], 1581 moved [RFC4623] to Informative. 1583 o Rephrasing in Section 6.2.2. Added pointers Section 6.1.2 and 1584 Section 6.2.2 in Table 2. 1586 o Added citations (and corresponding references) to [RFC1471] and 1587 [RFC1473] in Section 4.4, since Section 9.2 explicitly mentions: 1588 "MIB support for L2TPv2 and PPP are documented." 1590 o Fixed some RFC2119 keywords in Section 3.1.1, Section 3.1.2, 1591 Section 3.1.3, Section 3.1.4, Section 3.2.1, Section 3.2.2, 1592 Section 3.2.3, Section 3.2.4, Section 5.1.1.3, Section 5.4.2, and 1593 Section 8.1.1. 1595 o Added [RFC2868] to Section 4.3, and added missing citations to 1596 Section 4. 1598 o Added missing "Optional AVP" to Figure 11. 1600 o Updated the text in Section 6.2.2. 1602 o Added some clarifying sentences in Section 5.1.1, and completed 1603 Section 5.1.1.1 and Section 5.1.1.2. 1605 o Added an Informative reference to [RFC3022] for NAT/NAPT. 1607 o Corrected reference to [RFC1661] in Section 5.2.2, removed 1608 reference and citation to RFC1662. 1610 o Updated references, Delegated-IPv6-Prefix became [RFC4818] moved 1611 to Normative. 1613 o Added new address and email for J.F. Tremblay. 1615 o Added an acknowledgement to the participants, and pointer to the 1616 minutes, for the Barcelona interim meeting. 1618 o Moved the Softwire Problem Statement reference [RFC4925] to 1619 Informative. 1621 o Some additional purely editorial changes. 1623 Changes between -02 and -03: 1625 o Boiler changes in support of RFC 4748. 1627 o Added text about L2TPv2 HELLO and LCP ECHO usage in Section 1, 1628 Section 2.6 and Section 5.1.2. 1630 o Moved some downref to Informative ([RFC1877], [RFC2433], 1631 [RFC2867], [RFC2868], and [RFC3748]), and moved CHAP reference to 1632 Normative ([RFC1994]). 1634 o Removed the mention and citation for PAP authentication. 1636 Changes between -01 and -02: 1638 o Renamed all "Best Current Practices" sections as 1639 "Recommendations". See for example Section 1.4. 1641 o Moved Provisioning in Section 6. Removed intro text to new 1642 Section 7. 1644 o Removed all normative language from Section 6, Section 7, 1645 Section 8, and Section 9. 1647 o Removed empty sections "Implementation Status", and "Open Issues". 1649 o Fixed "Phase 0" in Section 1. 1651 o Small changes to Section 3.1. 1653 o Change L2TP -> L2TPv2 in some sections, including Section 6. 1655 o Small additions and typo fixes in Section 5.1.1.1 and 1656 Section 5.1.1.2. 1658 o Retitled Section 8 and Section 8.1, changed AAA -> RADIUS. 1660 o New paragraph in Section 9.1. 1662 o New paragraph in Section 8.2.1, including a pointer to 1663 [I-D.ietf-dhc-v6-relay-radius]. 1665 o Moved last paragraph to start of Section 10. 1667 o Moved some references from Normative to Informative. 1669 o Label the steps in Figure 9 and Figure 10. 1671 o Reword paragraph of Section 5.1. 1673 o Describe more messages than flows in Figure 11 and Figure 12. 1675 o Add text about Session Establishment between Figure 11 and 1676 Figure 12. 1678 o Section 5.1.1.1 and Section 5.1.1.2: Updates on Hostname AVP, 1679 Framing Capabilities AVP, Framing Type AVP, Connect Speed AVP and 1680 Challenge and Challenge Response AVPs. 1682 o Retitled Section 5.1.1.3. 1684 o Updates on the use of L2TP HELLO versus LCP, delay for Dead-End 1685 peer detection, and allow LCP. 1687 o Rewording in Section 5.1.3. 1689 o Section 5.2.1: Add a pointer to [RFC4623] and small updates. 1691 o Clarifications on PFC and ACFC, remove Figure 13. 1693 o Section 5.2.3: make references to RFCs for PAP, CHAP, etc. 1695 o Rewordings in Section 5.2.4.1 and Section 5.2.4.2. 1697 o Added Informative references to [RFC4623], [RFC1661], [RFC2433], 1698 and [RFC3748]. 1700 o Renamed the title and added more details on Section 5.3 and IPv6 1701 ND, including a pointer to [I-D.ietf-ipv6-2461bis]. 1703 o Added text in Section 5.4 about IPv4 PD is non-trivial and non 1704 commonly done. 1706 o Added B. Stevant as Editor. 1708 o Clarification in Section 5.2.4.1 and Section 5.2.4.2 regarding the 1709 scope of the MUST (to the specific scenarios). 1711 o Removed considerations about reverse DNS from Section 6, agreed on 1712 Barcelona. 1714 o Clarified the NAT case in Section 6.1.2 1716 o Added first paragraph in Section 6.2.1 regarding delegated IPv6 1717 prefixes. 1719 o Added new Section 6.3, Section 6.3.1 and Section 6.3.2 summarizing 1720 the scenarios for address allocation. 1722 Changes between -00 and -01: 1724 o Changed alignment in all figures to be centered, and fixed 1725 Figure 9 reference. 1727 o Section 1.4: Added new section with "Best Current Practices" 1728 definition. 1730 o Marked the following sections as "Best Current Practices": 1731 Section 6, Section 8, and Section 9. 1733 o Section 6.1.1, last paragraph: Removed sentence on IPv6 link 1734 address on the PPP link. Mailing list comment from Florent 1735 Parent, 13-Jul-2006. 1737 o Section 6.1.2, last paragraph: Changed IPv4 PPP link address to 1738 use host addresses (/32) negotiated with IPCP instead of /30. 1739 Mailing list comment from Bill Storer, 5-Jul-2006. 1741 o Section 5, Figure 10: Correction, s/SCCSN/SCCCN/; added missing 1742 ICRP, and changed direction of ICCN; typo correction s/IPV6P/ 1743 IPV6CP/. Mailing list comment from Bill Storer, 5-Jul-2006. 1745 o Section 5, Figure 10: Marked CHAP as "Optional - CHAP". 1747 o Section 5.1, Section 5.1.1, and Section 5.1.3: Minor typographical 1748 error correction and rewording of some sentences for grammar. 1750 o Section 5.1.1.1, Host Name AVP: Removed "for debugging purposes" 1751 and added that MAY be used to authenticate users. 1753 o Section 5.1.1.1, Framing Capabilities AVP: Swapped SHOULD and 1754 MUST. Mailing list comment from Bill Storer, 5-Jul-2006, text 1755 from Laurent Toutain. 1757 o Section 5.1.1.1, (Tx) Connect Speed: Correction: "but is *not* 1758 meaningful". 1760 o Section 5.1.1.2, Challenge and Challenge Response AVPs: Removed 1761 the last sentence of the first paragraph. Mailing list comment 1762 from Bill Storer, 5-Jul-2006, text from Laurent Toutain. 1764 o Section 5.1.2: Rewrote paragraph to use L2TPv2 HELLO messages and 1765 not LCP Echo Request and Reply messages to detect tunnel failure, 1766 as redundant in Softwires. Mailing list comment from Florent 1767 Parent, 10-Jul-2006, text from Bill Storer. 1769 o Section 5.2.1, first paragraph: Fixed PPP MTU calculation. 1770 Mailing list comment from Florent Parent, 10-Jul-2006. 1772 o Section 5.2.4.2: Rewrote to generalize the address assignment 1773 failure, to be an all-zeroes address or a protocol reject in 1774 response to the IPCP CONFREQ. Mailing list comment from Bill 1775 Storer, 5-Jul-2006, text from JF Tremblay. 1777 o Section 8, second paragraph: s/Tunnel-Medium /Tunnel-Type /. 1778 Mailing list comment from Bill Storer, 5-Jul-2006. 1780 o Section 8.1.2: Added usage of Framed-IP-Address attribute, and if 1781 not present then use the Tunnel-Client-Endpoint and Tunnel-Server- 1782 Endpoint attributes. Mailing list comment from Bill Storer, 1783 5-Jul-2006, text from JF Tremblay and Bill Storer. 1785 o Completed Section 8.2.2, Section 9.1, Section 9.2, and Section 10. 1787 Revision -00: 1789 o Initial revision. 1791 Authors' Addresses 1793 Bill Storer 1794 Cisco Systems 1795 170 W Tasman Dr 1796 San Jose, CA 95134 1797 USA 1799 Email: bstorer@cisco.com 1801 Carlos Pignataro (editor) 1802 Cisco Systems 1803 7200 Kit Creek Road 1804 PO Box 14987 1805 Research Triangle Park, NC 27709 1806 USA 1808 Email: cpignata@cisco.com 1809 Maria Alice Dos Santos 1810 Cisco Systems 1811 170 W Tasman Dr 1812 San Jose, CA 95134 1813 USA 1815 Email: mariados@cisco.com 1817 Bruno Stevant (editor) 1818 GET/ENST Bretagne 1819 2 rue de la Chataigneraie CS17607 1820 Cesson Sevigne, 35576 1821 France 1823 Email: bruno.stevant@enst-bretagne.fr 1825 Jean-Francois Tremblay 1826 Trellia Networks 1827 100, Alexis-Nihon, Suite 770 1828 Montreal, QC H4M 2P3 1829 Canada 1831 Email: jf@jftremblay.com 1833 Full Copyright Statement 1835 Copyright (C) The IETF Trust (2007). 1837 This document is subject to the rights, licenses and restrictions 1838 contained in BCP 78, and except as set forth therein, the authors 1839 retain all their rights. 1841 This document and the information contained herein are provided on an 1842 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1843 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1844 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1845 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1846 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1847 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1849 Intellectual Property 1851 The IETF takes no position regarding the validity or scope of any 1852 Intellectual Property Rights or other rights that might be claimed to 1853 pertain to the implementation or use of the technology described in 1854 this document or the extent to which any license under such rights 1855 might or might not be available; nor does it represent that it has 1856 made any independent effort to identify any such rights. Information 1857 on the procedures with respect to rights in RFC documents can be 1858 found in BCP 78 and BCP 79. 1860 Copies of IPR disclosures made to the IETF Secretariat and any 1861 assurances of licenses to be made available, or the result of an 1862 attempt made to obtain a general license or permission for the use of 1863 such proprietary rights by implementers or users of this 1864 specification can be obtained from the IETF on-line IPR repository at 1865 http://www.ietf.org/ipr. 1867 The IETF invites any interested party to bring to its attention any 1868 copyrights, patents or patent applications, or other proprietary 1869 rights that may cover technology that may be required to implement 1870 this standard. Please address the information to the IETF at 1871 ietf-ipr@ietf.org. 1873 Acknowledgment 1875 Funding for the RFC Editor function is provided by the IETF 1876 Administrative Support Activity (IASA).