draft-ietf-sip-dhcp-01.txt   draft-ietf-sip-dhcp-02.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft G.Nair, H.Schulzrinne Internet Draft G.Nair, H.Schulzrinne
draft-ietf-sip-dhcp-01.txt Columbia University draft-ietf-sip-dhcp-02.txt Columbia University
April 6, 2000 January 15, 2001
Expires: October 2000 Expires: June 2001
DHCP Option for SIP Servers DHCP 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
skipping to change at page 1, line 28 skipping to change at page 1, line 29
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
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
The list of Internet-Draft Shadow Directories can be accessed at 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 pointers to one This document defines a DHCP option that contains a pointers to one
or more SIP servers. This is one of the many methods that a SIP or more SIP outbound proxy servers. This is one of the many methods
client can use to obtain the addresses of a local oubound SIP server. that a SIP client can use to obtain the addresses of such a local SIP
server.
Table of Contents
1 Terminology ......................................... 2
2 Introduction ........................................ 2
3 Overview ............................................ 2
4 SIP server DHCP options ............................. 2
5 Security Consideration .............................. 3
6 Acknowledgements .................................... 3
7 Authors' Addresses .................................. 4
8 Bibliography ........................................ 4
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.
SIP server: As defined in RFC 2543 [2]. In the context of this SIP server: As defined in RFC 2543 [2]. This server MUST be an
document, a SIP server refers to the host the SIP server is outbound proxy server, as defined in [3]. In the context of
running on. this document, a SIP server refers to the host the SIP
server is running on.
SIP client: As defined in RFC 2543. In the context of this SIP client: As defined in RFC 2543. The client can be a user
document, a SIP client refers to the host the SIP client is agent client or the client portion of a proxy server. In
running on. the context of this document, a SIP client refers to the
host the SIP client is running on.
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and
and "OPTIONAL" are to be interpreted as described in RFC 2119 [3]. "OPTIONAL" are to be interpreted as described in RFC 2119 [4].
2 Introduction 2 Introduction
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. In particular, it is used for signaling of sessions or calls. A SIP system has a number of logical components:
Internet telephony calls. A SIP system has two components: user user agents, proxy servers, redirect servers and registrars. User
agents and servers. The user agent is the SIP end system that acts agents MAY contain SIP clients, proxy servers always do.
on behalf of someone who wants to participate in a SIP call.
This draft specifies a DHCP option [1,4] that allows SIP user agents This draft specifies a DHCP option [1,5] that allows SIP clients to
(clients) to locate a local SIP server that is to be used for all locate a local SIP server that is to be used for all outbound SIP
outbound SIP requests. (SIP clients MAY contact the address requests, a so-called outbound proxy server. (SIP clients MAY contact
identified in the SIP URL directly, without involving a local SIP the address identified in the SIP URL directly, without involving a
server. However in some circumstances, when firewalls are present, local SIP server. However in some circumstances, when firewalls are
SIP clients need to use a local server for outbound requests.) This present, SIP clients need to use a local server for outbound
is one of many possible solutions for locating the outbound SIP requests.) This is one of many possible solutions for locating the
server. outbound SIP server; manual configuration is an example of another.
3 Overview 3 Overview
The SIP client obtains a DNS [5] string via a DHCP option. The SIP The SIP client obtains a DNS [6] string via a DHCP option. This
client first uses the SRV [6] resource records to resolve the host string is then used by the mechanism described in [3] to locate the
name. If this fails, the A resource records are tried. 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].
4 SIP server DHCP options 4 SIP server DHCP options
This option specifies the DNS [5] string that is passed to the This option specifies the DNS [6] string that is passed to the
client. This string SHOULD be the domain name of the SIP server. The client. This string SHOULD be the domain name of the SIP server
client SHOULD first use this string to send an SRV query to the DNS (rather than a textual representation of the network address). The
server. If the client is not SRV-cognizant or the SRV query fails, code for this option is TBD. The length of the DNS name string is
the client sends the same string in an A record query. The code for specified in `Len'. The maximum length of this string is 255 octets
this option is TBD. The length of the DNS name string is specified in and minimum length is 1 octet. For example, a value may be
`Len'. The maximum length of this string is 255 octets and minimum "sip.example.com".
length is 1 octet.
Code Len DNS name of SIP server Code Len DNS name of SIP server
+-----+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+-----+--
| TBD | n | s1 | s2 | s3 | s4 | s5 | ... | TBD | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+-----+--
The reason for using the SRV string to obtain the IP address is that
load sharing can be implemented more readily by an SRV-cognizant
client. The string sent by the DHCP server SHOULD be the domain name
of the SIP server. The client uses this string to construct the SRV
query. The DHCP server MAY instead choose to send the fully qualified
domain name of the SIP server intended to be used in an A record
query, but this is NOT RECOMMENDED. The client however, MUST first
treat the string as a domain name and use it to construct the SRV
query. SIP clients usually support either UDP or TCP, but SIP
servers usually support both UDP and TCP. Thus, if the string sent
by the DHCP server is intended for use in constructing the SRV query,
it MUST NOT contain the Service and Proto [6] fields. The client is
aware of the transport protocols that it can support, therefore it is
appropriate that the Service and the Proto fields be added by the
client. The Service field in this case is always _sip. The Proto
fields may be _udp or _tcp depending on the client's capabilities.
The client adds the Service and Proto fields to the string before
making the SRV query. If the client's SRV query fails, the client
MUST use the string originally returned by the DHCP server in an A
record query (without adding the Service and Proto fields).
5 Security Consideration 5 Security Consideration
There are no security considerations beyond those described in RFC There are no security considerations beyond those described in RFC
2132. 2132.
6 Acknowledgements 6 Acknowledgements
We would like to thank Robert Elz, Wenyu Jiang, Peter Koch, Erik Robert Elz, Wenyu Jiang, Peter Koch, Erik Nordmark, Jonathan
Nordmark, Jonathan Rosenberg, Kundan Singh, Sven Ubik and Bernie Volz Rosenberg, Kundan Singh, Sven Ubik and Bernie Volz provided useful
for their contributions. feedback.
7 Authors' Addresses 7 Authors' Addresses
Gautam Nair Gautam Nair
Dept. of Computer Science Dept. of Computer Science
Columbia University 1214 Amsterdam Avenue, MC 0401 Columbia University 1214 Amsterdam Avenue, MC 0401
New York, NY 10027 New York, NY 10027
USA USA
electronic mail: gnair@cs.columbia.edu electronic mail: gnair@cs.columbia.edu
Henning Schulzrinne Henning Schulzrinne
Dept. of Computer Science Dept. of Computer Science
Columbia University 1214 Amsterdam Avenue, MC 0401 Columbia University 1214 Amsterdam Avenue, MC 0401
New York, NY 10027 New York, NY 10027
USA USA
electronic mail: schulzrinne@cs.columbia.edu electronic mail: schulzrinne@cs.columbia.edu
8 Bibliography 8 Bibliography
[1] R. Droms, "Dynamic host configuration protocol," Request for [1] R. Droms, "Dynamic host configuration protocol," Request for
Comments (Draft Standard) 2131, Internet Engineering Task Force, Mar. Comments 2131, Internet Engineering Task Force, Mar. 1997.
1997.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments (Proposed session initiation protocol," Request for Comments 2543, Internet
Standard) 2543, Internet Engineering Task Force, Mar. 1999. Engineering Task Force, Mar. 1999.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments (Best Current Practice) 2119, Internet
Engineering Task Force, Mar. 1997.
[4] S. Alexander and R. Droms, "DHCP options and BOOTP vendor
extensions," Request for Comments (Draft Standard) 2132, Internet
Engineering Task Force, Mar. 1997.
[5] P. V. Mockapetris, "Domain names - implementation and
specification," Request for Comments (Standard) 1035, Internet
Engineering Task Force, Nov. 1987.
[6] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying
the location of services (DNS SRV)," Request for Comments (Proposed
Standard) 2782, Internet Engineering Task Force, Feb. 2000.
Full Copyright Statement
Copyright (c) The Internet Society (2000). All Rights Reserved. [3] H. Schulzrinne and J. Rosenberg, "SIP: session initiation
protocol -- locating SIP servers," Internet Draft, Internet
Engineering Task Force, Jan. 2001. Work in progress.
This document and translations of it may be copied and furnished to [4] S. Bradner, "Key words for use in RFCs to indicate requirement
others, and derivative works that comment on or otherwise explain it levels," Request for Comments 2119, Internet Engineering Task Force,
or assist in its implementation may be prepared, copied, published Mar. 1997.
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be [5] S. Alexander and R. Droms, "DHCP options and BOOTP vendor
revoked by the Internet Society or its successors or assigns. extensions," Request for Comments 2132, Internet Engineering Task
Force, Mar. 1997.
This document and the information contained herein is provided on an [6] P. V. Mockapetris, "Domain names - implementation and
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING specification," Request for Comments 1035, Internet Engineering Task
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING Force, Nov. 1987.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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