idnits 2.17.1 draft-fsc-softwire-dhcp4o6-saddr-opt-02.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 21 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2015) is 3218 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 352, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 376, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-farrer-softwire-br-multiendpoints-00 -- 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 Intended status: Standards Track Q. Sun 5 Expires: January 5, 2016 Y. Cui 6 Tsinghua University 7 July 4, 2015 9 DHCPv4 over DHCPv6 Source Address Option 10 draft-fsc-softwire-dhcp4o6-saddr-opt-02 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 is designed to work in 24 conjunction with the IPv4 address allocation process. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 5, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 63 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 64 5. IPv6/IPv4 Binding Message Flow . . . . . . . . . . . . . . . 4 65 6. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. DHCPv4 over DHCPv6 Source Address Hint Option . . . . . . 6 67 6.2. DHCPv4 over DHCPv6 Source Address Option . . . . . . . . 6 68 6.3. Border Router Prefix Option . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 10.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 Deterministic IPv4-over-IPv6 transition technologies require that 80 elements are pre-configured with binding rules for routing traffic to 81 clients. This places a constraint on the location of the client's 82 tunnel endpoint: The tunnel endpoint has to be a pre-determined 83 prefix which is usually be configured on the home gateway device. 84 [I-D.ietf-softwire-map-dhcp] describes a DHCPv6 based mechanism for 85 provisioning such deterministic softwires. 87 If a dynamic provisioning model is used, such as using DHCPv4 over 88 DHCPv6, then pre-configuation of the softwire elements is not 89 possible and client rules must be created/deleted in line with the 90 allocation of IPv4 addresses to clients. This has the benefit of 91 removing the fixed address constraint for the client's tunnel 92 endpoint, as the address that the client will use can be learnt when 93 the tunnel is provisioned. The operator's tunnel concentrator(s) can 94 then be configured with the binding rule. 96 This document describes a mechanism for informing the service 97 provider of the binding between the dynamically allocated IPv4 98 address and Port Set ID (learnt through DHCPv4 over DHCPv6) and the 99 IPv6 address that the softwire Initiator will use for accessing IPv4- 100 over-IPv6 services. It is used with DHCPv4 over DHCPv6 [RFC7341] 101 message flows to communicate the binding over the IPv6-only network. 102 The service provider can then use this binding information to 103 provision other functional elements in their network accordingly, 104 e.g. using the client's binding information to synchronise the 105 binding table in the border router. 107 The mechanism allows much more flexibility in the location of the 108 IPv4-over-IPv6 tunnel endpoint, as the IPv6 address is dynamically 109 signalled back to the service provider. The DHCP 4o6 client and 110 tunnel client could be run on end devices attached to any routable 111 IPv6 prefix allocated to an end-user, located anywhere within an 112 arbitrary home network topology. 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 [I-D.ietf-softwire-map] and [I-D.ietf-softwire-lw4over6]. 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 DHCPv4 over DHCPv6 145 [RFC7341]. If a DHCP 4o6 client supports this mechanism, it MUST 146 include the code of OPTION_DHCP4O6_SADDR_HINT in the Option Request 147 Option (ORO) [RFC3315] when requesting IPv4 configuration through 148 DHCP 4o6. 150 The communication of parameters between the client and server is a 151 two-way process: OPTION_DHCP4O6_SADDR_HINT is optionally used by the 152 DHCP 4o6 server to indicate to the client a preferred IPv6 prefix for 153 binding the received IPv4 configuration and sourcing tunnel traffic. 154 This may be necessary if there are multiple IPv6 prefixes in use in 155 the customer network (e.g. ULAs), or if the specific IPv4-over-IPv6 156 transition mechanism requires the use of a particular prefix for any 157 reason. When the client has selected an IPv6 address to bind the 158 IPv4 configuration to, it passes the address back to the DHCP 4o6 159 server through OPTION_DHCP4O6_SADDR. 161 A softwire initiator also requires the IPv6 address of the border 162 router (i.e. softwire tunnel concentrator). In the dynamic mode, it 163 SHOULD acquire an IPv6 prefix of the BR through OPTION_BR_PREFIX. 164 Then the /128 border router address is constructed in the same manner 165 as described in [I-D.ietf-softwire-map], by concatenating the 166 OPTION_BR_PREFIX with IPv4 address and PSID. 168 To configure a softwire with DHCP 4o6, the DHCP client requests the 169 4o6 Server Address option using DHCPv6. If the DHCPv6 server 170 includes the DHCP 4o6 Server Address option in its response, then 171 DHCPv4 over DHCPv6 can be enabled, as in [RFC7341]. If the IPv6 172 source address of the client changes (such as IPv6 lease expiration, 173 etc.), the client follows the Section 9 of [RFC7341] to re-enable the 174 DHCPv4-over-DHCPv6 function. 176 5. IPv6/IPv4 Binding Message Flow 178 The following diagram shows the client/server message flow and how 179 the options defined in this document are used. In each step, the 180 relevant DHCPv4 message is given above the arrow and the relevant 181 options below the arrow. The DHCPv4 messages are encapsulated in 182 DHCPv4-query or DHCPv4-response messages, and those options are 183 included in the 'options' field of the DHCPv4-query or 184 DHCPv4-response message. 186 DHCP 4o6 DHCP 4o6 187 Client Server 188 | DHCPDISCOVER (DHCPv4) | 189 Step 1 |----------------------------------------------------->| 190 | ORO with OPTION_BR_PREFIX, | 191 | OPTION_DHCP4O6_SADDR_HINT(DHCPv6) | 192 | | 193 | DHCPOFFER (DHCPv4) | 194 Step 2 |<-----------------------------------------------------| 195 | OPTION_BR_PREFIX, OPTION_DHCP4O6_SADDR_HINT | 196 | (cipv6-prefix-hint with service provider's | 197 | preferred prefix) (DHCPv6) | 198 | | 199 | DHCPREQUEST (DHCPv4) | 200 Step 3 |----------------------------------------------------->| 201 | OPTION_BR_PREFIX, | 202 | OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with | 203 | client's bound /128 IPv6 address) (DHCPv6) | 204 | | 205 | DHCPACK (DHCPv4) | 206 Step 4 |<-----------------------------------------------------| 207 | OPTION_BR_PREFIX, | 208 | OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with | 209 | client's bound /128 IPv6 prefix) (DHCPv6) | 210 | | 212 IPv6/IPv4 Binding Message Flow 214 A client attempting dynamic softwire configuration includes the 215 option code for OPTION_BR_PREFIX, OPTION_DHCP4O6_SADDR_HINT in the 216 DHCPv6 ORO in all DHCPv4-query messages it sends. 218 When a DHCP 4o6 Server replies with a DHCPOFFER message, it SHOULD 219 include an OPTION_BR_PREFIX. It MAY also include 220 OPTION_DHCP4O6_SADDR_HINT, which is used to indicate a preferred 221 prefix that the client should use to bind IPv4 configuration to. If 222 this option is received, the client MUST perform a longest prefix 223 match between cipv6-prefix-hint and all prefixes/addresses in use on 224 the device. If a match is found, the selected prefix MUST then be 225 used to bind the received IPv4 configuration to. If the client 226 doesn't receive OPTION_DHCP4O6_SADDR_HINT the client can select any 227 valid /128 IPv6 prefix to use. 229 OPTION_DHCP4O6_SADDR is used by the client to inform the DHCP 4o6 230 Server which IPv6 address the IPv4 configuration has been bound to. 231 The client MUST put the selected IPv6 address into this option and 232 include it in the DHCPv4-response message when it sends the 233 DHCPREQUEST message. 235 6. DHCPv6 Options 237 6.1. DHCPv4 over DHCPv6 Source Address Hint Option 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | OPTION_DHCP4O6_SADDR_HINT | option-length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 |cipv6-hintlen | | 245 +-+-+-+-+-+-+-+-+ cipv6-prefix-hint . 246 . (variable length) . 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 o option-code: OPTION_DHCP4O6_SADDR_HINT (TBA1) 250 o option-length: 1 + length of cipv6-prefix-hint, specified in 251 bytes. 252 o cipv6-hintlen: 8-bit field expressing the bit mask length of the 253 IPv6 prefix specified in cipv6-prefix-hint. 254 o cipv6-prefix-hint: The IPv6 prefix indicating the preferred prefix 255 for the client to bind the received IPv4 configuration to. 257 6.2. DHCPv4 over DHCPv6 Source Address Option 259 The format of DHCPv4 over DHCPv6 Source address option is defined as 260 follows: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | OPTION_DHCP4O6_SADDR | option-length | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 + cipv6-src-address + 269 . (128 bits) . 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 o option-code: OPTION_DHCP4O6_SADDR (TBA2) 273 o option-length: 16. 274 o cipv6-src-address: The IPv6 address that the client has bound the 275 allocated IPv4 configuration to. 277 6.3. Border Router Prefix Option 279 The format of Border Router Prefix option is defined as follows: 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | OPTION_BR_PREFIX | option-length | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 |br-prefix6-len | | 287 +-+-+-+-+-+-+-+-+ br-ipv6-prefix + 288 . (variable length) . 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 o ooption-code: OPTION_BR_PREFIX (TBA3) 292 o option-length: 1 + length of br-ipv6-prefix specified in bytes. 293 o br-prefix6-len: 8 bits long field expressing the length of the 294 IPv6 prefix specified in the br-ipv6-prefix field. 295 o br-ipv6-prefix: a variable length field specifying the IPv6 296 address or prefix for the border router. It SHOULD be /64 or 297 /128. 299 This option provisions the softwire initiator with an IPv6 prefix of 300 BR. If the prefix length is /128, the softwire initiator takes this 301 /128 IPv6 address as the BR's tunnel endpoint address. If the prefix 302 length is /64, the softwire initiator MUST create the BR's /128 303 tunnel endpoint address by concatenating that prefix, its IPv4 304 address and PSID. This is similar to the initiator creating its own 305 IPv6 tunnel endpoint address [I-D.ietf-softwire-map]. 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Prefix from the OPTION_BR_PREFIX | 311 | (64-bits) | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Zero Padding | IPv4 Address | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | IPv4 Addr cont. | PSID | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 o Prefix from the OPTION_BR_PREFIX: The IPv6 prefix got from the 319 OPTION_BR_PREFIX. 320 o Padding: Padding (all zeros). 321 o IPv4 Address: Public IPv4 address allocated to the client 322 o PSID: Port Set ID allocated to the client, left padded with zeros 323 to 16-bits. If no PSID is provisioned, all zeros. 325 7. Security Considerations 327 TBD 329 8. IANA Considerations 331 IANA is requested to allocate the DHCPv6 option codes: 332 OPTION_DHCP4O6_SADDR_HINT, OPTION_DHCP4O6_SADDR and OPTION_BR_PREFIX. 334 9. Acknowledgements 336 The authors would like to thank Ted Lemon and Lishan Li for their 337 contributions. 339 10. References 341 10.1. Normative References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, March 1997. 346 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 347 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 348 7341, August 2014. 350 10.2. Informative References 352 [I-D.farrer-softwire-br-multiendpoints] 353 Farrer, I. and Q. Sun, "Multiple Tunnel Endpoints on 354 Border Router", draft-farrer-softwire-br-multiendpoints-00 355 (work in progress), March 2015. 357 [I-D.ietf-softwire-lw4over6] 358 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 359 I. Farrer, "Lightweight 4over6: An Extension to the DS- 360 Lite Architecture", draft-ietf-softwire-lw4over6-13 (work 361 in progress), November 2014. 363 [I-D.ietf-softwire-map] 364 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 365 Murakami, T., and T. Taylor, "Mapping of Address and Port 366 with Encapsulation (MAP)", draft-ietf-softwire-map-13 367 (work in progress), March 2015. 369 [I-D.ietf-softwire-map-dhcp] 370 Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 371 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 372 configuration of Softwire Address and Port Mapped 373 Clients", draft-ietf-softwire-map-dhcp-12 (work in 374 progress), March 2015. 376 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 377 2131, March 1997. 379 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 380 and M. Carney, "Dynamic Host Configuration Protocol for 381 IPv6 (DHCPv6)", RFC 3315, July 2003. 383 Authors' Addresses 385 Ian Farrer 386 Deutsche Telekom AG 387 CTO-ATI, Landgrabenweg 151 388 Bonn, NRW 53227 389 Germany 391 Email: ian.farrer@telekom.de 393 Qi Sun 394 Tsinghua University 395 Beijing 100084 396 P.R. China 398 Phone: +86-10-6278-5822 399 Email: sunqi.csnet.thu@gmail.com 401 Yong Cui 402 Tsinghua University 403 Beijing 100084 404 P.R. China 406 Phone: +86-10-6260-3059 407 Email: yong@csnet1.cs.tsinghua.edu.cn