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 <[email protected]> wrote: > Qi, > > On 16 June 2012 09:17, Qi Sun <[email protected]> wrote: > >> Hi Woj, >> >> Please see inline. >> >> On Fri, Jun 15, 2012 at 6:42 PM, Wojciech Dec <[email protected]> >> wrote: >> >>> Lee, >>> >>> On 15 June 2012 04:51, Lee, Yiu <[email protected]> wrote: >>> >>>> Hi Woj, >>>> >>>> Let me try to answer some of your questions: >>>> >>>> From: Wojciech Dec <[email protected]> >>>> Date: Thursday, June 14, 2012 9:07 AM >>>> To: Peng Wu <[email protected]> >>>> Cc: "[email protected]" <[email protected]>, Yong Cui < >>>> [email protected]> >>>> >>>> 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 <[email protected]> wrote: >>>> >>>>> Woj, >>>>> >>>>> On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec <[email protected]> >>>>> wrote: >>>>> > Peng, >>>>> > >>>>> > On 11 June 2012 20:38, Peng Wu <[email protected]> wrote: >>>>> >> >>>>> >> Woj, >>>>> >> >>>>> >> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec <[email protected]> >>>>> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >> > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
