[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: August 11, 2006                                     K. El Malki
                                                                 Athonet
                                                         V. Gurbani, Ed.
                                          Lucent Technologies, Inc./Bell
                                                            Laboratories
                                                        February 7, 2006


        IPv6 Transition in the Session Initiation Protocol (SIP)
                draft-ietf-sipping-v6-transition-02.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 August 11, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes how IPv4 Session Initiation Protocol (SIP)
   user agents can communicate with IPv6 SIP user agents (and vice
   versa) at the signaling layer as well as exchange media once the
   session has been successfully set up.  Both single- and dual-stack



Camarillo, et al.        Expires August 11, 2006                [Page 1]

Internet-Draft           IPv6 Transition in SIP            February 2006


   (i.e., an IPv4-only and an IPv4/IPv6) user agents are considered in
   this document.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  The Signaling Layer  . . . . . . . . . . . . . . . . . . . . .  4
     3.1   Proxy Behavior . . . . . . . . . . . . . . . . . . . . . .  4
       3.1.1   Relaying Requests Across Different Networks  . . . . .  5
     3.2   UA Behavior  . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  The Media Layer  . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1   Initial Offer  . . . . . . . . . . . . . . . . . . . . . . 10
     4.2   Connectivity Checks  . . . . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1   Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2   Informational References . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
   A.  Sample IPv4/IPv6 DNS File  . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 15




























Camarillo, et al.        Expires August 11, 2006                [Page 2]

Internet-Draft           IPv6 Transition in SIP            February 2006


1.  Introduction

   SIP [3] is a protocol to establish and manage multimedia sessions.
   After the exchange of signaling messages, SIP endpoints generally
   exchange session, or media traffic, which is not transported using
   SIP but 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 signaling layer and the media layer.  While unextended SIP
   can handle heterogeneous IPv6/IPv4 networks at the signaling layer as
   long as proxy servers and their Domain Name Service (DNS) entries are
   properly configured, user agents using different networks and address
   spaces must 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",
   "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.

   IPv4-only user agent: An IPv4-only user agent supports SIP signaling
   and media only on the IPv4 network.  It does not understand IPv6
   addresses.

   IPv4-only host: A host that is configured to work only on the IPv4
   network; i.e., it only understands IPv4 addresses.

   IPv6-only user agent: An IPv6-only user agent supports SIP signaling
   and media only on the IPv6 network.  It does not understand IPv4
   addresses.

   IPv6-only host: A host that is supports only IPv6, or a host that
   supports both an IPv4/IPv6 network but has been configured to operate
   on an IPv6 network only.

   IPv4/IPv6-aware: (1) A host that is configured to work on both the
   IPv4 and IPv6 networks (also known as a "dual-stack" host); and (2) a
   user agent that supports SIP signaling and media on both the IPv4 and



Camarillo, et al.        Expires August 11, 2006                [Page 3]

Internet-Draft           IPv6 Transition in SIP            February 2006


   IPv6 networks.

3.  The Signaling Layer

   An autonomous 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 at the
   signaling layer; i.e., the flow of SIP messages between participants
   in order to establish the session.  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).  Such topics are outlined in detail in a separate document
   [19].

3.1  Proxy Behavior

   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.  Furthermore, there SHOULD
   exist both IPv6 and IPv4 DNS entries for outbound proxy servers.
   This allows the user agent to query DNS and obtain an IP address most
   appropriate for its use (i.e., an IPv4-only user agent will query DNS
   for A resource records (RR), an IPv6-only user agent will query DNS
   for AAAA RRs, and a dual-stack user agent will query DNS for all RRs
   and choose a specific network.)

   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.

   On the receiving side, user agents inside an autonomous domain
   receive SIP traffic from sources external to their domain through an
   inbound proxy (which is sometimes co-located with the registrar of
   the domain).  As was the case previously, it is RECOMMENDED that
   domains deploy dual-stack inbound proxies or, alternatively, deploy
   both IPv4-only and IPv6-only inbound proxy servers.  This allows the
   user agents external to the autonomous domain to query DNS and
   receive an IP address of the inbound proxy most appropriate for its
   use (i.e., an IPv4-only user agent will query DNS for A RRs, an IPv6-
   only user agent will query DNS for AAAA RRs, and a dual-stack user
   agent will query DNS for all RRs and choose a specific network.)



Camarillo, et al.        Expires August 11, 2006                [Page 4]

Internet-Draft           IPv6 Transition in SIP            February 2006


   SIP uses DNS procedures to allow a proxy to resolve a SIP URI into
   the equivalent IP address, port, and transport protocol of the next
   hop to contact lookups [8].  When an IPv4/IPv6-aware SIP proxy
   queries the DNS, it gets an ordered set of IP addresses, ports, and
   transports to use.  If the server it is seeking is also IPv4/
   IPv6-aware and has a DNS A and AAAA RR, then the proxy must be
   prepared to contact the downstream server on all the transports over
   both of the networks (i.e., IPv4 and IPv6).  More specifically, when
   an IPv4/IPv6-aware proxy is prepared to send a request to an IPv4/
   IPv6-aware next hop server, it must determine whether to first send
   it to the IPv4 address of the server, or to the IPv6 address.  A
   technique to aid in this decision is outlined in RFC 3484 [17].  If
   SRV RR's have been used to derive the addresses of the server, the
   "Priority" field of the SRV RR can also aid in such a decision;
   however, the technique in RFC 3484 has precedence.  SRV priority
   levels MUST be used in addition to, but MUST NOT be used as a
   replacement for RFC 3484.  Regardless of which network is tried
   first, each search corresponds to a different branch, and as such,
   mandates that the the normative behavior in RFC3261 to handle
   requests sent on a branch be followed.

   Appendix A contains a sample DNS zone file entry that has been
   populated with both IPv4 and IPv6 addresses.

3.1.1  Relaying Requests Across Different Networks

   A SIP proxy server that receives a request using IPv6 and relays it
   to a user agent (or another downstream proxy) using IPv4, and vice
   versa, needs to remain in the path traversed by subsequent requests.
   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
      phase.
      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.

   Relaying a request across different networks in this manner has other
   ramifications.  For one, the proxy doing the relaying MUST include a
   Record- Route header in the request going downstream.  This allows



Camarillo, et al.        Expires August 11, 2006                [Page 5]

Internet-Draft           IPv6 Transition in SIP            February 2006


   the user agents to construct a route set that includes the proxy.
   Second, if the Uniform Resource Identifier (URI) included in the
   Record-Route header was in the form of an IP address, then the proxy
   MUST re-write the Record-Route header when the response traverses
   through it, and this re-write modifies the URI such that it contains
   an IP address understood by the recipient of the response.  Note that
   no rewriting is necessary in the response if the URI in the Record-
   Route header was in the form of a Fully Qualified Domain Name (FQDN)
   of the proxy.

   An example helps illustrate the re-writing behavior.  In the example,
   we use only those headers pertinent to the discussion.  Other headers
   have been omitted for brevity.  In addition, only the INVITE request
   and final response (200 OK) are shown; it is not the intent of the
   example to provide a complete call flow that includes provisional
   responses and other requests.

   In this example, proxy P, responsible for the domain example.com,
   receives a request from an IPv4-only upstream client.  It proxies
   this request to an IPv6-only downstream server.

   Proxy P is running on a dual-stack host; on the IPv4 interface, it
   has an address of 192.0.2.1 and on the IPv6 interface, it sports an
   address of 2001:db8::1.



























Camarillo, et al.        Expires August 11, 2006                [Page 6]

Internet-Draft           IPv6 Transition in SIP            February 2006


     UAC                 Proxy                  UAS
      |                    P                     |
      |                    |                     |
      +-----F1------------>|                     |
      |                    +------F2------------>|
      |                    |                     |
      |                    |<-----F3-------------+
      |<----F4-------------+                     |
     ...                  ...                   ...
      |                    |                     |
      V                    V                     V

   F1: INVITE sip:alice@example.com SIP/2.0
       ...

   F2: INVITE sip:alice@2001:db8::10 SIP/2.0
       Record-Route: <sip:2001:db8::1;lr>
       ...

   F3: SIP/2.0 200 OK
       Record-Route: <sip:2001:db8::1;lr>

   F4: SIP/2.0 200 OK
       Record-Route: <sip:192.0.2.1;lr>
       ...


   When the UAS gets an INVITE and it accepts the invitation, it will
   send a 200 OK (F3) and form a route set.  The route set will include
   the IPv6 address shown in F2.  Thus, the IPv6-only UAS has a route
   set that contains an IPv6 address.  When the 200 OK now traverses
   through P, it modifies the URI it inserted earlier.  Since the UAC is
   an IPv4-only user agent, P rewrites the IPv6 address with an IPv4
   address corresponding to the address configured on its IPv4
   interface.  Now, when the IPv4-only UAC receives the response, it
   will form a route set that includes an IPv4 address of P. In this
   manner, both the UAC and the UAS have the correct network address of
   P towards which they can target subsequent requests.

   Some salient observations on the example follow:

   1.  Strictly speaking, P could have inserted its FQDN in the Record-
       Route URI and the result would have been the same.  This is
       because P has both IPv4 and IPv6 addresses in the DNS; thus the
       URI resolution would have yielded an IPv4 address to the UAC and
       an IPv6 address to the UAS.  However, since this example
       demonstrates the response re-writing behavior, IP addresses were
       inserted in the Record-Route URIs.



Camarillo, et al.        Expires August 11, 2006                [Page 7]

Internet-Draft           IPv6 Transition in SIP            February 2006


   2.  An alternative to the response re-writing behavior is for P to
       double Record-Route.  That is, it inserts two Record-Route
       headers in the request going downstream.  The first Record-Route
       header MUST contain P's IP address that is compatible with the
       network type of the UAS, and the second Record-Route header MUST
       contain P's IP address that is compatible with the UAC.  Whether
       to use the response re-writing option or the double Record-Route
       method is an implementation-specific behavior.  Implementors are
       advised to weigh in the case where the Record-Route header may be
       used for cryptographic means, and if so, they must use the double
       Record-Route method (re-writing the Record-Route header mutates
       the Record-Route header as it is seen by each endpoint, thus
       invalidating any cryptographic checksums.)
   3.  Even though the example demonstrated P receiving requests from
       and sending requests to an endpoint, the logical flow is the same
       even if the downstream server and upstream client is a proxy.

3.2  UA Behavior

   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 an IPv4/IPv6-aware 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 also IPv4/
   IPv6-aware 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 an IPv4/
   IPv6-aware client is prepared to send a request to an IPv4/IPv6-aware
   next hop server, it must determine whether to first send it to the
   IPv4 address of the server, or to the IPv6 address.  A technique to
   aid in this decision is outlined in RFC 3484 [17].  If SRV RR's have
   been used to derive the addresses of the server, the "Priority" field
   of the SRV RR can also aid in such a decision; however, the technique
   in RFC 3484 has precedence.  SRV priority levels MUST be used in
   addition to, but MUST NOT be used as a replacement for RFC 3484.
   Regardless of which network is tried first, each search corresponds
   to a different branch, and as such, mandates that 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.




Camarillo, et al.        Expires August 11, 2006                [Page 8]

Internet-Draft           IPv6 Transition in SIP            February 2006


   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 user agents use FQDNs in those
   headers that are used as the basis for the Identity header and the
   AIB.

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
   (SDP[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.

   This IP version incompatibility problem would not exist if hosts
   implementing IPv6 also implemented IPv4, and were configured with
   both IPv4 and IPv6 addresses.  In such a case, a UA would be able to
   pick a compatible media transport address type to communicate with
   each other.

   Consequently, user agents need a means to obtain both IPv4 and IPv6
   addresses to receive media and to place them in offers and answers.
   Note that pragmatism dictates that IPv6 user agents undertake the
   greater burden in the transition period.  Since IPv6 user agents are



Camarillo, et al.        Expires August 11, 2006                [Page 9]

Internet-Draft           IPv6 Transition in SIP            February 2006


   not widely deployed yet, it seems appropriate that IPv6 user agents
   obtain IPv4 addresses instead of mandating an upgrade on the
   installed IPv4 base.  Furthermore, IPv6 user agents are expected to
   be dual-stack and thus also support IPv4, unlike the larger IPv4-only
   user agent base that does not or cannot support IPv6.

   However there will be deployments where the IPv6-only host solution
   is applicable, where UAs either only support IPv6 or are only
   configured with IPv6 addresses, 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).

   In such cases, relays (i.e., TURN) should be used to allow IPv6-only
   hosts to utilize IPv4 addresses to communicate with IPv4-only hosts.

   The advantage of this strategy is that the installed base of IPv4
   user agents continues to function unchanged, but an operator that
   introduces IPv6 must provide additional servers to allow IPv6 user
   agents to obtain IPv4 addresses.  This strategy may come at an
   additional cost to SIP operators deploying IPv6.  However, since
   IPv4-only SIP operators are also likely deploy TURN relays as a NAT-
   traversal, the additional effort to deploy IPv6 in an IPv4 SIP
   network should be limited from this aspect.

4.1  Initial Offer

   We now 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].

   When following the ICE procedures, in addition to local addresses,
   user agents need to obtain addresses from relays.  For example, an
   IPv6 user agent would obtain an IPv4 address from a relay.  The relay
   would forward the traffic received on this IPv4 address to the user
   agent using IPv6.  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.

   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-



Camarillo, et al.        Expires August 11, 2006               [Page 10]

Internet-Draft           IPv6 Transition in SIP            February 2006


   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.

   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
   procedures, both user agents MAY 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
   Translators).

5.  IANA Considerations

   This document does not contain any actions for the IANA.

6.  Security Considerations

   This document describes how IPv4 SIP user agents can communicate with
   IPv6 user agents (and vice versa).  To do this, it uses additional
   protocols (TURN, STUN, SDP); the threat model of each such protocol
   is included in its respective document.  This document does not
   introduce the possibility of any new security threats; however, it
   may make hosts more amenable to existing threats.  Consider, for
   instance, a UAC that allocates an IPv4 and IPv6 addresses locally and
   inserts these into the SDP.  Malicious user agents that may intercept
   the request can mount a denial of service attack targeted to the
   different network interfaces of the UAC.

7.  Acknowledgment

   The authors would like to thank Mohamed Boucadair, Cullen Jennings,
   Aki Niemi, Jonathan Rosenberg, and Robert Sparks for discussions on
   the WG list that improved the quality of this document.

8.  References

8.1  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, March 1997.



Camarillo, et al.        Expires August 11, 2006               [Page 11]

Internet-Draft           IPv6 Transition in SIP            February 2006


   [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
         (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-06 (work in
         progress), October 2005.

8.2  Informational References

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



Camarillo, et al.        Expires August 11, 2006               [Page 12]

Internet-Draft           IPv6 Transition in SIP            February 2006


         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., Boulton, C., and R. Sparks, "Recommendations on
         the use of IPv6 in the Session Initiation  Protocol (SIP)",
         draft-gurbani-sipping-ipv6-sip-02 (work in progress),
         February 2006.

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


Authors' Addresses

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com


   Karim El Malki
   Athonet

   Email: karim@athonet.com







Camarillo, et al.        Expires August 11, 2006               [Page 13]

Internet-Draft           IPv6 Transition in SIP            February 2006


   Vijay K. Gurbani (editor)
   Lucent Technologies, Inc./Bell Laboratories
   2701 Lucent Lane
   Rm 9F-546
   Lisle, IL  60532
   USA

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

Appendix A.  Sample IPv4/IPv6 DNS File

   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 networks.


       ...
       _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     192.0.2.1
       sip1 IN AAAA  2001:db8::1
       sip2 IN A     192.0.2.2
       sip2 IN AAAA  2001:db8::2
       ...





















Camarillo, et al.        Expires August 11, 2006               [Page 14]

Internet-Draft           IPv6 Transition in SIP            February 2006


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 (2006).  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, et al.        Expires August 11, 2006               [Page 15]


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