[arin-ppml] Policy Proposal: Open Access To IPv6

[Garry Dolley]

On Sat, May 30, 2009 at 05:28:03PM -0400, Kevin Loch wrote:
> Garry Dolley wrote:
>
> > If we give a /32 to anyone who asks for it, I *guarantee* you that
> > major ISPs will stop accepting /32's.  There will be too many of
> > them.
> >
> >They'll take it down to /30s or /24s or something like that.
>
> Can we get real here?  One of the problems of this one size
> fits all is the rather concentrated distribution of prefix
> sizes makes that strategy impractical in the extreme.  There
> very well may be widespread filtering based on some other
> metric but exclusion of all /32's is as good as turning the
> (IPv6) Internet off.

Exclusion of /32 is as good as turning the IPv6 Internet off *at
present time*, but that may not be the case in the future.  If /32's
become in large enough number that current hardware accelerated
routers cannot hold them all, then something will give.

Just imagine all the /32 holders now growing and starting to acquire
larger blocks, and the /48 holders get /32's because policy changes
make them easy to get; what will happen is the /32 will be regarded
as what the /48 once was.  

It was mentioned previously that one major ISP stopped accepting
/48's (to whoever posted that, can you tell us who it was?)

There's no reason to believe the /32 is immune to this or "special"
in some way.  BGP makes no discrimination, it is up to the network
operator.

The network community as a whole, through NANOG, many mailing lists
(such as this one), RFCs, and general operating knowledge, have come
to the general consensus that prefixes of a certain size are
"acceptable" within a BGP routing table.  Right now that consensus
falls around /48, /32 and larger blocks.

But who's to say that won't change as the IPv6 Internet grows, and
we are faced with external constraints beyond our control?

>> I want ARIN to put up the barrier to entry on /32 prefixes, because
>> if they don't, the multi-million dollar ISPs will start making their
>> own rules.
>
> Do you have a proposed policy for how to establish that barrier?  Today
> there is no barrier aside from the annual fee.  Anyone who can configure
> a router to announce a /32 should be able to come up with a plan for
> how to assign 200 end site prefixes, so that is certainly not a barrier.

The current policy.

The only thing I would change is the

  "be an existing, known ISP in the ARIN region" [1]

because this doesn't work for brand new LIRs/ISPs.  This could be
deleted; yet I do see that there is an "*or* have a plan for making
at least 200 end-site assignments..." [1], in which case perhaps it
doesn't matter.  If you plan on making those end-site assignments,
go ahead and apply for a /32.

A multi-homing requirement may work too (isn't there already one?
 or is it only for IPv4?).  I don't see why a block from your
upstream (unless none of your upstreams support IPv6, in which case
you should find one that has a clue) is somehow undesirable in this
discussion.  I know that renumbering when you switch providers is a
pain, but if it is that much of an issue, you can get an end-user
/48 all to yourself.

And if you have no upstream, use a ULA. [2]

> Removing that farcical "requirement" from the policy document might
> encourage network operators who do not already have a /32 to get one.

But you just said the 200 end site prefixes plan is not a barrier for
someone who can already configure a router to announce a /32, so why
would removing this requirement encourage more network ops to get a /32?

> I am not worried about a flood of "kids" willing to pay $2250/yr for a
> /32.  At some point in the future maybe, but not today.
>
> Also, if you self-moderate your posting to about once per day you will
> find that more people read what you have to say :)

This thread grew throughout last week (and is still growing), while
I was on vacation, and I said to myself I'll read it post-by-post
and reply on the weekend.  So there you have it.


1. https://www.arin.net/policy/nrpm.html#six511
2. RFC 4193, "Unique Local IPv6 Unicast Addresses"
   http://tools.ietf.org/html/rfc4193

-- 
Garry Dolley
ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181
Data center, VPS, and IP Transit solutions
Member Los Angeles County REACT, Unit 336 | WQGK336
Blog http://scie.nti.st