[arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call
cgrundemann at gmail.com
Thu Oct 29 20:26:39 EDT 2009
On Thu, Oct 29, 2009 at 11:05, David Williamson <dlw+arin at tellme.com> wrote:
> 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
If you do not have any transit customers, would you need to be
assigning space as an LIR? If the answer is no, then you should be
looking at section 6.5.8. Direct assignments from ARIN to end-user
organizations and not this 200 customer restriction which is in
section 22.214.171.124. Initial allocation criteria which also specifically
states that you are an LIR (it also states that you are an ISP, not
just an SP).
Maybe I am wrong but my impression is that a lot of the folks who want
the 200 customer limit removed are not LIRs at all and should really
be looking at the requirements for end-user assignments. I am sure I
will be corrected if this impression is mistaken.
>> 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.
When we say that 200 customers is a tad high, let's not forget that a
/32 contains over 65 thousand /48s. Not to mention the fact that
despite ARIN policy setting usage requirements based on a /48, a /56
is probably adequate for many (if not most) end-users. Having a need
for 200 out of 65 thousand does not seem like a stretch to me as a
decent justification - however arbitrary it is.
Also, we are not talking about 200 customers today - it says "be an
existing, known ISP in the ARIN region or have a plan for making at
least 200 end-site assignments to other organizations within 5 years."
Which means (to me at least) that if you are already an IPv4 LIR, you
don't need to worry about the customer requirement at all and if you
start up a new ISP you have to plan to take on 200 customers _over
five years_ - I have worked at start-up ISPs in the past and our plans
were always much higher than that, even in quite remote rural areas
(and they all exceeded that number as well).
All that being said - I am not totally against dropping the limit to
100, I just think that it should be discussed further as a separate
policy (I am willing to be convinced but am not there yet). I also
think that adding a multihoming section for IPv6 allocations, as Wes
suggested, makes much better sense.
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML