Internet DRAFT - draft-cui-dhc-dhcpv4-over-ipv6
draft-cui-dhc-dhcpv4-over-ipv6
Network Working Group Y. Cui
Internet-Draft P. Wu
Intended status: Standards Track J. Wu
Expires: April 23, 2012 Tsinghua University
T. Lemon
Nominum, Inc.
October 21, 2011
DHCPv4 over IPv6 transport
draft-cui-dhc-dhcpv4-over-ipv6-00
Abstract
Recently, there are demands arising for IPv4 address allocation under
IPv6 environment, especially in IPv6 transition scenarios. This
document describes the mechanism to survive DHCPv4 over IPv6 network.
DHCPv4 messages are transported in IPv6 packets when traversing the
IPv6 network. DHCPv4 protocol behavior is extended to support this
IPv6 transport. And for the relay case, a new suboption of the Relay
Agent Information Option is defined to carry the remote IPv6 address
of the clients.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Cui, et al. Expires April 23, 2012 [Page 1]
Internet-Draft DHCPv4 over IPv6 October 2011
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 4
5. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . . 6
6. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . . 6
7. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 7
8. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . . 7
9. Security Consideration . . . . . . . . . . . . . . . . . . . . 8
10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . . 8
Cui, et al. Expires April 23, 2012 [Page 2]
Internet-Draft DHCPv4 over IPv6 October 2011
1. Introduction
DHCPv4[RFC2131] was not designed with IPv6 consideration. In
particular, DHCPv4 cannot work on IPv6 network. However, with IPv4-
IPv6 coexistence coming to reality, the demands of allocating IPv4
address under IPv6 environment naturally arise. To meet this kind of
demands, DHCPv4 should be extended to run over IPv6 network.
A typical scenario that probably requires this feature is 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 or end
networks), across an IPv6 network. If the IPv4 addresses of the end
users are provisioned by the concentrator side, then this address
provisioning needs to cross the IPv6 network, too. One such tunnel
mechanism is demonstrated in [I-D.cui-softwire-host-4over6]. DHCPv4
over IPv6 would be a generic solution for this scenario.
Three main flavours 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 packets 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 onto DHCP, and requires extra efforts to
maintain tunnel endpoint information for encapsulation use.
o Use DHCPv4 and extend it to work over IPv6 transport. This
flavour uses IPv6 directly for DHCP packet transport instead of
relying on IPv4-in-IPv6 tunnel, and it keeps the advantage of
separation with IPv6 connectivity information. This document
focuses on this flavour. The document will define the extensions
of DHCPv4 protocol behavior, as well as a new suboption of the
Relay Agent Information Option, to fully support DHCPv4 over IPv6
transport.
2. Requirements Language
Cui, et al. Expires April 23, 2012 [Page 3]
Internet-Draft DHCPv4 over IPv6 October 2011
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Terminology
This document makes use of the following terms:
o DHCPv4: IPv4 Dynamic Host Configuration Protocol [RFC2131].
o Client Relay Agent(CRA): a special DHCPv4 Relay Agent that sits on
the same, IPv6-accessable host with the DHCPv4 client. CRA works
as a "bridge" between DHCPv4 client and the IPv6 network, to
convert between IPv4 transport and IPv6 transport.
o IPv6-Transport Server(TSV): a DHCPv4 Server that support supports
IPv6 transport. TS can listen on IPv6 for incoming DHCP messages,
and sends DHCP messages in IPv6 packets.
o IPv6-Transport Relay Agent(TRA): a DHCPv4 Relay Agent that
supports IPv6 transport. TRA sits on a machine which has both
IPv6 and IPv4 connectivity, and relays DHCP packets between CRA
and normal DHCPv4 server.
o Client Relay Agent IPv6 Address Sub-option(6ADDR suboption): a new
suboption of DHCP Relay Agent Information Option[RFC3046] defined
in this document. 6ADDR suboption is used by TRA to carry the IPv6
address of a CRA.
4. Protocol Summary
The scenario for DHCPv4 over IPv6 transport is shown in Figure 1.
DHCPv4 clients and DHCPv4 server/relay are separated by an IPv6
network in the middle. DHCP messages between a client and the
server/relay cannot naturally be forwarded to each other because they
are IPv4 UDP packets by default, either unicast or broadcast. To
bridge this gap, both the client side and the server/relay side
should enable DHCPv4 to work over IPv6 transport, i.e., get delivered
in IPv6 UDP packets and traverse IPv6 network.
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
DHCP messages from the client to the server, and from the server to
the client. CRA sends DHCPv4 messages to the server through unicast
IPv6 UDP, and receives unicast IPv6 UDP packets with the DHCPv4
messages from the server. By using CRA, no extension is required on
the client.
Cui, et al. Expires April 23, 2012 [Page 4]
Internet-Draft DHCPv4 over IPv6 October 2011
+-------------------------+
+------+ |
|DHCPv4| |
|Client| +-------+
+------+ |DHCPv4 |
| IPv6 Network |Server/|
+------+ |Relay |
|DHCPv4| +-------+
|Client| |
+------+ |
+-------------------------+
Figure 1 Scenario of DHCPv4 over IPv6 Transport
The IPv6-Transport DHCPv4 server can receive DHCP packets delivered
in IPv6 UDP from CRA, and send out DHCP packets to CRA using IPv6
UDP(figure 2(a)). TSV should send such packets to the IPv6 address
from which TSV receives corresponding DHCP messages earlier.
When CRAs communicate with an IPv6-Transport Relay Agent rather than
with a server directly, the situation will be a little more
complicated. Besides the IPv6 connection, TRA also has IPv4
connection and communicates with a regular DHCPv4 server through
IPv4. So TRA relays DHCP messages between CRAs in IPv6 and regular
server in IPv4. TRA has to use the DHCP Relay Agent Information
Option(Option 82) to record the IPv6 address of a CRA, which will be
used as forwarding destination when relaying DHCP a message from the
server. Since Option 82 doesn't has an existing suboption that fits
in here, this document defines a new Client Relay Agent IPv6 Address
Sub-option.
+------+ +------+
|client| IPv6 network |TSV |
|+CRA |----------------| |
+------+ +------+
(a)client--server case
+------+ +------+ +------+
|client| IPv6 network |TRA | IPv4 network |server|
|+CRA |----------------| |--------------| |
+------+ +------+ +------+
(b)client--relay--server case
Figure 2 Protocol Summary
Cui, et al. Expires April 23, 2012 [Page 5]
Internet-Draft DHCPv4 over IPv6 October 2011
5. Client Relay Agent IPv6 Address Sub-option
This suboption MUST be added by DHCPv4 relay agents which are TRAs.
It encodes the IPv6 address of the host from which a DHCPv4-in-IPv6
CRA-to-TRA packet was received. It is intended for use by TRAs in
relaying DHCPv4 responses back to the proper CRA. To be more
specific, TRAs use the IPv6 address encoded in this suboption as the
destination IPv6 address when relaying DHCPv4 responses to IPv6
network.
The CRA IPv6 address MUST be unique in the IPv6 domain.
The 6ADDR suboption has a fixed length of 18 octets. The SubOpt code
is tbd by IANA, the length field should be 16, and the following 16
octets contain the CRA IPv6 address.
DHCP servers MAY use this suboption to select parameters specific to
particular hosts. Servers MAY parse this suboption and extract the
IPv6 address semantic.
SubOpt Len Agent Remote ID
+------+------+------+------+------+- -+------+
| tbd | 16 | a1 | a2 | a3 | ... | a16 |
+------+------+------+------+------+- -+------+
Figure 3 Client Relay Agent IPv6 Address Sub-option format
6. Client Relay Agent Behavior
A Client Relay Agent sits on the same machine with the DHCPv4 client.
CRA is a special type of relay agent, which relays DHCPv4 messages
between regular client and TSV/TRA. The communication between CRA
and the client happens within the machine 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
configuration is provided before DHCPv4 process, for example through
DHCPv6 option, or by some other mechanisms, depending on the
application scenarios.
A CRA listens for DHCP packets on IPv4 UDP port 67. When it receives
from IPv4 any DHCP packet with bootp op field = 1, it forwards the
packet using the standard DHCP relay agent format, but over UDPv6,
with source port 67 and destination port 67. Here the CRA MUST NOT
include an option 82, and MUST NOT modify the giaddr field of the
Cui, et al. Expires April 23, 2012 [Page 6]
Internet-Draft DHCPv4 over IPv6 October 2011
DHCP packet. The CRA forwards the packet to each of the DHCP server
or relay agent IP addresses with which it is configured. The CRA
MUST use a global IPv6 address if it has one.
A CRA also listens for DHCP packets on IPv6 UDP port 68. When it
receives from IPv6 any DHCP packet with bootp op field = 2, the CRA
checks to see if the packet contains option 82, and if so, it drops
the packet. Otherwise, it delivers the packet to the DHCP client
using IPv4.
7. IPv6-Transport Server Behavior
To support IPv6 transport, the behavior of DHCPv4 server should be
extended. The IPv6-Transport Server can listen on IPv6 port 67 for
DHCPv4 packets, and send DHCPv4 packets through IPv6.
When a TSV listening on IPv6 UDP port 67, receives a DHCP packet, it
MUST record the IPv6 source address of that packet and retain it as
the return address of the packet. That is to say, when sometime
later the TSV responds to this packet which is received in IPv6, it
MUST send the response packet to the IPv6 return address recorded
earlier. The rest of TSV DHCP process is the same with normal DHCPv4
server. A TSV can also listen on IPv4 UDP port 67, just like a
normal DHCPv4 server, and process normally when receives IPv4 DHCPv4
packet.
This document places no new requirements on DHCPv4 servers that do
not listen on UDPv6--in order to use an IPv4-only DHCPv4 server
through an IPv6 connection, a TRA is required.
8. IPv6-Transport Relay Agent Behavior
An IPv6-Transport Relay Agent sits between IPv6 network and IPv4
network, and relays DHCPv4 message between CRAs and IPv4-only DHCPv4
server. The communication between CRAs and the TRA uses IPv6, and
the communication between TRA and server uses IPv4. A TRA listens on
IPv6 UDP port 67 for DHCP packets with bootp op field = 1, and also
on IPv4 UDP port 68 for DHCP packets with bootp op field = 2.
When relaying a DHCP message from CRA to server, TRA MUST add an
option 82 with a 6ADDR suboption. This suboption contains the IPv6
source address of the message when it is received in IPv6, i.e., the
CRA's IPv6 address. The TRA MUST also store IPv4 address of itself
in the giaddr field of the DHCP message. The TRA MAY include a Link
Selection Suboption[RFC2131] to indicate to the DHCP server which
link to use when choosing an IP address.
When a TRA receives a DHCP message from the DHCP server. If the
Cui, et al. Expires April 23, 2012 [Page 7]
Internet-Draft DHCPv4 over IPv6 October 2011
packet contains no 6ADDR suboption, the TRA discards the packet.
Otherwise, it processes it as required by [RFC3046], and forwards it
to the IPv6 address recorded in the 6ADDR suboption.
9. Security Consideration
This specification raises no particular security issues to the DHCPv4
protocol model.
10. IANA consideration
IANA is requested to assign one new suboption code from the registry
of DHCP Agent Sub-Option Codes maintained in
http://www.iana.org/assignments/bootp-dhcp-parameters. This
suboption code will be assigned to the Client Relay Agent IPv6
Address Sub-option.
11. References
11.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.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A.
Durand, "Softwire Problem Statement",
RFC 4925, July 2007.
11.2. Informative References
[I-D.cui-softwire-host-4over6] Cui, Y., Wu, J., Wu, P., Metz, C.,
Vautrin, O., and Y. Lee, "Public IPv4
over Access IPv6 Network",
Cui, et al. Expires April 23, 2012 [Page 8]
Internet-Draft DHCPv4 over IPv6 October 2011
draft-cui-softwire-host-4over6-06
(work in progress), July 2011.
Authors' Addresses
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6260-3059
EMail: cuiyong@tsinghua.edu.cn
Peng Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
EMail: peng-wu@foxmail.com
Jianping Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5983
EMail: jianping@cernet.edu.cn
Ted Lemon
Nominum, Inc.
2000 Seaport Blvd
Redwood City 94063
USA
Phone: +1-650-381-6000
EMail: mellon@nominum.com
Cui, et al. Expires April 23, 2012 [Page 9]
