On Tue, Apr 01, 2008 at 08:07:24PM +0530, Maverick 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 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. > 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. > 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. > 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. -- 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
Attachment:
pgpcPuWpCCulE.pgp
Description: PGP signature
_______________________________________________ dhcwg mailing list dhcwg at ietf.org https://www.ietf.org/mailman/listinfo/dhcwg