Subject: Re: Re: Prefix Delegation using ICMPv6

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

>From: Ralph Droms <[email-masked]>
>Date: 2006/08/22 Tue PM 11:04:04 CDT
>To: [email-masked]
>Cc: "Durand, Alain" <[email-masked]>, 
	Syam Madanapalli <[email-masked]>, 
	IETF IPv6 Mailing List <[email-masked]>
>Subject: Re: Prefix Delegation using ICMPv6

>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:
>
>>> From: "Durand, Alain" <[email-masked]>
>>> Date: 2006/08/22 Tue PM 10:31:10 CDT
>>> To: [email-masked], Syam Madanapalli <[email-masked]>,
>> 	IETF IPv6 Mailing List <[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. 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.
>>
>>
>> --------------------------------------------------------------------
>> 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 06:43:09 -0400

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

Prefix delegation has a pretty common set of requirements, based on  
RFC 3769.  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) any significant differentiation in requirements on the  
scale of those among SLAAC, DHCP and manual address configuration.

On Aug 23, 2006, at 2:44 AM, <[email-masked]>  
<[email-masked]> wrote:

> 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?
>
> 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'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. =^)
>
>> 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
>
> As I'd mentioned, our approach is based upon ND, which is at least  
> virtually ubiquitous in IPv6 implementations, if not entirely so.
>
> 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.
>
>> 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.
>
> 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).
>
> 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
>>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Aug 2006 15:24:59 +0300

Tim,

>BTW, what would be your burden of proof in what you are asking?** I'd not want to be chasing my technical tail. =^)
As Brian pointed out there are some design principles
that the IETF uses. We believe interoperability is very
valuable. We do not create alternative ways to do the
same thing, because doing so will burden implementors
with additional complexity and reduces the likelihood
that nodes can communicate successfully. Picking a
common way to do something is the fundamental idea
behind standards.

Of course, in some cases we actually do have to create
alternative mechanisms when the situation calls for it.
For instance, the requirements are very different, we
have new needs that fundamentally cannot be met
by the existing mechanisms, and so on. And we all
want to enable the things that the customers want to
do. So their requirements are important, but some
engineering may be needed before we decide what
solution should be employed.

I would suggest that you focus on the WHY question
and proceed with a rational analysis of whether
existing mechanisms are or are not sufficient for
your needs. This analysis should avoid arguments
such as "Devices do not have X, therefore we must
design Y". Such arguments do not provide any
information on what the reasons for not having
X were, whether designing Y will alleviate those
concerns, and whether the benefits from Y are
a good tradeoff with respect to the costs of supporting
both X and Y in everyone's products over the next
N years.

And the burden of proof is on the side of those
who want something new; you should convince
the community that it is indeed necessary.

--Jari

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Aug 2006 11:03:47 -0700

[email-masked] wrote:
> 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?

I believe you are mixing points here. Yes different mechanisms exist, but
they deal with different scenarios. Your draft does not really explain what
is different about the deployment scenario that justifies a new mechanism.
Section 3 has that title, but I would not be able to explain why this is
really any different after reading that text.

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

I am not opposed to doing something different, but there needs to be
something more than a wish to back it up. 

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

ICMPv6 is a fine alternative. The question is why is the DHCP approach
inadequate? That will need to be answered clearly if we are going to make
sure the proposed ICMPv6 approach actually meets the need.

> 
> BTW, what would be your burden of proof in what you are asking?** I'd not
> want to be chasing my technical tail. =^)

Explain how to evaluate that the proposed approach actually meets a detailed
need.

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

I think their point is that supporting this option requires new code in any
case. Stepping back, the debate seems to be over the bits-on-the-wire
format, while the architectural issues are that the requesting router needs
to have a mechanism for acquiring a prefix and the delegating router needs
to have a mechanism for responding to the request and tracking what is
active. I believe the state machinery to support the architectural points is
essentially the same regardless of the bits-on-the-wire format. 

Your proposal is essentially asking to chew up reserved flag bits to be able
to reuse some bits-on-the-wire code in the requesting and delegating
routers. Realistically it only reuses RS/RA code in the delegating router
since there is no existing expectation that a requesting router would
implement sending an RS message. Your section 3 tends to imply that the
primary justification is that some requesting routers don't implement DHCP.
This falls flat when they don't implement sending an RS either...

Fundamentally this draft needs to explain why a new format is *needed*
rather than just desired. The current arguments are cast as a mechanism,
though it appears this is really just a format issue. In the case that the
state machinery in the requesting & delegating routers are identical for
either packet format, the proposal needs to be explicit as to what the
DHCP-PD approach lacks and how this fulfills the need. In the case that the
state machinery is actually different (and I personally can't see how it
could be, but I am willing to be open minded), the proposal needs to spell
out something more than 'the lack of a DHCP client' since that is not really
necessary for the purposes of exchanging DHCP-PD format messages.

Tony