Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01

[Wojciech Dec <[e-mail]>]

Peng,

On 11 June 2012 20:38, Peng Wu <[e-mail]> wrote:

> Woj,
>
> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec <[e-mail]> wrote:
> > There is basic question regarding this draft, one that has also been
> raised
> > at previous WG meetings: "why is it needed?".
> It's actually written in section 4 of the draft.
>
> > There is a deeper issue here: This draft seems to give the impression
> that
> > running such a regular public addressed DHCPv4 based overlay on IPv6 is a
> > simple idea, as opposed to native dual stack. It is anything but, given
> that
> Why is it opposed to native dual-stack? It's IPv4-over-IPv6, similar
> to scenario of DS-Lite and MAP/4rd.
> I thought the assumption of IPv4-over-IPv6 is that you cannot/do not
> want to provision native dual-stack?
>

To put it simply: This draft describes a scenario where public v4 addresses
are available. The "classic" v6 migration scenario is in this case "dual
stack" and is what I believe has been advised for years by the IETF, and
continues to be the recommended approach. Why would one want to run in this
case dual-stack over a tunnel infra is the question? Is this intended as an
academic draft (as in "we can do it, but don't know why")?

>
> > a) it it requires changes to DHCPv4 processing b) it introduces non
> trivial
> > dependencies between DHCPv6 and DHCPv4 and tunnelling c) requires
> changes to
> > CPE d) makes life really a mess if we consider a real dual stack CPE.
> a) Simply make DHCPv4 work with IPv6 as underlying transport. No
> essential changes to protocol processing.
>

Woj> That's not what the draft DHCPv4overv6 indicates, unless one assumes a
very specific and limiting deployment scenario. In any case it's quite
clear that it is not possible to use regular DHCPv4 clients for this, or a
regular DHCPv4 server (there is no mention of how the broadcast flags
should be handled, mapped to IPv6, etc).


> b) What really matters here is provisioning the IPv4 address through
> DHCPv4. Just like in MAP/4rd, you provision the address through
> DHCPv6.
> In pb4over6 DHCPv6 is only an *option* to provide the concentrator
> address. You have similar logic too in MAP.
> So I don't think it's "non trivial dependancy". They are similar
> functions for all IPv4-over-IPv6 mechanisms that need provisioning,
> only different technical paths.
>

There are several components/parts that all need to play together in this
solution, many more than apparently required, and the failure of one is not
obvious to anyone looking at another. As in any such multi-part system
design, the overall complexity is higher.


> c) Any IPv4-over-IPv6 mechanism requires change to CPE
>

Yes, but in the case of this draft, the changes that are proposed do not
lead to anything over and above what plain dual stack accomplishes, except
extra complexity.