Subject: Re: RE: Re: Prefix Delegation using ICMPv6

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

Hi Tony, thanks for your reply (and for reading the draft as well). Please see my in-line comments:

>From: Tony Hain <[email-masked]>
>Date: 2006/08/23 Wed PM 01:03:47 CDT
>To: [email-masked], 'Ralph Droms' <[email-masked]>
>Cc: "'Durand, Alain'" <[email-masked]>, 
	'IETF IPv6 Mailing List' <[email-masked]>
>Subject: RE: Re: Prefix Delegation using ICMPv6

>[email-masked] 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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 24 Aug 2006 14:41:21 +0200

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

Customers of what?  Customers at home for ISP and DSL?  Customers of
netlmm deployments?  Customers of mobile routers?

You could mention a little more of the customer landscape you see, in
current IETF effort terms, and still stay technical.

Alex