[ppml] question on 2006-2 v6 internal microallocation

[David Williamson]

On Wed, Aug 23, 2006 at 09:53:12AM +0100, Michael.Dillon at btradianz.com wrote:
> > RFC 4193 ULAs do not insure global uniqueness, nor do they offer an
> > outside authority that documents if a given organization has a 
> legitimate
> > claim to use a specific address in the event of a collision.
> > 
> > We need a mechanism to guarantee global uniqueness between us and our
> > managed customer networks.
> 
> We are in the same position. In addition, we operate a global
> internetwork that is disjoint from the public Internet. Nevertheless,
> it is an internetwork connecting over 10,000 sites from well over
> a thousand different organizations. There the requirement for 
> globally unique registered addresses is exactly the same as the
> Internet requirement.

It's also worth noting that some networks attached to private
internetworks may also have an attachement to the public Internet,
which makes further demands on unqiue addressing, even when many of the
routes are nto exposed to the public Internet.  I have a customer that
decided to ignore global uniqueness in IPv4 space, since their network
doesn't touch the Internet.  That's all well and good, except I have to
exchange data with them *and* the public Internet.  That's rather
troublesome when they've decided to just use random space in IPv4.  (At
present, it's still in IANA reserved space.  That won't be true at some
point, and then it gets "exciting".)  global uniqueness, even for
non-attached networks, is a vital rquirement.

I don't understand the concerns with microallocations either.  I think
Jason has outlined a serious problem.  If you use BGP, this is an
issue.  I'd probably be in favor of a policy that hands out a /48 for
this purpose when you get an AS.  (A numbering scheme that makes the
allocation identifiable with the AS would be ideal.)

Finally, let's be honest: most organizations aren't going to consume a
/48 very quickly, if ever.  We're handing out gigantic chunks of
network space.  If the concern here is wastefulness, we should step
back and contemplate more than two allocation sizes (huge, i.e., /32,
and "micro", at /48).  If we're worried about consumption, let's hand out
blocks of a size that makes sense for an organization.  This really feels
like were repeating the mistakes of the past.

-David