simple DHCPv6 config with /56-Prefix

[Simon]

Walter H. <Walter.H at mathemainzel.info> wrote:

>>> 
>> There’s quite a bit different in IPv6 - it’s not just “extra address bits”. The opportunity was taken to fix some of the limitations found with IPv4 - such as the assumption that devices have a single address, and there’s only one subnet on each network, and all hosts in a subnet have direct communication. Unfortunately, as many people don’t realise that those problems exist, it’s seen as making it overly complicated.
>> 
>> I can recommend the free training available at 
>> https://ipv6.he.net/certification/ IMO Hurricane Electric have provided a great resource (including free IPv6 access via a tunnel over IPv4 https://tunnelbroker.net/
>> ). If you complete the certification program, you get what my local LUG members decreed to be the geekiest tee shirt ever made :-) Even if you don’t finish it, it worth the effort for the early stages where it introduces various aspects in a staged manner.
>> 
> yes, that IPv6 is different in more than just 3 bits from IPv4 is logic; but back to me origin intention ...
> my router has the following IPv4    172.16.0.1 with the subnetmask   255.255.0.0
> and I configured the dhcp to hand out addresses within this part:   172.16.127.1 ... 172.16.127.254
> and of course the DHCP clients got the correct IP, subnetmask and default gateway
> now the question:   Why do IPv6 clients have a prefix length of 128?

Ah, now there’s another thing that’s different with IPv6 - well not actually different, but in IPv4 was done differently.
An IP address (v4 or v6) does not itself have a prefix length or subnet length/mask. This was the case with IPv4, but for reasons I don’t recall, the two got tied closely together such that you always get a subnet length/mask with an IPv4 address - and so people believe that you can’t have one without the other.

This got fixed with IPv6. An address is an address<period> It does not have a prefix length. However, since IP stacks have been built on the premise that addresses have a 1:1 relationship with subnets, (AFAIK) all major implementations have a data structure that includes it.

And we come back to the on-link/off-link determination.
In the IPv4 world, there’s an assumption that addresses within the same subnet are on-link (nodes can communicate directly), and all other addresses are off-link (nodes cannot communicate directly). So since the single subnet/network and single address per interface are assumptions, the separate elements of addressing packets and determining whether the other end of a conversation is on the same network ended up being tied together.

In the IPv6 world, it’s different. When a node wishes to communicate with another node, it looks to see if the remote address is contained with any prefix advertised in an RA (Router Advertisement) as on-link. If it is, then it can send the packet directly to the remote node regardless of whether it’s in the same prefix or not. So you see that there is no value in tying an address to a prefix - but since IP stacks do just that, you need to provide a value, and /128 is logical.
Remember that IPv6 is designed for multiple addresses per interface, multiple prefixes per network, and other than as signalled by flags in RAs, you cannot assume whether another node is directly accessible just by considering whether you have addresses in a common prefix.

The prefix length you see attached to IPv6 address IS NOT USED FOR ANY ROUTING DECISIONS. To re-iterate: two nodes having addresses in the same prefix can’t necessarily communicate directly; and two nodes with addresses in different prefixes may be able to communicate directly. This information is not part of the address, it is signalled by flags attached to each prefix in RAs.


You need to change the mindset from “is the address in the same subnet” to “is the remote address within ANY subnet advertised as on-link for this network”

As an aside, this is doable in the IPv4 world, but it needs manual configuration of routing tables - none of the standard tools (e.g. DHCP) can do this, hence most people think it can’t be done. The equivalent of IPv6’s off-link prefix would be to configure the address with a /32 subnet mask. The equivalent of IPv6’s multiple on-link subnets is to configure routes for each subnet as “via interface” (rather than the more familiar “via gateway address”). It will also confuse the next person to come along and work on the network :D


> why can't I simple tell the DHCPv6 tell to hand out
> 2001:db8:0:17f::1 ... 2001:db8:0:17f:ffff:ffff:ffff:ffff and that the clients have the same prefix length as the server itself?

See above, addresses have no prefix length - they are just addresses.

> I just want a little bit less chaos in the way that I structure the adresses but not the segments it should be one large network;

OK

> e.g. with IPv4 I would give the mail servers IP addresses from this part 172.16.253.1 ... 172.16.253.254
> the proxy server a IP address from this part 172.16.128.1 ... 172.16.128.254
> but all have the same subnet mask 255.255.0.0 and the same default gateway  172.16.0.1

OK

> and this I would have in IPv6 too
> 
> the router should have   
> 2001:db8:0:100::1/56
> 
> the mail servers addresses from 2001:db8:0:1e0::1 ... 2001:db8:0:1e0:ffff:ffff:ffff:ffff
> the proxy server an address from  2001:db8:0:180::1 ... 2001:db8:0:180:ffff:ffff:ffff:ffff
> 
> and would have the /56 as prefix length as one big network;
> no splitting in /57, /58, ... or /64 ...

You can do that, you just need to configure your RAs to advertise the single 2001:db8:0/56 prefix - and set the right flags to indicate to clients that this is a managed network and they need to use DHCPv6 to get addresses.
However, be aware that SLAAC won’t work (properly/at all) on a /56 prefix, and Android does not support DHCPv6*, so Android devices won’t work on this network setup.

But also, you can advertise multiple /64 (or /63, or /62, or ...) prefixes without the nodes needing to use the router to communicate. So you could advertise :
2001:db8:0:1e0/64, configured as managed (i.e. no SLAAC), and either use DHCP or manual config for you mail servers.
Ditto for 2001:db8:0:180/64
Provide a SLAAC configured prefix (/64) if you need to support Android devices
Provide a (say) /60 for DHCP configured devices
Configure all these as “on-link” and the devices can communicate directly just as they could if you used a single /56.

Lots of options, but you need to “unlearn” some of the fundamentals you learned with IPv4 - and that’s hard !

> but the DHCPv6 clients don't get /56 as prefixlength, they get /128, why?

As above, addresses do not have a prefix length, the /128 is simply there to make it easier to refactor the IPv4 code to handle IPv6


* It’s tempting to say that Google consider it their job to snoop on everyone, and network operators should not be allowed to - but it’s more subtle than that. On a managed network using DHCP for address assignment, the network operator has considerable control and can significantly impact user privacy (e.g by providing “static” addresses, or only providing one address instead of allowing the device to have “many” and change them frequently). It seems to be Google’s view that user privacy trumps arguments such as legal requirements in many jurisdictions to be able to identify who was using an address at a particular time in the recent past (that’s a requirement placed on UK ISPs, and it’s common in financial and healthcare settings).
Regardless of the merits of either side of the argument, Google have a policy that they will not support DHCPv6 in Android, and even actively block third party implementations (by pressuring chipset vendors to block the packets in the hardware).



Simon