draft-ietf-dhc-v4configuration-00.txt   draft-ietf-dhc-v4configuration-01.txt 
DHC WG B. Rajtar DHC WG B. Rajtar
Internet-Draft Hrvatski Telekom Internet-Draft Hrvatski Telekom
Intended status: Informational I. Farrer Intended status: Informational I. Farrer
Expires: November 14, 2013 Deutsche Telekom AG Expires: November 29, 2013 Deutsche Telekom AG
May 13, 2013 May 28, 2013
Provisioning IPv4 Configuration Over IPv6 Only Networks Provisioning IPv4 Configuration Over IPv6 Only Networks
draft-ietf-dhc-v4configuration-00 draft-ietf-dhc-v4configuration-01
Abstract Abstract
As IPv6 becomes more widely adopted, some service providers are As IPv6 becomes more widely adopted, some service providers are
taking the approach of deploying IPv6 only networks, without dual- taking the approach of deploying IPv6 only networks, without dual-
stack functionality for IPv4. However, access to IPv4 based services stack functionality for IPv4. However, access to IPv4 based services
is still an ongoing requirement and approaches such as IPv4-in-IPv6 is still an ongoing requirement and approaches such as IPv4-in-IPv6
softwire tunnels are being developed to meet this need. softwire tunnels are being developed to meet this need.
In order to provision end-user's hosts with the necessary IPv4 In order to provision end-user's hosts with the necessary IPv4
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 14, 2013. This Internet-Draft will expire on November 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 27 skipping to change at page 2, line 27
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview of IPv4 Parameter Configuration Approaches . . . 3 1.1. Overview of IPv4 Parameter Configuration Approaches . . . 3
1.2. DHCPv4o6 Based Provisioning - Functional Overview . . . . 4 1.2. DHCPv4o6 Based Provisioning - Functional Overview . . . . 4
1.3. DHCPv6 Based Provisioning - Functional Overview . . . . . 5 1.3. DHCPv6 Based Provisioning - Functional Overview . . . . . 5
1.4. DHCPv4oSW Based Provisioning - Functional Overview . . . 5 1.4. DHCPv4oSW Based Provisioning - Functional Overview . . . 5
1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview . 6 1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview . 6
2. Requirements for the Solution Evaluation . . . . . . . . . . 7 2. Requirements for the Solution Evaluation . . . . . . . . . . 7
3. Comparison of the Four Approaches . . . . . . . . . . . . . . 8 3. Comparison of the Four Approaches . . . . . . . . . . . . . . 8
3.1. Pros and Cons of the Different Approaches . . . . . . . . 8 3.1. DHCPv6 Based Provisioning . . . . . . . . . . . . . . . . 8
3.1.1. DHCPv4o6 Based Provisioning . . . . . . . . . . . . . 8 3.1.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. DHCPv6 Based Provisioning . . . . . . . . . . . . . . 9 3.1.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. DHCPv4oSW Based Provisioning . . . . . . . . . . . . . . 10 3.2. DHCPv4o6 Based Provisioning . . . . . . . . . . . . . . . 9
3.2.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. DHCPv4oDHCPv6 Based Provisioning . . . . . . . . . . . . 11 3.3. DHCPv4oSW Based Provisioning . . . . . . . . . . . . . . 10
3.3.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. DHCPv4oDHCPv6 Based Provisioning . . . . . . . . . . . . 11
3.4.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
A service provider with an IPv6-only network must also be able to A service provider with an IPv6-only network must also be able to
provide customers with access to the Internet and other services over provide customers with access to the Internet and other services over
IPv4. Softwire based IPv4-in-IPv6 tunneling mechanisms are an IPv4. Softwire based IPv4-in-IPv6 tunneling mechanisms are an
obvious example of this, such as the ones described in: obvious example of this, such as the ones described in:
o [I-D.ietf-softwire-lw4over6] o [I-D.ietf-softwire-lw4over6]
skipping to change at page 3, line 50 skipping to change at page 4, line 6
2. Extend DHCPv6 with new options for IPv4 configuration, such as 2. Extend DHCPv6 with new options for IPv4 configuration, such as
[I-D.ietf-softwire-map-dhcp] describes. [I-D.ietf-softwire-map-dhcp] describes.
3. Use DHCPv6 as above for external IPv4 address and source port 3. Use DHCPv6 as above for external IPv4 address and source port
configuration. Use DHCPv4 over IPv4 messages within an IPv6 configuration. Use DHCPv4 over IPv4 messages within an IPv6
softwire for configuring additional parameters. This is referred softwire for configuring additional parameters. This is referred
to as DHCPv4oSW. to as 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.scskf-dhc-dhcpv4-over-dhcpv6]. message type as described in [I-D.ietf-dhc-dhcpv4-over-dhcpv6].
This is referred to as DHCPv4oDHCPv6. This is referred to as DHCPv4oDHCPv6.
At the time of writing, working examples of the first two approaches At the time of writing, working examples of the first two approaches
have been developed and successfully tested in several different have been developed and successfully tested in several different
operators networks. The third and fourth methods are still operators networks. The third and fourth methods are still
theoretical. theoretical.
The following sections provide more detail for each approach. The following sections provide more detail for each approach.
1.2. DHCPv4o6 Based Provisioning - Functional Overview 1.2. DHCPv4o6 Based Provisioning - Functional Overview
skipping to change at page 6, line 30 skipping to change at page 6, line 30
Currently, this approach is only theoretical and does not have a Currently, this approach is only theoretical and does not have a
corresponding Internet Draft providing more detail. corresponding Internet Draft providing more detail.
The protocol stack that would be used for obtaining additional IPv4 The protocol stack that would be used for obtaining additional IPv4
configuraion is as follows: configuraion is as follows:
DHCPv4/UDPv4/IPv4/IPv6 DHCPv4/UDPv4/IPv4/IPv6
1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview 1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview
[I-D.scskf-dhc-dhcpv4-over-dhcpv6] describes the transport of DHCPv4 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes the transport of DHCPv4
messages within two new DHCPv6 messages types: BOOTREQUESTV6 and messages within two new DHCPv6 messages types: BOOTREQUESTV6 and
BOOTREPLYV6. These messages types must be implemented in both the BOOTREPLYV6. These messages types must be implemented in both the
DHCPv4oDHCPv6 client and server. DHCPv4oDHCPv6 client and server.
In this approach, the configuration of stateless IPv4 addresses and In this approach, the configuration of stateless IPv4 addresses and
source ports (if required) is carried out using DHCPv6 as described source ports (if required) is carried out using DHCPv6 as described
in section 1.3 above. Dynamic IPv4 addressing, and/or any additional in section 1.3 above. Dynamic IPv4 addressing, and/or any additional
IPv4 configuration, is provided using DHCPv4 messages carried IPv4 configuration, is provided using DHCPv4 messages carried
(without IPv4/UDPv4 headers) within a new OPTION_BOOTP_MSG DHCPv6 (without IPv4/UDPv4 headers) within a new OPTION_BOOTP_MSG DHCPv6
option. option.
skipping to change at page 7, line 7 skipping to change at page 7, line 7
BOOTREQUESTV6 message, it passes it to the DHCPv4 server engine. BOOTREQUESTV6 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_BOOTP_MSG and puts this into a BOOTPRPLYV6 message.
As the DHCPv4 messages are carried within DHCPv6 multicast messages, As the DHCPv4 messages are carried within DHCPv6 multicast messages,
using the All_DHCP_Relay_Agents_and_Servers, they can be relayed in using the All_DHCP_Relay_Agents_and_Servers, they can be relayed in
exactly the same way as any other DHCPv6 multicasted message. exactly the same way as any other DHCPv6 multicasted message.
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 BOOTREQUESTV6 message to a different destination address, allowing
for the separation of DHCPv4 and DHCPv4 provisioning infrastructure. for the separation of DHCPv4 and DHCPv6 provisioning infrastructure.
The protocol stack used for obtaining dynamic v4 addressing or The protocol stack used for obtaining dynamic v4 addressing or
additional IPv4 configuraion is as follows: additional IPv4 configuraion is as follows:
DHCPv4/DHCPv6/UDPv6/IPv6 DHCPv4/DHCPv6/UDPv6/IPv6
2. Requirements for the Solution Evaluation 2. Requirements for the Solution Evaluation
The following requirements have been defined for the evalution of the The following requirements have been defined for the evalution of the
different approaches: different approaches:
skipping to change at page 7, line 30 skipping to change at page 7, line 30
through re-use of existing standards and implementations as much through re-use of existing standards and implementations as much
as possible. as possible.
2. Provide a method of supporting all existing DHCPv4 options so 2. Provide a method of supporting all existing DHCPv4 options so
that they can be utilised without the need for further that they can be utilised without the need for further
standardation. standardation.
3. Allow for the dynamic leasing of IPv4 addresses to clients. This 3. Allow for the dynamic leasing of IPv4 addresses to clients. This
allows for more efficient use of limited IPv4 resources. allows for more efficient use of limited IPv4 resources.
4. Enable the separation of IPv4 and IPv6 host configuration. 4. Enable the separation of IPv4 and IPv6 host configuration
infrastructure, i.e. independent DHCPv4 and DHCPv6 servers.
5. Avoid leaving legacy IPv4 options in DHCPv6. 5. Avoid leaving legacy IPv4 options in DHCPv6.
6. Provide a flexible architecture to give operators the option of 6. Provide a flexible architecture to give operators the option of
only deploying the functional elements necessary for their only deploying the functional elements necessary for their
specific requirements. specific requirements.
3. Comparison of the Four Approaches 3. Comparison of the Four Approaches
The table below shows a comparison of the different approaches The table below shows a comparison of how the different approaches
against the solution requirements described above. meet the solution requirements described above.
+----------+----------+--------+-----------+---------------+ +----------+----------+--------+-----------+---------------+
| Req. No. | DHCPv4o6 | DHCPv6 | DHCPv4oSW | DHCPv4oDHCPv6 | | Req. No. | DHCPv4o6 | DHCPv6 | DHCPv4oSW | DHCPv4oDHCPv6 |
+----------+----------+--------+-----------+---------------+ +----------+----------+--------+-----------+---------------+
| 1 | No | Yes | Yes | Yes | | 1 | No | Yes | No | Yes |
| 2 | Yes | No | Yes | Yes | | 2 | Yes | No | Yes | Yes |
| 3 | Yes | No | No | Yes | | 3 | Yes | No | No | Yes |
| 4 | Yes | No | Yes | Yes | | 4 | Yes | No | Yes | Yes |
| 5 | Yes | No | Yes | Yes | | 5 | Yes | No | Yes | Yes |
| 6 | Yes | No | Yes | Yes | | 6 | No | No | Yes | Yes |
+----------+----------+--------+-----------+---------------+ +----------+----------+--------+-----------+---------------+
Table 1: Approach Comparison Table 1: Approach Comparison
3.1. Pros and Cons of the Different Approaches
The following sections of the document provide more details of the The following sections of the document provide more details of the
pros and cons relevant to each of the approaches. pros and cons relevant to each of the approaches.
3.1.1. DHCPv4o6 Based Provisioning 3.1. DHCPv6 Based Provisioning
3.1.1.1. Pros 3.1.1. Pros
1. Simpler, in that no additional functional elements are required
except the DHCPv6 client and server.
2. A single protocol is used to deliver configuration information
for IPv4 and IPv6.
3. A single provisioning point for all configuration parameters.
4. Implementations already exist, proving that the approach works.
3.1.2. Cons
1. 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.
2. Means that DHCPv4 'legacy' options, which will be of decreasing
relevance in the future will remain in DHCPv6 for the lifetime of
the protocol.
3. Each time that a DHCPv4 option is ported to DHCPv6, all clients
and servers would need to be updated to implement the new option.
4. Does not provide an architecture for keeping IPv4 and IPv6
domains separated.
5. Does not provide a mechanism for dynamic IPv4 address leasing. A
DHCPv4 lease lifetime mechanism would need to be added to DHCPv6
for this.
3.2. DHCPv4o6 Based Provisioning
3.2.1. Pros
1. Once implemented, all existing DHCPv4 options will be available 1. Once implemented, all existing DHCPv4 options will be available
with no further ongoing development work necessary. with 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/server code. client/server code.
4. Simple, in that no additional functional elements are necessary 4. Simple, in that no additional functional elements are necessary
except the DHCPv4o6 client and server. The Transport Relay Agent except the DHCPv4o6 client and server. The Transport Relay Agent
is completely optional. is completely optional.
5. Suitable for the provisioning of dynamic IPv4 configuration as 5. Suitable for the provisioning of dynamic IPv4 configuration as
the existing DHCPv4 leasing mechanism can be used. the existing DHCPv4 leasing mechanism can be used.
6. Implementations already exist, proving that the approach works. 6. Implementations already exist, proving that the approach works.
3.1.1.2. Cons 3.2.2. Cons
1. More complex, in that there are more new functional elements 1. More complex, in that there are more new functional elements
(CRA, DHCPv4o6 server and optionally TRA) within the architecture (CRA, DHCPv4o6 server and optionally TRA) within the architecture
than are necessary in DHCPv6 based provisioning. than are necessary in DHCPv6 based provisioning.
2. A new DHCPv6 option is necessary in order to provision the IPv6 2. A new DHCPv6 option is necessary in order to provision the IPv6
address of the DHCPv4 server to the end device. address of the DHCPv4 server to the end device.
3. For a Host CRA (HCRA), DHCPv4 client host needs to be updated to 3. For a Host CRA (HCRA), DHCPv4 client host needs to be updated to
implement the IPv6 encapsulation and decapsulation function. implement the IPv6 encapsulation and decapsulation function.
Otherwise a physically separate On-Link CRA (LCRA) functional Otherwise a physically separate On-Link CRA (LCRA) functional
element must be deployed. element must 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.1.2. DHCPv6 Based Provisioning 3.3. DHCPv4oSW Based Provisioning
3.1.2.1. Pros
1. Simpler, in that no additional functional elements are required
except the DHCPv6 client and server.
2. A single protocol is used to deliver configuration information
for IPv4 and IPv6.
3. A single provisioning point for all configuration parameters.
4. Implementations already exist, proving that the approach works.
3.1.2.2. Cons
1. 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.
2. Means that DHCPv4 'legacy' options, which will be of decreasing
relevance in the future will remain in DHCPv6 for the lifetime of
the protocol.
3. Each time that a DHCPv4 option is ported to DHCPv6, all clients
and servers would need to be updated to implement the new option.
4. Does not provide an architecture for keeping IPv4 and IPv6
domains separated.
5. Does not provide a mechanism for dynamic IPv4 address leasing. A
DHCPv4 lease lifetime mechanism would need to be added to DHCPv6
for this.
3.2. DHCPv4oSW Based Provisioning
3.2.1. Pros 3.3.1. Pros
1. Once implemented, all existing DHCPv4 options will be be 1. Once implemented, all existing DHCPv4 options will be be
available with no further ongoing development work necessary. available with no further ongoing development work necessary.
2. Uses the existing DHCPv4 and DHCPv6 architectures in order to 2. Uses the existing DHCPv4 and DHCPv6 architectures in order to
provide IPv4 configuration in an IPv6 only environment. provide IPv4 configuration in an IPv6 only environment.
3. DHCPv4 and DHCPv6 based provisioning can be separated from each 3. DHCPv4 and DHCPv6 based provisioning can be separated from each
other if required, allowing flexibility in network design. other if required, allowing flexibility in network design.
3.2.2. Cons 3.3.2. Cons
1. More complex, in that there are more new functional elements 1. More complex, in that there are more new functional elements
within the architecture than are necessary in DHCPv6 based within the architecture than are necessary in DHCPv6 based
provisioning. provisioning.
2. IPv4 over IPv6 softwire approaches which distribute NAT to the 2. IPv4 over IPv6 softwire approaches which distribute NAT to the
CPE and allow for IP address sharing (MAP-E & LW4o6) forbid 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 use of reserved TCP/UDP ports (e.g. 0-1024). Every DHCPv4
client sharing the same address needs to have a UDP listener client sharing the same address needs to have a UDP listener
running on UDP port 68. To resolve this would require running on UDP port 68. To resolve this would require
skipping to change at page 11, line 15 skipping to change at page 11, line 11
6. A new mechanism must be defined in order to provide the DHCPv4 6. A new mechanism must be defined in order to provide the DHCPv4
client with the IPv4 address of the DHCPv4 server so that unicast client with the IPv4 address of the DHCPv4 server so that unicast
DHCPINFORM messages can be sent. DHCPINFORM messages can be sent.
7. As only DHCPINFORM/DHCPACK DHCPv4 message types are supported, 7. As only DHCPINFORM/DHCPACK DHCPv4 message types are supported,
dynamic IPv4 address leasing (using DHCPDISCOVER messages) can dynamic IPv4 address leasing (using DHCPDISCOVER messages) can
not be used. not be used.
8. The approach is unproven as no existing implementations exist. 8. The approach is unproven as no existing implementations exist.
3.3. DHCPv4oDHCPv6 Based Provisioning 3.4. DHCPv4oDHCPv6 Based Provisioning
3.3.1. Pros 3.4.1. Pros
1. Once implemented, all existing DHCPv4 options will be be 1. Once implemented, all existing DHCPv4 options will be be
available with no further ongoing development work necessary. available with no further ongoing development work necessary.
2. Uses the existing DHCPv4 and DHCPv6 architectures in order to 2. Uses the existing DHCPv4 and DHCPv6 architectures in order to
provide IPv4 configuration in an IPv6 only environment. provide IPv4 configuration in an IPv6 only environment.
3. DHCPv4 and DHCPv6 based provisioning can be separated from each 3. DHCPv4 and DHCPv6 based provisioning can be separated from each
other if required, allowing flexibility in network design. other if required, allowing flexibility in network design.
4. Suitable for the provisioning of dynamic IPv4 configuration as 4. Suitable for the provisioning of dynamic IPv4 configuration as
the existing DHCPv4 leasing mechanism can be used. the existing DHCPv4 leasing mechanism can be used.
3.3.2. Cons 3.4.2. Cons
1. More complex, in that there are more new functional elements 1. More complex, in that there are more new functional elements
within the architecture than are necessary in DHCPv6 based within the architecture than are necessary in DHCPv6 based
provisioning. provisioning.
2. DHCPv6 clients needs to be updated to implement the new DHCPv6 2. DHCPv6 clients needs to be updated to implement the new DHCPv6
message types. message types (BOOTPREQUESTv6 and BOOTPREPLYv6).
3. The DHCPv6 server needs to be updated to implement new 3. The DHCPv6 server needs to be updated to implement new
DHCPv4oDHCPv6 message types and functionality. DHCPv4oDHCPv6 message types and functionality.
4. If separation of DHCPv4 and DHCPv4 provisioning infrastructure is 4. If separation of DHCPv4 and DHCPv6 provisioning infrastructure is
required, DHCPv6 relay agents need to be updated to implement required, DHCPv6 relay agents need to be updated to implement
dedicated forwarding destinations based on message type. dedicated forwarding destinations based on message type.
5. The approach is currently unproven as no existing implementations 5. The approach is currently unproven as no existing implementations
exist. exist.
4. Conclusion 4. Conclusion
Discussion: This chapter will be updated to reflect the consensus Whilst all of the approaches described here will require some
of the DHC Working Group. 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.
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. 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 is not required by the operator.
Therefore, this memo recommends DHCPv4oDHCPv6
[I-D.ietf-dhc-dhcpv4-over-dhcpv6] as the best underlying approach for
provisioning IPv4 parameters over an IPv6 only network.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
6. Security Considerations 6. Security Considerations
skipping to change at page 12, line 34 skipping to change at page 13, line 19
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[I-D.ietf-dhc-dhcpinform-clarify] [I-D.ietf-dhc-dhcpinform-clarify]
Hankins, D., "Dynamic Host Configuration Protocol Hankins, D., "Dynamic Host Configuration Protocol
DHCPINFORM Message Clarifications", draft-ietf-dhc- DHCPINFORM Message Clarifications", draft-ietf-dhc-
dhcpinform-clarify-06 (work in progress), October 2011. dhcpinform-clarify-06 (work in progress), October 2011.
[I-D.ietf-dhc-dhcpv4-over-dhcpv6]
Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc-
dhcpv4-over-dhcpv6-00 (work in progress), April 2013.
[I-D.ietf-dhc-dhcpv4-over-ipv6] [I-D.ietf-dhc-dhcpv4-over-ipv6]
Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6 Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6
Transport", draft-ietf-dhc-dhcpv4-over-ipv6-06 (work in Transport", draft-ietf-dhc-dhcpv4-over-ipv6-06 (work in
progress), March 2013. progress), March 2013.
[I-D.ietf-softwire-lw4over6] [I-D.ietf-softwire-lw4over6]
Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the DS-Lite Farrer, "Lightweight 4over6: An Extension to the DS-Lite
Architecture", draft-ietf-softwire-lw4over6-00 (work in Architecture", draft-ietf-softwire-lw4over6-00 (work in
progress), April 2013. progress), April 2013.
skipping to change at page 13, line 21 skipping to change at page 14, line 10
Softwire CPE", draft-ietf-softwire-unified-cpe-00 (work in Softwire CPE", draft-ietf-softwire-unified-cpe-00 (work in
progress), March 2013. progress), March 2013.
[I-D.mrugalski-softwire-dhcpv4-over-v6-option] [I-D.mrugalski-softwire-dhcpv4-over-v6-option]
Mrugalski, T. and P. Wu, "Dynamic Host Configuration Mrugalski, T. and P. Wu, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for DHCPv4 over IPv6 Protocol for IPv6 (DHCPv6) Option for DHCPv4 over IPv6
Endpoint", draft-mrugalski-softwire- Endpoint", draft-mrugalski-softwire-
dhcpv4-over-v6-option-01 (work in progress), September dhcpv4-over-v6-option-01 (work in progress), September
2012. 2012.
[I-D.scskf-dhc-dhcpv4-over-dhcpv6]
Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
Farrer, "DHCPv4 over DHCPv6 Transport", draft-scskf-dhc-
dhcpv4-over-dhcpv6-01 (work in progress), April 2013.
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. 27 change blocks. 
80 lines changed or deleted 110 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/