[arin-ppml] Policy Proposal 107: Rework of IPv6assignment criteria

George Bonser gbonser at seven.com
Sun Jan 17 16:05:41 EST 2010

> -----Original Message-----
> From: arin-ppml-bounces at arin.net On
> Behalf Of David Farmer
> Those are what I intended.  I would like to find a replacement for
> HD-Ratios too.  But I haven't figured that out just yet and I'm not
> sure
> I'll be able to figure that our in time to make Toronto, besides very
> large proposal that change many different part of policy don't have a
> very good track record.
> > I offer the following comments:
> >
> > 1. Proposal 106 is superior to and incompatible with proposal 107. I
> > strongly prefer proposal 106.
> In some ways I agree with you and in other ways I disagree, but I have
> yet to decide if I prefer the direction of 106 to 107.  But, I am by
> means opposed to 106, I just think we need to consider all the options
> and pick the best one after considering all the implications.

We are an end user, not an ISP.  We currently have three multihomed
facilities and have at least one more in the US in the planning stages.
The current policies are not clear.  We asked for and obtained a /48 but
now realize we should have asked for more space but weren't familiar
with ipv6 addressing conventions.  Under proposal 106 we would have
asked for a /40.  107 is still somewhat ambiguous.  A compromise between
the two is that if an end user has multiple sites, just give them a /44
as that amount of space is going to be set aside for them anyway even if
not issued immediately.  It isn't as much as 106 would issue but a /44
would cover many organizations over their lifetime.

This allows the end user with multiple sites that are multihomed to more
easily aggregate addressing where possible (e.g. our current three sites
are all in the SF Bay area and are interconnected so I could aggregate
those in a single announcement to our upstream transit and our private
peering) without having to come back to ARIN each time I need an
additional /48 for another location.

HD requirements have been painful for us as about 1/3 of our addressing
is not internet reachable.  These addresses are used for things such as
private connections to business partners over encrypted VPN or direct
physical connections.  It gets hard to "prove" to someone that we are
using the address space when they do a simple address scan of the
network and come up with significantly less than we say we are using.
Our policies and those of our partners dictate that unique global
addressing be used for these connections to prevent collisions in local
addressing between our networks.

HD requirements are probably good for justifying additional space for
growth at a static number of facilities but when address space is
requested in order to support additional facilities, the HD requirement
doesn't really apply if one is to use a /48 per facility.  And this
would apply whether or not the new site is a discreet network or
integrated with a common backbone.  Splitting a /48 between locations
seems like a bad idea and as far as I can tell, the current "best
practice" is to use a /48 per location.

My suggestion would be to remove the HD requirement in 107 for initial
assignments to end users with multiple locations and simply issue them
the /44 block that 107 reserves.  For an end user with a single
location, the language in 107 is probably fine.  Or simply go with 106
which gives everyone a /48 or a /40 but after having to live with v4
scarcity so long seems somehow wasteful.

I just want enough address space to number all my facilities in their
own /48 without having to do the ARIN dance every time I add a new one.

More information about the ARIN-PPML mailing list