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

[" Peng Wu " <[e-mail]>]

Hi Carl,

This is quite interesting. Thanks for bring this up.
My understanding of how people work with RFC6024 is that, we develop a new transition technique, get it approved in Softwire or Behave, then we put the CPE requirement of this tech into RFC6204.
DSLite, as a stateful IPv4-over-IPv6 tech, has been standardized, so RFC6024 get update for this tech.
Now we also has 4over6 as a per-subscriber state IPv4-over-IPv6 tech and MAP as a stateless IPv4-over-IPv6 tech, both ongoing in softwire.
We'll see what we can do on RFC6204 when we get 4over6 done in Softwire.
Anyway, this is probably out of the scope of this mailinglist, but thank you again:)
 
 
------------------ Original ------------------
From:  "Wuyts Carl"<[e-mail]>;
Date:  Thu, Dec 1, 2011 06:30 PM
To:  "peng-wu"<[e-mail]>; "Ted Lemon"<[e-mail]>; "AndreKostur"<[e-mail]>; 
Cc:  "dhc WG"<[e-mail]>; 
Subject:  RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

 
Hello all,

Recently, the v6ops group have been discussing the update of RFC6204 (into RFC6204, latest version: http://www.ietf.org/id/draft-ietf-v6ops-6204bis-03.txt).  Compared with the initial RFC6204, now both 6rd and DSLite requirements have been added.
Copy from that doc:
""
DLW-4:  If the IPv6 CE Router is configured with a public IPv4
           address on its WAN interface, where public IPv4 address is
           defined as any address which is not in the private IP address
           space specified in [RFC5735], then the IPv6 CE Router SHOULD
           disable the DS-Lite B4 element.
""
This DHCP over IPv6 draft mentions the 2 mechanism: DSLite if no more public space available, and the discussed draft draft-ietf-dhc-dhcpv4-over-ipv6-00.txt.  I've suggested to remove the above requirement, but it ended up as described above: a SHOULD requirement (was a MUST before). 

I'd say it's getting a bit tricky now.  The DHCPv4 over IPv6 draft and the RFC6204bis are sharing some "components", e.g. the DSLite DHCPv6 option (RFC6334).  Although the requirement of RFC6204bis has been re-phrased to should it literally says that "the CPE SHOULD disable the DSLite tunnel in case of public IPv4 presence on the link", while this draft is adding an IPv4 public address to the tunnel interface.  Both DSLite and 4over6 are in fact similar interface/tunnel types, so might all become a bit confusing, no ??

regs

Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION
[e-mail]
tel.: [phone]


Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium
Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpen

Help preserve the color of our world - Think before you print.




-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of peng-wu
Sent: donderdag 1 december 2011 7:39
To: Ted Lemon; Andre Kostur
Cc: dhc WG
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

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
>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.
>
>
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg