draft-ietf-sip-dhcp-00.txt   draft-ietf-sip-dhcp-01.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-00.txt Columbia University draft-ietf-sip-dhcp-01.txt Columbia University
February 27, 2000 April 6, 2000
Expires: August 2000 Expires: October 2000
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 34 skipping to change at page 1, line 33
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 The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines DHCP options that contain one or more pointers This document defines a DHCP option that contains a pointers to one
to one or more SIP servers. This is one of the many methods that a or more SIP servers. This is one of the many methods that a SIP
SIP client can use to obtain the addresses of the SIP servers. client can use to obtain the addresses of a local oubound 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]. In the context of this
document, a SIP server refers to the host the application document, a SIP server refers to the host the SIP server is
is running on. running on.
SIP client: As defined in RFC 2543. In the context of this SIP client: As defined in RFC 2543. In the context of this
document, a SIP client refers to the host the application document, a SIP client refers to the host the SIP client is
is running on. 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", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [3]. and "OPTIONAL" are to be interpreted as described in RFC 2119 [3].
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 signalling of sessions or calls. In particular, it is used for signaling of
Internet telephony calls. A SIP system has two components: user Internet telephony calls. A SIP system has two components: user
agents and servers. The user agent is the SIP end system that acts agents and servers. The user agent is the SIP end system that acts
on behalf of someone who wants to participate in a SIP call. 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,4] that allows SIP user agents
(clients) to locate a local SIP server that is to be used for all (clients) to locate a local SIP server that is to be used for all
outbound SIP requests. (SIP clients MAY contact the address outbound SIP requests. (SIP clients MAY contact the address
identified in the SIP URL directly, without involving a local SIP identified in the SIP URL directly, without involving a local SIP
server. However in some circumstances, in particular with firewalls, server. However in some circumstances, when firewalls are present,
SIP clients need to use a local server for outbound requests.) This SIP clients need to use a local server for outbound requests.) This
is one of many possible solutions for locating the outbound SIP is one of many possible solutions for locating the outbound SIP
server. server.
3 Overview 3 Overview
We identify two methods of notifying the client of the servers' The SIP client obtains a DNS [5] string via a DHCP option. The SIP
location: client first uses the SRV [6] resource records to resolve the host
name. If this fails, the A resource records are tried.
1. DNS [5] SRV records: The host name can be resolved by the
client, using DNS and the name string obtained via a DHCP
option. The client first uses the SRV [6] resource records
to resolve the host name. If this fails the A resource
records are tried.
2. List of IP addresses: Used in case there is no DNS server
OR in the case that the client host is not DNS capable.
Either or both of these methods MAY be used to notify the client of
the servers' location through DHCP.
4 SIP server DHCP options 4 SIP server DHCP options
We propose two new DHCP options. Our approach is defined in the This option specifies the DNS [5] string that is passed to the
following sections. client. This string SHOULD be the domain name of the SIP server. The
client SHOULD first use this string to send an SRV query to the DNS
4.1 SIP server DNS name option server. If the client is not SRV-cognizant or the SRV query fails,
the client sends the same string in an A record query. The code for
This option specifies the DNS [5] name of the SIP server The client this option is TBD. The length of the DNS name string is specified in
SHOULD first use this string to send an SRV query to the DNS server. `Len'. The maximum length of this string is 255 octets and minimum
If the client is not SRV-cognizant OR the SRV query fails, the client length is 1 octet.
sends the same string in an A record query. The code for this option
is TBD. The length of the DNS name string is specified in `Len'. The
maximum length of this string is 255 octets and minimum 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 | ...
+-----+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+-----+--
Clients SHOULD use this method to locate the SIP server. The reason The reason for using the SRV string to obtain the IP address is that
to list the SRV string and use DNS to resolve the address is that
load sharing can be implemented more readily by an SRV-cognizant load sharing can be implemented more readily by an SRV-cognizant
client. 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
4.2 SIP server IP address option 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
This option specifies the list of IP addresses indicating SIP servers query, but this is NOT RECOMMENDED. The client however, MUST first
available to the client. The option SHOULD only be used if the client treat the string as a domain name and use it to construct the SRV
does not implement DNS (as in the case of some emebedded systems) OR query. SIP clients usually support either UDP or TCP, but SIP
if the DNS server is not responding. We duplicate relevant parts of servers usually support both UDP and TCP. Thus, if the string sent
the SRV record [6] in this option. Each item of the list consists of by the DHCP server is intended for use in constructing the SRV query,
an ASCII string with 5 fields separated by a single space (ASCII it MUST NOT contain the Service and Proto [6] fields. The client is
0x20) as shown below: aware of the transport protocols that it can support, therefore it is
appropriate that the Service and the Proto fields be added by the
<IP Address> <prio> <wt> <port> <prot> client. The Service field in this case is always _sip. The Proto
fields may be _udp or _tcp depending on the client's capabilities.
IP address: This field contains the IP address of the SIP server The client adds the Service and Proto fields to the string before
in dotted quad notation. 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
prio: This field indicates the priority of this target host. A record query (without adding the Service and Proto fields).
client MUST attempt to contact the target host with the
lowest-numbered priority it can reach; target hosts with
the same priority SHOULD be tried in a round-robin fashion
starting with a randomly chosen address. The range of
priorities is 0-65535.
wt: This field is used by the load balancing mechanism. When
selecting a target host among those that have the same
priority, the chance of trying this one first SHOULD be
proportional to its weight. The range of this number is 1-
65535. Domain administrators are urged to use Weight 0 when
there isn't any load balancing to do, to make the option
easier to read for humans (less noisy).
port: This field indicates the port on this target SIP server.
The range is 0-65535. This is often 5060 - as specified in
the IANA Assigned Numbers, but need not be.
prot: This field indicates the protocol used by the SIP server.
This can be either `TCP' or `UDP'. The protocol name is
case sensitive.
The code for this option is TBD. The length of this option is
specified in `Len'. The minimum length of this option is 17 octets.
The maximum length of this option is 255 octets.
Code Len string 1 string 2
+-----+-----+-----+-----+-----+-- --+-----+-----+--
| TBD | n | s1 | s2 | s3 | ... | s13 | s14 | ...
+-----+-----+-----+-----+-----+-- --+-----+-----+--
5 Multiple options
More than one SIP server option MAY be returned by the DHCP server.
More than one of any option types MAY be present. This permits the
client to select the option that suits its capabilities (DNS-SRV,
DNS-A, or no DNS capability).
6 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.
7 Acknowledgements 6 Acknowledgements
We would like to thank Jonathan Rosenberg, Bernie Volz, Kundan Singh, We would like to thank Robert Elz, Wenyu Jiang, Peter Koch, Erik
Sven Ubik and Wenyu Jiang for their contributions. Nordmark, Jonathan Rosenberg, Kundan Singh, Sven Ubik and Bernie Volz
for their contributions.
7 Authors' Addresses
8 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
9 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 (Draft Standard) 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 (Proposed
Standard) 2543, Internet Engineering Task Force, Mar. 1999. Standard) 2543, Internet Engineering Task Force, Mar. 1999.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement [3] S. Bradner, "Key words for use in RFCs to indicate requirement
skipping to change at page 5, line 40 skipping to change at page 4, line 43
Engineering Task Force, Mar. 1997. Engineering Task Force, Mar. 1997.
[4] S. Alexander and R. Droms, "DHCP options and BOOTP vendor [4] S. Alexander and R. Droms, "DHCP options and BOOTP vendor
extensions," Request for Comments (Draft Standard) 2132, Internet extensions," Request for Comments (Draft Standard) 2132, Internet
Engineering Task Force, Mar. 1997. Engineering Task Force, Mar. 1997.
[5] P. V. Mockapetris, "Domain names - implementation and [5] P. V. Mockapetris, "Domain names - implementation and
specification," Request for Comments (Standard) 1035, Internet specification," Request for Comments (Standard) 1035, Internet
Engineering Task Force, Nov. 1987. Engineering Task Force, Nov. 1987.
[6] A. Gulbrandsen and P. Vixie, "A DNS RR for specifying the [6] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying
location of services (DNS SRV)," Request for Comments (Experimental) the location of services (DNS SRV)," Request for Comments (Proposed
2052, Internet Engineering Task Force, Oct. 1996. Standard) 2782, Internet Engineering Task Force, Feb. 2000.
Full Copyright Statement Full Copyright Statement
Copyright (c) The Internet Society (2000). All Rights Reserved. Copyright (c) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
skipping to change at page 6, line 24 skipping to change at line 209
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents
1 Terminology ......................................... 1
2 Introduction ........................................ 2
3 Overview ............................................ 2
4 SIP server DHCP options ............................. 2
4.1 SIP server DNS name option .......................... 3
4.2 SIP server IP address option ........................ 3
5 Multiple options .................................... 4
6 Security Consideration .............................. 4
7 Acknowledgements .................................... 4
8 Authors' Addresses .................................. 4
9 Bibliography ........................................ 5
 End of changes. 

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