[ppml] 2005-1 status

Kevin Loch kloch at hotnic.net
Tue Jan 24 11:11:42 EST 2006

Michael.Dillon at btradianz.com wrote:
> Noting that the v6 policy gives out /32 blocks to
> LIRs, i.e. organizations that have an ironclad case
> for PI space, I wonder why 2005-1 does not specify
> a /32. Of course, the v6 policy also discusses 
> assigning /48 blocks to sites so if these v4 PI
> holders are a single site, then /48 would be appropriate.
> The existing policy only allows for shorter prefixes
> like /44 in the case of VERY LARGE SUBSCRIBERS.

We're proposing a new cagetory of assignments
distinct from LIR's and simple end sites.  This would
not change the existing policy for LIR's or simple
end sites.

I look at potential v6 PI holders as somewhere between
simple end sites and LIR's.   They may
be large organizations with multiple physical locations,
assigning /48's to internal units.  Think of them
as an "internal" LIR, justified by many physical locations.
Others may be simple multihomed sites so assigning a /32
would be wasteful.

Another reason to make the minimum size larger than /48
is to make it easy to distinguish between PI assignments
and deaggregated PA /48's.  In the future that could be
extremely useful.

> So, the existing policy defines a world in which there
> are lots of /32 routes globally, lots of /48 routes
> in a more local context (one provider's IBGP) and 
> no other prefix lengths.

/32 and /48 are "generous minimums", not fixed boundaries.
I see a virtual continuum of prefix lengths in my table today,
some RIR assigned, some deaggregated. There was alot of discussion at
the last meeting about the negative aspects of fixed boundaries, or even
the illusion of fixed boundaries.  I don't see the benefit
of taking it all the way down to single bits, but nibble boundaries seem

> Do we have a good reason to add a new standard prefix
> size to the mix? If so, then what are the criteria
> for defining this size?

I'd rather not do "standard prefixes".  I think /44
is a reasonable (generous?) minimum for PI and allow larger
sizes where they can be justified.

- Kevin

More information about the ARIN-PPML mailing list