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

Versions: 00

Network Working Group                                     Karim El Malki
INTERNET-DRAFT                                         Gonzalo Camarillo
Expires: June 2004                                              Ericsson
                                                      Jasminko Mulahusic
                                                             Mikael Lind
                                                             TeliaSonera
                                                          Hesham Soliman
                                                                 Flarion

                                                        December 3, 2003






          IPv6-IPv4 Translation mechanism for SIP-based services in
            Third Generation Partnership Project (3GPP) Networks
               <draft-elmalki-sipping-3gpp-translator-00.txt>


Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/lid-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This document is an individual submission to the IETF. Comments
   should be directed to the authors.


Abstract

   There have been discussions on the v6ops mailing list and at IETF
   meetings regarding the suitability of translators (i.e. NAT-PT) as



El Malki et. al.                                                [Page 1]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


   mechanisms for IPv4 to IPv6 transition. It has often been stated that
   NAT-PT is not a mechanism to be recommended in general to solve the
   IPv6-IPv4 transition problem. There have also been discussions
   regarding special scenarios where some form of translators could be
   deployed if their use is documented appropriately. The aim of this
   draft is to document the rationale for using translators in 3GPP
   (Third Generation Partnership Project) networks for IPv6-only SIP-
   based IP Multimedia Subsystem (IMS) services and to describe a
   solution to the problem.


TABLE OF CONTENTS

   1. Introduction.....................................................2
   2. 3GPP Network Requirements, SIP Requirements and constraints......3
   3. Analysis of current SIP solutions for IPv6/v4 transition.........4
      3.1 SIP Layer....................................................4
      3.2 Media Layer..................................................4
   4. IPv4/v6 Transition Solution for IMS..............................5
      4.1 Reference Architecture for the solution......................6
        4.1.1 SIP Edge Proxy...........................................6
        4.1.2 IP Address and Port Mapper (IPAPM).......................7
      4.2 IMS Generated INVITE.........................................7
        4.2.1. Session Policies Usage..................................9
      4.3 Internet Generated INVITE...................................10
      4.4 IPAPM Operation and State Installation......................11
      4.5 Private Addressing in IPv4 User Agent.......................12
        4.5.1 IMS Generated INVITE....................................13
        4.5.2 Internet (private IPv4) Generated INVITE................15
      4.6 Examples....................................................18
   5. Security Considerations.........................................18
   6. IANA Considerations.............................................18
   7. Contributors & Acknowledgements.................................18
   8. Authors' Addresses..............................................18
   9. References......................................................19


1. Introduction

   The Third Generation Partnership Project (3GPP) has adopted IPv6 as
   the protocol to be used to deploy new IP multimedia subsystem (IMS)
   services such as messaging or voice and video over IP. 3GPP networks
   have different constraints from other types of networks, therefore it
   is important to consider the special requirements which make
   translators an attractive solution for transitioning 3GPP networks.
   The 3GPP scenarios and analysis drafts [1][2] describe the 3GPP
   network and transition mechanisms which could be used in such
   networks. These should be used as reference together with RFC 3114
   [3] when reading this document. The aim of this draft is to document
   the reasons why translation can be an attractive mechanism in 3GPP



El Malki et. al.                                                [Page 2]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


   networks and to formulate a solution to the 3GPP IPv6-to-IPv4
   translation problem. This solution considers the impacts on SIP,
   which is used in the IPv6-only 3GPP IMS, and aims to reuse solutions
   and approaches from the SIP and SIPPING WGs.


2. 3GPP Network Requirements, SIP Requirements and constraints

   A 3GPP host communicates using PDP Contexts, which are layer-2 point-
   to-point communication channels between 3GPP hosts and the 3GPP
   network. Before being able to send any IP packets, a host needs to
   activate a PDP Context. It is during the PDP context activation that
   a host normally acquires an IP address. One of the special
   characteristics of PDP Contexts is that a PDP context can only be
   used to carry IPv4 or IPv6 packets but not both. The "PDP Type" which
   is requested by the 3GPP host when establishing a PDP Context will be
   either set to "IPv4" or "IPv6".

   The 3GPP IMS (IP Multimedia Subsystem) will be used to provide new
   multimedia services (e.g. messaging, video, voice, audio) to 3GPP
   hosts. In order to access IMS services the 3GPP host uses a PDP
   Context of type IPv6 (we will call this an IPv6 PDP Context from now
   on). The IMS is based on SIP [4].

   One essential requirement in 3GPP networks is that 3GPP hosts using
   IMS applications over IPv6 must be able to communicate with non-3GPP
   IPv4 hosts (e.g. on Internet) that use SIP applications. In order to
   achieve this, some kind of translation must be available between 3GPP
   network realms and the Internet.

   Another important requirement is to minimize the number of active PDP
   Contexts a host has on any given time. A reason for this is that
   there are practical constraints on the number of PDP Contexts which a
   3GPP host may establish. If a host uses many PDP Contexts it consumes
   extra resources in the 3GPP network. That is because each PDP Context
   requires a state to be maintained in the 3GPP network. In addition,
   each PDP Context would normally require radio signaling and a new
   radio channel to be established to the 3GPP host. Therefore each
   additional PDP Context also consumes extra radio resources required
   to establish the radio channel. For these reasons, any transition
   solution should support the case where a 3GPP host utilises only one
   IPv6 PDP Context, without the need to activate additional IPv4 PDP
   Contexts.

   As specified in [4], media parameters such as transport addresses are
   carried in the body of SIP message bodies. These bodies may be
   end-to-end integrity protected, therefore it may not possible to
   modify them en-route. In general the SIP WG discourages the use of
   intermediaries which alter the contents of SIP message bodies. This
   is a very important consideration for a 3GPP Translator solution.



El Malki et. al.                                                [Page 3]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003



   Also, it is preferred to limit impacts to the installed IPv4 user
   agent base and aim for a solution where most of the changes are made
   to the 3GPP user agent and IMS. That is because it will obviously be
   harder to require changes to SIP user agents on Internet than to
   require new functionality in 3GPP user agents which still have to be
   deployed.


3. Analysis of current SIP solutions for IPv6/v4 transition

   A complete solution for IPv6/v4 transition needs to handle both the
   SIP layer and the media layer (e.g. RTP). Vanilla SIP can handle
   heterogeneous IPv6/v4 networks at the SIP layer as long as proxies
   are properly configured. However, end-points using different address
   spaces need to implement extensions in order to exchange media
   between them. These extensions affect the session description
   protocol in use (e.g. SDP) and the SIP offer/answer state machine.

3.1 SIP Layer

   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 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, if
   the SIP server of a domain is a dual-stack proxy that supports IPv4
   and IPv6, it will be able to receive requests from IPv4-only and from
   IPv6-only hosts. Then, the SIP server will relay the request to the
   user agent using the address provided by the user agent at
   registration time (which could be IPv4 or IPv6).

   The SIP 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 server should always be configured to Record-Route in that
   situation.

3.2 Media Layer

   SIP establishes media sessions using the offer/answer model [5]. One
   end-point, the offerer, sends a session description (the offer) to
   the other end-point, 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



El Malki et. al.                                                [Page 4]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


   session. Offer and answer are written using a session description
   protocol. The most widespread session description protocol at present
   is SDP [6] and 3GPP IMS uses SDP, thus we will focus on it. Session
   descriptions are transmitted end-to-end and are not modified by
   proxies. In this document we sometimes use SIP INVITEs and 200 (OK)
   Responses for simplicity to identify the offer and response model,
   but it should be noted that support for other SIP messages carrying
   the SDP offer/answer is implied.

   Vanilla SDP only allows an end-point to provide a single IP address
   per media stream. However, using the ALT extension [7] it is possible
   to include several IP addresses in the description of a media stream.
   Using ALT, an offerer can provide, for instance, an IPv4 and an IPv6
   address for a particular media stream. The answerer will choose the
   address of the type it supports or prefers.

   An end-point can use several mechanisms to obtain the different
   addresses to be placed in its ALT group in its session description.
   It can be a dual-stack host that configures IPv4 and IPv6 addresses
   or it can use protocols like TURN [8], RSIP [9], STUN [10] or TEREDO
   [11] to discover extra IP addresses which it is reachable at.

   ICE [12] describes how to couple address discovery procedures with
   the offer/answer model. ICE is useful when the user agents are in
   different private addresses spaces, where more than one offer/answer
   exchange is needed to discover a reachable address for the peer.


4. IPv4/v6 Transition Solution for IMS

   As mentioned previously, one important requirement for 3GPP networks
   is that 3GPP hosts running SIP-based IMS applications over IPv6 must
   be able to communicate with IPv4 SIP hosts on the Internet. This
   requires the following to be performed at the borders of the 3GPP
   network:

   1. Ensure that the IP addresses in SDP offers/answers are of the
      appropriate type for a communication to proceed.

   2. Enable media communication by performing IP address and port
      mapping of the media traffic (e.g. RTP/UDP) exchanged between the
      IPv6 IMS user agent and the non-3GPP IPv4 user agent.

   3. Ensure that IP version 4 is used for transport of SIP messages
      between the IMS domain and external IPv4 domains.

   IMS user agents need a means to obtain a public IPv4 address plus a
   port number to place in their session descriptions in order to
   receive media and an IPv6 address plus port number to send media to.
   For incoming (to IMS) media packets, the public destination IPv4



El Malki et. al.                                                [Page 5]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


   address plus port number will be mapped to the 3GPP user agent's own
   IPv6 address plus port number at the edge of the 3GPP network. For
   outgoing (from IMS) media packets, the destination IPv6 address plus
   port number will be mapped to the public IPv4 address plus port
   number of the non-3GPP IPv4 user agent.

   A solution to these problems is given in the following sections.


4.1 Reference Architecture for the solution

   We introduce two network elements: the SIP Edge Proxy and the IP
   Address and Port Mapper (IPAPM). The reference architecture is shown
   in Figure 1.


                                       -------    ------
                                      |  IMS  |  | SIP  |
                                 IPv6 |  SIP  |  | Edge |      --------
                                   ---| proxy |  | Proxy| IPv4|        |
    ------               ------   /   | (CSCF)|--|      |-----|        |
   |      |             |      | /     -------    ------      |        |
   | 3GPP |             | GGSN |/             IPv6  |         |        |
   | IPv6 |=============|      |\                   |         |  IPv4  |
   | host |  IPv6-only  |      | \             -------        |  Net   |
   |      | PDP Context |      |  \  IPv6     |       | IPv4  |        |
    ------               ------    -----------| IPAPM |-------|        |
                                              |       |       |        |
                                               -------         --------

   Figure 1 -  SIP Edge Proxy and IP Address/Port Mapper (IPAPM) in the
               3GPP Network


   We will refer to "Incoming" SIP messages as IPv4 messages going from
   an IPv4 host towards the SIP Edge Proxy, while "Outgoing" messages
   are from the SIP Edge Proxy towards the IPv4 host.

   Note that a user agent on the IPv4 network (Internet) may support
   receiving and transmitting media over both IPv4 and IPv6 (dual-stack)
   or only over IPv4. This is independent of whether the user agent is
   using dual-stack or IPv4-only SIP proxies and registrars. Therefore
   an intermediate node cannot deduce the media IP-type capability of a
   user agent from these characteristics.

4.1.1 SIP Edge Proxy

   The SIP Edge Proxy will naturally be a dual-stack node with both IPv6
   and public IPv4 addresses configured on its interfaces. It will
   perform Record-Routing, as described in Section 3.1 and will be in



El Malki et. al.                                                [Page 6]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


   the path of all the requests coming from and going to the IPv4
   network.

   The SIP Edge Proxy must store and manage a local pool of IPv6 and
   public IPv4 addresses which have been previously configured on the
   interfaces of an IPAPM node. The SIP Edge Proxy may have multiple
   IPv6/v4 address pools each belonging to different physical IPAPM
   nodes. This would enable the SIP Edge Proxy to perform load sharing
   or utilise IPAPMs which are best placed for the communication (e.g.
   by comparing IP addresses).

   Note that the SIP Edge Proxy is a logical entity which may be
   implemented as a part of other SIP proxies. The IPv4 DNS records for
   the domain will point to the SIP Edge Proxy and all the outgoing
   requests with an IPv4 address as the SIP next-hop will be routed to
   it. Since in the 3GPP model it is the S-CSCF proxy which receives all
   incoming SIP messages to the IMS domain, the SIP Edge Proxy could be
   integrated in that node.

4.1.2 IP Address and Port Mapper (IPAPM)

   The IPAPM (IP Address and Port Mapper) is needed because the 3GPP
   IPv6-only host and the IPv4-only host cannot send media traffic to
   each other due to IP layer incompatibility. The IPAPM will simply
   perform the IP address mapping for the appropriate IP address, port,
   protocol tuples on both incoming and outgoing media (RTP) packets.
   The SIP Edge Proxy will install and delete this bidirectional state
   in the IPAPM (see 4.4). It should be noted that the IPAPM operation
   is similar to that of a bidirectional NA(P)T-PT [16] after having
   installed state for a particular connection. That is, the translation
   algorithm (SIIT) is the same. Hence, if needed, an IPAPM device may
   also operate as a normal NA(P)T-PT for a specific limited set of
   (non-IMS) application traffic, but this is not necessarily
   recommended and is outside the scope of this draft (see [2]). There
   are also important differences between IPAPM and NAT-PT, including
   the absence of Application Layer Gateways (ALGs) and the method used
   to install state in the translator. Therefore the use of IPAPMs
   avoids many of the problems normally associated with NAT-PT.


4.2 IMS Generated INVITE

   When a 3GPP user agent sends an SDP offer (e.g. in an INVITE) to an
   Internet user agent with only IPv6 addresses in the SDP, the Internet
   user may be dual-stack (in which case there should be no address
   incompatibility problem) or it may be IPv4-only. If it is IPv4-only,
   the 3GPP user agent will get a final error response back. This final
   error response will typically be a 488 (Not acceptable here) response
   with a warning header with warn code 300 (Incompatible network
   protocol).



El Malki et. al.                                                [Page 7]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003



   This response will traverse the SIP Edge Proxy, which will locally
   assign a public IPv4 address and port number to the IPv6 3GPP user
   agent for this session (Call-id, To tag, From tag) from a local pool
   of addresses/ports. The unique address/port combination should stay
   allocated to the same 3GPP IPv6 user agent for the duration of the
   SIP session. The SIP Edge Proxy must install this mapping state
   information in the IPAPM when it also obtains the 3GPP user's IPv6
   address (in the successive SDP offer, see below).

   The SIP Edge Proxy should add the assigned IPv4 media address and
   port assigned to the 3GPP user agent to the 488 (Not Acceptable Here)
   response. Note that the SIP Edge Proxy should not modify the contents
   of SDP, but append the IPv4 media address to the message using
   session policies [13]. This is in line with what is described in
   [13], which recommends against SDP editing and puts requirements to
   achieve the same goal using a better solution. Therefore this work in
   the SIPPING WG addresses our problem and its completion should be
   encouraged. The SIP Edge Proxy utilises session policies to append
   the assigned IPv4 media address and port to the response. The IPv4
   address must be public. The 3GPP user agent will, upon reception of
   this response, generate a new SDP offer that contains both the IPv4
   and the original IPv6 addresses and uses ALT [7]. This SDP offer will
   traverse the SIP Edge Proxy. Therefore  we are effectively adding a
   requirement to [13] that the solution should allow proxies to request
   the use of certain IP addresses and ports in SDP offers and answers.
   The SIP Edge Proxy can now install a bidirectional mapping in the
   IPAPM between the 3GPP user's IPv6 media address/port and the
   assigned public IPv4 address/port for the session.

   When the IPv4-only user agent sends back a SDP answer containing at
   least a public IPv4 address/port pair, the SIP Edge Proxy locally
   assigns an IPv6 address and port to the IPv4 user agent from a local
   pool of addresses/ports. The unique address/port combination should
   stay allocated to the same IPv4 user agent for the duration of the
   SIP session. The SIP Edge Proxy must install this bidirectional
   mapping state information in the IPAPM. Then the SIP Edge Proxy
   appends this IPv6 address plus port number to the SDP answer. As
   mentioned previously, SDP editing should be avoided and a solution
   satisfying the requirements in [13] should be used. This IPv6 address
   and port will be used by the 3GPP IPv6-only user agent to send media
   to the IPv4 user agent. The IPAPM will map this IPv6 address/port
   pair to the IPv4 address contained in the SDP answer. Media can now
   flow in both directions through the IPAPM. In this paragraph we have
   effectively added a requirement to [13] that the solution should
   allow proxies to request the use of certain IP addresses and ports as
   destination of the media flows.






El Malki et. al.                                                [Page 8]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


   3GPP UA       3GPP SIP        SIP Edge       Internet      Internet
   IPv6          Proxies          Proxy         SIP Proxy     IPv4 UA
    |               |               |              |              |
    |-------------->|-------------->|------------->|------------->|
    | INVITE Offer  |  INVITE Offer | INVITE Offer | INVITE Offer |
    |   (IPv6)      |    (IPv6)     |  (IPv6)      |   (IPv6)     |
    |               |               |              |              |
    |               |            (A)|<-------------|<-------------|
    |<--------------|<--------------|     Error    |     Error    |
    |     Error     |     Error     |              |              |
    |  [IPv4 ext.]  |  [IPv4 ext.]  |              |              |
    |               |               |              |              |
    |-------------->|-------------->|(B)           |              |
    | INVITE Offer  | INVITE Offer  |------------->|------------->|
    | (IPv4, IPv6)  | (IPv4, IPv6)  | INVITE Offer | INVITE Offer |
    |               |               | (IPv4, IPv6) | (IPv4, IPv6) |
    |               |               |              |              |
    |               |            (C)|<-------------|<-------------|
    |<--------------|<--------------|   OK (IPv4)  |   OK (IPv4)  |
    |   OK (IPv4)   |   OK (IPv4)   |              |              |
    |  [IPv6 ext.]  | [IPv6 ext.]   |              |              |
    |               |               |              |              |
    |-------------->|-------------->|------------->|------------->|
    |   ACK         |     ACK       |    ACK       |    ACK       |
    |               |               |              |              |

              Figure 2 - IMS-Generated INVITE Messaging Diagram
                    (Public IPv4 Address on Internet UA)

     (A) - SIP Edge Proxy locally assigns a public IPv4 addr/port to the
           3GPP UA and communicates this to the 3GPP UA by inserting
           this information in the [IPv4 ext.]
     (B) - SIP Edge Proxy installs mapping in IPAPM for 3GPP UA IPv6
           addr/port to locally assigned IPv4 addr/port (IPv4), see (A).
     (C) - SIP Edge Proxy installs mapping in IPAPM for Internet UA IPv4
           addr/port to locally assigned IPv6 addr/port (in [IPv6 ext.])


    (IPvx)      - Represents the IPvx SDP media information (addr/port)
    [IPvx ext.] - Represents a special extension containing the IPvx
                  address/port pair appended to (but separate from) the
                  SDP message.


4.2.1. Session Policies Usage

   In order to install the IPv4 to IPv6 mapping for a session in the
   IPAPM, the SIP Edge Proxy needs to know the IP addresses of both user
   agents, the 3GPP IMS terminal and the Internet user agent. If we
   could assume that both user agents supported session policies, they



El Malki et. al.                                                [Page 9]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


   could use them to inform the SIP Edge Proxy about their respectives
   addresses. However, at present, most of the SIP user agents on the
   Internet do not support session policies. That is why the SIP Edge
   proxy relies on parsing the SDP of the Internet user agent. This is
   possible because the IMS does not allow other session description
   formats than SDP and does not allow SDP encryption (although
   integrity protection is allowed).


4.3 Internet Generated INVITE

   In order to limit the impact on IPv4 user agents on Internet, the SIP
   Edge Proxy will perform a different procedure in the case of SDP
   offers (e.g. INVITE) sent by IPv4 user agents with at least a public
   IPv4 address in their session descriptions.

   Upon receiving this offer, the SIP Edge Proxy will parse the SDP and
   establish that the IPv4 user agent does not currently have IPv6
   addresses but has at least one public IPv4 address. The SIP Edge
   Proxy should then locally assign an IPv6 address plus port to the
   IPv4 user agent for this session. At this point the SIP Edge Proxy
   has enough information to install a bidirectional mapping in the
   IPAPM between the IPv4 user agent's public IPv4 media address/port
   and the IPv6 address/port assigned to it for the session. It will
   also allocate an IPv4 public address/port to the 3GPP IPv6 user
   agent, even though it cannot establish the binding until it obtains
   the 3GPP IPv6 user agent's media address in the SDP answer. The SIP
   Edge Proxy should then append the IPv6 media address and port,
   assigned to the IPv4 user agent, and the IPv4 media address and port,
   assigned to the 3GPP IPv6 user agent, to the SDP offer (e.g. INVITE).
   To achieve this it will not do SIP editing but will use the mechanism
   already described in 4.2 in relation to [13].

   The 3GPP IPv6-only user agent will receive the SDP offer (e.g.
   INVITE) and process the appended IPv6 and IPv4 address/port pairs.
   The 3GPP user agent will use the appended IPv6 address/port to send
   media to the IPv4 user agent. It will then send the SDP answer (e.g.
   200 OK). The SDP answer will contain both its newly assigned IPv4
   address/port (appended to the offer) and its IPv6 address/port and
   uses ALT [7].

   The SDP answer will traverse the SIP Edge Proxy. At this point the
   SIP Edge Proxy can install the bidirectional mapping state in the
   IPAPM between the 3GPP user agent's IPv6 address and the public IPv4
   address/port it was locally assigned earlier (which is also contained
   in the SDP answer itself). The IPv4 user agent will use the public
   IPv4 address and port in the SDP answer to send media to the 3GPP
   IPv6 user agent. Media can now flow in both directions through the
   IPAPM.




El Malki et. al.                                               [Page 10]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


   3GPP UA       3GPP SIP        SIP Edge       Internet      Internet
   IPv6          Proxies          Proxy         SIP Proxy     IPv4 UA
    |               |               |              |              |
    |               |            (D)|<-------------|<-------------|
    |<--------------|<--------------| INVITE Offer | INVITE Offer |
    | INVITE Offer  |  INVITE Offer |   (IPv4)     |   (IPv4)     |
    |    (IPv4)     |    (IPv4)     |              |              |
    |  [IPv6 ext.]  |  [IPv6 ext.]  |              |              |
    |  [IPv4 ext.]  |  [IPv4 ext.]  |              |              |
    |               |               |              |              |
    |-------------->|-------------->|(E)           |              |
    |OK (IPv4, IPv6)|OK (IPv4, IPv6)|------------->|------------->|
    |               |               |OK (IPv4,IPv6)|OK (IPv4,IPv6)|
    |               |               |              |              |
    |<--------------|<--------------|<-------------|<-------------|
    |   ACK         |     ACK       |    ACK       |    ACK       |

           Figure 3 - Internet-Generated INVITE Messaging Diagram
                    (Public IPv4 Address on Internet UA)

    (D) -  SIP Edge Proxy installs mapping in IPAPM for Internet UA IPv4
           address/port to locally assigned IPv6 addr/port (in [IPv6
           ext.]) SIP Edge Proxy also locally assigns IPv4 addr/port to
           3GPP UA (in IPv4 ext.) but does not install IPAPM mapping.
     (E) -  SIP Edge Proxy installs mapping in IPAPM between 3GPP UA IPv6
            addr/port and previously assigned IPv4 addr/port (in
            [IPv4 ext.])


4.4 IPAPM Operation and State Installation

   The installation of state in the IPAPM is intimately coupled with the
   generation of session descriptions (offers and answers) by the user
   agent.

   For incoming media packets (arriving at the IPAPM's IPv4 interface),
   the IPAPM should modify source and destination address and port pairs
   as follows. The IPAPM should make an address/port mapping for packets
   having the public IPv4 source address plus port number that the IPv4
   user agent placed in its session descriptions. The IPAPM should map
   the source address/port of these IPv4 packets to the IPv6 source
   address plus port number assigned by the SIP Edge Proxy to the IPv4
   user agent for this session. The IPAPM must also look for packets
   having the public IPv4 destination/port address corresponding to that
   assigned to the IPv6 user agent by the SIP Edge Proxy. These must be
   mapped to the IPv6 address/port pair contained in the session
   description sent by the IPv6 user agent.

   For outgoing media packets (arriving at the IPAPM's IPv6 interface),
   the IPAPM should modify source and destination address and port pairs



El Malki et. al.                                               [Page 11]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


   as follows. Packets having the IPv6 source address plus port number
   that the 3GPP user agent placed in its session descriptions, must be
   mapped to the IPv4 source address and port assigned by the SIP Edge
   Proxy to the 3GPP user agent for this session. The IPAPM must also
   look for packets having the IPv6 destination/port address
   corresponding to that assigned to the IPv4 user agent by the SIP Edge
   Proxy. These must be mapped to the IPv4 address/port pair contained
   in the session description sent by the IPv4 user agent

   Note that the protocol used for communicating the address/port
   mapping information from SIP Edge Proxy to the IPAPM is beyond the
   scope of this document. Two alternatives are MEGACO [14] and the
   MIDCOM protocol being developed [15].

   [Note for next revision: Specify how long to keep state]


4.5 Private Addressing in IPv4 User Agent

   The procedures described above work fine when the IPv4 user agent has
   a public IPv4 address and provides it in its session description.
   However, many IPv4 user agents are behind NATs. Therefore it is
   necessary for them to discover the public IPv4 address/port which
   they get assigned by the NAT, to be able to use it in end-to-end SDP
   messages.

   To resolve this situation the 3GPP IMS user agent should choose to
   use ICE when the first attempt fails (i.e. Error response to an
   INVITE) or when the peer uses only private IPv4 addresses in its
   offer. The 3GPP user agent would add "a=alt" lines to its media lines
   grouped by ALT, as described in [7] and would run STUN servers on
   those media transport addresses. The IPv4 user agent would be able to
   discover public addresses for itself by communicating with these STUN
   servers. Using ICE and STUN this way allows user agents to discover
   new addresses which allow connectivity to the SIP peer, as described
   in [12]. This mechanism does not require introduction of new servers
   in IMS, but requires additional procedures in the SIP proxy, support
   in the 3GPP user agent and in the IPv4 user agent as described in the
   sections below.

   It may be possible to recommend ICE implementation in 3GPP user
   agents, but support of ICE/STUN in IPv4 user agents is necessary to
   make this communication work. Since at the current time it is
   uncertain whether IPv4 user agents on the Internet will support
   ICE/STUN, it is not possible to guarantee that this procedure will
   work. Should this procedure fail then the user agents will know that
   communication is not possible.

   We assume that the IPv4 user agent utilizes a SIP Proxy which has one
   or more public IPv4 addresses. Therefore this proxy can communicate



El Malki et. al.                                               [Page 12]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


   with the SIP Edge Proxy at the edge of the IMS domain which also has
   at least one public IPv4 address.


4.5.1 IMS Generated INVITE

   As described previously, this solution is based on the ICE mechanism
   [12]. In this case the 3GPP user agent sends an INVITE to the IPv4
   user agent. The IPv4 user agent happens to have only IPv4 private
   addresses. As described previously (see 4.2), this results in an
   Error response from the IPv4 user agent. The SIP Edge Proxy then
   locally assigns an IPv4 address/port to the 3GPP user agent, gets
   ready to install state in the IPAPM and appends this address/port to
   the Error Response. The 3GPP user agent then generates a new INVITE
   and uses the procedure described in ICE [12]. In particular it should
   start STUN servers on the IPv6 addresses it will use in its offer.
   The 3GPP user agent then sends the offer containing "a=alt" lines to
   its media lines grouped by ALT [7]. One of the media addresses must
   be the public IPv4 address which the SIP Edge Proxy appended to the
   previous Error Response. The SIP Edge Proxy now has all the
   information to install bidirectional state in the IPAPM for the 3GPP
   user agent.

   The IPv4 user agent (assuming it supports ICE) runs the ICE procedure
   upon receiving the offer (INVITE) from the 3GPP user agent. In this
   way it discovers at least one public IPv4 address/port pair for
   itself and uses this in its SDP answer. The procedure then follows as
   described in 4.2. Note that it is not strictly necessary that the
   3GPP user agent runs STUN after receiving the response since it does
   not need to discover new addresses for the communication.

   If ICE is not supported by the IPv4 user agent then the communication
   will ultimately fail. The IPv4 user agent will return only private
   IPv4 addresses in its SDP answer. The response will traverse the SIP
   Edge Proxy which will not be able to allocate IPv6 address/port pairs
   mapped to private IPv4 addresses. The 3GPP user agent will receive
   the response, will return an ACK and will immediately send a BYE
   message to terminate the call since it cannot accept the private IPv4
   address in the SDP response.

   Note that according to this mechanism the 3GPP UA should start STUN
   servers on its IPv6 media addresses when it transmits an SDP Offer
   containing IPv4 addresses (message marked with "a=alt lines" in
   Figure 4).









El Malki et. al.                                               [Page 13]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


   3GPP UA       3GPP SIP        SIP Edge       Internet      Internet
   IPv6          Proxies          Proxy         SIP Proxy     IPv4 UA
    |               |               |              |              |
    |-------------->|-------------->|------------->|------------->|
    | INVITE Offer  |  INVITE Offer | INVITE Offer | INVITE Offer |
    |   (IPv6)      |    (IPv6)     |  (IPv6)      |   (IPv6)     |
    |               |               |              |              |
    |               |            (F)|<-------------|<-------------|
    |<--------------|<--------------|     Error    |     Error    |
    |     Error     |      Error    |              |              |
    |  [IPv4 ext.]  |   [IPv4 ext.] |              |              |
    |               |               |              |              |
    |-------------->|-------------->|(G)           |              |
    |  INVITE Offer | INVITE Offer  |------------->|------------->|
    | (IPv4, IPv6)  | (IPv4, IPv6)  | INVITE Offer | INVITE Offer |
    |  a=alt lines  | a=alt lines   | (IPv4, IPv6) | (IPv4, IPv6) |
    |               |               | a=alt lines  | a=alt lines  |
    |               |                              |              |
    |               |             IPAPM            |              |
    |               |               |              |              |
    |               |            (H)|<-------------|<-------------|
    |<--------------|<--------------|STUN Bind.Req.|STUN Bind.Req.|
    |STUN Bind. Req |STUN Bind. Req.|              |              |
    |               |               |              |              |
    |-------------->|-------------->|------------->|------------->|
    |STUN Bind.Resp.|STUN Bind.Resp.|STUN Bind.Resp|STUN Bind.Resp|
    |               |                              |              |
    |               |            SIP Edge          |              |
    |               |             Proxy            |              |
    |               |               |              |              |
    |               |            (J)|<-------------|<-------------|
    |<--------------|<--------------|   OK (IPv4)  |   OK (IPv4)  |
    |   OK (IPv4)   |   OK (IPv4)   |              |              |
    |  [IPv6 ext.]  | [IPv6 ext.]   |              |              |
    |               |               |              |              |
    |-------------->|-------------->|------------->|------------->|
    |   ACK         |     ACK       |    ACK       |    ACK       |
    |               |               |              |              |


              Figure 4 - IMS-Generated INVITE Messaging Diagram
                        (Private IPv4 Address on Internet UA)

     (F) -  SIP Edge Proxy locally assigns a public IPv4 addr/port to the
            3GPP UA and communicates this to the 3GPP UA by inserting
            this information in the [IPv4 ext.]
     (G) -  SIP Edge Proxy installs mapping in IPAPM for 3GPP UA IPv6
            addr/port to locally assigned IPv4 addr/port (IPv4), see (F).
     (H) -  SIP Edge Proxy reads the incoming STUN Binding Request and
            forwards it by translating the IPv4 destination address to



El Malki et. al.                                               [Page 14]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


            the IPv6 address (IPAPM has the mapping, see (E)). As a
            source address it uses the IPv4 address in the original
            message and a IPAPM-owned prefix (PREFIX::a.b.c.d).
     (J)  - SIP Edge Proxy installs mapping in IPAPM for Internet UA IPv4
            addr/port to locally assigned IPv6 addr/port (in [IPv6 ext.])


4.5.2 Internet (private IPv4) Generated INVITE

   As described previously, this solution is based on the ICE mechanism
   [12]. The IPv4 user agent (which only has private IPv4 addresses)
   sends an SDP offer (e.g. INVITE) to the 3GPP IPv6-only user agent
   utilising private addresses. It would add "a=alt" lines to its media
   lines and would run STUN servers on those transport addresses. The
   SDP offer will then traverse the SIP Edge Proxy. The SIP Edge Proxy
   is unable to make the local assignment of an IPv6 address/port pair
   to the IPv4 user agent (see 4.3) because of the private IPv4
   addressing in the SDP offer. However it is able to make a local
   assignment of an IPv4 public address/port to the 3GPP IPv6 user agent
   for this session, and will append this address/port to the SDP offer.
   The mechanism to append this information to the SDP offer is
   described in 4.2.

   When the 3GPP user agent receives the SDP offer it will send back an
   SDP answer (e.g. 200 OK) to allow the STUN procedure to proceed (i.e.
   it can see that the offerer is using STUN). The SDP answer will
   contain the newly assigned public IPv4 address/port (previously
   appended to the SDP offer by the SIP Edge Proxy) and its IPv6 media
   address/ports. The 3GPP user should add "a=alt" lines to its media
   lines and run STUN servers on those media addresses (i.e. excluding
   the IPv4 address since it is an IPv6-only host).

   The SDP answer will traverse the SIP Edge Proxy. The SIP Edge Proxy
   will now be able to install the bidirectional mapping in the IPAPM
   between the 3GPP user agent's IPv6 media address in the SDP answer
   and the public IPv4 address which it locally assigned previously
   (this IPv4 address is also contained in the SDP answer).

   When the IPv4 user agent receives the SDP answer, it will run STUN
   towards the public IPv4 address supplied by the 3GPP user agent in
   SDP as described in [12]. This will allow it to check connectivity to
   the IPv4 address in the answer and learn about public IPv4 addresses
   which it is reachable at.

   At this point the IPAPM will have a binding which allows it to map
   the IPv4 destination address of the STUN Binding Request to the 3GPP
   UA's IPv6 address. However it does not have a binding to map the IPv4
   source address to an IPv6 source address. That is performed by
   combining the original IPv4 address and an IPAPM-owned IPv6 prefix,
   similar to the procedure used in NAT-PT [16] (i.e. PREFIX::a.b.c.d,



El Malki et. al.                                               [Page 15]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


   where a.b.c.d is the IPv4 address). The IPAPM should be STUN-aware to
   allow only STUN packets to undergo this procedure. The IPAPM must
   also maintain one or more IPv6 address prefixes for this purpose
   which must be configured on its IPv6 interface. The IPv6 addresses
   used for this procedure must not be the same as those used for
   mapping operations from the SIP Edge Proxy. The STUN Request will
   therefore reach the 3GPP user agent having the IPAPM-owned IPv6
   address as its source address. The 3GPP UA must extract the original
   IPv4 address from the source address of the STUN Binding Request to
   be used in the Binding Response message. The IPAPM will be able to
   easily map the source/destination addresses of the incoming STUN
   Binding Response from the 3GPP UA by using its bindings (for the
   source address) and by extracting the IPv4 address from the IPv6
   address (for the destination address).

   Once it has found new public IPv4 addresses which allow connectivity
   to the 3GPP user agent, the IPv4 user agent should issue a new offer
   (e.g. re-INVITE or UPDATE) to pass the newly discovered public IPv4
   address to the callee. Now that the IPv4 user agent has at least a
   public address/port pair it can complete the procedure successfully
   as described in 4.3.

   If the IPv4 user agent does not support ICE, the communication would
   fail. One alternative could be to deploy specific servers (e.g. TURN)
   on the edge of the 3GPP network (i.e. IPAPM) if it is found that IPv4
   user agents support other methods to discover public IPv4
   address/ports.

   Note that according to this mechanism the 3GPP UA should start STUN
   servers on its IPv6 media addresses when it transmits an SDP Answer
   containing IPv4 addresses (message marked with "a=alt lines" in
   Figure 5).





















El Malki et. al.                                               [Page 16]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


   3GPP UA       3GPP SIP        SIP Edge       Internet      Internet
   IPv6          Proxies          Proxy         SIP Proxy     IPv4 UA
    |               |               |              |              |
    |               |            (K)|<-------------|<-------------|
    |<--------------|<--------------| INVITE Offer | INVITE Offer |
    | INVITE Offer  |  INVITE Offer |   (IPv4)     |   (IPv4)     |
    |    (IPv4)     |    (IPv4)     |              |              |
    |  [IPv4 ext.]  |  [IPv4 ext.]  |              |              |
    |               |               |              |              |
    |-------------->|-------------->|------------->|------------->|
    |OK (IPv4, IPv6)|OK (IPv4, IPv6)|OK (IPv4,IPv6)|OK (IPv4,IPv6)|
    | a=alt lines   | a=alt lines   | a=alt lines  | a=alt lines  |
    |               |                              |              |
    |               |             IPAPM            |              |
    |               |               |              |              |
    |               |            (L)|<-------------|<-------------|
    |<--------------|<--------------|STUN Bind.Req.|STUN Bind.Req.|
    |STUN Bind. Req |STUN Bind. Req.|              |              |
    |               |               |              |              |
    |-------------->|-------------->|------------->|------------->|
    |STUN Bind.Resp.|STUN Bind.Resp.|STUN Bind.Resp|STUN Bind.Resp|
    |               |                              |              |
    |               |            SIP Edge          |              |
    |               |             Proxy            |              |
    |               |               |              |              |
    |               |            (M)|<-------------|<-------------|
    |<--------------|<--------------| INVITE Offer | INVITE Offer |
    | INVITE Offer  | INVITE Offer  |   (IPv4)     |   (IPv4)     |
    |    (IPv4)     |    (IPv4)     |              |              |
    |  [IPv6 ext.]  |  [IPv6 ext.]  |              |              |
    |               |               |              |              |
    |-------------->|-------------->|------------->|------------->|
    |OK (IPv4, IPv6)|OK (IPv4, IPv6)|OK (IPv4,IPv6)|OK (IPv4,IPv6)|
    |               |               |              |              |
    |<--------------|<--------------|<-------------|<-------------|
    |   ACK         |     ACK       |    ACK       |    ACK       |


           Figure 5 - Internet-Generated INVITE Messaging Diagram
                    (Private IPv4 Address on Internet UA)

     (K) -  SIP Edge Proxy locally assigns IPv4 public addr/port to the
            3GPP UA (in [IPv4 ext.]) but does not install IPAPM state.
     (L) -  SIP Edge Proxy reads the incoming STUN Binding Request and
            forwards it by translating the IPv4 destination address to
            the IPv6 address (IPAPM has the mapping, see (H)). As a
            source address it uses the IPv4 address in the original
            message and a IPAPM-owned prefix (PREFIX::a.b.c.d).
     (M) -  SIP Edge Proxy installs mapping in IPAPM between Internet UA
            IPv4 address/port and a locally assigned IPv6 address/port.



El Malki et. al.                                               [Page 17]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


            This is communicated to the 3GPP UA using the [IPv6 ext.]


4.6 Examples

   TBD.


5. Security Considerations

   TBD.


6. IANA Considerations

   TBD


7. Contributors & Acknowledgements

   Gabor Bajko (Nokia) has contributed to this work with useful
   suggestions to clarify the text. Arne Pehrsson (Ericsson) has
   contributed the STUN address mapping mechanism in 4.5.1 and 4.5.2


8. Authors' Addresses

   Karim El Malki
   Ericsson
   LM Ericssons Vag. 8
   126 25 Stockholm
   Sweden
   Phone:  +46 8 7195803
   E-mail: karim.el-malki@ericsson.com

   Gonzalo Camarillo
   Ericsson
   Advanced Signalling Research Lab.
   FIN-02420 Jorvas
   Finland
   E-mail: gonzalo.camarillo@ericsson.com

   Mikael Lind
   TeliaSonera
   Vitsandsgatan 9B
   SE-12386 Farsta
   Sweden
   E-mail: mikael.lind@teliasonera.com





El Malki et. al.                                               [Page 18]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


   Jasminko Mulahusic
   TeliaSonera
   Vitsandsgatan 9B
   SE-12386 Farsta
   Sweden
   E-mail: jasminko.mulahusic@teliasonera.com

   Hesham Soliman
   Flarion
   E-mail: H.Soliman@flarion.com


9. References

   [1]   Soininen, J. (Ed.), et al., "Transition Scenarios for 3GPP
         Networks", RFC 3574, August 2003.

   [2]   Wiljakka, J. (Ed.), et al., "Analysis on IPv6 Transition in
         3GPP Networks", draft-ietf-v6ops-analysis-07 (work in
         progress), October 2003.

   [3]   Wasserman, M. (Ed.), et al., "Recommendations for IPv6 in Third
         Generation Partnership Project (3GPP) Standards", RFC 3314,
         September 2002.

   [4]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [5]   Rosenberg, J., Schulzrinne, H., "An Offer/Answer Model with the
         Session Description Protocol (SDP) ", RFC 3264, June 2002.

   [6]   Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

   [7]   Camarillo, G. , Rosenberg, J., "The Alternative Semantics for
         the Session Description Protocol Grouping Framework",
         draft-camarillo-mmusic-alt-02 (work in progress), Oct 2003.

   [8]   Rosenberg, J., Weinberger, J., Mahy, R., Huitema, C.,
         "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom
         turn-02 (work in progress), October 2003.

   [9]   Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm
         Specific IP: Framework", RFC 3102, October 2001.

   [10]  Rosenberg, J., Weinberger, J., Huitema, C., Mahy, R., "STUN -
         Simple Traversal of User Datagram Protocol (UDP) Through
         Network Address Translators (NATs)", RFC 3489, March 2003.




El Malki et. al.                                               [Page 19]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


   [11]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs",
         draft-huitema-v6ops-teredo-00 (work in progress), June 2003.

   [12]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
         Methodology for Network Address Translator (NAT) Traversal for
         the Session Initiation Protocol (SIP)",
         draft-ietf-mmusic-ice-00 (work in progress), Oct 2003.

   [13]  Rosenberg, J., "Requirements for Session Policy for the Session
         Initiation Protocol (SIP)", draft-ietf-sipping-session-policy-
         req-00 (work in progress), June 2003.

   [14]  Groves, C., Pantaleo, M., Anderson, T., Taylor, T., "Gateway
         Control Protocol Version 1", RFC 3525, June 2003.

   [15]  Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., Rayhan,
         A., "Middlebox communication architecture and framework", RFC
         3303, August 2002.

   [16]  Tsirtsis, G., Srisuresh, P., "Network Address Translation -
         Protocol Translation", RFC 2766, February 2000.
































El Malki et. al.                                               [Page 20]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.



El Malki et. al.                                               [Page 21]


INTERNET-DRAFT    IPv6-IPv4 Translator for SIP in 3GPP          Dec 2003


Acknowledgement

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

















































El Malki et. al.                                               [Page 22]


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