<html>

<head>

<style><!--

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

font-size: 12pt;

font-family:Calibri

}

--></style></head>

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

>><i> In using the latest OpenWRT 15.05 (C.C.) with DNSMASQ 2.73 is

</i>>><i> logging DHCP (v6) CONFIRM events with host names but not

</i>>><i> re-entering them into the lease file. (note, I also saw this late

</i>>><i> in 14.07 (B.B.) with DNSMASQ for that release so its not new.)

</i>>><i> 

</i>>><i> A way to catch this behavior is use (client) a Debian flavor with 

</i>>><i> Network-Manager driving the connections. The sever again OpenWRT

>> with ODHCP removed and just DNSMASQ for all DNS/DHCP services 4/6.

</i>>><i> Upon its initial connection the client will make a DHCP (v6)

</i>>><i> 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.

</i>>><i> Upon reconnecting, the client will issue a DHCP CONFIRM: "just

</i>>><i> checking this is still mine," DNSMASQ logs the event in syslog, the

</i>>><i> host name is in syslog, but the host name is not in the lease

</i>>><i> file.

</i>>><i> 

</i>>><i> The lease file information appears to be used by DNSMASQ

</i>>><i> internally to prevent hashing into the same address for two

</i>>><i> clients. While unlikely with the advisable DHCP "constructor" of

</i>>><i> ::1000-::FFFF, this could result in conflicts if DNSMASQ receives

</i>>><i> multiple SIGUP's from other processes and no lease is found to

</i>>><i> prevent conflict. The lease files can also be used in third party

</i>>><i> scripts to establish host identification and provide access to

</i>>><i> semi-controlled resources. Such as, hotel or restaurant Internet

</i>>><i> using an authorized "receipt code" check with an on-router

>> intercept website for gating to the world.

</i>>><i> 

</i>>><i> -Reboot Router -Sun Oct 18 00:35:07 2015 daemon.info 

</i>>><i> dnsmasq-dhcp[1811]: DHCPCONFIRM(br-lan) DUID -Sun Oct 18 00:35:07 

</i>>><i> 2015 daemon.info dnsmasq-dhcp[1811]: DHCPREPLY(br-lan) 

</i>>><i> fdc0:a828::XXXX DUID HOSTNAME -Sun Oct 18 00:35:07 2015

</i>>><i> daemon.info dnsmasq-dhcp[1811]: DHCPREPLY(br-lan)

</i>>><i> 2001:470:YYYY:YYYY::XXXX DUID HOSTNAME -No dhcpv6 lease file entry

</i>>><i> 

</i>>><i> (Note: It appears when Windows drops/looses a connection for more 

</i>>><i> than a second-ish, it will always SOLICIT and get entered into the 

</i>>><i> lease file.)

</i>>><i> 

</i>>><i> 

</i>><i>> ERIC</i></pre>                                    </div></body>

</html>