[Dnsmasq-discuss] Possible Bug: DHCPV6 Does Not Make Lease Entry for DHCP CONFIRM

[Eric Luehrsen]

In using the latest OpenWRT 15.05 (C.C.) with DNSMASQ 2.73 is logging DHCP (v6) CONFIRM events with host names but not re-entering them into the lease file. (note, I also saw this late in 14.07 (B.B.) with DNSMASQ for that release so its not new.)

A way to catch this behavior is use (client) a Debian flavor with Network-Manager driving the connections. The sever again OpenWRT with ODHCP removed and just DNSMASQ for all DNS/DHCP services 4/6. Upon its initial connection the client will make a DHCP (v6) SOLICIT. At this time, DNSMASQ will write a lease file entry just as one would expect like DHCP (v4). Then cause the router to reset. Upon reconnecting, the client will issue a DHCP CONFIRM: "just checking this is still mine," DNSMASQ logs the event in syslog, the host name is in syslog, but the host name is not in the lease file.

The lease file information appears to be used by DNSMASQ internally to prevent hashing into the same address for two clients. While unlikely with the advisable DHCP "constructor" of ::1000-::FFFF, this could result in conflicts if DNSMASQ receives multiple SIGUP's from other processes and no lease is found to prevent conflict. The lease files can also be used in third party scripts to establish host identification and provide access to semi-controlled resources. Such as, hotel or restaurant Internet using an authorized "receipt code" check with an on-router intercept website for gating to the world.

-Reboot Router
-Sun Oct 18 00:35:07 2015 daemon.info dnsmasq-dhcp[1811]: DHCPCONFIRM(br-lan) DUID
-Sun Oct 18 00:35:07 2015 daemon.info dnsmasq-dhcp[1811]: DHCPREPLY(br-lan) fdc0:a828::XXXX DUID HOSTNAME
-Sun Oct 18 00:35:07 2015 daemon.info dnsmasq-dhcp[1811]: DHCPREPLY(br-lan) 2001:470:YYYY:YYYY::XXXX DUID HOSTNAME
-No dhcpv6 lease file entry

(Note: It appears when Windows drops/looses a connection for more than a second-ish, it will always SOLICIT and get entered into the lease file.)


ERIC

[Simon Kelley]

Dnsmasq doesn't insert a DHCP lease into the database when it gets a
SOLICIT, that happens when it gets a REQUEST.

I think there are two things here. The first is that openWRT doesn't
keep the lease database in non-volatile storage. Dnsmasq really wants
the lease database to persist over a reboot, and you're only seeing
this effect because it doesn't.

The second issue is the semantics of DHCPCONFIRM. RFC 3315 says

Any responding servers will indicate whether those
addresses are appropriate for the link to which the client is
attached with the status in the Reply message it returns to the
client.

My reading is that this is NOT a check that lease(s) exist, only that
the addresses are in the appropriate subnet, which they are in this
case. It's possible that I've mis-interpreted the intention of the RFC
here.

Cheers,

Simon.

Post by Eric Luehrsen
In using the latest OpenWRT 15.05 (C.C.) with DNSMASQ 2.73 is
logging DHCP (v6) CONFIRM events with host names but not
re-entering them into the lease file. (note, I also saw this late
in 14.07 (B.B.) with DNSMASQ for that release so its not new.)
A way to catch this behavior is use (client) a Debian flavor with
Network-Manager driving the connections. The sever again OpenWRT
with ODHCP removed and just DNSMASQ for all DNS/DHCP services 4/6.
Upon its initial connection the client will make a DHCP (v6)
SOLICIT. At this time, DNSMASQ will write a lease file entry just
as one would expect like DHCP (v4). Then cause the router to reset.
Upon reconnecting, the client will issue a DHCP CONFIRM: "just
checking this is still mine," DNSMASQ logs the event in syslog, the
host name is in syslog, but the host name is not in the lease
file.
The lease file information appears to be used by DNSMASQ
internally to prevent hashing into the same address for two
clients. While unlikely with the advisable DHCP "constructor" of
::1000-::FFFF, this could result in conflicts if DNSMASQ receives
multiple SIGUP's from other processes and no lease is found to
prevent conflict. The lease files can also be used in third party
scripts to establish host identification and provide access to
semi-controlled resources. Such as, hotel or restaurant Internet
using an authorized "receipt code" check with an on-router
intercept website for gating to the world.
-Reboot Router -Sun Oct 18 00:35:07 2015 daemon.info
dnsmasq-dhcp[1811]: DHCPCONFIRM(br-lan) DUID -Sun Oct 18 00:35:07
2015 daemon.info dnsmasq-dhcp[1811]: DHCPREPLY(br-lan)
fdc0:a828::XXXX DUID HOSTNAME -Sun Oct 18 00:35:07 2015
daemon.info dnsmasq-dhcp[1811]: DHCPREPLY(br-lan)
2001:470:YYYY:YYYY::XXXX DUID HOSTNAME -No dhcpv6 lease file entry
(Note: It appears when Windows drops/looses a connection for more
than a second-ish, it will always SOLICIT and get entered into the
lease file.)
ERIC
_______________________________________________ Dnsmasq-discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Eric Luehrsen]

Simon -

Understood. I should not have short handed "the full process
which starts by SOLICIT," so that a full new lease is always entered.

With respect to OpenWRT or any embedded server software, there is
a pragmatic limit to the embedded flash. a SoC has 8-16MB of internal
flash, often on the smaller side. It also is not so well distributed
with its re-write usage in hardware. The RAM is external 128-256MB.
Things like lease files, cache files, and whatever go into RAM.

With respect to RFC 3315, its implied scope appears to be on the
link itself. It doesn't cover, at least well, the robustness actions
that should occur in the server or client storage media. In section
18.1.2, it includes use cases like wireless roaming.

If stateless DHCP, then I guess INFO~ w/ CONFIRM could be be used,
but the RA pretty much nail down the prefix appropriateness. The
only use for CONFIRM I can think of is stateful DHCP w/o RA to
passively confirm, but without resetting timers and maybe triggering
some authentication event. ISC dhclient appears to send CONFIRM just
with the stateful DHCP address.

- If stateless DHCP clients would use CONFIRM, then you wouldn't
- have to invent the IPV4-MAC to IPV6-SLAAC DNS inferred entry.
- Nice one by the way. Also a network would have ID on all those
- privacy addresses flying about.

So lets say DNSMASQ receives [PRE/64]::AB6E from within its
constructor range ::1000-::FFFF. This address is not
[PRE/64]:[SLAAC]. Would this not infer a lease registration
reconciliation and not just a stateless DHCP confirmation with
respect to an RA? If DNSMASQ were a human clerk, would he not
say "hey, have you stayed with us before? Let me get your honors
member information penciled in."

So I agree there is room for lots of re-interpretation. However,
should we consider observed behaviors in the wild and the strong
inference possible with DNSMASQ internal design (DHCP-RNAGE option).
If a roaming network needed to be reset, then it would be nice to
ensure all machines resuming stateful access were in a lease file.

- Eric

Post by Simon Kelley
Dnsmasq doesn't insert a DHCP lease into the database when it gets a
SOLICIT, that happens when it gets a REQUEST.
I think there are two things here. The first is that openWRT doesn't
keep the lease database in non-volatile storage. Dnsmasq really wants
the lease database to persist over a reboot, and you're only seeing
this effect because it doesn't.
The second issue is the semantics of DHCPCONFIRM. RFC 3315 says
Any responding servers will indicate whether those
addresses are appropriate for the link to which the client is
attached with the status in the Reply message it returns to the
client.
My reading is that this is NOT a check that lease(s) exist, only that
the addresses are in the appropriate subnet, which they are in this
case. It's possible that I've mis-interpreted the intention of the RFC
here.
Cheers,
Simon.

Post by Eric Luehrsen
In using the latest OpenWRT 15.05 (C.C.) with DNSMASQ 2.73 is
logging DHCP (v6) CONFIRM events with host names but not
re-entering them into the lease file. (note, I also saw this late
in 14.07 (B.B.) with DNSMASQ for that release so its not new.)
A way to catch this behavior is use (client) a Debian flavor with
Network-Manager driving the connections. The sever again OpenWRT
with ODHCP removed and just DNSMASQ for all DNS/DHCP services 4/6.
Upon its initial connection the client will make a DHCP (v6)
SOLICIT. At this time, DNSMASQ will write a lease file entry just
as one would expect like DHCP (v4). Then cause the router to reset.
Upon reconnecting, the client will issue a DHCP CONFIRM: "just
checking this is still mine," DNSMASQ logs the event in syslog, the
host name is in syslog, but the host name is not in the lease
file.
The lease file information appears to be used by DNSMASQ
internally to prevent hashing into the same address for two
clients. While unlikely with the advisable DHCP "constructor" of
::1000-::FFFF, this could result in conflicts if DNSMASQ receives
multiple SIGUP's from other processes and no lease is found to
prevent conflict. The lease files can also be used in third party
scripts to establish host identification and provide access to
semi-controlled resources. Such as, hotel or restaurant Internet
using an authorized "receipt code" check with an on-router
intercept website for gating to the world.
-Reboot Router -Sun Oct 18 00:35:07 2015 daemon.info
dnsmasq-dhcp[1811]: DHCPCONFIRM(br-lan) DUID -Sun Oct 18 00:35:07
2015 daemon.info dnsmasq-dhcp[1811]: DHCPREPLY(br-lan)
fdc0:a828::XXXX DUID HOSTNAME -Sun Oct 18 00:35:07 2015
daemon.info dnsmasq-dhcp[1811]: DHCPREPLY(br-lan)
2001:470:YYYY:YYYY::XXXX DUID HOSTNAME -No dhcpv6 lease file entry
(Note: It appears when Windows drops/looses a connection for more
than a second-ish, it will always SOLICIT and get entered into the
lease file.)
ERIC

[Simon Kelley]

I'm not clear how the current behaviour should change.

For DHCPv4, if a DHCP client renews a lease which isn;t in the
database, then it gets added - this is explicitly to improve behaviour
when the lease database is lost. Maybe the same should be done for
DHCPv6. Note that RENEW is not CONFIRM in this case.


Cheers,

Simon.

Post by Eric Luehrsen
Simon -
Understood. I should not have short handed "the full process which
starts by SOLICIT," so that a full new lease is always entered.
With respect to OpenWRT or any embedded server software, there is a
pragmatic limit to the embedded flash. a SoC has 8-16MB of
internal flash, often on the smaller side. It also is not so well
distributed with its re-write usage in hardware. The RAM is
external 128-256MB. Things like lease files, cache files, and
whatever go into RAM.
With respect to RFC 3315, its implied scope appears to be on the
link itself. It doesn't cover, at least well, the robustness
actions that should occur in the server or client storage media. In
section 18.1.2, it includes use cases like wireless roaming.
If stateless DHCP, then I guess INFO~ w/ CONFIRM could be be used,
but the RA pretty much nail down the prefix appropriateness. The
only use for CONFIRM I can think of is stateful DHCP w/o RA to
passively confirm, but without resetting timers and maybe
triggering some authentication event. ISC dhclient appears to send
CONFIRM just with the stateful DHCP address.
- If stateless DHCP clients would use CONFIRM, then you wouldn't -
have to invent the IPV4-MAC to IPV6-SLAAC DNS inferred entry. -
Nice one by the way. Also a network would have ID on all those -
privacy addresses flying about.
So lets say DNSMASQ receives [PRE/64]::AB6E from within its
constructor range ::1000-::FFFF. This address is not
[PRE/64]:[SLAAC]. Would this not infer a lease registration
reconciliation and not just a stateless DHCP confirmation with
respect to an RA? If DNSMASQ were a human clerk, would he not say
"hey, have you stayed with us before? Let me get your honors member
information penciled in."
So I agree there is room for lots of re-interpretation. However,
should we consider observed behaviors in the wild and the strong
inference possible with DNSMASQ internal design (DHCP-RNAGE
option). If a roaming network needed to be reset, then it would be
nice to ensure all machines resuming stateful access were in a
lease file.
- Eric

Post by Simon Kelley
Dnsmasq doesn't insert a DHCP lease into the database when it
gets a SOLICIT, that happens when it gets a REQUEST.
I think there are two things here. The first is that openWRT
doesn't keep the lease database in non-volatile storage. Dnsmasq
really wants the lease database to persist over a reboot, and
you're only seeing this effect because it doesn't.
The second issue is the semantics of DHCPCONFIRM. RFC 3315 says
Any responding servers will indicate whether those addresses are
appropriate for the link to which the client is attached with the
status in the Reply message it returns to the client.
My reading is that this is NOT a check that lease(s) exist, only
that the addresses are in the appropriate subnet, which they are
in this case. It's possible that I've mis-interpreted the
intention of the RFC here.
Cheers,
Simon.

Post by Eric Luehrsen
In using the latest OpenWRT 15.05 (C.C.) with DNSMASQ 2.73 is
logging DHCP (v6) CONFIRM events with host names but not
re-entering them into the lease file. (note, I also saw this
late in 14.07 (B.B.) with DNSMASQ for that release so its not
new.)
A way to catch this behavior is use (client) a Debian flavor
with Network-Manager driving the connections. The sever again
OpenWRT with ODHCP removed and just DNSMASQ for all DNS/DHCP
services 4/6. Upon its initial connection the client will make
a DHCP (v6) SOLICIT. At this time, DNSMASQ will write a lease
file entry just as one would expect like DHCP (v4). Then cause
the router to reset. Upon reconnecting, the client will issue a
DHCP CONFIRM: "just checking this is still mine," DNSMASQ logs
the event in syslog, the host name is in syslog, but the host
name is not in the lease file.
The lease file information appears to be used by DNSMASQ
internally to prevent hashing into the same address for two
clients. While unlikely with the advisable DHCP "constructor"
of ::1000-::FFFF, this could result in conflicts if DNSMASQ
receives multiple SIGUP's from other processes and no lease is
found to prevent conflict. The lease files can also be used in
third party scripts to establish host identification and
provide access to semi-controlled resources. Such as, hotel or
restaurant Internet using an authorized "receipt code" check
with an on-router intercept website for gating to the world.
-Reboot Router -Sun Oct 18 00:35:07 2015 daemon.info
dnsmasq-dhcp[1811]: DHCPCONFIRM(br-lan) DUID -Sun Oct 18
00:35:07 2015 daemon.info dnsmasq-dhcp[1811]: DHCPREPLY(br-lan)
fdc0:a828::XXXX DUID HOSTNAME -Sun Oct 18 00:35:07 2015
daemon.info dnsmasq-dhcp[1811]: DHCPREPLY(br-lan)
2001:470:YYYY:YYYY::XXXX DUID HOSTNAME -No dhcpv6 lease file
entry
(Note: It appears when Windows drops/looses a connection for
more than a second-ish, it will always SOLICIT and get entered
into the lease file.)
ERIC
_______________________________________________ Dnsmasq-discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss