Subject: RE: simpler prefix delegation

From: [email-masked]
Date: Thu, 18 Mar 2004 16:47:47 -0000

On 18 March 2004, Pekka Savola wrote:
> On Thu, 18 Mar 2004, Ralph Droms wrote:
> > Is there interest in expending any more of the IETF's resources 
> > reopening a problem for which we have rough consensus on a 
> solution, 
> > published specifications and running code?
> 
> You say that carefully, but still giving an impression as if 
> rough consensus had been gauged that only one solution would 
> be specified -- otherwise there would not be "reopening" the 
> problem. That has never been even raised (AFAIR); I'd 
> certainly have objected.
> 
> The fact that there is a solution out there, which fits the 
> needs of some users, does not mean that there can not (or 
> should not) be a different kind of solution which would seem 
> to be much more appropriate in some other scenarios or for 
> some other users.

As I've said before in reference to the recursive name server discovery
discussion, I don't believe it benefits the network operations community
to have multiple solutions to these kind of requirements.

 -- Mat

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Alain Durand <[email-masked]>
Date: Thu, 18 Mar 2004 15:04:03 -0800

> to have multiple solutions to these kind of requirements.

Neither does it benefit the implementor community which then does not 
know what to implement,
nor how to make all the alternative solution works together.

So unless someone can come with a better reason than 'I do not like to 
read the DHCPv6 spec because
it is 120 pages long', please let's stick to one solution and move on 
to try to solve other still unresolved issues.

	- Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Mar 2004 08:54:03 +0100

> to have multiple solutions to these kind of requirements.

The vendor community would probably agree. 

   Brian

---

From: "Byung-Yeob Kim" <[email-masked]>
Date: Sat, 20 Mar 2004 14:35:21 +0900

Reaching rough consensus?  As all of us might know, alternatives to DHCP
have always been controversial. Even I admit that DHCPv6 looks good for
hierarchical prefix delegation and it is hard to find HDCP-less place,
even though some of my colleagues are still frenzy about 1894 Ubiquitous
something that includes multiple-level DHCP-LESS routers on Big
brother's clothing :)

Also I tend to disagree with that 120 pages are too heavy to be
implemented.  However IMHO, combing with existing stateless
auto-configuration, prefix delegation has room for simplification and I
don't want to call it a new protocol nor reinventing DHCPv6, rather I'd
call it an extension to an existing (say, ICMP or stateless auto-conf
you name it.)

I thank you for invaluable comments on the draft, especially Pekka
Savola and Laurent Clévy.  Opinions will be taken into consideration on
the next draft. If there's anybody want to collaborate please let me
know.

Weekend! It's a great day for flying,
Bob (Byung-yeob)

---

From: Pekka Savola <[email-masked]>
Date: Sat, 20 Mar 2004 10:44:17 +0200 (EET)

> The vendor community would probably agree. 

Probably, except for those vendors who would rather not want to be
required to implement DHCPv6 for tasks {Foo, Bar, ....}.

The question is really whether DHCPv6 is a feasible requirement in
*every* scenario where you'd desire prefix delegation, [DNS
discovery], and [whatnot].  If there is consensus that the answer is
"yes", we can focus the energies elsewhere.  But I do not think there
is such concensus (even a rough one; even if it might help).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Ralph Droms <[email-masked]>
Date: Sun, 21 Mar 2004 06:02:11 -0500

>required to implement DHCPv6 for tasks {Foo, Bar, ....}.

The network architect/engineer/admin (customer) community should be
considered here, as well.  Are there any customers that have said "DHCPv6 PD
is too complex, we want something simpler"?  I haven't heard from any.

>is such concensus (even a rough one; even if it might help).

I think the question is really "Do the network architects/engineers/admins
(customers) want something simpler"?  We don't need to make that decision
for them.

- Ralph

- Ralph

---

From: Wataru Kawakami -ipv4- <[email-masked]>
Date: Sun, 21 Mar 2004 21:00:20 +0900

> is too complex, we want something simpler"?  I haven't heard from any.
That's too much saying.
 
If delegation of ``prefix'' to CPE is not needed (i.e. only 
address assignment to the 1st hop CPE device is only requir-
ed), DHCPv6 PD is too much.
# In case of this, use ``RA + DAD'' ?

If you assume the case to delegate prefix, DHCPv6 PD may be 
the solution.

wataru
# Sorry to say, IPv4 is still attrative for me.
# Also, IPv4 PPP is still attractive for me.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 22 Mar 2004 12:09:17 -0800 (PST)

FWIW RFC 2461+2462 is 118 pages and I don't recall people complaining
about them being too complex to implement. I suspect 2 more pages
for DHCPv2 + DHCPV6 PD isn't that significant.

So I think there is something other than page count that matters.
Writing clear specifications which answers the implementor's questions up
front as well as specifies sufficient detail for a high likelyhood
of interoperable implementations etc means that a fair number of things need
to be written down.

Oh - and I think DHCPv6 has more implementable/deployable security than
neighbor discovery (since we were more lax about mandatory to implement
security  and interoperability testing with security back in 1998).
If you want that for the Neighbor Discovery functionality you need to
add 60 to 80 pages of SEND drafts to the page count.

  Erik

---

From: Fred Templin <[email-masked]>
Date: Mon, 22 Mar 2004 17:00:42 -0800

This discussion (and the bykim draft) reminds me of some materials
I briefed a long time ago during an NGTRANS session at IETF50:

  http://6bone.net/ngtrans/IETF-50-Minneapolis/Templin-v6v4compat.ppt

(See slides #15-#19; note that the colors in the diagrams denote distinct
IPv6 prefix assignments).

The breifing presented a high-level vision of how a hierarchy of
IPv6 prefixes could be driven deeply into an enterprise network
([RFC1918], section 1) during the early phases of IPv6 deployment
w/o delving into technical details save for one - ISATAP was then
and remains today the basic IPv6-over-(foo) mechanism required to
support the vision.

In terms of other required functions, this thread is touching on many
but it seems surprising that folks are viewing things from an "either/or"
perspective. Instead, it seems clear that the solution will not amount
to picking one of DHCPv6 vs. IPv6 ND, but rather combining the
best aspects of both.

For example, the notion of "stateless prefix delegation" seems a clear
oxymoron; prefix delegations require servers to keep lease lifetimes and
employ mechanisms to avoid duplicate assignments and reclaim expired
prefixes. We already have the state engine of DHCPv6 for this, and so
how could it make sense to re-invent this wheel vis-a-vis extensions to
the stateless mechanisms specified by RFCs 2461/2? By the same token,
router lifetime advertisements, autoconfiguration prefix advertisements,
etc. are clearly stateless mechanisms and so how could it make sense
to use DHCPv6 for this instead of IPv6 ND?

It seems like folks might be hung up somewhat on mistaking the actual
format of messages sent over the wire with the protocols implemented
at the endpoints. In other words, it just doesn't matter what we call the
messages that are sent over the wire as long as they are kept to a
minimum, are efficiently coded, and support the hybrid functions
required for combining the best aspects of DHCPv6 and IPv6 ND.
Perhaps this entails piggybacking DHCPv6 and IPv6 ND messages?
Perhaps this entails deploying a DHCPv6 server/relay on each IPv6
router/ND proxy?

To use an analogy, the  legendary golfer Bobby Jones said that the
secret to shooting low scores is to "find a way to turn 3 shots into 2".
If we can find a way to  combine the best aspects of DHCPv6  and
IPv6 ND, and "turn 4 messages into 2", then everyone wins.

Fred
[email-masked]