>From: Ralph Droms <[EMAIL PROTECTED]>
>Date: 2006/08/23 Wed AM 05:43:09 CDT
>To: "<[EMAIL PROTECTED]>" <[EMAIL PROTECTED]>
>Cc: "Durand, Alain" <[EMAIL PROTECTED]>,
Syam Madanapalli <[EMAIL PROTECTED]>,
IETF IPv6 Mailing List <[email protected]>
>Subject: Re: Prefix Delegation using ICMPv6
>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 PROTECTED]>
><[EMAIL PROTECTED]> wrote:
>
>>> 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 <[email protected]>
>>> 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 <[email protected]>
>>>>> 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 protected]
>>>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
