draft-ietf-sip-dhcp-05.txt   draft-ietf-sip-dhcp-06.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft H.Schulzrinne Internet Draft H.Schulzrinne
draft-ietf-sip-dhcp-05.txt Columbia University Columbia University
November 21, 2001 draft-ietf-sip-dhcp-06.txt
Expires: May 2002 March 1, 2002
Expires: August 2002
DHCP Option for SIP Servers DHCPv4 Option for SIP Servers
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 35
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines a DHCP option that contains a single name or This document defines a DHCP-for-IPv4 option that contains a list of
IPv4 address that can be mapped to one or more SIP outbound proxy domain names or IPv4 addresses that can be mapped to one or more SIP
servers. This is one of the many methods that a SIP client can use outbound proxy servers. This is one of the many methods that a SIP
to obtain the addresses of such a local SIP server. client can use to obtain the addresses of such a local SIP server.
1 Terminology 1 Terminology
DHCP client: A DHCP [1] client is an Internet host that uses DHCP client: A DHCP [1] client is an Internet host that uses
DHCP to obtain configuration parameters such as a network DHCP to obtain configuration parameters such as a network
address. address.
DHCP server: A DHCP server is an Internet host that returns DHCP server: A DHCP server is an Internet host that returns
configuration parameters to DHCP clients. configuration parameters to DHCP clients.
skipping to change at page 2, line 31 skipping to change at page 2, line 31
The Session Initiation Protocol (SIP) [2] is an application-layer The Session Initiation Protocol (SIP) [2] is an application-layer
control protocol that can establish, modify and terminate multimedia control protocol that can establish, modify and terminate multimedia
sessions or calls. A SIP system has a number of logical components: sessions or calls. A SIP system has a number of logical components:
user agents, proxy servers, redirect servers and registrars. User user agents, proxy servers, redirect servers and registrars. User
agents MAY contain SIP clients, proxy servers always do. agents MAY contain SIP clients, proxy servers always do.
This draft specifies a DHCP option [1,5] that allows SIP clients to This draft specifies a DHCP option [1,5] that allows SIP clients to
locate a local SIP server that is to be used for all outbound SIP locate a local SIP server that is to be used for all outbound SIP
requests, a so-called outbound proxy server. (SIP clients MAY contact requests, a so-called outbound proxy server. (SIP clients MAY contact
the address identified in the SIP URL directly, without involving a the address identified in the SIP URL directly, without involving a
local SIP server. However in some circumstances, when firewalls are local SIP server. However in some circumstances, for example, when
present, SIP clients need to use a local server for outbound firewalls are present, SIP clients need to use a local server for
requests.) This is one of many possible solutions for locating the outbound requests.) This is one of many possible solutions for
outbound SIP server; manual configuration is an example of another. locating the outbound SIP server; manual configuration is an example
of another.
3 SIP Server DHCP Option 3 SIP Server DHCP Option
The SIP server DHCP option carries either a 32-bit (binary) IPv4 The SIP server DHCP option carries either a 32-bit (binary) IPv4
address or, preferably, a DNS (RFC 1035 [6]) fully-qualified domain address or, preferably, a DNS (RFC 1035 [6]) fully-qualified domain
name to be used by the SIP client to locate a SIP server. name to be used by the SIP client to locate a SIP server.
The option has two encodings, specified by the encoding byte ('enc') The option has two encodings, specified by the encoding byte ('enc')
that follows the code byte. If the encoding byte has the value 0, it that follows the code byte. If the encoding byte has the value 0, it
is followed by a list of domain names, as described below (Section is followed by a list of domain names, as described below (Section
3.1). If the encoding byte has the value 1, it is followed by one or 3.1). If the encoding byte has the value 1, it is followed by one or
more IPv4 addresses (Section 3.2). All implementations MUST support more IPv4 addresses (Section 3.2). All implementations MUST support
both encodings. The 'Len' field indicates the total number of octets both encodings. The 'Len' field indicates the total number of octets
in the option following the 'Len' field, including the encoding byte. in the option following the 'Len' field, including the encoding byte.
A DHCP server MUST NOT mix the two encodings in the same DHC message,
even if it sends two different instances of the same option. Attempts
to do so would result in incorrect client behavior as DHC processing
rules call for the concatenation of multiple instances of an option
into a single option prior to processing the option [7].
The code for this option is TBD. The code for this option is TBD.
3.1 Domain Name List 3.1 Domain Name List
If the 'enc' byte has a value of 0, the encoding byte is followed by If the 'enc' byte has a value of 0, the encoding byte is followed by
a sequence of labels, encoded according to Section 3.1 of RFC 1035 a sequence of labels, encoded according to Section 3.1 of RFC 1035
[6], quoted below: [6], quoted below:
Domain names in messages are expressed in terms of a Domain names in messages are expressed in terms of a
sequence of labels. Each label is represented as a one sequence of labels. Each label is represented as a one
octet length field followed by that number of octets. Since octet length field followed by that number of octets. Since
every domain name ends with the null label of the root, a every domain name ends with the null label of the root, a
domain name is terminated by a length byte of zero. The domain name is terminated by a length byte of zero. The
high order two bits of every length octet must be zero, and high order two bits of every length octet must be zero, and
skipping to change at page 3, line 25 skipping to change at page 3, line 33
to 63 octets or less. To simplify implementations, the to 63 octets or less. To simplify implementations, the
total length of a domain name (i.e., label octets and label total length of a domain name (i.e., label octets and label
length octets) is restricted to 255 octets or less. length octets) is restricted to 255 octets or less.
RFC 1035 encoding was chosen to accomodate future RFC 1035 encoding was chosen to accomodate future
internationalized domain name mechanisms. internationalized domain name mechanisms.
The minimum length for this encoding is 3. The minimum length for this encoding is 3.
The option MAY contain multiple domain names, but these SHOULD refer The option MAY contain multiple domain names, but these SHOULD refer
to different SRV records, rather than different A records. Domain to different NAPTR records, rather than different A records. The
names SHOULD be listed in order of preference. client MUST try the records in the order listed, applying the
mechanism described in Section 4.1 of RFC XXXX [3] for each. The
A SIP client obtains a domain name through the DHCP SIP server client only resolves the subsequent domain names if attempts to
option, which the client then uses to locate the outbound proxy contact the first one failed or yielded no common transport protocols
server by the mechanism described in RFC XXXX [3]. In summary, the between client and server or denote a domain administratively
domain name is used first in a DNS SRV lookup and, if that fails prohibited by client policy.
because of a lack of matching DNS SRV records, the domain name is
used in an address record lookup. Normative details are contained in
RFC XXXX [3].
Use of multiple domain names is not meant to replace SRV Use of multiple domain names is not meant to replace NAPTR
records, but rather to allow a single DHCP server to and SRV records, but rather to allow a single DHCP server
indicate outbound proxy servers operated by multiple to indicate outbound proxy servers operated by multiple
providers. providers.
An encoding according to section 4.1.4 of "Domain Names - Clients MUST support compression according to the encoding in Section
Implementation And Specification" [6] does not seem 4.1.4 of "Domain Names - Implementation And Specification" [6].
appropriate here, since the domain names are supposed to be
different domains, so that compression will have little Since the domain names are supposed to be different
effect. domains, compression will likely have little effect,
however.
If the length of the domain list exceeds the maximum permissible If the length of the domain list exceeds the maximum permissible
within a single option (254 octets), then the domain list must be within a single option (254 octets), then the domain list must be
represented in the DHCP message as specified in "Encoding Long DHCP represented in the DHCP message as specified in [7].
Options".
The DHCP option for this encoding has the following format: The DHCP option for this encoding has the following format:
Code Len enc DNS name of SIP server Code Len enc DNS name of SIP server
+-----+-----+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+-----+-----+--
| TBD | n | 0 | s1 | s2 | s3 | s4 | s5 | ... | TBD | n | 0 | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+-----+-----+--
As an example, consider the case where the server wants to offer two As an example, consider the case where the server wants to offer two
outbound proxy servers, "example.com" and "example.net". These would outbound proxy servers, "example.com" and "example.net". These would
skipping to change at page 4, line 28 skipping to change at page 4, line 33
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|TBD|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 | |TBD|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+
| 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+
3.2 IPv4 Address List 3.2 IPv4 Address List
This option specifies a list of IPv4 addresses indicating SIP If the 'enc' byte has a value of 1, the encoding byte is followed by
outbound proxy servers available to the client. Servers SHOULD be a list of IPv4 addresses indicating SIP outbound proxy servers
listed in order of preference. available to the client. Servers MUST be listed in order of
preference.
Its minimum length is 5, and the length MUST be a multiple of 4 plus Its minimum length is 5, and the length MUST be a multiple of 4 plus
one. The DHCP option for this encoding has the following format: one. The DHCP option for this encoding has the following format:
Code Len enc Address 1 Address 2 Code Len enc Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+-----+-----+--
| TBD | n | 1 | a1 | a2 | a3 | a4 | a1 | ... | TBD | n | 1 | a1 | a2 | a3 | a4 | a1 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+-----+-----+--
4 Security Consideration 4 Security Consideration
There are no security considerations beyond those described in RFC The ecurity considerations in RFC 2131 [1], RFC 2543 [2] and RFC XXXX
2131 [1], RFC 2543 [2] and RFC XXXX [3]. [3] apply. If an adversary manages to modify the response from a DHCP
server or insert its own response, a SIP user agent could be led to
contact a rogue SIP server, possibly one that then intercepts call
requests or denies service. A modified DHCP answer could also omit
host names that translated to TLS-based SIP servers, thus
facilitating intercept.
5 IANA Considerations 5 IANA Considerations
IANA has assigned a DHCP option number of TBD for the "SIP Servers IANA has assigned a DHCP option number of TBD for the "SIP Servers
DHCP Option" defined in this document. DHCP Option" defined in this document.
6 Acknowledgements 6 Acknowledgements
Ralph Droms, Robert Elz, Wenyu Jiang, Peter Koch, Gautam Nair, Thomas Ralph Droms, Robert Elz, Wenyu Jiang, Peter Koch, Gautam Nair, Thomas
Narten, Erik Nordmark, Jonathan Rosenberg, Kundan Singh, Sven Ubik, Narten, Erik Nordmark, Jonathan Rosenberg, Kundan Singh, Sven Ubik,
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/