<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>Many thanks to those who responded to help me with this. Initially, I resolved this by modifying a user-supplied patch to remove this option from sent packets.</p>
<p><br>
</p>
<p>Today, I found the "proper" solution in the 1.2.0 documentation. This is tested and working.</p>
<p><br>
</p>
<p></p>
<div class="titlepage">
<h3 class="title">8.2.17. Echoing Client-ID (RFC 6842)</h3>
</div>
<p>The original DHCPv4 specification (<a class="ulink" href="http://tools.ietf.org/html/rfc2131" target="_top">RFC 2131</a>) states that the DHCPv4 server must not send back client-id options when responding to clients. However, in some cases that confused
clients that did not have MAC address or client-id; see <a class="ulink" href="http://tools.ietf.org/html/rfc6842" target="_top">
RFC 6842</a>. for details. That behavior has changed with the publication of <a class="ulink" href="http://tools.ietf.org/html/rfc6842" target="_top">
RFC 6842</a> which updated <a class="ulink" href="http://tools.ietf.org/html/rfc2131" target="_top">
RFC 2131</a>. That update states that the server must send client-id if the client sent it. That is Kea's default behavior. However, in some cases older devices that do not support
<a class="ulink" href="http://tools.ietf.org/html/rfc6842" target="_top">RFC 6842</a>. may refuse to accept responses that include the client-id option. To enable backward compatibility, an optional configuration parameter has been introduced. To configure
it, use the following configuration statement:</p>
<pre class="screen">"Dhcp4": {
<strong class="userinput">"echo-client-id": false</strong>,
...
}
</pre>
<br>
<p></p>
<p><br>
</p>
<div id="Signature">
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif, Helvetica, EmojiFont, 'Apple Color Emoji', 'Segoe UI Emoji', NotoColorEmoji, 'Segoe UI Symbol', 'Android Emoji', EmojiSymbols; background-color: rgb(255, 255, 255);">
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
Duane Wylie<br>
<br>
</div>
</div>
</div>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Kea-users <kea-users-bounces@lists.isc.org> on behalf of Duane Wylie <duane.wylie@eatel.com><br>
<b>Sent:</b> Wednesday, August 9, 2017 3:57 PM<br>
<b>To:</b> kea-users@lists.isc.org<br>
<b>Subject:</b> [Kea-users] Client-ID (option 61)</font>
<div> </div>
</div>
<div>
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>We're evaluating KEA (version 1.2.0) as our DHCP platform moving forward. In my testing with our Docsis/HFC network, I am not able to have a docsis modem respond to a DHCPOFFER message from KEA. I can get the same modem to respond to a similarly formatted
DHCPOFFER from ISC DHCP.</p>
<p><br>
</p>
<p>Looking at the tcpdump output from the server, the only difference that stands out is the Client-ID (option 61). While, in both cases, the docsis modem does supply the Client-ID in the DHCPDISCOVER packet, the KEA server DOES include the Client-ID in the
resulting DHCPOFFER where the ISC DHCP server DOES NOT include the Client-ID in it's DHCPOFFER.</p>
<p><br>
</p>
<p><span style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,'Apple Color Emoji','Segoe UI Emoji',NotoColorEmoji,'Segoe UI Symbol','Android Emoji',EmojiSymbols; font-size:16px">(Interesting note: RFC </span><span style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,'Apple Color Emoji','Segoe UI Emoji',NotoColorEmoji,'Segoe UI Symbol','Android Emoji',EmojiSymbols; font-size:16px">2131
(Draft Standard) states</span><span style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,'Apple Color Emoji','Segoe UI Emoji',NotoColorEmoji,'Segoe UI Symbol','Android Emoji',EmojiSymbols; font-size:16px"> that the server "MUST NOT" include
the Client-ID in the DHCPOFFER. At the same time, RFC </span><span style="font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,'Apple Color Emoji','Segoe UI Emoji',NotoColorEmoji,'Segoe UI Symbol','Android Emoji',EmojiSymbols; font-size:16px">6842
(Proposed Standard) indicates the server MUST include the Client-ID IF the client provided it in the DHCPDISCOVER.)</span><br>
</p>
<p><br>
</p>
<p>I need to determine why the KEA offer is not 'working'. Admittedly, I do not know for certain that the Client-ID is the root of my problem. I think the next step is to somehow prove that success or failure does indeed hinge on the inclusion of the Client-ID
field in the DHCPOFFER. I'm at somewhat of an impasse, as I cannot figure out how to tell KEA to NOT include the option. (At the same time, I cannot figure out how to tell ISC DHCP to include the option - though this is off topic for the Kea-users list.)</p>
<p><br>
</p>
<p>Does anyone have any insight into a configuration option to disable option 61? Is there a generic way to disable a certain option via the kea.conf file? Or, where in the code can I 'flip the switch' the turn option 61 off on an offer?</p>
<p><br>
</p>
<p><br>
</p>
<p>Thanks in advance,</p>
<p>Duane</p>
<p><br>
</p>
</div>
</div>
</div>
</div>
</body>
</html>