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: Query (Niall O'Reilly)
2. Re: Query (Simon)
3. Re: simple DHCPv6 config with /56-Prefix (Simon)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Sep 2022 18:00:32 +0100
From: "Niall O'Reilly" <niall.orei...@ucd.ie>
To: "Users of ISC DHCP" <dhcp-users@lists.isc.org>
Subject: Re: Query
Message-ID: <d13c4314-990e-479f-a91d-ff9aa0b38...@ucd.ie>
Content-Type: text/plain; format=flowed; markup=markdown
On 27 Sep 2022, at 13:25, Soporte VT wrote:
> Is there any configuration in which the IP change insted, like never
> asign the same IP to the same cliente. Thanks for your tieme.
I don't know for sure, but expect not, as such behaviour would
not comply with the DHCP specification.
Best regards,
Niall O'Reilly
------------------------------
Message: 2
Date: Wed, 28 Sep 2022 21:01:22 +0100
From: Simon <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Query
Message-ID: <f5fb4e42-7b52-4df8-992b-04c9e3cf5...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Soporte VT <sopo...@vallecastelecom.com> wrote:
> I am writing from a lack of awareness. I work for an ISP provider, which has
> a DHCP server running perfectly with a public IP address pool.
>
> Since more of the clients never turn off their routers, it is like the DHCP
> client holds the IP address information for a long time, or it never changes,
> in my opinion. I did some test, like rebooting the router or leaving it off
> for a whole day, and the client takes the same ip address.
That is by design and required by the RFCs. The server tried hard to keep
addresses stable - even if a device is left turned off for some time, it will
get the same address when turned on unless it?s had to be re-allocated due to
churn.
> Is there any configuration in which the IP change insted, like never asign
> the same IP to the same cliente.
No, as already said, this would be explicitly against the RFCs.
I have to admit, it?s a question that?s not come up for a while, but it used to
come up fairly regularly on this list - if you search the archives you should
find a few threads about it. There are ways to force address changes, but all
of them have downsides - like clients having their connections drop
periodically and any open sessions break.
Most threads repeat the above, then add that if your boss is telling you that
clients need to keep changing address, then it?s time to look for another job
before clients work out why their connections keep dropping periodically, move
to a more enlightened provider, and your?s goes bust.
Simon
------------------------------
Message: 3
Date: Wed, 28 Sep 2022 21:19:22 +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: <e308e33f-382b-45f1-a3f7-da44a7cfa...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Walter H. <walte...@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
------------------------------
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 167, Issue 8
******************************************
