idnits 2.17.1 draft-cui-dhc-dhcpv4-over-ipv6-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2011) is 4571 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: 'RFC3527' is defined on line 339, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4925 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Cui 3 Internet-Draft P. Wu 4 Intended status: Standards Track J. Wu 5 Expires: April 23, 2012 Tsinghua University 6 T. Lemon 7 Nominum, Inc. 8 October 21, 2011 10 DHCPv4 over IPv6 transport 11 draft-cui-dhc-dhcpv4-over-ipv6-00 13 Abstract 15 Recently, there are demands arising for IPv4 address allocation under 16 IPv6 environment, especially in IPv6 transition scenarios. This 17 document describes the mechanism to survive DHCPv4 over IPv6 network. 18 DHCPv4 messages are transported in IPv6 packets when traversing the 19 IPv6 network. DHCPv4 protocol behavior is extended to support this 20 IPv6 transport. And for the relay case, a new suboption of the Relay 21 Agent Information Option is defined to carry the remote IPv6 address 22 of the clients. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 23, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . . 6 63 6. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . . 6 64 7. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 7 65 8. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . . 7 66 9. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 67 10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 70 11.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 DHCPv4[RFC2131] was not designed with IPv6 consideration. In 75 particular, DHCPv4 cannot work on IPv6 network. However, with IPv4- 76 IPv6 coexistence coming to reality, the demands of allocating IPv4 77 address under IPv6 environment naturally arise. To meet this kind of 78 demands, DHCPv4 should be extended to run over IPv6 network. 80 A typical scenario that probably requires this feature is IPv4-over- 81 IPv6 hub and spoke tunnel[RFC4925]. In this scenario, IPv4-over-IPv6 82 tunnel is used to provide IPv4 connectivity to end users(hosts or end 83 networks), across an IPv6 network. If the IPv4 addresses of the end 84 users are provisioned by the concentrator side, then this address 85 provisioning needs to cross the IPv6 network, too. One such tunnel 86 mechanism is demonstrated in [I-D.cui-softwire-host-4over6]. DHCPv4 87 over IPv6 would be a generic solution for this scenario. 89 Three main flavours of solutions may be considered: 91 o Use DHCPv6 instead of DHCPv4, to provision IPv4-related 92 connectivity. In DHCPv6, the provisioned IPv4 address can be 93 embedded into IPv6 address, or carried within a new option. Along 94 with that, dedicated options are needed to convey IPv4-related 95 information, such as the IPv4 address of DNS server, NTP server, 96 etc. Therefore it will put a certain amount of IPv6-unrelated 97 information into DHCPv6 protocol. 99 o Use DHCPv4 and tunnel DHCPv4-in-IPv4 packets over IPv6. Unlike 100 the previous approach where DHCPv6 is used for both IPv4 and IPv6 101 connectivity, this approach consists in preserving the separation 102 between IPv4 and IPv6 connectivity information. It allows to 103 maintain the IPv4 service without major modification of IPv6- 104 related provisioning resources, and sustains DHCPv4 to be the 105 IPv4-related information carrier. However, this approach enforces 106 an IPv4-in-IPv6 tunnel onto DHCP, and requires extra efforts to 107 maintain tunnel endpoint information for encapsulation use. 109 o Use DHCPv4 and extend it to work over IPv6 transport. This 110 flavour uses IPv6 directly for DHCP packet transport instead of 111 relying on IPv4-in-IPv6 tunnel, and it keeps the advantage of 112 separation with IPv6 connectivity information. This document 113 focuses on this flavour. The document will define the extensions 114 of DHCPv4 protocol behavior, as well as a new suboption of the 115 Relay Agent Information Option, to fully support DHCPv4 over IPv6 116 transport. 118 2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. Terminology 125 This document makes use of the following terms: 127 o DHCPv4: IPv4 Dynamic Host Configuration Protocol [RFC2131]. 129 o Client Relay Agent(CRA): a special DHCPv4 Relay Agent that sits on 130 the same, IPv6-accessable host with the DHCPv4 client. CRA works 131 as a "bridge" between DHCPv4 client and the IPv6 network, to 132 convert between IPv4 transport and IPv6 transport. 134 o IPv6-Transport Server(TSV): a DHCPv4 Server that support supports 135 IPv6 transport. TS can listen on IPv6 for incoming DHCP messages, 136 and sends DHCP messages in IPv6 packets. 138 o IPv6-Transport Relay Agent(TRA): a DHCPv4 Relay Agent that 139 supports IPv6 transport. TRA sits on a machine which has both 140 IPv6 and IPv4 connectivity, and relays DHCP packets between CRA 141 and normal DHCPv4 server. 143 o Client Relay Agent IPv6 Address Sub-option(6ADDR suboption): a new 144 suboption of DHCP Relay Agent Information Option[RFC3046] defined 145 in this document. 6ADDR suboption is used by TRA to carry the IPv6 146 address of a CRA. 148 4. Protocol Summary 150 The scenario for DHCPv4 over IPv6 transport is shown in Figure 1. 151 DHCPv4 clients and DHCPv4 server/relay are separated by an IPv6 152 network in the middle. DHCP messages between a client and the 153 server/relay cannot naturally be forwarded to each other because they 154 are IPv4 UDP packets by default, either unicast or broadcast. To 155 bridge this gap, both the client side and the server/relay side 156 should enable DHCPv4 to work over IPv6 transport, i.e., get delivered 157 in IPv6 UDP packets and traverse IPv6 network. 159 On the client side, a special relay agent called Client Relay Agent 160 is placed on the same machine with the client. CRA is used to relay 161 DHCP messages from the client to the server, and from the server to 162 the client. CRA sends DHCPv4 messages to the server through unicast 163 IPv6 UDP, and receives unicast IPv6 UDP packets with the DHCPv4 164 messages from the server. By using CRA, no extension is required on 165 the client. 167 +-------------------------+ 168 +------+ | 169 |DHCPv4| | 170 |Client| +-------+ 171 +------+ |DHCPv4 | 172 | IPv6 Network |Server/| 173 +------+ |Relay | 174 |DHCPv4| +-------+ 175 |Client| | 176 +------+ | 177 +-------------------------+ 179 Figure 1 Scenario of DHCPv4 over IPv6 Transport 181 The IPv6-Transport DHCPv4 server can receive DHCP packets delivered 182 in IPv6 UDP from CRA, and send out DHCP packets to CRA using IPv6 183 UDP(figure 2(a)). TSV should send such packets to the IPv6 address 184 from which TSV receives corresponding DHCP messages earlier. 186 When CRAs communicate with an IPv6-Transport Relay Agent rather than 187 with a server directly, the situation will be a little more 188 complicated. Besides the IPv6 connection, TRA also has IPv4 189 connection and communicates with a regular DHCPv4 server through 190 IPv4. So TRA relays DHCP messages between CRAs in IPv6 and regular 191 server in IPv4. TRA has to use the DHCP Relay Agent Information 192 Option(Option 82) to record the IPv6 address of a CRA, which will be 193 used as forwarding destination when relaying DHCP a message from the 194 server. Since Option 82 doesn't has an existing suboption that fits 195 in here, this document defines a new Client Relay Agent IPv6 Address 196 Sub-option. 198 +------+ +------+ 199 |client| IPv6 network |TSV | 200 |+CRA |----------------| | 201 +------+ +------+ 202 (a)client--server case 204 +------+ +------+ +------+ 205 |client| IPv6 network |TRA | IPv4 network |server| 206 |+CRA |----------------| |--------------| | 207 +------+ +------+ +------+ 208 (b)client--relay--server case 210 Figure 2 Protocol Summary 212 5. Client Relay Agent IPv6 Address Sub-option 214 This suboption MUST be added by DHCPv4 relay agents which are TRAs. 215 It encodes the IPv6 address of the host from which a DHCPv4-in-IPv6 216 CRA-to-TRA packet was received. It is intended for use by TRAs in 217 relaying DHCPv4 responses back to the proper CRA. To be more 218 specific, TRAs use the IPv6 address encoded in this suboption as the 219 destination IPv6 address when relaying DHCPv4 responses to IPv6 220 network. 222 The CRA IPv6 address MUST be unique in the IPv6 domain. 224 The 6ADDR suboption has a fixed length of 18 octets. The SubOpt code 225 is tbd by IANA, the length field should be 16, and the following 16 226 octets contain the CRA IPv6 address. 228 DHCP servers MAY use this suboption to select parameters specific to 229 particular hosts. Servers MAY parse this suboption and extract the 230 IPv6 address semantic. 232 SubOpt Len Agent Remote ID 233 +------+------+------+------+------+- -+------+ 234 | tbd | 16 | a1 | a2 | a3 | ... | a16 | 235 +------+------+------+------+------+- -+------+ 237 Figure 3 Client Relay Agent IPv6 Address Sub-option format 239 6. Client Relay Agent Behavior 241 A Client Relay Agent sits on the same machine with the DHCPv4 client. 242 CRA is a special type of relay agent, which relays DHCPv4 messages 243 between regular client and TSV/TRA. The communication between CRA 244 and the client happens within the machine using IPv4, and the 245 communication between CRA and TSV/TRA happens on the IPv6 network 246 using IPv6. 248 A CRA is configured with one or more IPv6 addresses of TSV/TRA. This 249 configuration is provided before DHCPv4 process, for example through 250 DHCPv6 option, or by some other mechanisms, depending on the 251 application scenarios. 253 A CRA listens for DHCP packets on IPv4 UDP port 67. When it receives 254 from IPv4 any DHCP packet with bootp op field = 1, it forwards the 255 packet using the standard DHCP relay agent format, but over UDPv6, 256 with source port 67 and destination port 67. Here the CRA MUST NOT 257 include an option 82, and MUST NOT modify the giaddr field of the 258 DHCP packet. The CRA forwards the packet to each of the DHCP server 259 or relay agent IP addresses with which it is configured. The CRA 260 MUST use a global IPv6 address if it has one. 262 A CRA also listens for DHCP packets on IPv6 UDP port 68. When it 263 receives from IPv6 any DHCP packet with bootp op field = 2, the CRA 264 checks to see if the packet contains option 82, and if so, it drops 265 the packet. Otherwise, it delivers the packet to the DHCP client 266 using IPv4. 268 7. IPv6-Transport Server Behavior 270 To support IPv6 transport, the behavior of DHCPv4 server should be 271 extended. The IPv6-Transport Server can listen on IPv6 port 67 for 272 DHCPv4 packets, and send DHCPv4 packets through IPv6. 274 When a TSV listening on IPv6 UDP port 67, receives a DHCP packet, it 275 MUST record the IPv6 source address of that packet and retain it as 276 the return address of the packet. That is to say, when sometime 277 later the TSV responds to this packet which is received in IPv6, it 278 MUST send the response packet to the IPv6 return address recorded 279 earlier. The rest of TSV DHCP process is the same with normal DHCPv4 280 server. A TSV can also listen on IPv4 UDP port 67, just like a 281 normal DHCPv4 server, and process normally when receives IPv4 DHCPv4 282 packet. 284 This document places no new requirements on DHCPv4 servers that do 285 not listen on UDPv6--in order to use an IPv4-only DHCPv4 server 286 through an IPv6 connection, a TRA is required. 288 8. IPv6-Transport Relay Agent Behavior 290 An IPv6-Transport Relay Agent sits between IPv6 network and IPv4 291 network, and relays DHCPv4 message between CRAs and IPv4-only DHCPv4 292 server. The communication between CRAs and the TRA uses IPv6, and 293 the communication between TRA and server uses IPv4. A TRA listens on 294 IPv6 UDP port 67 for DHCP packets with bootp op field = 1, and also 295 on IPv4 UDP port 68 for DHCP packets with bootp op field = 2. 297 When relaying a DHCP message from CRA to server, TRA MUST add an 298 option 82 with a 6ADDR suboption. This suboption contains the IPv6 299 source address of the message when it is received in IPv6, i.e., the 300 CRA's IPv6 address. The TRA MUST also store IPv4 address of itself 301 in the giaddr field of the DHCP message. The TRA MAY include a Link 302 Selection Suboption[RFC2131] to indicate to the DHCP server which 303 link to use when choosing an IP address. 305 When a TRA receives a DHCP message from the DHCP server. If the 306 packet contains no 6ADDR suboption, the TRA discards the packet. 307 Otherwise, it processes it as required by [RFC3046], and forwards it 308 to the IPv6 address recorded in the 6ADDR suboption. 310 9. Security Consideration 312 This specification raises no particular security issues to the DHCPv4 313 protocol model. 315 10. IANA consideration 317 IANA is requested to assign one new suboption code from the registry 318 of DHCP Agent Sub-Option Codes maintained in 319 http://www.iana.org/assignments/bootp-dhcp-parameters. This 320 suboption code will be assigned to the Client Relay Agent IPv6 321 Address Sub-option. 323 11. References 325 11.1. Normative References 327 [RFC2119] Bradner, S., "Key words for use in 328 RFCs to Indicate Requirement Levels", 329 BCP 14, RFC 2119, March 1997. 331 [RFC2131] Droms, R., "Dynamic Host 332 Configuration Protocol", RFC 2131, 333 March 1997. 335 [RFC3046] Patrick, M., "DHCP Relay Agent 336 Information Option", RFC 3046, 337 January 2001. 339 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., 340 and J. Kumarasamy, "Link Selection 341 sub-option for the Relay Agent 342 Information Option for DHCPv4", 343 RFC 3527, April 2003. 345 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. 346 Durand, "Softwire Problem Statement", 347 RFC 4925, July 2007. 349 11.2. Informative References 351 [I-D.cui-softwire-host-4over6] Cui, Y., Wu, J., Wu, P., Metz, C., 352 Vautrin, O., and Y. Lee, "Public IPv4 353 over Access IPv6 Network", 354 (work in progress), July 2011. 356 Authors' Addresses 358 Yong Cui 359 Tsinghua University 360 Department of Computer Science, Tsinghua University 361 Beijing 100084 362 P.R.China 364 Phone: +86-10-6260-3059 365 EMail: cuiyong@tsinghua.edu.cn 367 Peng Wu 368 Tsinghua University 369 Department of Computer Science, Tsinghua University 370 Beijing 100084 371 P.R.China 373 Phone: +86-10-6278-5822 374 EMail: peng-wu@foxmail.com 376 Jianping Wu 377 Tsinghua University 378 Department of Computer Science, Tsinghua University 379 Beijing 100084 380 P.R.China 382 Phone: +86-10-6278-5983 383 EMail: jianping@cernet.edu.cn 385 Ted Lemon 386 Nominum, Inc. 387 2000 Seaport Blvd 388 Redwood City 94063 389 USA 391 Phone: +1-650-381-6000 392 EMail: mellon@nominum.com