[arin-ppml] V6 address allocation policy

George Bonser gbonser at seven.com
Tue Jan 19 22:53:28 EST 2010

> So then do you support something like PP#106?
> Any change you think should be made to PP#106 as it currently is
> written?
> If people support or oppose the direction of PP#106 the AC needs to
> here
> you say that one way or the other and the more clearly you say it one
> way or the other the better.

I would say that I generally support 106 but would also support a slight
modification of prop 106.

For multihomed end users, I would expand the number of different
allocations from 3 to 4.

Instead of:

/48, /40, and /32

I would support:

/48, /44, /40, and /32

A /44 allocation would serve many organizations with all the addressing
they would ever need.  If you look at the number of individual
multi-homed end users, I believe a relatively small percentage of the
total number of them needing more than a /48 would make use of more than
a /44 as most such organizations are relatively small.

So it would be something like: /48 for a single multihomed location, /44
for small multiple site multihomed, /40 for medium multiple site
multihomed, /32 for large.

I believe the majority of organizations would be able to get the right
sized assignment the first time and it does offer some address
conservation from giving everyone a /40.

Of course, the problem comes in when someone grows across the boundary
and needs more space.  Nobody wants to renumber. And that is the part
where I am having a problem coming up with a good suggestion to deal
with.  Initial assignments aren't the problem, the problem would seem to
be how to handle growth across boundaries without forcing someone to
renumber their existing space if they don't want to.

The closest thing I can come to that might work is something like this:

If your initial assignment was a /48 then a /44 space is "blocked out"
for you to grow into.  If you grow and require additional space, you are
given the remainder of the /44.

If you have a /44 and now require additional space you are given a /40
*AND* allowed to keep your initial /44 if the /40 block from which your
/44 was taken is not completely available for issue.

If you have a /40 and now require additional space you are given a /32
*AND* allowed to keep your /40 if the /32 from which your /40 was taken
is not completely available for issue.

This is very important, I believe, because it addresses one of the
psychological reasons why people often want more space than they need.
Renumbering is not desired nor is maintaining a myriad of disconnected
blocks.  If they can get a /40 now and know that if they grow to the
point of qualifying for a /32, if there isn't sufficient space adjacent
to their existing allocation, they won't have to renumber.  Having an
extra /40 in addition to a /32 represents less than 1% of their address
space.  Organizations would be encouraged to return the initial smaller
allocations but not forced to do so.  Maybe they could be encouraged to
do so via an annual surcharge as long as they hold the extra addresses
or something.

I think this would result in less address "waste" than simply giving
everyone with multiple sites a /40 as most of these organizations will
have only a small number of locations anyway and a /44 would serve most
of them forever.


More information about the ARIN-PPML mailing list