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

["Lee, Yiu" <[e-mail]>]

Hi Woj,

Let me try to answer some of your questions:

From:  Wojciech Dec <[e-mail]>
Date:  Thursday, June 14, 2012 9:07 AM
To:  Peng Wu <[e-mail]>
Cc:  "[e-mail]" <[e-mail]>, Yong Cui
<[e-mail]>
Subject:  Re: [Softwires] WG last call on
draft-ietf-softwire-public-4over6-01

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?

[YL]  The scenario is addressing IPv6-only access network. If the access
network is DS, yes, you don't need this technology.

- 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.

[YL] AFAIK, the client won't change but will require CRA. This technology is
to support legacy v4 service while migrating to IPv6. The client will have
both v4 and v6 addresses. This is given. So I fail to see why this is only
an investment in legacy IPv4 technology.

- 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).

[YL] I am sorry, I can't follow this. Can you explain more please?

- DHCPv4 servers need to be modified to take into account IPv6.

[YL] Yes or we need to deploy TRA.

Thanks,
Yiu

-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~