draft-ietf-v6ops-3gpp-analysis-10.txt   draft-ietf-v6ops-3gpp-analysis-11.txt 
Internet Draft J. Wiljakka (ed.) Internet Draft J. Wiljakka (ed.)
Document: draft-ietf-v6ops-3gpp-analysis-10.txt Nokia Document: draft-ietf-v6ops-3gpp-analysis-11.txt Nokia
Expires: November 2004 Expires: April 2005
May 2004 October 2004
Analysis on IPv6 Transition in 3GPP Networks Analysis on IPv6 Transition in 3GPP Networks
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance and any of which I become aware will be disclosed, in accordance
with RFC 3668. with RFC 3668.
skipping to change at page 2, line 20 skipping to change at page 2, line 20
1.3 Terminology...............................................4 1.3 Terminology...............................................4
2. Transition Mechanisms and DNS Guidelines......................5 2. Transition Mechanisms and DNS Guidelines......................5
2.1 Dual Stack................................................5 2.1 Dual Stack................................................5
2.2 Tunneling.................................................5 2.2 Tunneling.................................................5
2.3 Protocol Translators......................................6 2.3 Protocol Translators......................................6
2.4 DNS Guidelines for IPv4/IPv6 Transition...................6 2.4 DNS Guidelines for IPv4/IPv6 Transition...................6
3. GPRS Transition Scenarios.....................................6 3. GPRS Transition Scenarios.....................................6
3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes...........7 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes...........7
3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network
.............................................................8 .............................................................8
3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network.
............................................................10 .............................................................10
3.4 IPv6 UE Connecting to an IPv4 Node.......................10 3.4 IPv6 UE Connecting to an IPv4 Node.......................10
3.5 IPv4 UE Connecting to an IPv6 Node.......................11 3.5 IPv4 UE Connecting to an IPv6 Node.......................11
4. IMS Transition Scenarios.....................................12 4. IMS Transition Scenarios.....................................12
4.1 UE Connecting to a Node in an IPv4 Network through IMS...12 4.1 UE Connecting to a Node in an IPv4 Network through IMS...12
4.2 Two IPv6 IMS Connected via an IPv4 Network...............14 4.2 Two IPv6 IMS Connected via an IPv4 Network...............14
5. About 3GPP UE IPv4/IPv6 Configuration........................14 5. About 3GPP UE IPv4/IPv6 Configuration........................14
6. Summary and Recommendations..................................15 6. Summary and Recommendations..................................15
7. Security Considerations......................................16 7. Security Considerations......................................15
8. References...................................................16 8. References...................................................17
8.1 Normative................................................16 8.1 Normative................................................17
8.2 Informative..............................................17 8.2 Informative..............................................17
9. Contributors.................................................19 9. Contributors.................................................19
10. Authors and Acknowledgements................................19 10. Authors and Acknowledgements................................19
11. Editor's Contact Information................................20 11. Editor's Contact Information................................20
12. Intellectual Property Statement.............................20 12. Intellectual Property Statement.............................20
13. Copyright...................................................20 13. Copyright...................................................21
Appendix A...................................................21 Appendix A...................................................21
1. Introduction 1. Introduction
This document describes and analyzes the process of transition to This document describes and analyzes the process of transition to
IPv6 in Third Generation Partnership Project (3GPP) General Packet IPv6 in Third Generation Partnership Project (3GPP) General Packet
Radio Service (GPRS) packet networks, in which the radio network Radio Service (GPRS) packet networks, in which the radio network
architecture is based on Global System for Mobile Communications architecture is based on Global System for Mobile Communications
(GSM), or Universal Mobile Telecommunications System (UMTS) / (GSM), or Universal Mobile Telecommunications System (UMTS) /
Wideband Code Division Multiple Access (WCDMA) technology. Wideband Code Division Multiple Access (WCDMA) technology.
skipping to change at page 6, line 35 skipping to change at page 6, line 35
take place at the network layer (using NAT-like techniques), the take place at the network layer (using NAT-like techniques), the
transport layer (using a TCP/UDP proxy) or the application layer transport layer (using a TCP/UDP proxy) or the application layer
(using application relays). (using application relays).
2.4 DNS Guidelines for IPv4/IPv6 Transition 2.4 DNS Guidelines for IPv4/IPv6 Transition
To avoid the DNS name space from fragmenting into parts where some To avoid the DNS name space from fragmenting into parts where some
parts of DNS are only visible using IPv4 (or IPv6) transport, the parts of DNS are only visible using IPv4 (or IPv6) transport, the
recommendation (as of this writing) is to always keep at least one recommendation (as of this writing) is to always keep at least one
authoritative server IPv4-enabled, and to ensure that recursive DNS authoritative server IPv4-enabled, and to ensure that recursive DNS
servers support IPv4. See DNS IPv6 transport guidelines [DNStrans] servers support IPv4. See DNS IPv6 transport guidelines [RFC3901]
for more information. for more information.
3. GPRS Transition Scenarios 3. GPRS Transition Scenarios
This section discusses the scenarios that might occur when a GPRS This section discusses the scenarios that might occur when a GPRS
UE contacts services or other nodes, e.g. a web server in the UE contacts services or other nodes, e.g. a web server in the
Internet. Internet.
The following scenarios described by [RFC3574] are analyzed here. The following scenarios described by [RFC3574] are analyzed here.
In all of the scenarios, the UE is part of a network where there is In all of the scenarios, the UE is part of a network where there is
skipping to change at page 7, line 47 skipping to change at page 7, line 47
The tunneling mechanism may require public IPv4 addresses, but The tunneling mechanism may require public IPv4 addresses, but
there are tunneling mechanisms and deployment scenarios in which there are tunneling mechanisms and deployment scenarios in which
private IPv4 addresses may be used; for instance, if the tunnel private IPv4 addresses may be used; for instance, if the tunnel
endpoints are in the same private domain, or the tunneling endpoints are in the same private domain, or the tunneling
mechanism works through IPv4 NAT. mechanism works through IPv4 NAT.
One deployment scenario uses a laptop computer and a 3GPP UE as a One deployment scenario uses a laptop computer and a 3GPP UE as a
modem. IPv6 packets are encapsulated in IPv4 packets in the laptop modem. IPv6 packets are encapsulated in IPv4 packets in the laptop
computer and an IPv4 PDP context is activated. The tunneling computer and an IPv4 PDP context is activated. The tunneling
mechanism depends on the laptop computers support of tunneling mechanism depends on the laptop computers support of tunneling
mechanisms. Another deployment scenario is performing IPv6-in-IPv4 mechanisms. Another deployment scenario is performing IPv6-in-IPv4
tunneling in the UE itself and activating an IPv4 PDP context. tunneling in the UE itself and activating an IPv4 PDP context.
Closer details for an applicable tunneling mechanism are not Closer details for an applicable tunneling mechanism are not
analyzed in this document. However, a simple host-to-router analyzed in this document. However, a simple host-to-router
(automatic) tunneling mechanism may be a good fit. There is not yet (automatic) tunneling mechanism can be a good fit. There is not yet
consensus on the right approach, and proposed mechanisms so far consensus on the right approach, and proposed mechanisms so far
include [ISATAP] and [STEP]. Especially ISATAP has had some support include [ISATAP] and [STEP]. Especially ISATAP has had some support
in the wg. However, further work is needed to find out the in the wg. Goals for 3GPP zero-configuration tunneling are
requirements for the scenario and to specify the mechanism. documented in [zeroconf].
This document strongly recommends the 3GPP operators to deploy This document strongly recommends the 3GPP operators to deploy
basic IPv6 support in their GPRS networks. That makes it possible basic IPv6 support in their GPRS networks. That makes it possible
to lessen the transition effects in the UEs. to lessen the transition effects in the UEs.
As a general guideline, IPv6 communication is preferred to IPv4 As a general guideline, IPv6 communication is preferred to IPv4
communication going through IPv4 NATs to the same dual stack peer communication going through IPv4 NATs to the same dual stack peer
node. node.
Public IPv4 addresses are often a scarce resource for the operator Public IPv4 addresses are often a scarce resource for the operator
skipping to change at page 10, line 34 skipping to change at page 10, line 34
This would leave only IPv6 UEs. This would leave only IPv6 UEs.
Therefore, overall, the transition scenario involving an IPv4 UE Therefore, overall, the transition scenario involving an IPv4 UE
communicating with an IPv4 peer through an IPv6 network is not communicating with an IPv4 peer through an IPv6 network is not
considered very likely in 3GPP networks. considered very likely in 3GPP networks.
3.4 IPv6 UE Connecting to an IPv4 Node 3.4 IPv6 UE Connecting to an IPv4 Node
Generally speaking, IPv6-only UEs may be easier to manage, but that Generally speaking, IPv6-only UEs may be easier to manage, but that
would require all services to be used over IPv6, and the universal would require all services to be used over IPv6, and the universal
deployment of IPv6 probably isnt realistic in the near future. deployment of IPv6 probably isnt realistic in the near future.
Dual stack implementation requires management of both IPv4 and IPv6 Dual stack implementation requires management of both IPv4 and IPv6
networks and one approach is that "legacy" applications keep using networks and one approach is that "legacy" applications keep using
IPv4 for the foreseeable future and new applications requiring end- IPv4 for the foreseeable future and new applications requiring end-
to-end connectivity (for example, peer-to-peer services) use IPv6. to-end connectivity (for example, peer-to-peer services) use IPv6.
As a general guideline, IPv6-only UEs are not recommended in the As a general guideline, IPv6-only UEs are not recommended in the
early phases of transition until the IPv6 deployment has become so early phases of transition until the IPv6 deployment has become so
prevalent that direct communication with IPv4(-only) nodes will be prevalent that direct communication with IPv4(-only) nodes will be
the exception, and not the rule. It is assumed that IPv4 will the exception, and not the rule. It is assumed that IPv4 will
remain useful for quite a long time, so in general, dual-stack remain useful for quite a long time, so in general, dual-stack
implementation in the UE can be recommended. This recommendation implementation in the UE can be recommended. This recommendation
skipping to change at page 11, line 28 skipping to change at page 11, line 28
not discussed further here. not discussed further here.
For many applications, application proxies can be appropriate (e.g. For many applications, application proxies can be appropriate (e.g.
HTTP proxies, SMTP relays, etc.). Such application proxies will not HTTP proxies, SMTP relays, etc.). Such application proxies will not
be transparent to the UE. Hence, a flexible mechanism with minimal be transparent to the UE. Hence, a flexible mechanism with minimal
manual intervention should be used to configure these proxies on manual intervention should be used to configure these proxies on
IPv6 UEs. Application proxies can be placed, for example, on the IPv6 UEs. Application proxies can be placed, for example, on the
GGSN external interface ("Gi"), or inside the service network. GGSN external interface ("Gi"), or inside the service network.
The authors note that [NATPTappl] discusses the applicability of The authors note that [NATPTappl] discusses the applicability of
NAT-PT. The problems related to NAT-PT usage in 3GPP networks are NAT-PT and [NATPTdep] discusses the reasons to deprecate NAT-PT.
The problems related to NAT-PT usage in 3GPP networks are
documented in appendix A. documented in appendix A.
3.5 IPv4 UE Connecting to an IPv6 Node 3.5 IPv4 UE Connecting to an IPv6 Node
The legacy IPv4 nodes are typically nodes that support the The legacy IPv4 nodes are typically nodes that support the
applications that are popular today in the IPv4 Internet: mostly e- applications that are popular today in the IPv4 Internet: mostly e-
mail and web-browsing. These applications will, of course, be mail and web-browsing. These applications will, of course, be
supported in the future IPv6 Internet. However, the legacy IPv4 UEs supported in the future IPv6 Internet. However, the legacy IPv4 UEs
are not going to be updated to support future applications. As are not going to be updated to support future applications. As
these applications are designed for IPv6, and to use the advantages these applications are designed for IPv6, and to use the advantages
skipping to change at page 12, line 20 skipping to change at page 12, line 20
1) UE connecting to a node in an IPv4 network through IMS 1) UE connecting to a node in an IPv4 network through IMS
2) Two IPv6 IMS connected via an IPv4 network 2) Two IPv6 IMS connected via an IPv4 network
For DNS recommendations, we refer to section 2.4. As DNS traffic is For DNS recommendations, we refer to section 2.4. As DNS traffic is
not directly related to the IMS functionality, the recommendations not directly related to the IMS functionality, the recommendations
are not in contradiction with the IPv6-only nature of the IMS. 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 4.1 UE Connecting to a Node in an IPv4 Network through IMS
This scenario occurs when an IMS UE (IPv6) connects to a node in 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 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 the other node is a part of a different system than 3GPP, e.g. a
fixed PC, with only IPv4 capabilities. fixed PC, with only IPv4 capabilities.
Over time, users will upgrade the legacy IPv4 nodes to dual-stack, Over time, users will upgrade the legacy IPv4 nodes to dual-stack,
often by replacing the entire node, eliminating this particular often by replacing the entire node, eliminating this particular
problem in that specific deployment. problem in that specific deployment.
Still, it is difficult to estimate how many non-upgradeable legacy Still, it is difficult to estimate how many non-upgradeable legacy
IPv4 nodes need to communicate with the IMS UEs. It is assumed that IPv4 nodes need to communicate with the IMS UEs. It is assumed that
skipping to change at page 12, line 45 skipping to change at page 12, line 45
As the IMS is exclusively IPv6 [3GPP 23.221], for many of the As the IMS is exclusively IPv6 [3GPP 23.221], for many of the
applications in the IMS, some kind of translators may need to applications in the IMS, some kind of translators may need to
be used in the communication between the IPv6 IMS and the legacy be used in the communication between the IPv6 IMS and the legacy
IPv4 hosts in cases where these legacy IPv4 hosts cannot be IPv4 hosts in cases where these legacy IPv4 hosts cannot be
upgraded to support IPv6. upgraded to support IPv6.
This section gives a brief analysis of the IMS interworking issues, This section gives a brief analysis of the IMS interworking issues,
and presents a high level view of SIP within the IMS. The authors and presents a high level view of SIP within the IMS. The authors
recommend that a detailed solution for the general SIP/SDP/media recommend that a detailed solution for the general SIP/SDP/media
IPv4/IPv6 transition problem will be specified as soon as possible IPv4/IPv6 transition problem will be specified as soon as possible
as a task within the SIP WGs in the IETF. as a task within the SIP related WGs in the IETF.
As control (or signaling) and user (or data) traffic are separated The issue of the IPv4/IPv6 interworking in SIP is somewhat more
in SIP calls, and thus, the IMS, the transition of IMS traffic from challenging than many other protocols. The control (or signaling)
IPv6 to IPv4 must be handled at two levels: 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 1. Session Initiation Protocol (SIP) [RFC3261], and Session
Description Protocol (SDP) [RFC2327] [RFC3266] (Mm-interface) Description Protocol (SDP) [RFC2327] [RFC3266] (Mm-interface)
2. the user data traffic (Mb-interface)
SIP carries an SDP body containing the addressing and other
parameters for establishing the user data traffic (the media).
Figure 1 shows a signaling edge for SIP and SDP, a dual stack SIP 2. the user data traffic (Mb-interface)
proxy at the border between the 3GPP IPv6-only IMS and the IPv4
systems.
In a possible approach, this edge could contain a SIP ALG, which
would change the IP addresses transported in the SIP messages and
the SDP payload of those messages to the appropriate version. This
approach would have the drawback (like other SDP rewriting
solutions) of impacting authentication mechanisms that may be
needed for other purposes. Moreover, this approach would not take
advantage of SIP's ability to use proxy routing, nor of SDP's
ability to carry multiple alternative addresses. These intrinsic
features of SIP and SDP require a more detailed analysis, but they
could yield benefits. The SIP ALG approach requires NAT-PT (with
the issues described in Appendix A), because the IMS-side IPv6
addresses must be assigned IPv4 addresses for reachability from the
legacy IPv4 side shown in Figure 1. The approach based on intrinsic
SIP proxy routing would not require assignment of temporary IPv4
addresses to the IPv6 IMS endpoints; instead they would be reached
via an IPv4-side address of a SIP proxy acting for them. This SIP
proxy would be doing normal SIP processing.
On the user data transport level, the analysis raises other issues: In addition, SIP carries an SDP body containing the addressing and
the IMS data is time-sensitive, so NAT-PT IPv6-IPv4 protocol other parameters for establishing the user data traffic (the
translation (with the scalability concerns raised in Appendix A) media). Hence, the two levels of interworking cannot be made
may look simplest, but needs a skeptical look. Alternatives include independently.
routing to a transcoder, whose task is to terminate an IPv6 stream
and start an IPv4 stream. Again, this requires a more detailed
analysis.
For each of the protocols, there has to be interoperability for DNS Figure 1 shows an example setup for IPv4 and IPv6 interworking in
queries; see section 2.4 for details. 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 edge| |\ | |S-CSCF|---| |SIP Serv| |\
| | +------+ | | +--------+ | \ -------- | | +------+ | | +--------+ | \ --------
+-|+ | / | | | | | | +-|+ | / | | | | | |
| | | +------+ +------+ | | + | -| |- | | | +------+ +------+ | | + | -| |-
| |-|-|P-CSCF|--------|I-CSCF| | | | | | () | | |-|-|P-CSCF|--------|I-CSCF| | | | | | () |
| | +------+ +------+ | |+----------+| / ------ | | +------+ +------+ | |+----------+| / ------
| |-----------------------------------|| [ALG?] ||/ | |-----------------------------------|| TrGW ||/
+--+ | IPv6 | |+----------+| IPv4 +--+ | IPv6 | |+----------+| IPv4
UE | | |Interworking| UE | | |Interworking|
| IP Multimedia CN Subsystem | |Unit | | IP Multimedia CN Subsystem | |Unit |
+-------------------------------+ +------------+ +-------------------------------+ +------------+
Figure 1: UE using IMS to contact a legacy phone Figure 1: UE using IMS to contact a legacy phone
Figure 1 shows a generic SIP signaling edge - an ALG-like Currently the only way to make the IPv4-IPv6 interworking to work
replacement of the IPv6 addresses with IPv4 addresses using limited in the protocol level, is to have the SIP server reserve IP address
subsets of NAT-PT [RFC2766]. This is a possible approach, but and port from the TrGW both for IPv4 and IPv6. The SIP server then
exploiting SIP's proxy routing to allow the dual homed SIP edge to rewrites the SDP in the SIP signaling to insert the transition
make the address change without a translator could be a promising gateway in the middle of the media flow between the two end-points.
alternative without the scaling problems of NAT-PT. However, this approach has some drawbacks. The biggest drawback is
that the rewriting of SDP in the SIP signaling prevents securing
the SDP payload between the two end-points. Furthermore, this
solution does not use some of newer features of SDP such as
carrying multiple alternative addresses in the SDP.
This analysis clearly shows that a new solution for IPv4-IPv6
interworking in SIP networks is needed. It is recommended that the
SIP related WGs start working on a solution to overcome the
drawbacks of the current solution.
4.2 Two IPv6 IMS Connected via an IPv4 Network 4.2 Two IPv6 IMS Connected via an IPv4 Network
At the early stages of IMS deployment, there may be cases where two 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 IMS islands are separated by an IPv4 network such as the legacy
Internet. Here both the UEs and the IMS islands are IPv6-only. Internet. Here both the UEs and the IMS islands are IPv6-only.
However, the IPv6 islands are not connected natively with IPv6. However, the IPv6 islands are not connected natively with IPv6.
In this scenario, the end-to-end SIP connections are based on 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 The only issue is to make connection between two IPv6-only IMS
skipping to change at page 15, line 38 skipping to change at page 15, line 15
discussed here. discussed here.
6. Summary and Recommendations 6. Summary and Recommendations
This document has analyzed five GPRS and two IMS IPv6 transition This document has analyzed five GPRS and two IMS IPv6 transition
scenarios. Numerous 3GPP networks are using private IPv4 addresses scenarios. Numerous 3GPP networks are using private IPv4 addresses
today, and introducing IPv6 is an important thing. The two first today, and introducing IPv6 is an important thing. The two first
GPRS scenarios and both IMS scenarios are seen the most relevant. GPRS scenarios and both IMS scenarios are seen the most relevant.
The authors summarize some main recommendations here: The authors summarize some main recommendations here:
- Dual-stack UEs are recommended instead of IPv4-only or IPv6- - Dual-stack UEs are recommended instead of IPv4-only or IPv6-
only UEs. It is important to take care that the applications only UEs. It is important to take care that applications in
in the UEs support IPv6. IPv6-only UEs can become feasible the UEs support IPv6. In other words, applications should be
when IPv6 is widely deployed in the networks, and most IP version-independent. IPv6-only UEs can become feasible when
services work on IPv6. IPv6 is widely deployed in the networks, and most services
work on IPv6.
- It is recommended to activate an IPv6 PDP context when - It is recommended to activate an IPv6 PDP context when
communicating with an IPv6 peer node and an IPv4 PDP context communicating with an IPv6 peer node and an IPv4 PDP context
when communicating with an IPv4 peer node. when communicating with an IPv4 peer node.
- IPv6 communication is preferred to IPv4 communication going - IPv6 communication is preferred to IPv4 communication going
through IPv4 NATs to the same dual stack peer node. through IPv4 NATs to the same dual stack peer node.
- This document strongly recommends the 3GPP operators to deploy - This document strongly recommends the 3GPP operators to deploy
basic IPv6 support in their GPRS networks as soon as possible. basic IPv6 support in their GPRS networks as soon as possible.
That makes it possible to lessen the transition effects in the That makes it possible to lessen the transition effects in the
UEs. UEs.
- A tunneling mechanism in the UE may be needed during the early - A tunneling mechanism in the UE may be needed during the early
phases of the IPv6 transition process. A lightweight, phases of the IPv6 transition process. A lightweight,
automatic tunneling mechanism should be standardized in the automatic tunneling mechanism should be standardized in the
IETF. IETF. See [zeroconf] for more details.
- Tunneling mechanisms can be used in 3GPP networks, and only - Tunneling mechanisms can be used in 3GPP networks, and only
generic recommendations are given in this document. More generic recommendations are given in this document. More
details can be found, for example, in [ISP-sa]. details can be found, for example, in [ISP-sa].
- We recommend that a detailed solution for the general - We recommend that a detailed solution for the general
SIP/SDP/media IPv4/IPv6 transition problem will be specified SIP/SDP/media IPv4/IPv6 transition problem will be specified
as soon as possible as a task within the SIP WGs in the IETF. as soon as possible as a task within the SIP related WGs in
the IETF.
7. Security Considerations 7. Security Considerations
Deploying IPv6 has some generic security considerations one should Deploying IPv6 has some generic security considerations one should
be aware of [V6SEC]; however, these are not specific to 3GPP be aware of [V6SEC]; however, these are not specific to 3GPP
transition, and are therefore out of the scope of this memo. transition, and are therefore out of the scope of this memo.
This memo recommends the use of a relatively small number of This memo recommends the use of a relatively small number of
techniques. Each technique has its own security considerations, techniques. Each technique has its own security considerations,
including: including:
skipping to change at page 16, line 33 skipping to change at page 16, line 12
- native upstream access or tunneling by the 3GPP network - native upstream access or tunneling by the 3GPP network
operator, operator,
- use of routing protocols to ensure redundancy, - use of routing protocols to ensure redundancy,
- use of locally-deployed specific-purpose protocol relays and - use of locally-deployed specific-purpose protocol relays and
application proxies to reach IPv4(-only) nodes from IPv6-only application proxies to reach IPv4(-only) nodes from IPv6-only
UEs, or UEs, or
- a specific mechanism for SIP signalling and media translation - a specific mechanism for SIP signalling and media translation
The threats of configured tunneling are described in [RFC2893-bis]. The threats of configured tunneling are described in [RFC2893-bis].
Attacks against routing protocols are described in the respective Attacks against routing protocols are described in the respective
documents and in general in [ROUTESEC]. Threats related to documents and in general in [ROUTESEC]. Threats related to protocol
protocol relays have been described in [RFC3142]. The security relays have been described in [RFC3142]. The security properties of
properties of SIP internetworking are to be specified when the SIP internetworking are to be specified when the mechanism is
mechanism is specified. specified.
In particular, this memo does not recommend the following technique In particular, this memo does not recommend the following technique
which has security issues, not further analyzed here: which has security issues, not further analyzed here:
- NAT-PT or other translator as a general-purpose transition - NAT-PT or other translator as a general-purpose transition
mechanism mechanism
8. References 8. References
8.1 Normative 8.1 Normative
[RFC2663] Srisuresh, P., Holdrege, M.: IP Network Address [RFC2663] Srisuresh, P., Holdrege, M.: IP Network Address
Translator (NAT) Terminology and Considerations, August 1999. Translator (NAT) Terminology and Considerations, August 1999.
[RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm [RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm
(SIIT), February 2000. (SIIT), February 2000.
skipping to change at page 17, line 20 skipping to change at page 17, line 29
[RFC3574] Soininen, J. (editor): Transition Scenarios for 3GPP [RFC3574] Soininen, J. (editor): Transition Scenarios for 3GPP
Networks, August 2003. Networks, August 2003.
[RFC3667] Bradner, S.: IETF Rights in Contributions, February 2004. [RFC3667] Bradner, S.: IETF Rights in Contributions, February 2004.
[RFC3668] Bradner, S.: Intellectual Property Rights in IETF [RFC3668] Bradner, S.: Intellectual Property Rights in IETF
Technology, February 2004. Technology, February 2004.
[RFC2893-bis] Nordmark, E. and Gilligan, R. E.: "Basic Transition [RFC2893-bis] Nordmark, E. and Gilligan, R. E.: "Basic Transition
Mechanisms for IPv6 Hosts and Routers", January 2004, draft-ietf- Mechanisms for IPv6 Hosts and Routers", September 2004, draft-ietf-
v6ops-mech-v2-02.txt, work in progress. v6ops-mech-v2-06.txt, work in progress.
[3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service [3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service
(GPRS); Service description; Stage 2 (Release 5)", December 2002. (GPRS); Service description; Stage 2 (Release 5)", December 2002.
[3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements [3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements
(Release 5)", December 2002. (Release 5)", December 2002.
[3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem [3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem
(IMS); Stage 2 (Release 5)", December 2002. (IMS); Stage 2 (Release 5)", December 2002.
skipping to change at page 18, line 18 skipping to change at page 18, line 27
[RFC3319] Schulzrinne, H., Volz, B.: Dynamic Host Configuration [RFC3319] Schulzrinne, H., Volz, B.: Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
Servers, July 2003. Servers, July 2003.
[RFC3646] Droms, R. (ed.): DNS Configuration options for DHCPv6, [RFC3646] Droms, R. (ed.): DNS Configuration options for DHCPv6,
December 2003. December 2003.
[RFC3736] Droms, R.: Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R.: Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6, April 2004. (DHCP) Service for IPv6, April 2004.
[DNStrans] Durand, A. and Ihren, J.: "DNS IPv6 transport [RFC3901] Durand, A. and Ihren, J.: DNS IPv6 Transport Operational
operational guidelines", March 2004, draft-ietf-dnsop-ipv6- Guidelines, September 2004.
transport-guidelines-02.txt, work in progress.
[ISATAP] Templin, F., Gleeson, T., Talwar, M. and Thaler, D.: [ISATAP] Templin, F., Gleeson, T., Talwar, M. and Thaler, D.:
"Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", April "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", April
2004, draft-ietf-ngtrans-isatap-21.txt, work in progress. 2004, draft-ietf-ngtrans-isatap-22.txt, work in progress.
[ISP-sa] Lind, M., Ksinant, V., Park, D. and Baudot, A.: "Scenarios [ISP-sa] Lind, M., Ksinant, V., Park, D. and Baudot, A.: "Scenarios
and Analysis for Introducing IPv6 into ISP Networks", April 2004, and Analysis for Introducing IPv6 into ISP Networks", June 2004,
draft-ietf-v6ops-isp-scenarios-analysis-02.txt, work in progress. draft-ietf-v6ops-isp-scenarios-analysis-03.txt, work in progress.
[NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S. [NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S.
and Wang, H.: "NAT-PT Applicability", October 2003, draft-satapati- and Wang, H.: "NAT-PT Applicability", October 2003, draft-satapati-
v6ops-natpt-applicability-00.txt, work in progress. v6ops-natpt-applicability-00.txt, work in progress, the draft has
expired.
[NATPTdep] Aoun, C. and Davies, E.: "Reasons to Deprecate NAT-PT",
September 2004, draft-aoun-v6ops-natpt-deprecate-00.txt, work in
progress.
[ROUTESEC] Barbir, A., Murphy, S. and Yang, Y.: "Generic Threats to [ROUTESEC] Barbir, A., Murphy, S. and Yang, Y.: "Generic Threats to
Routing Protocols", April 2004, draft-ietf-rpsec-routing-threats- Routing Protocols", April 2004, draft-ietf-rpsec-routing-threats-
06.txt, work in progress. 06.txt, work in progress.
[STEP] Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment [STEP] Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment
Procedure (STEP)", January 2004, draft-savola-v6ops-conftun-setup- Procedure (STEP)", January 2004, draft-savola-v6ops-conftun-setup-
02.txt, work in progress. 02.txt, work in progress, the draft has expired.
[V6SEC] Savola, P.: "IPv6 Transition/Co-existence Security [V6SEC] Savola, P.: "IPv6 Transition/Co-existence Security
Considerations", February 2004, draft-savola-v6ops-security- Considerations", February 2004, draft-savola-v6ops-security-
overview-02.txt, work in progress. overview-02.txt, work in progress, the draft has expired.
[zeroconf] Nielsen, K., Morelli, M., Palet, J., Soininen, J. and
Wiljakka, J.: "Goals for Zero-Configuration Tunneling in 3GPP",
October 2004, draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt, work
in progress.
[3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer [3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer
3 specification; Core network protocols; Stage 3 (Release 5)", June 3 specification; Core network protocols; Stage 3 (Release 5)", June
2003. 2003.
[OMA-CP] OMA Client Provisioning: Provisioning Architecture [OMA-CP] OMA Client Provisioning: Provisioning Architecture
Overview Version 1.1, OMA-WAP-ProvArch-v1_1-20021112-C, Open Mobile Overview Version 1.1, OMA-WAP-ProvArch-v1_1-20021112-C, Open Mobile
Alliance, 12-Nov-2002. Alliance, 12-Nov-2002.
9. Contributors 9. Contributors
skipping to change at page 21, line 11 skipping to change at page 21, line 27
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
Appendix A - On the Use of Generic Translators in the 3GPP Networks Appendix A - On the Use of Generic Translators in the 3GPP Networks
This appendix lists mainly 3GPP-specific arguments about generic This appendix lists mainly 3GPP-specific arguments about generic
translators, even though the use of generic translators is translators, even though the use of generic translators is
discouraged. The section may be removed in future versions of the discouraged.
memo.
Due to the significant lack of IPv4 addresses in some domains, port Due to the significant lack of IPv4 addresses in some domains, port
multiplexing is likely to be a necessary feature for translators 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 (i.e. NAPT-PT). If NAPT-PT is used, it needs to be placed on the
GGSN external (Gi) interface, typically separate from the GGSN. GGSN external (Gi) interface, typically separate from the GGSN.
NAPT-PT can be installed, for example, on the edge of the NAPT-PT can be installed, for example, on the edge of the
operator's network and the public Internet. NAPT-PT will intercept operator's network and the public Internet. NAPT-PT will intercept
DNS requests and other applications that include IP addresses in DNS requests and other applications that include IP addresses in
their payloads, translate the IP header (and payload for some their payloads, translate the IP header (and payload for some
applications if necessary) and forward packets through its IPv4 applications if necessary) and forward packets through its IPv4
interface. interface.
NAPT-PT introduces limitations that are expected to be magnified NAPT-PT introduces limitations that are expected to be magnified
within the 3GPP architecture. Some of these limitations are listed within the 3GPP architecture. Some of these limitations are listed
below (notice that most of them are also relevant for IPv4 NAT). below (notice that most of them are also relevant for IPv4 NAT).
[NATPTappl] discusses the applicability of NAT-PT in more detail. [NATPTappl] discusses the applicability of NAT-PT in more detail.
[NATPTdep] discusses the reasons to deprecate NAT-PT.
1. NAPT-PT is a single point of failure for all ongoing 1. NAPT-PT is a single point of failure for all ongoing
connections. connections.
2. There are additional forwarding delays due to further 2. There are additional forwarding delays due to further
processing, when compared to normal IP forwarding. processing, when compared to normal IP forwarding.
3. There are problems with source address selection due to the 3. There are problems with source address selection due to the
inclusion of a DNS ALG on the same node [NATPT-DNS]. inclusion of a DNS ALG on the same node [NATPT-DNS].
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/