>From: Ralph Droms <[EMAIL PROTECTED]>
>Date: 2006/08/22 Tue PM 11:04:04 CDT
>To: [EMAIL PROTECTED]
>Cc: "Durand, Alain" <[EMAIL PROTECTED]>, 
        Syam Madanapalli <[EMAIL PROTECTED]>, 
        IETF IPv6 Mailing List <ipv6@ietf.org>
>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 PROTECTED]> wrote:
>
>>> From: "Durand, Alain" <[EMAIL PROTECTED]>
>>> Date: 2006/08/22 Tue PM 10:31:10 CDT
>>> To: [EMAIL PROTECTED], Syam Madanapalli <[EMAIL PROTECTED]>,
>>      IETF IPv6 Mailing List <ipv6@ietf.org>
>>> 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
>> 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
--------------------------------------------------------------------

Reply via email to