idnits 2.17.1 draft-ietf-sip-nat-02.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 1, 2002) is 7969 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft J. Rosenberg 4 dynamicsoft 5 J. Weinberger 6 dynamicsoft 7 H. Schulzrinne 8 Columbia U. 9 draft-ietf-sip-nat-02.txt 10 July 1, 2002 11 Expires: January 2003 13 An Extension to the Session Initiation Protocol (SIP) 14 for Symmetric Response Routing 16 STATUS OF THIS MEMO 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress". 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 To view the list Internet-Draft Shadow Directories, see 35 http://www.ietf.org/shadow.html. 37 Abstract 39 The Session Initiation Protocol (SIP) operates over UDP and TCP. When 40 used with UDP, responses to requests are returned to the source 41 address the request came from, but from the port written into the 42 topmost Via header of the request. This behavior is not desirable in 43 many cases, most notably, when the client is behind a NAT. This 44 extension defines a new parameter for the Via header, called rport, 45 that allows a client to request that the server send the response 46 back to the source IP address and port where the request came from. 48 Table of Contents 50 1 Introduction ........................................ 3 51 2 Terminology ......................................... 3 52 3 Client Behavior ..................................... 3 53 4 Server Behavior ..................................... 4 54 5 Syntax .............................................. 4 55 6 Example ............................................. 5 56 7 Security Considerations ............................. 6 57 8 IANA Considerations ................................. 6 58 9 Acknowledgements .................................... 6 59 10 Author's Addresses .................................. 7 60 11 Normative References ................................ 7 61 12 Informative References .............................. 7 63 1 Introduction 65 The Session Initiation Protocol (SIP) [1] operates over UDP and TCP. 66 When used with UDP, responses to requests are returned to the source 67 address the request came from, but from the port written into the 68 topmost Via header of the request. This behavior is not desirable in 69 many cases, most notably, when the client is behind a NAT. In that 70 case, the response will not properly traverse the NAT, since it will 71 not match the binding established with the request. 73 Related to this, there is currently no way in SIP for a client to 74 learn, from a response to its request, the source port that the 75 server saw in the request. Currently, SIP does provide the client 76 with the source IP address that the server saw in the request. This 77 information is conveyed in the received parameter in the topmost Via 78 header of the response. This information has proved useful for basic 79 NAT traversal, debugging purposes, and support of multi-homed hosts. 80 However, it is incomplete without the port information. 82 This extension defines a new parameter for the Via header, called 83 rport, that allows a client to request that the server send the 84 response back to the source IP address and port where the request 85 came from. The rport parameter is analagous to the received 86 parameter, except rport contains a port number, not the IP address. 88 2 Terminology 90 In this document, the key words "MUST", "MUSTNOT", "REQUIRED", 91 "SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and 92 "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and 93 indicate requirement levels for compliant SIP implementations. 95 3 Client Behavior 97 The client behavior specified here affects the transport processing 98 defined in Section 18.1 of SIP [1]. 100 A client compliant to this specification (clients include UACs and 101 proxies) MAY include an rport parameter in the top Via header of 102 requests it generates. This parameter MUST have no value; it serves 103 as a flag to indicate to the server that this extension is supported 104 and requested for the transaction. 106 When the client sends the request, if the request is sent using UDP, 107 the client MUST be prepared to receive the response on the same 108 socket the request was sent on. Specifically, it MUST be prepared to 109 receive the response on the same IP address and port present in the 110 source IP address and source port of the request. For backwards 111 compatibility, the client MUST still be prepared to receive a 112 response on the port indicated in the sent-by field of the topmost 113 Via, as specified in Section 18.1.1 of SIP [1]. 115 In the case where there is a NAT between the client and server, in 116 order for the response to always be received, the NAT binding must 117 remain in existence for the duration of the transaction. Most UDP NAT 118 bindings appear to have a timeout of about one minute. Therefore, 119 non-INVITE transactions will have no problem. For INVITE 120 transactions, the client may need to retransmit its INVITE every 20 121 seconds or so, even after receiving a provisional response, in order 122 to keep the binding open to receive the final response. 124 OPEN ISSUE: This is awful. Perhaps a further sign that the 125 only real answer is TCP? Or, perhaps this belongs in 126 sipping-nat-scenarios, not here. 128 4 Server Behavior 130 The server behavior specified here affects the transport processing 131 defined in Section 18.2 of SIP [1]. 133 When a server compliant to this specification (which can be a proxy 134 or UAS) receives a request, it examines the topmost Via header. If 135 this Via header contains an rport parameter with no value, it MUST 136 insert the port the request was received from as the value of this 137 parameter. This is analagous to the way in which a server will insert 138 the receieved parameter with the source IP address the request was 139 received from. In fact, the server MUST insert a received parameter 140 containing the source IP address that the request came from, even if 141 it is identical to the value of the sent-by field. Note that this 142 processing takes place independent of the transport protocol. 144 When a server attempts to send a response over an unreliable unicast 145 transport, such as UDP, and there is no Via maddr parameter present, 146 but there is both a received parameter and an rport parameter, the 147 response MUST be sent to the IP address listed in the received 148 parameter, and the port in the rport parameter. This effectively adds 149 a new processing step between bullets two and three in Section 18.2.2 150 of SIP [1]. 152 5 Syntax 154 The syntax for the rport parameter is: 156 response-port = "rport" [EQUAL 1*DIGIT] 157 This extends the existing definition of the Via header parameters, so 158 that its BNF now looks like: 160 via-params = via-ttl / via-maddr 161 / via-received / via-branch 162 / response-port / via-extension 164 6 Example 166 Consider an example. A client sends an INVITE which looks like: 168 INVITE sip:user@domain SIP/2.0 169 Via: SIP/2.0/UDP 10.1.1.1:4540;rport 171 This INVITE is sent with a source port of 4540 and source IP address 172 of 10.1.1.1. The request is natted, so that the source IP appears as 173 68.44.20.1 and the source port as 9988. This is received at a proxy. 174 The proxy forwards the request, but not before appending a value to 175 the rport parameter in the proxied request: 177 INVITE sip:user@domain2 SIP/2.0 178 Via: SIP/2.0/UDP proxy.domain.com 179 Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988 181 This request generates a response, which arrives at the proxy: 183 SIP/2.0 200 OK 184 Via: SIP/2.0/UDP proxy.domain.com 185 Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988 187 The proxy strips its top Via, and then examines the next one. It 188 contains both a received param, and an rport. The result is that the 189 following response is sent to IP address 68.44.20.1, port 9988: 191 SIP/2.0 200 OK 192 Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988 194 The NAT rewrites the destination address of this packet back to IP 195 10.1.1.1, port 4540, and is received by the client. 197 7 Security Considerations 199 Since this extension merely adds source port information to the 200 source address information already present in SIP, it does not appear 201 to add any additional security considerations. 203 8 IANA Considerations 205 There are no IANA Considerations associated with this specification. 207 9 Acknowledgements 209 The authors would like to thank Rohan Mahy for his comments and 210 contributions to this work. 212 Full Copyright Statement 214 Copyright (c) The Internet Society (2002). All Rights Reserved. 216 This document and translations of it may be copied and furnished to 217 others, and derivative works that comment on or otherwise explain it 218 or assist in its implementation may be prepared, copied, published 219 and distributed, in whole or in part, without restriction of any 220 kind, provided that the above copyright notice and this paragraph are 221 included on all such copies and derivative works. However, this 222 document itself may not be modified in any way, such as by removing 223 the copyright notice or references to the Internet Society or other 224 Internet organizations, except as needed for the purpose of 225 developing Internet standards in which case the procedures for 226 copyrights defined in the Internet Standards process must be 227 followed, or as required to translate it into languages other than 228 English. 230 The limited permissions granted above are perpetual and will not be 231 revoked by the Internet Society or its successors or assigns. 233 This document and the information contained herein is provided on an 234 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 235 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 236 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 237 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 238 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 240 10 Author's Addresses 242 Jonathan Rosenberg 243 dynamicsoft 244 72 Eagle Rock Avenue 245 First Floor 246 East Hanover, NJ 07936 247 email: jdrosen@dynamicsoft.com 249 Joel Weinberger 250 dynamicsoft 251 72 Eagle Rock Avenue 252 First Floor 253 East Hanover, NJ 07936 254 email: jweinberger@dynamicsoft.com 256 Henning Schulzrinne 257 Columbia University 258 M/S 0401 259 1214 Amsterdam Ave. 260 New York, NY 10027-7003 261 email: schulzrinne@cs.columbia.edu 263 11 Normative References 265 [1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation 266 protocol," Internet Draft, Internet Engineering Task Force, Feb. 267 2002. Work in progress. 269 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 270 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 272 12 Informative References 274 Full Copyright Statement 276 Copyright (c) The Internet Society (2002). All Rights Reserved. 278 This document and translations of it may be copied and furnished to 279 others, and derivative works that comment on or otherwise explain it 280 or assist in its implementation may be prepared, copied, published 281 and distributed, in whole or in part, without restriction of any 282 kind, provided that the above copyright notice and this paragraph are 283 included on all such copies and derivative works. However, this 284 document itself may not be modified in any way, such as by removing 285 the copyright notice or references to the Internet Society or other 286 Internet organizations, except as needed for the purpose of 287 developing Internet standards in which case the procedures for 288 copyrights defined in the Internet Standards process must be 289 followed, or as required to translate it into languages other than 290 English. 292 The limited permissions granted above are perpetual and will not be 293 revoked by the Internet Society or its successors or assigns. 295 This document and the information contained herein is provided on an 296 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 297 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 298 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 299 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 300 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.