[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: April 20, 2006                                      K. El Malki
                                                              V. Gurbani
                                          Lucent Technologies, Inc./Bell
                                                        October 17, 2005

        IPv6 Transition in the Session Initiation Protocol (SIP)

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 20, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This document describes how IPv4 Session Initiation Protocol (SIP)
   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-

Camarillo, et al.        Expires April 20, 2006                 [Page 1]

Internet-Draft           IPv6 Transition in SIP             October 2005

   stack user agents are considered in the discussions.

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
     3.4   Sending a Request over a New Network: Re-computing
           Identifiers  . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  The Media Layer  . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1   Initial Offer  . . . . . . . . . . . . . . . . . . . . . .  7
     4.2   Connectivity Checks  . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1   Normative References . . . . . . . . . . . . . . . . . . .  8
     8.2   Informational References . . . . . . . . . . . . . . . . .  9
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
       Intellectual Property and Copyright Statements . . . . . . . . 11

Camarillo, et al.        Expires April 20, 2006                 [Page 2]

Internet-Draft           IPv6 Transition in SIP             October 2005

1.  Introduction

   SIP [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 Real-Time Transport Protocol (RTP [15]).

   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 Domain Name Service (DNS) entries are
   properly configured, user agents using different address spaces need
   to implement extensions in order to exchange media between them.

   This document addresses the systems-level issues to make SIP work
   successfully between IPv4 and IPv6.  Section 3 and Section 4 provide
   discussions on the topics that are pertinent to the signaling layer
   and media layer, respectively, to establish a successful session
   between heterogeneous IPv4/IPv6 networks.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   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

   An autonomous SIP domain sends and receives SIP traffic to and from
   its user agents as well as to and from other autonomous domains.
   This section describes the issues related to such traffic exchanges.
   We assume that the network administrators appropriately configure
   their networks such that the SIP servers within an autonomous domain
   can communicate between themselves.  While this section contains
   systems-level issues, it does not address implementation-specific
   issues (i.e., parser torture tests, application programming
   interfaces to use in programs, etc).  Such topics are outlined in
   detail in a separate document [19].

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

Camarillo, et al.        Expires April 20, 2006                 [Page 3]

Internet-Draft           IPv6 Transition in SIP             October 2005

   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
   appropriate discovery mechanisms to provide user agents with the IPv4
   and IPv6 addresses of their outbound proxy servers.  For example, a
   domain may support both the DHCPv4 [14] and the DHCPv6 [13] options
   for SIP servers.

   If user agents are configured with the Fully-Qualified Domain Name
   (FQDN) 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 co-located 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.

   As an example, a portion of a sample DNS zone file entry is
   reproduced below that has both IPv4 and IPv6 addresses.  This entry
   corresponds to a proxy server for the domain "example.com".  The
   proxy server supports the Transmission Control Protocol (TCP) and
   User Datagram Protocol (UDP) transport for both IPv4 and IPv6

   _sip._tcp  SRV  20 0 5060 sip1.example.com
              SRV   0 0 5060 sip2.example.com
   _sip._udp  SRV  20 0 5060 sip1.example.com
              SRV   0 0 5060 sip2.example.com

   sip1 IN A
   sip1 IN AAAA  2001:db8::1
   sip2 IN A
   sip2 IN AAAA  2001:db8::2

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

Camarillo, et al.        Expires April 20, 2006                 [Page 4]

Internet-Draft           IPv6 Transition in SIP             October 2005

   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.

      Note that while this is the recommended practice, some problems
      may still arise if a RFC2543 [16] endpoint is involved in
      signaling.  Since the ABNF in RFC2543 did not include production
      rules to parse IPv6 network identifiers, there is a good chance
      that a RFC2543-only compliant endpoint is not able to parse or
      regenerate IPv6 network identifiers in headers.  Thus, despite a
      dual-stack proxy inserting itself into the session establishment,
      the endpoint itself may not succeed in the signaling establishment
      This is generally not a problem with RFC3261 endpoints; even if
      such an endpoint runs on an IPv4-only host, it still is able to
      parse and regenerate IPv6 network identifiers.

3.4  Sending a Request over a New Network: Re-computing  Identifiers

   SIP uses DNS procedures to allow a client to resolve a SIP URI into
   the equivalent IP address, port, and transport protocol of the next
   hop to contact lookups [8].  When a SIP client queries the DNS, it
   gets an ordered set of IP addresses, ports, and transports to use.
   If the server it is seeking is dual-stacked and has a DNS A and AAAA
   RR, then the client will need to be prepared to contact the server on
   all the transports over both of the networks (i.e., IPv4 and IPv6).
   More specifically, when a dual-stack client is prepared to send a
   request to a dual-stack next hop server, it must determine whether to
   first send it to the IPv4 address of the server, or to the IPv6
   address.  If SRV RRs have been used to derive the addresses of the
   server, the "Priority" field of the SRV RR can aid in such a
   decision.  Another technique to aid in this decision is outlined in
   RFC 3484 [17].  Regardless of which network is tried first, each
   search corresponds to a different branch, and as such, mandates that

Camarillo, et al.        Expires April 20, 2006                 [Page 5]

Internet-Draft           IPv6 Transition in SIP             October 2005

   the normative behavior in RFC3261 to handle requests sent on a branch
   be followed.

   When a request is to be sent on a branch, certain identifiers are
   computed.  Specifically, a branch ID is computed and inserted in the
   topmost Via header, and certain headers are used to generate
   signatures for Identity [20] and Authenticated Identity Body (AIB
   [18]).  The headers that are used to generate signatures can contain
   either raw IP addresses or FQDNs; consequently, an implementation may
   choose to insert a raw IP address in such headers.  This choice has
   ramifications, as discussed next.

   When a request is re-targeted to a new branch because the old one did
   not elicit a response, and the request is now destined to a new
   network (i.e., old request went to an IPv4 downstream server while
   the new one is destined towards an IPv6 downstream server) care must
   be taken in re-computing the identifiers.  More specifically,
   implementations MUST ensure that, at the very least, the branch id is
   recomputed.  Additionally, if raw IP addresses were used to generate
   the signatures for the Identity header and AIB, these signatures MUST
   be recomputed.

   To avoid recomputing the signatures used in the Identity header or
   the AIB, it is RECOMMENDED that SIP entities use FQDNs in those
   headers that are used as the basis for the Identity header and the

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
   protocol.  The most widespread protocol to describe sessions at
   present is called, aptly enough, the Session Description Protocol

   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

Camarillo, et al.        Expires April 20, 2006                 [Page 6]

Internet-Draft           IPv6 Transition in SIP             October 2005


   This IP version incompatibility problem would not exist if hosts
   implementing IPv6 also implemented IPv4.  However there will be
   deployments where the IPv6-only host solution is applicable, such as:

   1.  Networks where public IPv4 addresses are scarce and it is
       preferable to make large deployments only on IPv6.
   2.  Networks utilizing Layer-2s that do not support contemporary IPv4
       and IPv6 usage on the same link (e.g., the 3rd Generation
       Partnership Project, 3GPP).

   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) [12] procedures and how they can encode
   them in an SDP session description using the ANAT semantics [7] 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 [10] [11] 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 [9].

4.2  Connectivity Checks

   Once the answerer has generated an answer following the ICE

Camarillo, et al.        Expires April 20, 2006                 [Page 7]

Internet-Draft           IPv6 Transition in SIP             October 2005

   procedures, both user agents SHOULD perform the STUN-based [6]
   connectivity checks specified by ICE.  This checks help prevent some
   types of flooding attacks and allow user agents to discover new
   addresses that can be useful in the presence of NATs (Network Address

5.  IANA Considerations

   This document does not contain any actions for the IANA.

6.  Security Considerations


7.  Acknowledgment


8.  References

8.1  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", 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
         the Session Description Protocol (SDP)", RFC 3264, June 2002.

   [5]   Camarillo, 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]   Camarillo, G. and J. Rosenberg, "The Alternative Network
         Address Types (ANAT) Semantics for the  Session Description
         Protocol (SDP) Grouping Framework", RFC 4091, June 2005.

   [8]   Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol

Camarillo, et al.        Expires April 20, 2006                 [Page 8]

Internet-Draft           IPv6 Transition in SIP             October 2005

         (SIP): Locating SIP Servers", RFC 3263, June 2002.

   [9]   Camarillo, G. and J. Rosenberg, "Usage of the Session
         Description Protocol (SDP) Alternative  Network Address Types
         (ANAT) Semantics in the Session Initiation  Protocol (SIP)",
         RFC 4092, June 2005.

   [10]  Rosenberg, J., Huitema, C., and R. Mahy, "Traversal Using Relay
         NAT (TURN)", draft-rosenberg-midcom-turn-08 (work in progress),
         September 2005.

   [11]  Camarillo, G. and O. Novo, "Traversal Using Relay NAT (TURN)
         Extension for IPv4/IPv6  Transition",
         draft-camarillo-midcom-turn-ipv6-00 (work in progress),
         October 2005.

   [12]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
         Methodology for  Network Address Translator (NAT) Traversal for
         Offer/Answer Protocols", draft-ietf-mmusic-ice-05 (work in
         progress), July 2005.

8.2  Informational References

   [13]  Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv6)
         Options for Session  Initiation Protocol (SIP) Servers",
         RFC 3319, July 2003.

   [14]  Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-
         for-IPv4) Option  for Session Initiation Protocol (SIP)
         Servers", RFC 3361, August 2002.

   [15]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications",
         RFC 3550, July 2003.

   [16]  Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
         "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [17]  Draves, R., "Default Address Selection for Internet Protocol
         Version 6 (IPv6)", RFC 3484, Feb 2003.

   [18]  Peterson, J., "Session Initiation Protocol (SIP) Authenticated
         Identity Body (AIB) Format", RFC 3893, September 2004.

   [19]  Gurbani, V. and C. Boulton, "Recommendations on the use of IPv6
         in the Session Initiation  Protocol (SIP)",
         draft-gurbani-sipping-ipv6-sip-01 (work in progress),
         October 2005.

Camarillo, et al.        Expires April 20, 2006                 [Page 9]

Internet-Draft           IPv6 Transition in SIP             October 2005

   [20]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
         Identity Management in the Session Initiation Protocol (SIP)",
         draft-ietf-sip-identity-05 (work in progress), MArch 2005.

Authors' Addresses

   Gonzalo Camarillo
   Hirsalantie 11
   Jorvas  02420

   Email: Gonzalo.Camarillo@ericsson.com

   Karim El Malki

   Email: karim@athonet.com

   Vijay K. Gurbani
   Lucent Technologies, Inc./Bell Laboratories
   2000 Lucent Lane
   Rm 6G-440
   Naperville, IL  60566

   Phone: +1 630 224 0216
   Email: vkg@lucent.com

Camarillo, et al.        Expires April 20, 2006                [Page 10]

Internet-Draft           IPv6 Transition in SIP             October 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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Camarillo, et al.        Expires April 20, 2006                [Page 11]

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