idnits 2.17.1 draft-camarillo-sipping-v6-transition-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 323. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (February 12, 2005) is 7013 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) ** Obsolete normative reference: RFC 2327 (ref. '2') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 3388 (ref. '5') (Obsoleted by RFC 5888) ** Obsolete normative reference: RFC 3489 (ref. '6') (Obsoleted by RFC 5389) == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-06 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-03 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING Working Group G. Camarillo 2 Internet-Draft Ericsson 3 Expires: August 13, 2005 February 12, 2005 5 IPv6 Transcition in the Session Initiation Protocol (SIP) 6 draft-camarillo-sipping-v6-transition-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 13, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes how IPv4 SIP (Session Initiation Protocol) 42 nodes can communicate with IPv6 SIP nodes. Additionally, this 43 document also describes how a SIP user agent that supports IPv4 can 44 exchange media with one that supports IPv6. Both single and 45 dual-stack user agents are considered in the discussions. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. The SIP Layer . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1 Outbound Proxy . . . . . . . . . . . . . . . . . . . . . . 3 53 3.2 Inbound Proxy . . . . . . . . . . . . . . . . . . . . . . 4 54 3.3 Incoming Requests to a Domain . . . . . . . . . . . . . . 4 55 4. The Media Layer . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1 Initial Offer . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2 Connectivity Checks . . . . . . . . . . . . . . . . . . . 5 58 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 8. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 6 64 9.2 Informational References . . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 66 Intellectual Property and Copyright Statements . . . . . . . . 8 68 1. Introduction 70 SIP (Session Initiation Protocol) [3] is a protocol to establish and 71 manage multimedia sessions. After exchanging SIP traffic, SIP 72 endpoints generally exchange session traffic, which is not 73 transported using SIP, but using a different protocol. For example, 74 audio streams are typically carried using RTP (Real-Time Transport 75 Protocol) [13]. 77 Consequently, a complete solution for IPv6 transition needs to handle 78 both the SIP layer and the media layer. While unextended SIP can 79 handle heterogeneous IPv6/v4 networks at the SIP layer as long as 80 proxy servers and their DNS entries are properly configured, user 81 agents using different address spaces need to implement extensions in 82 order to exchange media between them. Section 3 discusses issues 83 related to the SIP layer and Section 4 discusses issues related to 84 the media layer. 86 2. Terminology 88 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 89 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 90 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 91 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 92 compliant implementations. 94 3. The SIP Layer 96 A given domain can send and receive SIP traffic to and from its user 97 agents and to and from other domains. The next sections describe the 98 issues related to these traffic exchanges. We assume that network 99 administrators appropriately configure their networks so that the SIP 100 servers within a domain can communicate between them. 102 3.1 Outbound Proxy 104 User agents typically send SIP traffic to an outbound proxy, which 105 takes care of routing it forward. In order to support both IPv4-only 106 and IPv6-only user agents, it is RECOMMENDED that domains deploy 107 dual-stack outbound proxy servers or, alternatively, deploy both 108 IPv4-only and IPv6-only outbound proxies. 110 Some domains provide automatic means for user agents to discover 111 their proxy servers. It is RECOMMENDED that domains implement 112 discovery mechanisms able to provide user agents with the IPv4 and 113 IPv6 addresses of their outbound proxy servers. For example, a 114 domain may support both the DHCPv4 [12] and the DHCPv6 [11] options 115 for SIP servers. 117 If user agents are configured with the FQDN (Fully-Qualified Domain 118 Name) of their outbound proxy servers (instead of with their IP 119 addresses) there SHOULD be both IPv6 and IPv4 DNS entries for 120 outbound proxy servers. This way, user agents can use DNS to obtain 121 both their IPv6 and IPv4 addresses. 123 3.2 Inbound Proxy 125 User agents receive SIP traffic from their domains through an inbound 126 proxy (which is sometimes collocated with the registrar of the 127 domain). It is RECOMMENDED that domains deploy dual-stack inbound 128 proxies or, alternatively, deploy both IPv4-only and IPv6-only 129 inbound proxy servers. 131 3.3 Incoming Requests to a Domain 133 A SIP user agent is typically reachable through the SIP server that 134 handles its domain. If the publicly available SIP URI for a 135 particular user, referred to as the user's AoR (Address of Record), 136 is 'sip:user@example.com', requests sent to that user will be routed 137 to the SIP server at 'example.com'. The proxy or user agent sending 138 the request will perform a DNS lookup for 'example.com' in order to 139 obtain the IP address of the SIP server. 141 Therefore, it is RECOMMENDED that domains have both IPv4 and IPv6 DNS 142 entries for SIP servers. This way, the domain will be able to 143 receive requests from IPv4-only and from IPv6-only hosts. Of course, 144 the domain SHOULD have dual-stack proxy servers or both IPv4-only and 145 IPv6-only proxy servers to handle the incoming SIP traffic. 147 A SIP proxy server that receives a request using IPv6 and relays it 148 to the user agent using IPv4, or vice versa, needs to remain in the 149 path traversed by subsequent requests between both user agents. 150 Therefore, such a SIP proxy server MUST be configured to Record-Route 151 in that situation. 153 4. The Media Layer 155 SIP establishes media sessions using the offer/answer model [4]. One 156 endpoint, the offerer, sends a session description (the offer) to the 157 other endpoint, the answerer. The offer contains all the media 158 parameters needed to exchange media with the offerer: codecs, 159 transport addresses, protocols to transfer media, etc. 161 When the answerer receives an offer, it elaborates an answer and 162 sends it back to the offerer. The answer contains the media 163 parameters that the answerer is willing to use for that particular 164 session. Offer and answer are written using a session description 165 protocol. The most widespread session description protocol at 166 present is SDP (Session Description Protocol) [2]. 168 A direct offer/answer exchange between an IPv4-only user agent and an 169 IPv6-only user agent does not result in the establishment of a 170 session. The IPv6-only user agent wishes to receive media on one or 171 more IPv6 addresses, but the IPv4-only user agent cannot send media 172 to these addresses and generally does not even understand their 173 format. 175 Consequently, user agents need a means to obtain both IPv4 and IPv6 176 addresses (either locally or using relays) to receive media and to 177 place them in offers and answers. The following sections describe 178 how user agents can gather addresses following the ICE (Interactive 179 Connectivity Establishment) [9] procedures and how they can encode 180 them in an SDP session description using the ANAT semantics [8] for 181 the SDP grouping framework [5]. 183 4.1 Initial Offer 185 It is RECOMMENDED that user agents gather IPv4 and IPv6 addresses 186 using the ICE procedures to generate all their offers. This way, 187 both IPv4-only and IPv6-only answerers will be able to generate an 188 answer that establishes a session. Note that, in case of forking, 189 the same offer carried in an INVITE request can arrive to an 190 IPv4-only user agent and to an IPv6-only user agent at roughly the 191 same time. Having placed both IPv4 and IPv6 addresses in the offer 192 reduces the session establishment time because both all types of 193 answerers find the offer valid. 195 When following the ICE procedures, in addition to local addresses, 196 user agents need to obtain addresses from relays. For example, and 197 IPv4 user agent would obtain an IPv6 address from a relay. The relay 198 would forward the traffic received on this IPv6 address to the user 199 agent using IPv4. Such user agents MAY use any mechanism to obtain 200 addresses in relays, but, following the recommendations in ICE, it is 201 RECOMMENDED that user agents support TURN [7] for this purpose. 203 User agents that use SDP SHOULD support the ANAT semantics for the 204 SDP grouping framework. ANAT allows user agents to include both IPv4 205 and IPv6 addresses in their SDP session descriptions. The SIP usage 206 of the ANAT semantics is discussed in [10]. 208 4.2 Connectivity Checks 210 Once the answerer has generated an answer following the ICE 211 procedures, both user agents SHOULD perform the STUN-based [6] 212 connectivity checks specified by ICE. This checks help prevent some 213 types of flooding attacks and allow user agents to discover new 214 addresses that can be useful in the presence of NATs (Network Address 215 Translators). 217 5. Example 219 TBD. 221 6. IANA Considerations 223 This document does not contain any actions for the IANA. 225 7. Security Considerations 227 TBD. 229 8. Acknowledges 231 TBD. 233 9. References 235 9.1 Normative References 237 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 238 Levels", BCP 14, RFC 2119, March 1997. 240 [2] Handley, M. and V. Jacobson, "SDP: Session Description 241 Protocol", RFC 2327, April 1998. 243 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 244 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 245 Session Initiation Protocol", RFC 3261, June 2002. 247 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 248 Session Description Protocol (SDP)", RFC 3264, June 2002. 250 [5] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne, 251 "Grouping of Media Lines in the Session Description Protocol 252 (SDP)", RFC 3388, December 2002. 254 [6] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 255 Simple Traversal of User Datagram Protocol (UDP) Through 256 Network Address Translators (NATs)", RFC 3489, March 2003. 258 [7] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 259 draft-rosenberg-midcom-turn-06 (work in progress), October 260 2004. 262 [8] Camarillo, G., "The Alternative Network Address Types Semantics 263 (ANAT) for theSession Description Protocol (SDP) Grouping 264 Framework", draft-ietf-mmusic-anat-02 (work in progress), 265 October 2004. 267 [9] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 268 Methodology for Network Address Translator (NAT) Traversal for 269 Multimedia Session Establishment Protocols", 270 draft-ietf-mmusic-ice-03 (work in progress), October 2004. 272 [10] Camarillo, G., "Usage of the Session Description Protocol (SDP) 273 Alternative Network Address Types (ANAT) Semantics in the 274 Session Initiation Protocol (SIP)", 275 draft-ietf-sip-anat-usage-00 (work in progress), June 2004. 277 9.2 Informational References 279 [11] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 280 Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) 281 Servers", RFC 3319, July 2003. 283 [12] Schulzrinne, H., "Dynamic Host Configuration Protocol 284 (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) 285 Servers", RFC 3361, August 2002. 287 [13] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 288 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 289 RFC 3550, July 2003. 291 Author's Address 293 Gonzalo Camarillo 294 Ericsson 295 Hirsalantie 11 296 Jorvas 02420 297 Finland 299 EMail: Gonzalo.Camarillo@ericsson.com 301 Intellectual Property Statement 303 The IETF takes no position regarding the validity or scope of any 304 Intellectual Property Rights or other rights that might be claimed to 305 pertain to the implementation or use of the technology described in 306 this document or the extent to which any license under such rights 307 might or might not be available; nor does it represent that it has 308 made any independent effort to identify any such rights. Information 309 on the procedures with respect to rights in RFC documents can be 310 found in BCP 78 and BCP 79. 312 Copies of IPR disclosures made to the IETF Secretariat and any 313 assurances of licenses to be made available, or the result of an 314 attempt made to obtain a general license or permission for the use of 315 such proprietary rights by implementers or users of this 316 specification can be obtained from the IETF on-line IPR repository at 317 http://www.ietf.org/ipr. 319 The IETF invites any interested party to bring to its attention any 320 copyrights, patents or patent applications, or other proprietary 321 rights that may cover technology that may be required to implement 322 this standard. Please address the information to the IETF at 323 ietf-ipr@ietf.org. 325 Disclaimer of Validity 327 This document and the information contained herein are provided on an 328 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 329 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 330 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 331 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 332 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 333 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 335 Copyright Statement 337 Copyright (C) The Internet Society (2005). This document is subject 338 to the rights, licenses and restrictions contained in BCP 78, and 339 except as set forth therein, the authors retain all their rights. 341 Acknowledgment 343 Funding for the RFC Editor function is currently provided by the 344 Internet Society.