Subject: Re: RE: Prefix Delegation using ICMPv6

From: <[email-masked]>
Date: Tue, 22 Aug 2006 22:25:32 -0500 (CDT)

X-Mailman-Version 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).
>
>The argument that "implementing a solution based on the DHCPv6 packet format is faster...", because DHCPv6 PD is standardized, is false.
>
>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?
>
>Further, sometimes customer requirements drive innovation (yes sometimes, it is the other way around). 
>
>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 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
>>[email-masked]
>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>>--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Aug 2006 07:23:39 -0400

Some more detailed responses in line...

- Ralph

On Aug 22, 2006, at 11:25 PM, <[email-masked]>  
<[email-masked]> 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-masked]>
>> Date: 2006/08/22 Tue PM 09:12:21 CDT
>> To: Syam Madanapalli <[email-masked]>,
> 	IETF IPv6 Mailing List <[email-masked]>
>> 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.
>
> 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.**
> 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.

> 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.
>
> 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.
>>
>>
>>
>>

---

From: "Rao Satyanarayana-W60007" <[email-masked]>
Date: Wed, 23 Aug 2006 11:24:05 -0400

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-masked]

> -----Original Message-----
> From: Ralph Droms [mailto:[email-masked]] 
> Sent: Wednesday, August 23, 2006 6:24 AM
> To: [email-masked]
> Cc: Durand, Alain; IETF IPv6 Mailing List
> Subject: Re: Prefix Delegation using ICMPv6
> 
> > 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:
> >
> > direct you to an e-mail I'd posted to this workgroup about 
> four weeks 
> > ago (25Jul06, 0742EST, quoted below):
> >
> > 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.
> 
> desired", it's hard to talk about your e-mail.  I didn't pay 
> close attention; was there followup to your e-mail?
> 
> > 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...
> >
> > implemented virtually ubiquitously, if not entirely so. 
> Please see the 
> > draft to see what modifications we propose to accomodate the
> >> 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...
> >
> 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.
> 
> >> Again, they would not have to implement the whole DHCPv6 
> machinery if 
> >> they do not want to.
> >
> 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.
> 
> >> Administrative Requests: 
> https://www1.ietf.org/mailman/listinfo/ipv6
> >>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 24 Aug 2006 14:29:23 +0200

Hi Satya and icmpv6-pd draft co-authors,

Rao Satyanarayana-W60007 wrote:
> 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

I understand there may be a need for ICMPv6-PD, but there's also a need
to motivate it better than just that.

Why do you need PD in first place?  (regardless of DHCP or ICMP based).
  Is it for a DSL-like deployment for users in their SOHO or their house
to get an IPv6 prefix and distribute to the other PCs in house?

Is it for a mobile phone to connect to a cellular-like wireless
provider?  There wouldn't be a need for a prefix in that case.

Is it for a netlmm-like deployment where prefix-per-mobile seems to be
the guiding line?  In that deployment there's no need to assign an
entire prefix to the mobile, just the address has to be derived from a
specific prefix.  I.e. a netlmm mobile wouldn't need to propagate
further sub-prefixes.

Is it for a mobile phone acting as a mobile router (NEMOv6) and needing
to offer addresses to other hosts in its moving network?

Please explain why do you need PD in first place (regardless of DHCP or
PD).  This is stuff that has already been discussed in all the above
contexts.  What is _your_ context?

> ( by intrinsic, I mean that is always available in the ipv6 stack 
> implementations)

This makes little sense to a wide various audience.  There are available
IPv6 stack implementations that do today DHCPv6 and PD.  They are more
available than others (depending where from you look at it).

Some Mobile Devices have built-in IPv6 ICMPv6 stacks that are hardly
modifiable, for which it is much much easier to modify DHCPv6 to PD.

Please describe _your_ context and acknowledge where DHCPv6-PD _could_ work.

Alex