Internet Protocol version 6 address management

This article may be deleted soon.
	To oppose or discuss a nomination, please go to CZ:Proposed for deletion and follow the instructions. For the monthly nomination lists, see Category:Articles for deletion. This article deals with the process of obtaining and managing Internet Protocol version 6 (IPv6) address space. The size and other characteristics of the address block assigned will affect many aspects of deployment. After obtaining Internet Protocol version 4 address space, there remain operational issues in effectively managing it. IPv4 supports dynamic, but stateful, address assignment using the Dynamic Host Configuration Protocol (DHCP). In this context, "stateful" means that there is a server that knows the relationship between a specific computer and the address it is given. DHCP implementations, however, usually only know that relationship as between low-level machine identifier (i.e., IEEE 802 address) and IP address. Experience showed that considerable effort was needed to find a machine by its MAC address, and Dynamic DNS update, assuming DNS names could be given to hosts, was operationally superior. There is an upgraded DHCP mechanism that supports IPv6 address assignment, but, in addition, IPv6 has another mechanism, Internet Protocol version 6 Stateless Address Autoconfiguration (SLAAC), in which there is no addressing server; a host computes its own address. For SLAAC to be operationally manageable, there needs to be a means of matching hosts to general identifiers, and, again, Dynamic DNS update appears to be the only viable mechanism. Best practices are evolving. Sources used here include the ARIN IPv6 wiki and the IPv6 Portal General principles, perhaps counterintuitive to IPv4 experience Subnet assumptions Each network segment (LAN, VLAN, etc.) should be a /64. Remember that 48 bits of that will be the MAC, feeding into the EUI64 process used by stateless autoconfiguration. The remaining /16 bits gives quite a bit of room for internal aggregation (e.g., OSPF#area|OSPF areas). Aspects of good IPv6 management will be quite counter-intuitive for experienced IPv4 network designers and administrators. For example, the IETF expects that you will assign a /64 even for point-to-point links. Fewer typos because all subnets are the same size You can use longer prefixes but what's the point? /127 was originally usable, then rendered obsolete due to the Subnet Routers' Anycast address ... but is now *possibly* coming back into the acceptable practice realm for security reasons /126 will break Mobile IPv6 Home Agent discovery /112 leaves final 16 bits free for Node IDs Use /64 unless you have read and understand RFC 3627 Private addresses Before assuming the need for private addresses in the style of RFC1918, think long and hard about why they are needed in an IPv6 context. Even in IPv4, RFC1918 has not been a panacea, especially after mergers and divestitures, or a need for an extranet VPN, or simply to expand the address space. The IPv6-ish way to creat a ULA prefix as defined in RFC4193 Use http://www.sixxs.net/tools/grh/ula/ web tool to generate one Add it to the registry at the above site, if you want people to know that this is your private space Make sure your internal registry people are aware of your ULA prefix(es) so that everybody uses it correctly Note that the use of ULAs is not widespread, and in many environments it is not desirable (assuming Globals will also be present, another address space to operate (manage, filter, route, etc.)). End user organizations The enterprise network should receive a prefix sufficient to provide a /48 allocation for each site (office/campus/PoP) at which the company has employees or systems. Organizations may have multiple /48s for groups of sites; there will need to be justification that the larger blocks will be adequately used, according to address registry guidelines, within five years. Orgainzations with multiple /48 allocations should consider enterprise-wise aggregation levels of /60 or larger blocks for the administration of enterprise policies for common functions such as: DMZ Realtime traffic, such as voice & video Network loopback addresses and Link space End user sites For end user sites, the basic allocation is assumed to be a /48, which allows 65k subnets (larger allocations are possible, simply requiring justification). When considering this number of subnets, remember that the large address space is meant to avoid the complexities of the many lengths of subnets common in real-world IPv4 implementations. Per the IETF - No subnets, with an exception for loopbacks, will use prefixes longer than /64 and the /128 loopback assignments would normally come out of a specific /64 block. The above specification does have some exceptions, places where the "real world" might disagree with the IETF. /56 for "SOHO" / Home-User allocations is an accepted practice The use of longer-than-/64 prefix lengths is discussed above Service providers All customers get one /48 unless they can show that they need more than 65k subnets. Host count is irrelevant. Do not assign to customers from PoP aggregates Define aggregate areas which contain several PoPs Carry customer networks in iBGP Aggregate only in eBGP If you have lots of consumer customers you may want to assign /56s to private residence sites. Expect the registry to allocate a /32 and reserve one /32 Plan for the time when you get a second allocation giving you a /31 aggregate. If you get more than /32 first time round, ask the RIR how much is reserved so you can plan appropriately. References