SIPPING Working Group G. Camarillo
Internet-Draft Ericsson
Expires: August 13, 2005 February 12, 2005
IPv6 Transcition in the Session Initiation Protocol (SIP)
draft-camarillo-sipping-v6-transition-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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.
This Internet-Draft will expire on August 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes how IPv4 SIP (Session Initiation Protocol)
nodes can communicate with IPv6 SIP nodes. Additionally, this
document also describes how a SIP user agent that supports IPv4 can
exchange media with one that supports IPv6. Both single and
dual-stack user agents are considered in the discussions.
Camarillo Expires August 13, 2005 [Page 1]
Internet-Draft IPv6 Transition in SIP February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The SIP Layer . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Outbound Proxy . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Inbound Proxy . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Incoming Requests to a Domain . . . . . . . . . . . . . . 4
4. The Media Layer . . . . . . . . . . . . . . . . . . . . . . . 4
4.1 Initial Offer . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Connectivity Checks . . . . . . . . . . . . . . . . . . . 5
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 6
9.2 Informational References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
Camarillo Expires August 13, 2005 [Page 2]
Internet-Draft IPv6 Transition in SIP February 2005
1. Introduction
SIP (Session Initiation Protocol) [3] is a protocol to establish and
manage multimedia sessions. After exchanging SIP traffic, SIP
endpoints generally exchange session traffic, which is not
transported using SIP, but using a different protocol. For example,
audio streams are typically carried using RTP (Real-Time Transport
Protocol) [13].
Consequently, a complete solution for IPv6 transition needs to handle
both the SIP layer and the media layer. While unextended SIP can
handle heterogeneous IPv6/v4 networks at the SIP layer as long as
proxy servers and their DNS entries are properly configured, user
agents using different address spaces need to implement extensions in
order to exchange media between them. Section 3 discusses issues
related to the SIP layer and Section 4 discusses issues related to
the media layer.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.
3. The SIP Layer
A given domain can send and receive SIP traffic to and from its user
agents and to and from other domains. The next sections describe the
issues related to these traffic exchanges. We assume that network
administrators appropriately configure their networks so that the SIP
servers within a domain can communicate between them.
3.1 Outbound Proxy
User agents typically send SIP traffic to an outbound proxy, which
takes care of routing it forward. In order to support both IPv4-only
and IPv6-only user agents, it is RECOMMENDED that domains deploy
dual-stack outbound proxy servers or, alternatively, deploy both
IPv4-only and IPv6-only outbound proxies.
Some domains provide automatic means for user agents to discover
their proxy servers. It is RECOMMENDED that domains implement
discovery mechanisms able to provide user agents with the IPv4 and
IPv6 addresses of their outbound proxy servers. For example, a
domain may support both the DHCPv4 [12] and the DHCPv6 [11] options
for SIP servers.
Camarillo Expires August 13, 2005 [Page 3]
Internet-Draft IPv6 Transition in SIP February 2005
If user agents are configured with the FQDN (Fully-Qualified Domain
Name) of their outbound proxy servers (instead of with their IP
addresses) there SHOULD be both IPv6 and IPv4 DNS entries for
outbound proxy servers. This way, user agents can use DNS to obtain
both their IPv6 and IPv4 addresses.
3.2 Inbound Proxy
User agents receive SIP traffic from their domains through an inbound
proxy (which is sometimes collocated with the registrar of the
domain). It is RECOMMENDED that domains deploy dual-stack inbound
proxies or, alternatively, deploy both IPv4-only and IPv6-only
inbound proxy servers.
3.3 Incoming Requests to a Domain
A SIP user agent is typically reachable through the SIP server that
handles its domain. If the publicly available SIP URI for a
particular user, referred to as the user's AoR (Address of Record),
is 'sip:user@example.com', requests sent to that user will be routed
to the SIP server at 'example.com'. The proxy or user agent sending
the request will perform a DNS lookup for 'example.com' in order to
obtain the IP address of the SIP server.
Therefore, it is RECOMMENDED that domains have both IPv4 and IPv6 DNS
entries for SIP servers. This way, the domain will be able to
receive requests from IPv4-only and from IPv6-only hosts. Of course,
the domain SHOULD have dual-stack proxy servers or both IPv4-only and
IPv6-only proxy servers to handle the incoming SIP traffic.
A SIP proxy server that receives a request using IPv6 and relays it
to the user agent using IPv4, or vice versa, needs to remain in the
path traversed by subsequent requests between both user agents.
Therefore, such a SIP proxy server MUST be configured to Record-Route
in that situation.
4. The Media Layer
SIP establishes media sessions using the offer/answer model [4]. One
endpoint, the offerer, sends a session description (the offer) to the
other endpoint, the answerer. The offer contains all the media
parameters needed to exchange media with the offerer: codecs,
transport addresses, protocols to transfer media, etc.
When the answerer receives an offer, it elaborates an answer and
sends it back to the offerer. The answer contains the media
parameters that the answerer is willing to use for that particular
session. Offer and answer are written using a session description
Camarillo Expires August 13, 2005 [Page 4]
Internet-Draft IPv6 Transition in SIP February 2005
protocol. The most widespread session description protocol at
present is SDP (Session Description Protocol) [2].
A direct offer/answer exchange between an IPv4-only user agent and an
IPv6-only user agent does not result in the establishment of a
session. The IPv6-only user agent wishes to receive media on one or
more IPv6 addresses, but the IPv4-only user agent cannot send media
to these addresses and generally does not even understand their
format.
Consequently, user agents need a means to obtain both IPv4 and IPv6
addresses (either locally or using relays) to receive media and to
place them in offers and answers. The following sections describe
how user agents can gather addresses following the ICE (Interactive
Connectivity Establishment) [9] procedures and how they can encode
them in an SDP session description using the ANAT semantics [8] for
the SDP grouping framework [5].
4.1 Initial Offer
It is RECOMMENDED that user agents gather IPv4 and IPv6 addresses
using the ICE procedures to generate all their offers. This way,
both IPv4-only and IPv6-only answerers will be able to generate an
answer that establishes a session. Note that, in case of forking,
the same offer carried in an INVITE request can arrive to an
IPv4-only user agent and to an IPv6-only user agent at roughly the
same time. Having placed both IPv4 and IPv6 addresses in the offer
reduces the session establishment time because both all types of
answerers find the offer valid.
When following the ICE procedures, in addition to local addresses,
user agents need to obtain addresses from relays. For example, and
IPv4 user agent would obtain an IPv6 address from a relay. The relay
would forward the traffic received on this IPv6 address to the user
agent using IPv4. Such user agents MAY use any mechanism to obtain
addresses in relays, but, following the recommendations in ICE, it is
RECOMMENDED that user agents support TURN [7] for this purpose.
User agents that use SDP SHOULD support the ANAT semantics for the
SDP grouping framework. ANAT allows user agents to include both IPv4
and IPv6 addresses in their SDP session descriptions. The SIP usage
of the ANAT semantics is discussed in [10].
4.2 Connectivity Checks
Once the answerer has generated an answer following the ICE
procedures, both user agents SHOULD perform the STUN-based [6]
connectivity checks specified by ICE. This checks help prevent some
Camarillo Expires August 13, 2005 [Page 5]
Internet-Draft IPv6 Transition in SIP February 2005
types of flooding attacks and allow user agents to discover new
addresses that can be useful in the presence of NATs (Network Address
Translators).
5. Example
TBD.
6. IANA Considerations
This document does not contain any actions for the IANA.
7. Security Considerations
TBD.
8. Acknowledges
TBD.
9. References
9.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[3] 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.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002.
[6] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.
[7] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-06 (work in progress), October
2004.
Camarillo Expires August 13, 2005 [Page 6]
Internet-Draft IPv6 Transition in SIP February 2005
[8] Camarillo, G., "The Alternative Network Address Types Semantics
(ANAT) for theSession Description Protocol (SDP) Grouping
Framework", draft-ietf-mmusic-anat-02 (work in progress),
October 2004.
[9] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Multimedia Session Establishment Protocols",
draft-ietf-mmusic-ice-03 (work in progress), October 2004.
[10] Camarillo, G., "Usage of the Session Description Protocol (SDP)
Alternative Network Address Types (ANAT) Semantics in the
Session Initiation Protocol (SIP)",
draft-ietf-sip-anat-usage-00 (work in progress), June 2004.
9.2 Informational References
[11] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
Servers", RFC 3319, July 2003.
[12] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCP-for-IPv4) Option for Session Initiation Protocol (SIP)
Servers", RFC 3361, August 2002.
[13] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
Author's Address
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Camarillo Expires August 13, 2005 [Page 7]
Internet-Draft IPv6 Transition in SIP February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Camarillo Expires August 13, 2005 [Page 8]