Subject: Re: Prefix Delegation using ICMPv6

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Aug 2006 18:31:05 -0400

Tim - The answer to your exact question is, of course, yes.  But, in  
my opinion, that question is not the right starting point for our  
conversation.

A better question to start with, which we certainly ought to ask as  
members of an engineering organization like the IETF, is: "Is there a  
sufficiently large set of scenarios and use cases where the  
requirements cannot be met by DHCPv6 PD to warrant the investment of  
resources to design, specify, publish, implement and test an entirely  
new protocol or protocol extension?".

The IETF has spent far too much effort in defining theoretically  
possible protocols.

- Ralph

On Aug 23, 2006, at 5:59 PM, <[email-masked]> wrote:
> [...]
> 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.

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

---

From: "Rao Satyanarayana-W60007" <[email-masked]>
Date: Wed, 23 Aug 2006 18:54:07 -0400

Ralph,
Implementation and test effort is always there whether it is a existing
protocol or a new protocol to catch implementation specific bugs. Even
if one licenses a particular implementation, there is always testing
involved though the effort can be less focused on testing the licensed
components but the integrated system. If the proposal has merit and
looks appealing, implementations will come.

What we would like to know now is are there any bugs in the proposal
being specified? I think the questions should be is there merit in the
proposal? Does it basically work? What needs to be modified for it to
work? Our claim is that there are situations and configurations where
DHCPv6 may not be enabled or available and hence PD process can not
depend on dhcp protocol. If the PD mechanism can be run utilizing more
basic and fundamental components of the ipv6 stack, why not? If it
basically works, and if implementers believe that it is simpler and easy
to implement and deploy, it will get used. It does not propose to
replace the dhcpv6 based 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 5:31 PM
> To: [email-masked]
> Cc: Durand, Alain; IETF IPv6 Mailing List
> Subject: Re: Prefix Delegation using ICMPv6
> 
> Tim - The answer to your exact question is, of course, yes.  
> But, in my opinion, that question is not the right starting 
> point for our conversation.
> 
> A better question to start with, which we certainly ought to 
> ask as members of an engineering organization like the IETF, 
> is: "Is there a sufficiently large set of scenarios and use 
> cases where the requirements cannot be met by DHCPv6 PD to 
> warrant the investment of resources to design, specify, 
> publish, implement and test an entirely new protocol or 
> protocol extension?".
> 
> The IETF has spent far too much effort in defining 
> theoretically possible protocols.
> 
> - Ralph
> 
> > 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

---

From: <[email-masked]>
Date: Wed, 23 Aug 2006 16:59:21 -0500 (CDT)

>From: Ralph Droms <[email-masked]>
>Date: 2006/08/23 Wed AM 06:23:39 CDT
>To: "<[email-masked]>" <[email-masked]>
>Cc: "Durand, Alain" <[email-masked]>, 
	Syam Madanapalli <[email-masked]>, 
	IETF IPv6 Mailing List <[email-masked]>

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

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

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Aug 2006 16:59:35 -0700

Rao Satyanarayana wrote:
> ...
> being specified? 

Routers do not currently *send* RS messages. 
Bug == "ICMPv6 is an integral part of the IPv6 stack and
   hence the proposed mechanism for Prefix Delegation does not require
   any additional components or applications on either the requester or
   the delegator for prefix delegation purposes"

> I think the questions should be is there merit in the
> proposal? 

That is true, but your section 3 does not establish that merit. 

> Does it basically work? 

Probably.

> What needs to be modified for it to work?

The fundamental ND implementation in the CPE router.

> Our claim is that there are situations and configurations where
> depend on dhcp protocol.

You assert that without attribution. As Ole pointed out you end up
reinventing DHCP, but masking it behind an ICMP packet format.

>  If the PD mechanism can be run utilizing more
> basic and fundamental components of the ipv6 stack, why not? 

That would be fine if those components actually exist. The ability to
receive RS and send RA is not the same as what this proposal calls for.

> If it

The state of DHCP-PD is somewhat irrelevant. The point is that multiple
reviews of the document will have to be done before it makes it to RFC. You
appear to be unwilling to expand on the fundamental justification, and would
rather burn list bandwidth arguing your right to build something different. 

You need to explain why the DHCP-PD packet format is insufficient, or
explain how your state machine sitting behind ICMP will be significantly
simpler than a light-weight DHCP client. 'Significant customer demand' is an
important metric, but it is not the only one. Start by showing some
willingness to actually work within the IETF process by rev'ing the draft to
put substantive detail in section 3.

Tony

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 23 Aug 2006 17:12:23 -0700

Tim,

I took a look at the I-D and it reads well. I see that you
(and the co-authors) are asking RSs to carry PIOs by way of
requesting specific prefixes, and that you are asking for new
flag bits (the 'P' bit in the RS message 'Reserved' field and
the 'D' bit in the PIO 'Reserved1' field) which would qualify
this as an RS/RA-based prefix delegation mechanism.

But then, I see in Sections 5.1 and 5.2 that the specification
is also asking for new ICMPv6 message types, so the mechanism
is apparently not implemented via RS/RA messages alone. Is
there a way to do this with RS/RA alone, or do you also need
the extra ICMPv6 messages?

Fred
[email-masked]

---

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

Rao Satyanarayana-W60007 wrote:
> Ralph, Implementation and test effort is always there whether it is a
>  existing protocol or a new protocol to catch implementation specific
>  bugs. Even if one licenses a particular implementation, there is 
> always testing involved though the effort can be less focused on 
> testing the licensed components but the integrated system. If the 
> proposal has merit and looks appealing, implementations will come.
> 

Come on, I am not here to debug a specification, no?

> I think the questions should be is there merit in the proposal?

The proposal has merit.  ICMPv6 could carry prefixes.

> Does it basically work?

It could.

> What needs to be modified for it to work?

What do you think?

> DHCPv6 may not be enabled or available and hence PD process can not 

Which are those situations?

DHCPv6 software is widely available.   Most run in userspace.  Most
parts of ICMPv6 on most platforms runs in kernel space.  It's easier to
implement in userspace.

What are the situations you think of?

> If the PD mechanism can be run utilizing more basic and fundamental 
> components of the ipv6 stack, why not? If it basically works, and if 
> implementers believe that it is simpler and easy to implement and 
> deploy, it will get used.

What is the potential scope of this deployment?  How large?  Any
interoperability needs between any two manufacturers.

> It does not propose to replace the dhcpv6 based proposal.

What are the situations where DHCPv6-PD does work ok?

Alex

---

From: "Rao Satyanarayana-W60007" <[email-masked]>
Date: Thu, 24 Aug 2006 10:44:35 -0400

Inline.

- Satya Rao

> From: Petrescu Alexandru-AAP021 
> Sent: Thursday, August 24, 2006 7:35 AM
> To: Rao Satyanarayana-W60007
> Cc: Ralph Droms; [email-masked]; Durand, Alain; IETF 
> IPv6 Mailing List

I do not know what you mean by debug? Did anybody not say if a proposal
you may have submitted may or not work in some or certain cases?. Did
they not comment on the plus and minus points of the proposal? That's
what I mean by bugs in the proposal.

-satya

---

From: "Rao Satyanarayana-W60007" <[email-masked]>
Date: Thu, 24 Aug 2006 10:52:31 -0400

Hi Fred,
Well, the intention is to use RS/RA for PD but use icmp type/code for
any error messaging for the PD process between the requesters and
delegators.

Thanks,

- Satya Rao

> From: Templin, Fred L [mailto:[email-masked]] 
> Sent: Wednesday, August 23, 2006 7:12 PM
> Cc: IETF IPv6 Mailing List
> Subject: RE: Re: Prefix Delegation using ICMPv6
> 
> Tim,
> 
> But then, I see in Sections 5.1 and 5.2 that the 
> specification is also asking for new ICMPv6 message types, so 
> the mechanism is apparently not implemented via RS/RA 
> messages alone. Is there a way to do this with RS/RA alone, 
> or do you also need the extra ICMPv6 messages?
> 
> Fred

---

From: Thomas Narten <[email-masked]>
Date: Thu, 24 Aug 2006 11:26:19 -0400

> would be "neither required nor desired"?

Please make the case here (using technical justifications). Basic the
need for a new protocol on theoretical possibilities has repeatedly
been problematic in the IETF.

> It is here that I'd like to start this portion of our conversation.

I would not. Starting off with the assertion that "its theoretically
possible that the existing protocol isn't desired, therefore we should
invent a new one" is a complete non-starter for the IETF.

We do engineering here, presumably solving real problems, where the
existing solutions are inadquate or non-existent.

> There's no doubt that DHCPv6 PD works, was carefully considered, and
>  does have an install base. We affirm that fully.

In which case, there would appear to be no need to talk about a new
protocol, since you appear to admit that an existing standard does
solve the problem.

If you want this group to consider a new protocol, start by convincing
us that:

1) there is a real (not theoretical) problem that needs solving, and

2) the existinFrom [email-masked] Thu Aug 24 11:26:59 2006
To: [email-masked]
Comments: In-reply-to <[email-masked]>
	message dated "Wed, 23 Aug 2006 16:59:21 -0500."
Date: Thu, 24 Aug 2006 11:26:19 -0400
From: Thomas Narten <[email-masked]>
Cc: "Durand, Alain" <[email-masked]>,
	IETF IPv6 Mailing List <[email-masked]>, Ralph Droms <[email-masked]>
Subject: Re: Prefix Delegation using ICMPv6 

> would be "neither required nor desired"?

Please make the case here (using technical justifications). Basic the
need for a new protocol on theoretical possibilities has repeatedly
been problematic in the IETF.

> It is here that I'd like to start this portion of our conversation.

I would not. Starting off with the assertion that "its theoretically
possible that the existing protocol isn't desired, therefore we should
invent a new one" is a complete non-starter for the IETF.

We do engineering here, presumably solving real problems, where the
existing solutions are inadquate or non-existent.

> There's no doubt that DHCPv6 PD works, was carefully considered, and
>  does have an install base. We affirm that fully.

In which case, there would appear to be no need to talk about a new
protocol, since you appear to admit that an existing standard does
solve the problem.

If you want this group to consider a new protocol, start by convincing
us that:

1) there is a real (not theoretical) problem that needs solving, and

2) the existing mechanisms do not address it properly, and

3) the best way to address the problem is with a new mechanism (and
   it's better than other proposed ways of fixing the problem).

At this point, AFAIAC, you have not gotten past either points 1) or 2).

Thomas

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Aug 2006 08:29:14 -0700

> any error messaging for the PD process between the requesters and

OK, I see now. When Tim first contacted me he came across with
a certain sense of naivety that doesn't seem to be supported
by his interactions here, and he led me to believe that he was
talking about new ICMP messages for prefix delegation. Then
later, when I suggested to Tim that RS/RA could be used for
the PD, he told me that yes in fact that was what he would
be proposing and he ended the discussion with what I could
only describe as a certain sense of self-righteousness.

Now we come to find out that its *both* RS/RA *and* two new
ICMP messages. That's a lot of messages, and it might lead one
to ask that if there needs to be two new ICMP messages why not
use them for the prefix delegation too and avoid overloading
RS/RA and tweaking specs? (But then I guess the proposal
wouldn't be any much different than those that were offered
several years ago?)

Fred
Matthew 7:5  

Thanks,

- Satya Rao

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 24 Aug 2006 17:46:35 +0200

Rao Satyanarayana-W60007 wrote:
> I do not know what you mean by debug? Did anybody not say if a 
> proposal you may have submitted may or not work in some or certain 
> cases?. Did they not comment on the plus and minus points of the 
> proposal? That's what I mean by bugs in the proposal.

I understand.  I thought you were looking for protocol bugs comparing to
how would it fit into ICMPv6 types, etc.  This may come later, it's too
early now.  Sorry for misunderstanding.

Developing a protocol takes some time and this is the first time this 
particular draft is posted.

Alex