IPv6 Address Allocation at SLAC

Draft, V3.0

ipv6-l (SLAC IPV6 Mailing List), 03/04/2003

(Based on first drafts from Davide Salomoni)

---

IPv6 Addresses: overview

IPv6 addresses are 128 bit (16 bytes) long, compared to the 32 bit (4 bytes) addresses of IPv4. The address allocation for the IPv6 addresses is managed, as for the IPv4 addresses, by the Regional Local Internet Registries (for the Americas, ARIN, http://www.arin.net).

One of the goals the IPv6 suite wants to reach is that of efficient address allocation, both in terms of routing table allocation and of routing performance; the IPv6 addresses being so bigger than IPv4 addresses, it's necessary to think right from the start about hierarchical allocation of the address space. As an example of this, ARIN have allocated a CIDR (Classless Inter-Domain Routing) block of IPv6 addresses to ESnet; ESnet, being at the moment our "Internet service provider", have allocated to SLAC a subset of their IPv6 addresses.

The SLAC IPv6 Addresses

PRT Prefix

The IPv6 addresses allocated by ESnet to SLAC are the block 2001:0400:0e10::/48; this means that all of the SLAC IPv6 addresses will begin with these 6 bytes. These 6 bytes are called the Public Routing Topology (PRT) prefix. Since an IPv6 address is made of 16 bytes, we are left with 10 bytes to allocate. This document details the internal allocation of the SLAC IPv6 addresses.

Let's examine the various parts of the PRT prefix; to do this, we need to write it in binary form (see RFC2373, RFC3188 for more details):

20	01	04	00	0e	10
00100000	00000001	00000100	00000000	00001110	00010000

• starting from the left, the first 3 bits (001) are called the Format Prefix (FP); at the time of this writing, the FP is set to 001 for all the assigned IPv6 addresses.
• the next 13 bits (0000000000001) designate the Top Level Aggregator (TLA) ID; the TLA ID = 1 is the first one to be assigned by the Internet Registries; in the future, other TLAs may be assigned.
• the next 16 bits (0000010000000000) are called the Sub-TLA ID, and indicate the assignment that ARIN has given to ESnet: 2001:0400::/32;
• the next 24 bits (0000111000010000) are called the Next-Level Aggregation ID (NLA); ESnet has allocated this number to SLAC.

Rationale for the SLAC IPv6 Addresses

The new address allocation should cover the following issues:

• scalability; extension of the routed/switched SLAC network should not affect performance.
• support of new hosts and LANs; we want that our new address allocation be able to cope with foreseeable increases in the number of LANs and/or hosts.
• support for mobile/remote users; it's reasonable to allocate a set of addresses right from the start, to be used for the interconnection of mobile and/or remote users.
• support for testing and security.
• future services (reserved block)

Address allocation

The EUI-64 standard identifies a networked interface at the physical layer (what we usually call now the "MAC Address"); this identification is stored in the last 64 bits of the IPv6 address. In other words, the last 8 bytes of an IPv6 address (rather than the current 6 bytes of e.g. an Ethernet address) are used for interface identification.

We are therefore left with 128 (original IPv6 address) -48 (SLAC PRT prefix) -64 (interface ID) = 16 bits to create our hierarchical IPv6 address space. These 16 bits are called the Site-Level Aggregation (SLA) ID.

The SLA ID, starting from the leftmost bit, is defined here as follow:

• the first 4 bits define the service ID; this allows up to 16 services, of which the following are defined:
  0000 : test
  0001 : ordinary LAN
  0010 : LAN belonging to the SLAC Internet-Free Zone (IFZ); these addresses won't be routed outside SLAC, using ACLs on the appropriate routers.
  Other services may be defined in the future.
• the next 6 bits are reserved for future use and are set to 0.
• the meaning of the next 6 bits depends on the service ID. For tests (service ID = 0000), these bits define the test ID. For ordinary LANs (service ID = 0001), these bits define the LAN ID. Without using any of the reserved bits, this would allow a maximum of 64 LANs (we currently have around 25 VLANs); if the evolution of the SLAC network will call for other types of allocation, the LAN ID could be either simply expanded using some of the reserved bits (to allow more LANs), and/or the reserved bits could be used to define other types of hierarchy (that is, one could impose another level of hierarchy, based for example on building number). The same considerations apply to IFZ LANs (service ID = 0010). Other services may define these bits differently.

With this allocation structure, an example of a complete IPv6 test address for test ID = 1 will be the following:

20	01	04	00	0e	10	00	01
00100000	00000001	00000100	00000000	00001110	00010000	00000000	00000001
SLAC PRT Prefix						Service ID	Test ID	64-bit Interface ID

An host in LAN 1 will have the following IPv6 address:

20	01	04	00	0e	10	10	01
00100000	00000001	00000100	00000000	00001110	00010000	00010000	00000001
SLAC PRT Prefix						Service ID	LAN ID	64-bit Interface ID

And finally, an IFZ address for IFZ LAN 1 will look like the following:

20	01	04	00	0e	10	20	01
00100000	00000001	00000100	00000000	00001110	00010000	00100000	00000001
SLAC PRT Prefix						Service ID	LAN ID	64-bit Interface ID

It is likely that it will take some time before all the IPv6 features (among them, routing infrastructure, automatic DNS updates, general availability of IPv6 stacks on hosts) are in place; this transitional period will be very beneficial to validate this proposal. Even renumbering hosts, thanks to the IPv6 autoconfiguration, won't be much of a problem - the only things that will have to be manually changed in case this plan is modified (provided DNSv6 is working properly) are the IPv6 prefixes on the routers.

Back to IPV6 Main Page