idnits 2.17.1 draft-ietf-dhc-dhcpv4-over-ipv6-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 : ---------------------------------------------------------------------------- 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 (March 29, 2012) is 4408 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) ** Downref: Normative reference to an Informational RFC: RFC 4925 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: September 30, 2012 Tsinghua University 6 T. Lemon 7 Nominum, Inc. 8 March 29, 2012 10 DHCPv4 over IPv6 Transport 11 draft-ietf-dhc-dhcpv4-over-ipv6-02 13 Abstract 15 In IPv6 networks, there remains a need to provide IPv4 service for 16 some residual devices. This document describes a mechanism for 17 allocating IPv4 addresses to such devices using DHCPv4 with an IPv6 18 transport. It is done by extending DHCP client and server behavior, 19 and by adding a new Relay Agent Information option to carry the IPv6 20 address of the client. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 30, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . . 6 61 6. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . . 6 62 7. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 7 63 8. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . . 8 64 9. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 65 10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8 66 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 69 12.2. Informative References . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 DHCPv4 [RFC2131] was not designed with IPv6 in mind: DHCPv4 cannot 74 operate on an IPv6 network. However, as dual-stack networks become a 75 reality, the need arises to allocate IPv4 addresses in an IPv6 76 environment. To meet this demand, this document extends DHCPv4 to 77 allow the use of an IPv6 network for transport. 79 A typical scenario that probably requires this feature is IPv4-over- 80 IPv6 hub and spoke tunnel [RFC4925]. In this scenario, IPv4-over- 81 IPv6 tunnel is used to provide IPv4 connectivity to end users (hosts 82 or end networks) across an IPv6 network. If the IPv4 addresses of 83 the end users are provisioned by the concentrator side, then the 84 provisioning process should be able to cross the IPv6 network, too. 85 One such tunnel mechanism is demonstrated in 86 [I-D.ietf-softwire-public-4over6]. DHCPv4 over IPv6 would be a 87 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 messages 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 on 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. Instead of 110 relying on IPv4-in-IPv6 tunnel, this flavour uses IPv6 directly 111 for DHCP message transport, 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. 117 2. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 3. Terminology 124 This document makes use of the following terms: 126 o DHCPv4: IPv4 Dynamic Host Configuration Protocol [RFC2131]. 128 o Client Relay Agent(CRA): a special DHCPv4 Relay Agent that sits on 129 the same, IPv6-accessable host with the DHCPv4 client. CRA works 130 as a "bridge" between DHCPv4 client and the IPv6 network, to 131 convert between IPv4 transport and IPv6 transport. 133 o On-link Client Relay Agent(LCRA): a CRA sits on the link of the 134 host rather then inside the host. 136 o IPv6-Transport Server(TSV): a DHCPv4 Server that supports IPv6 137 transport. TSV can listen on IPv6 for incoming DHCPv4 messages, 138 and send DHCPv4 messages in IPv6 packets. 140 o IPv6-Transport Relay Agent(TRA): a DHCPv4 Relay Agent that 141 supports IPv6 transport. TRA sits on a machine which has both 142 IPv6 and IPv4 connectivity, and relays DHCP messages between CRA 143 and normal DHCPv4 server. 145 o Client Relay Agent IPv6 Address Sub-option(CRA6ADDR suboption): a 146 new suboption of DHCP Relay Agent Information Option [RFC3046] 147 defined in this document. CRA6ADDR suboption is used by TRA to 148 carry the IPv6 address of a CRA. 150 4. Protocol Summary 152 The scenario for DHCPv4 over IPv6 transport is shown in Figure 1. 153 DHCPv4 clients and DHCPv4 server/relay are separated by an IPv6 154 network in the middle. DHCP messages between a client and the 155 server/relay cannot naturally be forwarded to each other because they 156 are by default IPv4 UDP packets, either unicast or broadcast. To 157 bridge this gap, both the client side and the server/relay side 158 should enable DHCPv4 over IPv6 transport. More precisely, they 159 should support delivering and receiving DHCP messages in IPv6 UDP 160 packets and thereby traverse the IPv6 network. 162 On the client side, a special relay agent called Client Relay Agent 163 is placed on the same host with the client, or on the link of the 164 client. CRA is used to relay DHCP messages from the client to the 165 server, and from the server to the client. CRA sends DHCPv4 messages 166 to the server through unicast IPv6 UDP, and receives unicast IPv6 UDP 167 packets with the DHCPv4 messages from the server. By using CRA, no 168 extension is required on the DHCP client. 170 +-------------------------+ 171 +------+ | 172 |DHCPv4| | 173 |Client| +-------+ 174 +------+ |DHCPv4 | 175 | IPv6 Network |Server/| 176 +------+ |Relay | 177 |DHCPv4| +-------+ 178 |Client| | 179 +------+ | 180 +-------------------------+ 182 Figure 1 Scenario of DHCPv4 over IPv6 Transport 184 The IPv6-Transport DHCPv4 server can receive DHCP messages delivered 185 in IPv6 UDP from CRA, and send out DHCP messages to CRA using IPv6 186 UDP(figure 2(a)). TSV should send DHCP messages to the IPv6 address 187 from which it receives relevant DHCP messages earlier. 189 When CRAs communicate with an IPv6-Transport Relay Agent rather than 190 with a server directly, the situation will become a little more 191 complicated. Besides the IPv6 communication with CRA, TRA also 192 communicates with a regular DHCPv4 server through IPv4. Therefore, 193 when TRA relays DHCP messages between a CRA and the DHCPv4 server, it 194 receives DHCP message from the CRA in IPv6 and sends it to the server 195 in IPv4, while receives DHCP message from the server in IPv4 and 196 sends it to the CRA in IPv6. TRA has to use the DHCP Relay Agent 197 Information Option(Option 82) to record the IPv6 address of a CRA, 198 which will be used as forwarding destination when relaying a DHCP 199 message from the server. Since Option 82 doesn't have an existing 200 suboption that fits in the case, this document defines a new Client 201 Relay Agent IPv6 Address Sub-option. 203 +------+ +------+ 204 |client| IPv6 network |TSV | 205 |+CRA |----------------| | 206 +------+ +------+ 207 (a)client--server case 209 +------+ +------+ +------+ 210 |client| IPv6 network |TRA | IPv4 network |server| 211 |+CRA |----------------| |--------------| | 212 +------+ +------+ +------+ 213 (b)client--relay--server case 215 Figure 2 Protocol Summary 217 5. Client Relay Agent IPv6 Address Sub-option 219 This suboption MUST be added by a DHCPv4 TRA. It encodes the IPv6 220 address of the host from which a DHCPv4-in-IPv6 CRA-to-TRA message 221 was received. It is intended for the TRA to relay DHCPv4 replies 222 back to the proper CRA. To be more specific, the TRA uses the IPv6 223 address encoded in this suboption as the destination IPv6 address 224 when relaying a DHCPv4 reply to IPv6 network. 226 The CRA IPv6 address MUST be unique in the IPv6 domain. 228 The CRA6ADDR suboption has a fixed length of 18 octets. The SubOpt 229 code is tbd by IANA, the length field should be 16, and the following 230 16 octets contain the CRA IPv6 address. 232 DHCP servers handles it following the standard option 82 procedure 233 defined in [RFC3046]. DHCP servers MAY use this suboption to select 234 parameters specific to particular hosts. Servers MAY parse this 235 suboption and extract the semantic of IPv6 address. 237 SubOpt Len Agent Remote ID 238 +------+------+------+------+------+- -+------+ 239 | tbd | 16 | a1 | a2 | a3 | ... | a16 | 240 +------+------+------+------+------+- -+------+ 242 Figure 3 Client Relay Agent IPv6 Address Sub-option format 244 6. Client Relay Agent Behavior 246 A Client Relay Agent sits on the same host with the DHCPv4 client. 247 CRA is a special type of relay agent, which relays DHCPv4 messages 248 between regular client and TSV/TRA. The communication between CRA 249 and the client happens within the machine using IPv4, and the 250 communication between CRA and TSV/TRA happens on the IPv6 network 251 using IPv6. 253 A CRA is configured with one or more IPv6 addresses of TSV/TRA. This 254 configuration is provided before DHCPv4 process, for example through 255 DHCPv6 option, or by some other mechanisms depending on the 256 application scenarios. 258 A CRA listens for DHCP messages on IPv4 UDP port 67. When it 259 receives from IPv4 any DHCP message with bootp op field = 1, it 260 forwards the message using the standard DHCP relay agent format, but 261 over UDPv6, with source port 67 and destination port 67. Here the 262 CRA MUST NOT include an option 82 or modify the giaddr field of the 263 DHCP message. The CRA forwards the message to each of the DHCP 264 server or relay agent with which it is configured. The CRA MUST use 265 a global IPv6 address if it has onbe. 267 A CRA also listens for DHCP messages on IPv6 UDP port 68. When it 268 receives from IPv6 any DHCP message with bootp op field = 2, the CRA 269 checks to see if the message contains option 82, and if so, it 270 discards the message. Otherwise, it delivers the message to the DHCP 271 client using IPv4. 273 A CRA can also sits on the link of the host (LCRA). The basic 274 functionility of LCRA is the same with CRA. LCRA SHOULD NOT include 275 a option 82 or modify the giaddr of DHCP message. If it has to, 276 [I-D.ietf-dhc-dhcpv4-relay-encapsulation] can be used as the solution 277 to the coexistence of LCRA and TRA. LCRA does not necessarily need 278 an IPv4 address, though it may be configured with one. 280 A CRA MUST only serve the client inside the same host, while the LCRA 281 MUST serve any client on the link. When the IPv6 address of TSV/TRA 282 is provisioned, the DHCP client uses CRA; else the client uses LCRA. 284 7. IPv6-Transport Server Behavior 286 To support IPv6 transport, the behavior of DHCPv4 server should be 287 extended. The IPv6-Transport Server can listen on IPv6 port 67 for 288 DHCPv4 messages, and send DHCPv4 messages through IPv6. 290 A TSV listens for DHCP messages on IPv6 UDP port 67. When it 291 receives from IPv6 a DHCP message, it MUST record the IPv6 source 292 address of that message and retain it as the return address of the 293 message. That is to say, when sometime later the TSV responds to 294 this message, it MUST send the reply message to the IPv6 return 295 address retained earlier, with destination port 68. When filling in 296 the server id option of DHCP replies, the TSV MUST choose an IPv4 297 address which is reachable from the client once the residual IPv4 298 serivice is set up. This follows the server id option requirement in 299 [RFC2131]. The rest of TSV DHCP process is the same with normal 300 DHCPv4 server. A TSV can also listen on IPv4 UDP port 67 like a 301 normal DHCPv4 server, and process normally when receives IPv4 DHCPv4 302 message. 304 This document places no new requirements on DHCPv4 servers that do 305 not listen on UDPv6--in order to use an IPv4-only DHCPv4 server 306 through an IPv6 connection, a TRA is required. 308 8. IPv6-Transport Relay Agent Behavior 310 An IPv6-Transport Relay Agent sits between IPv6 network and IPv4 311 network, and relays DHCPv4 message between CRAs and IPv4-only DHCPv4 312 server. The communication between CRAs and the TRA uses IPv6, while 313 the communication between TRA and server uses IPv4. A TRA listens on 314 IPv6 UDP port 67 for DHCP messages with bootp op field = 1, as well 315 as IPv4 UDP port 68 for DHCP messages with bootp op field = 2. 317 When relaying a DHCP message from CRA to server, TRA MUST add an 318 option 82 with a CRA6ADDR suboption. This suboption contains the 319 IPv6 source address of the message (the CRA's IPv6 address) which is 320 retained when the message is received in IPv6. The TRA MUST also 321 store the IPv4 address of itself in the giaddr field of the DHCP 322 message. The TRA MAY include a Link Selection Suboption [RFC3527] to 323 indicate to the DHCP server which link to use when choosing an IP 324 address. 326 When receiving a DHCP message from the DHCP server, if the option 82 327 in the message contains no CRA6ADDR suboption, the TRA MUST discard 328 the message. Otherwise, it processes it as required by [RFC3046], 329 and forwards it to the IPv6 address recorded in the CRA6ADDR 330 suboption, with source port 67 and destination port number 68. TRA 331 SHOULD drop DHCPv4-over-IPv6 traffic that is not originated from 332 configured server address. 334 9. Security Consideration 336 This mechanism may rise a new form of DHCP protocol attack. A 337 malicious attacker in IPv6 can interference with the DHCPv4 process 338 by inject fake DHCPv4-in-IPv6 messages which will be handled by TSV 339 or TRA. However, the damage is the same with the known DHCPv4 attack 340 happened in IPv4. The only difference is the attacker and the victim 341 could locate in different address families. 343 Another impact is DHCP filtering. There are firewalls today capable 344 of filtering DHCP traffic (DHCPv4 over IPv4 and DHCPv6 over IPv6 345 packages). The DHCP messages with the new, DHCPv4-in-IPv6 style may 346 bypass these firewalls. Nevertheless it is not difficult for them to 347 make some slight modification and adapt to the new DHCPv4 message 348 pattern. 350 10. IANA consideration 351 IANA is requested to assign one new suboption code from the registry 352 of DHCP Agent Sub-Option Codes maintained in 353 http://www.iana.org/assignments/bootp-dhcp-parameters. This 354 suboption code will be assigned to the Client Relay Agent IPv6 355 Address Sub-option. 357 11. Contributors 359 Francis Dupont and Tomek Mrugalski. 361 12. References 363 12.1. Normative References 365 [RFC2119] Bradner, S., "Key words 366 for use in RFCs to 367 Indicate Requirement 368 Levels", BCP 14, RFC 2119, 369 March 1997. 371 [RFC2131] Droms, R., "Dynamic Host 372 Configuration Protocol", 373 RFC 2131, March 1997. 375 [RFC3046] Patrick, M., "DHCP Relay 376 Agent Information Option", 377 RFC 3046, January 2001. 379 [RFC3527] Kinnear, K., Stapp, M., 380 Johnson, R., and J. 381 Kumarasamy, "Link 382 Selection sub-option for 383 the Relay Agent 384 Information Option for 385 DHCPv4", RFC 3527, 386 April 2003. 388 [RFC4925] Li, X., Dawkins, S., Ward, 389 D., and A. Durand, 390 "Softwire Problem 391 Statement", RFC 4925, 392 July 2007. 394 12.2. Informative References 396 [I-D.ietf-dhc-dhcpv4-relay-encapsulation] Lemon, T., Deng, H., and 397 L. Huang, "Relay Agent 398 Encapsulation for DHCPv4", 399 relay-encapsulation-01 400 (work in progress), 401 July 2011. 403 [I-D.ietf-softwire-public-4over6] Cui, Y., Wu, J., Wu, P., 404 Metz, C., Vautrin, O., and 405 Y. Lee, "Public IPv4 over 406 IPv6 Access Network", draf 407 t-ietf-softwire-public- 408 4over6-01 (work in 409 progress), March 2012. 411 Authors' Addresses 413 Yong Cui 414 Tsinghua University 415 Department of Computer Science, Tsinghua University 416 Beijing 100084 417 P.R.China 419 Phone: +86-10-6260-3059 420 EMail: cuiyong@tsinghua.edu.cn 422 Peng Wu 423 Tsinghua University 424 Department of Computer Science, Tsinghua University 425 Beijing 100084 426 P.R.China 428 Phone: +86-10-6278-5822 429 EMail: pengwu.thu@gmail.com 431 Jianping Wu 432 Tsinghua University 433 Department of Computer Science, Tsinghua University 434 Beijing 100084 435 P.R.China 437 Phone: +86-10-6278-5983 438 EMail: jianping@cernet.edu.cn 440 Ted Lemon 441 Nominum, Inc. 442 2000 Seaport Blvd 443 Redwood City 94063 444 USA 446 Phone: +1-650-381-6000 447 EMail: mellon@nominum.com