idnits 2.17.1 draft-nair-sip-dhcp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 68: '...s. (SIP clients MAY contact the addre...' RFC 2119 keyword, line 139: '... client SHOULD first use this string...' RFC 2119 keyword, line 152: '... Clients SHOULD use this method to l...' RFC 2119 keyword, line 160: '...client. The list SHOULD only be used i...' RFC 2119 keyword, line 167: '...t host. A client MUST attempt to conta...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 131 has weird spacing: '...de Len con...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 11, 2000) is 8840 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 254 looks like a reference -- Missing reference section? '2' on line 258 looks like a reference -- Missing reference section? '3' on line 262 looks like a reference -- Missing reference section? '4' on line 266 looks like a reference -- Missing reference section? '5' on line 270 looks like a reference -- Missing reference section? '6' on line 274 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 Internet Draft Nair/Schulzrinne 3 draft-nair-sip-dhcp-01.txt Columbia University 4 February 11, 2000 5 Expires: August 2000 7 DHCP Option for SIP Servers 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document defines a DHCP option that contains one or more 33 pointers to one or more SIP servers. This enables a SIP client to 34 obtain the addresses of the SIP servers during bootup. 36 1 Terminology 38 DHCP client: A DHCP [1] client is an Internet host that uses 39 DHCP to obtain configuration parameters such as a network 40 address. 42 DHCP server: A DHCP server is an Internet host that returns 43 configuration parameters to DHCP clients. 45 SIP server: As defined in RFC 2543 [2]. In the context of this 46 document, a SIP server refers to the host the application 47 is running on. 49 SIP client: As defined in RFC 2543. In the context of this 50 document, a SIP client refers to the host the application 51 is running on. 53 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 54 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 55 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3]. 57 2 Introduction 59 The Session Initiation Protocol (SIP) [2] is an application-layer 60 control protocol that can establish, modify and terminate multimedia 61 sessions or calls. In particular, it is used for signalling of 62 Internet telephony calls. A SIP system has two components: user 63 agents and servers. The user agent is the SIP end system that acts 64 on behalf of someone who wants to participate in a SIP call. 66 This draft specifies a DHCP option [1,4] that allows SIP user agents 67 (clients) to locate a local SIP server that is to be used for all 68 outbound SIP requests. (SIP clients MAY contact the address 69 identified in the SIP URL directly, without involving a local SIP 70 server. However in some circumstances, in particular with firewalls, 71 SIP clients need to use a local server for outbound requests.) 73 3 Overview 75 We identify two methods of notifying the client of the servers' 76 location: 78 1. DNS [5] SRV records: IP address can be resolved by the 79 client, using DNS and the name string passed through a DHCP 80 option. The client first uses the SRV [6] resource records 81 to resolve the host name. If this fails the A resource 82 records are tried. 84 2. List of IP addresses: Used in case there is no DNS server 85 OR in the case that the client host is not DNS capable. 87 Any or all of these methods may be used to notify the client of the 88 servers' location. 90 One approach to using these methods through DHCP is to have a 91 separate DHCP option for each method. This approach makes it easier 92 for the client to ignore an option that it is not concerned with. 93 This is an issue in the case of smaller embedded systems that do not 94 implement DNS or with systems that do not recognize the DNS SRV 95 record. In these cases the client is interested only in the IP 96 address of the SIP server or the DNS `A' record, as the case may be. 98 This approach however consumes at least two option numbers from the 99 option number space. 101 In order to conserve the option number space, we propose to include 102 both methods within a single option space. This is done by separating 103 them into individual sub-options. The drawback of this method is that 104 it is more complicated than the individual option approach mentioned 105 above. However in addition to conserving precious option number 106 space, it logically groups both methods of SIP server location into a 107 single field. This approach is defined in the following sections. 109 4 SIP server option 111 This option specifies one or more fields containing location 112 information for the SIP servers. The fields that can be carried in 113 this option are described in the sections that follow. 115 The code for this option is TBD, and its maximum length is 255 116 octets. 118 Code Len Sub-Options 119 +-----+-----+-----+-----+-----+-----+-- 120 | TBD | n | s1 | s2 | s3 | s4 | ... 121 +-----+-----+-----+-----+-----+-----+-- 123 The `Len' field specifies the total number of octets contained in all 124 sub-options. 126 Each sub-option will contain a sub-code followed by a length that 127 specifies the number of octets containing configuration information 128 within the sub-option. 130 Sub Sub 131 Code Len configuration information 132 +-----+-----+-----+-----+-----+-----+-----+-- 133 | x | n | c1 | c2 | c3 | c4 | c5 | ... 134 +-----+-----+-----+-----+-----+-----+-----+-- 136 4.1 DNS name sub-option 138 This sub-option specifies the DNS [5] name of the SIP server The 139 client SHOULD first use this string to send an SRV query to the DNS 140 server. If the client is not SRV-cognizant OR the SRV query fails, 141 the client sends the same string in an A record query. The sub-code 142 for this sub-option is 1. The length of the DNS name string is 143 specified in `Sub Len'. The maximum length of this string is 253 144 octets and minimum length is 1 octet. 146 Sub Sub 147 Code Len DNS name of SIP server 148 +-----+-----+-----+-----+-----+-----+-----+-- 149 | 1 | n | s1 | s2 | s3 | s4 | s5 | ... 150 +-----+-----+-----+-----+-----+-----+-----+-- 152 Clients SHOULD use this method to locate the SIP server. The reason 153 to list the SRV string and use DNS to resolve the address is that 154 load sharing can be implemented more readily by an SRV-cognizant 155 client. 157 4.2 IP address sub-option 159 This sub-option specifies the list of IP addresses indicating SIP 160 servers available to the client. The list SHOULD only be used if the 161 client does not implement DNS (as in the case of some emebedded 162 systems) OR if the DNS server is not responding. We duplicate 163 relevant parts of the SRV record [6] in this sub-option. Each item of 164 the list consists of 6 fields which are described below: 166 1. prio: This is a 16 bit field which indicates the priority 167 of this target host. A client MUST attempt to contact the 168 target host with the lowest-numbered priority it can reach; 169 target hosts with the same priority SHOULD be tried in a 170 round-robin fashion starting with a randomly chosen 171 address. The range of priorities is 0-65535. 173 2. wt: This is a 16 bit field used by the load balancing 174 mechanism. When selecting a target host among those that 175 have the same priority, the chance of trying this one first 176 SHOULD be proportional to its weight. The range of this 177 number is 1-65535. Domain administrators are urged to use 178 Weight 0 when there isn't any load balancing to do, to make 179 the sub-option easier to read for humans (less noisy). 181 3. port: This is a 16 bit field indicating the port on this 182 target SIP server. The range is 0-65535. This is often 5060 183 - as specified in the IANA Assigned Numbers, but need not 184 be. 186 4. prot: This is an 8 bit field indicating the protocol used 187 by the SIP server. This can be either TCP or UDP. The IANA 188 assigned number for TCP (6) and UDP (17) are used here. 190 5. pad: This is an 8 bit field introduced to ensure that the 191 suboption data is alligned with a 32 bit boundary. This 192 makes it easier for the client to process the data. 194 6. IP address: This is a 32 bit field indicating the IP 195 address of the SIP server. 197 The sub-code for this sub-option is 2. The minimum length of this 198 sub-option is 12 octets and the length MUST be a multiple of 12. The 199 maximum length of this sub-option is 252 octets. 201 Sub Sub 202 Code Len Sub-option data 1 Sub-option data 2 203 +-----+-----+-----+-----+-----+-- --+-----+-----+-- 204 | 2 | n | i1 | i2 | i3 | ... | i13 | i14 | ... 205 +-----+-----+-----+-----+-----+-- --+-----+-----+-- 207 The sub-option data is as follows: 209 0 1 2 3 210 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | prio | wt | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | port | prot | pad | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | IP address | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 5 Multiple sub-options 221 More than one sub-option MAY be returned by the DHCP server. More 222 than one of any sub-option types MAY be present. This permits the 223 client to select the sub-option that suits its capabilities (DNS-SRV, 224 DNS-A, or no DNS capability). 226 6 Security Consideration 228 There are no security considerations beyond those described in RFC 229 2132. 231 7 Acknowledgements 233 We would like to thank Bernie Volz, Jonathan Rosenberg, Kundan Singh, 234 Wenyu Jiang and Sven Ubik for their contributions. 236 8 Authors' Addresses 238 Gautam Nair 239 Dept. of Computer Science 240 Columbia University 1214 Amsterdam Avenue, MC 0401 241 New York, NY 10027 242 USA 243 electronic mail: gnair@cs.columbia.edu 245 Henning Schulzrinne 246 Dept. of Computer Science 247 Columbia University 1214 Amsterdam Avenue, MC 0401 248 New York, NY 10027 249 USA 250 electronic mail: schulzrinne@cs.columbia.edu 252 9 Bibliography 254 [1] R. Droms, "Dynamic host configuration protocol," Request for 255 Comments (Draft Standard) 2131, Internet Engineering Task Force, Mar. 256 1997. 258 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 259 session initiation protocol," Request for Comments (Proposed 260 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 262 [3] S. Bradner, "Key words for use in RFCs to indicate requirement 263 levels," Request for Comments (Best Current Practice) 2119, Internet 264 Engineering Task Force, Mar. 1997. 266 [4] S. Alexander and R. Droms, "DHCP options and BOOTP vendor 267 extensions," Request for Comments (Draft Standard) 2132, Internet 268 Engineering Task Force, Mar. 1997. 270 [5] P. V. Mockapetris, "Domain names - implementation and 271 specification," Request for Comments (Standard) 1035, Internet 272 Engineering Task Force, Nov. 1987. 274 [6] A. Gulbrandsen and P. Vixie, "A DNS RR for specifying the 275 location of services (DNS SRV)," Request for Comments (Experimental) 276 2052, Internet Engineering Task Force, Oct. 1996. 278 Full Copyright Statement 280 Copyright (c) The Internet Society (2000). All Rights Reserved. 282 This document and translations of it may be copied and furnished to 283 others, and derivative works that comment on or otherwise explain it 284 or assist in its implementation may be prepared, copied, published 285 and distributed, in whole or in part, without restriction of any 286 kind, provided that the above copyright notice and this paragraph are 287 included on all such copies and derivative works. However, this 288 document itself may not be modified in any way, such as by removing 289 the copyright notice or references to the Internet Society or other 290 Internet organizations, except as needed for the purpose of 291 developing Internet standards in which case the procedures for 292 copyrights defined in the Internet Standards process must be 293 followed, or as required to translate it into languages other than 294 English. 296 The limited permissions granted above are perpetual and will not be 297 revoked by the Internet Society or its successors or assigns. 299 This document and the information contained herein is provided on an 300 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 301 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 302 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 303 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 304 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 306 Table of Contents 308 1 Terminology ......................................... 1 309 2 Introduction ........................................ 2 310 3 Overview ............................................ 2 311 4 SIP server option ................................... 3 312 4.1 DNS name sub-option ................................. 4 313 4.2 IP address sub-option ............................... 4 314 5 Multiple sub-options ................................ 5 315 6 Security Consideration .............................. 6 316 7 Acknowledgements .................................... 6 317 8 Authors' Addresses .................................. 6 318 9 Bibliography ........................................ 6