RE: [dhcwg] How to encode DNS labels in DHCP options

["Bernie Volz (EUD)" <[e-mail]>]

Thomas:

The problem is that the FQDN option is already in such wide deployment with
the ASCII encoding that it would be impossible to ask that everyone change
to using the new. This ID just took too long and people went ahead and
implement it (especially since the option id was already assigned). So, the
solution is to document this behavoir and find a way to support the new
proper behavoir in a backward compatible way. And then also to indicate that
this old method should not be used.

Note that I think it should be "SHOULD be consider deprecated."

So, I think the wording in the document is correct and should basically stay
that way. Perhaps the historical perspective needs to be added?

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:[e-mail]]
Sent: Tuesday, September 04, 2001 4:21 PM
To: [e-mail]
Subject: [dhcwg] How to encode DNS labels in DHCP options


The document draft-ietf-dhc-fqdn-option-02.txt is apparently in
WGLC. I note that this document uses the following encoding to encode
the DNS name:

   The data in the Domain Name field may appear in one of two formats:
   ASCII, or DNS-style binary encoding (without compression, of
   course), as described in RFC1035[3]. A client which sends the FQDN
   option MUST set the "E" bit to indicate that the data in the Domain
   Name field is DNS binary encoded. If a server receives an FQDN
   option from a client, and intends to include an FQDN option in its
   reply, it MUST use the same encoding that the client used. The DNS
   encoding is recommended. The use of ASCII-encoded domain-names is
   fragile, and the use of ASCII encoding in this option should be
   considered deprecated.

What does it mean for ascii to be deprecated, when the previous text
says it MUST be supported. Is this trying to document some behavior
(from an earlier ID) that has been implemented and deployed? (If so,
it might be good to actually come out and say that).

Or, given that this is an ID, not an update to an existing RFC, seems
like if you don't want to allow ascii, the document should simply not
support it at all. What is the document really telling implementors
regarding what they should implement?

As a comparison point, draft-aboba-dhc-domsearch-06.txt doesn't allow
ascii, it just uses the on-the-wire binary encoding.

Finally, I'll note that I recently took the message back to the author
of draft-ietf-sip-dhcp-04.txt that said they shouldn't be using ascii
(see appended note). Was that in error?

I'd like to see some clarification on this seeming inconsistancy. What
is the WG's position with regards to the how DHCP options should be
encoding DNS labels?

Thomas

From: Thomas Narten <[e-mail]>
To: Henning Schulzrinne <[e-mail]>
cc: Allison Mankin <[e-mail]>,
    "Ralph E. Droms" <[e-mail]>
Date: Mon, 27 Aug 2001 11:49:39 -0400
Subject: draft-ietf-sip-dhcp-04.txt

Hi Henning.

I'd like to restart discussion on the sip-dhcp document. The meeting
minutes from Minneapolis include:

> This is from the minutes of the DHC WG meeting in Minnesota.
> 
>    DHCP Option for SIP Servers                Henning Schulzrinne, 20 minutes
>    http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-dhcp-04.txt
> 
>    The WG finds this option acceptable in principle; however, the
>    specific format and encoding of data in the option is still an issue.
>    Authors want simple ASCII text encoding of DNS name or dotted decimal
>    IP address; WG recommends RFC1035 encoding for DNS name and binary
>    encoding of IP address with flag to indicate which encoding is in use.
>    WG has selected RFC1035 for other recent options.

The last two sentences are the ones that are key.

draft-ietf-sip-dhcp-04.txt currently says:


   The SIP server DHCP option carries a DNS (RFC 1035 [6]) fully-
   qualified domain name to be used by the SIP client to locate a SIP
   server. The FQDN is 16-bit Unicode text encoded into an octet stream
   using UTF-8 (RFC 2044 [7]). The FQDN in the SIP server option MUST
   NOT be null-terminated. It MUST NOT end with a period.

and then later:

   It is possible, but NOT RECOMMENDED that the string is the textual
   representation of a network address, e.g., a "dotted quad" for IPv4
   and the hexadecimal representation of RFC 2373 [8].  Implementations
   MUST detect this case by checking whether all characters are decimal
   digits or periods.

This is, of course, in contrast to what the DHC WG is recommending.

Are there any issues with just going along with the DHC WG
recommendation? 

Thomas


_______________________________________________
dhcwg mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/dhcwg