idnits 2.17.1 draft-klatsky-dispatch-ipv6-impact-ipv4-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 7, 2014) is 3673 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3986' is mentioned on line 352, but not defined == Missing Reference: 'RFC5954' is mentioned on line 354, but not defined == Missing Reference: 'RFC5952' is mentioned on line 356, but not defined == Missing Reference: 'RFC6947' is mentioned on line 392, but not defined -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH C. Klatsky, Ed. 3 Internet-Draft Comcast 4 Intended status: Informational O. Johansson 5 Expires: October 9, 2014 Edvina 6 R. Shekh-Yusef 7 Avaya 8 A. Hutton 9 Siemens Enterprise Communications 10 G. Salgueiro 11 Cisco Systems 12 April 7, 2014 14 Interoperability Impacts of IPv6 Interworking 15 with Existing IPv4 SIP Implementations 16 draft-klatsky-dispatch-ipv6-impact-ipv4-03 18 Abstract 20 This document captures potential impacts to IPv4 SIP implementations 21 when interworking with IPv6 SIP implementations. Although some 22 amount of interworking translation will occur at the network and 23 application layers, an IPv4 SIP application may still encounter a SIP 24 message with some IPv6 values in it, resulting in unforeseen error 25 conditions. Such potential scenarios will be identified in this 26 document so that SIP application developers can define solutions to 27 handle these cases. Note, this document is not intended to be an 28 exhaustive list, rather to provide an overview of some of the more 29 commonly encountered potential scenarios. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 9, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology and Conventions Used in This Document . . . . . . 3 67 3. Potential IPv4/IPv6 Interoperability Failure Scenarios . . . 3 68 3.1. IPv6 Address Handling in Via Headers . . . . . . . . . . 4 69 3.2. IPv6 Address Handling in Record-Route and Route Headers . 4 70 3.3. IPv6 Address Handling in From / To / Contact Headers . . 4 71 3.4. IPv6 Address Handling in SDP Body . . . . . . . . . . . . 5 72 3.5. IPv6 Address Handling in 'reginfo' XML Registration 73 Information Document . . . . . . . . . . . . . . . . . . 5 74 3.6. IPv6 Address Handling in 30x Redirect . . . . . . . . . . 5 75 3.7. IPv6 Address Handling in REFER-based Transfer . . . . . . 5 76 3.8. DNS Resolution of IPv4/IPv6 in SRV Records . . . . . . . 6 77 3.9. IPv6 Address Handling in Multiple Contact Registrations . 6 78 3.10. Unsupported Address . . . . . . . . . . . . . . . . . . . 6 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 84 7.2. Informative References . . . . . . . . . . . . . . . . . 7 85 Appendix A. Additional Guidelines . . . . . . . . . . . . . . . 8 86 A.1. IPv6 Implementation Guidelines . . . . . . . . . . . . . 8 87 A.2. IPv6/IPv4 Interworking Function: Avoid IPv6 address 88 Leakage? . . . . . . . . . . . . . . . . . . . . . . . . 9 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 91 1. Introduction 93 The continued proliferation of IPv6 infrastructure deployments has 94 resulted in more IPv6 Session Initiation Protocol (SIP) User Agents 95 (UAs) being turned up on the network. Considering the large deployed 96 install base of IPv4 SIP UAs developed prior to the widespread 97 deployment of IPv6, it is a well known fact that not all IPv4 SIP UAs 98 have taken into account all possible IPv4 SIP-to-IPv6 SIP 99 interoperability considerations at the time of their development. 100 The scenarios outlined in this document are intended as guidance for 101 application developers to help identify solutions to resolve the 102 identified interoperability challenges. 104 2. Terminology and Conventions Used in This Document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 RFC 3261 [RFC3261] defines additional terms used in this document 111 that are specific to the SIP domain such as "proxy"; "registrar"; 112 "redirect server"; "user agent server" or "UAS"; "user agent client" 113 or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog"; 114 "transaction"; "server transaction". 116 This document uses the term "SIP Server" that is defined to include 117 the following SIP entities: user agent server, registrar, redirect 118 server, a SIP proxy in the role of user agent server, and a B2BUA in 119 the role of a user agent server. 121 This document also uses the following terminology to make clear 122 distinction between SIP entities supporting only IPv4, only IPv6 or 123 supporting both IPv4 and IPv6. 125 IPv4-only UA/UAC/UAS: An IPv4-only UA/UAC/UAS supports SIP signaling 126 and media only on the IPv4 network. It does not understand IPv6 127 addresses. 129 IPv6-only UA/UAC/UAS: An IPv6-only UA/UAC/UAS supports SIP signaling 130 and media only on the IPv6 network. It does not understand IPv4 131 addresses. 133 IPv4/IPv6 UA/UAC/UAS: A UA/UAC/UAS that supports SIP signaling and 134 media on both IPv4 and IPv6 networks; such a UA/UAC/UAS is known 135 (and will be referred to in this document) as a "dual-stack" 136 [RFC4213] UA/UAC/UAS. 138 3. Potential IPv4/IPv6 Interoperability Failure Scenarios 139 3.1. IPv6 Address Handling in Via Headers 141 As an IPv6 SIP message makes its way through the network, the Via 142 header is updated and includes specific IPv6 addresses of IPv6 nodes 143 that it has traversed. If the message arrives at an IPv4-only UAS it 144 may still contain those IPv6 addresses in the Via header. Presumably 145 the topmost Via header references an IPv4 address or a Fully 146 Qualified Domain Name (FQDN) resolvable to any IPv4 address. In this 147 case the IPv4-only UAS is able to send its response on to its next 148 hop, otherwise the message would not have made it to the IPv4-only UA 149 at all. The challenge for the IPv4-only UA then becomes to not 150 generate an error even if the other Via headers that it does not need 151 to act upon contain IPv6 addresses. 153 3.2. IPv6 Address Handling in Record-Route and Route Headers 155 Similar to the concerns of having IPv6 addresses in the Via headers, 156 IPv4 SIP UAS may also encounter Record-Route headers that contain 157 IPv6 addresses of IPv6 nodes the SIP message has traversed. It is 158 again assumed that if the SIP message arrives at an IPv4-only UA that 159 the topmost Record-Route header references an IPv4 address or a FQDN 160 resolvable to any IPv4 address, such that the response may be routed 161 back to a node reachable by the IPv4-only UAS. In this instance the 162 IPv4-only UA should not generate an error when parsing the IPv6 163 addresses. Additionally, the IPv4-only UA may also need to populate 164 the Route header in the response that includes the IPv6 addresses 165 learned from previously received Record-Route header, and again do so 166 without generating an error. 168 3.3. IPv6 Address Handling in From / To / Contact Headers 170 Another scenario with possible IPv6-to-IPv4 interoperability 171 implications is the case where the IPv4-only UAS receives an IPv6 172 address in the Contact header and no Record-Route header. Since this 173 represents the peer's reachable contact IP, it may not have been 174 modified by any interworking element in the communications path. The 175 IPv4-only UAS will have to send its requests through its outbound SIP 176 server, and not generate an error upon receipt of a message with this 177 IPv6 information. 179 In addition, using an IP address instead of domain in To and/or From 180 headers may impact communication, as the From header is used for 181 other communication sessions or added to a phone book. 183 3.4. IPv6 Address Handling in SDP Body 185 IPv4-only UASs may also receive SDP offers with IPv6 addresses in the 186 Session Description Protocol (SDP) [RFC4566] portion of the message. 187 An IPv6 address can appear in multiple places in the SDP, such as the 188 o= line, c= line or a= lines (for Interactive Connectivity 189 Establishment (ICE) [RFC5245] attributes). A working assumption is 190 that minimally the c= line will reference an IPv4 address of a media 191 interworking element to allow the media communications being 192 established by this session to work. Nonetheless the IPv4-only UAS 193 needs be aware and properly handle any IPv6 addresses that may be 194 within the received SDP. 196 3.5. IPv6 Address Handling in 'reginfo' XML Registration Information 197 Document 199 There may be instances where an IPv4-only UAC subscribes to the 200 registration event package [RFC3680] as a "watcher" for a specific 201 entity, to be informed of registration state changes for that entity. 202 The "watcher" may have no knowledge of the IP address family in use 203 on the "watched" entity, and it is possible that a NOTIFY indicating 204 an IPv6 address in the Extensible Markup Language (XML) [XML] body is 205 received. The "watcher" needs to properly parse such a NOTIFY and 206 provide the status update of the "watched" entity to the user or 207 system that requested the information. This would be the case when 208 an IPv6 SIP client registration is being "watched". 210 3.6. IPv6 Address Handling in 30x Redirect 212 There may be scenarios where an IPv4-only UAC receives a 30x redirect 213 message in response to a request it has sent. This 30x message may 214 contain a Contact header with an IPv6 address. This is the case 215 where the call is being redirected to an IPv6-only UAS. Since this 216 represents the peer's reachable contact IP, it may not have been 217 modified by any interworking element in the communications path. 219 If the UAC has a configured outbound proxy the new call will be setup 220 to that proxy. If that proxy is not dual stack, the call will fail. 221 If there's no outbound proxy configured, the call will fail. If the 222 UAC is a soft phone or hard phone, an error message should be 223 displayed. 225 3.7. IPv6 Address Handling in REFER-based Transfer 227 After establishing a call between two IPv4-only UAs, one of the 228 parties in the call may attempt to transfer the other party to a 3rd 229 party using the REFER method [RFC5589]. This transfer may be to an 230 IPv6-only UAS. The implication is that both IPv4-only UASs involved 231 in the call transfer need to be able to handle a REFER with an IPv6 232 address in the Refer-To header. The transferor needs to be able to 233 form the proper REFER message with the IPv6 Contact and the 234 transferee needs to be able to process the REFER message and attempt 235 to establish a call with the transfer target. 237 3.8. DNS Resolution of IPv4/IPv6 in SRV Records 239 A dual-stack UA may use the Domain Name System (DNS) SRV mechanism to 240 resolve addresses of proxies that it needs to communicate with. In 241 such a case it needs to be able to locate both IPv4 proxies and IPv6 242 proxies. This implies that the DNS server has been updated with both 243 A and AAAA records for the SIP server, and that the dual-stack UA 244 requests for both IPv4 and IPv6 SIP server addresses. 246 3.9. IPv6 Address Handling in Multiple Contact Registrations 248 A 200 OK to a REGISTER request might include multiple Contact headers 249 because the user has registered his or her Address of Record (AOR) on 250 multiple clients. Some of these Contact headers might have IPv6 251 addresses. An IPv4-only UAC must be able to handle the IPv6 252 information properly. 254 3.10. Unsupported Address 256 If the endpoint is an IPv4-only client and it receives a request with 257 an SDP offer that has IPv6 address(es) only, the IPv4-only client 258 should decline the request by returning 488 "Not Acceptable Here" (as 259 defined in section 13.3.1.2 of RFC3261) with Warning header that has 260 warning code of 301 "Incompatible Network Address Formats" (as 261 defined in section 20.43 of RFC3261). If the ipv4-only client 262 receives a request with an SDP offer that has a mixed set of IPv4 and 263 IPv6 addresses, then the IPv4-only client should accept the IPv4 264 address(es) and decline the IPv6 address(es) by setting the port 265 number in the m-line to zero. 267 4. Security Considerations 269 This document merely describes the potential impacts of IPv6 on IPv4 270 SIP implementations. The scenarios discussed in this informational 271 document do not introduce any new security threats. The specific 272 security vulnerabilities, attacks, threat models of the various 273 protocols discussed in this document (SIP, SDP, ICE, etc.) are well 274 documented in their respective documents. 276 5. IANA Considerations 278 This document does not require actions by IANA. 280 6. Acknowledgements 282 The authors would like to acknowledge the support and contribution of 283 the SIP Forum IPv6 Working Group. Mohamed Boucadair has contributed 284 significant ideas and text. Dan Wing, Hadriel Kaplan, Paul Kyzivat, 285 Dale Worley, and Neel Neelakantan have all provided a detailed review 286 of the document and thoughtful comments. 288 7. References 290 7.1. Normative References 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 7.2. Informative References 297 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 298 A., Peterson, J., Sparks, R., Handley, M., and E. 299 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 300 June 2002. 302 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 303 Package for Registrations", RFC 3680, March 2004. 305 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 306 for IPv6 Hosts and Routers", RFC 4213, October 2005. 308 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 309 Description Protocol", RFC 4566, July 2006. 311 [RFC5118] Gurbani, V., Boulton, C., and R. Sparks, "Session 312 Initiation Protocol (SIP) Torture Test Messages for 313 Internet Protocol Version 6 (IPv6)", RFC 5118, February 314 2008. 316 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 317 (ICE): A Protocol for Network Address Translator (NAT) 318 Traversal for Offer/Answer Protocols", RFC 5245, April 319 2010. 321 [RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session 322 Initiation Protocol (SIP) Call Control - Transfer", BCP 323 149, RFC 5589, June 2009. 325 [XML] Sperberg-McQueen, C., Yergeau, F., Bray, T., Maler, E., 326 and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth 327 Edition)", World Wide Web Consortium Recommendation REC- 328 xml-20081126, November 2008, 329 . 331 Appendix A. Additional Guidelines 333 Some additional interoperability guidelines are presented in this 334 section. 336 A.1. IPv6 Implementation Guidelines 338 This section lists basic IPv6 recommendations for SIP 339 implementations: 341 To avoid parsing errors, IPv6 address MUST be delimited by "[" and " 342 ]" in the following cases: 344 * If an IPv6 address is included in a SIP Request URI 345 * If an IPv6 address is included in a SIP "Via" header 346 * If an IPv6 address is included in a SIP "Contact" header 348 No delimiters are needed for other SIP tags such as "received" or 349 even at the SDP level. 351 The SIP ABNF for IPv6 reference defined in [RFC3261] MUST NOT be 352 used. Instead, rules defined in [RFC3986] MUST be supported. 354 To compare SIP URIs, [RFC5954] MUST be used instead of [RFC3261]. 356 [RFC5952] MUST be supported for IPv6 textual representation purposes. 358 An IPv6-enabled SIP MUST NOT include any loopback address (::1) or 359 link local address (fe80) in SIP headers and SDP body. 361 The offer/answer does not include IP Address in negotiation aspects 362 and doesn't distinguish IPv4/IPv6. If the dual stack IPv4/IPv6 UAS 363 receives an INVITE from IPv4 endpoint, based on Contact information, 364 it should respond using the offer (IPv4/IPv6) in media/c= for better 365 interoperability. 367 A IPv6 implementation parsers can be checked by running the test 368 cases defined in [RFC5118] 370 A.2. IPv6/IPv4 Interworking Function: Avoid IPv6 address Leakage? 372 The introduction of IPv6-enabled SIP UAs may lead to some failure 373 issues of the legacy (IPv4-only) UA are unable to parse IPv6 374 addresses. To prevent those failure cases, an IPv6/IPv4 Interworking 375 Function may be deployed in the SIP infrastructure to adapt SIP 376 messages. In particular, this interworking function may be 377 configured to avoid leaking any IPv6 address to a legacy IPv4-only 378 SIP UA (and vice versa). An IPv6-only SIP UA will be seen by a 379 remote IPv4-only SIP UA as any legacy IPv4-only SIP UA. Leaking IPv6 380 addresses in headers is a concern only for headers used for session 381 routing purposes (e.g., topmost via, contact, etc.). 383 Within managed SIP networks, the impact of leaking addresses of 384 distinct address family should be assessed through testing campaigns. 385 If no failures are experienced, enabling the function which prevents 386 leaking addresses of distinct address family may be avoided. 388 In order to promote the use of IPv6 transfer capabilities and avoid 389 extensive usage of IPv4/IPv6 interworking resources, leaking IPv6 390 addresses in a backward compatible manner should be encouraged. For 391 instance, the SDP offer can include both IPv4 and IPv6 addresses 392 (e.g., [RFC6947]). The address family to be used to place the 393 session will be decided by the remote peer. 395 When both IPv4 and IPv6 SIP UA are deployed in a network, the SIP 396 Proxy Server will need a trigger to decide whether invoking IPv4/IPv6 397 Interworking function is required; otherwise IPv4/IPv6 IWF resources 398 won't be optimized. A potential solution for this problem is 399 discussed in [I-D.boucadair-dispatch- ipv6-atypes]. Relying on the 400 address of contact is not deterministic since a dual-stack SIP UA may 401 be registered with its IPv4 address while it supports also IPv6. 403 Authors' Addresses 405 Carl Klatsky (editor) 406 Comcast 407 1717 Arch St. 408 Philadelphia, PA 19103 409 US 411 Email: carl_klatsky@cable.comcast.com 412 Olle E. Johansson 413 Edvina 414 Runbovaegen 10 415 Sollentuna SE-192 48 416 SE 418 Email: oej@edvina.net 420 Rifaat Shekh-Yusef 421 Avaya 422 250 Sidney Street 423 Belleville, Ontario 424 Canada 426 Email: rifatyu@avaya.com 428 Andrew Hutton 429 Siemens Enterprise Communications 430 Technology Drive 431 Nottingham NG9 1LA 432 UK 434 Email: andrew.hutton@siemens-enterprise.com 436 Gonzalo Salgueiro 437 Cisco Systems 438 7200-12 Kit Creek Road 439 Research Triangle Park, NC 27709 440 US 442 Email: gsalguei@cisco.com