Subject: [dhcwg] DHCPv6: Domain Name in Option 39

From: Govind Saoji <[email-masked]>
Date: Wed, 26 Mar 2008 18:50:42 +0530

Hi,
 
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,

So that domain names may be encoded uniformly, a domain name or alist 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.
 
Thanks
GS
 
_________________________________________________________________
Education: Are exams worrying you all the day long? Write to MSN education experts for help.
http://education.in.msn.com/

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

---

From: "H. Peter Anvin" <[email-masked]>
Date: Sat, 12 Apr 2008 14:43:17 -0700

Govind Saoji wrote:
> 
> 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 seems that not making it a MUST clause is insane -- how is the client 
going to know how to parse the reply if it is not a MUST clause??

IMO, the actual implementation really doesn't matter much -- these kind 
of conversions are so simple to do (having written one in assembly, 
myself.)  However, not having an unambiguous encoding format is beyond 
insane -- which one it happens to be is really much less important.

	-hpa