idnits 2.17.1 draft-ietf-softwire-hs-framework-l2tpv2-02.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 on line 1668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1679. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1686. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1692. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (November 17, 2006) is 6370 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') ** Downref: Normative reference to an Informational RFC: RFC 1877 ** Downref: Normative reference to an Informational RFC: RFC 2433 ** 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) ** Downref: Normative reference to an Informational RFC: RFC 2867 ** Downref: Normative reference to an Informational RFC: RFC 2868 ** 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-09 == 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: 13 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: May 21, 2007 Cisco Systems 6 J. Tremblay 7 Hexago 8 B. Stevant, Ed. 9 GET/ENST Bretagne 10 November 17, 2006 12 Softwires Hub & Spoke Deployment Framework with L2TPv2 13 draft-ietf-softwire-hs-framework-l2tpv2-02 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 May 21, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . 13 75 3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 13 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. Softwire Transport Related . . . . . . . . . . . . . . . . 17 82 4.2. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 4.3. Authentication Authorization Accounting . . . . . . . . . 18 84 4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 18 86 4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 18 87 4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 18 89 5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 18 90 5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 20 91 5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 21 92 5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 23 93 5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 24 94 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 24 95 5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 24 96 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 24 97 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 24 98 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 24 99 5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 25 101 5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 25 102 5.2.4.1. IPv6CP . . . . . . . . . . . . . . . . . . . . . . 25 103 5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 25 104 5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 25 105 5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 106 5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 26 107 5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 26 109 6. Considerations about the Address Provisioning Model . . . . . 27 110 6.1. Softwire Endpoints Addresses . . . . . . . . . . . . . . . 27 111 6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 27 112 6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 27 113 6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 27 114 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 27 115 6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 28 116 6.3. Possible scenarios . . . . . . . . . . . . . . . . . . . . 28 117 6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 28 118 6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 28 120 7. Considerations about Address Stability . . . . . . . . . . . . 29 122 8. Considerations about RADIUS Integration . . . . . . . . . . . 29 123 8.1. Softwires Endpoints . . . . . . . . . . . . . . . . . . . 29 124 8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 30 125 8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 30 126 8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 30 127 8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30 128 8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 31 130 9. Considerations for Maintenance and Statistics . . . . . . . . 31 131 9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 31 132 9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 134 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 136 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 138 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 140 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 141 13.1. Normative References . . . . . . . . . . . . . . . . . . . 32 142 13.2. Informative References . . . . . . . . . . . . . . . . . . 34 144 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 35 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 147 Intellectual Property and Copyright Statements . . . . . . . . . . 40 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 may send L2TPv2 194 keepalive HELLO messages to monitor the health of the Softwire and 195 the peer LCCE or to refresh the NAT/PAT translation entry at the CPE 196 or at the other end of the access link. 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 can be used to monitor 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 L2TPv2 MIB [RFC3371] supports the complete suite of management 316 operations such as configuration of Control Channel and Session, 317 polling of Control Channel and Session status and their traffic 318 statistics and notifications of Control Channel and Session UP/DOWN 319 events. 321 2.7. Encapsulations 323 L2TPv2 supports the following encapsulations: 325 o IPv6/PPP/L2TPv2/UDP/IPv4 327 o IPv4/PPP/L2TPv2/UDP/IPv6 329 o IPv4/PPP/L2TPv2/UDP/IPv4 331 o IPv6/PPP/L2TPv2/UDP/IPv6 333 Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not 334 support "autodetect" of NAT/PAT. 336 3. Deployment Scenarios 338 For the "Hubs and Spokes" problem space, four scenarios have been 339 identified. In each of these four scenarios, different home 340 equipment plays the role of the Softwire Initiator. This section 341 elaborates each scenario with L2TPv2 as the Softwire protocol and 342 other possible protocols involved to complete the solution. This 343 section examines the four scenarios for both IPv6 over IPv4 and IPv4 344 over IPv6 encapsulations. 346 3.1. IPv6 over IPv4 Softwire with L2TPv2 348 The following subsections cover IPv6 connectivity across an IPv4-only 349 access network using a Softwire. 351 3.1.1. Host CPE as Softwire Initiator 353 Softwire initiator is the host CPE (directly connected to a modem), 354 which is dual-stack. There is no other gateway device. The IPv4 355 traffic should not traverse the softwire. 357 In this scenario, IPv6CP negotiates IPv6 over PPP which also provides 358 the capability for the ISP to assign the 64-bit Interface Id to the 359 host CPE or perform uniqueness validation for the two Interface Ids 360 at the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor 361 Discovery runs over the IPv6 over PPP link, and the LNS can assign a 362 64-bit global prefix to the host CPE via Router Advertisement (RA) 363 while other configuration options (such as DNS) can be conveyed to 364 the host CPE via DHCPv6/v4. 366 IPv6 or dual-stack IPv4-only dual-stack 367 |------------------||-----------------||----------| 369 I SC SI 370 N +-----+ +----------+ 371 T | | | v4/v6 | 372 E <==[ IPv6 ]....|v4/v6|....[IPv4~only]....| host CPE | 373 R [network] | | [ network ] | | 374 N | LNS | |LAC Client| 375 E +-----+ +----------+ 376 T _ _ _ _ _ _ _ _ _ 377 ()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic 378 PPP o L2TPv2 o UDP o IPv4 379 Softwire 381 <------------------> 382 IPv6CP: capable of /64 intf Id assignment or 383 uniqueness check 385 |------------------>/64 prefix 386 RA 387 |------------------>DNS, etc. 388 DHCPv6/v4 390 Figure 1: Host CPE as Softwire Initiator 392 3.1.2. Router CPE as Softwire Initiator 394 Softwire initiator is the router CPE, which is a dual-stack device. 395 The IPv4 traffic should not traverse the Softwire. 397 In this scenario, IPv6CP negotiates IPv6 over PPP which also provides 398 the capability for the ISP to assign the 64-bit Interface Id to the 399 router CPE or perform uniqueness validation for the two Interface Ids 400 at the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor 401 Discovery runs over the IPv6 over PPP link, and the LNS can assign a 402 64-bit global prefix to the router CPE via Router Advertisement (RA). 403 DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g. delegating 404 a 48-bit prefix to be used within the home network) and convey other 405 configuration options (such as DNS) to the router CPE. 407 IPv6 or dual-stack IPv4-only dual-stack 408 |------------------||-----------------||---------------------| 410 I SC SI 411 N +-----+ +----------+ 412 T | | | v4/v6 | +-----+ 413 E <==[ IPv6 ]....|v4/v6|....[IPv4~only]....| CPE |----|v4/v6| 414 R [network] | | [ network ] | | | host| 415 N | LNS | |LAC Client| +-----+ 416 E +-----+ +----------+ 417 T _ _ _ _ _ _ _ _ _ 418 ()_ _ _ _ _ _ _ _ _() <-------- IPv6 traffic 419 PPP o L2TPv2 o UDP o IPv4 420 Softwire 422 <------------------> 423 IPv6CP: capable of /64 intf Id assignment or 424 uniqueness check 426 |------------------>/64 prefix 427 RA 428 |------------------>/48 prefix, 429 DHCPv6 DNS, etc. 431 |------->/64 prefix 432 RA 433 |-------> DNS, etc. 434 DHCPv4/v6 436 Figure 2: Router CPE as Softwire Initiator 438 3.1.3. Host behind CPE as Softwire Initiator 440 The CPE is IPv4-only. Softwire initiator is a dual-stack host 441 (behind IPv4- only CPE), which acts as an IPv6 host CPE. The IPv4 442 traffic should not traverse the Softwire. 444 In this scenario, IPv6CP negotiates IPv6 over PPP which also provides 445 the capability for the ISP to assign the 64-bit Interface Id to the 446 host or perform uniqueness validation for the two Interface Ids at 447 the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor 448 Discovery runs over the IPv6 over PPP link, and the LNS can assign a 449 64-bit global prefix to the host via Router Advertisement (RA) while 450 other configuration options (such as DNS) can be conveyed to the host 451 via DHCPv6/v4. 453 IPv6 or dual-stack IPv4-only dual-stack 454 |------------------||----------------------------||----------| 456 I SC SI 457 N +-----+ +----------+ 458 T | | +-------+ | v4/v6 | 459 E <==[ IPv6 ]....|v4/v6|....[IPv4~only]....|v4-only|--| host | 460 R [network] | | [ network ] | CPE | | | 461 N | LNS | +-------+ |LAC Client| 462 E +-----+ +----------+ 463 T _ _ _ _ _ _ _ _ _ _ _ _ _ _ 464 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6 465 PPP o L2TPv2 o UDP o IPv4 traffic 466 Softwire 468 <------------------------------> 469 IPv6CP: capable of /64 intf Id assignment or 470 uniqueness check 472 |------------------------------>/64 prefix 473 RA 474 |------------------------------>DNS, etc. 475 DHCPv4/v6 477 Figure 3: Host behind CPE as Softwire Initiator 479 3.1.4. Router behind CPE as Softwire Initiator 481 The CPE is IPv4-only. Softwire initiator is a dual-stack device 482 (behind the IPv4-only CPE) acting as an IPv6 CPE router inside the 483 home network. The IPv4 traffic should not traverse the Softwire. 485 In this scenario, IPv6CP negotiates IPv6 over PPP which also provides 486 the capability for the ISP to assign the 64-bit Interface Id to the 487 v4/v6 router or perform uniqueness validation for the two Interface 488 Ids at the two PPP ends [RFC2472]. After IPv6 over PPP is up, 489 Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can 490 assign a 64-bit global prefix to the v4/v6 router via Router 491 Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix 492 Delegation (for example, delegating a 48-bit prefix to be used within 493 the home network) and convey other configuration options (such as 494 DNS) to the v4/v6 router. 496 IPv6 or dual-stack IPv4-only dual-stack 497 |------------------||-------------------------||-------------| 499 I SC SI 500 N +-----+ +----------+ 501 T | | +-------+ | v4/v6 | 502 E <==[ IPv6 ]....|v4/v6|..[IPv4~only]..|v4-only|---| router | 503 R [network] | | [ network ] | CPE | | | | 504 N | LNS | +-------+ | |LAC Client| 505 E +-----+ | +----------+ 506 T | 507 ---------+-----+ 508 |v4/v6| 509 | host| 510 _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ 511 ()_ _ _ _ _ _ _ _ _ _ _ _ _() <--IPv6 traffic 512 PPP o L2TPv2 o UDP o IPv4 513 Softwire 515 <---------------------------> 516 IPv6CP: capable of /64 intf Id assignment or 517 uniqueness check 519 |--------------------------->/64 prefix 520 RA 521 |--------------------------->/48 prefix, 522 DHCPv6 DNS, etc. 524 |----> /64 525 RA prefix 526 |----> DNS, 527 DHCPv4/v6 etc. 529 Figure 4: Router behind CPE as Softwire Initiator 531 3.2. IPv4 over IPv6 Softwire with L2TPv2 533 The following subsections cover IPv4 connectivity across an IPv6-only 534 access network using a Softwire. 536 3.2.1. Host CPE as Softwire Initiator 538 Softwire initiator is the host CPE (directly connected to a modem), 539 which is dual-stack. There is no other gateway device. The IPv6 540 traffic should not traverse the Softwire. 542 In this scenario, IPCP negotiates IPv4 over PPP which also provides 543 the capability for the ISP to assign a global IPv4 address to the 544 host CPE. Global IPv4 address can also be assigned via DHCP. Other 545 configuration options (such as DNS) can be conveyed to the host CPE 546 via IPCP [RFC1877] or DHCP. 548 IPv4 or dual-stack IPv6-only dual-stack 549 |------------------||-----------------||---------| 551 I SC SI 552 N +-----+ +----------+ 553 T | | | v4/v6 | 554 E <==[ IPv4 ]....|v4/v6|....[IPv6~only]....| host CPE | 555 R [network] | | [ network ] | | 556 N | LNS | |LAC Client| 557 E +-----+ +----------+ 558 T _ _ _ _ _ _ _ _ _ 559 ()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic 560 PPP o L2TPv2 o UDP o IPv6 561 Softwire 563 <------------------> 564 IPCP: capable of global IP assignment 565 and DNS, etc. 567 Figure 5: Host CPE as Softwire Initiator 569 3.2.2. Router CPE as Softwire Initiator 571 IPv4 connectivity across an IPv6-only access network (STH). Softwire 572 initiator is the router CPE, which is a dual-stack device. The IPv6 573 traffic should not traverse the Softwire. 575 In this scenario, IPCP negotiates IPv4 over PPP which also provides 576 the capability for the ISP to assign a global IPv4 address to the 577 router CPE. Global IPv4 address can also be assigned via DHCP. 578 Other configuration options (such as DNS) can be conveyed to the 579 router CPE via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation 580 for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used. 582 IPv4 or dual-stack IPv6-only dual-stack Home 583 |------------------||-----------------||-------------------| 585 I SC SI 586 N +-----+ +----------+ 587 T | | | v4/v6 | +-----+ 588 E <==[ IPv4 ]....|v4/v6|....[IPv6~only]....| CPE |--|v4/v6| 589 R [network] | | [ network ] | | | host| 590 N | LNS | |LAC Client| +-----+ 591 E +-----+ +----------+ 592 T _ _ _ _ _ _ _ _ _ 593 ()_ _ _ _ _ _ _ _ _() <--------- IPv4 traffic 594 PPP o L2TPv2 o UDP o IPv6 595 Softwire 597 <------------------> 598 IPCP: capable of global IP assignment 599 and DNS, etc. 601 |------------------> 602 DHCPv4: prefix, mask, PD 604 private/ 605 |------> global 606 DHCP IP, DNS, 607 etc. 609 Figure 6: Router CPE as Softwire Initiator 611 3.2.3. Host behind CPE as Softwire Initiator 613 IPv4 connectivity across an IPv6-only access network (STH). The CPE 614 is IPv6-only. Softwire initiator is a dual-stack host (behind the 615 IPv6 CPE), which acts as an IPv4 host CPE. The IPv6 traffic should 616 not traverse the Softwire. 618 In this scenario, IPCP negotiates IPv4 over PPP which also provides 619 the capability for the ISP to assign a global IPv4 address to the 620 host. Global IPv4 address can also be assigned via DHCP. Other 621 configuration options (such as DNS) can be conveyed to the host CPE 622 via IPCP [RFC1877] or DHCP. 624 IPv4 or dual-stack IPv6-only dual-stack 625 |------------------||----------------------------||----------| 627 I SC SI 628 N +-----+ +----------+ 629 T | | +-------+ | v4/v6 | 630 E <==[ IPv4 ]....|v4/v6|....[IPv6~only]....|v6-only|--| host | 631 R [network] | | [ network ] | CPE | | | 632 N | LNS | +-------+ |LAC Client| 633 E +-----+ +----------+ 634 T _ _ _ _ _ _ _ _ _ _ _ _ _ _ 635 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv4 636 PPP o L2TPv2 o UDP o IPv6 traffic 637 Softwire 639 <------------------------------> 640 IPCP: capable of global IP assignment 641 and DNS, etc. 643 Figure 7: Host behind CPE as Softwire Initiator 645 3.2.4. Router behind CPE as Softwire Initiator 647 IPv4 connectivity across an IPv6-only access network (STH). The CPE 648 is IPv6-only. Softwire initiator is a dual-stack device (behind the 649 IPv6-only CPE) acting as an IPv4 CPE router inside the home network. 650 The IPv6 traffic should not traverse the Softwire. 652 In this scenario, IPCP negotiates IPv4 over PPP which also provides 653 the capability for the ISP to assign a global IPv4 IP address to the 654 v4/v6 router. Global IPv4 address can also be assigned via DHCP. 655 Other configuration options (such as DNS) can be conveyed to the 656 v4/v6 router via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation 657 for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used. 659 IPv4 or dual-stack IPv6-only dual-stack 660 |------------------||-------------------------||------------| 662 I SC SI 663 N +-----+ +----------+ 664 T | | +-------+ | v4/v6 | 665 E <==[ IPv4 ]....|v4/v6|..[IPv6~only]..|v6-only|---| router | 666 R [network] | | [ network ] | CPE | | | | 667 N | LNS | +-------+ | |LAC Client| 668 E +-----+ | +----------+ 669 T | 670 --------+-----+ 671 |v4/v6| 672 | host| 673 _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ 674 ()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- IPv4 675 PPP o L2TPv2 o UDP o IPv4 traffic 676 Softwire 678 <---------------------------> 679 IPCP: assigns global IP address and DNS, etc. 681 |---------------------------> 682 DHCPv4: prefix, mask, PD 684 private/ 685 |----> global 686 DHCP IP, DNS, 687 etc. 689 Figure 8: Router behind CPE as Softwire Initiator 691 4. Standardisation Status 693 4.1. Softwire Transport Related 695 RFC 3193 Securing L2TP using IPsec. 697 RFC 3948 UDP Encapsulation of IPsec ESP Packets. 698 IPSec supports both IPv4 and IPv6 transports. 700 4.2. L2TPv2 701 RFC 2661 Layer Two Tunneling Protocol "L2TP". 702 For both IPv4 and IPv6 payloads, support is complete. 703 For both IPv4 and IPv6 transport, support is complete. 705 4.3. Authentication Authorization Accounting 707 RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol 708 Support. 710 RFC 2865 Remote Authentication Dial In User Service (RADIUS). 712 RFC 3162 RADIUS and IPv6. 714 4.4. MIB 716 RFC 3371 Layer Two Tunneling Protocol "L2TP" Management Information 717 Base. 719 RFC 4087 IP Tunnel MIB. 720 Both IPv4 and IPv6 transport is supported. 722 4.5. Softwire Payload Related 724 4.5.1. For IPv6 Payloads 726 RFC 2472 IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2]. 728 RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). 730 RFC 3646 DNS Configuration options for Dynamic Host Configuration 731 Protocol for IPv6 (DHCPv6). 733 RFC 2461 Neighbor Discovery for IP Version 6 (IPv6). 735 4.5.2. For IPv4 Payloads 737 RFC 1661 The Point-to-Point Protocol (PPP). 739 RFC 1332 The PPP Internet Protocol Control Protocol (IPCP). 741 DHCP Subnet Allocation 742 Work in progress [I-D.ietf-dhc-subnet-alloc]. 744 5. Softwire Establishment 746 A Softwire is established in 3 distinct steps (Figure 9). First a 747 L2TPv2 tunnel with a single session is established from the SI to the 748 SC. Second a PPP session is established over the L2TPv2 session and 749 the SI obtains an address. Third the SI optionally gets other 750 information through DHCP such as a delegated prefix and DNS servers. 752 SC SI 753 | | 754 |<-------------L2TPv2------------>| Step 1 755 | | L2TPv2 Tunnel establishment 756 | | 757 |<-------------PPP--------------->| Step 2 758 |<----End Point Configuration---->| PPP and End Point 759 | | configuration 760 | | 761 |<------Router Configuration----->| Step 3 762 | | Additional configuration 763 | | (optional) 765 Figure 9: Steps for the Establishment of a Softwire 767 In the following diagram (Figure 10), each of the three steps 768 required to establish a Softwire is described in detail. 770 SC SI 771 | | 772 | | Step 1 773 |<------------SCCRQ---------------| - 774 |-------------SCCRP-------------->| | 775 |<------------SCCCN---------------| | 776 |<------------ICRQ----------------| | L2TPv2 777 |-------------ICRP--------------->| | 778 |<------------ICCN----------------| - 779 | | 780 | | Step 2 781 |<-----Configuration-Request------| - 782 |------Configuration-Request----->| | PPP 783 |<-------Configuration-Ack--------| | LCP 784 |--------Configuration-Ack------->| - 785 | | 786 |-----------Challenge------------>| - PPP Authentication 787 |<----------Response--------------| | (Optional - CHAP) 788 |------------Success------------->| - 789 | | 790 |<-----Configuration-Request------| - 791 |------Configuration-Request----->| | PPP NCP 792 |<-------Configuration-Ack--------| | (IPV6CP or IPCP) 793 |--------Configuration-Ack------->| - 794 | | 795 |<------Router-Solicitation-------| - Neighbor Discovery 796 |-------Router-Advertisement----->| | (IPv6 only) 797 | | - 798 | | 799 | | Step3 800 |<-----------Solicit--------------| - 801 |-----------Advertise------------>| | DHCP 802 |<---------- Request--------------| | (Optional) 803 |-------------Reply-------------->| - 805 Figure 10: Detailed Steps in the Establishment of a Softwire 807 5.1. L2TPv2 Tunnel Setup 809 L2TPv2 [RFC2661] was originally designed to provide private network 810 access to end users connected to a public network. In the L2TPv2 811 model, the end user makes a connection to an L2TP Access Concentrator 812 (LAC). The LAC then initiates an L2TPv2 tunnel to an L2TP Network 813 Server (LNS). The LNS then transfers end user traffic between the 814 L2TPv2 tunnel and the private network. 816 In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI) 817 assumes the role of the LAC and the Softwire Concentrator assumes the 818 role of the LNS. 820 In the Softwire model, an L2TPv2 packet MUST be carried over UDP. 821 The underlying version of the IP protocol may be IPv4 or IPv6, 822 depending on the Softwires scenario. 824 5.1.1. Tunnel Establishment 826 The following diagram, (Figure 11), describes messages exchanged and 827 AVPs used to establish a tunnel between an SI (LAC) and an SC (LNS). 828 The messages and AVPs described here are only a subset of those 829 defined in [RFC2661]. This is because Softwires uses only a subset 830 of the L2TPv2 functionality. One session per tunnel is needed. Note 831 that in the Softwires environment, the SI always initiates the 832 tunnel. No outgoing or analog calls are permitted. L2TPv2 833 attributes SHOULD NOT be hidden. 835 SCCRQ 836 Mandatory AVP 837 Message Type 838 Protocol Version 839 Host Name 840 Framing Capabilities 841 Assigned Tunnel ID 842 Optional AVP: 843 Receive Window Size 844 Firmware Revision 845 Vendor Name 846 (Challenge) 848 SCCRP 849 Mandatory AVP: 850 Message Type 851 Protocol Version 852 Framing Capabilities 853 Host Name 854 Assigned Tunnel ID 855 Optional AVP: 856 Firmware Revision 857 Vendor Name 858 Receive Window Size 859 (Challenge Response) 860 (Challenge) 862 SCCCN 863 Mandatory AVP: 864 Message Type 865 (Challenge Response) 867 Figure 11: Tunnel Establishment 869 In L2TPv2, the tunnel between a LAC and LNS may carry the data of 870 multiple users. Each of these user's is represented by an L2TPv2 871 session within the tunnel. In the Softwires environment, the tunnel 872 carries the information of a single user. So, there is only one 873 L2TPv2 session per tunnel. The following diagram, (Figure 12), 874 describes messages exchanged and AVPs used to establish a session 875 between an SI (LAC) and an SC (LNS). The messages and AVPs described 876 here are only a subset of those defined in [RFC2661]. This is 877 because Softwires uses only a subset of the L2TPv2 functionality. 878 Note that in the Softwires environment, the SI always initiates the 879 session. No outgoing or analog calls are permitted. L2TPv2 880 attributes SHOULD NOT be hidden. 882 ICRQ 883 Mandatory AVP: 884 Message Type 885 Assigned Session ID 886 Call Serial Number 888 ICRP 889 Mandatory AVP: 890 Message Type 891 Assigned Session ID 893 ICCN 894 Mandatory AVP: 895 Message Type 896 (Tx) Connect Speed 897 Framing Type 899 Figure 12: Session Establishment 901 5.1.1.1. AVPs Required for Softwires 903 This paragraph specifies specific values for AVPs used in the 904 Softwires context. 906 Host Name AVP 908 This AVP is mandatory and is present in SCCRQ and SCCRP messages. 909 This AVP may be used to authenticate users, in which case it would 910 contain a user identification. If this AVP is not used to 911 authenticate users, it may be used for documention. 913 Framing Capabilities AVP 915 Synchronous bit SHOULD be set to 1 and Asynchronous bit to 1. 916 This AVP SHOULD be ignored by the receiver. 918 Framing Type AVP 920 Synchronous bit SHOULD be set to 1 and Asynchronous bit to 0. 921 This AVP SHOULD be ignored by the receiver. 923 (Tx) Connect Speed 925 (Tx) Connect Speed is a mandatory AVP but is not meaningful in the 926 Softwires context. It SHOULD be left to 0 and ignored by the 927 receiver. 929 Assigned Tunnel ID, Receive Window Size, Firmware Revision, Vendor 930 Name, Call Serial Number, and Assigned Session ID 932 As defined in [RFC2661] 934 5.1.1.2. AVPs Optional for Softwires 936 Challenge and Challenge Response AVPs 938 These AVPs are not required, but are necessary to implement tunnel 939 authentication. Since tunnel authentication happens at the 940 beginning of L2TPv2 tunnel creation, it can be helpful in 941 preventing DoS attacks. 943 5.1.1.3. AVPs not Relevant for Softwires 945 L2TPv2 specifies numerous AVPs that, while allowed for a given 946 command, are irrelevant to a Softwires. Softwires implementations 947 should not send these AVPs. However, they should ignore them when 948 they are received. This will make it easier to create Softwires 949 applications on top of existing L2TPv2 implementations. 951 5.1.2. Tunnel Maintenance 953 Periodically, the SI must transit a message to the SC to maintain NAT 954 context and detect tunnel failure. The L2TPv2 HELLO message provides 955 a simple, low overhead method of doing this. However, using the 956 default values specified in [RFC2661] could result in a dead end 957 detection time of 83 seconds. If this is not acceptable, LCP Echo 958 Request and Reply messages may be used for quicker dead end 959 detection. 961 5.1.3. Tunnel Teardown 963 Either the SI or SC can teardown the session and tunnel. This is 964 done as specified in [RFC2661]. There is no action specific to 965 Softwires in this case. 967 5.2. PPP Connection 969 5.2.1. MTU 971 The MTU of the PPP link SHOULD be the link MTU minus the size of the 972 IP, UDP, L2TPv2, and PPP headers together. On an IPv4 link with an 973 MTU equal to 1500 bytes, this would usually mean a PPP MTU of 1460 974 bytes. This may vary according to the size of the L2TP header. See 975 [RFC4623] for a detailed discussion of fragmentation issues. 977 5.2.2. LCP 979 Once the L2TPv2 session is established, the SI and SC initiate the 980 PPP connection by negotiating LCP as described in [RFC1661]. ACFC 981 [RFC1662] SHOULD be rejected. 983 5.2.3. Authentication 985 After completing LCP negotiation, the SI and SC may optionally 986 perform authentication. If authentication is chosen, CHAP [RFC1994] 987 authentication MUST be supported by both the Softwire Initiator and 988 Softwire Concentrator. Other authentication methods such as PAP 989 [RFC1994], MS-CHAP [RFC2433], and EAP [RFC3748] MAY be supported. 991 A detailed discussion of Softwires security is contained in 992 [I-D.ietf-softwire-security-requirements] 994 5.2.4. IPCP 996 5.2.4.1. IPv6CP 998 In the IPv6 over IPv4 scenarios (see Section 3.1), after the 999 authentication phase, the Softwire Initiator MUST negotiate IPv6CP as 1000 defined in [RFC2472]. IPv6CP provides a way to negotiate a unique 1001 64-bit interface identifier to be used for the address 1002 autoconfiguration at the local end of the link. 1004 5.2.4.2. IPv4CP 1006 In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire 1007 Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain 1008 an IPv4 address from the SC. IPCP may also be used to obtain DNS 1009 information as described in [RFC1877]. 1011 5.3. Global IPv6 Address Assignement to Endpoints 1013 In several scenario defined in Section 3, Global IPv6 addresses are 1014 expected to be allocated to Softwires end points. Since IPv6CP only 1015 provide Link-Local addresses (see [RFC2472]), IPv6 Neighbor Discovery 1016 [RFC2462] or DHCPv6 [RFC3315] SHOULD be used to configure these 1017 addresses. 1019 The Softwire Initiator of an IPv6 Softwire MUST send a Router 1020 Solicitation message to the Softwire Concentrator after IPV6CP is 1021 completed. The Softwire Concentrator MUST answer with a Router 1022 Advertisement. This message MUST contains the global IPv6 prefix of 1023 the PPP link if Neighbor discovery is used to configure addresses of 1024 Softwire end points. 1026 If DHCPv6 is available for address delegation, the M bits of the 1027 Router Advertisement SHOULD be set. The Softwire Initiator MUST then 1028 send a DHCPv6 Request to configure the address of the Softwire 1029 endpoint. 1031 Duplicate Address Detection ([I-D.ietf-ipv6-2461bis]) MUST be 1032 performed on the Softwire in both cases. 1034 5.4. DHCP 1036 The Softwire Initiator MAY use DHCP to get additional information 1037 such as delegated prefix and DNS servers. If the SI supports DHCP, 1038 it SHOULD send a Solicit message to verify if more information is 1039 available. 1041 When delegating an IPv4 prefix to the SI, the SC SHOULD inject a 1042 route for this prefix in the IPv4 routing table in order to forward 1043 the traffic to the relevant Softwire. 1045 5.4.1. DHCPv6 1047 IF a SI establishing an IPv6 Softwire acts as a router (scenarios 1048 3.1.2 and 3.1.4) it MUST include the IA_PD option [RFC3633] in the 1049 DHCPv6 Solicit message [RFC3315] in order to request an IPv6 prefix. 1051 When delegating an IPv6 prefix to the SI, the SC SHOULD inject a 1052 route for this prefix in the IPv4 routing table in order to forward 1053 the traffic to the relevant Softwire. 1055 5.4.2. DHCPv4 1057 A SI establishing an IPv4 Softwire MAY send a DHCP request containing 1058 the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc]. This 1059 practice is not common but may be used to connect IPv4 subnets using 1060 Softwires, as defined in Section 3.2.2 and Section 3.2.4. 1062 One Subnet-Request suboption MUST be configured with the 'h' bit set 1063 to '1', as the SI is expected to perform the DHCP server function. 1064 The 'i' bit of the Subnet-Request suboption should be set to '0' the 1065 first time a prefix is requested and to '1' on subsequent requests, 1066 if a prefix has been allocated. The Prefix length suboption SHOULD 1067 be 0 by default. If the SI is configured to support only specific 1068 prefix lengths, it should specify the longest (smallest) prefix 1069 length it supports. 1071 If the SI was previously assigned a prefix from that same SC, it 1072 SHOULD include the Subnet Information suboption with the prefix it 1073 was previously assigned. The 'c' and 's' bits of the suboption 1074 SHOULD be set to '0'. 1076 6. Considerations about the Address Provisioning Model 1078 This section describes how a Softwire Concentrator may manage 1079 delegated addresses for Softwire endpoints and for subnets behind the 1080 Softwire Initiator. One common practice is to aggregate endpoints 1081 addresses and delegated prefixes into one prefix routed to the SC. 1082 The main benefit is to ease the routing scheme by isolating on the SC 1083 succeeding route injections (when delegating new prefixes for SI). 1085 6.1. Softwire Endpoints Addresses 1087 6.1.1. IPv6 1089 A Softwire Concentrator should provide globally routable addresses to 1090 Softwire endpoints. Other types of addresses such as Unique Local 1091 Addresses [RFC4193] may be used to address Softwire end points in a 1092 private network with no global connectivity. A single /64 should be 1093 assigned to the Softwire to address both Softwire endpoints. 1095 Global or ULA addresses must be assigned to endpoints when the 1096 scenario "Host CPE as Softwire Initiator" (described in 1097 Section 3.1.1) is considered to be deployed. For other scenarios, 1098 this may be optional and link local addresses should be used. 1100 6.1.2. IPv4 1102 A Softwire Concentrator may provide either globally routable or 1103 private IPv4 addresses. When using IPv4 private addresses [RFC1918] 1104 on the endpoints, it is not not recommended to delegate an IPv4 1105 private prefix to the SI, as it can lead to a nested-NAT situations. 1107 The endpoints of the PPP link use host addresses (i.e., /32), 1108 negotiated using IPCP. 1110 6.2. Delegated Prefixes 1112 6.2.1. IPv6 Prefixes 1114 Delegated IPv6 should be of global scope if assigned IPv6 addresses 1115 for endpoints are global. Using ULA addresses is not recommended 1116 when subnet is connected to the global IPv6 Internet. When using ULA 1117 IPv6 address for endpoint, Delegated IPv6 prefix may be either of 1118 Global or ULA scope. 1120 Delegated IPv6 prefixes are between /48 and /64 in length. When a SI 1121 receives a prefix shorter than 64, it can assign different /64 1122 prefixes to each of its interfaces. A SI receiving a single /64 is 1123 expected to perform bridging if more than one interface are available 1124 (wired and wireless for example). 1126 6.2.2. IPv4 Prefixes 1128 Delegated IPv4 prefixes should be of the same scope than the assigned 1129 IPv4 addresses and be routable within that address space. Prefix 1130 length is between /8 and /30. 1132 6.3. Possible scenarios 1134 This section summarizes the differents scenarios for address 1135 provisioning with the considerations given in the previous sections. 1137 6.3.1. Scenarios for IPv6 1139 This table describes the possible combination of IPv6 address scope 1140 for endpoints and delegated prefixes. 1142 +------------------+-----------------------+------------------------+ 1143 | Endpoint IPv6 | Delegated Global IPv6 | Delegated ULA IPv6 | 1144 | Address | Prefix | Prefix | 1145 +------------------+-----------------------+------------------------+ 1146 | Link Local | Possible | Possible | 1147 | | | | 1148 | ULA | Possible | Possible | 1149 | | | | 1150 | Global | Possible | Possible, but Not | 1151 | | | Recommended | 1152 +------------------+-----------------------+------------------------+ 1154 Table 1: Scenarios for IPv6 1156 6.3.2. Scenarios for IPv4 1158 This table describes the possible combination of IPv6 address scope 1159 for endpoints and delegated prefixes. 1161 +------------------+-----------------------+------------------------+ 1162 | Endpoint IPv4 | Delegated Public IPv4 | Delegated Private IPv4 | 1163 | Address | Prefix | Prefix | 1164 +------------------+-----------------------+------------------------+ 1165 | Private IPv4 | Possible | Possible, but Not | 1166 | | | Recommended | 1167 | | | | 1168 | Public IPv4 | Possible | Possible | 1169 +------------------+-----------------------+------------------------+ 1171 Table 2: Scenarios for IPv4 1173 7. Considerations about Address Stability 1175 A Softwire can provide stable addresses even if the underlying 1176 addressing scheme changes, by opposition to automatic tunneling. A 1177 Softwire Concentrator should always provide the same address and 1178 prefix to a reconnecting user. However, if the goal of the Softwire 1179 service is to provide a temporary address for a roaming user, it may 1180 be provisioned to provide only a temporary address. 1182 The address and prefix are expected to change when reconnecting to a 1183 different Softwire Concentrator. However an organization providing a 1184 Softwire service may provide the same address and prefix across 1185 different Softwire Concentrators at the cost of a more fragmented 1186 routing table. The routing fragmentation issue may be limited if the 1187 prefixes are aggregated in a location topologically close to the SC. 1188 This would be the case for example if several SCs are put in parallel 1189 for load-balancing purpose. 1191 8. Considerations about RADIUS Integration 1193 The Softwire Concentrator is expected to act as a client to a AAA 1194 server, for example a RADIUS server. During the PPP authentication 1195 phase, the RADIUS server may return additional informations in the 1196 form of attributes in the Access Accept message. 1198 The Softwire Concentrator may include the Tunnel-Type and Tunnel- 1199 Medium-Type attributes [RFC2868] in the Access Request messages to 1200 provide a hint of the type of Softwire being configured. 1202 8.1. Softwires Endpoints 1203 8.1.1. IPv6 Softwires 1205 If the RADIUS server includes a Framed-Interface-Id attribute 1206 [RFC3162], the Softwire Concentrator must send it to the Softwire 1207 Initiator in the Interface Identifier field of its IPV6CP 1208 Configuration Request message. 1210 If the Framed-IPv6-Prefix attribute is mentioned [RFC3162], that 1211 prefix MUST be used in the router advertisements sent to the SI. If 1212 Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC 1213 must choose a prefix with that pool to send RAs. 1215 If none of the attributes above are included but the AAA server 1216 returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint 1217 attributes [RFC2868] are present and of the correct address family, 1218 these must be used in the IPV6CP Interface Identifier and for the 1219 router advertisements. 1221 8.1.2. IPv4 Softwires 1223 If the Framed-IP-Address attribute [RFC2865] is present, the Softwire 1224 Concentrator must provide that address to the Softwire Initiator 1225 during IPCP address negotiation. That is, when the Softwire 1226 Initiator requests an IP address from the Softwire Concentrator, the 1227 address provided should be the Framed-IP-Address. 1229 If the Framed-IP-Address attribute is not present and the Tunnel- 1230 Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are 1231 present and of the correct address family, these should be used in 1232 the IPCP IP-Address configuration option. 1234 8.2. Delegated Prefixes 1236 8.2.1. IPv6 Prefixes 1238 If the attribute Delegated-IPv6-Prefix 1239 [I-D.ietf-radext-delegated-prefix] is present in the RADIUS Access 1240 Accept message, it must be used by the Softwire Concentrator for the 1241 delegation of the IPv6 prefix. Since the prefix delegation is 1242 performed by DHCPv6 and the attribute is linked to a username, the SC 1243 must associate the DUID of a DHCPv6 request to tunnel it came from 1244 and its user. 1246 Interaction between RADIUS, PPP and DHCPv6 server may follow the 1247 mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. During the 1248 Softwire authentication phase, PPP collects the RADIUS attributes for 1249 the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is 1250 assigned to the Softwire and fill these attributes in RRAO (Relay 1251 Agent RADIUS Attribute Option) into succeeding DHCPv6 requests from 1252 the client before forwarding them to the DHCPv6 server. 1254 8.2.2. IPv4 Prefixes 1256 The combination of the Framed-IP-Address and Framed-IP-Netmask 1257 attributes [RFC2865] may be used by the Softwire Concentrator to 1258 delegate an IPv4 prefix to the Softwire Initiator. 1260 9. Considerations for Maintenance and Statistics 1262 9.1. RADIUS Accounting 1264 RADIUS Accounting for L2TP and PPP are documented (see Section 4.3). 1266 When deploying Softwires solutions, operators may experience 1267 difficulties to differentiate the address family of the traffic 1268 reported in accounting information from RADIUS. This problem and 1269 some potential solutions are described in 1270 [I-D.stevant-softwire-accounting]. 1272 9.2. MIBs 1274 MIB support for L2TPv2 and PPP are documented (see Section 4.4). 1275 Also see [RFC4293] 1277 10. Security Considerations 1279 A detailed discussion of Softwires security is contained in 1280 [I-D.ietf-softwire-security-requirements]. 1282 The L2TPv2 Softwires solution provides the following tools for 1283 security: 1285 o IPsec [RFC3193] provides the highest level of security. 1287 o PPP CHAP [RFC1994] provides basic user authentication. 1289 o L2TP Tunnel Authentication [RFC2661] provides authentication at 1290 tunnel setup. It may be used to limit DoS attacks by 1291 authenticating the tunnel before L2TP session and PPP resources 1292 are allocated. 1294 11. IANA Considerations 1296 This document creates no new requirements on IANA namespaces 1297 [RFC2434]. 1299 12. Acknowledgements 1301 The authors would like to acknowledge the following contributors who 1302 provided helpful input on this document: Florent Parent, Jordi Palet 1303 Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, and 1304 Francis Dupont. 1306 The authors would also like to acknowledge the participants in the 1307 Softwires interim meeting at China University - Hong Kong (February 1308 23-24, 2006). The minutes for this meeting are at 1309 . 1311 ### Point to minutes of Barcelona meeting 1313 13. References 1315 13.1. Normative References 1317 [I-D.ietf-softwire-problem-statement] 1318 Li, X., "Softwire Problem Statement", 1319 draft-ietf-softwire-problem-statement-02 (work in 1320 progress), May 2006. 1322 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 1323 (IPCP)", RFC 1332, May 1992. 1325 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1326 RFC 1661, July 1994. 1328 [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 1329 July 1994. 1331 [RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control 1332 Protocol Extensions for Name Server Addresses", RFC 1877, 1333 December 1995. 1335 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1336 E. Lear, "Address Allocation for Private Internets", 1337 BCP 5, RFC 1918, February 1996. 1339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1340 Requirement Levels", BCP 14, RFC 2119, March 1997. 1342 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 1343 RFC 2433, October 1998. 1345 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1346 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1347 October 1998. 1349 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1350 Autoconfiguration", RFC 2462, December 1998. 1352 [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", 1353 RFC 2472, December 1998. 1355 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1356 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1357 RFC 2661, August 1999. 1359 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1360 "Remote Authentication Dial In User Service (RADIUS)", 1361 RFC 2865, June 2000. 1363 [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting 1364 Modifications for Tunnel Protocol Support", RFC 2867, 1365 June 2000. 1367 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, 1368 M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1369 Support", RFC 2868, June 2000. 1371 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1372 RFC 3162, August 2001. 1374 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 1375 "Securing L2TP using IPsec", RFC 3193, November 2001. 1377 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1378 and M. Carney, "Dynamic Host Configuration Protocol for 1379 IPv6 (DHCPv6)", RFC 3315, July 2003. 1381 [RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two 1382 Tunneling Protocol "L2TP" Management Information Base", 1383 RFC 3371, August 2002. 1385 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1386 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1387 December 2003. 1389 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1390 Levkowetz, "Extensible Authentication Protocol (EAP)", 1391 RFC 3748, June 2004. 1393 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1394 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1395 RFC 3948, January 2005. 1397 [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- 1398 Edge (PWE3) Fragmentation and Reassembly", RFC 4623, 1399 August 2006. 1401 13.2. Informative References 1403 [I-D.ietf-dhc-subnet-alloc] 1404 Johnson, R., "Subnet Allocation Option", 1405 draft-ietf-dhc-subnet-alloc-04 (work in progress), 1406 October 2006. 1408 [I-D.ietf-dhc-v6-relay-radius] 1409 Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option", 1410 draft-ietf-dhc-v6-relay-radius-02 (work in progress), 1411 February 2006. 1413 [I-D.ietf-ipv6-2461bis] 1414 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 1415 draft-ietf-ipv6-2461bis-09 (work in progress), 1416 October 2006. 1418 [I-D.ietf-ipv6-over-ppp-v2] 1419 Varada, S., "IP Version 6 over PPP", 1420 draft-ietf-ipv6-over-ppp-v2-02 (work in progress), 1421 June 2005. 1423 [I-D.ietf-radext-delegated-prefix] 1424 Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1425 Attribute", draft-ietf-radext-delegated-prefix-05 (work in 1426 progress), October 2006. 1428 [I-D.ietf-softwire-security-requirements] 1429 Yamamoto, S., "Softwire Security Analysis and 1430 Requirements", 1431 draft-ietf-softwire-security-requirements-01 (work in 1432 progress), October 2006. 1434 [I-D.stevant-softwire-accounting] 1435 Stevant, B., "Accounting on Softwires", 1436 draft-stevant-softwire-accounting-01 (work in progress), 1437 October 2006. 1439 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1440 Protocol (CHAP)", RFC 1994, August 1996. 1442 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 1443 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1445 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1446 Addresses", RFC 4193, October 2005. 1448 [RFC4293] Routhier, S., "Management Information Base for the 1449 Internet Protocol (IP)", RFC 4293, April 2006. 1451 Appendix A. Revision History 1453 [Note to RFC Editor: please remove this entire appendix, and the 1454 corresponding entries in the table of contents, prior to 1455 publication.] 1457 Changes between -01 and -02: 1459 o Renamed all "Best Current Practices" sections as 1460 "Recommendations". See for example Section 1.4. 1462 o Moved Provisioning in Section 6. Removed intro text to new 1463 Section 7. 1465 o Removed all normative language from Section 6, Section 7, 1466 Section 8, and Section 9. 1468 o Removed empty sections "Implementation Status", and "Open Issues". 1470 o Fixed "Phase 0" in Section 1. 1472 o Small changes to Section 3.1. 1474 o Change L2TP -> L2TPv2 in some sections, including Section 6. 1476 o Small additions and typo fixes in Section 5.1.1.1 and 1477 Section 5.1.1.2. 1479 o Retitled Section 8 and Section 8.1, changed AAA -> RADIUS. 1481 o New paragraph in Section 9.1. 1483 o New paragraph in Section 8.2.1, including a pointer to 1484 [I-D.ietf-dhc-v6-relay-radius]. 1486 o Moved last paragraph to start of Section 10. 1488 o Moved some references from Normative to Informative. 1490 o Label the steps in Figure 9 and Figure 10. 1492 o Reword paragraph of Section 5.1. 1494 o Describe more messages than flows in Figure 11 and Figure 12. 1496 o Add text about Session Establishment between Figure 11 and 1497 Figure 12. 1499 o Section 5.1.1.1 and Section 5.1.1.2: Updates on Hostname AVP, 1500 Framing Capabilities AVP, Framing Type AVP, Connect Speed AVP and 1501 Challenge and Challenge Response AVPs. 1503 o Retitled Section 5.1.1.3. 1505 o Updates on the use of L2TP HELLO versus LCP, delay for Dead-End 1506 peer detection, and allow LCP. 1508 o Rewording in Section 5.1.3. 1510 o Section 5.2.1: Add a pointer to [RFC4623] and small updates. 1512 o Clarifications on PFC and ACFC, remove Figure 13. 1514 o Section 5.2.3: make references to RFCs for PAP, CHAP, etc. 1516 o Rewordings in Section 5.2.4.1 and Section 5.2.4.2. 1518 o Added Informative references to [RFC4623], [RFC1661], [RFC1662], 1519 [RFC2433], and [RFC3748]. 1521 o Renamed the title and added more details on Section 5.3 and IPv6 1522 ND, including a pointer to [I-D.ietf-ipv6-2461bis]. 1524 o Added text in Section 5.4 about IPv4 PD is non-trivial and non 1525 commonly done. 1527 o Added B. Stevant as Editor. 1529 o Clarification in Section 5.2.4.1 and Section 5.2.4.2 regarding the 1530 scope of the MUST (to the specific scenarios). 1532 o Removed considerations about reverse DNS from Section 6, agreed on 1533 Barcelona. 1535 o Clarified the NAT case in Section 6.1.2 1537 o Added first paragraph in Section 6.2.1 regarding delegated IPv6 1538 prefixes. 1540 o Added new Section 6.3, Section 6.3.1 and Section 6.3.2 summarizing 1541 the scenarios for address allocation. 1543 Changes between -00 and -01: 1545 o Changed alignment in all figures to be centered, and fixed 1546 Figure 9 reference. 1548 o Section 1.4: Added new section with "Best Current Practices" 1549 definition. 1551 o Marked the following sections as "Best Current Practices": 1552 Section 6, Section 8, and Section 9. 1554 o Section 6.1.1, last paragraph: Removed sentence on IPv6 link 1555 address on the PPP link. Mailing list comment from Florent 1556 Parent, 13-Jul-2006. 1558 o Section 6.1.2, last paragraph: Changed IPv4 PPP link address to 1559 use host addresses (/32) negotiated with IPCP instead of /30. 1560 Mailing list comment from Bill Storer, 5-Jul-2006. 1562 o Section 5, Figure 10: Correction, s/SCCSN/SCCCN/; added missing 1563 ICRP, and changed direction of ICCN; typo correction s/IPV6P/ 1564 IPV6CP/. Mailing list comment from Bill Storer, 5-Jul-2006. 1566 o Section 5, Figure 10: Marked CHAP as "Optional - CHAP". 1568 o Section 5.1, Section 5.1.1, and Section 5.1.3: Minor typographical 1569 error correction and rewording of some sentences for grammar. 1571 o Section 5.1.1.1, Host Name AVP: Removed "for debugging purposes" 1572 and added that MAY be used to authenticate users. 1574 o Section 5.1.1.1, Framing Capabilities AVP: Swapped SHOULD and 1575 MUST. Mailing list comment from Bill Storer, 5-Jul-2006, text 1576 from Laurent Toutain. 1578 o Section 5.1.1.1, (Tx) Connect Speed: Correction: "but is *not* 1579 meaningful". 1581 o Section 5.1.1.2, Challenge and Challenge Response AVPs: Removed 1582 the last sentence of the first paragraph. Mailing list comment 1583 from Bill Storer, 5-Jul-2006, text from Laurent Toutain. 1585 o Section 5.1.2: Rewrote paragraph to use L2TPv2 HELLO messages and 1586 not LCP Echo Request and Reply messages to detect tunnel failure, 1587 as redundant in Softwires. Mailing list comment from Florent 1588 Parent, 10-Jul-2006, text from Bill Storer. 1590 o Section 5.2.1, first paragraph: Fixed PPP MTU calculation. 1591 Mailing list comment from Florent Parent, 10-Jul-2006. 1593 o Section 5.2.4.2: Rewrote to generalize the address assignment 1594 failure, to be an all-zeroes address or a protocol reject in 1595 response to the IPCP CONFREQ. Mailing list comment from Bill 1596 Storer, 5-Jul-2006, text from JF Tremblay. 1598 o Section 8, second paragraph: s/Tunnel-Medium /Tunnel-Type /. 1599 Mailing list comment from Bill Storer, 5-Jul-2006. 1601 o Section 8.1.2: Added usage of Framed-IP-Address attribute, and if 1602 not present then use the Tunnel-Client-Endpoint and Tunnel-Server- 1603 Endpoint attributes. Mailing list comment from Bill Storer, 1604 5-Jul-2006, text from JF Tremblay and Bill Storer. 1606 o Completed Section 8.2.2, Section 9.1, Section 9.2, and Section 10. 1608 Revision -00: 1610 o Initial revision. 1612 Authors' Addresses 1614 Bill Storer (editor) 1615 Cisco Systems 1616 170 W Tasman Dr 1617 San Jose, CA 95134 1618 USA 1620 Email: bstorer@cisco.com 1621 Carlos Pignataro (editor) 1622 Cisco Systems 1623 7025 Kit Creek Road 1624 PO Box 14987 1625 Research Triangle Park, NC 27709 1626 USA 1628 Email: cpignata@cisco.com 1630 Maria Alice Dos Santos 1631 Cisco Systems 1632 170 W Tasman Dr 1633 San Jose, CA 95134 1634 USA 1636 Email: mariados@cisco.com 1638 Jean-Francois Tremblay 1639 Hexago 1640 1470 Peel, suite 910 1641 Montreal, QC J4B 2Z5 1642 Canada 1644 Email: jean-francois.tremblay@hexago.com 1646 Bruno Stevant (editor) 1647 GET/ENST Bretagne 1648 2 rue de la Chataigneraie CS17607 1649 Cesson Sevigne, 35576 1650 France 1652 Email: bruno.stevant@enst-bretagne.fr 1654 Full Copyright Statement 1656 Copyright (C) The Internet Society (2006). 1658 This document is subject to the rights, licenses and restrictions 1659 contained in BCP 78, and except as set forth therein, the authors 1660 retain all their rights. 1662 This document and the information contained herein are provided on an 1663 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1664 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1665 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1666 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1667 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1668 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1670 Intellectual Property 1672 The IETF takes no position regarding the validity or scope of any 1673 Intellectual Property Rights or other rights that might be claimed to 1674 pertain to the implementation or use of the technology described in 1675 this document or the extent to which any license under such rights 1676 might or might not be available; nor does it represent that it has 1677 made any independent effort to identify any such rights. Information 1678 on the procedures with respect to rights in RFC documents can be 1679 found in BCP 78 and BCP 79. 1681 Copies of IPR disclosures made to the IETF Secretariat and any 1682 assurances of licenses to be made available, or the result of an 1683 attempt made to obtain a general license or permission for the use of 1684 such proprietary rights by implementers or users of this 1685 specification can be obtained from the IETF on-line IPR repository at 1686 http://www.ietf.org/ipr. 1688 The IETF invites any interested party to bring to its attention any 1689 copyrights, patents or patent applications, or other proprietary 1690 rights that may cover technology that may be required to implement 1691 this standard. Please address the information to the IETF at 1692 ietf-ipr@ietf.org. 1694 Acknowledgment 1696 Funding for the RFC Editor function is provided by the IETF 1697 Administrative Support Activity (IASA).