[Dnsmasq-discuss] clients of DHCPv6 with constructed IPv6 address range are not notified on address range change

[Andrey Vakhitov]

Thanks for a great dnsmasq software.



I'm using dnsmasq 2.79 in combination with IPv6 prefix delegation. The
prefixes are changing daily due to daily reconnect of upstream router.
Dhcpcd is used to handle prefix delegation on external interface and apply
new address to internal interface (dmz0). Dnsmasq picks up the prefix
assigned to the internal interface by dhcpcd and server RA and DHCPv6
server.



dhcp-range=set:dmz6,::,constructor:dmz0,ra-stateless,ra-names

dhcp-host=id:00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18,set:dmzfix6,[::56],dm
zhost



Initially the host gets IPv6 address via DHCPv6 correctly, DNS resolution
works as expected, everything seems to be ok. But after reconnect (and
according prefix change) the client stays with the IPv6 address from old
prefix and doesn't update it. I've used tcpdump to monitor DHCP-related
traffic and could not see DHCPv6 RECONFIGURE message sent by dnsmasq to
clients on prefix change. I assume that this is the cause of the problem:
DHCP clients are not aware of changed prefix and can't act without
corresponding notification from server.

As dhcp client I use build-in DHCP client from system-networkd, just for
info, maybe it matters.



If I'm wrong with my assumption I'd appreciate any explanation helping me to
configure dnsmasq and DHCP client properly.



Best regards,

--

Andrey Vakhitov



E-Mail: <mailto:***@vakhitov.net> ***@vakhitov.net
Stuttgart, Germany

[Simon Kelley]

Dnsmasq doesn't implement RECONFIGURE. It probably should. The main
problem, from a quick look at the RFC, is that RECONFIGURE mandates use
of security mechanism, and dnsmasq doesn't implement that either!

The intention is that address change is a gradual process. The old
address gets deprecated whilst the new one is added, and after a while
the old address disappears. DHCP lease times are shorter than the time
taken for an address to disappear. This gives time for hosts to move to
the new address.

What's happening in your case seems a bit brutal. Even if you can push
the change to all the clients fast, you're still going to break every
on-going connection at address-change time.


Cheers,

Simon.

Post by Andrey Vakhitov
Thanks for a great dnsmasq software.
 
I’m using dnsmasq 2.79 in combination with IPv6 prefix delegation. The
prefixes are changing daily due to daily reconnect of upstream router.
Dhcpcd is used to handle prefix delegation on external interface and
apply new address to internal interface (dmz0). Dnsmasq picks up the
prefix assigned to the internal interface by dhcpcd and server RA and
DHCPv6 server.
 
dhcp-range=set:dmz6,::,constructor:dmz0,ra-stateless,ra-names
dhcp-host=id:00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18,set:dmzfix6,[::56],dmzhost
 
Initially the host gets IPv6 address via DHCPv6 correctly, DNS
resolution works as expected, everything seems to be ok. But after
reconnect (and according prefix change) the client stays with the IPv6
address from old prefix and doesn’t update it. I’ve used tcpdump to
monitor DHCP-related traffic and could not see DHCPv6 RECONFIGURE
message sent by dnsmasq to clients on prefix change. I assume that this
is the cause of the problem: DHCP clients are not aware of changed
prefix and can’t act without corresponding notification from server.
As dhcp client I use build-in DHCP client from system-networkd, just for
info, maybe it matters…
 
If I’m wrong with my assumption I’d appreciate any explanation helping
me to configure dnsmasq and DHCP client properly.
 
Best regards,
--
Andrey Vakhitov
 
Stuttgart, Germany
 
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Uwe Schindler]

Hi Simon,

unfortunately that problem is seen often with providers in Germany, although the large ones no longer do it (or allow to disable the disconnect). The problem is that German providers automatically disconnect the PPPoE connection every 24 hrs. After reconnecting you get a new address (IPv4) and prefix (IPv6). Since the changes we did (deprecating prefixes) this works fine for standard router advertisements. But won't help for DHCPv6.

My recommendation to the reporter:
- Don't use stateful DHCPv6 in Germany, that does not work well. You clients should get the addresses using router advertisements. For static hosts assign static names in your own domain. The "ra-names" assigns both the IPv4 and IPv6 address to the SLAAC name, so lookup works fine. With router advertisements, DNSmasq will send "deprecated" prefixes for some time when it figures out that the prefix changed and sends the new prefix at the same time. This allows to have no interruption (except the forced PPP disconnect). In general, in IPv6 world you should forget about static addresses, it's also better for privacy.
- Alternatively use a very short DHCPv6 lease time. E.g., if router advertisements last a maximum time of 30 minutes, also set the lease time to 30 minutes for IPv6. This requires clients to renew more often, but the change gots faster. If you force the router to disconnect during nights at a fixed time, the effect won't be so large.

Uwe

-----
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de

-----Original Message-----
On Behalf Of Simon Kelley
Sent: Sunday, September 9, 2018 11:49 PM
Subject: Re: [Dnsmasq-discuss] clients of DHCPv6 with constructed IPv6
address range are not notified on address range change
Dnsmasq doesn't implement RECONFIGURE. It probably should. The main
problem, from a quick look at the RFC, is that RECONFIGURE mandates use
of security mechanism, and dnsmasq doesn't implement that either!
The intention is that address change is a gradual process. The old
address gets deprecated whilst the new one is added, and after a while
the old address disappears. DHCP lease times are shorter than the time
taken for an address to disappear. This gives time for hosts to move to
the new address.
What's happening in your case seems a bit brutal. Even if you can push
the change to all the clients fast, you're still going to break every
on-going connection at address-change time.
Cheers,
Simon.

Post by Andrey Vakhitov
Thanks for a great dnsmasq software.
I’m using dnsmasq 2.79 in combination with IPv6 prefix delegation. The
prefixes are changing daily due to daily reconnect of upstream router.
Dhcpcd is used to handle prefix delegation on external interface and
apply new address to internal interface (dmz0). Dnsmasq picks up the
prefix assigned to the internal interface by dhcpcd and server RA and
DHCPv6 server.
dhcp-range=set:dmz6,::,constructor:dmz0,ra-stateless,ra-names
dhcp-

host=id:00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18,set:dmzfix6,[::56],dmzhos
t

Post by Andrey Vakhitov
Initially the host gets IPv6 address via DHCPv6 correctly, DNS
resolution works as expected, everything seems to be ok. But after
reconnect (and according prefix change) the client stays with the IPv6
address from old prefix and doesn’t update it. I’ve used tcpdump to
monitor DHCP-related traffic and could not see DHCPv6 RECONFIGURE
message sent by dnsmasq to clients on prefix change. I assume that this
is the cause of the problem: DHCP clients are not aware of changed
prefix and can’t act without corresponding notification from server.
As dhcp client I use build-in DHCP client from system-networkd, just for
info, maybe it matters…
If I’m wrong with my assumption I’d appreciate any explanation helping
me to configure dnsmasq and DHCP client properly.
Best regards,
--
Andrey Vakhitov
Stuttgart, Germany
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Andrey Vakhitov]

Hello Simon & Uwe,

Post by Uwe Schindler
unfortunately that problem is seen often with providers in Germany, although the large ones no longer
do it (or allow to disable the disconnect). The problem is that German providers automatically
disconnect the PPPoE connection every 24 hrs. After reconnecting you get a new address (IPv4) and
prefix (IPv6). Since the changes we did (deprecating prefixes) this works fine for standard router
advertisements. But won't help for DHCPv6.

This is exactly my case, my ISP is o2.

Post by Uwe Schindler

Post by Simon Kelley
Dnsmasq doesn't implement RECONFIGURE. It probably should. The main
problem, from a quick look at the RFC, is that RECONFIGURE mandates
use of security mechanism, and dnsmasq doesn't implement that either!

I know that it's against RFC but some routers (like the fritzbox I'm using, very popular choice in Germany) actually send RECONFIGURE without authentication. This is BTW the reason for introduction of "noauthrequired" config option in dhcpcd ;-)

Post by Uwe Schindler
- Don't use stateful DHCPv6 in Germany, that does not work well. You clients should get the addresses
using router advertisements. For static hosts assign static names in your own domain. The "ra-names"
assigns both the IPv4 and IPv6 address to the SLAAC name, so lookup works fine. With router
advertisements, DNSmasq will send "deprecated" prefixes for some time when it figures out that the
prefix changed and sends the new prefix at the same time. This allows to have no interruption (except
the forced PPP disconnect). In general, in IPv6 world you should forget about static addresses, it's also
better for privacy.

As you correctly recognized, the reason for usage of stateful DHCPv6 was to get correct dynamic name resolution for IPv6. My IPv4 setup utilizes static addresses, I didn't used DHCPv4 for hosts acting as servers. I also see the combination of DHCPv4 with SLAAC as possible workaround, I've to try it. My problem with this setup is the lack of fallback address in networkd DHCP client: If DHCPv4 fails due to any reason the host get some "weird" address. Static IPv4 setup is free from this drawback and wanted to keep it as is and complement it with IPv6 solution...

Best regards,
--
Andrey Vakhitov

E-Mail: ***@vakhitov.net Stuttgart, Germany

[Andrey Vakhitov]

Hello Uwe,

Post by Andrey Vakhitov

Post by Uwe Schindler
- Don't use stateful DHCPv6 in Germany, that does not work well. You
clients should get the addresses using router advertisements. For static

hosts assign static names in your own domain. The "ra-names"

Post by Andrey Vakhitov

Post by Uwe Schindler
assigns both the IPv4 and IPv6 address to the SLAAC name, so lookup
works fine. With router advertisements, DNSmasq will send "deprecated"

As you correctly recognized, the reason for usage of stateful DHCPv6 was

to get correct dynamic name resolution for IPv6.

Post by Andrey Vakhitov
I also see the combination of DHCPv4 with SLAAC as possible workaround,

I've to try it

I've set it up as you suggested, initially name resolution seems to work
fine. But after some days of operation (and some nightly reconnects) dnsmasq
seems to loose associated IPv6 adresses: DNS request reports only IPv6
address assigned via DHCP. The SLAAC-based IPv6 addresses on hosts are
present and correct. How can I investigate and fix this issue?

Best regards,
--
Andrey Vakhitov

E-Mail: ***@vakhitov.net Stuttgart, Germany

[Simon Kelley]

Post by Andrey Vakhitov
Hello Uwe,

Post by Andrey Vakhitov

Post by Uwe Schindler
- Don't use stateful DHCPv6 in Germany, that does not work well. You
clients should get the addresses using router advertisements. For static

hosts assign static names in your own domain. The "ra-names"

Post by Andrey Vakhitov

Post by Uwe Schindler
assigns both the IPv4 and IPv6 address to the SLAAC name, so lookup
works fine. With router advertisements, DNSmasq will send "deprecated"

As you correctly recognized, the reason for usage of stateful DHCPv6 was

to get correct dynamic name resolution for IPv6.

Post by Andrey Vakhitov
I also see the combination of DHCPv4 with SLAAC as possible workaround,

I've to try it
I've set it up as you suggested, initially name resolution seems to work
fine. But after some days of operation (and some nightly reconnects) dnsmasq
seems to loose associated IPv6 adresses: DNS request reports only IPv6
address assigned via DHCP. The SLAAC-based IPv6 addresses on hosts are
present and correct. How can I investigate and fix this issue?

Hmm, not easy.

Look in the log for lines that look like

DHCPv4-derived IPv6 names on ........

which should occur after a reconnect with a different address which
causes new DHCP address ranges to be constructed.

After that happens, dnsmasq will take a guess at the IPv6 addresses that
hosts will assign themselves, based on the network address and the MAC
address of the host (transformed into EUI-64) It then starts to ping
those addresses, and when it gets a reply, it will log

SLAAC_CONFIRM(interface) <address> <hostname>


and start using the address/name in the DNS.

Once confirmed, the addresses remain valid until the DHCPv4 lease it's
based on expires or goes though init-reboot state or the MAC address or
interface it's accessible by changes.

The only other thing that will delete these addresses in a new address
appearing and a new dhcp range being created, hence it's interesting to
look at what happens in the logs after each of those events.



Cheers,

Simon.

Post by Andrey Vakhitov
Best regards,
--
Andrey Vakhitov
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Andrey Vakhitov]

Hi Simon,

Post by Simon Kelley

Post by Andrey Vakhitov
I've set it up as you suggested, initially name resolution seems to
work fine. But after some days of operation (and some nightly
reconnects) dnsmasq seems to loose associated IPv6 adresses: DNS
request reports only IPv6 address assigned via DHCP. The SLAAC-based
IPv6 addresses on hosts are present and correct. How can I investigate

and fix this issue?

Post by Simon Kelley
Look in the log for lines that look like
DHCPv4-derived IPv6 names on ........
which should occur after a reconnect with a different address which causes

new DHCP address ranges to be constructed.

Post by Simon Kelley
After that happens, dnsmasq will take a guess at the IPv6 addresses that

hosts will assign themselves,

Post by Simon Kelley
based on the network address and the MAC address of the host (transformed

into EUI-64)

Post by Simon Kelley
It then starts to ping those addresses, and when it gets a reply, it will

log

Post by Simon Kelley
SLAAC_CONFIRM(interface) <address> <hostname>
and start using the address/name in the DNS.
Once confirmed, the addresses remain valid until the DHCPv4 lease it's

based on expires or goes

Post by Simon Kelley
though init-reboot state or the MAC address or interface it's accessible

by changes.

Post by Simon Kelley
The only other thing that will delete these addresses in a new address

appearing and a new dhcp

Post by Simon Kelley
range being created, hence it's interesting to look at what happens in the

logs after each of those events.

Strange thing: sometimes after reconnect I can observe expected behaviour
(like you described it, see log 1), sometimes not (SLAAC-CONFIRM is missing,
see log 2)

---------- log1 --------
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on
2001:16b8:2284:f5fc::, constructed for lan0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on
2001:16b8:2284:f5fc::, constructed for lan0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on
2001:16b8:2284:f5fc::, constructed for lan0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on
2001:16b8:2284:f5fd::, constructed for dmz0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on
2001:16b8:2284:f5fd::, constructed for dmz0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on
2001:16b8:2284:f5fd::, constructed for dmz0
Sep 17 20:22:45 rtr dnsmasq[7855]: reading /etc/dnsmasq-resolv.conf
Sep 17 20:22:45 rtr dnsmasq[7855]: using local addresses only for domain
homenet
Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.4.4#53
Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.8.8#53
Sep 17 20:22:45 rtr dnsmasq[7855]: ignoring nameserver
fd00::7eff:4dff:fe03:2c18 - cannot make/bind socket: Address alr>
Sep 17 20:22:45 rtr dnsmasq[7855]: setting upstream servers from DBus
Sep 17 20:22:45 rtr dnsmasq[7855]: using local addresses only for domain
homenet
Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.4.4#53
Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.8.8#53
Sep 17 20:22:47 rtr dhcpcd[15081]: lan0: DHCPv6 DAD completed
Sep 17 20:22:47 rtr dhcpcd[15081]: lan0: executing
`/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6
Sep 17 20:22:47 rtr dhcpcd[15081]: dmz0: DHCPv6 DAD completed
Sep 17 20:22:47 rtr dhcpcd[15081]: dmz0: executing
`/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6
Sep 17 20:22:49 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0)
00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 17 20:22:55 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 17 20:22:56 rtr dhcpcd[15081]: wan0: fe80::7eff:4dff:fe03:2c18 is
unreachable, expiring it
Sep 17 20:22:56 rtr dhcpcd[15081]: wan0: executing
`/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
Sep 17 20:22:58 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:2284:f5fc::
Sep 17 20:22:58 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:2250:65f8:: old prefix
Sep 17 20:22:58 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 17 20:22:59 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:2284:f5fd::
Sep 17 20:22:59 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:2250:65f9:: old prefix
Sep 17 20:23:03 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(lan0)
2001:16b8:2284:f5fc:d250:99ff:fe84:93d0 vdrmain
Sep 17 20:23:03 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(dmz0)
2001:16b8:2284:f5fd:5054:ff:fe12:3456 dmzhost
Sep 17 20:23:03 rtr dhcpcd[15081]: wan0: fe80::7eff:4dff:fe03:2c18 is
reachable again
Sep 17 20:23:03 rtr dhcpcd[15081]: wan0: executing
`/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:2284:f5fd::
Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:2250:65f9:: old prefix
Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(lan0)
2001:16b8:2284:f5fc:222:4dff:fea7:dcdc vdrkit
Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(lan0)
2001:16b8:2284:f5fc:fca1:42ff:fed2:a2bd xenhost
-------------------------

---------- log2 --------
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on
2001:16b8:22c4:83fc::, constructed for lan0
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on
2001:16b8:22c4:83fc::, constructed for lan0
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: router advertisement on
2001:16b8:22c4:83fc::, constructed for lan0
Sep 18 04:35:20 rtr dhcpcd[15081]: lan0: waiting for DHCPv6 DAD to complete
Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: adding address
2001:16b8:22c4:83fd::1/64
Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: pltime 3600 seconds, vltime 7200
seconds
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on
2001:16b8:22c4:83fd::, constructed for dmz0
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on
2001:16b8:22c4:83fd::, constructed for dmz0
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: router advertisement on
2001:16b8:22c4:83fd::, constructed for dmz0
Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: waiting for DHCPv6 DAD to complete
Sep 18 04:35:20 rtr dhcpcd[15081]: lan0: adding route to
2001:16b8:22c4:83fc::/64
Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: adding route to
2001:16b8:22c4:83fd::/64
Sep 18 04:35:20 rtr dhcpcd[15081]: wan0: executing
`/usr/lib/dhcpcd/dhcpcd-run-hooks' BOUND6
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0)
00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:35:20 rtr dhcpcd[15081]: wan0: Router Advertisement DAD completed
Sep 18 04:35:20 rtr dhcpcd[15081]: wan0: executing
`/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
Sep 18 04:35:21 rtr ddclient[1597]: SUCCESS: updating rtrhomevak.spdns.de:
good: IP address set to 2001:16b8:22c4:8300>
Sep 18 04:35:21 rtr dhcpcd[15081]: dmz0: DHCPv6 DAD completed
Sep 18 04:35:21 rtr dhcpcd[15081]: dmz0: executing
`/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6
Sep 18 04:35:21 rtr dhcpcd[15081]: lan0: DHCPv6 DAD completed
Sep 18 04:35:21 rtr dhcpcd[15081]: lan0: executing
`/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6
Sep 18 04:35:29 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:22c4:83fc::
Sep 18 04:35:29 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:2285:3afc:: old prefix
Sep 18 04:35:29 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:35:29 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:35:31 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:22c4:83fd::
Sep 18 04:35:31 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:2285:3afd:: old prefix
Sep 18 04:35:31 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0)
00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:35:34 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:22c4:83fc::
Sep 18 04:35:34 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:2285:3afc:: old prefix
Sep 18 04:35:34 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:22c4:83fd::
Sep 18 04:35:34 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:2285:3afd:: old prefix
Sep 18 04:35:34 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:35:34 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:35:34 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0)
00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:35:36 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:22c4:83fc::
Sep 18 04:35:36 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:2285:3afc:: old prefix
Sep 18 04:35:36 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:35:36 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:35:42 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:22c4:83fc::
Sep 18 04:35:42 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:2285:3afc:: old prefix
Sep 18 04:35:42 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:35:42 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:35:43 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:22c4:83fd::
Sep 18 04:35:43 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:2285:3afd:: old prefix
Sep 18 04:35:43 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0)
00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:35:44 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:22c4:83fc::
Sep 18 04:35:44 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:2285:3afc:: old prefix
Sep 18 04:35:44 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:35:44 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:35:48 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:22c4:83fd::
Sep 18 04:35:48 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:2285:3afd:: old prefix
Sep 18 04:35:48 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0)
00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:35:51 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:22c4:83fd::
Sep 18 04:35:51 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:2285:3afd:: old prefix
Sep 18 04:35:51 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0)
00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:35:54 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:22c4:83fc::
Sep 18 04:35:54 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:2285:3afc:: old prefix
Sep 18 04:35:54 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:22c4:83fc::
Sep 18 04:35:54 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:2285:3afc:: old prefix
Sep 18 04:35:54 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:35:54 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:35:58 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:22c4:83fd::
Sep 18 04:35:58 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:2285:3afd:: old prefix
Sep 18 04:35:58 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0)
00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:36:00 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:22c4:83fd::
Sep 18 04:36:00 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:2285:3afd:: old prefix
Sep 18 04:36:00 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0)
00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:36:01 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:22c4:83fc::
Sep 18 04:36:01 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:2285:3afc:: old prefix
Sep 18 04:36:01 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:36:01 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0)
00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:36:08 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:22c4:83fd::
Sep 18 04:36:08 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0)
2001:16b8:2285:3afd:: old prefix
Sep 18 04:36:08 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0)
00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:36:10 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:22c4:83fc::
Sep 18 04:36:10 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0)
2001:16b8:2285:3afc:: old prefix
-------------------------

Best Regards,
--
Andrey Vakhitov

E-Mail:  ***@vakhitov.net            Stuttgart, Germany

[line wrap clean up]

On Tue, Sep 18, 2018 at 11:13:27PM +0200, Andrey Vakhitov wrote:
Hi Simon,

Post by Simon Kelley

Post by Andrey Vakhitov
I've set it up as you suggested, initially name resolution seems
to work fine. But after some days of operation (and some nightly
reconnects) dnsmasq seems to loose associated IPv6 adresses: DNS
request reports only IPv6 address assigned via DHCP. The SLAAC-based
IPv6 addresses on hosts are present and correct. How can I investigate
and fix this issue?

Look in the log for lines that look like
DHCPv4-derived IPv6 names on ........
which should occur after a reconnect with a different address which
causes new DHCP address ranges to be constructed.
After that happens, dnsmasq will take a guess at the IPv6 addresses
that hosts will assign themselves, based on the network address and
the MAC address of the host (transformed into EUI-64) It then starts
to ping those addresses, and when it gets a reply, it will log
SLAAC_CONFIRM(interface) <address> <hostname>
and start using the address/name in the DNS.
Once confirmed, the addresses remain valid until the DHCPv4 lease it's
based on expires or goes though init-reboot state or the MAC address
or interface it's accessible by changes.
The only other thing that will delete these addresses in a new address
appearing and a new dhcp range being created, hence it's interesting
to look at what happens in the logs after each of those events.

Strange thing: sometimes after reconnect I can observe expected behaviour
(like you described it, see log 1), sometimes not (SLAAC-CONFIRM is missing,
see log 2)

---------- log1 --------
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 2001:16b8:2284:f5fc::, constructed for lan0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 2001:16b8:2284:f5fc::, constructed for lan0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on 2001:16b8:2284:f5fc::, constructed for lan0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 2001:16b8:2284:f5fd::, constructed for dmz0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 2001:16b8:2284:f5fd::, constructed for dmz0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on 2001:16b8:2284:f5fd::, constructed for dmz0
Sep 17 20:22:45 rtr dnsmasq[7855]: reading /etc/dnsmasq-resolv.conf
Sep 17 20:22:45 rtr dnsmasq[7855]: using local addresses only for domain homenet
Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.4.4#53
Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.8.8#53
Sep 17 20:22:45 rtr dnsmasq[7855]: ignoring nameserver fd00::7eff:4dff:fe03:2c18 - cannot make/bind socket: Address alr>
Sep 17 20:22:45 rtr dnsmasq[7855]: setting upstream servers from DBus
Sep 17 20:22:45 rtr dnsmasq[7855]: using local addresses only for domain homenet
Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.4.4#53
Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.8.8#53
Sep 17 20:22:47 rtr dhcpcd[15081]: lan0: DHCPv6 DAD completed
Sep 17 20:22:47 rtr dhcpcd[15081]: lan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6
Sep 17 20:22:47 rtr dhcpcd[15081]: dmz0: DHCPv6 DAD completed
Sep 17 20:22:47 rtr dhcpcd[15081]: dmz0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6
Sep 17 20:22:49 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) 00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 17 20:22:55 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 17 20:22:56 rtr dhcpcd[15081]: wan0: fe80::7eff:4dff:fe03:2c18 is unreachable, expiring it
Sep 17 20:22:56 rtr dhcpcd[15081]: wan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
Sep 17 20:22:58 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2284:f5fc::
Sep 17 20:22:58 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2250:65f8:: old prefix
Sep 17 20:22:58 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 17 20:22:59 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2284:f5fd::
Sep 17 20:22:59 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2250:65f9:: old prefix
Sep 17 20:23:03 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(lan0) 2001:16b8:2284:f5fc:d250:99ff:fe84:93d0 vdrmain
Sep 17 20:23:03 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(dmz0) 2001:16b8:2284:f5fd:5054:ff:fe12:3456 dmzhost
Sep 17 20:23:03 rtr dhcpcd[15081]: wan0: fe80::7eff:4dff:fe03:2c18 is reachable again
Sep 17 20:23:03 rtr dhcpcd[15081]: wan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2284:f5fd::
Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2250:65f9:: old prefix
Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(lan0) 2001:16b8:2284:f5fc:222:4dff:fea7:dcdc vdrkit
Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(lan0) 2001:16b8:2284:f5fc:fca1:42ff:fed2:a2bd xenhost
-------------------------

---------- log2 --------
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 2001:16b8:22c4:83fc::, constructed for lan0
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 2001:16b8:22c4:83fc::, constructed for lan0
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: router advertisement on 2001:16b8:22c4:83fc::, constructed for lan0
Sep 18 04:35:20 rtr dhcpcd[15081]: lan0: waiting for DHCPv6 DAD to complete
Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: adding address 2001:16b8:22c4:83fd::1/64
Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: pltime 3600 seconds, vltime 7200 seconds
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 2001:16b8:22c4:83fd::, constructed for dmz0
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 2001:16b8:22c4:83fd::, constructed for dmz0
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: router advertisement on 2001:16b8:22c4:83fd::, constructed for dmz0
Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: waiting for DHCPv6 DAD to complete
Sep 18 04:35:20 rtr dhcpcd[15081]: lan0: adding route to 2001:16b8:22c4:83fc::/64
Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: adding route to 2001:16b8:22c4:83fd::/64
Sep 18 04:35:20 rtr dhcpcd[15081]: wan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' BOUND6
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) 00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:35:20 rtr dhcpcd[15081]: wan0: Router Advertisement DAD completed
Sep 18 04:35:20 rtr dhcpcd[15081]: wan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
Sep 18 04:35:21 rtr ddclient[1597]: SUCCESS: updating rtrhomevak.spdns.de: good: IP address set to 2001:16b8:22c4:8300>
Sep 18 04:35:21 rtr dhcpcd[15081]: dmz0: DHCPv6 DAD completed
Sep 18 04:35:21 rtr dhcpcd[15081]: dmz0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6
Sep 18 04:35:21 rtr dhcpcd[15081]: lan0: DHCPv6 DAD completed
Sep 18 04:35:21 rtr dhcpcd[15081]: lan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6
Sep 18 04:35:29 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:22c4:83fc::
Sep 18 04:35:29 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2285:3afc:: old prefix
Sep 18 04:35:29 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:35:29 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:35:31 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:22c4:83fd::
Sep 18 04:35:31 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2285:3afd:: old prefix
Sep 18 04:35:31 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) 00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:35:34 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:22c4:83fc::
Sep 18 04:35:34 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2285:3afc:: old prefix
Sep 18 04:35:34 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:22c4:83fd::
Sep 18 04:35:34 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2285:3afd:: old prefix
Sep 18 04:35:34 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:35:34 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:35:34 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) 00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:35:36 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:22c4:83fc::
Sep 18 04:35:36 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2285:3afc:: old prefix
Sep 18 04:35:36 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:35:36 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:35:42 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:22c4:83fc::
Sep 18 04:35:42 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2285:3afc:: old prefix
Sep 18 04:35:42 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:35:42 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:35:43 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:22c4:83fd::
Sep 18 04:35:43 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2285:3afd:: old prefix
Sep 18 04:35:43 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) 00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:35:44 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:22c4:83fc::
Sep 18 04:35:44 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2285:3afc:: old prefix
Sep 18 04:35:44 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:35:44 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:35:48 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:22c4:83fd::
Sep 18 04:35:48 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2285:3afd:: old prefix
Sep 18 04:35:48 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) 00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:35:51 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:22c4:83fd::
Sep 18 04:35:51 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2285:3afd:: old prefix
Sep 18 04:35:51 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) 00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:35:54 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:22c4:83fc::
Sep 18 04:35:54 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2285:3afc:: old prefix
Sep 18 04:35:54 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:22c4:83fc::
Sep 18 04:35:54 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2285:3afc:: old prefix
Sep 18 04:35:54 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:35:54 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:35:58 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:22c4:83fd::
Sep 18 04:35:58 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2285:3afd:: old prefix
Sep 18 04:35:58 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) 00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:36:00 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:22c4:83fd::
Sep 18 04:36:00 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2285:3afd:: old prefix
Sep 18 04:36:00 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) 00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:36:01 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:22c4:83fc::
Sep 18 04:36:01 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2285:3afc:: old prefix
Sep 18 04:36:01 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:36:01 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:36:08 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:22c4:83fd::
Sep 18 04:36:08 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2285:3afd:: old prefix
Sep 18 04:36:08 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) 00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:36:10 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:22c4:83fc::
Sep 18 04:36:10 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2285:3afc:: old prefix
-------------------------

Best Regards,
--
Andrey Vakhitov

E-Mail: ***@vakhitov.net Stuttgart, Germany


Groeten
Geert Stappers

[Simon Kelley]

Post by Uwe Schindler
Hi Simon,

Post by Simon Kelley

Post by Andrey Vakhitov
I've set it up as you suggested, initially name resolution seems
to work fine. But after some days of operation (and some nightly
reconnects) dnsmasq seems to loose associated IPv6 adresses: DNS
request reports only IPv6 address assigned via DHCP. The SLAAC-based
IPv6 addresses on hosts are present and correct. How can I investigate
and fix this issue?

Look in the log for lines that look like
DHCPv4-derived IPv6 names on ........
which should occur after a reconnect with a different address which
causes new DHCP address ranges to be constructed.
After that happens, dnsmasq will take a guess at the IPv6 addresses
that hosts will assign themselves, based on the network address and
the MAC address of the host (transformed into EUI-64) It then starts
to ping those addresses, and when it gets a reply, it will log
SLAAC_CONFIRM(interface) <address> <hostname>
and start using the address/name in the DNS.
Once confirmed, the addresses remain valid until the DHCPv4 lease it's
based on expires or goes though init-reboot state or the MAC address
or interface it's accessible by changes.
The only other thing that will delete these addresses in a new address
appearing and a new dhcp range being created, hence it's interesting
to look at what happens in the logs after each of those events.

Strange thing: sometimes after reconnect I can observe expected behaviour
(like you described it, see log 1), sometimes not (SLAAC-CONFIRM is missing,
see log 2)

Is it possible that those hosts are sometimes down or disconnected?

FWIW the strategy in the code is to continue trying to ping putative
addresses more-or-less forever, with increasing backoff, _except_ when a
call to sendto() returns EHOSTUNREACH (no route to host) which causes
the code to give up.

I confess I have no idea why it's like that, and the git commit
messages don't really give much clue. Even more annoying, the original
code logged when giving up, but that was subsequently removed, with
equally unsatisfactory commits.

Cheers,

Simon.

[Andrey Vakhitov]

Hello Simon,

Post by Simon Kelley
FWIW the strategy in the code is to continue trying to ping putative
addresses more-or-less forever, with increasing backoff, _except_
when a call to sendto()
returns EHOSTUNREACH (no route to host) which causes the code to give up.

Is it possible that it collides with route changes happening during
renumbering? Is it possible to keep pinging for some prolonged period
(may be configurable, let's say 10 minutes) ?

Post by Simon Kelley
I confess I have no idea why it's like that, and the git commit
messages don't
really give much clue. Even more annoying, the original code logged
when giving up, but that was subsequently removed, with equally
unsatisfactory commits.

Do you have a reference to appropriate changesets? Maybe I could make
local patches and collect more information on this issue... Well, I'm
leaving for a week right now, so I have to put it on hold for a week,
but I'd continue investigation after that if I'd know there to put the traces ...

Reversing this patch
...
Will give you logging for the event of giving up on "no route to host"
error. If we can establish that's what's happening, it should be possible to
tweak the strategy to fix the problem.

I've reactivated thepatch locally and observing it since 4 days. Todays night associated IPv6 names got lost again directly during IP prefix change process, the log shows it clearly (see log 1). So I would vote again for retrying during some extended timeframe even if the host isn't reachable.
Renumbering during previous 3 nights went smooth, see log 2 for example

----------------- log 1 ---------------------
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: unauthenticated RECONFIGURE6 from fe80::7eff:4dff:fe03:2c18
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: RECONFIGURE6 from fe80::7eff:4dff:fe03:2c18
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: broadcasting RENEW6 (xid 0x4a0693), next in 10.5 seconds
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: DHCPv6 REPLY: prefix mismatch
Okt 03 04:50:57 rtr dhcpcd[6467]: lan0: deleting address 2001:16b8:224c:d2fc::1/64
Okt 03 04:50:57 rtr dhcpcd[6467]: lo: deleting reject route to 2001:16b8:224c:d2fc::/62
Okt 03 04:50:57 rtr dhcpcd[6467]: lan0: deleting route to 2001:16b8:224c:d2fc::/64
Okt 03 04:50:57 rtr dhcpcd[6467]: dmz0: deleting address 2001:16b8:224c:d2fd::1/64
Okt 03 04:50:57 rtr dhcpcd[6467]: dmz0: deleting route to 2001:16b8:224c:d2fd::/64
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: soliciting a DHCPv6 lease
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: delaying SOLICIT6 (xid 0x88553e), next in 0.3 seconds
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: router advertisement on 2001:16b8:224c:d2fd::, old prefix for dmz0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: router advertisement on 2001:16b8:224c:d2fc::, old prefix for lan0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: no address range available for DHCPv6 request via lan0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: no address range available for DHCPv6 request via lan0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: no address range available for DHCPv6 request via dmz0
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: broadcasting SOLICIT6 (xid 0x88553e), next in 0.9 seconds
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: SOL_MAX_RT 3600 -> 3600
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: INF_MAX_RT 3600 -> 3600
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: ADV 2001:16b8:2284:b9fc::/62 from fe80::7eff:4dff:fe03:2c18
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: broadcasting REQUEST6 (xid 0x3b716e), next in 1.0 seconds
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: REPLY6 received from fe80::7eff:4dff:fe03:2c18
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: 2001:16b8:224c:d2fc::/62: became stale
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: renew in 1800, rebind in 2880, expire in 7200 seconds
Okt 03 04:50:57 rtr dhcpcd[6467]: lo: adding reject route to 2001:16b8:2284:b9fc::/62
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: writing lease `/var/db/dhcpcd/wan0.lease6'
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: delegated prefix 2001:16b8:2284:b9fc::/62
Okt 03 04:50:57 rtr dhcpcd[6467]: lan0: adding address 2001:16b8:2284:b9fc::1/64
Okt 03 04:50:57 rtr dhcpcd[6467]: lan0: pltime 3600 seconds, vltime 7200 seconds
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: router advertisement on 2001:16b8:2284:b9fc::, old prefix for lan0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: DHCPv6 stateless on 2001:16b8:2284:b9fc::, constructed for lan0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: DHCPv4-derived IPv6 names on 2001:16b8:2284:b9fc::, constructed for lan0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: router advertisement on 2001:16b8:2284:b9fc::, constructed for lan0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: SLAAC-HOSTUNREACH a00:3a::2001:16b8:2284:b9fc
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: SLAAC-HOSTUNREACH a00:3a::2001:16b8:2284:b9fc
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: SLAAC-HOSTUNREACH a00:3a::2001:16b8:2284:b9fc
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: SLAAC-HOSTUNREACH a00:3a::2001:16b8:2284:b9fc
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: SLAAC-HOSTUNREACH a00:3a::2001:16b8:2284:b9fc
Okt 03 04:50:57 rtr dhcpcd[6467]: lan0: waiting for DHCPv6 DAD to complete
Okt 03 04:50:57 rtr dhcpcd[6467]: dmz0: adding address 2001:16b8:2284:b9fd::1/64
Okt 03 04:50:57 rtr dhcpcd[6467]: dmz0: pltime 3600 seconds, vltime 7200 seconds
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: router advertisement on 2001:16b8:2284:b9fd::, old prefix for dmz0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: DHCPv6 stateless on 2001:16b8:2284:b9fd::, constructed for dmz0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: DHCPv4-derived IPv6 names on 2001:16b8:2284:b9fd::, constructed for dmz0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: router advertisement on 2001:16b8:2284:b9fd::, constructed for dmz0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: SLAAC-HOSTUNREACH a00:3a::2001:16b8:2284:b9fd
Okt 03 04:50:57 rtr dhcpcd[6467]: dmz0: waiting for DHCPv6 DAD to complete
Okt 03 04:50:57 rtr dhcpcd[6467]: lan0: adding route to 2001:16b8:2284:b9fc::/64
Okt 03 04:50:57 rtr dhcpcd[6467]: dmz0: adding route to 2001:16b8:2284:b9fd::/64
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' BOUND6
Okt 03 04:50:58 rtr dhcpcd[6467]: wan0: Router Advertisement DAD completed
Okt 03 04:50:58 rtr dhcpcd[6467]: wan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
-----------------

----------------- log 2 ---------------------
Okt 02 04:26:13 rtr dhcpcd[15287]: wan0: unauthenticated RECONFIGURE6 from fe80::7eff:4dff:fe03:2c18
Okt 02 04:26:13 rtr dhcpcd[15287]: wan0: RECONFIGURE6 from fe80::7eff:4dff:fe03:2c18
Okt 02 04:26:13 rtr dhcpcd[15287]: wan0: broadcasting RENEW6 (xid 0x7c8262), next in 9.5 seconds
Okt 02 04:26:13 rtr dhcpcd[15287]: wan0: DHCPv6 REPLY: prefix mismatch
Okt 02 04:26:13 rtr dhcpcd[15287]: lan0: deleting address 2001:16b8:22c3:19fc::1/64
Okt 02 04:26:13 rtr dhcpcd[15287]: lo: deleting reject route to 2001:16b8:22c3:19fc::/62
Okt 02 04:26:13 rtr dhcpcd[15287]: lan0: deleting route to 2001:16b8:22c3:19fc::/64
Okt 02 04:26:13 rtr dhcpcd[15287]: dmz0: deleting address 2001:16b8:22c3:19fd::1/64
Okt 02 04:26:13 rtr dhcpcd[15287]: dmz0: deleting route to 2001:16b8:22c3:19fd::/64
Okt 02 04:26:13 rtr dhcpcd[15287]: wan0: soliciting a DHCPv6 lease
Okt 02 04:26:13 rtr dnsmasq-dhcp[11540]: router advertisement on 2001:16b8:22c3:19fd::, old prefix for dmz0
Okt 02 04:26:13 rtr dnsmasq-dhcp[11540]: router advertisement on 2001:16b8:22c3:19fc::, old prefix for lan0
Okt 02 04:26:13 rtr dhcpcd[15287]: wan0: delaying SOLICIT6 (xid 0xe758a9), next in 0.3 seconds
Okt 02 04:26:13 rtr dnsmasq-dhcp[11540]: no address range available for DHCPv6 request via lan0
Okt 02 04:26:13 rtr dnsmasq-dhcp[11540]: no address range available for DHCPv6 request via lan0
Okt 02 04:26:13 rtr dnsmasq-dhcp[11540]: no address range available for DHCPv6 request via dmz0
Okt 02 04:26:14 rtr dhcpcd[15287]: wan0: broadcasting SOLICIT6 (xid 0xe758a9), next in 1.0 seconds
Okt 02 04:26:14 rtr dhcpcd[15287]: wan0: SOL_MAX_RT 3600 -> 3600
Okt 02 04:26:14 rtr dhcpcd[15287]: wan0: INF_MAX_RT 3600 -> 3600
Okt 02 04:26:14 rtr dhcpcd[15287]: wan0: ADV 2001:16b8:2220:4ffc::/62 from fe80::7eff:4dff:fe03:2c18
Okt 02 04:26:14 rtr dhcpcd[15287]: wan0: broadcasting REQUEST6 (xid 0x5e613f), next in 1.0 seconds
Okt 02 04:26:14 rtr dhcpcd[15287]: wan0: REPLY6 received from fe80::7eff:4dff:fe03:2c18
Okt 02 04:26:14 rtr dhcpcd[15287]: wan0: 2001:16b8:22c3:19fc::/62: became stale
Okt 02 04:26:14 rtr dhcpcd[15287]: wan0: renew in 1800, rebind in 2880, expire in 7200 seconds
Okt 02 04:26:14 rtr dhcpcd[15287]: lo: adding reject route to 2001:16b8:2220:4ffc::/62
Okt 02 04:26:14 rtr dhcpcd[15287]: wan0: writing lease `/var/db/dhcpcd/wan0.lease6'
Okt 02 04:26:14 rtr dhcpcd[15287]: wan0: delegated prefix 2001:16b8:2220:4ffc::/62
Okt 02 04:26:14 rtr dhcpcd[15287]: lan0: adding address 2001:16b8:2220:4ffc::1/64
Okt 02 04:26:14 rtr dhcpcd[15287]: lan0: pltime 3600 seconds, vltime 7200 seconds
Okt 02 04:26:14 rtr dhcpcd[15287]: lan0: waiting for DHCPv6 DAD to complete
Okt 02 04:26:14 rtr dhcpcd[15287]: dmz0: adding address 2001:16b8:2220:4ffd::1/64
Okt 02 04:26:14 rtr dhcpcd[15287]: dmz0: pltime 3600 seconds, vltime 7200 seconds
Okt 02 04:26:14 rtr dhcpcd[15287]: dmz0: waiting for DHCPv6 DAD to complete
Okt 02 04:26:14 rtr dhcpcd[15287]: lan0: adding route to 2001:16b8:2220:4ffc::/64
Okt 02 04:26:14 rtr dnsmasq-dhcp[11540]: router advertisement on 2001:16b8:2220:4ffc::, old prefix for lan0
Okt 02 04:26:14 rtr dnsmasq-dhcp[11540]: DHCPv6 stateless on 2001:16b8:2220:4ffc::, constructed for lan0
Okt 02 04:26:14 rtr dnsmasq-dhcp[11540]: DHCPv4-derived IPv6 names on 2001:16b8:2220:4ffc::, constructed for lan0
Okt 02 04:26:14 rtr dnsmasq-dhcp[11540]: router advertisement on 2001:16b8:2220:4ffc::, constructed for lan0
Okt 02 04:26:14 rtr dnsmasq-dhcp[11540]: router advertisement on 2001:16b8:2220:4ffd::, old prefix for dmz0
Okt 02 04:26:14 rtr dnsmasq-dhcp[11540]: DHCPv6 stateless on 2001:16b8:2220:4ffd::, constructed for dmz0
Okt 02 04:26:14 rtr dnsmasq-dhcp[11540]: DHCPv4-derived IPv6 names on 2001:16b8:2220:4ffd::, constructed for dmz0
Okt 02 04:26:14 rtr dnsmasq-dhcp[11540]: router advertisement on 2001:16b8:2220:4ffd::, constructed for dmz0
Okt 02 04:26:14 rtr dhcpcd[15287]: dmz0: adding route to 2001:16b8:2220:4ffd::/64
Okt 02 04:26:14 rtr dhcpcd[15287]: wan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' BOUND6
Okt 02 04:26:14 rtr dhcpcd[15287]: wan0: Router Advertisement DAD completed
Okt 02 04:26:14 rtr dhcpcd[15287]: wan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
-----------------


Best Regards,
--
Andrey Vakhitov

E-Mail: ***@vakhitov.net Stuttgart, Germany

[Andrey Vakhitov]

Hello Simon,

I've reactivated the patch locally and observing it since 4 days. Todays night associated
IPv6 names got lost again directly during IP prefix change process, the log shows it clearly
(see log 1). So I would vote again for retrying during some extended timeframe even if the
host isn't reachable.

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=ee1df06aabaa8f212eaa7102f6d62cb25bfb35e9

Thanks a lot for your great support! I've applied the patch and will monitor the behaviour.

Best Regards,
--
Andrey Vakhitov

E-Mail: ***@vakhitov.net Stuttgart, Germany

[Andrey Vakhitov]

Hello Simon,

the patch seems to work reliable, I've not seen any glitches so far. I'd suggest to apply it to main branch.

-----Ursprüngliche Nachricht-----
Von: Andrey Vakhitov <***@vakhitov.net>
Gesendet: Samstag, 6. Oktober 2018 20:31
An: 'Simon Kelley' <***@thekelleys.org.uk>; 'dnsmasq-***@lists.thekelleys.org.uk' <dnsmasq-***@lists.thekelleys.org.uk>
Betreff: AW: AW: AW: [Dnsmasq-discuss] clients of DHCPv6 with constructed IPv6 address range are not notified on address range change

Hello Simon,

I've reactivated the patch locally and observing it since 4 days.
Todays night associated
IPv6 names got lost again directly during IP prefix change process,
the log shows it clearly (see log 1). So I would vote again for
retrying during some extended timeframe even if the host isn't reachable.

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=ee1df06aabaa
8f212eaa7102f6d62cb25bfb35e9

Thanks a lot for your great support! I've applied the patch and will monitor the behaviour.

Best Regards,
--
Andrey Vakhitov

E-Mail: ***@vakhitov.net Stuttgart, Germany

[Simon Kelley]

Post by Andrey Vakhitov
Hello Simon,
the patch seems to work reliable, I've not seen any glitches so far. I'd suggest to apply it to main branch.

The patch is in 2.80, released yesterday.

Simon.

Post by Andrey Vakhitov
-----Ursprüngliche Nachricht-----
Gesendet: Samstag, 6. Oktober 2018 20:31
Betreff: AW: AW: AW: [Dnsmasq-discuss] clients of DHCPv6 with constructed IPv6 address range are not notified on address range change
Hello Simon,

I've reactivated the patch locally and observing it since 4 days.
Todays night associated
IPv6 names got lost again directly during IP prefix change process,
the log shows it clearly (see log 1). So I would vote again for
retrying during some extended timeframe even if the host isn't reachable.

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=ee1df06aabaa
8f212eaa7102f6d62cb25bfb35e9

Thanks a lot for your great support! I've applied the patch and will monitor the behaviour.
Best Regards,
--
Andrey Vakhitov

[Simon Kelley]

Post by Andrey Vakhitov
Strange thing: sometimes after reconnect I can observe expected behaviour
(like you described it, see log 1), sometimes not (SLAAC-CONFIRM is missing,
see log 2)
---------- log1 --------
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 2001:16b8:2284:f5fc::, constructed for lan0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 2001:16b8:2284:f5fc::, constructed for lan0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on 2001:16b8:2284:f5fc::, constructed for lan0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 2001:16b8:2284:f5fd::, constructed for dmz0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 2001:16b8:2284:f5fd::, constructed for dmz0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on 2001:16b8:2284:f5fd::, constructed for dmz0
Sep 17 20:22:45 rtr dnsmasq[7855]: reading /etc/dnsmasq-resolv.conf
---------- log2 --------
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 2001:16b8:22c4:83fc::, constructed for lan0
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 2001:16b8:22c4:83fc::, constructed for lan0
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: router advertisement on 2001:16b8:22c4:83fc::, constructed for lan0
Sep 18 04:35:20 rtr dhcpcd[15081]: lan0: waiting for DHCPv6 DAD to complete
Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: adding address 2001:16b8:22c4:83fd::1/64
Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: pltime 3600 seconds, vltime 7200 seconds
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 2001:16b8:22c4:83fd::, constructed for dmz0
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 2001:16b8:22c4:83fd::, constructed for dmz0
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: router advertisement on 2001:16b8:22c4:83fd::, constructed for dmz0
Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: waiting for DHCPv6 DAD to complete
Sep 18 04:35:20 rtr dhcpcd[15081]: lan0: adding route to 2001:16b8:22c4:83fc::/64
Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: adding route to 2001:16b8:22c4:83fd::/64
Sep 18 04:35:20 rtr dhcpcd[15081]: wan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' BOUND6
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) 00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
Sep 18 04:35:20 rtr dhcpcd[15081]: wan0: Router Advertisement DAD completed
Sep 18 04:35:20 rtr dhcpcd[15081]: wan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
Sep 18 04:35:21 rtr ddclient[1597]: SUCCESS: updating rtrhomevak.spdns.de: good: IP address set to 2001:16b8:22c4:8300>
Sep 18 04:35:21 rtr dhcpcd[15081]: dmz0: DHCPv6 DAD completed
Sep 18 04:35:21 rtr dhcpcd[15081]: dmz0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6
Sep 18 04:35:21 rtr dhcpcd[15081]: lan0: DHCPv6 DAD completed
Sep 18 04:35:21 rtr dhcpcd[15081]: lan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6

If you look, lots of things are different between the two logs. In the
second one, dhcpcd is doing routing table changes, for instance. That
could explain why dnsmasq gives up trying to confirm SLAAC addresses
because it gets transient "no route to host" returns. (see previous
reply to make sense of this.)


Simon.

[Andrey Vakhitov]

Hello Simon,

Post by Simon Kelley
If you look, lots of things are different between the two logs. In the

second one,

Post by Simon Kelley
dhcpcd is doing routing table changes, for instance. That could explain

why dnsmasq

Post by Simon Kelley
gives up trying to confirm SLAAC addresses because it gets transient "no

route to host"

Post by Simon Kelley
returns. (see previous reply to make sense of this.)

Ok, change of the routing is actually the "normal case" for me in this
scenario. Once again: My ISP requires nightly reconnect. After the reconnect
IPv6 address range assigned by IPS changes normally. Delegated prefixes
allocated by upstream router are changing also. Addresses of internal
interfaces there dnsmasq provides DHCP & DNS services are changing as well
(new prefix). And this is exactly the reason why I want to utilize
"ra-names" option: IPv6 prefixes are changing every day and I need name
resolution to reach hosts via IPv6.

Best Regards,
--
Andrey Vakhitov

E-Mail:  ***@vakhitov.net            Stuttgart, Germany

[Simon Kelley]

Post by Andrey Vakhitov
Hello Simon & Uwe,

Post by Uwe Schindler
unfortunately that problem is seen often with providers in Germany, although the large ones no longer
do it (or allow to disable the disconnect). The problem is that German providers automatically
disconnect the PPPoE connection every 24 hrs. After reconnecting you get a new address (IPv4) and
prefix (IPv6). Since the changes we did (deprecating prefixes) this works fine for standard router
advertisements. But won't help for DHCPv6.

This is exactly my case, my ISP is o2.

Post by Uwe Schindler

Post by Simon Kelley
Dnsmasq doesn't implement RECONFIGURE. It probably should. The main
problem, from a quick look at the RFC, is that RECONFIGURE mandates
use of security mechanism, and dnsmasq doesn't implement that either!

I know that it's against RFC but some routers (like the fritzbox I'm using, very popular choice in Germany) actually send RECONFIGURE without authentication. This is BTW the reason for introduction of "noauthrequired" config option in dhcpcd ;-)

I wonder if a very simple RECONFIGURE implementation would work here:
Just send a non-specific RECONFIGURE message to all clients when a new
IPV6 network turns up? Without security. That would be fairly simple to
implement and to configure.



Cheers,

Simon.