Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: simple DHCPv6 config with /56-Prefix (Simon)
2. Re: simple DHCPv6 config with /56-Prefix (Walter H.)
----------------------------------------------------------------------
Message: 1
Date: Mon, 29 Aug 2022 15:57:19 +0100
From: Simon <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: simple DHCPv6 config with /56-Prefix
Message-ID: <4863bf94-8954-4407-b3a8-6c7559eb0...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Walter H. <walte...@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
------------------------------
Message: 2
Date: Mon, 29 Aug 2022 19:34:00 +0200
From: "Walter H." <walte...@mathemainzel.info>
To: dhcp-users@lists.isc.org
Subject: Re: simple DHCPv6 config with /56-Prefix
Message-ID: <38e3aa26-210e-6035-a1c2-16afc71c9...@mathemainzel.info>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 29.08.2022 16:57, Simon wrote:
> Walter H. <walte...@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-0001.bin>
------------------------------
Subject: Digest Footer
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 166, Issue 14
*******************************************
