Date: Mon, 27 Nov 2000 09:19:32 -0500
From: "Brian Haberman" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| The following is an individual submission discussing automated
| prefix delegation.
In general, I think this is a great idea, IPv6 needs more like this.
| Right now, we restrict its use to leaf
| networks, but are working on expanding it.
I looked, but other than for the assertion of that, I couldn't find
such a restriction?
If a router can request a /56 prefix from its upstream router, what's
to stop it then registering as an ALL-DELEGATORS on its other links
and then giving out shorter prefixes to anyone who asks - or even just
receiving a request from downstream, making a request upstream, and
then passing back the prefix obtained ?
| Comments welcome.
I am a little concerned with the assumption that an ALL-DELEGATOR is
a router. To me, a protocol like this requires state in the server,
so it can remember what it has allocated over outages (including
"broken box, replace it" outages). That smells more like a host
than a router to me (and yes, I know that routers are also hosts, but
not usually that kind of host, though they can be).
Was there some reason you're assuming that the delegator is a router?
I'm also not sure why it is important that it be deterministic which
server (delegator) a client router picks when it receives multiple
offers? Wouldn't any one of them suffice? Perhaps all of them
(serially) if the client ends up unable to obtain a prefix from the
first it tries.
I know you have "not directly connected" (between client & server) as
a "future work" - this is one I think needs more urgent future work.
It could be as easy as having it not possible when there is no site
local address (or global) already available to the client, but if there
is, doing an expanding ring multicast search (limited to a smallish N
hops, and prefering site local over global - using site scope multicast)
to find the delegator. Alternatively, dhcp type relay agents in routers...
Also, is there a need for 2 icmp types really? I know icmp has a tradition
of request & reply messages, but couldn't all this be made to fit in one?
There are already lots of sub-codes for the messages.
kre
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------