draft-ietf-v6ops-3gpp-analysis-02.txt   draft-ietf-v6ops-3gpp-analysis-03.txt 
Internet Draft J. Wiljakka (ed.) Internet Draft J. Wiljakka (ed.)
Document: draft-ietf-v6ops-3gpp-analysis-02.txt Nokia Document: draft-ietf-v6ops-3gpp-analysis-03.txt Nokia
Expires: September 2003 Expires: September 2003
March 2003 March 2003
Analysis on IPv6 Transition in 3GPP Networks Analysis on IPv6 Transition in 3GPP Networks
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction..................................................2 1. Introduction..................................................2
1.1 Scope of this Document....................................3 1.1 Scope of this Document....................................3
1.2 Abbreviations.............................................3 1.2 Abbreviations.............................................3
1.3 Terminology...............................................4 1.3 Terminology...............................................4
2. Transition Mechanisms.........................................4 2. Transition Mechanisms.........................................4
2.1 Dual Stack................................................5 2.1 Dual Stack................................................5
2.2 Tunneling.................................................5 2.2 Tunneling.................................................5
2.3 Protocol Translators......................................5 2.3 Protocol Translators......................................5
3. GPRS Transition Scenarios.....................................6 3. GPRS Transition Scenarios.....................................6
3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes...........6 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes...........6
3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 8 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network
3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network10 .............................................................8
3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network
............................................................10
3.4 IPv6 UE Connecting to an IPv4 Node.......................11 3.4 IPv6 UE Connecting to an IPv4 Node.......................11
3.5 IPv4 UE Connecting to an IPv6 Node.......................12 3.5 IPv4 UE Connecting to an IPv6 Node.......................12
4. Transition Scenarios with IMS................................13 4. IMS Transition Scenarios.....................................13
4.1 DNS Interworking in IMS..................................13 4.1 DNS Interworking in IMS..................................13
4.2 UE Connecting to a Node in an IPv4 Network through IMS...14 4.2 UE Connecting to a Node in an IPv4 Network through IMS...14
4.3 Two IMS Islands Connected over IPv4 Network..............16 4.3 Two IMS Islands Connected over IPv4 Network..............16
5. Security Considerations......................................16 5. Security Considerations......................................16
6. Changes from draft-ietf-v6ops-3gpp-analysis-01.txt...........16 6. Changes from draft-ietf-v6ops-3gpp-analysis-02.txt...........16
7. Copyright....................................................16 7. Copyright....................................................16
8. References...................................................17 8. References...................................................17
8.1 Normative................................................17 8.1 Normative................................................17
8.2 Informative..............................................18 8.2 Informative..............................................18
9. Authors and Acknowledgements.................................20 9. Authors and Acknowledgements.................................20
10. Editor's Contact Information................................20 10. Editor's Contact Information................................20
1. Introduction 1. Introduction
This document describes and analyzes the process of transition to This document describes and analyzes the process of transition to
skipping to change at page 3, line 4 skipping to change at page 3, line 6
The transition scenarios are documented in [3GPP-SCEN] and this The transition scenarios are documented in [3GPP-SCEN] and this
document will further analyze them. The scenarios are divided into document will further analyze them. The scenarios are divided into
two categories: GPRS scenarios and IMS scenarios. two categories: GPRS scenarios and IMS scenarios.
GPRS scenarios are the following: GPRS scenarios are the following:
- Dual Stack UE connecting to IPv4 and IPv6 nodes - Dual Stack UE connecting to IPv4 and IPv6 nodes
- IPv6 UE connecting to an IPv6 node through an IPv4 network - IPv6 UE connecting to an IPv6 node through an IPv4 network
- IPv4 UE connecting to an IPv4 node through an IPv6 network - IPv4 UE connecting to an IPv4 node through an IPv6 network
- IPv6 UE connecting to an IPv4 node - IPv6 UE connecting to an IPv4 node
- IPv4 UE connecting to an IPv6 node - IPv4 UE connecting to an IPv6 node
Two IMS scenarios are:
IMS scenarios are the following:
- UE connecting to a node in an IPv4 network through IMS - UE connecting to a node in an IPv4 network through IMS
- Two IMS islands connected via IPv4 network - Two IMS islands connected via IPv4 network
The focus is on analyzing different transition scenarios, The focus is on analyzing different transition scenarios,
applicable transition mechanisms and finding solutions for those applicable transition mechanisms and finding solutions for those
transition scenarios. In the scenarios, the User Equipment (UE) transition scenarios. In the scenarios, the User Equipment (UE)
connects to nodes in other networks, e.g. in the Internet and connects to nodes in other networks, e.g. in the Internet and
IPv6/IPv4 transition mechanisms are needed. IPv6/IPv4 transition mechanisms are needed.
1.1 Scope of this Document 1.1 Scope of this Document
The scope of this informational document is to analyze and solve The scope of this informational document is to analyze and solve
the possible transition scenarios in the 3GPP defined GPRS network the possible transition scenarios in the 3GPP defined GPRS network
where a UE connects to, or is contacted from the Internet, or where a UE connects to, or is contacted from the Internet, or
another UE. The document covers scenarios with and without the use another UE. The document covers scenarios with and without the use
of the SIP based IP Multimedia Core Network Subsystem (IMS). This of the SIP based IP Multimedia Core Network Subsystem (IMS). This
document is not focused on radio interface issues; both 3GPP Second document is not focused on radio interface issues; both 3GPP Second
(GSM) and Third Generation (UMTS) radio network architectures will (GSM) and Third Generation (UMTS) radio network architectures will
be covered by these scenarios. be covered by these scenarios.
The transition mechanisms specified by the IETF Ngtrans / v6ops The transition mechanisms specified by the IETF Ngtrans and v6ops
Working Group shall be used. This document shall not specify any Working Groups shall be used. This document shall not specify any
new transition mechanisms, but if a need for a new mechanism is new transition mechanisms, but if a need for a new mechanism is
found, this will be reported to the v6ops Working Group. found, that will be reported to the v6ops Working Group.
1.2 Abbreviations 1.2 Abbreviations
2G Second Generation Mobile Telecommunications, for 2G Second Generation Mobile Telecommunications, for
example GSM and GPRS technologies. example GSM and GPRS technologies.
3G Third Generation Mobile Telecommunications, for example 3G Third Generation Mobile Telecommunications, for example
UMTS technology. UMTS technology.
3GPP Third Generation Partnership Project 3GPP Third Generation Partnership Project
ALG Application Level Gateway ALG Application Level Gateway
APN Access Point Name. The APN is a logical name referring APN Access Point Name. The APN is a logical name referring
skipping to change at page 5, line 18 skipping to change at page 5, line 18
enables support for both IPv4 and IPv6 and it is also needed to enables support for both IPv4 and IPv6 and it is also needed to
perform IPv6 in IPv4 tunneling. UEs with dual stack and public / perform IPv6 in IPv4 tunneling. UEs with dual stack and public /
global IP addresses can often access both IPv4 and IPv6 services global IP addresses can often access both IPv4 and IPv6 services
without additional translators in the network. without additional translators in the network.
2.2 Tunneling 2.2 Tunneling
Tunneling is a transition mechanism that requires dual IPv4/IPv6 Tunneling is a transition mechanism that requires dual IPv4/IPv6
stack functionality in the encapsulating and decapsulating nodes. stack functionality in the encapsulating and decapsulating nodes.
Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6. Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6.
IPv6-in-IPv4 tunneling mechanisms are implemented by virtual IPv6-in-IPv4 tunneling mechanisms perform as virtual IPv6 links
interfaces that are configured over one or more physical IPv4 over IPv4, and they are implemented by virtual IPv6 interfaces that
interfaces. Sending nodes encapsulate IPv6 packets in IPv4 packets are configured over one or more physical IPv4 interfaces. Sending
when the IPv6 routing table determines that the next hop toward the nodes encapsulate IPv6 packets in IPv4 packets when the IPv6
IPv6 destination address is via a tunnel interface. Receiving nodes routing table determines that the next hop toward the IPv6
destination address is via a tunnel interface. Receiving nodes
decapsulate IPv6 packets from IPv4 packets that arrive on tunnel decapsulate IPv6 packets from IPv4 packets that arrive on tunnel
interfaces. Tunneling can be static or dynamic. interfaces. Tunneling can be static or dynamic.
Static (configured) tunnel interfaces are virtual IPv6 point-to- Static (configured) tunnels are fixed IPv6 links over IPv4. They
point links over IPv4. They require static configuration of the require static configuration of the IPv6 source, IPv6 next-hop and
IPv6 source, IPv6 next-hop and IPv4 destination addresses for IPv6- IPv4 destination addresses for IPv6-in-IPv4 encapsulation. The IPv6
in-IPv4 encapsulation. The IPv6 destination address is specified by
the application and is used to determine the IPv6 next-hop address
via longest-prefix-match in the IPv6 routing table. Configured
tunnels are specified in [RFC2893].
Dynamic (automatic) tunnel interfaces are virtual IPv6 point-to-
multipoint links over IPv4. They require static configuration of
the IPv6 source address only. Like in static tunneling, the IPv6
destination address is specified by the application and is used to destination address is specified by the application and is used to
determine the IPv6 next-hop address via a longest-prefix-match determine the IPv6 next-hop address via longest-prefix-match in the
lookup in the IPv6 routing table. But unlike static tunnels, the IPv6 routing table. Configured tunnels are specified in [RFC2893].
IPv4 destination address is derived from the IPv6 next-hop address
in some way, for example, via direct encoding in the IPv6 next-hop Dynamic (automatic) tunnels enable stateless encapsulation of IPv6-
address. This enables stateless encapsulation of IPv6-in-IPv4. in-IPv4. They are virtual IPv6 links over IPv4 where the tunnel
This means that the IPv4 source address is taken from an IPv4 endpoints are not configured, i.e. the links are created
interface over which the automatic tunnel is configured. Examples dynamically, and they only require static configuration of the IPv6
of dynamic tunneling mechanisms are "6to4" [RFC3056], [ISATAP], source address. Like in static tunneling, the IPv6 destination
[DSTM] and [TEREDO]. address is specified by the application and it is used to determine
the IPv6 next-hop address via a longest-prefix-match lookup in the
IPv6 routing table. But unlike static tunnels, the IPv4 destination
address is not configured (fixed); it is derived from the IPv6
next-hop address in some way. For example, the IPv4 destination
address can be embedded in the IPv6 next-hop address. Examples of
dynamic tunneling mechanisms are "6to4" [RFC3056], [ISATAP], [DSTM]
and [TEREDO].
2.3 Protocol Translators 2.3 Protocol Translators
A translator can be defined as an intermediate component between a A translator can be defined as an intermediate component between a
native IPv4 node and a native IPv6 node to enable direct native IPv4 node and a native IPv6 node to enable direct
communication between them without requiring any modifications to communication between them without requiring any modifications to
the end nodes. the end nodes.
Header conversion is a translation mechanism. In header conversion, Header conversion is a translation mechanism. In header conversion,
IPv6 packet headers are converted to IPv4 packet headers, and vice IPv6 packet headers are converted to IPv4 packet headers, and vice
skipping to change at page 6, line 41 skipping to change at page 6, line 41
3) IPv4 UE connecting to an IPv4 node through an IPv6 network 3) IPv4 UE connecting to an IPv4 node through an IPv6 network
4) IPv6 UE connecting to an IPv4 node 4) IPv6 UE connecting to an IPv4 node
5) IPv4 UE connecting to an IPv6 node 5) IPv4 UE connecting to an IPv6 node
3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes
In this scenario, the UE is capable of communicating with both IPv4 In this scenario, the UE is capable of communicating with both IPv4
and IPv6 nodes by activating IPv4 or IPv6 PDP context. This also and IPv6 nodes by activating IPv4 or IPv6 PDP context. This also
requires that the GGSN is supporting both IPv4 and IPv6. The dual requires that the GGSN is supporting both IPv4 and IPv6. The dual
stack UE may have both stacks or only one of them active stack UE may have both stacks or only one of them active
simultaneously. If "IPv6 in IPv4" tunneling is needed, it is often simultaneously. If "IPv6 in IPv4" tunneling is needed, it is
beneficial to activate IPv6 PDP context and make encapsulation / recommended to activate an IPv6 PDP context and make encapsulation
decapsulation in the network (like described in section 3.2). / decapsulation in the network (like described in section 3.2).
However, if the GGSN does not support IPv6, and an application on However, if the GGSN does not support IPv6, and an application on
the UE needs to communicate with an IPv6 node, the UE may activate the UE needs to communicate with an IPv6 node, the UE may activate
an IPv4 PDP context and tunnel IPv6 packets in IPv4 packets using a an IPv4 PDP context and tunnel IPv6 packets in IPv4 packets using a
tunneling mechanism. Tunneling in the UE requires dual stack tunneling mechanism. Tunneling in the UE requires dual stack
capability in the UE. The use of private IPv4 addresses in the UE capability in the UE. The use of private IPv4 addresses in the UE
depends on the support of these addresses by the tunneling depends on the support of these addresses by the tunneling
mechanism and the deployment scenario. In some cases public IPv4 mechanism and the deployment scenario. In some cases public IPv4
addresses are required, but if the tunnel endpoints are in the same addresses are required, but if the tunnel endpoints are in the same
private domain or the tunneling mechanism works through IPv4 NAT, private domain or the tunneling mechanism works through IPv4 NAT,
skipping to change at page 13, line 23 skipping to change at page 13, line 23
Internet. The same methods and technology can be used for IPv4 to Internet. The same methods and technology can be used for IPv4 to
IPv6 transition. IPv6 transition.
An alternative solution could be a general network address An alternative solution could be a general network address
translation mechanisms such as NAT46 [NAT64]. translation mechanisms such as NAT46 [NAT64].
When thinking the DNS issues, the DNS zones containing AAAA records When thinking the DNS issues, the DNS zones containing AAAA records
for the IPv6 nodes need to be served by at least one IPv4 for the IPv6 nodes need to be served by at least one IPv4
accessible DNS server [DNStrans]. accessible DNS server [DNStrans].
4. Transition Scenarios with IMS 4. IMS Transition Scenarios
As the IMS is exclusively IPv6, the number of possible transition As the IMS is exclusively IPv6, the number of possible transition
scenarios is reduced dramatically. In the following, the possible scenarios is reduced dramatically. In the following, the possible
transition scenarios are listed. Those scenarios are analyzed in transition scenarios are listed. Those scenarios are analyzed in
sections 4.2 and 4.3. sections 4.2 and 4.3.
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 IMS islands connected over IPv4 network 2) Two IMS islands connected over IPv4 network
4.1 DNS Interworking in IMS 4.1 DNS Interworking in IMS
skipping to change at page 14, line 19 skipping to change at page 14, line 19
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.
There will probably be few legacy IPv4 nodes in the Internet that There will probably be few legacy IPv4 nodes in the Internet that
will communicate with the IMS UEs. It is assumed that the solution will communicate with the IMS UEs. It is assumed that the solution
described here is used for limited cases, in which communications described here is used for limited cases, in which communications
with a small number of legacy IPv4 SIP equipment are needed. As the with a small number of legacy IPv4 SIP equipment are needed. As the
IMS is exclusively IPv6 [3GPP 23.221], translators have to be used IMS is exclusively IPv6 [3GPP 23.221], translators have to be used
in the communication between the IPv6 IMS and legacy IPv4 hosts, in the communication between the IPv6 IMS and legacy IPv4 hosts,
i.e. making a dual stack based solution is not feasible. This i.e. making a dual stack based solution is not feasible. This
section aims to give an overview on how that interworking can be section aims to give a brief overview on how that interworking can
handled. be handled.
As control (or signaling) and user (or data) traffic are separated As control (or signaling) and user (or data) traffic are separated
in SIP, and thus, the IMS, the translation of the IMS traffic has in SIP, and thus, the IMS, the translation of the IMS traffic has
to be done on two levels - Session Initiation Protocol (SIP) to be done on two levels - Session Initiation Protocol (SIP)
[RFC3261], and Session Description Protocol (SDP) [RFC2327] [RFC3261], and Session Description Protocol (SDP) [RFC2327]
[RFC3266] on the one hand (Mm-interface), and on the actual user [RFC3266] on the one hand (Mm-interface), and on the actual user
data traffic level on the other (Mb-interface). data traffic level on the other (Mb-interface).
SIP and SDP transition has to be made in an SIP/SDP Application SIP and SDP transition has to be made in an SIP/SDP Application
Level Gateway. The ALG has to change the IP addresses transported Level Gateway. The ALG has to change the IP addresses transported
skipping to change at page 15, line 5 skipping to change at page 15, line 5
traffic. However, in order to have an IPv4 address for the IMS UE, traffic. However, in order to have an IPv4 address for the IMS UE,
and to be able to route the user traffic within the legacy IPv4 and to be able to route the user traffic within the legacy IPv4
network to the correct translator, there has to be an IPv4 address network to the correct translator, there has to be an IPv4 address
allocated for the duration of the session from the user traffic allocated for the duration of the session from the user traffic
translator. The allocation of this address from the user traffic translator. The allocation of this address from the user traffic
translator has to be done by the SIP/SDP ALG in order for the translator has to be done by the SIP/SDP ALG in order for the
SIP/SDP ALG to know the correct IPv4 address. This can be achieved SIP/SDP ALG to know the correct IPv4 address. This can be achieved
by using a protocol for the ALG to do the allocation such as MEGACO by using a protocol for the ALG to do the allocation such as MEGACO
[RFC3015]. [RFC3015].
+-------------------------------+ +----------+ +-------------------------------+ +------------+
| +------+ | |+--------+| | +------+ | |+--------+|
| |S-CSCF|---||SIP ALG ||\ | |S-CSCF|---||SIP ALG ||\
| | +------+ | |+--------+| \ -------- | | +------+ | |+--------+| \ --------
+-|+ | / | | | | | | +-|+ | / | | | | | |
| | | +------+ +------+ | | + | -| |- | | | +------+ +------+ | | + | -| |-
| |-|-|P-CSCF|--------|I-CSCF| | | | | | () | | |-|-|P-CSCF|--------|I-CSCF| | | | | | () |
| | +------+ +------+ | |+--------+| / ------ | | +------+ +------+ | |+----------+| / ------
| |-----------------------------------|| NAT-PT ||/ | |-----------------------------------||Translator||/
+--+ | IPv6 | |+--------+| IPv4 +--+ | IPv6 | |+----------+| IPv4
UE | | | | UE | | |Interworking|
| IP Multimedia CN Subsystem | |Translator| | 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 possible configuration scenario where the SIP ALG Figure 1 shows a possible configuration scenario where the SIP ALG
is separate to the CSCFs. The translator can either be set up in a is separate to the CSCFs. The translator can either be set up in a
single device with both SIP translation and media translation, or single device with both SIP translation and media translation, or
those functionalities can be divided to two different entities with those functionalities can be divided to two different entities with
an interface in between. an interface in between. We call the combined network element on
the edge of the IPv6-only IMS an "Interworking Unit" in this
document. One alternative is to use a suitable subset of NAT-PT
[RFC2766] in this network element to take care of the media (user
data) IPv4/IPv6 translation. The problems related to NAT-PT are
documented in subsection 3.4.
A special situation is when the IPv4-only destination node is A special case is when the IPv4-only destination node is registered
registered to a SIP proxy that happens to be dual stack. In such a to a SIP proxy that happens to be dual stack. In such a case, the
case, the connection from the edge of the IMS to the destination connection from the edge of the IMS to the destination network
network could be either IPv4 or IPv6, as the SIP INVITE message could be either IPv4 or IPv6, as the SIP INVITE message sent by the
sent by the IMS UE involves DNS address resolution only for the IMS UE involves DNS address resolution only for the destination SIP
destination SIP proxy (and not for the destination node). If IPv4 proxy (and not for the destination node). If IPv4 is used (from the
is used (from the edge of the IMS to the destination SIP proxy), edge of the IMS to the destination SIP proxy), then no further
then no further IPv4-IPv6 interworking is needed outside the IMS IPv4-IPv6 interworking is needed outside the IMS domain, as IPv4-
domain, as IPv4-IPv6 translation will be performed on the edge of IPv6 translation will be performed on the edge of the IMS.
the IMS.
On the other hand, when IPv6 is used to connect both SIP proxies On the other hand, when IPv6 is used to connect both SIP proxies
(that is more likely), translation is not taken care of in the IMS (that is more likely), translation is not taken care of in the IMS
because there is no way of detecting that the destination node is because there is no way of detecting that the destination node is
IPv4-only (i.e., only the IP version of the destination SIP proxy IPv4-only (i.e., only the IP version of the destination SIP proxy
can be detected from the DNS reply). Thus, IPv6 to IPv4 translation can be detected from the DNS reply). Thus, IPv6 to IPv4 translation
should be performed in the destination SIP domain (for example, should be performed in the destination SIP domain (for example,
implemented in the dual stack SIP proxy). In addition, it could implemented in the dual stack SIP proxy). In addition, it could
also happen (especially in the initial stages of IPv6 deployment) also happen (especially in the initial stages of IPv6 deployment)
that end-to-end IPv6 connectivity between the IMS and the that end-to-end IPv6 connectivity between the IMS and the
skipping to change at page 16, line 15 skipping to change at page 16, line 18
4.3 Two IMS Islands Connected over IPv4 Network 4.3 Two IMS Islands Connected over 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 native IPv6 connected. However, the IPv6 islands are not native IPv6 connected.
In this scenario, the end-to-end SIP connections would be based on In this scenario, the end-to-end SIP connections would be based on
IPv6. The only issue is to make connection between two IPv6-only IPv6. The only issue is to make connection between two IPv6-only
IMS islands over IPv4 network. So, in practice, this scenario is IMS islands over IPv4 network. So, in practice, this scenario is
very closely related to GPRS scenario represented in section 4.2. very closely related to GPRS scenario represented in section 3.2.
IPv4 / IPv6 interworking can be taken care of in the network; the IPv4 / IPv6 interworking can be taken care of in the network; the
basic options are static and dynamic tunneling. The tunnel starting basic options are static and dynamic tunneling. The tunnel starting
point or endpoint should be located on the edge of the IMS domain. point or endpoint should be located on the edge of the IMS domain.
Static "IPv6 in IPv4" tunnels configured between different IMS Static "IPv6 in IPv4" tunnels configured between different IMS
domains would be a good solution. Note that this scenario is domains would be a good solution. Note that this scenario is
comparable to 6bone [6BONE] network operation. comparable to 6bone [6BONE] network operation.
5. Security Considerations 5. Security Considerations
skipping to change at page 16, line 37 skipping to change at page 16, line 40
reachability of IPv4 and IPv6 nodes (use of DNS through reachability of IPv4 and IPv6 nodes (use of DNS through
NAT-PT). NAT-PT DNS ALG problems are described in [NATPT- NAT-PT). NAT-PT DNS ALG problems are described in [NATPT-
DNS] and [Unmaneval]. DNS] and [Unmaneval].
2. The 3GPP specifications do not currently define the usage 2. The 3GPP specifications do not currently define the usage
of DNS Security. They neither disallow the usage of DNSSEC, of DNS Security. They neither disallow the usage of DNSSEC,
nor do they mandate it. nor do they mandate it.
3. NAT-PT breaks DNSSEC. 3. NAT-PT breaks DNSSEC.
6. Changes from draft-ietf-v6ops-3gpp-analysis-01.txt 6. Changes from draft-ietf-v6ops-3gpp-analysis-02.txt
- Editorial changes in some sections - Editorial changes in some sections
- Subsection 4.2: adding short description on destination
network dual stack SIP proxy case
7. Copyright 7. Copyright
The following copyright notice is copied from [RFC2026], Section The following copyright notice is copied from [RFC2026], Section
10.4. It describes the applicable copyright for this document. 10.4. It describes the applicable copyright for this document.
Copyright (C) The Internet Society March 01, 2003. All Rights Copyright (C) The Internet Society March 30, 2003. All Rights
Reserved. Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works. paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet as by removing the copyright notice or references to the Internet
skipping to change at page 18, line 8 skipping to change at page 18, line 8
[RFC2893] Gilligan, R., Nordmark, E.: Transition Mechanisms for [RFC2893] Gilligan, R., Nordmark, E.: Transition Mechanisms for
IPv6 Hosts and Routers, RFC 2893, August 2000. IPv6 Hosts and Routers, RFC 2893, August 2000.
[RFC3015] Cuervo, F., et al: Megaco Protocol Version 1.0, RFC 3015, [RFC3015] Cuervo, F., et al: Megaco Protocol Version 1.0, RFC 3015,
November 2000. November 2000.
[RFC3056] Carpenter, B., Moore, K.: Connection of IPv6 Domains via [RFC3056] Carpenter, B., Moore, K.: Connection of IPv6 Domains via
IPv4 Clouds, RFC 3056, February 2001. IPv4 Clouds, RFC 3056, February 2001.
[RFC3261] J. Rosenberg, et al: SIP: Session Initiation Protocol, [RFC3261] Rosenberg, J., et al.: SIP: Session Initiation Protocol,
June 2002. June 2002.
[RFC3266] S. Olson, G. Camarillo, A. B. Roach: Support for IPv6 in [RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6
Session Description Protocol (SDP), June 2002. in Session Description Protocol (SDP), June 2002.
[3GPP-SCEN] Soininen, J. (editor): "Transition Scenarios for 3GPP [3GPP-SCEN] Soininen, J. (editor): "Transition Scenarios for 3GPP
Networks", January 2003, draft-ietf-v6ops-3gpp-cases-02.txt, work Networks", January 2003, draft-ietf-v6ops-3gpp-cases-02.txt, work
in progress. 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.
skipping to change at page 19, line 14 skipping to change at page 19, line 14
[DSTM] Bound, J., et al: "Dual Stack Transition Mechanism (DSTM)", [DSTM] Bound, J., et al: "Dual Stack Transition Mechanism (DSTM)",
July 2002, draft-ietf-ngtrans-dstm-08.txt, work in progress, the July 2002, draft-ietf-ngtrans-dstm-08.txt, work in progress, the
draft has expired. draft has expired.
[IGP] Cristallo, G., Gastaud, G., Ooms, D., Galand, D., Preguica, [IGP] Cristallo, G., Gastaud, G., Ooms, D., Galand, D., Preguica,
C., Baudot, A., Diribarne, G.: "Connecting IPv6 islands within an C., Baudot, A., Diribarne, G.: "Connecting IPv6 islands within an
IPv4 AS", February 2002, draft-many-ngtrans-connect-ipv6-igp- IPv4 AS", February 2002, draft-many-ngtrans-connect-ipv6-igp-
02.txt, work in progress, the draft has expired. 02.txt, work in progress, the draft has expired.
[ISATAP] Templin, F., et al: "Intra-Site Automatic Tunnel [ISATAP] Templin, F., et al.: "Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP)", January 2003, draft-ietf-ngtrans- Addressing Protocol (ISATAP)", January 2003, draft-ietf-ngtrans-
isatap-12.txt, work in progress. isatap-12.txt, work in progress.
[NAT64] Durand, A.: "NAT64 - NAT46", June 2002, draft-durand- [NAT64] Durand, A.: "NAT64 - NAT46", June 2002, draft-durand-
ngtrans-nat64-nat46-00.txt, work in progress, the draft has ngtrans-nat64-nat46-00.txt, work in progress, the draft has
expired. expired.
[NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766", [NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766",
January 2002, draft-durand-natpt-dns-alg-issues-00.txt, work in January 2003, draft-durand-v6ops-natpt-dns-alg-issues-00.txt, work
progress, the draft has expired. in progress.
[TEREDO] Huitema, C.: "Teredo: Tunneling IPv6 over UDP Through [TEREDO] Huitema, C.: "Teredo: Tunneling IPv6 over UDP Through
NATs", September 2002, draft-ietf-ngtrans-shipworm-08.txt, work in NATs", September 2002, draft-ietf-ngtrans-shipworm-08.txt, work in
progress. progress.
[Unmaneval] Huitema, C., Austein, R., Dilettante, B., Satapati, S., [Unmaneval] Huitema, C., Austein, R., Dilettante, B., Satapati, S.,
van der Pol, R.: "Evaluation of Transition Mechanisms for Unmanaged van der Pol, R.: "Evaluation of Transition Mechanisms for Unmanaged
Networks", November 2002, draft-huitema-ngtrans-unmaneval-01.txt, Networks", November 2002, draft-huitema-ngtrans-unmaneval-01.txt,
work in progress. work in progress.
[6BONE] http://www.6bone.net [6BONE] http://www.6bone.net
9. Authors and Acknowledgements 9. Authors and Acknowledgements
This document is written by: This document is written by:
Alain Durand, Sun Microsystems Alain Durand, Sun Microsystems
<Alain.Durand@sun.com> <Alain.Durand@sun.com>
Karim El-Malki, Ericsson Radio Systems Karim El-Malki, Ericsson Radio Systems
<Karim.El-Malki@era.ericsson.se> <Karim.El-Malki@era.ericsson.se>
Paul Francis, Tahoe Networks
<francis@tahoenetworks.com>
Niall Richard Murphy, Enigma Consulting Limited Niall Richard Murphy, Enigma Consulting Limited
<niallm@enigma.ie> <niallm@enigma.ie>
Hugh Shieh, AT&T Wireless Hugh Shieh, AT&T Wireless
<hugh.shieh@attws.com> <hugh.shieh@attws.com>
Jonne Soininen, Nokia Jonne Soininen, Nokia
<jonne.soininen@nokia.com> <jonne.soininen@nokia.com>
 End of changes. 

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