draft-ietf-dhc-dhcpv4-over-ipv6-08.txt   draft-ietf-dhc-dhcpv4-over-ipv6-09.txt 
Network Working Group Y. Cui Network Working Group Y. Cui
Internet-Draft P. Wu Internet-Draft P. Wu
Intended status: Informational J. Wu Intended status: Informational J. Wu
Expires: April 24, 2014 Tsinghua University Expires: October 26, 2014 Tsinghua University
T. Lemon T. Lemon
Nominum, Inc. Nominum, Inc.
Q. Sun Q. Sun
Tsinghua University Tsinghua University
October 21, 2013 April 24, 2014
DHCPv4 over IPv6 Transport DHCPv4 over IPv6 Transport
draft-ietf-dhc-dhcpv4-over-ipv6-08 draft-ietf-dhc-dhcpv4-over-ipv6-09
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
(IPv6-Transport Relay Agent) and relay DHCP traffic for the server, (IPv6-Transport Relay Agent) and relay DHCP traffic for the server,
with a new Relay Agent Information sub-option added to carry the IPv6 with a new Relay Agent Information sub-option added to carry the IPv6
address of the Client Relay Agent. DHCPv4 over IPv6 has been address of the Client Relay Agent. DHCPv4 over IPv6 has been
developed in the IETF, and some implementations and deployments have developed in the IETF, and some implementations and deployments have
been carried out. But this mechanism is not recommended for future been carried out. But this mechanism is not recommended for future
implementation or deployment. implementation or deployment.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 24, 2014. This Internet-Draft will expire on October 26, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . 4
4. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . . 6 4. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . 5
5. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . 6 5. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . 6
6. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 7 6. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . 7
7. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . 8 7. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . 8
8. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 8. Security Consideration . . . . . . . . . . . . . . . . . . . 8
9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 9
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Motivation for selecting this particular solution . . 11 Appendix A. Motivation for selecting this particular solution . 10
A.1. Configuring IPv4 with DHCPv6 . . . . . . . . . . . . . . 11 A.1. Configuring IPv4 with DHCPv6 . . . . . . . . . . . . . . 10
A.2. Tunnel DHCPv4 over IPv6 . . . . . . . . . . . . . . . . . 11 A.2. Tunnel DHCPv4 over IPv6 . . . . . . . . . . . . . . . . . 11
A.3. DHCPv4 relayed over IPv6 . . . . . . . . . . . . . . . . 12 A.3. DHCPv4 relayed over IPv6 . . . . . . . . . . . . . . . . 11
Appendix B. Discussion on One Host Retrieving Multiple Appendix B. Discussion on One Host Retrieving Multiple Addresses
Addresses through One CRA . . . . . . . . . . . . . . 12 through One CRA . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
DHCPv4 over IPv6 mechanism has been developed in the IETF. There DHCPv4 over IPv6 mechanism has been developed in the IETF. There
have been implementations from ISC, Juniper, Huawei, Tsinghua have been implementations from ISC, Juniper, Huawei, Tsinghua
University, etc. It is in active deployments in some networks, University, etc. It is in active deployments in some networks,
including in the China Next Generation Internet (CNGI) and China including in the China Next Generation Internet (CNGI) and China
Education and Research Network 2 (CERNET2), Deutsche Telekom, and so Education and Research Network 2 (CERNET2), Deutsche Telekom, and so
on. Documenting this mechanism is for the benefit of vendors and on. Documenting this mechanism is for the benefit of vendors and
operators of the existing implementations and deployments. According operators of the existing implementations and deployments. According
skipping to change at page 4, line 10 skipping to change at page 3, line 48
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. The TSV listens on IPv6 for incoming DHCPv4 messages, transport. The TSV listens on IPv6 for incoming DHCPv4 messages,
and sends DHCPv4 messages in IPv6 packets. and 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. The TRA sits on a machine which has both supports IPv6 transport. The TRA sits on a machine which has both
IPv6 and IPv4 connectivity, and relays DHCP messages between a CRA IPv6 and IPv4 connectivity, and relays DHCP messages between a CRA
and a regular DHCPv4 server. Unlike the CRA, the TRA sits on the and a regular DHCPv4 server. Unlike the CRA, the TRA sits on the
remote end of IPv6 network, and communicates with DHCPv4 server remote end of the IPv6 network, and communicates with the DHCPv4
through IPv4. server through IPv4.
o Client Relay Agent IPv6 Address Sub-option (CRA6ADDR sub-option): o Client Relay Agent IPv6 Address sub-option (CRA6ADDR sub-option):
a new sub-option of the DHCP Relay Agent Information Option a new sub-option of the DHCP Relay Agent Information Option
[RFC3046], defined in this document, which is used to carry the [RFC3046], defined in this document, which is used to carry the
IPv6 address of the CRA. IPv6 address of the CRA.
3. Protocol Summary 3. 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
server/relay cannot naturally be forwarded to each other because they /relay cannot naturally be forwarded to each other because they are
are IPv4 UDP packets, either unicast or broadcast. To bridge this IPv4 UDP packets, either unicast or broadcast. To bridge this gap,
gap, both the client side and the server/relay side can enable DHCPv4 both the client side and the server/relay side can enable DHCPv4 over
over IPv6 transport. More precisely, it is necessary for them to IPv6 transport. More precisely, it is necessary for them to support
support delivering and receiving DHCP messages in IPv6 UDP packets delivering and receiving DHCP messages in IPv6 UDP packets and
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. The 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. It 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.
+-------------------------+ +-------------------------+
+------+ | +------+ |
|DHCPv4| | |DHCPv4| |
|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 is able to receive DHCP messages The IPv6-Transport DHCPv4 server is able to receive DHCP messages
delivered in IPv6 UDP from the CRA, and send out DHCP messages to the delivered in IPv6 UDP from the CRA, and send out DHCP messages to the
CRA using IPv6 UDP (figure 2(a)). The TSV sends DHCP messages to the CRA using IPv6 UDP (figure 2(a)). The TSV sends DHCP messages to the
IPv6 address from which it receives relevant DHCP messages earlier. IPv6 address 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 becomes a little more with a server directly, the situation becomes a little more
complicated. Besides the IPv6 communication with a CRA, a TRA also complicated. Besides the IPv6 communication with a CRA, a TRA also
communicates with a regular DHCPv4 server through IPv4. Therefore, communicates with a regular DHCPv4 server through IPv4. Therefore,
when the TRA relays DHCP messages between a CRA and the DHCPv4 when the TRA relays DHCP messages between a CRA and the DHCPv4
server, it receives DHCP message from the CRA in IPv6 and sends it to server, it receives a DHCP message from the CRA in IPv6 and sends it
the server in IPv4, as well as receives DHCP message from the server to the server in IPv4, as well as receives a DHCP message from the
in IPv4 and sends it to the CRA in IPv6. server in IPv4 and sends it to the CRA in IPv6.
The TRA sends the IPv6 address of the CRA to the DHCP server using The TRA sends the IPv6 address of the CRA to the DHCP server using
the Client Relay Agent IPv6 Address (CRA6ADDR) suboption, defined in the Client Relay Agent IPv6 Address (CRA6ADDR) suboption, defined in
this document. The DHCP server returns this suboption to the TRA as this document. The DHCP server returns this suboption to the TRA as
required in [RFC3046]. The TRA then uses the returned CRA6ADDR required in [RFC3046]. The TRA then uses the returned CRA6ADDR
suboption to determine the destination address to which to relay the suboption to determine the destination address to which to relay the
response. response.
+------+ +------+ +------+ +------+
|client| IPv6 network |TSV | |client| IPv6 network |TSV |
skipping to change at page 6, line 5 skipping to change at page 5, line 41
|+HCRA |----------------| |--------------| | |+HCRA |----------------| |--------------| |
+------+ +------+ +------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
|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
4. Client Relay Agent IPv6 Address Sub-option 4. Client Relay Agent IPv6 Address Sub-option
The CRA6ADDR suboption is a suboption of the Relay Agent Information The CRA6ADDR suboption is a suboption of the Relay Agent Information
Option [RFC3046]. It encodes the IPv6 address of the machine from Option [RFC3046]. It encodes the IPv6 address of the machine from
which a DHCPv4-in-IPv6 CRA-to-TRA message was received. It is used which a DHCPv4-in-IPv6 CRA-to-TRA message was received. It is used
by the TRA to relay DHCPv4 replies back to the proper CRA. The TRA by the TRA to relay DHCPv4 replies back to the proper CRA. The TRA
uses the IPv6 address encoded in this suboption as the destination uses the IPv6 address encoded in this suboption as the destination
IPv6 address when relaying a DHCPv4 message from the DHCP server to IPv6 address when relaying a DHCPv4 message from the DHCP server to
the CRA. the CRA.
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.
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
5. Client Relay Agent Behavior 5. 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 same link as the host (LCRA). A CRA listens for (HCRA), or on the same link as the host (LCRA). A CRA listens for
DHCP packets on IPv4 on port 67, and also listens for DHCP packets on DHCP packets on IPv4 on port 67, and also listens for DHCP packets on
IPv6 on port 67. IPv6 on port 67.
A CRA is configured with one or more IPv6 addresses of TSV/TRA as the A CRA is configured with one or more IPv6 addresses of TSV/TRA as the
destination(s). The CRA is also configured with a global IPv6 destination(s). The CRA is also configured with a global IPv6
skipping to change at page 7, line 41 skipping to change at page 7, line 30
DHCPv4 client actually gets an IPv4 address. DHCPv4 client actually gets an IPv4 address.
6. IPv6-Transport Server Behavior 6. 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 and IPv4 UDP port A TSV listens for DHCP messages on IPv6 UDP port 67 and IPv4 UDP port
67. When it receives a DHCP message on IPv6, it retains the IPv6 67. When it receives a DHCP message on IPv6, it retains the IPv6
source address of that message until it has sent a response. When it source address of that message until it has sent a response. The TSV
sends a response, it sends the response to this IPv6 address, with sends the response to this IPv6 address, with destination port 67.
destination port 67.
The TSV is bound to send a server identifier option [RFC2132] The TSV is bound to send a server identifier option [RFC2132]
containing an IPv4 address which will be reachable from the client containing an IPv4 address which will be reachable from the client
once the residual IPv4 service is set up. This follows the server id once the residual IPv4 service is set up. This follows the server id
option requirement in [RFC2131]. option requirement in [RFC2131].
The rest of TSV DHCP process is the same with a normal DHCPv4 server. The rest of TSV DHCP process is the same with a normal DHCPv4 server.
A TSV also listens on IPv4 UDP port 67 like a normal DHCPv4 server, A TSV also listens on IPv4 UDP port 67 like a normal DHCPv4 server,
and process IPv4 DHCPv4 messages normally. This requirement exists and process IPv4 DHCPv4 messages normally. This requirement exists
because when a DHCPv4 client renews, it sends its renewal messages because when a DHCPv4 client renews, it sends its renewal messages
directly to the server, rather than broadcasting them. directly to the server, rather than broadcasting them.
Because a CRA may use relay agent encapsulation Because a CRA may use relay agent encapsulation
[I-D.ietf-dhc-dhcpv4-relay-encapsulation], the TSV ought to support [I-D.ietf-dhc-dhcpv4-relay-encapsulation], the TSV ought to support
it. A TSV that does not support it will not interoperate with a CRA it. A TSV that does not support it will not interoperate with a CRA
that sends relay agent options. that sends relay agent options.
skipping to change at page 8, line 18 skipping to change at page 8, line 8
directly to the server, rather than broadcasting them. directly to the server, rather than broadcasting them.
Because a CRA may use relay agent encapsulation Because a CRA may use relay agent encapsulation
[I-D.ietf-dhc-dhcpv4-relay-encapsulation], the TSV ought to support [I-D.ietf-dhc-dhcpv4-relay-encapsulation], the TSV ought to support
it. A TSV that does not support it will not interoperate with a CRA it. A TSV that does not support it will not interoperate with a CRA
that sends relay agent options. that sends relay agent options.
7. IPv6-Transport Relay Agent Behavior 7. IPv6-Transport Relay Agent Behavior
An IPv6-Transport Relay Agent sits between an IPv6 network and an An IPv6-Transport Relay Agent sits between an IPv6 network and an
IPv4 network, and relays DHCPv4 messages between CRAs and an IPv4- IPv4 network, and relays DHCPv4 messages between CRAs and an
only DHCPv4 server. The communication between CRAs and the TRA uses IPv4-only DHCPv4 server. The communication between CRAs and the TRA
IPv6, while the communication between the TRA and the server uses uses IPv6, while the communication between the TRA and the server
IPv4. A TRA listens on IPv6 UDP port 67 for DHCP messages with BOOTP uses IPv4. A TRA listens on IPv6 UDP port 67 for DHCP messages with
op field set to 1 or 3, as well as IPv4 UDP port 67 for DHCP messages BOOTP op field set to 1 or 3, as well as IPv4 UDP port 67 for DHCP
with BOOTP op field set to 2 or 4. messages with BOOTP op field set to 2 or 4.
When relaying a DHCP message from CRA to server, the TRA adds a When relaying a DHCP message from CRA to server, the TRA adds a
CRA6ADDR suboption. The TRA sets the contents of this suboption to CRA6ADDR suboption. The TRA sets the contents of this suboption to
the IPv6 source address of the message. The TRA also stores one its the IPv6 source address of the message. The TRA also stores one of
own IPv4 addresses in the giaddr field of the DHCP message. The TRA its own IPv4 addresses in the giaddr field of the DHCP message. The
may include a Link Selection sub-option [RFC3527] to indicate to the TRA may include a Link Selection sub-option [RFC3527] to indicate to
DHCP server which link to use when choosing an IP address. If the the DHCP server which link to use when choosing an IP address. If
received message is a RELAYFORWARD message, the TRA encapsulates the the received message is a RELAYFORWARD message, the TRA encapsulates
message in a new RELAYFORWARD message and stores the CRA6ADDR in the the message in a new RELAYFORWARD message and stores the CRA6ADDR in
new relay segment. If it is some other message, the TRA appends a the new relay segment. If it is some other message, the TRA appends
Relay Agent Information Option as described in [RFC3046], but may a Relay Agent Information Option as described in [RFC3046], but may
encapsulate it in the same way as RELAYFORWARD message instead, which encapsulate it in the same way as RELAYFORWARD message instead, which
depends on the implementation. depends on the implementation.
When receiving a DHCP message from the DHCP server, if the message When receiving a DHCP message from the DHCP server, if the message
contains no CRA6ADDR suboption, the TRA discards the message. contains no CRA6ADDR suboption, the TRA discards the message.
Otherwise, it processes it as required by [RFC3046] and Otherwise, it processes it as required by [RFC3046] and
[I-D.ietf-dhc-dhcpv4-relay-encapsulation], and forwards it to the [I-D.ietf-dhc-dhcpv4-relay-encapsulation], and forwards it to the
IPv6 address recorded in the CRA6ADDR sub-option, with source port 67 IPv6 address recorded in the CRA6ADDR sub-option, with source port 67
and destination port 67. and destination port 67.
skipping to change at page 9, line 17 skipping to change at page 9, line 8
Another impact is DHCP filtering. There are firewalls today capable Another impact is DHCP filtering. There are firewalls today capable
of filtering DHCP traffic (DHCPv4 over IPv4 and DHCPv6 over IPv6 of filtering DHCP traffic (DHCPv4 over IPv4 and DHCPv6 over IPv6
packets). The DHCP messages with the new, DHCPv4-in-IPv6 style may packets). The DHCP messages with the new, DHCPv4-in-IPv6 style may
bypass these firewalls. Nevertheless it is not difficult for them to bypass these firewalls. Nevertheless it is not difficult for them to
make some slight modification and adapt to the new DHCPv4 message make some slight modification and adapt to the new DHCPv4 message
pattern. pattern.
9. IANA Consideration 9. IANA Consideration
IANA is requested to assign one new sub-option code from the registry IANA is requested to assign one new sub-option code from the registry
of DHCP Agent Sub-Option Codes maintained in of DHCP Agent Sub-Option Codes maintained in http://www.iana.org/
http://www.iana.org/assignments/bootp-dhcp-parameters. This sub- assignments/bootp-dhcp-parameters. This sub-option code will be
option code will be assigned to the Client Relay Agent IPv6 Address assigned to the Client Relay Agent IPv6 Address Sub-option.
Sub-option.
10. Contributors 10. Contributors
The following gentlemen also contributed to the effort: The following gentlemen also contributed to the effort:
Francis Dupont Francis Dupont
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
Email: fdupont@isc.org Email: fdupont@isc.org
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
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-dhc-dhcpv4-relay-encapsulation] [I-D.ietf-dhc-dhcpv4-relay-encapsulation]
Lemon, T., Deng, H., and L. Huang, "Relay Agent Lemon, T., Deng, H., and L. Huang, "Relay Agent
Encapsulation for DHCPv4", Encapsulation for DHCPv4", draft-ietf-dhc-dhcpv4-relay-
draft-ietf-dhc-dhcpv4-relay-encapsulation-01 (work in encapsulation-01 (work in progress), July 2011.
progress), July 2011.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
RFC 2131, March 1997. 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
RFC 3046, January 2001. 3046, January 2001.
[RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
"Link Selection sub-option for the Relay Agent Information "Link Selection sub-option for the Relay Agent Information
Option for DHCPv4", RFC 3527, April 2003. Option for DHCPv4", RFC 3527, April 2003.
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
Identifiers for Dynamic Host Configuration Protocol Identifiers for Dynamic Host Configuration Protocol
Version Four (DHCPv4)", RFC 4361, February 2006. Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007. Problem Statement", RFC 4925, July 2007.
[RFC6842] Swamy, N., Halwasia, G., and P. Jhingran, "Client [RFC6842] Swamy, N., Halwasia, G., and P. Jhingran, "Client
Identifier Option in DHCP Server Replies", RFC 6842, Identifier Option in DHCP Server Replies", RFC 6842,
January 2013. January 2013.
11.2. Informative References 11.2. Informative References
[I-D.ietf-dhc-dhcpv4-over-dhcpv6] [I-D.ietf-dhc-dhcpv4-over-dhcpv6]
Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
Farrer, "DHCPv4 over DHCPv6 Transport", Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc-
draft-ietf-dhc-dhcpv4-over-dhcpv6-02 (work in progress), dhcpv4-over-dhcpv6-07 (work in progress), April 2014.
October 2013.
[I-D.ietf-dhc-v4configuration] [I-D.ietf-dhc-v4configuration]
Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration
Over IPv6 Only Networks", Over IPv6 Only Networks", draft-ietf-dhc-
draft-ietf-dhc-v4configuration-02 (work in progress), v4configuration-05 (work in progress), February 2014.
September 2013.
[I-D.ietf-softwire-public-4over6] [I-D.ietf-softwire-public-4over6]
Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
IPv4 over IPv6 Access Network", IPv4 over IPv6 Access Network", draft-ietf-softwire-
draft-ietf-softwire-public-4over6-10 (work in progress), public-4over6-10 (work in progress), July 2013.
July 2013.
Appendix A. Motivation for selecting this particular solution Appendix A. Motivation for selecting this particular solution
We considered three possible solutions to the problem of configuring We considered three possible solutions to the problem of configuring
IPv4 addresses on an IPv6 network. IPv4 addresses on an IPv6 network.
A.1. Configuring IPv4 with DHCPv6 A.1. Configuring IPv4 with DHCPv6
Use DHCPv6 instead of DHCPv4, to provision IPv4-related connectivity. Use DHCPv6 instead of DHCPv4, to provision IPv4-related connectivity.
In DHCPv6, the provisioned IPv4 address can be embedded into IPv6 In DHCPv6, the provisioned IPv4 address can be embedded into IPv6
 End of changes. 30 change blocks. 
82 lines changed or deleted 80 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/