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@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
