| Date: | Wed, 23 Jan 2019 17:52:36 +0000 |
| To: | dhcp-public@isc.org |
| From: | cathya@isc.org |
| Subject: | DHCPv6 option aftr-name is not coded correctly when delivered to a client |
An issue has been encountered when setting the DHCPv6 option 'aftr-name'
Within dhcpd.conf, it is set as :
option dhcp6.aftr-name aftr.example.com;
RFC 6334 does state:
The tunnel-endpoint-name field is formatted as required in DHCPv6
[RFC3315] Section 8 ("Representation and Use of Domain Names").
Briefly, the format described is using a single octet noting the
length of one DNS label (limited to at most 63 octets), followed by
the label contents. This repeats until all labels in the FQDN are
exhausted, including a terminating zero-length label.
Which implies that this should be encoded as follows:
+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+
| 0x04 | a | f | t | r | 0x07 | e | x | a | m | p | l | e | 0x03 | c | o | m | 0x00 |
+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+
However, within a packet capture (see linked customer support ticket for details), it is encoded as follows:
+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+
| a | f | t | r | . | e | x | a | m | p | l | e | . | c | o | m |
+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+
Wireshark even tags this as being a "Malformed DNS name record"
This looks to be a bug in the implementation of this option within the DHCP service - and the client receiving the option appears to be unable to make use of it.