[arin-ppml] Revised - Draft Policy ARIN-2022-2: Remove Barrier to BGP Uptake in ASN Policy

[Scott Leibrand]

If someone uses a private ASN to announce a route, that route still takes
RIB/FIB space, it just has its origin ASN as the upstream provider's ASN.

-Scott

On Sat, Sep 17, 2022 at 10:22 PM Adam Thompson <athompson at merlin.mb.ca>
wrote:

> I’m on the fence.
>
>
>
> I think the scarce resource is no longer 16-bit ASNs but is now FIB space
> on routers.  I even know of a few where RIB space is the issue, not FIB.
> We’re not – that I know of – about to hit another 512k day or similar in
> the next six months, but there are a lot of routers out there that can only
> handle 1M IPv4-sized routes.
>
>
>
> I agree with your logic (the comparison to RFC1918) but I am concerned
> about an explosion of ASNs and corresponding routes.  I’m assuming an
> explosion of ASNs will equate an explosion of routes, v4 and/or v6, as
> otherwise, why would you need a public ASN?
>
>
>
> Separately, I don’t see anything wrong with the modifications proposed in
> the Staff Review – they seem sound, although I wish the full proposed
> rewritten section had been included, in addition to the item-wise
> commentary.
>
>
>
> -Adam
>
>
>
> *Adam Thompson*
>
> Consultant, Infrastructure Services
>
> [image: MERLIN]
>
> 100 - 135 Innovation Drive
>
> Winnipeg, MB R3T 6A8
>
> (204) 977-6824 or 1-800-430-6404 (MB only)
>
> https://www.merlin.mb.ca
>
> Chat with me on Teams
> <https://teams.microsoft.com/l/chat/0/0?users=athompson@merlin.mb.ca>
>
>
>
> *From:* ARIN-PPML <arin-ppml-bounces at arin.net> *On Behalf Of *Scott
> Leibrand
> *Sent:* September 13, 2022 12:20 PM
> *To:* ARIN <info at arin.net>
> *Cc:* PPML <arin-ppml at arin.net>
> *Subject:* Re: [arin-ppml] Revised - Draft Policy ARIN-2022-2: Remove
> Barrier to BGP Uptake in ASN Policy
>
>
>
> I support this.
>
> Scott
>
>
>
> On Sep 13, 2022, at 7:46 AM, ARIN <info at 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 at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20220918/d774d653/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 13827 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20220918/d774d653/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 359 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20220918/d774d653/attachment-0001.png>