Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

From: [email-masked]
Date: Wed, 30 Nov 2011 08:14:40 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title           : DHCPv4 over IPv6 Transport
	Author(s)       : Yong Cui
                          Peng Wu
                          Jianping Wu
                          Ted Lemon
	Filename        : draft-ietf-dhc-dhcpv4-over-ipv6-00.txt
	Pages           : 9
	Date            : 2011-11-30

   Recently, there are demands arising for IPv4 address allocation under
   IPv6 environment, especially in IPv6 transition scenarios.  This
   document describes the mechanism to survive DHCPv4 over IPv6 network.
   DHCPv4 messages are transported in IPv6 packets when traversing the
   IPv6 network.  DHCPv4 protocol behavior of the client and server is
   extended to support this IPv6 transport.  For the relay case, a new
   suboption of the Relay Agent Information Option is defined to carry
   the remote IPv6 address of the clients.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

---

From: Andre Kostur <[email-masked]>
Date: Wed, 30 Nov 2011 09:05:56 -0800

>        Filename        : draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

On first reading I'm concerned about the architecture in general.  By
this draft it is imposing additional requirements on any IPv4 device
that wishes to operate in this environment.   Wouldn't it be better to
place the additional behaviours on a relay agent type behaviour on the
upstream router, or the device performing the 4 to 6 translation?  I
doubt if I'm ever going to get a firmware update on my blu-ray player
to support this new behaviour, but if the agent functionality is
pushed higher up in the the network, then any and all existing IPv4
devices that are already doing DHCP will be able to continue to
operate in this environment.

--
Andre Kostur
Senior Product Design Engineer
Incognito Software Inc.
E: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Dec 2011 05:16:46 +0000

On Nov 30, 2011, at 12:05 PM, Andre Kostur wrote:
On first reading I'm concerned about the architecture in general.

Thanks for reading it.   I don't think the use case you're describing is one that the authors of the draft have in mind; I agree with you that it's unlikely that this use case would work.   However, the intended use for this technique is in a device that already understands how to set up a stateless 4over6 tunnel, so presumably this isn't the only change that would be required on the device.

The intended use as I understand it is in a situation where we have a generally working IPv6 network, but there are a few remaining applications that need IPv4 addresses.   Because these applications are sparsely distributed through the network, setting up infrastructure to support them in each location where they might be needed doesn't make sense.   Instead, you put this technology on those nodes that need it, and those nodes are expected to be few, and far between.

Peng Wu could probably explain the intention here better than I can.

---

From: peng-wu <[email-masked]>
Date: Thu, 1 Dec 2011 14:39:15 +0800

Hi Andre,

Thanks for your review in such a short time :)
As Ted has explained, the user case we already have is Hub & Spoke
IPv4-over-IPv6, where end users sparsely distributed in the IPv6 
network has IPv4 communication demand, so they build IPv4-in-IPv6
 tunnels with a remote router which is connected to IPv4. For this
"tunneled" IPv4 access, end users need IPv4 address provisioned
 from the remote router. So the IPv4 devices that wishes to operator 
in this environment need to support IPv4-in-IPv6 tunnel besides the
DHCP extension, which means changes on the device is already 
needed anyway.
Details on scenarios & tunnel mechanisms can be found in: 
http://tools.ietf.org/html/draft-ietf-softwire-public-4over6-00
http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-04

About the suggestion to place the additional behaviours on the
upstream router: we actually have mechanism for this case, such
as configured tunnel & RFC5565. But that's another secanrio. The 
critical difference is that, the ISPs don't want to provison native IPv4
in the last hop of their IPv6 network anymore.  They want go with
only IPv6.

As to performing the 4 to 6 translation, that's a totally different story.
For example, the first thing coming to my mind is that, with 4 to 6 
translation the remote end of the communication would be IPv6, while
with 4over6 tunnel the remote end would lie in IPv4. I believe the 
Softwire and Behave WG have agreed that tunneling and translation 
have respective application scenarios. Actually in this case, network-side 
4 to 6 translation (NAT-PT) was obsoleted for quite a lot issues while
host-side 4 to 6 translation would bring much more changes to the OS
than tunnel. So tunnel would actually be a reasonable choice here...

Back to the blu-ray player example you raised, I guess usually such a
device would locate behind a home gateway/CPE rather than connect
to the ISP network directly. Then your gateway/CPE would implement
the CRA funtions and interact with the remote DHCP server, while
your player only interacts with the gatway/CPE to get a private IPv4 
address. Just like what happens today. 

Hope this helps to understand the intension.
BTW, we're trying to find a way of implementing CRA so that it could
cooperate with the existing DHCP client implementation. Then we 
don't have to modify the client so there'll be less changes.
--------------
peng-wu