draft-ietf-dhc-dhcpv4-over-ipv6-04.txt   draft-ietf-dhc-dhcpv4-over-ipv6-05.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: March 17, 2013 Tsinghua University Expires: March 20, 2013 Tsinghua University
T. Lemon T. Lemon
Nominum, Inc. Nominum, Inc.
September 13, 2012 September 16, 2012
DHCPv4 over IPv6 Transport DHCPv4 over IPv6 Transport
draft-ietf-dhc-dhcpv4-over-ipv6-04 draft-ietf-dhc-dhcpv4-over-ipv6-05
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 March 17, 2013. This Internet-Draft will expire on March 20, 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 8 8. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . 8
9. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 9. Security Consideration . . . . . . . . . . . . . . . . . . . . 8
10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9 10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix 1. Motivation for selecting this particular solution . . 11 Appendix A. Motivation for selecting this particular solution . . 10
1.1. Configuring IPv4 with DHCPv6 . . . . . . . . . . . . . . 11 A.1. Configuring IPv4 with DHCPv6 . . . . . . . . . . . . . . 11
1.2. Tunnel DHCPv4 over IPv6 . . . . . . . . . . . . . . . . . 11 A.2. Tunnel DHCPv4 over IPv6 . . . . . . . . . . . . . . . . . 11
1.3. DHCPv4 relayed over IPv6 . . . . . . . . . . . . . . . . 12 A.3. DHCPv4 relayed over IPv6 . . . . . . . . . . . . . . . . 12
Appendix 2. Discussion on One Host Retrieving Multiple Appendix B. Discussion on One Host Retrieving Multiple
Addresses through One CRA . . . . . . . . . . . . . . 12 Addresses through One CRA . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 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.
skipping to change at page 7, line 13 skipping to change at page 7, line 13
the message to the DHCP client using IPv4. the message to the DHCP client using IPv4.
When the CRA receives any message on IPv6 with BOOTP op field set to When the CRA receives any message on IPv6 with BOOTP op field set to
4, it decapsulates the message as specified in DHCPv4 Relay Agent 4, it decapsulates the message as specified in DHCPv4 Relay Agent
Encapsulation [I-D.ietf-dhc-dhcpv4-relay-encapsulation]. If the CRA Encapsulation [I-D.ietf-dhc-dhcpv4-relay-encapsulation]. If the CRA
does not support encapsulation, it MUST silently discard the message. does not support encapsulation, it MUST silently discard the message.
The LCRA or HCRA MUST NOT use the Relay Agent Information Option The LCRA or HCRA MUST NOT use the Relay Agent Information Option
[RFC3046]. If either type of CRA needs to send relay agent options, [RFC3046]. If either type of CRA needs to send relay agent options,
it MUST use relay agent encapsulation as defined in it MUST use relay agent encapsulation as defined in
[I-D.ietf-dhc-dhcpv4-relay-encapsulation]. In that case, the TRA and [I-D.ietf-dhc-dhcpv4-relay-encapsulation].
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 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 host running the DHCP client, it uses TSV/TRA is provisioned to the host running the DHCP client, it uses
HCRA; else the client depends on LCRA. A HCRA serves only one link; HCRA; else the client depends on LCRA. A HCRA serves only one link;
the multiple link case MUST be handled by multiple HCRA instances. A the multiple link case MUST be handled by multiple HCRA instances. A
LCRA does not necessarily need an IPv4 address, though it may be LCRA does not necessarily need an IPv4 address, though it may be
configured with one. configured with one.
In HCRA case, the DHCPv6 client (or other IPv6 configuration In HCRA case, the DHCPv6 client (or other IPv6 configuration
skipping to change at page 10, line 4 skipping to change at page 9, line 40
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. References 12. References
12.1. Normative References 12.1. Normative 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-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-encapsulation-01 (work in draft-ietf-dhc-dhcpv4-relay-encapsulation-01 (work in
progress), July 2011. progress), July 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
skipping to change at page 10, line 37 skipping to change at page 10, line 38
[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.
12.2. Informative References 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] [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-public-4over6-03 (work in progress), draft-ietf-softwire-public-4over6-03 (work in progress),
August 2012. August 2012.
1. 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.
1.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
address, or carried within a new option. Along with that, dedicated address, or carried within a new option. Along with that, dedicated
options are needed to convey IPv4-related information, such as the options are needed to convey IPv4-related information, such as the
IPv4 address of DNS server, NTP server, etc. Therefore it will put a IPv4 address of DNS server, NTP server, etc. Therefore it will put a
certain amount of IPv6-unrelated information into DHCPv6 protocol. certain amount of IPv6-unrelated information into DHCPv6 protocol.
This solution was rejected for two reasons. First, the DHCPv6 This solution was rejected for two reasons. First, the DHCPv6
protocol does not currently provide a mechanism for recording protocol does not currently provide a mechanism for recording
skipping to change at page 11, line 37 skipping to change at page 11, line 32
While it is possible, using DHCPv6, to deliver IPv4 addresses as While it is possible, using DHCPv6, to deliver IPv4 addresses as
IPv6-encoded IPv4 addresses, it might be necessary to add additional IPv6-encoded IPv4 addresses, it might be necessary to add additional
DHCPv6 options simply to support IPv4. These options would then DHCPv6 options simply to support IPv4. These options would then
remain in the protocol, long after the need for IPv4 has gone. remain in the protocol, long after the need for IPv4 has gone.
By comparison, any extensions to DHCPv4 will naturally be forgotten By comparison, any extensions to DHCPv4 will naturally be forgotten
when DHCPv4 is no longer needed. This means that whatever extensions when DHCPv4 is no longer needed. This means that whatever extensions
we make to DHCPv4 to solve the problem, we can stop maintaining as we make to DHCPv4 to solve the problem, we can stop maintaining as
soon as IPv4 is no longer needed. soon as IPv4 is no longer needed.
1.2. Tunnel DHCPv4 over IPv6 A.2. Tunnel DHCPv4 over IPv6
Use DHCPv4 for configuration, and tunnel DHCPv4-in-IPv4 messages over Use DHCPv4 for configuration, and tunnel DHCPv4-in-IPv4 messages over
IPv6. Unlike the previous approach where DHCPv6 is used for both IPv6. Unlike the previous approach where DHCPv6 is used for both
IPv4 and IPv6 connectivity, this approach preserves the separation IPv4 and IPv6 connectivity, this approach preserves the separation
between IPv4 and IPv6 connectivity information. It maintains the between IPv4 and IPv6 connectivity information. It maintains the
IPv4 service without major modifications to IPv6-related provisioning IPv4 service without major modifications to IPv6-related provisioning
resources, and sustains DHCPv4 to be the IPv4-related information resources, and sustains DHCPv4 to be the IPv4-related information
carrier. carrier.
This approach was not chosen because it adds a requirement for DHCPv4 This approach was not chosen because it adds a requirement for DHCPv4
skipping to change at page 12, line 11 skipping to change at page 12, line 6
operate over a tunnel would require substantial changes to the DHCPv4 operate over a tunnel would require substantial changes to the DHCPv4
client, as well as maintaining a tunnel over which to deliver DHCPv4 client, as well as maintaining a tunnel over which to deliver DHCPv4
traffic. traffic.
This also creates a chicken-and-egg problem: how do we set up an IPv4 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 tunnel when we do not know our IPv4 address? Solutions to these
problems were proposed, but they require significant changes to the problems were proposed, but they require significant changes to the
DHCP client and significant additional work to make a tunnel that DHCP client and significant additional work to make a tunnel that
could carry the DHCP packets. could carry the DHCP packets.
1.3. DHCPv4 relayed over IPv6 A.3. DHCPv4 relayed over IPv6
Use DHCPv4 for configuration, and extend it to use an IPv6 transport Use DHCPv4 for configuration, and extend it to use an IPv6 transport
for relayed messages. Essentially this involves a single change to for relayed messages. Essentially this involves a single change to
the protocol, to allow DHCPv4 servers or relay agents to send and the protocol, to allow DHCPv4 servers or relay agents to send and
receive packets using an IPv6 transport. No changes are required on receive packets using an IPv6 transport. No changes are required on
the client. the client.
The working group chose this third solution because, of the three, it The working group chose this third solution because, of the three, it
required the fewest changes to the DHCP protocol, so that it was required the fewest changes to the DHCP protocol, so that it was
easiest to specify and easiest to implement. easiest to specify and easiest to implement.
2. Discussion on One Host Retrieving Multiple Addresses through One CRA Appendix B. 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
 End of changes. 15 change blocks. 
25 lines changed or deleted 25 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/