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

Mark Stapp <mjs@cisco.com> Tue, 04 September 2001 21: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 RAA28574; Tue, 4 Sep 2001 17:30:57 -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 RAA08727; Tue, 4 Sep 2001 17:27:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08702 for <dhcwg@ns.ietf.org>; Tue, 4 Sep 2001 17:27:50 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28477 for <dhcwg@ietf.org>; Tue, 4 Sep 2001 17:26:24 -0400 (EDT)
Received: from mjs-nt.cisco.com ([172.27.181.73]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA18037; Tue, 4 Sep 2001 17:27:19 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010904170432.02ac0330@funnel.cisco.com>
X-Sender: mjs@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 04 Sep 2001 17:27:19 -0400
To: Thomas Narten <narten@raleigh.ibm.com>
From: Mark Stapp <mjs@cisco.com>
Subject: Re: [dhcwg] How to encode DNS labels in DHCP options
Cc: dhcwg@ietf.org
In-Reply-To: <200109042021.QAA30257@rotala.raleigh.ibm.com>
References: <Message of "Mon, 27 Aug 2001 21:12:05 EDT." <200108280112.f7S1C6T00354@grosse.bisbee.fugue.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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

Thomas,

I think it's clear to us that we should specify DNS encoding for domain 
names carried in DHCP options.

As Bernie noted, there's a historical problem in this case that makes it 
unusually painful to remove text about the ASCII behavior entirely. We 
don't want new clients to implement the deprecated behavior, but we need to 
describe it for the benefit of new server implementations which will 
encounter old clients for a long time to come. The draft has evolved to try 
to accomodate the situation, but I can understand that it hasn't cleared up 
the confusion.

I've tried to revise a couple of sections in the document to make this 
situation and its roots clearer. Client implementations are directed to use 
the dns-encoding. Server implementors are advised of the deprecated client 
behavior, which is described in a new section alongside the specification 
of the Domain Name field.

This is the revised text from section 4.1, describing the use of the "E" flag:

    The data in the Domain Name field SHOULD appear in DNS-style binary
    encoding (without compression, of course), as described in
    RFC1035[3]. A client which sends the FQDN option SHOULD use this
    encoding. The client MUST set the "E" bit when the data in the
    Domain Name field is in DNS binary encoding. 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, and
    MUST set the "E" bit accordingly.

    Server implementors should note that earlier draft versions of this
    specification permitted an ASCII encoding of the domain name.
    Clients which implemented this encoding were deployed before this
    specification was completed. Server implementors which need to
    support these clients should note the section on the deprecated
    ASCII encoding (Section 4.3.1).

And this is the revised text from section 4.3, describing the Domain Name 
field:


4.3 The Domain Name Field

    The Domain Name part of the option carries all or part of the FQDN
    of a DHCP client. The data in the Domain Name field SHOULD appear in
    uncompressed DNS encoding as specified in RFC1035[3]. If the DHCP
    client uses DNS encoding, it MUST set the third bit in the Flags
    field (the "E" bit). A client may be configured with a
    fully-qualified domain name, or with a partial name that is not
    fully-qualified. If a client knows only part of its name, it MAY
    send a name that is not fully-qualified, indicating that it knows
    part of the name but does not necessarily know the zone in which the
    name is to be embedded.

    A client which wants to convey part of its FQDN sends a non-terminal
    sequence of labels in the Domain Name part of the option. Clients
    and servers should assume that the the name field contains a
    fully-qualified name unless this partial-name format exists.

4.3.1 Deprecated ASCII Encoding

    The DNS encoding specified above MUST be supported by DHCP servers.
    However, a substantial population of clients implemented an earlier
    version of this specification, which permitted an ASCII encoding of
    the Domain Name field. Server implementations should be aware that
    clients which send the FQDN option with the "E" bit clear are using
    an ASCII version of the Domain Name field. Servers MAY be prepared
    to return an ASCII encoded version of the Domain Name field to such
    clients. The use of ASCII encoding in this option should be
    considered deprecated.

    A DHCP client which used ASCII encoding was permitted to suggest a
    single label if it was not configured with a fully-qualified name.
    Such clients send a single label as a series of ASCII characters in
    the Domain Name field, excluding the "." (dot) character. Such
    clients SHOULD follow the character-set recommendations of
    RFC1034[2] and RFC1035[3].

Does this help? Is this too much change, or the right amount? Is there 
anything that's still unclear after these changes?

-- Mark

At 04:21 PM 9/4/01 -0400, Thomas Narten wrote:
>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>,
>     "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


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg