[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01

Network Working Group                                       M. Boucadair
Internet-Draft                                               Y. Noisette
Intended status: Standards Track                          France Telecom
Expires: January 28, 2010                                       A. Allen
                                                Research in Motion (RIM)
                                                           July 27, 2009


   The atypes media feature tag for Session Initiation Protocol (SIP)
                draft-boucadair-dispatch-ipv6-atypes-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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 28, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Boucadair, et al.       Expires January 28, 2010                [Page 1]

Internet-Draft        The atypes media feature tag             July 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This specification defines a new media feature tag called atypes.
   This new media feature tag indicates the IP address type capabilities
   of the UA (User Agent) and can aid the routing process and ease the
   invocation of required functions when heterogeneous (i.e.  IPv4 and
   IPv6) parties are involved in a given SIP session.

Requirements Language

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
































Boucadair, et al.       Expires January 28, 2010                [Page 2]

Internet-Draft        The atypes media feature tag             July 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Justification for atypes . . . . . . . . . . . . . . . . . . .  5
   3.  Relationship of atypes to ANAT/ICE . . . . . . . . . . . . . .  5
   4.  sip.atypes Media Feature Tag . . . . . . . . . . . . . . . . .  7
   5.  Session Routing Considerations . . . . . . . . . . . . . . . .  9
   6.  Examples of atypes tag usages  . . . . . . . . . . . . . . . .  9
     6.1.  IPv4-only UA . . . . . . . . . . . . . . . . . . . . . . .  9
     6.2.  IPv6-only UA . . . . . . . . . . . . . . . . . . . . . . . 10
     6.3.  Dual Stack REGISTER with one IP address in Contact
           header field . . . . . . . . . . . . . . . . . . . . . . . 11
     6.4.  Dual Stack REGISTER with two IP addresses in Contact
           header field . . . . . . . . . . . . . . . . . . . . . . . 12
     6.5.  Dual Stack REGISTER with one IPv4-mapped IPv6  address
           in the Contact header field  . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16




























Boucadair, et al.       Expires January 28, 2010                [Page 3]

Internet-Draft        The atypes media feature tag             July 2009


1.  Introduction

   Due to IPv4 address exhaustion problem, IPv6 deployment should be
   accelerated.  In this context and especially from a SIP perspective,
   the IPv4-IPv6 co-existence introduces heterogeneous scenarios with
   combinations of IPv4 and IPv6 nodes some of which are capable of
   supporting both IPv4 and IPv6 dual stack (DS) and some of which are
   capable of supporting only IPv4 or only IPv6.  Additionally, some UAs
   that are dual stack capable are unable to use both interfaces
   natively at the same time which can mean for example that if a UA has
   to use IPv6 for signaling it cannot use IPv4 for media even though
   the UA supports an IPv4 stack.  This mainly motivated by restrictions
   due to available resources such the need to maintain one PDP (packet
   data protocol) context in case of mobile networks.

   Draft-ietf-sipping-ipv6-transition [I-D.ietf-sipping-v6-transition]
   provides recommendations to solve this issue including recommending
   Dual Stack (DS) nodes in the core service platform having the
   signalling and media path traverse these DS elements.  While this is
   viable for big service providers it not viable for smaller ones
   especially at the earlier stages of IPv6 deployment.  Upgrading
   existing networks to follow all these recommendations requires a
   large investment.

   An interim alternative is to use a SIP Application Level Gateway
   (ALG) and a Network Address Translation - Protocol
   Translation(NAT-PT) node to convert between IPv4 and IPv6 addressing.
   However an ALG and a NAT-PT/NAT64 introduce additional nodes into the
   signaling and media paths and can result in the so called "trombone"
   effect with signaling and even more importantly media being
   unnecessarily routed via an ALG/NAT-PT/NAT64 in a network located at
   a significant distance from both of the UAs involved in the session.
   This is particularly significant in mobile networks in roaming
   scenarios where potentially media then has be routed via multiple
   hops over international links when a roaming user establishes a
   session with a user located in the roamed to country.  This situation
   is potentially unavoidable when an ALG/NAT-PT/NAT64 is needed to be
   inserted in the signaling and the media path because of incompatible
   IP versions between UAs that require IP address translation.  It is
   highly undesirable to redundantly include ALG/NAT-PT/NAT64 nodes in
   the path when the UAs can establish sessions without requiring ALG/
   NAT-PT nodes in the path.

   In order to avoid redundant inclusion of ALG/ NAT-PT/NAT64 nodes in
   the path, it is necessary for network nodes to be able to determine
   the connectivity types supported by UAs prior to forwarding session
   establishment requests.  Without such a capability, SIP Proxy Servers
   have no way to predict a session failure without a ALG/NAT-PT/NAT64



Boucadair, et al.       Expires January 28, 2010                [Page 4]

Internet-Draft        The atypes media feature tag             July 2009


   being included in the path even when the ANAT [RFC4091] [RFC4092] or
   ICE [I-D.ietf-mmusic-ice] mechanisms are also used.

   Additionally, when multiple UAs are registered with the same Address
   of Record (AoR) it is useful to be able to have a UA indicate a
   preference to contact a UA using the mechanism defined in RFC 3841
   [RFC3841] that supports the same IP version in order to avoid the
   need for NAT-PT/NAT64.

   This specification also addresses call routing and optimization
   mechanisms using the atypes Media Feature Tag to avoid as much as
   possible invoking SIP ALGs and NAT-PT/NAT64 when establishing a
   multimedia session between UAs.


2.  Justification for atypes

   SIP service platforms should be aware of the type of the involved
   peers before forwarding session establishment requests.  If these
   means are not supported, SIP Proxy Servers have no way to predict a
   session failure, even if ANAT [RFC4091] or ICE [I-D.ietf-mmusic-ice]
   procedures are adopted, and also to optimise the invocation of
   adaptation functions.

   The first alternative to notify the service platform about the type
   of the UA is to send SIP REGISTER message which encloses all
   available IP addresses.  For IPv4-only and IPv6-only UAs, only one
   single IP address is carried in SIP REGISTER messages.  For DS UAs,
   two IP addresses are enclosed.  Upon receipt, of this message, the
   registrar stores these addresses.  Two registration databases may be
   maintained, one for IPv4 and another one for IPv6.  A second
   alternative is to send several REGISTER request using available
   connectivity types.  In this case, a DS UA sends two REGISTER
   messages.  The first one is sent using its IPv4 connectivity and the
   second one using its IPv6 ones.  Two databases are maintained by the
   conversational service platform.  Consequently, upon receipt of an
   INVITE, the SIP Proxy Server may question its databases to retrieve
   the types of the involved parties.  SIP ALG is invoked accordingly.

   The drawback of this procedure is that it depends on the behaviour of
   the terminal.  A standardised behaviour should be encouraged.  To
   that aim, a new Media Feature Tag is introduced in this document.
   More details are provided hereafter.


3.  Relationship of atypes to ANAT/ICE

   ICE [I-D.ietf-mmusic-ice] specification deprecates



Boucadair, et al.       Expires January 28, 2010                [Page 5]

Internet-Draft        The atypes media feature tag             July 2009


   [RFC4091][RFC4092].  Like ANAT, ICE can be used to enclose both IPv4
   and IPv6 information in a given SDP offer.  In the remaining part,
   ANAT and ICE are used interchangeably since, from IPv4-IPv6
   interworking perspective, both provide the same solution.

   ANAT/ICE makes it possible for Dual Stack UAs to provide both IPv4
   and IPv6 addresses for a single logical media stream.  This
   singularly helps interworking as, whatever the distant UA version is
   (IPv4/IPv6-only or Dual-Stack), this latter should be able to
   understand at least one of the offers.  In this way the ANAT/ICE
   semantic provides a first approach to interworking problem, when
   heterogeneous UAs are involved in the SIP communication.  It indeed
   improves SIP exchanges, in so far as it allows all sessions arising/
   coming from Dual Stack UA to lead to successful calls.

   This interesting feature needs however to be nuanced, as it
   unfortunately does not fit all cases.  [RFC4091] already lists some
   cases where, depending on the implementation, recipients of an offer
   using ANAT might have different behaviours, thus requiring the
   introduction of the sdp-anat option-tag.  ANAT also requires the UA
   to be Dual Stack, which means it does not cover the case where UAs
   belong to different and restrictive IP version realms.  In other
   words, the ANAT proposition does not help solving scenarios where
   mono-stack (i.e.  IPv4 or IPv6) UAs are involved.  In this latter
   case, SIP exchanges can only succeed if intermediary nodes or
   functions (Proxy Servers, ALG, Session Border Controllers (SBCs),
   etc.) intervene in the signalling path.  This intervention, denoted
   as adaptation function in the rest of this document, is necessary to
   ensure a successful SIP exchange between these mono-satck UAs.
   Unfortunately, in these situations, ANAT/ICE does not help SIP
   servers situated all along the signalling path to take the right
   decision when IPv4-IPv6 interconnection needs (or should need) to be
   tackled.

   The atypes Media Feature Tag helps to provide a global answer to the
   interconnection problem, when heterogeneous SIP UAs are involved.
   Moreover, it aids SIP nodes situated all along the signalling path,
   to determine when to invoke the adaptation function helping the
   routing of the call.

   The atypes Media Feature Tag makes it possible for SIP Proxy Servers
   to determine the IP versions supported by the distant and the
   originating UA, when they process the initial SIP request.  This
   means that, the earlier possible in the exchange, a SIP node becomes
   aware of the potential interconnection problem due to IP version
   incompatibility.  This also means that this particular node can
   trigger the invocation of the adaptation function, which will modify
   the initial SDP offer in order to make this SIP exchange successful.



Boucadair, et al.       Expires January 28, 2010                [Page 6]

Internet-Draft        The atypes media feature tag             July 2009


   The atypes Media Feature Tag can therefore aid treatment of all
   exchange types intervening between mono-stack (IPv4 or IPv6) or Dual
   Stack UAs (whether they use ANAT or not).  Anytime a potential
   interconnection problem is suspected using the atypes Media Feature
   Tag, the SIP Proxy will be able to drive the adaptation function
   invocation and route the SIP exchange accordingly.

   The atypes Media Feature Tag can also provide interesting
   optimisation characteristics.  For instance, a service provider might
   force adaptation function like SIP ALGs to be invoked each time the
   SIP message leave an IPv4 realm for an IPv6 realm (and vice-versa),
   in order to modify the SDP offer accordingly.  This kind of
   modifications could happen more than once during the SIP signalling
   exchanges (and even more than once in a single direction!).  In the
   end, both UAs intervening in the SIP exchange might be of the same
   type, thus not requiring any change of the SDP offer!  Using the
   atypes Media Feature Tag such situation could be avoided, as the SIP
   Proxy Server would determine UAs are compatible, thus no modification
   should be make to SDP offers, even if layer 3 information are
   modified during the routing of the SIP message.

   The atypes Media Feature Tag can also help in the case where
   different SIP realms are crossed, where the information from the
   atypes Media Feature Tag for the distant UA is not available at the
   originating Proxy Server.  In this case, the atypes Media Feature Tag
   can be included in the SIP request thus enabling the distant SIP
   Proxy Server, which has the atypes Media Feature Tag information for
   the remote UA, to determine whether to route the SIP request via its
   adaptation function.

   The atypes Media Feature Tag is not limited to the single IPv4-IPv6
   interconnection problem, though this first version of the
   specification is dedicated to this usage.

   Further values of atypes can be defined in future specifications.
   The atypes Media Feature Tag is also compatible with the parallel
   usage of ICE or CCAP [I-D.boucadair-mmusic-ccap]..


4.  sip.atypes Media Feature Tag

   The 'sip.app-subtype' media feature tag is of type token with a case-
   sensitive equality relationship.  It indicates whether a
   (communications) device supports IPv4 for both signaling and media,
   IPv6 for both signaling and media, IPv6 for signaling and IPv4 for
   media simultaneously, IPv4 for signaling and IPv6 for media
   simultaneously.  A plurality of tokens is included for all the
   supported combinations.  Its values include:



Boucadair, et al.       Expires January 28, 2010                [Page 7]

Internet-Draft        The atypes media feature tag             July 2009


      - ipv4: The device can support IPv4 addresses for both signaling
      and media.

      - ipv6: The device can support IPv6 addresses for both signaling
      and media.

      - ipv4s-ipv6m: The device can support both IPv4 and IPv6 addresses
      and use the IPv4 address for signaling and the IPv6 address for
      media.

      - ipv6s-ipv4m: The device can support both IPv4 and IPv6 addresses
      and use the IPv6 address for signaling and the IPv4 address for
      media.

   Other values of atypes can be defined such as:

      - ipv4_via_nat46: When enclosed in a SIP message, a given SIP UA
      indicates "here is my IPv4 address, it goes through a translator
      so avoid using it if you can utilize my IPv6 address"

      - ipv6_via_nat64: When enclosed in a SIP message, a given SIP UA
      indicates "here is my IPv6 address, it goes through a translator
      so avoid using it if you can utilize my IPv4 address"

      - ipv4_via_cgn: When enclosed in a SIP message, a given SIP UA
      indicates "here is my IPv4 address, it goes through a CGN device
      so avoid using it if you can utilize a public IPv4 or IPv6
      address"

   When included in the Contact header field of a REGISTER request or an
   INVITE request, a UAC SHOULD include all atypes values that represent
   the address type combinations it can currently support.  When
   included in the Contact header field of a response a UAS SHOULD
   include all atypes values that represent the address type
   combinations it can currently support.

   A UAS that receives an OPTIONS request SHOULD include in the Contact
   header field an atypes Media Feature Tag containing all atypes values
   that represent the address type combinations it can currently
   support.

   A given UA MAY restrict its SIP communications to its IPv4-only
   interface or IPv6-only ones or MAY use all available ones.  The
   selected local restriction is conveyed in the atypes Media Feature
   Tag. Within this context, an IPv6 interface is judged available only
   if the scope of this interface is global and not local to the link.

   When included in the Accept-Contact or Reject-Contact header field,



Boucadair, et al.       Expires January 28, 2010                [Page 8]

Internet-Draft        The atypes media feature tag             July 2009


   it indicates a desire on the part of a UAC to be connected to a UAS
   which can support, or cannot support respectively, the address types
   and address type combinations specified.


5.  Session Routing Considerations

   Based on atypes tag value, the Registrar classifies the UA IP address
   capabilities for signaling and media.

   In order to route calls and to decide the need to invoke a SIP ALG or
   to alter SIP messages, which leads to a successful call between
   heterogeneous parties, a SIP Proxy Server MAY act as follows:

   a.  A first alternative is to interrogate the registration database
       maintained by the Registrar Server: In this alternative, the SIP
       Proxy Server asks the Registrar Server about the type of the
       Called and the Caller parties.  The SIP Proxy Server decides to
       invoke an ALG in case the two involved parties are either IPv4-
       only or IPv6-only.

   b.  The second alternative is to examine the atypes Media Feature Tag
       conveyed in the Contact header field of the INVITE request and
       the atypes Media Feature Tag values stored by the Registrar
       Server for the address type of the Called party.  In this
       scenario, the SIP Proxy Server routes the call by comparing the
       compatibility of the two retrieved atypes values (types of Called
       and Caller parties).


6.  Examples of atypes tag usages

   These sections provide a set of examples of SIP messages when atypes
   media feature tag is used.

6.1.  IPv4-only UA

   Let consider an IPv4-only UA denoted A. Its IP address is
   192.165.25.2.  This UA has been provisioned with required contact
   information to contact its Registrar (RS).  In this example, a FQDN
   is provided: rs.test.com.  Means that have been used to provision the
   UA are out of scope of this document.

   (1) A sends this REGISTER message to its Registrar Server RS:







Boucadair, et al.       Expires January 28, 2010                [Page 9]

Internet-Draft        The atypes media feature tag             July 2009


   REGISTER sip:rs.test.com SIP/2.0
   Via: SIP/2.0/UDP 192.165.25.2:5062;branch=z9hG4bK00e31d6ed
   Max-Forwards: 70
   Content-Length: 0
   To: A <sip:A@test.com>
   From: A <sip:A@test.com>;tag=ed3833bd7363e68
   Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com
   CSeq: 1830746364 REGISTER
   Contact: A <sip:A@192.165.25.2:5062>
            ;atypes="ipv4";expires=900

   (2) RS answers to A with a 200 OK message as follows:

   SIP/2.0 200 OK
   Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com
   CSeq: 1830746365 REGISTER
   From: A <sip:A@test.com>;tag=ed3833bd7363e68
   To: A <sip:A@test.com>;tag=3ab7fe89d998709
   Via:SIP/2.0/UDP 192.165.25.2:5062;branch=z9hG4bK00e31d6ed
   Content-Length: 0
   Contact: A <sip:A@192.165.25.2:5062>
            ;atypes="ipv4";expires=900

6.2.  IPv6-only UA

   Let consider an IPv6-only UA called B which IP address is 2001:688:
   1ffb:ff80::2.  Its attached Registrar Server is identified by this
   FQDN: r6.test.com.

   (1) B sends to its Registrar Server the following message:

   REGISTER sip:r6.test.com SIP/2.0
   Via: SIP/2.0/UDP
   [2001:688:1ffb:ff80::2]:5060;branch=z9hG4bK00e31d6ed
   Max-Forwards: 70
   Content-Length: 0
   To: B <sip:B@test.com>
   From: B <sip:B@test.com>;tag=ed3833bd7363e68
   Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com
   CSeq: 1830746364 REGISTER
   Contact: B <sip:B@[2001:688:1ffb:ff80::2]:5060>
            ;atypes="ipv6";expires=900

   (2) The Registrar Server answers with the following 200 OK message:







Boucadair, et al.       Expires January 28, 2010               [Page 10]

Internet-Draft        The atypes media feature tag             July 2009


   SIP/2.0 200 OK
   Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com
   CSeq: 1830746365 REGISTER
   From: B <sip: B@test.com>;tag=ed3833bd7363e68
   To: B <sip: B@test.com>;tag=3ab7fe89d998709
   Via:SIP/2.0/UDP[2001:688:1ffb:ff80::2]:5060;branch=z9hG4bK00e31d6ed
   Content-Length: 0
   Contact: B <sip:B@[2001:688:1ffb:ff80::2]:5060>
            ;atypes="ipv6";expires=900

   One IP address MAY be enclosed in the Contact header field of a dual
   stack registration message.  The type of the contact address MAY be
   distinct from the value of atypes.  For instance:

   o  an IPv4 address may be enclosed in the Contact header field even
      if the assigned atypes value is equal to "ipv6",

   o  or only one IP address may be carried in the Contact header field
      even if the atypes value is set to "ipv6,ipv4".

   The IP address in the Contact header field MAY be used by
   intermediary proxies when contacting the UA.

6.3.  Dual Stack REGISTER with one IP address in Contact header field

   Let consider a dual-stack UA (DS) which IP addresses are 2001:688:
   1ffb:ff80::2 and 192.168.25.5 which does not support IPv4 and IPv6
   simultaneously.  The FQDN of the Register Server is rs.test.com.

   (1) DS sends a REGISTER message to its Registrar Server as follows:

   REGISTER sip:rs.test.com SIP/2.0
   Via: SIP/2.0/UDP 192.168.25.5:5060;branch=z9hG4bK00e31d6ed
   Max-Forwards: 70
   Content-Length: 0
   To: DS <sip:DS@test.com>
   From: DS <sip:DS@test.com>;tag=ed3833bd7363e68
   Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com
   CSeq: 1830746364 REGISTER
   Contact: DS <sip:DS@192.168.25.5:5060>
            ;atypes="ipv4,ipv6";expires=900

   (2) The Registrar Server answers with a 200 OK message as shown
   below:







Boucadair, et al.       Expires January 28, 2010               [Page 11]

Internet-Draft        The atypes media feature tag             July 2009


   SIP/2.0 200 OK
   Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com
   CSeq: 1830746365 REGISTER
   From: DS <sip: DS@test.com>;tag=ed3833bd7363e68
   To: DS <sip:DS@test.com>;tag=3ab7fe89d998709
   Via:SIP/2.0/UDP 192.168.25.5:5060;branch=z9hG4bK00e31d6ed
   Content-Length: 0
   Contact: DS <sip:DS@192.168.25.5:5060>
            ;atypes="ipv4,ipv6";expires=900

6.4.  Dual Stack REGISTER with two IP addresses in Contact header field

   Let consider a dual-stack UA (DS) which IP addresses are 2001:688:
   1ffb:ff80::2 and 192.168.25.5 which does not support IPv4 and IPv6
   simultaneously on each interface.  The FQDN of the Register Server is
   rs.test.com.

   (1) DS sends a REGISTER message to its Registrar Server as follows:

   REGISTER sip:rs.test.com SIP/2.0
   Via: SIP/2.0/UDP 192.168.25.5:5060;branch=z9hG4bK00e31d6ed
   Max-Forwards: 70
   Content-Length: 0
   To: DS <sip:DS@test.com>
   From: DS <sip:DS@test.com>;tag=ed3833bd7363e68
   Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com
   CSeq: 1830746364 REGISTER
   Contact: DS1 <sip:DS1@192.168.25.5:5060>
            ;atypes="ipv4";expires=900
   Contact: DS2 <sip:DS2@[2001:688:1ffb:ff80::2]:5063>
            ;atypes="ipv6";expires=900

   (2) The Registrar Server answers with a 200 OK message as shown
   below:
   SIP/2.0 200 OK
   Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com
   CSeq: 1830746365 REGISTER
   From: DS <sip: DS@test.com>;tag=ed3833bd7363e68
   To: DS <sip:DS@test.com>;tag=3ab7fe89d998709
   Via:SIP/2.0/UDP 192.168.25.5:5060;branch=z9hG4bK00e31d6ed
   Content-Length: 0
   Contact: DS1 <sip:DS1@192.168.25.5:5060>
            ;atypes="ipv4,ipv6";expires=900
   Contact: DS2 <sip:DS2@[2001:688:1ffb:ff80::2]:5063>
            ;atypes="ipv4,ipv6";expires=900






Boucadair, et al.       Expires January 28, 2010               [Page 12]

Internet-Draft        The atypes media feature tag             July 2009


6.5.  Dual Stack REGISTER with one IPv4-mapped IPv6  address in the
      Contact header field

   Let consider a dual-stack UA (DS) which the IPv4 address 192.168.25.5
   is mapped to the IPV6 address ::ffff:192.168.25.5 and which does
   support simultaneous use of IPv4 and IPv6.  The FQDN of the Register
   Server is rs.test.com.

   (1) DS sends a REGISTER message to its Registrar Server as follows:

   REGISTER sip:rs.test.com SIP/2.0
   Via: SIP/2.0/UDP 192.168.25.5:5062;branch=z9hG4bK00e31d6ed
   Max-Forwards: 70
   Content-Length: 0
   To: DS <sip:DS@test.com>
   From: DS <sip:DS@test.com>;tag=ed3833bd7363e68
   Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com
   CSeq: 1830746364 REGISTER
   Contact: DS <sip:DS@[::ffff:192.168.25.5]>
            ;atypes="ipv6,ipv6s-ipv4m";expires=900

   (2) The Registrar Server answers with a 200 OK message as shown
   below:

   SIP/2.0 200 OK
   Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com
   CSeq: 1830746365 REGISTER
   From: DS <sip: DS@test.com>;tag=ed3833bd7363e68
   To: DS <sip:DS@test.com>;tag=3ab7fe89d998709
   Via:SIP/2.0/UDP 192.168.25.5:5062;branch=z9hG4bK00e31d6ed
   Content-Length: 0
   Contact: DS <sip:DS@[::ffff:192.168.25.5]>
            ;atypes="ipv6,ipv6s-ipv4m";expires=900


7.  IANA Considerations

   This specification adds a new media feature tag to the SIP Media
   Feature Tag Registration Tree defined in RFC 3840 [RFC3840].

   Media feature tag name: sip.atypes

   ASN.1 Identifier: TBD

   Summary of the media feature indicated by this tag: The sip.atypes
   media feature tag indicates whether a communications device supports
   IPv4 for both signaling and media, IPv6 for both signaling and media,
   IPv6 for signaling and IPv4 for media simultaneously, IPv4 for



Boucadair, et al.       Expires January 28, 2010               [Page 13]

Internet-Draft        The atypes media feature tag             July 2009


   signaling and IPv6 for media simultaneously.  A plurality of tokens
   is included for all the supported combinations.

   Values appropriate for use with this feature tag: Token with an
   equality relationship.

   Typical values include:

   ipv4: The device can support IPv4 addresses for both signaling and
   media.

   ipv6: The device can support IPv6 addresses for both signaling and
   media.

   ipv4s-ipv6m: The device can support both IPv4 and IPv6 addresses and
   use the IPv4 address for signaling and the IPv6 address for media.

   ipv6s-ipv4m: The device can support both IPv4 and IPv6 addresses and
   use the IPv6 address for signaling and the IPv4 address for media.

   The feature tag is intended primarily for use in the following
   applications, protocols, services, or negotiation mechanisms: This
   feature tag is most useful in a communications application, for
   describing the capabilities of a device, such as a phone or PDA.

   Examples of typical use: Optimally routing a session and ensuring
   compatibility between IP versions to successfully establish sessions.

   Related standards or documents: RFC XXXX [[Note to IANA: Please
   replace XXXX with the RFC number of this specification.]].

   Security Considerations: Security considerations for this media
   feature tag are discussed in Section 7 of RFC XXXX .  [[Note to IANA:
   Please replace XXXX with the RFC number of this specification.]]


8.  Security Considerations

   When present in a SIP request or response, this media feature tag may
   be used to determine whether a session is routed via a ALG/NAT-PT/
   NAT64 in order to successfully establish a session.  If the values of
   the atypes Media Feature Tags are modified by an intermediary then it
   is possible that a session would fail to be established if the
   modified values caused the network proxies to not insert a ALG/
   NAT-PT/NAT64 when they are needed.  However if the contact address
   itself is also modified this could also prevent a session being
   established.  Integrity protection for the Contact header field
   should be provided.



Boucadair, et al.       Expires January 28, 2010               [Page 14]

Internet-Draft        The atypes media feature tag             July 2009


9.  Acknowledgements

   TBC.


10.  References

10.1.  Normative References

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

   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
              "Indicating User Agent Capabilities in the Session
              Initiation Protocol (SIP)", RFC 3840, August 2004.

10.2.  Informative References

   [I-D.boucadair-mmusic-ccap]
              Boucadair, M. and H. Kaplan, "Session Description Protocol
              (SDP) Connectivity Capability (CCAP)  Attribute",
              draft-boucadair-mmusic-ccap-00 (work in progress),
              July 2009.

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address  Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.

   [I-D.ietf-sipping-v6-transition]
              Camarillo, G., "IPv6 Transition in the Session Initiation
              Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work
              in progress), August 2007.

   [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
              Preferences for the Session Initiation Protocol (SIP)",
              RFC 3841, August 2004.

   [RFC4091]  Camarillo, G. and J. Rosenberg, "The Alternative Network
              Address Types (ANAT) Semantics for the Session Description
              Protocol (SDP) Grouping Framework", RFC 4091, June 2005.

   [RFC4092]  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.




Boucadair, et al.       Expires January 28, 2010               [Page 15]

Internet-Draft        The atypes media feature tag             July 2009


Authors' Addresses

   Mohamed Boucadair
   France Telecom
   3, av Francois Chateau
   Rennes  35000
   France

   Email: mohamed.boucadair@orange-ftgroup.com


   Yoann Noisette
   France Telecom

   Email: yoann.noisette@orange-ftgroup.com


   Andrew Allen
   Research in Motion (RIM)
   300 Knightsbridge Parkway, Suite 360
   Lincolnshire, Illinois  60069
   USA

   Email: aallen@rim.com



























Boucadair, et al.       Expires January 28, 2010               [Page 16]


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