Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. DHCPv4 vendor-encapsulated-options (43) option (Francis Dupont)
2. DHCPv4 vendor-encapsulated-options (43) option (problem)
(Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Thu, 14 Sep 2017 14:44:19 +0000
From: Francis Dupont <[email protected]>
To: [email protected]
Subject: [kea-dev] DHCPv4 vendor-encapsulated-options (43) option
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Currently the way Kea handles the DHCPv4 vendor-encapsulated-options
(43) option is incorrect. The ticket #5073 was created to fix this
but I was not happy with my proposed fix so I created a second ticket
#5290 to design a better solution.
The next two messages will explain what is the problem (1) and what is
the current state of the solution design (2). Note the real issue is
not to fix this but to fix in a way flexible enough for users and
without major changes in Kea option definition code...
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 2
Date: Thu, 14 Sep 2017 14:54:29 +0000
From: Francis Dupont <[email protected]>
To: [email protected]
Subject: [kea-dev] DHCPv4 vendor-encapsulated-options (43) option
(problem)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Currently the option is defined as empty with encapsulated space
set to vendor-encapsulated-options-space.
Even it is not very sexy it works in at least 90% of cases but
the specs (RFC 2132) say:
If a vendor potentially encodes more than one item of information in
this option, then the vendor SHOULD encode the option using
"Encapsulated vendor-specific options" as described below:
so with one encoded item the option is not filled by suboptions
but with a raw value, i.e., the correct definition is binary
(or no definition at all as it is the default).
It can raise a bug during decoding (unpack) and drop correct but
wrongly unparsable received messages. This is why #5073 was created
for Kea 1.2.
Regards
Francis Dupont <[email protected]>
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 42, Issue 1
**************************************
