idnits 2.17.1 draft-ietf-softwire-hs-framework-l2tpv2-03.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 1697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1715. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1721. 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 (February 14, 2007) is 6271 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-ietf-softwire-problem-statement-02 ** Downref: Normative reference to an Informational draft: draft-ietf-softwire-problem-statement (ref. 'I-D.ietf-softwire-problem-statement') ** 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) == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-04 == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-10 == Outdated reference: A later version (-03) exists of draft-ietf-ipv6-over-ppp-v2-02 == Outdated reference: A later version (-09) exists of draft-ietf-softwire-security-requirements-01 == Outdated reference: A later version (-02) exists of draft-stevant-softwire-accounting-01 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwires Working Group B. Storer, Ed. 3 Internet-Draft C. Pignataro, Ed. 4 Intended status: Standards Track M. Dos Santos 5 Expires: August 18, 2007 Cisco Systems 6 J. Tremblay 7 Hexago 8 B. Stevant, Ed. 9 GET/ENST Bretagne 10 February 14, 2007 12 Softwires Hub & Spoke Deployment Framework with L2TPv2 13 draft-ietf-softwire-hs-framework-l2tpv2-03 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 18, 2007. 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 and Port Address Translation (NAT/PAT) . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 10 69 3.1. IPv6 over IPv4 Softwire with L2TPv2 . . . . . . . . . . . 10 70 3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 10 71 3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 11 72 3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 12 73 3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 13 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 . . . . . . . . . . . 15 77 3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 16 78 3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 17 80 4. Standardisation Status . . . . . . . . . . . . . . . . . . . . 19 81 4.1. Softwire Transport Related . . . . . . . . . . . . . . . . 19 82 4.2. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 4.3. Authentication Authorization Accounting . . . . . . . . . 19 84 4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 19 86 4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 19 87 4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 20 89 5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 21 90 5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 22 91 5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 23 92 5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 25 93 5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 26 94 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 26 95 5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 26 96 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 26 97 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 27 98 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 27 99 5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 106 5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28 107 5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 28 109 6. Considerations about the Address Provisioning Model . . . . . 30 110 6.1. Softwire Endpoints Addresses . . . . . . . . . . . . . . . 30 111 6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30 112 6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30 113 6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 30 114 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30 115 6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 31 116 6.3. Possible scenarios . . . . . . . . . . . . . . . . . . . . 31 117 6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 31 118 6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 31 120 7. Considerations about Address Stability . . . . . . . . . . . . 33 122 8. Considerations about RADIUS Integration . . . . . . . . . . . 34 123 8.1. Softwires Endpoints . . . . . . . . . . . . . . . . . . . 34 124 8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 34 125 8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 34 126 8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 34 127 8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 35 128 8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 35 130 9. Considerations for Maintenance and Statistics . . . . . . . . 36 131 9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 36 132 9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 134 10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 136 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 138 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 139 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 140 13.1. Normative References . . . . . . . . . . . . . . . . . . . 40 141 13.2. Informative References . . . . . . . . . . . . . . . . . . 41 143 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 43 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 146 Intellectual Property and Copyright Statements . . . . . . . . . . 48 148 1. Introduction 150 The Softwires Working Group has selected Layer Two Tunneling Protocol 151 version 2 (L2TPv2) as the phase 1 protocol to be deployed in the 152 Softwires "Hubs and Spokes" solution space. This document describes 153 the framework for the L2TPv2 "Hubs and Spokes" solution, and the 154 implementation details specified in this document should be followed 155 to achieve interoperability among different vendor implementations. 157 In the "Hubs and Spokes" solution space, a Softwire is established to 158 provide the home network with IPv4 connectivity across an IPv6-only 159 access network or IPv6 connectivity across an IPv4-only access 160 network. When L2TPv2 is used in the Softwire context, the voluntary 161 tunneling model applies. The Softwire Initiator (SI) at the home 162 network takes the role of the L2TP Access Concentrator (LAC) client 163 (initiating both the L2TP tunnel/session and PPP link) while the 164 Softwire Concentrator (SC) at the ISP takes the role of the L2TP 165 Network Server (LNS). Since L2TPv2 compulsory tunneling model does 166 not apply to Softwires, it should not be requested or honored. This 167 document identifies all the voluntary tunneling related L2TPv2 168 attributes that apply to Softwires and specifies the handling 169 mechanism for such attributes in order to avoid ambiguities in 170 implementations. This document also identifies the set of L2TPv2 171 attributes specific to compulsory tunneling model that do not apply 172 to Softwires and specifies the mechanism to ignore or nullify their 173 effect within the Softwires context. 175 The SI and SC must follow the L2TPv2 operations described in 176 [RFC2661] when performing Softwire establishment, tear-down and OAM. 177 With L2TPv2, a Softwire consists of an L2TPv2 Control Channel, a 178 single Session, and the PPP link negotiated over the Session. To 179 establish the Softwire, the SI first initiates an L2TPv2 Control 180 Channel to the SC which accepts the request and terminates the 181 Control Channel. L2TPv2 supports an optional mutual Control Channel 182 authentication which allows both SI and SC to validate each other's 183 identity at the initial phase of hand-shaking before proceeding with 184 Control Channel establishment. After the L2TPv2 Control Channel is 185 established between the SI and SC, the SI initiates an L2TPv2 Session 186 to the SC. Then the PPP/IP link is negotiated over the L2TPv2 187 Session between the SI and SC. After the PPP/IP link is established, 188 it acts as the Softwire between the SI and SC for tunneling IP 189 traffic of one Address Family across the access network of another 190 Address Family. 192 During the life of the Softwire, both SI and SC send L2TPv2 keepalive 193 HELLO messages to monitor the health of the Softwire and the peer 194 LCCE or to refresh the NAT/PAT translation entry at the CPE or at the 195 other end of the access link. Optionally, LCP ECHO messages can be 196 used as keepalives for the same purposes. In the event of keepalive 197 timeout or administrative shutdown of the Softwire, either SI or SC 198 may tear down the Softwire by tearing down the L2TPv2 Control Channel 199 and Session as specified in [RFC2661]. 201 1.1. Abbreviations 203 LCCE L2TP Control Connection Endpoint (See [RFC3931]) 205 SC Softwire Concentrator, the node terminating the Softwire in 206 the service provider network (See 207 [I-D.ietf-softwire-problem-statement]) 209 SI Softwire Initiator, the node initiating the Softwire within 210 the customer network (See 211 [I-D.ietf-softwire-problem-statement]) 213 STH Softwire Transport Header (See 214 [I-D.ietf-softwire-problem-statement]) 216 SPH Softwire Payload Header (See 217 [I-D.ietf-softwire-problem-statement]) 219 1.2. Requirements Language 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 223 document are to be interpreted as described in [RFC2119]. 225 1.3. Contributing Authors 227 Following is the complete list of contributors to this document. 229 Maria Alice Dos Santos 230 Carlos Pignataro 231 Bill Storer 232 Cisco Systems 233 Jean-Francois Tremblay 234 Hexago 235 Laurent Toutain 236 Bruno Stevant 237 GET/ENST Bretagne 239 1.4. Considerations 241 Some sections of this document contain considerations that are not 242 required for interoperability and correct operation of Softwire 243 implementations. These sections are marked as "Considerations". 245 2. Applicability of L2TPv2 for Softwire Requirements 247 A list of Softwire "Hubs and Spokes" requirements have been 248 identified by the Softwire Problem Statement 249 [I-D.ietf-softwire-problem-statement]. The following section 250 describes how L2TPv2 fulfills each of them. 252 2.1. Network and Port Address Translation (NAT/PAT) 254 A "Hubs and Spokes" Softwire must be able to traverse NAT/PAT in case 255 the scenario in question involves a non-upgradable pre-existing IPv4 256 home gateway performing NAT/PAT or some carrier equipment at the 257 other end of the access link performing NAT/PAT. The L2TPv2 Softwire 258 (i.e. Control Channel and Session) is capable of NAT/PAT traversal 259 since L2TPv2 can run over UDP. 261 Since L2TPv2 does not "autodetect" NAT/PAT along the path, L2TPv2 262 does not offer UDP bypass regardless of NAT/PAT presence. Both NAT/ 263 PAT "autodetect" and UDP bypass are optional requirements. 265 2.2. Scalability 267 In the "Hubs and Spokes" model, a carrier must be able to scale the 268 solution to millions of Softwire initiators by adding more hubs (i.e. 269 Softwire concentrators). L2TPv2 is a widely deployed protocol in 270 broadband services, and its scalability has been proven in multiple 271 large-scale IPv4 Virtual Private Network deployments which scale up 272 to millions of subscribers each. 274 2.3. Multicast 276 Multicast protocols simply run over L2TPv2 Softwires transparently 277 together with other regular IP traffic. 279 2.4. Authentication, Authorization and Accounting 281 L2TPv2 supports optional mutual Control Channel authentication and 282 leverages the optional mutual PPP per-session authentication. L2TPv2 283 is well integrated with AAA solutions (such as RADIUS) for both 284 authentication and authorization. Most L2TPv2 implementations 285 available in the market support logging of authentication and 286 authorization events. 288 L2TPv2 integration with RADIUS accounting (RADIUS Accounting 289 extension for tunnel [RFC2867]) allows the collection and reporting 290 of L2TPv2 Softwire usage statistics. 292 2.5. Privacy, Integrity, and Replay Protection 294 Since L2TPv2 runs over IP/UDP in the Softwire context, IPSec ESP can 295 be used in conjunction to provide per-packet authentication, 296 integrity, replay protection and confidentiality for both L2TPv2 297 control and data traffic [RFC3193] and [RFC3948]. 299 For Softwire deployments in which full payload security is not 300 required, the L2TPv2 built-in Control Channel authentication and the 301 inherited PPP authentication and PPP Encryption Control Protocol can 302 be considered. 304 2.6. Operations and Management (OAM) 306 L2TPv2 supports an optional in-band keepalive mechanism which injects 307 HELLO control messages after a specified period of time has elapsed 308 since the last data or control message was received on a tunnel. If 309 the HELLO control message is not reliably delivered, then the Control 310 Channel and its session will be torn down. In the Softwire context, 311 the L2TPv2 keepalive is used to monitor the connectivity status 312 between the SI and SC and/or as a refresh mechanism for any NAT/PAT 313 translation entry along the access link. 315 LCP ECHO offers a similar mechanism to monitor the connectivity 316 status, as described in [RFC1661]. Softwires implementations SHOULD 317 use L2TPv2 Hello keepalives and in addition MAY use PPP LCP Echo 318 messages to ensure Dead End Detection and/or to refresh NAT/PAT 319 translation entries. The combination of these two mechanisms can be 320 used as an optimization. 322 L2TPv2 MIB [RFC3371] supports the complete suite of management 323 operations such as configuration of Control Channel and Session, 324 polling of Control Channel and Session status and their traffic 325 statistics and notifications of Control Channel and Session UP/DOWN 326 events. 328 2.7. Encapsulations 330 L2TPv2 supports the following encapsulations: 332 o IPv6/PPP/L2TPv2/UDP/IPv4 334 o IPv4/PPP/L2TPv2/UDP/IPv6 336 o IPv4/PPP/L2TPv2/UDP/IPv4 338 o IPv6/PPP/L2TPv2/UDP/IPv6 339 Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not 340 support "autodetect" of NAT/PAT. 342 3. Deployment Scenarios 344 For the "Hubs and Spokes" problem space, four scenarios have been 345 identified. In each of these four scenarios, different home 346 equipment plays the role of the Softwire Initiator. This section 347 elaborates each scenario with L2TPv2 as the Softwire protocol and 348 other possible protocols involved to complete the solution. This 349 section examines the four scenarios for both IPv6 over IPv4 and IPv4 350 over IPv6 encapsulations. 352 3.1. IPv6 over IPv4 Softwire with L2TPv2 354 The following subsections cover IPv6 connectivity across an IPv4-only 355 access network using a Softwire. 357 3.1.1. Host CPE as Softwire Initiator 359 Softwire initiator is the host CPE (directly connected to a modem), 360 which is dual-stack. There is no other gateway device. The IPv4 361 traffic should not traverse the softwire. 363 In this scenario, IPv6CP negotiates IPv6 over PPP which also provides 364 the capability for the ISP to assign the 64-bit Interface Id to the 365 host CPE or perform uniqueness validation for the two Interface Ids 366 at the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor 367 Discovery runs over the IPv6 over PPP link, and the LNS can assign a 368 64-bit global prefix to the host CPE via Router Advertisement (RA) 369 while other configuration options (such as DNS) can be conveyed to 370 the host CPE via DHCPv6/v4. 372 IPv6 or dual-stack IPv4-only dual-stack 373 |------------------||-----------------||----------| 375 I SC SI 376 N +-----+ +----------+ 377 T | | | v4/v6 | 378 E <==[ IPv6 ]....|v4/v6|....[IPv4~only]....| host CPE | 379 R [network] | | [ network ] | | 380 N | LNS | |LAC Client| 381 E +-----+ +----------+ 382 T _ _ _ _ _ _ _ _ _ 383 ()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic 384 PPP o L2TPv2 o UDP o IPv4 385 Softwire 387 <------------------> 388 IPv6CP: capable of /64 intf Id assignment or 389 uniqueness check 391 |------------------>/64 prefix 392 RA 393 |------------------>DNS, etc. 394 DHCPv6/v4 396 Figure 1: Host CPE as Softwire Initiator 398 3.1.2. Router CPE as Softwire Initiator 400 Softwire initiator is the router CPE, which is a dual-stack device. 401 The IPv4 traffic should not traverse the Softwire. 403 In this scenario, IPv6CP negotiates IPv6 over PPP which also provides 404 the capability for the ISP to assign the 64-bit Interface Id to the 405 router CPE or perform uniqueness validation for the two Interface Ids 406 at the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor 407 Discovery runs over the IPv6 over PPP link, and the LNS can assign a 408 64-bit global prefix to the router CPE via Router Advertisement (RA). 409 DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g. delegating 410 a 48-bit prefix to be used within the home network) and convey other 411 configuration options (such as DNS) to the router CPE. 413 IPv6 or dual-stack IPv4-only dual-stack 414 |------------------||-----------------||---------------------| 416 I SC SI 417 N +-----+ +----------+ 418 T | | | v4/v6 | +-----+ 419 E <==[ IPv6 ]....|v4/v6|....[IPv4~only]....| CPE |----|v4/v6| 420 R [network] | | [ network ] | | | host| 421 N | LNS | |LAC Client| +-----+ 422 E +-----+ +----------+ 423 T _ _ _ _ _ _ _ _ _ 424 ()_ _ _ _ _ _ _ _ _() <-------- IPv6 traffic 425 PPP o L2TPv2 o UDP o IPv4 426 Softwire 428 <------------------> 429 IPv6CP: capable of /64 intf Id assignment or 430 uniqueness check 432 |------------------>/64 prefix 433 RA 434 |------------------>/48 prefix, 435 DHCPv6 DNS, etc. 437 |------->/64 prefix 438 RA 439 |-------> DNS, etc. 440 DHCPv4/v6 442 Figure 2: Router CPE as Softwire Initiator 444 3.1.3. Host behind CPE as Softwire Initiator 446 The CPE is IPv4-only. Softwire initiator is a dual-stack host 447 (behind IPv4- only CPE), which acts as an IPv6 host CPE. The IPv4 448 traffic should not traverse the Softwire. 450 In this scenario, IPv6CP negotiates IPv6 over PPP which also provides 451 the capability for the ISP to assign the 64-bit Interface Id to the 452 host or perform uniqueness validation for the two Interface Ids at 453 the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor 454 Discovery runs over the IPv6 over PPP link, and the LNS can assign a 455 64-bit global prefix to the host via Router Advertisement (RA) while 456 other configuration options (such as DNS) can be conveyed to the host 457 via DHCPv6/v4. 459 IPv6 or dual-stack IPv4-only dual-stack 460 |------------------||----------------------------||----------| 462 I SC SI 463 N +-----+ +----------+ 464 T | | +-------+ | v4/v6 | 465 E <==[ IPv6 ]....|v4/v6|....[IPv4~only]....|v4-only|--| host | 466 R [network] | | [ network ] | CPE | | | 467 N | LNS | +-------+ |LAC Client| 468 E +-----+ +----------+ 469 T _ _ _ _ _ _ _ _ _ _ _ _ _ _ 470 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6 471 PPP o L2TPv2 o UDP o IPv4 traffic 472 Softwire 474 <------------------------------> 475 IPv6CP: capable of /64 intf Id assignment or 476 uniqueness check 478 |------------------------------>/64 prefix 479 RA 480 |------------------------------>DNS, etc. 481 DHCPv4/v6 483 Figure 3: Host behind CPE as Softwire Initiator 485 3.1.4. Router behind CPE as Softwire Initiator 487 The CPE is IPv4-only. Softwire initiator is a dual-stack device 488 (behind the IPv4-only CPE) acting as an IPv6 CPE router inside the 489 home network. The IPv4 traffic should not traverse the Softwire. 491 In this scenario, IPv6CP negotiates IPv6 over PPP which also provides 492 the capability for the ISP to assign the 64-bit Interface Id to the 493 v4/v6 router or perform uniqueness validation for the two Interface 494 Ids at the two PPP ends [RFC2472]. After IPv6 over PPP is up, 495 Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can 496 assign a 64-bit global prefix to the v4/v6 router via Router 497 Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix 498 Delegation (for example, delegating a 48-bit prefix to be used within 499 the home network) and convey other configuration options (such as 500 DNS) to the v4/v6 router. 502 IPv6 or dual-stack IPv4-only dual-stack 503 |------------------||-------------------------||-------------| 505 I SC SI 506 N +-----+ +----------+ 507 T | | +-------+ | v4/v6 | 508 E <==[ IPv6 ]....|v4/v6|..[IPv4~only]..|v4-only|---| router | 509 R [network] | | [ network ] | CPE | | | | 510 N | LNS | +-------+ | |LAC Client| 511 E +-----+ | +----------+ 512 T | 513 ---------+-----+ 514 |v4/v6| 515 | host| 516 _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ 517 ()_ _ _ _ _ _ _ _ _ _ _ _ _() <--IPv6 traffic 518 PPP o L2TPv2 o UDP o IPv4 519 Softwire 521 <---------------------------> 522 IPv6CP: capable of /64 intf Id assignment or 523 uniqueness check 525 |--------------------------->/64 prefix 526 RA 527 |--------------------------->/48 prefix, 528 DHCPv6 DNS, etc. 530 |----> /64 531 RA prefix 532 |----> DNS, 533 DHCPv4/v6 etc. 535 Figure 4: Router behind CPE as Softwire Initiator 537 3.2. IPv4 over IPv6 Softwire with L2TPv2 539 The following subsections cover IPv4 connectivity across an IPv6-only 540 access network using a Softwire. 542 3.2.1. Host CPE as Softwire Initiator 544 Softwire initiator is the host CPE (directly connected to a modem), 545 which is dual-stack. There is no other gateway device. The IPv6 546 traffic should not traverse the Softwire. 548 In this scenario, IPCP negotiates IPv4 over PPP which also provides 549 the capability for the ISP to assign a global IPv4 address to the 550 host CPE. Global IPv4 address can also be assigned via DHCP. Other 551 configuration options (such as DNS) can be conveyed to the host CPE 552 via IPCP [RFC1877] or DHCP. 554 IPv4 or dual-stack IPv6-only dual-stack 555 |------------------||-----------------||---------| 557 I SC SI 558 N +-----+ +----------+ 559 T | | | v4/v6 | 560 E <==[ IPv4 ]....|v4/v6|....[IPv6~only]....| host CPE | 561 R [network] | | [ network ] | | 562 N | LNS | |LAC Client| 563 E +-----+ +----------+ 564 T _ _ _ _ _ _ _ _ _ 565 ()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic 566 PPP o L2TPv2 o UDP o IPv6 567 Softwire 569 <------------------> 570 IPCP: capable of global IP assignment 571 and DNS, etc. 573 Figure 5: Host CPE as Softwire Initiator 575 3.2.2. Router CPE as Softwire Initiator 577 IPv4 connectivity across an IPv6-only access network (STH). Softwire 578 initiator is the router CPE, which is a dual-stack device. The IPv6 579 traffic should not traverse the Softwire. 581 In this scenario, IPCP negotiates IPv4 over PPP which also provides 582 the capability for the ISP to assign a global IPv4 address to the 583 router CPE. Global IPv4 address can also be assigned via DHCP. 584 Other configuration options (such as DNS) can be conveyed to the 585 router CPE via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation 586 for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used. 588 IPv4 or dual-stack IPv6-only dual-stack Home 589 |------------------||-----------------||-------------------| 591 I SC SI 592 N +-----+ +----------+ 593 T | | | v4/v6 | +-----+ 594 E <==[ IPv4 ]....|v4/v6|....[IPv6~only]....| CPE |--|v4/v6| 595 R [network] | | [ network ] | | | host| 596 N | LNS | |LAC Client| +-----+ 597 E +-----+ +----------+ 598 T _ _ _ _ _ _ _ _ _ 599 ()_ _ _ _ _ _ _ _ _() <--------- IPv4 traffic 600 PPP o L2TPv2 o UDP o IPv6 601 Softwire 603 <------------------> 604 IPCP: capable of global IP assignment 605 and DNS, etc. 607 |------------------> 608 DHCPv4: prefix, mask, PD 610 private/ 611 |------> global 612 DHCP IP, DNS, 613 etc. 615 Figure 6: Router CPE as Softwire Initiator 617 3.2.3. Host behind CPE as Softwire Initiator 619 IPv4 connectivity across an IPv6-only access network (STH). The CPE 620 is IPv6-only. Softwire initiator is a dual-stack host (behind the 621 IPv6 CPE), which acts as an IPv4 host CPE. The IPv6 traffic should 622 not traverse the Softwire. 624 In this scenario, IPCP negotiates IPv4 over PPP which also provides 625 the capability for the ISP to assign a global IPv4 address to the 626 host. Global IPv4 address can also be assigned via DHCP. Other 627 configuration options (such as DNS) can be conveyed to the host CPE 628 via IPCP [RFC1877] or DHCP. 630 IPv4 or dual-stack IPv6-only dual-stack 631 |------------------||----------------------------||----------| 633 I SC SI 634 N +-----+ +----------+ 635 T | | +-------+ | v4/v6 | 636 E <==[ IPv4 ]....|v4/v6|....[IPv6~only]....|v6-only|--| host | 637 R [network] | | [ network ] | CPE | | | 638 N | LNS | +-------+ |LAC Client| 639 E +-----+ +----------+ 640 T _ _ _ _ _ _ _ _ _ _ _ _ _ _ 641 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv4 642 PPP o L2TPv2 o UDP o IPv6 traffic 643 Softwire 645 <------------------------------> 646 IPCP: capable of global IP assignment 647 and DNS, etc. 649 Figure 7: Host behind CPE as Softwire Initiator 651 3.2.4. Router behind CPE as Softwire Initiator 653 IPv4 connectivity across an IPv6-only access network (STH). The CPE 654 is IPv6-only. Softwire initiator is a dual-stack device (behind the 655 IPv6-only CPE) acting as an IPv4 CPE router inside the home network. 656 The IPv6 traffic should not traverse the Softwire. 658 In this scenario, IPCP negotiates IPv4 over PPP which also provides 659 the capability for the ISP to assign a global IPv4 IP address to the 660 v4/v6 router. Global IPv4 address can also be assigned via DHCP. 661 Other configuration options (such as DNS) can be conveyed to the 662 v4/v6 router via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation 663 for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used. 665 IPv4 or dual-stack IPv6-only dual-stack 666 |------------------||-------------------------||------------| 668 I SC SI 669 N +-----+ +----------+ 670 T | | +-------+ | v4/v6 | 671 E <==[ IPv4 ]....|v4/v6|..[IPv6~only]..|v6-only|---| router | 672 R [network] | | [ network ] | CPE | | | | 673 N | LNS | +-------+ | |LAC Client| 674 E +-----+ | +----------+ 675 T | 676 --------+-----+ 677 |v4/v6| 678 | host| 679 _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ 680 ()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- IPv4 681 PPP o L2TPv2 o UDP o IPv4 traffic 682 Softwire 684 <---------------------------> 685 IPCP: assigns global IP address and DNS, etc. 687 |---------------------------> 688 DHCPv4: prefix, mask, PD 690 private/ 691 |----> global 692 DHCP IP, DNS, 693 etc. 695 Figure 8: Router behind CPE as Softwire Initiator 697 4. Standardisation Status 699 4.1. Softwire Transport Related 701 RFC 3193 Securing L2TP using IPsec. 703 RFC 3948 UDP Encapsulation of IPsec ESP Packets. 704 IPSec supports both IPv4 and IPv6 transports. 706 4.2. L2TPv2 708 RFC 2661 Layer Two Tunneling Protocol "L2TP". 709 For both IPv4 and IPv6 payloads, support is complete. 710 For both IPv4 and IPv6 transport, support is complete. 712 4.3. Authentication Authorization Accounting 714 RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol 715 Support. 717 RFC 2865 Remote Authentication Dial In User Service (RADIUS). 719 RFC 3162 RADIUS and IPv6. 721 4.4. MIB 723 RFC 3371 Layer Two Tunneling Protocol "L2TP" Management Information 724 Base. 726 RFC 4087 IP Tunnel MIB. 727 Both IPv4 and IPv6 transport is supported. 729 4.5. Softwire Payload Related 731 4.5.1. For IPv6 Payloads 733 RFC 2472 IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2]. 735 RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). 737 RFC 3646 DNS Configuration options for Dynamic Host Configuration 738 Protocol for IPv6 (DHCPv6). 740 RFC 2461 Neighbor Discovery for IP Version 6 (IPv6). 742 4.5.2. For IPv4 Payloads 744 RFC 1661 The Point-to-Point Protocol (PPP). 746 RFC 1332 The PPP Internet Protocol Control Protocol (IPCP). 748 DHCP Subnet Allocation 749 Work in progress [I-D.ietf-dhc-subnet-alloc]. 751 5. Softwire Establishment 753 A Softwire is established in 3 distinct steps (Figure 9). First a 754 L2TPv2 tunnel with a single session is established from the SI to the 755 SC. Second a PPP session is established over the L2TPv2 session and 756 the SI obtains an address. Third the SI optionally gets other 757 information through DHCP such as a delegated prefix and DNS servers. 759 SC SI 760 | | 761 |<-------------L2TPv2------------>| Step 1 762 | | L2TPv2 Tunnel establishment 763 | | 764 |<-------------PPP--------------->| Step 2 765 |<----End Point Configuration---->| PPP and End Point 766 | | configuration 767 | | 768 |<------Router Configuration----->| Step 3 769 | | Additional configuration 770 | | (optional) 772 Figure 9: Steps for the Establishment of a Softwire 774 In the following diagram (Figure 10), each of the three steps 775 required to establish a Softwire is described in detail. 777 SC SI 778 | | 779 | | Step 1 780 |<------------SCCRQ---------------| - 781 |-------------SCCRP-------------->| | 782 |<------------SCCCN---------------| | 783 |<------------ICRQ----------------| | L2TPv2 784 |-------------ICRP--------------->| | 785 |<------------ICCN----------------| - 786 | | 787 | | Step 2 788 |<-----Configuration-Request------| - 789 |------Configuration-Request----->| | PPP 790 |<-------Configuration-Ack--------| | LCP 791 |--------Configuration-Ack------->| - 792 | | 793 |-----------Challenge------------>| - PPP Authentication 794 |<----------Response--------------| | (Optional - CHAP) 795 |------------Success------------->| - 796 | | 797 |<-----Configuration-Request------| - 798 |------Configuration-Request----->| | PPP NCP 799 |<-------Configuration-Ack--------| | (IPV6CP or IPCP) 800 |--------Configuration-Ack------->| - 801 | | 802 |<------Router-Solicitation-------| - Neighbor Discovery 803 |-------Router-Advertisement----->| | (IPv6 only) 804 | | - 805 | | 806 | | Step3 807 |<-----------Solicit--------------| - 808 |-----------Advertise------------>| | DHCP 809 |<---------- Request--------------| | (Optional) 810 |-------------Reply-------------->| - 812 Figure 10: Detailed Steps in the Establishment of a Softwire 814 5.1. L2TPv2 Tunnel Setup 816 L2TPv2 [RFC2661] was originally designed to provide private network 817 access to end users connected to a public network. In the L2TPv2 818 model, the end user makes a connection to an L2TP Access Concentrator 819 (LAC). The LAC then initiates an L2TPv2 tunnel to an L2TP Network 820 Server (LNS). The LNS then transfers end user traffic between the 821 L2TPv2 tunnel and the private network. 823 In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI) 824 assumes the role of the LAC and the Softwire Concentrator assumes the 825 role of the LNS. 827 In the Softwire model, an L2TPv2 packet MUST be carried over UDP. 828 The underlying version of the IP protocol may be IPv4 or IPv6, 829 depending on the Softwires scenario. 831 5.1.1. Tunnel Establishment 833 The following diagram, (Figure 11), describes messages exchanged and 834 AVPs used to establish a tunnel between an SI (LAC) and an SC (LNS). 835 The messages and AVPs described here are only a subset of those 836 defined in [RFC2661]. This is because Softwires uses only a subset 837 of the L2TPv2 functionality. One session per tunnel is needed. Note 838 that in the Softwires environment, the SI always initiates the 839 tunnel. No outgoing or analog calls are permitted. L2TPv2 840 attributes SHOULD NOT be hidden. 842 SCCRQ 843 Mandatory AVP 844 Message Type 845 Protocol Version 846 Host Name 847 Framing Capabilities 848 Assigned Tunnel ID 849 Optional AVP: 850 Receive Window Size 851 Firmware Revision 852 Vendor Name 853 (Challenge) 855 SCCRP 856 Mandatory AVP: 857 Message Type 858 Protocol Version 859 Framing Capabilities 860 Host Name 861 Assigned Tunnel ID 862 Optional AVP: 863 Firmware Revision 864 Vendor Name 865 Receive Window Size 866 (Challenge Response) 867 (Challenge) 869 SCCCN 870 Mandatory AVP: 871 Message Type 872 (Challenge Response) 874 Figure 11: Tunnel Establishment 876 In L2TPv2, the tunnel between a LAC and LNS may carry the data of 877 multiple users. Each of these user's is represented by an L2TPv2 878 session within the tunnel. In the Softwires environment, the tunnel 879 carries the information of a single user. So, there is only one 880 L2TPv2 session per tunnel. The following diagram, (Figure 12), 881 describes messages exchanged and AVPs used to establish a session 882 between an SI (LAC) and an SC (LNS). The messages and AVPs described 883 here are only a subset of those defined in [RFC2661]. This is 884 because Softwires uses only a subset of the L2TPv2 functionality. 885 Note that in the Softwires environment, the SI always initiates the 886 session. No outgoing or analog calls are permitted. L2TPv2 887 attributes SHOULD NOT be hidden. 889 ICRQ 890 Mandatory AVP: 891 Message Type 892 Assigned Session ID 893 Call Serial Number 895 ICRP 896 Mandatory AVP: 897 Message Type 898 Assigned Session ID 900 ICCN 901 Mandatory AVP: 902 Message Type 903 (Tx) Connect Speed 904 Framing Type 906 Figure 12: Session Establishment 908 5.1.1.1. AVPs Required for Softwires 910 This paragraph specifies specific values for AVPs used in the 911 Softwires context. 913 Host Name AVP 915 This AVP is mandatory and is present in SCCRQ and SCCRP messages. 916 This AVP may be used to authenticate users, in which case it would 917 contain a user identification. If this AVP is not used to 918 authenticate users, it may be used for documention. 920 Framing Capabilities AVP 922 Synchronous bit SHOULD be set to 1 and Asynchronous bit to 1. 923 This AVP SHOULD be ignored by the receiver. 925 Framing Type AVP 927 Synchronous bit SHOULD be set to 1 and Asynchronous bit to 0. 928 This AVP SHOULD be ignored by the receiver. 930 (Tx) Connect Speed 932 (Tx) Connect Speed is a mandatory AVP but is not meaningful in the 933 Softwires context. It SHOULD be left to 0 and ignored by the 934 receiver. 936 Assigned Tunnel ID, Receive Window Size, Firmware Revision, Vendor 937 Name, Call Serial Number, and Assigned Session ID 939 As defined in [RFC2661] 941 5.1.1.2. AVPs Optional for Softwires 943 Challenge and Challenge Response AVPs 945 These AVPs are not required, but are necessary to implement tunnel 946 authentication. Since tunnel authentication happens at the 947 beginning of L2TPv2 tunnel creation, it can be helpful in 948 preventing DoS attacks. 950 5.1.1.3. AVPs not Relevant for Softwires 952 L2TPv2 specifies numerous AVPs that, while allowed for a given 953 command, are irrelevant to a Softwires. Softwires implementations 954 should not send these AVPs. However, they should ignore them when 955 they are received. This will make it easier to create Softwires 956 applications on top of existing L2TPv2 implementations. 958 5.1.2. Tunnel Maintenance 960 Periodically, the SI MUST transmit a message to the SC to maintain 961 NAT/PAT contexts and detect tunnel failure. The L2TPv2 HELLO message 962 provides a simple, low overhead method of doing this. 964 The default values specified in [RFC2661] for L2TPv2 HELLO messages 965 could result in a dead end detection time of 83 seconds. Although 966 these retransmission timers and counters SHOULD be configurable (see 967 [RFC2661]), these values may not be adapted for all situations, where 968 a quicker dead end detection is required, or where NAT/PAT context 969 needs to be refreshed more frequently. In such cases, the SI MAY 970 use, in combination with L2TPv2 HELLO, LCP ECHO messages (Echo- 971 Request and Echo-Reply codes) described in [RFC1661] which timeout 972 could be configured to a lower value. When used, LCP ECHO messages 973 SHOULD have a re-emission timer lower than the value for L2TPv2 HELLO 974 hello messages. 976 5.1.3. Tunnel Teardown 978 Either the SI or SC can teardown the session and tunnel. This is 979 done as specified in [RFC2661]. There is no action specific to 980 Softwires in this case. 982 5.2. PPP Connection 984 5.2.1. MTU 986 The MTU of the PPP link SHOULD be the link MTU minus the size of the 987 IP, UDP, L2TPv2, and PPP headers together. On an IPv4 link with an 988 MTU equal to 1500 bytes, this would usually mean a PPP MTU of 1460 989 bytes. This may vary according to the size of the L2TP header. See 990 [RFC4623] for a detailed discussion of fragmentation issues. 992 5.2.2. LCP 994 Once the L2TPv2 session is established, the SI and SC initiate the 995 PPP connection by negotiating LCP as described in [RFC1661]. ACFC 996 [RFC1662] SHOULD be rejected. 998 5.2.3. Authentication 1000 After completing LCP negotiation, the SI and SC may optionally 1001 perform authentication. If authentication is chosen, CHAP [RFC1994] 1002 authentication MUST be supported by both the Softwire Initiator and 1003 Softwire Concentrator. Other authentication methods such as MS- 1004 CHAPv1 [RFC2433], and EAP [RFC3748] MAY be supported. 1006 A detailed discussion of Softwires security is contained in 1007 [I-D.ietf-softwire-security-requirements] 1009 5.2.4. IPCP 1011 5.2.4.1. IPv6CP 1013 In the IPv6 over IPv4 scenarios (see Section 3.1), after the 1014 authentication phase, the Softwire Initiator MUST negotiate IPv6CP as 1015 defined in [RFC2472]. IPv6CP provides a way to negotiate a unique 1016 64-bit interface identifier to be used for the address 1017 autoconfiguration at the local end of the link. 1019 5.2.4.2. IPv4CP 1021 In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire 1022 Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain 1023 an IPv4 address from the SC. IPCP may also be used to obtain DNS 1024 information as described in [RFC1877]. 1026 5.3. Global IPv6 Address Assignement to Endpoints 1028 In several scenario defined in Section 3, Global IPv6 addresses are 1029 expected to be allocated to Softwires end points. Since IPv6CP only 1030 provide Link-Local addresses (see [RFC2472]), IPv6 Neighbor Discovery 1031 [RFC2462] or DHCPv6 [RFC3315] SHOULD be used to configure these 1032 addresses. 1034 The Softwire Initiator of an IPv6 Softwire MUST send a Router 1035 Solicitation message to the Softwire Concentrator after IPV6CP is 1036 completed. The Softwire Concentrator MUST answer with a Router 1037 Advertisement. This message MUST contains the global IPv6 prefix of 1038 the PPP link if Neighbor discovery is used to configure addresses of 1039 Softwire end points. 1041 If DHCPv6 is available for address delegation, the M bits of the 1042 Router Advertisement SHOULD be set. The Softwire Initiator MUST then 1043 send a DHCPv6 Request to configure the address of the Softwire 1044 endpoint. 1046 Duplicate Address Detection ([I-D.ietf-ipv6-2461bis]) MUST be 1047 performed on the Softwire in both cases. 1049 5.4. DHCP 1051 The Softwire Initiator MAY use DHCP to get additional information 1052 such as delegated prefix and DNS servers. If the SI supports DHCP, 1053 it SHOULD send a Solicit message to verify if more information is 1054 available. 1056 When delegating an IPv4 prefix to the SI, the SC SHOULD inject a 1057 route for this prefix in the IPv4 routing table in order to forward 1058 the traffic to the relevant Softwire. 1060 5.4.1. DHCPv6 1062 IF a SI establishing an IPv6 Softwire acts as a router (scenarios 1063 3.1.2 and 3.1.4) it MUST include the IA_PD option [RFC3633] in the 1064 DHCPv6 Solicit message [RFC3315] in order to request an IPv6 prefix. 1066 When delegating an IPv6 prefix to the SI, the SC SHOULD inject a 1067 route for this prefix in the IPv4 routing table in order to forward 1068 the traffic to the relevant Softwire. 1070 5.4.2. DHCPv4 1072 A SI establishing an IPv4 Softwire MAY send a DHCP request containing 1073 the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc]. This 1074 practice is not common but may be used to connect IPv4 subnets using 1075 Softwires, as defined in Section 3.2.2 and Section 3.2.4. 1077 One Subnet-Request suboption MUST be configured with the 'h' bit set 1078 to '1', as the SI is expected to perform the DHCP server function. 1079 The 'i' bit of the Subnet-Request suboption should be set to '0' the 1080 first time a prefix is requested and to '1' on subsequent requests, 1081 if a prefix has been allocated. The Prefix length suboption SHOULD 1082 be 0 by default. If the SI is configured to support only specific 1083 prefix lengths, it should specify the longest (smallest) prefix 1084 length it supports. 1086 If the SI was previously assigned a prefix from that same SC, it 1087 SHOULD include the Subnet Information suboption with the prefix it 1088 was previously assigned. The 'c' and 's' bits of the suboption 1089 SHOULD be set to '0'. 1091 6. Considerations about the Address Provisioning Model 1093 This section describes how a Softwire Concentrator may manage 1094 delegated addresses for Softwire endpoints and for subnets behind the 1095 Softwire Initiator. One common practice is to aggregate endpoints 1096 addresses and delegated prefixes into one prefix routed to the SC. 1097 The main benefit is to ease the routing scheme by isolating on the SC 1098 succeeding route injections (when delegating new prefixes for SI). 1100 6.1. Softwire Endpoints Addresses 1102 6.1.1. IPv6 1104 A Softwire Concentrator should provide globally routable addresses to 1105 Softwire endpoints. Other types of addresses such as Unique Local 1106 Addresses [RFC4193] may be used to address Softwire end points in a 1107 private network with no global connectivity. A single /64 should be 1108 assigned to the Softwire to address both Softwire endpoints. 1110 Global or ULA addresses must be assigned to endpoints when the 1111 scenario "Host CPE as Softwire Initiator" (described in 1112 Section 3.1.1) is considered to be deployed. For other scenarios, 1113 this may be optional and link local addresses should be used. 1115 6.1.2. IPv4 1117 A Softwire Concentrator may provide either globally routable or 1118 private IPv4 addresses. When using IPv4 private addresses [RFC1918] 1119 on the endpoints, it is not not recommended to delegate an IPv4 1120 private prefix to the SI, as it can lead to a nested-NAT situations. 1122 The endpoints of the PPP link use host addresses (i.e., /32), 1123 negotiated using IPCP. 1125 6.2. Delegated Prefixes 1127 6.2.1. IPv6 Prefixes 1129 Delegated IPv6 should be of global scope if assigned IPv6 addresses 1130 for endpoints are global. Using ULA addresses is not recommended 1131 when subnet is connected to the global IPv6 Internet. When using ULA 1132 IPv6 address for endpoint, Delegated IPv6 prefix may be either of 1133 Global or ULA scope. 1135 Delegated IPv6 prefixes are between /48 and /64 in length. When a SI 1136 receives a prefix shorter than 64, it can assign different /64 1137 prefixes to each of its interfaces. A SI receiving a single /64 is 1138 expected to perform bridging if more than one interface are available 1139 (wired and wireless for example). 1141 6.2.2. IPv4 Prefixes 1143 Delegated IPv4 prefixes should be of the same scope than the assigned 1144 IPv4 addresses and be routable within that address space. Prefix 1145 length is between /8 and /30. 1147 6.3. Possible scenarios 1149 This section summarizes the differents scenarios for address 1150 provisioning with the considerations given in the previous sections. 1152 6.3.1. Scenarios for IPv6 1154 This table describes the possible combination of IPv6 address scope 1155 for endpoints and delegated prefixes. 1157 +------------------+-----------------------+------------------------+ 1158 | Endpoint IPv6 | Delegated Global IPv6 | Delegated ULA IPv6 | 1159 | Address | Prefix | Prefix | 1160 +------------------+-----------------------+------------------------+ 1161 | Link Local | Possible | Possible | 1162 | | | | 1163 | ULA | Possible | Possible | 1164 | | | | 1165 | Global | Possible | Possible, but Not | 1166 | | | Recommended | 1167 +------------------+-----------------------+------------------------+ 1169 Table 1: Scenarios for IPv6 1171 6.3.2. Scenarios for IPv4 1173 This table describes the possible combination of IPv6 address scope 1174 for endpoints and delegated prefixes. 1176 +------------------+-----------------------+------------------------+ 1177 | Endpoint IPv4 | Delegated Public IPv4 | Delegated Private IPv4 | 1178 | Address | Prefix | Prefix | 1179 +------------------+-----------------------+------------------------+ 1180 | Private IPv4 | Possible | Possible, but Not | 1181 | | | Recommended | 1182 | | | | 1183 | Public IPv4 | Possible | Possible | 1184 +------------------+-----------------------+------------------------+ 1186 Table 2: Scenarios for IPv4 1188 7. Considerations about Address Stability 1190 A Softwire can provide stable addresses even if the underlying 1191 addressing scheme changes, by opposition to automatic tunneling. A 1192 Softwire Concentrator should always provide the same address and 1193 prefix to a reconnecting user. However, if the goal of the Softwire 1194 service is to provide a temporary address for a roaming user, it may 1195 be provisioned to provide only a temporary address. 1197 The address and prefix are expected to change when reconnecting to a 1198 different Softwire Concentrator. However an organization providing a 1199 Softwire service may provide the same address and prefix across 1200 different Softwire Concentrators at the cost of a more fragmented 1201 routing table. The routing fragmentation issue may be limited if the 1202 prefixes are aggregated in a location topologically close to the SC. 1203 This would be the case for example if several SCs are put in parallel 1204 for load-balancing purpose. 1206 8. Considerations about RADIUS Integration 1208 The Softwire Concentrator is expected to act as a client to a AAA 1209 server, for example a RADIUS server. During the PPP authentication 1210 phase, the RADIUS server may return additional informations in the 1211 form of attributes in the Access Accept message. 1213 The Softwire Concentrator may include the Tunnel-Type and Tunnel- 1214 Medium-Type attributes [RFC2868] in the Access Request messages to 1215 provide a hint of the type of Softwire being configured. 1217 8.1. Softwires Endpoints 1219 8.1.1. IPv6 Softwires 1221 If the RADIUS server includes a Framed-Interface-Id attribute 1222 [RFC3162], the Softwire Concentrator must send it to the Softwire 1223 Initiator in the Interface Identifier field of its IPV6CP 1224 Configuration Request message. 1226 If the Framed-IPv6-Prefix attribute is mentioned [RFC3162], that 1227 prefix MUST be used in the router advertisements sent to the SI. If 1228 Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC 1229 must choose a prefix with that pool to send RAs. 1231 If none of the attributes above are included but the AAA server 1232 returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint 1233 attributes [RFC2868] are present and of the correct address family, 1234 these must be used in the IPV6CP Interface Identifier and for the 1235 router advertisements. 1237 8.1.2. IPv4 Softwires 1239 If the Framed-IP-Address attribute [RFC2865] is present, the Softwire 1240 Concentrator must provide that address to the Softwire Initiator 1241 during IPCP address negotiation. That is, when the Softwire 1242 Initiator requests an IP address from the Softwire Concentrator, the 1243 address provided should be the Framed-IP-Address. 1245 If the Framed-IP-Address attribute is not present and the Tunnel- 1246 Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are 1247 present and of the correct address family, these should be used in 1248 the IPCP IP-Address configuration option. 1250 8.2. Delegated Prefixes 1251 8.2.1. IPv6 Prefixes 1253 If the attribute Delegated-IPv6-Prefix 1254 [I-D.ietf-radext-delegated-prefix] is present in the RADIUS Access 1255 Accept message, it must be used by the Softwire Concentrator for the 1256 delegation of the IPv6 prefix. Since the prefix delegation is 1257 performed by DHCPv6 and the attribute is linked to a username, the SC 1258 must associate the DUID of a DHCPv6 request to tunnel it came from 1259 and its user. 1261 Interaction between RADIUS, PPP and DHCPv6 server may follow the 1262 mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. During the 1263 Softwire authentication phase, PPP collects the RADIUS attributes for 1264 the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is 1265 assigned to the Softwire and fill these attributes in RRAO (Relay 1266 Agent RADIUS Attribute Option) into succeeding DHCPv6 requests from 1267 the client before forwarding them to the DHCPv6 server. 1269 8.2.2. IPv4 Prefixes 1271 The combination of the Framed-IP-Address and Framed-IP-Netmask 1272 attributes [RFC2865] may be used by the Softwire Concentrator to 1273 delegate an IPv4 prefix to the Softwire Initiator. 1275 9. Considerations for Maintenance and Statistics 1277 9.1. RADIUS Accounting 1279 RADIUS Accounting for L2TP and PPP are documented (see Section 4.3). 1281 When deploying Softwires solutions, operators may experience 1282 difficulties to differentiate the address family of the traffic 1283 reported in accounting information from RADIUS. This problem and 1284 some potential solutions are described in 1285 [I-D.stevant-softwire-accounting]. 1287 9.2. MIBs 1289 MIB support for L2TPv2 and PPP are documented (see Section 4.4). 1290 Also see [RFC4293] 1292 10. Security Considerations 1294 A detailed discussion of Softwires security is contained in 1295 [I-D.ietf-softwire-security-requirements]. 1297 The L2TPv2 Softwires solution provides the following tools for 1298 security: 1300 o IPsec [RFC3193] provides the highest level of security. 1302 o PPP CHAP [RFC1994] provides basic user authentication. 1304 o L2TP Tunnel Authentication [RFC2661] provides authentication at 1305 tunnel setup. It may be used to limit DoS attacks by 1306 authenticating the tunnel before L2TP session and PPP resources 1307 are allocated. 1309 11. IANA Considerations 1311 This document creates no new requirements on IANA namespaces 1312 [RFC2434]. 1314 12. Acknowledgements 1316 The authors would like to acknowledge the following contributors who 1317 provided helpful input on this document: Florent Parent, Jordi Palet 1318 Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, and 1319 Francis Dupont. 1321 The authors would also like to acknowledge the participants in the 1322 Softwires interim meeting at China University - Hong Kong (February 1323 23-24, 2006). The minutes for this meeting are at 1324 . 1326 ### Point to minutes of Barcelona meeting 1328 13. References 1330 13.1. Normative References 1332 [I-D.ietf-softwire-problem-statement] 1333 Li, X., "Softwire Problem Statement", 1334 draft-ietf-softwire-problem-statement-02 (work in 1335 progress), May 2006. 1337 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 1338 (IPCP)", RFC 1332, May 1992. 1340 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1341 RFC 1661, July 1994. 1343 [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 1344 July 1994. 1346 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1347 E. Lear, "Address Allocation for Private Internets", 1348 BCP 5, RFC 1918, February 1996. 1350 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1351 Protocol (CHAP)", RFC 1994, August 1996. 1353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1354 Requirement Levels", BCP 14, RFC 2119, March 1997. 1356 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1357 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1358 October 1998. 1360 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1361 Autoconfiguration", RFC 2462, December 1998. 1363 [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", 1364 RFC 2472, December 1998. 1366 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1367 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1368 RFC 2661, August 1999. 1370 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1371 "Remote Authentication Dial In User Service (RADIUS)", 1372 RFC 2865, June 2000. 1374 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1375 RFC 3162, August 2001. 1377 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 1378 "Securing L2TP using IPsec", RFC 3193, November 2001. 1380 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1381 and M. Carney, "Dynamic Host Configuration Protocol for 1382 IPv6 (DHCPv6)", RFC 3315, July 2003. 1384 [RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two 1385 Tunneling Protocol "L2TP" Management Information Base", 1386 RFC 3371, August 2002. 1388 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1389 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1390 December 2003. 1392 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1393 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1394 RFC 3948, January 2005. 1396 [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- 1397 Edge (PWE3) Fragmentation and Reassembly", RFC 4623, 1398 August 2006. 1400 13.2. Informative References 1402 [I-D.ietf-dhc-subnet-alloc] 1403 Johnson, R., "Subnet Allocation Option", 1404 draft-ietf-dhc-subnet-alloc-04 (work in progress), 1405 October 2006. 1407 [I-D.ietf-dhc-v6-relay-radius] 1408 Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option", 1409 draft-ietf-dhc-v6-relay-radius-02 (work in progress), 1410 February 2006. 1412 [I-D.ietf-ipv6-2461bis] 1413 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 1414 draft-ietf-ipv6-2461bis-10 (work in progress), 1415 January 2007. 1417 [I-D.ietf-ipv6-over-ppp-v2] 1418 Varada, S., "IP Version 6 over PPP", 1419 draft-ietf-ipv6-over-ppp-v2-02 (work in progress), 1420 June 2005. 1422 [I-D.ietf-radext-delegated-prefix] 1423 Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1424 Attribute", draft-ietf-radext-delegated-prefix-05 (work in 1425 progress), October 2006. 1427 [I-D.ietf-softwire-security-requirements] 1428 Yamamoto, S., "Softwire Security Analysis and 1429 Requirements", 1430 draft-ietf-softwire-security-requirements-01 (work in 1431 progress), October 2006. 1433 [I-D.stevant-softwire-accounting] 1434 Stevant, B., "Accounting on Softwires", 1435 draft-stevant-softwire-accounting-01 (work in progress), 1436 October 2006. 1438 [RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control 1439 Protocol Extensions for Name Server Addresses", RFC 1877, 1440 December 1995. 1442 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 1443 RFC 2433, October 1998. 1445 [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting 1446 Modifications for Tunnel Protocol Support", RFC 2867, 1447 June 2000. 1449 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, 1450 M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1451 Support", RFC 2868, June 2000. 1453 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1454 Levkowetz, "Extensible Authentication Protocol (EAP)", 1455 RFC 3748, June 2004. 1457 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 1458 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1460 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1461 Addresses", RFC 4193, October 2005. 1463 [RFC4293] Routhier, S., "Management Information Base for the 1464 Internet Protocol (IP)", RFC 4293, April 2006. 1466 Appendix A. Revision History 1468 [Note to RFC Editor: please remove this entire appendix, and the 1469 corresponding entries in the table of contents, prior to 1470 publication.] 1472 Changes between -02 and -03: 1474 o Boiler changes in support of RFC 4748. 1476 o Added text about L2TPv2 HELLO and LCP ECHO usage in Section 1, 1477 Section 2.6 and Section 5.1.2. 1479 o Moved some downref to Informative ([RFC1877], [RFC2433], 1480 [RFC2867], [RFC2868], and [RFC3748]), and moved CHAP reference to 1481 Normative ([RFC1994]). 1483 o Removed the mention and citation for PAP authentication. 1485 Changes between -01 and -02: 1487 o Renamed all "Best Current Practices" sections as 1488 "Recommendations". See for example Section 1.4. 1490 o Moved Provisioning in Section 6. Removed intro text to new 1491 Section 7. 1493 o Removed all normative language from Section 6, Section 7, 1494 Section 8, and Section 9. 1496 o Removed empty sections "Implementation Status", and "Open Issues". 1498 o Fixed "Phase 0" in Section 1. 1500 o Small changes to Section 3.1. 1502 o Change L2TP -> L2TPv2 in some sections, including Section 6. 1504 o Small additions and typo fixes in Section 5.1.1.1 and 1505 Section 5.1.1.2. 1507 o Retitled Section 8 and Section 8.1, changed AAA -> RADIUS. 1509 o New paragraph in Section 9.1. 1511 o New paragraph in Section 8.2.1, including a pointer to 1512 [I-D.ietf-dhc-v6-relay-radius]. 1514 o Moved last paragraph to start of Section 10. 1516 o Moved some references from Normative to Informative. 1518 o Label the steps in Figure 9 and Figure 10. 1520 o Reword paragraph of Section 5.1. 1522 o Describe more messages than flows in Figure 11 and Figure 12. 1524 o Add text about Session Establishment between Figure 11 and 1525 Figure 12. 1527 o Section 5.1.1.1 and Section 5.1.1.2: Updates on Hostname AVP, 1528 Framing Capabilities AVP, Framing Type AVP, Connect Speed AVP and 1529 Challenge and Challenge Response AVPs. 1531 o Retitled Section 5.1.1.3. 1533 o Updates on the use of L2TP HELLO versus LCP, delay for Dead-End 1534 peer detection, and allow LCP. 1536 o Rewording in Section 5.1.3. 1538 o Section 5.2.1: Add a pointer to [RFC4623] and small updates. 1540 o Clarifications on PFC and ACFC, remove Figure 13. 1542 o Section 5.2.3: make references to RFCs for PAP, CHAP, etc. 1544 o Rewordings in Section 5.2.4.1 and Section 5.2.4.2. 1546 o Added Informative references to [RFC4623], [RFC1661], [RFC1662], 1547 [RFC2433], and [RFC3748]. 1549 o Renamed the title and added more details on Section 5.3 and IPv6 1550 ND, including a pointer to [I-D.ietf-ipv6-2461bis]. 1552 o Added text in Section 5.4 about IPv4 PD is non-trivial and non 1553 commonly done. 1555 o Added B. Stevant as Editor. 1557 o Clarification in Section 5.2.4.1 and Section 5.2.4.2 regarding the 1558 scope of the MUST (to the specific scenarios). 1560 o Removed considerations about reverse DNS from Section 6, agreed on 1561 Barcelona. 1563 o Clarified the NAT case in Section 6.1.2 1565 o Added first paragraph in Section 6.2.1 regarding delegated IPv6 1566 prefixes. 1568 o Added new Section 6.3, Section 6.3.1 and Section 6.3.2 summarizing 1569 the scenarios for address allocation. 1571 Changes between -00 and -01: 1573 o Changed alignment in all figures to be centered, and fixed 1574 Figure 9 reference. 1576 o Section 1.4: Added new section with "Best Current Practices" 1577 definition. 1579 o Marked the following sections as "Best Current Practices": 1580 Section 6, Section 8, and Section 9. 1582 o Section 6.1.1, last paragraph: Removed sentence on IPv6 link 1583 address on the PPP link. Mailing list comment from Florent 1584 Parent, 13-Jul-2006. 1586 o Section 6.1.2, last paragraph: Changed IPv4 PPP link address to 1587 use host addresses (/32) negotiated with IPCP instead of /30. 1588 Mailing list comment from Bill Storer, 5-Jul-2006. 1590 o Section 5, Figure 10: Correction, s/SCCSN/SCCCN/; added missing 1591 ICRP, and changed direction of ICCN; typo correction s/IPV6P/ 1592 IPV6CP/. Mailing list comment from Bill Storer, 5-Jul-2006. 1594 o Section 5, Figure 10: Marked CHAP as "Optional - CHAP". 1596 o Section 5.1, Section 5.1.1, and Section 5.1.3: Minor typographical 1597 error correction and rewording of some sentences for grammar. 1599 o Section 5.1.1.1, Host Name AVP: Removed "for debugging purposes" 1600 and added that MAY be used to authenticate users. 1602 o Section 5.1.1.1, Framing Capabilities AVP: Swapped SHOULD and 1603 MUST. Mailing list comment from Bill Storer, 5-Jul-2006, text 1604 from Laurent Toutain. 1606 o Section 5.1.1.1, (Tx) Connect Speed: Correction: "but is *not* 1607 meaningful". 1609 o Section 5.1.1.2, Challenge and Challenge Response AVPs: Removed 1610 the last sentence of the first paragraph. Mailing list comment 1611 from Bill Storer, 5-Jul-2006, text from Laurent Toutain. 1613 o Section 5.1.2: Rewrote paragraph to use L2TPv2 HELLO messages and 1614 not LCP Echo Request and Reply messages to detect tunnel failure, 1615 as redundant in Softwires. Mailing list comment from Florent 1616 Parent, 10-Jul-2006, text from Bill Storer. 1618 o Section 5.2.1, first paragraph: Fixed PPP MTU calculation. 1619 Mailing list comment from Florent Parent, 10-Jul-2006. 1621 o Section 5.2.4.2: Rewrote to generalize the address assignment 1622 failure, to be an all-zeroes address or a protocol reject in 1623 response to the IPCP CONFREQ. Mailing list comment from Bill 1624 Storer, 5-Jul-2006, text from JF Tremblay. 1626 o Section 8, second paragraph: s/Tunnel-Medium /Tunnel-Type /. 1627 Mailing list comment from Bill Storer, 5-Jul-2006. 1629 o Section 8.1.2: Added usage of Framed-IP-Address attribute, and if 1630 not present then use the Tunnel-Client-Endpoint and Tunnel-Server- 1631 Endpoint attributes. Mailing list comment from Bill Storer, 1632 5-Jul-2006, text from JF Tremblay and Bill Storer. 1634 o Completed Section 8.2.2, Section 9.1, Section 9.2, and Section 10. 1636 Revision -00: 1638 o Initial revision. 1640 Authors' Addresses 1642 Bill Storer (editor) 1643 Cisco Systems 1644 170 W Tasman Dr 1645 San Jose, CA 95134 1646 USA 1648 Email: bstorer@cisco.com 1650 Carlos Pignataro (editor) 1651 Cisco Systems 1652 7025 Kit Creek Road 1653 PO Box 14987 1654 Research Triangle Park, NC 27709 1655 USA 1657 Email: cpignata@cisco.com 1659 Maria Alice Dos Santos 1660 Cisco Systems 1661 170 W Tasman Dr 1662 San Jose, CA 95134 1663 USA 1665 Email: mariados@cisco.com 1667 Jean-Francois Tremblay 1668 Hexago 1669 1470 Peel, suite 910 1670 Montreal, QC J4B 2Z5 1671 Canada 1673 Email: jean-francois.tremblay@hexago.com 1675 Bruno Stevant (editor) 1676 GET/ENST Bretagne 1677 2 rue de la Chataigneraie CS17607 1678 Cesson Sevigne, 35576 1679 France 1681 Email: bruno.stevant@enst-bretagne.fr 1683 Full Copyright Statement 1685 Copyright (C) The IETF Trust (2007). 1687 This document is subject to the rights, licenses and restrictions 1688 contained in BCP 78, and except as set forth therein, the authors 1689 retain all their rights. 1691 This document and the information contained herein are provided on an 1692 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1693 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1694 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1695 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1696 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1697 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1699 Intellectual Property 1701 The IETF takes no position regarding the validity or scope of any 1702 Intellectual Property Rights or other rights that might be claimed to 1703 pertain to the implementation or use of the technology described in 1704 this document or the extent to which any license under such rights 1705 might or might not be available; nor does it represent that it has 1706 made any independent effort to identify any such rights. Information 1707 on the procedures with respect to rights in RFC documents can be 1708 found in BCP 78 and BCP 79. 1710 Copies of IPR disclosures made to the IETF Secretariat and any 1711 assurances of licenses to be made available, or the result of an 1712 attempt made to obtain a general license or permission for the use of 1713 such proprietary rights by implementers or users of this 1714 specification can be obtained from the IETF on-line IPR repository at 1715 http://www.ietf.org/ipr. 1717 The IETF invites any interested party to bring to its attention any 1718 copyrights, patents or patent applications, or other proprietary 1719 rights that may cover technology that may be required to implement 1720 this standard. Please address the information to the IETF at 1721 ietf-ipr@ietf.org. 1723 Acknowledgment 1725 Funding for the RFC Editor function is provided by the IETF 1726 Administrative Support Activity (IASA).