SIPPING Working Group Internet Draft Expires: August 2003

J. Mulahusic H. Persson Telia February 2003

SIP Issues in Dual-stack Environments draft-persson-sipping-sip-issues-dual-stack-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [i]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as InternetDrafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The advent of IPv6 in addition to IPv4 makes hosts and servers dualstack. SIP communications can be used in both environments but there is little understanding what will happen if some nodes are dual-stack while others, presently the majority, is IPv4 only enabled. This document describes some scenarios and associated issues when dualstack users and servers try to communicate with IPv4 only hosts using SIP. It is not evident that interoperability is achieved, and if that is not the case, this would severely limit the usability of both SIP and IPv6. 1. Introduction

Mulahusic & Persson

Expires - August 2003

[Page 1]

SIP Issues in Dual-stack Environments

February 2003

Currently, the vast majority of the Internet hosts are IPv4-only. As the IPv6 adoption on the Internet is growing, more and more hosts are going to be dual-stack enabled, i.e. they will support both IPv4 and IPv6. A relatively easy step to make services available to all clients regardless of which network protocol they are utilizing (IPv4-only or dual-stack clients) is to have servers understand both IP versions, i.e. have servers be dual-stack. Note that making servers available over both network protocols will still not solve the NAT-related end-to-end issues, as some clients may still be located behind NAT boxes. The SIP communication between IPv4-only hosts and dual-stack enabled hosts, but which is bypassing dual-stack enabled servers, can in some perfectly regular cases according to SIP operation, introduce failure modes not described in the SIP standard [RFC3261]. This may lead to inability to initiate and set-up sessions between pairs of hosts, which in practice should be possible since the hosts support same IP versions. One of the basic presumptions made here is that IPv6 is being gradually deployed in an IPv4 environment by upgrading existing IPv4 nodes to dual-stack or deploying new dual-stack nodes. Accordingly, IPv4 servers have been made available to dual-stack clients by being upgraded to dual-stack servers. However, there may exist a number of clients that cannot be upgraded to dual-stack and will thus not be able to support the new IP protocol. Deploying IPv6-only clients and SIP communication between IPv4-only and IPv6-only clients has not been considered as interesting and has not been analyzed in this document. Perhaps a more interesting case for the nearer future would be to consider dual-stack SIP servers and single-stack (IPv4-only) SIP servers and scenarios derived from this case. However, the scenarios described here are felt to be more general and the case with singlestack SIP servers is considered to be a sub-set of the more general scenario cases described in this document. The inability to initiate communication between the hosts supporting several IP versions can have two causes. Either the host initiating the session can not in advance find out what IP version a peer on the other end is supporting or the inability of the other side to unambiguously signal that the IP version chosen by the host initiating the session is not supported by the target host. The inability to in advance find out what IP version(s) the target host is supporting cannot be done as this information is only known to, possibly, the SIP server with which the target host has registered or, usually the case, the client itself. The SIP does not have any mechanism defined to acquire such information in advance. Mulahusic & Persson Expires - August 2003 [Page 2]

SIP Issues in Dual-stack Environments

February 2003

There exist a number of final responses that might be used to signal that the target client do not support the IP version chosen by the initiating host, but none of the available responses are felt to unambiguously describe the failure reason. The purpose of this document is to highlight the issue when dualstack hosts initiate SIP sessions towards IPv4-only hosts. Specifying mechanisms to cope with these events would greatly increase the interoperability between hosts/networks of dual-stack type and IPv4only hosts/networks. 2. Scenario I, First try IPv6 and if error try IPv4 This is scenario when both users that wish to communicate are located behind dual-stack SIP servers. The host initiating the session is registered with its SIP server with both IPv4 and IPv6 addresses. The target user is on the other hand IPv4-only and is therefore registered only with its IPv4 address, even though the SIP server it is registered with is dual-stack. When the originating host initiates a session it will, perhaps due to local policy or some other valid reason, choose IPv6 as the default network protocol to send initial INVITE to the first hop SIP server which is in this case dual-stack. Choosing IPv6 as the default network protocol can mean that the contact address in the SIP header will be an IPv6 address. The SIP server will, after elsewhere defined SIP mechanisms [RFC3261], forward the request to the next hop SIP server, which is again dual-stack in this case. When finally, the request reaches SIP server of the destination host, the contact address in the request may be the IPv6 address of the host originating the request. The target host�s SIP server will be able to process and understand the request, according to the SIP procedures described elsewhere [RFC3261], since this server is also a dual-stack server. However, the target SIP server may or may not be able to discover that the request contains IPv6 addresses, which the target host may not understand. If the server is able to find out that the request cannot be understood by the target host, e.g. the target host has only registered with an IPv4 address; the server may choose to reply with some type of response to the originating host. Likewise, the server may choose to forward the message and let the target host deal with the request. If the target SIP server has chosen to respond with a final response, it will respond to the originating host to try again with another

Mulahusic & Persson

Expires - August 2003

[Page 3]

SIP Issues in Dual-stack Environments

February 2003

version of the network protocol as this one is not supported by the target host. example1.com . . . example2.com . proxy proxy . . dual-stack dual-stack . Alice's . . . . . . . . . . . . . . . . . . . . Bob's softphone SIP Phone dual-stack IPv4-only | | | | | INVITE (IPv6) | | | |--------------->| INVITE (IPv6) | | | 100 Trying |--------------->| | |<---------------|Error Try (IPv4)| | | Error Try(IPv4)|<-------------- | | |<---------------| | | | INVITE (IPv4) | | | |--------------->| INVITE (IPv4) | | | 100 Trying |--------------->| INVITE (IPv4) | |<---------------| 100 Trying |--------------->| | |<---------------| 180 Ringing | | | 180 Ringing |<---------------| | |<---------------| | . . . Figure 1: Scenario I setup example Figure 1 illustrates the example when a dual-stack host is initiating a SIP session towards an IPv4-only host. Since proxy servers involved in the communication are dual-stack, the SIP signaling will reach the last proxy server as it is the only server, except the target host itself, that can tell which IP version the target host is using. Similarly would happen if the last hop proxy server forwarded request to the target host and had the target host itself handle the request and found an error. 2.1 Analysis of final responses This is a short analysis of available final responses and which of these could be used to inform originating client that the target host cannot be contacted using the IP version in the request. The server should however signal in the response that the client could be reached using alternative IP version. Redirection 3XX Redirection 3XX type responses seem to have what is needed to inform the originating host that the target host is not reachable at that Mulahusic & Persson Expires - August 2003 [Page 4]

SIP Issues in Dual-stack Environments

February 2003

address and what address should alternatively be probed. However, there might exist some issues with 3XX responses as different IP versions are being mixed. �301 Moved Permanently� is probably too strong to signal back to the originating host as the client may register with IPv6 address at some later point in time. �302 Moved Temporarily� is quite close to what is being looked for in this case. The alternative IPv4 address of the client where it can be reached is signaled back to the originating host informing the originating host to use alternative address and protocol. Again, the issue is that the server may not be able to find out that the IP version used in the request is not supported by the target host. �380 Alternative Service� could be used if �service� also includes network protocols. Even this response has the same issue as previous one, i.e. how does the server knows that there might be a problem with the IP version? Request Failure 4XX The nearest one when analyzing 4XX final responses is probably the �480 Temporarily unavailable�, but 480 means that the callee�s end system has been successfully contacted which is not true in this case. 480 also means that the proxy recognizes the user, but does not have a valid forwarding location, which also is not completely true. Server Failure 5XX Can this type of responses be used as this is not exactly a server error? �505 Version Not Supported� is really close, but this is only about SIP version, but not IP version? 2.2 Analysis of Warnings The Warning header field described in [RFC3261] have the right semantics to signal this types of errors. However, as defined today, available warnings are closely tied to signaling SDP related errors and not general SIP errors caused by mismatch in network protocols between peers. 3. Scenario II, Try IPv4 and IPv6 simultaneously Scenario II has the same presumptions as the first one. A dual-stack host tries to set up a session with an IPv4-only host. The SIP signaling is traversing dual-stack SIP servers.

Mulahusic & Persson

Expires - August 2003

[Page 5]

SIP Issues in Dual-stack Environments

February 2003

In Scenario II, instead of first sending IPv6 request and waiting for response before eventually sending out an IPv4 response, the host sends both requests simultaneously. When the first response is received, it is the one used to set-up the session. One issue with Scenario II is the handling of simultaneous requests if the target host also is a dual-stack host. The target host will somehow have to recognize that the requests are actually for the same session except that they have been sent utilizing different IP transports. Is it sufficient if call-id�s are the same for both requests? What will happen with the request that is not accepted? 4. Conclusions As shown in the two examples above, there may exist issues with operation of SIP in dual-stack environments. As dual-stack hosts have been deployed on the Internet for some time now, and as more are to be deployed in the future, it might be useful to clarify how SIP is meant to operate in such environments in order to avoid unexpected interoperability problems. The scenarios illustrated above are should not be seen as a complete list of all cases with interoperability issues. There may exist other and more complex issues not described here. The scenarios above are only two basic cases described with purpose to show that there exist cases where interoperability may be an issue. If found necessary, this document can provide a basis for further investigation of SIP issues in dual-stack environments and in making a more thoroughly list of scenario of interest to consider when finding a solution. Such a work would eventually lead to providing clarifications for implementers and networks administrators about what to consider when implementing and deploying SIP and SIP applications to be used in dual-stack environments. Security Considerations Since the purpose of this document is to only highlight some of the existing issues with previously defined standards, the document does not introduce any new security threats. References [RFC3261] Rosenberg, J., et.al., �SIP: Session Initiation Protocol�, RFC 3261, June 2002.

Mulahusic & Persson

Expires - August 2003

[Page 6]

SIP Issues in Dual-stack Environments Authors' Addresses Jasminko Mulahusic Telia Vitsandsgatan 9 123 86 Farsta Sweden Phone: +46 8 713 82 94 Email: Jasminko.W.Mulahusic@telia.se H�kan Persson Telia Vitsandsgatan 9 123 86 Farsta Sweden Phone: +46 8 713 82 33 Email: Hakan.N.Persson@telia.se

February 2003

Mulahusic & Persson

Expires - August 2003

[Page 7]

SIP Issues in Dual-stack Environments

February 2003

Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be

Mulahusic & Persson

Expires - August 2003

[Page 8]

SIP Issues in Dual-stack Environments

February 2003

followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgments Funding for the RFC Editor function is currently provided by the Internet Society.

Mulahusic & Persson

Expires - August 2003

[Page 9]

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.