idnits 2.17.1 draft-ietf-softwire-hs-framework-l2tpv2-07.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 1842. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1853. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1860. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1866. 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 (September 26, 2007) is 6050 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 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 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 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: March 29, 2008 Cisco Systems 6 B. Stevant, Ed. 7 GET/ENST Bretagne 8 J. Tremblay 9 Trellia Networks 10 September 26, 2007 12 Softwires Hub & Spoke Deployment Framework with L2TPv2 13 draft-ietf-softwire-hs-framework-l2tpv2-07 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 March 29, 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 [RFC5072]. 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 [RFC5072]. 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 [RFC5072]. 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 [RFC5072]. 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 4861 "Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861]. 758 RFC 5072 "IP Version 6 over PPP" [RFC5072]. 760 RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" 761 [RFC3315]. 763 RFC 3646 "DNS Configuration options for Dynamic Host Configuration 764 Protocol for IPv6 (DHCPv6)" [RFC3646]. 766 4.5.2. For IPv4 Payloads 768 RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)" 769 [RFC1332]. 771 RFC 1661 "The Point-to-Point Protocol (PPP)" [RFC1661]. 773 RFC 1877 "PPP Internet Protocol Control Protocol Extensions for 774 Name Server Addresses" [RFC1877]. 776 DHCP Subnet Allocation "Subnet Allocation Option". 778 * Work in progress, see [I-D.ietf-dhc-subnet-alloc]. 780 5. Softwire Establishment 782 A Softwire is established in three distinct steps (see Figure 9). 783 First an L2TPv2 tunnel with a single session is established from the 784 SI to the SC. Second a PPP session is established over the L2TPv2 785 session and the SI obtains an address. Third the SI optionally gets 786 other information through DHCP such as a delegated prefix and DNS 787 servers. 789 SC SI 790 | | 791 |<-------------L2TPv2------------>| Step 1 792 | | L2TPv2 Tunnel establishment 793 | | 794 |<-------------PPP--------------->| Step 2 795 |<----End Point Configuration---->| PPP and End Point 796 | | configuration 797 | | 798 |<------Router Configuration----->| Step 3 799 | | Additional configuration 800 | | (optional) 802 Figure 9: Steps for the Establishment of a Softwire 804 In the following diagram (see Figure 10), each of the three steps 805 required to establish a Softwire is described in detail. 807 SC SI 808 | | 809 | | Step 1 810 |<------------SCCRQ---------------| - 811 |-------------SCCRP-------------->| | 812 |<------------SCCCN---------------| | 813 |<------------ICRQ----------------| | L2TPv2 814 |-------------ICRP--------------->| | 815 |<------------ICCN----------------| - 816 | | 817 | | Step 2 818 |<-----Configuration-Request------| - 819 |------Configuration-Request----->| | PPP 820 |<-------Configuration-Ack--------| | LCP 821 |--------Configuration-Ack------->| - 822 | | 823 |-----------Challenge------------>| - PPP Authentication 824 |<----------Response--------------| | (Optional - CHAP) 825 |------------Success------------->| - 826 | | 827 |<-----Configuration-Request------| - 828 |------Configuration-Request----->| | PPP NCP 829 |<-------Configuration-Ack--------| | (IPV6CP or IPCP) 830 |--------Configuration-Ack------->| - 831 | | 832 |<------Router-Solicitation-------| - Neighbor Discovery 833 |-------Router-Advertisement----->| | (IPv6 only) 834 | | - 835 | | 836 | | Step3 837 |<-----------Solicit--------------| - 838 |-----------Advertise------------>| | DHCP 839 |<---------- Request--------------| | (Optional) 840 |-------------Reply-------------->| - 842 Figure 10: Detailed Steps in the Establishment of a Softwire 844 5.1. L2TPv2 Tunnel Setup 846 L2TPv2 [RFC2661] was originally designed to provide private network 847 access to end users connected to a public network. In the L2TPv2 848 model, the end user makes a connection to an L2TP Access Concentrator 849 (LAC). The LAC then initiates an L2TPv2 tunnel to an L2TP Network 850 Server (LNS). The LNS then transfers end user traffic between the 851 L2TPv2 tunnel and the private network. 853 In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI) 854 assumes the role of the LAC and the Softwire Concentrator assumes the 855 role of the LNS. 857 In the Softwire model, an L2TPv2 packet MUST be carried over UDP. 858 The underlying version of the IP protocol may be IPv4 or IPv6, 859 depending on the Softwires scenario. 861 In the following sections, the term "Tunnel" follows the definition 862 from [RFC2661], namely: "The Tunnel consists of a Control Connection 863 and zero or more L2TP Sessions". 865 5.1.1. Tunnel Establishment 867 Figure 11 describes the messages exchanged and AVPs used to establish 868 a tunnel between an SI (LAC) and an SC (LNS). The messages and AVPs 869 described here are only a subset of those defined in [RFC2661]. This 870 is because Softwires uses only a subset of the L2TPv2 functionality. 871 The subset of L2TP Control Connection Management AVPs that is 872 applicable to Softwires is grouped into Mandatory AVPs and Optional 873 AVPs (see Figure 11). Note that in the Softwires environment, the SI 874 always initiates the tunnel. L2TPv2 attributes SHOULD NOT be hidden. 876 SCCRQ 877 Mandatory AVP 878 Message Type 879 Protocol Version 880 Host Name 881 Framing Capabilities 882 Assigned Tunnel ID 883 Optional AVP: 884 Receive Window Size 885 Firmware Revision 886 Vendor Name 887 Challenge 889 SCCRP 890 Mandatory AVP: 891 Message Type 892 Protocol Version 893 Framing Capabilities 894 Host Name 895 Assigned Tunnel ID 896 Optional AVP: 897 Firmware Revision 898 Vendor Name 899 Receive Window Size 900 Challenge Response 901 Challenge 903 SCCCN 904 Mandatory AVP: 905 Message Type 906 Optional AVP: 907 Challenge Response 909 Figure 11: Control Connection Establishment 911 In L2TPv2, the tunnel between an LAC and LNS may carry the data of 912 multiple users. Each of these user's is represented by an L2TPv2 913 session within the tunnel. In the Softwires environment, the tunnel 914 carries the information of a single user. So, there is only one 915 L2TPv2 session per tunnel. Figure 12 describes the messages 916 exchanged and the AVPs used to establish a session between an SI 917 (LAC) and an SC (LNS). The messages and AVPs described here are only 918 a subset of those defined in [RFC2661]. This is because Softwires 919 uses only a subset of the L2TPv2 functionality. The subset of L2TP 920 Call Management AVPs that is applicable to Softwires is grouped into 921 Mandatory AVPs and Optional AVPs (see Figure 12). Note that in the 922 Softwires environment, the SI always initiates the session. No 923 outgoing or analog calls are permitted. L2TPv2 attributes SHOULD NOT 924 be hidden. 926 ICRQ 927 Mandatory AVP: 928 Message Type 929 Assigned Session ID 930 Call Serial Number 932 ICRP 933 Mandatory AVP: 934 Message Type 935 Assigned Session ID 937 ICCN 938 Mandatory AVP: 939 Message Type 940 (Tx) Connect Speed 941 Framing Type 943 Figure 12: Session Establishment 945 5.1.1.1. AVPs Required for Softwires 947 This section prescribes specific values for AVPs used in the 948 Softwires context that are Mandatory. 950 Host Name AVP 952 This AVP is mandatory and is present in SCCRQ and SCCRP messages. 953 This AVP may be used to authenticate users, in which case it would 954 contain a user identification. If this AVP is not used to 955 authenticate users, it may be used for logging purposes. 957 Framing Capabilities AVP 959 Synchronous bit SHOULD be set to 1 and Asynchronous bit to 1. 960 This AVP SHOULD be ignored by the receiver. 962 Framing Type AVP 964 Synchronous bit SHOULD be set to 1 and Asynchronous bit to 0. 965 This AVP SHOULD be ignored by the receiver. 967 (Tx) Connect Speed 969 (Tx) Connect Speed is a mandatory AVP but is not meaningful in the 970 Softwires context. It SHOULD be left to 0 and ignored by the 971 receiver. 973 Message Type AVP, Protocol Version AVP, Assigned Tunnel ID AVP, Call 974 Serial Number AVP, and Assigned Session ID AVP 976 As defined in [RFC2661] 978 5.1.1.2. AVPs Optional for Softwires 980 This section prescribes specific values for AVPs used in the 981 Softwires context that are Optional. 983 Challenge AVP and Challenge Response AVP 985 These AVPs are not required, but are necessary to implement tunnel 986 authentication. Since tunnel authentication happens at the 987 beginning of L2TPv2 tunnel creation, it can be helpful in 988 preventing DoS attacks. 990 Receive Window Size AVP, Firmware Revision AVP, and Vendor Name AVP 992 As defined in [RFC2661] 994 5.1.1.3. AVPs not Relevant for Softwires 996 L2TPv2 specifies numerous AVPs that, while allowed for a given 997 command, are irrelevant to a Softwires. Softwires implementations 998 SHOULD NOT send these AVPs. However, they SHOULD ignore them when 999 they are received. This will make it easier to create Softwires 1000 applications on top of existing L2TPv2 implementations. 1002 5.1.2. Tunnel Maintenance 1004 Periodically, the SI MUST transmit a message to the SC to maintain 1005 NAT/NAPT contexts and detect tunnel failure. The L2TPv2 HELLO 1006 message provides a simple, low overhead method of doing this. 1008 The default values specified in [RFC2661] for L2TPv2 HELLO messages 1009 could result in a dead end detection time of 83 seconds. Although 1010 these retransmission timers and counters SHOULD be configurable (see 1011 Section 5.8 of [RFC2661]), these values may not be adapted for all 1012 situations, where a quicker dead end detection is required, or where 1013 NAT/NAPT context needs to be refreshed more frequently. In such 1014 cases, the SI MAY use, in combination with L2TPv2 HELLO, LCP ECHO 1015 messages (Echo-Request and Echo-Reply codes) described in [RFC1661]. 1016 When used, LCP ECHO messages SHOULD have a re-emission timer lower 1017 than the value for L2TPv2 HELLO hello messages. The default value 1018 recommended in Section 6.5 of [RFC2661] for the HELLO message 1019 retransmission interval is 60 seconds. When used, a set of suggested 1020 values (included here only for guidance) for the LCP ECHO message 1021 request interval is a default of 30 seconds, a minimum of 10 seconds, 1022 and a maximum of the lesser of the configured L2TPv2 HELLO 1023 retransmisison interval and 60 seconds. 1025 5.1.3. Tunnel Teardown 1027 Either the SI or SC can teardown the session and tunnel. This is 1028 done as specified in [RFC2661]. There is no action specific to 1029 Softwires in this case. 1031 5.2. PPP Connection 1033 5.2.1. MTU 1035 The MTU of the PPP link SHOULD be the link MTU minus the size of the 1036 IP, UDP, L2TPv2, and PPP headers together. On an IPv4 link with an 1037 MTU equal to 1500 bytes, this could tipically mean a PPP MTU of 1460 1038 bytes. When the link is managed by IPsec, this MTU should be lowered 1039 to take into account the ESP encapsulation (see 1040 [I-D.ietf-softwire-security-requirements]). The value for the MTU 1041 may also vary according to the size of the L2TP header, as defined by 1042 the leading bits of the L2TP message header (see [RFC2661]). 1043 Additionally, see [RFC4623] for a detailed discussion of 1044 fragmentation issues. 1046 5.2.2. LCP 1048 Once the L2TPv2 session is established, the SI and SC initiate the 1049 PPP connection by negotiating LCP as described in [RFC1661]. The 1050 Address-and-Control-Field-Compression configuration option (ACFC) 1051 [RFC1661] SHOULD be rejected. 1053 5.2.3. Authentication 1055 After completing LCP negotiation, the SI and SC may optionally 1056 perform authentication. If authentication is chosen, CHAP [RFC1994] 1057 authentication MUST be supported by both the Softwire Initiator and 1058 Softwire Concentrator. Other authentication methods such as MS- 1059 CHAPv1 [RFC2433], and EAP [RFC3748] MAY be supported. 1061 A detailed discussion of Softwires security is contained in 1062 [I-D.ietf-softwire-security-requirements]. 1064 5.2.4. IPCP 1066 5.2.4.1. IPV6CP 1068 In the IPv6 over IPv4 scenarios (see Section 3.1), after the 1069 authentication phase, the Softwire Initiator MUST negotiate IPV6CP as 1070 defined in [RFC5072]. IPV6CP provides a way to negotiate a unique 1071 64-bit Interface-Identifier to be used for the address 1072 autoconfiguration at the local end of the link. 1074 5.2.4.2. IPv4CP 1076 In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire 1077 Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain 1078 an IPv4 address from the SC. IPCP may also be used to obtain DNS 1079 information as described in [RFC1877]. 1081 5.3. Global IPv6 Address Assignement to Endpoints 1083 In several scenarios defined in Section 3, Global IPv6 addresses are 1084 expected to be allocated to Softwires end points. Since IPV6CP only 1085 provide Link-Local addresses (see [RFC5072]), IPv6 Neighbor Discovery 1086 [RFC4862] or DHCPv6 [RFC3315] SHOULD be used to configure these 1087 addresses. 1089 The Softwire Initiator of an IPv6 Softwire MUST send a Router 1090 Solicitation message to the Softwire Concentrator after IPV6CP is 1091 completed. The Softwire Concentrator MUST answer with a Router 1092 Advertisement. This message MUST contains the global IPv6 prefix of 1093 the PPP link if Neighbor discovery is used to configure addresses of 1094 Softwire end points. 1096 If DHCPv6 is available for address delegation, the M bits of the 1097 Router Advertisement SHOULD be set. The Softwire Initiator MUST then 1098 send a DHCPv6 Request to configure the address of the Softwire 1099 endpoint. 1101 Duplicate Address Detection ([RFC4861]) MUST be performed on the 1102 Softwire in both cases. 1104 5.4. DHCP 1106 The Softwire Initiator MAY use DHCP to get additional information 1107 such as delegated prefix and DNS servers. If the SI supports DHCP, 1108 it SHOULD send a Solicit message to verify if more information is 1109 available. 1111 When delegating an IPv4 prefix to the SI, the SC SHOULD inject a 1112 route for this prefix in the IPv4 routing table in order to forward 1113 the traffic to the relevant Softwire. 1115 5.4.1. DHCPv6 1117 If an SI establishing an IPv6 Softwire acts as a router (i.e., in the 1118 scenarios in Section 3.1.2 and Section 3.1.4) it MUST include the 1119 IA_PD option [RFC3633] in the DHCPv6 Solicit message [RFC3315] in 1120 order to request an IPv6 prefix. 1122 When delegating an IPv6 prefix to the SI, the SC SHOULD inject a 1123 route for this prefix in the IPv4 routing table in order to forward 1124 the traffic to the relevant Softwire. 1126 5.4.2. DHCPv4 1128 An SI establishing an IPv4 Softwire MAY send a DHCP request 1129 containing the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc]. 1130 This practice is not common but may be used to connect IPv4 subnets 1131 using Softwires, as defined in Section 3.2.2 and Section 3.2.4. 1133 One Subnet-Request suboption MUST be configured with the 'h' bit set 1134 to '1', as the SI is expected to perform the DHCP server function. 1135 The 'i' bit of the Subnet-Request suboption SHOULD be set to '0' the 1136 first time a prefix is requested and to '1' on subsequent requests, 1137 if a prefix has been allocated. The Prefix length suboption SHOULD 1138 be 0 by default. If the SI is configured to support only specific 1139 prefix lengths, it SHOULD specify the longest (smallest) prefix 1140 length it supports. 1142 If the SI was previously assigned a prefix from that same SC, it 1143 SHOULD include the Subnet Information suboption with the prefix it 1144 was previously assigned. The 'c' and 's' bits of the suboption 1145 SHOULD be set to '0'. 1147 6. Considerations about the Address Provisioning Model 1149 This section describes how a Softwire Concentrator may manage 1150 delegated addresses for Softwire endpoints and for subnets behind the 1151 Softwire Initiator. One common practice is to aggregate endpoints 1152 addresses and delegated prefixes into one prefix routed to the SC. 1153 The main benefit is to ease the routing scheme by isolating on the SC 1154 succeeding route injections (when delegating new prefixes for SI). 1156 6.1. Softwire Endpoints Addresses 1158 6.1.1. IPv6 1160 A Softwire Concentrator should provide globally routable addresses to 1161 Softwire endpoints. Other types of addresses such as Unique Local 1162 Addresses [RFC4193] may be used to address Softwire end points in a 1163 private network with no global connectivity. A single /64 should be 1164 assigned to the Softwire to address both Softwire endpoints. 1166 Global or ULA addresses must be assigned to endpoints when the 1167 scenario "Host CPE as Softwire Initiator" (described in 1168 Section 3.1.1) is considered to be deployed. For other scenarios, 1169 this may be optional and link local addresses should be used. 1171 6.1.2. IPv4 1173 A Softwire Concentrator may provide either globally routable or 1174 private IPv4 addresses. When using IPv4 private addresses [RFC1918] 1175 on the endpoints, it is not recommended to delegate an IPv4 private 1176 prefix to the SI, as it can lead to a nested-NAT situations. 1178 The endpoints of the PPP link use host addresses (i.e., /32), 1179 negotiated using IPCP. 1181 6.2. Delegated Prefixes 1183 6.2.1. IPv6 Prefixes 1185 Delegated IPv6 should be of global scope if the IPv6 addresses 1186 assigned to endpoints are global. Using ULA addresses is not 1187 recommended when the subnet is connected to the global IPv6 Internet. 1188 When using ULA IPv6 address for endpoint, the delegated IPv6 prefix 1189 may be either of Global or ULA scope. 1191 Delegated IPv6 prefixes are between /48 and /64 in length. When an 1192 SI receives a prefix shorter than 64, it can assign different /64 1193 prefixes to each of its interfaces. An SI receiving a single /64 is 1194 expected to perform bridging if more than one interface are available 1195 (wired and wireless for example). 1197 6.2.2. IPv4 Prefixes 1199 Delegated IPv4 prefixes should be routable within the address space 1200 used by assigned IPv4 addresses. Delegate non-routable IPv4 prefixes 1201 (i.e. private IPv4 prefix over public IPv4 addresses or another class 1202 of private IPv4 addresses) is not recommended as a practice for 1203 provisioning and address translation should be considered in these 1204 cases. The prefix length is between /8 and /30. 1206 6.3. Possible scenarios 1208 This section summarizes the differents scenarios for address 1209 provisioning with the considerations given in the previous sections. 1211 6.3.1. Scenarios for IPv6 1213 This table describes the possible combination of IPv6 address scope 1214 for endpoints and delegated prefixes. 1216 +------------------+-----------------------+------------------------+ 1217 | Endpoint IPv6 | Delegated Global IPv6 | Delegated ULA IPv6 | 1218 | Address | Prefix | Prefix | 1219 +------------------+-----------------------+------------------------+ 1220 | Link Local | Possible | Possible | 1221 | | | | 1222 | ULA | Possible | Possible | 1223 | | | | 1224 | Global | Possible | Possible, but Not | 1225 | | | Recommended | 1226 +------------------+-----------------------+------------------------+ 1228 Table 1: Scenarios for IPv6 1230 6.3.2. Scenarios for IPv4 1232 This table describes the possible combination of IPv4 address scope 1233 for endpoints and delegated prefixes. 1235 +-------------+-----------------+-----------------------------------+ 1236 | Endpoint | Delegated | Delegated Private IPv4 Prefix | 1237 | IPv4 | Public IPv4 | | 1238 | Address | Prefix | | 1239 +-------------+-----------------+-----------------------------------+ 1240 | Private | Possible | Possible, but Not Recommended | 1241 | IPv4 | | when using NAT (cf. | 1242 | | | Section 6.1.2) | 1243 | | | | 1244 | Public IPv4 | Possible | Possible, but NAT usage is | 1245 | | | recommended (cf. Section 6.2.2) | 1246 +-------------+-----------------+-----------------------------------+ 1248 Table 2: Scenarios for IPv4 1250 7. Considerations about Address Stability 1252 A Softwire can provide stable addresses even if the underlying 1253 addressing scheme changes, by opposition to automatic tunneling. A 1254 Softwire Concentrator should always provide the same address and 1255 prefix to a reconnecting user. However, if the goal of the Softwire 1256 service is to provide a temporary address for a roaming user, it may 1257 be provisioned to provide only a temporary address. 1259 The address and prefix are expected to change when reconnecting to a 1260 different Softwire Concentrator. However an organization providing a 1261 Softwire service may provide the same address and prefix across 1262 different Softwire Concentrators at the cost of a more fragmented 1263 routing table. The routing fragmentation issue may be limited if the 1264 prefixes are aggregated in a location topologically close to the SC. 1265 This would be the case for example if several SCs are put in parallel 1266 for load-balancing purpose. 1268 8. Considerations about RADIUS Integration 1270 The Softwire Concentrator is expected to act as a client to a AAA 1271 server, for example a RADIUS server. During the PPP authentication 1272 phase, the RADIUS server may return additional informations in the 1273 form of attributes in the Access Accept message. 1275 The Softwire Concentrator may include the Tunnel-Type and Tunnel- 1276 Medium-Type attributes [RFC2868] in the Access Request messages to 1277 provide a hint of the type of Softwire being configured. 1279 8.1. Softwires Endpoints 1281 8.1.1. IPv6 Softwires 1283 If the RADIUS server includes a Framed-Interface-Id attribute 1284 [RFC3162], the Softwire Concentrator must send it to the Softwire 1285 Initiator in the Interface-Identifier field of its IPV6CP 1286 Configuration Request message. 1288 If the Framed-IPv6-Prefix attribute is mentioned [RFC3162], that 1289 prefix must be used in the router advertisements sent to the SI. If 1290 Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC 1291 must choose a prefix with that pool to send RAs. 1293 If none of the attributes above are included but the AAA server 1294 returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint 1295 attributes [RFC2868] with the correct address family, these must be 1296 used in the IPV6CP Interface-Identifier and for the router 1297 advertisements. 1299 8.1.2. IPv4 Softwires 1301 If the Framed-IP-Address attribute [RFC2865] is present, the Softwire 1302 Concentrator must provide that address to the Softwire Initiator 1303 during IPCP address negotiation. That is, when the Softwire 1304 Initiator requests an IP address from the Softwire Concentrator, the 1305 address provided should be the Framed-IP-Address. 1307 If the Framed-IP-Address attribute is not present and the Tunnel- 1308 Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are 1309 present and of the correct address family, these should be used in 1310 the IPCP IP-Address configuration option. 1312 8.2. Delegated Prefixes 1314 8.2.1. IPv6 Prefixes 1316 If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the 1317 RADIUS Access Accept message, it must be used by the Softwire 1318 Concentrator for the delegation of the IPv6 prefix. Since the prefix 1319 delegation is performed by DHCPv6 and the attribute is linked to a 1320 username, the SC must associate the DHCP Unique Identifier (DUID) of 1321 a DHCPv6 request to the tunnel it came from and its user. 1323 Interaction between RADIUS, PPP and DHCPv6 server may follow the 1324 mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. During the 1325 Softwire authentication phase, PPP collects the RADIUS attributes for 1326 the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is 1327 assigned to the Softwire. The DHCPv6 relay fills in these attributes 1328 in the Relay agent RADIUS Attribute Option (RRAO) DHCPv6 option, 1329 before forwarding the DHCPv6 requests to the DHCPv6 server. 1331 8.2.2. IPv4 Prefixes 1333 The combination of the Framed-IP-Address and Framed-IP-Netmask 1334 attributes [RFC2865] may be used by the Softwire Concentrator to 1335 delegate an IPv4 prefix to the Softwire Initiator. 1337 9. Considerations for Maintenance and Statistics 1339 9.1. RADIUS Accounting 1341 RADIUS Accounting for L2TP and PPP are documented (see Section 4.3). 1343 When deploying Softwires solutions, operators may experience 1344 difficulties to differentiate the address family of the traffic 1345 reported in accounting information from RADIUS. This problem and 1346 some potential solutions are described in 1347 [I-D.stevant-softwire-accounting]. 1349 9.2. MIBs 1351 MIB support for L2TPv2 and PPP are documented (see Section 4.4). 1352 Also see [RFC4293]. 1354 10. Security Considerations 1356 A detailed discussion of Softwires security is contained in 1357 [I-D.ietf-softwire-security-requirements]. 1359 The L2TPv2 Softwires solution provides the following tools for 1360 security: 1362 o IPsec [RFC4301] with IKEv2 [RFC4306] provides the highest level of 1363 security. [RFC3193] describes interaction between IPsec and 1364 L2TPv2. 1366 o PPP CHAP [RFC1994] provides basic user authentication. 1368 o L2TP Tunnel Authentication [RFC2661] provides authentication at 1369 tunnel setup. It may be used to limit DoS attacks by 1370 authenticating the tunnel before L2TP session and PPP resources 1371 are allocated. 1373 11. IANA Considerations 1375 This document creates no new requirements on IANA namespaces 1376 [RFC2434]. 1378 12. Acknowledgements 1380 The authors would like to acknowledge the following contributors who 1381 provided helpful input on this document: Florent Parent, Jordi Palet 1382 Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, and 1383 Francis Dupont. 1385 The authors would also like to acknowledge the participants in the 1386 Softwires interim meetings held in Hong Kong, China and Barcelona, 1387 Spain. The minutes for the interim meeting at the China University - 1388 Hong Kong (February 23-24, 2006) are at 1389 . The 1390 minutes for the interim meeting at Polytechnic University of 1391 Catalonia - Barcelona (September 14-15, 2006) are reachable at . 1394 13. References 1396 13.1. Normative References 1398 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 1399 (IPCP)", RFC 1332, May 1992. 1401 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1402 RFC 1661, July 1994. 1404 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1405 E. Lear, "Address Allocation for Private Internets", 1406 BCP 5, RFC 1918, February 1996. 1408 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1409 Protocol (CHAP)", RFC 1994, August 1996. 1411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1412 Requirement Levels", BCP 14, RFC 2119, March 1997. 1414 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1415 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1416 October 1998. 1418 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1419 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1420 RFC 2661, August 1999. 1422 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1423 "Remote Authentication Dial In User Service (RADIUS)", 1424 RFC 2865, June 2000. 1426 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1427 RFC 3162, August 2001. 1429 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 1430 "Securing L2TP using IPsec", RFC 3193, November 2001. 1432 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1433 and M. Carney, "Dynamic Host Configuration Protocol for 1434 IPv6 (DHCPv6)", RFC 3315, July 2003. 1436 [RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two 1437 Tunneling Protocol "L2TP" Management Information Base", 1438 RFC 3371, August 2002. 1440 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1441 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1442 December 2003. 1444 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1445 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1446 RFC 3948, January 2005. 1448 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1449 Internet Protocol", RFC 4301, December 2005. 1451 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1452 RFC 4306, December 2005. 1454 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1455 Attribute", RFC 4818, April 2007. 1457 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1458 Address Autoconfiguration", RFC 4862, September 2007. 1460 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 1461 PPP", RFC 5072, September 2007. 1463 13.2. Informative References 1465 [I-D.ietf-dhc-subnet-alloc] 1466 Johnson, R., "Subnet Allocation Option", 1467 draft-ietf-dhc-subnet-alloc-05 (work in progress), 1468 June 2007. 1470 [I-D.ietf-dhc-v6-relay-radius] 1471 Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option", 1472 draft-ietf-dhc-v6-relay-radius-02 (work in progress), 1473 February 2006. 1475 [I-D.ietf-softwire-security-requirements] 1476 Yamamoto, S., "Softwire Security Analysis and 1477 Requirements", 1478 draft-ietf-softwire-security-requirements-03 (work in 1479 progress), July 2007. 1481 [I-D.stevant-softwire-accounting] 1482 Stevant, B., "Accounting on Softwires", 1483 draft-stevant-softwire-accounting-01 (work in progress), 1484 October 2006. 1486 [RFC1471] Kastenholz, F., "The Definitions of Managed Objects for 1487 the Link Control Protocol of the Point-to-Point Protocol", 1488 RFC 1471, June 1993. 1490 [RFC1473] Kastenholz, F., "The Definitions of Managed Objects for 1491 the IP Network Control Protocol of the Point-to-Point 1492 Protocol", RFC 1473, June 1993. 1494 [RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control 1495 Protocol Extensions for Name Server Addresses", RFC 1877, 1496 December 1995. 1498 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 1499 RFC 2433, October 1998. 1501 [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting 1502 Modifications for Tunnel Protocol Support", RFC 2867, 1503 June 2000. 1505 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, 1506 M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1507 Support", RFC 2868, June 2000. 1509 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1510 Address Translator (Traditional NAT)", RFC 3022, 1511 January 2001. 1513 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1514 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1515 December 2003. 1517 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1518 Levkowetz, "Extensible Authentication Protocol (EAP)", 1519 RFC 3748, June 2004. 1521 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 1522 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1524 [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005. 1526 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1527 Addresses", RFC 4193, October 2005. 1529 [RFC4293] Routhier, S., "Management Information Base for the 1530 Internet Protocol (IP)", RFC 4293, April 2006. 1532 [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- 1533 Edge (PWE3) Fragmentation and Reassembly", RFC 4623, 1534 August 2006. 1536 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1537 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1538 September 2007. 1540 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 1541 Problem Statement", RFC 4925, July 2007. 1543 Appendix A. Revision History 1545 [Note to RFC Editor: please remove this entire appendix, and the 1546 corresponding entries in the table of contents, prior to 1547 publication.] 1549 Changes between -06 and -07: 1551 o Changed RFC numbers: RFC2461 and I-D 2461(bis) to [RFC4861], 1552 RFC2462 to [RFC4862], and RFC2472 and I-D.ietf-ipv6-over-ppp-v2 to 1553 [RFC5072]. 1555 Changes between -05 and -06: 1557 o Swapped Section 4.1 and Section 4.2. Renamed Section 4.2 to 1558 "Securing the Softwire Transport". 1560 o In Section 5.2.1, added a mention that the MTU should be lower 1561 that 1460 when using IPsec. 1563 o In Section 10, added pointers to [RFC4301] and [RFC4306]. 1565 Changes between -04 and -05: 1567 o Replaced "documentation" with "logging purposes" in 1568 Section 5.1.1.1. 1570 o Added suggested values (only as guidance) for Keepalives in 1571 Section 5.1.2. 1573 Changes between -03 and -04: 1575 o Added missing references to [RFC4087], [RFC4861], and [RFC3646], 1576 moved [RFC4623] to Informative. 1578 o Rephrasing in Section 6.2.2. Added pointers Section 6.1.2 and 1579 Section 6.2.2 in Table 2. 1581 o Added citations (and corresponding references) to [RFC1471] and 1582 [RFC1473] in Section 4.4, since Section 9.2 explicitly mentions: 1583 "MIB support for L2TPv2 and PPP are documented." 1585 o Fixed some RFC2119 keywords in Section 3.1.1, Section 3.1.2, 1586 Section 3.1.3, Section 3.1.4, Section 3.2.1, Section 3.2.2, 1587 Section 3.2.3, Section 3.2.4, Section 5.1.1.3, Section 5.4.2, and 1588 Section 8.1.1. 1590 o Added [RFC2868] to Section 4.3, and added missing citations to 1591 Section 4. 1593 o Added missing "Optional AVP" to Figure 11. 1595 o Updated the text in Section 6.2.2. 1597 o Added some clarifying sentences in Section 5.1.1, and completed 1598 Section 5.1.1.1 and Section 5.1.1.2. 1600 o Added an Informative reference to [RFC3022] for NAT/NAPT. 1602 o Corrected reference to [RFC1661] in Section 5.2.2, removed 1603 reference and citation to RFC1662. 1605 o Updated references, Delegated-IPv6-Prefix became [RFC4818] moved 1606 to Normative. 1608 o Added new address and email for J.F. Tremblay. 1610 o Added an acknowledgement to the participants, and pointer to the 1611 minutes, for the Barcelona interim meeting. 1613 o Moved the Softwire Problem Statement reference [RFC4925] to 1614 Informative. 1616 o Some additional purely editorial changes. 1618 Changes between -02 and -03: 1620 o Boiler changes in support of RFC 4748. 1622 o Added text about L2TPv2 HELLO and LCP ECHO usage in Section 1, 1623 Section 2.6 and Section 5.1.2. 1625 o Moved some downref to Informative ([RFC1877], [RFC2433], 1626 [RFC2867], [RFC2868], and [RFC3748]), and moved CHAP reference to 1627 Normative ([RFC1994]). 1629 o Removed the mention and citation for PAP authentication. 1631 Changes between -01 and -02: 1633 o Renamed all "Best Current Practices" sections as 1634 "Recommendations". See for example Section 1.4. 1636 o Moved Provisioning in Section 6. Removed intro text to new 1637 Section 7. 1639 o Removed all normative language from Section 6, Section 7, 1640 Section 8, and Section 9. 1642 o Removed empty sections "Implementation Status", and "Open Issues". 1644 o Fixed "Phase 0" in Section 1. 1646 o Small changes to Section 3.1. 1648 o Change L2TP -> L2TPv2 in some sections, including Section 6. 1650 o Small additions and typo fixes in Section 5.1.1.1 and 1651 Section 5.1.1.2. 1653 o Retitled Section 8 and Section 8.1, changed AAA -> RADIUS. 1655 o New paragraph in Section 9.1. 1657 o New paragraph in Section 8.2.1, including a pointer to 1658 [I-D.ietf-dhc-v6-relay-radius]. 1660 o Moved last paragraph to start of Section 10. 1662 o Moved some references from Normative to Informative. 1664 o Label the steps in Figure 9 and Figure 10. 1666 o Reword paragraph of Section 5.1. 1668 o Describe more messages than flows in Figure 11 and Figure 12. 1670 o Add text about Session Establishment between Figure 11 and 1671 Figure 12. 1673 o Section 5.1.1.1 and Section 5.1.1.2: Updates on Hostname AVP, 1674 Framing Capabilities AVP, Framing Type AVP, Connect Speed AVP and 1675 Challenge and Challenge Response AVPs. 1677 o Retitled Section 5.1.1.3. 1679 o Updates on the use of L2TP HELLO versus LCP, delay for Dead-End 1680 peer detection, and allow LCP. 1682 o Rewording in Section 5.1.3. 1684 o Section 5.2.1: Add a pointer to [RFC4623] and small updates. 1686 o Clarifications on PFC and ACFC, remove Figure 13. 1688 o Section 5.2.3: make references to RFCs for PAP, CHAP, etc. 1690 o Rewordings in Section 5.2.4.1 and Section 5.2.4.2. 1692 o Added Informative references to [RFC4623], [RFC1661], [RFC2433], 1693 and [RFC3748]. 1695 o Renamed the title and added more details on Section 5.3 and IPv6 1696 ND, including a pointer to I-D.ietf-ipv6-2461bis. 1698 o Added text in Section 5.4 about IPv4 PD is non-trivial and non 1699 commonly done. 1701 o Added B. Stevant as Editor. 1703 o Clarification in Section 5.2.4.1 and Section 5.2.4.2 regarding the 1704 scope of the MUST (to the specific scenarios). 1706 o Removed considerations about reverse DNS from Section 6, agreed on 1707 Barcelona. 1709 o Clarified the NAT case in Section 6.1.2 1711 o Added first paragraph in Section 6.2.1 regarding delegated IPv6 1712 prefixes. 1714 o Added new Section 6.3, Section 6.3.1 and Section 6.3.2 summarizing 1715 the scenarios for address allocation. 1717 Changes between -00 and -01: 1719 o Changed alignment in all figures to be centered, and fixed 1720 Figure 9 reference. 1722 o Section 1.4: Added new section with "Best Current Practices" 1723 definition. 1725 o Marked the following sections as "Best Current Practices": 1726 Section 6, Section 8, and Section 9. 1728 o Section 6.1.1, last paragraph: Removed sentence on IPv6 link 1729 address on the PPP link. Mailing list comment from Florent 1730 Parent, 13-Jul-2006. 1732 o Section 6.1.2, last paragraph: Changed IPv4 PPP link address to 1733 use host addresses (/32) negotiated with IPCP instead of /30. 1734 Mailing list comment from Bill Storer, 5-Jul-2006. 1736 o Section 5, Figure 10: Correction, s/SCCSN/SCCCN/; added missing 1737 ICRP, and changed direction of ICCN; typo correction s/IPV6P/ 1738 IPV6CP/. Mailing list comment from Bill Storer, 5-Jul-2006. 1740 o Section 5, Figure 10: Marked CHAP as "Optional - CHAP". 1742 o Section 5.1, Section 5.1.1, and Section 5.1.3: Minor typographical 1743 error correction and rewording of some sentences for grammar. 1745 o Section 5.1.1.1, Host Name AVP: Removed "for debugging purposes" 1746 and added that MAY be used to authenticate users. 1748 o Section 5.1.1.1, Framing Capabilities AVP: Swapped SHOULD and 1749 MUST. Mailing list comment from Bill Storer, 5-Jul-2006, text 1750 from Laurent Toutain. 1752 o Section 5.1.1.1, (Tx) Connect Speed: Correction: "but is *not* 1753 meaningful". 1755 o Section 5.1.1.2, Challenge and Challenge Response AVPs: Removed 1756 the last sentence of the first paragraph. Mailing list comment 1757 from Bill Storer, 5-Jul-2006, text from Laurent Toutain. 1759 o Section 5.1.2: Rewrote paragraph to use L2TPv2 HELLO messages and 1760 not LCP Echo Request and Reply messages to detect tunnel failure, 1761 as redundant in Softwires. Mailing list comment from Florent 1762 Parent, 10-Jul-2006, text from Bill Storer. 1764 o Section 5.2.1, first paragraph: Fixed PPP MTU calculation. 1765 Mailing list comment from Florent Parent, 10-Jul-2006. 1767 o Section 5.2.4.2: Rewrote to generalize the address assignment 1768 failure, to be an all-zeroes address or a protocol reject in 1769 response to the IPCP CONFREQ. Mailing list comment from Bill 1770 Storer, 5-Jul-2006, text from JF Tremblay. 1772 o Section 8, second paragraph: s/Tunnel-Medium /Tunnel-Type /. 1773 Mailing list comment from Bill Storer, 5-Jul-2006. 1775 o Section 8.1.2: Added usage of Framed-IP-Address attribute, and if 1776 not present then use the Tunnel-Client-Endpoint and Tunnel-Server- 1777 Endpoint attributes. Mailing list comment from Bill Storer, 1778 5-Jul-2006, text from JF Tremblay and Bill Storer. 1780 o Completed Section 8.2.2, Section 9.1, Section 9.2, and Section 10. 1782 Revision -00: 1784 o Initial revision. 1786 Authors' Addresses 1788 Bill Storer 1789 Cisco Systems 1790 170 W Tasman Dr 1791 San Jose, CA 95134 1792 USA 1794 Email: bstorer@cisco.com 1796 Carlos Pignataro (editor) 1797 Cisco Systems 1798 7200 Kit Creek Road 1799 PO Box 14987 1800 Research Triangle Park, NC 27709 1801 USA 1803 Email: cpignata@cisco.com 1805 Maria Alice Dos Santos 1806 Cisco Systems 1807 170 W Tasman Dr 1808 San Jose, CA 95134 1809 USA 1811 Email: mariados@cisco.com 1812 Bruno Stevant (editor) 1813 GET/ENST Bretagne 1814 2 rue de la Chataigneraie CS17607 1815 Cesson Sevigne, 35576 1816 France 1818 Email: bruno.stevant@enst-bretagne.fr 1820 Jean-Francois Tremblay 1821 Trellia Networks 1822 100, Alexis-Nihon, Suite 770 1823 Montreal, QC H4M 2P3 1824 Canada 1826 Email: jf@jftremblay.com 1828 Full Copyright Statement 1830 Copyright (C) The IETF Trust (2007). 1832 This document is subject to the rights, licenses and restrictions 1833 contained in BCP 78, and except as set forth therein, the authors 1834 retain all their rights. 1836 This document and the information contained herein are provided on an 1837 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1838 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1839 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1840 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1841 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1842 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1844 Intellectual Property 1846 The IETF takes no position regarding the validity or scope of any 1847 Intellectual Property Rights or other rights that might be claimed to 1848 pertain to the implementation or use of the technology described in 1849 this document or the extent to which any license under such rights 1850 might or might not be available; nor does it represent that it has 1851 made any independent effort to identify any such rights. Information 1852 on the procedures with respect to rights in RFC documents can be 1853 found in BCP 78 and BCP 79. 1855 Copies of IPR disclosures made to the IETF Secretariat and any 1856 assurances of licenses to be made available, or the result of an 1857 attempt made to obtain a general license or permission for the use of 1858 such proprietary rights by implementers or users of this 1859 specification can be obtained from the IETF on-line IPR repository at 1860 http://www.ietf.org/ipr. 1862 The IETF invites any interested party to bring to its attention any 1863 copyrights, patents or patent applications, or other proprietary 1864 rights that may cover technology that may be required to implement 1865 this standard. Please address the information to the IETF at 1866 ietf-ipr@ietf.org. 1868 Acknowledgment 1870 Funding for the RFC Editor function is provided by the IETF 1871 Administrative Support Activity (IASA).