Subject: Fwd: I-D ACTION:draft-ietf-sip-dhcp-03.txt

From: Ralph Droms <[email-masked]>
Date: Tue, 23 Jan 2001 10:42:52 -0500

FYI - a new version of the "DHCP option for SIP Servers" draft has been 
published.  If you have comments, please post them to the mailing list by 
5PM EST, 1/24.

- Ralph

>To: IETF-Announce:;
>Cc: [email-masked]
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-ietf-sip-dhcp-03.txt
>Date: Tue, 23 Jan 2001 07:34:38 -0500
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Session Initiation Protocol Working Group 
>of the IETF.
>
>         Title           : DHCP Option for SIP Servers
>         Author(s)       : G. Nair, H. Schulzrinne
>         Filename        : draft-ietf-sip-dhcp-03.txt
>         Pages           : 4
>         Date            : 22-Jan-01
>
>This document defines a DHCP option that contains a single name that
>can be mapped to one or more SIP outbound proxy servers. This is one
>of the many methods that a SIP client can use to obtain the addresses
>of such a local SIP server.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcp-03.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-ietf-sip-dhcp-03.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-ietf-sip-dhcp-03.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-sip-dhcp-03.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sip-dhcp-03.txt>

---

From: Ralph Droms <[email-masked]>
Date: Tue, 23 Jan 2001 12:05:58 -0500

>3 SIP server DHCP options
>
>    The SIP client obtains a DNS [6] full-qualified domain name (FQDN)
>    via a DHCP option. This FQDN is then used by the mechanism described
>    in [3] to locate the outbound proxy server. In summary, the domain
>    name encoded in the string is used first in a DNS SRV lookup and, if
>    that fails because of a lack of matching DNS SRV records, in an
>    address record lookup. Normative details are contained in [3].

The encoding technique needs to be more explicitly defined.  Is it a string 
of 7-bit ASCII characters, is it null-terminated, is it RFC1035 
encoded?  The specifications for some earlier DHCP options have not been 
entirely explicit, which has led to interoperability problems.  Later 
options have been more carefully specified; e.g., in RFC2241:

>3. NDS Tree Name Option
>
>    This option specifies the name of the NDS tree the client will be
>    contacting. NDS tree names are 16-bit Unicode strings. For
>    transmission in the NDS Tree Name Option, an NDS tree name is
>    transformed into octets using UTF-8. The string should NOT be zero
>    terminated.

The only (standard status) options that use domain names are 15 (domain 
name) and 12 (host name).  Both of these options are carried over to DHCP 
from BOOTP (RFC1497).  Bernard Aboba's "DHCP Domain Search Option" 
<draft-aboba-dhc-domsearch-01.txt> specifies RFC1035 encoding of domain 
names.  I would recommend using RFC1035 encoding.

>    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 [7].

I would recommend against simply overloading text representation of IP 
addresses because of potential confusion.  If you really want to allow use 
of IP addresses, how about names from the  inverse DNS domains?

>4 Security Consideration
>
>    There are no security considerations beyond those described in RFC
>    2132, RFC 2543 [2] and RFC XXX [3].

The DHCP security considerations are in RFC2131.

- Ralph

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Jan 2001 13:11:30 -0800

> names.  I would recommend using RFC1035 encoding.

I'm still not sure why RFC1035, compared to UTF-8. Even with RFC1035,
you need to specify what the bytes mean, since RFC 1035 doesn't say:

  For all parts of the DNS that are part of the official protocol, all
  comparisons between character strings (e.g., labels, domain names,
etc.)
  are done in a case-insensitive manner.  At present, this rule is in
  force throughout the domain system without exception.  However, future
  additions beyond current usage may need to use the full binary octet
  capabilities in names, so attempts to store domain names in 7-bit
ASCII
  or use of special bytes to terminate labels, etc., should be avoided.

Thus, I'm not sure why 

label\Llabel\L

(where \L is the length) is any better than

label.label.

Assuming that 'label' is binary/UTF-8.

All I know is that none of the current DHCP servers will work with RFC
1035 encoding without using hex encoding, which is awful.

> of IP addresses, how about names from the  inverse DNS domains?

I'm open to suggestions, but using in-addr.arpa for this seems a bit
odd. We definitely need this, though.

> The DHCP security considerations are in RFC2131.

Fixed.