draft-ietf-dhc-dhcpv4-over-ipv6-01.txt   draft-ietf-dhc-dhcpv4-over-ipv6-02.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: September 13, 2012 Tsinghua University Expires: September 30, 2012 Tsinghua University
T. Lemon T. Lemon
Nominum, Inc. Nominum, Inc.
March 12, 2012 March 29, 2012
DHCPv4 over IPv6 Transport DHCPv4 over IPv6 Transport
draft-ietf-dhc-dhcpv4-over-ipv6-01 draft-ietf-dhc-dhcpv4-over-ipv6-02
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 extending DHCP client and server behavior, transport. It is done by extending DHCP client and server behavior,
and by adding a new Relay Agent Information option to carry the IPv6 and by adding a new Relay Agent Information option to carry the IPv6
address of the client. address of the client.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 September 13, 2012. This Internet-Draft will expire on September 30, 2012.
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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . 6 6. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . . 6
7. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 7 7. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 7
8. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . . 7 8. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . . 8
9. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 9. Security Consideration . . . . . . . . . . . . . . . . . . . . 8
10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8 10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . . 9
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 DHCPv4 to environment. To meet this demand, this document extends DHCPv4 to
allow the use of an IPv6 network for transport. 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-
skipping to change at page 4, line 19 skipping to change at page 4, line 19
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 that sits on o Client Relay Agent(CRA): a special DHCPv4 Relay Agent that sits on
the same, IPv6-accessable host with the DHCPv4 client. CRA works the same, IPv6-accessable host with the DHCPv4 client. CRA works
as a "bridge" between DHCPv4 client and the IPv6 network, to as a "bridge" between DHCPv4 client and the IPv6 network, to
convert between IPv4 transport and IPv6 transport. convert between IPv4 transport and IPv6 transport.
o On-link Client Relay Agent(LCRA): a CRA sits on the link of the
host rather then inside the host.
o IPv6-Transport Server(TSV): a DHCPv4 Server that supports IPv6 o IPv6-Transport Server(TSV): a DHCPv4 Server that supports IPv6
transport. TSV can listen on IPv6 for incoming DHCPv4 messages, transport. TSV can listen on IPv6 for incoming DHCPv4 messages,
and send DHCPv4 messages in IPv6 packets. and send 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 normal DHCPv4 server. and normal DHCPv4 server.
o Client Relay Agent IPv6 Address Sub-option(CRA6ADDR suboption): a o Client Relay Agent IPv6 Address Sub-option(CRA6ADDR suboption): a
skipping to change at page 4, line 46 skipping to change at page 4, line 49
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 by default IPv4 UDP packets, either unicast or broadcast. To
bridge this gap, both the client side and the server/relay side bridge this gap, both the client side and the server/relay side
should enable DHCPv4 over IPv6 transport. More precisely, they should enable DHCPv4 over IPv6 transport. More precisely, they
should support delivering and receiving DHCP messages in IPv6 UDP should support delivering and receiving DHCP messages in IPv6 UDP
packets and thereby traverse the IPv6 network. packets and 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 machine with the client. CRA is used to relay is placed on the same host with the client, or on the link of the
DHCP messages from the client to the server, and from the server to client. CRA is used to relay DHCP messages from the client to the
the client. CRA sends DHCPv4 messages to the server through unicast server, and from the server to the client. CRA sends DHCPv4 messages
IPv6 UDP, and receives unicast IPv6 UDP packets with the DHCPv4 to the server through unicast IPv6 UDP, and receives unicast IPv6 UDP
messages from the server. By using CRA, no extension is required on packets with the DHCPv4 messages from the server. By using CRA, no
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| |
skipping to change at page 6, line 22 skipping to change at page 6, line 25
back to the proper CRA. To be more specific, the TRA uses the IPv6 back to the proper CRA. To be more specific, the TRA uses the IPv6
address encoded in this suboption as the destination IPv6 address address encoded in this suboption as the destination IPv6 address
when relaying a DHCPv4 reply to IPv6 network. when relaying a DHCPv4 reply to IPv6 network.
The CRA IPv6 address MUST be unique in the IPv6 domain. The CRA IPv6 address MUST be unique in the IPv6 domain.
The CRA6ADDR suboption has a fixed length of 18 octets. The SubOpt The CRA6ADDR suboption has a fixed length of 18 octets. The SubOpt
code is tbd by IANA, the length field should be 16, and the following code is tbd by IANA, the length field should be 16, and the following
16 octets contain the CRA IPv6 address. 16 octets contain the CRA IPv6 address.
DHCP servers MAY use this suboption to select parameters specific to DHCP servers handles it following the standard option 82 procedure
particular hosts. Servers MAY parse this suboption and extract the defined in [RFC3046]. DHCP servers MAY use this suboption to select
semantic of IPv6 address. parameters specific to particular hosts. Servers MAY parse this
suboption and extract the semantic of 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 machine with the DHCPv4 client. A Client Relay Agent sits on the same host with the DHCPv4 client.
CRA is a special type of relay agent, which relays DHCPv4 messages CRA is a special type of relay agent, which relays DHCPv4 messages
between regular client and TSV/TRA. The communication between CRA between regular client and TSV/TRA. The communication between CRA
and the client happens within the machine using IPv4, and the and the client happens within the machine using IPv4, and the
communication between CRA and TSV/TRA happens on the IPv6 network communication between CRA and TSV/TRA happens on the IPv6 network
using IPv6. 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. This
configuration is provided before DHCPv4 process, for example through configuration is provided before DHCPv4 process, for example through
DHCPv6 option, or by some other mechanisms depending on the DHCPv6 option, or by some other mechanisms depending on the
application scenarios. application scenarios.
A CRA listens for DHCP messages on IPv4 UDP port 67. When it A CRA listens for DHCP messages on IPv4 UDP port 67. When it
receives from IPv4 any DHCP message with bootp op field = 1, it receives from IPv4 any DHCP message with bootp op field = 1, it
forwards the message using the standard DHCP relay agent format, but forwards the message using the standard DHCP relay agent format, but
over UDPv6, with source port 67 and destination port 67. Here the over UDPv6, with source port 67 and destination port 67. Here the
CRA MUST NOT include an option 82 or modify the giaddr field of the CRA MUST NOT include an option 82 or modify the giaddr field of the
DHCP message. The CRA forwards the message to each of the DHCP DHCP message. The CRA forwards the message to each of the DHCP
server or relay agent with which it is configured. The CRA MUST use server or relay agent with which it is configured. The CRA MUST use
a global IPv6 address if it has one. a global IPv6 address if it has onbe.
A CRA also listens for DHCP messages on IPv6 UDP port 68. When it A CRA also listens for DHCP messages on IPv6 UDP port 68. When it
receives from IPv6 any DHCP message with bootp op field = 2, the CRA receives from IPv6 any DHCP message with bootp op field = 2, the CRA
checks to see if the message contains option 82, and if so, it checks to see if the message contains option 82, and if so, it
discards the message. Otherwise, it delivers the message to the DHCP discards the message. Otherwise, it delivers the message to the DHCP
client using IPv4. client using IPv4.
A CRA can also sits on the link of the host (LCRA). The basic
functionility of LCRA is the same with CRA. LCRA SHOULD NOT include
a option 82 or modify 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. LCRA does not necessarily need
an IPv4 address, though it may be configured with one.
A CRA MUST only serve the client inside the same host, while the LCRA
MUST serve any client on the link. When the IPv6 address of TSV/TRA
is provisioned, the DHCP client uses CRA; else the client uses LCRA.
7. IPv6-Transport Server Behavior 7. IPv6-Transport Server Behavior
To support IPv6 transport, the behavior of DHCPv4 server should be To support IPv6 transport, the behavior of DHCPv4 server should be
extended. The IPv6-Transport Server can listen on IPv6 port 67 for extended. The IPv6-Transport Server can listen on IPv6 port 67 for
DHCPv4 messages, and send DHCPv4 messages through IPv6. DHCPv4 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. When it
receives from IPv6 a DHCP message, it MUST record the IPv6 source receives from IPv6 a DHCP message, it MUST record the IPv6 source
address of that message and retain it as the return address of the address of that message and retain it as the return address of the
message. That is to say, when sometime later the TSV responds to message. That is to say, when sometime later the TSV responds to
this message, it MUST send the reply message to the IPv6 return this message, it MUST send the reply message to the IPv6 return
address retained earlier, with destination port 68. When the TSV address retained earlier, with destination port 68. When filling in
receives an DHCP message with a CRA6ADDR option, the TSV handles it the server id option of DHCP replies, the TSV MUST choose an IPv4
following the standard option 82 proceudure defined in [RFC3046]. address which is reachable from the client once the residual IPv4
The rest of TSV DHCP process is the same with normal DHCPv4 server. serivice is set up. This follows the server id option requirement in
A TSV can also listen on IPv4 UDP port 67 like a normal DHCPv4 [RFC2131]. The rest of TSV DHCP process is the same with normal
server, and process normally when receives IPv4 DHCPv4 message. DHCPv4 server. A TSV can 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 This document places no new requirements on DHCPv4 servers that do
not listen on UDPv6--in order to use an IPv4-only DHCPv4 server not listen on UDPv6--in order to use an IPv4-only DHCPv4 server
through an IPv6 connection, a TRA is required. through an IPv6 connection, a TRA is required.
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
skipping to change at page 8, line 32 skipping to change at page 9, line 4
could locate in different address families. could locate in different address families.
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
packages). The DHCP messages with the new, DHCPv4-in-IPv6 style may packages). 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.
10. IANA consideration 10. IANA consideration
IANA is requested to assign one new suboption code from the registry IANA is requested to assign one new suboption code from the registry
of DHCP Agent Sub-Option Codes maintained in of DHCP Agent Sub-Option Codes maintained in
http://www.iana.org/assignments/bootp-dhcp-parameters. This http://www.iana.org/assignments/bootp-dhcp-parameters. This
suboption code will be assigned to the Client Relay Agent IPv6 suboption code will be assigned to the Client Relay Agent IPv6
Address Sub-option. Address Sub-option.
11. References 11. Contributors
11.1. Normative References Francis Dupont and Tomek Mrugalski.
[RFC2119] Bradner, S., "Key words for use in 12. References
RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119,
March 1997.
[RFC2131] Droms, R., "Dynamic Host 12.1. Normative References
Configuration Protocol", RFC 2131,
March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent [RFC2119] Bradner, S., "Key words
Information Option", RFC 3046, for use in RFCs to
January 2001. Indicate Requirement
Levels", BCP 14, RFC 2119,
March 1997.
[RFC3527] Kinnear, K., Stapp, M., Johnson, [RFC2131] Droms, R., "Dynamic Host
R., and J. Kumarasamy, "Link Configuration Protocol",
Selection sub-option for the Relay RFC 2131, March 1997.
Agent Information Option for
DHCPv4", RFC 3527, April 2003.
[RFC4925] Li, X., Dawkins, S., Ward, D., and [RFC3046] Patrick, M., "DHCP Relay
A. Durand, "Softwire Problem Agent Information Option",
Statement", RFC 4925, July 2007. RFC 3046, January 2001.
11.2. Informative References [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.
[I-D.ietf-softwire-public-4over6] Cui, Y., Wu, J., Wu, P., Metz, C., [RFC4925] Li, X., Dawkins, S., Ward,
Vautrin, O., and Y. Lee, "Public D., and A. Durand,
IPv4 over Access IPv6 Network", dr "Softwire Problem
aft-ietf-softwire-public-4over6-00 Statement", RFC 4925,
(work in progress), July 2007.
September 2011.
12.2. Informative References
[I-D.ietf-dhc-dhcpv4-relay-encapsulation] Lemon, T., Deng, H., and
L. Huang, "Relay Agent
Encapsulation for 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", draf
t-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
 End of changes. 23 change blocks. 
53 lines changed or deleted 88 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/