Getting Started with IPv6 Migration
Wednesday January 17, 2018
We’ve had a look at the theory behind migration to IPv6. Now have a look at how to put this into practice.
If you’re going to migrate to IPv6, you’re going to need some IPv6 addresses. There are two ways to get these. One is to go to your provider and get them to give you addresses.
The other is to get some addresses of your own. This is called Provider Independent (PI) addressing and is the most flexible option. This is the option we’ll focus on here.
Step 1: Find your local RIR. IANA is the organisation responsible for IP address allocation. They allocate addresses to Regional Internet Registries (RIRs). The RIR, in turn, allocate addresses to you.
The RIR you work with will depend on where you are in the world. Have a look at IANA’s website to find your RIR.
Step 2: Register with the RIR. You will need an account to begin. This normally includes a yearly membership fee. The fee varies per RIR, but as an example, APNIC membership is $500 per year.
To become a member, you need to submit an application. It may take up to a week before you get approved.
Once you have a membership, you can begin to request some resources.
Step 3: Get some addresses. IPv6 address blocks are typically assigned in /48 or /32 address blocks. Different RIRs may have different sized blocks available for allocation. Some may even allocate a /56 for very small customers.
The size of the block that you’re entitled to will depend on your needs. If you have customers that you need to allocate addresses to, you will be entitled to more addresses.
Each allocation will have an additional cost. The cost is calculated according to a complicated formula. There is usually a fee calculator to help you out.
Step 4: Get an Autonomous System Number. This is optional but required if you want to peer with two internet providers. This is another allocation from the RIR.
Step 5: Decide where to start. This is where you need an understanding of the theory. The primary options are:
- Edge to core
- Core to edge
- IPv6 islands
Just like IPv4, it’s important to plan out your address space. Conservation may not be much of an issue, but all the other principles still apply. For example, contiguous subnets make summarisation easier.
You probably already understand address space planning fairly well. Here are just a few tips on how things are different in IPv6.
Allocate /64 subnets everywhere! Yes really. This may come as a shock if you haven’t used IPv6 yet, but it’s all based around /64 allocations. Even point-to-point links will use /64.
Notice that you should allocate /64’s. If you want, you can use a longer subnet mask. A /126 or /127 is fine to use. But remember, in your address plan, allocate a /64.
When you’re allocating addresses to a point-to-point link, consider this scheme. Give one end an ::A address, and the other a ::B address.
There’s no technical reason for this. It’s just to make things simpler for you later. One end will always be ::A, and the other will always be ::B.
Be careful with zero compression. This is when there are a lot of zeroes in the subnet, which get compressed. For example, 2001:0DB8:0000:0000::/64 is compressed to 2001:DB8::/64.
Once again, there’s no technical reason to avoid this subnet. But consider a non-network person. This type of address can be confusing. This example could be improved by allocating 2001:Db8:0:1::/64.
When planning the address space, think hierarchically, and build in some reserve. That is, don’t go around handing out all sequential subnets.
In addition to this, be careful when embedding additional information into IP addresses. This includes VLAN numbers and legacy IPv4 spaces. This may leak information to the internet. You’re not hidden behind NAT anymore, remember?
Also, don’t put link-local addresses into DNS. Link-local addresses aren’t routable and may overlap with other segments. Keep them out of DNS.
RFC 4193 addresses are called Unique Local Addresses (ULA). These are like RFC 1918 private addresses in IPv4. You may be tempted to deploy these in your network, and use NAT.
Avoid this temptation! One goal of IPv6 is to make everything unique. Imagine readdressing later if there’s a merger.
In fact, it’s recommended to only use ULA addresses if you have a very specific need. Some say that they have ‘secret’ networks. If you do, consider route-filtering instead.
Sample Address Plan #1
Here is an example of something you might do. This assumes that you have a /48 block of IPv6 addresses. Subnets are all /64 bits long, which gives us 16-bits to play with.
We allocate addresses hierarchically, like this:
- Location (4-bits): Could be the country, state or so on. Business unit could also be used here
- Buildings (4-bits): Building number, or perhaps sub-levels
- Floors (4-bits): Or perhaps areas within a building
- Traffic Type (4-bits): Such as data, voice, guest, and so on
Sample Address Plan #2
This follows the same scheme as the previous example. This case just changes the order of the bits.
The important thing is to consider how you will summarise traffic. This will depend on your needs, so use your brain here.
Now it’s time to select a suitable method for migration. There’s no one solution to fit every network. To help decide, here are a few questions to ask yourself:
- What is the business goal behind IPv6?
- What type of network is this? Enterprise? Service provider?
- What’s the budget and time frame?
- Do you need IPv6 end-to-end?
- What are the design constraints? Are there legacy applications, old router code, security devices that don’t support IPv6?
- Are the support staff trained to use IPv6?
- Do you need multicast? What about dynamic routing protocols?
Now, decide if you need to remediate the network first. Do you need to upgrade devices to support IPv6 or just tunnel across them?
There’s more to IPv6 than just IP addresses. There are all the additional services that come along with it.
You can allocate addresses dynamically or manually. Manual configuration is quite complicated, especially for workstations and servers. The dynamic options are Stateless Address Autoconfiguration (SLAAC) and DHCPv6.
SLAAC uses an IPv6 RA (Router Advertisement) message to pass the network prefix to clients. Clients use this prefix to configure their own addresses based on their MAC address. SLAAC is limited, as it cannot pass much additional information to the client.
DHCPv6 is the preferred option, as you can pass more information to the clients. This includes DNS servers, NTP servers, IP addresses, and so on.
IPv6 favours dynamic addressing, so DNS is critical. The AAAA record is the A record equivalent for IPv6. These can be delivered over an IPv4 infrastructure. In fact, this is recommended until IPv6 is fully implemented. This is so anything can access DNS from anywhere.
IPv6 may feel new, but it has been around in some form for quite a while. It is actually older than FHRP’s. This is why it has an FHRP of its own built in. It is Neighbour Unreachability Detection (NUD).
The problem with NUD is that it comes from a time before fast convergence was a necessity. It converges in around 30 seconds, which is unacceptable in today’s networks. For this reason, it’s still recommended to use HSRP, VRRP, or GLBP.
IPv6 adds a new footprint to your network that someone may want to exploit. So, you may want to consider creating some security policies. Here, we’ll look at a few of the areas you may want to secure.
Many security principles apply to IPv6 in the same way that they did for IPv4. For example, you need to secure the control plane. One way to do this is to use authentication between peers in your IGP. Other factors are quite different.
While you’re running both v4 and v6, the recommendation is to use IPv4 for management. For example, use SSH over IPv4 to manage your routers. This is because it has proven to be secure, while IPv6 hasn’t been around as long.
Also on the point of migration is tunnelling. The tunnels that you’re using probably don’t include encryption by default. So, if you’re traversing insecure networks, you need to turn this on.
One fundamental difference is that IPv6 does not use NAT in the traditional sense. This means that your IP addresses are known end-to-end. This is just one more reason to use host-based firewalls and IPS systems.
ACL’s have a seemingly small difference with IPv6. They don’t support wildcard masks in IOS. This may have an implication, as this limits the effectiveness of role-based addressing.
IPv6 has a few built-in messages. You may want to filter them out like you might have done with ICMPv4. Try to resist this temptation, as these messages are critical for IPv6 to work correctly. Instead, use the layer-2 security tools shown later.
These messages include:
- Neighbour Discovery (ND)
- Registration authority (RA)
- Duplicate Address Detection (DAD)
Just like IPv4, there are several security tools to use at layer-2:
- RA-Guard – Protects from malicious RA messages, but allowing RA messages only on specified ports
- DHCPv6 Guard – This is the same as DHCP Guard for IPv4
- Source/Prefix Guard – A legitimate prefix is configured. Packets on the layer-2 segment are inspected to see if they are in the allowed prefix
- Destination Guard – Protects against cache exhaustion. This stops an attacker sweeping a segment to fill the cache
There are some security advances in IPv6. IPv6 can really benefit from having PKI in the network. This is because of the Secure Neighbour Discovery (SeND) protocol. This protects against attacks like message spoofing.
This is done with a Cryptographically Generated Address (CGA). This uses the network’s PKI to verify that the sender really owns the IP address it’s sending from.
Packet Life – IPv6 Access Lists on IOS
Cisco Live – BRKSPG-2067 – IPv6 Design and Transition Mechanisms
Cisco Live – Intermediate – Enterprise IPv6 Deployment – BRKRST-2301
Cisco Support Forums – IPv6 Subnetting – Overview and Case Study
Marwan Al-shawi and Andre Laurent – Designing for Cisco Network Service Architectures (ARCH) Foundation Learning Guide: CCDP ARCH 300-320 (ISBN 158714462X)