Subject: [Fwd: I-D ACTION:draft-haberman-ipngwg-auto-prefix-00.txt]

From: "Brian Haberman" <[email-masked]>
Date: Mon, 27 Nov 2000 09:19:32 -0500

All,
     The following is an individual submission discussing automated
prefix delegation.  The basic idea is that routers can request a prefix
to use within a network.  Right now, we restrict its use to leaf
networks, but are working on expanding it.  Comments welcome.

Regards,
Brian

[email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
>         Title           : Automatic Prefix Delegation Protocol for Internet
>                           Protocol Version 6 (IPv6)
>         Author(s)       : B. Haberman, J. Martin
>         Filename        : draft-haberman-ipngwg-auto-prefix-00.txt
>         Pages           : 11
>         Date            : 22-Nov-00
> 
> The expansion of the IP address space provided by IPv6 makes it both
> possible and reasonable to allocate entire subnets to environments
> that had been previously limited to a few individual IP addresses.
> Other protocols such as Neighbor Discovery and Stateless Address
> Autoconfiguration allow hosts within those subnets to be
> automatically configured. The router between this subnet and the
> upstream world requires just one more piece to make this process
> automatic, a network prefix.
> This document describes a mechanism for the automated delegation of
> an IPv6 network prefix. It allows routers to request a specific size
> prefix and inform the upstream router of the routing protocols of
> which it is capable. Upon authorizing the request the delegating
> router then returns a prefix, the desired routing protocol, and a
> lifetime for the use of the prefix.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-haberman-ipngwg-auto-prefix-00.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-haberman-ipngwg-auto-prefix-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-haberman-ipngwg-auto-prefix-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
>   ------------------------------------------------------------------------
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Mon, 27 Nov 2000 22:03:42 +0700

Date:        Mon, 27 Nov 2000 09:19:32 -0500
    From:        "Brian Haberman" <[email-masked]>
    Message-ID:  <[email-masked]>

  |      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

---

From: "Brian Haberman" <[email-masked]>
Date: Mon, 27 Nov 2000 12:07:49 -0500

Robert,

> I looked, but other than for the assertion of that, I couldn't find

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.

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

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

> (serially) if the client ends up unable to obtain a prefix from the

It was meant as a guideline for requestors.  How they choose which
delegator to use may not be all that important.

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

> 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

---

From: Robert Elz <[email-masked]>
Date: Tue, 28 Nov 2000 15:49:42 +0700

Date:        Mon, 27 Nov 2000 12:07:49 -0500
    From:        "Brian Haberman" <[email-masked]>
    Message-ID:  <[email-masked]>

  | We have a concern though,
  | about having multiple routers on the same network requesting multiple
  | prefixes for use on it.

Yes...

I have always been of the view that it ought be prefectly safe for routers
to acquire a prefix on a net the same way that hosts do - listen for RAs
from other routers... (and like hosts, also via static config optionally).

Then, I'd only be asking for prefix allocation for a net in the case
that there were no other routers on the link.

This even fits well with divided cables, that end up with one router on
each, each of which is connected to the outside world (when they boot,
or when one of them boots - as in after a power off restart, where the
switch supposed to connect the segments doesn't recover) - then they
can each go get a prefix from their servers, and depending up how they're
set up, might each get handed the same prefix (perhaps with some glue
added, like instructions to build a tunnel, and bridge, between themselves)
or they might each be given a different prefix, as they are at least
temporarily disjoint nets, and then allow one of the prefixes to die out
after the nets reconnect.

There's lots of scope for good work here...

Unfortunately, there are (or at least were) also lots of people who
seem to strongly believe that any kind of router autoconfiguration us
something so dangerous, that it can never be permitted.

  | I also have a concern about having this protocol
  | look like DHCPv6 (replace addresses with prefixes).

I had the same thought, but more along the lines of merging the two...
(ie: just use DHCPv6 to fetch the prefix, the DHCP servers have
just about all the mechanism to do everything that is needed here).

kre

---

From: Ignatios Souvatzis <[email-masked]>
Date: Wed, 29 Nov 2000 14:35:50 +0100

> >         Filename        : draft-haberman-ipngwg-auto-prefix-00.txt

First comments, and a question:

1. I suggest to swap the "Routing capabilites" with the "Reserved" field 
   in 5.1 Prefix Request Message; and also the "Lifetime" with the "Rt Proto"
   field in 5.2 Prefix Delegation Message.

   This way, the 16 bit field is naturally aligned (assuming alignment of 
   the whole packet buffer) and can be accessed more efficient by a lot of
   devices.

2. This one is probably covered by "6. To Do's: additional security
   discussion"...

   My impression is that there are all sorts of DOS (and worse) attacks
   possible if no authentication header is used. (This happens for lots of
   routing-like protools, of course.) This must be pointed out in the Security
   Discussion.

3. What are the differences  between this protocol and Router Renumbering?
   What are the interactions between this protocol and Router Renumbering?

Regards,
	-is