draft-ietf-dhc-v4configuration-01.txt   draft-ietf-dhc-v4configuration-02.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: November 29, 2013 Deutsche Telekom AG Expires: April 03, 2014 Deutsche Telekom AG
May 28, 2013 September 30, 2013
Provisioning IPv4 Configuration Over IPv6 Only Networks Provisioning IPv4 Configuration Over IPv6 Only Networks
draft-ietf-dhc-v4configuration-01 draft-ietf-dhc-v4configuration-02
Abstract Abstract
As IPv6 becomes more widely adopted, some service providers are As IPv6 becomes more widely adopted, some service providers are
taking the approach of deploying IPv6 only networks, without dual- taking the approach of deploying IPv6 only networks, without dual-
stack functionality for IPv4. However, access to IPv4 based services stack functionality for IPv4. However, access to IPv4 based services
is still an ongoing requirement and approaches such as IPv4-in-IPv6 is still an ongoing requirement and approaches such as IPv4-in-IPv6
softwire tunnels are being developed to meet this need. softwire tunnels are being developed to meet this need.
In order to provision end-user's hosts with the necessary IPv4 In order to provision end-user's hosts with the necessary IPv4
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 November 29, 2013. This Internet-Draft will expire on April 03, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview of IPv4 Parameter Configuration Approaches . . . 3 1.1. Overview of IPv4 Parameter Configuration Approaches . . . 4
1.2. DHCPv4o6 Based Provisioning - Functional Overview . . . . 4 1.2. DHCPv4o6 Based Provisioning - Functional Overview . . . . 4
1.3. DHCPv6 Based Provisioning - Functional Overview . . . . . 5 1.3. DHCPv6 Based Provisioning - Functional Overview . . . . . 5
1.4. DHCPv4oSW Based Provisioning - Functional Overview . . . 5 1.4. DHCPv6+DHCPv4oSW Based Provisioning - Functional Overview 6
1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview . 6 1.5. DHCPv4oSW Based Provisioning - Functional Overview . . . 7
2. Requirements for the Solution Evaluation . . . . . . . . . . 7 1.6. DHCPv4oDHCPv6 Based Provisioning - Functional Overview . 7
3. Comparison of the Four Approaches . . . . . . . . . . . . . . 8 2. Requirements for the Solution Evaluation . . . . . . . . . . 8
3.1. DHCPv6 Based Provisioning . . . . . . . . . . . . . . . . 8 3. Comparison of the Five Approaches . . . . . . . . . . . . . . 9
3.1.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. DHCPv6 Based Provisioning . . . . . . . . . . . . . . . . 10
3.1.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. DHCPv4o6 Based Provisioning . . . . . . . . . . . . . . . 9 3.1.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. DHCPv4o6 Based Provisioning . . . . . . . . . . . . . . . 10
3.2.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. DHCPv4oSW Based Provisioning . . . . . . . . . . . . . . 10 3.2.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. DHCPv6+DHCPv4oSW Based Provisioning . . . . . . . . . . . 11
3.3.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. DHCPv4oDHCPv6 Based Provisioning . . . . . . . . . . . . 11 3.3.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4. DHCPv4oSW Based Provisioning . . . . . . . . . . . . . . 12
3.4.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 3.5. DHCPv4oDHCPv6 Based Provisioning . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 3.5.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 3.5.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. DHCPv4oIPv6 . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. DHCPv6+DHCPv4oSW . . . . . . . . . . . . . . . . . . . . 15
6.4. DHCPv4oSW . . . . . . . . . . . . . . . . . . . . . . . . 15
6.5. DHCPv4oDHCPv6 . . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
A service provider with an IPv6-only network must also be able to A service provider with an IPv6-only network must also be able to
provide customers with access to the Internet and other services over provide customers with access to the Internet and other services over
IPv4. Softwire based IPv4-in-IPv6 tunneling mechanisms are an IPv4. Softwire based IPv4-in-IPv6 tunneling mechanisms are an
obvious example of this, such as the ones described in: obvious example of this, such as the ones described in:
o [I-D.ietf-softwire-lw4over6] o [I-D.ietf-softwire-lw4over6]
o [I-D.ietf-softwire-map] o [I-D.ietf-softwire-map]
o [I-D.ietf-softwire-unified-cpe] o [I-D.ietf-softwire-unified-cpe]
A general trend here is to relocate NAT44 functionality and IPv4 A general trend here is to relocate NAT44 functionality and IPv4
address sharing from the centralized tunnel concentrator to the CPE address sharing from the centralized tunnel concentrator to the CPE
in order to achieve better scalability. This results in the need to in order to achieve better scalability. This results in the need to
provision a number of configuration parameters to the CPE, such as provision a number of configuration parameters to the CPE, such as
the external public IPv4 address and a restricted port-range to use the external public IPv4 address and a restricted port-range to use
for NAT. for NAT. These parameters are pre-requisites for successfully
configuring the client for providing IPv4 based connectivity.
In order to configure customer's devices for softwire functionality, In order to configure customer's devices for softwire functionality,
a dynamic provisioning mechanism is necessary. In IPv4 only a dynamic provisioning mechanism is necessary. In IPv4 only
networks, DHCPv4 has often been used to provide configuration, but in networks, DHCPv4 has often been used to provide IPv4 configuration,
an IPv6 only network, DHCPv4 messages cannot be transported natively. but in an IPv6 only network, DHCPv4 messages cannot be transported
natively.
Although softwire mechanisms are currently the only use-case for dhcp Although IPv4-in-IPv6 softwire tunnel clients are currently the only
based configuration of IPv4 parameters in IPv6 only networks, a use-case for DHCP based configuration of IPv4 parameters in IPv6 only
suitable approach must not be limited to only supporting softwire networks, a suitable approach must not be limited to only supporting
configuration. the configuration of softwires or other specific underlying IPv4 over
IPv6 architectures or mechanisms. DHCPv4 options may also need to be
conveyed to clients for configuring IPv4 based services, e.g. SIP
server addresses.
This document compares four different approaches which have been This document describes and compares five different methods which
proposed for resolving this problem. have been proposed as solutions to this problem.
1.1. Overview of IPv4 Parameter Configuration Approaches 1.1. Overview of IPv4 Parameter Configuration Approaches
In order to resolve the problem described above, the following The following approaches for transporting IPv4 configuration
approaches for transporting IPv4 configuration parameters have been parameters over IPv6 only networks have been suggested:
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 with new options for IPv4 configuration, such as 2. Extend DHCPv6 with new options for IPv4 configuration, such as
[I-D.ietf-softwire-map-dhcp] describes. [I-D.ietf-softwire-map-dhcp] describes.
3. Use DHCPv6 as above for external IPv4 address and source port 3. Use DHCPv6 as above for external IPv4 address and source port
configuration. Use DHCPv4 over IPv4 messages within an IPv6 configuration. Use DHCPv4 over IPv4 messages within an IPv6
softwire for configuring additional parameters. This is referred softwire for configuring additional parameters. This is referred
to as DHCPv4oSW. to as DHCPv6+DHCPv4oSW.
4. Use DHCPv4 format messages, transporting them within a new DHCPv6 4. Use DHCPv4 over IPv4 messages transported over a broadcast
capable IPv4overIPv6 transport (e.g. a softwire) for all IPv4
configuration including the external IPv4 address and source port
configuration. This is referred to as DHCPv4oSW.
5. 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 approaches At the time of writing, working examples of the first two approaches
have been developed and successfully tested in several different have been developed and successfully tested in several different
operators networks. The third and fourth methods are still operators networks. The fourth approach has been tested successfully
in a lab environment. The remaining two methods are still
theoretical. theoretical.
The following sections provide more detail for each approach. The following sections provide describe each of the approaches in
more 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. In initiate and exchange DHCPv4 messages with the DHCPv4 server. In
order adapt this to an IPv6-only network, an existing DHCPv4 client order adapt this to an IPv6-only network, an existing DHCPv4 client
implements a 'Client Relay' (CRA) function, which takes DHCPv4 implements a 'Client Relay' (CRA) function, which takes DHCPv4
messages and puts them into UDPv6 and IPv6. messages and puts them into UDPv6 and IPv6.
As the mechanism involves unicast based communications, the IPv6 As the mechanism involves unicast based communications, the IPv6
address of the server must be provisioned to the client. This option address of the server must be provisioned to the client. This option
is described in [I-D.mrugalski-softwire-dhcpv4-over-v6-option]. is described in [I-D.mrugalski-softwire-dhcpv4-over-v6-option].
The DHCPv4o6 server must either provide an IPv6 interface to the The DHCPv4o6 server must provide an IPv6 interface to the client.
client, or an intermediary 'Transport Relay Agent' device can act as This interface may be directly on the server and/or via an
the gateway between the IPv4 and IPv6 domains. intermediary 'Transport Relay Agent' device can act as the gateway
between the IPv4 and IPv6 domains.
For the dynamic allocation of IPv4 addresses, the DHCPv4o6 server For the dynamic allocation of IPv4 addresses, the DHCPv4 server needs
needs to be extended to support the new functionality, such as to be extended to support the new DHCPv4o6 functionality, such as the
storing the IPv6 address of DHCPv4o6 clients. The CRA6ADDR option storing the IPv6 address of DHCPv4o6 clients and implementing the
must also be implemented. 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 CRA on the host and the egress of the IPv6-only transport domain--the CRA on the host and the
TRA or TSV on the server. As a result, this approach has sometimes TRA or TSV on the server. As a result, this approach has sometimes
been referred to as a tunneling approach. However, relay agent been referred to as a tunneling approach. However, relay agent
encapsulation is not a tunnel, since it carries only DHCP traffic; it encapsulation is not a tunnel, since it carries only DHCP traffic; it
would be more accurate to describe it as an encapsulation. would be more accurate to describe it as an encapsulation based
transport.
It is worth noting that there is no technical reason for using relay It is worth noting that there is no technical reason for using relay
encapsulation for DHCPv4o6; this approach was taken because the encapsulation for DHCPv4o6; this approach was taken because the
authors of the draft originally imagined that it might be used to authors of the draft originally imagined that it might be used to
provide configuration information for an unmodified DHCPv4 client. provide configuration information for an unmodified DHCPv4 client.
However, this turns out not to be a viable approach: in order for However, this turns out not to be a viable approach: in order for
this to work, there would have to be IPv4 routing on the local link this to work, there would have to be IPv4 routing on the local link
to which the client is connected. In that case, there's no need for to which the client is connected. In that case, there's no need for
DHCPv4o6. DHCPv4o6.
skipping to change at page 5, line 19 skipping to change at page 5, line 46
stated in this document. stated in this document.
[I-D.ietf-dhc-dhcpv4-over-ipv6] decribes this solution in detail. [I-D.ietf-dhc-dhcpv4-over-ipv6] decribes this solution in detail.
The protocol stack is as follows: The protocol stack is as follows:
DHCPv4/UDPv6/IPv6 DHCPv4/UDPv6/IPv6
1.3. DHCPv6 Based Provisioning - Functional Overview 1.3. DHCPv6 Based Provisioning - Functional Overview
In this approach, DHCPv6 would be extended with new DHCPv6 options In this approach, DHCPv6 [RFC3315] would be extended with new DHCPv6
for configuring all IPv4 based services and functions. Any DHCPv4 options for configuring all IPv4 based services and functions, (i.e.
IPv4 address assignment and any necessary DHCPv4 options). DHCPv4
options needed by IPv4 clients connected to the IPV6 network are options needed by IPv4 clients connected to the IPV6 network are
updated as new DHCPv6 native options carrying IPv4 configuration updated as new DHCPv6 native options carrying IPv4 configuration
parameters. parameters. IPv4 address leasing would also need to be managed by
the DHCPv6 server.
At the time of writing, it is not known how many such options would At the time of writing, it is not known how many such options would
need to be ported from DHCPv4 to DHCPv6. need to be ported from DHCPv4 to DHCPv6.
An example of this approach is described in An example of this approach is described in
[I-D.ietf-softwire-map-dhcp], where a DHCPv6 message is used to [I-D.ietf-softwire-map-dhcp], where a DHCPv6 message is used to
convey the parameters necessary for IPv4 in IPv6 softwire convey the parameters necessary for IPv4 in IPv6 softwire
configuration. configuration.
The protocol stack is as follows: The protocol stack is as follows:
DHCPv6/UDPv6/IPv6 DHCPv6/UDPv6/IPv6
1.4. DHCPv4oSW Based Provisioning - Functional Overview 1.4. DHCPv6+DHCPv4oSW Based Provisioning - Functional Overview
In this approach, the configuration of IPv4 address and source ports In this approach, the configuration of IPv4 address and source ports
(if required) is carried out using DHCPv6 as described in section 1.3 (if required) is carried out using DHCPv6 as described in section 1.3
above. Any additional IPv4 configuration parameters which are above. Any additional IPv4 configuration parameters which are
required are then provisioned using a DHCPv4 messages transported required are then provisioned using a DHCPv4 messages transported
within IPv6 in the configured softwire in the same manner as any within IPv6 in the configured softwire in the same manner as any
other IPv4 based traffic. other IPv4 based traffic. Broadcast based DHCPv4 DHCPDISCOVER
messages (necessary for IPv4 address assignment) can not be
transported as they are not compatible with the softwire
architecture.
On receipt at the tunnel concentrator (e.g. MAP Border Router or a On receipt at the tunnel concentrator (e.g. MAP Border Router or a
Lightweight 4over6 lwAFTR), the DHCPv4 message removed from the Lightweight 4over6 lwAFTR), the DHCPv4 message removed from the
softwire and forwarded to the DHCPv4 server in the same way as any softwire and forwarded to the DHCPv4 server in the same way as any
other IPv4 packet is handled. other IPv4 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), the messages exchanged between the and source ports (using DHCPv6 or a well-known IPv4 address for DS-
DHCPv4 client and server would be strictly DHCPINFORM/DHCPACK Lite clients), the messages exchanged between the DHCPv4 client and
messages, for the configuration of additional IPv4 parameters. server would be strictly DHCPINFORM/DHCPACK messages, for the
Broadcast based DHCPDISCOVER messages can not be transported as they configuration of additional IPv4 parameters.
are not compatible with the softwire architecture.
For this approach to function, a mechanism for the DHCPv4 client to For this approach to function, a mechanism for the DHCPv4 client to
learn the IPv4 address of the DHCPv4 server is needed. This could be learn the IPv4 address of the DHCPv4 server is needed. This could be
done by defining a well-known IPv4 address for the DHCPv4 server, done by defining a well-known IPv4 address for the DHCPv4 server,
implementing a DHCPv4 relay function within the tunnel concentrator implementing a DHCPv4 relay function within the tunnel concentrator
or other configuration methods. or other configuration methods.
From a transport perspective, the key difference between this method From a transport perspective, the key difference between this method
and DHCPv4o6 (described above) is that here, the DHCPv4 message is and DHCPv4o6 (described above) is that here, the DHCPv4 message is
put into UDPv4 and IPv4 and then put into the IPv6 softwire, instead put into UDPv4 and IPv4 and then put into the IPv6 softwire, instead
of directly placing the DHCPv4 message into UDPv6 and IPv6. of directly placing the DHCPv4 message into UDPv6 and IPv6.
Currently, this approach is only theoretical and does not have a Currently, this approach is only theoretical and does not have a
corresponding Internet Draft providing more detail. corresponding Internet Draft providing more detail.
The protocol stack that would be used for obtaining additional IPv4 The protocol stack used for obtaining an IPv4 address and source
configuraion is as follows: ports (if required) is as follows:
DHCPv6/UDPv6/IPv6
The protocol stack used for obtaining additional IPv4 configuration
is as follows:
DHCPv4/UDPv4/IPv4/IPv6 DHCPv4/UDPv4/IPv4/IPv6
1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview 1.5. DHCPv4oSW Based Provisioning - Functional Overview
[I-D.troan-dhc-dhcpv4osw] describes a method for complete client
configuration using DHCPv4 transported across a broadcast capable
link layer transport, such as a softwire. This differs from
DHCPv6+DHCPv4oSW in that it could support all DHCPv4 message types
and is not limited to just DHCPINFORM/DHCPACK messages. This means
that it can be used for the assignment of IPv4 addresses as well as
other DHCPv4 options.
This functions by running a DHCPv4 client on the link layer interface
(e.g. the softwire tunnel interface). As the link layer must support
broadcasts, DHCPDISCOVER and other broadcast DHCPv4 messages can be
supported. The DHCPv4 message flow is then the same as described in
section 3.1 of [RFC2131].
In this approach, either the tunnel concentrator must also be the
DHCPv4 server or it must act as a DHCPv4 relay so that the broadcast
DHCPDISCOVER/DHCPREQUEST messages can be decapsulated and forwarded
to the DHCPv4 server. If it is functioning as a relay, then the
DHCPv4 Relay Information Option (option 82) is used to convey the
client's source IPv6 address. This is also used by the relay for
routing return DHCPv4 packets.
The DHCPv4oSW client may be configured with a shared IPv4 address
with restricted layer 4 source ports. This will normally exclude the
well-known TCP/UDP ports in the range 0-1023, so the DHCPv4oSW client
must be updated to source BOOTP/DHCP requests from a port taken from
the range allocated to the client instead of UDP port 67. Likewise,
the DHCPv4oSW server must use the L4 source port from a client's
message as the destination port for the response.
The protocol stack used for obtaining DHCPv4 based configuration is:
DHCPv4/UDPv4/IPv4/IPv6
1.6. DHCPv4oDHCPv6 Based Provisioning - Functional Overview
[I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes the transport of DHCPv4 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes the transport of DHCPv4
messages within two new DHCPv6 messages types: BOOTREQUESTV6 and messages within two new DHCPv6 messages types: BOOTREQUESTV6 and
BOOTREPLYV6. These messages types must be implemented in both the BOOTREPLYV6. These messages types must be implemented in both the
DHCPv4oDHCPv6 client and server. DHCPv4oDHCPv6 client and server.
In this approach, the configuration of stateless IPv4 addresses and In this approach, the configuration of stateless IPv4 addresses and
source ports (if required) is carried out using DHCPv6 as described source ports (if required) is carried out using DHCPv6 as described
in section 1.3 above. Dynamic IPv4 addressing, and/or any additional in section 1.3 above. Dynamic IPv4 addressing, and/or any additional
IPv4 configuration, is provided using DHCPv4 messages carried IPv4 configuration, is provided using DHCPv4 messages carried
skipping to change at page 7, line 23 skipping to change at page 8, line 45
2. Requirements for the Solution Evaluation 2. Requirements for the Solution Evaluation
The following requirements have been defined for the evalution of the The following requirements have been defined for the evalution of the
different approaches: different approaches:
1. Minimize the amount of work necessary to implement the solution 1. Minimize the amount of work necessary to implement the solution
through re-use of existing standards and implementations as much through re-use of existing standards and implementations as much
as possible. as possible.
2. Provide a method of supporting all existing DHCPv4 options so 2. Provide a method of supporting all DHCPv4 options so that they
that they can be utilised without the need for further can be utilised without the need for further standardation.
standardation.
3. Allow for the dynamic leasing of IPv4 addresses to clients. This 3. Allow for the dynamic leasing of IPv4 addresses to clients. This
allows for more efficient use of limited IPv4 resources. allows for more efficient use of limited IPv4 resources.
4. Enable the separation of IPv4 and IPv6 host configuration 4. Enable the separation of IPv4 and IPv6 host configuration
infrastructure, i.e. independent DHCPv4 and DHCPv6 servers. infrastructure, i.e. independent DHCPv4 and DHCPv6 servers.
5. Avoid leaving legacy IPv4 options in DHCPv6. 5. Avoid leaving legacy IPv4 options in DHCPv6.
6. Provide a flexible architecture to give operators the option of 6. Provide a flexible architecture to give operators the option of
only deploying the functional elements necessary for their only deploying the functional elements necessary for their
specific requirements. specific requirements.
3. Comparison of the Four Approaches 7. Not restricted to specific IPv4 over IPv6 transport mechanisms or
architectures.
The table below shows a comparison of how the different approaches 8.
meet the solution requirements described above.
+----------+----------+--------+-----------+---------------+ 3. Comparison of the Five Approaches
| Req. No. | DHCPv4o6 | DHCPv6 | DHCPv4oSW | DHCPv4oDHCPv6 |
+----------+----------+--------+-----------+---------------+ The table below provides an evaluation comparison of how the
| 1 | No | Yes | No | Yes | different approaches meet the solution requirements described above.
| 2 | Yes | No | Yes | Yes |
| 3 | Yes | No | No | Yes | +------+----------+-------+----------------+----------+-------------+
| 4 | Yes | No | Yes | Yes | | Req. | DHCPv4o6 | DHCPv | DHCPv6+DHCPv4o | DHCPv4oS | DHCPv4oDHCP |
| 5 | Yes | No | Yes | Yes | | No. | | 6 | SW | W | v6 |
| 6 | No | No | Yes | Yes | +------+----------+-------+----------------+----------+-------------+
+----------+----------+--------+-----------+---------------+ | 1 | No | Yes | No | Yes | Yes |
| 2 | Yes | No | Yes | Yes | Yes |
| 3 | Yes | No | No | Yes | Yes |
| 4 | Yes | No | Yes | Yes | Yes |
| 5 | Yes | No | Yes | Yes | Yes |
| 6 | No | No | Yes | Yes | Yes |
| 7 | Yes | Yes | No | No | Yes |
+------+----------+-------+----------------+----------+-------------+
Table 1: Approach Comparison Table 1: Approach Comparison
The following sections of the document provide more details of the The following sections of the document provide more details of the
pros and cons relevant to each of the approaches. pros and cons relevant to each of the approaches.
3.1. DHCPv6 Based Provisioning 3.1. DHCPv6 Based Provisioning
3.1.1. Pros 3.1.1. Pros
skipping to change at page 9, line 9 skipping to change at page 10, line 37
relevance in the future will remain in DHCPv6 for the lifetime of relevance in the future will remain in DHCPv6 for the lifetime of
the protocol. the protocol.
3. Each time that a DHCPv4 option is ported to DHCPv6, all clients 3. Each time that a DHCPv4 option is ported to DHCPv6, all clients
and servers would need to be updated to implement the new option. and servers would need to be updated to implement the new option.
4. Does not provide an architecture for keeping IPv4 and IPv6 4. Does not provide an architecture for keeping IPv4 and IPv6
domains separated. domains separated.
5. Does not provide a mechanism for dynamic IPv4 address leasing. A 5. Does not provide a mechanism for dynamic IPv4 address leasing. A
DHCPv4 lease lifetime mechanism would need to be added to DHCPv6 DHCPv4 lease lifetime management mechanism would need to be added
for this. to DHCPv6 for this.
3.2. DHCPv4o6 Based Provisioning 3.2. DHCPv4o6 Based Provisioning
3.2.1. Pros 3.2.1. Pros
1. Once implemented, all existing DHCPv4 options will be available 1. Implemention makes all existing DHCPv4 options available with no
with no further ongoing development work necessary. further ongoing development work necessary.
2. IPv4 and IPv6 based provisioning can be separated from each other 2. IPv4 and IPv6 based provisioning can be separated from each other
if required, allowing flexibility in network design. if required, allowing flexibility in network design.
3. Easy to implement through minor adaptation of existing DHCPv4 3. Easy to implement through minor adaptation of existing DHCPv4
client/server code. client, relay and server code.
4. Simple, in that no additional functional elements are necessary 4. Simple, in that no additional functional elements are necessary
except the DHCPv4o6 client and server. The Transport Relay Agent except the DHCPv4o6 client relay and server. If a TSV is used,
is completely optional. then the TRA is not required.
5. Suitable for the provisioning of dynamic IPv4 configuration as 5. Suitable for the provisioning of dynamic IPv4 configuration as
the existing DHCPv4 leasing mechanism can be used. the existing DHCPv4 leasing mechanism can be used.
6. Implementations already exist, proving that the approach works. 6. Implementations already exist, proving that the approach works.
3.2.2. Cons 3.2.2. Cons
1. More complex, in that there are more new functional elements 1. More complex, in that there are more new functional elements
(CRA, DHCPv4o6 server and optionally TRA) within the architecture (CRA, DHCPv4o6 server and optionally TRA) within the architecture
than are necessary in DHCPv6 based provisioning. than are necessary in DHCPv6 based provisioning.
2. A new DHCPv6 option is necessary in order to provision the IPv6 2. A new DHCPv6 option is necessary in order to provision the IPv6
address of the DHCPv4 server to the end device. address of the DHCPv4 server to the end device.
3. For a Host CRA (HCRA), DHCPv4 client host needs to be updated to 3. The DHCPv4 client host needs to be updated to implement the IPv6
implement the IPv6 encapsulation and decapsulation function. encapsulation and decapsulation function (i.e An HCRA).
Otherwise a physically separate On-Link CRA (LCRA) functional Otherwise a separate On-Link CRA (LCRA) functional element must
element must be deployed. be deployed.
4. A DHCPv4 server must be deployed and maintained. 4. A DHCPv4 server must be deployed and maintained.
5. The DHCPv4 server needs to be updated to implement new DHCPv4o6 5. The DHCPv4 server needs to be updated to implement new DHCPv4o6
functionality. functionality.
3.3. DHCPv4oSW Based Provisioning 3.3. DHCPv6+DHCPv4oSW Based Provisioning
3.3.1. Pros 3.3.1. Pros
1. Once implemented, all existing DHCPv4 options will be be 1. Once implemented, all existing DHCPv4 options will be be
available with no further ongoing development work necessary. available with no further ongoing development work necessary.
2. Uses the existing DHCPv4 and DHCPv6 architectures in order to 2. Uses the existing DHCPv4 and DHCPv6 architectures in order to
provide IPv4 configuration in an IPv6 only environment. provide IPv4 configuration in an IPv6 only environment.
3. DHCPv4 and DHCPv6 based provisioning can be separated from each 3. DHCPv4 and DHCPv6 based provisioning can be separated from each
other if required, allowing flexibility in network design. other if required, allowing flexibility in network design.
3.3.2. Cons 3.3.2. Cons
1. More complex, in that there are more new functional elements 1. More complex, in that there are more new functional elements
within the architecture than are necessary in DHCPv6 based within the architecture than are necessary in DHCPv6 based
provisioning. provisioning.
2. IPv4 over IPv6 softwire approaches which distribute NAT to the 2. IPv4 over IPv6 softwire approaches that distribute NAT to the CPE
CPE and allow for IP address sharing (MAP-E & LW4o6) forbid the and allow for IP address sharing (MAP-E & LW4o6) forbid the use
use of reserved TCP/UDP ports (e.g. 0-1024). Every DHCPv4 of reserved TCP/UDP ports (e.g. 0-1024). Every DHCPv4 client
client sharing the same address needs to have a UDP listener sharing the same address needs to have a UDP listener running on
running on UDP port 68. To resolve this would require UDP port 68. To resolve this would require significant rework to
significant rework to either the softwire mechanisms and/or the either the softwire mechanisms and/or the DHCPv4 client
DHCPv4 client implementation. implementatioIn.
3. From the current specification, DHCPINFORM is not suitable for 3. From the current specification, DHCPINFORM is not suitable for
use over a softwire. Additional work, such as the development of use over a softwire. Additional work, such as the development of
'shims' would be necessary 'shims' would be necessary
4. The current DHCPINFORM specification has a number of unclear 4. The current DHCPINFORM specification has a number of unclear
points, such as those described in points, such as those described in
[I-D.ietf-dhc-dhcpinform-clarify]. Substantial work would be [I-D.ietf-dhc-dhcpinform-clarify]. Substantial work would be
required to resolve this. required to resolve this.
5. Links the deployment of IPv4 configuration over IPv6 to a 5. Links the deployment of IPv4 configuration over IPv6 to a
softwire implementation (e.g. requiring a softwire concentrator softwire implementation (e.g. requiring a softwire concentrator
to act as a DHCPv4 relay). Whilst softwires are the only to act as a DHCPv4 relay). Whilst softwires are the only
application for this functionality at the moment, this may not application for this functionality at the moment, this may not
always be the case. always be the case.
6. A new mechanism must be defined in order to provide the DHCPv4 6. A new mechanism must be defined in order to provide the DHCPv4
client with the IPv4 address of the DHCPv4 server so that unicast client with the IPv4 address of the DHCPv4 server so that unicast
DHCPINFORM messages can be sent. DHCPINFORM messages can be sent.
7. As only DHCPINFORM/DHCPACK DHCPv4 message types are supported, 7. As only DHCPINFORM/DHCPACK DHCPv4 message types are supported,
dynamic IPv4 address leasing (using DHCPDISCOVER messages) can dynamic IPv4 address leasing (using DHCPDISCOVER messages) can
not be used. not be used.
8. The approach is unproven as no existing implementations exist. 8. Restricted to underlying hub-and-spoke IPv4 over IPv6
architectures. The 'hub' is necessary for the location of the
DHCPv4 relay, as all traffic. An underlying mesh architecture
does not have such a location to deploy the relay.
3.4. DHCPv4oDHCPv6 Based Provisioning 9. The approach is unproven as no existing implementations exist.
3.4. DHCPv4oSW Based Provisioning
3.4.1. Pros 3.4.1. Pros
1. Once implemented, all existing DHCPv4 options will be be 1. Once implemented, all existing DHCPv4 options will be be
available with no further ongoing development work necessary. available with no further ongoing development work necessary.
2. Uses the existing DHCPv4 architecture in order to provide IPv4
configuration in an IPv6 only environment.
3. DHCPv4 and DHCPv6 based provisioning can be separated from each
other if required, allowing flexibility in network design.
3.4.2. Cons
1. Requires the DHCPv4 client, DHCPv4 server and softwire
concentrator (or other relaying device) to be modified.
2. Requires the DHCPv4 client and server to be updated to use
dynamic ports taken from the restricted port set allocated to the
client instead of the well-known DHCPv4 ports.
3. The DHCPv4 client must be modified to identify the properties of
the interface it is configuring and request parameters
accordingly (e.g. restricted port-sets cannot be used on Ethernet
transport interfaces but are allowed for a softwire transport)
4. May not be suitable for configuring translation based approaches
(e.g. MAP-T)
5. Restricted to underlying hub-and-spoke IPv4 over IPv6
architectures. The 'hub' is necessary for the location of the
DHCPv4 relay, as all traffic, including DHCPDISCOVER messages
will pass through it. An underlying mesh architecture does not
have such a location to deploy the relay.
3.5. DHCPv4oDHCPv6 Based Provisioning
3.5.1. Pros
1. Once implemented, all existing DHCPv4 options will be be
available with no further ongoing development work necessary.
2. Uses the existing DHCPv4 and DHCPv6 architectures in order to 2. Uses the existing DHCPv4 and DHCPv6 architectures in order to
provide IPv4 configuration in an IPv6 only environment. provide IPv4 configuration in an IPv6 only environment.
3. DHCPv4 and DHCPv6 based provisioning can be separated from each 3. DHCPv4 and DHCPv6 based provisioning can be separated from each
other if required, allowing flexibility in network design. other if required, allowing flexibility in network design.
4. Suitable for the provisioning of dynamic IPv4 configuration as 4. Suitable for the provisioning of dynamic IPv4 configuration as
the existing DHCPv4 leasing mechanism can be used. the existing DHCPv4 leasing mechanism can be used.
3.4.2. Cons 3.5.2. Cons
1. More complex, in that there are more new functional elements 1. More complex, in that there are more new functional elements
within the architecture than are necessary in DHCPv6 based within the architecture than are necessary in DHCPv6 based
provisioning. provisioning.
2. DHCPv6 clients needs to be updated to implement the new DHCPv6 2. DHCPv6 clients needs to be updated to implement the new DHCPv6
message types (BOOTPREQUESTv6 and BOOTPREPLYv6). message types (BOOTPREQUESTv6 and BOOTPREPLYv6).
3. The DHCPv6 server needs to be updated to implement new 3. The DHCPv6 server needs to be updated to implement new
DHCPv4oDHCPv6 message types and functionality. DHCPv4oDHCPv6 message types and functionality.
4. If separation of DHCPv4 and DHCPv6 provisioning infrastructure is 4. The approach is currently unproven as no existing implementations
required, DHCPv6 relay agents need to be updated to implement
dedicated forwarding destinations based on message type.
5. The approach is currently unproven as no existing implementations
exist. exist.
4. Conclusion 4. Conclusion
Whilst all of the approaches described here will require some Whilst all of the approaches described here will require some
development work in order to realize, it is clear from the above development work in order to realize, it is clear from the above
analysis that the most sustainable approach capitalizes on existing analysis that the most sustainable approach capitalizes on existing
DHCPv4 implementations and include them as new DHCPv6 message types. DHCPv4 implementations and include them as new DHCPv6 message types.
The main rationale for this is that it enables all of DHCPv4's The 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. existing 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
skipping to change at page 12, line 28 skipping to change at page 14, line 40
configuration parameters in an efficient, ongoing manner. configuration parameters in an efficient, ongoing manner.
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. DHCPv4oSW does not provide this function and so is not necessary. DHCPv4oSW does not provide this function and so is not
recommended. 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 is not required by the operator. specific functionality (e.g. sending DHCPv4 options) is not required
by the operator.
Therefore, this memo recommends DHCPv4oDHCPv6 Therefore, this memo recommends DHCPv4oDHCPv6
[I-D.ietf-dhc-dhcpv4-over-dhcpv6] as the best underlying approach for [I-D.ietf-dhc-dhcpv4-over-dhcpv6] as the best underlying approach for
provisioning IPv4 parameters over an IPv6 only network. provisioning IPv4 parameters over an IPv6 only network.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
6. Security Considerations 6. Security Considerations
The following sections provide pointers to the documented security
considerations associated with each approach.
6.1. DHCPv4oIPv6
Security considerations associated with this approach are described
in Section 8 of [I-D.ietf-dhc-dhcpv4-over-ipv6].
6.2. DHCPv6
Security considerations associated with this approach are described
in Section 23 of [RFC3315].
6.3. DHCPv6+DHCPv4oSW
There is currently no document describing this mechanism, so no
security considerations have been documented.
6.4. DHCPv4oSW
At the time of writing,[I-D.troan-dhc-dhcpv4osw] does not list any
security considerations.
6.5. DHCPv4oDHCPv6
Security considerations associated with this approach are described
in Section 10 of [RFC3315].
7. Acknowledgements 7. Acknowledgements
Thanks to Ted Lemon and Tomek Mrugalski for their input and reviews. Thanks to Ted Lemon, Tomek Mrugalski, Ole Troan and Francis Dupont
for their input and reviews.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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.
8.2. Informative References 8.2. 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-00 (work in progress), April 2013. dhcpv4-over-dhcpv6-01 (work in progress), July 2013.
[I-D.ietf-dhc-dhcpv4-over-ipv6] [I-D.ietf-dhc-dhcpv4-over-ipv6]
Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6 Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6
Transport", draft-ietf-dhc-dhcpv4-over-ipv6-06 (work in Transport", draft-ietf-dhc-dhcpv4-over-ipv6-07 (work in
progress), March 2013. progress), September 2013.
[I-D.ietf-softwire-lw4over6] [I-D.ietf-softwire-lw4over6]
Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the DS-Lite Farrer, "Lightweight 4over6: An Extension to the DS-Lite
Architecture", draft-ietf-softwire-lw4over6-00 (work in Architecture", draft-ietf-softwire-lw4over6-01 (work in
progress), April 2013. progress), July 2013.
[I-D.ietf-softwire-map-dhcp] [I-D.ietf-softwire-map-dhcp]
Mrugalski, T., Troan, O., Dec, W., Bao, C., Mrugalski, T., Deng, X., Troan, O., Bao, C., Dec, W., and
leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options l. leaf.yeh.sdo@gmail.com, "DHCPv6 Options for
for Mapping of Address and Port", draft-ietf-softwire-map- configuration of Softwire Address and Port Mapped
dhcp-03 (work in progress), February 2013. Clients", draft-ietf-softwire-map-dhcp-04 (work in
progress), July 2013.
[I-D.ietf-softwire-map] [I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP)", draft-ietf-softwire-map-06 with Encapsulation (MAP)", draft-ietf-softwire-map-08
(work in progress), May 2013. (work in progress), August 2013.
[I-D.ietf-softwire-unified-cpe] [I-D.ietf-softwire-unified-cpe]
Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 Boucadair, M., Farrer, I., Perreault, S., and S.
Softwire CPE", draft-ietf-softwire-unified-cpe-00 (work in Sivakumar, "Unified IPv4-in-IPv6 Softwire CPE", draft-
progress), March 2013. ietf-softwire-unified-cpe-01 (work in progress), May 2013.
[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-v6-option-01 (work in progress), September dhcpv4-over-v6-option-01 (work in progress), September
2012. 2012.
[I-D.troan-dhc-dhcpv4osw]
Troan, O., "DHCPv4 over A+P softwires", draft-troan-dhc-
dhcpv4osw-00 (work in progress), June 2013.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
Authors' Addresses Authors' Addresses
Branimir Rajtar Branimir Rajtar
Hrvatski Telekom Hrvatski Telekom
Zagreb Zagreb
Croatia Croatia
Email: branimir.rajtar@t.ht.hr Email: branimir.rajtar@t.ht.hr
Ian Farrer Ian Farrer
 End of changes. 54 change blocks. 
129 lines changed or deleted 282 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/