Option 61 (Client ID) in DHCPOFFER

Dima Fadeyev dima at scancom.es
Mon Nov 28 14:54:46 UTC 2011


Ok, I guess this is what I should had comunicated to the manufacturer 
right from the start. Laurent, thanks a lot for your answers and time.

Best regards,
-- 
Dima Fadeyev

> Hello,
>
>  As it is mentioned in the draft from the link you gave, RFC2131 
> states that client identifier *MUST NOT* be returned by dhcp server, 
> so here is the answer to your question.
>
>  I don't think the behavior proposed from this draft (that cid *MUST* 
> be included) has already been implemented in ISC DHCP (draft dated 
> 16/08/2011).
>
> regards,
> laurent
>
> 2011/11/25 Dima Fadeyev <dima at scancom.es <mailto:dima at scancom.es>>
>
>
>>     Tested and I have same result (even asking the client to claim it).
>>
>>     I think, from my knowledge, that cid (opt 61) is only valuable
>>     for dhcp server (why the client asks the server for things it
>>     already knows). Do you have specials needs for doing this ?
>     I'm testing the GPON OLT/ONTs from one asian manufacturer. The
>     manufacturer is saying that the ONT (CPE equipment) monitors the
>     61 option in dhcpoffers to tell if the dhcpoffer is destinated to
>     this particular ont or to some other device.
>
>     In other words, the ONT would send a dhcpdiscover with a unique
>     option 61 and monitor for a dhcpoffer which would have the same
>     value set in this option. Once such a dhcpoffer is seen, the ONT
>     would accept the IP and other relevant data set in dhcpoffer.
>
>     The manufacturer have given me this reference
>     http://tools.ietf.org/html/draft-ietf-dhc-client-id-01
>     saying that in part three it is stated that the client identifier
>     must be included in dhcpoffer if it is included in dhcpdiscover by
>     client. They've also given me the name of dhcp server they are
>     using (and which is inserting the option 61 in dhcpdiscover): N2X
>     (Agilent Test Machine), which I've never heard of before.
>
>>
>>     One possible way could be to send back value via a private option
>>     (range 224-254) :
>>
>>     option cid-sent-back code 224 = string;
>>     option cid-sent-back = option dhcp-client-identifier;
>>     option dhcp-parameter-request-list 1,3,6,12,15,26,28,42,224;
>>
>>     regards,
>>     laurent
>>
>>
>>     2011/11/24 Dima Fadeyev <dima at scancom.es <mailto:dima at scancom.es>>
>>
>>         Thanks for your reply,
>>
>>         I've included this line into my dhcpd.conf:
>>         option dhcp-parameter-request-list 1,3,6,12,15,26,28,42,61;
>>
>>         As you can see, option 61 is included. However I still can't
>>         make dhcp server include the option 61 into dhcpoffer. This
>>         is how my dhcpdiscover and dhcpoffer packets look like right now:
>>
>>         On 11/23/2011 08:21 PM, Laurent PROUFF wrote:
>>           TIME: 16:00:11.283846
>>             IP: > (00:d0:cb:cf:d0:ab) >  (Broadcast)
>>             OP: 1 (BOOTPREQUEST)
>>          HTYPE: 1 (Ethernet)
>>           HLEN: 6
>>           HOPS: 0
>>            XID: 64217936
>>           SECS: 0
>>          FLAGS: 0
>>         CIADDR: 0.0.0.0
>>         YIADDR: 0.0.0.0
>>         SIADDR: 0.0.0.0
>>         GIADDR: 0.0.0.0
>>         CHADDR: 00:d0:cb:cf:d0:ab:00:00:00:00:00:00:00:00:00:00
>>          SNAME: .
>>          FNAME: .
>>         OPTION:  53 (  1) DHCP message type         1 (DHCPDISCOVER)
>>         OPTION:  61 (  7) Client-identifier         01:00:d0:cb:cf:d0:ab
>>         OPTION:  60 ( 11) Vendor class identifier   udhcp 1.9.2
>>         OPTION:  57 (  2) Maximum DHCP message size 576
>>         OPTION:  55 (  8) Parameter Request List      1 (Subnet mask)
>>                                                       3 (Routers)
>>                                                       6 (DNS server)
>>                                                      12 (Host name)
>>                                                      15 (Domainname)
>>                                                      26 (Interface MTU)
>>                                                      28 (Broadcast
>>         address)
>>                                                      42 (NTP servers)
>>
>>         ---------------------------------------------------------------------------
>>           TIME: 16:00:11.284036
>>             IP: > (00:22:4d:38:37:27) >  (00:d0:cb:cf:d0:ab)
>>             OP: 2 (BOOTPREPLY)
>>          HTYPE: 1 (Ethernet)
>>           HLEN: 6
>>           HOPS: 0
>>            XID: 64217936
>>           SECS: 0
>>          FLAGS: 0
>>         CIADDR: 0.0.0.0
>>         YIADDR: 10.0.0.154
>>         SIADDR: 0.0.0.0
>>         GIADDR: 0.0.0.0
>>         CHADDR: 00:d0:cb:cf:d0:ab:00:00:00:00:00:00:00:00:00:00
>>          SNAME: .
>>          FNAME: .
>>         OPTION:  53 (  1) DHCP message type         2 (DHCPOFFER)
>>         OPTION:  54 (  4) Server identifier         10.0.0.32
>>         OPTION:  51 (  4) IP address leasetime      340600 (3d22h36m40s)
>>         OPTION:   1 (  4) Subnet mask               255.255.255.0
>>         OPTION:   3 (  4) Routers                   10.0.0.2
>>         OPTION:   6 (  8) DNS server                10.0.0.2,8.8.8.8
>>         OPTION:  12 (  7) Host name                 foobar2
>>         OPTION:  15 ( 11) Domainname example.com <http://example.com>
>>         OPTION:  26 (  2) Interface MTU             1500
>>         OPTION:  28 (  4) Broadcast address         10.0.0.255
>>         OPTION:  42 (  4) NTP servers               10.0.0.32
>>
>>         Best regards,
>>         Dima Fadeyev
>>
>>>         hello,
>>>
>>>          maybe it can help.... (from man dhcp-options)
>>>
>>>         *option dhcp-parameter-request-list* /uint16/ [*,*
>>>         /uint16/... ]*;*
>>>         This option, when sent by the client, specifies which
>>>         options the client wishes the server to return. Normally, in
>>>         the ISC DHCP client, this is done using the
>>>         /request/ statement. If this option is not specified by the
>>>         client, the DHCP server will normally return every option
>>>         that is valid in scope and that fits into the reply. When
>>>         this option is specified on the server, the server returns
>>>         the specified options. This can be used to force a client to
>>>         take options that it hasn't requested, and it can also be
>>>         used to tailor the response of the DHCP server for clients
>>>         that may need a more limited set of options than those the
>>>         server would normally return.
>>>
>>>         regards,
>>>         laurent
>>>
>>>         2011/11/23 Dima Fadeyev <dima at scancom.es
>>>         <mailto:dima at scancom.es>>
>>>
>>>             Hello everyone,
>>>
>>>             I have a quick question. Is it possible to make ISC
>>>             dhcpd server insert the option 61 (client id) in
>>>             DHCPOFFER, in case if it is present in DHCPDISCOVER?
>>>             The ISC dhcpd version we are using is dhcp-4.1.1
>>>             (dhcp-4.1.1-12.P1.el6_0.4.x86_64 CentOS rpm).
>>>
>>>             Thanks in advance
>>>
>>>             -- 
>>>             Dima Fadeyev
>>>
>>>             _______________________________________________
>>>             dhcp-users mailing list
>>>             dhcp-users at lists.isc.org <mailto:dhcp-users at lists.isc.org>
>>>             https://lists.isc.org/mailman/listinfo/dhcp-users
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         dhcp-users mailing list
>>>         dhcp-users at lists.isc.org  <mailto:dhcp-users at lists.isc.org>
>>>         https://lists.isc.org/mailman/listinfo/dhcp-users
>>
>>
>>         _______________________________________________
>>         dhcp-users mailing list
>>         dhcp-users at lists.isc.org <mailto:dhcp-users at lists.isc.org>
>>         https://lists.isc.org/mailman/listinfo/dhcp-users
>>
>>
>>
>>
>>     _______________________________________________
>>     dhcp-users mailing list
>>     dhcp-users at lists.isc.org  <mailto:dhcp-users at lists.isc.org>
>>     https://lists.isc.org/mailman/listinfo/dhcp-users
>
>
>     -- 
>     Dima Fadeyev
>     Departamento de Ingeniería de Scancom S.L.
>
>
>     _______________________________________________
>     dhcp-users mailing list
>     dhcp-users at lists.isc.org <mailto:dhcp-users at lists.isc.org>
>     https://lists.isc.org/mailman/listinfo/dhcp-users
>
>
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users


-- 
Dima Fadeyev
Departamento de Ingeniería de Scancom S.L.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20111128/d51f4c5e/attachment.html>


More information about the dhcp-users mailing list