draft-ietf-dhc-v4configuration-04.txt   draft-ietf-dhc-v4configuration-05.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: July 19, 2014 Deutsche Telekom AG Expires: August 16, 2014 Deutsche Telekom AG
January 15, 2014 February 12, 2014
Provisioning IPv4 Configuration Over IPv6 Only Networks Provisioning IPv4 Configuration Over IPv6 Only Networks
draft-ietf-dhc-v4configuration-04 draft-ietf-dhc-v4configuration-05
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
necessary for such mechanisms, a number of different approaches have necessary for such mechanisms, a number of different approaches have
been proposed. This memo discusses each of the proposals, identifies been proposed. This memo discusses each of the proposals, identifies
the benefits and drawbacks and recommends a single approach as the the benefits and drawbacks and recommends approaches to be used as
basis for future deployment and development. the basis for future deployment and development.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 19, 2014. This Internet-Draft will expire on August 16, 2014.
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
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 . . . . 4
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. DHCPv4oDHCPv6 Based Provisioning - Functional Overview . 7 1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview . 7
2. Requirements for the Solution Evaluation . . . . . . . . . . 8 2. Requirements for the Solution Evaluation . . . . . . . . . . 8
3. Comparison of the Five Approaches . . . . . . . . . . . . . . 9 3. Comparison of the Four Approaches . . . . . . . . . . . . . . 9
3.1. DHCPv4o6 Based Provisioning . . . . . . . . . . . . . . . 9 3.1. DHCPv4o6 Based Provisioning . . . . . . . . . . . . . . . 9
3.1.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. DHCPv6 Based Provisioning . . . . . . . . . . . . . . . . 10 3.2. DHCPv6 Based Provisioning . . . . . . . . . . . . . . . . 10
3.2.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. DHCPv6 + Stateless DHCPv4oSW Based Provisioning . . . . . 11 3.3. DHCPv6 + Stateless DHCPv4oSW Based Provisioning . . . . . 11
3.3.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. DHCPv4oSW Based Provisioning . . . . . . . . . . . . . . 12 3.4. DHCPv4oDHCPv6 Based Provisioning . . . . . . . . . . . . 12
3.4.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. DHCPv4oDHCPv6 Based Provisioning . . . . . . . . . . . . 13
3.5.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Transporting Unmodified DHCPv4 Messages over an IPv6 5. Transporting Unmodified DHCPv4 Messages over an IPv6 Link
Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . 14 Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Combined Hub and DHCPv4 Relay Required Functionality . . 14 5.1. Combined Hub and DHCPv4 Relay Required Functionality . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7.1. DHCPv4oIPv6 . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. DHCPv4oIPv6 . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.3. DHCPv6+DHCPv4oSW . . . . . . . . . . . . . . . . . . . . 15 7.3. DHCPv6+DHCPv4oSW . . . . . . . . . . . . . . . . . . . . 15
7.4. DHCPv4oDHCPv6 . . . . . . . . . . . . . . . . . . . . . . 16 7.4. DHCPv4oDHCPv6 . . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Informative References . . . . . . . . . . . . . . . . . . . 15
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 today's 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 when compared
in the need to provision a number of configuration parameters to the to centralized Carrier Grade NAT architectures. This results in the
CPE, such as the external public IPv4 address and a restricted port- need to provision a number of configuration parameters to the CPE,
range to use for NAT. Other parameters may also be necessary, such as the external public IPv4 address and a restricted port-range
depending on the underlying transport technology that is in use. In to use for NAT. Other parameters may also be necessary, depending on
IPv4 only networks, DHCPv4 has often been used to provide IPv4 the underlying transport technology that is in use. In IPv4 only
configuration, but in an IPv6 only network, DHCPv4 messages cannot be networks, DHCPv4 has often been used to provide IPv4 configuration,
transported natively without either IPv6 encapsulation or but in an IPv6 only network, DHCPv4 messages cannot be transported
translation. natively without either IPv6 encapsulation or translation.
DHCPv4 messages can be transported, unmodified, over a broadcast DHCPv4 messages can be transported, unmodified, over a broadcast
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), DHCPv6 based address leasing or additional IPv4 configuration), a DHCPv6 based
approaches (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
parameters in IPv6 only networks, a suitable approach must not be parameters in IPv6 only networks, a suitable IPv4 provisioning
limited to only supporting softwires configuration or be reliant on solution should not be limited to only supporting the configuration
specific underlying IPv4 over IPv6 architectures or mechanisms. of softwires, or be bound to specific IPv4 over IPv6 architectures or
mechanisms. The solution needs to be flexible enough to support new
IPv4 over IPv6 technologies as they are developed.
This document describes and compares four 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 for external IPv4 address and source port
configuration. Use DHCPv4 over IPv4 messages within an IPv6 configuration (e.g. [I-D.ietf-softwire-map-dhcp]. Use DHCPv4
softwire for configuring additional parameters. This is referred over IPv4 messages within an IPv6 softwire for configuring
to as DHCPv6 + Stateless DHCPv4oSW. additional parameters. This is referred to as DHCPv6 + Stateless
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 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 remaining two methods are still theoretical. operators networks.
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 Agent (HCRA) function, which takes
messages and puts them into UDPv6 and IPv6. DHCPv4 messages and puts them into UDP and IPv6.
As the mechanism involves unicast 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 client's 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 directly on the server and/or via an client. This interface may be implemented directly on the server and
intermediary 'Transport Relay Agent' (TRA) device acting as the /or via an intermediary 'Transport Relay Agent' (TRA) device which
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 approach has the TRA or TSV on the server. As a result, this has sometimes been
sometimes been referred to as a tunneling approach. However, relay referred to as a tunneling approach. However, relay agent
agent encapsulation is not a tunnel, since it carries only DHCP encapsulation is not a tunnel, since it carries only DHCP traffic; it
traffic; it would be more accurate to describe it as an encapsulation would be more accurate to describe it as an encapsulation based
based transport. transport.
[I-D.ietf-dhc-dhcpv4-over-ipv6] also defines an On-Link Client Relay [I-D.ietf-dhc-dhcpv4-over-ipv6] also defines an On-Link Client Relay
agent (LCRA), which is a Client Relay Agent located on the same link Agent (LCRA), which is a Client Relay Agent located on the same link
as an unmodified DHCPv4 client. It is worth noting that there is no as an unmodified DHCPv4 client. It is worth noting that there is no
technical reason for using relay encapsulation for DHCPv4o6; this technical reason for using relay encapsulation for DHCPv4o6; this
approach was taken because the authors of the draft originally approach was taken because the authors of the draft originally
imagined that it might be used to provide configuration information imagined that it might be used to provide configuration information
for an unmodified DHCPv4 client. However, this turns out not to be a for an unmodified DHCPv4 client. However, this turns out not to be a
viable approach: in order for this to work, there would have to be viable approach: in order for this to work, there would have to be
IPv4 routing on the local link to which the client is connected. In IPv4 routing on the local link to which the client is connected. In
that case, there's no need for DHCPv4o6. that case, there's no need for DHCPv4o6.
Given that this is the case, there is no technical reason why Given that this is the case, there is no technical reason why
DHCPv4o6 can't simply use the IPv6 transport directly, without any DHCPv4o6 can't simply use the IPv6 transport directly, without any
relay encapsulation. This would greatly simplify the specification relay encapsulation. This would greatly simplify the specification
and the implementation, and would still address the requirements and the implementation, and would still address the requirements
stated in this document. stated in this document.
[I-D.ietf-dhc-dhcpv4-over-ipv6] describes this solution in detail. [I-D.ietf-dhc-dhcpv4-over-ipv6] describes this solution in detail.
The protocol stack is as follows: The protocol stack for provisioning IPv4/IPv6 tunneling and
translation mechanisms is as follows:
DHCPv4/UDPv6/IPv6 DHCPv4/UDP/IPv6
1.3. DHCPv6 Based Provisioning - Functional Overview 1.3. DHCPv6 Based Provisioning - Functional Overview
In this approach, DHCPv6 [RFC3315] would be extended with new DHCPv6 In this approach, DHCPv6 [RFC3315] would be extended with new DHCPv6
options for configuring all IPv4 based services and functions (i.e. options for configuring all IPv4 based services and functions (i.e.
IPv4 address assignment and any necessary DHCPv4 options). DHCPv4 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. IPv4 address leasing would also need to be managed by parameters. IPv4 address leasing would also need to be managed by
the DHCPv6 server. the DHCPv6 server.
At the time of writing, it is not known which or how many such At the time of writing, it is not known which or how many such
options would need to be ported from DHCPv4 to DHCPv6. options would need to be ported from DHCPv4 to DHCPv6.
The protocol stack is as follows: The protocol stack for provisioning IPv4/IPv6 tunneling and
translation mechanisms is as follows:
DHCPv6/UDPv6/IPv6 DHCPv6/UDP/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, configuration of the 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 that 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, through the configured softwire in
same manner as any other IPv4 based traffic. Broadcast based DHCPv4 the same manner as any other IPv4 based traffic. Broadcast based
DHCPDISCOVER messages (necessary for IPv4 address assignment) can not DHCPv4 DHCPDISCOVER messages (necessary for IPv4 address assignment)
be transported as they are not compatible with the existing, unicast can not be transported as some softwire mechanisms implement NBMA
based softwire architecture. links, where broadcast isn't supported. Additionally, there is a
more general issue with the use of fixed L4 ports in A+P [RFC6346]
based approaches. Here, a single IPv4 address is shared among
multiple users, each using a unique set of ports for differentiation
meaning that it is not possible for every client to be allocated a
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 would be server would be strictly DHCPINFORM/DHCPACK messages. These can be
used for the configuration of any additional IPv4 parameters. used for conveying additional DHCPv4 based options.
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
DHCPv4 relay function within the tunnel concentrator or other DHCPv4 relay function within the tunnel concentrator or other
methods. 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 the protocol stack. Here the and DHCPv4o6 (described above) is the protocol stack. Here the
DHCPv4 message is first put into UDPv4 and IPv4 and then into the DHCPv4 message is first put into UDP and IPv4 and then into the IPv6
IPv6 softwire, instead of placing the DHCPv4 message directly into softwire, instead of placing the DHCPv4 message directly into UDP and
UDPv6 and IPv6. 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 used for obtaining an IPv4 address and source For IPv4/IPv6 tunneling and translation mechanism, the protocol stack
ports (if required) is as follows: used for obtaining an IPv4 address and source ports (if required) is
as follows:
DHCPv6/UDPv6/IPv6 DHCPv6/UDP/IPv6
The protocol stack used for obtaining additional IPv4 configuration For provisioning IPv4/IPv6 tunneling mechanisms, the protocol stack
is as follows: for obtaining additional IPv4 configuration is:
DHCPv4/UDPv4/IPv4/IPv6 DHCPv4/UDP/IPv4
NB: The encapsulating IPv6 tunneling header is not shown as it is
functionally a layer 2 header.
And for provisioning IPv4/IPv6 translation mechanisms:
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: BOOTREQUESTV6 and messages within two new DHCPv6 messages types: DHCPV4-QUERY and
BOOTREPLYV6. These new messages types must be implemented in both DHCPV4-RESPONSE. These new messages types must be implemented in
the DHCPv4oDHCPv6 client and server. both 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
(without IPv4/UDPv4 headers) within a new OPTION_BOOTP_MSG DHCPv6 (without IPv4/UDP headers) within a new OPTION_DHCPV4_MSG DHCPv6
option. option.
OPTION_BOOTP_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_BOOT_MSG within a
BOOTREQUESTV6 message, it passes it to the DHCPv4 server engine. 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_BOOTP_MSG and puts this into a BOOTPRPLYV6 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
BOOTREQUESTV6 message to a different destination address, allowing DHCPV4-QUERY message to a different destination address, allowing for
for the separation of DHCPv4 and DHCPv6 provisioning infrastructure. the separation of DHCPv4 and DHCPv6 provisioning infrastructure.
If the DHCPv4oDHCPv6 client is provision with a unicast IPv6 If the DHCPv4oDHCPv6 client is provisioned with a unicast IPv6
address(es) for the server(s), then an entirely unicast message flow address(es) for the server(s), then an entirely unicast message flow
between the client and server is also possible without the need for between the client and server is also possible without the need for
relaying. relaying.
The protocol stack used for obtaining dynamic v4 addressing or For provisioning IPv4/IPv6 tunneling and translation mechanisms, the
protocol stack used for obtaining dynamic v4 addressing and/or
additional IPv4 configuration is as follows: additional IPv4 configuration is as follows:
DHCPv4/DHCPv6/UDPv6/IPv6 DHCPv4/DHCPv6/UDP/IPv6
2. Requirements for the Solution Evaluation 2. Requirements for the Solution Evaluation
The following requirements have been defined to evaluate the The following requirements have been defined to evaluate 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.
skipping to change at page 8, line 48 skipping to change at page 9, line 11
functions to restrict provisioning domains to the relevant functions to restrict provisioning domains to the relevant
protocol and allow the removal of IPv4 infrastructure in the protocol and allow the removal of IPv4 infrastructure in the
future. future.
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.
7. Not restricted to specific IPv4 over IPv6 transport mechanisms or 7. Not be restricted to specific underlying IPv4 over IPv6 transport
architectures. mechanisms or architectures. The solution needs to be flexible
enough to support new IPv4 over IPv6 technologies as they are
developed.
3. Comparison of the Five Approaches 3. Comparison of the Four 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 + Stateless | DHCPv4oDHCPv6 | | Req. | DHCPv4o6 | DHCPv6 | DHCPv6 + Stateless | DHCPv4oDHCPv6 |
| No. | | | DHCPv4oSW | | | No. | | | DHCPv4oSW | |
+--------+----------+--------+----------------------+---------------+ +--------+----------+--------+----------------------+---------------+
| 1 | No | Yes | No | Yes | | 1 | No | Yes | No | Yes |
| 2 | Yes | No | Yes | Yes | | 2 | Yes | No | Yes | Yes |
skipping to change at page 9, line 41 skipping to change at page 10, line 5
1. Implementation makes all existing DHCPv4 options available with 1. Implementation makes all existing DHCPv4 options available with
no further ongoing development work necessary. no 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, relay and server code. client, relay and server code.
4. No additional functional elements are necessary except the 4. Suitable for dynamic IPv4 address leases where the IPv4 address
DHCPv4o6 client relay agent and server. If a TSV is used, then a
TRA is not required.
5. Suitable for dynamic IPv4 address leases where the IPv4 address
lifetime is not linked to the lifetime of a DHCPv6 lease. lifetime is not linked to the lifetime of a DHCPv6 lease.
6. Implementations already exist, proving that the approach works. 5. Implementations already exist, proving that the approach works.
3.1.2. Cons 3.1.2. Cons
1. More new functional elements required within the architecture 1. More new functional elements required within the architecture
(CRA, DHCPv4o6 server and optionally TRA) than are necessary in (CRA, DHCPv4o6 server and optionally TRA) than are necessary in
DHCPv6 based provisioning. 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. The DHCPv4 client host needs to be updated to implement the IPv6 3. The DHCPv4 client host needs to be updated to implement the IPv6
encapsulation and decapsulation function (i.e. An HCRA). encapsulation and decapsulation function (i.e., an HCRA).
Otherwise a separate On-Link CRA (LCRA) functional element must Otherwise a separate On-Link CRA (LCRA) functional 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.2. DHCPv6 Based Provisioning 3.2. DHCPv6 Based Provisioning
3.2.1. Pros 3.2.1. Pros
1. No additional functional elements are required except the DHCPv6 1. No additional functional elements are required except the DHCPv6
client and server. client and server.
2. A single protocol is used to deliver configuration information 2. A single protocol is used to deliver configuration information
for IPv4 and IPv6. for IPv4 and IPv6.
3. Single provisioning point for all configuration parameters. 3. Single provisioning point for all configuration parameters.
4. Implementations already exist, proving that the approach works.
3.2.2. Cons 3.2.2. Cons
1. Any required DHCPv4 options must be ported to DHCPv6, which will 1. Any required DHCPv4 options must be ported to DHCPv6, which will
require re-development work for each option. require re-development work for each option.
2. Means that DHCPv4 'legacy' options (which will be of decreasing 2. Means that DHCPv4 'legacy' options (which will be of decreasing
relevance in the future) will remain in DHCPv6 for the lifetime relevance in the future) will remain in DHCPv6 for the lifetime
of the protocol. of 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 and possibly relays would need to be updated to servers and possibly relays would need to be updated to implement
implement the new option. the new option.
4. Architecture does not allow for the separation of IPv4 and IPv6 4. Architecture does not allow for the separation of IPv4 and IPv6
domains. domains.
5. Does not provide a mechanism for dynamic IPv4 address leasing, 5. Does not provide a mechanism for dynamic IPv4 address leasing.
where the lifetime of IPv4 addresses is not linked to the The lifetime of the IPv4 address is linked to the lifetime of a
lifetime of a DHCPv6 lease. A DHCPv4 lease lifetime management DHCPv6 address lease (i.e. the IPv4 address can only be changed
mechanism would need to be added to DHCPv6 to implement this. when a DHCPv6 RENEW/REBIND message is sent). To remove this
interdependency, a new DHCPv4 lease management mechanism would
need to be added to DHCPv6 (e.g. a new Identity Association
solely for IPv4 address leasing).
3.3. DHCPv6 + Stateless DHCPv4oSW Based Provisioning 3.3. DHCPv6 + Stateless DHCPv4oSW Based Provisioning
3.3.1. Pros 3.3.1. Pros
1. Once implemented, all existing DHCPv4 options will be available 1. Once implemented, all existing DHCPv4 options will be available
with no ongoing development work necessary. with no ongoing development work required.
2. Uses existing DHCPv4 and DHCPv6 architectures in order to provide 2. Uses existing DHCPv4 and DHCPv6 architectures in order to provide
IPv4 configuration in an IPv6 only environment. IPv4 configuration in an IPv6 only environment.
3. DHCPv4 and DHCPv6 based provisioning can be separated from each 3. If required, DHCPv4 and DHCPv6 based provisioning can be
other if required, allowing flexibility in network design. separated from each other, allowing flexibility in network
design.
3.3.2. Cons 3.3.2. Cons
1. More new functional elements required than are necessary in 1. More new functional elements required than are necessary with
DHCPv6 based provisioning. DHCPv6 based provisioning.
2. IPv4 over IPv6 softwire approaches that distribute NAT to the CPE 2. IPv4 over IPv6 softwire approaches that distribute the NAT44
and allow for IP address sharing (MAP-E & LW4o6) forbid the use function to the CPE and allow for IP address sharing (MAP-E &
of reserved TCP/UDP ports (e.g. 0-1024). Every DHCPv4 client LW4o6) forbid the use of reserved TCP/UDP ports (e.g. 0-1024).
sharing the same address needs to have a UDP listener running on Every DHCPv4 client sharing the same address needs to have a UDP
UDP port 68. To resolve this would require significant rework to listener running on UDP port 68. To resolve this would require
either the softwire mechanisms and/or the DHCPv4 client significant rework to either the softwire mechanisms and/or the
implementation. DHCPv4 client implementation.
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.
skipping to change at page 12, line 14 skipping to change at page 12, line 20
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) cannot 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 to locate the DHCPv4 relay
DHCPv4 relay, as all traffic must pass through it. An underlying function, 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 currently unproven. Although existing
implementations may currently exist, the approach has not been
demonstrated.
3.4. DHCPv4oSW Based Provisioning 3.4. DHCPv4oDHCPv6 Based Provisioning
3.4.1. Pros 3.4.1. Pros
1. Once implemented, all existing DHCPv4 options will be available 1. Once implemented, all existing DHCPv4 options will be available
with no ongoing development work necessary. with no ongoing development work necessary.
2. Uses 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. May require 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. 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 available
with no ongoing development work necessary.
2. Uses existing DHCPv4 and DHCPv6 architectures in order to provide 2. Uses existing DHCPv4 and DHCPv6 architectures in order to provide
IPv4 configuration in an IPv6 only environment. IPv4 configuration in an IPv6 only environment.
3. DHCPv4 and DHCPv6 based provisioning can be separated from each 3. If required, DHCPv4 and DHCPv6 based provisioning can be
other if required, allowing flexibility in network design. separated from each other, 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.5.2. Cons 3.4.2. Cons
1. More new functional elements within the architecture than are 1. More new functional elements within the architecture than are
necessary in DHCPv6 based provisioning. necessary in DHCPv6 based provisioning.
2. DHCPv6 clients needs to be updated to implement the new DHCPv6 2. DHCPv6 clients need 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 the new
DHCPv4oDHCPv6 message types and functionality. DHCPv4oDHCPv6 message types and functionality.
4. The approach is currently unproven as no existing implementations 4. 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 to realize, it is clear from the above analysis that development work to realize, it is clear from the above analysis that
the most sustainable approach capitalizes on existing DHCPv4 the most sustainable approach capitalizes on existing DHCPv4
skipping to change at page 15, line 16 skipping to change at page 14, line 40
3. For some IPv4 in IPv6 transition technologies, a client may be 3. For some IPv4 in IPv6 transition technologies, a client may be
configured with an IPv4 address which is shared by other clients. configured with an IPv4 address which is shared by other clients.
In these cases, clients using a single IPv4 address are In these cases, clients using a single IPv4 address are
differentiated using the combination of the IPv4 address and a differentiated using the combination of the IPv4 address and a
range of restricted layer 4 source ports unique to each client range of restricted layer 4 source ports unique to each client
(used for NAPT). The DHCPv4 client L4 port (68) must not be (used for NAPT). The DHCPv4 client L4 port (68) must not be
provisioned to any client for NAPT use. provisioned to any client for NAPT use.
4. The DHCPv4 relay must implement the Server Identifier Override 4. The DHCPv4 relay must implement the Server Identifier Override
Suboption described in [RFC5107] to direct all DHCPv4 messages Sub-option described in [RFC5107] to direct all DHCPv4 messages
through the DHCPv4 relay. As option 82 is being used to identify through the DHCPv4 relay. As option 82 is being used to identify
the destination IPv6 address for messages from the DHCPv4 server the destination IPv6 address for messages from the DHCPv4 server
to the client, the L4 destination port is not required for the to the client, the L4 destination port is not required for the
return path lookup process and is left unchanged as port 68. return path lookup process and is left unchanged as port 68.
6. IANA Considerations 6. IANA Considerations
This document does not make any request from IANA. 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.
7. Security Considerations 7. Security Considerations
The following sections provide pointers to the documented security This document analyzes various solutions and doesn't introduce any
considerations associated with each approach. new capabilities necessitating additional security considerations.
The following sub-sections provide pointers to the documented
security considerations associated with each approach.
7.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].
7.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].
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 10 of [RFC3315]. in Section 11 of [I-D.ietf-dhc-dhcpv4-over-dhcpv6].
8. Acknowledgements 8. Acknowledgements
Thanks to Ted Lemon, Tomek Mrugalski, Ole Troan and Francis Dupont Thanks to Ted Lemon, Tomek Mrugalski, Ole Troan, Bernie Volz and
for their input and reviews. Francis Dupont for their input and reviews.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. 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-03 (work in progress), November 2013. dhcpv4-over-dhcpv6-04 (work in progress), January 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-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-06 (work
in progress), November 2013. in progress), February 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., Dec, W., Bao, C.,
leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options
for configuration of Softwire Address and Port Mapped for configuration of Softwire Address and Port Mapped
Clients", draft-ietf-softwire-map-dhcp-06 (work in Clients", draft-ietf-softwire-map-dhcp-06 (work in
progress), November 2013. progress), November 2013.
[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-05 (work
in progress), September 2013. in progress), February 2014.
[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-09 with Encapsulation (MAP)", draft-ietf-softwire-map-10
(work in progress), December 2013. (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-v6-option-01 (work in progress), September dhcpv4-over-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,
February 2008. February 2008.
[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the
IPv4 Address Shortage", RFC 6346, August 2011.
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. 74 change blocks. 
185 lines changed or deleted 161 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/