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