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

[Qi Sun <[e-mail]>]

Hi Woj,

     Please see inline.

On Fri, Jun 15, 2012 at 6:42 PM, Wojciech Dec <[e-mail]> wrote:

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

[Qi]Because it is difficult for the operators to deploy native dual stack
in such a short period when the IPv4 address resource is running out, here
comes stateful mechanisms DS-lite and pb4over6 to solve the transition
problems, with/without CGN on the AFTR/concentrator. IMHO, they do not
compete with native dual stack for the reason above.


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

[Qi] Pb4over6 is a stateful mechanism without CGN. It's different from
other work.

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.
>
> [Qi] IMO we should progress the draft, instead of blocking the IPv4/IPv6
transition progress.


>
>> - 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.
>
>>
>> [Qi] CRA is short for Client Relay Agent. AFAIK, we don't take DHCP relay
agent as a change to DHCP server, but a separate part. So I'm not sure if
it's proper to call CRA a client change.


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

[Qi]  I think you ignored a fact that the DHCPv4 server is likely to be
collocated with the concentrator, as Peng stated before.  IMHO , in MAP,
you put many kinds of information in one DHCPv6 option. The client and CPE
need to be modified to pick out what they need. And there are some other
process to make the mechanism work. I think it is not simpler than pb4over6.

>
> -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~
>>>
>>
>>
>
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>
>