Content-Type: text/plain; charset="utf-8" Date: Wed, 23 Jan 2019 17:52:36 +0000 MIME-Version: 1.0 To: dhcp-public@isc.org From: cathya@isc.org Message-ID: Subject: DHCPv6 option aftr-name is not coded correctly when delivered to a client X-Mailer: MIME-tools 5.508 (Entity 5.508) X-RT-Interface: Web Content-Disposition: inline Content-Transfer-Encoding: binary X-RT-Original-Encoding: utf-8 Content-Length: 1695 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.