Robert,
Robert Elz wrote:
>
> 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?
Operationally, there is not a restriction. We have a concern though,
about having multiple routers on the same network requesting multiple
prefixes for use on it. There are some details that I have not had
time to completely work through yet.
>
> 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 ?
See comment above. I also have a concern about having this protocol
look like DHCPv6 (replace addresses with prefixes).
>
> | 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).
Good point. There is no reason that the delegator cannot be a host.
In fact, it may be better if it was a host.
>
> 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.
It was meant as a guideline for requestors. How they choose which
delegator to use may not be all that important.
>
> 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...
Either a relay or a site-local multicast address is what I had in
mind for "not directly connected" requests. I just did not have time
to address it and the security issues prior to the deadline.
>
> 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.
Yes, that was my original intent, and could easily be modified to
use one type.
Thanks for the comments.
Brian
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
