Provisioning IPv4
Configuration Over IPv6 Only Networks
Hrvatski Telekom
Zagreb
Croatia
branimir.rajtar@t.ht.hr
Deutsche Telekom AG
Bonn
Germany
ian.farrer@telekom.de
Internet
DHC WG
As IPv6 becomes more widely adopted, some service providers are
choosing to deploy IPv6 only networks without dual-stack functionality
for IPv4. However, as access to IPv4 based services will continue to be
a requirement for the foreseeable future, IPv4 over IPv6 mechanisms,
such as softwire tunnels are being developed.
In order to provision end-user's hosts with the IPv4 configuration
necessary for such mechanisms, a number of different approaches have
been proposed. This memo discusses each of the proposals, identifies the
benefits and drawbacks and recommends a single approach as the basis for
future deployment and development.
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.
A service provider with an IPv6-only network must also be able to
provide customers with access to the IPv4 Internet and other IPv4-only
services. IPv4 over IPv6 tunneling / translation mechanisms are an
obvious example of this, such as the ones described in:
In today's home networks, each residential user is allocated a single
global IPv4 address which is used for NAT44. Decentralizing NAT44 allows
for much better scaling and, when combined with stateless network
functions, can simplify redundancy and logging. This results in the need
to provision a number of configuration parameters to the CPE, such as
the external public IPv4 address and a restricted port-range to use for
NAT. Other parameters may also be necessary, depending on the underlying
transport technology that is in use. In IPv4 only networks, DHCPv4 has
often been used to provide IPv4 configuration, but in an IPv6 only
network, DHCPv4 messages cannot be 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
. 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
needs to receive a static IPv4 address assignment (with no dynamic
address leasing or additional IPv4 configuration), DHCPv6 based
approaches (e.g. ) may
provide a suitable solution.
This document is concerned with more complex IPv4 configuration
scenarios, to bring IPv4 configuration over IPv6-only networks in line
with the functionality offered by DHCPv4 in IPv4 native networks. DHCPv4
options may also need to be conveyed to clients for configuring IPv4
based services, e.g., SIP server addresses.
Although IPv4-in-IPv6 softwire tunnel and translation clients are
currently the only use-case for DHCP based configuration of IPv4
parameters in IPv6 only networks, a suitable approach must not be
limited to only supporting softwires configuration or be reliant on
specific underlying IPv4 over IPv6 architectures or mechanisms.
This document describes and compares four different methods which
have been proposed as solutions to this problem.
The following approaches for transporting IPv4 configuration
parameters over IPv6 only networks have been suggested:
Adapt DHCPv4 format messages to be
transported over IPv6 as described in . For brevity, this is
referred to as DHCPv4o6.
Extend DHCPv6 to support IPv4 address leasing
and other DHCPv4 options.
Use DHCPv6 as above for external IPv4 address and source port
configuration. Use DHCPv4 over IPv4 messages within an IPv6
softwire for configuring additional parameters. This is referred
to as DHCPv6 + Stateless DHCPv4oSW.
Use DHCPv4 format messages, transporting them within a new
DHCPv6 message type as described in . This is referred to as
DHCPv4oDHCPv6.
At the time of writing, working examples of the first two methods
have been developed and successfully tested in several different
operators networks. The remaining two methods are still
theoretical.
The following sections provide describe each of the approaches in
more detail.
In order to receive IPv4 configuration parameters, IPv4-only
clients initiate and exchange DHCPv4 messages with the DHCPv4 server.
To adapt this for an IPv6-only network, an existing DHCPv4 client
implements a 'Host Client Relay' (HCRA) function, which takes DHCPv4
messages and puts them into UDPv6 and IPv6.
As the mechanism involves unicast based communications, the IPv6
address of the server must be provisioned to the client. A DHCPv6
option for provisioning client's with this address is described in
.
The IPv6 Transport Server (TSV) provides an IPv6 interface to the
client. This interface may be directly on the server and/or via an
intermediary 'Transport Relay Agent' (TRA) device acting as the
gateway between the IPv4 and IPv6 domains.
For the dynamic allocation of IPv4 addresses, the DHCPv4 server
function needs to be extended to add DHCPv4o6 TSV capabilities, such
as the storing the IPv6 address of DHCPv4o6 clients and implementing
the CRA6ADDR option.
This approach currently uses functional elements for ingress 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 sometimes
been referred to as a tunneling approach. However, relay agent
encapsulation is not a tunnel, since it carries only DHCP traffic; it
would be more accurate to describe it as an encapsulation based
transport.
also defines an
On-Link Client Relay 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 technical reason for using relay encapsulation
for DHCPv4o6; this approach was taken because the authors of the draft
originally imagined that it might be used to provide configuration
information 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 IPv4 routing on the local link to which the client is
connected. In that case, there's no need for DHCPv4o6.
Given that this is the case, there is no technical reason why
DHCPv4o6 can't simply use the IPv6 transport directly, without any
relay encapsulation. This would greatly simplify the specification and
the implementation, and would still address the requirements stated in
this document.
describes this
solution in detail.
The protocol stack is as follows:
DHCPv4/UDPv6/IPv6
In this approach, DHCPv6 would be extended
with new DHCPv6 options for configuring all IPv4 based services and
functions (i.e. IPv4 address assignment and any necessary DHCPv4
options). DHCPv4 options needed by IPv4 clients connected to the IPv6
network are updated as new DHCPv6 native options carrying IPv4
configuration parameters. IPv4 address leasing would also need to be
managed by the DHCPv6 server.
At the time of writing, it is not known which or how many such
options would need to be ported from DHCPv4 to DHCPv6.
The protocol stack is as follows:
DHCPv6/UDPv6/IPv6
In this approach, the configuration of IPv4 address and source
ports (if required) is carried out using DHCPv6, e.g. using . Any additional IPv4
configuration parameters that are required are then provisioned using
DHCPv4 messages transported within IPv6 in the configured softwire in
the same manner as any other IPv4 based traffic. Broadcast based
DHCPv4 DHCPDISCOVER messages (necessary for IPv4 address assignment)
can not be transported as they are not compatible with the existing,
unicast based softwire architecture.
On receipt by the tunnel concentrator (e.g. MAP Border Router or a
Lightweight 4over6 lwAFTR), the DHCPv4 message is extracted from the
IPv6 packet and forwarded to the DHCPv4 server in the same way as any
other IPv4 forwarding plane packet is handled.
As the client is already configured with its external IPv4 address
and source ports (using DHCPv6 or a well-known IPv4 address for
DS-Lite clients), the messages exchanged between the DHCPv4 client and
server would be strictly DHCPINFORM/DHCPACK messages. These would be
used for the configuration of any additional IPv4 parameters.
For this approach to function, a mechanism for the DHCPv4 client to
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 DHCPv4
relay function within the tunnel concentrator or other methods.
From a transport perspective, the key difference between this
method and DHCPv4o6 (described above) is the protocol stack. Here the
DHCPv4 message is first put into UDPv4 and IPv4 and then into the IPv6
softwire, instead of placing the DHCPv4 message directly into UDPv6
and IPv6.
Currently, this approach is only theoretical and does not have a
corresponding Internet Draft providing more detail.
The protocol stack used for obtaining an IPv4 address and source
ports (if required) is as follows:
DHCPv6/UDPv6/IPv6
The protocol stack used for obtaining additional IPv4 configuration
is as follows:
DHCPv4/UDPv4/IPv4/IPv6
describes
transporting DHCPv4 messages within two new DHCPv6 messages types:
BOOTREQUESTV6 and BOOTREPLYV6. These new messages types must be
implemented in both the DHCPv4oDHCPv6 client and server.
In this approach, the configuration of stateless IPv4 addresses and
source ports (if required) is carried out using DHCPv6 as described in
section 1.3 above. Dynamic IPv4 addressing, and/or any additional IPv4
configuration, is provided using DHCPv4 messages carried (without
IPv4/UDPv4 headers) within a new OPTION_BOOTP_MSG DHCPv6 option.
OPTION_BOOTP_MSG enables the client and server to send BOOTP/DHCPv4
messages verbatim across the IPv6 network. When a DHCPv4oDHCPv6 server
receives a DHCPv6 request containing OPTION_BOOT_MSG within a
BOOTREQUESTV6 message, it passes it to the DHCPv4 server engine.
Likewise, the DHCPv4 server place its DHCPv4 response in the payload
of OPTION_BOOTP_MSG and puts this into a BOOTPRPLYV6 message.
DHCPv4 messages can be carried within DHCPv6 multicast messages,
using the All_DHCP_Relay_Agents_and_Servers multicast address. These
can be relayed in exactly the same way as any other DHCPv6 multicasted
messages.
Optionally, DHCPv6 relays could be updated so that they forward the
BOOTREQUESTV6 message to a different destination address, allowing for
the separation of DHCPv4 and DHCPv6 provisioning infrastructure.
If the DHCPv4oDHCPv6 client is provision with a unicast IPv6
address(es) for the server(s), then an entirely unicast message flow
between the client and server is also possible without the need for
relaying.
The protocol stack used for obtaining dynamic v4 addressing or
additional IPv4 configuration is as follows:
DHCPv4/DHCPv6/UDPv6/IPv6
The following requirements have been defined to evaluate the
different approaches:
Minimize the amount of work necessary to implement the solution
through re-use of existing standards and implementations as much as
possible.
Provide a method of supporting all DHCPv4 options so that they
can be utilized without the need for further standardization.
Allow for the dynamic leasing of IPv4 addresses to clients. This
allows for more efficient use of limited IPv4 resources.
Enable the separation of IPv4 and IPv6 host configuration
infrastructure, i.e. independent DHCPv4 and DHCPv6 server functions
to restrict provisioning domains to the relevant protocol and allow
the removal of IPv4 infrastructure in the future.
Avoid leaving legacy IPv4 options in DHCPv6.
Provide a flexible architecture to give operators the option of
only deploying the functional elements necessary for their specific
requirements.
Not restricted to specific IPv4 over IPv6 transport mechanisms or
architectures.
The table below provides a comparative evaluation showing how the
different approaches meet the solution requirements described above.
Req. No.
DHCPv4o6
DHCPv6
DHCPv6 + Stateless DHCPv4oSW
DHCPv4oDHCPv6
1
No
Yes
No
Yes
2
Yes
No
Yes
Yes
3
Yes
No
No
Yes
4
Yes
No
Yes
Yes
5
Yes
No
Yes
Yes
6
No
No
Yes
Yes
7
Yes
Yes
No
Yes
The following sections of the document provide more detail on the
pros and cons of each of the approaches.
Implementation makes all existing DHCPv4 options available
with no further ongoing development work necessary.
IPv4 and IPv6 based provisioning can be separated from each
other if required, allowing flexibility in network design.
Easy to implement through minor adaptation of existing DHCPv4
client, relay and server code.
No additional functional elements are necessary except the
DHCPv4o6 client relay agent and server. If a TSV is used, then a
TRA is not required.
Suitable for dynamic IPv4 address leases where the IPv4
address lifetime is not linked to the lifetime of a DHCPv6
lease.
Implementations already exist, proving that the approach
works.
More new functional elements required within the architecture
(CRA, DHCPv4o6 server and optionally TRA) than are necessary in
DHCPv6 based provisioning.
A new DHCPv6 option is necessary in order to provision the
IPv6 address of the DHCPv4 server to the end device.
The DHCPv4 client host needs to be updated to implement the
IPv6 encapsulation and decapsulation function (i.e. An HCRA).
Otherwise a separate On-Link CRA (LCRA) functional element must
be deployed.
A DHCPv4 server must be deployed and maintained.
The DHCPv4 server needs to be updated to implement new
DHCPv4o6 functionality.
No additional functional elements are required except the
DHCPv6 client and server.
A single protocol is used to deliver configuration
information for IPv4 and IPv6.
Single provisioning point for all configuration
parameters.
Implementations already exist, proving that the approach
works.
Any required DHCPv4 options must be ported to DHCPv6, which
will require re-development work for each option.
Means that DHCPv4 'legacy' options (which will be of
decreasing relevance in the future) will remain in DHCPv6 for
the lifetime of the protocol.
Each time that a DHCPv4 option is ported to DHCPv6, all
clients and servers and possibly relays would need to be updated
to implement the new option.
Architecture does not allow for the separation of IPv4 and
IPv6 domains.
Does not provide a mechanism for dynamic IPv4 address
leasing, where the lifetime of IPv4 addresses is not linked to
the lifetime of a DHCPv6 lease. A DHCPv4 lease lifetime
management mechanism would need to be added to DHCPv6 to
implement this.
Once implemented, all existing DHCPv4 options will be
available with no ongoing development work necessary.
Uses existing DHCPv4 and DHCPv6 architectures in order to
provide IPv4 configuration in an IPv6 only environment.
DHCPv4 and DHCPv6 based provisioning can be separated from
each other if required, allowing flexibility in network
design.
More new functional elements required than are necessary in
DHCPv6 based provisioning.
IPv4 over IPv6 softwire approaches that distribute NAT to the
CPE and allow for IP address sharing (MAP-E & LW4o6) forbid
the use of reserved TCP/UDP ports (e.g. 0-1024). Every DHCPv4
client sharing the same address needs to have a UDP listener
running on UDP port 68. To resolve this would require
significant rework to either the softwire mechanisms and/or the
DHCPv4 client implementation.
From the current specification, DHCPINFORM is not suitable
for use over a softwire. Additional work, such as the
development of 'shims' would be necessary.
The current DHCPINFORM specification has a number of unclear
points, such as those described in . Substantial work
would be required to resolve this.
Links the deployment of IPv4 configuration over IPv6 to a
softwire implementation (e.g. requiring a softwire concentrator
to act as a DHCPv4 relay). Whilst softwires are the only
application for this functionality at the moment, this may not
be the case in the future, meaning another solution may be
required.
A new mechanism must be defined in order to provide the
DHCPv4 client with the IPv4 address of the DHCPv4 server so that
unicast DHCPINFORM messages can be sent.
As only the DHCPINFORM/DHCPACK DHCPv4 message types are
supported, dynamic IPv4 address leasing (using DHCPDISCOVER
messages) cannot be used.
Restricted to underlying hub-and-spoke IPv4 over IPv6
architectures. The 'hub' is necessary for the location of the
DHCPv4 relay, as all traffic must pass through it. An underlying
mesh architecture does not have such a location to deploy the
relay function.
The approach is unproven as no existing implementations
exist.
Once implemented, all existing DHCPv4 options will be
available with no ongoing development work necessary.
Uses existing DHCPv4 architecture in order to provide IPv4
configuration in an IPv6 only environment.
DHCPv4 and DHCPv6 based provisioning can be separated from
each other if required, allowing flexibility in network
design.
Requires the DHCPv4 client, DHCPv4 server and softwire
concentrator (or other relaying device) to be modified.
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.
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)
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.
Once implemented, all existing DHCPv4 options will be
available with no ongoing development work necessary.
Uses existing DHCPv4 and DHCPv6 architectures in order to
provide IPv4 configuration in an IPv6 only environment.
DHCPv4 and DHCPv6 based provisioning can be separated from
each other if required, allowing flexibility in network
design.
Suitable for the provisioning of dynamic IPv4 configuration
as the existing DHCPv4 leasing mechanism can be used.
More new functional elements within the architecture than are
necessary in DHCPv6 based provisioning.
DHCPv6 clients needs to be updated to implement the new
DHCPv6 message types (BOOTPREQUESTv6 and BOOTPREPLYv6).
The DHCPv6 server needs to be updated to implement new
DHCPv4oDHCPv6 message types and functionality.
The approach is currently unproven as no existing
implementations exist.
Whilst all of the approaches described here will require some
development work to realize, it is clear from the above analysis that
the most sustainable approach capitalizes on existing DHCPv4
implementations and include them as new DHCPv6 message types. The main
rationale for this is that it enables all of DHCPv4's existing options
to be migrated for use over IPv6 in a single step.
Porting of all necessary DHCPv4 options to DHCPv6 would require
ongoing development work, re-implementing existing DHCPv4 functionality
in DHCPv6. This will result in having legacy DHCPv4 options in DHCPv6,
which will no longer be useful once IPv4 is completely abandoned.
Therefore, the DHCPv6 approach is not suitable for delivering IPv4
configuration parameters in an efficient, ongoing manner.
The dynamic leasing of IPv4 addresses is fundamental to the efficient
use of remaining IPv4 resources. This will become increasingly important
in the future, so a mechanism which supports this is necessary. DHCPv6 +
Stateless DHCPv4oSW does not provide this function and so is not
recommended.
The DHCPv4o6 approach requires a DHCPv4 server (with DHCPv4o6
functionality) for all deployment scenarios, even when DHCPv4 specific
functionality (e.g. sending DHCPv4 options) is not required by the
operator.
Therefore, this memo recommends DHCPv4oDHCPv6 as the best underlying
approach for provisioning IPv4 parameters over an IPv6 only network.
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 .
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.
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.
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.
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.
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.
The DHCPv4 relay must implement the Server Identifier Override
Suboption described in 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.
This document does not make any request from IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
The following sections provide pointers to the documented security
considerations associated with each approach.
Security considerations associated with this approach are described
in Section 8 of .
Security considerations associated with this approach are described
in Section 23 of .
There is currently no document describing this mechanism, so no
security considerations have been documented.
Security considerations associated with this approach are described
in Section 10 of .
Thanks to Ted Lemon, Tomek Mrugalski, Ole Troan and Francis Dupont
for their input and reviews.