We believe that there is a need for an alternate way of doing PD simply because the DHCP PD is not intrinsic to the stack and makes it unusable sometimes. ICMPv6 is intrinsic ( by intrinsic, I mean that is always available in the ipv6 stack implementations) and this proposal builds on the current ND process and hence is usable in almost all situations. This is not an replacement solution to dhcpv6 based solution. I am not talking about faster /slower here but the simplicity of having a always usable PD solution in all situations (and conforming to the PD requirements) without having to enable another protocol is what I think is the strong point of this proposal.
- Satya Rao Mobile Devices Technology Office Motorola Tel: 512-996-6781 Email: [EMAIL PROTECTED] > -----Original Message----- > From: Ralph Droms [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 23, 2006 6:24 AM > To: [EMAIL PROTECTED] > Cc: Durand, Alain; IETF IPv6 Mailing List > Subject: Re: Prefix Delegation using ICMPv6 > > Some more detailed responses in line... > > - Ralph > > On Aug 22, 2006, at 11:25 PM, <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> wrote: > > > Hi Alain, > > > > 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: > > > >> From: "Durand, Alain" <[EMAIL PROTECTED]> > >> Date: 2006/08/22 Tue PM 09:12:21 CDT > >> To: Syam Madanapalli <[EMAIL PROTECTED]>, > > IETF IPv6 Mailing List <ipv6@ietf.org> > >> Subject: RE: Prefix Delegation using ICMPv6 > > > >> "Currently proposed solution for IPv6 Prefix Delegation > is based on > >> DHCPv6 protocol. We believe that in certain network > topologies and > >> configurations where the CPE routers may not be capable or > >> configured > >> to use DHCPv6 and hence can not utilize the currently > proposed ipv6 > >> prefix delegation procedure. Therefore an alternate ipv6 prefix > >> delegation procedure that does not require or depend on > the DHCPv6 > >> protocol is needed." > >> > >> > >> > >> Could you please elaborate on the above rationale for this work? > > > > Alain, that seems to be a fair question. My first inclination is to > > direct you to an e-mail I'd posted to this workgroup about > four weeks > > ago (25Jul06, 0742EST, quoted below): > > > > "Good morning all. AFAIK, there is currently no defined way (other > > than via DHCPv6) to do IPv6 PD. It may well be that between > a PE and > > CE, DHCPv6 is neither required nor desired, but PD is. > > Without more detail about why DHCPv6 is "neither required nor > desired", it's hard to talk about your e-mail. I didn't pay > close attention; was there followup to your e-mail? > > > Over the past twelve months or so there has been some interest in > > ICMPv6 PD expressed to me. I'm considering submitting a > related draft, > > and seeking a co-author. Kindly reply off-line." > > > > While I welcome your question at the present time, I should > say that > > it would have also been welcomed when the above referenced mail was > > first sent. > > > >> > >> Using the DHCPv6 packet format, PD is a 2 packet exchange, and > >> nothing forces any implementation to use the rest of the DHCP > >> machinery. > > > >> The argument that CPE or routers do not implement DHCP is weak > >> because they do not implement this new mechanism either... > > > > IPv6 ND, the mechanism upon which our approach is based, is > > implemented virtually ubiquitously, if not entirely so. > Please see the > > draft to see what modifications we propose to accomodate the > > IPv6 PD requirement using ICMPv6.** > >> So if work need to be done, one could argue that implementing a > >> solution based on the DHCPv6 packet format is faster as > the mechanism > >> is already standardized... > > > > For "one to so argue" would be to do so incorrectly given > the above.** > > > > It is also true that DHCPv6 PD is already standardized (in fact, a > > full six months before the standard that defines IPv6 PD > requirements > > in the first place). > > WHile it is true that work on DHCPv6 PD began before the > requirements document, the timing of the publication of the > two documents is an artifact of the RFC publication process. > The PD requirements doc was fundamentally complete before the > DHCPv6 PD RFC was published. The IETF certainly considered > the PD requirements doc in the process of developing and > publishing DHCPv6 PD. > > > The argument that "implementing a solution based on the > DHCPv6 packet > > format is faster...", because DHCPv6 PD is standardized, is false. > > Maybe yes, maybe no. However, today we have a published > standard, that was developed through a process that > considered several alternatives (including ICMP) and which > has been implemented by multiple vendors. There is at least > one open source implementation available. These > implementations have been shown to be interoperable at the > TAHI interoperability tests and are deployed in production today. > > > Even if the "mechanism" to which you refer is vanilla DHCPv6, AFAIK > > there are NO vendors that implement the entire suite of DHCPv6 > > abilities. Do you know of any? > > Yes, there are several including an open source implementation. > > > Further, sometimes customer requirements drive innovation (yes > > sometimes, it is the other way around). > > But we haven't seen those customer requirements. > > > Customer requirements/requests/demands for an alternative (non > > DHCPv6-based) IPv6 PD mechanism are on the rise. We (co-authors and > > I) propose one such way to do it. > > > >> Again, they would not have to implement the whole DHCPv6 > machinery if > >> they do not want to. > > > > Perhaps you are correct in this instance, though with the ICMPv6 PD > > based approach, IPv6 PD could be done without it entirely. > > I don't understand the advantage to avoiding DHCPv6 entirely. > From the network operator's point of view, you've got to do > the same amount of work for any form of PD: fundamentally > configure the server with the prefixes to be assigned. As I > have argued before, we have > DHCPv6 PD implemented in IOS. It requires fewer than a > handful of CLI commands to configure and you would need the > same number of commands to configure ICMP PD. > > From the implementor's point of view, I won't get into an > argument about lines of code...but my observation is that > implementing DHCPv6 is not particularly onerous. > > > I implore you to read the draft in its entirety, as I/we do most > > sincerely welcome the technical review of our proposed mechanism. > > > > Best Regards, > > > > Tim Enos > > 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 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
