simple DHCPv6 config with /56-Prefix

[Simon]

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

>> 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 !
> when I read your text, it sounds not that complicated;
> 
> a workmate gave the hint to split one /64 from the /56 and use this - IPv6 works somewhat totally different from IPv4;
> 
> ok I did it like this:
> 
> lets say I'm using only 2001:db8:1:1::/64
> 
> the mail servers addresses have from 2001:db8:1:1:1e00::1 ... 2001:db8:1:1:1e00:ffff:ffff:ffff
> 
> the proxy server an address from 2001:db8:1:1:1800::1 ... 2001:db8:1:1:1800:ffff:ffff:ffff
> 
> I use only managed DHCP - no SLAAC - and for these clients I use these addresses
> 
> from 2001:db8:1:1:7f00::1 ... 2001:db8:1:1:7f00:ffff:ffff:ffff
> 
> and the router itself has this IPv6 address 2001:db8:1:1::1/64
> 
> now I got something weired and strange ...
> 
> e.g. one mail server has 2001:db8:1:1:1e00:1  and one dhcpv6 client got 2001:db8:1:1:7f00:18e7:d9b6:550a
> 
> on the mail server ...
> 
> # traceroute6 2001:db8:1:1:7f00:18e7:d9b6:550a
> traceroute to 2001:db8:1:1:7f00:18e7:d9b6:550a (2001:db8:1:1:7f00:18e7:d9b6:550a), 30 hops max, 80 byte packets
>  1  2001:db8:1:1:7f00:18e7:d9b6:550a (2001:db8:1:1:7f00:18e7:d9b6:550a)  0.768 ms  0.759 ms  0.848 ms
> #
> 
> on the DHCPv6 client
> 
> # traceroute6 2001:db8:1:1:1e00::1
> traceroute to 2001:db8:1:1:1e00::1 (2001:db8:1:1:1e00::1), 30 hops max, 80 byte packets
>  1  2001:db8:1:1::1 (2001:db8:1:1::1)  0.423 ms  0.540 ms  0.621 ms
>  2  2001:db8:1:1:1e00::1 (2001:db8:1:1:1e00::1)  1.975 ms  1.873 ms  1.804 ms
> #
> 
> where must I look for fixing this behaviour?
> 
> I guess this should be somewhat like this:
> 
> # traceroute6 2001:db8:1:1:1e00::1
> traceroute to 2001:db8:1:1:1e00::1 (2001:db8:1:1:1e00::1), 30 hops max, 80 byte packets
> 1  2001:db8:1:1:1e00::1 (2001:db8:1:1:1e00::1) 0.975 ms  0.873 ms  0.804 ms
> #

What do the routing tables look like for the two nodes ? What is the router advertising - prefix & flags ?

My guess is that the DHCPv6 client doesn’t have a route for the 2001:db8:1:1::/64 as a directly connected prefix - therefore it’s sending the packets via the router. On the assumption that you manually configured the mail server, I’d guess you don’t have your RA flags set right.

TBH, this is already outside my own comfort zone as I’ve not been actively working with networks for a couple of years. But having quickly looked this up, you should have the M and O flags set in your RAs to signal that it’s a managed network and that the devices need to use a DHCPv6 server for config info. What I suspect you may have missed is that you need to also set the L flag for the prefix to tell the device that addresses in this prefix are on-link (and clear the A flag to disable auto-config (SLAAC)).
https://blog.ipspace.net/2012/11/ipv6-router-advertisements-deep-dive.html


By way of showing that this isn’t actually all that different in IPv6 vs IPv4, consider this setup in the IPv4 space :
On gateway
ip address add 10.1.1.1/32 dev eth0 <- use of /32 decouples address from subnet
ip route add 10.0.0.0/8 dev eth0 <- tell the system that the subnet is reachable via this interface, equivalent of “on link” for an IPv6 prefix.

On mail server
ip address add 10.1.2.1/32 dev eth0
ip route add 10.0.0.0/8 dev eth0
ip route add default via 10.1.1.1

On client
ip address add 10.1.53.53/32 dev eth0
ip route add 10.0.0.0/8 dev eth0
ip route add default via 10.1.1.1

Apart from typos and/or incorrect remembering of ip command syntax, I believe this should achieve something very similar to the setup in IPv6. Using /32 for addresses mimics the fact that all IPv6 addresses should really be described as /128, and the route add commands mimic the effect of receiving RAs for 10.0.0.0/8 with the L bit set.
As I wrote earlier, there isn’t any magic linkage between addresses and subnet lengths - it’s just that traditionally there’s been this 1:1 mapping that ties addresses and subnet together. The above could be changed to make the servers and clients in different subnets :

On gateway
ip address add 10.1.1.1/24 dev eth0
ip route add 10.1.2.0/24 dev eth0
ip route add 10.1.53.0/24 dev eth0

On mail server
ip address add 10.1.2.1/24 dev eth0
ip route add 10.1.1.0/24 dev eth0
ip route add 10.1.53.0/24 dev eth0
ip route add default via 10.1.1.1

On client
ip address add 10.1.53.53/24 dev eth0
ip route add 10.1.1.0/24 dev eth0
ip route add 10.1.2.0/24 dev eth0 <- by missing the L flag in the RA, I think you have omitted this bit from your IPv6 setup.
ip route add default via 10.1.1.1

Note that here, there’s no route command to add the local subnet as that’s implied by the use of a /24 subnet mask - you’ll see a routing table entry when you add the IP address.
Equally valid would be :
ip address add 10.1.53.53/32 dev eth0
ip route add 10.1.1.0/24 dev eth0
ip route add 10.1.2.0/24 dev eth0
ip route add 10.1.53.0/24 dev eth0
ip route add default via 10.1.1.1
And this would be analogous to the setup I mentioned before where you use separate /64 prefixes for routers, servers, clients, etc.


Simon