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
- RE: [dhcwg] How to encode DNS labels in DHCP opti… Bernie Volz (EUD)
- Re: [dhcwg] How to encode DNS labels in DHCP opti… Mark Stapp
- Re: [dhcwg] How to encode DNS labels in DHCP opti… Ted Lemon
- Re: [dhcwg] How to encode DNS labels in DHCP opti… Thomas Narten
- RE: [dhcwg] How to encode DNS labels in DHCP opti… Bernie Volz (EUD)
- Re: [dhcwg] How to encode DNS labels in DHCP opti… Thomas Narten
- Re: [dhcwg] How to encode DNS labels in DHCP opti… Bud Millwood
- Re: [dhcwg] How to encode DNS labels in DHCP opti… Josh Littlefield
- Re: [dhcwg] How to encode DNS labels in DHCP opti… Ted Lemon
- Re: [dhcwg] How to encode DNS labels in DHCP opti… unixos
- Re: [dhcwg] How to encode DNS labels in DHCP opti… Henning G. Schulzrinne
- Re: [dhcwg] How to encode DNS labels in DHCP opti… Ted Lemon
- Re: [dhcwg] Incorporation of WG last call comment… Ted Lemon
- Re: [dhcwg] draft-ietf-dhc-csr-05.txt Ted Lemon
- Re: [dhcwg] IPR disclosure and <draft-ietf-dhc-su… Naiming Shen
- Re: [dhcwg] IPR disclosure and <draft-ietf-dhc-su… Ted Lemon
- Re: [dhcwg] IPR disclosure and <draft-ietf-dhc-su… Bud Millwood