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
