draft-ietf-v6ops-3gpp-analysis-03.txt   draft-ietf-v6ops-3gpp-analysis-04.txt 
Internet Draft J. Wiljakka (ed.) Internet Draft J. Wiljakka (ed.)
Document: draft-ietf-v6ops-3gpp-analysis-03.txt Nokia Document: draft-ietf-v6ops-3gpp-analysis-04.txt Nokia
Expires: September 2003 Expires: December 2003
March 2003 June 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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document analyzes making the transition to IPv6 in Third This document analyzes the transition to IPv6 in Third Generation
Generation Partnership Project (3GPP) General Packet Radio Service Partnership Project (3GPP) General Packet Radio Service (GPRS)
(GPRS) packet networks. The focus is on analyzing different packet networks. The focus is on analyzing different transition
transition scenarios, applicable transition mechanisms and finding scenarios, applicable transition mechanisms and finding solutions
solutions for those transition scenarios. In these scenarios, the for those transition scenarios. In these scenarios, the User
User Equipment (UE) connects to other nodes, e.g. in the Internet, Equipment (UE) connects to other nodes, e.g. in the Internet, and
and IPv6/IPv4 transition mechanisms are needed. IPv6/IPv4 transition mechanisms are needed.
Table of Contents Table of Contents
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..................................... 5
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 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 7
.............................................................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.......................11 3.4 IPv6 UE Connecting to an IPv4 Node....................... 10
3.5 IPv4 UE Connecting to an IPv6 Node.......................12 3.5 IPv4 UE Connecting to an IPv6 Node.......................12
4. IMS Transition Scenarios.....................................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... 13
4.3 Two IMS Islands Connected over IPv4 Network..............16 4.3 Two IMS Islands Connected over IPv4 Network.............. 15
5. Security Considerations......................................16 5. Security Considerations......................................16
6. Changes from draft-ietf-v6ops-3gpp-analysis-02.txt...........16 6. Changes from draft-ietf-v6ops-3gpp-analysis-03.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................................. 19
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
IPv6 in Third Generation Partnership Project (3GPP) General Packet IPv6 in Third Generation Partnership Project (3GPP) General Packet
Radio Service (GPRS) packet networks. The authors can be found in Radio Service (GPRS) packet networks. The authors can be found in
Authors and Acknowledgements section. Comments, input and feedback Authors and Acknowledgements section.
from the people in the IETF v6ops Working Group are appreciated.
This document analyzes the transition scenarios in 3GPP packet This document analyzes the transition scenarios in 3GPP packet
data networks that might come up in the deployment phase of IPv6. data networks that might come up in the deployment phase of IPv6.
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
skipping to change at page 5, line 8 skipping to change at page 5, line 8
The IPv4/IPv6 transition methods can be divided to: The IPv4/IPv6 transition methods can be divided to:
- dual IPv4/IPv6 stack - dual IPv4/IPv6 stack
- tunneling - tunneling
- protocol translators - protocol translators
2.1 Dual Stack 2.1 Dual Stack
The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider
the 3GPP GPRS core network, dual stack implementation in the GGSN the 3GPP GPRS core network, dual stack implementation in the GGSN
enables support for both IPv4 and IPv6 and it is also needed to enables support for IPv4 and IPv6 PDP contexts. UEs with dual stack
perform IPv6 in IPv4 tunneling. UEs with dual stack and public / and public (global) IP addresses can often access both IPv4 and
global IP addresses can often access both IPv4 and IPv6 services 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 perform as virtual IPv6 links
over IPv4, and they are implemented by virtual IPv6 interfaces that
are configured over one or more physical IPv4 interfaces. Sending
nodes encapsulate IPv6 packets in IPv4 packets when the IPv6
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
interfaces. Tunneling can be static or dynamic.
Static (configured) tunnels are fixed IPv6 links over IPv4. They Tunneling can be static or dynamic. Static (configured) tunnels are
require static configuration of the IPv6 source, IPv6 next-hop and fixed IPv6 links over IPv4, and they are specified in [RFC2893].
IPv4 destination addresses for IPv6-in-IPv4 encapsulation. The IPv6 Dynamic (automatic) tunnels are virtual IPv6 links over IPv4 where
destination address is specified by the application and is used to the tunnel endpoints are not configured, i.e. the links are created
determine the IPv6 next-hop address via longest-prefix-match in the dynamically.
IPv6 routing table. Configured tunnels are specified in [RFC2893].
Dynamic (automatic) tunnels enable stateless encapsulation of IPv6-
in-IPv4. They are virtual IPv6 links over IPv4 where the tunnel
endpoints are not configured, i.e. the links are created
dynamically, and they only require static configuration of the IPv6
source address. Like in static tunneling, the IPv6 destination
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, or vice
versa, and checksums are adjusted or recalculated if necessary. versa, and checksums are adjusted or recalculated if necessary.
NAT-PT (Network Address Translator / Protocol Translator) [RFC2766] NAT-PT (Network Address Translator / Protocol Translator) [RFC2766]
using SIIT [RFC2765] is an example of such a mechanism. using SIIT [RFC2765] is an example of such a mechanism.
Translators are typically needed when the two communicating nodes Translators are typically needed when the two communicating nodes
do not share the same IP version. Translation can actually happen do not share the same IP version. Translation can actually happen
at Layer 3 (using NAT-like techniques), Layer 4 (using a TCP/UDP at Layer 3 (using NAT-like techniques), Layer 4 (using a TCP/UDP
proxy) or Layer 7 (using application relays) proxy) or Layer 7 (using application relays).
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 [3GPP-SCEN] are analyzed here. The following scenarios described by [3GPP-SCEN] 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
at least one router of the same IP version, i.e. GGSN, and it is at least one router of the same IP version, i.e. GGSN, and it is
connecting to a node in a different network. connecting to a node in a different network.
1) Dual Stack UE connecting to IPv4 and IPv6 nodes 1) Dual Stack UE connecting to IPv4 and IPv6 nodes
2) IPv6 UE connecting to an IPv6 node through an IPv4 network 2) IPv6 UE connecting to an IPv6 node through an IPv4 network
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 dual stack UE is capable of communicating
and IPv6 nodes by activating IPv4 or IPv6 PDP context. This also with both IPv4 and IPv6 nodes. It is recommended to activate an
requires that the GGSN is supporting both IPv4 and IPv6. The dual IPv6 PDP context when communicating with an IPv6 peer node and an
stack UE may have both stacks or only one of them active IPv4 PDP context when communicating with an IPv4 peer node. If the
simultaneously. If "IPv6 in IPv4" tunneling is needed, it is 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE
recommended to activate an IPv6 PDP context and make encapsulation activates the appropriate PDP context depending on the type of
/ decapsulation in the network (like described in section 3.2). application it has started or depending on the address of the peer
host it needs to communicate with. If IPv6 PDP contexts are
available and "IPv6 in IPv4" tunneling is needed, it is recommended
to activate an IPv6 PDP context and perform tunneling in the
network. This case is described in more detail in section 3.2.
However, if the GGSN does not support IPv6, and an application on However, the UE may attach to a 3GPP network, in which the SGSN
the UE needs to communicate with an IPv6 node, the UE may activate (Serving GPRS Support Node), the GGSN and the HLR (Home Location
an IPv4 PDP context and tunnel IPv6 packets in IPv4 packets using a Register) support IPv4 PDP contexts by default, but may not support
tunneling mechanism. Tunneling in the UE requires dual stack IPv6 PDP contexts. If the 3GPP network does not support IPv6 PDP
capability in the UE. The use of private IPv4 addresses in the UE contexts, and an application on the UE needs to communicate with an
IPv6(-only) node, the UE may activate an IPv4 PDP context and
encapsulate IPv6 packets in IPv4 packets using a tunneling
mechanism. This might happen in very early phases of IPv6
deployment, or in IPv6 demonstrations and trials.
The UE may be assigned a private or public IPv4 address when the
IPv4 PDP context has been activated, although it is more likely
that it will receive a private address (due to the lack of public
IPv4 addresses). 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 (one example is 6to4 [RFC3056]), but if the
private domain or the tunneling mechanism works through IPv4 NAT, tunnel endpoints are in the same private domain or the tunneling
private IPv4 addresses can be used. One deployment scenario example mechanism works through IPv4 NAT (Network Address Translator),
is using laptop computer and a UMTS UE as a modem. IPv6 packets are private IPv4 addresses can be used (examples are [ISATAP] and
encapsulated in IPv4 packets in the laptop computer and IPv4 PDP [TEREDO]). In general, if tunneling from the host is needed, ISATAP
context is activated. Although "IPv6 in IPv4" tunneling in the UE and 6to4 are preferred and TEREDO is a mechanism of last resort
can be either automatic or configured (by the user), the first when neither of these are applicable.
alternative is more probable, because it is expected that most UE
users just want to use an application in their UE; they might not
even care, whether the network connection is IPv4 or IPv6.
When analyzing a dual stack UE behavior, an application running on One deployment scenario example is using laptop computer and a UMTS
a UE can identify whether the endpoint required is an IPv4 or IPv6 UE as a modem. IPv6 packets are encapsulated in IPv4 packets in the
capable node by examining the address to discover what address laptop computer and an IPv4 PDP context is activated. Although
family category it falls into. Alternatively if a user supplies a "IPv6 in IPv4" tunneling can be either automatic or configured (by
name to be resolved, the DNS may contain records sufficient to the user), the first alternative is favored, because it is expected
identify which protocol should be used to initiate connection with that most UE users just want to use an application in their UE;
the endpoint. Since the UE is capable of native communication with they might not even care, whether the network connection is IPv4 or
both protocols, one of the main concerns of an operator is correct IPv6.
address space and routing management. The operator must maintain
address spaces for both protocols. Public IPv4 addresses often are
a scarce resource for the operator and typically it is not possible
for a UE to have a globally unique IPv4 address continually
allocated for its use. Use of private IPv4 addresses means use of
NATs (Network Address Translators) when communicating with a peer
node outside the operator's network. In large networks, NAT systems
can become very complex, expensive and difficult to maintain.
As a general guideline, IPv6 communication (native or tunneled from As a general guideline, IPv6 communication (native or tunneled from
the UE) is preferred to IPv4 communication going through IPv4 NATs the UE) is preferred to IPv4 communication going through IPv4 NATs
to the same dual stack peer node. In this scenario, the UE talks to to the same dual stack peer node. In this scenario, the UE talks to
the DNS resolver using the IP version that is available via the the DNS resolver using the IP version that is available via the
activated PDP context. activated PDP context.
Keeping the Internet name space unfragmented is an important thing. When analyzing a dual stack UE behavior, an application running on
This covers IPv4 and IPv6. It means that any record in the public a UE can identify whether the endpoint required is an IPv4 or IPv6
Internet should be available unmodified to any nodes, IPv4 or IPv6, capable node by examining the address to discover what address
regardless of the transport being used. The recommended approach family category it falls into. Alternatively, if a user supplies a
is: every recursive DNS server should be either IPv4-only or dual name to be resolved, the DNS may contain records sufficient to
stack and every single DNS zone should be served by at least an identify which protocol should be used to initiate the connection
IPv4 reachable DNS server. This recommendation rules out IPv6-only with the endpoint. Since the UE is capable of native communication
recursive DNS servers and DNS zones served by IPv6-only DNS servers with both protocols, one of the main concerns of an operator is
and this approach could be revisited if translation techniques correct address space and routing management. The operator must
between IPv4 and IPv6 were to be widely deployed [DNStrans]. maintain address spaces for both protocols. Public IPv4 addresses
are often a scarce resource for the operator and typically it is
not possible for a UE to have a globally unique IPv4 address
continuously allocated for its use. Use of private IPv4 addresses
means use of NATs when communicating with a peer node outside the
operator's network. In large networks, NAT systems can become very
complex, expensive and difficult to maintain.
Keeping the Internet name space unfragmented is another important
issue for both IPv4 and IPv6. It means that any record in the
public Internet should be available unmodified to any nodes, IPv4
or IPv6, regardless of the transport being used. The recommended
approach is the following: every recursive DNS server should be
either IPv4-only or dual stack and every single DNS zone should be
served by at least an IPv4 reachable DNS server. This
recommendation rules out IPv6-only recursive DNS servers and DNS
zones served by IPv6-only DNS servers, and this approach could be
revisited if translation techniques between IPv4 and IPv6 were to
be widely deployed [DNStrans].
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
The best solution for this scenario is obtained with tunneling, The best solution for this scenario is obtained with tunneling,
i.e. "IPv6 in IPv4" tunneling is a requirement. An IPv6 PDP context i.e. "IPv6 in IPv4" tunneling is a requirement. An IPv6 PDP context
is activated between the UE and the GGSN. Tunneling is handled in is activated between the UE and the GGSN. Tunneling is handled in
the network, because IPv6 UE is not capable of tunneling (it does the network, because IPv6 UE is not capable of tunneling (it does
not have the dual stack functionality needed for tunneling). not have the dual stack functionality needed for tunneling). The
Encapsulating node can be the GGSN, the edge router between the encapsulating node can be the GGSN, the edge router between the
border of the operator's IPv6 network and the public Internet, or border of the operator's IPv6 network and the public Internet, or
any other dual stack node within the operator's IP network. The any other dual stack node within the operator's IP network. The
encapsulation (uplink) and decapsulation (downlink) can be handled encapsulation (uplink) and decapsulation (downlink) can be handled
by the same network element. Typically the tunneling handled by the by the same network element. Typically the tunneling handled by the
network elements is transparent to the UEs and the IP traffic looks network elements is transparent to the UEs and IP traffic looks
like native IPv6 traffic to them. For the applications, tunneling like native IPv6 traffic to them. For the applications, tunneling
enables end-to-end IPv6 connectivity. Note that this scenario is enables end-to-end IPv6 connectivity. Note that this scenario is
comparable to 6bone [6BONE] network operation. comparable to 6bone [6BONE] network operation.
"IPv6 in IPv4" tunnels between the IPv6 islands can be static or "IPv6 in IPv4" tunnels between IPv6 islands can be either static or
dynamic. The selection of the type of tunneling mechanism is up to dynamic. The selection of the type of tunneling mechanism is up to
the operator / ISP deployment scenario and only generic the operator / ISP deployment scenario and only generic
recommendations can be given in this document. recommendations can be given in this document.
The following subsections are focused on the usage of different The following subsections are focused on the usage of different
tunneling mechanisms when the peer node is in the operator's tunneling mechanisms when the peer node is in the operator's
network or outside the operator's network. The authors note that network or outside the operator's network. The authors note that
where the actual 3GPP network ends and which parts of the network where the actual 3GPP network ends and which parts of the network
belong to the ISP(s) also depends on the deployment scenario. The belong to the ISP(s) also depends on the deployment scenario. The
authors are also not commenting how many ISP functions the 3GPP authors are not commenting how many ISP functions the 3GPP operator
operator should perform. However, many 3GPP operators are ISPs of should perform. However, many 3GPP operators are ISPs of some sort
some sort themselves. themselves. ISP transition scenarios are documented and analyzed in
[ISP-scen], [ISP-analysis] and their future updates.
3.2.1 Tunneling inside the 3GPP Operator's Network 3.2.1 Tunneling inside the 3GPP Operator's Network
Many GPRS operators already have IPv4 backbone networks deployed Many GPRS operators already have IPv4 backbone networks deployed
and they are gradually migrating them while introducing IPv6 and they are gradually migrating them while introducing IPv6
islands. IPv6 backbones can be considered quite rare in the first islands. IPv6 backbones can be considered quite rare in the first
phases of the transition. If the 3GPP operator already has IPv6 phases of the transition. If the 3GPP operator already has IPv6
widely deployed in its network, this subsection is not so relevant. widely deployed in its network, this subsection is not so relevant.
In initial, smaller scale IPv6 deployment, where a small number of In initial, smaller scale IPv6 deployment, where a small number of
IPv6 in IPv4 tunnels are required to connect the IPv6 islands over IPv6 in IPv4 tunnels are required to connect the IPv6 islands over
the 3GPP operator's IPv4 network, manually configured tunnels can the 3GPP operator's IPv4 network, manually configured tunnels can
be used. In a 3GPP network, one IPv6 island could contain the GGSN be used. In a 3GPP network, one IPv6 island could contain the GGSN
while another island contains the operator's IPv6 application while another island contains the operator's IPv6 application
servers. However, manually configured tunnels can be an servers. However, manually configured tunnels can be an
administrative burden when the number of islands and therefore administrative burden when the number of islands and therefore
tunnels rises. tunnels rises. In that case, upgrading parts of the backbone to
dual stack may be the simplest choice. The administrative burden
could also be mitigated by using automated management tools which
are typically necessary to manage large networks anyway.
It is also possible to use dynamic tunneling mechanisms such as Even a dynamic tunneling mechanism, such as "6to4" [RFC3056] or an
"6to4" [RFC3056] and IGP/EGP routing protocol based tunneling IGP/EGP routing protocol based tunneling mechanism [BGP][IGP],
mechanisms [BGP][IGP]. Routing protocol based mechanisms such as could be used if other methods are not suitable. Routing protocol
[BGP] consist of running BGP between the neighboring router tunnel based mechanisms such as [BGP] consist of running BGP between the
endpoints and using multi-protocol BGP extensions to exchange neighboring router tunnel endpoints and using multi-protocol BGP
reachability information of IPv6 prefixes. The routers use this extensions to exchange reachability information of IPv6 prefixes.
information to create IPv6 in IPv4 tunnel interfaces and route IPv6
packets over the IPv4 network. It is possible to combine this with The routers use this information to create IPv6 in IPv4 tunnel
different types of tunnels. interfaces and route IPv6 packets over the IPv4 network. It is
possible to combine this with different types of tunnels.
Connection redundancy should also be noted as an important
requirement in 3GPP networks. Static tunnels on their own don't
provide a routing recovery solution for all scenarios where an IPv6
route goes down. However, they may provide an adequate solution
depending on the design of the network and in presence of other
router redundancy mechanisms. On the other hand, IGP/EGP based
mechanisms can provide redundancy.
"6to4" nodes use special IPv6 addresses with a "6to4" prefix "6to4" nodes use special IPv6 addresses with a "6to4" prefix
containing the IPv4 address of the corresponding "IPv6 in IPv4" containing the IPv4 address of the corresponding "IPv6 in IPv4"
tunnel endpoint ("6to4" router) which performs encapsulation / tunnel endpoint ("6to4" router) which performs encapsulation /
decapsulation. When connecting two nodes with "6to4" addresses, the decapsulation. When connecting two nodes with "6to4" addresses, the
corresponding "6to4" routers use the IPv4 addresses specified in corresponding "6to4" routers use the IPv4 addresses specified in
the "6to4" prefixes to tunnel IPv6 packets through the IPv4 the "6to4" prefixes to tunnel IPv6 packets through the IPv4
network. But if only one of them has a "6to4" address, a "6to4" network. But if only one of them has a "6to4" address, a "6to4"
relay must be present to perform the missing "6to4" router relay must be present to perform the missing "6to4" router
functionality for the native-IPv6 node. In this case there are two functionality for the native-IPv6 node. If we consider the "6to4"
deployment options for "IPv6 in IPv4" tunneling between the "6to4" tunneling mechanism and the 3GPP addressing model (a unique /64
router and the relay. The first option assumes that "6to4" routers prefix allocated for each primary PDP context), a /48 "6to4" prefix
using a given relay each have a default IPv6 route (configured would only be enough for approximately 65000 UEs. Thus, a few
tunnel) pointing to that relay. The other one consists of using an public IPv4 addresses would be needed depending on the size of the
IPv6 exterior routing protocol; this way the set of "6to4" routers operator.
using a given relay obtain native IPv6 routes from it using a
routing protocol such as BGP4+ [RFC2283]. Although this solution is
more complex, it provides effective policy control, i.e. BGP4+
policy determines which "6to4" routers are able to use which relay.
The conclusion is that in most "internal" 3GPP scenarios it is
preferred to use manually configured tunnels or EGP/IGP based
tunneling mechanisms, if it is not feasible to enable IPv6 in the
network infrastructure yet.
3.2.2 Tunneling outside the 3GPP Operator's Network 3.2.2 Tunneling outside the 3GPP Operator's Network
This subsection includes the case when the peer node is outside the This subsection includes the case when the peer node is outside the
operator's network. In that case the "IPv6 in IPv4" tunnel starting operator's network. In that case the "IPv6 in IPv4" tunnel starting
point can be in the operator's network - encapsulating node can be point can be in the operator's network - encapsulating node can be
e.g. the GGSN or the edge router. e.g. the GGSN or the edge router.
The case is pretty straightforward if the upstream ISP provides The case is pretty straightforward if the upstream ISP provides
native IPv6 connectivity to the Internet. If there is no native native IPv6 connectivity to the Internet. If there is no native
IPv6 connectivity available in the 3GPP network, an "IPv6 in IPv4" IPv6 connectivity available in the 3GPP network, an "IPv6 in IPv4"
tunnel should be configured from e.g. the GGSN to the dual stack tunnel should be configured from e.g. the GGSN to the dual stack
border gateway in order to access the upstream ISP. border gateway in order to access the upstream ISP.
If the ISP only provides IPv4 connectivity, then the IPv6 traffic If the ISP only provides IPv4 connectivity, then the IPv6 traffic
initiated from the 3GPP network should be transported tunneled in initiated from the 3GPP network should be transported tunneled in
IPv4 to the ISP. Defining the tunnel endpoint depends on the IPv4 to the ISP. Defining the tunnel endpoint depends on the
deployment scenario. deployment scenario. The authors want to avoid duplicating work and
note here that the ISP transition scenarios are analyzed in [ISP-
scen] and [ISP-analysis].
Usage of manually configured "IPv6 in IPv4" tunneling is sensible Usage of manually configured "IPv6 in IPv4" tunneling is sensible
if the number of the tunnels can be kept limited. It is assumed if the number of the tunnels can be kept limited. It is assumed
that a maximum of 10-15 configured "IPv6 in IPv4" tunnels from the that a maximum of 10-15 configured "IPv6 in IPv4" tunnels from the
3GPP network towards the ISP / Internet should be sufficient. 3GPP network towards the ISP / Internet should be sufficient.
Usage of dynamic tunneling, such as "6to4", can also be considered, On the other hand, usage of dynamic tunneling, such as "6to4", can
but the scalability problems arise when thinking about the great also be considered, but scalability problems arise when thinking
number of UEs in the 3GPP networks. If we consider the "6to4" about the great number of UEs in the 3GPP networks. The specific
tunneling mechanism and the 3GPP addressing model (a unique /64 limitation when applying "6to4" in 3GPP networks should also be
prefix allocated for each primary PDP context), a /48 "6to4" prefix taken into account, as commented in 3.2.1. Other issues to keep in
would only be enough for approximately 65000 UEs. Thus, a few mind with respect to the "6to4" mechanism are that reverse DNS is
public IPv4 addresses would be needed depending on the size of the not yet completely solved and there are some security
operator. Other issues to keep in mind with respect to the "6to4" considerations associated with the use of "6to4" relay routers (see
mechanism are that reverse DNS is not yet completely solved and [6to4SEC]). Moreover, in a later phase of the transition period,
there are some security considerations associated with the use of there will be a need for assigning new, native IPv6 addresses to
"6to4" relay routers (see [6to4SEC]). Moreover, in a later phase of all "6to4" nodes in order to enable native IPv6 connectivity.
the transition period, there will be a need for assigning new
(native IPv6) addresses to all "6to4" nodes in order to enable
native IPv6 connectivity.
The conclusion is that in most "external" 3GPP scenarios it is
preferred to use a few manually configured tunnels.
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
3GPP networks are expected to support both IPv4 and IPv6 for a long 3GPP networks are expected to support both IPv4 and IPv6 for a long
time, on the UE-GGSN link and between the GGSN and external time, on the UE-GGSN link and between the GGSN and external
networks. For this scenario it is useful to split the end-to-end networks. For this scenario it is useful to split the end-to-end
IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to- IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to-
v4NODE. An IPv6-capable GGSN is expected to support both IPv6 and v4NODE. An IPv6-capable GGSN is expected to support both IPv6 and
IPv4 UEs. Therefore an IPv4-only UE will be able to use an IPv4 IPv4 UEs. Therefore an IPv4-only UE will be able to use an IPv4
link (PDP context) to connect to the GGSN without the need to link (PDP context) to connect to the GGSN without the need to
skipping to change at page 11, line 36 skipping to change at page 11, line 24
(Gi) interface, typically separate from the GGSN. NA(P)T-PT can be (Gi) interface, typically separate from the GGSN. NA(P)T-PT can be
installed, for example, on the edge of the operator's network and installed, for example, on the edge of the operator's network and
the public Internet. NA(P)T-PT will intercept DNS requests and the public Internet. NA(P)T-PT will intercept DNS requests and
other applications that include IP addresses in their payloads, other applications that include IP addresses in their payloads,
translate the IP header (and payload for some applications if translate the IP header (and payload for some applications if
necessary) and forward packets through its IPv4 interface. necessary) and forward packets through its IPv4 interface.
NA(P)T-PT introduces limitations that are expected to be magnified NA(P)T-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 some of them are also relevant for IPv4 NAT). We below (notice that some of them are also relevant for IPv4 NAT). We
note here that [Unmaneval] section 3.2 analyzes the problem with note here that [v4v6trans] analyzes the issues when translating
address translation. However, the NAT-PT issues should be clearly between IPv4 and IPv6. However, the NAT-PT issues should be clearly
documented in an RFC in the v6ops Working Group and a decision documented in an RFC in the v6ops Working Group and a decision
should be made, whether revisiting the NAT-PT RFC is necessary / should be made, whether revisiting the NAT-PT RFC is necessary /
what kind of update is needed. what kind of update is needed.
1. NA(P)T-PT is a single point of failure for all ongoing 1. NA(P)T-PT is a single point of failure for all ongoing
connections. connections.
2. Additional forwarding delays due to further processing, when 2. Additional forwarding delays due to further processing, when
compared to normal IP forwarding. compared to normal IP forwarding.
skipping to change at page 14, line 51 skipping to change at page 14, line 38
traffic to the appropriate user traffic translator. This mapping traffic to the appropriate user traffic translator. This mapping
can be done by the SIP/SDP ALG for the SIP traffic. The user can be done by the SIP/SDP ALG for the SIP traffic. The user
traffic translator would do the similar mapping for the user traffic translator would do the similar mapping for the user
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.
[RFC3015].
+-------------------------------+ +------------+ +-------------------------------+ +------------+
| +------+ | | +--------+ | | +------+ | | +--------+ |
| |S-CSCF|---| |SIP ALG | |\ | |S-CSCF|---| |SIP ALG | |\
| | +------+ | | +--------+ | \ -------- | | +------+ | | +--------+ | \ --------
+-|+ | / | | | | | | +-|+ | / | | | | | |
| | | +------+ +------+ | | + | -| |- | | | +------+ +------+ | | + | -| |-
| |-|-|P-CSCF|--------|I-CSCF| | | | | | () | | |-|-|P-CSCF|--------|I-CSCF| | | | | | () |
| | +------+ +------+ | |+----------+| / ------ | | +------+ +------+ | |+----------+| / ------
| |-----------------------------------||Translator||/ | |-----------------------------------||Translator||/
skipping to change at page 15, line 30 skipping to change at page 15, line 30
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. We call the combined network element on an interface in between. We call the combined network element on
the edge of the IPv6-only IMS an "Interworking Unit" in this the edge of the IPv6-only IMS an "Interworking Unit" in this
document. One alternative is to use a suitable subset of NAT-PT document. One alternative is to use a suitable subset of NAT-PT
[RFC2766] in this network element to take care of the media (user [RFC2766] in this network element to take care of the media (user
data) IPv4/IPv6 translation. The problems related to NAT-PT are data) IPv4/IPv6 translation. The problems related to NAT-PT are
documented in subsection 3.4. documented in section 3.4.
A special case is when the IPv4-only destination node is registered
to a SIP proxy that happens to be dual stack. In such a case, the
connection from the edge of the IMS to the destination network
could be either IPv4 or IPv6, as the SIP INVITE message sent by the
IMS UE involves DNS address resolution only for the destination SIP
proxy (and not for the destination node). If IPv4 is used (from the
edge of the IMS to the destination SIP proxy), then no further
IPv4-IPv6 interworking is needed outside the IMS domain, as IPv4-
IPv6 translation will be performed on the edge of the IMS.
On the other hand, when IPv6 is used to connect both SIP proxies The authors notify that work is being done on analyzing 3GPP
(that is more likely), translation is not taken care of in the IMS IPv4/IPv6 translators related to IMS scenario 1, and a personal
because there is no way of detecting that the destination node is draft is expected shortly.
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
should be performed in the destination SIP domain (for example,
implemented in the dual stack SIP proxy). In addition, it could
also happen (especially in the initial stages of IPv6 deployment)
that end-to-end IPv6 connectivity between the IMS and the
destination domain is not yet available. Thus, this would be
equivalent to the scenario described in 4.3 (two IPv6 islands
connecting through an IPv4 network) and an IPv6 in IPv4 tunneling
mechanism should be used (in addition to IPv4-IPv6 translation in
the destination domain).
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 are based on IPv6.
IPv6. The only issue is to make connection between two IPv6-only The only issue is to make connection between two IPv6-only IMS
IMS islands over IPv4 network. So, in practice, this scenario is islands over IPv4 network. This scenario is closely related to GPRS
very closely related to GPRS scenario represented in section 3.2. scenario represented in section 3.2. and similar tunneling
solutions are applicable also in this scenario.
IPv4 / IPv6 interworking can be taken care of in the network; the
basic options are static and dynamic tunneling. The tunnel starting
point or endpoint should be located on the edge of the IMS domain.
Static "IPv6 in IPv4" tunnels configured between different IMS
domains would be a good solution. Note that this scenario is
comparable to 6bone [6BONE] network operation.
5. Security Considerations 5. Security Considerations
1. Problems have been identified in the case of the 1. NAT-PT DNS ALG problems are described in [NATPT-DNS] and
reachability of IPv4 and IPv6 nodes (use of DNS through [v4v6trans].
NAT-PT). NAT-PT DNS ALG problems are described in [NATPT-
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-02.txt 6. Changes from draft-ietf-v6ops-3gpp-analysis-03.txt
- Tunneling text in 2.2 shortened
- Text changes in 3.1
- Text changes in 3.2
- Text changes in 4.2
- Editorial changes in some sections - Editorial changes in some sections
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 30, 2003. All Rights Copyright (C) The Internet Society June 13, 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 17, line 50 skipping to change at page 17, line 30
[RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm [RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm
(SIIT), RFC 2765, February 2000. (SIIT), RFC 2765, February 2000.
[RFC2766] Tsirtsis, G., Srisuresh, P.: Network Address Translation [RFC2766] Tsirtsis, G., Srisuresh, P.: Network Address Translation
- Protocol Translation (NAT-PT), RFC 2766, February 2000. - Protocol Translation (NAT-PT), RFC 2766, February 2000.
[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,
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] Rosenberg, J., et al.: SIP: Session Initiation Protocol, [RFC3261] Rosenberg, J., et al.: SIP: Session Initiation Protocol,
June 2002. June 2002.
[RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6 [RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6
in 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", March 2003, draft-ietf-v6ops-3gpp-cases-03.txt, work in
in progress. 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 48 skipping to change at page 18, line 26
[RFC3314] Wasserman, M. (editor): "Recommendations for IPv6 in 3GPP [RFC3314] Wasserman, M. (editor): "Recommendations for IPv6 in 3GPP
Standards", September 2002. Standards", September 2002.
[6to4SEC] Savola, P.: "Security Considerations for 6to4", January [6to4SEC] Savola, P.: "Security Considerations for 6to4", January
2003, draft-savola-v6ops-6to4-security-02.txt, work in progress. 2003, draft-savola-v6ops-6to4-security-02.txt, work in progress.
[BGP] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., Le [BGP] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., Le
Faucheur, F.: "Connecting IPv6 Islands across IPv4 Clouds with Faucheur, F.: "Connecting IPv6 Islands across IPv4 Clouds with
BGP", October 2002, draft-ooms-v6ops-bgp-tunnel-00.txt, work in BGP", October 2002, draft-ooms-v6ops-bgp-tunnel-00.txt, work in
progress. progress, the draft has expired.
[DNStrans] Durand, A.: "IPv6 DNS transition issues", October 2002,
draft-ietf-dnsop-ipv6-dns-issues-00.txt, work in progress.
[DSTM] Bound, J., et al: "Dual Stack Transition Mechanism (DSTM)", [DNStrans] Durand, A. and Ihren, J.: "IPv6 DNS transition issues",
July 2002, draft-ietf-ngtrans-dstm-08.txt, work in progress, the February 2003, draft-ietf-dnsop-ipv6-dns-issues-02.txt, work in
draft has expired. progress.
[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)", March 2003, draft-ietf-ngtrans-
isatap-12.txt, work in progress. isatap-13.txt, work in progress.
[ISP-scen] Mickles, C. (Editor): "Transition Scenarios for ISP
Networks", March 2003, draft-mickles-v6ops-isp-cases-05.txt, work
in progress.
[ISP-analysis] Mickles, C. (Editor): "Transition Analysis for ISP
Networks", February 2003, draft-mickles-v6ops-isp-analysis-00.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 2003, draft-durand-v6ops-natpt-dns-alg-issues-00.txt, work January 2003, draft-durand-v6ops-natpt-dns-alg-issues-00.txt, work
in progress. 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", June 2003, draft-huitema-v6ops-teredo-00.txt, work in
progress. progress.
[Unmaneval] Huitema, C., Austein, R., Dilettante, B., Satapati, S., [v4v6trans] van der Pol, R., Satapati, S., Sivakumar, S.:
van der Pol, R.: "Evaluation of Transition Mechanisms for Unmanaged "Issues when translating between IPv4 and IPv6", January 2003,
Networks", November 2002, draft-huitema-ngtrans-unmaneval-01.txt, draft-vanderpol-v6ops-translation-issues-00.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>
skipping to change at page 20, line 23 skipping to change at page 19, line 38
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>
Hesham Soliman, Ericsson Radio Systems Hesham Soliman, Flarion
<hesham.soliman@era.ericsson.se> <h.soliman@flarion.com>
Margaret Wasserman, Wind River Margaret Wasserman, Wind River
<mrw@windriver.com> <mrw@windriver.com>
Juha Wiljakka, Nokia Juha Wiljakka, Nokia
<juha.wiljakka@nokia.com> <juha.wiljakka@nokia.com>
The authors would like to thank Gabor Bajko, Ajay Jain, Ivan The authors would like to thank Heikki Almay, Gabor Bajko, Ajay
Laloux, Pekka Savola, Pedro Serna, Fred Templin, Anand Thakur and Jain, Ivan Laloux, Pekka Savola, Pedro Serna, Fred Templin, Anand
Rod Van Meter for their valuable input. Thakur and Rod Van Meter for their valuable input.
10. Editor's Contact Information 10. Editor's Contact Information
Comments or questions regarding this document should be sent to the Comments or questions regarding this document should be sent to the
v6ops mailing list or directly to the document editor: v6ops mailing list or directly to the document editor:
Juha Wiljakka Juha Wiljakka
Nokia Nokia
Visiokatu 3 Phone: +358 7180 48372 Visiokatu 3 Phone: +358 7180 48372
FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com
 End of changes. 

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