[arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call

David Williamson dlw+arin at tellme.com
Thu Oct 29 13:05:55 EDT 2009


On Thu, Oct 29, 2009 at 10:05:09AM -0500, George, Wes E [NTK] wrote:
> I'm struggling with Owen's recommended change a bit. I wasn't in favor of it at the meeting, but I'm trying to keep an open mind. I believe that the general spirit of the recommended changes is to remove as many barriers as possible to deployment of IPv6 by making it very easy to qualify for IPv6 space. I support that in principle. However, I don't understand why direct PI allocations are a requirement for networks of this size vs. simply getting PD space from an upstream. We're talking about networks which do not believe they can put together a plan that passes the red-face test that they will have 200 customers within 5 years. What drives the need for PI space in this case? Having had to personally renumber hundreds of end sites when we deprecated 6bone, I don't view having to renumber if you change providers as a barrier in a network this small (sorry). So that leaves multihoming...

The NRPM spends a bunch of text defining terms in section 6.2, but
nowhere does it define "customer".  There's some allusions to users,
but I think the common reading of it in this context is persons or
organizations who buy transit services from the LIR/ISP.  That
definition is why there's a need for the PI policy, and why there
is a need to look at the arbitrary 200 customer number.

I agree with most of your above statements in the context of small to
large transit ISPs.  There are, however, non-transit service providers
(like my employer) that have legitimate need for our own address
space.  We simply cannot use reassigned PA space.  And I disagree with
your assertion that renumbering is easy.  It can be, but many
enterprises have substantial VPN infrastructures, and changing the
configs of your portners devices to accomodate a renumbering is a
manpower expense that trivially justifies the ongoing cost of your own
space.  Furthermore, we simply do not qualify as an LIR, and we don't
have any transit customers, which makes the 200 number seem very large
indeed.

> Section 6 of the NRPM has no references at all to multihoming. Perhaps that's a problem, given its prevalence in the sections on IPv4.

On this, I entirely concur.  If you are going to be singlehomed, please
don't use a routing slot, and please just use PA.

> I would be in support of something that adds a reference to being multihomed in the criteria as justification for PI space, rather than a reduction in the number of end sites. IPv6 address space is mindbogglingly big, so I know that talk about trying to be prudent in our use of it will largely be shouted down, but I'll say it anyway. This maybe goes a bit too far.

Makes sense to me.  But the original discussion is really about LIRs,
which won't be getting PI space anyway.

> To ask a related question - why would big ISPs need huge blocks (/32-29 or larger) if nearly all of their downstreams can qualify for a PI block either as an end user or an LIR? If we really want nearly everyone to be able to qualify for space directly from ARIN, perhaps we should be looking to move away from the PD model entirely, and leave ISPs to allocate only infrastructure blocks and dynamic end hosts (mobile devices, homes, etc)? I'm not trying to start a discussion about routing table explosion here, so let's leave that on the sidelines for now. I'm simply asking because that's the general direction I see this going if we continue to make it easier for direct allocations from ARIN. Is that the aim?

'cause not every org needs to be multihomed. :-)  (See my comment above.)

The hard problem here is where to set the arbitrary customer number.
We don't want to create a swamp.  (Really, I just don't want Jason's
basement to have it's own /32.)  On the other hand, we don't want to
discourage adoption.  The 200 number seems a tad high, but that's just
gut instinct, and not backed by any data.  I think I'd be in favor of a
new PP that changes the number to 100.  I would prefer to detach that
from the draft as it is currently written, though.

-David



More information about the ARIN-PPML mailing list