Classless AS-based Addressing

IP address fragment is one of the most contributing factors that cause scalability problems to the IPv4 inter-domain routing system. The IPv6 routing system will face severe scalability issue if the IPv6 addresses are recklessly used without careful aggregation strategy. This document propose Classless AS-Based Addressing (CABA) scheme, which embeds 32 bits AS number (ASN) into the IPv6 address. If ASNs are properly allocated, CABA can facilitate aggregation of IP addresses and reduce the size of inter-domain routing tables.

The Classless AS-Based address has five fields of fixed lengths, as shown in Figure 1.

IANA /8 field should be allocated by IANA. ASN Low /16 is the lower 16 bits of the AS number. ASN High /16 is the higher 16 bits of the AS number. Subnet /24 should be allocated by individual ASes according to their intra-domain routing policies. Interface /64 is interface ID. All ASNs are assumed as 32 bits long. For a legacy ASN of 16 bits, the higher 16 bits are filled with 0. The document uses AS x.y to denote an ASN whose higher part is x and lower part is y. For example, AS 199081 (0x309a9 in hex) is denoted as AS 3.2473, and the ASN Low /16 field and the ASN High /16 field are 0x09a9 and 0x0003 respectively, as shown in Figure 2.

In order to prevent routing scalability issues, any prefixes that are more specific than the allocated /40 should not be advertised into global routing system. Meanwhile, IPv6 operator must filter BGP updates that contain information of more specific prefixes.

To take advantage of this AS-based addressing scheme, this document suggests to allocate ASNs in a way similar to provider-aggregatable (PA) addresses, where each allocation is made by ASes instead of RIRs. Initially, a legacy 16-bit ASN is regarded as holding 65536 32-bit ASNs. For example, AS 333 holds ASNs from 0.333 to 65535.333. Existing 32-bit ASNs are regarded as holding only one 32-bit ASN and it is not hold by any other AS. For example, if 2.333 exists, AS 333 holds ASNs 0.333, 1.333 and from 3.333 to 65535.333. And each AS can use only one ASN for routing purpose and this ASN is the smallest among all ASNs it holds. When a new AS wants to obtain an ASN, it should choose a provider who holds several ASNs and ask for a unrouted ASN. The provider should response by allocating an ASN or a range of ASNs from its ASN pool according to its policy. Each AS can have its own allocation policy but must conform to the following guidelines: 1. The higher part of allocated ASNs should be successive. 2. The higher part of remained ASNs should be as successive as possible (There might be holes due to historical reasons). For example, if AS 0.333 allocates 4 ASNs to its customer, it should allocate ASNs from 65532.333 to 65535.333. Therefore, an ASN can only decide the number of ASNs in each allocation. As examples, there might be two kind of polices: 1. Allocating a fixed ratio of all ASNs currently hold by the AS. 2. Allocating a fixed number of ASNs. For example, an AS who has ASNs from 0.100 to 65535.100 may choose to allocate 1/4 of its ASNs (49152.1s00~65535.100) or 256 ASNs (65280.100~65535.100). An AS can define its own allocation policy provided the policy conforms to the above guidelines. According to the allocation strategy above, we encode the ASN's lower bits first. Thus ASNs who have the same lower part share a common prefix. As Figure 2 shows, AS 0.2473 and AS 3.2473 share the same prefix [xx]09:a900::/32 and their IPv6 blocks are more likely to be aggregated by ASN allocator AS 0.2473. (xx denote the bits provided by IANA). Therefore, any prefixes that are more specific than the corresponding AS-Based prefix should not be advertised into global routing system. As a result, IPv6 operator must filter the anomalous BGP updates which contain information of more specific prefixes.

For core routers in the Internet, their inter-domain routing tables are usually large and complex. routing tables list the routes to particular network prefixes and some metrics associated with those routes. As there are so many prefixes spreading around the current Internet, core routers' inter-domain routing tables become larger, causing routing system overloaded. In the current Internet, an AS usually announces several prefixes to its neighbors. CABA scheme embeds 32-bit ASN into its IPv6 address. If CABA is adopted in the Internet, the number of spreading prefixes will reduce obviously. One AS deploying CABA can only announce one prefix to other networks. Thus, the size of inter-domain routing tables will never be more than the number of ASes. Figure 3 shows the result of our simulation. The routes from inter-domain routing tables are collected by Routeviews in August, 2016. We choose different proportions of ASes in the Internet randomly to adopt CABA scheme and count the size of inter-domain routing tables.

In addition, since the allocation of ASNs facilitates aggregation of IP addresses (providers can aggregate classless AS-Based addresses which they allocate to customers), the size of routing tables will reduce further.

IANA should allocate a /8 IPv6 address block for this purpose, which is similar to 2002::/8 used by 6to4. No IPv4 allocation required.

This document includes no request to security.

This draft describes an addressing scheme CABA (Classless AS-Based Addressing) and an address allocation scheme which can facilitate aggregation of addresses. CABA can solve the scalability problem of IP address and reduce the size of core RIBs obviously.