Discussion:
static lease is ignored
(too old to reply)
Andrea Borgia
2019-08-17 09:50:02 UTC
Permalink
Hi.

I have two "testing" installations with corresponding static lease in
the router; in its logs I see the lease gets requested and granted.

Problem is, both systems do not adopt that address but they have:
- a /128 (different from the lease, unknown origin) marked "scope global
noprefixroute"
- a /64 marked "scope global temporary dynamic"
- another /64 marked "scope global mngtmpaddr noprefixroute"
- a link-local address

The end result is name resolution fails and systems are only reachable
via ipv4 fallback. Privacy-wise the system is already preferring the PE
address, which is good.

How I find out the origin of that /128 and, most important, the reason
why the lease is ignored? Both systems are using type 4 DUID, though it
probably doesn't matter as long as the router has a matching entry.

Thanks,
Andrea.

P.S.: this is a spin-off from an earlier post on OpenWRT's forum:
https://forum.openwrt.org/t/stale-dhcpv6-leases-under-network-dhcp-and-dns/42535/7
Chris Bell
2019-08-18 11:40:01 UTC
Permalink
Post by Andrea Borgia
Hi.
I have two "testing" installations with corresponding static lease in
the router; in its logs I see the lease gets requested and granted.
- a /128 (different from the lease, unknown origin) marked "scope global
noprefixroute"
- a /64 marked "scope global temporary dynamic"
- another /64 marked "scope global mngtmpaddr noprefixroute"
- a link-local address
The end result is name resolution fails and systems are only reachable
via ipv4 fallback. Privacy-wise the system is already preferring the PE
address, which is good.
How I find out the origin of that /128 and, most important, the reason
why the lease is ignored? Both systems are using type 4 DUID, though it
probably doesn't matter as long as the router has a matching entry.
Thanks,
Andrea.
https://forum.openwrt.org/t/stale-dhcpv6-leases-under-network-dhcp-and-dns/4
2535/7
DHCP was originally designed for IPv4, and some servers do not provide a
comparable IPv6 service. To add to the confusion, mobile devices often work
best (or only!) with IPv6 Router Advertisement, RA, provided by routers and
gateways. This caused a headache for Microsoft when they decided to make their
own headquarters IPv6 only, but Microsoft had not even attempted to design a
system compatible with RA.
RA is able to inform devices which address ranges should be used where, while
all devices should be able to decide which address to use when attempting to
access any other device. Each device should compare the destination address
with all their own alternatives and choose the one with the greatest number of
shared leading binary digits. I also run BIND9 as a local reference for DHCP
servers, with configurations for all network names and "ARPA" reverse lookups.
All local routing is done to box_name.network_name.
It has taken time, and I am still learning. If you decide to try Shorewall(6)
then all network names must be no greater than 3 characters, and not begin
with a numeral.
--
Chris Bell
Website http://chrisbell.org.uk
Andrea Borgia
2019-08-18 18:30:01 UTC
Permalink
Post by Chris Bell
It has taken time, and I am still learning. If you decide to try Shorewall(6)
then all network names must be no greater than 3 characters, and not begin
with a numeral.
I'm running OpenWRT and I do not anticipate changing it anytime soon:
changing the whole setup without a valid reason would just be adding
complication to complication and I'm already a master at that without
external help ;)

Especially since in my own network there is at least one host, a raspi,
behaving just as expected: requesting the lease, getting it and then
actually using it.

I'd like to understand how the current Debian "testing" goes about
acquiring an IPV6 address to get to the bottom of this, in other words.

Andrea.
Andrea Borgia
2019-08-18 22:20:01 UTC
Permalink
Post by Andrea Borgia
I'd like to understand how the current Debian "testing" goes about
acquiring an IPV6 address to get to the bottom of this, in other words.
(public) note to self: it works MUCH better when a dhcpv6 "solicit"
message is quickly followed by a "request". If anything, say a firewall,
were to block the reply to "solicit", fat chance that it'll ever work!
Loading...