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

[Davis, Terry L]

Wes

The simple answer is that regardless of how we try to prevent it; our computing environment gets built into our applications.  In short, although IPv6 makes re-addressing easy, it cannot fix the parts of an entity's infrastructure that get built into code, scripts, or configs.

Thus re-addressing after even a year or two present huge potential issues for the entity contemplating changing ISPs and thus getting new addresses.  Outages of any magnitude scare even the CIO's of small businesses.

It is the same thing we are seeing trying to migrate entities into "cloud computing"; they still have to take the risk that some number of your apps will fail in the transition because the apps have "the current computing environment" embedded in their code.

Take care
Terry

PS: And for larger enterprises, Sarbanes-Oxley may even come into play as to whether they can accept PA space.

________________________________
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of George, Wes E [NTK]
Sent: Friday, May 29, 2009 1:26 PM
To: Stacy Hughes; arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6

I agree with Leo's comments regarding the risks to deaggregation and routing table size with no sizable benefit.

The comment was made in San Antonio when we were discussing relaxing standards for community networks, and I'll echo/paraphrase it here...

I need to see some level of justification as to why provider independent space is a requirement and provider-allocated space will not work for a non-multihomed network. Otherwise I'm not convinced that there's sufficient reason to loosen the requirements for direct allocations simply on the basis that it discriminates against those who can't/won't multihome or don't have a network of a specific size.

While I can see how innovation might be chilled by overly stringent allocation policies, I don't see how innovation or adoption is chilled by having to use PD allocations, and I echo the statement that if policy was the only reason why IPv6 wasn't widely deployed, we'd be in FAR better shape right now.

Yes, in the short term while there are ISPs that don't have their collective "stuff" together on an IPv6 deployment and it is not possible to *get* IPv6 service (and therefore also an allocation) from one's upstream, this would be a problem. However, that is going to be self-correcting for a lot of reasons, and if it's a deal-breaker, the entity in question will find another ISP that is able to meet their needs.
If it's a block size issue, I would expect that this will go similarly to the way that it does in IPv4, either an ISP has enough space to allocate the requested block size to their customer, or they go to Arin to get more space using this as the justification.

That said, as IPv4 space is getting harder to come by, ISPs have tightened up their justification requirements. It would be good to ensure that ISPs are being more open in their allocations of IPv6 by comparison in order to ensure that we aren't preventing people who want IPv6 space from getting it. If that falls beyond ARIN's purview and this is an attempt to solve that, I'm not sure that it's the best solution.

Thanks,
Wes

________________________________
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Stacy Hughes
Sent: Friday, May 29, 2009 1:49 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6
 A multihoming requirement discriminates against networks that either cannot or do not want to multihome.
I oppose this modification.
Stacy
On Fri, May 29, 2009 at 10:42 AM, Leo Bicknell <bicknell at ufp.org<mailto:bicknell at ufp.org>> wrote:
In a message written on Fri, May 29, 2009 at 11:14:45AM -0400, Member Services wrote:
> 1) Remove ?by advertising that connectivity through its single
> aggregated address allocation? from article 3 of section 6.5.1.1
>
> 2) Remove article 4 of section 6.5.1.1, ?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? in its entirety.
I fear the way this is written may be confusing.  Section 6.5.1.1 is at
https://www.arin.net/policy/nrpm.html#six511

If these changes were made, I believe the section would then read:

 6.5.1.1. Initial allocation criteria

 To qualify for an initial allocation of IPv6 address space, an
 organization must:

  1. be an LIR;
  2. not be an end site;
  3. plan to provide IPv6 connectivity to organizations to which it
     will assign IPv6 address space.

I would like to make two comments as a result.

Criteria #1 doesn't make a lot of sense.  If you were a new participant
(no IPv4 or IPv6 resources at all) and going only for IPv6 then you
aren't an LIR yet, indeed, you are trying to become one.  I think,
but cannot be sure, that the LIR reference has to do with fee/membership
structures of other RIR's.

The result of this policy is basically you get an allocation if you
want one and can show you will provide IPv6 to another entity and
are willing to pay the fees.  This is too loose of a standard.
While I believe we should be giving out IPv6 relatively easily and
there is no danger in running out of the numbers that does not mean
we don't still have the issue of routing slots, staff to deal with
the number of requests, and other issues.

To that end, I would like to suggest a new criteria:

 - Plan to announce the IPv6 address space provided to at least
   two other autonomous systems.

Basically, setting the bar at being multi-homed to BGP speaking
networks.  No number of sites requirement, you only need 1 customer
to meet the customer requirement.

--
      Leo Bicknell - bicknell at ufp.org<mailto:bicknell at ufp.org> - CCIE 3440
       PGP keys at http://www.ufp.org/~bicknell/

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto:ARIN-PPML at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.


________________________________
This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090529/e5327655/attachment.htm>