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

[Wojciech Dec <[e-mail]>]

Qi,

On 16 June 2012 16:02, Qi Sun <[e-mail]> wrote:

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

Woj> As was previously indicated there are numerous solutions in this area,
and a review of this space is needed.

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

Woj> The fact that this is WG draft does not mean anything except that at
some point there was interest in working on a solution to a problem.
Currently it appears that there are multiple solutions to this problem,
some perhaps more flexible and practical than others. We won't know that
until we take stock of the whole space, rather than publishing RFCs that
(in this case) IMO bring little value.

-Woj.

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