draft-ietf-dhc-v4configuration-05.txt   draft-ietf-dhc-v4configuration-06.txt 
DHC WG B. Rajtar DHC WG B. Rajtar
Internet-Draft Hrvatski Telekom Internet-Draft Hrvatski Telekom
Intended status: Informational I. Farrer Intended status: Informational I. Farrer
Expires: August 16, 2014 Deutsche Telekom AG Expires: January 2, 2015 Deutsche Telekom AG
February 12, 2014 July 01, 2014
Provisioning IPv4 Configuration Over IPv6 Only Networks Provisioning IPv4 Configuration Over IPv6 Only Networks
draft-ietf-dhc-v4configuration-05 draft-ietf-dhc-v4configuration-06
Abstract Abstract
As IPv6 becomes more widely adopted, some service providers are As IPv6 becomes more widely adopted, some service providers are
choosing to deploy IPv6 only networks without dual-stack choosing to deploy IPv6 only networks without dual-stack
functionality for IPv4. However, as access to IPv4 based services functionality for IPv4. However, as access to IPv4 based services
will continue to be a requirement for the foreseeable future, IPv4 will continue to be a requirement for the foreseeable future, IPv4
over IPv6 mechanisms, such as softwire tunnels are being developed. over IPv6 mechanisms, such as softwire tunnels are being developed.
In order to provision end-user's hosts with the IPv4 configuration In order to provision end-user's hosts with the IPv4 configuration
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 August 16, 2014. This Internet-Draft will expire on January 2, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 3, line 43 skipping to change at page 3, line 43
capable link-layer, depending on the underlying IPv4 in IPv6 capable link-layer, depending on the underlying IPv4 in IPv6
technology, network topology and DHCPv4 client capabilities. A technology, network topology and DHCPv4 client capabilities. A
functional description of how unmodified DHCPv4 can be used is functional description of how unmodified DHCPv4 can be used is
provided in Section 5. This approach is recommended for service provided in Section 5. This approach is recommended for service
providers whose network and clients can support this DHCPv4 providers whose network and clients can support this DHCPv4
architecture. architecture.
For the most simple IPv4 provisioning case, where the client only For the most simple IPv4 provisioning case, where the client only
needs to receive a static IPv4 address assignment (with no dynamic needs to receive a static IPv4 address assignment (with no dynamic
address leasing or additional IPv4 configuration), a DHCPv6 based address leasing or additional IPv4 configuration), a DHCPv6 based
approach (e.g. [I-D.ietf-softwire-map-dhcp]) may provide a suitable approach (e.g. [I-D.ietf-softwire-map-dhcp]) may provide a suitable
solution. solution.
This document is concerned with more complex IPv4 configuration This document is concerned with more complex IPv4 configuration
scenarios, to bring IPv4 configuration over IPv6-only networks in scenarios, to bring IPv4 configuration over IPv6-only networks in
line with the functionality offered by DHCPv4 in IPv4 native line with the functionality offered by DHCPv4 in IPv4 native
networks. DHCPv4 options may also need to be conveyed to clients for networks. DHCPv4 options may also need to be conveyed to clients for
configuring IPv4 based services, e.g., SIP server addresses. configuring IPv4 based services, e.g., SIP server addresses.
Although IPv4-in-IPv6 softwire tunnel and translation clients are Although IPv4-in-IPv6 softwire tunnel and translation clients are
currently the only use-case for DHCP based configuration of IPv4 currently the only use-case for DHCP based configuration of IPv4
skipping to change at page 4, line 29 skipping to change at page 4, line 29
parameters over IPv6 only networks have been suggested: parameters over IPv6 only networks have been suggested:
1. Adapt DHCPv4 format messages to be transported over IPv6 as 1. Adapt DHCPv4 format messages to be transported over IPv6 as
described in [I-D.ietf-dhc-dhcpv4-over-ipv6]. For brevity, this described in [I-D.ietf-dhc-dhcpv4-over-ipv6]. For brevity, this
is referred to as DHCPv4o6. is referred to as DHCPv4o6.
2. Extend DHCPv6 to support IPv4 address leasing and other DHCPv4 2. Extend DHCPv6 to support IPv4 address leasing and other DHCPv4
options. options.
3. Use DHCPv6 for external IPv4 address and source port 3. Use DHCPv6 for external IPv4 address and source port
configuration (e.g. [I-D.ietf-softwire-map-dhcp]. Use DHCPv4 configuration (e.g. [I-D.ietf-softwire-map-dhcp]. Use DHCPv4
over IPv4 messages within an IPv6 softwire for configuring over IPv4 messages within an IPv6 softwire for configuring
additional parameters. This is referred to as DHCPv6 + Stateless additional parameters. This is referred to as DHCPv6 + Stateless
DHCPv4oSW. DHCPv4oSW.
4. Use DHCPv4 format messages, transporting them within a new DHCPv6 4. Use DHCPv4 format messages, transporting them within a new DHCPv6
message type as described in [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. message type as described in [I-D.ietf-dhc-dhcpv4-over-dhcpv6].
This is referred to as DHCPv4oDHCPv6. This is referred to as DHCPv4oDHCPv6.
At the time of writing, working examples of the first two methods At the time of writing, working examples of all but the third method
have been developed and successfully tested in several different have been developed and successfully tested in several different
operators networks. operators networks.
The following sections provide describe each of the approaches in The following sections describe each of the approaches in more
more detail. detail.
1.2. DHCPv4o6 Based Provisioning - Functional Overview 1.2. DHCPv4o6 Based Provisioning - Functional Overview
In order to receive IPv4 configuration parameters, IPv4-only clients In order to receive IPv4 configuration parameters, IPv4-only clients
initiate and exchange DHCPv4 messages with the DHCPv4 server. To initiate and exchange DHCPv4 messages with the DHCPv4 server. To
adapt this for an IPv6-only network, an existing DHCPv4 client adapt this for an IPv6-only network, an existing DHCPv4 client
implements a Host Client Relay Agent (HCRA) function, which takes implements a Host Client Relay Agent (HCRA) function, which takes
DHCPv4 messages and puts them into UDP and IPv6. DHCPv4 messages and puts them into UDP and IPv6.
As the mechanism involves unicast IPv6 based communications, the IPv6 As the mechanism involves unicast IPv6 based communications, the IPv6
address of the server must be provisioned to the client. A DHCPv6 address of the server must be provisioned to the client. A DHCPv6
option for provisioning clients with this address is described in option for provisioning clients with this address is described in
[I-D.mrugalski-softwire-dhcpv4-over-v6-option]. [I-D.mrugalski-softwire-dhcpv4-over-v6-option].
The IPv6 Transport Server (TSV) provides an IPv6 interface to the The IPv6 Transport Server (TSV) provides an IPv6 interface to the
client. This interface may be implemented directly on the server and client. This interface may be implemented directly on the server
/or via an intermediary 'Transport Relay Agent' (TRA) device which and/or via an intermediary 'Transport Relay Agent' (TRA) device which
acts as the gateway between the IPv4 and IPv6 domains. acts as the gateway between the IPv4 and IPv6 domains.
For the dynamic allocation of IPv4 addresses, the DHCPv4 server For the dynamic allocation of IPv4 addresses, the DHCPv4 server
function needs to be extended to add DHCPv4o6 TSV capabilities, such function needs to be extended to add DHCPv4o6 TSV capabilities, such
as the storing the IPv6 address of DHCPv4o6 clients and implementing as the storing the IPv6 address of DHCPv4o6 clients and implementing
the CRA6ADDR option. the CRA6ADDR option.
This approach currently uses functional elements for ingress and This approach currently uses functional elements for ingress and
egress of the IPv6-only transport domain - the HCRA on the host and egress of the IPv6-only transport domain - the HCRA on the host and
the TRA or TSV on the server. As a result, this has sometimes been the TRA or TSV on the server. As a result, this has sometimes been
skipping to change at page 6, line 41 skipping to change at page 6, line 41
the same manner as any other IPv4 based traffic. Broadcast based the same manner as any other IPv4 based traffic. Broadcast based
DHCPv4 DHCPDISCOVER messages (necessary for IPv4 address assignment) DHCPv4 DHCPDISCOVER messages (necessary for IPv4 address assignment)
can not be transported as some softwire mechanisms implement NBMA can not be transported as some softwire mechanisms implement NBMA
links, where broadcast isn't supported. Additionally, there is a links, where broadcast isn't supported. Additionally, there is a
more general issue with the use of fixed L4 ports in A+P [RFC6346] more general issue with the use of fixed L4 ports in A+P [RFC6346]
based approaches. Here, a single IPv4 address is shared among based approaches. Here, a single IPv4 address is shared among
multiple users, each using a unique set of ports for differentiation multiple users, each using a unique set of ports for differentiation
meaning that it is not possible for every client to be allocated a meaning that it is not possible for every client to be allocated a
fixed L4 within its unique port set. fixed L4 within its unique port set.
On receipt by the tunnel concentrator (e.g. MAP Border Router or a On receipt by the tunnel concentrator (e.g. MAP Border Router or a
Lightweight 4over6 lwAFTR), the DHCPv4 message is extracted from the Lightweight 4over6 lwAFTR), the DHCPv4 message is extracted from the
IPv6 packet and forwarded to the DHCPv4 server in the same way as any IPv6 packet and forwarded to the DHCPv4 server in the same way as any
other IPv4 forwarding plane packet is handled. other IPv4 forwarding plane packet is handled.
As the client is already configured with its external IPv4 address As the client is already configured with its external IPv4 address
and source ports (using DHCPv6 or a well-known IPv4 address for DS- and source ports (using DHCPv6 or a well-known IPv4 address for DS-
Lite clients), the messages exchanged between the DHCPv4 client and Lite clients), the messages exchanged between the DHCPv4 client and
server would be strictly DHCPINFORM/DHCPACK messages. These can be server would be strictly DHCPINFORM/DHCPACK messages. These can be
used for conveying additional DHCPv4 based options. used for conveying additional DHCPv4 based options.
skipping to change at page 7, line 45 skipping to change at page 7, line 45
DHCPv4/UDP/IPv6 DHCPv4/UDP/IPv6
1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview 1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview
[I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes transporting DHCPv4 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes transporting DHCPv4
messages within two new DHCPv6 messages types: DHCPV4-QUERY and messages within two new DHCPv6 messages types: DHCPV4-QUERY and
DHCPV4-RESPONSE. These new messages types must be implemented in DHCPV4-RESPONSE. These new messages types must be implemented in
both the DHCPv4oDHCPv6 client and server. both the DHCPv4oDHCPv6 client and server.
In this approach, the configuration of stateless IPv4 addresses and In this approach, dynamic IPv4 addressing, and/or any additional IPv4
source ports (if required) is carried out using DHCPv6 as described configuration, is provided using DHCPv4 messages carried (without
in section 1.3 above. Dynamic IPv4 addressing, and/or any additional IPv4/UDP headers) within a new OPTION_DHCPV4_MSG DHCPv6 option.
IPv4 configuration, is provided using DHCPv4 messages carried
(without IPv4/UDP headers) within a new OPTION_DHCPV4_MSG DHCPv6
option.
OPTION_DHCPV4_MSG enables the client and server to send BOOTP/DHCPv4 OPTION_DHCPV4_MSG enables the client and server to send BOOTP/DHCPv4
messages verbatim across the IPv6 network. When a DHCPv4oDHCPv6 messages verbatim across the IPv6 network. When a DHCPv4oDHCPv6
server receives a DHCPv6 request containing OPTION_BOOT_MSG within a server receives a DHCPv6 request containing OPTION_DHCPV4_MSG within
DHCPV4-QUERY message, it passes it to the DHCPv4 server engine. a DHCPV4-QUERY message, it passes it to the DHCPv4 server engine.
Likewise, the DHCPv4 server place its DHCPv4 response in the payload Likewise, the DHCPv4 server place its DHCPv4 response in the payload
of OPTION_DHCPV4_MSG and puts this into a DHCPV4-RESPONSE message. of OPTION_DHCPV4_MSG and puts this into a DHCPV4-RESPONSE message.
DHCPv4 messages can be carried within DHCPv6 multicast messages, DHCPv4 messages can be carried within DHCPv6 multicast messages,
using the All_DHCP_Relay_Agents_and_Servers multicast address. These using the All_DHCP_Relay_Agents_and_Servers multicast address. These
can be relayed in exactly the same way as any other DHCPv6 can be relayed in exactly the same way as any other DHCPv6
multicasted messages. multicasted messages.
Optionally, DHCPv6 relays could be updated so that they forward the Optionally, DHCPv6 relays could be updated so that they forward the
DHCPV4-QUERY message to a different destination address, allowing for DHCPV4-QUERY message to a different destination address, allowing for
skipping to change at page 13, line 26 skipping to change at page 13, line 23
implementations and include them as new DHCPv6 message types. The implementations and include them as new DHCPv6 message types. The
main rationale for this is that it enables all of DHCPv4's existing main rationale for this is that it enables all of DHCPv4's existing
options to be migrated for use over IPv6 in a single step. options to be migrated for use over IPv6 in a single step.
Porting of all necessary DHCPv4 options to DHCPv6 would require Porting of all necessary DHCPv4 options to DHCPv6 would require
ongoing development work, re-implementing existing DHCPv4 ongoing development work, re-implementing existing DHCPv4
functionality in DHCPv6. This will result in having legacy DHCPv4 functionality in DHCPv6. This will result in having legacy DHCPv4
options in DHCPv6, which will no longer be useful once IPv4 is options in DHCPv6, which will no longer be useful once IPv4 is
completely abandoned. completely abandoned.
Therefore, the DHCPv6 approach is not suitable for delivering IPv4 Therefore, the DHCPv6 approach is not appropriate for delivering IPv4
configuration parameters in an efficient, ongoing manner. configuration parameters.
The dynamic leasing of IPv4 addresses is fundamental to the efficient The dynamic leasing of IPv4 addresses is fundamental to the efficient
use of remaining IPv4 resources. This will become increasingly use of remaining IPv4 resources. This will become increasingly
important in the future, so a mechanism which supports this is important in the future, so a mechanism which supports this is
necessary. DHCPv6 + Stateless DHCPv4oSW does not provide this necessary. DHCPv6 + Stateless DHCPv4oSW does not provide this
function and so is not recommended. function and so is not recommended.
The DHCPv4o6 approach requires a DHCPv4 server (with DHCPv4o6 The DHCPv4o6 approach requires a DHCPv4 server (with DHCPv4o6
functionality) for all deployment scenarios, even when DHCPv4 functionality) for all deployment scenarios, even when DHCPv4
specific functionality (e.g. sending DHCPv4 options) is not required specific functionality (e.g. sending DHCPv4 options) is not required
skipping to change at page 15, line 30 skipping to change at page 15, line 30
in Section 23 of [RFC3315]. in Section 23 of [RFC3315].
7.3. DHCPv6+DHCPv4oSW 7.3. DHCPv6+DHCPv4oSW
There is currently no document describing this mechanism, so no There is currently no document describing this mechanism, so no
security considerations have been documented. security considerations have been documented.
7.4. DHCPv4oDHCPv6 7.4. DHCPv4oDHCPv6
Security considerations associated with this approach are described Security considerations associated with this approach are described
in Section 11 of [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. in [I-D.ietf-dhc-dhcpv4-over-dhcpv6].
8. Acknowledgements 8. Acknowledgements
Thanks to Ted Lemon, Tomek Mrugalski, Ole Troan, Bernie Volz and Thanks to Ted Lemon, Tomek Mrugalski, Ole Troan, Bernie Volz and
Francis Dupont for their input and reviews. Francis Dupont for their input and reviews.
9. Informative References 9. Informative References
[I-D.ietf-dhc-dhcpinform-clarify] [I-D.ietf-dhc-dhcpinform-clarify]
Hankins, D., "Dynamic Host Configuration Protocol Hankins, D., "Dynamic Host Configuration Protocol
DHCPINFORM Message Clarifications", draft-ietf-dhc- DHCPINFORM Message Clarifications", draft-ietf-dhc-
dhcpinform-clarify-06 (work in progress), October 2011. dhcpinform-clarify-06 (work in progress), October 2011.
[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", draft-ietf-dhc- Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc-
dhcpv4-over-dhcpv6-04 (work in progress), January 2014. dhcpv4-over-dhcpv6-09 (work in progress), June 2014.
[I-D.ietf-dhc-dhcpv4-over-ipv6] [I-D.ietf-dhc-dhcpv4-over-ipv6]
Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4 Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4
over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-08 over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-09
(work in progress), October 2013. (work in progress), April 2014.
[I-D.ietf-softwire-lw4over6] [I-D.ietf-softwire-lw4over6]
Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
I. Farrer, "Lightweight 4over6: An Extension to the DS- I. Farrer, "Lightweight 4over6: An Extension to the DS-
Lite Architecture", draft-ietf-softwire-lw4over6-06 (work Lite Architecture", draft-ietf-softwire-lw4over6-10 (work
in progress), February 2014. in progress), June 2014.
[I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP)", draft-ietf-softwire-map-10
(work in progress), January 2014.
[I-D.ietf-softwire-map-dhcp] [I-D.ietf-softwire-map-dhcp]
Mrugalski, T., Troan, O., Dec, W., Bao, C., Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng,
for configuration of Softwire Address and Port Mapped "DHCPv6 Options for configuration of Softwire Address and
Clients", draft-ietf-softwire-map-dhcp-06 (work in Port Mapped Clients", draft-ietf-softwire-map-dhcp-07
progress), November 2013. (work in progress), March 2014.
[I-D.ietf-softwire-map-t] [I-D.ietf-softwire-map-t]
Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and
T. Murakami, "Mapping of Address and Port using T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", draft-ietf-softwire-map-t-05 (work Translation (MAP-T)", draft-ietf-softwire-map-t-05 (work
in progress), February 2014. in progress), February 2014.
[I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP)", draft-ietf-softwire-map-10
(work in progress), January 2014.
[I-D.mrugalski-softwire-dhcpv4-over-v6-option] [I-D.mrugalski-softwire-dhcpv4-over-v6-option]
Mrugalski, T. and P. Wu, "Dynamic Host Configuration Mrugalski, T. and P. Wu, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for DHCPv4 over IPv6 Protocol for IPv6 (DHCPv6) Option for DHCPv4 over IPv6
Endpoint", draft-mrugalski-softwire- Endpoint", draft-mrugalski-softwire-dhcpv4-over-
dhcpv4-over-v6-option-01 (work in progress), September v6-option-01 (work in progress), September 2012.
2012.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, [RFC5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp,
"DHCP Server Identifier Override Suboption", RFC 5107, "DHCP Server Identifier Override Suboption", RFC 5107,
 End of changes. 19 change blocks. 
42 lines changed or deleted 39 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/