[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-camarillo-sipping-v6-transition) 00 01 02 03 04 05 06 07 RFC 6157

SIPPING Working Group                                       G. Camarillo
Internet-Draft                                                  Ericsson
Expires: January 12, 2006                                  July 11, 2005


       IPv6 Transcition in the Session Initiation Protocol (SIP)
                draft-ietf-sipping-v6-transition-00.txt

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 January 12, 2006.

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 January 12, 2006                [Page 1]

Internet-Draft           IPv6 Transition in SIP                July 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 January 12, 2006                [Page 2]

Internet-Draft           IPv6 Transition in SIP                July 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 January 12, 2006                [Page 3]

Internet-Draft           IPv6 Transition in SIP                July 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 January 12, 2006                [Page 4]

Internet-Draft           IPv6 Transition in SIP                July 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 January 12, 2006                [Page 5]

Internet-Draft           IPv6 Transition in SIP                July 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-07 (work in progress),
         February 2005.



Camarillo               Expires January 12, 2006                [Page 6]

Internet-Draft           IPv6 Transition in SIP                July 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-04 (work in progress), February 2005.

   [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 January 12, 2006                [Page 7]

Internet-Draft           IPv6 Transition in SIP                July 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 January 12, 2006                [Page 8]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/