idnits 2.17.1 draft-fsc-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 : ---------------------------------------------------------------------------- ** 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 (February 12, 2014) is 3718 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.ietf-softwire-map-dhcp' is defined on line 288, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 304, but no explicit reference was found in the text == Unused Reference: 'RFC3927' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'RFC4361' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'RFC6148' is defined on line 316, but no explicit reference was found in the text == Unused Reference: 'RFC6346' is defined on line 319, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-dhcpv6-04 == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-08 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-06 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-06 == 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: 1 error (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC WG I. Farrer 3 Internet-Draft Deutsche Telekom AG 4 Intended status: Standards Track Q. Sun 5 Expires: August 16, 2014 Y. Cui 6 Tsinghua University 7 February 12, 2014 9 DHCPv4 over DHCPv6 Source Address Option 10 draft-fsc-dhc-dhcp4o6-saddr-opt-00 12 Abstract 14 DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes one 15 possible mechanism for dynamically configuring IPv4 over an IPv6 only 16 network. For DHCPv4 over DHCPv6 to function with some softwire 17 mechanisms, the operator must obtain information about the DHCP 4o6 18 client's allocated IPv4 address and PSID, as well as the /128 IPv6 19 prefix that the client will use as the source of IPv4-in-IPv6 tunnel. 20 This memo defines a DHCPv6 option to convey this IPv6 prefix between 21 the DHCP 4o6 client and server. It is designed to work in 22 conjunction with the DHCPv4 IPv4 address allocation process message 23 flow. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 16, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Applicabiliity . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 68 4. DHCPv4 over DHCPv6 Source Address Option . . . . . . . . . . 6 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 8.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes a 80 mechanism for dynamically configuring IPv4 over an IPv6 only network 81 by transporting the complete set of DHCPv4 messages within a specific 82 pair of DHCPv6 messages. The IPv4 configuration provisioned to the 83 DHCP 4o6 clients is then generally used for configuring IPv4 over 84 IPv6 services. IPv4 addresses can be dynamically leased to DHCP 4o6 85 clients in the same manner as IPv4 addresses are leased to DHCPv4 86 clients in IPv4 networks. The main advantages to this approach is a 87 greater efficiency in the use of limited IPv4 address resources over 88 IPv6 networks. 90 Currently defined IPv4 over IPv6 transition technologies are, by 91 design, quite prescriptive in the location of the tunnel endpoint 92 within the home network. The tunnel endpoint must usually be 93 configured on either the home gateway device, or sourced from a very 94 specific IPv6 tunnel prefix allocated to the home network (and in 95 some cases, both). This is necessary to enable the end-to-end 96 provisioning chain between the IPv4-over-IPv6 client in the home 97 network, the border router (the egress point from the IPv4 over IPv6 98 domain to the IPv4-only domain) and the provisioning systems 99 responsible for configuring the functional elements. 101 The dynamic leasing of IPv4 addresses to clients alters this end-to- 102 end provisioning chain. It can no longer be assumed that a Softwire 103 Initiator sourcing from a specific IPv6 prefix have to use a certain 104 IPv6 address as the source for encapsulating its IPv4 packets. 105 Therefore, a mechanism is necessary to inform the service provider of 106 the binding between the allocated IPv4 address (learnt through 107 DHCPv4) and the IPv6 address that the IPv4 over IPv6 client will use 108 for accessing IPv4-over-IPv6 services. The service provider can then 109 use this binding information to provision other functional elements 110 it their network such as the border router accordingly. 112 A second benefit of such a mechanism is that it allows much more 113 flexibility in the location of the IPv4 over IPv6 tunnel endpoint as 114 this will be dynamically signalled back to the service provider. The 115 DHCP 4o6 client and tunnel client could be run on end devices 116 attached to any valid IPv6 prefix allocated to an end-user, located 117 anywhere within an arbitrary home network topology. 119 As The DHCP 4o6 server manages the leasing of IPv4 addresses to the 120 DHCP 4o6 clients, which runs on the Softwire Initiators, it holds the 121 most accurate IPv4 lease information available across the IPv6 122 network between the server and the client. It follows that the DHCP 123 4o6 server should also hold information about the /128 IPv6 prefixes 124 that active clients are using, so that the server contains a single, 125 comprehensive and up to date dynamic IPv4/IPv6 binding table. 127 This memo describes a DHCPv6 option so that the server can indicate 128 to the client a preferred IPv6 prefix to use (if necessary) and for 129 the client to signal back the /128 IPv6 prefix that they will bind 130 the allocated IPv4 configuration to. The DHCP 4o6 server then stores 131 this information alongside the IPv4 lease information. 133 Current mechanisms suitable for extending to incorporate DHCPv4 over 134 DHCPv6 with dynamic IPv4 address leasing include 135 [I-D.ietf-softwire-map] and [I-D.ietf-softwire-lw4over6]. For these 136 mechanisms to function, the operator needs the information about the 137 DHCP 4o6 client's allocated IPv4 address, PSID and also the /128 IPv6 138 prefix that the client will use to source the IPv4-in-IPv6 tunnel 139 endpoint. 141 2. Applicabiliity 143 Although DHCPv4 over DHCPv6 is used as the configuration protocol 144 throughout this document, the DHCPv6 option and provisioning process 145 which is described here may also be used with other DHCP based IPv4 146 over IPv6 configuration mechanisms, such as DHCPv4 over IPv6 147 [I-D.ietf-dhc-dhcpv4-over-ipv6]. 149 3. Solution Overview 151 The DHCPv6 option (OPTION_DHCPV4OV6_SADDR) described by this memo is 152 intended to be used alongside the normal DHCPv4 IPv4 address 153 allocation message flow as described in [RFC2131], in the context of 154 DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] . It is a two- 155 way communication process, allowing the service provider to 156 (optionally) indicate to the client a preferred prefix alongside the 157 DHCPOFFER message, which can be used for binding the received IPv4 158 configuration and sourcing tunnel traffic. When the client has 159 selected the IPv6 prefix to bind the IPv4 configuration to, it passes 160 this back to the DHCP 4o6 server along with the DHCPREQUEST message. 161 This may be necessary if there are multiple IPv6 prefixes in use in 162 the customer network, or if the specific IPv4 over IPv6 transition 163 mechanism requires the use of a particular prefix for any reason. 165 The following diagram shows the client/server message flow and how 166 the different fields of OPTION_DHCPV4OV6_SADDR are used. In each 167 step, the relevant DHCPv4 message is given above the arrow and the 168 relevant paramaters used in OPTION_DHCPV4OV6_SADDR's fields below the 169 arrow. 171 DHCP 4o6 DHCP 4o6 172 Client Server 173 | DHCPDISCOVER | 174 Step 1 |-------------------------------------------->| 175 | OPTION_DHCPV4OV6_SADDR (blank fields) | 176 | | 177 | DHCPOFFER | 178 Step 2 |<--------------------------------------------| 179 | OPTION_DHCPV4OV6_SADDR (cipv6-prefix-hint | 180 | with service provider's preferred prefix) | 181 | | 182 | DHCPREQUEST | 183 Step 3 |-------------------------------------------->| 184 | OPTION_DHCPV4OV6_SADDR (cipv6-bound-prefix | 185 | with client's bound /128 IPv6 prefix) | 186 | | 187 | DHCPACK | 188 Step 4 |<--------------------------------------------| 189 | OPTION_DHCPV4OV6_SADDR (cipv6-bound-prefix | 190 | with client's bound /128 IPv6 prefix) | 191 | | 193 IPv6/IPv4 Binding Message Flow 195 The OPTION_DHCPV4OV6_SADDR (defined below) option is included by the 196 DHCP 4o6 client within DHCPv4-query messages. The DHCP 4o6 server 197 MAY reply with this option within DHCPv4-response messages. 199 The DHCP 4o6 Server and Client MAY implement the 200 OPTION_DHCPV4OV6_SADDR option. If used, this option MUST be present 201 within all future DHCPv4 over DHCPv6 transactions. 203 The option comprises of two prefixes (with associated prefix length 204 fields): 206 cipv6-prefix-hint Used by the server to indicate a preferred prefix 207 that the client should use to bind IPv4 208 configuration to. If this field contains a 209 prefix, the client MUST perform a longest prefix 210 match between cipv6-prefix-hint and all prefixes 211 configured on the device. The selected prefix 212 MUST then be used to bind the received IPv4 213 configuration to. If this field is left blank, 214 then the client can select any valid IPv6 prefix. 215 cipv6-bound-prefix Used by the client to inform the DHCP 4o6 Server 216 of the IPv6 prefix that it has bound the IPv4 217 configuration to. This MUST be a /128 prefix 218 configured on the client. 220 4. DHCPv4 over DHCPv6 Source Address Option 222 The format of DHCPv4 over DHCPv6 Source address option is defined as 223 follows: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | OPTION_DHCPV4OV6_SADDR | option-length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | cipv6-hintlen | | 231 +-+-+-+-+-+-+-+-+ cipv6-prefix-hint . 232 . (variable length) . 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |cipv6-boundlen | | 235 +-+-+-+-+-+-+-+-+ cipv6-bound-prefix . 236 . (variable length) . 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 o option-code: OPTION_DHCPV4OV6_SADDR (TBA) 240 o option-length: 2 + length of cipv6-prefix-hint + length of cipv6 241 -bound-prefix, specified in bytes. 242 o cipv6-hintlen: 8-bit field expressing the bit mask length of the 243 IPv6 prefix specified in cipv6-prefix-hint. 244 o cipv6-prefix-hint: The IPv6 prefix that the server uses to 245 indicate the preferred prefix that the client should use to bind 246 IPv4 configuration to. 247 o cipv6-boundlen: 8-bit field expressing the bit mask length of the 248 IPv6 prefix specified in cipv6-bound-prefix. Default: 128. 249 o cipv6-bound-prefix: The IPv6 prefix that the client is using to 250 bind the allocated IPv4 configuration to. 252 5. Security Considerations 254 TBD 256 6. IANA Considerations 258 IANA is requested to allocate the DHCPv6 option code: 259 OPTION_DHCPV4OV6_SADDR. 261 7. Acknowledgements 263 8. References 265 8.1. Normative References 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, March 1997. 270 8.2. Informative References 272 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 273 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 274 Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- 275 dhcpv4-over-dhcpv6-04 (work in progress), January 2014. 277 [I-D.ietf-dhc-dhcpv4-over-ipv6] 278 Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4 279 over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-08 280 (work in progress), October 2013. 282 [I-D.ietf-softwire-lw4over6] 283 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 284 I. Farrer, "Lightweight 4over6: An Extension to the DS- 285 Lite Architecture", draft-ietf-softwire-lw4over6-06 (work 286 in progress), February 2014. 288 [I-D.ietf-softwire-map-dhcp] 289 Mrugalski, T., Troan, O., Dec, W., Bao, C., 290 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 291 for configuration of Softwire Address and Port Mapped 292 Clients", draft-ietf-softwire-map-dhcp-06 (work in 293 progress), November 2013. 295 [I-D.ietf-softwire-map] 296 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 297 Murakami, T., and T. Taylor, "Mapping of Address and Port 298 with Encapsulation (MAP)", draft-ietf-softwire-map-10 299 (work in progress), January 2014. 301 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 302 2131, March 1997. 304 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 305 and M. Carney, "Dynamic Host Configuration Protocol for 306 IPv6 (DHCPv6)", RFC 3315, July 2003. 308 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 309 Configuration of IPv4 Link-Local Addresses", RFC 3927, May 310 2005. 312 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 313 Identifiers for Dynamic Host Configuration Protocol 314 Version Four (DHCPv4)", RFC 4361, February 2006. 316 [RFC6148] Kurapati, P., Desetti, R., and B. Joshi, "DHCPv4 Lease 317 Query by Relay Agent Remote ID", RFC 6148, February 2011. 319 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 320 IPv4 Address Shortage", RFC 6346, August 2011. 322 Authors' Addresses 324 Ian Farrer 325 Deutsche Telekom AG 326 CTO-ATI, Landgrabenweg 151 327 Bonn, NRW 53227 328 Germany 330 Email: ian.farrer@telekom.de 332 Qi Sun 333 Tsinghua University 334 Beijing 100084 335 P.R.China 337 Phone: +86-10-6278-5822 338 Email: sunqi@csnet1.cs.tsinghua.edu.cn 340 Yong Cui 341 Tsinghua University 342 Beijing 100084 343 P.R.China 345 Phone: +86-10-6260-3059 346 Email: yong@csnet1.cs.tsinghua.edu.cn