draft-ietf-dhc-dhcpv4-over-ipv6-03.txt   draft-ietf-dhc-dhcpv4-over-ipv6-04.txt 
Network Working Group Y. Cui Network Working Group Y. Cui
Internet-Draft P. Wu Internet-Draft P. Wu
Intended status: Standards Track J. Wu Intended status: Standards Track J. Wu
Expires: November 19, 2012 Tsinghua University Expires: March 17, 2013 Tsinghua University
T. Lemon T. Lemon
Nominum, Inc. Nominum, Inc.
May 18, 2012 September 13, 2012
DHCPv4 over IPv6 Transport DHCPv4 over IPv6 Transport
draft-ietf-dhc-dhcpv4-over-ipv6-03 draft-ietf-dhc-dhcpv4-over-ipv6-04
Abstract Abstract
In IPv6 networks, there remains a need to provide IPv4 service for In IPv6 networks, there remains a need to provide IPv4 service for
some residual devices. This document describes a mechanism for some residual devices. This document describes a mechanism for
allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6 allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6
transport. It is done by putting a special relay agent function transport. It is done by putting a special relay agent function
(Client Relay Agent) on the client side, as well as extending the (Client Relay Agent) on the client side, as well as extending the
behavior of the server; in the case where DHCP server only supports behavior of the server; in the case where DHCP server only supports
IPv4 transport, a relay agent is extended to support IPv6 transport IPv4 transport, a relay agent is extended to support IPv6 transport
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 19, 2012. This Internet-Draft will expire on March 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 4
5. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . . 6 5. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . . 6
6. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . 7 6. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . 6
7. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 8 7. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 7
8. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . 8 8. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . 8
9. Security Consideration . . . . . . . . . . . . . . . . . . . . 9 9. Security Consideration . . . . . . . . . . . . . . . . . . . . 8
10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9 10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9
12. Appendix: Discussion on One Host Retrieving Multiple 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Addresses through One CRA . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 10
13.1. Normative References . . . . . . . . . . . . . . . . . . 11 Appendix 1. Motivation for selecting this particular solution . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . 11 1.1. Configuring IPv4 with DHCPv6 . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2. Tunnel DHCPv4 over IPv6 . . . . . . . . . . . . . . . . . 11
1.3. DHCPv4 relayed over IPv6 . . . . . . . . . . . . . . . . 12
Appendix 2. Discussion on One Host Retrieving Multiple
Addresses through One CRA . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
DHCPv4 [RFC2131] was not designed with IPv6 in mind: DHCPv4 cannot DHCPv4 [RFC2131] was not designed with IPv6 in mind: DHCPv4 cannot
operate on an IPv6 network. However, as dual-stack networks become a operate on an IPv6 network. However, as dual-stack networks become a
reality, the need arises to allocate IPv4 addresses in an IPv6 reality, the need arises to allocate IPv4 addresses in an IPv6
environment. To meet this demand, this document extends the DHCPv4 environment. To meet this demand, this document extends the DHCPv4
protocol to allow the use of an IPv6 network for transport. protocol to allow the use of an IPv6 network for transport.
A typical scenario that probably requires this feature is IPv4-over- A typical scenario that probably requires this feature is IPv4-over-
IPv6 hub and spoke tunnel [RFC4925]. In this scenario, IPv4-over- IPv6 hub and spoke tunnel [RFC4925]. In this scenario, IPv4-over-
IPv6 tunnel is used to provide IPv4 connectivity to end users (hosts IPv6 tunnel is used to provide IPv4 connectivity to end users (hosts
or end networks) across an IPv6 network. If the IPv4 addresses of or end networks) across an IPv6 network. If the IPv4 addresses of
the end users are provisioned by the concentrator side, then the the end users are provisioned by the concentrator side, then the
provisioning process should be able to cross the IPv6 network. One provisioning process should be able to cross the IPv6 network. One
such tunnel mechanism is demonstrated in such tunnel mechanism is demonstrated in
[I-D.ietf-softwire-public-4over6]. DHCPv4 over IPv6 would be a [I-D.ietf-softwire-public-4over6]. DHCPv4 over IPv6 would be a
generic solution for this scenario. generic solution for this scenario.
Three main flavors of solutions may be considered:
o Use DHCPv6 instead of DHCPv4, to provision IPv4-related
connectivity. In DHCPv6, the provisioned IPv4 address can be
embedded into IPv6 address, or carried within a new option. Along
with that, dedicated options are needed to convey IPv4-related
information, such as the IPv4 address of DNS server, NTP server,
etc. Therefore it will put a certain amount of IPv6-unrelated
information into DHCPv6 protocol.
o Use DHCPv4 and tunnel DHCPv4-in-IPv4 messages over IPv6. Unlike
the previous approach where DHCPv6 is used for both IPv4 and IPv6
connectivity, this approach consists in preserving the separation
between IPv4 and IPv6 connectivity information. It allows to
maintain the IPv4 service without major modification of IPv6-
related provisioning resources, and sustains DHCPv4 to be the
IPv4-related information carrier. However, this approach enforces
an IPv4-in-IPv6 tunnel on DHCP, and subsequently requires extra
efforts to maintain tunnel endpoint information for encapsulation
use.
o Use DHCPv4 and extend it to work on IPv6 transport. Instead of
relying on IPv4-in-IPv6 tunnel, this flavor uses IPv6 directly for
DHCP message transport, and it keeps the advantage of separation
with IPv6 connectivity information. This document focuses on this
flavor. The document defines the behavior of extended DHCPv4
components, as well as a new sub-option of the Relay Agent
Information Option, to support DHCPv4 over IPv6.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
This document makes use of the following terms: This document makes use of the following terms:
o DHCPv4: IPv4 Dynamic Host Configuration Protocol [RFC2131]. o DHCPv4: IPv4 Dynamic Host Configuration Protocol [RFC2131].
o Client Relay Agent(CRA): a special DHCPv4 Relay Agent which works o Client Relay Agent(CRA): a special DHCPv4 Relay Agent which relays
as a "proxy" between DHCPv4 client and the IPv6 network by between DHCPv4 client and DHCPv4 server using an IPv6 network. A
converting between IPv4 transport and IPv6 transport. A CRA CRA either sits on the same, IPv6-accessable host with the DHCPv4
either sits on the same, IPv6-accessable host with the DHCPv4
client, or sits on the same link with the host. client, or sits on the same link with the host.
o Host Client Relay Agent(HCRA): a CRA which sits on the same, IPv6- o Host Client Relay Agent(HCRA): a CRA which sits on the same, IPv6-
accessible host with the DHCPv4 client. accessible host with the DHCPv4 client.
o On-Link Client Relay Agent(LCRA): a CRA which sits on the same o On-Link Client Relay Agent(LCRA): a CRA which sits on the same
link with the host that runs DHCPv4 client. link with the host that runs DHCPv4 client.
o IPv6-Transport Server(TSV): a DHCPv4 Server that supports IPv6 o IPv6-Transport Server(TSV): a DHCPv4 Server that supports IPv6
transport. TSV listens on IPv6 for incoming DHCPv4 messages, and transport. TSV listens on IPv6 for incoming DHCPv4 messages, and
sends DHCPv4 messages in IPv6 packets. sends DHCPv4 messages in IPv6 packets.
o IPv6-Transport Relay Agent(TRA): a DHCPv4 Relay Agent that o IPv6-Transport Relay Agent(TRA): a DHCPv4 Relay Agent that
supports IPv6 transport. TRA sits on a machine which has both supports IPv6 transport. TRA sits on a machine which has both
IPv6 and IPv4 connectivity, and relays DHCP messages between CRA IPv6 and IPv4 connectivity, and relays DHCP messages between CRA
and regular DHCPv4 server. Unlike CRA, TRA sits on the remote end and regular DHCPv4 server. Unlike CRA, TRA sits on the remote end
of IPv6 network, and communicates with DHCPv4 server through IPv4. of IPv6 network, and communicates with DHCPv4 server through IPv4.
o Client Relay Agent IPv6 Address Sub-option(CRA6ADDR sub-option): a o Client Relay Agent IPv6 Address Sub-option (CRA6ADDR sub-option):
new sub-option of DHCP Relay Agent Information Option [RFC3046] a new sub-option of the DHCP Relay Agent Information Option
defined in this document. CRA6ADDR sub-option is used by TRA to [RFC3046], defined in this document, which is used to carry the
carry the IPv6 address of a CRA. IPv6 address of the CRA.
4. Protocol Summary 4. Protocol Summary
The scenario for DHCPv4 over IPv6 transport is shown in Figure 1. The scenario for DHCPv4 over IPv6 transport is shown in Figure 1.
DHCPv4 clients and DHCPv4 server/relay are separated by an IPv6 DHCPv4 clients and DHCPv4 server/relay are separated by an IPv6
network in the middle. DHCP messages between a client and the network in the middle. DHCP messages between a client and the
server/relay cannot naturally be forwarded to each other because they server/relay cannot naturally be forwarded to each other because they
are by default IPv4 UDP packets, either unicast or broadcast. To are IPv4 UDP packets, either unicast or broadcast. To bridge this
bridge this gap, both the client side and the server/relay side gap, both the client side and the server/relay side must enable
should enable DHCPv4 over IPv6 transport. More precisely, they DHCPv4 over IPv6 transport. More precisely, they must support
should support delivering and receiving DHCP messages in IPv6 UDP delivering and receiving DHCP messages in IPv6 UDP packets and
packets and thereby traverse the IPv6 network. thereby traverse the IPv6 network.
On the client side, a special relay agent called Client Relay Agent On the client side, a special relay agent called Client Relay Agent
is placed on the same host with the client, or on the link of the is placed on the same host with the client, or on the link of the
host. CRA is used to relay DHCP messages from the client to the host. CRA is used to relay DHCP messages from the client to the
server, and from the server to the client. CRA sends DHCPv4 messages server, and from the server to the client. CRA sends DHCPv4 messages
to the server through unicast IPv6 UDP, and receives unicast IPv6 UDP to the server through unicast IPv6 UDP, and receives unicast IPv6 UDP
packets with the DHCPv4 messages from the server. By using CRA, no packets with the DHCPv4 messages from the server. By using CRA, no
extension is required on the DHCP client. extension is required on the DHCP client.
+-------------------------+ +-------------------------+
skipping to change at page 5, line 30 skipping to change at page 5, line 4
|Client| +-------+ |Client| +-------+
+------+ |DHCPv4 | +------+ |DHCPv4 |
| IPv6 Network |Server/| | IPv6 Network |Server/|
+------+ |Relay | +------+ |Relay |
|DHCPv4| +-------+ |DHCPv4| +-------+
|Client| | |Client| |
+------+ | +------+ |
+-------------------------+ +-------------------------+
Figure 1 Scenario of DHCPv4 over IPv6 Transport Figure 1 Scenario of DHCPv4 over IPv6 Transport
The IPv6-Transport DHCPv4 server can receive DHCP messages delivered The IPv6-Transport DHCPv4 server can receive DHCP messages delivered
in IPv6 UDP from CRA, and send out DHCP messages to CRA using IPv6 in IPv6 UDP from CRA, and send out DHCP messages to CRA using IPv6
UDP (figure 2(a)). TSV should send DHCP messages to the IPv6 address UDP (figure 2(a)). TSV should send DHCP messages to the IPv6 address
from which it receives relevant DHCP messages earlier. from which it receives relevant DHCP messages earlier.
When CRAs communicate with an IPv6-Transport Relay Agent rather than When CRAs communicate with an IPv6-Transport Relay Agent rather than
with a server directly, the situation will become a little more with a server directly, the situation becomes a little more
complicated. Besides the IPv6 communication with CRA, TRA also complicated. Besides the IPv6 communication with CRA, TRA also
communicates with a regular DHCPv4 server through IPv4. Therefore, communicates with a regular DHCPv4 server through IPv4. Therefore,
when TRA relays DHCP messages between a CRA and the DHCPv4 server, it when TRA relays DHCP messages between a CRA and the DHCPv4 server, it
receives DHCP message from the CRA in IPv6 and sends it to the server receives DHCP message from the CRA in IPv6 and sends it to the server
in IPv4, as well as receives DHCP message from the server in IPv4 and in IPv4, as well as receives DHCP message from the server in IPv4 and
sends it to the CRA in IPv6. TRA has to use the DHCP Relay Agent sends it to the CRA in IPv6.
Information Option (Option code 82) to record the IPv6 address of the
CRA, which will be used as forwarding destination when relaying a TRA sends the IPv6 address of the CRA to the DHCP server using the
DHCP message from the server. Since Option 82 doesn't have an Client Relay Agent IPv6 Address suboption, defined in this document.
existing sub-option that fits in the case, this document defines a The DHCP server returns this suboption to the TRA as required in
new Client Relay Agent IPv6 Address Sub-option. The DHCPv4 server [RFC3046]. The TRA then uses the returned CRA6ADDR suboption to
MUST support the new sub-option in this case. determine the destination address to which to relay the response.
+------+ +------+ +------+ +------+
|client| IPv6 network |TSV | |client| IPv6 network |TSV |
|+HCRA |----------------| | |+HCRA |----------------| |
+------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
|client| |LCRA | IPv6 network |TSV | |client| |LCRA | IPv6 network |TSV |
| |--| |----------------| | | |--| |----------------| |
+------+ +------+ +------+ +------+ +------+ +------+
skipping to change at page 6, line 32 skipping to change at page 6, line 7
|client| |LCRA | IPv6 network |TRA | IPv4 network |server| |client| |LCRA | IPv6 network |TRA | IPv4 network |server|
| |--| |----------------| |--------------| | | |--| |----------------| |--------------| |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
(b)client--relay--server case (b)client--relay--server case
Figure 2 Protocol Summary Figure 2 Protocol Summary
5. Client Relay Agent IPv6 Address Sub-option 5. Client Relay Agent IPv6 Address Sub-option
This sub-option MUST be added by a DHCPv4 TRA. It encodes the IPv6 The CRA6ADDR suboption is a suboption of the Relay Agent Information
address of the machine from which a DHCPv4-in-IPv6 CRA-to-TRA message Option [RFC3046]. It encodes the IPv6 address of the machine from
was received. It is intended for the TRA to relay DHCPv4 replies which a DHCPv4-in-IPv6 CRA-to-TRA message was received. It is used
back to the proper CRA. To be more specific, the TRA uses the IPv6 by the TRA to relay DHCPv4 replies back to the proper CRA. The TRA
address encoded in this sub-option as the destination IPv6 address uses the IPv6 address encoded in this suboption as the destination
when relaying a DHCPv4 reply to IPv6 network. IPv6 address when relaying a DHCPv4 message from the DHCP server to
the CRA.
The CRA IPv6 address MUST be unique in the IPv6 domain.
The CRA6ADDR sub-option has a fixed length of 18 octets. The SubOpt The CRA6ADDR sub-option has a fixed length of 18 octets. The SubOpt
code is tbd by IANA, the length field is 16, and the following 16 code is tbd by IANA, the length field is 16, and the following 16
octets contain the CRA IPv6 address. octets contain the CRA IPv6 address.
DHCP servers handle it following the standard option 82 procedure
defined in [RFC3046]. DHCP servers MAY use this sub-option to select
parameters specific to particular hosts. Servers MAY parse this sub-
option and extract the IPv6 address.
SubOpt Len Agent Remote ID SubOpt Len Agent Remote ID
+------+------+------+------+------+- -+------+ +------+------+------+------+------+- -+------+
| tbd | 16 | a1 | a2 | a3 | ... | a16 | | tbd | 16 | a1 | a2 | a3 | ... | a16 |
+------+------+------+------+------+- -+------+ +------+------+------+------+------+- -+------+
Figure 3 Client Relay Agent IPv6 Address Sub-option format Figure 3 Client Relay Agent IPv6 Address Sub-option format
6. Client Relay Agent Behavior 6. Client Relay Agent Behavior
A Client Relay Agent sits on the same host with the DHCPv4 client A Client Relay Agent sits on the same host with the DHCPv4 client
(HCRA), or on the link of the host (LCRA). CRA is a special type of (HCRA), or on the same link as the host (LCRA). CRA listens for DHCP
relay agent, which relays DHCPv4 messages between regular client and packets on IPv4 on port 67, and also listens for DHCP packets on IPv6
TSV/TRA. The communication between CRA and the client happens inside on port 67.
the last-hop local network using IPv4, and the communication between
CRA and TSV/TRA happens on the IPv6 network using IPv6.
A CRA is configured with one or more IPv6 addresses of TSV/TRA. This A CRA is configured with one or more IPv6 addresses of TSV/TRA, using
configuration is provided before DHCPv4 process, for example through a DHCPv6 option or some other mechanism. The CRA cannot forward
DHCPv6 option, or by some other mechanisms depending on the DHCPv4 messages before it is configured with an IPv6 address itself,
application scenarios. so to function properly, the IPv6 address for the CRA SHOULD be
configured before the DHCPv4 client starts. The CRA SHOULD use a
global IPv6 address.
A CRA listens for DHCP messages on IPv4 UDP port 67. When it When the CRA receives any DHCP message on IPv4 with BOOTP op field
receives from IPv4 any DHCP message with bootp op field = 1, it set to 1, it forwards the message over UDP on IPv6 using a standard
forwards the message using the standard DHCP relay agent format, but DHCP message format, with source port 67 and destination port 67.
over UDPv6, with source port 67 and destination port 67. The CRA The CRA forwards the message to each TSV or TRA address with which it
forwards the message to each of the TSV or TRA with which it is is configured.
configured. The CRA SHOULD use a global IPv6 address if it has one.
A CRA also listens for DHCP messages on IPv6 UDP port 68. When it When the CRA receives any message on IPv6 with BOOTP op field set to
receives from IPv6 any DHCP message with bootp op field = 2, the CRA 2, the CRA checks to see if the message contains option 82. If it
checks to see if the message contains option 82, and if so, it does, the CRA silently discards the message. Otherwise, it relays
discards the message. Otherwise, it delivers the message to the DHCP the message to the DHCP client using IPv4.
client using IPv4.
The basic functionality of HCRA and LCRA are the same. The When the CRA receives any message on IPv6 with BOOTP op field set to
difference is that, when relaying DHCP messages, the HCRA MUST NOT 4, it decapsulates the message as specified in DHCPv4 Relay Agent
include an option 82 or modify the giaddr field of the DHCP message, Encapsulation [I-D.ietf-dhc-dhcpv4-relay-encapsulation]. If the CRA
while in the LCRA case, it SHOULD NOT include an option 82 or modify does not support encapsulation, it MUST silently discard the message.
the giaddr of DHCP message. If it has to,
[I-D.ietf-dhc-dhcpv4-relay-encapsulation] can be used as the solution
to the coexistence of LCRA and TRA.
A HCRA MUST only serve the client inside the same host, while the The LCRA or HCRA MUST NOT use the Relay Agent Information Option
[RFC3046]. If either type of CRA needs to send relay agent options,
it MUST use relay agent encapsulation as defined in
[I-D.ietf-dhc-dhcpv4-relay-encapsulation]. In that case, the TRA and
the DHCPv4 server for the TRA MUST support relay agent encapsulation;
TSV SHOULD support relay agent encapsulation as well.
An HCRA MUST only serve the client inside the same host, while the
LCRA SHOULD serve any client on the link. When the IPv6 address of LCRA SHOULD serve any client on the link. When the IPv6 address of
TSV/TRA is provisioned to the DHCP client, it uses HCRA; else the TSV/TRA is provisioned to the host running the DHCP client, it uses
client depends on LCRA. A HCRA serves only one link; the multiple HCRA; else the client depends on LCRA. A HCRA serves only one link;
link case MUST be handled by multiple HCRA instances. A LCRA does the multiple link case MUST be handled by multiple HCRA instances. A
not necessarily need an IPv4 address, though it may be configured LCRA does not necessarily need an IPv4 address, though it may be
with one. configured with one.
In HCRA case, the DHCPv6 client (or other IPv6 configuration
processes), DHCPv4 client and CRA runs on the same physical
interface. If possible, the host running the DHCPv4 client and CRA
SHOULD defer the operation of the DHCPv4 client until an IPv6 address
of the interface has been acquired, as well as the TSV/TRA address
information. If this is not done, the DHCPv4 client may send several
messages that the CRA cannot relay, and this could result in long
delays before the DHCPv4 client actually gets an IPv4 address.
7. IPv6-Transport Server Behavior 7. IPv6-Transport Server Behavior
To support IPv6 transport, the behavior of DHCPv4 server is extended. To support IPv6 transport, the behavior of DHCPv4 server is extended.
The IPv6-Transport Server can listen on IPv6 port 67 for DHCPv4 The IPv6-Transport Server can listen on IPv6 port 67 for DHCPv4
messages, and send DHCPv4 messages through IPv6. messages, and send DHCPv4 messages through IPv6.
A TSV listens for DHCP messages on IPv6 UDP port 67. When it A TSV listens for DHCP messages on IPv6 UDP port 67 and IPv4 UDP port
receives from IPv6 a DHCP message, it MUST record the IPv6 source 67. When it receives a DHCP message on IPv6, it MUST retain the IPv6
address of that message and retain it as the return address of the source address of that message until it has sent a response. When it
message. That is to say, when sometime later the TSV responds to sends a response, it MUST send the response to this IPv6 address,
this message, it MUST send the reply message to the IPv6 return with destination port 67.
address retained earlier, with destination port 68. When filling in
the server id option of DHCP replies, the TSV MUST choose an IPv4
address which is reachable from the client once the residual IPv4
service is set up. This follows the server id option requirement in
[RFC2131]. The rest of TSV DHCP process is the same with normal
DHCPv4 server. A TSV MAY also listen on IPv4 UDP port 67 like a
normal DHCPv4 server, and process normally when receives IPv4 DHCPv4
message.
This document places no new requirements on DHCPv4 servers that do The TSV MUST send a server identifier option [RFC2132] containing an
not listen on UDPv6 (other than to support the CRA6ADDR IPv4 address which will be reachable from the client once the
sub-option)--in order to use an IPv4-only DHCPv4 server through an residual IPv4 service is set up. This follows the server id option
IPv6 connection, a TRA is required. requirement in [RFC2131].
The rest of TSV DHCP process is the same with normal DHCPv4 server.
A TSV MUST also listen on IPv4 UDP port 67 like a normal DHCPv4
server, and process IPv4 DHCPv4 messages normally. This requirement
exists because when a DHCPv4 client renews, it sends its renewal
messages directly to the server, rather than broadcasting them.
Because the CRA may use relay agent encapsulation
[I-D.ietf-dhc-dhcpv4-relay-encapsulation], the TSV SHOULD support it.
A TSV that does not support it will not interoperate with a CRA that
sends relay agent options.
8. IPv6-Transport Relay Agent Behavior 8. IPv6-Transport Relay Agent Behavior
An IPv6-Transport Relay Agent sits between IPv6 network and IPv4 An IPv6-Transport Relay Agent sits between IPv6 network and IPv4
network, and relays DHCPv4 message between CRAs and IPv4-only DHCPv4 network, and relays DHCPv4 message between CRAs and IPv4-only DHCPv4
server. The communication between CRAs and the TRA uses IPv6, while server. The communication between CRAs and the TRA uses IPv6, while
the communication between the TRA and the server uses IPv4. A TRA the communication between the TRA and the server uses IPv4. A TRA
listens on IPv6 UDP port 67 for DHCP messages with bootp op field = listens on IPv6 UDP port 67 for DHCP messages with BOOTP op field set
1, as well as IPv4 UDP port 68 for DHCP messages with bootp op field to 1 or 3, as well as IPv4 UDP port 67 for DHCP messages with BOOTP
= 2. op field set to 2 or 4.
When relaying a DHCP message from CRA to server, TRA MUST add an When relaying a DHCP message from CRA to server, TRA MUST add a
option 82 with a CRA6ADDR sub-option. This sub-option contains the CRA6ADDR suboption. The TRA sets the contents of this suboption to
IPv6 source address of the message (the CRA's IPv6 address) which is the IPv6 source address of the message. The TRA MUST also store one
retained when the message is received in IPv6. The TRA MUST also its own IPv4 addresses in the giaddr field of the DHCP message. The
store the IPv4 address of itself in the giaddr field of the DHCP TRA MAY include a Link Selection sub-option [RFC3527] to indicate to
message. The TRA MAY include a Link Selection sub-option [RFC3527] the DHCP server which link to use when choosing an IP address. If
to indicate to the DHCP server which link to use when choosing an IP the received message is a RELAYFORWARD message, the TRA MUST
address. encapsulate the message in a new RELAYFORWARD message and store the
CRA6ADDR in the new relay segment. If it is some other message, the
TRA SHOULD append a Relay Agent Information Option as described in
[RFC3046], but MAY encapsulate it in the same way as RELAYFORWARD
message instead.
When receiving a DHCP message from the DHCP server, if the option 82 When receiving a DHCP message from the DHCP server, if the message
in the message contains no CRA6ADDR sub-option, the TRA MUST discard contains no CRA6ADDR suboption, the TRA MUST discard the message.
the message. Otherwise, it processes it as required by [RFC3046], Otherwise, it processes it as required by [RFC3046] and
and forwards it to the IPv6 address recorded in the CRA6ADDR sub- [I-D.ietf-dhc-dhcpv4-relay-encapsulation], and forwards it to the
option, with source port 67 and destination port number 68. TRA IPv6 address recorded in the CRA6ADDR sub-option, with source port 67
SHOULD drop DHCPv4-over-IPv6 traffic that is not originated from and destination port number 67.
configured server address.
9. Security Consideration 9. Security Consideration
This mechanism may rise a new form of DHCP protocol attack. A This mechanism may rise a new form of DHCP protocol attack. A
malicious attacker in IPv6 can interference with the DHCPv4 process malicious attacker in IPv6 can interference with the DHCPv4 process
by inject fake DHCPv4-in-IPv6 messages which will be handled by TSV by inject fake DHCPv4-in-IPv6 messages which will be handled by TSV
or TRA. However, the damage is the same with the known DHCPv4 attack or TRA. However, the damage is the same with the known DHCPv4 attack
happened in IPv4. The only difference is the attacker and the victim happened in IPv4. The only difference is the attacker and the victim
could locate in different address families. could locate in different address families.
skipping to change at page 10, line 14 skipping to change at page 9, line 41
Tomasz Mrugalski Tomasz Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
Email: tomasz.mrugalski@gmail.com Email: tomasz.mrugalski@gmail.com
Dmitry Anipko Dmitry Anipko
Microsoft Corporation Microsoft Corporation
Email: danipko@microsoft.com Email: danipko@microsoft.com
12. Appendix: Discussion on One Host Retrieving Multiple Addresses 12. References
through One CRA 12.1. Normative References
[I-D.ietf-dhc-dhcpv4-relay-encapsulation]
Lemon, T., Deng, H., and L. Huang, "Relay Agent
Encapsulation for DHCPv4",
draft-ietf-dhc-dhcpv4-relay-encapsulation-01 (work in
progress), July 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
"Link Selection sub-option for the Relay Agent Information
Option for DHCPv4", RFC 3527, April 2003.
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
Identifiers for Dynamic Host Configuration Protocol
Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
12.2. Informative References
[I-D.ietf-dhc-client-id]
Swamy, N., Halwasia, G., and S. Unit, "Client Identifier
Option in DHCP Server Replies",
draft-ietf-dhc-client-id-05 (work in progress),
September 2012.
[I-D.ietf-softwire-public-4over6]
Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
IPv4 over IPv6 Access Network",
draft-ietf-softwire-public-4over6-03 (work in progress),
August 2012.
1. Motivation for selecting this particular solution
We considered three possible solutions to the problem of configuring
IPv4 addresses on an IPv6 network.
1.1. Configuring IPv4 with DHCPv6
Use DHCPv6 instead of DHCPv4, to provision IPv4-related connectivity.
In DHCPv6, the provisioned IPv4 address can be embedded into IPv6
address, or carried within a new option. Along with that, dedicated
options are needed to convey IPv4-related information, such as the
IPv4 address of DNS server, NTP server, etc. Therefore it will put a
certain amount of IPv6-unrelated information into DHCPv6 protocol.
This solution was rejected for two reasons. First, the DHCPv6
protocol does not currently provide a mechanism for recording
bindings between IPv4 addresses and DHCPv6 clients. Extending DHCPv6
to provide this functionality would be a substantial change to the
existing protocol.
Second, a deliberate choice was made when the DHCPv6 protocol was
defined to avoid simply copying existing functionality from DHCPv4.
While it is possible, using DHCPv6, to deliver IPv4 addresses as
IPv6-encoded IPv4 addresses, it might be necessary to add additional
DHCPv6 options simply to support IPv4. These options would then
remain in the protocol, long after the need for IPv4 has gone.
By comparison, any extensions to DHCPv4 will naturally be forgotten
when DHCPv4 is no longer needed. This means that whatever extensions
we make to DHCPv4 to solve the problem, we can stop maintaining as
soon as IPv4 is no longer needed.
1.2. Tunnel DHCPv4 over IPv6
Use DHCPv4 for configuration, and tunnel DHCPv4-in-IPv4 messages over
IPv6. Unlike the previous approach where DHCPv6 is used for both
IPv4 and IPv6 connectivity, this approach preserves the separation
between IPv4 and IPv6 connectivity information. It maintains the
IPv4 service without major modifications to IPv6-related provisioning
resources, and sustains DHCPv4 to be the IPv4-related information
carrier.
This approach was not chosen because it adds a requirement for DHCPv4
to operate over an IPv4-in-IPv6 tunnel. DHCPv4 clients generally
operate on broadcast networks, not on tunnels. To make DHCPv4
operate over a tunnel would require substantial changes to the DHCPv4
client, as well as maintaining a tunnel over which to deliver DHCPv4
traffic.
This also creates a chicken-and-egg problem: how do we set up an IPv4
tunnel when we do not know our IPv4 address? Solutions to these
problems were proposed, but they require significant changes to the
DHCP client and significant additional work to make a tunnel that
could carry the DHCP packets.
1.3. DHCPv4 relayed over IPv6
Use DHCPv4 for configuration, and extend it to use an IPv6 transport
for relayed messages. Essentially this involves a single change to
the protocol, to allow DHCPv4 servers or relay agents to send and
receive packets using an IPv6 transport. No changes are required on
the client.
The working group chose this third solution because, of the three, it
required the fewest changes to the DHCP protocol, so that it was
easiest to specify and easiest to implement.
2. Discussion on One Host Retrieving Multiple Addresses through One CRA
This document is written with the intention of supporting a use case This document is written with the intention of supporting a use case
where a single DHCP client is configuring a single tunnel endpoint where a single DHCP client is configuring a single tunnel endpoint
per physical link. The technique described in this document could be per physical link. The technique described in this document could be
used by a host needing to configure more than one tunnel endpoint on used by a host needing to configure more than one tunnel endpoint on
the same physical link, i.e., to retrieve multiple addresses through the same physical link, i.e., to retrieve multiple addresses through
the same CRA. However, the following additional behavior is REQUIRED the same CRA. However, the following additional behavior is REQUIRED
to support this case. to support this case.
DHCP server implementing this specification MUST implement Client DHCP server implementing this specification MUST implement Client
skipping to change at page 11, line 10 skipping to change at page 13, line 15
accept the messages intended for it). How this is accomplished is accept the messages intended for it). How this is accomplished is
left to the implementor. However, implementations MUST follow this left to the implementor. However, implementations MUST follow this
requirement; otherwise, it will be impossible for multiple tunnel requirement; otherwise, it will be impossible for multiple tunnel
endpoints to be successfully configured. The easiest way to endpoints to be successfully configured. The easiest way to
accomplish this is to have a single DHCP client process with multiple accomplish this is to have a single DHCP client process with multiple
DHCP state machines, and to dispatch each DHCP message to the correct DHCP state machines, and to dispatch each DHCP message to the correct
DHCP client state machine using the client identifier. However, this DHCP client state machine using the client identifier. However, this
is not REQUIRED; any mechanism that results in client state machines is not REQUIRED; any mechanism that results in client state machines
receiving the messages that are intended for them will suffice. receiving the messages that are intended for them will suffice.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
"Link Selection sub-option for the Relay Agent Information
Option for DHCPv4", RFC 3527, April 2003.
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
Identifiers for Dynamic Host Configuration Protocol
Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
13.2. Informative References
[I-D.ietf-dhc-client-id]
Swamy, N., Halwasia, G., and S. Unit, "Client Identifier
Option in DHCP Server Replies",
draft-ietf-dhc-client-id-02 (work in progress),
March 2012.
[I-D.ietf-dhc-dhcpv4-relay-encapsulation]
Lemon, T., Deng, H., and L. Huang, "Relay Agent
Encapsulation for DHCPv4",
draft-ietf-dhc-dhcpv4-relay-encapsulation-01 (work in
progress), July 2011.
[I-D.ietf-softwire-public-4over6]
Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y.
Lee, "Public IPv4 over IPv6 Access Network",
draft-ietf-softwire-public-4over6-01 (work in progress),
March 2012.
Authors' Addresses Authors' Addresses
Yong Cui Yong Cui
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
P.R.China P.R.China
Phone: +86-10-6260-3059 Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn Email: yong@csnet1.cs.tsinghua.edu.cn
skipping to change at page 12, line 35 skipping to change at page 14, line 4
Email: pengwu.thu@gmail.com Email: pengwu.thu@gmail.com
Jianping Wu Jianping Wu
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
P.R.China P.R.China
Phone: +86-10-6278-5983 Phone: +86-10-6278-5983
Email: jianping@cernet.edu.cn Email: jianping@cernet.edu.cn
Ted Lemon Ted Lemon
Nominum, Inc. Nominum, Inc.
2000 Seaport Blvd 2000 Seaport Blvd
Redwood City 94063 Redwood City, CA 94063
USA USA
Phone: +1-650-381-6000 Phone: +1-650-381-6000
Email: mellon@nominum.com Email: mellon@nominum.com
 End of changes. 33 change blocks. 
195 lines changed or deleted 247 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/