RFC 4704 DHCPv6 FQDN Option 39

[Maverick]

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

[David W. Hankins]

Post by Maverick
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

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.

Post by Maverick
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.

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.

Post by Maverick
It would be great if anyone can help in understanding reasoning behind this
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.

Post by Maverick
Also, I am sceptical about DNS compatibility if we follow
different formats in case of DHCPv4 and DHCPv6. Any thoughts?

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.

[Govind Saoji]

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 ofa DHCPv6 client. The data in the Domain Name field MUST be encodedas 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 insection 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 thatnumber of octets. Since every domain name ends with the null label ofthe root, a domain name is terminated by a length byte of zero. Thehigh order two bits of every length octet must be zero, and theremaining six bits of the length field limit the label to 63 octets orless.

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? ThanksGS



Windows Live Spaces : Help your online world come to life, add 500 photos a month. Try it!
_________________________________________________________________
Video: Get a glimpse of the latest in Cricket, Bollywood, News and Fashion. Only on MSN videos.
http://video.msn.com/?mkt=en-in

[Ted Lemon]

Post by Maverick
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?

The spec is as written, so unless it's really badly broken, you're
stuck with it. And I don't think it's broken at all, actually.

DNS wire format is the correct format for domain names encapsulated in
DHCP messages because there is no possibility of information loss.
Presentation format (a text string) is appropriate for displaying
domain names for humans to read. However, the translation between
DNS presentation format and wire format is beyond the scope of the DHC
working group to specify, so it's really better for us to just specify
the wire format, which is documented in an RFC to which we can refer.

In practice, translating between wire-format and presentation format
is about 50 lines of code, so there's really no significant space or
time overhead.

Also, please bear in mind the line that you did *not* quote from
RFC3315, which says that label compression is not permitted. This
substantially simplifies translating to DNS wire format; if you were
to fail to notice this restriction, I could see where you might
consider implementing the wire format conversion to be too much.