I support this. Scott
> On Sep 13, 2022, at 7:46 AM, ARIN <i...@arin.net> wrote: > > > The following Draft Policy has been revised: > > * ARIN-2022-2: Remove Barrier to BGP Uptake in ASN Policy > > Revised text is below and can be found at: > > https://www.arin.net/participate/policy/drafts/2022_2/ > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion to assess the conformance of this Draft Policy with > ARIN's Principles of Internet number resource policy as stated in the Policy > Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/participate/policy/pdp/ > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/participate/policy/drafts/ > > Regards, > > Sean Hopkins > Senior Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > > Draft Policy ARIN-2022-2: Remove Barrier to BGP Uptake in ASN Policy > > Problem Statement: > > The current requirements for getting an ASN have resulted in confusion > particularly for new entrants, who have their hands more than full with the > mechanics of getting BGP up and running. The availability of 32 bit ASNs > provides an opportunity for the removal of unnecessary constraints and > processes for the allocation of ASNs. > > ARIN does not provide guidance to use RFC1918 space if possible and likewise > ARIN should not require the use of private ASNs in preference to public ASNs. > > Further Technical Rationale: > > Four octet (32 bit) ASNs were defined in May 2007 in RFC 4893. It has taken > several years for routing equipment in general use to catch up, but today 32 > bit ASNs are generally accepted and it is rare that an organization which has > been issued a 32 bit ASN comes back to ARIN and says they need a 16 bit ASN > instead. > > The austerity measure of requiring extensive documentation to get an ASN is > left over from the days of 16 bit ASNs (total space 65000). It is no longer > appropriate and we should align our conservation requirements with those > found in other 32-bit spaces (total space four billion). Consider: > > A /32 of IPv6 space is the default allocation and will be assigned to any ISP > that requests it. > > Temporary assignment of a /32 of IPv4 space can be acquired on most > residential ISPs by issuing a DHCP request. > > We propose making issuance of the first 32 bit ASN for any ORGID (or each > site for organizations that have number resources under multiple discrete > networks policy) be pro-forma upon request. If an org’s technical people > think they need a public ASN, they probably do! > > Policy statement: > > Replace the entirety of Section 5, which currently reads: > > There are a limited number of available Autonomous System Numbers (AS > Numbers), therefore, it is important to determine which sites require unique > ASNs and which do not. If a unique ASN is not required for a given network > design, one or more of the ASN reserved for private use should be utilized. > Those numbers are: 64512 through 65534 and 4200000000 through 4294967294 > inclusive. > > In order to be assigned an ASN, each requesting organization must provide > ARIN with verification that it requires a unique routing policy, such as a > plan: > > To originate announcement of IP Number Resources via an accepted protocol > (such as Border Gateway Protocol) from an ASN different than that of its > upstream provider; > > To multihome a site with one or more Autonomous Systems; or > > To use an ASN to interconnect with other Autonomous Systems. > > ASNs are issued based on current need, as set out in this section 5. > > With the following new Section 5: > > Any organization may be issued a single Autonomous System Number (ASN) upon > request. Organizations that have space issued under Multiple Discrete > Networks policy may be issued one ASN per discrete network upon request. > > Additional ASN requests should include proof of the requestor's need for a > unique routing policy, or other technical justification for the need for more > than one ASN. > > Timetable for implementation: Immediate > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues.
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
