[dhcwg] How to encode DNS labels in DHCP options

Thomas Narten <narten@raleigh.ibm.com> Tue, 04 September 2001 20:30 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26984; Tue, 4 Sep 2001 16:30:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06583; Tue, 4 Sep 2001 16:27:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06551 for <dhcwg@ns.ietf.org>; Tue, 4 Sep 2001 16:27:37 -0400 (EDT)
Received: from extmail01m.raleigh.ibm.com (extmail01.raleigh.ibm.com [204.146.167.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26880 for <dhcwg@ietf.org>; Tue, 4 Sep 2001 16:26:11 -0400 (EDT)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [192.168.1.107]) by extmail01m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id QAA19022 for <dhcwg@ietf.org>; Tue, 4 Sep 2001 16:27:07 -0400
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id QAA33934 for <dhcwg@ietf.org>; Tue, 4 Sep 2001 16:27:06 -0400
Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA30257 for <dhcwg@ietf.org>; Tue, 4 Sep 2001 16:21:14 -0400
Message-Id: <200109042021.QAA30257@rotala.raleigh.ibm.com>
To: dhcwg@ietf.org
In-Reply-To: Message of "Mon, 27 Aug 2001 21:12:05 EDT." <200108280112.f7S1C6T00354@grosse.bisbee.fugue.com>
Date: Tue, 04 Sep 2001 16:21:13 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Subject: [dhcwg] How to encode DNS labels in DHCP options
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

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 <narten@rotala.raleigh.ibm.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Allison Mankin <mankin@ISI.EDU>DU>,
    "Ralph E. Droms" <droms@bucknell.edu>
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
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg