Hi Tony, thanks for your reply (and for reading the draft as well). Please see
my in-line comments:
>From: Tony Hain <[EMAIL PROTECTED]>
>Date: 2006/08/23 Wed PM 01:03:47 CDT
>To: [EMAIL PROTECTED], 'Ralph Droms' <[EMAIL PROTECTED]>
>Cc: "'Durand, Alain'" <[EMAIL PROTECTED]>,
'IETF IPv6 Mailing List' <[email protected]>
>Subject: RE: Re: Prefix Delegation using ICMPv6
>[EMAIL PROTECTED] wrote:
>> >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?
>
>I believe you are mixing points here. Yes different mechanisms exist, but
>they deal with different scenarios.
Tony, I am not mixing points though I'm afraid you've missed mine (for which I
apologize). I was making one and only one point, that being there is >1 IETF
standardized way to do IPv6 node addressing. That's it.
At it's most basic the mechanisms deal with one and only one scenario, that
being the assignment of IPv6 addresses to nodes. To try and take the point any
further than that would be to take it further than I'd intended.
>Your draft does not really explain what is different about the deployment
>scenario that justifies a new mechanism.
Actually it does, though I'd be willing to consider including any suggested
related text you might have in mind in the next version of our document.
>Section 3 has that title, but I would not be able to explain why this is
>really any different after reading that text.
"Motivation for ICMPv6 based Prefix Delegation" is the title. The section does
go on to mention a few different scenarios wherein a non-DHCPv6-based PD
mechanism would be warranted. Please let me know what additional info you would
like to see in this section so we can consider including it in the next version
of the document.
>
>> ...
>> >
>> >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).
>
>I am not opposed to doing something different, but there needs to be something
>more than a wish to back it up.
Thanks Tony. Please keep in mind the ICMPv6 PD mechanism we propose and the
current DHCPv6 PD are not mutually exclusive (I realize you're not saying they
are).
A real reason why the ICMPv6 PD mechanism is proposed is THAT customers have
asked for it. WHY they have asked for it perhaps could be included in future
versions of this draft.
One possible reason WHY customers ask for it could be that their edge router(s)
do not have any DHCPv6 components installed or enabled (WHY they do not have
DHCPv6 enabled on their edge router(s) is another question, the answer(s) for
which could also be included in future versions of this draft... I'd be happy
to take the gathering of said info as an 'action item' from the group).
That said, one possible reason for customers not having it enabled on their
edge router(s) could be that the only config info required from the PE by the
CE is knowledge of what prefix(es) to use for autoconfiguration of addresses
and/or what prefixes to be considered for on-link determination. In such a case
as that, it would seem unnecessary to enable DHCPv6 on that link just to do PD.
The proposed ICMPv6 PD mechanism would easily handle the IPv6 PD requirement.
>
>>
>> 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.
Agreed! :) It would be edifying to know why folks (other than the draft
co-authors) think so.
>The question is why is the DHCP approach inadequate?
When phrased that way, I feel as if I/we need to better communicate that we
affirm the DHCPv6 approach is, ceteris paribus, not inadequate in many
instances.
The ICMPv6 PD approach that we submit to the group addresses customer need for
IPv6 PD when DHCPv6 is not available.
This is the point at its most basic: if there is no DHCPv6 enabled, customers
can't do DHCPv6-based PD.
Again, WHY it is not enabled is a separate question (as an action item from the
group, I can include the answer(s) in future versions of this draft).
>That will need to be answered clearly if we are going >to make sure the
>proposed ICMPv6 approach actually >meets the need.
I'd tend to say that if the customers say they need it (because they need to
do IPv6 PD, yet are not implementing DHCPv6 on, for example, the link(s)
between their edge router(s) and their ISP(s) edge router(s)) that means the
ICMPv6 approach meets the need. Just for emphasis, I'll again say (last time, I
promise!) that I'll take an action item to include some customer rationale in
future versions of this draft.**
I'd like to know what the group thinks of our proposed ICMPv6 PD mechanism on a
technical basis as well. Please see the Introduction for an understanding of
what we believe about the ICMPv6 PD solution we propose.
>
>>
>> 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.
Thanks Tony.**
>
>> ...
>> >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.
>
>I think their point is that supporting this option requires new code in any
>case.
Perhaps, but arguably very little.
>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
Yes certainly to the architectural point! The requesting router needs to have A
prefix delegation mechanism that conforms to RFC 3769 (not DHCPv6 PD, or any
other particular mechanism, per se). We believe both RFC 3633 and our ICMPv6
mechanism do this.
>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.
Actually, with the implementation of our proposed ICMPv6 PD mechanism the
requesting router would indeed be sending an RS message (with the new 'P' flag
set, and potentially with one or more PIOs attached to indicate preference(s)).
>Your section 3 tends to imply that the primary justification is that some
>requesting routers don't implement DHCP.
While that definitely is a justification, in future versions of the draft... :)
>This falls flat when they don't implement sending an RS either...
The RN would be sending an RS as noted above.
<snip></snip>
>Tony
Best Regards,
Tim
Rom 8:28
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
