10. [Optional] IPv6 and RIPng

Don’t worry if you don’t have much time to do this. The parts regarding subnetting and addressing will be covered as a class-exercise in the upcoming lab on Subnetting. Students wanting to do this section should not find it difficult, but will benefit greatly from watching the 20-minute video on IPv6 Subnetting in the Lab Resources.

RIP (either version 1 or 2) doesn’t have support for IPv6. Instead, we have RIPng (RIP Next Generation)[83], which is an extension of RIPv2, although some features, such as authentication, are not supported in RIPng[84].

10.1. Design the Subnetting and Addresses

Let’s begin by doing a little bit of addressing. This is starting to get into the up-and-coming subnetting lab, but this is rather easy (easier than IPv4 with public IP addresses).

If we want to subnet our network, we first need a network allocation. We’ll create one using Unique-local addresses, and then subnet that. A Unique-local address can easily be generated using random numbers, but we can generate fewer clashes by basing it on something that is already reasonably globally unique, such as an Ethernet MAC address. Point your web browser to Generate Unique Local Address and put in the MAC address of any of your interfaces, such as any one of the interfaces on R1.

Write down the network allocation that has been generated; this is what we shall be subnetting. For this example, I’m using fd49:59ab:879f::/48; you should use the one you generated.

The allocation that you generate will contain 48 bits for the network ID. We typically want subnets no smaller than a /64, so we have 16 bits to use for subnetting. If we were to only allocate subnets of size /64, then we have up to 216 subnets, and a routing entry for each!

If, however, we wanted to provide some more hierarchy in our addressing plan, and allow some of these divisions to be further subnetted, then we should use some intermediate size. For example, if we allocate subnets of size “/56”, then that means we’ve used 56-48=8 bits for our subnet IDs. This means we can have 28=256 subnets of size “/56”.

IPv4 conditioned us to like subnetting on 8-bit boundaries. This is because IPv4 addresses are dotted decimal, and each decimal was 8-bit integer (0—255). IPv6, on the other hand, uses hexadecimal notation, so we can naturally work easily with 4-bit boundaries.

In the example above, if 216=65,536 subnets is too many, and 28=256 is worryingly few, we could compromise and use subnets of size “/60”, which would give us 260-48=212=4096 subnets, and each subnet could have 4 bits of subnet ID remaining which could be used for further subnetting. This is good, because dealing with subnets smaller than a /64 is not good for hosts, as you can’t use SLAAC in that case.

Since this is our first network, let’s just assume for now that we want each subnet in our network to be a /56. Bear in mind, though, that we could have a mixture of different subnet sizes if we needed, but we can keep things simple for now.

So, looking at the network map, give each of the five subnets a number; because we’ve already got a nicely organised IPv4 network running in parallel, we shall save some confusion and use the same subnet IDs. Allocate a /56 to each subnet in your network. You might end up with something like the following. This is also shown on the map in Figure 21, “IPv6 Subnetting and Addressing”.

Network allocation:   fd49:59ab:879f::/48
   subnet 1:                       …:01│00::/56
   subnet 2:                       …:02│00::/56
   subnet 3:                       …:03│00::/56
   subnet 4:                       …:04│00::/56
   subnet 5:                       …:05│00::/56
                                       ↑ /56 boundary

Figure 21. IPv6 Subnetting and Addressing

IPv6 Subnetting and Addressing

The subnetting and addressing plan for our network.


Note that I have shown the network identifier as ommitted in the various subnets, to try and aid your understanding of how the addressing scheme is structured. The full prefix of subnet 3, for example, is fd49:59ab:879f:0300::/56.

Please also note that I have shown the subnet ID as 0300, and NOT as 03, because then you might be tempted to write fd49:59ab:879f:03::/56, which is NOT THE SAME, as the latter is actually fd49:59ab:879f:0003::/56. Only the first two digits (8 bits) of 0300, for example, are being used here as the subnet ID, the remaining bits up to the 64th bit would typically be zero and available for further subnetting.

But we’re not quite done yet. We want to use SLAAC to advertise a prefix onto our ethernet segments. According to RFC 2464 — “Transmission of IPv6 Packets over Ethernet Networks” — the prefix length must be exactly 64 bits. So in our case we’ve given ourselves a prefix of /56, but we only offer a smaller /64 out of that. What happens with the left-over bits? They remain available for further subnetting, should we desire to subnet one of the networks further. Figure 22, “IPv6 Subnetting Allowing for Growth” shows one possible way in which the network might grow. Note that by reserving some bits for subnetting, we allow for more hierarchical addressing which leads to more efficient routing: the number of routes that the other routers need to know about remain the same bacause they can easily be summarised.

Figure 22. IPv6 Subnetting Allowing for Growth

IPv6 Subnetting Allowing for Growth

The subnetting of our IPv6 network, showing why it is useful to reserve some bits for subnetting.


Routers don’t use address autoconfiguration, so each will need a static address. We’ll be simple and just use a host ID of 1, 2 and 3 for routers R1, R2 and R3. There is no requirement to do it quite like this, it’s just to make addresses easier to recognise. Figure 21, “IPv6 Subnetting and Addressing” shows the addressing structure of our network, as we have discussed it. Write down the address for each interface on R1, R2 and R3. Note that clients C1 and C2 still use address autoconfiguration.

R1  eth0     fd49:59ab:879f:0400::1
R1  eth1.10  fd49:59ab:879f:0100::1
R1  eth1.20  fd49:59ab:879f:0200::1
R2  eth0     fd49:59ab:879f:0500::2
R2  eth1.10  fd49:59ab:879f:0100::2
R2  eth1.30  fd49:59ab:879f:0300::2
R3  eth0.20  fd49:59ab:879f:0200::3
R3  eth0.30  fd49:59ab:879f:0300::3

10.2. Configure Interfaces

Now that we have designed the addressing and have assigned addresses for each interface, let’s now affect those assignments. You should consult the Vyatta IPv6 documentation for the full details. Here is an example of configuring just the eth1 VLAN 10 interface on R1:

configure
set interfaces ethernet eth1 vif 10 address fd49:59ab:879f:0100::1/56
commit
run show interfaces

Use ping6 address (if you’re still in configuration mode, use run ping6 address) and test that you can contact all of your neighbours.

Use show ipv6 route to view the IPv6 routing tables.

You’ll also want to enable router advertisements on at least R1’s eth0 interface, and similarly on R2:

set interfaces ethernet eth0 ipv6 router-advert prefix fd49:59ab:879f:0400::/64
commit

Use ifconfig or similar on the clients to ensure they have an address.

10.3. Configuring RIPng

Configuring RIPng is much like the IPv4 equivalent in Vyatta. The first thing to do is ensure that IPv6 forwarding is turned on, or perhaps it would be better to ensure it hasn’t been disabled:

delete system ipv6 disable-forwarding  Not needed now, was in earlier versions of Vyatta
commit

Enable RIPng on the interfaces that need to participate in RIPng. In our case, this is at least those interfaces towards the inside of our network. Using R1 as an example:

set protocols ripng interface eth1.10
set protocols ripng interface eth1.20
commit

Advertise (redistribute) connected networks:

set protocols ripng redistribute connected
commit

Verify that it is working:

run show ipv6 ripng status
run show ipv6 route

Repeat the above on all other routers, then test reachability using ping6 and/or traceroute6.



[83] During early development, IPv6 was refered to as IPng, for Next Generation.

[84] Such functionality is supposed to be supplied by IPSec support in IPv6.