I will reiterate my comment that /44 is too stringent and /48 should be used instead.
Owen On Oct 21, 2014, at 7:20 AM, Milton L Mueller <[email protected]> wrote: > > Based on feedback from NANOG, our Baltimore general meeting, and the AC > meeting and list I have revised 2014-1 for what I hope is the last time. I > have updated the Wiki and am requesting staff and legal review. > > I believe the proposal is technically sound, enables fair and impartial > resource allocation and has widespread community support . > > Full amended text below. Note that I have also amended the problem statement > to reflect the revisions. The earlier text about defining out of region use, > engagement of external entities, etc is no longer needed and thus is gone. > The comments section is also modified to reflect the overall simplification. > > Milton L. Mueller > Laura J. and L. Douglas Meredith Professor Syracuse University School of > Information Studies http://faculty.ischool.syr.edu/mueller/mueller/Home.html > > === > > Draft Policy ARIN-2014-1 Out of Region Use > > Date: 21 October 2014 > > Problem statement: > Current policy neither clearly forbids nor clearly permits out or region use > of ARIN registered resources. This has created confusion and controversy > within the ARIN community for some time. Earlier work on this issue has > explored several options to restrict or otherwise limit out of region use. > None of these options have gained consensus within the community. The next > logical option is a proposal that clearly permits out of region use while > addressing some of the concerns expressed about unlimited openness to out of > region use. > > Policy statement: > > Create new Section X: > > ARIN registered resources may be used outside the ARIN service region. Out of > region use of IPv4, IPv6, or ASNs are valid justification for additional > number resources if the applicant is an ARIN member in good standing and is > currently using at least the equivalent of a /22 of IPv4, or a /44 of IPv6, > or 1 ASN within the ARIN service region, respectively. > > The services and facilities used to justify the need for ARIN resources that > will be used out of region cannot also be used to justify resource requests > from another RIR. When a request for resources from ARIN is justified by need > located within another RIR's service region, an officer of the applicant must > attest that the same services and facilities have not been used as the basis > for a resource request in the other region(s). ARIN reserves the right to > request a listing of all the applicant's number holdings in the region(s) of > proposed use, but this should happen only when there are significant reasons > to suspect duplicate requests. > > Comments: > a. Timetable for implementation: Immediate b. Anything else Current policy is > ambiguous on the issue of out of region use of ARIN registered resources. The > only guidance on the issue in current policy is Section 2.2, which defines > the the role of RIRs as "to manage and distribute public Internet address > space within their respective regions." Some in the community believe this > means out of region use should be prevented or restricted, while others > believe this is only intended to focus efforts within the region and not > define where resources may be used. > Previous policy proposals have explored restricting or otherwise limiting out > of region use, but none have gained consensus within the ARIN community. > Several standards for restricting out of region use were explored, but all of > them were perceived as interfering with the legitimate operations of multi- > or trans-regional networks. > The requirement to have a minimal level of resources deployed in the region > (/44 for IPv6, /22 for IPv4, 1 ASN) is an attempt to respond to law > enforcement and some community concerns. An absolute threshold ensures that > those applying for ARIN resources are actually operating in the region and > not simply a shell company, but it avoids the known pitfalls of trying to use > percentages of the organization's overall holdings to do that. The use of > officer attestation and the possibility of an audit is an attempt to prevent > duplicate requests without requiring burdensome reporting requirements. > In summary, this proposal ensures that trans-regional organizations or > service providers operating within the ARIN region may receive all the > resources they need from ARIN if they wish to do so. This change is > particularly important for IPv6. Requiring organizations get IPv6 resources > from multiple RIRs will result in additional unique non-aggregatable prefixes > within the IPv6 route table. > > _______________________________________________ > ARIN Proprietary & Confidential Information ARIN-COUNCIL mailing list > [email protected] http://lists.arin.net/mailman/listinfo/arin-council > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
