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