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

[Wojciech Dec <[e-mail]>]

Lee,

On 15 June 2012 04:51, Lee, Yiu <[e-mail]> wrote:

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

Woj> This draft proposes using public IPv4 addressing to deliver a dual
stack service to the end-user. Even on a future IPv6-only network, in the
selective cases where such a dual stack service is to be offered, using
existing IPv4 functionality, one that all operators use today, that is
mature, and requires NO client or server or relay changes, is way simpler
than investing in new intricate functionality.
I see this scheme directly leading into changing this scenario to one of
IPv4 address sharing, which brings this work into direct overlap with other
work in softwires.
As such I can only re-iterate what I said before; IMO we need a thorough
review of this solution space, including this draft, before progressing.


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

Woj> The fact that there is a CRA means a client change, or a CPE change.
The fact that you call it CRA, and not DHCP-client change, even though this
function is specific to DHCPv4, does not change that fact.

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

Woj> The sequence of events leading to a client acquiring a v4 address is
complex and not intuitive to anyone who deals with DHCPv4. There are
numerous points at which the whole thing could fail even before dhcpv4.

-Woj.



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