Subject: RE: Prefix Delegation using ICMPv6

From: "Durand, Alain" <[email-masked]>
Date: Tue, 22 Aug 2006 22:12:21 -0400

"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?

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... 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... Again, they
would
not have to implement the whole DHCPv6 machinery if they do not want to.

   - Alain.

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

---

From: [email-masked]
Date: Wed, 23 Aug 2006 00:32:20 -0500 (CDT)

Good evening ais 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

---

From: [email-masked]
Date: Wed, 23 Aug 2006 00:32:20 -0500 (CDT)

Good evening all, my apologies to the list (the original message doesn't appear to have gone through the first time).

>From: [email-masked]
>Date: 2006/08/22 Tue PM 10:25:32 CDT
>To: "Durand, Alain" <[email-masked]>, 
	Syam Madanapalli <[email-masked]>, 
	IETF IPv6 Mailing List <[email-masked]>
>Subject: Re: RE: Prefix Delegation using ICMPv6

>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
>
>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. 
>
>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.
>
>>
>>IETF IPv6 working ll, my apologies to the list (the original message doesn't appear to have gone through the first time).

>From: [email-masked]
>Date: 2006/08/22 Tue PM 10:25:32 CDT
>To: "Durand, Alain" <[email-masked]>, 
	Syam Madanapalli <[email-masked]>, 
	IETF IPv6 Mailing List <[email-masked]>
>Subject: Re: RE: Prefix Delegation using ICMPv6

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

group mailing list

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 23 Aug 2006 14:26:19 -0400

I think another point is that if they're concerned about having to run a
separate DHCPv6 client "process" to handle PD (as was I think discussed
in an earlier email), there's nothing in the DHCPv6 specification that
says you can not implement DHCPv6 in the IPv6 kernel. If PD is integral
to your network architecture, why not put the implementation there?

You can also have it in both places (though of course likely not the
best design if both are doing PD) -- just be sure to allow applications
to also use the port and deliver all (or at least those not "accepted"
by the kernel layer) to those applications.

- Bernie

---

From: <[email-masked]>
Date: Wed, 23 Aug 2006 14:13:49 -0500 (CDT)

Hi Brian,

Thanks also for replying; my apologies for my tardy response:

>From: Brian E Carpenter <[email-masked]>
>Date: 2006/08/23 Wed AM 03:09:42 CDT
>To: [email-masked]
>Cc: "Durand, Alain" <[email-masked]>, 
>Subject: Re: Prefix Delegation using ICMPv6

>[email-masked] wrote:
>>>Date: 2006/08/22 Tue PM 10:31:10 CDT
>>>To: [email-masked], Syam Madanapalli <[email-masked]>, 
>> 
>>>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. 
>
>However, Alain is only citing a design principle that we often use when
>deciding whether a new idea is valuable. You'll find it in RFC 1958:
>
>    3.2 If there are several ways of doing the same thing, choose one.
>    If a previous design, in the Internet context or elsewhere, has
>    successfully solved the same problem, choose the same solution unless
>    there is a good technical reason not to.  Duplication of the same
>    protocol functionality should be avoided as far as possible, without
>    of course using this argument to reject improvements.

Good reference, Brian. I'm also thinking that RFC 1958 is Informational in status, thus to quote from RFC 2026 (section 4.2.2):

"An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation...  The Informational designation is intended to provide for the timely publication of a
very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section 4.2.3)."

Given that "does not represent an Internet community consensus or recommendation" clause (and the Informational status of the RFC), I'd say that there is an extant way to do IPv6 PD is not inherently to say that we (IPv6 WG in this instance) ought not consider alternative IPv6 PD mechanisms.

>
>but it certainly wasn't original then. In other words, you have to
>supply "a good technical reason" to add new functions.

One technical reason that motivates our ICMPv6 PD proposal is (quoting from an earlier e-mail from Syam):

"Also, the subnet model that NetLMM WG wants to choose is to have a unique prefix for each MN. These extensions for RS/RA allows NetLMM hosts to be able to get unique prefixes in a better compared to current RS/RA messages."

 Given that
>DHCP has become pretty much universal in IPv4 deployment, I'm having
>a hard time seeing why the same won't happen for IPv6.

>      Brian

Best Regards,

Tim
Rom 8:28

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

---

From: <[email-masked]>
Date: Wed, 23 Aug 2006 13:46:13 -0500 (CDT)

>From: Ole Troan <[email-masked]>
>Date: 2006/08/23 Wed AM 12:57:16 CDT
>To: Syam Madanapalli <[email-masked]>
>Cc: IETF IPv6 Mailing List <[email-masked]>

>I don't understand the rationale for this work either.

Hi Ole, thanks for the reply. Sorry it took me so long to get back to you.

>
>the first PD proposal (by Brian Haberman) was indeed based on using
>ICMP as transport. separate message types instead of
>piggy-backing on RS/RA though.

Yes, absolutely. The Haberman draft is just one of three such docs of which I'm aware:

1.draft-haberman-ipngwg-auto-prefix-02.txt
2.draft-bykim-ipv6-hpd-01.txt
3.draft-arunt-prefix-delegation-using-icmpv6-00.txt

>as we continued to develop that
>mechanism we realised that we were pretty much reinventing the DHCP
>protocol machine. that realisation led to specifying it as an DHCP
>option instead of as a new protocol.

I see what you're saying. I should say that our proposed PD mechanism is more representative of the extension of RS/RA functionality than the creation of an entirely new protocol.

>
>a technical comment on your proposal; how do you plan to support
>shared links with multiple requesting routers?

Have you had an opportunity to read our proposal in its entirety? Here is a cut from our text (section 4, page 5) which I hope will answer that question:

"There may be cases where more than one DR is present on the link shared with the RN.  In cases such as this, the RN will choose as its DR the PD capable router whose solicited RA it received first.

Subsequent RAs received from the remaining on-link PD-capable routers will be ignored."

>RAs are typically multicast.

Yes and no. An unsolicited RA is typically multicast, whereas a solicited RA would be unicast.

Best Regards,

Tim
Rom 8:28

>/ot

---

From: <[email-masked]>
Date: Wed, 23 Aug 2006 18:19:29 -0500 (CDT)

>From: Rao Satyanarayana-W60007 <[email-masked]>
>Date: 2006/08/23 Wed PM 05:54:07 CDT
>To: Ralph Droms <[email-masked]>, [email-masked]
>Subject: RE: Prefix Delegation using ICMPv6

Satya,

You put this so much better than I have, I think. Thank you!

Tim
Rom 8:28

>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
>> Cc: Durand, Alain; IETF IPv6 Mailing List
>> 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.
>> 
>>

---

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

>From: Ralph Droms <[email-masked]>
>Date: 2006/08/23 Wed AM 05:43:09 CDT
>To: "<[email-masked]>" <[email-masked]>

>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-masked]>  
><[email-masked]> wrote:
>
>>> From: Ralph Droms <[email-masked]>
>>> Date: 2006/08/22 Tue PM 11:04:04 CDT
>>> 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-masked]> wrote:
>>>
>>>> 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.
>>>>
>>>>

---

From: [email-masked]
Date: Thu, 24 Aug 2006 13:54:23 -0500 (CDT)

>From: "Templin, Fred L" <[email-masked]>
>Date: 2006/08/23 Wed PM 07:12:23 CDT
>Subject: RE: Re: Prefix Delegation using ICMPv6

>Tim,
>
>I took a look at the I-D and it reads well.

Hi Fred, thanks.

 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.

Yes.

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

These ICMPv6 message types/codes are for error messages.

 Is
>there a way to do this with RS/RA alone, or do you also need
>the extra ICMPv6 messages?

>
>Fred
>[email-masked] 

Tim
Rom 8:28

---

From: <[email-masked]>
Date: Fri, 25 Aug 2006 01:55:15 -0500 (CDT)

>From: Jari Arkko <[email-masked]>
>Date: 2006/08/25 Fri AM 01:11:55 CDT

>Tim,
>
>Its probably best if you now update your draft with a better description
>of what scenario you are looking at, details about the customers
>requirements, justification of why new work is needed, and an analysis
>of why existing solutions are inappropriate or undesirable in your
>scenario.

Hi Jari, you're absolutely right. Even now we're in the process of considering how to better describe and provide detail for all the things you mention above.

>This has already been a long discussion but in my >opinion it has not been all that informative yet with >regards to these issues. Also, at least I personally >want to know what problem >we are solving before spending a lot of effort in analysing a solution --

Understood. In future revisions for example we hope to better illustrate customer requirements that exist for which our proposed ICMPv6 PD mechanism would be  either a better or the only solution.

Any technical feedback would however also be very helpful as we revise.

>we know there is an infinite number of ways to design a protocol
>but the real question is whether it solves a problem.
>
>Looking forward to your new draft.
>
>--Jari

Tim
Rom 8:28