Subject: Distribution of FC00::/8

From: Aidan Williams <[email-masked]>
Date: Wed, 13 Aug 2003 13:45:34 +1000

Hi Guys,

Geoff points out in his document that distribution of the "centrally 
assigned" Unique Local IPv6 Unicast Addresses space FC00::/8 is tricky 
if the registries all have to coordinate with each other when selection 
occurs.

Also, assigning address blocks seems undesirable because the desire to 
cripple the aggregability of this address space and hence cripple its 
global routability.

A mechanism for partitioning the available space amongst a set of 
registries that isn't "block-like" could therefore be a useful thing.

A suggestion:  IANA can allocate vectors of numbers to each registry 
that span the entire address space.
For example:  In the allocatable range 0-2^41, each set of numbers 
described by
  S = { n < 0-2^41: n = V + k*G where k=0,1,2, ...}
where:
  G is a largish number that partitions the available space, and
  V (< G) identifies the vector that is allocated to a registry
are non-overlapping, non-aggregable allocations.

IANA would allocate integer Vs to registries and keep a database of the 
Vs already assigned.  The Vs can be sequentially allocated.  Registries 
allocate from the S-es (vectors of numbers) generated by the Vs they are 
given without the need to coordinate with each other.  The value G 
controls the size of the vector (I'm not sure off-hand what a sensible 
number might be).

Technically, a router could work out V by examining the address (ie 
the_41_bit_part mod G  will be the same for all allocations in the same 
vector) and thus perform aggregation by routing on the value of V, 
however if G is not a power of 2 (perhaps a prime) this would be an 
expensive operation.

- aidan

--------------------------------------------------------------------
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: Zefram <[email-masked]>
Date: Wed, 13 Aug 2003 09:46:25 +0100

>if the registries all have to coordinate with each other when selection 

The obvious, and I think best, solution (presuming that distribution
of registration is desirable) is for IANA to generate independent
random prefixes in advance and delegate these en masse.  The delegated
registrars can then assign the prefixes they have been given to individual
registrants, either sequentially or randomly.  This is not an expensive
operation.

I oppose your idea of having allocated prefixes be numerically related,
because it defeats the aim of having no discernable structure in the
prefix IDs.  Whoever generates the prefixes must do so randomly and
independently.

-zefram

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 13 Aug 2003 09:39:44 -0700

> prefix IDs.  Whoever generates the prefixes must do so randomly and

I don't see why this is a problem.  The prefix generation could
be done sequentially, it seems to me.  Randomness makes it a _lot_
harder to guarantee uniqueness, for no good reason that I can see.
Who cares if there is structure or not, when the prefixes aren't
going to be routed?

Regards,
Charlie P.

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Aug 2003 14:10:44 -0400

> > I oppose your idea of having allocated prefixes be numerically
> > related, because it defeats the aim of having no discernable
> > structure in the prefix IDs.  Whoever generates the prefixes must do
> > so randomly and independently.
> 

my preference is also to not require that the prefixes be randomly
assigned, in order to allow delegation of prefix assignment to multiple
authorized parties.  of course it's fine if those parties generate
prefixes from within their delegated space in non-sequential order to
further discourage attempts at aggregation and routing.  but in practice
I think the order of requests for PI blocks will be sufficiently random
that aggregation would be infeasible anyway.

Keith

---

From: Aidan Williams <[email-masked]>
Date: Thu, 14 Aug 2003 13:17:29 +1000

>registrants, either sequentially or randomly.  This is not an expensive
That would be a very large database, hence expensive.
Increasing the size of the blocks to manage the scale of the database 
increases
the size of the "aggregable chunks".

>prefix IDs.  Whoever generates the prefixes must do so randomly and
Randomly is not the requirement.  Non-aggregatable is the requirement.

If you don't like the simple approach, a collegue of  mine came up with
the idea of using a perfect hash to do the mapping.  In that case there is
no mapping.  I'll write it up shortly.

- aidan

---

From: Aidan Williams <[email-masked]>
Date: Thu, 14 Aug 2003 14:13:37 +1000

Charles E. Perkins wrote:

>Randomness makes it a _lot_
I agree that randomness makes it a lot harder to guarantee global 
uniqueness, hence my desire to get to a solution that does not allow 
aggregation and is not random.  :-)

I had a partly crippled sentence relating to motivation in an earlier email:
  "Also, assigning address blocks seems undesirable because [of] the 
desire to cripple the aggregability of this address space and hence 
cripple its global routability."

Basically, people want to break aggregability in order to ensure that 
this will never become a de-facto PI address space.  That is, to ensure 
by design that it can never be routed.  But I suspect you don't think 
this is a worthwhile goal..

- aidan

---

From: Geoff Huston <[email-masked]>
Date: Thu, 14 Aug 2003 14:14:14 +1000

>Who cares if there is structure or not, when the prefixes aren't

The observation is that you cannot guarantee "aren't going to be routed",
If you want to make it "very hard to route globally" then the Hinden draft
makes the assumption that if you assure that there is no guessable
structure of addresses this space. No guessable structure (i.e.
random selection) is intended to ensure that
   a) its impossible to undertake any form of aggregation of
       adjacent prefixes and
   b) its impossible to create a reverse DNS structure that exploits
       structure

Of course you may not care that these prefixes leak into the global
routing table, in which case it becomes a different scenario
altogether.

   Geoff

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Aug 2003 13:13:04 +0200

Since these addresses by definition have no geographical or topological
significance, and the idea is that they should be assigned as a public 
good (i.e. approximately at cost price with any profit being used for
the public good), I'm still at a loss as to why we would need to
distribute the registry function. In any case, that is an IANA matter.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK