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

From: Wuyts Carl <[email-masked]>
Date: Thu, 1 Dec 2011 11:30:41 +0100

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
[email-masked]
tel.: +32 3 443 65 90

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: [email-masked] [mailto:[email-masked]] 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
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 1 Dec 2011 07:50:31 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Wuyts Carl
Sent: Thursday, December 01, 2011 5:31 AM
To: peng-wu; Ted Lemon; AndreKostur
Cc: dhc WG
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

>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", 

Note if the CPE router WAN is assigned a public IPv4 address, the SP
supports native IPv4 and why does the CPE then need DS-Lite? I don't
think a use case exists for native IPv4 and DS-Lite running concurrently
on the CE router.  Neither does DS-Lite have a sunsetting because what
does DS-Lite sunset to?  Native IPv4?  Hmm, the reason the network went
to DS-Lite is because public IPv4 address space is depleted.  

Hemant

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 1 Dec 2011 14:57:46 +0100

I don't agree.  The above draft is about a v6-only access network, so CPE-PE link is v6-only.
I agree on the fact that you in that case don't have to use DSLite, but in the above draft, there's no native v4 link next to the v6.

Carl Wuyts

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: donderdag 1 december 2011 14:51
To: Wuyts Carl; peng-wu; Ted Lemon; AndreKostur
Cc: dhc WG
Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wuyts Carl
Sent: Thursday, December 01, 2011 5:31 AM
To: peng-wu; Ted Lemon; AndreKostur
Cc: dhc WG
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

>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", 

Note if the CPE router WAN is assigned a public IPv4 address, the SP supports native IPv4 and why does the CPE then need DS-Lite? I don't think a use case exists for native IPv4 and DS-Lite running concurrently on the CE router.  Neither does DS-Lite have a sunsetting because what does DS-Lite sunset to?  Native IPv4?  Hmm, the reason the network went to DS-Lite is because public IPv4 address space is depleted.  

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 1 Dec 2011 08:06:26 -0600

Carl,

We are in agreement.  I am not commenting on the dhcpv4-over-ipv6 document.  I was only explaining the CE router text as to why the text says if native IPv4 is available why use DS-Lite.

Hemant

-----Original Message-----
From: Wuyts Carl [mailto:[email-masked]] 
Sent: Thursday, December 01, 2011 8:58 AM
To: Hemant Singh (shemant); peng-wu; Ted Lemon; AndreKostur
Cc: dhc WG
Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

Carl Wuyts

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: donderdag 1 december 2011 14:51
To: Wuyts Carl; peng-wu; Ted Lemon; AndreKostur
Cc: dhc WG
Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wuyts Carl
Sent: Thursday, December 01, 2011 5:31 AM
To: peng-wu; Ted Lemon; AndreKostur
Cc: dhc WG
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

Hemant

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 1 Dec 2011 15:23:49 +0100

No worries, but these things are all pretty much in the same area, hence you might get the feeling that some things are contra-dicting each other, such as the public IPv4 address presence and it's reqs on it in RFc6204bis.

Carl Wuyts

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: donderdag 1 december 2011 15:06
To: Wuyts Carl; peng-wu; Ted Lemon; AndreKostur
Cc: dhc WG
Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

Carl,

Hemant

-----Original Message-----
From: Wuyts Carl [mailto:[email-masked]]
Sent: Thursday, December 01, 2011 8:58 AM
To: Hemant Singh (shemant); peng-wu; Ted Lemon; AndreKostur
Cc: dhc WG
Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

Carl Wuyts

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

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: donderdag 1 december 2011 14:51
To: Wuyts Carl; peng-wu; Ted Lemon; AndreKostur
Cc: dhc WG
Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wuyts Carl
Sent: Thursday, December 01, 2011 5:31 AM
To: peng-wu; Ted Lemon; AndreKostur
Cc: dhc WG
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

Hemant

---

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

On Dec 1, 2011, at 5:30 AM, Wuyts Carl wrote:
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 ??

Carl, as a group, we are not qualified to make architectural decisions about IPv6 transition technologies that don't directly involve DHCP.   We adopted this work because we were asked to do so as part of an effort from the softwires working group.   If you think this is a bad architecture, please raise that discussion there.   I get the impression that it's been discussed to death, though.

---

From: Wuyts Carl <[email-masked]>
Date: Fri, 2 Dec 2011 08:20:03 +0100

Ted, I read "we are not qualified to make architectural decisions about IPv6 transition technologies that don't directly involve DHCP".  Good, however, the RFC6204 initially was putting a req in place to state that the CPE MUST wait for the RA prior of starting its DHCPv6 client.  This is linked to DHCP I'd say, no ?  I see too many times that links are being made between protocols or check for address or ....  It is OK to say that one should wait for it, so to leave it open as implementation choice or configuration possibility for the vendor.

Carl Wuyts
Connect Division

[email-masked]<mailto:[email-masked]>
tel.: +32 3 443 65 90
<http://twitter.com/#!/TechnicolorIPv6>
<http://www.technicolor.com/>
Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium

From: Ted Lemon [mailto:[email-masked]]
Sent: donderdag 1 december 2011 17:37
To: Wuyts Carl
Cc: peng-wu; Andre Kostur; dhc WG
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

---

From: Ted Lemon <[email-masked]>
Date: Fri, 2 Dec 2011 17:38:12 +0000

On Dec 2, 2011, at 2:20 AM, Wuyts Carl wrote:
Ted, I read “we are not qualified to make architectural decisions about IPv6 transition technologies that don't directly involve DHCP”.  Good, however, the RFC6204 initially was putting a req in place to state that the CPE MUST wait for the RA prior of starting its DHCPv6 client.  This is linked to DHCP I’d say, no ?  I see too many times that links are being made between protocols or check for address or ….  It is OK to say that one should wait for it, so to leave it open as implementation choice or configuration possibility for the vendor.

What does this have to do with DHCPv4 over IPv6?   RFC6204 is not a DHC working group document.   I'm going to give you my best answer to this question under a separate subject line.