simple DHCPv6 config with /56-Prefix

Walter H. Walter.H at mathemainzel.info
Mon Aug 29 17:34:00 UTC 2022


On 29.08.2022 16:57, Simon wrote:
> 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 ?

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?

Thanks,
Walter


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3550 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220829/c8e8a83b/attachment.bin>


More information about the dhcp-users mailing list