One of my readers was reading the Preparing an IPv6 Addressing Plan document on RIPE web site, and found that the document proposes two approaches to IPv6 addressing: encode location in high-order bits and subnet type in low-order bits (the traditional approach) or encode subnet type in high-order bits and location in low-order bits (totally counter intuitive to most networking engineers). His obvious question was: “Is anyone using type-first addressing in production network?”

Terastream project seems to be using service-first format; if you’re doing something similar, please leave a comment!

Wait, what?

The traditional approach to devising an IPv[46] addressing plan goes along these lines:

• Get your own address space (or use RFC 1918 address space);
• Assign a prefix to every site. In IPv6 world it’s possible to use fixed-length prefixes regardless of site size – if you get a /32 prefix for an enterprise network it’s pretty comfy giving each site a /48, and even a large site might not have more than 64K subnets (the number of /64 prefixes in a /48 prefix);
• Assign each segment within a site a subnet (or a /64 prefix in IPv6 world) within the site prefix.

This is what the RIPE document calls “Location First” addressing. Well known, used in almost all networks, and easy to summarize.

The alternative approach (called Type First in RIPE document) assigns a few highest bits within your address space to subnet type, and then assigns a type-specific prefix to every site. Segments of that type are then numbered from the address space of the type-specific site prefix.

The Type First approach obviously messes up per-site summarization (each site needs N prefixes – one per type – in the enterprise WAN routing table). The only reason one would want to use this approach is to simplify security policy enforcement – it’s easy to match traffic belonging to a security zone by matching on high-order bits.

The Type First approach is another wonderful example of MacGyver approach to networking. Instead of yelling at vendors who cannot match IPv6 addresses with discontiguous don’t care bits (like we could do in IPv4) and voting with our wallets we’re considering revamping addressing plans to work around vendor limitations.

Does It Matter?

Frankly, it doesn’t. Unless you’re using broken data center switches that only support 1K IPv6 routes and insert all WAN routes into the data center routing domain, it doesn’t matter too much how many IPv6 prefixes you have in your enterprise WAN routing table (OSPF’s route computation time depends primarily on the number of routers, not prefixes).

In any case, as Ron Broersma (one of the few true IPv6 deployment veterans) usually says in his IPv6 presentations, “Don’t spend too much time on your IPv6 addressing plan. You’ll inevitably get it wrong the first few times” … and renumbering an IPv6 network is not such a big deal if you’re using a templating tool to generate your ACLs and object groups in your firewall rules.

More information

Before starting your IPv6 address planning exercise, you (RFC 2119) MUST read the fantastic document written by Enno Rey and you SHOULD read all they have to say on IPv6 anyway.

Also, check out the IPv6 resources page on ipSpace.net – you might find what you’re looking for in one of the IPv6 webinars, or discover that what you really need is an on-site IPv6 workshop.