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

[Wojciech Dec <[e-mail]>]

Peng,

your answers do not address the key concerns:
- Why is this needed, besides that it can be done, as opposed to classic
dual stack?
- It requires changes to the client/relay, thus it cannot be simply used
with regular DHCPv4 implementations (note: it doesn't matter that you're
putting a CRA element, that's an implementation detail). It is thus
invesement in legacy IPv4 technology, not migration to IPv6.
- It is more complicated to get through failures, to anyone who looks at it
all objectively (Basic example: A dhcpv4 user will have no idea that the
failure to get an ipv4 address is because in the
CRA/whatever-stuff-is-combbled-to-make-this-work DNSv6 is returning a wrong
AAAA for some host name that happens to be a dhcpv4 server, or because
dhcpv6 is not providing the right option or name).
- DHCPv4 servers need to be modified to take into account IPv6.

-Woj.


On 13 June 2012 06:36, Peng Wu <[e-mail]> wrote:

> Woj,
>
> On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec <[e-mail]> wrote:
> > 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")?
> [Peng] That's not always the case. Now to be more precise, with pb 4over6
> 1.Concentrator can be in a high position, and we don't have to IPv4 every
> where
> 2.Provision IPv4 in a flexible, on-demand way
> 3.It can be deployed along with DS-lite to provide a value-added service
> These points are already written in the draft
>
> >>
> >> > 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).
> [Peng]Actually we can use regular DHCPv4 client, with the help of a
> CRA function planted on the same host, that's a very fundamental point
> of the DHCPv4over6v6 draft.
> Server side need modification, yes. But only on the step of
> sending/receiving DHCP messages (sockets). That's what I wanted to
> express in last mail.
> FYI, it only uses IPv6 unicast, with the aid of CRA.
>
> >>
> >> 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.
> Sorry but I simply don't buy that it's *significant* more complexity.
> As to failure, it's more like a sequencial rather than " the failure
> of one is not obvious to anyone looking at another". If I cannot get
> the concentrator or the DHCPv4 server address, I stop the rest steps.
>
>
> >>
> >> 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.
> See above
>
> Cheers~
>