>From: Ralph Droms <[EMAIL PROTECTED]>
>Date: 2006/08/23 Wed AM 06:23:39 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
>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.
Hi Ralph, why is it hard to talk about the e-mail without "more detail"?
Do you believe that it is theoretically possible that DHCPv6 PD would be
"neither required nor desired"? It is here that I'd like to start this portion
of our conversation.
>I didn't pay close attention; was there followup to your e-mail?
No problem. There was some follow-up, primarily (off-line) from the folks that
are presently co-authors with me. There should also be a few related e-mails
posted to the IPv6 mailing list too.
>
>> 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.
That I truly didn't know, so thanks for the clarification!
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.
There's no doubt that DHCPv6 PD works, was carefully considered, and does have
an install base. We affirm that fully.
The ICMPv6 PD mechanism we propose and the extant DHCPv6 one are not mutually
exclusive. That there is already a defined standard does not inherently
preclude the introduction of another.
>
>> 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.
I think I know of the open source implementation of which you speak (is it
allowed/acceptable to name names?), and believe I know of at least one "major"
network equipment vendor that has an implementation.
In either case, how wide is the install/operational base? I'm also not sure
that customers "choose" the DHCPv6 PD mechanism because up to this point that
is the only choice they have been offered.
We'd merely like to offer the ICMPv6 PD mechanism to those who, for whatever
reason, desire and/or require it).
>
>> Further, sometimes customer requirements drive innovation (yes
>> sometimes, it is the other way around).
>
>But we haven't seen those customer requirements.
Is "we" those of us on this list? Sorry... :^\ Anyhow, I believe at least part
of the reason some have not seen those customer requirements is that they
aren't aware that they could have a choice even if they wanted it.
I also believe that customer requirements aren't always necessarily for DHCPv6
PD specifically, rather for SOME way to to IPv6 PD (which of course up to this
point has only been the DHCPv6 way).
>> 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.
I'm truly sorry about the misunderstanding on this one... Nobody is proposing
an inherent advantage to avoiding DHCPv6 entirely. The point being addressed
was just above this text in this e-mail: "...they would not have to implement
the whole DHCPv6 machinery if they do not want to."
That said, I'd say it's also true that if something is not required, it's OK
(and perhaps good as well) to not include it.
If for example you have requesting nodes (RNs) that are using SLAAC to get
their addresses and do not require any other configuration info, DHCPv6 would
probably not need to be run just for the sake of PD. This I believe is a case
where the ICMPv6 PD approach is informed.
>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.
We definitely agree on that point.
>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.
AFAIK it is implemented in IOS on a limited # of platforms (such as the 7301)
but not others (such as the GSR). Is it now implemented across all hardware
platforms that run IOS?
>
> 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.
Agreed. Again, we are agreeing that DHCPv6 PD works, is standardized, and has
an install/operational base already.
I think it's also safe to say that to implement our proposed ICMPv6 PD
mechanism would be rather unobtrusive code-wise. It's not either/or.
Tim
Rom 8:28
>
>> 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
--------------------------------------------------------------------
