idnits 2.17.1 draft-fsc-softwire-dhcp4o6-saddr-opt-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 : ---------------------------------------------------------------------------- ** There are 19 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 (September 30, 2014) is 3497 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: 'RFC2131' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 337, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-08 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-10 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-10 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 6 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: April 3, 2015 Y. Cui 6 Tsinghua University 7 September 30, 2014 9 DHCPv4 over DHCPv6 Source Address Option 10 draft-fsc-softwire-dhcp4o6-saddr-opt-01 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, the 17 operator must obtain information about the IPv4 address and Port Set 18 ID allocated to the DHCP 4o6 client, as well as the /128 IPv6 prefix 19 that the client will use as the source of IPv4-in-IPv6 tunnel. This 20 memo defines a DHCPv6 container option and two DHCPv6 sub-options 21 used to communicate the source tunnel IPv6 address between the DHCP 22 4o6 client and server. It is designed to work in conjunction with 23 the IPv4 address allocation process. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 3, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 62 4. IPv6/IPv4 Binding Message Flow . . . . . . . . . . . . . . . 4 63 5. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.1. DHCPv4 over DHCPv6 Source Address Hint Option . . . . . . 6 65 5.2. DHCPv4 over DHCPv6 Source Address Option . . . . . . . . 6 66 5.3. DHCPv4 over DHCPv6 Softwire Container Option . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 9.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 Deterministic IPv4-over-IPv6 transition technologies are prescriptive 78 in the location of the tunnel endpoint within the home network. The 79 tunnel endpoint should usually be configured on either the home 80 gateway device, or sourced from a specific IPv6 tunnel prefix 81 allocated to the home network (and in some cases, both). 82 [I-D.ietf-softwire-map-dhcp] describes a DHCPv6 based mechanism for 83 provisioning such deterministic softwires. 85 This document describes a mechanism for informing the service 86 provider of the binding between the dynamically allocated IPv4 87 address and Port Set ID (learnt through DHCPv4 over DHCPv6) and the 88 IPv6 address that the Softwire Initiator will use for accessing IPv4- 89 over-IPv6 services. It is used with DHCPv4 over DHCPv6 [RFC7341] 90 message flows to communicate the binding over the IPv6-only network. 91 The service provider can then use this binding information to 92 provision other functional elements in their network accordingly, 93 e.g. using the client's binding information to synchronise the 94 binding table in the border router. 96 The mechanism allows much more flexibility in the location of the 97 IPv4-over-IPv6 tunnel endpoint, as the IPv6 address is dynamically 98 signalled back to the service provider. The DHCP 4o6 client and 99 tunnel client could be run on end devices attached to any routable 100 IPv6 prefix allocated to an end-user, located anywhere within an 101 arbitrary home network topology. 103 This memo describes extensions to [I-D.ietf-softwire-map-dhcp] to 104 enable the provisioning and tunnel management of softwire initiators 105 configured through DHCPv4 over DHCPv6. 107 Current mechanisms suitable for extending to incorporate DHCPv4 over 108 DHCPv6 with dynamic IPv4 address leasing include 109 [I-D.ietf-softwire-map] and [I-D.ietf-softwire-lw4over6]. 111 2. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 3. Solution Overview 119 The solution in this document extends the Softwire46 container 120 approach described in [I-D.ietf-softwire-map-dhcp] by defining a new 121 container type: OPTION_S46_CONT_DHCP4O6. The container is used to 122 carry the sub-options necessary for softwire configuration. A client 123 can indicate its support for dynamic softwire configuration by 124 including the OPTION_S46_CONT_DHCP4O6 option code within the Option 125 Request Option. 127 Two new DHCPv6 sub-options are also defined in this memo: 128 OPTION_DHCP4O6_SADDR_HINT and OPTION_DHCP4O6_SADDR. They are 129 intended to be used alongside the normal DHCPv4 IPv4 address 130 allocation message flow in the context of DHCPv4 over DHCPv6 131 [RFC7341]. 133 The communication of parameters between the client and server is two- 134 way: OPTION_DHCP4O6_SADDR_HINT can be (optionally) used by the DHCP 135 4o6 server to optionally indicate to the client a preferred IPv6 136 prefix for binding the received IPv4 configuration and sourcing 137 tunnel traffic. This may be necessary if there are multiple IPv6 138 prefixes in use in the customer network, or if the specific IPv4- 139 over-IPv6 transition mechanism requires the use of a particular 140 prefix for any reason. When the client has selected the IPv6 address 141 to bind the IPv4 configuration to, it passes the address back to the 142 DHCP 4o6 server through OPTION_DHCP4O6_SADDR. 144 A softwire client also requires an address (or addresses) for the 145 Border Router (softwire tunnel concentrator). This is used as the 146 destination address for the client's IPv4-in-IPv6 encapsulated 147 traffic. Section 4.2 of [I-D.ietf-softwire-map-dhcp] describes the 148 OPTION_S46_BR option. This option SHOULD be included as an 149 encapsulated option within OPTION_S46_CONT_DHCP4O6. 151 This mechanism MUST be used with DHCPv4 over DHCPv6. The DHCP client 152 MUST request the 4o6 Server Address option first to get DHCPv4 over 153 DHCPv6 enabled, as in [RFC7341]. Then the OPTION_S46_CONT_DHCP4O6 154 MAY be included in DHCPv4-query and DHCPv4-response messages. If the 155 IPv6 source address of the client changes (such as IPv6 lease 156 expiration, etc.), the client follows the Section 9 of [RFC7341] to 157 reenable the DHCPv4-over-DHCPv6 function. 159 If OPTION_S46_CONT_DHCP4O6 is used, the option (as well as any 160 suboption(s) it contains) MUST be transported in the DHCPv4-query and 161 DHCPv4-response messages [RFC7341]. 163 4. IPv6/IPv4 Binding Message Flow 165 The following diagram shows the client/server message flow and how 166 the OPTION_S46_CONT_DHCP4O6 container and its sub-options are used. 167 In each step, the relevant DHCPv4 message is given above the arrow 168 and the relevant options below the arrow. The DHCPv4 messages are 169 encapsulated in DHCPv4-query or DHCPv4-response message, and those 170 options are included in the 'options' field of the DHCPv4-query or 171 DHCPv4-response message. 173 DHCP 4o6 DHCP 4o6 174 Client Server 175 | DHCPDISCOVER (DHCPv4) | 176 Step 1 |----------------------------------------------------->| 177 | ORO with OPTION_S46_CONT_DHCP4O6 (DHCPv6) | 178 | | 179 | DHCPOFFER (DHCPv4) | 180 Step 2 |<-----------------------------------------------------| 181 | OPTION_S46_CONT_DHCP4O6 containing OPTION_S46_BR, | 182 | OPTION_DHCP4O6_SADDR_HINT (cipv6-prefix-hint with | 183 | service provider's preferred prefix) (DHCPv6) | 184 | | 185 | DHCPREQUEST (DHCPv4) | 186 Step 3 |----------------------------------------------------->| 187 | OPTION_S46_CONT_DHCP4O6 containing OPTION_S46_BR, | 188 | OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with | 189 | client's bound /128 IPv6 address) (DHCPv6) | 190 | | 191 | DHCPACK (DHCPv4) | 192 Step 4 |<-----------------------------------------------------| 193 | OPTION_S46_CONT_DHCP4O6 containing OPTION_S46_BR, | 194 | OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with | 195 | client's bound /128 IPv6 prefix) (DHCPv6) | 196 | | 198 IPv6/IPv4 Binding Message Flow 200 The DHCP 4o6 Server and Client MAY implement the 201 OPTION_S46_CONT_DHCP4O6 option and its sub-options. A client that 202 intends to dynamically configure softwires SHOULD include the option 203 code for OPTION_S46_CONT_DHCP4O6 in the DHCPv6 ORO alongside the 204 DHCPv4 DHCPDISCOVER message. This container option MUST be present, 205 along with relevant sub-options, in all subsequent DHCPv4 over DHCPv6 206 transactions for the lifetime of the IPv4 address lease. 207 OPTION_S46_BR SHOULD also be included in the container. 209 When a DHCP 4o6 Server replies with a DHCPOFFER message, it SHOULD 210 include an OPTION_S46_CONT_DHCP4O6 option containing OPTION_S46_BR. 211 It MAY also include OPTION_DHCP4O6_SADDR_HINT. The 212 OPTION_DHCP4O6_SADDR_HINT is used by the server to indicate a 213 preferred prefix that the client should use to bind IPv4 214 configuration to. If this sub-option is received, the client MUST 215 perform a longest prefix match between cipv6-prefix-hint and all 216 configured prefixes on the device. If a match is found, then the 217 selected prefix MUST then be used to bind the received IPv4 218 configuration to. If the client doesn't receive the sub-option, or 219 the matching fails, the client can select any valid /128 IPv6 prefix 220 to use. 222 OPTION_DHCP4O6_SADDR is used by the client to inform the DHCP 4o6 223 Server which IPv6 prefix the IPv4 configuration has been bound to. 224 The client MUST put the selected IPv6 address into this sub-option 225 and include OPTION_S46_CONT_DHCP4O6 in the DHCPv4-response message 226 when it sends the DHCPREQUEST message. 228 5. DHCPv6 Options 230 5.1. DHCPv4 over DHCPv6 Source Address Hint Option 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | OPTION_DHCP4O6_SADDR_HINT | option-length | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 |cipv6-hintlen | | 238 +-+-+-+-+-+-+-+-+ cipv6-prefix-hint . 239 . (variable length) . 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 o option-code: OPTION_DHCP4O6_SADDR_HINT (TBA1) 243 o option-length: 1 + length of cipv6-prefix-hint, specified in 244 bytes. 245 o cipv6-hintlen: 8-bit field expressing the bit mask length of the 246 IPv6 prefix specified in cipv6-prefix-hint. 247 o cipv6-prefix-hint: The IPv6 prefix indicating the preferred prefix 248 for the client to bind the received IPv4 configuration to. 250 5.2. DHCPv4 over DHCPv6 Source Address Option 252 The format of DHCPv4 over DHCPv6 Source address option is defined as 253 follows: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | OPTION_DHCP4O6_SADDR | option-length | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | | 261 + cipv6-src-address + 262 . (128 bits) . 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 o option-code: OPTION_DHCP4O6_SADDR (TBA2) 266 o option-length: 16. 267 o cipv6-src-address: The IPv6 address that the client has bound the 268 allocated IPv4 configuration to. 270 5.3. DHCPv4 over DHCPv6 Softwire Container Option 272 The DHCP 4o6 Container option carries the relevant options and 273 parameters for configuring the client. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | OPTION_S46_CONT_DHCP4O6 | option-length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | | 281 | encapsulated-options (variable length) | 282 . . 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 o option-code: OPTION_S46_CONT_DHCP4O6 (TBA3) 286 o option-length: length of encapsulated-options (specified in bytes) 287 o encapsulated-options: options for configuring the DHCP 4o6 288 Softwire client. 290 6. Security Considerations 292 TBD 294 7. IANA Considerations 296 IANA is requested to allocate the DHCPv6 option code: 297 OPTION_DHCP4O6_SADDR_HINT, OPTION_DHCP4O6_SADDR and 298 OPTION_S46_CONT_DHCP4O6. 300 8. Acknowledgements 302 9. References 304 9.1. Normative References 306 [I-D.ietf-softwire-map-dhcp] 307 Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 308 W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng, 309 "DHCPv6 Options for configuration of Softwire Address and 310 Port Mapped Clients", draft-ietf-softwire-map-dhcp-08 311 (work in progress), July 2014. 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, March 1997. 316 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 317 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 318 7341, August 2014. 320 9.2. Informative References 322 [I-D.ietf-softwire-lw4over6] 323 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 324 I. Farrer, "Lightweight 4over6: An Extension to the DS- 325 Lite Architecture", draft-ietf-softwire-lw4over6-10 (work 326 in progress), June 2014. 328 [I-D.ietf-softwire-map] 329 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 330 Murakami, T., and T. Taylor, "Mapping of Address and Port 331 with Encapsulation (MAP)", draft-ietf-softwire-map-10 332 (work in progress), January 2014. 334 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 335 2131, March 1997. 337 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 338 and M. Carney, "Dynamic Host Configuration Protocol for 339 IPv6 (DHCPv6)", RFC 3315, July 2003. 341 Authors' Addresses 343 Ian Farrer 344 Deutsche Telekom AG 345 CTO-ATI, Landgrabenweg 151 346 Bonn, NRW 53227 347 Germany 349 Email: ian.farrer@telekom.de 351 Qi Sun 352 Tsinghua University 353 Beijing 100084 354 P.R. China 356 Phone: +86-10-6278-5822 357 Email: sunqi@csnet1.cs.tsinghua.edu.cn 358 Yong Cui 359 Tsinghua University 360 Beijing 100084 361 P.R. China 363 Phone: +86-10-6260-3059 364 Email: yong@csnet1.cs.tsinghua.edu.cn