Network Working Group F. Le
Request for Comments: 4487 CMU
Category: Informational S. Faccin
B. Patil
Nokia
H. Tschofenig
Siemens
May 2006
Network Working Group F. Le
Request for Comments: 4487 CMU
Category: Informational S. Faccin
B. Patil
Nokia
H. Tschofenig
Siemens
May 2006
Mobile IPv6 and Firewalls: Problem Statement
移动IPv6和防火墙：问题陈述
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document captures the issues that may arise in the deployment of IPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as General Packet Radio Service / Universal Mobile Telecommunications System (GPRS/UMTS) and CDMA2000 networks.
本文档介绍了支持移动IPv6和防火墙的IPv6网络在部署过程中可能出现的问题。这些问题不仅适用于保护企业网络的防火墙，也适用于3G移动网络，如通用分组无线业务/通用移动通信系统（GPRS/UMTS）和CDMA2000网络。
The goal of this document is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions.
本文档的目标是突出防火墙和移动IPv6的问题，并作为进一步讨论的促成因素。这里确定的问题可以通过制定适当的解决方案来解决。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Abbreviations ...................................................4
4. Overview of Firewalls ...........................................4
5. Analysis of Various Scenarios Involving MIP6 Nodes and
Firewalls .......................................................6
5.1. Scenario Where the Mobile Node Is in a Network
Protected by Firewall(s) ...................................7
5.2. Scenario Where the Correspondent Node Is in a
Network Protected by Firewall(s) ...........................9
5.3. Scenario Where the HA Is in a Network Protected by
Firewall(s) ...............................................12
5.4. Scenario Where the MN Moves to a Network Protected by
Firewall(s) ...............................................12
6. Conclusions ....................................................13
7. Security Considerations ........................................14
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................14
Appendix A. Applicability to 3G Networks ..........................15
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Abbreviations ...................................................4
4. Overview of Firewalls ...........................................4
5. Analysis of Various Scenarios Involving MIP6 Nodes and
Firewalls .......................................................6
5.1. Scenario Where the Mobile Node Is in a Network
Protected by Firewall(s) ...................................7
5.2. Scenario Where the Correspondent Node Is in a
Network Protected by Firewall(s) ...........................9
5.3. Scenario Where the HA Is in a Network Protected by
Firewall(s) ...............................................12
5.4. Scenario Where the MN Moves to a Network Protected by
Firewall(s) ...............................................12
6. Conclusions ....................................................13
7. Security Considerations ........................................14
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................14
Appendix A. Applicability to 3G Networks ..........................15
Network elements such as firewalls are an integral aspect of a majority of IP networks today, given the state of security in the Internet, threats, and vulnerabilities to data networks. Current IP networks are predominantly based on IPv4 technology, and hence firewalls have been designed for these networks. Deployment of IPv6 networks is currently progressing, albeit at a slower pace. Firewalls for IPv6 networks are still maturing and in development.
考虑到互联网的安全状况、威胁和数据网络的脆弱性，防火墙等网络元素是当今大多数IP网络的一个组成部分。当前的IP网络主要基于IPv4技术，因此防火墙已经为这些网络设计。IPv6网络的部署目前正在进行中，尽管速度较慢。IPv6网络的防火墙仍在成熟和发展中。
Mobility support for IPv6 has been standardized as specified in RFC 3775. Given the fact that Mobile IPv6 is a recent standard, most firewalls available for IPv6 networks do not support Mobile IPv6.
IPv6的移动性支持已经按照RFC 3775中的规定进行了标准化。鉴于移动IPv6是最新的标准，IPv6网络的大多数防火墙都不支持移动IPv6。
Unless firewalls are aware of Mobile IPv6 protocol details, these security devices will interfere with the smooth operation of the protocol and can be a detriment to deployment.
除非防火墙了解移动IPv6协议的详细信息，否则这些安全设备将干扰协议的顺利运行，并可能对部署造成不利影响。
Mobile IPv6 enables IP mobility for IPv6 nodes. It allows a mobile 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 of the extensions to IPv6 defined in the Mobile IPv6 specification [1].
移动IPv6支持IPv6节点的IP移动性。它允许移动IPv6节点通过其主IPv6地址进行访问，而不考虑移动设备连接到的任何链路。这是移动IPv6规范[1]中定义的IPv6扩展的结果。
Mobile IPv6 protocol design also incorporates a feature termed Route Optimization. This set of extensions is a fundamental part of the protocol that enables optimized routing of packets between a mobile node and its correspondent node and therefore optimized performance of the communication.
移动IPv6协议设计还包含一个称为路由优化的功能。这组扩展是协议的一个基本部分，它能够优化移动节点和其对应节点之间的数据包路由，从而优化通信性能。
In most cases, current firewall technologies, however, do not support Mobile IPv6 or are not even aware of Mobile IPv6 headers and extensions. Since most networks in the current business environment deploy firewalls, this may prevent future large-scale deployment of the Mobile IPv6 protocol.
然而，在大多数情况下，当前的防火墙技术不支持移动IPv6，甚至不知道移动IPv6头和扩展。由于当前业务环境中的大多数网络都部署了防火墙，这可能会阻止将来大规模部署移动IPv6协议。
This document presents in detail some of the issues that firewalls present for Mobile IPv6 deployment, as well as the impact of each issue.
本文档详细介绍了防火墙在移动IPv6部署中存在的一些问题，以及每个问题的影响。
Return Routability Test (RRT): The Return Routability Test is a procedure defined in RFC 3775 [1]. It is performed prior to the Route Optimization (RO), where a mobile node (MN) instructs a correspondent node (CN) to direct the mobile node's data traffic to its claimed care-of address (CoA). The Return Routability procedure provides some security assurance and prevents the misuse of Mobile IPv6 signaling to maliciously redirect the traffic or to launch other attacks.
返回路由性测试（RRT）：返回路由性测试是RFC 3775[1]中定义的程序。它是在路由优化（RO）之前执行的，其中移动节点（MN）指示对应节点（CN）将移动节点的数据业务定向到其声称的转交地址（CoA）。返回可路由性过程提供了一些安全保证，并防止滥用移动IPv6信令恶意重定向流量或发起其他攻击。
This document uses the following abbreviations:
本文件使用以下缩写：
o CN: Correspondent Node
o CN：对应节点
o CoA: Care of Address
o 转交地址：CoA
o CoTI: Care of Test Init
o CoTI：测试初始的照管
o HA: Home Agent
o 房委会：房屋署
o HoA: Home Address
o 家庭住址
o HoTI: Home Test Init
o HoTI：家庭测试初始化
o HoT: Home Test
o 热：家庭测试
o MN: Mobile Node
o 移动节点
o RO: Route Optimization
o RO：路线优化
o RRT: Return Routability Test
o 返回路由性测试
The following section provides a brief overview of firewalls. It is intended as background information so that issues with the Mobile IPv6 protocol can then be presented in detail in the following sections.
以下部分简要概述防火墙。本文旨在作为背景信息，以便在以下章节中详细介绍移动IPv6协议的问题。
There are different types of firewalls, and state can be created in these firewalls through different methods. Independent of the adopted method, firewalls typically look at five parameters of the traffic arriving at the firewalls:
有不同类型的防火墙，可以通过不同的方法在这些防火墙中创建状态。独立于所采用的方法，防火墙通常会查看到达防火墙的流量的五个参数：
o Source IP address
o 源IP地址
o Destination IP address
o 目标IP地址
o Protocol type
o 协议类型
o Source port number
o 源端口号
o Destination port number
o 目的地端口号
Based on these parameters, firewalls usually decide whether to allow the traffic or to drop the packets. Some firewalls may filter only incoming traffic, while others may also filter outgoing traffic.
基于这些参数，防火墙通常决定是允许流量还是丢弃数据包。一些防火墙可能只过滤传入流量，而其他防火墙也可能过滤传出流量。
According to Section 3.29 of RFC 2647 [2], stateful packet filtering refers to the process of forwarding or rejecting traffic based on the contents of a state table maintained by a firewall. These types of firewalls are commonly deployed to protect networks from different 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.
根据RFC 2647[2]第3.29节，有状态数据包过滤是指根据防火墙维护的状态表的内容转发或拒绝流量的过程。这些类型的防火墙通常用于保护网络免受不同的威胁，例如阻止来自外部网络的未经请求的传入流量。以下简要介绍了这些防火墙的工作原理，因为它们会对移动IPv6协议产生其他问题，如后续章节所述。
In TCP, an MN sends a TCP SYN message to connect to another host in the Internet.
在TCP中，MN发送TCP SYN消息以连接到Internet上的另一台主机。
Upon receiving that SYN packet, the firewall records the source IP address, the destination IP address, the Protocol type, the source port number, and the destination port number indicated in that packet before transmitting it to the destination.
在接收到该SYN数据包后，防火墙会记录该数据包中指示的源IP地址、目标IP地址、协议类型、源端口号和目标端口号，然后再将其发送到目标。
When an incoming message from the external networks reaches the firewall, it searches the packet's source IP address, destination IP address, Protocol type, source port number, and destination port number in its entries to see if the packet matches the characteristics of a request sent previously. If so, the firewall allows the packet to enter the network. If the packet was not solicited from an internal node, the packet is blocked.
当来自外部网络的传入消息到达防火墙时，它会在其条目中搜索数据包的源IP地址、目标IP地址、协议类型、源端口号和目标端口号，以查看数据包是否与先前发送的请求的特征相匹配。如果是这样，防火墙允许数据包进入网络。如果该数据包不是从内部节点请求的，则该数据包被阻止。
When the TCP close session packets are exchanged or after some configurable period of inactivity, the associated entry in the firewall is deleted. This mechanism prevents entries from remaining when TCP are abruptly terminated.
当TCP关闭会话数据包被交换时或在某个可配置的非活动期后，防火墙中的相关条目将被删除。此机制可防止TCP突然终止时保留条目。
A similar entry is created when using UDP. The difference with this transport protocol is that UDP is connectionless and does not have packets signaling the initiation or termination of a session. Consequently, the duration of the entries relies solely on timers.
使用UDP时会创建类似的条目。这种传输协议的不同之处在于UDP是无连接的，没有发送会话启动或终止信号的数据包。因此，条目的持续时间完全取决于计时器。
The following section describes various scenarios involving MIP6 nodes and firewalls and also presents the issues related to each scenario.
以下部分描述了涉及MIP6节点和防火墙的各种场景，并介绍了与每个场景相关的问题。
The Mobile IPv6 specifications define three main entities: the mobile 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 firewalls:
移动IPv6规范定义了三个主要实体：移动节点（MN）、对应节点（CN）和归属代理（HA）。这些实体中的每一个都可能位于由一个或多个防火墙保护的网络中：
o Section 5.1 analyzes the issues when the MN is in a network protected by firewall(s)
o 第5.1节分析了MN位于受防火墙保护的网络中时的问题
o Section 5.2 analyzes the issues when the CN is in a network protected by firewall(s)
o 第5.2节分析了CN位于受防火墙保护的网络中时的问题
o Section 5.3 analyzes the issues when the HA is in a network protected by firewall(s)
o 第5.3节分析了HA位于受防火墙保护的网络中时的问题
The MN may also be moving from an external network, to a network protected by firewall(s). The issues of this case are described in Section 5.4.
MN也可能从外部网络移动到受防火墙保护的网络。第5.4节描述了本案例的问题。
Some of the described issues (e.g., Sections 5.1 and 5.2) may require modifications to the protocols or to the firewalls, and others (e.g., Section 5.3) may require only that appropriate rules and configuration be in place.
所述的一些问题（如第5.1节和第5.2节）可能需要修改协议或防火墙，而其他问题（如第5.3节）可能只需要适当的规则和配置到位。
5.1. Scenario Where the Mobile Node Is in a Network Protected by Firewall(s)
5.1. 移动节点位于受防火墙保护的网络中的场景
Let's consider MN A, in a network protected by firewall(s).
让我们考虑MN A，在由防火墙保护的网络中。
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of A +---+
| | A | | FW | | B |
| +---+ +----+ +---+
|Internal | External
| MN | Node
| |
+----------------+
Network protected
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of A +---+
| | A | | FW | | B |
| +---+ +----+ +---+
|Internal | External
| MN | Node
| |
+----------------+
Network protected
Figure 1: Issues between MIP6 and firewalls when MN is in a network protected by firewalls
图1：当MN位于受防火墙保护的网络中时，MIP6和防火墙之间的问题
A number of issues need to be considered:
需要考虑若干问题：
Issue 1: When MN A connects to the network, it should acquire a local IP address (CoA) and send a Binding Update (BU) to its Home Agent to update the HA with its current point of attachment. The Binding Updates and Acknowledgements should be protected by IPsec ESP according to the MIPv6 specifications [1]. However, as a default rule, many firewalls drop IPsec ESP packets because they cannot determine whether inbound ESP packets are legitimate. It is difficult or impossible to create useful state by observing the outbound ESP packets. This may cause the Binding Updates and Acknowledgements between the mobile nodes and their home agent to be dropped.
问题1：当MN A连接到网络时，它应该获取本地IP地址（CoA），并向其归属代理发送绑定更新（BU），以使用其当前连接点更新HA。根据MIPv6规范[1]，绑定更新和确认应由IPsec ESP保护。但是，作为默认规则，许多防火墙丢弃IPsec ESP数据包，因为它们无法确定入站ESP数据包是否合法。通过观察出站ESP数据包很难或不可能创建有用的状态。这可能导致移动节点与其归属代理之间的绑定更新和确认被丢弃。
Issue 2: Let's now consider a node in the external network, B, trying to establish a communication with MN A.
问题2：现在考虑外部网络中的一个节点，B，试图与MN A建立通信。
* B sends a packet to the mobile node's home address.
* 将移动分组B发送到归属节点的地址。
* The packet is intercepted by the MN's home agent, which tunnels it to the MN's CoA [1].
* 该数据包被MN的归属代理截获，该代理通过隧道将其传输到MN的CoA[1]。
* When arriving at the firewall(s) protecting MN A, the packet may be dropped since the incoming packet may not match any existing state. As described in Section 4, stateful inspection packet filters (for example) typically drop unsolicited incoming traffic.
* 当到达保护mna的防火墙时，分组可能被丢弃，因为传入分组可能不匹配任何现有状态。如第4节所述，有状态检查包过滤器（例如）通常丢弃未经请求的传入流量。
* B will thus not be able to contact MN A and establish a communication.
* 因此，B将无法联系MN A并建立通信。
Even though the HA is updated with the location of an MN, firewalls may prevent correspondent nodes from establishing communications when the MN is in a network protected by firewall(s).
即使使用MN的位置更新HA，当MN位于受防火墙保护的网络中时，防火墙可能会阻止对应节点建立通信。
Issue 3: Let's assume a communication between MN A and an external node B. MN A may want to use Route Optimization (RO) so that packets can be directly exchanged between the MN and the CN without passing through the HA. However, the firewalls protecting the MN might present issues with the Return Routability procedure that needs to be performed prior to using RO.
问题3：假设MN a和外部节点B之间存在通信。MN a可能希望使用路由优化（RO），以便数据包可以在MN和CN之间直接交换，而无需通过HA。然而，保护MN的防火墙可能会在使用RO之前需要执行的返回路由性过程中出现问题。
According to the MIPv6 specifications, the Home Test message of the RRT must be protected by IPsec in tunnel mode. However, firewalls might drop any packet protected by ESP, since the firewalls cannot analyze the packets encrypted by ESP (e.g., port numbers). The firewalls may thus drop the Home Test messages and prevent the completion of the RRT procedure.
根据MIPv6规范，RRT的Home Test消息必须在隧道模式下受IPsec保护。但是，防火墙可能会丢弃受ESP保护的任何数据包，因为防火墙无法分析ESP加密的数据包（例如端口号）。因此，防火墙可能会丢弃Home Test消息并阻止RRT过程的完成。
Issue 4: Let's assume that MN A successfully sends a Binding Update to its home agent (resp. correspondent nodes) -- which solves issue 1 (resp. issue 3) -- and that the subsequent traffic is sent from the HA (resp. CN) to the MN's CoA. However there may not be any corresponding state in the firewalls. The firewalls protecting A may thus drop the incoming packets.
问题4：假设MNA成功地将绑定更新发送到其归属代理（对应节点）——这解决了问题1（对应问题3）——并且后续流量从HA（对应CN）发送到MN的CoA。但是，防火墙中可能没有任何相应的状态。因此，保护服务器的防火墙可能会丢弃传入的数据包。
The appropriate states for the traffic to the MN's CoA need to be created in the firewall(s).
需要在防火墙中为MN的CoA的流量创建适当的状态。
Issue 5: When 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; 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 state that is associated with the MN.
问题5：当MNA移动时，它可能会移动到由不同防火墙提供服务的链接。MNA可能正在向其CN发送BU；然而，由于MN连接到的新链路上的防火墙没有任何与MN相关联的状态，因此传入的分组可能在防火墙处被丢弃。
The issues described above result from the fact that the MN is behind the firewall. Consequently, the MN's communication capability with other nodes is affected by the firewall rules.
事实上，MN背后的防火墙问题正是上述结果。因此，MN与其他节点的通信能力受到防火墙规则的影响。
5.2. Scenario Where the Correspondent Node Is in a Network Protected by Firewall(s)
5.2. 对应节点位于受防火墙保护的网络中的场景
Let's consider an MN in a network, communicating with a Correspondent Node C in a network protected by firewall(s). There are no issues with the presence of a firewall in the scenario where the MN is sending packets to the CN via a reverse tunnel that is set up between the MN and HA. However, firewalls may present different issues to Route Optimization.
让我们考虑一个网络中的MN，与防火墙保护的网络中的对应节点C通信。在MN通过在MN和HA之间建立的反向隧道向CN发送数据包的场景中，防火墙的存在不存在任何问题。然而，防火墙可能会给路由优化带来不同的问题。
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of B
| |CN | | FW |
| | C | +----+
| +---+ | +---+
| | | B |
| | +---+
+----------------+ External Mobile
Network protected Node
by a firewall
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of B
| |CN | | FW |
| | C | +----+
| +---+ | +---+
| | | B |
| | +---+
+----------------+ External Mobile
Network protected Node
by a firewall
Figure 2: Issues between MIP6 and firewalls when a CN is in a network protected by firewalls
图2：当CN位于受防火墙保护的网络中时，MIP6和防火墙之间的问题
The following issues need to be considered:
需要考虑以下问题：
Issue 1: The MN (MN B) should use its Home Address (HoA B) when establishing the communication with the CN (CN C), if MN B wants to take advantage of the mobility support provided by the Mobile IPv6 protocol for its communication with CN C. The state created by the firewall protecting CN C is therefore created based on the IP address of C (IP C) and the home address of Node B (IP HoA B). The states may be created via different means, and the protocol type as well as the port numbers depend on the connection setup.
问题1：如果MN B希望利用移动IPv6协议为其与CN C的通信提供的移动性支持，则MN（MN B）在与CN（CN C）建立通信时应使用其家庭地址（HoA B）。因此，保护CN C的防火墙创建的状态是基于C（IP C）的IP地址创建的以及节点B的家庭地址（IP HoA B）。可以通过不同的方式创建状态，协议类型以及端口号取决于连接设置。
Uplink packet filters (1)
上行数据包过滤器（1）
Source IP address: IP C
来源IP地址：IP C
Destination IP address: HoA B
目的IP地址：HoA B
Protocol Type: TCP/UDP
协议类型：TCP/UDP
Source Port Number: #1
源端口号：#1
Destination Port Number: #2
目标端口号：#2
Downlink packet filters (2)
下行包过滤器（2）
Source IP address: HoA B
来源IP地址：HoA B
Destination IP address: IP C
目的IP地址：IP C
Protocol Type: TCP/UDP
协议类型：TCP/UDP
Source Port Number: #2
源端口号：#2
Destination Port Number: #1
目标端口号：#1
Nodes C and B might be topologically close to each other, while B's home agent may be far away, resulting in a trombone effect that can create delay and degrade the performance. MN B may decide to initiate the route optimization procedure with Node C. Route optimization requires MN B to send a Binding Update to Node C in order to create an entry in its binding cache that maps the MN's home address to its current care-of-address. However, prior to sending the binding update, the mobile node must first execute a Return Routability Test:
节点C和B可能在拓扑上彼此接近，而B的归属代理可能距离较远，从而导致长号效应，该效应会造成延迟并降低性能。MN B可以决定启动节点C的路由优化过程。路由优化要求MN B向节点C发送绑定更新，以便在其绑定缓存中创建一个条目，该条目将MN的主地址映射到其当前转交地址。但是，在发送绑定更新之前，移动节点必须首先执行返回路由性测试：
* Mobile Node B has to send a Home Test Init (HoTI) message via its home agent and
* 移动节点B必须通过其归属代理发送归属测试初始（HoTI）消息，并且
* a Care of Test Init (COTI) message directly to its Correspondent Node C.
* 直接发送到对应节点C的Care of Test Init（COTI）消息。
The Care of Test Init message is sent using the CoA of B as the source address. Such a packet does not match any entry in the protecting firewall (2). The CoTi message will thus be dropped by the firewall.
Care of Test Init消息使用B的CoA作为源地址发送。这样的数据包与保护防火墙（2）中的任何条目都不匹配。因此，CoTi消息将被防火墙丢弃。
The HoTI is a Mobility Header packet, and as the protocol type differs from the established state in the firewall (see (2)), the HoTI packet will also be dropped.
HoTI是移动报头分组，并且由于协议类型不同于防火墙中的已建立状态（参见（2）），因此也将丢弃HoTI分组。
As a consequence, the RRT cannot be completed, and route optimization cannot be applied. Every packet has to go through Node B's home agent and tunneled between B's home agent and B.
因此，无法完成RRT，也无法应用路由优化。每个数据包都必须经过节点B的主代理，并在B的主代理和B之间进行隧道传输。
+----------------+
| +----+ HoTI (HoA) +----+
| | FW |X<---------------|HA B|
| +----X +----+
| +------+ | ^ CoTI & HoTI ^
| | CN C | | | dropped by FW |
| +------+ | | | HoTI
| | | |
| | | CoTI (CoA)+------+
| | +------------------| MN B |
+----------------+ +------+
Network protected External Mobile
by a firewall Node
+----------------+
| +----+ HoTI (HoA) +----+
| | FW |X<---------------|HA B|
| +----X +----+
| +------+ | ^ CoTI & HoTI ^
| | CN C | | | dropped by FW |
| +------+ | | | HoTI
| | | |
| | | CoTI (CoA)+------+
| | +------------------| MN B |
+----------------+ +------+
Network protected External Mobile
by a firewall Node
Figure 3: Issues with Return Routability Test
图3：返回可路由性测试的问题
Issue 2: Let's assume that the Binding Update to the CN is successful; the firewall(s) might still drop packets that are:
问题2：假设对CN的绑定更新成功；防火墙仍可能丢弃以下数据包：
1. coming from the CoA, since these incoming packets are sent from the CoA and do not match the Downlink Packet filter (2).
1. 来自CoA，因为这些传入分组是从CoA发送的，并且与下行链路分组过滤器（2）不匹配。
2. sent from the CN to the CoA if uplink packet filters are implemented. The uplink packets are sent to the MN's CoA and do not match the uplink packet filter (1).
2. 如果实施了上行链路分组过滤器，则从CN发送到CoA。上行链路分组被发送到MN的CoA，并且与上行链路分组滤波器（1）不匹配。
The packet filters for the traffic sent to (resp. from) the CoA need to be created in the firewall(s).
需要在防火墙中创建发送到（或从）CoA的流量的数据包过滤器。
Requiring the firewalls to update the connection state upon detecting Binding Update messages from a node outside the network protected by the firewall does not appear feasible or desirable, since currently the firewall does not have any means to verify the validity of Binding Update messages and therefore to modify the state information securely. Changing the firewall states without verifying the validity of the Binding Update messages could lead to denial of service attacks. Malicious nodes may send fake binding updates, forcing the firewall to change its state information, and therefore leading the firewall to drop packets from the connections that use the legitimate addresses. An adversary might also use an address update to enable its own traffic to pass through the firewall and enter the network.
要求防火墙在检测到来自受防火墙保护的网络外部节点的绑定更新消息时更新连接状态似乎不可行或不可取，由于目前防火墙没有任何方法来验证绑定更新消息的有效性，因此无法安全地修改状态信息。在不验证绑定更新消息的有效性的情况下更改防火墙状态可能会导致拒绝服务攻击。恶意节点可能发送假绑定更新，迫使防火墙更改其状态信息，从而导致防火墙从使用合法地址的连接中丢弃数据包。对手还可能使用地址更新来使其自己的流量通过防火墙并进入网络。
Issue 3: Let's assume that the Binding Update to the CN is successful. The CN may be protected by different firewalls, and as a result of the MN's change of IP address, incoming and outgoing traffic may pass through a different firewall. The new
问题3：假设对CN的绑定更新成功。CN可能受到不同防火墙的保护，并且由于MN的IP地址更改，传入和传出流量可能会通过不同的防火墙。新的
firewall may not have any state associated with the CN, and incoming packets (and potentially outgoing traffic as well) may be dropped at the firewall.
防火墙可能没有任何与CN关联的状态，并且传入的数据包（以及潜在的传出流量）可能会在防火墙上丢弃。
Firewall technology allows clusters of firewalls to share state [3]. This, for example, allows the support of routing asymmetry. However, if the previous and the new firewalls, through which the packets are routed after the Binding Update has been sent, do not share state, this may result in packets being dropped at the new firewall. As the new firewall does not have any state associated with the CN, incoming packets (and potentially outgoing traffic as well) may be dropped at the new firewall.
防火墙技术允许防火墙集群共享状态[3]。例如，这允许支持路由不对称。但是，如果在发送绑定更新后通过其路由数据包的上一个防火墙和新防火墙不共享状态，这可能会导致数据包在新防火墙上被丢弃。由于新防火墙没有任何与CN相关联的状态，因此传入的分组（以及潜在的传出流量）可以在新防火墙处丢弃。
In the scenarios where the home agent is in a network protected by firewall(s), the following issues may exist:
在归属代理位于受防火墙保护的网络中的场景中，可能存在以下问题：
Issue 1: If the firewall(s) protecting the home agent block ESP traffic, much of the MIPv6 signaling (e.g., Binding Update, HoT) may be dropped at the firewall(s), preventing MN(s) from updating their binding cache and performing Route Optimization, since Binding Update, HoT, and other MIPv6 signaling must be protected by IPsec ESP.
问题1：如果保护归属代理的防火墙阻止ESP通信，则大部分MIPv6信令（例如绑定更新、热）可能会在防火墙上丢弃，从而阻止MN更新其绑定缓存并执行路由优化，因为绑定更新、热和其他MIPv6信令必须由IPsec ESP保护。
Issue 2: If the firewall(s) protecting the home agent block unsolicited incoming traffic (e.g., as stateful inspection packet filters do), the firewall(s) may drop connection setup requests from CNs, and packets from MNs.
问题2：如果保护归属代理的防火墙阻止未经请求的传入流量（如有状态检查数据包过滤器），则防火墙可能会丢弃来自CNs的连接设置请求和来自MNs的数据包。
Issue 3: If the home agent is in a network protected by several firewalls, an MN/CN's change of IP address may result in the passage of traffic to and from the home agent through a different firewall that may not have the states corresponding to the flows. As a consequence, packets may be dropped at the firewall.
问题3：如果归属代理位于受多个防火墙保护的网络中，则MN/CN的IP地址更改可能会导致流量通过不同的防火墙进出归属代理，该防火墙可能不具有与流量对应的状态。因此，数据包可能会在防火墙上丢弃。
Let's consider an HA in a network protected by firewall(s). The following issues need to be investigated:
让我们考虑在防火墙保护下的网络中的HA。需要调查以下问题：
Issue 1: Similarly to issue 1 described in Section 5.1, the MN will send a Binding Update to its home agent after acquiring a local IP address (CoA). The Binding Updates and Acknowledgements should be protected by IPsec ESP according to the MIPv6 specifications [1]. However, as a default rule, many firewalls drop ESP packets. This may cause the Binding Updates and Acknowledgements between the mobile nodes and their home agent to be dropped.
问题1：与第5.1节中描述的问题1类似，MN将在获取本地IP地址（CoA）后向其归属代理发送绑定更新。根据MIPv6规范[1]，绑定更新和确认应由IPsec ESP保护。但是，默认情况下，许多防火墙会丢弃ESP数据包。这可能导致移动节点与其归属代理之间的绑定更新和确认被丢弃。
Issue 2: The MN may be in a communication with a CN, or a CN may be attempting to establish a connection with the MN. In both cases, packets sent from the CN will be forwarded by the MN's HA to the MN's CoA. However, when the packets arrive at the firewall(s), the incoming traffic may not match any existing state, and the firewall(s) may therefore drop it.
问题2：MN可能正在与CN进行通信，或者CN可能正试图与MN建立连接。在这两种情况下，从CN发送的数据包将由MN的HA转发给MN的CoA。但是，当数据包到达防火墙时，传入流量可能与任何现有状态都不匹配，因此防火墙可能会丢弃它。
Issue 3: If the MN is in a communication with a CN, the MN may attempt to execute an RRT for packets to be route optimized. Similarly to issue 3, Section 5.1, the Home Test message that should be protected by ESP may be dropped by firewall(s) protecting the MN. Firewall(s) may as a default rule drop any ESP traffic. As a consequence, the RRT cannot be completed.
问题3：如果MN正在与CN通信，则MN可能会尝试对要进行路由优化的分组执行RRT。与问题3第5.1节类似，应受到ESP保护的家庭测试消息可能会被保护MN的防火墙丢弃。默认情况下，防火墙可以删除任何ESP流量。因此，RRT无法完成。
Issue 4: If the MN is in a communication with a CN, and assuming that the MN successfully sent a Binding Update to its CN to use Route Optimization, packets will then be sent from the CN to the MN's CoA and from the MN's CoA to the CN.
问题4：如果MN正在与CN进行通信，并且假设MN成功地向其CN发送绑定更新以使用路由优化，那么数据包将从CN发送到MN的CoA，并从MN的CoA发送到CN。
Packets sent from the CN to the MN's CoA may, however, not match any existing entry in the firewall(s) protecting the MN, and therefore be dropped by the firewall(s).
然而，从CN发送到MN的CoA的分组可能与保护MN的防火墙中的任何现有条目不匹配，因此被防火墙丢弃。
If packet filtering is applied to uplink traffic (i.e., traffic sent by the MN), packets sent from the MN's CoA to the CN may not match any entry in the firewall(s) either and may be dropped as well.
如果分组过滤应用于上行链路业务（即，由MN发送的业务），则从MN的CoA发送到CN的分组也可能与防火墙中的任何条目不匹配，并且也可能被丢弃。
Current firewalls may not only prevent route optimization but may also prevent regular TCP and UDP sessions from being established in some cases. This document describes some of the issues between the Mobile IPv6 protocol and current firewall technologies.
当前的防火墙不仅可能阻止路由优化，而且在某些情况下还可能阻止建立常规TCP和UDP会话。本文档描述了移动IPv6协议和当前防火墙技术之间的一些问题。
This document captures the various issues involved in the deployment of Mobile IPv6 in networks that would invariably include firewalls. A number of different scenarios are described, which include configurations where the mobile node, correspondent node, and home agent exist across various boundaries delimited by the firewalls. This enables a better understanding of the issues when deploying Mobile IPv6 as well as the issues for firewall design and policies to be installed therein.
本文档介绍了在始终包含防火墙的网络中部署移动IPv6所涉及的各种问题。描述了许多不同的场景，其中包括移动节点、对应节点和归属代理跨越防火墙分隔的各种边界存在的配置。当安装IPv6时，可以更好地理解其中的移动防火墙设计和问题。
This document describes several issues that exist between the Mobile IPv6 protocol and firewalls.
本文档描述了移动IPv6协议和防火墙之间存在的几个问题。
Firewalls may prevent Mobile IP6 signaling in addition to dropping incoming/outgoing traffic.
除了丢弃传入/传出流量外，防火墙还可能阻止移动IP6信令。
If the firewall configuration is modified in order to support the Mobile IPv6 protocol but not properly configured, many attacks may be possible as outlined above: malicious nodes may be able to launch different types of denial of service attacks.
如果修改防火墙配置以支持移动IPv6协议，但未正确配置，则可能会发生如上所述的许多攻击：恶意节点可能会发起不同类型的拒绝服务攻击。
We would like to thank James Kempf, Samita Chakrabarti, Giaretta Gerardo, Steve Bellovin, Henrik Levkowetz, and Spencer Dawkins for their valuable comments. Their suggestions have helped improve both the presentation and the content of the document.
我们要感谢詹姆斯·坎普夫、萨米塔·查克拉巴蒂、贾莱塔·杰拉尔多、史蒂夫·贝洛文、亨里克·列夫科维茨和斯宾塞·道金斯的宝贵评论。他们的建议有助于改进文件的介绍和内容。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[2] Newman, D., "Benchmarking Terminology for Firewall Performance", RFC 2647, August 1999.
[2] Newman，D.，“防火墙性能的基准术语”，RFC 2647，1999年8月。
[3] Noble, J., Doug, D., Hourihan, K., Hourihan, K., Stephens, R., Stiefel, B., Amon, A., and C. Tobkin, "Check Point NG VPN-1/ Firewall-1 Advanced Configuration and Troubleshooting", Syngress Publishing Inc., 2003.
[3] Noble，J.，Doug，D.，Hourihan，K.，Hourihan，K.，Stephens，R.，Stiefel，B.，Amon，A.，和C.Tobkin，“Check Point NG VPN-1/防火墙-1高级配置和故障排除”，Syngres Publishing Inc.，2003年。
[4] Chen, X., Rinne, J., Wiljakka, J., and M. Watson, "Problem Statement for MIPv6 Interactions with GPRS/UMTS Packet Filtering", Work in Progress, January 2006.
[4] Chen，X.，Rinne，J.，Wiljakka，J.，和M.Watson，“MIPv6与GPRS/UMTS数据包过滤交互的问题陈述”，正在进行的工作，2006年1月。
In 3G networks, different packet filtering functionalities may be implemented to prevent malicious nodes from flooding or launching other attacks against the 3G subscribers. The packet filtering functionality of 3G networks is further described in [4]. Packet filters are set up and applied to both uplink and downlink traffic: outgoing and incoming data not matching the packet filters is dropped. The issues described in this document also apply to 3G networks.
在3G网络中，可以实现不同的分组过滤功能以防止恶意节点泛滥或对3G用户发起其他攻击。[4]中进一步描述了3G网络的分组过滤功能。设置包过滤器并应用于上行链路和下行链路流量：丢弃与包过滤器不匹配的传出和传入数据。本文档中描述的问题也适用于3G网络。
Authors' Addresses
作者地址
Franck Le Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213 USA
美国宾夕法尼亚州匹兹堡福布斯大道5000号法兰克卡内基梅隆大学15213
EMail: franckle@cmu.edu
EMail: franckle@cmu.edu
Stefano Faccin Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA
美国德克萨斯州欧文连接大道6000号Stefano Faccin诺基亚研究中心，邮编75039
EMail: sfaccinstd@gmail.com
EMail: sfaccinstd@gmail.com
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA
美国德克萨斯州欧文市Basavaraj Patil诺基亚6000连接驱动器75039
EMail: Basavaraj.Patil@nokia.com
EMail: Basavaraj.Patil@nokia.com
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
德国巴伐利亚州慕尼黑第6环汉内斯·茨霍芬尼西门子奥托·哈恩81739
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。