[EMAIL PROTECTED] wrote: > >Tim - SLAAC and DHCPv6 are fundamentally different ways to assign > >addresses. > > Ralph thanks, I'm glad you (realize that) see my point. There is more than > one IETF standardized way to do host addressing. Do you believe it is > good that more than one IETF standardized way to do host addressing > exists?
I believe you are mixing points here. Yes different mechanisms exist, but they deal with different scenarios. Your draft does not really explain what is different about the deployment scenario that justifies a new mechanism. Section 3 has that title, but I would not be able to explain why this is really any different after reading that text. > ... > > > >I would be interested in seeing more detail about specific topologies > >and scenarios in which DHCPv6 PD is inadequate.** > > I'd like to repeat my/our contention that ICMPv6 PD is not meant to > replace DHCPv6 PD. The two are not mutually exclusive. > > In some cases, customers may wish to have an alternative to the existing > mechanism (WHY they wish to have it is a separate question, THAT they do > is an issue which helped inform the writing of our draft). I am not opposed to doing something different, but there needs to be something more than a wish to back it up. > > Customer requirements are often what drive innovation (sometimes the other > way around). Over the past few years, more customers have expressed > interest in/requirement for an alternative to DHCPv6 PD. Our draft based > upon ICMPv6 is one such proposed solution. ICMPv6 is a fine alternative. The question is why is the DHCP approach inadequate? That will need to be answered clearly if we are going to make sure the proposed ICMPv6 approach actually meets the need. > > BTW, what would be your burden of proof in what you are asking?** I'd not > want to be chasing my technical tail. =^) Explain how to evaluate that the proposed approach actually meets a detailed need. > ... > >is the argument that some hosts may not implement >DHCPv6, so there is a > need for some way to accomplish >PD without DHCPv6. But I think Alain > refuted that argument > > Ralph, I think the point was not refuted. > > As I'd mentioned, our approach is based upon ND, which is at least > virtually ubiquitous in IPv6 implementations, if not entirely so. I think their point is that supporting this option requires new code in any case. Stepping back, the debate seems to be over the bits-on-the-wire format, while the architectural issues are that the requesting router needs to have a mechanism for acquiring a prefix and the delegating router needs to have a mechanism for responding to the request and tracking what is active. I believe the state machinery to support the architectural points is essentially the same regardless of the bits-on-the-wire format. Your proposal is essentially asking to chew up reserved flag bits to be able to reuse some bits-on-the-wire code in the requesting and delegating routers. Realistically it only reuses RS/RA code in the delegating router since there is no existing expectation that a requesting router would implement sending an RS message. Your section 3 tends to imply that the primary justification is that some requesting routers don't implement DHCP. This falls flat when they don't implement sending an RS either... Fundamentally this draft needs to explain why a new format is *needed* rather than just desired. The current arguments are cast as a mechanism, though it appears this is really just a format issue. In the case that the state machinery in the requesting & delegating routers are identical for either packet format, the proposal needs to be explicit as to what the DHCP-PD approach lacks and how this fulfills the need. In the case that the state machinery is actually different (and I personally can't see how it could be, but I am willing to be open minded), the proposal needs to spell out something more than 'the lack of a DHCP client' since that is not really necessary for the purposes of exchanging DHCP-PD format messages. > ... Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
