draft-ietf-dhc-v4configuration-03.txt   draft-ietf-dhc-v4configuration-04.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: June 9, 2014 Deutsche Telekom AG Expires: July 19, 2014 Deutsche Telekom AG
December 06, 2013 January 15, 2014
Provisioning IPv4 Configuration Over IPv6 Only Networks Provisioning IPv4 Configuration Over IPv6 Only Networks
draft-ietf-dhc-v4configuration-03 draft-ietf-dhc-v4configuration-04
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 47 skipping to change at page 1, line 47
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 June 9, 2014. This Internet-Draft will expire on July 19, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview of IPv4 Parameter Configuration Approaches . . . 4 1.1. Overview of IPv4 Parameter Configuration Approaches . . . 4
1.2. DHCPv4o6 Based Provisioning - Functional Overview . . . . 5 1.2. DHCPv4o6 Based Provisioning - Functional Overview . . . . 5
1.3. DHCPv6 Based Provisioning - Functional Overview . . . . . 6 1.3. DHCPv6 Based Provisioning - Functional Overview . . . . . 6
1.4. DHCPv6 + Stateless DHCPv4oSW Based Provisioning - 1.4. DHCPv6 + Stateless DHCPv4oSW Based Provisioning -
Functional Overview . . . . . . . . . . . . . . . . . . . 6 Functional Overview . . . . . . . . . . . . . . . . . . . 6
1.5. DHCPv4oSW Based Provisioning - Functional Overview . . . 7 1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview . 7
1.6. DHCPv4oDHCPv6 Based Provisioning - Functional Overview . 8 2. Requirements for the Solution Evaluation . . . . . . . . . . 8
2. Requirements for the Solution Evaluation . . . . . . . . . . 9 3. Comparison of the Five Approaches . . . . . . . . . . . . . . 9
3. Comparison of the Five Approaches . . . . . . . . . . . . . . 10 3.1. DHCPv4o6 Based Provisioning . . . . . . . . . . . . . . . 9
3.1. DHCPv4o6 Based Provisioning . . . . . . . . . . . . . . . 10 3.1.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. DHCPv6 Based Provisioning . . . . . . . . . . . . . . . . 11 3.2. DHCPv6 Based Provisioning . . . . . . . . . . . . . . . . 10
3.2.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. DHCPv6 + Stateless DHCPv4oSW Based Provisioning . . . . . 12 3.3. DHCPv6 + Stateless DHCPv4oSW Based Provisioning . . . . . 11
3.3.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. DHCPv4oSW Based Provisioning . . . . . . . . . . . . . . 13 3.4. DHCPv4oSW Based Provisioning . . . . . . . . . . . . . . 12
3.4.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. DHCPv4oDHCPv6 Based Provisioning . . . . . . . . . . . . 14 3.5. DHCPv4oDHCPv6 Based Provisioning . . . . . . . . . . . . 13
3.5.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 14 3.5.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 14 3.5.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. Transporting Unmodified DHCPv4 Messages over an IPv6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. DHCPv4oIPv6 . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Combined Hub and DHCPv4 Relay Required Functionality . . 14
6.2. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.3. DHCPv6+DHCPv4oSW . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.4. DHCPv4oSW . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. DHCPv4oIPv6 . . . . . . . . . . . . . . . . . . . . . . . 15
6.5. DHCPv4oDHCPv6 . . . . . . . . . . . . . . . . . . . . . . 16 7.2. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 7.3. DHCPv6+DHCPv4oSW . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.4. DHCPv4oDHCPv6 . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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 IPv4 Internet and other provide customers with access to the IPv4 Internet and other
IPv4-only services. IPv4 over IPv6 tunneling / translation IPv4-only services. IPv4 over IPv6 tunneling / translation
mechanisms are an obvious example of this, such as the ones described mechanisms are an obvious example of this, such as the ones described
in: 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-map-t] o [I-D.ietf-softwire-map-t]
In todays home networks, each residential user is allocated a single In today's home networks, each residential user is allocated a single
global IPv4 address which is used for NAT44. Decentralizing NAT44 global IPv4 address which is used for NAT44. Decentralizing NAT44
allows for much better scaling and, when combined with stateless allows for much better scaling and, when combined with stateless
network functions, can simplify redundancy and logging. This results network functions, can simplify redundancy and logging. This results
in the need to provision a number of configuration parameters to the in the need to provision a number of configuration parameters to the
CPE, such as the external public IPv4 address and a restricted port- CPE, such as the external public IPv4 address and a restricted port-
range to use for NAT. Other parameters may also be necessary, range to use for NAT. Other parameters may also be necessary,
depending on the underlying transport technology that is in use. In depending on the underlying transport technology that is in use. In
IPv4 only networks, DHCPv4 has often been used to provide IPv4 IPv4 only networks, DHCPv4 has often been used to provide IPv4
configuration, but in an IPv6 only network, DHCPv4 messages cannot be configuration, but in an IPv6 only network, DHCPv4 messages cannot be
transported natively. transported natively without either IPv6 encapsulation or
translation.
DHCPv4 messages can be transported, unmodified, over a broadcast
capable link-layer, depending on the underlying IPv4 in IPv6
technology, network topology and DHCPv4 client capabilities. A
functional description of how unmodified DHCPv4 can be used is
provided in Section 5. This approach is RECOMMENDED for service
providers whose network and clients can support this DHCPv4
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), DHCPv6 based address leasing or additional IPv4 configuration), DHCPv6 based
approaches (e.g. [I-D.ietf-softwire-map-dhcp]) may provide a suitable approaches (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
parameters in IPv6 only networks, a suitable approach must not be parameters in IPv6 only networks, a suitable approach must not be
limited to only supporting softwires configuration or be reliant on limited to only supporting softwires configuration or be reliant on
specific underlying IPv4 over IPv6 architectures or mechanisms. specific underlying IPv4 over IPv6 architectures or mechanisms.
This document describes and compares five different methods which This document describes and compares four different methods which
have been proposed as solutions to 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
The following approaches for transporting IPv4 configuration The following approaches for transporting IPv4 configuration
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 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 DHCPv6 + Stateless DHCPv4oSW. to as DHCPv6 + Stateless DHCPv4oSW.
4. Use DHCPv4 over IPv4 messages transported over a broadcast 4. Use DHCPv4 format messages, transporting them within a new DHCPv6
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 methods At the time of writing, working examples of the first two methods
have been developed and successfully tested in several different have been developed and successfully tested in several different
operators networks. The fourth approach has been tested successfully operators networks. The remaining two methods are still theoretical.
in a lab environment. The remaining two methods are still
theoretical.
The following sections provide describe each of the approaches in The following sections provide describe each of the approaches in
more detail. 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. 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' (HCRA) function, which takes DHCPv4 implements a 'Host Client Relay' (HCRA) 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. A DHCPv6
is described in [I-D.mrugalski-softwire-dhcpv4-over-v6-option]. option for provisioning client's with this address is described in
[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 directly on the server and/or via an client. This interface may be directly on the server and/or via an
intermediary 'Transport Relay Agent' (TRA) device acting as the intermediary 'Transport Relay Agent' (TRA) device acting as the
gateway between the IPv4 and IPv6 domains. 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.
skipping to change at page 6, line 32 skipping to change at page 6, line 34
The protocol stack is as follows: The protocol stack is as follows:
DHCPv6/UDPv6/IPv6 DHCPv6/UDPv6/IPv6
1.4. DHCPv6 + Stateless DHCPv4oSW Based Provisioning - Functional 1.4. DHCPv6 + Stateless DHCPv4oSW Based Provisioning - Functional
Overview 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, e.g. using (if required) is carried out using DHCPv6, e.g. using
[I-D.ietf-softwire-map-dhcp]. Any additional IPv4 configuration [I-D.ietf-softwire-map-dhcp]. Any additional IPv4 configuration
parameters which are required are then provisioned using DHCPv4 parameters that are required are then provisioned using DHCPv4
messages transported within IPv6 in the configured softwire in the messages transported within IPv6 in the configured softwire in the
same manner as any other IPv4 based traffic. Broadcast based DHCPv4 same manner as any other IPv4 based traffic. Broadcast based DHCPv4
DHCPDISCOVER messages (necessary for IPv4 address assignment) can not DHCPDISCOVER messages (necessary for IPv4 address assignment) can not
be transported as they are not compatible with the softwire be transported as they are not compatible with the existing, unicast
architecture. based softwire architecture.
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 removed from the Lightweight 4over6 lwAFTR), the DHCPv4 message is extracted from the
softwire 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 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 would be server would be strictly DHCPINFORM/DHCPACK messages. These would be
used for the configuration of any additional IPv4 parameters. used for the configuration of any additional IPv4 parameters.
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 also required. This learn the IPv4 address of the DHCPv4 server is also required. This
could be via a well-known IPv4 address for the DHCPv4 server, a could be via a well-known IPv4 address for the DHCPv4 server, a
skipping to change at page 7, line 26 skipping to change at page 7, line 30
The protocol stack used for obtaining an IPv4 address and source The protocol stack used for obtaining an IPv4 address and source
ports (if required) is as follows: ports (if required) is as follows:
DHCPv6/UDPv6/IPv6 DHCPv6/UDPv6/IPv6
The protocol stack used for obtaining additional IPv4 configuration The protocol stack used for obtaining additional IPv4 configuration
is as follows: is as follows:
DHCPv4/UDPv4/IPv4/IPv6 DHCPv4/UDPv4/IPv4/IPv6
1.5. DHCPv4oSW Based Provisioning - Functional Overview 1.5. DHCPv4oDHCPv6 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. It differs from stateless
DHCPv6+DHCPv4oSW in that it is capable of supporting all DHCPv4
message types and is not limited solely to DHCPINFORM/DHCPACK
messages. This means that it is also suitable the assignment of IPv4
addresses as well as other DHCPv4 options.
Functionally, a DHCPv4 client operates 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
transported. 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. This allows
broadcast DHCPDISCOVER/DHCPREQUEST messages to be decapsulated and
forwarded to the DHCPv4 server. If the concentrator 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.
A 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 UDPv4 DHCP
client port (68) would not be available. This problem could be
resolved using one of the following two methods:
o The DHCPv4oSW client is updated to source BOOTP/DHCP requests
using a port taken from the client's allocated range. Likewise,
the DHCPv4oSW server must use the L4 source port from a client's
message as the destination port for the response.
o The DHCP Server Identifier Override Suboption described in
[RFC5107] could be used to direct all DHCPv4 messages through the
DHCPv4 relay. As option 82 is being used to identify the
destination IPv6 address for messages from the DHCPv4 server to
the client, the L4 destination port is not necessary for the
lookup process and could be left unchanged.
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 transporting DHCPv4 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes transporting DHCPv4
messages within two new DHCPv6 messages types: BOOTREQUESTV6 and messages within two new DHCPv6 messages types: BOOTREQUESTV6 and
BOOTREPLYV6. These new messages types must be implemented in both BOOTREPLYV6. These new messages types must be implemented in both
the DHCPv4oDHCPv6 client and server. the 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 10, line 10 skipping to change at page 9, line 10
specific requirements. specific requirements.
7. Not restricted to specific IPv4 over IPv6 transport mechanisms or 7. Not restricted to specific IPv4 over IPv6 transport mechanisms or
architectures. architectures.
3. Comparison of the Five Approaches 3. Comparison of the Five Approaches
The table below provides a comparative evaluation showing how the The table below provides a comparative evaluation showing how the
different approaches meet the solution requirements described above. different approaches meet the solution requirements described above.
+-------+----------+--------+-----------+-----------+---------------+ +--------+----------+--------+----------------------+---------------+
| Req. | DHCPv4o6 | DHCPv6 | DHCPv6 + | DHCPv4oSW | DHCPv4oDHCPv6 | | Req. | DHCPv4o6 | DHCPv6 | DHCPv6 + Stateless | DHCPv4oDHCPv6 |
| No. | | | Stateless | | | | No. | | | DHCPv4oSW | |
| | | | DHCPv4oSW | | | +--------+----------+--------+----------------------+---------------+
+-------+----------+--------+-----------+-----------+---------------+ | 1 | No | Yes | No | Yes |
| 1 | No | Yes | No | Yes | Yes | | 2 | Yes | No | Yes | Yes |
| 2 | Yes | No | Yes | Yes | Yes | | 3 | Yes | No | No | Yes |
| 3 | Yes | No | No | Yes | Yes | | 4 | Yes | No | Yes | Yes |
| 4 | Yes | No | Yes | Yes | Yes | | 5 | Yes | No | Yes | Yes |
| 5 | Yes | No | Yes | Yes | Yes | | 6 | No | No | Yes | Yes |
| 6 | No | No | Yes | Yes | Yes | | 7 | Yes | Yes | No | Yes |
| 7 | Yes | Yes | No | No | Yes | +--------+----------+--------+----------------------+---------------+
+-------+----------+--------+-----------+-----------+---------------+
Table 1: Approach Comparison Table 1: Approach Comparison
The following sections of the document provide more detail on the The following sections of the document provide more detail on the
pros and cons of each of the approaches. pros and cons of each of the approaches.
3.1. DHCPv4o6 Based Provisioning 3.1. DHCPv4o6 Based Provisioning
3.1.1. Pros 3.1.1. Pros
skipping to change at page 13, line 11 skipping to change at page 12, line 11
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 be application for this functionality at the moment, this may not be
the case in the future, meaning another solution may be required. the case in the future, meaning another solution may be required.
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 the DHCPINFORM/DHCPACK DHCPv4 message types are 7. As only the DHCPINFORM/DHCPACK DHCPv4 message types are
supported, dynamic IPv4 address leasing (using DHCPDISCOVER supported, dynamic IPv4 address leasing (using DHCPDISCOVER
messages) can not be used. messages) cannot be used.
8. Restricted to underlying hub-and-spoke IPv4 over IPv6 8. Restricted to underlying hub-and-spoke IPv4 over IPv6
architectures. The 'hub' is necessary for the location of the architectures. The 'hub' is necessary for the location of the
DHCPv4 relay, as all traffic must pass through it. An underlying DHCPv4 relay, as all traffic must pass through it. An underlying
mesh architecture does not have such a location to deploy the mesh architecture does not have such a location to deploy the
relay function. relay function.
9. The approach is unproven as no existing implementations exist. 9. The approach is unproven as no existing implementations exist.
3.4. DHCPv4oSW Based Provisioning 3.4. DHCPv4oSW Based Provisioning
skipping to change at page 15, line 16 skipping to change at page 14, line 16
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
by the operator. by the operator.
DHCPv4o6 requires that there is a tunnel concentrator, or similar
'hub' in the underlying architecture so that a DHCP relay can be
deployed. This does not meet Requirement 7.
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. Transporting Unmodified DHCPv4 Messages over an IPv6 Link Layer
This document makes no request of IANA. DHCPv4 can be transported across a broadcast capable link layer, such
as a softwire. Functionally, a DHCPv4 client operates 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 transported. The DHCPv4 message flow is then
the same as described in section 3.1 of [RFC2131].
For an unmodified DHCPv4 client to function over an IPv6 native
network, the underlying IPv4 over IPv6 architecture must be based on
a point-to-point link between the client and a central point (i.e. a
hub or tunnel concentrator) which all client DHCPv4 broadcast
messages will pass through. This hub must function as either the
DHCPv4 server or a DHCPv4 relay. The relay forwards broadcast DHCPv4
DHCPDISCOVER/DHCPREQUEST messages to a separate DHCPv4 server.
5.1. Combined Hub and DHCPv4 Relay Required Functionality
When the DHCPv4 relay function is co-located with the IPv4 in IPv6
hub function, there are some implementation considerations and
requirements that must be fulfilled. The following list describes
these.
1. Depending on the underlying IPv4 over IPv6 mechanism that the hub
is based upon, it may be necessary to modify the encapsulation/
decapsulation or IPv6/IPv4 translation packet validation policy
so that IPv4 payload packets sourced from the unspecified address
(0.0.0.0) are not dropped for broadcast DHCPv4 payload packets.
2. The DHCPv4 relay must use the DHCPv4 Relay Information Option
(option 82) Relay-ID sub-option (2) to convey the client's source
IPv6 address. This is used by the relay to route DHCPv4 response
packets sent by the DHCPv4 server to the correct client.
3. For some IPv4 in IPv6 transition technologies, a client may be
configured with an IPv4 address which is shared by other clients.
In these cases, clients using a single IPv4 address are
differentiated using the combination of the IPv4 address and a
range of restricted layer 4 source ports unique to each client
(used for NAPT). The DHCPv4 client L4 port (68) must not be
provisioned to any client for NAPT use.
4. The DHCPv4 relay must implement the Server Identifier Override
Suboption described in [RFC5107] to direct all DHCPv4 messages
through the DHCPv4 relay. As option 82 is being used to identify
the destination IPv6 address for messages from the DHCPv4 server
to the client, the L4 destination port is not required for the
return path lookup process and is left unchanged as port 68.
6. IANA Considerations
This document does not make any request from 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 7. Security Considerations
The following sections provide pointers to the documented security The following sections provide pointers to the documented security
considerations associated with each approach. considerations associated with each approach.
6.1. DHCPv4oIPv6 7.1. DHCPv4oIPv6
Security considerations associated with this approach are described Security considerations associated with this approach are described
in Section 8 of [I-D.ietf-dhc-dhcpv4-over-ipv6]. in Section 8 of [I-D.ietf-dhc-dhcpv4-over-ipv6].
6.2. DHCPv6 7.2. DHCPv6
Security considerations associated with this approach are described Security considerations associated with this approach are described
in Section 23 of [RFC3315]. in Section 23 of [RFC3315].
6.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.
6.4. DHCPv4oSW 7.4. DHCPv4oDHCPv6
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 Security considerations associated with this approach are described
in Section 10 of [RFC3315]. in Section 10 of [RFC3315].
7. Acknowledgements 8. Acknowledgements
Thanks to Ted Lemon, Tomek Mrugalski, Ole Troan and Francis Dupont Thanks to Ted Lemon, Tomek Mrugalski, Ole Troan and Francis Dupont
for their input and reviews. for their input and reviews.
8. References 9. References
8.1. Normative References 9.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 9.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-02 (work in progress), October 2013. dhcpv4-over-dhcpv6-03 (work in progress), November 2013.
[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-08
(work in progress), October 2013. (work in progress), October 2013.
[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-03 (work Lite Architecture", draft-ietf-softwire-lw4over6-03 (work
skipping to change at page 17, line 19 skipping to change at page 17, line 14
[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-04 (work Translation (MAP-T)", draft-ietf-softwire-map-t-04 (work
in progress), September 2013. in progress), September 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-08 with Encapsulation (MAP)", draft-ietf-softwire-map-09
(work in progress), August 2013. (work in progress), December 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 [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,
February 2008. February 2008.
 End of changes. 35 change blocks. 
144 lines changed or deleted 139 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/