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

[Qi Sun <[e-mail]>]

Hi Woj,

In your previous mail you wrote :
> This statement confirms all the concerns
regarding this draft; it mentiones IPv4 address
run-out in the context of a draft whose sole
purpose is to hand out public IPv4 addresses,; it
also mentions the difficulty of deploying dual
stack, yet, this draft requires IPv6 to be
deployed (presumably in existing networks) along
with an IPv4 overlay too.

[Qi] Operators still have IPv4 address space to assign. that's why
IPv4 Internet is still growing. And if we don't hand out IPv4 address
, how can we achieve IPv4-over-IPv6(such as DS-Lite and MAP)? And
handing out public IPv4 address can achieve e2e transparency.

In the mechanism, there are dual stack nodes, which contribute to
achieve IPv4-over-IPv6. This is different from the so called 'native'
dual stack in which every node is dual stack.

> Woj> The last thing we need is another
transition mechanism, and this draft appears to
claim being one and nobody's blocking here
deployment of IPv6.
As stated earlier, we need a review of the whole
solution space in softwires, rather than spin up
more drafts that are of questionable use.

[Qi] This mechanism has its senario which has been stated in the draft
andof previous mails. what's more, this draft is now a WG  draft , NOT
a new draft.  So I don't think it is of 'questionable' use.

Best Regards!

Qi

On 6/16/12, Wojciech Dec <[e-mail]> wrote:
> Qi,
>
> On 16 June 2012 09:17, Qi Sun <[e-mail]> wrote:
>
>> 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.
>>
>
> This statement confirms all the concerns regarding this draft; it mentiones
> IPv4 address run-out in the context of a draft whose sole purpose is to
> hand out public IPv4 addresses,; it also mentions the difficulty of
> deploying dual stack, yet, this draft requires IPv6 to be deployed
> (presumably in existing networks) along with an IPv4 overlay too.
>
>>
>>
>>> 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.
>>
>
> Woj> The last thing we need is another transition mechanism, and this draft
> appears to claim being one and nobody's blocking here deployment of IPv6.
> As stated earlier, we need a review of the whole solution space in
> softwires, rather than spin up more drafts that are of questionable use.
>
> -Woj.
>
>>
>>
>>>
>>>> - 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
>>>
>>>
>>
>