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

From: Thomas Narten <[email-masked]>
Date: Tue, 04 Sep 2001 16:21:13 -0400

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 <[email-masked]>
To: Henning Schulzrinne <[email-masked]>
cc: Allison Mankin <[email-masked]>,
    "Ralph E. Droms" <[email-masked]>
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
[email-masked]
http://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Mark Stapp <[email-masked]>
Date: Tue, 04 Sep 2001 17:27:19 -0400

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 04 Sep 2001 17:58:04 -0400

The idea of using the RFC1035 encoding is that it is exactly what the
DNS protocol currently specifies.   This means that if we use this
format, we don't have to worry that it will be our fault that the
encoding doesn't work.   When IDN happens, it will presumably work on
top of the existing packet format, so that means that what we have
specified should also work.

So IMHO any new DHCP option that contains a domain name should use the
RFC1035 format.   I can't remember the details with SIP, but I *think*
that what is being encoded is not a domain name, and that is the
reason for the difference.

			       _MelloN_

---

From: Thomas Narten <[email-masked]>
Date: Wed, 05 Sep 2001 13:47:28 -0400

Hi Mark.

> encounter old clients for a long time to come.

Makes sense to me.  

>     MUST set the "E" bit accordingly.

My only quibble with the above is the SHOULD. Why not a MUST?  If you
want clients that implement *this* spec to implement the binary
encoding, seems like it should be a MUST (i.e., no wiggle
room). Saying SHOULD allows them to implement the ascii flavor and be
compliant. That wouldn't seem to be the goal here.

>     part of the name but does not necessarily know the zone in which the

Might be good to say that "not fully-qualified" really means a single
label.

> anything that's still unclear after these changes?

Overall, this seems much better to me.

Thanks,
Thomas

---

From: Bud Millwood <[email-masked]>
Date: Thu, 6 Sep 2001 11:23:46 +0200

I'll admit I don't know much about the DNS binary name format, but I'm going 
to ask: why is it better to encode DNS names in binary than ASCII?

--
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 70 566 7803
fax: +46 8 758 3687
mailto:[email-masked]

---

From: Josh Littlefield <[email-masked]>
Date: Thu, 06 Sep 2001 09:56:47 -0400

> to ask: why is it better to encode DNS names in binary than ASCII?

There are no special characters (such as ".", or a null terminator) in DNS
native format, so it requires no quoting characters (which would themselves
require quoting).  It is not intended to be directly printable, so character
set issues are transparent, or will be when IDN resolves questions about
localized, non-7-bit ASCII names.  The form is simply a series of counted
label strings, so no real parsing is involved in handling the names.

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                                      250 Apollo Drive
tel: 978-244-8378  fax: same               Chelmsford, MA  01824-3627

---

From: Ted Lemon <[email-masked]>
Date: Thu, 06 Sep 2001 09:44:48 -0700

> to ask: why is it better to encode DNS names in binary than ASCII?

The short answer to this is that you shouldn't ask questions like this
on a working group mailing list - you should learn about the format.
However, in this case reading RFC1035 probably wouldn't answer your
question.   The answer is that the RFC1035 format is at least
theoretically capable of handling unicode, whereas an ASCII
representation obviously is not.

			       _MelloN_

---

From: [email-masked]
Date: Fri, 7 Sep 2001 02:33:32 +0900

Hi! It's My Comment....

----- Original Message -----
From: "Ted Lemon" <[email-masked]>
To: "Bud Millwood" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 07, 2001 1:44 AM
Subject: Re: [dhcwg] How to encode DNS labels in DHCP options

> representation obviously is not.
It is IDN WG Issue.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sat, 08 Sep 2001 12:58:59 -0400

I think in practice, this only moves the problem around. It seems
unlikely that configuration files for DHCP servers would force users to
enter RFC 1035 notation. Among other things, it is rather likely to
cause errors. (Forget to update the count byte when you change a label
and you've introduced some rather strange results.) 

Thus, I would expect that actual servers will use some higher-level
character set that can express IDN names, say, UTF-8 and then internally
translate. If that's the case, it really doesn't much matter where the
translation takes place. 

It does matter if the standard OS interfaces expect UTF-8, say, since
most applications will need this. In that case, you'll do the
translation twice. The client gets the RFC 1035 string from DHCP,
translates it into UTF-8 so that the client OS understands it and then
this gets translated again by the resolver library back into RFC 1035
for the on-the-wire format. I know of no current resolver library that
allows you to specify RFC 1035 labels as input, but I obviously haven't
done a complete survey. Can be done, but hasn't accomplished much in
terms of avoiding translation errors, since you have two translations
instead of one. One can only hope that both translation directions are
one-to-one, otherwise you could get some peculiar results.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Ted Lemon <[email-masked]>
Date: Sat, 08 Sep 2001 13:44:21 -0700

> and you've introduced some rather strange results.) 

Of course the DHCP server doesn't have to force the user to enter
protocol level information directly.  And you are right that this
moves the problem around.   It moves it to where it can be
appropriately handled - the application's user interface.

The protocol has to be *able* to encode IDN when/if IDN materializes.
We do not need to say how an application presents this to the user.
We can safely leave that to the IDN people.

			       _MelloN_