HTTP/2 200 date: Mon, 14 Jul 2025 01:35:35 GMT content-type: text/plain content-length: 1346 x-xss-protection: 1; mode=block referrer-policy: no-referrer, same-origin, strict-origin-when-cross-origin x-frame-options: SAMEORIGIN x-content-type-options: nosniff last-modified: Mon, 21 Jan 2019 23:36:35 GMT etag: "d28-5800054d2a6c0-gzip" cache-control: max-age=3600, public expires: Mon, 14 Jul 2025 02:35:35 GMT vary: Accept-Encoding content-encoding: gzip x-envoy-upstream-service-time: 3 strict-transport-security: max-age=15552000; preload cf-cache-status: MISS accept-ranges: bytes content-security-policy: frame-ancestors 'self' https://rex.apnic.net https://rex.stg.xyz.apnic.net server: cloudflare cf-ray: 95ed48c7ce141712-BLR ---------------------------------------------------------------------- prop-128-v001: Multihoming not required for ASN ---------------------------------------------------------------------- Proposers: Jordi Palet Mart?nez jordi.palet@theipv6company.com 1. Problem Statement -------------------- When the ASN assignment policy was originally designed, the reliability of networks was not so good as today. So, at that time, it was making sense to make sure that and ASN holder is multihomed. However, today this is not necessarily a reasonable requirement, and even in some cases, some networks may require an ASN and not willing to be multihomed (because the cost, or remote locations that have only a single upstream, etc.), and their SLA requirements don?t need that redundancy. The deployment of IPv6 also increase the need for organizations which are not ISPs, to obtain IPv6 PI in order to have stable addresses, and in that situation, ideally, they should announce their PI space with their own ASN. In most cases, they don?t have to be multihomed. 2. Objective of policy change ----------------------------- To ensure that organizations which have their own routing policy and the need to interconnect with other organizations, can do it. Interconnect is used here with the commonly understood meaning of establishing a connection between two (administratively) separate networks. 3. Situation in other regions ----------------------------- ARIN and LACNIC don?t require multihoming. RIPE requires it. AfriNIC has a policy equivalent to APNIC, but I?m submitting a proposal similar to this one to change it as well as in the case of RIPE. 4. Proposed policy solution --------------------------- Current Policy text 12.1. Evaluation of eligibility An organization is eligible for an ASN assignment if: - it is currently multihomed, or - it holds previously-allocated provider independent address space and intends to multihome in the future. An organization will also be eligible if it can demonstrate that it will meet the above criteria upon receiving an ASN (or within a reasonably short time thereafter). Requests for ASNs under these criteria will be evaluated using the guidelines described in RFC1930 'Guidelines for the creation, selection and registration of an Autonomous System' (AS). Proposed text 12.1. Evaluation of eligibility An organization is eligible for an ASN assignment if: - it is multihomed or - has the need to interconnect with other AS. An organization will also be eligible if it can demonstrate that it will meet any of the above criteria upon receiving an ASN (or within a reasonably short time thereafter). Requests for ASNs under these criteria will be evaluated using the guidelines described in RFC1930 'Guidelines for the creation, selection and registration of an Autonomous System' (AS). 5. Advantages / Disadvantages ----------------------------- Advantages: Fulfilling the objectives above indicated. Disadvantages: None foreseen. 6. Impact on resource holders ----------------------------- None. 7. References ------------- https://www.arin.net/policy/nrpm.html#five https://www.lacnic.net/683/2/lacnic/ https://www.ripe.net/publications/docs/ripe-679