A mechanism to allocate IPv6 blocks for BGP networks based on the networks AS Number

IPv6's massive address space provides a wonderful opportunity to radically change the process of IP address allocation. Presently IPv6 allocation is the same process as used by the IPv4 world. The RIRs allocate IPv6 address blocks based on member requests and their space requirements. A minimum allocation of a /48 is believed to be sufficient to start any enterprise in the world of IPv6. Described below is a method to automatically define an IPv6 /48 block that can be used in the global routing tables for any ASN.

The /48 address is allocated using a fixed pattern.

The sum of the bits in the IANA allocated /16 prefix plus the 32 bits of the ASN plus the /48 of user defined usage adds up to 128 bits. Bits Usage 16 IANA provided prefix 32 ASN 80 User defined 128 TOTAL The end network can allocate out of the assigned /48 as needed. It is assumed that the end network will use this allocation for global routing; however the network may choose to not announce this allocation. If any route is announced from this allocation, any prefixes more specific than the allocated /48 must not be propagated in to the global IPv6 routing table. This is to prevent the IPv6 routing table from becoming too large. Therefore, a site which uses this allocation MUST NOT advertise a more specific than the allocated /48 routing prefix. All native IPv6 network operators MUST filter out and discard any routing prefix advertisements longer than /48 from within this /16 allocation.

IANA is to allocate a /16 in a similar manner to the 2002::/16 allocation for 6to4 which is used by the 6to4 protocol.. No IPv4 allocation by IANA is required.

ASNs are now defined as 32 bits long. If a network operates a smaller 16 bit ASN (for example an earlier allocation) then there are 16 bits of zeros prepending the ASN number. No provision is provided within this allocation methodology to provide 16 bit ASNs with an advantage as this could cause an overlapping allocation. No special treatment is provided an operator of a 16 bit ASN; All ASNs are considered to use 32 bits.

ASNs are normally expressed as human-readable decimal numbers; yet for this allocation the number should be converted into a hexadecimal notation. All IPv6 addresses are written in hexadecimal. (NNNN represents the /16 allocation by IANA) ASN in decemal. ASN in hexadecimal Sample IP block AS1 1 NNNN:0000:0001::/48 AS6939 1B1B NNNN:0000:1B1B::/48 AS29001 7149 NNNN:0000:0001::/48 AS393220 60004 NNNN:0006:0004::/48 A network is assigned an ASN via the existing RIR process. Only valid ASN holders can use this ASN-based prefix.

ASNs are allocated by RIRs and this RFC does not handle that arena. ASNs defined as private ASNs MUST NOT use this scheme. The special 16-bit ASN 23456 MUST NOT use this scheme.

Filtering would be a simple case of mapping the final ASN in a path to the prefix in an exact bit-order match. For example; the prefix NNNN:0000:1B1B::/48 should only be seen as announced from AS6939 (6939 equals 0x1B1B in hex). Networks would have their upstream transit providers add this /48 prefix to their existing inbound BGP route filters.

In order for the IPv6 /48 to have valid whois information RIRs will have to map it from their existing ASN whois data. The whois data for the /48 should be the same as the ASN whois data.

It is suggested that RIRs, via their Internet Registry services, support these automatic assignments (including but not limited to whois and reverse DNS). The RIRs should provide these services in addition to the services already provided for the associated AS number.

Reverse DNS is vital to the operation of the global Internet. Any block allocated via this mechanism should include the ability to have the network operator provide reverse DNS entries. It is proposed that the first /64 from the allocated /48 have the rDNS services hard coded into the ::1 and ::2 addresses. This allows reverse DNS to operate without intervention or RIR involvement.

This mechanism is not expected to have any impact to the global Internet routing table since existing policies in the RIR system already readily provide for the allocation of provider-independent IPv6 prefixes. Additionally, AS number holders are likely to be multihomed entities which were going to be independently routed in any case. Service Providers are, as always, not obligated to route these IPv6 assignments and/or may establish conditions of service which offset any additional routing cost.

This memo includes a request to IANA to allocate a /16 from the available IPv6 address space.

There is clearly a need for RPKI ROAs for all allocated ASNs within an RIR. The mapping would be 1:1 from ASN to /48 prefix. Hence an RIR allocating an ASN should also allow the holder of that ASN to manage this IPv6 prefix via their RIR portal. There is nothing different in with a prefix from this space than from a prefix allocated by an RIR.

We would like to thank the following people. ???? We would also like to also thank the contributions from people in the industry that have promoted IPv6 and multihoming: Bill Manning (as himself) and Randy Bush (IIJ).