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
