>From: Ralph Droms <[EMAIL PROTECTED]> >Date: 2006/08/23 Wed AM 05:43:09 CDT >To: "<[EMAIL PROTECTED]>" <[EMAIL PROTECTED]> >Cc: "Durand, Alain" <[EMAIL PROTECTED]>, Syam Madanapalli <[EMAIL PROTECTED]>, IETF IPv6 Mailing List <ipv6@ietf.org> >Subject: Re: Prefix Delegation using ICMPv6
>Tim - I don't think I made my point clear. SLAAC, DHCP and manual >addressing are all very different ways to accomplish the same result, >stemming from very different requirements: > >SLAAC - all nodes on a link share the same prefixes; advertising > device sends a single message with configuration information >for > all nodes; protocol communications are essentially one way > (advertiser->node); network operations don't explicitly control > specific addresses assigned to each node >DHCP - network operations communicates one-to-one and interactively > with each node; network operations has information about > addresses assigned to each node >manual- no interaction with network operations; node administrator >chooses > addresses assigned to node Hi Ralph, your point is very clear, and I definitely agree with what you are saying. Sorry for any misunderstanding. My original related point was/is to address the fact THAT there is historical precedent for doing something (in my example, IPv6 node addressing) in >1 IETF standardized way, not WHY there is (also that it is good that there is). Using similar logic I/we truly would like to have the technical merits of our proposal considered by this body. > >Prefix delegation has a pretty common set of requirements, based on >RFC 3769. Using RFC 3769 as our guide, we seek to offer a PD mechanism (which happens to use ICMPv6). >I didn't see in the ICMP PD draft (which I will reread more carefully as soon >as I recover from being away from my office for a week) I myself am getting over a virtual lack of sleep, so I can sympathize with the need for recovery time! :) >any significant differentiation in requirements on the scale of those among >SLAAC, DHCP and manual address configuration. I'm not sure there is significant differentiation in requirements, especially along those scales. Given the way I read RFC 3769 however, I'm thinking there might not need to be (rather that whatever IPv6 PD mechanism that is proposed meets the requirements). Tim Rom 8:28 > > >On Aug 23, 2006, at 2:44 AM, <[EMAIL PROTECTED]> ><[EMAIL PROTECTED]> wrote: > >>> From: Ralph Droms <[EMAIL PROTECTED]> >>> Date: 2006/08/22 Tue PM 11:04:04 CDT >>> To: [EMAIL PROTECTED] >>> Cc: "Durand, Alain" <[EMAIL PROTECTED]>, >> Syam Madanapalli <[EMAIL PROTECTED]>, >> IETF IPv6 Mailing List <ipv6@ietf.org> >>> Subject: Re: Prefix Delegation using ICMPv6 >> >>> 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? >> >>> Don't forget manual assignment, as well. DHCPv6 for >>> other information (RFC 3736) has nothing to do with addressing. >> >> Not sure why you mention manual assignment, as the point was about >> IETF standardized ways to do host addressing. Regarding RFC 3736, >> you are correct (good catch). >> >> The point that there is ALREADY at least one such case (node >> addressing) for which there is more than one standardized IETF way >> is irrefutable. >> >> 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 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). >> >> 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. =^) >> >>> All I've seen in a quick read of your doc >> >> As I value your technical input, I'd ask you to read the doc in its >> entirety and provide technical feedback. >> >>> 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. >> >>> by pointing out that any new PD protocol would also, by >>> definition, not be >>> implemented already in any hosts, so the advantage is minimal. >> >> ICMPv6 PD isn't necessarily as new as might be implied. Please see >> the draft to understand the modifications to RS and RA messages we >> propose. >> >> Further I would contend that there isn't as wide an install base >> for DHCPv6 PD as might be implied here. >> >> Even further, even if there was it would still not preclude the >> presence of another IPv6 PD mechanism. >> >>> >>> We had a long discussion about PD alternatives some time before the >>> DHCPv6 PD RFC was published. >> >> I believe there was, yes. >> >>> The consensus was, at that time, that the protocol >messages and >>> amount of "work" required for PD was >pretty much the same >>> regardless of how the messages >are carried (DHCP, ICMP, etc.), >> >> I would tend to agree. >> >>> and there was also consensus that PD seemed a logical extension of >>> the >address assignment in DHCP, so that consensus was the >>> motivation for DHCPv6 PD. >> >> Are you arguing that said consensus from 2003 (when 3633 was >> published) ends the debate on IPv6 PD? >> >> I respect the fact that you are a co-author of both the DHCPv6 PD >> spec (RFC 3633), and IPv6 PD requirements spec (RFC 3769). >> >> If only DHCPv6 PD is to be standardized by the IETF, please explain >> why RFC 3769 was ever written. >> >> To me, implicit in the publication of 3769 is the notion that ANY >> mechanism that purports to do IPv6 PD needs to meet said >> requirements. We believe our mechanism both does that, and >> satisfies many customer requirements as well. >> >> If consideration of IETF standardization for alternate IPv6 PD >> mechanisms is not allowed (including technical debate of our >> draft), I'd respectfully ask you to tell me why 3769 was written in >> the first place. >> >> Best Regards, >> >> Tim >> Rom 8:28 >> >>> >>> - Ralph >>> >>> On Aug 22, 2006, at 11:48 PM, <[EMAIL PROTECTED]> wrote: >>> >>>>> From: "Durand, Alain" <[EMAIL PROTECTED]> >>>>> Date: 2006/08/22 Tue PM 10:31:10 CDT >>>>> To: [EMAIL PROTECTED], Syam Madanapalli >>>>> <[EMAIL PROTECTED]>, >>>> IETF IPv6 Mailing List <ipv6@ietf.org> >>>>> Subject: RE: RE: Prefix Delegation using ICMPv6 >>>> >>>>> >>>>>> Thanks for the quick e-mail. As one of the co-authors, I'd in >>>>>> turn like to reply (and state that ICMPv6 PD is ANOTHER way >>>>>> to do IPv6 PD, NOT a replacement for the existing mechanism). >>>>>> FWIW, please see comments in-line: >>>>> >>>>> This is probably the crux of the issue. >>>> ... >>>>> I believe that having multiple IETF standardized ways to achieve >>>>> the same thing is a bad idea. >>>> >>>> Hi Alain, I respect your opinion but believe differently. BTW, >>>> there is already at least one such instance of their being >>>> "multiple IETF standardized ways to achieve" IPv6 addressing for >>>> nodes. SLAAC (RFC 2462[bis]) and DHCPv6 (RFC 3315), AND DHCPv6 >>>> 'lite' (RFC 3736). >>>> >>>> Tim >>>> Rom 8:28 >>>> >>>>> >>>>> - Alain. >>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------