Dividing the Indivisible

The “proper” approach would be to call up the provider and ask for more; there is no reason to limit IPv6 assignments to end-users to just a single /64, and in fact the current best practices document (RFC 6177) recommends “giving home sites significantly more than a single /64”.

But what if changing the ways of your provider does not seem to be a feasible option, but you still want to have multiple physical networks and at least a semi-comfortable experience (i.e. not being forced to use DHCPv6 everywhere, or bridge everything into one L2 LAN)?

This simple HOWTO explains how you can have one “primary” network with functional SLAAC, and an arbitrary (16 in my example) number of “secondary” networks, where only DHCPv6 will be available. Full two-way routing between all these networks will work without any issues.

Why bother trying to combine SLAAC and DHCPv6 networks, and not simply split the /64 into smaller subnets to use DHCPv6 for all of those? Because I believe it is convenient to retain at least one network with SLAAC, I imagine this would be your main private LAN, where majority of your computers and other devices are, so that you can enjoy the convenience of SLAAC and not need to set up DHCPv6 clients on all of those.

Let's assume we have the following.

What we do is…

Carve out a /108 out of the /64, and split it into up to sixteen /112 networks.

Let's say this network will be 2001:db8:abcd:cdef:ffff:ffff:fff0::/108.

But if hosts on the main LAN assume they have the /64 directly accessible on-link, how will they know they need to reach some subnets that are technically within the /64, via the router?

The answer is: from a more-specific route in RAs!

For the Dibbler DHCPv6 server (the rest of the config file is omitted).

iface "eth1" {
 class {
   pool 2001:db8:abcd:cdef:ffff:ffff:fff1::/112
 }
}

iface "eth2" {
 class {
   pool 2001:db8:abcd:cdef:ffff:ffff:fff2::/112
 }
}

iface "eth3" {
 class {
   pool 2001:db8:abcd:cdef:ffff:ffff:fff3::/112
 }
}

interface eth0 {
    AdvSendAdvert on;
    prefix ::/64 { };
    route 2001:db8:abcd:cdef:ffff:ffff:fff0::/108 { };  # <- the main secret sauce in this whole recipe
};

interface eth1 {
    AdvSendAdvert on;
    AdvManagedFlag on;
    prefix ::/112 { AdvAutonomous off; };
};

interface eth2 {
    AdvSendAdvert on;
    AdvManagedFlag on;
    prefix ::/112 { AdvAutonomous off; };
};

interface eth3 {
    AdvSendAdvert on;
    AdvManagedFlag on;
    prefix ::/112 { AdvAutonomous off; };
};

Simple.

• eth0: 2001:db8:abcd:cdef::1/64
• eth1: 2001:db8:abcd:cdef:ffff:ffff:fff1::1/112
• eth2: 2001:db8:abcd:cdef:ffff:ffff:fff2::1/112
• eth3: 2001:db8:abcd:cdef:ffff:ffff:fff3::1/112

Hosts from your primary LAN assume that the whole /64 is their own personal playground, and that they can pick any address they want. In theory this can lead to address collisions with some hosts on your secondary networks. But:

1. We ruled out possibility of collision with a EUI-64 address by using ff:ff in the middle of our /108 (those will always have ff:fe);
2. The probability of a “Privacy Extensions” address suddenly having ffff:ffff:fff in it, is… well, calculate yourself, seems “pretty low” to me.