simple DHCPv6 config with /56-Prefix

[Simon]

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

>>> 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 ?
> 
> the mail server with a fixed configured IPv6
> 
> # ip -6 route show
> 
> 2001:db8:1:1::/64 dev ens160 proto kernel metric 100 pref medium
> fe80::/64 dev ens160 proto kernel metric 1024 pref medium
> default via 2001:db8:1:1::1 dev ens160 proto static metric 100 pref medium
> #
> 
> the DHCPv6 client
> 
> # ip -6 route show
> 2001:db8:1:1:7f00:18e7:d9b6:550a dev ens160 proto kernel metric 100 pref medium
> 2001:db8:1:1::/64 via fe80::264e:45ff:fe54:3024 dev ens160 proto ra metric 100 pref high
> fe80::/64 dev ens160 proto kernel metric 100 pref medium
> default via fe80::264e:45ff:fe54:3024 dev ens160 proto ra metric 100 pref medium
> #
>> 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.
> strange, the DHCPv6 client has this route ...
>>  On the assumption that you manually configured the mail server, I’d guess you don’t have your RA flags set right.
> 
> the radvd.conf looks like this
> 
> interface br0
> {
> 	AdvSendAdvert on;
> 
> 	# stateful DHCPv6: on
> 	# stateless DHCPv6 (SLAAC): off
> 	AdvManagedFlag on;
> 
> 	# get DNS from DHCPd6: on
> 	# get DNS from RADVd: off
> 	AdvOtherConfigFlag on;
> 
> 	# enable Mobile IPv6 support: on
> 	# disable Mobile IPv6 support: off
> 	AdvHomeAgentFlag off;
> 
> 	MinRtrAdvInterval 5;
> 	MaxRtrAdvInterval 15;
> 
> 	prefix 2001:db8:1:1::/64
> 	{
> 		AdvOnLink on;
> 		AdvAutonomous off;
> 	};
> 
> 	route 2001:db8:1:1::/64
> #	route ::/0
> #	route fe80::264e:45ff:fe54:3024/64
> 	{
> 		AdvRouteLifetime infinity;
> 		AdvRoutePreference high;
> 	};
> };
> 
> but there is another strange thing ...
> 
> as both the DHCPv6 client and my mail server are virtual machines on my Windows PC
> pinging the Windows PC itself shows this:
> 
> from the mail server
> 
> # ping6 2001:db8:1:1::57:4b53:5430
> PING 2001:db8:1:1::57:4b53:5430(2001:db8:1:1::57:4b53:5430) 56 data bytes
> 64 bytes from 2001:db8:1:1::57:4b53:5430: icmp_seq=1 ttl=128 time=0.178 ms
> 64 bytes from 2001:db8:1:1::57:4b53:5430: icmp_seq=2 ttl=128 time=0.193 ms
> ...
> #
> 
> from the DHCPv6 client
> 
> # ping6 2001:db8:1:1::57:4b53:5430
> PING 2001:db8:1:1::57:4b53:5430(2001:db8:1:1::57:4b53:5430) 56 data bytes
> 64 bytes from 2001:db8:1:1::57:4b53:5430: icmp_seq=1 ttl=128 time=0.275 ms
> 64 bytes from 2001:db8:1:1::57:4b53:5430: icmp_seq=1 ttl=128 time=0.611 ms (DUP!)
> 64 bytes from 2001:db8:1:1::57:4b53:5430: icmp_seq=2 ttl=128 time=0.308 ms
> 64 bytes from 2001:db8:1:1::57:4b53:5430: icmp_seq=2 ttl=128 time=0.584 ms (DUP!)
> ...
> #
> 
> now the really confusing, a Windows virtual machine (another DHCPv6 client)
> doesn't show the (DUP!) and has only 1 hop to the Windows PC itself
> to the mail server like the other DHCPv6 clients 2 hops;
> 
> whats going on, shall this be correct, am I missing something?

Sorry for not replying sooner, it’s been one of those periods when it seems everything is piling into your free time at the same time.

To be perfectly honest I have no idea where the duplicate pings are coming from - I was hoping someone else might jump in with ideas. However, I do see in the information above :

> the DHCPv6 client
> 
> # ip -6 route show
> 2001:db8:1:1:7f00:18e7:d9b6:550a dev ens160 proto kernel metric 100 pref medium
> 2001:db8:1:1::/64 via fe80::264e:45ff:fe54:3024 dev ens160 proto ra metric 100 pref high
> fe80::/64 dev ens160 proto kernel metric 100 pref medium
> default via fe80::264e:45ff:fe54:3024 dev ens160 proto ra metric 100 pref medium

This indicates that the route to 2001:db8:1:1::/64 is via your router rather than directly connected. I could hazard a guess that the client is pinging the host and two things are happening :
1) The host is seeing the packet as it passes through it’s internal networking setup, and replying.
2) The packet is (correctly) being sent out to the router, which forwards it to the host, which then replies again.

So I think the challenge is to figure out why the DHCP client is not setting up a route for 2001:db8:1:1::/64 to be locally connected.
Now I’ve gone and had a look at the man page for radvd.conf, I wonder if the ROUTE statement is causing this. As I read the man page, it’s configuring the RAs to include this router as a route to 2001:db8:1:1::/64 - i.e. for the clients to route traffic to 2001:db8:1:1::/64 via the router and ignore the on-link status. So I would suggest turning that off altogether and see what happens.


Simon