DRAFT 6bone [AGGR] [TEST] usage

[Bob Fink]

6bone Folk,

================================================================================
NOTE:  The following is being put out a little prematurely as I'm leaving
on vacation as I write this (31 May thru 23 Jun) and won't be able to even
see the responses till 24 June.  Nonetheless, I felt that it was important
to not have everyone wondering what we do next on the 6bone with the new
[AGGR] and [TEST] drafts that have just come out...   so here is something
for your comment!.

I'll ask Bob Hinden to moderate this (if he is so willing) given he is the
principal author of both [AGGR] and [TEST].


Have a good time... I will :-)
================================================================================


Now that the new IPv6 Aggregatable Unicast Address Format [AGGR] is published,

ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-unicast-aggr-00.txt

and the new Testing Address Allocation Internet Draft [TEST] is available,

ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-testv2-addralloc-00.txt

it is time for some planning on how to use them appropriately for the 6bone.

I approach this with the overarching goal of having the 6bone do as much as
possible to advance IPv6, and that at this moment this means testing the
new [AGGR] addressing format using [TEST] and the related notions of site
renumbering.


The address format in [TEST] assigns a TLA to the 6bone (0x1FFE which looks
like 0x3FFE when the Format Prefix 001 is included) to be used to emulate
an addressing hierarchy similar to what might occur in real production use.

I would propose that we use the NLA* field as shown below:

         |3|   13    |  8  |     24      |   16   |    64 bits      |
         +-+---------+-----+-------------+--------+-----------------+
         |  0x3FFE   |NLA1 |     NLA2    |  SLA*  | Interface ID    |
         +-+---------+-----+-------------+--------+-----------------+

NLA1 would be our TLA equivalent, that is, up to 256 Backbone sites acting
as our version of TLAs.  I doubt that we would have more than 256 backbone
sites, but if we got close to that we could practice our implementation of
TLA assignment requirements (see [AGGR]).

NLA2 would be assigned by the NLA1 authorities as they wish, but with a
recommended downward delegation structure based on [AGGR].  The following
is extracted from [AGGR], and modified for NLA level.

         |  n  |      24-n bits     |   16   |    64 bits      |
         +-----+--------------------+--------+-----------------+
         |NLA2 |       Site         |  SLA*  | Interface ID    |
         +-----+--------------------+--------+-----------------+

               |  m  |    24-n-m    |   16   |    64 bits      |
               +-----+--------------+--------+-----------------+
               |NLA3 |    Site      |  SLA*  | Interface ID    |
               +-----+--------------+--------+-----------------+

                     |  o  |24-n-m-o|   16   |    64 bits      |
                     +-----+--------+--------+-----------------+
                     |NLA4 |  Site  |  SLA*  | Interface ID    |
                     +-----+--------+--------+-----------------+


The NLA delegation works in the same manner as CIDR delegation in IPv4
[CIDR].  NLA1s are required to assume registry duties for the NLAs below
them, NLA2s for those below them, etc.


At this time I would propose a nominal usage for our current 6bone topology
that only has one level below a backbone site that looks like:


         |  8  |        16 bits     |   16   |    64 bits      |
         +-----+--------------------+--------+-----------------+
         |NLA2 |       Site         |  SLA*  | Interface ID    |
         +-----+--------------------+--------+-----------------+

Then the transit (intermediate backbone) site would sequentially assign
Site IDs, or use ASN numbers as long as they are unique in the NLA.

If there was no transit site between the backbone and leaf site, then the
NLA2 field would be set to zeros.

As an example of this, assuming a backbone NLA1 of 0x01 for our first
backbone site, no transit thus an NLA2 of 0x00, and a sequential site ID
(with start at the right edge numbering) of 0x0001, the routing prefix for
the first site would look like:

        3FFE:0100:0001/48
 6bone _|||| |||| ||||__site
             ||||
 b/b site____||||
               ||
 transit_______||


Another example of this, assuming the same backbone NLA1 of 0x01 and a
transit site under it (with start at the left edge numbering) with an NLA2
of 0x80, and a sequential site ID of 0x0001, the routing prefix for the
first site would look like:

        3FFE:0180:0001/48
 6bone _|||| |||| ||||__site
             ||||
 b/b site____||||
               ||
 transit_______||


Note 1: the two sites numbered 0x0001 in the above examples are really two
different sites as their NLA2 authority above them is different.

Note 2: there would be nothing to prevent an NLA2 transit site from further
allocating NLA3s below, but that becomes the policy of it and the NLA1
above them to work out (as the width of the NLA2 field needs to be clear if
this is done).


I would propose assigning NLA1 code points to all existing 6bone backbone
sites, then backbone sites would assign leaf and transit site codes as
these sites apply for them.  The first group to request them would
presumably be the existing transit and leaf sites under them.


Address Registries

Every NLA must keep a registry of the assignments that it has made in a
form that is web viewable (I will suggest a format for this later).  In
addition, NLAs must provide downward web pointers to the NLAs below them.
Only leaf sites need not provide a registry (their DNS will suffice).

[David Kessens can help automate a registry with his RIPE-style RR db at
ISI, but I don't want to try to arbitrate that myself at this time.  Maybe
David can discuss this more on the list.]


Transition from the existing RFC 1897 test address space to the new AGGR format

Obviously a transition from the RFC 1897 test addresses to the new [TEST]
format has to be worked out.  One problem is that it will be a slow process
to get all the implementations modified to support [AGGR], which in
particular means support for EUI-64.  So, if we don't want to have a
modified [AGGR] that supports the existing 48-bit form of usage, we can't
move to [AGGR] till EUI-64 is implemented.

This means we will need to route between the two forms of addresses in a
transition mode, which shouldn't really be hard as the routing is really
done on prefixes with specified lengths.

Therefore, I believe we leave the 6bone current addressing as is, don't
allow new RFC 1897 form addresses, assign NLA1s to the current backbone
sites, and assume these backbone sites will know how to handle being
addressed with two IPv6 address forms (RFC 1897 and [AGGR]).


Multihoming

I would suggest that for now we not have multihomed sites.  We could later
figure out how to try out exchanges and then do multihomed in that context.

Sites that want to multihome now would get multiple prefixes.


FINAL NOTE:

I realize some of the above (hopefully not all) may be half baked...for
that I apologize.  Let's start discussing how to move the 6bone into [AGGR]
using [TEST] in the spirit of the grandly cooperative project we have all
been co-participating in... it's been fun so far (at least for me), so
let's keep the cooperative, friendly, exciting spirit of the 6bone going!


Regards,

Bob


-end