One document matched: draft-ietf-dhc-v4configuration-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-dhc-v4configuration-02"
ipr="trust200902">
<front>
<title abbrev="Provisioning IPv4 Config Over IPv6">Provisioning IPv4
Configuration Over IPv6 Only Networks</title>
<author fullname="Branimir Rajtar" initials="B." surname="Rajtar">
<organization>Hrvatski Telekom</organization>
<address>
<postal>
<street/>
<city>Zagreb</city>
<country>Croatia</country>
</postal>
<email>branimir.rajtar@t.ht.hr</email>
</address>
</author>
<author fullname="Ian Farrer" initials="I." surname="Farrer">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street/>
<city>Bonn</city>
<country>Germany</country>
</postal>
<email>ian.farrer@telekom.de</email>
</address>
</author>
<date day="30" month="September" year="2013"/>
<area>Internet</area>
<workgroup>DHC WG</workgroup>
<abstract>
<t>As IPv6 becomes more widely adopted, some service providers are
taking the approach of deploying IPv6 only networks, without dual-stack
functionality for IPv4. However, access to IPv4 based services is still
an ongoing requirement and approaches such as IPv4-in-IPv6 softwire
tunnels are being developed to meet this need.</t>
<t>In order to provision end-user's hosts with the necessary IPv4
configuration, a number of different mechanisms have been proposed. This
memo discusses the benefits and drawbacks of each, with the aim of
recommending a single approach as the basis for future work.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>A service provider with an IPv6-only network must also be able to
provide customers with access to the Internet and other services over
IPv4. Softwire based IPv4-in-IPv6 tunneling mechanisms are an obvious
example of this, such as the ones described in: <list style="symbols">
<t><xref target="I-D.ietf-softwire-lw4over6"/></t>
<t><xref target="I-D.ietf-softwire-map"/></t>
<t><xref target="I-D.ietf-softwire-unified-cpe"/></t>
</list></t>
<t>A general trend here is to relocate NAT44 functionality and IPv4
address sharing from the centralized tunnel concentrator to the CPE in
order to achieve better scalability. 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.
These parameters are pre-requisites for successfully configuring the
client for providing IPv4 based connectivity.</t>
<t>In order to configure customer's devices for softwire functionality,
a dynamic provisioning mechanism is necessary. 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.</t>
<t>Although IPv4-in-IPv6 softwire tunnel 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 the
configuration of softwires or other specific underlying IPv4 over IPv6
architectures or mechanisms. DHCPv4 options may also need to be conveyed
to clients for configuring IPv4 based services, e.g. SIP server
addresses.</t>
<t>This document describes and compares five different methods which
have been proposed as solutions to this problem.</t>
<section title="Overview of IPv4 Parameter Configuration Approaches">
<t>The following approaches for transporting IPv4 configuration
parameters over IPv6 only networks have been suggested:<list
style="numbers">
<t hangText="DHCPv4o6">Adapt DHCPv4 format messages to be
transported over IPv6 as described in <xref
target="I-D.ietf-dhc-dhcpv4-over-ipv6"/>. For brevity, this is
referred to as DHCPv4o6.</t>
<t hangText="DHCP">Extend DHCPv6 with new options for IPv4
configuration, such as <xref target="I-D.ietf-softwire-map-dhcp"/>
describes.</t>
<t>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+DHCPv4oSW.</t>
<t>Use DHCPv4 over IPv4 messages transported over a broadcast
capable IPv4overIPv6 transport (e.g. a softwire) for all IPv4
configuration including the external IPv4 address and source port
configuration. This is referred to as DHCPv4oSW.</t>
<t>Use DHCPv4 format messages, transporting them within a new
DHCPv6 message type as described in <xref
target="I-D.ietf-dhc-dhcpv4-over-dhcpv6"/>. This is referred to as
DHCPv4oDHCPv6.</t>
</list></t>
<t>At the time of writing, working examples of the first two
approaches have been developed and successfully tested in several
different operators networks. The fourth approach has been tested
successfully in a lab environment. The remaining two methods are still
theoretical.</t>
<t>The following sections provide describe each of the approaches in
more detail.</t>
</section>
<section title="DHCPv4o6 Based Provisioning - Functional Overview">
<t>In order to receive IPv4 configuration parameters, IPv4-only
clients initiate and exchange DHCPv4 messages with the DHCPv4 server.
In order adapt this to an IPv6-only network, an existing DHCPv4 client
implements a 'Client Relay' (CRA) function, which takes DHCPv4
messages and puts them into UDPv6 and IPv6.</t>
<t>As the mechanism involves unicast based communications, the IPv6
address of the server must be provisioned to the client. This option
is described in <xref
target="I-D.mrugalski-softwire-dhcpv4-over-v6-option"/>.</t>
<t>The DHCPv4o6 server must provide an IPv6 interface to the client.
This interface may be directly on the server and/or via an
intermediary 'Transport Relay Agent' device can act as the gateway
between the IPv4 and IPv6 domains.</t>
<t>For the dynamic allocation of IPv4 addresses, the DHCPv4 server
needs to be extended to support the new DHCPv4o6 functionality, such
as the storing the IPv6 address of DHCPv4o6 clients and implementing
the CRA6ADDR option.</t>
<t>This approach currently uses functional elements for ingress and
egress of the IPv6-only transport domain--the CRA on the host and the
TRA or TSV on the server. As a result, this approach has sometimes
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.</t>
<t>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.</t>
<t>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.</t>
<t><xref target="I-D.ietf-dhc-dhcpv4-over-ipv6"/> decribes this
solution in detail.</t>
<t>The protocol stack is as follows:</t>
<t>DHCPv4/UDPv6/IPv6</t>
</section>
<section title="DHCPv6 Based Provisioning - Functional Overview">
<t>In this approach, DHCPv6 <xref target="RFC3315"/> 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.</t>
<t>At the time of writing, it is not known how many such options would
need to be ported from DHCPv4 to DHCPv6.</t>
<t>An example of this approach is described in <xref
target="I-D.ietf-softwire-map-dhcp"/>, where a DHCPv6 message is used
to convey the parameters necessary for IPv4 in IPv6 softwire
configuration.</t>
<t>The protocol stack is as follows:</t>
<t>DHCPv6/UDPv6/IPv6</t>
</section>
<section title="DHCPv6+DHCPv4oSW Based Provisioning - Functional Overview">
<t>In this approach, the configuration of IPv4 address and source
ports (if required) is carried out using DHCPv6 as described in
section 1.3 above. Any additional IPv4 configuration parameters which
are required are then provisioned using a 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 softwire architecture.</t>
<t>On receipt at the tunnel concentrator (e.g. MAP Border Router or a
Lightweight 4over6 lwAFTR), the DHCPv4 message removed from the
softwire and forwarded to the DHCPv4 server in the same way as any
other IPv4 packet is handled.</t>
<t>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, for the
configuration of additional IPv4 parameters. </t>
<t>For this approach to function, a mechanism for the DHCPv4 client to
learn the IPv4 address of the DHCPv4 server is needed. This could be
done by defining a well-known IPv4 address for the DHCPv4 server,
implementing a DHCPv4 relay function within the tunnel concentrator or
other configuration methods.</t>
<t>From a transport perspective, the key difference between this
method and DHCPv4o6 (described above) is that here, the DHCPv4 message
is put into UDPv4 and IPv4 and then put into the IPv6 softwire,
instead of directly placing the DHCPv4 message into UDPv6 and
IPv6.</t>
<t>Currently, this approach is only theoretical and does not have a
corresponding Internet Draft providing more detail.</t>
<t>The protocol stack used for obtaining an IPv4 address and source
ports (if required) is as follows:</t>
<t>DHCPv6/UDPv6/IPv6</t>
<t>The protocol stack used for obtaining additional IPv4 configuration
is as follows:</t>
<t>DHCPv4/UDPv4/IPv4/IPv6</t>
</section>
<section title="DHCPv4oSW Based Provisioning - Functional Overview">
<t><xref target="I-D.troan-dhc-dhcpv4osw"/> describes a method for
complete client configuration using DHCPv4 transported across a
broadcast capable link layer transport, such as a softwire. This
differs from DHCPv6+DHCPv4oSW in that it could support all DHCPv4
message types and is not limited to just DHCPINFORM/DHCPACK messages.
This means that it can be used for the assignment of IPv4 addresses as
well as other DHCPv4 options.</t>
<t>This functions by running a DHCPv4 client on the link layer
interface (e.g. the softwire tunnel interface). As the link layer must
support broadcasts, DHCPDISCOVER and other broadcast DHCPv4 messages
can be supported. The DHCPv4 message flow is then the same as
described in section 3.1 of <xref target="RFC2131"/>.</t>
<t>In this approach, either the tunnel concentrator must also be the
DHCPv4 server or it must act as a DHCPv4 relay so that the broadcast
DHCPDISCOVER/DHCPREQUEST messages can be decapsulated and forwarded to
the DHCPv4 server. If it is functioning as a relay, then the DHCPv4
Relay Information Option (option 82) is used to convey the client's
source IPv6 address. This is also used by the relay for routing return
DHCPv4 packets.</t>
<t>The DHCPv4oSW client may be configured with a shared IPv4 address
with restricted layer 4 source ports. This will normally exclude the
well-known TCP/UDP ports in the range 0-1023, so the DHCPv4oSW client
must be updated to source BOOTP/DHCP requests from a port taken from
the range allocated to the client instead of UDP port 67. Likewise,
the DHCPv4oSW server must use the L4 source port from a client's
message as the destination port for the response.</t>
<t>The protocol stack used for obtaining DHCPv4 based configuration
is:</t>
<t>DHCPv4/UDPv4/IPv4/IPv6</t>
</section>
<section title="DHCPv4oDHCPv6 Based Provisioning - Functional Overview">
<t><xref target="I-D.ietf-dhc-dhcpv4-over-dhcpv6"/> describes the
transport of DHCPv4 messages within two new DHCPv6 messages types:
BOOTREQUESTV6 and BOOTREPLYV6. These messages types must be
implemented in both the DHCPv4oDHCPv6 client and server.</t>
<t>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.</t>
<t>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.</t>
<t>As the DHCPv4 messages are carried within DHCPv6 multicast
messages, using the All_DHCP_Relay_Agents_and_Servers, they can be
relayed in exactly the same way as any other DHCPv6 multicasted
message. 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.</t>
<t>The protocol stack used for obtaining dynamic v4 addressing or
additional IPv4 configuraion is as follows:</t>
<t>DHCPv4/DHCPv6/UDPv6/IPv6</t>
</section>
</section>
<section title="Requirements for the Solution Evaluation">
<t>The following requirements have been defined for the evalution of the
different approaches:</t>
<t><list style="numbers">
<t>Minimize the amount of work necessary to implement the solution
through re-use of existing standards and implementations as much as
possible.</t>
<t>Provide a method of supporting all DHCPv4 options so that they
can be utilised without the need for further standardation.</t>
<t>Allow for the dynamic leasing of IPv4 addresses to clients. This
allows for more efficient use of limited IPv4 resources.</t>
<t>Enable the separation of IPv4 and IPv6 host configuration
infrastructure, i.e. independent DHCPv4 and DHCPv6 servers.</t>
<t>Avoid leaving legacy IPv4 options in DHCPv6.</t>
<t>Provide a flexible architecture to give operators the option of
only deploying the functional elements necessary for their specific
requirements.</t>
<t>Not restricted to specific IPv4 over IPv6 transport mechanisms or
architectures.</t>
<t><vspace blankLines="14"/></t>
</list></t>
</section>
<section title="Comparison of the Five Approaches">
<t>The table below provides an evaluation comparison of how the
different approaches meet the solution requirements described above.</t>
<texttable anchor="functional" title="Approach Comparison">
<ttcol align="center">Req. No.</ttcol>
<ttcol align="center">DHCPv4o6</ttcol>
<ttcol align="center">DHCPv6</ttcol>
<ttcol align="center">DHCPv6+DHCPv4oSW</ttcol>
<ttcol align="center">DHCPv4oSW</ttcol>
<ttcol align="center">DHCPv4oDHCPv6</ttcol>
<c>1</c>
<c>No</c>
<c>Yes</c>
<c>No</c>
<c>Yes</c>
<c>Yes</c>
<c>2</c>
<c>Yes</c>
<c>No</c>
<c>Yes</c>
<c>Yes</c>
<c>Yes</c>
<c>3</c>
<c>Yes</c>
<c>No</c>
<c>No</c>
<c>Yes</c>
<c>Yes</c>
<c>4</c>
<c>Yes</c>
<c>No</c>
<c>Yes</c>
<c>Yes</c>
<c>Yes</c>
<c>5</c>
<c>Yes</c>
<c>No</c>
<c>Yes</c>
<c>Yes</c>
<c>Yes</c>
<c>6</c>
<c>No</c>
<c>No</c>
<c>Yes</c>
<c>Yes</c>
<c>Yes</c>
<c>7</c>
<c>Yes</c>
<c>Yes</c>
<c>No</c>
<c>No</c>
<c>Yes</c>
</texttable>
<t>The following sections of the document provide more details of the
pros and cons relevant to each of the approaches.</t>
<section title="DHCPv6 Based Provisioning">
<t/>
<section title="Pros">
<t><list style="numbers">
<t>Simpler, in that no additional functional elements are
required except the DHCPv6 client and server.</t>
<t>A single protocol is used to deliver configuration
information for IPv4 and IPv6.</t>
<t>A single provisioning point for all configuration
parameters.</t>
<t>Implementations already exist, proving that the approach
works.</t>
</list></t>
</section>
<section title="Cons">
<t><list style="numbers">
<t>Any required DHCPv4 options must be ported to DHCPv6, which
will require re-development work for each option. All functional
elements in the DHCPv6 implementation (clients, servers, relays)
would need to be updated for each change.</t>
<t>Means that DHCPv4 'legacy' options, which will be of
decreasing relevance in the future will remain in DHCPv6 for the
lifetime of the protocol.</t>
<t>Each time that a DHCPv4 option is ported to DHCPv6, all
clients and servers would need to be updated to implement the
new option.</t>
<t>Does not provide an architecture for keeping IPv4 and IPv6
domains separated.</t>
<t>Does not provide a mechanism for dynamic IPv4 address
leasing. A DHCPv4 lease lifetime management mechanism would need
to be added to DHCPv6 for this.</t>
</list></t>
</section>
</section>
<section title="DHCPv4o6 Based Provisioning">
<t/>
<section title="Pros">
<t><list style="numbers">
<t>Implemention makes all existing DHCPv4 options available with
no further ongoing development work necessary.</t>
<t>IPv4 and IPv6 based provisioning can be separated from each
other if required, allowing flexibility in network design.</t>
<t>Easy to implement through minor adaptation of existing DHCPv4
client, relay and server code.</t>
<t>Simple, in that no additional functional elements are
necessary except the DHCPv4o6 client relay and server. If a TSV
is used, then the TRA is not required.</t>
<t>Suitable for the provisioning of dynamic IPv4 configuration
as the existing DHCPv4 leasing mechanism can be used.</t>
<t>Implementations already exist, proving that the approach
works.</t>
</list></t>
</section>
<section title="Cons">
<t><list style="numbers">
<t>More complex, in that there are more new functional elements
(CRA, DHCPv4o6 server and optionally TRA) within the
architecture than are necessary in DHCPv6 based
provisioning.</t>
<t>A new DHCPv6 option is necessary in order to provision the
IPv6 address of the DHCPv4 server to the end device.</t>
<t>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.</t>
<t>A DHCPv4 server must be deployed and maintained.</t>
<t>The DHCPv4 server needs to be updated to implement new
DHCPv4o6 functionality.</t>
</list></t>
</section>
</section>
<section title="DHCPv6+DHCPv4oSW Based Provisioning">
<t/>
<section title="Pros">
<t><list style="numbers">
<t>Once implemented, all existing DHCPv4 options will be be
available with no further ongoing development work
necessary.</t>
<t>Uses the existing DHCPv4 and DHCPv6 architectures in order to
provide IPv4 configuration in an IPv6 only environment.</t>
<t>DHCPv4 and DHCPv6 based provisioning can be separated from
each other if required, allowing flexibility in network
design.</t>
</list></t>
</section>
<section title="Cons">
<t><list style="numbers">
<t>More complex, in that there are more new functional elements
within the architecture than are necessary in DHCPv6 based
provisioning.</t>
<t>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 implementatioIn.</t>
<t>From the current specification, DHCPINFORM is not suitable
for use over a softwire. Additional work, such as the
development of 'shims' would be necessary</t>
<t>The current DHCPINFORM specification has a number of unclear
points, such as those described in <xref
target="I-D.ietf-dhc-dhcpinform-clarify"/>. Substantial work
would be required to resolve this.</t>
<t>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
always be the case.</t>
<t>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.</t>
<t>As only DHCPINFORM/DHCPACK DHCPv4 message types are
supported, dynamic IPv4 address leasing (using DHCPDISCOVER
messages) can not be used.</t>
<t>Restricted to underlying hub-and-spoke IPv4 over IPv6
architectures. The 'hub' is necessary for the location of the
DHCPv4 relay, as all traffic. An underlying mesh architecture
does not have such a location to deploy the relay.</t>
<t>The approach is unproven as no existing implementations
exist.</t>
</list></t>
</section>
</section>
<section title="DHCPv4oSW Based Provisioning">
<t/>
<section title="Pros">
<t><list style="numbers">
<t>Once implemented, all existing DHCPv4 options will be be
available with no further ongoing development work
necessary.</t>
<t>Uses the existing DHCPv4 architecture in order to provide
IPv4 configuration in an IPv6 only environment.</t>
<t>DHCPv4 and DHCPv6 based provisioning can be separated from
each other if required, allowing flexibility in network
design.</t>
</list></t>
</section>
<section title="Cons">
<t><list style="numbers">
<t>Requires the DHCPv4 client, DHCPv4 server and softwire
concentrator (or other relaying device) to be modified.</t>
<t>Requires the DHCPv4 client and server to be updated to use
dynamic ports taken from the restricted port set allocated to
the client instead of the well-known DHCPv4 ports.</t>
<t>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)</t>
<t>May not be suitable for configuring translation based
approaches (e.g. MAP-T)</t>
<t>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. </t>
</list></t>
</section>
</section>
<section title="DHCPv4oDHCPv6 Based Provisioning">
<t/>
<section title="Pros">
<t><list style="numbers">
<t>Once implemented, all existing DHCPv4 options will be be
available with no further ongoing development work
necessary.</t>
<t>Uses the existing DHCPv4 and DHCPv6 architectures in order to
provide IPv4 configuration in an IPv6 only environment.</t>
<t>DHCPv4 and DHCPv6 based provisioning can be separated from
each other if required, allowing flexibility in network
design.</t>
<t>Suitable for the provisioning of dynamic IPv4 configuration
as the existing DHCPv4 leasing mechanism can be used.</t>
</list></t>
</section>
<section title="Cons">
<t><list style="numbers">
<t>More complex, in that there are more new functional elements
within the architecture than are necessary in DHCPv6 based
provisioning.</t>
<t>DHCPv6 clients needs to be updated to implement the new
DHCPv6 message types (BOOTPREQUESTv6 and BOOTPREPLYv6).</t>
<t>The DHCPv6 server needs to be updated to implement new
DHCPv4oDHCPv6 message types and functionality.</t>
<t>The approach is currently unproven as no existing
implementations exist.</t>
</list></t>
</section>
</section>
</section>
<section title="Conclusion">
<t>Whilst all of the approaches described here will require some
development work in order 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.</t>
<t>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.</t>
<t>Therefore, the DHCPv6 approach is not suitable for delivering IPv4
configuration parameters in an efficient, ongoing manner.</t>
<t>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.
DHCPv4oSW does not provide this function and so is not recommended.</t>
<t>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.</t>
<t>Therefore, this memo recommends DHCPv4oDHCPv6 <xref
target="I-D.ietf-dhc-dhcpv4-over-dhcpv6"/> as the best underlying
approach for provisioning IPv4 parameters over an IPv6 only network.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The following sections provide pointers to the documented security
considerations associated with each approach. </t>
<section title="DHCPv4oIPv6">
<t>Security considerations associated with this approach are described
in Section 8 of <xref target="I-D.ietf-dhc-dhcpv4-over-ipv6"/>.</t>
</section>
<section title="DHCPv6">
<t>Security considerations associated with this approach are described
in Section 23 of <xref target="RFC3315"/>.</t>
</section>
<section title="DHCPv6+DHCPv4oSW">
<t>There is currently no document describing this mechanism, so no
security considerations have been documented.</t>
</section>
<section title="DHCPv4oSW">
<t>At the time of writing,<xref target="I-D.troan-dhc-dhcpv4osw"/>
does not list any security considerations.</t>
</section>
<section title="DHCPv4oDHCPv6">
<t>Security considerations associated with this approach are described
in Section 10 of <xref target="RFC3315"/>.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Ted Lemon, Tomek Mrugalski, Ole Troan and Francis Dupont
for their input and reviews.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-softwire-lw4over6'?>
<?rfc include='reference.I-D.ietf-softwire-map'?>
<?rfc include='reference.I-D.ietf-softwire-unified-cpe'?>
<?rfc include='reference.I-D.ietf-dhc-dhcpv4-over-ipv6'?>
<?rfc include='reference.I-D.ietf-softwire-map-dhcp'?>
<?rfc include='reference.I-D.ietf-dhc-dhcpinform-clarify'?>
<?rfc include='reference.I-D.ietf-dhc-dhcpv4-over-dhcpv6'?>
<?rfc include='reference.I-D.mrugalski-softwire-dhcpv4-over-v6-option'?>
<?rfc include='reference.I-D.troan-dhc-dhcpv4osw'?>
<?rfc include='reference.RFC.2131'?>
<?rfc include='reference.RFC.3315'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 13:55:06 |