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? - 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. - 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). - DHCPv4 servers need to be modified to take into account IPv6.
-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
