>From: Jari Arkko <[EMAIL PROTECTED]> >Date: 2006/08/23 Wed AM 07:24:59 CDT >To: [EMAIL PROTECTED] >Cc: Ralph Droms <[EMAIL PROTECTED]>, IETF IPv6 Mailing List <[email protected]> >Subject: Re: Prefix Delegation using ICMPv6
>Tim, > >>Given that there is a historical precedent for being able to do something via >>more than one standardized IETF way, I'd suggest that IPv6 PD is another such >>case where such an approach is warranted. >>... >>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). >> >>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. >> >>BTW, what would be your burden of proof in what you are asking?** I'd not >>want to be chasing my technical tail. =^) >> >> >As Brian pointed out there are some design principles >that the IETF uses. We believe interoperability is >very valuable. Hi Jari, being part of that 'we', I definitely agree. I'd also say I believe that the ICMPv6 PD mechanism we (co-authors and I) propose would be interoperable. >We do not create alternative ways to >do the same thing, because doing so will >burden >implementors with additional complexity and reduces >the likelihood >that nodes can communicate >successfully. Picking a common way to do something >is >the fundamental idea behind standards. In general that is true. However, for things such as IPv6 node addressing we have DHCPv6 and SLAAC. The point is THAT there is >1 way to do something (in this case IPv6 node addressing). There are certainly cases where nodes that get their IPv6 address info from each method reside on the same link. Not wanting to debate how much complexity is too much, I'd say that having both DHCPv6 and SLAAC nodes on the same link is not a problem (have seen it work myself). > >Of course, in some cases we actually do have to >create alternative mechanisms >when the situation >calls for it. Definitely agreed. >For instance, the requirements are very different, e.g. if a customer requires that IPv6 PD be done, but DHCPv6 not be used? When posting my original e-mail to the list, this is one thing I was considering. >we have new needs that fundamentally cannot be met by the existing mechanisms, >and so on. IPv6 node addressing can be done via DHCPv6 as well as SLAAC. I'd of course also agree that while IPv6 PD can be (and is done well) by DHCPv6, it can be done via ICMPv6 as well. >And we all want to enable the things that the >customers want to do. So their >requirements are >important, but some engineering may be needed before >we >decide what solution should be employed. Absolutely Jari, agreed. We (co-authors and I) are seeking to address customer requirements for IPv6 PD in cases where DHCPv6 PD is not required. We understand that some engineering may be needed in order to implement our proposed solution. We truly do seek and value input on our draft proposal. In reviewing our draft, how much engineering do you suppose would be required to deploy the proposed ICMPv6 PD mechanism? > >I would suggest that you focus on the WHY question >and proceed with a rational analysis of whether >existing mechanisms are or are not sufficient for >your needs. We shall definitely continue to look at the WHY question, your point is well taken. One case in which DHCPv6 might not be necessary (though perhaps sufficient) is a case where the customer end-nodes get their addressing information from SLAAC, and do not require any other automated configuration be done. In this instance, it seems unnecessary to enable DHCPv6 just for the sake of PD. An ICMPv6-based PD mechanism such as the one we propose would seem to fit here. >This analysis should avoid arguments such as "Devices >do not have X, >therefore we must design Y". Such >arguments do not provide any information on >what the >reasons for not having X were, I'm pretty sure I see what you're saying, though not certain I completely concur. We as solution providers always need to know WHY our customers do not have X. Sometimes, THAT they don't have X is all we need to know IMO. >whether designing Y will alleviate those concerns, In the case where IPv6 PD is required but DHCPv6 is not an option (perhaps only because of customer policy, perhaps for another reason), "Y" in this case would alleviate those concerns. >and whether the benefits from Y are a good tradeoff >with respect to the costs >of supporting both X and Y >in everyone's products over the next N years. How much of a support cost increase do you see in the case where it's possible to do both DHCPv6 PD and ICMPv6 PD? I don't see much if any. I'm honestly not seeing when if ever (for example) an ISP and customer would have both mechanisms running on the same link. > >And the burden of proof is on the side of those >who want something new; you should convince >the community that it is indeed necessary. That's what we're trying to do, and I agree with you. > >--Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
