Subject: [dhcwg] RFC 4704 DHCPv6 FQDN Option 39

From: Maverick <[email-masked]>
Date: Tue, 1 Apr 2008 20:07:24 +0530

Hi,

I have query regarding how domain name is passed in FQDN option 39.

According to RFC 4704 section 4.2,

The Domain Name part of the option carries all or part of the FQDN of
a DHCPv6 client.  The data in the Domain Name field MUST be encoded
as described in Section 8 of [5].

According to RFC 3315 section 8,

Domain name or a list of domain names is encoded using the technique
described in
section 3.1 of RFC 1035 [10].

According to RFC 1035, section 3.1

Domain names in messages are expressed in terms of a sequence of labels.
Each label is represented as a one octet length field followed by that
number of octets.  Since every domain name ends with the null label of
the root, a domain name is terminated by a length byte of zero.  The
high order two bits of every length octet must be zero, and the
remaining six bits of the length field limit the label to 63 octets or
less.

Looking at above format, from implementation perspective, this adds extra
overhead on DHCPv6 client and DHCPv6 server even though they have nothing to
do with those name...other than passing to DNS. It could have been much
simpler if could have just passed Fully Qualified Domain Name in this option
as was the case with DHCPv4 protocol where sending FQDN in this format is
not MUST clause.

It would be great if anyone can help in understanding reasoning behind this
decision. Also, I am sceptical about DNS compatibility if we follow
different formats in case of DHCPv4 and DHCPv6. Any thoughts?

Thanks
-Maverick
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 1 Apr 2008 08:10:03 -0700

> do with those name...other than passing to DNS. It could have been much

It's true it is an extra step to convert a text-input FQDN into
rfc1035 format.  I doubt for most it is extra code more than one
additional function call; most clients have to consume DNS anyway,
so they already have in their libraries a function to produce it.

> as was the case with DHCPv4 protocol where sending FQDN in this format is

I think that anyone who sends the DHCPv4 FQDN option not in RFC1035
format is asking for future and present interoperability problems.  In
my opinion, the flat text version of the fqdn is documented as a
historical use (but maybe wasn't at the time of publishing), and
should be avoided.

> decision.

Flat text does not convey domain names very well.  The continued use
of flat text with some kind of escaping mechanism furthers the
"chilling effect" on non-us-ascii users of the DNS.  If every
character in a domain name were unicode, then (nearly) all characters
would have to be escaped, and the flat text format no longer looks
very attractive.  Taken to its furthest extreme, if you had a
maximally sized FQDN, 256 octets, it would take 1024 bytes of DHCP
payload space (or so) to convey it in escapes.  More than the maximum
DHCPv4 payload size.  This artificially prefers US-ASCII encodings,
and while we may or may not argue about that being a good or even
necessary thing for DNS compatibility, it doesn't seem like the sort
of policy DHC should dictate.

So the simplest way to convey an FQDN is in DNS wire format.  What is
or is not legal in DNS wire format is or is not a legal FQDN.  64
opaque octects per label, 256 opaque octets per full domain name.
If memory serves.

> Also, I am sceptical about DNS compatibility if we follow

I don't have my packet dumps in front of me, but my memory is that all
the major DHCP clients that implement the DHCPv4 FQDN option do send
the FQDN in RFC1035 wire format.

I agree that if someone were to elect to send the DHCPv4 FQDN in
flat text, they would be setting themselves up for problems, as
it would not be easy to share code between the two sides of the
protocol, and any attempts to do so could create some "leakage".

Not to mention the aforementioned "simplicity made difficult" for
anyone who is trying to obtain an unusual FQDN.  You will have to
make sure that all parties in the DHCPv4 flat-text arena implement
the same (RFC1035) escape sequences, and do not interpret odd or
unusual characters in unusual ways (finding NULLs even after they
are escaped, presuming spaces separate multiple domain names).

And not to mention that it would be an unusual implementation in the
industry, one that is unlikely to receive a great deal of testing for
compatibility.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg