SIPPING Working Group

Internet Draft J. Mulahusic

H. Persson
Expires: August 2003 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 Internet-
Drafts.

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 dual-
stack. 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 dual-
stack 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 single-
stack 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 dual-

stack 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 IPv4-
only 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 February 2003

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

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]