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

[Peng Wu <[e-mail]>]

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~