idnits 2.17.1 draft-fsc-softwire-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 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 ([I-D.ietf-dhc-dhcpv4-over-dhcpv6]), 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 (June 30, 2014) is 3559 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 327, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 330, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-07 == 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: January 1, 2015 Y. Cui 6 Tsinghua University 7 June 30, 2014 9 DHCPv4 over DHCPv6 Source Address Option 10 draft-fsc-softwire-dhcp4o6-saddr-opt-00 12 Abstract 14 DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes a 15 mechanism for dynamically configuring IPv4 over an IPv6-only network. 16 For DHCPv4 over DHCPv6 to function with some IPv4-over-IPv6 softwire 17 mechanisms, the operator must obtain information about the IPv4 18 address and Port Set ID allocated to the DHCP 4o6 client, as well as 19 the /128 IPv6 prefix that the client will use as the source of IPv4- 20 in-IPv6 tunnel. This memo defines a DHCPv6 container option and two 21 DHCPv6 sub-options, to communicate the source tunnel IPv6 address 22 between the DHCP 4o6 client and server. It is designed to work in 23 conjunction with 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 January 1, 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 . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. DHCPv4 over DHCPv6 Source Address Hint Option . . . . . . 5 65 5.2. DHCPv4 over DHCPv6 Source Address Option . . . . . . . . 6 66 5.3. DHCPv4 over DHCPv6 Softwire Container Option . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 9.2. Informative References . . . . . . . . . . . . . . . . . 7 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 these deterministic softwires. 85 This document describes a mechanism to inform the service provider of 86 the binding between the dynamically allocated IPv4 address and Port 87 Set ID (learnt through DHCPv4 over DHCPv6) and the IPv6 address that 88 the Softwire Initiator will use for accessing IPv4-over-IPv6 89 services. It is used with DHCPv4 over DHCPv6 90 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] message flows to communicate the 91 binding over the IPv6-only network. The service provider can then 92 use this binding information to provision other functional elements 93 in their network accordingly (such as the border router). 95 The mechanism allows much more flexibility in the location of the 96 IPv4-over-IPv6 tunnel endpoint, as the IPv6 address is dynamically 97 signalled back to the service provider. The DHCP 4o6 client and 98 tunnel client could be run on end devices attached to any routable 99 IPv6 prefix allocated to an end-user, located anywhere within an 100 arbitrary home network topology. 102 This memo describes extensions to [I-D.ietf-softwire-map-dhcp] to 103 enable the provisioning and tunnel management of softwire initiators 104 configured through DHCPv4 over DHCPv6. 106 Current mechanisms suitable for extending to incorporate DHCPv4 over 107 DHCPv6 with dynamic IPv4 address leasing include 108 [I-D.ietf-softwire-map] and [I-D.ietf-softwire-lw4over6]. 110 2. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 3. Solution Overview 118 The solution described in this document extends the Softwire46 119 container approach in [I-D.ietf-softwire-map-dhcp] by defining a new 120 container type: OPTION_S46_CONT_DHCP4O6. The container is used to 121 carry the sub-options necessary for softwire configuration. A client 122 can indicate its support for dynamic softwire configuration by 123 including the OPTION_S46_CONT_DHCP4O6 option code within the Option 124 Request Option. 126 Two new DHCPv6 sub-options are also described in this memo: 127 OPTION_DHCP4O6_SADDR_HINT and OPTION_DHCP4O6_SADDR. They are 128 intended to be used alongside the normal IPv4 address allocation 129 message flow in the context of DHCPv4 over DHCPv6 130 [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. 132 It is a two-way communication process. The OPTION_DHCP4O6_SADDR_HINT 133 is used by the DHCP 4o6 server to optionally indicate to the client a 134 preferred IPv6 prefix for binding the received IPv4 configuration and 135 sourcing tunnel traffic. This may be necessary if there are multiple 136 IPv6 prefixes in use in the customer network, or if the specific 137 IPv4-over-IPv6 transition mechanism requires the use of a particular 138 prefix for any reason. When the client has selected the IPv6 address 139 to bind the IPv4 configuration to, it passes the address back to the 140 DHCP 4o6 server through OPTION_DHCP4O6_SADDR. 142 A softwire client also requires an address or addresses for the 143 Border Router (softwire tunnel concentrator). This is used as the 144 destination address for the client IPv4-in-IPv6 encapsulated traffic. 146 Section 4.2 of [I-D.ietf-softwire-map-dhcp] describes the 147 OPTION_S46_BR option. This option SHOULD be included as an 148 encapsulated option within OPTION_S46_CONT_DHCP4O6. 150 This mechanism MUST be used with DHCPv4 over DHCPv6. The DHCP client 151 MUST request the 4o6 Server Address option first to get DHCPv4 over 152 DHCPv6 enabled, as in [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. Then the 153 OPTION_S46_CONT_DHCP4O6 MAY be included in DHCPv4-query and 154 DHCPv4-response messages. 156 4. IPv6/IPv4 Binding Message Flow 158 The following diagram shows the client/server message flow and how 159 the container OPTION_S46_CONT_DHCP4O6 and its sub-options are used. 160 In each step, the relevant DHCPv4 message is given above the arrow 161 and the relevant options below the arrow. The DHCPv4 messages are 162 encapsulated in DHCPv4-query or DHCPv4-response message, and those 163 options are included in the 'options' filed of the DHCPv4-query or 164 DHCPv4-response message. 166 DHCP 4o6 DHCP 4o6 167 Client Server 168 | DHCPDISCOVER | 169 Step 1 |----------------------------------------------------->| 170 | ORO with OPTION_S46_CONT_DHCP4O6 | 171 | | 172 | DHCPOFFER | 173 Step 2 |<-----------------------------------------------------| 174 | OPTION_S46_CONT_DHCP4O6 containing OPTION_S46_BR, | 175 | OPTION_DHCP4O6_SADDR_HINT (cipv6-prefix-hint with | 176 | service provider's preferred prefix) | 177 | | 178 | DHCPREQUEST | 179 Step 3 |----------------------------------------------------->| 180 | OPTION_S46_CONT_DHCP4O6 containing OPTION_S46_BR, | 181 | OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with | 182 | client's bound /128 IPv6 address) | 183 | | 184 | DHCPACK | 185 Step 4 |<-----------------------------------------------------| 186 | OPTION_S46_CONT_DHCP4O6 containing OPTION_S46_BR, | 187 | OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with | 188 | client's bound /128 IPv6 prefix) | 189 | | 191 IPv6/IPv4 Binding Message Flow 193 The DHCP 4o6 Server and Client MAY implement the 194 OPTION_S46_CONT_DHCP4O6 option and its sub-options. A client that 195 intends to dynamically configure softwires SHOULD include the code of 196 OPTION_S46_CONT_DHCP4O6 in the ORO when it sends a DHCPDISCOVER 197 message. If so, this container option MUST be present along with 198 relevant sub-options in all future DHCPv4 over DHCPv6 transactions. 199 The OPTION_S46_BR SHOULD be included in the container. 201 When a DHCP 4o6 Server replies with a DHCPOFFER message, it SHOULD 202 include the OPTION_S46_CONT_DHCP4O6 option with the OPTION_S46_BR, 203 but it MAY include the OPTION_DHCP4O6_SADDR_HINT. The 204 OPTION_DHCP4O6_SADDR_HINT is used by the server to indicate a 205 preferred prefix that the client should use to bind IPv4 206 configuration to. If received this sub-option, the client MUST 207 perform a longest prefix match between cipv6-prefix-hint and all 208 prefixes configured on the device. The selected prefix MUST then be 209 used to bind the received IPv4 configuration to. Otherwise, the 210 client can select any valid /128 IPv6 prefix. 212 The OPTION_DHCP4O6_SADDR is used by the client to inform the DHCP 4o6 213 Server of the IPv6 prefix that it has bound the IPv4 configuration 214 to. The client MUST put the selected IPv6 address into this sub- 215 option and include the OPTION_S46_CONT_DHCP4O6 in the DHCPv4-response 216 message when it sends the DHCPREQUEST message. 218 5. DHCPv6 Options 220 5.1. DHCPv4 over DHCPv6 Source Address Hint Option 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | OPTION_DHCP4O6_SADDR_HINT | option-length | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 |cipv6-boundlen | | 228 +-+-+-+-+-+-+-+-+ cipv6-bound-prefix . 229 . (variable length) . 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 o option-code: OPTION_DHCP4O6_SADDR_HINT (TBA1) 233 o option-length: 2 + length of cipv6-prefix-hint, specified in 234 bytes. 235 o cipv6-hintlen: 8-bit field expressing the bit mask length of the 236 IPv6 prefix specified in cipv6-prefix-hint. 237 o cipv6-prefix-hint: The IPv6 prefix that the server uses to 238 indicate the preferred prefix that the client should use to bind 239 IPv4 configuration to. 241 5.2. DHCPv4 over DHCPv6 Source Address Option 243 The format of DHCPv4 over DHCPv6 Source address option is defined as 244 follows: 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | OPTION_DHCP4O6_SADDR | option-length | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | | 252 + cipv6-src-address + 253 . (128 bits) . 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 o option-code: OPTION_DHCP4O6_SADDR (TBA2) 257 o option-length: 16. 258 o cipv6-src-address: The IPv6 address that the client is using to 259 bind the allocated IPv4 configuration to. 261 5.3. DHCPv4 over DHCPv6 Softwire Container Option 263 The DHCP 4o6 Container option specifies the container used to group 264 the relevant options and parameters for configuring the client. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | OPTION_S46_CONT_DHCP4O6 | option-length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 | encapsulated-options (variable length) | 273 . . 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 o option-code: OPTION_S46_CONT_DHCP4O6 (TBA3) 277 o option-length: 2 + length of encapsulated options (specified in 278 bytes) 279 o encapsulated-options: options for configuring the DHCP 4o6 280 Softwire client. 282 6. Security Considerations 284 TBD 286 7. IANA Considerations 288 IANA is requested to allocate the DHCPv6 option code: 289 OPTION_DHCP4O6_SADDR_HINT, OPTION_DHCP4O6_SADDR and 290 OPTION_S46_CONT_DHCP4O6. 292 8. Acknowledgements 294 9. References 296 9.1. Normative References 298 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 299 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 300 Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- 301 dhcpv4-over-dhcpv6-09 (work in progress), June 2014. 303 [I-D.ietf-softwire-map-dhcp] 304 Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 305 W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng, 306 "DHCPv6 Options for configuration of Softwire Address and 307 Port Mapped Clients", draft-ietf-softwire-map-dhcp-07 308 (work in progress), March 2014. 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, March 1997. 313 9.2. Informative References 315 [I-D.ietf-softwire-lw4over6] 316 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 317 I. Farrer, "Lightweight 4over6: An Extension to the DS- 318 Lite Architecture", draft-ietf-softwire-lw4over6-10 (work 319 in progress), June 2014. 321 [I-D.ietf-softwire-map] 322 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 323 Murakami, T., and T. Taylor, "Mapping of Address and Port 324 with Encapsulation (MAP)", draft-ietf-softwire-map-10 325 (work in progress), January 2014. 327 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 328 2131, March 1997. 330 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 331 and M. Carney, "Dynamic Host Configuration Protocol for 332 IPv6 (DHCPv6)", RFC 3315, July 2003. 334 Authors' Addresses 336 Ian Farrer 337 Deutsche Telekom AG 338 CTO-ATI, Landgrabenweg 151 339 Bonn, NRW 53227 340 Germany 342 Email: ian.farrer@telekom.de 344 Qi Sun 345 Tsinghua University 346 Beijing 100084 347 P.R. China 349 Phone: +86-10-6278-5822 350 Email: sunqi@csnet1.cs.tsinghua.edu.cn 352 Yong Cui 353 Tsinghua University 354 Beijing 100084 355 P.R. China 357 Phone: +86-10-6260-3059 358 Email: yong@csnet1.cs.tsinghua.edu.cn