idnits 2.17.00 (12 Aug 2021) /tmp/idnits59972/draft-lee-6man-ra-dslite-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 5, 2010) is 4239 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4862' is defined on line 250, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 266, but no explicit reference was found in the text == Outdated reference: draft-ietf-softwire-dual-stack-lite has been published as RFC 6333 == Outdated reference: draft-ietf-softwire-ds-lite-tunnel-option has been published as RFC 6334 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Working Group Y. Lee 3 Internet-Draft Comcast 4 Intended status: Standards Track M. Boucadair 5 Expires: April 8, 2011 France Telecom 6 X. Xu 7 Huawei 8 October 5, 2010 10 IPv6 RA Option for DS-Lite AFTR Element 11 draft-lee-6man-ra-dslite-01 13 Abstract 15 This document specifies a new optional extension to IPv6 Router 16 Advertisement messages to allow IPv6 routers to advertise DS-Lite 17 AFTR addresses to IPv6 hosts (i.e., a default IPv6 route for DS-Lite 18 traffic). The provisioning of the AFTR address is crucial to access 19 IPv4 connectivity services in a DS-Lite context. Means to ensure 20 reliable delivery of this information to connecting hosts is a must. 22 Furthermore, this RA option can be used as a means to distribute DS- 23 Lite serviced customers among a set of deployed AFTRs without 24 requiring a central knowledge of the underlying topology and deployed 25 AFTRs. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 8, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Coexistence of RA Option and DHCPv6 Option . . . . . . . . . . 3 70 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 6. Neighbour Discovery Extension . . . . . . . . . . . . . . . . . 4 73 6.1. AFTR Element Option . . . . . . . . . . . . . . . . . . . . 4 74 6.1.1. Procedure in IPv6 Host with B4 Implementation . . . . . 5 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 6 81 Appendix A. Load Balancing Use Case . . . . . . . . . . . . . . . 7 82 Appendix B. Scope . . . . . . . . . . . . . . . . . . . . . . . . 8 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 85 1. Introduction 87 Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite] provides a means 88 to guarantee IPv4 service continuity during the transition period 89 where global IPv4 addresses become a scarce resource. In the DS-Lite 90 framework, the B4 element tunnels the IPv4-in-IPv6 datagrams towards 91 one of the available AFTR entities deployed in the provider network. 92 The B4 element can learn the AFTR address by DHCPv6 93 [I-D.ietf-softwire-ds-lite-tunnel-option] or RADIUS 94 [I-D.maglione-softwire-dslite-radius-ext]. 96 The provisioning of the AFTR information to connecting hosts 97 embedding B4 is mandatory for the delivery of IPv4 connectivity 98 services in the context of DS-Lite deployment. As an analogy with 99 native IPv6 connectivity provisioning, the AFTR information (i.e., IP 100 address or FQDN) can be seen as a default IPv6 route for DS-Lite 101 IPv4-in-IPv6 traffic. Indeed, when no AFTR information is 102 provisioned to a requesting host embedding a B4 element, no external 103 IPv4 address would be assigned and the IPv4 traffic won't be 104 delivered outside the local domain. In other terms, fail to 105 provision an AFTR to B4 element will break IPv4 connectivity. 107 Service providers need a reliable and flexible method to provision 108 the AFTR address(es) to the B4 elements in customers' premises. This 109 document describes a mechanism to use a new IPv6 RA Option to 110 advertise the AFTR address to the IPv6 hosts. 112 In the remaining part of the document, host is used for short to 113 denote a host embedding B4 element. 115 2. Motivation 117 A service provider may want to deploy DS-lite without using DHCP. 118 Auto-configuration [RFC4861] allows an IPv6 host to learn the IPv6 119 prefix and IPv6 default gateway solely from the Router Advertisement 120 (RA). In this document, we define a new AFTR RA option so that a B4 121 element can learn a set of AFTRs. 123 3. Coexistence of RA Option and DHCPv6 Option 125 The RA AFTR option and the DHCP option can be used together. When 126 the host receives a RA and the "O" flag is set in the RA, the host 127 may send a DHCPv6 request for AFTR provisioning. If the DHCP server 128 returns the DS-Lite tunnel option, the host may use the address in 129 the option. If the RA does not contain the AFTR option, the RA may 130 send the DHCP request to obtain the AFTR configuration from the DHCP 131 server regardless of whether the "O" flag is set in the RA or not. 133 4. Terminology 135 This document uses terms defined in 136 [I-D.ietf-softwire-dual-stack-lite]. In addition, we define the 137 following new terms: 139 o AFTR Option: IPv6 RA option to deliver AFTR information (e.g., IP 140 address) to IPv6 hosts. 142 o AFTR Element List: A data structure for managing AFTR Element 143 Information in the IPv6 protocol stack in addition to the Neighbor 144 Cache and Destination Cache for Neighbor Discovery. 146 5. Overview 148 This document defines a new ND option called AFTR option that 149 contains the list of addresses of AFTR element. This new option 150 advertises a list of available AFTR elements. This option follows 151 the procedures defined in [RFC4861]. This works the same way that 152 the hosts learn routers and prefixes. The AFTR element is only 153 useful for B4 elements, i.e.- ordinary IPv6 hosts must ignore this 154 option. The IPv6 host with B4 element implemented can learn a list 155 of AFTR elements thanks to this option. 157 The AFTR option can be sent along with other options in the same RA 158 message simultaneously. The router sending the AFTR option in RA 159 must be configured with the AFTR information. The information is 160 provisioned in the first-hop router of the B4 elements. The AFTR 161 option can be used on any network that supports ND. 163 6. Neighbour Discovery Extension 165 This AFTR configuration mechanism in this memo defines a new ND 166 option in Neighbor Discovery: The AFTR Element option. 168 6.1. AFTR Element Option 170 The AFTR Element Option contains one or more IPv6 addresses of the 171 AFTR elements. All of the addresses share the same lifetime value. 172 If a particular AFTR is configured to have different lifetime values, 173 a new AFTR option can be used. Figure 1 shows the AFTR Element 174 Option format. 176 0 1 2 3 177 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Type | Length | Reserved | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Lifetime | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | | 184 : Addresses of IPv6 AFTR Elements : 185 | | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 1 190 Where 192 o Type is the RA AFTR Option type 194 o Length is a 8-bit unsigned integer. The length of the option is 195 in unit of 8 octets. 197 o Reserved is for future use. 199 o Lifetime is a 16-bit unsigned integer. The lifetime associated 200 with the AFTR elements in units of seconds. 202 o Addresses of IPv6 AFTR Elements contain one or more 128-bit IPv6 203 addresses of the AFTR elements. The number of addresses is 204 determined by the Length field. That is, the number if addresses 205 is equal to (Length - 1) / 2. 207 6.1.1. Procedure in IPv6 Host with B4 Implementation 209 When the host receives the option via RA, it checks whether the 210 option is valid. 212 o If the AFTR option is valid, the host should copy the option's 213 value into the B4 configuration. 215 o If the AFTR option is invalid, the host must discard the option. 217 7. IANA Considerations 219 This document requests IANA to assign a new option code for: 221 o DS-Lite AFTR Address 223 8. Security Considerations 225 This document does not introduce any new security in addition to what 226 has been identified in [RFC4861] and 227 [I-D.ietf-softwire-dual-stack-lite]. 229 9. Acknowledgements 231 Many thanks to C. Jacquenet for his review and comments. 233 10. References 235 10.1. Normative References 237 [I-D.ietf-softwire-dual-stack-lite] 238 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 239 Stack Lite Broadband Deployments Following IPv4 240 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work 241 in progress), August 2010. 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, March 1997. 246 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 247 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 248 September 2007. 250 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 251 Address Autoconfiguration", RFC 4862, September 2007. 253 10.2. Informative References 255 [I-D.ietf-softwire-ds-lite-tunnel-option] 256 Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 257 Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite", 258 draft-ietf-softwire-ds-lite-tunnel-option-05 (work in 259 progress), September 2010. 261 [I-D.maglione-softwire-dslite-radius-ext] 262 Maglione, R. and A. Durand, "RADIUS Extensions for Dual- 263 Stack Lite", draft-maglione-softwire-dslite-radius-ext-00 264 (work in progress), July 2010. 266 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 267 Extensions", RFC 2132, March 1997. 269 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 270 More-Specific Routes", RFC 4191, November 2005. 272 Appendix A. Load Balancing Use Case 274 [[Note: The content of this section is still under discussion between 275 authors.]] 277 Load balancing and traffic dimensioning is one of the hot topic to be 278 considered when deploying stateful devices such as AFTRs. Service 279 providers need means to distribute their DS-Lite serviced customers 280 among a set of AFTR devices without experiencing any congestion 281 neither traffic loss due to the overloading of a given AFTR while 282 free AFTR resources are available. This dimensioning task is not new 283 per se. In particular, VoIP service providers rely on DNS to 284 redirect customers traffic to a given SBC (or P-CSCF) node. 286 Various solutions to balance customers among a set of AFTRs can be 287 considered as follows: 289 o DHCPv6 server returns an IPv6 address of an AFTR based on a 290 identifier of the customer. 292 o DHCPv6 server returns a generic FQDN of AFTR nodes. A DNS-based 293 load balancing is implemented during the resolution of the FQDN. 295 o DHCPv6 returns a geographical domain search name which will be 296 used to redirect the client to a given AFTR. The DHCPv6 server 297 needs to correlate the AFTR information with an identifier of the 298 requesting customer. 300 o The DHCPv6 relay agent can insert locally configured information 301 when responding back to a connecting client. 303 o Etc. 305 As an alternative to these modes, RA can be used to implicitly 306 redirect DS-Lite serviced customers to a given AFTR without requiring 307 any use of a customer identifier. DHCPv6 servers are not modified. 309 Access routers can be configured to insert an IP address when sending 310 RAs to attached hosts. The configuration of the information to be 311 inserted in RA messages can be achieved using already deployed tools. 313 Appendix B. Scope 315 It was tempting to define a generic option which is an extension of 316 [RFC4191] to indicate a route which is used by IPv4-in-IPv6 traffic. 317 Since DS-Lite is the only technique which is required crossing a 318 stateful device after the de-capsulation. We decided to limit the 319 applicability scope of this option to DS-Lite. 321 Authors' Addresses 323 Yiu L. Lee 324 Comcast 326 Email: yiu_lee@cable.comcast.com 327 URI: http://www.comcast.com 329 Mohamed Boucadair 330 France Telecom 332 Email: mohamed.boucadair@orange-ftgroup.com 333 URI: http://www.orange-ftgroup.com 335 Xiaohu Xu 336 Huawei 338 Email: xuxh@huawei.com