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