idnits 2.17.1 draft-ietf-sipping-v6-transition-07.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 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 655. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 661. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3264, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 543 has weird spacing: '... Option for S...' == 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). (Using the creation date from RFC3264, updated by this document, for RFC5378 checks: 2002-01-31) -- 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 (August 16, 2007) is 6069 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 4566 (ref. '2') (Obsoleted by RFC 8866) == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-04 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-17 == Outdated reference: A later version (-11) exists of draft-ietf-behave-turn-ipv6-03 ** Obsolete normative reference: RFC 3484 (ref. '9') (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 2543 (ref. '14') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) == Outdated reference: A later version (-04) exists of draft-ietf-sipping-ipv6-torture-tests-03 == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-08 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Updates: 3264 (if approved) K. El Malki 5 Intended status: Standards Track Athonet 6 Expires: February 17, 2008 V. Gurbani 7 Bell Laboratories, Alcatel-Lucent 8 August 16, 2007 10 IPv6 Transition in the Session Initiation Protocol (SIP) 11 draft-ietf-sipping-v6-transition-07 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on February 17, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document describes how IPv4 Session Initiation Protocol (SIP) 45 user agents can communicate with IPv6 SIP user agents (and vice 46 versa) at the signaling layer as well as exchange media once the 47 session has been successfully set up. Both single- and dual-stack 48 (i.e., an IPv4-only and an IPv4/IPv6) user agents are considered. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. The Signaling Layer . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1.1. Relaying Requests Across Different Networks . . . . . 5 57 3.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 8 58 4. The Media Layer . . . . . . . . . . . . . . . . . . . . . . . 8 59 4.1. Updates to RFC3264 . . . . . . . . . . . . . . . . . . . . 9 60 4.2. Initial Offer . . . . . . . . . . . . . . . . . . . . . . 10 61 4.3. Connectivity Checks . . . . . . . . . . . . . . . . . . . 10 62 5. Contacting Servers: Interaction of RFC3263 and RFC3484 . . . . 11 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 68 9.2. Informational References . . . . . . . . . . . . . . . . . 13 69 Appendix A. Sample IPv4/IPv6 DNS File . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 71 Intellectual Property and Copyright Statements . . . . . . . . . . 16 73 1. Introduction 75 SIP [3] is a protocol to establish and manage multimedia sessions. 76 After the exchange of signaling messages, SIP endpoints generally 77 exchange session, or media traffic, which is not transported using 78 SIP but a different protocol. For example, audio streams are 79 typically carried using Real-Time Transport Protocol (RTP [13]). 81 Consequently, a complete solution for IPv6 transition needs to handle 82 both the signaling layer and the media layer. While unextended SIP 83 can handle heterogeneous IPv6/IPv4 networks at the signaling layer as 84 long as proxy servers and their Domain Name Service (DNS) entries are 85 properly configured, user agents using different networks and address 86 spaces must implement extensions in order to exchange media between 87 them. 89 This document addresses the systems-level issues to make SIP work 90 successfully between IPv4 and IPv6. Section 3 and Section 4 provide 91 discussions on the topics that are pertinent to the signaling layer 92 and media layer, respectively, to establish a successful session 93 between heterogeneous IPv4/IPv6 networks. 95 2. Terminology 97 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 98 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 99 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 100 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 101 compliant implementations. 103 IPv4-only user agent: An IPv4-only user agent supports SIP signaling 104 and media only on the IPv4 network. It does not understand IPv6 105 addresses. 107 IPv4-only node: A host that implements only IPv4. An IPv4-only node 108 does not understand IPv6. The installed base of IPv4 hosts 109 existing before the transition begins are IPv4-only nodes. 111 IPv6-only user agent: An IPv6-only user agent supports SIP signaling 112 and media only on the IPv6 network. It does not understand IPv4 113 addresses. 115 IPv6-only node: A host that implements IPv6 and does not implement 116 IPv4. 118 IPv4/IPv6 node: A host that implements both IPv4 and IPv6; such 119 hosts are also known as "dual-stack" hosts [17]. 121 IPv4/IPv6 user agent: An user agent that supports SIP signaling and 122 media on both IPv4 and IPv6 networks. 124 IPv4/IPv6 proxy: A proxy that supports SIP signaling on both IPv4 125 and IPv6 networks. 127 3. The Signaling Layer 129 An autonomous domain sends and receives SIP traffic to and from its 130 user agents as well as to and from other autonomous domains. This 131 section describes the issues related to such traffic exchanges at the 132 signaling layer; i.e., the flow of SIP messages between participants 133 in order to establish the session. We assume that the network 134 administrators appropriately configure their networks such that the 135 SIP servers within an autonomous domain can communicate between 136 themselves. This section contains systems-level issues; a companion 137 document [15] addresses IPv6 parser torture tests in SIP. 139 3.1. Proxy Behavior 141 User agents typically send SIP traffic to an outbound proxy, which 142 takes care of routing it forward. In order to support both IPv4-only 143 and IPv6-only user agents, it is RECOMMENDED that domains deploy 144 dual-stack outbound proxy servers or, alternatively, deploy both 145 IPv4-only and IPv6-only outbound proxies. Furthermore, there SHOULD 146 exist both IPv6 and IPv4 DNS entries for outbound proxy servers. 147 This allows the user agent to query DNS and obtain an IP address most 148 appropriate for its use (i.e., an IPv4-only user agent will query DNS 149 for A resource records (RR), an IPv6-only user agent will query DNS 150 for AAAA RRs, and a dual-stack user agent will query DNS for all RRs 151 and choose a specific network.) 153 Some domains provide automatic means for user agents to discover 154 their proxy servers. It is RECOMMENDED that domains implement 155 appropriate discovery mechanisms to provide user agents with the IPv4 156 and IPv6 addresses of their outbound proxy servers. For example, a 157 domain may support both the DHCPv4 [11] and the DHCPv6 [10] options 158 for SIP servers. 160 On the receiving side, user agents inside an autonomous domain 161 receive SIP traffic from sources external to their domain through an 162 inbound proxy, which is sometimes co-located with the registrar of 163 the domain. As was the case previously, it is RECOMMENDED that 164 domains deploy dual-stack inbound proxies or, alternatively, deploy 165 both IPv4-only and IPv6-only inbound proxy servers. This allows the 166 user agents external to the autonomous domain to query DNS and 167 receive an IP address of the inbound proxy most appropriate for its 168 use (i.e., an IPv4-only user agent will query DNS for A RRs, an IPv6- 169 only user agent will query DNS for AAAA RRs, and a dual-stack user 170 agent will query DNS for all RRs and choose a specific network.) 171 This strategy; i.e., deploying dual-stack proxies, also allows for an 172 IPv6-only user agent in the autonomous domain to communicate with an 173 IPv4-only user agent in the same autonomous domain. Without such a 174 proxy, user agents using different networks identifiers will not be 175 able to successfully signal each other. 177 Proxies MUST follow the recommendations in Section 5 to determine the 178 order of the downstream servers to contact when routing a request. 180 3.1.1. Relaying Requests Across Different Networks 182 A SIP proxy server that receives a request using IPv6 and relays it 183 to a user agent (or another downstream proxy) using IPv4, and vice 184 versa, needs to remain in the path traversed by subsequent requests. 185 Therefore, such a SIP proxy server MUST be configured to Record-Route 186 in that situation. 188 Note that while this is the recommended practice, some problems 189 may still arise if a RFC2543 [14] endpoint is involved in 190 signaling. Since the ABNF in RFC2543 did not include production 191 rules to parse IPv6 network identifiers, there is a good chance 192 that a RFC2543-only compliant endpoint is not able to parse or 193 regenerate IPv6 network identifiers in headers. Thus, despite a 194 dual-stack proxy inserting itself into the session establishment, 195 the endpoint itself may not succeed in the signaling establishment 196 phase. 198 This is generally not a problem with RFC3261 endpoints; even if 199 such an endpoint runs on an IPv4-only node, it still is able to 200 parse and regenerate IPv6 network identifiers. 202 Relaying a request across different networks in this manner has other 203 ramifications. For one, the proxy doing the relaying must remain in 204 the signaling path for the duration of the session; otherwise, the 205 upstream client and the downstream server would not be able to 206 communicate directly. Second, to remain in the signaling path, the 207 proxy MUST insert one or two Record-Route headers: if the proxy is 208 inserting an URI that contains a fully qualified domain name of the 209 proxy, and that name has both IPv4 and IPv6 addresses in DNS, then 210 inserting one Record-Route header suffices. But if the proxy is 211 inserting a IP addresses in the Record-Route header, then it must 212 insert two such headers; the first Record-Route header contains the 213 proxy's IP address that is compatible with the network type of the 214 downstream server, and the second Record-Route header contains the 215 proxy's IP address that is compatible with the upstream client. 217 An example helps illustrate this behavior. In the example, we use 218 only those headers pertinent to the discussion. Other headers have 219 been omitted for brevity. In addition, only the INVITE request and 220 final response (200 OK) are shown; it is not the intent of the 221 example to provide a complete call flow that includes provisional 222 responses and other requests. 224 In this example, proxy P, responsible for the domain example.com, 225 receives a request from an IPv4-only upstream client. It proxies 226 this request to an IPv6-only downstream server. Proxy P is running 227 on a dual-stack host; on the IPv4 interface, it has an address of 228 192.0.2.1 and on the IPv6 interface, it is configured with an address 229 of 2001:db8::1 ( Appendix A contains a sample DNS zone file entry 230 that has been populated with both IPv4 and IPv6 addresses.) 231 UAC Proxy UAS 232 (IPv4) P (IPv6) 233 | (IPv4/IPv6) | 234 | | | 235 +---F1--------->| | 236 | +---F2-------->| 237 | | | 238 | |<--F3---------+ 239 |<--F4----------+ | 240 ... ... ... 241 | | | 242 V V V 244 F1: INVITE sip:alice@example.com SIP/2.0 245 ... 247 F2: INVITE sip:alice@2001:db8::10 SIP/2.0 248 Record-Route: 249 Record-Route: 250 ... 252 F3: SIP/2.0 200 OK 253 Record-Route: 254 Record-Route: 255 ... 257 F4: SIP/2.0 200 OK 258 Record-Route: 259 Record-Route: 260 ... 262 Figure 1: Relaying requests across different networks. 264 When the UAS gets an INVITE and it accepts the invitation, sends a 265 200 OK (F3) and forms a route set. The first entry in its route set 266 corresponds to the proxy's IPv6 interface. Similarly, when the 200 267 OK reaches the UAC (F4), it creates a route set by following the 268 guidelines of RFC3261 and reversing the Record-Route headers. The 269 first entry in its route set corresponds to the proxy's IPv4 270 interface. In this manner, both the UAC and the UAS will have the 271 correct address of the proxy to which they can target subsequent 272 requests. 274 Alternatively, the proxy could have inserted its fully-qualified 275 domain name (FQDN) in the Record-Route URI and the result would have 276 been the same. This is because the proxy has both IPv4 and IPv6 277 addresses in the DNS; thus the URI resolution would have yielded an 278 IPv4 address to the UAC and an IPv6 address to the UAS. 280 3.2. User Agent Behavior 282 User agent clients MUST follow the normative text specified in 283 Section 4.2 to gather IP addresses pertinent to the network. Having 284 done that, clients MUST follow the recommendations in Section 5 to 285 determine the order of the downstream servers to contact when routing 286 a request. 288 Autonomous domains SHOULD deploy dual-stack user agent servers, or 289 alternatively, deploy both IPv4-only and IPv6-only servers. In 290 either case, RR in DNS for reaching the server should be specified 291 appropriately. 293 4. The Media Layer 295 SIP establishes media sessions using the offer/answer model [4]. One 296 endpoint, the offerer, sends a session description (the offer) to the 297 other endpoint, the answerer. The offer contains all the media 298 parameters needed to exchange media with the offerer: codecs, 299 transport addresses, protocols to transfer media, etc. 301 When the answerer receives an offer, it elaborates an answer and 302 sends it back to the offerer. The answer contains the media 303 parameters that the answerer is willing to use for that particular 304 session. Offer and answer are written using a session description 305 protocol. The most widespread protocol to describe sessions at 306 present is called, aptly enough, the Session Description Protocol 307 (SDP[2]). 309 A direct offer/answer exchange between an IPv4-only user agent and an 310 IPv6-only user agent does not result in the establishment of a 311 session. The IPv6-only user agent wishes to receive media on one or 312 more IPv6 addresses, but the IPv4-only user agent cannot send media 313 to these addresses, and generally does not even understand their 314 format. Consequently, user agents need a means to obtain both IPv4 315 and IPv6 addresses to receive media and to place them in offers and 316 answers. 318 This IP version incompatibility problem would not exist if hosts 319 implementing IPv6 also implemented IPv4, and were configured with 320 both IPv4 and IPv6 addresses. In such a case, a UA would be able 321 to pick a compatible media transport address type to communicate 322 with each other. 324 Pragmatism dictates that IPv6 user agents undertake the greater 325 burden in the transition period. Since IPv6 user agents are not 326 widely deployed yet, it seems appropriate that IPv6 user agents 327 obtain IPv4 addresses instead of mandating an upgrade on the 328 installed IPv4 base. Furthermore, IPv6 user agents are expected to 329 be dual-stacked and thus also support IPv4, unlike the larger IPv4- 330 only user agent base that does not or cannot support IPv6. 332 An IPv6 node SHOULD also be able to send and receive media using IPv4 333 addresses, but if it cannot, it SHOULD support STUN relay usage [8]. 334 Such a relay allows the IPv6 node to indirectly send and receive 335 media using IPv4. 337 The advantage of this strategy is that the installed base of IPv4 338 user agents continues to function unchanged, but it requires an 339 operator that introduces IPv6 to provide additional servers for 340 allowing IPv6 user agents to obtain IPv4 addresses. This strategy 341 may come at an additional cost to SIP operators deploying IPv6. 342 However, since IPv4-only SIP operators are also likely to deploy STUN 343 relays for NAT (Network Address Translators) traversal, the 344 additional effort to deploy IPv6 in an IPv4 SIP network should be 345 limited in this aspect. 347 However, there will be deployments where an IPv4/IPv6 node is unable 348 to use both interfaces natively at the same time, and instead, runs 349 as an IPv6-only node. Examples of such deployments include: 351 1. Networks where public IPv4 addresses are scarce and it is 352 preferable to make large deployments only on IPv6. 353 2. Networks utilizing Layer-2's that do not support concurrent IPv4 354 and IPv6 usage on the same link. 356 4.1. Updates to RFC3264 358 This section provides a normative update to RFC 3264 [4] in the 359 following manner: 361 1. In some cases, especially those dealing with third party call 362 control (see Section 4.2 of [12]), there arises a need to specify 363 the IPv6 equivalent of the IPv4 unspecified address (0.0.0.0) in 364 the SDP offer. For this, IPv6 implementations MUST use a domain 365 name within the .invalid DNS top-level domain instead of using 366 the IPv6 unspecified address (i.e., ::). 367 2. Each media description in the SDP answer MUST use the same 368 network type as the corresponding media description in the offer. 369 Thus, if the applicable "c=" line for a media description in the 370 offer contained a network type with the value "IP4", the 371 applicable "c=" line for the corresponding media description in 372 the answer MUST contain "IP4" as the network type. Similarly, if 373 the applicable "c=" line for a media description in the offer 374 contained a network type with the value "IP6", the applicable 375 "c=" line for the corresponding media description in the answer 376 MUST contain "IP6" as the network type. 378 4.2. Initial Offer 380 We now describe how user agents can gather addresses by following the 381 Interactive Connectivity Establishment (ICE, [7]) procedures. ICE is 382 protocol that allows two communicating user agents to arrive at a 383 pair of mutually reachable transport addresses for media 384 communications in the presence of NATs. It uses the Session 385 Traversal Utilities for NAT (STUN, [18]) protocol, applying its 386 binding discovery and relay usages. 388 When following the ICE procedures, in addition to local addresses, 389 user agents may need to obtain addresses from relays; for example, an 390 IPv6 user agent would obtain an IPv4 address from a relay. The relay 391 would forward the traffic received on this IPv4 address to the user 392 agent using IPv6. Such user agents MAY use any mechanism to obtain 393 addresses in relays, but, following the recommendations in ICE, it is 394 RECOMMENDED that user agents support STUN relay usage [6] [8] for 395 this purpose. 397 IPv4/IPv6 user agents SHOULD gather both IPv4 and IPv6 addresses 398 using the ICE procedures to generate all their offers. This way, 399 both IPv4-only and IPv6-only answerers will be able to generate a 400 mutually acceptable answer that establishes a session (having used 401 ICE to gather both IPv4 and IPv6 addresses in the offer reduces the 402 session establishment time because all answerers will find the offer 403 valid.) 405 Implementations are encouraged to use ICE; however, the normative 406 strength of the text above is left at a SHOULD since in some 407 managed networks (such as a closed enterprise network) it is 408 possible for the administrator to have control over the IP version 409 utilized in all nodes and thus deploy an IPv6-only network, for 410 example. The use of ICE can be avoided for signaling messages 411 that stay within such managed networks. 413 4.3. Connectivity Checks 415 Once the answerer has generated an answer following the ICE 416 procedures, both user agents perform the connectivity checks as 417 specified by ICE. These checks help prevent some types of flooding 418 attacks and allow user agents to discover new addresses that can be 419 useful in the presence of NATs. 421 5. Contacting Servers: Interaction of RFC3263 and RFC3484 423 RFC3263 maps a SIP or SIPS URI to a set of DNS SRV records for the 424 various servers that can handle the URI. The Expected Output, given 425 an Application Unique String (the URI) is one or more SRV records, 426 sorted by the "priority" field, and further ordered by the "weight" 427 field in each priority class. 429 The terms "Expected Output" and "Application Unique String", as 430 they are to be interpreted in the context of SIP, are defined in 431 Section 8 of RFC3263 [5]. 433 To find a particular IP address to send the request to, the client 434 will eventually perform an A or AAAA DNS lookup on a target. As 435 specified in RFC3263, this target will have been obtained through 436 NAPTR and SRV lookups, or if NAPTR and SRV lookup did not return any 437 records, the target will simply be the domain name of the Application 438 Unique String. In order to translate the target to the corresponding 439 set of IP addresses, IPv6-only or dual-stack clients MUST use the 440 newer getaddrinfo() name lookup function, instead of gethostbyname() 441 [16]. The new function implements the Source and Destination Address 442 Selection algorithms specified in RFC3484 [9], which is expected to 443 be supported by all IPv6 hosts. 445 The advantage of the additional complexity is that this technique 446 will output an ordered list of IPv6/IPv4 destination addresses based 447 on the relative merits of the corresponding source/destination pairs. 448 This will guarantee optimal routing. However, the Source and 449 Destination Selection algorithms of RFC3484 are dependent on broad 450 operating system support and uniform implementation of the 451 application programming interfaces that implement this behavior. 453 Developers should carefully consider the issues described by Roy 454 et al. [19] with respect to address resolution delays and address 455 selection rules. For example, implementations of getaddrinfo() 456 may return address lists containing IPv6 global addresses at the 457 top of the list and IPv4 addresses at the bottom, even when the 458 host is only configured with an IPv6 local scope (e.g., link- 459 local) and an IPv4 address. This will, of course, introduce a 460 delay in completing the connection. 462 6. IANA Considerations 464 This document does not contain any actions for the IANA. 466 7. Security Considerations 468 This document describes how IPv4 SIP user agents can communicate with 469 IPv6 user agents (and vice versa). To do this, it uses additional 470 protocols (STUN relay usage [6], ICE [7], SDP [2]); the threat model 471 of each such protocol is included in its respective document. The 472 procedures introduced in this document do not introduce the 473 possibility of any new security threats; however, they may make hosts 474 more amenable to existing threats. Consider, for instance, a UAC 475 that allocates an IPv4 and IPv6 addresses locally and inserts these 476 into the SDP. Malicious user agents that may intercept the request 477 can mount a denial of service attack targeted to the different 478 network interfaces of the UAC. In such a case, the UAC should use 479 mechanisms that protect confidentiality and integrity of the 480 messages, such as using the SIPS URI scheme as described in Section 481 26.2.2 of RFC3261 [3], or secure MIME as described in Section 23 of 482 RFC3261 [3]. If HTTP Digest is used as an authentication mechanism 483 in SIP, then the UAC should ensure that the quality of protection 484 also includes the SDP payload. 486 8. Acknowledgment 488 The authors would like to thank Mohamed Boucadair, Christine Fischer, 489 Cullen Jennings, Aki Niemi, Jonathan Rosenberg, and Robert Sparks for 490 discussions on the working group list that improved the quality of 491 this document. 493 Additionally, Francois Audet, Mary Barnes, Keith Drage, and Dale 494 Worley provided invaluable comments as part of the working group last 495 call review process. Jari Arkko, Lars Eggert, Tobias Gondrom, Suresh 496 Krishnan, and Tim Polk conducted an in-depth review of the work as 497 part of IESG and Gen-ART reviews. 499 9. References 501 9.1. Normative References 503 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 504 Levels", RFC 2119, March 1997. 506 [2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 507 Description Protocol", RFC 4566, July 2006. 509 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 510 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 511 Session Initiation Protocol", RFC 3261, June 2002. 513 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 514 the Session Description Protocol (SDP)", RFC 3264, June 2002. 516 [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 517 (SIP): Locating SIP Servers", RFC 3263, June 2002. 519 [6] Rosenberg, J., Mahy, R., and C. Huitema, "Traversal Using 520 Relays around NAT (TURN): Relay Extensions to Session Traversal 521 Utilities for NAT (STUN)", draft-ietf-behave-turn-04 (work in 522 progress), July 2007. 524 [7] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 525 Methodology for Network Address Translator (NAT) Traversal for 526 Offer/Answer Protocols", draft-ietf-mmusic-ice-17 (work in 527 progress), July 2007. 529 [8] Camarillo, G. and O. Novo, "Extensions to the Simple Traversal 530 Underneath NAT (STUN) Relay Usage for IPv4/IPv6 Transition", 531 draft-ietf-behave-turn-ipv6-03 (work in progress), July 2007. 533 [9] Draves, R., "Default Address Selection for Internet Protocol 534 Version 6 (IPv6)", RFC 3484, Feb 2003. 536 9.2. Informational References 538 [10] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv6) 539 Options for Session Initiation Protocol (SIP) Servers", 540 RFC 3319, July 2003. 542 [11] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP- 543 for-IPv4) Option for Session Initiation Protocol (SIP) 544 Servers", RFC 3361, August 2002. 546 [12] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 547 "Best Current Practices for Third Party Call Control (3pcc) in 548 the Session Initiation Protocol (SIP)", RFC 3725. 550 [13] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 551 "RTP: A Transport Protocol for Real-Time Applications", 552 RFC 3550, July 2003. 554 [14] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, 555 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 557 [15] Gurbani, V., Boulton, C., and R. Sparks, "Session Initiation 558 Protocol (SIP) Torture Test Messages for Internet Protocol 559 Version 6 (IPv6)", draft-ietf-sipping-ipv6-torture-tests-03 560 (work in progress), May 2007. 562 [16] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, 563 "Application Aspects of IPv6 Transition", RFC 4038, March 2005. 565 [17] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 566 IPv6 Hosts and Routers", RFC 4213, October 2005. 568 [18] Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D. 569 Wing, "Session Traversal Utilities for Network Address 570 Translators (NAT) (STUN) (STUN)", 571 draft-ietf-behave-rfc3489bis-08 (work in progress), July 2007. 573 [19] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On- 574 Link Assumption Considered Harmful", 575 draft-ietf-v6ops-onlinkassumption-04.txt (work in progress), 576 January 2006. 578 Appendix A. Sample IPv4/IPv6 DNS File 580 A portion of a sample DNS zone file entry is reproduced below that 581 has both IPv4 and IPv6 addresses. This entry corresponds to a proxy 582 server for the domain "example.com". The proxy server supports the 583 Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) 584 transport for both IPv4 and IPv6 networks. 586 ... 587 _sip._tcp SRV 20 0 5060 sip1.example.com 588 SRV 0 0 5060 sip2.example.com 589 _sip._udp SRV 20 0 5060 sip1.example.com 590 SRV 0 0 5060 sip2.example.com 592 sip1 IN A 192.0.2.1 593 sip1 IN AAAA 2001:db8::1 594 sip2 IN A 192.0.2.2 595 sip2 IN AAAA 2001:db8::2 596 ... 598 Authors' Addresses 600 Gonzalo Camarillo 601 Ericsson 602 Hirsalantie 11 603 Jorvas 02420 604 Finland 606 Email: Gonzalo.Camarillo@ericsson.com 608 Karim El Malki 609 Athonet 611 Email: karim@athonet.com 613 Vijay K. Gurbani 614 Bell Laboratories, Alcatel-Lucent 615 2701 Lucent Lane 616 Rm 9F-546 617 Lisle, IL 60532 618 USA 620 Phone: +1 630 224 0216 621 Email: vkg@alcatel-lucent.com 623 Full Copyright Statement 625 Copyright (C) The IETF Trust (2007). 627 This document is subject to the rights, licenses and restrictions 628 contained in BCP 78, and except as set forth therein, the authors 629 retain all their rights. 631 This document and the information contained herein are provided on an 632 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 633 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 634 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 635 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 636 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 637 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 639 Intellectual Property 641 The IETF takes no position regarding the validity or scope of any 642 Intellectual Property Rights or other rights that might be claimed to 643 pertain to the implementation or use of the technology described in 644 this document or the extent to which any license under such rights 645 might or might not be available; nor does it represent that it has 646 made any independent effort to identify any such rights. Information 647 on the procedures with respect to rights in RFC documents can be 648 found in BCP 78 and BCP 79. 650 Copies of IPR disclosures made to the IETF Secretariat and any 651 assurances of licenses to be made available, or the result of an 652 attempt made to obtain a general license or permission for the use of 653 such proprietary rights by implementers or users of this 654 specification can be obtained from the IETF on-line IPR repository at 655 http://www.ietf.org/ipr. 657 The IETF invites any interested party to bring to its attention any 658 copyrights, patents or patent applications, or other proprietary 659 rights that may cover technology that may be required to implement 660 this standard. Please address the information to the IETF at 661 ietf-ipr@ietf.org. 663 Acknowledgment 665 Funding for the RFC Editor function is provided by the IETF 666 Administrative Support Activity (IASA).