Interoperability Impacts of IPv6 Interworking with Existing IPv4 SIP Implementations
draft-klatsky-dispatch-ipv6-impact-ipv4-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Carl Klatsky , Olle E. Johansson , Rifaat Shekh-Yusef , Andrew Hutton , Gonzalo Salgueiro | ||
| Last updated | 2013-06-06 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-klatsky-dispatch-ipv6-impact-ipv4-00
DISPATCH C. Klatsky, Ed.
Internet-Draft Comcast
Intended status: Informational O. Johansson
Expires: December 06, 2013 Edvina
R. Shekh-Yusef
Avaya
A. Hutton
Siemens Enterprise Communications
G. Salgueiro
Cisco Systems
June 04, 2013
Interoperability Impacts of IPv6 Interworking
with Existing IPv4 SIP Implementations
draft-klatsky-dispatch-ipv6-impact-ipv4-00
Abstract
This document captures potential impacts to IPv4 SIP implementations
when interworking with IPv6 SIP implementations. Although some
amount of interworking translation will occur at the network and
application layers, an IPv4 SIP application may still encounter a SIP
message with some IPv6 values in it, resulting in unforeseen error
conditions. Such potential scenarios will be identified in this
document so that SIP application developers can define solutions to
handle these cases. Note, this document is not intended to be an
exhaustive list, rather to provide an overview of some of the more
commonly encountered potential scenarios.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 06, 2013.
Klatsky, et al. Expires December 06, 2013 [Page 1]
Internet-Draft IPv4/IPv6 Interoperability in SIP June 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions Used in This Document . . . . . . 3
3. Potential IPv4/IPv6 Interoperability Failure Scenarios . . . 3
3.1. IPv6 Address Handling in Via Headers . . . . . . . . . . 3
3.2. IPv6 Address Handling in Record-Route and Route Headers . 4
3.3. IPv6 Address Handling in Contact Headers . . . . . . . . 4
3.4. IPv6 Address Handling in SDP Body . . . . . . . . . . . . 4
3.5. IPv6 Address Handling in 'reginfo' XML Registration
Information Document . . . . . . . . . . . . . . . . . . 5
3.6. IPv6 Address Handling in 30x Redirect . . . . . . . . . . 5
3.7. IPv6 Address Handling in REFER-based Transfer . . . . . . 5
3.8. DNS Resolution of IPv4/IPv6 in SRV Records . . . . . . . 5
3.9. IPv6 Address Handling in Multiple Contact Registrations . 5
3.10. Unsupported Address . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The continued proliferation of IPv6 infrastructure deployments has
resulted in more IPv6 Session Initiation Protocol (SIP) User Agents
(UAs) being turned up on the network. Considering the large deployed
install base of IPv4 SIP UAs developed prior to the widespread
deployment of IPv6, it is a well known fact that not all IPv4 SIP UAs
have taken into account all possible IPv4 SIP-to-IPv6 SIP
interoperability considerations at the time of their development.
Klatsky, et al. Expires December 06, 2013 [Page 2]
Internet-Draft IPv4/IPv6 Interoperability in SIP June 2013
The scenarios outlined in this document are intended as guidance for
application developers to help identify solutions to resolve the
identified interoperability challenges. The scenarios detailed in
this document are not meant to be exhaustive, and more scenarios may
be identified in the future.
2. Terminology and Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
RFC 3261 [RFC3261] defines additional terms used in this document
that are specific to the SIP domain such as "proxy"; "registrar";
"redirect server"; "user agent server" or "UAS"; "user agent client"
or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog";
"transaction"; "server transaction".
This document uses the term "SIP Server" that is defined to include
the following SIP entities: user agent server, registrar, redirect
server, a SIP proxy in the role of user agent server, and a B2BUA in
the role of a user agent server.
This document also uses the following terminology to make clear
distinction between SIP entities supporting only IPv4, only IPv6 or
supporting both IPv4 and IPv6.
IPv4-only UA/UAC/UAS: An IPv4-only UA/UAC/UAS supports SIP signaling
and media only on the IPv4 network. It does not understand IPv6
addresses.
IPv6-only UA/UAC/UAS: An IPv6-only UA/UAC/UAS supports SIP signaling
and media only on the IPv6 network. It does not understand IPv4
addresses.
IPv4/IPv6 UA/UAC/UAS: A UA/UAC/UAS that supports SIP signaling and
media on both IPv4 and IPv6 networks; such a UA/UAC/UAS is known
(and will be referred to in this document) as a "dual-stack"
[RFC4213] UA/UAC/UAS.
3. Potential IPv4/IPv6 Interoperability Failure Scenarios
3.1. IPv6 Address Handling in Via Headers
As an IPv6 SIP message makes its way through the network, the Via
header is updated and includes specific IPv6 addresses of IPv6 nodes
that it has traversed. If the message arrives at an IPv4-only UAS it
may still contain those IPv6 addresses in the Via header. Presumably
Klatsky, et al. Expires December 06, 2013 [Page 3]
Internet-Draft IPv4/IPv6 Interoperability in SIP June 2013
the topmost Via header references an IPv4 address or a Fully
Qualified Domain Name (FQDN) resolvable to any IPv4 address. In this
case the IPv4-only UAS is able to send its response on to its next
hop, otherwise the message would not have made it to the IPv4-only UA
at all. The challenge for the IPv4-only UA then becomes to not
generate an error even if the other Via headers that it does not need
to act upon contain IPv6 addresses.
3.2. IPv6 Address Handling in Record-Route and Route Headers
Similar to the concerns of having IPv6 addresses in the Via headers,
IPv4 SIP UAS may also encounter Record-Route headers that contain
IPv6 addresses of IPv6 nodes the SIP message has traversed. It is
again assumed that if the SIP message arrives at an IPv4-only UA that
the topmost Record-Route header references an IPv4 address or a FQDN
resolvable to any IPv4 address, such that the response may be routed
back to a node reachable by the IPv4-only UAS. In this instance the
IPv4-only UA should not generate an error when parsing the IPv6
addresses. Additionally, the IPv4-only UA may also need to populate
the Route header in the response that includes the IPv6 addresses
learned from previously received Record-Route header, and again do so
without generating an error.
3.3. IPv6 Address Handling in Contact Headers
Another scenario with possible IPv6-to-IPv4 interoperability
implications is the case where the IPv4-only UAS receives an IPv6
address in the Contact header. Since this represents the peer's
reachable contact IP, it may not have been modified by any
interworking element in the communications path. The IPv4-only UAS
will have to send its requests through its outbound SIP server, and
not generate an error upon receipt of a message with this IPv6
information.
3.4. IPv6 Address Handling in SDP Body
IPv4-only UASes may also receive INVITEs with IPv6 addresses in the
Session Description Protocol (SDP) [RFC4566] portion of the message.
An IPv6 address can appear in multiple places in the SDP, such as the
o= line, c= line or a= lines (for Interactive Connectivity
Establishment (ICE) [RFC5245] attributes). A working assumption is
that minimally the c= line will reference an IPv4 address of a media
interworking element to allow the media communications being
established by this session to work. Nonetheless the IPv4-only UAS
needs be aware and properly handle any IPv6 addresses that may be
within the received SDP.
Klatsky, et al. Expires December 06, 2013 [Page 4]
Internet-Draft IPv4/IPv6 Interoperability in SIP June 2013
3.5. IPv6 Address Handling in 'reginfo' XML Registration Information
Document
There may be instances where an IPv4-only UAC subscribes to the
registration event package [RFC3680] as a "watcher" for a specific
entity, to be informed of registration state changes for that entity.
The "watcher" may have no knowledge of the IP address family in use
on the "watched" entity, and it is possible that a NOTIFY indicating
an IPv6 address in the Extensible Markup Language (XML) [XML] body is
received. The "watcher" needs to properly parse such a NOTIFY and
provide the status update of the "watched" entity to the user or
system that requested the information.
3.6. IPv6 Address Handling in 30x Redirect
There may be scenarios where an IPv4-only UAC receives a 30x redirect
message in response to a request it has sent. This 30x message may
contain a Contact header with an IPv6 address. This is the case
where the call is being redirected to an IPv6-only UAS. Since this
represents the peer's reachable contact IP, it may not have been
modified by any interworking element in the communications path. The
IPv4-only UAC should send its new request to its outbound SIP server
without generating an error upon receipt of a 30x message with IPv6
information.
3.7. IPv6 Address Handling in REFER-based Transfer
After establishing a call between two IPv4-only UAs, one of the
parties in the call may attempt to transfer the other party to a 3rd
party using the REFER method [RFC5589]. This transfer may be to an
IPv6-only UAS. The implication is that both IPv4-only UASes involved
in the call transfer need to be able to handle a REFER with an IPv6
address in the Refer-To header. The transferor needs to be able to
form the proper REFER message with the IPv6 Contact and the
transferee needs to be able to process the REFER message and attempt
to establish a call with the transfer target.
3.8. DNS Resolution of IPv4/IPv6 in SRV Records
A dual-stack UA may use the Domain Name System (DNS) SRV mechanism to
resolve addresses of proxies that it needs to communicate with. In
such a case it needs to be able to locate both IPv4 proxies and IPv6
proxies. This implies that the DNS server has been updated with both
A and AAAA records for the SIP server, and that the dual-stack UA
requests for both IPv4 and IPv6 SIP server addresses.
3.9. IPv6 Address Handling in Multiple Contact Registrations
Klatsky, et al. Expires December 06, 2013 [Page 5]
Internet-Draft IPv4/IPv6 Interoperability in SIP June 2013
A 200 OK to a REGISTER request might include multiple Contact headers
because the user has registered his or her Address of Record (AOR) on
multiple clients. Some of these Contact headers might have IPv6
addresses. An IPv4-only UAC must be able to handle the IPv6
information properly.
3.10. Unsupported Address
If the endpoint is an IPv4-only or an IPv6-only endpoint, and it
receives a request with an SDP offer that has a network address that
is not compatible with the network address it supports, the endpoint
should decline the request by returning a 488 "Not Acceptable Here"
(as defined in section 13.3.1.2 of RFC3261) with a Warning header
that has a warning code or 301 "Incompatible Network Address Formats"
(as defined in section 20.43 of RFC3261).
4. Security Considerations
This document merely describes the potential impacts of IPv6 on IPv4
SIP implementations. The scenarios discussed in this informational
document do not introduce any new security threats. The specific
security vulnerabilities, attacks, threat models of the various
protocols discussed in this document (SIP, SDP, ICE, etc.) are well
documented in their respective documents.
5. IANA Considerations
This document does not require actions by IANA.
6. Acknowledgements
The authors would like to acknowledge the support and contribution of
the SIP Forum IPv6 Working Group. This document has benefited from
the detailed review and thoughtful comments of Dan Wing.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
Klatsky, et al. Expires December 06, 2013 [Page 6]
Internet-Draft IPv4/IPv6 Interoperability in SIP June 2013
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session
Initiation Protocol (SIP) Call Control - Transfer", BCP
149, RFC 5589, June 2009.
[XML] Sperberg-McQueen, C., Yergeau, F., Bray, T., Maler, E.,
and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>.
Authors' Addresses
Carl Klatsky (editor)
Comcast
1717 Arch St.
Philadelphia, PA 19103
US
Email: carl_klatsky@cable.comcast.com
Olle E. Johansson
Edvina
Runbovaegen 10
Sollentuna SE-192 48
SE
Email: oej@edvina.net
Klatsky, et al. Expires December 06, 2013 [Page 7]
Internet-Draft IPv4/IPv6 Interoperability in SIP June 2013
Rifaat Shekh-Yusef
Avaya
250 Sidney Street
Belleville, Ontario
Canada
Email: rifatyu@avaya.com
Andrew Hutton
Siemens Enterprise Communications
Technology Drive
Nottingham NG9 1LA
UK
Email: andrew.hutton@siemens-enterprise.com
Gonzalo Salgueiro
Cisco Systems
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
US
Email: gsalguei@cisco.com
Klatsky, et al. Expires December 06, 2013 [Page 8]