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

[Simon Kelley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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.


On 22/10/15 02:57, Eric Luehrsen wrote:
> 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
> 
>> 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.
>> 
>> On 18/10/15 06:09, Eric Luehrsen wrote:
>>> 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
>>> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJWKV4XAAoJEBXN2mrhkTWiag0P/1M6GpysTYuYXD7Ua8nVaKPm
vpJr1rLa3SAmbABsVjIOEqzpXlWhfbBxlYmSn8454bG/3VchOY0MzuRQWeA56BwD
y8PMxZC1V3W3ZKEnA4nLUg4OpZE/kXy6oAeNnCwaMriTHqKGP8cxPAQp+P8KiNYO
MFDgkVNcG8BrNMNBlPuoNFaLuJR3uH89U8+/HpHZrV1DRIsuKXdEAEnUxdi2jv9/
FWgyOh87pXCCsgZaG+8g8Pmkt1MEb14AEQANWQaRhPrFhZhDLWSQp7bNSzI7NVT4
yOiL2JDF3DDQyQBpvy+yGMEZ6Jtx4qa4PrCsbNyshsu8BcLCqtunf58FeZnGCYYr
8f3vsUMFARrRTZS8rAumD6KqKYkTHs0IeFuHe/dSZxhGRvNWMOAG3sqrGYgYd+fx
GqSmpAPB+zVGfzEBZxUpdjUShK+acKdHn4ESoNBmr/ASiG01gji3i+Mnk6OCB3yE
UNCK89grbBKSuurfuskR0TWAj05oPqk6Ilr+DmcpB6ja/DKe0n8rD7tADYQfPxEg
xHa83MxBWkz/CF/3lNtj2CSu0LPLWDPCnJzqdcCvVs4mu/i66os3y7VteF8fdmUW
aqP9VXHqqQUHrMJgCtPE++XHW6200rfZ9qBK/ILYVjaxXiTKORXBUQQfb4vce+Yb
Fub/cqQyGrnxPY5fY1tI
=X5Mo
-----END PGP SIGNATURE-----