[arin-ppml] Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension - IAB comment

Mon Jun 27 18:16:21 EDT 2011

On Mon, 27 Jun 2011 13:35:26 -0700
Owen DeLong <owen at delong.com> wrote:

> I believe there may be a fifth option.
> 
> I believe that the ISPs who need this space might be able to  form a consortium and
> use this as a standard justification to have the IPs registered to the consortium
> as an organization. It would be up to the consortium after that whether they
> expressed a willingness for non-members to make duplicate use of their
> address space for this purpose or not.
> 

This is the best way to solve this problem. It does not externalise the
costs of this allocation to those who don't need the space i.e. the
rest of the Internet community who don't have the particular problem
that the proponents of this proposal want to solve.

> John Curran, could you please comment on whether such a request from
> a consortium for an allocation or assignment could be processed within
> staff interpretation of existing policy?
> 
> Thoughts?
> 
> Owen
> 
> On Jun 27, 2011, at 10:43 AM, William Herrin wrote:
> 
> > On Sat, Jun 25, 2011 at 11:11 PM, John Curran <jcurran at arin.net> wrote:
> >>> In keeping with the spirit of RFC 2860 with respect to the assignment
> >>> of specialized address blocks, ARIN Staff will consult with the IANA and
> >>> the IAB regarding implementation of this draft policy.
> >> 
> >>> == A Procedural Issue: ARINA 2011-005 and RFC2860 section 4.3 ==
> >>> 
> >>> The IAB honors and values the division of responsibilities as
> >>> documented in RFC 2860 section 4.3. That section forms the basis for
> >>> Unicast address allocation via ICANN through the RIR system.
> >>> 
> >>> Policy proposal 2011-005 is not a regular proposal in the sense that
> >>> it adheres to Unicast space. In contrast, it allows for an allocation
> >>> of addresses for special and global use very similar to, and almost
> >>> indistinguishable from, RFC1918 local addresses. Because of the impact
> >>> beyond the ARIN region the management (i.e. creation
> >>> and subsequent changes) of such reservation should be global and RFC2860
> >>> puts the management responsibility with the IETF.
> >>> 
> >>> The IAB believes that the adoption by ARIN would be in conflict with the
> >>> provisions in RFC2860 and would set a bad precedent: Setting aside
> >>> special addresses should be done within the existing process, i.e. by
> >>> the IETF.
> >>> 
> >>> If there is consensus for 2011-005 in the ARIN region we would be
> >>> happy to work with you to resubmit the proposal to the IETF and, as
> >>> usual, have the IESG judge consensus. This would include our reaching
> >>> out to other RIRs to have members of their community provide input on
> >>> this proposal. Clear support from the various RIR communities might
> >>> bring new insights into to the IETF, producing a level of support that
> >>> was not present with the earlier drafts.
> > 
> > Hi Folks,
> > 
> > In light of the IAB's objection, it seems to me that the ARIN board
> > has four options to consider:
> > 
> > 1. Submit an internet draft as the IAB requests, along with the
> > implications of doing so.
> > 
> > 2. Implement 2011-5  as recommended by the AC and community, and over
> > the IAB's objection.
> > 
> > 3. Abandon 2011-5. Proponents may make their case to the IETF.
> > 
> > 4. Implement 2011-5 as a temporary stopgap policy pending further IETF action.
> > 
> > 
> > 
> > 1. The case for complying with the IAB's request:
> > 
> > The Internet standards process works because of the cordial and
> > cooperative atmosphere between the various NGOs and individual
> > participants. The IETF is indeed the appropriate venue for global
> > assignment of IP addresses to specific purposes as opposed to specific
> > end users. However, we must observe that the IANA has insufficient
> > unicast (class A, B or C) addresses available to award the IETF for
> > the implementation of 2011-5's intended use.
> > 
> > Accordingly, ARIN should reserve the /10 that 2011-5 calls for and
> > hold it unused while championing an RFC through the IETF's standards
> > process that uses the /10 as contemplated in 2011-5. Upon publication
> > of such an RFC, the /10 would be ceded to IANA for use with the RFC.
> > Upon a failure to reach consensus within the IETF process, the /10
> > would be returned to the ARIN free pool for general use.
> > 
> > 
> > 2. The case for implementing 2011-5 over the IAB's objection.
> > 
> > a. ARIN's constituents have expressed a well defined, well supported
> > and consensus need for addresses to be used similar like RFC1918 space
> > but with the expectation that such space crosses the administrative
> > boundary between ISP and end-user and should, thus, not be used by the
> > end-user.
> > 
> > b. The IETF had the opportunity to act on these constituents' concerns
> > but failed to take leadership citing, among other reasons, that it
> > would deplete the pool of addresses available to the RIRs from IANA.
> > 
> > c. The ARIN region is satisfied with depleting its own address pool
> > for this purpose.
> > 
> > d. The IAB's suggestion that the proposal be brought back to the IETF
> > is rendered disingenuous by the fact that no addresses remain at the
> > IANA for implementation.
> > 
> > e. Precedent exists for RIRs to unilaterally act on regional
> > imperatives despite potentially global impact. Witness APNIC's
> > abandonment of needs-based allocation.
> > 
> > Because of these points, ARIN has a moral duty to act on behalf of its
> > constituents. Should the IETF desire to reclaim leadership in this
> > matter, ARIN's open public policy process is available to all comers
> > who may request that the addresses be reassigned to any RFC that is
> > produced.
> > 
> > 
> > 3. The case for abandoning 2011-5:
> > 
> > The IETF is the proper venue for a proposal like 2011-5. Such
> > proposals were considered and rejected. 2011-5 is an end-run around
> > around the proper process.
> > 
> > 
> > 4. The case for 2011-5 as a stopgap pending IETF action:
> > 
> > ARIN constituents within the ARIN region have an immediate and
> > pressing need for IP addresses to be used for the interior of multiple
> > NAT translators. This need is not adequately served by the delay
> > inherent in initiating a fresh proposal in the IETF's standards
> > process, it is not adequately served by RFC1918 and it is poorly
> > served by having every ISP use its own unique space allocated by ARIN.
> > Due to the IETF's failure to act in a timely manner while addresses
> > were still available to them from IANA, ARIN has a duty to act on its
> > constituents' imperative.
> > 
> > Nevertheless, global assignment of addresses to purposes rather than
> > registrants properly belongs with the IETF. ARIN should facilitate the
> > IETF retaking the leadership on the matter by ending the ARIN-region
> > policy and ceding the /10 address block back to IANA after the IETF
> > debates, drafts and publishes an RFC that the board of trustees
> > believes meets or exceeds ARIN constituents' expectations for these
> > addresses.
> > 
> > 
> > For your consideration,
> > Bill Herrin
> > 
> > 
> > 
> > --
> > William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> > Falls Church, VA 22042-3004
> > _______________________________________________
> > PPML
> > 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:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> 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:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.