draft-ietf-mip6-firewalls-01.txt   draft-ietf-mip6-firewalls-02.txt 
MIP6 F. Le MIP6 F. Le
Internet-Draft S. Faccin Internet-Draft S. Faccin
Expires: August 24, 2005 B. Patil Expires: November 6, 2005 B. Patil
Nokia Nokia
H. Tschofenig H. Tschofenig
Siemens Siemens
February 20, 2005 May 5, 2005
Mobile IPv6 and Firewalls Problem statement Mobile IPv6 and Firewalls: Problem statement
draft-ietf-mip6-firewalls-01.txt draft-ietf-mip6-firewalls-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in 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.
This Internet-Draft will expire on August 24, 2005. This Internet-Draft will expire on November 6, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
Firewalls are an integral aspect of a majority of IP networks today Network elements such as firewalls are an integral aspect of a
given the state of security in the Internet, threats and majority of IP networks today, given the state of security in the
vulnerabilities to data networks. Current IP networks are Internet, threats, and vulnerabilities to data networks. Current IP
predominantly based on IPv4 technology and hence firewalls have been networks are predominantly based on IPv4 technology and hence
designed for these networks. Deployment of IPv6 networks is firewalls have been designed for these networks. Deployment of IPv6
currently progressing, albeit at a slower pace. Firewalls for IPv6 networks is currently progressing, albeit at a slower pace.
networks are still maturing and in development. Firewalls for IPv6 networks are still maturing and in development.
Mobility support for IPv6 has now been standardized as specified in Mobility support for IPv6 has been standardized as specified in RFC
RFC 3775. Given the fact that Mobile IPv6 is a recent standard, most 3775. Given the fact that Mobile IPv6 is a recent standard, most
firewalls available for IPv6 networks do not support Mobile IPv6. firewalls available for IPv6 networks do not support Mobile IPv6.
Unless firewalls are aware of Mobile IPv6 protocol details, these Unless firewalls are aware of Mobile IPv6 protocol details, these
security devices will interfere in the smooth operation of the security devices will interfere in the smooth operation of the
protocol and can be a detriment to deployment. This document protocol and can be a detriment to deployment. This document
presents deployment of IPv6 networks when they support Mobile IPv6 captures the issues that may arise in the deployment of IPv6 networks
and firewalls. when they support Mobile IPv6 and firewalls.
The issues are not only applicable to firewalls protecting enterprise The issues are not only applicable to firewalls protecting enterprise
networks, but are also applicable in 3G mobile networks such as networks, but are also applicable in 3G mobile networks such as GPRS/
GPRS/UMTS and CDMA2000 networks, where packet filters are implemented UMTS and cdma2000 networks.
in the GGSN in GPRS/UMTS networks and the PDSN in CDMA2000 networks.
The goal of this Internet draft is to highlight the issues with The goal of this Internet draft is to highlight the issues with
firewalls and Mobile IPv6 and act as an enabler for further firewalls and Mobile IPv6 and act as an enabler for further
discussion. Issues identified here can be solved by developing discussion. Issues identified here can be solved by developing
appropriate solutions in the MIP6 WG. appropriate solutions in the MIP6 WG.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 3, line 20 skipping to change at page 3, line 20
4. Overview of firewalls . . . . . . . . . . . . . . . . . . . . 7 4. Overview of firewalls . . . . . . . . . . . . . . . . . . . . 7
5. Analysis of various scenarios involving MIP6 nodes and 5. Analysis of various scenarios involving MIP6 nodes and
firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 9 firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1 Scenario where the Mobile Node is in a network 5.1 Scenario where the Mobile Node is in a network
protected by firewall(s) . . . . . . . . . . . . . . . . . 9 protected by firewall(s) . . . . . . . . . . . . . . . . . 9
5.2 Scenario where the Correspondent Node is in a network 5.2 Scenario where the Correspondent Node is in a network
protected by firewall(s) . . . . . . . . . . . . . . . . . 11 protected by firewall(s) . . . . . . . . . . . . . . . . . 11
5.3 Scenario where the HA is in a network protected by 5.3 Scenario where the HA is in a network protected by
firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 14 firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 14
5.4 Scenario where MN moves to a network protected by 5.4 Scenario where MN moves to a network protected by
firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 14 firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 15
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1 Normative References . . . . . . . . . . . . . . . . . . . 19 9.1 Normative References . . . . . . . . . . . . . . . . . . . 20
9.2 Informative References . . . . . . . . . . . . . . . . . . 19 9.2 Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
A. Applicability to 3G Networks . . . . . . . . . . . . . . . . . 21 A. Applicability to 3G Networks . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . 23
1. Introduction 1. Introduction
Mobile IPv6 enables IP mobility for IPv6 nodes. It allows a mobile Mobile IPv6 enables IP mobility for IPv6 nodes. It allows a mobile
IPv6 node to be reachable via its home IPv6 address irrespective of IPv6 node to be reachable via its home IPv6 address irrespective of
any link that the mobile attaches to. This is possible as a result any link that the mobile attaches to. This is possible as a result
of the extensions to IPv6 defined in the Mobile IPv6 specification of the extensions to IPv6 defined in the Mobile IPv6 specification
[1]. [1].
Mobile IPv6 protocol design also incorporates a feature termed as Mobile IPv6 protocol design also incorporates a feature termed as
Route Optimization. This set of extensions is a fundamental part of Route Optimization. This set of extensions is a fundamental part of
the protocol that enables optimized routing of packets between a the protocol that enables optimized routing of packets between a
Mobile Node and its correspondent node and therefore the performance Mobile Node and its correspondent node and therefore the performance
of the communication. of the communication.
In most cases, current firewall technologies, however, do not support In most cases, current firewall technologies, however, do not support
Mobile IPv6 or are even unaware of Mobile IPv6 headers and Mobile IPv6 or are even aware of Mobile IPv6 headers and and
extensions. Since most networks in the current business environment extensions. Since most networks in the current business environment
deploy firewalls, this may prevent future large-scale deployment of deploy firewalls, this may prevent future large-scale deployment of
the Mobile IPv6 protocol. the Mobile IPv6 protocol.
This document presents in detail about some of the issues that This document presents in detail some of the issues that firewalls
firewalls present for Mobile IPv6 deployment, as well as the impact present for Mobile IPv6 deployment, as well as the impact of each
of each issue. issue.
2. Terminology 2. Terminology
Return Routability Test (RRT): The Return Routability Test is a Return Routability Test (RRT): The Return Routability Test is a
procedure defined in RFC 3775 [1]. It is performed prior to the procedure defined in RFC 3775 [1]. It is performed prior to the
Route Optimization (RO), where a mobile node (MN) instructs a Route Optimization (RO), where a mobile node (MN) instructs a
correspondent node (CN) to direct the mobile node's data traffic correspondent node (CN) to direct the mobile node's data traffic
to its claimed care-of address (CoA). The Return Routability to its claimed care-of address (CoA). The Return Routability
procedure provides some security assurance and prevents the misuse procedure provides some security assurance and prevents the misuse
of Mobile IPv6 signaling to maliciously redirect the traffic or to of Mobile IPv6 signaling to maliciously redirect the traffic or to
launch other attacks. launch other attacks.
3. Abbreviations 3. Abbreviations
This document uses the following abbreviations: This document uses the following abbreviations:
o CN Correspondent Node
o CoA Care of Address o CN: Correspondent Node
o CoTI Care of Test Init
o HA Home Agent o CoA: Care of Address
o HoA Home Address
o HoTI Home Test Init o CoTI: Care of Test Init
o MN Mobile Node
o RO Route Optimization o HA: Home Agent
o RRT Return Routability Test
o HoA: Home Address
o HoTI: Home Test Init
o MN: Mobile Node
o RO: Route Optimization
o RRT: Return Routability Test
4. Overview of firewalls 4. Overview of firewalls
The following provides a brief overview of firewalls. This section The following section provides a brief overview of firewalls. It is
is intended as a background information so that issues with the intended as background information so that issues with the Mobile
Mobile IPv6 protocol can then be presented in detail in the following IPv6 protocol can then be presented in detail in the following
sections. Readers familiar with firewall technology may skip this sections.
section.
There are different types of firewalls and state can be created in There are different types of firewalls and state can be created in
these firewalls through different methods. Independent of the these firewalls through different methods. Independent of the
adopted method, firewalls typically look at five parameters of the adopted method, firewalls typically look at five parameters of the
traffic arriving at the firewalls: traffic arriving at the firewalls:
o Source IP address o Source IP address
o Destination IP address o Destination IP address
o Protocol type o Protocol type
o Source port number o Source port number
o Destination port number o Destination port number
Based on these parameters, firewalls usually decide whether to allow Based on these parameters, firewalls usually decide whether to allow
the traffic or to drop the packets. Some firewalls may filter only the traffic or to drop the packets. Some firewalls may filter only
incoming traffic while others may also filter outgoing traffic. incoming traffic while others may also filter outgoing traffic.
Stateful packet filters are a specific type of firewalls. They are According to Section 3.29 of RFC 2647 [2] stateful packet filtering
commonly deployed to protect networks from different threats. refers to the process of forwarding or rejecting traffic based on the
Stateful packet filters typically block unsolicited incoming traffic contents of a state table maintained by a firewall. These types of
from the external networks. The following briefly describe how these firewalls are commonly deployed to protect networks from different
firewalls work since they can create additional issues with the threats, such as blocking unsolicited incoming traffic from the
external networks. The following briefly describes how these
firewalls work since they can create additional problems with the
Mobile IPv6 protocol as described in the subsequent sections. Mobile IPv6 protocol as described in the subsequent sections.
When a MN connects using TCP to another host in the Internet, it When a MN connects using TCP to another host in the Internet, it
sends a TCP SYN message to set up the connection. When that SYN sends a TCP SYN message to set up the connection. When that SYN
packet is routed through the firewall, the firewall creates an entry packet is routed through the firewall, the firewall creates an entry
in its state table containing the source IP address, the destination in its state table containing the source IP address, the destination
IP address, the Protocol type, the source port number and the IP address, the Protocol type, the source port number and the
destination port number indicated in that packet and then forwards destination port number indicated in that packet and then forwards
the packet to the destination. When the response comes back, the the packet to the destination. When the response comes back, the
filter looks up the packet's source IP address, destination IP filter looks up the packet's source IP address, destination IP
skipping to change at page 8, line 6 skipping to change at page 8, line 11
number in its state table: If they match an expected response, the number in its state table: If they match an expected response, the
firewall let the packet to pass. If no table entry exists, the firewall let the packet to pass. If no table entry exists, the
packet is dropped since it was not requested from inside the network. packet is dropped since it was not requested from inside the network.
The filter removes the state table entries when the TCP close session The filter removes the state table entries when the TCP close session
negotiation packets are routed through, or after some period of negotiation packets are routed through, or after some period of
delay, usually a few minutes. This ensures that dropped connections delay, usually a few minutes. This ensures that dropped connections
do not leave table holes open. do not leave table holes open.
For UDP, similar state is created but since UDP is connectionless and For UDP, similar state is created but since UDP is connectionless and
the protocol does not have indication of the beginning nor the end of the protocol does not have an indication of the beginning or the end
a session, the state is based only on timers. of a session, the state is based only on timers.
5. Analysis of various scenarios involving MIP6 nodes and firewalls 5. Analysis of various scenarios involving MIP6 nodes and firewalls
The following section describes various scenarios involving MIP6 The following section describes various scenarios involving MIP6
nodes and firewalls and also presents the issues related to each nodes and firewalls and also presents the issues related to each
scenario. scenario.
The Mobile IPv6 specifications define three main entities: the Mobile The Mobile IPv6 specifications define three main entities: the Mobile
Node (MN), the Correspondent Node (CN) and the Home Agent (HA). Each Node (MN), the Correspondent Node (CN) and the Home Agent (HA). Each
of these entities may be in a network protected by one or many of these entities may be in a network protected by one or many
skipping to change at page 11, line 18 skipping to change at page 11, line 25
Issue 5: When the MN A moves, it may move to a link that is served by Issue 5: When the MN A moves, it may move to a link that is served by
a different firewall. MN A might be sending a BU to its CN, a different firewall. MN A might be sending a BU to its CN,
however incoming packets may be dropped at the firewall, since the however incoming packets may be dropped at the firewall, since the
firewall on the new link that the MN attaches to does not have any firewall on the new link that the MN attaches to does not have any
state that is associated with the MN. state that is associated with the MN.
5.2 Scenario where the Correspondent Node is in a network protected by 5.2 Scenario where the Correspondent Node is in a network protected by
firewall(s) firewall(s)
Let's consider a MN in a network, communicating with a Correspondent Let's consider a MN in a network, communicating with a Correspondent
Node A in a network protected by firewall(s). There is no issue with Node A in a network protected by firewall(s). There are no issues
Reverse Tunneling. However firewalls may present different issues to with the presence of a firewall in the scenario where the MN is
sending packets to the CN via a reverse tunnel that is setup between
the MN and HA. However firewalls may present different issues to
Route Optimization. Route Optimization.
+----------------+ +----+ +----------------+ +----+
| | | HA | | | | HA |
| | +----+ | | +----+
| | Home Agent | | Home Agent
| +---+ +----+ of B | +---+ +----+ of B
| |CN | | FW | | |CN | | FW |
| +---+ +----+ | +---+ +----+
| | +---+ | | +---+
skipping to change at page 13, line 41 skipping to change at page 14, line 16
need to be created in the firewall(s). need to be created in the firewall(s).
Requiring the firewalls to update the connection state upon Requiring the firewalls to update the connection state upon
detecting Binding Update messages from a node outside the network detecting Binding Update messages from a node outside the network
protected by the firewall does not appear feasible nor desirable, protected by the firewall does not appear feasible nor desirable,
since currently the firewall does not have any means to verify the since currently the firewall does not have any means to verify the
validity of Binding Update messages and to therefore securely validity of Binding Update messages and to therefore securely
modify the state information. Changing the firewall states modify the state information. Changing the firewall states
without verifying the validity of the Binding Update messages without verifying the validity of the Binding Update messages
could lead to denial of service attacks. Malicious nodes may send could lead to denial of service attacks. Malicious nodes may send
faked Binding Update forcing the firewall to change its state fake binding updates, forcing the firewall to change its state
information, and therefore leading the firewall to drop packets information, and therefore leading the firewall to drop packets
from the connections that use the legitimate addresses. An from the connections that use the legitimate addresses. An
adversary might also use an address update to enable its own adversary might also use an address update to enable its own
traffic to enter the network. traffic to pass through the firewall and enter the network.
Issue 3: Let's assume that the Binding Update to the CN is Issue 3: Let's assume that the Binding Update to the CN is
successful. The CN may be protected by different firewalls and as successful. The CN may be protected by different firewalls and as
a result of the MN's change of IP address, incoming and outgoing a result of the MN's change of IP address, incoming and outgoing
traffic may pass through a different firewall. The new firewall traffic may pass through a different firewall. The new firewall
may not have any state associated with the CN and incoming may not have any state associated with the CN and incoming packets
(potentially outgoing traffic) may be dropped at the firewall. (and potentially outgoing traffic as well) may be dropped at the
firewall.
5.3 Scenario where the HA is in a network protected by firewall(s) 5.3 Scenario where the HA is in a network protected by firewall(s)
Let's consider a MN moving into a network protected by firewall(s). Let's consider a MN moving into a network protected by firewall(s).
The following issues may exist: The following issues may exist:
Issue 1: If the firewall(s) block ESP traffic, many of the MIPv6 Issue 1: If the firewall(s) block ESP traffic, many of the MIPv6
signaling (e.g. Binding Update, HoT) may be dropped at the signaling (e.g. Binding Update, HoT) may be dropped at the
firewall(s) preventing MN(s) from updating their binding cache and firewall(s) preventing MN(s) from updating their binding cache and
performing Route Optimization, since Binding Update, HoT and other performing Route Optimization, since Binding Update, HoT and other
skipping to change at page 16, line 8 skipping to change at page 17, line 8
be dropped by the firewall(s). be dropped by the firewall(s).
If packet filtering is applied to uplink traffic (i.e. traffic If packet filtering is applied to uplink traffic (i.e. traffic
sent by the MN), packets sent from the MN's CoA to the the CN may sent by the MN), packets sent from the MN's CoA to the the CN may
not match any entry in the firewall(s) either and may be dropped not match any entry in the firewall(s) either and may be dropped
as well. as well.
6. Conclusions 6. Conclusions
Current firewalls may not only prevent route optimization but may Current firewalls may not only prevent route optimization but may
also prevent communications to be established in some cases. This also prevent regular TCP and UDP sessions from being established in
document describes some of the issues between the Mobile IP protocol some cases. This document describes some of the issues between the
and current firewall technologies. Mobile IPv6 protocol and current firewall technologies.
This document captures the various issues involved in the deployment This document captures the various issues involved in the deployment
of Mobile IPv6 in networks that would invariably include firewalls. of Mobile IPv6 in networks that would invariably include firewalls.
A number of different scenarios are described which include A number of different scenarios are described which include
configurations where the mobile node, correspondent node and home configurations where the mobile node, correspondent node and home
agent exist across various boundaries delimited by the firewalls. agent exist across various boundaries delimited by the firewalls.
This enables a better understanding of the issues when deploying This enables a better understanding of the issues when deploying
Mobile IPv6 as well as providing an understanding for firewall design Mobile IPv6 as well as providing an understanding for firewall design
and policies to be installed therein. and policies to be installed therein.
7. Security Considerations 7. Security Considerations
This document describes several issues that exist between the Mobile This document describes several issues that exist between the Mobile
IPv6 protocol and firewalls. IPv6 protocol and firewalls.
Firewalls may prevent Mobile IP6 traffic and drop incoming/outgoing Firewalls may prevent Mobile IP6 signaling in addition to dropping
traffic. incoming/outgoing traffic.
If the firewall configuration is modified in order to support the If the firewall configuration is modified in order to support the
Mobile IPv6 protocol but not properly configured, many attacks may be Mobile IPv6 protocol but not properly configured, many attacks may be
possible as outlined above: malicious nodes may be able to launch possible as outlined above: malicious nodes may be able to launch
different types of denial of service attacks. different types of denial of service attacks.
8. Acknowledgments 8. Acknowledgments
We would like to thank James Kempf, Samita Chakrabarti and Giaretta We would like to thank James Kempf, Samita Chakrabarti and Giaretta
Gerardo for their valuable comments. Their suggestions have helped Gerardo for their valuable comments. Their suggestions have helped
to improve both the presentation and the content of the document. to improve both the presentation and the content of the document.
9. References 9. References
9.1 Normative References 9.1 Normative References
[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
9.2 Informative References 9.2 Informative References
[2] Chen, X., Watson, M. and M. Harris, "Problem Statement for MIPv6 [2] Newman, D., "Benchmarking Terminology for Firewall Performance",
Interactions with GPRS/UMTS Packet Filtering", RFC 2647, August 1999.
Internet-Draft draft-chen-mip6-gprs-02, October 2004.
[3] Chen, X., Watson, M., and M. Harris, "Problem Statement for
MIPv6 Interactions with GPRS/UMTS Packet Filtering",
draft-chen-mip6-gprs-03 (work in progress), February 2005.
Authors' Addresses Authors' Addresses
Franck Le Franck Le
Nokia Research Center Nokia Research Center
6000 Connection Drive 6000 Connection Drive
Irving, TX 75039 Irving, TX 75039
USA USA
Email: franck.le@nokia.com Email: franck.le@nokia.com
Stefano Faccin Stefano Faccin
Nokia Research Center Nokia Research Center
6000 Connection Drive 6000 Connection Drive
Irving, TX 75039 Irving, TX 75039
USA USA
Email: stefano.faccin@nokia.com Email: stefano.faccin@nokia.com
Basavaraj Patil Basavaraj Patil
Nokia Research Center Nokia
6000 Connection Drive 6000 Connection Drive
Irving, TX 75039 Irving, TX 75039
USA USA
Email: Basavaraj.Patil@nokia.com Email: Basavaraj.Patil@nokia.com
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Appendix A. Applicability to 3G Networks Appendix A. Applicability to 3G Networks
In 3G networks, different packet filtering functionalities may be In 3G networks, different packet filtering functionalities may be
implemented to prevent malicious nodes from flooding or launching implemented to prevent malicious nodes from flooding or launching
other attacks against the 3G subscribers. The packet filtering other attacks against the 3G subscribers. The packet filtering
functionality of 3G networks are further described in [2]. Packet functionality of 3G networks are further described in [3]. Packet
filters are set up and applied to both uplink and downlink traffic: filters are set up and applied to both uplink and downlink traffic:
outgoing and incoming data not matching the packet filters is dropped outgoing and incoming data not matching the packet filters is dropped
. The issues described in this document also apply to 3G networks. . The issues described in this document also apply to 3G networks.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
 End of changes. 

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