idnits 2.17.1 draft-ietf-dhc-dhcp4o6-saddr-opt-00.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 : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC7341]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2017) is 2606 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: 'I-D.farrer-softwire-br-multiendpoints' is defined on line 351, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 356, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHCWG I. Farrer 3 Internet-Draft Deutsche Telekom AG 4 Updates: RFC7598 (if approved) Q. Sun 5 Intended status: Standards Track Y. Cui 6 Expires: September 10, 2017 L. Sun 7 Tsinghua University 8 March 9, 2017 10 DHCPv4 over DHCPv6 Source Address Option 11 draft-ietf-dhc-dhcp4o6-saddr-opt-00 13 Abstract 15 DHCPv4 over DHCPv6 [RFC7341] describes a mechanism for dynamically 16 configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6 17 to function with some IPv4-over-IPv6 softwire mechanisms and 18 deployment scenarios, the operator must learn the /128 IPv6 address 19 that the client will use as the source of IPv4-in-IPv6 tunnel. This 20 address, in conjunction with the IPv4 address and the Port Set ID 21 allocated to the DHCP 4o6 client are used to create a binding table 22 entry in the softwire tunnel concentrator. This memo defines two 23 DHCPv6 options used to communicate the source tunnel IPv6 address 24 between the DHCP 4o6 client and server. It also describes a method 25 for configuring the client with the IPv6 address of the border router 26 so that the softwire can be established. It is designed to work in 27 conjunction with the IPv4 address allocation process. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 10, 2017. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 66 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 67 4.1. Provisioning the BR Address . . . . . . . . . . . . . . . 4 68 5. IPv6/IPv4 Binding Message Flow . . . . . . . . . . . . . . . 4 69 6. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . . . 6 70 6.1. DHCPv4 over DHCPv6 Source Address Hint Option . . . . . . 6 71 6.1.1. Client Option Validation Behavior . . . . . . . . . . 6 72 6.2. DHCPv4 over DHCPv6 Source Address Option . . . . . . . . 7 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 10.2. Informative References . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 Deterministic IPv4-over-IPv6 transition technologies require that 84 elements are pre-configured with binding rules for routing traffic to 85 clients. This places a constraint on the location of the client's 86 tunnel endpoint: The tunnel endpoint has to be a pre-determined 87 prefix which is usually be configured on the home gateway device. 88 [RFC7597] describes a DHCPv6 based mechanism for provisioning such 89 deterministic softwires. 91 A dynamic provisioning model, such as using DHCPv4 over DHCPv6 92 [RFC7341] allows much more flexibility in the location of the IPv4- 93 over-IPv6 tunnel endpoint, as the IPv6 address is dynamically 94 signalled back to the service provider so that the corresponding 95 tunnel configuration in the border router (BR) can be created. The 96 DHCP 4o6 client and tunnel client could be run on end devices 97 attached to any routable IPv6 prefix allocated to an end-user, 98 located anywhere within an arbitrary home network topology. Dynamic 99 allocation also helps to optimize IPv4 resource usage as only clients 100 which are currently active are allocated IPv4 addresses. 102 This document describes a mechanism for dynamically provisioning 103 softwires created using DHCPv4 over DHCPv6 (DHCP 4o6), including 104 provisioning the client with the address of the softwire border 105 router (BR) and informing the service provider of client's binding 106 between the dynamically allocated IPv4 address and Port Set ID and 107 the IPv6 address that the softwire Initiator will use for accessing 108 IPv4-over-IPv6 services. 110 It is used with DHCP 4o6 message flows to communicate the binding 111 over the IPv6-only network. The service provider can then use this 112 binding information to provision other functional elements in their 113 network accordingly, e.g. using the client's binding information to 114 synchronise the binding table in the border router. 116 2. Applicability 118 The mechanism described in this document is only suitable for use for 119 provisioning softwire clients via DHCP 4o6. The options described 120 here are only applicable within the DHCP 4o6 message exchange 121 process. Current softwire technologies suitable for extending to 122 incorporate DHCPv4 over DHCPv6 with dynamic IPv4 address leasing 123 include [RFC7597] and [RFC7596]. 125 3. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 4. Solution Overview 133 The solution in this document is intended for the dynamic 134 establishment of IPv4-over-IPv6 softwires. DHCP 4o6 [RFC7341] 135 supports dynamically allocating (shared) IPv4 address. For a 136 softwire to be successfully created, the IPv4 address has to be 137 linked to the client's IPv6 tunnel source address. Within this 138 process, the DHCP 4o6 client uses a DHCPv6 option to signal its 139 tunnel source IPv6 address to the DHCP 4o6 server so that the 140 operator's provisioning system can create the binding and configure 141 the tunnel concentrator accordingly. 143 Two new DHCPv6 options are defined in this memo: 144 OPTION_DHCP4O6_SADDR_HINT and OPTION_DHCP4O6_SADDR. They are 145 intended to be used alongside the normal DHCPv4 IPv4 address 146 allocation message flow in the context of DHCP 4o6. If a DHCP 4o6 147 client supports this mechanism, it MUST include the code of 148 OPTION_DHCP4O6_SADDR_HINT in the Option Request Option (ORO) 149 [RFC3315] when requesting IPv4 configuration through DHCP 4o6. 151 The communication of parameters between the client and server is a 152 two-way process: OPTION_DHCP4O6_SADDR_HINT is optionally used by the 153 DHCP 4o6 server to indicate to the client a preferred IPv6 prefix for 154 binding the received IPv4 configuration and sourcing tunnel traffic. 155 This may be necessary if there are multiple IPv6 prefixes in use in 156 the customer network (e.g. ULAs), or if the specific IPv4-over-IPv6 157 transition mechanism requires the use of a particular prefix for any 158 reason. When the client has selected an IPv6 address to bind the 159 IPv4 configuration to, it passes the address back to the DHCP 4o6 160 server using OPTION_DHCP4O6_SADDR. 162 4.1. Provisioning the BR Address 164 To configure a softwire, the initiator also requires the IPv6 address 165 of the BR. Section 4.2 of [RFC7598] defines option 90 166 (OPTION_S46_BR) for this purpose, but mandates that the option can 167 only be used when encapsulated within one of the softwire container 168 options: OPTION_S46_CONT_MAPE, OPTION_S46_CONT_MAPT or 169 OPTION_S46_CONT_LW. From Section 3 of [RFC7598]: 171 "Softwire46 DHCPv6 clients that receive provisioning options that 172 are not encapsulated in container options MUST silently ignore 173 these options." 175 This document updates [RFC7598] to remove this restriction for DHCPv6 176 option 90 (OPTION_S46_BR) allowing it to appear directly within the 177 list of options in the client's ORO request and directly within 178 subsequent messages sent by the DHCPv6 server. 180 5. IPv6/IPv4 Binding Message Flow 182 The following diagram shows the client/server message flow and how 183 the options defined in this document are used. In each step, the 184 relevant DHCPv4 message is given above the arrow and the relevant 185 options below the arrow. All the DHCPv4 messages here are 186 encapsulated in DHCPv4-query or DHCPv4-response messages, and those 187 options are included in the 'options' field of the DHCPv4-query or 188 DHCPv4-response message. 190 DHCP 4o6 DHCP 4o6 191 Client Server 192 | DHCPDISCOVER (DHCPv4) | 193 Step 1 |----------------------------------------------------->| 194 | ORO with OPTION_S46_BR, | 195 | OPTION_DHCP4O6_SADDR_HINT(DHCPv6) | 196 | | 197 | DHCPOFFER (DHCPv4) | 198 Step 2 |<-----------------------------------------------------| 199 | OPTION_S46_BR, OPTION_DHCP4O6_SADDR_HINT | 200 | (cipv6-prefix-hint with service provider's | 201 | preferred prefix) (DHCPv6) | 202 | | 203 | DHCPREQUEST (DHCPv4) | 204 Step 3 |----------------------------------------------------->| 205 | OPTION_S46_BR, | 206 | OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with | 207 | client's bound /128 IPv6 address) (DHCPv6) | 208 | | 209 | DHCPACK (DHCPv4) | 210 Step 4 |<-----------------------------------------------------| 211 | OPTION_S46_BR, | 212 | OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with | 213 | client's bound /128 IPv6 prefix) (DHCPv6) | 214 | | 216 IPv6/IPv4 Binding Message Flow 218 A client attempting dynamic softwire configuration includes the 219 option code for OPTION_BR_PREFIX, OPTION_DHCP4O6_SADDR_HINT in the 220 DHCPv6 ORO in all DHCPv4-query messages it sends. 222 When a DHCP 4o6 Server replies with a DHCPOFFER message, it SHOULD 223 include OPTION_S46_BR. It MAY also include 224 OPTION_DHCP4O6_SADDR_HINT, which is used to indicate a preferred 225 prefix that the client should use to bind IPv4 configuration to. If 226 this option is received, the client MUST perform a longest prefix 227 match between cipv6-prefix-hint and all prefixes/addresses in use on 228 the device. If a match is found, the selected prefix MUST then be 229 used to bind the received IPv4 configuration to and source the tunnel 230 from. If no match is found, or the client doesn't receive 231 OPTION_DHCP4O6_SADDR_HINT the client MAY select any valid IPv6 232 address to use as the tunnel source. 234 Once the client has selected which prefix it will use, it MAY use 235 either an existing IPv6 address that is already configured on an 236 interface, or create a new address specifically for use as the 237 softwire source address (e.g. using an Interface Identifier 238 constructed as per Section 6 of [RFC7597]). If a new address is 239 being created, the client MUST complete configuration of the new 240 address, performing duplicate address detection (if required) before 241 proceeding to Step 3. 243 OPTION_DHCP4O6_SADDR is used by the client to inform the DHCP 4o6 244 Server which IPv6 address the IPv4 configuration has been bound to. 245 The client MUST put the selected IPv6 softwire source address into 246 this option and include it in the DHCPv4-response message when it 247 sends the DHCPREQUEST message. 249 6. DHCPv6 Options 251 6.1. DHCPv4 over DHCPv6 Source Address Hint Option 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | OPTION_DHCP4O6_SADDR_HINT | option-length | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 |cipv6-hintlen | | 259 +-+-+-+-+-+-+-+-+ cipv6-prefix-hint . 260 . (variable length) . 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 o option-code: OPTION_DHCP4O6_SADDR_HINT (TBA1) 264 o option-length: 1 + length of cipv6-prefix-hint, specified in 265 bytes. 266 o cipv6-hintlen: 8-bit field expressing the bit mask length of the 267 IPv6 prefix specified in cipv6-prefix-hint. Valid values are 0 to 268 128. 269 o cipv6-prefix-hint: The IPv6 prefix indicating the preferred prefix 270 for the client to bind the received IPv4 configuration to. The 271 length is (cipv6-hintlen + 7) / 8. The field is padded on the 272 right with zero bits up to the nearest octet boundary when cipv6- 273 prefix-hint is not evenly divisible by 8. 275 OPTION_DHCP4O6_SADDR_HINT is a singleton. Servers MUST NOT send more 276 than one instance of the OPTION_DHCP4O6_SADDR_HINT option. 278 6.1.1. Client Option Validation Behavior 280 On receipt of the OPTION_DHCP4O6_SADDR_HINT option, the client makes 281 the following validation checks: 283 o The received cipv6-hintlen value is not larger than 128. 285 o The received cipv6-hintlen value is not larger than the number of 286 bytes sent in the cipv6-prefix-hint field. (e.g. the cipv6-hintlen 287 is 128 but the cipv6-prefix-hint has only 8 bytes). 289 For either of these cases the receiver MAY either discard the option 290 and proceed to attempt configuration as if the option had not been 291 received, or attempt to use the received values for the long prefix 292 match anyway. 294 The receiver MUST only use bits the cipv6-prefix-hint field up to the 295 value specified in the cipv6-hintlen when performing the longest 296 prefix match. cipv6-prefix-hint bits beyond this value MUST be 297 ignored. 299 6.2. DHCPv4 over DHCPv6 Source Address Option 301 The format of DHCPv4 over DHCPv6 Source address option is defined as 302 follows: 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | OPTION_DHCP4O6_SADDR | option-length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | | 310 + cipv6-src-address + 311 . (128 bits) . 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 o option-code: OPTION_DHCP4O6_SADDR (TBA2) 315 o option-length: 16. 316 o cipv6-src-address: 16 bytes long; The IPv6 address that the client 317 has bound the allocated IPv4 configuration to. 319 7. Security Considerations 321 Security considerations which are applicable to [RFC7341] are also 322 applicable here. 324 8. IANA Considerations 326 IANA is requested to allocate a DHCPv6 option code for 327 OPTION_DHCP4O6_SADDR_HINT and a DHCPv4 option code for 328 OPTION_DHCP4O6_SADDR. 330 9. Acknowledgements 332 The authors would like to thank Ted Lemon, Lishan Li and Tatuya 333 Jinmei for their contributions and comments. 335 10. References 337 10.1. Normative References 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 345 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 346 RFC 7341, DOI 10.17487/RFC7341, August 2014, 347 . 349 10.2. Informative References 351 [I-D.farrer-softwire-br-multiendpoints] 352 Farrer, I. and Q. Sun, "Multiple BR Tunnel Endpoint 353 Addresses", draft-farrer-softwire-br-multiendpoints-01 354 (work in progress), July 2015. 356 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 357 RFC 2131, DOI 10.17487/RFC2131, March 1997, 358 . 360 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 361 C., and M. Carney, "Dynamic Host Configuration Protocol 362 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 363 2003, . 365 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 366 Farrer, "Lightweight 4over6: An Extension to the Dual- 367 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 368 July 2015, . 370 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 371 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 372 Port with Encapsulation (MAP-E)", RFC 7597, 373 DOI 10.17487/RFC7597, July 2015, 374 . 376 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 377 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 378 Configuration of Softwire Address and Port-Mapped 379 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 380 . 382 Authors' Addresses 384 Ian Farrer 385 Deutsche Telekom AG 386 CTO-ATI, Landgrabenweg 151 387 Bonn, NRW 53227 388 Germany 390 Email: ian.farrer@telekom.de 392 Qi Sun 393 Tsinghua University 394 Beijing 100084 395 P.R. China 397 Phone: +86-10-6278-5822 398 Email: sunqi.csnet.thu@gmail.com 400 Yong Cui 401 Tsinghua University 402 Beijing 100084 403 P.R. China 405 Phone: +86-10-6260-3059 406 Email: yong@csnet1.cs.tsinghua.edu.cn 408 Linhui Sun 409 Tsinghua University 410 Beijing 100084 411 P.R. China 413 Phone: +86-10-6278-5822 414 Email: lh.sunlinh@gmail.com