For many applications, application proxies can be appropriate (e.g.,
HTTP proxies, SMTP relays, etc.) Such application proxies will not
be transparent to the UE. Hence, a flexible mechanism with minimal
manual intervention should be used to configure these proxies on IPv6
UEs. Application proxies can be placed, for example, on the GGSN
external interface ("Gi"), or inside the service network.
The authors note that [NATPTappl] discusses the applicability of
NAT-PT, and [NATPTexp] discusses general issues with all forms of
IPv6-IPv4 translation. The problems related to NAT-PT usage in 3GPP
networks are documented in Appendix A.
3.5. IPv4 UE Connecting to an IPv6 Node
The legacy IPv4 nodes are typically nodes that support the
applications that are popular today in the IPv4 Internet: mostly e-
mail and web browsing. These applications will, of course, be
supported in the future IPv6 Internet. However, the legacy IPv4 UEs
are not going to be updated to support future applications. As these
applications are designed for IPv6, and to use the advantages of
newer platforms, the legacy IPv4 nodes will not be able to take
advantage of them. Thus, they will continue to support legacy
services.
Taking the above into account, the traffic to and from the legacy
IPv4 UE is restricted to a few applications. These applications
already mostly rely on proxies or local servers to communicate
between private address space networks and the Internet. The same
methods and technology can be used for IPv4-to-IPv6 transition.
4. IMS Transition Scenarios
As IMS is exclusively IPv6, the number of possible transition
scenarios is reduced dramatically. The possible IMS scenarios are
listed below and analyzed in Sections 4.1 and 4.2.
1) UE connecting to a node in an IPv4 network through IMS
2) Two IPv6 IMS connected via an IPv4 network
For DNS recommendations, we refer to Section 2.4. As DNS traffic is
not directly related to the IMS functionality, the recommendations
are not in contradiction with the IPv6-only nature of the IMS.
4.1. UE Connecting to a Node in an IPv4 Network through IMS
This scenario occurs when an (IPv6) IMS UE connects to a node in the
IPv4 Internet through the IMS, or vice versa. This happens when the
other node is a part of a different system than 3GPP, e.g., a fixed
PC, with only IPv4 capabilities.
Over time, users will upgrade the legacy IPv4 nodes to dual-stack,
often by replacing the entire node, eliminating this particular
problem in that specific deployment.
Still, it is difficult to estimate how many non-upgradable legacy
IPv4 nodes need to communicate with the IMS UEs. It is assumed that
the solution described here is used for limited cases, in which
communications with a small number of legacy IPv4 SIP equipment are
needed.
As the IMS is exclusively IPv6 [3GPP-23.221], for many of the
applications in the IMS, some kind of translators may need to be used
in the communication between the IPv6 IMS and the legacy IPv4 hosts
in cases where these legacy IPv4 hosts cannot be upgraded to support
IPv6.
This section gives a brief analysis of the IMS interworking issues
and presents a high-level view of SIP within the IMS. The authors
recommend that a detailed solution for the general SIP/SDP/media
IPv4/IPv6 transition problem will be specified as soon as possible as
a task within the SIP-related Working Groups in the IETF.
The issue of the IPv4/IPv6 interworking in SIP is somewhat more
challenging than many other protocols. The control (or signaling)
and user (or data) traffic are separated in SIP calls, and thus, the
IMS, the transition of IMS traffic from IPv6 to IPv4, must be handled
at two levels:
1. Session Initiation Protocol (SIP) [RFC3261], and Session
Description Protocol (SDP) [RFC2327] [RFC3266] (Mm-interface)
2. the user data traffic (Mb-interface)
In addition, SIP carries an SDP body containing the addressing and
other parameters for establishing the user data traffic (the media).
Hence, the two levels of interworking cannot be made independently.
Figure 1 shows an example setup for IPv4 and IPv6 interworking in
IMS. The "Interworking Unit" comprises two internal elements a dual
stack SIP server and a transition gateway (TrGW) for the media
traffic. These two elements are interconnected for synchronizing the
interworking of the SIP signaling and the media traffic.
+-------------------------------+ +------------+
| +------+ | | +--------+ |
| |S-CSCF|---| |SIP Serv| |\
| | +------+ | | +--------+ | \ --------
+-|+ | / | | | | | |
| | | +------+ +------+ | | + | -| |-
| |-|-|P-CSCF|--------|I-CSCF| | | | | | () |
| | +------+ +------+ | |+----------+| / ------
| |-----------------------------------|| TrGW ||/
+--+ | IPv6 | |+----------+| IPv4
UE | | |Interworking|
| IP Multimedia CN Subsystem | |Unit |
+-------------------------------+ +------------+
Figure 1: UE using IMS to contact a legacy phone
On reception of an INVITE, the SIP server reserves an IP address and
a port from the TrGW both for IPv4 and IPv6. Then, the SIP server
acts as a B2BUA (Back-to-Back User Agent) and rewrites the SDP of the
INVITE to insert the transition gateway in the middle of the media
flow between the two endpoints.
When performing its B2BUA role, the SIP server acts as a UA (User
Agent) toward both the IMS and the IPv4 host. Consequently, the SIP
server needs to support all the extensions that apply to the session,
which are listed in the Require header fields of the SIP messages.
This approach has a number of important drawbacks, however. The
biggest drawback is that the rewriting of the SDP in the SIP
signaling prevents securing the SDP payload between the two
endpoints. In addition, it breaks the end-to-end negotiation of SIP
extensions required for each session. Therefore, the extensions to
be used in a particular session are limited by the extensions
supported by the SIP server acting as a B2BUA. That is, the
introduction of a new extension requires upgrading not only the UAs
but the B2BUAs as well.
This analysis clearly shows that a new solution for IPv4-IPv6
interworking in SIP networks is needed. The ability to convey
multiple alternative addresses in SDP session descriptions [RFC4091]
represents a step in this direction.
Given the problems related to the use of B2BUAs, it is recommended
that the SIP-related Working Groups quickly work on a solution to
overcome the drawbacks of this approach.
4.2. Two IPv6 IMS Connected via an IPv4 Network
At the early stages of IMS deployment, there may be cases where two
IMS islands are separated by an IPv4 network such as the legacy
Internet. Here both the UEs and the IMS islands are IPv6 only.
However, the IPv6 islands are not connected natively with IPv6.
In this scenario, the end-to-end SIP connections are based on IPv6.
The only issue is to make connection between two IPv6-only IMS
islands over IPv4 network. This scenario is closely related to GPRS
scenario represented in Section 3.2. and similar tunneling solutions
are applicable also in this scenario.
5. About 3GPP UE IPv4/IPv6 Configuration
This informative section aims to give a brief overview of the
configuration needed in the UE in order to access IP-based services.
There can also be other application-specific settings in the UE that
are not described here.
UE configuration is required in order to access IPv6- or IPv4-based
services. The GGSN Access Point has to be defined when using, for
example, the web-browsing application. One possibility is to use
over-the-air configuration [OMA-CP] to configure the GPRS settings.
The user can, for example, visit the operator WWW page and subscribe
the GPRS Access Point settings to his/her UE and receive the settings
via Short Message Service (SMS). After the user has accepted the
settings and a PDP context has been activated, he/she can start
browsing. The Access Point settings can also be typed in manually or
be pre-configured by the operator or the UE manufacturer.
DNS server addresses typically also need to be configured in the UE.
In the case of IPv4 type PDP context, the (IPv4) DNS server addresses
can be received in the PDP context activation (a control plane
mechanism). A similar mechanism is also available for IPv6: so-
called Protocol Configuration Options Information Element (PCO-IE)
specified by the 3GPP [3GPP-24.008]. It is also possible to use
[RFC3736] (or [RFC3315]) and [RFC3646] for receiving DNS server
addresses. Active IETF work on DNS discovery mechanisms is ongoing
and might result in other mechanisms becoming available over time.
The DNS server addresses can also be received over the air (using
SMS) [OMA-CP] or typed in manually in the UE.
When accessing IMS services, the UE needs to know the Proxy-Call
Session Control Function (P-CSCF) IPv6 address. Either a 3GPP-
specific PCO-IE mechanism or a DHCPv6-based mechanism ([RFC3736] and
[RFC3319]) can be used. Manual configuration or configuration over
the air is also possible. IMS subscriber authentication and
registration to the IMS and SIP integrity protection are not
discussed here.
6. Summary and Recommendations
This document has analyzed five GPRS and two IMS IPv6 transition
scenarios. Numerous 3GPP networks are using private IPv4 addresses
today, and introducing IPv6 is important. The two first GPRS
scenarios and both IMS scenarios are seen as the most relevant. The
authors summarize some main recommendations here:
- Dual stack UEs are recommended instead of IPv4-only or IPv6-
only UEs. It is important to take care that applications in
the UEs support IPv6. In other words, applications should be
IP version independent. IPv6-only UEs can become feasible when
IPv6 is widely deployed in the networks, and most services work
on IPv6.
- It is recommended to activate an IPv6 PDP context when
communicating with an IPv6 peer node and an IPv4 PDP context
when communicating with an IPv4 peer node.
- IPv6 communication is preferred to IPv4 communication going
through IPv4 NATs to the same dual stack peer node.
- This document strongly recommends that the 3GPP operators
deploy basic IPv6 support in their GPRS networks as soon as
possible. That makes it possible to lessen the transition
effects in the UEs.
- A tunneling mechanism in the UE may be needed during the early
phases of the IPv6 transition process. A lightweight,
automatic tunneling mechanism should be standardized in the
IETF. See [zeroconf] for more details.
- Tunneling mechanisms can be used in 3GPP networks, and only
generic recommendations are given in this document. More
details can be found, for example, in [RFC4029].
- The authors recommend that a detailed solution for the general
SIP/SDP/media IPv4/IPv6 transition problem be specified as soon
as possible as a task within the SIP-related Working Groups in
the IETF.
7. Security Considerations
Deploying IPv6 has some generic security considerations one should be
aware of [V6SEC]; however, these are not specific to 3GPP transition
and are therefore out of the scope of this memo.
This memo recommends the use of a relatively small number of
techniques. Each technique has its own security considerations,
including:
- native upstream access or tunneling by the 3GPP network
operator,
- use of routing protocols to ensure redundancy,
- use of locally deployed specific-purpose protocol relays and
application proxies to reach IPv4(-only) nodes from IPv6-only
UEs, or
- a specific mechanism for SIP signaling and media translation.
The threats of configured tunneling are described in [RFC4213].
Attacks against routing protocols are described in the respective
documents and in general in [ROUTESEC]. Threats related to protocol
relays have been described in [RFC3142]. The security properties of
SIP internetworking are to be specified when the mechanism is
specified.
In particular, this memo does not recommend the following technique,
which has security issues, not further analyzed here:
- NAT-PT or other translator as a general-purpose transition
mechanism
8. References
8.1. Normative References
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC3261] 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.
[RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks",
RFC 3574, August 2003.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
Mechanisms for IPv6 Hosts and Routers", RFC 4213,
October 2005.
[3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service
(GPRS); Service description; Stage 2 (Release 5)",
December 2002.
[3GPP-23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements
(Release 5)", December 2002.
[3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem (IMS);
Stage 2 (Release 5)", December 2002.
[3GPP-24.228] 3GPP TS 24.228 V5.3.0, "Signalling flows for the IP
multimedia call control based on SIP and SDP; Stage 3
(Release 5)", December 2002.
[3GPP-24.229] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control
Protocol based on SIP and SDP; Stage 3 (Release 5)",
December 2002.
8.2. Informative References
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport
Relay Translator", RFC 3142, June 2001.
[RFC3266] Olson, S., Camarillo, G., and A. Roach, "Support for
IPv6 in Session Description Protocol (SDP)", RFC 3266,
June 2002.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards", RFC
3314, September 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host
Configuration Protocol (DHCPv6) Options for Session
Initiation Protocol (SIP) Servers", RFC 3319, July
2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration
Protocol (DHCP) Service for IPv6", RFC 3736, April
2004.
[RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport
Operational Guidelines", BCP 91, RFC 3901, September
2004.
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
Savola, "Scenarios and Analysis for Introducing IPv6
into ISP Networks", RFC 4029, March 2005.
[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.
[ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
"Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP)", RFC 4214, September 2005.
[NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S.
and H. Wang, "NAT-PT Applicability", Work in Progress,
October 2003.
[NATPTexp] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
Experimental", Work in Progress, July 2005.
[ROUTESEC] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats
to Routing Protocols", Work in Progress, April 2004.
[STEP] Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment
Procedure (STEP)", Work in Progress, January 2004.
[V6SEC] Savola, P.: "IPv6 Transition/Co-existence Security
Considerations", Work in Progress, February 2004.
[zeroconf] Nielsen, K., Morelli, M., Palet, J., Soininen, J., and
J. Wiljakka, "Goals for Zero-Configuration Tunneling in
3GPP", Work in Progress, October 2004.
[3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
specification; Core network protocols; Stage 3 (Release
5)", June 2003.
[OMA-CP] OMA Client Provisioning: Provisioning Architecture
Overview Version 1.1, OMA-WAP-ProvArch-v1_1-20021112-C,
Open Mobile Alliance, 12-Nov-2002.
9. Contributors
Pekka Savola has contributed both text and his IPv6 experience to
this document. He has provided a large number of helpful comments on
the v6ops mailing list. Allison Mankin has contributed text for IMS
Scenario 1 (Section 4.1).
10. Authors and Acknowledgements
This document was written by:
Alain Durand, Comcast
<alain_durand@cable.comcast.com>
Karim El-Malki, Ericsson Radio Systems
<Karim.El-Malki@era.ericsson.se>
Niall Richard Murphy, Enigma Consulting Limited
<niallm@enigma.ie>
Hugh Shieh, AT&T Wireless
<hugh.shieh@attws.com>
Jonne Soininen, Nokia
<jonne.soininen@nokia.com>
Hesham Soliman, Flarion
<h.soliman@flarion.com>
Margaret Wasserman, ThingMagic
<margaret@thingmagic.com>
Juha Wiljakka, Nokia
<juha.wiljakka@nokia.com>
The authors would like to give special thanks to Spencer Dawkins for
proofreading.
The authors would like to thank Heikki Almay, Gabor Bajko, Gonzalo
Camarillo, Ajay Jain, Jarkko Jouppi, David Kessens, Ivan Laloux,
Allison Mankin, Jasminko Mulahusic, Janne Rinne, Andreas Schmid,
Pedro Serna, Fred Templin, Anand Thakur, and Rod Van Meter for their
valuable input.
Appendix A - On the Use of Generic Translators in the 3GPP Networks
This appendix lists mainly 3GPP-specific arguments about generic
translators, even though the use of generic translators is
discouraged.
Due to the significant lack of IPv4 addresses in some domains, port
multiplexing is likely to be a necessary feature for translators
(i.e., NAPT-PT). If NAPT-PT is used, it needs to be placed on the
GGSN external interface (Gi), typically separate from the GGSN.
NAPT-PT can be installed, for example, on the edge of the operator’s
network and the public Internet. NAPT-PT will intercept DNS requests
and other applications that include IP addresses in their payloads,
translate the IP header (and payload for some applications if
necessary), and forward packets through its IPv4 interface.
NAPT-PT introduces limitations that are expected to be magnified
within the 3GPP architecture. [NATPTappl] discusses the
applicability of NAT-PT in more detail. [NATPTexp] discusses general
issues with all forms of IPv6-IPv4 translation.
3GPP networks are expected to handle a very large number of
subscribers on a single GGSN (default router). Each GGSN is expected
to handle hundreds of thousands of connections. Furthermore, high
reliability is expected for 3GPP networks. Consequently, a single
point of failure on the GGSN external interface would raise concerns
on the overall network reliability. In addition, IPv6 users are
expected to use delay-sensitive applications provided by IMS. Hence,
there is a need to minimize forwarding delays within the IP backbone.
Furthermore, due to the unprecedented number of connections handled
by the default routers (GGSN) in 3GPP networks, a network design that
forces traffic to go through a single node at the edge of the network
(typical NAPT-PT configuration) is not likely to scale. Translation
mechanisms should allow for multiple translators, for load sharing
and redundancy purposes.
To minimize the problems associated with NAPT-PT, the following
actions can be recommended:
1. Separate the DNS ALG from the NAPT-PT node (in the "IPv6 to
IPv4" case).
2. Ensure (if possible) that NAPT-PT does not become a single
point of failure.
3. Allow for load sharing between different translators. That is,
it should be possible for different connections to go through
different translators. Note that load sharing alone does not
prevent NAPT-PT from becoming a single point of failure.
Editor’s Contact Information
Comments or questions regarding this document should be sent to the
v6ops mailing list or directly to the document editor:
Juha Wiljakka
Nokia
Visiokatu 3
FIN-33720 TAMPERE, Finland