Internet Research Task Force (IRTF) Y. Qiu
Request for Comments: 5726 Institute for Infocomm Research
Category: Experimental F. Zhao, Ed.
ISSN: 2070-1721 Google
R. Koodli
Cisco Systems
February 2010
Internet Research Task Force (IRTF) Y. Qiu
Request for Comments: 5726 Institute for Infocomm Research
Category: Experimental F. Zhao, Ed.
ISSN: 2070-1721 Google
R. Koodli
Cisco Systems
February 2010
Mobile IPv6 Location Privacy Solutions
移动IPv6位置隐私解决方案
Abstract
摘要
Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the Mobile IPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.
移动IPv6（RFC 3775）允许移动节点在Internet上漫游时保持可访问性。然而，移动节点的位置和移动可以通过在信令或数据分组中使用的IP地址来揭示。在本文中，我们考虑在RFC 4882中描述的移动IPv6位置隐私问题，并提出有效和安全的技术来保护移动节点的位置隐私。本文档是IP移动性优化（MobOpts）研究组的产品。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the IP Mobility Optimizations Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。该RFC代表了互联网研究任务组（IRTF）IP移动性优化研究小组的共识。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5726.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5726.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................5
2. Conventions and Terminology .....................................6
2.1. Conventions ................................................6
2.2. Terminology ................................................6
3. Requirements ....................................................8
4. Solution Overview ...............................................9
5. Reverse-Tunneled Correspondent Binding Update ..................11
5.1. The Procedure .............................................12
5.2. Route-Optimized Payload Packets ...........................14
5.3. Mobile Node Operation .....................................15
5.3.1. Conceptual Data Structures .........................15
5.3.2. Reverse-Tunneled Correspondent Binding
Update to the Correspondent Node ...................15
5.3.3. Reverse-Tunneled Correspondent Binding
Acknowledgement from the Correspondent Node ........16
5.3.4. Route-Optimized Payload Packets ....................16
5.3.5. Receiving ICMP Error Message .......................17
5.3.6. Binding Error from the Correspondent Node ..........17
5.3.7. Binding Refresh Request from the
Correspondent Node .................................17
5.4. Home Agent Operation ......................................17
5.5. Correspondent Node Operation ..............................18
5.5.1. Conceptual Data Structures .........................18
5.5.2. Reverse-Tunneled Correspondent Binding
Update from the Mobile Node ........................18
5.5.3. Reverse-tunneled Correspondent Binding
Acknowledgement to the Mobile Node .................18
5.5.4. Route-Optimized Payload Packets ....................18
5.5.5. ICMP Error Message to the Mobile Node ..............19
5.5.6. Binding Error to the Mobile Node ...................19
5.5.7. Binding Refresh Request to the Mobile Node .........19
5.6. Summary ...................................................20
6. IP Address Location Privacy Solution Using the Pseudo
Home Address ...................................................20
6.1. Home Binding Update .......................................20
6.1.1. Pseudo Home Address Registration ...................20
6.1.2. Home De-Registration ...............................21
6.2. Correspondent Binding Update Using the Pseudo Home
Address ...................................................22
6.2.1. Return Routability Procedure .......................22
6.2.2. Route-Optimized Correspondent Binding Update .......24
6.2.3. Reverse-tunneled Correspondent Binding Update ......25
6.2.4. Using Different Pseudo Home Addresses with
Different Correspondent Nodes ......................25
6.3. Payload Packets ...........................................25
6.3.1. Reverse Tunneling Mode .............................25
1. Introduction ....................................................5
2. Conventions and Terminology .....................................6
2.1. Conventions ................................................6
2.2. Terminology ................................................6
3. Requirements ....................................................8
4. Solution Overview ...............................................9
5. Reverse-Tunneled Correspondent Binding Update ..................11
5.1. The Procedure .............................................12
5.2. Route-Optimized Payload Packets ...........................14
5.3. Mobile Node Operation .....................................15
5.3.1. Conceptual Data Structures .........................15
5.3.2. Reverse-Tunneled Correspondent Binding
Update to the Correspondent Node ...................15
5.3.3. Reverse-Tunneled Correspondent Binding
Acknowledgement from the Correspondent Node ........16
5.3.4. Route-Optimized Payload Packets ....................16
5.3.5. Receiving ICMP Error Message .......................17
5.3.6. Binding Error from the Correspondent Node ..........17
5.3.7. Binding Refresh Request from the
Correspondent Node .................................17
5.4. Home Agent Operation ......................................17
5.5. Correspondent Node Operation ..............................18
5.5.1. Conceptual Data Structures .........................18
5.5.2. Reverse-Tunneled Correspondent Binding
Update from the Mobile Node ........................18
5.5.3. Reverse-tunneled Correspondent Binding
Acknowledgement to the Mobile Node .................18
5.5.4. Route-Optimized Payload Packets ....................18
5.5.5. ICMP Error Message to the Mobile Node ..............19
5.5.6. Binding Error to the Mobile Node ...................19
5.5.7. Binding Refresh Request to the Mobile Node .........19
5.6. Summary ...................................................20
6. IP Address Location Privacy Solution Using the Pseudo
Home Address ...................................................20
6.1. Home Binding Update .......................................20
6.1.1. Pseudo Home Address Registration ...................20
6.1.2. Home De-Registration ...............................21
6.2. Correspondent Binding Update Using the Pseudo Home
Address ...................................................22
6.2.1. Return Routability Procedure .......................22
6.2.2. Route-Optimized Correspondent Binding Update .......24
6.2.3. Reverse-tunneled Correspondent Binding Update ......25
6.2.4. Using Different Pseudo Home Addresses with
Different Correspondent Nodes ......................25
6.3. Payload Packets ...........................................25
6.3.1. Reverse Tunneling Mode .............................25
6.3.2. Route Optimization Mode ............................26
6.4. Prefix Discovery ..........................................26
6.5. Mobile Node Operation .....................................26
6.5.1. Conceptual Data Structures .........................26
6.5.2. Binding Update to the Home Agent ...................27
6.5.3. Binding Acknowledgement from the Home Agent ........27
6.5.4. Home Test Init to the Home Agent ...................28
6.5.5. Home Test from the Home Agent ......................28
6.5.6. Route-Optimized Payload Packets ....................29
6.5.7. Receiving Binding Refresh Request ..................29
6.6. Home Agent Operation ......................................29
6.6.1. Conceptual Data Structures .........................30
6.6.2. Binding Update from the Mobile Node ................30
6.6.3. Binding Acknowledgement to the Mobile Node .........31
6.6.4. Home Test Init from the Mobile Node ................31
6.6.5. Home Test to the Mobile Node .......................32
6.7. Correspondent Node Operation ..............................32
7. Extensions to Mobile IPv6 ......................................32
7.1. Encrypted Home Address Destination Option .................32
7.2. Encrypted Home Address Routing Header .....................33
7.3. Pseudo Home Address Mobility Option .......................34
7.4. Pseudo Home Address Acknowledgement Mobility Option .......35
8. Security Considerations ........................................37
8.1. Home Binding Update .......................................37
8.2. Correspondent Binding Update ..............................38
8.3. Route-Optimized Payload Packets ...........................38
9. Related Work ...................................................39
10. IANA Considerations ...........................................40
11. Conclusion ....................................................40
12. Acknowledgements ..............................................41
13. References ....................................................41
13.1. Normative References .....................................41
13.2. Informative References ...................................42
Appendix A. Profiling Attack: Discussion ..........................44
A.1. The Care-of Address ........................................44
A.2. Profiling on the Encrypted Home Address ....................44
A.3. The IPsec SPI ..............................................45
A.4. The IPsec Sequence Number ..................................45
A.5. The Regular Interval of Signaling Messages..................46
A.6. The Sequence Number in the Binding Update Message ..........46
A.7. Multiple Concurrent Sessions ...............................46
A.8. Summary ....................................................47
6.3.2. Route Optimization Mode ............................26
6.4. Prefix Discovery ..........................................26
6.5. Mobile Node Operation .....................................26
6.5.1. Conceptual Data Structures .........................26
6.5.2. Binding Update to the Home Agent ...................27
6.5.3. Binding Acknowledgement from the Home Agent ........27
6.5.4. Home Test Init to the Home Agent ...................28
6.5.5. Home Test from the Home Agent ......................28
6.5.6. Route-Optimized Payload Packets ....................29
6.5.7. Receiving Binding Refresh Request ..................29
6.6. Home Agent Operation ......................................29
6.6.1. Conceptual Data Structures .........................30
6.6.2. Binding Update from the Mobile Node ................30
6.6.3. Binding Acknowledgement to the Mobile Node .........31
6.6.4. Home Test Init from the Mobile Node ................31
6.6.5. Home Test to the Mobile Node .......................32
6.7. Correspondent Node Operation ..............................32
7. Extensions to Mobile IPv6 ......................................32
7.1. Encrypted Home Address Destination Option .................32
7.2. Encrypted Home Address Routing Header .....................33
7.3. Pseudo Home Address Mobility Option .......................34
7.4. Pseudo Home Address Acknowledgement Mobility Option .......35
8. Security Considerations ........................................37
8.1. Home Binding Update .......................................37
8.2. Correspondent Binding Update ..............................38
8.3. Route-Optimized Payload Packets ...........................38
9. Related Work ...................................................39
10. IANA Considerations ...........................................40
11. Conclusion ....................................................40
12. Acknowledgements ..............................................41
13. References ....................................................41
13.1. Normative References .....................................41
13.2. Informative References ...................................42
Appendix A. Profiling Attack: Discussion ..........................44
A.1. The Care-of Address ........................................44
A.2. Profiling on the Encrypted Home Address ....................44
A.3. The IPsec SPI ..............................................45
A.4. The IPsec Sequence Number ..................................45
A.5. The Regular Interval of Signaling Messages..................46
A.6. The Sequence Number in the Binding Update Message ..........46
A.7. Multiple Concurrent Sessions ...............................46
A.8. Summary ....................................................47
The IP address location privacy problem is concerned with unwittingly revealing the current location of a mobile node to eavesdroppers and to communicating parties. In the presence of mobility as specified in Mobile IPv6 [6], there are two related problems: disclosing the care-of address to a correspondent node, and revealing the home address to an eavesdropper (please see the terminology below). A detailed description of the location privacy problem can be found in RFC 4882 [11]. This document assumes that the reader is familiar with the basic operation of Mobile IPv6 specified in RFC 3775, as well as the location privacy problem described in RFC 4882.
IP地址位置隐私问题涉及到无意中将移动节点的当前位置泄露给窃听者和通信方。在移动IPv6[6]中规定的移动性存在的情况下，存在两个相关问题：向通信节点披露转交地址，以及向窃听者披露家庭地址（请参见下面的术语）。有关位置隐私问题的详细说明，请参见RFC 4882[11]。本文档假设读者熟悉RFC 3775中规定的移动IPv6的基本操作，以及RFC 4882中描述的位置隐私问题。
In order to protect location privacy, a mobile node must not disclose the binding between its care-of address and its home address. In this document, we propose a set of extensions to the Mobile IPv6 specification to address the IP address location privacy problem. Related to the IP address location privacy is "profiling", where the activities of a mobile node are linked and then analyzed. Profiled activities may contribute to compromising a mobile node's location privacy, especially when combined with additional information. Furthermore, once location privacy is compromised, it may lead to more targeted profiling. Solutions to thwart profiling are important; however, they are not central to this document. We discuss profiling in the appendix.
为了保护位置隐私，移动节点不得披露其转交地址和家庭地址之间的绑定。在本文档中，我们建议对移动IPv6规范进行一系列扩展，以解决IP地址位置隐私问题。与IP地址位置隐私相关的是“分析”，即链接并分析移动节点的活动。分析的活动可能有助于损害移动节点的位置隐私，尤其是与其他信息结合使用时。此外，一旦位置隐私受到损害，可能会导致更具针对性的分析。阻止仿形的解决方案很重要；但是，它们不是本文件的核心。我们将在附录中讨论分析。
We propose two IP address location privacy solutions in this document. With the first solution (as described in Section 5), the mobile node can communicate with the correspondent node by using the real home address without location privacy being breached by eavesdroppers. This is done by using parameters generated during the return routability procedure to mask the real home address, which provides an evolution towards location privacy protection based on return routability messages already specified in RFC 3775. With the second solution (as described in Section 6), an IPsec tunnel mode security association with a non-null encryption algorithm is negotiated to encrypt signaling messages (including the real home address therein) exchanged between the mobile node and the home agent, for example, during the home binding update procedure. Furthermore, during the return routability procedure and the correspondent binding update procedure, a "pseudo home address" (the definition of this new term and many other commonly used mobility related terms is provided in Section 2) is used to replace the real home address in various messages, which allows the mobile node to hide its real home address from both the correspondent node and eavesdroppers without the need for additional extensions to the correspondent node. Moreover, the mobile node may mask the pseudo
在本文档中，我们提出了两个IP地址位置隐私解决方案。使用第一种解决方案（如第5节所述），移动节点可以通过使用真实的家庭地址与对应节点通信，而不会被窃听者侵犯位置隐私。这是通过使用返回可路由性过程中生成的参数来屏蔽真实的家庭地址来实现的，这提供了一种基于RFC 3775中已经指定的返回可路由性消息的位置隐私保护的演变。使用第二种解决方案（如第6节所述），协商具有非空加密算法的IPsec隧道模式安全关联，以加密移动节点和归属代理之间交换的信令消息（包括其中的真实归属地址），例如，在归属绑定更新过程中。此外，在返回路由性过程和相应的绑定更新过程期间，使用“伪家庭地址”（第2节提供了该新术语和许多其他常用的移动相关术语的定义）来替换各种消息中的真实家庭地址，这允许移动节点向对应节点和窃听者隐藏其真实家庭地址，而无需对对应节点进行额外扩展。此外，移动节点可以掩蔽伪信道
home address by using the mechanism specified in Section 5 to further enhance location privacy protection. Each of these two solutions can be implemented on its own without relying on the other.
通过使用第5节规定的机制来进一步加强位置隐私保护的家庭地址。这两个解决方案中的每一个都可以独立实现，而不依赖于另一个。
The solutions presented in this document are designed based on the following assumptions. First, we focus on location privacy issues arising when the mobile node attaches to a foreign link; location privacy issues when the mobile node attaches to its home link, if any, are outside the scope of this document. Second, we assume that IPsec [2] is used to secure mobility signaling messages exchanged between the mobile node and the home agent; therefore, location privacy solutions when other security mechanisms are used are beyond the scope of this document. Third, we assume that eavesdroppers are passive attackers, e.g., an eavesdropper along the path traversed by traffic flows from or to the mobile node. We make this assumption because messages generated by active attackers can either be discarded based on local policy at a mobile node or the mobile node could choose to treat such messages like those of any other correspondent nodes. Thus, specific threats to location privacy posed by active attackers are also beyond the scope of this document. Fourth, in order to simplify analysis, we assume that both the correspondent node and the home agent are fixed nodes; if either is mobile, the same analysis and solutions for the mobile node may also apply. Finally, the same solution applies to each of the care-of addresses if a mobile node maintains more than one care-of address.
本文件中提出的解决方案是基于以下假设设计的。首先，我们关注移动节点连接到外部链接时出现的位置隐私问题；移动节点连接到其主链接时的位置隐私问题（如有）不在本文档范围内。其次，我们假设IPsec[2]用于保护移动节点和归属代理之间交换的移动信令消息；因此，使用其他安全机制时的位置隐私解决方案超出了本文档的范围。第三，我们假设窃听者是被动攻击者，例如，沿着从或到移动节点的流量所穿过的路径的窃听者。我们之所以做出这种假设，是因为主动攻击者生成的消息可以根据移动节点的本地策略丢弃，或者移动节点可以选择像对待任何其他对应节点的消息一样对待这些消息。因此，主动攻击者对位置隐私造成的特定威胁也超出了本文档的范围。第四，为了简化分析，我们假设对应节点和归属代理都是固定节点；如果其中一个是移动的，则也可以应用针对移动节点的相同分析和解决方案。最后，如果移动节点维护多个转交地址，则相同的解决方案适用于每个转交地址。
This document represents the consensus of the MobOpts Research Group. It has been reviewed by the Research Group members active in the specific area of work. At the request of their chairs, this document has been comprehensively reviewed by multiple active contributors to the IETF Mobile IP related working groups.
本文件代表了MobOpts研究小组的共识。该报告已由活跃于特定工作领域的研究小组成员审查。应主席的要求，IETF移动IP相关工作组的多个积极参与者对本文件进行了全面审查。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
In this document, we introduce two new terms, "pseudo home address" and "encrypted home address". The definition of these two terms is provided in the following.
在本文中，我们引入了两个新术语，“伪家庭地址”和“加密家庭地址”。以下提供了这两个术语的定义。
o Pseudo Home Address (pHoA): A unicast IPv6 address formed to replace the real home address used in certain Mobile IPv6 signaling or data packets. Without explicit indication, the pseudo home address looks like a regular IPv6 address [5].
o 伪家庭地址（pHoA）：一个单播IPv6地址，用于替换某些移动IPv6信令或数据包中使用的真实家庭地址。在没有明确指示的情况下，伪主地址看起来像常规IPv6地址[5]。
o Encrypted Home Address (eHoA): The output when applying an encryption algorithm to the real home address or the pseudo home address with additional inputs, e.g., a key. The real home address can be recovered from the encrypted home address by using a decryption algorithm.
o 加密家庭地址（eHoA）：将加密算法应用于实际家庭地址或带有额外输入（例如密钥）的伪家庭地址时的输出。通过使用解密算法，可以从加密的家庭地址恢复真实的家庭地址。
In addition, we use commonly adopted mobility-related terms as defined in [6] and [11] throughout this document. Some of these terms are provided below for easier reference. Nevertheless, we assume that readers are familiar with the basic operation of the Mobile IPv6 protocol as defined in RFC 3775 [6], RFC 3776 [7], and RFC 4877 [8].
此外，我们在本文件中使用了[6]和[11]中定义的常用移动相关术语。以下提供了其中一些术语，以便于参考。然而，我们假设读者熟悉RFC 3775[6]、RFC 3776[7]和RFC 4877[8]中定义的移动IPv6协议的基本操作。
o Mobile Node (MN): A Mobile IPv6 compliant mobile node that can roam on the Internet
o 移动节点（MN）：符合IPv6的移动节点，可在Internet上漫游
o Correspondent Node (CN): An IPv6 node that communicates with the mobile node
o 通讯节点（CN）：与移动节点通信的IPv6节点
o Home Network: The network where the mobile node is normally present when it is not roaming
o 家庭网络：移动节点不漫游时通常存在的网络
o Visited Network: The network that the mobile node uses to access the Internet when it is roaming
o 访问网络：移动节点在漫游时用于访问Internet的网络
o Home Agent (HA): A router on the mobile node's home network that provides forwarding support when the mobile node is roaming
o 归属代理（HA）：移动节点的归属网络上的路由器，在移动节点漫游时提供转发支持
o Home Address (HoA): The mobile node's unicast IP address valid on its home network
o 家庭地址（HoA）：移动节点在其家庭网络上有效的单播IP地址
o Care-of Address (CoA): The mobile node's unicast IP address valid on the visited network
o 转交地址（CoA）：在访问的网络上有效的移动节点的单播IP地址
o Return Routability (RR): A procedure which enables secure binding between the care-of address and the home address when no pre-existing security association exists between the mobile node and the correspondent node
o 返回可路由性（RR）：当移动节点和对应节点之间不存在预先存在的安全关联时，启用转交地址和家庭地址之间的安全绑定的过程
o Home Test Init (HoTI) / Home Test (HoT) / Care-of Test Init (CoTI) / Care-of Test (CoT): Messages used during the return routability procedure
o Home Test Init（HoTI）/Home Test（HoT）/Care of Test Init（CoTI）/Care of Test（CoT）：返回路由性过程中使用的消息
o Binding Update (BU): A message used by the mobile node to securely bind its care-of address to its home address at the correspondent node or the home agent
o 绑定更新（BU）：移动节点用于将其转交地址安全绑定到对应节点或归属代理的归属地址的消息
o Binding Acknowledgement (BA): A response to the Binding Update
o 绑定确认（BA）：对绑定更新的响应
o Message Authentication Code (MAC): The value, which is computed using HMAC_SHA1 in this document, that protects both a message's integrity and its authenticity
o 消息身份验证码（MAC）：在本文档中使用HMAC_SHA1计算的值，用于保护消息的完整性和真实性
o Route Optimization: A mechanism that allows direct routing of packets between a roaming mobile node and its correspondent node, without having to traverse the home network
o 路由优化：一种允许在漫游移动节点与其对应节点之间直接路由数据包的机制，无需穿越家庭网络
o Reverse Tunneling or Bidirectional Tunneling: A mechanism used for packet forwarding between a roaming mobile node and its correspondent node via its home agent
o 反向隧道或双向隧道：用于漫游移动节点与其对应节点之间通过其归属代理进行数据包转发的机制
In this section, we describe the requirements that should be met by the Mobile IPv6 location privacy solutions, hereafter referred to as "the solution". These are some of the basic requirements set forth in order to make the solution readily implementable by those familiar with Mobile IPv6 and the related security protocols used with it (such as IKEv2 [4] and IPsec).
在本节中，我们将介绍移动IPv6位置隐私解决方案（以下简称“解决方案”）应满足的要求。这些是为使熟悉移动IPv6及其使用的相关安全协议（如IKEv2[4]和IPsec）的人易于实现解决方案而提出的一些基本要求。
R01: The solution must follow the framework and architecture of IPv6 and Mobile IPv6 (as specified in RFC 3775, RFC 3776, and RFC 4877).
R01：解决方案必须遵循IPv6和移动IPv6的框架和体系结构（如RFC 3775、RFC 3776和RFC 4877中所述）。
R02: The solution must not interfere with the operation of IPsec. This means that the principles and the operation specified in RFC 3776 and RFC 4877 need to be followed. For example, the IPsec security association and policy must be identified by the real home address.
R02:解决方案不得干扰IPsec的操作。这意味着需要遵循RFC 3776和RFC 4877中规定的原则和操作。例如，IPsec安全关联和策略必须由实际的家庭地址标识。
R03: The solution should provide back-compatibility in order for different Mobile IPv6 entities to work together even though they may have different capabilities. This requires the mobile node to be able to detect whether the home agent or the correspondent node supports the use of the location privacy solutions.
R03：解决方案应提供向后兼容性，以便不同的移动IPv6实体能够协同工作，即使它们可能具有不同的功能。这要求移动节点能够检测归属代理或对应节点是否支持使用位置隐私解决方案。
R04: The overhead resulting from the solution, in terms of payloads or messages transmitted and memory, should be kept minimal.
R04：解决方案在有效负载或消息传输和内存方面产生的开销应保持最小。
The IP address location privacy solutions proposed in this document intend to conceal the binding between the mobile node's real home address and its care-of address from eavesdroppers and the correspondent node. In this section, we present an overview of the proposed solutions.
本文档中提出的IP地址位置隐私解决方案旨在隐藏移动节点的真实家庭地址与其转交地址之间的绑定，以防窃听者和对应节点。在本节中，我们将概述所提出的解决方案。
With the Mobile IPv6 specification, during the home binding update procedure, both the real home address and the care-of address are in the cleartext when either the IPsec tunnel mode or the IPsec transport mode is used with no encryption. As described in Section 6.1, the solution to prevent the real home address being leaked to eavesdroppers on the MN-HA path during the home binding update procedure is to set up an IPsec tunnel mode security association with a non-null encryption algorithm to encrypt home binding signaling messages and the real home address therein. This method is also used to enable location privacy protection during other mobility signaling message exchanges between the home agent and the mobile node, such as the prefix discovery procedure (see Section 6.4).
根据移动IPv6规范，在家庭绑定更新过程中，当IPsec隧道模式或IPsec传输模式未加密时，真实家庭地址和转交地址都在明文中。如第6.1节所述，在家庭绑定更新过程中，防止真实家庭地址泄漏给MN-HA路径上的窃听者的解决方案是使用非空加密算法建立IPsec隧道模式安全关联，以加密家庭绑定信令消息和其中的真实家庭地址。该方法还用于在归属代理和移动节点之间的其他移动信令消息交换期间启用位置隐私保护，例如前缀发现过程（参见第6.4节）。
When communicating with the correspondent node with the reverse tunneling mode, the mobile node can hide its current location from the correspondent node and eavesdroppers along the HA-CN path, since the care-of address is not included in payload packets transmitted on that path. Also, an IPsec security association with a non-null encryption algorithm established between the mobile node and the home agent can conceal the real home address carried in payload packets from eavesdroppers along the MN-HA path.
当使用反向隧道模式与对应节点通信时，移动节点可以向对应节点和沿着HA-CN路径的窃听者隐藏其当前位置，因为转交地址不包括在该路径上传输的有效载荷分组中。此外，具有在移动节点和归属代理之间建立的非空加密算法的IPsec安全关联可以隐藏有效载荷分组中携带的真实归属地址，以防沿着MN-HA路径的窃听者。
In order to communicate with a correspondent node in the route optimization mode, the mobile node needs to perform the return routability procedure followed by the correspondent binding update procedure. With the current Mobile IPv6 specification, the real home address and the care-of address in the correspondent Binding Update message and payload packets are visible to eavesdroppers. Therefore, in order to send and receive packets through the optimized route and protect location privacy at the same time, the mobile node needs to disclose its care-of address and conceal its real home address. There are two different scenarios and we propose a different solution for each scenario.
为了在路由优化模式下与对应节点通信，移动节点需要执行返回路由性过程，然后执行对应绑定更新过程。根据当前的移动IPv6规范，窃听者可以看到相应绑定更新消息和有效负载数据包中的真实家庭地址和转交地址。因此，为了通过优化的路由发送和接收数据包，同时保护位置隐私，移动节点需要公开其转交地址并隐藏其真实的家庭地址。有两种不同的场景，我们为每个场景提出了不同的解决方案。
One scenario is that the correspondent node is able to obtain the mobile node's real home address and initiates communication with the mobile node by using the real home address. In this case, the mobile node needs to continue to use the real home address with the correspondent node in order to maintain session continuity, and to
一个场景是对应节点能够获得移动节点的真实家庭地址，并通过使用真实家庭地址来发起与移动节点的通信。在这种情况下，移动节点需要继续使用对应节点的真实家庭地址，以保持会话连续性，并
conceal the real home address from eavesdroppers. The solution for this scenario (hereinafter referred to as "reverse-tunneled correspondent binding update") is described in Section 5. With this solution, the mobile node exchanges the same return routability signaling messages as defined in RFC 3775 with the correspondent node and then derives a privacy management key from keygen tokens and uses this key to encrypt the real home address. Finally, it reverse-tunnels an extended correspondent Binding Update message via the home agent to register the encrypted home address and the real home address at the correspondent node. After the correspondent registration, the mobile node and the correspondent node use the registered encrypted home address, instead of the real home address in payload packets exchanged via the optimized route. The encrypted home address is different for different correspondent nodes since the privacy management key would be different.
对窃听者隐瞒真实的家庭住址。第5节描述了该场景的解决方案（以下称为“反向隧道对应绑定更新”）。使用该解决方案，移动节点与对应节点交换RFC 3775中定义的相同返回路由性信令消息，然后从keygen令牌导出隐私管理密钥，并使用该密钥加密真实家庭地址。最后，它通过归属代理反向传输扩展的对应绑定更新消息，以在对应节点上注册加密的归属地址和真实的归属地址。在对应注册之后，移动节点和对应节点使用注册的加密家庭地址，而不是通过优化路由交换的有效载荷分组中的真实家庭地址。加密的家庭地址对于不同的通信节点是不同的，因为隐私管理密钥是不同的。
The other scenario is that the mobile node prefers to conceal its real home address from both the correspondent node and the eavesdroppers (typically the mobile node initiates communication in this case, since the correspondent node does not know the real home address). The solution for this scenario is described in Section 6.2. With this solution, the mobile node first obtains a home keygen token generated based on the pseudo home address during the home address test procedure. Subsequently, the mobile node sends the correspondent Binding Update message to register the binding between the pseudo home address and the care-of address at the correspondent node via the optimized route. After the correspondent registration, the mobile node and the correspondent node use the registered pseudo home address, instead of the real home address, in payload packets exchanged via the optimized route. Note that the use of the pseudo home address is completely transparent to the correspondent node.
另一种情况是，移动节点倾向于向对应节点和窃听者隐藏其真实家庭地址（通常，在这种情况下，移动节点发起通信，因为对应节点不知道真实家庭地址）。第6.2节描述了该场景的解决方案。利用该解决方案，移动节点首先在归属地址测试过程中获得基于伪归属地址生成的归属密钥生成令牌。随后，移动节点发送对应绑定更新消息，以通过优化的路由在对应节点处注册伪归属地址和转交地址之间的绑定。在对应注册之后，移动节点和对应节点在经由优化路由交换的有效载荷分组中使用注册的伪归属地址，而不是真实的归属地址。请注意，伪主地址的使用对对应节点是完全透明的。
Furthermore, it is feasible to throttle "profiling" on the pseudo home address by using a combination of these two solutions. That is, the mobile node uses the pseudo home address in the extended home address test procedure to obtain a home keygen token; then, it uses the pseudo home address instead of the real home address in the reverse-tunneled correspondent binding update procedure. With this solution, the encrypted pseudo home address used in route optimized payload packets looks different to eavesdroppers each time, after a new round of the return routability procedure is completed.
此外，通过使用这两种解决方案的组合来限制伪主地址上的“分析”是可行的。即，移动节点在扩展归属地址测试过程中使用伪归属地址来获得归属密钥生成令牌；然后，在反向隧道对应绑定更新过程中，它使用伪主地址而不是真实的主地址。使用此解决方案，在完成新一轮返回路由可路由性过程后，路由优化有效负载数据包中使用的加密伪主地址每次对窃听者来说都是不同的。
Before a pseudo home address is used with a correspondent node, it MUST be registered with the home agent during the home registration procedure. The mobile node indicates the requested pseudo home address in a new mobility option, called the Pseudo Home Address option (see Section 7.3), carried in the home Binding Update message,
在将伪主地址用于对应节点之前，必须在主注册过程中向主代理注册它。移动节点在归属绑定更新消息中携带的称为伪归属地址选项（参见第7.3节）的新移动选项中指示请求的伪归属地址，
and the home agent indicates the status of pseudo home address registration in another new mobility option, called Pseudo Home Address Acknowledgement option (see Section 7.4), carried in the home Binding Acknowledgement message. The pseudo home address MUST be routable in order for the home agent to intercept packets destined at this pseudo home address. It is statistically difficult for other nodes to derive the real home address from the pseudo home address. A detailed description of pseudo home address generation is provided in Section 6.1.1.1.
并且归属代理在归属绑定确认消息中携带的另一个称为伪归属地址确认选项（参见第7.4节）的新移动选项中指示伪归属地址注册的状态。伪家庭地址必须是可路由的，以便家庭代理截获以该伪家庭地址为目的地的数据包。从统计上讲，其他节点很难从伪主地址推导出真实的主地址。第6.1.1.1节提供了伪家庭地址生成的详细说明。
With extensions introduced in this document, a mobile node is able to discover whether the home agent and the correspondent node support the location privacy solutions or not. When present in the home Binding Update message, the Pseudo Home Address mobility option indicates that the mobile node requests the use of the location privacy solutions. If such a Binding Update message is valid and the home agent supports the location privacy solutions for this particular mobile node, it responds with the Pseudo Home Address Acknowledgement mobility option in the Binding Acknowledgement message. Otherwise, if the home agent does not support the location privacy solutions, it does not include the Pseudo Home Address Acknowledgement mobility option in the Binding Acknowledgement message. Similarly, the presence of the Encrypted Home Address destination option in the correspondent Binding Update message indicates to the correspondent node that the mobile node requests the use of the location privacy solutions. If such a Binding Update message is valid and the correspondent node supports the location privacy solutions for this particular mobile node, it responds with the Encrypted Home Address routing header in the correspondent Binding Acknowledgement message to the mobile node. If the correspondent node does not support the location privacy solutions, it rejects the mobile node's request by returning an ICMP Parameter Problem message with Code value set to 2. Furthermore, a home agent that recognizes such extensions but does not wish to provide location privacy protection MAY redirect the mobile node to another home agent. If the request for using the location privacy solutions is rejected, the mobile node may either proceed without location privacy protection, or try with a different home agent or a correspondent node, or abort the operation.
通过本文档中介绍的扩展，移动节点能够发现归属代理和对应节点是否支持位置隐私解决方案。当出现在家庭绑定更新消息中时，伪家庭地址移动选项指示移动节点请求使用位置隐私解决方案。如果这样的绑定更新消息是有效的，并且归属代理支持该特定移动节点的位置隐私解决方案，则它使用绑定确认消息中的伪归属地址确认移动选项进行响应。否则，如果归属代理不支持位置隐私解决方案，则在绑定确认消息中不包括伪归属地址确认移动选项。类似地，对应绑定更新消息中的加密家庭地址目的地选项的存在向对应节点指示移动节点请求使用位置隐私解决方案。如果这样的绑定更新消息是有效的，并且对应节点支持该特定移动节点的位置隐私解决方案，则其使用对应绑定确认消息中的加密归属地址路由报头响应移动节点。如果对应节点不支持位置隐私解决方案，它将通过返回ICMP参数问题消息（代码值设置为2）拒绝移动节点的请求。此外，识别此类扩展但不希望提供位置隐私保护的归属代理可以将移动节点重定向到另一归属代理。如果拒绝使用位置隐私解决方案的请求，则移动节点可以在没有位置隐私保护的情况下继续，或者尝试使用不同的归属代理或对应节点，或者中止操作。
In this section, we describe a solution that protects location privacy against eavesdroppers when the mobile node uses the real home address during communication with the correspondent node via the optimized route. Note that this solution does not require any change to return routability signaling messages. The detailed description is as follows.
在本节中，我们描述了一种解决方案，当移动节点在通过优化路由与对应节点通信期间使用真实家庭地址时，该解决方案可保护位置隐私免受窃听。请注意，此解决方案不需要任何更改来返回可路由性信令消息。具体说明如下。
After the return routability procedure is completed, if the mobile node needs to protect location privacy, and at the same time still uses the real home address with the correspondent node, the mobile node derives a privacy management key, Kpm, from the Kbm, where Kpm = HMAC_SHA1 (Kbm, 0). The mobile node uses Kpm to generate the encrypted home address as follows.
在返回可路由性过程完成之后，如果移动节点需要保护位置隐私，并且同时仍然使用对应节点的真实家庭地址，则移动节点从Kbm派生隐私管理密钥Kpm，其中Kpm=HMAC_SHA1（Kbm，0）。移动节点使用Kpm生成加密的家庭地址，如下所示。
encrypted home address = Enc(Kpm, the home address)
加密的家庭地址=Enc（Kpm，家庭地址）
Where Enc() is a symmetric key encryption algorithm. AES is the default encryption algorithm.
其中Enc（）是一种对称密钥加密算法。AES是默认的加密算法。
Kpm changes upon every change of Kbm, which itself changes when return routability is run (e.g., upon change of care-of address, expiry of keygen token, etc.). So, Kpm is not re-used when a care-of address changes.
Kpm会随着Kbm的每次更改而更改，当返回路由性运行时，Kbm本身也会更改（例如，在转交地址更改、keygen令牌到期时，等等）。因此，当转交地址发生更改时，不会重复使用Kpm。
The mobile node generates a correspondent Binding Update message and reverse-tunnels this message to the correspondent node via the home agent. The format of this message after encapsulation is:
移动节点生成对应绑定更新消息，并通过归属代理将该消息反向传送到对应节点。封装后此消息的格式为：
IPv6 header (source = care-of address, destination = home agent) ESP header in tunnel mode IPv6 header (source = home address, destination = correspondent node) Destination option header Encrypted Home Address option (encrypted home address) Parameters: Alternative Care-of Address option (care-of address) sequence number (within the Binding Update message header) home nonce index (within the Nonce Indices option) care-of nonce index (within the Nonce Indices option) First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BU)))
IPv6标头（源=转交地址，目的地=归属代理）隧道模式下的ESP标头IPv6标头（源=归属地址，目的地=对应节点）目的地选项标头加密的归属地址选项（加密的归属地址）参数：替代转交地址选项（转交地址）序号（在绑定更新消息头中）主临时索引（在临时索引选项中）转交临时索引（在临时索引选项中）首先（96，HMAC_SHA1（Kbm，（转交地址|对应方| BU）））
This packet is protected by the IPsec security association with a non-null encryption algorithm. If the home agent can process this packet successfully, it forwards the following packet to the correspondent node.
此数据包受IPsec安全关联和非空加密算法的保护。如果归属代理能够成功地处理该数据包，则它将以下数据包转发给对应节点。
IPv6 header (source = home address, destination = correspondent node) Destination option header Encrypted Home Address option (encrypted home address)
IPv6标头（源=主地址，目标=对应节点）目标选项标头加密的主地址选项（加密的主地址）
Parameters: Alternative Care-of Address option (care-of address) sequence number (within the Binding Update message header) home nonce index (within the Nonce Indices option) care-of nonce index (within the Nonce Indices option) First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BU)))
参数：可选转交地址选项（转交地址）序列号（在绑定更新消息头内）主临时索引（在临时索引选项内）转交临时索引（在临时索引选项内）首先（96，HMAC_SHA1（Kbm，（转交地址|对应方| BU）））
After receiving a reverse-tunneled correspondent Binding Update message, the correspondent node performs the operation as described in Section 5.5. If the correspondent Binding Update message is processed successfully and an acknowledgement is requested, the correspondent node constructs a Binding Acknowledgement message shown below.
在接收到反向隧道对应绑定更新消息后，对应节点执行第5.5节所述的操作。如果成功处理对应的绑定更新消息并请求确认，则对应节点将构造如下所示的绑定确认消息。
IPv6 header (source = correspondent node, destination = home address) Encrypted Home Address routing header encrypted home address Parameters: sequence number (within the Binding Update message header) First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BA)))
IPv6报头（源=对应节点，目的地=家庭地址）加密家庭地址路由报头加密家庭地址参数：序列号（在绑定更新消息报头内）第一（96，HMAC_SHA1（Kbm，（转交地址|对应方| BA）））
Upon receiving this Binding Acknowledgement message, the home agent applies the IPsec security association with a non-null encryption algorithm to this message and forwards the following packet to the mobile node.
在接收到该绑定确认消息后，归属代理将具有非空加密算法的IPsec安全关联应用于该消息，并将以下数据包转发给移动节点。
IPv6 header (source = home agent, destination = care-of address) ESP header in tunnel mode IPv6 header (source = correspondent node, destination = home address) Encrypted Home Address routing header encrypted home address Parameters: sequence number (within the Binding Update message header) First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BA)))
IPv6报头（源=归属代理，目的地=转交地址）隧道模式下的ESP报头IPv6报头（源=对应节点，目的地=归属地址）加密的归属地址路由报头加密的归属地址参数：序列号（在绑定更新消息报头内）第一（96，HMAC_SHA1（Kbm，（转交地址|通讯员| BA）））
The reverse-tunneled correspondent binding update procedure is completed after the mobile node processes the received Binding Acknowledgement message. Note that when the mobile node communicates with a different correspondent node, the encrypted home address looks different.
在移动节点处理接收到的绑定确认消息之后，反向隧道对应绑定更新过程完成。注意，当移动节点与不同的对应节点通信时，加密的家庭地址看起来不同。
To delete an established Binding Cache entry at the correspondent node, the mobile node reverse-tunnels the following Binding Update message via the home agent. Note that the Encrypted Home Address option is optional during the correspondent binding de-registration and only the home keygen token is used to generate Kbm and Kpm, if needed, in this case.
要删除对应节点上已建立的绑定缓存项，移动节点通过归属代理反向传输以下绑定更新消息。请注意，在相应的绑定取消注册期间，加密的家庭地址选项是可选的，在这种情况下，如果需要，仅使用家庭密钥生成令牌来生成Kbm和Kpm。
IPv6 header (source = care-of address, destination = home agent) ESP header in tunnel mode IPv6 header (source = home address, destination = correspondent node) Destination option header (optional) Encrypted Home Address option (encrypted home address) Parameters: Alternative Care-of Address option (care-of address) sequence number (within the Binding Update message header) home nonce index (within the Nonce Indices option) care-of nonce index (within the Nonce Indices option) First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BU)))
IPv6标头（源=转交地址，目的地=归属代理）隧道模式下的ESP标头IPv6标头（源=归属地址，目的地=对应节点）目的地选项标头（可选）加密的归属地址选项（加密的归属地址）参数：替代转交地址选项（转交地址）序号（在绑定更新消息头中）主临时索引（在临时索引选项中）转交临时索引（在临时索引选项中）首先（96，HMAC_SHA1（Kbm，（转交地址|对应方| BU）））
If an acknowledgement is requested, the correspondent node returns the following Binding Acknowledgement message to the mobile node.
如果请求确认，则对应节点将以下绑定确认消息返回给移动节点。
IPv6 header (source = correspondent node, destination = home address) Encrypted Home Address routing header (optional) encrypted home address Parameters: sequence number (within the Binding Update message header) First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BA)))
IPv6报头（源=对应节点，目的地=家庭地址）加密家庭地址路由报头（可选）加密家庭地址参数：序列号（在绑定更新消息报头内）第一（96，HMAC_SHA1（Kbm，（转交地址|对应方| BA）））
Since the destination IP address in this message is the home address, the home agent will receive this message and forward it to the mobile node via the reverse tunnel.
由于此消息中的目标IP地址是归属地址，归属代理将接收此消息并通过反向隧道将其转发给移动节点。
After the correspondent registration is completed successfully, subsequent payload packets are exchanged via the optimized route between the mobile node and the correspondent node. In such packets, only the encrypted home address carried in the Encrypted Home Address destination option and the Encrypted Home Address routing header are visible to eavesdroppers.
在对应注册成功完成之后，随后的有效载荷分组经由移动节点和对应节点之间的优化路由交换。在这样的分组中，只有加密的家庭地址目的地选项中携带的加密的家庭地址和加密的家庭地址路由报头对窃听者可见。
The format of payload packets sent from the mobile node to the correspondent node is:
从移动节点发送到对应节点的有效载荷分组的格式为：
IPv6 header (source = care-of address, destination = correspondent node) Destination option header Encrypted Home Address option (encrypted home address) Payload
IPv6标头（源=转交地址，目的地=对应节点）目的地选项标头加密的家庭地址选项（加密的家庭地址）有效负载
The format of payload packets sent from the correspondent node to the mobile node is:
从对应节点发送到移动节点的有效载荷分组的格式为：
IPv6 header (source = correspondent node, destination = care-of address) Encrypted Home Address routing header encrypted home address Payload
IPv6标头（源=对应节点，目标=转交地址）加密的家庭地址路由标头加密的家庭地址有效负载
The Binding Update List entry for the correspondent registration is extended with a new field to store the current encrypted home address used with a particular correspondent node. The encrypted home address is stored when the mobile node sends a reverse-tunneled correspondent Binding Update message, and the state of the corresponding Binding Update List entry is updated when the mobile node successfully processes the correspondent Binding Acknowledgement message. Note that the encrypted home address field is not valid in the Binding Update List entry for the home registration.
对应注册的绑定更新列表条目使用新字段进行扩展，以存储与特定对应节点一起使用的当前加密家庭地址。当移动节点发送反向隧道对应绑定更新消息时，存储加密的归属地址，并且当移动节点成功处理对应绑定确认消息时，更新对应绑定更新列表条目的状态。请注意，加密的家庭地址字段在家庭注册的绑定更新列表条目中无效。
Given that the encrypted home address is 128 bits long, it is expected that each encrypted home address or the combination of the encrypted home address and the correspondent node's IP address stored in the Binding Update List is unique. Therefore, the mobile node can use the encrypted home address (or use it together with the correspondent node's IP address) as a primary key to look up the Binding Update List.
假定加密的家庭地址为128位长，则预期每个加密的家庭地址或加密的家庭地址与存储在绑定更新列表中的对应节点的IP地址的组合是唯一的。因此，移动节点可以使用加密的家庭地址（或将其与对应节点的IP地址一起使用）作为主键来查找绑定更新列表。
5.3.2. Reverse-Tunneled Correspondent Binding Update to the Correspondent Node
5.3.2. 反向隧道对应绑定更新到对应节点
After the return routability procedure, if the mobile node chooses to use the location privacy solution with the correspondent node, e.g., based on the mobile node's configuration, it generates the encrypted home address, updates or creates a new correspondent Binding Update List entry to store the encrypted home address, then forwards the
在返回可路由性过程之后，如果移动节点选择对对应节点使用位置隐私解决方案，例如，基于移动节点的配置，它生成加密的家庭地址，更新或创建新的对应绑定更新列表条目以存储加密的家庭地址，然后转发
correspondent Binding Update message through the reverse tunnel established with the home agent. Note that the MAC is generated in the same way as specified in RFC 3775, and it does not cover the encrypted home address.
通过与归属代理建立的反向隧道发送相应的绑定更新消息。请注意，MAC的生成方式与RFC 3775中规定的相同，并且它不包括加密的家庭地址。
5.3.3. Reverse-Tunneled Correspondent Binding Acknowledgement from the Correspondent Node
5.3.3. 来自对应节点的反向隧道对应绑定确认
When the mobile node receives a Binding Acknowledgement message from the correspondent node in response to a previously sent reverse-tunneled correspondent Binding Update message, if this Binding Acknowledgement message contains an Encrypted Home Address routing header, the mobile node considers that the correspondent node supports the location privacy solution. The mobile node authenticates this message based on RFC 3775. If authentication is successful, the mobile node decrypts the encrypted home address and compares the result with the real home address, or compares the encrypted home address with the one stored in the Binding Update List entry. If they match, the mobile node considers that the correspondent registration is successful and updates the state of the corresponding Binding Update List entry. If they do not match, the mobile node MAY start the correspondent binding update procedure again.
当移动节点响应于先前发送的反向隧道对应绑定更新消息从对应节点接收绑定确认消息时，如果该绑定确认消息包含加密的归属地址路由报头，移动节点认为对应节点支持位置隐私解决方案。移动节点基于rfc3775认证该消息。如果认证成功，移动节点解密加密的家庭地址并将结果与真实家庭地址进行比较，或者将加密的家庭地址与存储在绑定更新列表条目中的家庭地址进行比较。如果它们匹配，则移动节点认为对应注册成功，并更新相应绑定更新列表条目的状态。如果它们不匹配，移动节点可以再次启动相应的绑定更新过程。
In order to maintain session continuity, upper layers of the IP stack in the mobile node still use the real home address, even after the reverse-tunneled correspondent registration.
为了保持会话连续性，移动节点中的IP堆栈的上层仍然使用真实的家庭地址，即使在反向隧道通信注册之后也是如此。
A possible way of implementation is as follows. When the Mobile IP sublayer at the mobile node receives a packet from the upper layer, the normal processing as specified in RFC 3775 is performed. Subsequently, the Home Address option is replaced with the Encrypted Home Address option carrying the encrypted home address stored in the corresponding Binding Update List entry, and then the mobile node forwards the packet to the correspondent node via the optimized route.
一种可能的实现方式如下。当移动节点处的移动IP子层从上层接收到分组时，执行RFC 3775中指定的正常处理。随后，将归属地址选项替换为携带存储在相应绑定更新列表条目中的加密归属地址的加密归属地址选项，然后移动节点经由优化路由将分组转发给对应节点。
On the other hand, when the mobile node receives a payload packet carrying the Encrypted Home Address routing header, the mobile node uses the encrypted home address (optionally together with the IP address of the correspondent node) to look up the Binding Update List. If an entry is found, the mobile node accepts this packet, replaces the Encrypted Home Address option with the Home Address option carrying the real home address, and continues with processing based on RFC 3775. If no entry is found, the mobile node silently drops the received packet.
另一方面，当移动节点接收到携带加密的归属地址路由报头的有效载荷分组时，移动节点使用加密的归属地址（可选地与对应节点的IP地址一起）来查找绑定更新列表。如果找到条目，则移动节点接受该分组，用携带真实家庭地址的家庭地址选项替换加密的家庭地址选项，并基于RFC 3775继续处理。如果找不到条目，移动节点会无声地丢弃接收到的数据包。
The mobile node may receive an ICMP Parameter Problem, Code 2, message forwarded by the home agent via the bidirectional tunnel, for example, when the correspondent node does not support the use of the Encrypted Home Address option. If such a message is received, the mobile node SHOULD not attempt to use the location privacy solution with the correspondent node. The mobile node may choose either not to communicate with the correspondent node, or to communicate without location privacy protection.
例如，当对应节点不支持使用加密的归属地址选项时，移动节点可接收归属代理经由双向隧道转发的ICMP参数问题（代码2）消息。如果接收到这样的消息，则移动节点不应尝试与对应节点一起使用位置隐私解决方案。移动节点可以选择不与对应节点通信，或者选择在没有位置隐私保护的情况下通信。
When the mobile node communicates with a correspondent node by using the encrypted home address, a Binding Error message with the Status field set as 1 (unknown binding for Home Address destination option) may be received by the mobile node if there is no valid Binding Cache entry established at the correspondent node. Note that we do not specify a new Status value to be used in this case because the implementation of the Binding Update List entry can contain an indication of whether an encrypted home address is currently used with the correspondent node. Upon receiving the Binding Error message, the mobile node can find out which encrypted home address is invalid by looking at the Home Address field of the Binding Error message. The mobile node may then perform the correspondent binding update procedure to establish a valid binding for the encrypted home address.
当移动节点通过使用加密的归属地址与对应节点通信时，如果在对应节点上没有建立有效的绑定缓存条目，则移动节点可以接收状态字段设置为1（归属地址目的地选项的未知绑定）的绑定错误消息。注意，在这种情况下，我们没有指定要使用的新状态值，因为绑定更新列表项的实现可以包含当前是否与对应节点一起使用加密的家庭地址的指示。在接收到绑定错误消息时，移动节点可以通过查看绑定错误消息的home address字段来找出哪个加密的home address无效。然后，移动节点可以执行相应的绑定更新过程，以建立加密家庭地址的有效绑定。
When the mobile node receives a Binding Refresh Request message sent from the correspondent node and forwarded by the home agent via the bidirectional tunnel, the mobile node needs to perform the correspondent binding update procedure to refresh the binding for the encrypted home address at the correspondent node.
当移动节点接收到从对应节点发送并由归属代理经由双向隧道转发的绑定刷新请求消息时，移动节点需要执行对应绑定更新过程以刷新对应节点处的加密归属地址的绑定。
With the solution described in this section (i.e., Section 5), there is no new home agent operation to be specified. That is, the home agent behaves based on RFC 3775 when processing signaling or data packets.
对于本节（即第5节）中描述的解决方案，不需要指定新的归属代理操作。即，当处理信令或数据分组时，归属代理基于RFC 3775进行行为。
The Binding Cache entry is extended with a new field to store the current encrypted home address used with a particular mobile node. The encrypted home address is stored when the correspondent node successfully processes a reverse-tunneled correspondent Binding Update message.
绑定缓存项使用新字段进行扩展，以存储特定移动节点使用的当前加密家庭地址。当对应节点成功处理反向隧道对应绑定更新消息时，存储加密的家庭地址。
Given that the encrypted home address is 128 bits long, it is expected that each encrypted home address or the combination of the care-of address and the encrypted home address stored in the Binding Cache entry is unique. Therefore, the correspondent node can use the encrypted home address (or use it together with the care-of address) as a primary key to look up the Binding Cache.
假设加密的家庭地址为128位长，则每个加密的家庭地址或托管地址与存储在绑定缓存项中的加密家庭地址的组合都是唯一的。因此，对应节点可以使用加密的家庭地址（或将其与转交地址一起使用）作为主键来查找绑定缓存。
5.5.2. Reverse-Tunneled Correspondent Binding Update from the Mobile Node
5.5.2. 来自移动节点的反向隧道对应绑定更新
When receiving a reverse-tunneled Binding Update message with the Encrypted Home Address option, if the correspondent node supports the location privacy solution, it verifies the message by using the same method as defined in RFC 3775. If this verification succeeds, the correspondent node generates Kpm and uses it to decrypt the encrypted home address, and compares the result with the source IP address. If they match, the correspondent node stores the encrypted home address in the corresponding Binding Cache entry.
当接收到带有加密家庭地址选项的反向隧道绑定更新消息时，如果对应节点支持位置隐私解决方案，则它将使用RFC 3775中定义的相同方法验证该消息。如果验证成功，对应节点将生成Kpm并使用它对加密的家庭地址进行解密，并将结果与源IP地址进行比较。如果它们匹配，对应节点将加密的家庭地址存储在相应的绑定缓存条目中。
5.5.3. Reverse-tunneled Correspondent Binding Acknowledgement to the Mobile Node
5.5.3. 对移动节点的反向隧道对应绑定确认
If an acknowledgement to the reverse-tunneled correspondent Binding Update message is requested by the mobile node, the correspondent node returns a Binding Acknowledgement message with the Encrypted Home Address routing header, if it supports the location privacy solution. The MAC in the Binding Acknowledgement message is generated in the same way as specified in RFC 3775 and does not cover the encrypted home address carried in the Encrypted Home Address routing header.
如果移动节点请求对反向隧道对应绑定更新消息的确认，则对应节点返回带有加密的归属地址路由报头的绑定确认消息（如果其支持位置隐私解决方案）。绑定确认消息中的MAC以RFC 3775中指定的相同方式生成，并且不覆盖加密的归属地址路由报头中携带的加密的归属地址。
In order to maintain session continuity, upper layers of the IP stack in the correspondent node still use the real home address, even after the reverse-tunneled correspondent registration.
为了保持会话连续性，对应节点中的IP堆栈的上层仍然使用真实的家庭地址，即使在反向隧道对应注册之后也是如此。
A possible way of implementation is as follows. When the IP layer at the correspondent node finishes processing the packet received from the upper layer based on RFC 3775, the Type 2 routing header together with the real home address therein is replaced with the Encrypted Home Address routing header with the encrypted home address found in the corresponding Binding Cache entry. Then, this packet is forwarded to the mobile node via the optimized route.
一种可能的实现方式如下。当对应节点处的IP层基于RFC 3775完成对从上层接收的分组的处理时，类型2路由报头连同其中的真实家庭地址一起被替换为具有在相应绑定缓存条目中找到的加密家庭地址的加密家庭地址路由报头。然后，该分组经由优化的路由转发到移动节点。
On the other hand, when the correspondent node receives a payload packet with the Encrypted Home Address option, it uses the encrypted home address (optionally together with the care-of address of the mobile node) to look up the Binding Cache. If there is an entry, the correspondent node replaces the Encrypted Home Address option with the Home Address option carrying the real home address before forwarding the packet to the upper layer. If no matching entry is found, the correspondent node sends a Binding Error message to the source IP address, i.e., the care-of address of the mobile node.
另一方面，当对应节点接收到具有加密的归属地址选项的有效载荷分组时，它使用加密的归属地址（可选地与移动节点的转交地址一起）来查找绑定高速缓存。如果存在条目，则对应节点在将数据包转发到上层之前，将加密的Home Address选项替换为携带真实Home Address的Home Address选项。如果未找到匹配条目，则对应节点向源IP地址（即移动节点的转交地址）发送绑定错误消息。
When receiving a reverse-tunneled correspondent Binding Update message with the Encrypted Home Address option, if the correspondent node does not support location privacy extensions, it sends an ICMP Parameter Problem, Code 2, message to the source IP address (i.e., the home address of the mobile node) and the home agent then forwards this ICMP message to the mobile node via the bidirectional tunnel.
当接收到带有加密家庭地址选项的反向隧道对应绑定更新消息时，如果对应节点不支持位置隐私扩展，它会向源IP地址（即移动节点的家庭地址）发送ICMP参数问题代码2消息然后，归属代理通过双向隧道将该ICMP消息转发给移动节点。
When the correspondent node receives a payload packet with the Encrypted Home Address option for which there is no valid Binding Cache entry, it returns a Binding Error message with the Status code set as 1 back to the source IP address of the packet. Furthermore, the Home Address field in the Binding Error message MUST be copied from the Encrypted Home Address field in the Encrypted Home Address destination option of the offending packet, or set to the unspecified address if no such option appears in the packet.
当对应节点接收到具有加密的Home Address选项且没有有效绑定缓存项的有效负载数据包时，它将状态代码设置为1的绑定错误消息返回到数据包的源IP地址。此外，绑定错误消息中的Home Address字段必须从违规数据包的加密Home Address destination选项中的加密Home Address字段复制，或者如果数据包中没有出现此类选项，则将其设置为未指定的地址。
When the correspondent node realizes that a Binding Cache entry is about to expire, it sends a Binding Refresh Request message to the real home address of the mobile node stored in the Binding Cache entry.
当对应节点意识到绑定缓存项即将过期时，它向存储在绑定缓存项中的移动节点的真实家庭地址发送绑定刷新请求消息。
With the solution in Section 5, the real home address is visible in the Binding Update and Binding Acknowledgement messages along the HA-CN path. Like Mobile IPv6 itself, it has not been designed to change the communications between the home network and the correspondent node; the same issues would affect non-mobile hosts as well. This solution meets all the requirements set forth for the location privacy solutions and provides a simple way to provide location privacy protection while allowing the use of the real home address with the correspondent node.
使用第5节中的解决方案，真实的家庭地址在绑定更新和绑定确认消息中沿HA-CN路径可见。与移动IPv6本身一样，它的设计目的不是改变家庭网络和对应节点之间的通信；同样的问题也会影响非移动主机。此解决方案满足位置隐私解决方案的所有要求，并提供了一种简单的方法来提供位置隐私保护，同时允许使用对应节点的真实家庭地址。
When the mobile node attaches to a foreign link, it first performs the home binding update procedure for the real home address with the home agent, as specified in RFC 3775. For hiding the real home address, we require the use of IPsec Encapsulating Security Payload (ESP) [3] in tunnel mode. In order to provide location privacy, a non-null encryption transform must be used so that the real home address is encrypted and encapsulated, and made invisible to eavesdroppers on the MN-HA path. The packet formats and processing rules are the same as specified in RFC 3775 and RFC 4877.
当移动节点连接到外部链路时，它首先与归属代理执行真实归属地址的归属绑定更新过程，如RFC 3775中所指定。为了隐藏真实的家庭地址，我们需要在隧道模式下使用IPsec封装安全有效负载（ESP）[3]。为了提供位置隐私，必须使用非空加密转换，以便对真实的家庭地址进行加密和封装，并使MN-HA路径上的窃听者不可见。数据包格式和处理规则与RFC 3775和RFC 4877中规定的相同。
To protect location privacy in the route optimization mode, the mobile node replaces the real home address used in certain signaling and payload packets with the pseudo home address. Different from the encrypted home address, the pseudo home address needs to be routable so that the home agent can intercept packets with the pseudo home address used as the destination address. The pseudo home address is generated by concatenating one of the home network prefixes with a random bit string. There are many ways to generate such a random bit string, for example, by using a random number generator or a secure encryption or hash algorithm.
为了在路由优化模式下保护位置隐私，移动节点将在某些信令和有效载荷分组中使用的真实归属地址替换为伪归属地址。与加密的家庭地址不同，伪家庭地址需要是可路由的，以便家庭代理可以截获使用伪家庭地址作为目标地址的数据包。伪家庭地址是通过将一个家庭网络前缀与一个随机位字符串连接而生成的。有许多方法可以生成这样的随机位字符串，例如，通过使用随机数生成器或安全加密或哈希算法。
Using the pseudo home address instead of the real home address even in return routability and binding update to the correspondent has the following advantages. First, the pseudo home address does not reveal the identity of a mobile node since it is not (or should not be) publicly known. Hence, the signaling on the HA-CN is path is more secure since attackers will not be able to determine the identity of the mobile node based on the pseudo home address. Second, the mobile
使用伪主地址而不是真实的主地址，即使是在向通信方返回路由性和绑定更新时，也具有以下优点。首先，伪家庭地址不显示移动节点的身份，因为它不是（或不应该）公众所知的。因此，HA-CN is路径上的信令更安全，因为攻击者将无法根据伪主地址确定移动节点的身份。第二，手机
node can communicate with a correspondent without disclosing its real home address. Finally, the chosen pseudo home address can be different with different correspondents for both signaling and data traffic purposes.
节点可以与通讯员通信，而无需透露其真实的家庭地址。最后，出于信令和数据通信的目的，所选择的伪主地址可以与不同的对应方不同。
The prefix used to form the pseudo home address MUST be managed by the same home agent so that it can forward the return routability messages. Even though it does not have to be the same as that used in the real home address, the prefix is highly recommended to be different. For instance, a home agent may use a different prefix pool for location privacy purposes for a set of mobile nodes. This ensures that the real home address and the pseudo home address are not co-related (assuming the mobile node chooses different interface identifiers (IIDs)).
用于形成伪主地址的前缀必须由同一个主代理管理，以便它可以转发返回的路由性消息。尽管它不必与实际家庭地址中使用的前缀相同，但强烈建议前缀不同。例如，归属代理可以为一组移动节点的位置隐私目的使用不同的前缀池。这确保真实归属地址和伪归属地址不相关（假设移动节点选择不同的接口标识符（iid））。
The mobile node MUST register the pseudo home address to be used with the home agent before actually using it with a correspondent node. To do so, the mobile node indicates a pseudo home address in the Pseudo Home Address mobility option in the Binding Update message sent to the home agent. If the home agent supports the location privacy solution, it performs the Duplicate Address Detection to detect whether this pseudo home address conflicts with other pseudo home addresses submitted from different mobile nodes. Based on the result, the home agent indicates whether to accept the pseudo home address by setting the appropriate status code in the Pseudo Home Address Acknowledgement option in the Binding Acknowledgement message. If the home agent prefers the use of a different home network prefix from that of the requested pseudo home address, the home agent returns the new pseudo home address in the Pseudo Home Address Acknowledgement mobility option to the mobile node.
移动节点必须先注册要与归属代理一起使用的伪归属地址，然后才能与对应节点一起实际使用它。为此，移动节点在发送给归属代理的绑定更新消息中的伪归属地址移动选项中指示伪归属地址。如果归属代理支持位置隐私解决方案，它将执行重复地址检测，以检测此伪归属地址是否与从不同移动节点提交的其他伪归属地址冲突。基于该结果，归属代理通过在绑定确认消息中的伪归属地址确认选项中设置适当的状态代码来指示是否接受伪归属地址。如果归属代理倾向于使用与所请求的伪归属地址不同的归属网络前缀，则归属代理将伪归属地址确认移动选项中的新伪归属地址返回给移动节点。
The mobile node MAY register the pseudo home address when it is about to communicate with a correspondent node with location privacy protection. The default lifetime of registered pseudo home addresses is the same as the Home Binding Cache entry; however, a mobile node may choose any value and a home agent may grant any value. The mobile node can add or delete any pseudo home address by using the Pseudo Home Address mobility option in the home Binding Update message. The home agent does not have to recover the real home address from the pseudo home address.
当移动节点即将与具有位置隐私保护的对应节点通信时，移动节点可以注册伪家庭地址。注册的伪主地址的默认生存期与主绑定缓存项相同；然而，移动节点可以选择任何值，并且归属代理可以授予任何值。移动节点可以通过使用归属绑定更新消息中的伪归属地址移动选项来添加或删除任何伪归属地址。归属代理不必从伪归属地址恢复真实的归属地址。
When the mobile node returns to its home link, the home de-registration procedure is the same as specified in RFC 3775, i.e., the real home address is used as the source IP address in the Binding
当移动节点返回其归属链路时，归属取消注册过程与RFC 3775中指定的相同，即，真实归属地址被用作绑定中的源IP地址
Update message and the destination IP address in the Binding Acknowledgement message. The de-registration of the real home address results in automatic de-registration of all pseudo home addresses. When the mobile node decides to disconnect from the home agent while at its foreign link, the format of the Binding Update and Acknowledgement is the same as that defined for the home registration, except that the Lifetime field is set to zero. The home agent deletes the corresponding Binding Cache entry including the registered pseudo home address, if any.
更新消息和绑定确认消息中的目标IP地址。真实家庭地址的注销会导致所有伪家庭地址的自动注销。当移动节点决定在其外部链路上断开与归属代理的连接时，绑定更新和确认的格式与为归属注册定义的格式相同，只是生存期字段设置为零。归属代理删除相应的绑定缓存项，包括注册的伪归属地址（如果有）。
The location privacy solution specified in this section does not introduce any change to the care-of address test procedure as specified in RFC 3775. In the following, we highlight the extensions to the home address test procedure, during which the mobile node obtains a home keygen token generated based on the pseudo home address.
本节中规定的位置隐私解决方案不会对RFC 3775中规定的转交地址测试程序进行任何更改。在下文中，我们重点介绍对归属地址测试过程的扩展，在此过程中，移动节点获得基于伪归属地址生成的归属密钥生成令牌。
The mobile node generates and sends a Home Test Init message to the home agent. The format of this message is:
移动节点生成并向归属代理发送归属测试初始消息。此消息的格式为：
IPv6 header (source = care-of address, destination = home agent) ESP header in tunnel mode IPv6 header (source = home address, destination = correspondent) Mobility Header (HoTI) Home Init Cookie Pseudo Home Address mobility option (pseudo home address)
IPv6报头（源=转交地址，目的地=归属代理）隧道模式下的ESP报头IPv6报头（源=归属地址，目的地=通讯者）移动报头（HoTI）home Init Cookie伪归属地址移动选项（伪归属地址）
The difference from what is specified in RFC 3775 is that the mobile node includes a Pseudo Home Address mobility option (see Section 7.3) in the Home Test Init message. A new option for carrying the pseudo home address is necessary because the security association between the mobile node and the home agent is based on the real home address. The pseudo home address contained in the Pseudo Home Address option is selected by the mobile node from a set of pseudo home addresses that have been registered with the home agent during the home registration procedure. Note that the Home Test Init message is protected by an IPsec security association in the ESP tunnel mode with a non-null encryption algorithm and a non-null authentication algorithm, as specified in RFC 3776.
与RFC 3775中规定的不同之处在于，移动节点在Home Test Init消息中包括伪归属地址移动选项（参见第7.3节）。由于移动节点和归属代理之间的安全关联基于真实的归属地址，因此有必要使用新的选项来携带伪归属地址。移动节点从在归属注册过程中已向归属代理注册的一组伪归属地址中选择包含在伪归属地址选项中的伪归属地址。请注意，Home Test Init消息由ESP隧道模式下的IPsec安全关联保护，该关联使用非空加密算法和非空身份验证算法，如RFC 3776中所述。
When receiving a Home Test Init message, the home agent performs the operation as specified in Section 6.6.4. If this operation succeeds when the Pseudo Home Address mobility option is present in the Home Test Init message, the home agent generates a Home Test Init message
当收到Home Test Init消息时，Home agent执行第6.6.4节中规定的操作。如果当Home Test Init消息中存在伪Home Address mobility选项时，此操作成功，则Home agent将生成Home Test Init消息
and forwards it to the correspondent node. As shown in the following, the pseudo home address carried in the Pseudo Home Address mobility option is used as the source IP address in the forwarded Home Test Init message.
并将其转发到对应节点。如下图所示，伪家庭地址移动选项中携带的伪家庭地址用作转发的家庭测试初始化消息中的源IP地址。
IPv6 header (source = pseudo home address, destination = correspondent) Mobility Header (HoTI) Home Init Cookie
IPv6头（源=伪主地址，目标=对应方）移动头（HoTI）主初始化Cookie
The forwarded Home Test Init message looks the same to the correspondent node as what is specified in RFC 3775 and the correspondent node does not realize that the pseudo home address is used, and just generates a home keygen token using the same algorithm as specified in RFC 3775.
转发的Home Test Init消息在对应节点看来与RFC 3775中指定的消息相同，并且对应节点没有意识到使用了伪Home地址，只是使用RFC 3775中指定的相同算法生成Home keygen令牌。
home keygen token = First (64, HMAC_SHA1 (Kcn, (pseudo home address | nonce | 0)))
home keygen令牌=第一个（64，HMAC|U SHA1（Kcn，（伪家庭地址| nonce | 0）））
The correspondent node then replies with a Home Test message. As shown in the following, the format of this message is the same as that specified in RFC 3776, and the pseudo home address is used as the destination IP address.
然后，通信节点用主测试消息进行回复。如下图所示，此消息的格式与RFC 3776中指定的格式相同，并且伪主地址用作目标IP地址。
IPv6 header (source = correspondent, destination = pseudo home address) Mobility Header (HoT) Home Init Cookie Home Keygen Token Home Nonce Index
IPv6报头（源=对应方，目标=伪主地址）移动报头（HoT）home Init Cookie home Keygen Token home Nonce Index
When the home agent intercepts the Home Test message using proxy Neighbor Discovery, it performs the operation as specified in Section 6.6.5. If this operation succeeds, the home agent generates the following Home Test message and forwards to the mobile node.
当归属代理使用代理邻居发现截获归属测试消息时，它将执行第6.6.5节中规定的操作。如果此操作成功，归属代理将生成以下归属测试消息并转发给移动节点。
IPv6 header (source = home agent, destination = care-of address) ESP header in tunnel mode IPv6 header (source = correspondent, destination = home address) Mobility Header (HoT) Home Init Cookie Home Keygen Token Home Nonce Index Pseudo Home Address Acknowledgement mobility option (pseudo home address)
IPv6标头（源=归属代理，目的地=转交地址）隧道模式中的ESP标头IPv6标头（源=对应方，目的地=归属地址）移动标头（热）home Init Cookie home Keygen令牌home Nonce Index伪归属地址确认移动选项（伪归属地址）
When the mobile node receives the Home Test message, it performs operation as specified in Section 6.5.5. If such operation succeeds, the mobile node obtains a home keygen token computed using the pseudo home address. After the care-of address test is completed, the mobile node hashes the care-of keygen token and the home keygen token together to generate Kbm using the same method as specified in RFC 3775.
当移动节点接收到归属测试消息时，它执行第6.5.5节中规定的操作。如果这样的操作成功，则移动节点获得使用伪归属地址计算的归属密钥生成令牌。在转交地址测试完成之后，移动节点使用RFC 3775中指定的相同方法将转交密钥根令牌和归属密钥根令牌散列在一起以生成Kbm。
In this procedure, the mobile node MUST use the same pseudo home address used during the home address test procedure. The pseudo home address is carried in the Home Address option in the correspondent Binding Update message.
在此过程中，移动节点必须使用在家庭地址测试过程中使用的相同伪家庭地址。在对应绑定更新消息的home address选项中携带伪home address。
IPv6 header (source = care-of address, destination = correspondent) Destination option header Home Address destination option (pseudo home address) Parameters: sequence number (within the Binding Update message header) home nonce index (within the Nonce Indices option) care-of nonce index (within the Nonce Indices option) First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BU)))
IPv6标头（源=转交地址，目的地=对应方）目的地选项标头家庭地址目的地选项（伪家庭地址）参数：序列号（在绑定更新消息标头内）家庭nonce索引（在nonce索引选项内）转交nonce索引（在nonce索引选项内）首先（96，HMAC_SHA1（Kbm，（转交地址|通讯员| BU）））
When the correspondent node receives the Binding Update message, it performs the same operation as specified in RFC 3775. If such operation succeeds and an acknowledgement is requested by the mobile node, the correspondent node replies with the following Binding Acknowledgement message.
当对应节点接收到绑定更新消息时，它执行RFC 3775中指定的相同操作。如果这样的操作成功并且移动节点请求确认，则对应节点用以下绑定确认消息进行应答。
IPv6 header (source = correspondent, destination = care-of address) Parameters: sequence number (within the Binding Update message header) First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BA)))
IPv6头（源=对应方，目的地=转交地址）参数：序列号（在绑定更新消息头中）第一（96，HMAC|U SHA1（Kbm，（转交地址|对应方| BA）））
After the mobile node receives the Binding Acknowledgement message indicating that the correspondent registration succeeds, the mobile node can now use the pseudo home address for communicating with the correspondent node.
在移动节点接收到指示对应注册成功的绑定确认消息之后，移动节点现在可以使用伪归属地址与对应节点通信。
Such a Binding Update message may also be used by the mobile node to delete a previously established binding at the correspondent node. In this case, similar to what is specified in RFC 3775, Kbm is generated exclusively from the home keygen token that is based on the pseudo home address.
这样的绑定更新消息还可被移动节点用于删除对应节点处先前建立的绑定。在这种情况下，与RFC 3775中指定的内容类似，Kbm仅从基于伪主地址的home keygen令牌生成。
The mobile node may choose to use reverse tunneling for sending the Binding Update. The format of messages during such a procedure is similar to what is described in Sections 5 and 6.2.1, except that a pseudo home address is used in place of the real home address. The Encrypted Home Address destination and the Encrypted Home Address routing header SHOULD be used to carry the encrypted pseudo home address.
移动节点可以选择使用反向隧道来发送绑定更新。该过程中的消息格式类似于第5节和第6.2.1节中所述，不同之处在于使用伪家庭地址代替真实家庭地址。应使用加密的家庭地址目的地和加密的家庭地址路由报头来携带加密的伪家庭地址。
6.2.4. Using Different Pseudo Home Addresses with Different Correspondent Nodes
6.2.4. 对不同的对应节点使用不同的伪主地址
Based on its configuration and policy, the mobile node can choose to use the same or different pseudo home addresses when communicating with different correspondent nodes. Using a different pseudo home address with each correspondent node may help prevent the mobile node's activities from being linked and correlated. To do so, the mobile node selects a different but already registered pseudo home address and repeats the return routability procedure and the correspondent binding update procedure with each correspondent node.
根据其配置和策略，移动节点在与不同的对应节点通信时可以选择使用相同或不同的伪家庭地址。对每个对应节点使用不同的伪主地址可能有助于防止移动节点的活动被链接和关联。为此，移动节点选择不同但已注册的伪家庭地址，并对每个对应节点重复返回路由性过程和对应绑定更新过程。
In addition, if the mobile node prefers, it MAY use different pseudo home addresses for different sessions with the same correspondent node. This typically requires additional configuration at the mobile node that associates a specific session (for example, identified by the port number and the protocol number, among others) with a specific pseudo home address. This document does not address details of this solution.
此外，如果移动节点更愿意，则它可以对具有相同对应节点的不同会话使用不同的伪归属地址。这通常需要移动节点上的附加配置，该配置将特定会话（例如，由端口号和协议号等标识）与特定伪主地址相关联。本文档不涉及此解决方案的详细信息。
The format of payload packets reverse-tunneled via the home agent is the same as that specified for the home address test procedure in Section 6.2.1.
通过归属代理反向隧道传输的有效负载数据包的格式与第6.2.1节中针对归属地址测试程序规定的格式相同。
When the route-optimized correspondent binding update procedure is performed, the format of payload packets exchanged between the mobile node and the correspondent node is the same as specified in RFC 3775. The operation of the mobile node when communicating with the correspondent node via the route optimization mode is described in Section 6.5.6.
当执行路由优化的对应绑定更新过程时，移动节点和对应节点之间交换的有效载荷分组的格式与RFC 3775中指定的相同。第6.5.6节描述了通过路由优化模式与对应节点通信时移动节点的操作。
When the reverse tunneled correspondent binding update procedure is performed, the format of payload packets exchanged between the mobile node and the correspondent node is the same as specified in Section 5, except that the encrypted pseudo home address SHOULD be included in the Encrypted Home Address destination option and the Encrypted Home Address routing header.
当执行反向隧道对应绑定更新过程时，移动节点和对应节点之间交换的有效载荷分组的格式与第5节中规定的相同，除了加密的伪家庭地址应包含在加密的家庭地址目标选项和加密的家庭地址路由标头中之外。
The solution to protect location privacy during the prefix discovery procedure is similar to that used during the home binding update procedure.
前缀发现过程中保护位置隐私的解决方案与主绑定更新过程中使用的解决方案类似。
In this section, we describe the mobile node's operation when the location privacy solution is used.
在本节中，我们将描述使用位置隐私解决方案时移动节点的操作。
We introduce a new data structure, called Pseudo Home Address table, to record the information of pseudo home addresses. The mobile node may maintain a Pseudo Home Address table for each home agent it registers with. Each entry in the table contains a pseudo home address and its associated state, i.e., "unconfirmed" or "confirmed". The mobile node creates or updates entries in the Pseudo Home Address table when sending the home Binding Update message or receiving the home Binding Acknowledgement message. The pseudo home address can be used as a key to search the table. There MUST NOT be any duplicated pseudo home addresses stored in the Pseudo Home Address table.
我们引入了一种新的数据结构，称为伪家庭地址表，用来记录伪家庭地址的信息。移动节点可以为其注册的每个归属代理维护伪归属地址表。表中的每个条目都包含一个伪家庭地址及其关联状态，即“未确认”或“已确认”。移动节点在发送归属绑定更新消息或接收归属绑定确认消息时创建或更新伪归属地址表中的条目。伪主地址可用作搜索表的键。伪家庭地址表中不得存储任何重复的伪家庭地址。
The Binding Update List entry is extended with a field, called Pseudo Home Address. This field MAY be implemented as a pointer that points to a corresponding entry in the Pseudo Home Address table. This pointer is initialized as NULL when the Binding Update List entry is
绑定更新列表项使用一个名为伪主地址的字段进行扩展。该字段可以实现为指向伪主地址表中相应项的指针。当绑定更新列表项为空时，此指针初始化为空
created (for example, when the mobile node sends a Binding Update message or a Home Test Init message to the home agent). For the binding sent to a specific home agent, the Pseudo Home Address field points to the first entry in the Pseudo Home Address table (or NULL if the table is empty), so that the mobile node can access all the pseudo home addresses registered at this home agent; on the other hand, for the binding sent to a specific correspondent node, the Pseudo Home Address field points to the Pseudo Home Address table entry that contains the actual pseudo home address used with this correspondent node (or NULL if no pseudo home address is used with this correspondent node).
创建（例如，当移动节点向归属代理发送绑定更新消息或归属测试初始化消息时）。对于发送到特定归属代理的绑定，伪归属地址字段指向伪归属地址表中的第一个条目（如果表为空，则为NULL），以便移动节点可以访问在该归属代理注册的所有伪归属地址；另一方面，对于发送到特定对应节点的绑定，伪Home Address字段指向包含与此对应节点一起使用的实际伪Home Address的伪Home Address表条目（如果没有与此对应节点一起使用伪Home Address，则为NULL）。
The mobile node may decide to perform the home registration with location privacy protection, for example, when it attaches to a foreign link or when it needs to extend the lifetime of a registered home binding.
例如，当移动节点连接到外部链路时或当移动节点需要延长注册的归属绑定的生存期时，移动节点可以决定执行具有位置隐私保护的归属注册。
Since IPsec tunnel mode is used, the mobile node MUST negotiate a non-null encryption algorithm (for example, during the bootstrapping) and use it to protect the home Binding Update message as specified in RFC 3775 and RFC 4877. In addition, the mobile node can register a pseudo home address as described above. If the mobile node does not wish to register the pseudo home address at this point, but wishes to discover whether the home agent supports the location privacy solution, the mobile node includes a Pseudo Home Address mobility option without the Pseudo Home Address field in the Binding Update message sent to the home agent.
由于使用IPsec隧道模式，移动节点必须协商非空加密算法（例如，在引导期间），并使用它来保护RFC 3775和RFC 4877中指定的主绑定更新消息。此外，移动节点可以如上所述注册伪家庭地址。如果移动节点此时不希望注册伪家庭地址，但希望发现归属代理是否支持位置隐私解决方案，则移动节点包括伪家庭地址移动选项，而不包括发送给归属代理的绑定更新消息中的伪家庭地址字段。
After sending the home de-registration binding update message, in addition to the operation specified in RFC 3775, the mobile node MUST stop using any data structure specific to the location privacy solution and MAY delete them after the Binding Acknowledgement message is processed successfully.
在发送归属取消注册绑定更新消息之后，除了RFC 3775中指定的操作之外，移动节点必须停止使用特定于位置隐私解决方案的任何数据结构，并且可以在绑定确认消息成功处理之后删除它们。
With IPsec tunnel mode, the mobile node follows the rules specified in RFC 3775 and RFC 4877 to process the Binding Acknowledgement message.
在IPsec隧道模式下，移动节点遵循RFC 3775和RFC 4877中指定的规则来处理绑定确认消息。
In addition, if one or more Pseudo Home Address Acknowledgement mobility options are present in the Binding Acknowledgement message, the mobile node checks the Status field in each option. If the Status field in one option is 0 (Success), the pseudo home address, if not already present, is added into the Pseudo Home Address table, and the state of the corresponding entry is set to "confirmed".
此外，如果绑定确认消息中存在一个或多个伪归属地址确认移动选项，则移动节点检查每个选项中的状态字段。如果一个选项中的状态字段为0（成功），则伪家庭地址（如果尚未存在）将添加到伪家庭地址表中，并且相应条目的状态设置为“已确认”。
Otherwise, the mobile node deletes any existing pseudo home address with the "unconfirmed" state (i.e., either an error code or no acknowledgement for such a pseudo home address is received) from the Pseudo Home Address table.
否则，移动节点从伪家庭地址表中删除具有“未确认”状态的任何现有伪家庭地址（即，错误代码或未接收到对此类伪家庭地址的确认）。
The mobile node considers that the home agent supports the location privacy solution, if a valid Pseudo Home Address Acknowledgement mobility option with or without a Pseudo Home Address field is received.
如果接收到带有或不带有伪家庭地址字段的有效伪家庭地址确认移动选项，则移动节点认为家庭代理支持位置隐私解决方案。
Note that the mobile node MUST determine whether the home registration succeeds or not based on what is specified RFC 3775.
注意，移动节点必须基于指定的RFC 3775来确定归属注册是否成功。
To enable location privacy protection during communication with the correspondent node in the route optimization mode, the mobile node generates a Home Test Init message based on what is specified in RFC 3775 and RFC 3776. In addition, if the return routability procedure is for a new session with the correspondent node, the mobile node selects any pseudo home address from those already registered with the home agent and stored in the Pseudo Home Address table; otherwise, the mobile node must use the same pseudo home address as used with the same correspondent node before. The selected pseudo home address is carried in the Pseudo Home Address mobility option of the generated Home Test Init message. This Home Test Init message is protected by an IPsec security association with a non-null encryption algorithm.
为了在路由优化模式下与对应节点通信期间启用位置隐私保护，移动节点基于RFC 3775和RFC 3776中指定的内容生成Home Test Init消息。此外，如果返回路由性过程用于与对应节点的新会话，则移动节点从已经向归属代理注册并存储在伪归属地址表中的伪归属地址中选择任何伪归属地址；否则，移动节点必须使用与之前同一对应节点使用的相同的伪主地址。所选的伪家庭地址携带在生成的home Test Init消息的伪家庭地址移动选项中。此Home Test Init消息受IPsec安全关联和非空加密算法的保护。
After sending the Home Test Init message to the home agent, if there is no Binding Update List entry existing for the correspondent node, the mobile node creates one entry that points to the pseudo home address used; otherwise, the mobile node updates the existing entry.
在将Home Test Init消息发送给归属代理之后，如果对应节点不存在绑定更新列表条目，则移动节点创建一个指向所使用的伪归属地址的条目；否则，移动节点将更新现有条目。
When the mobile node receives a Home Test message from the home agent, it processes the packet based on processing rules specified in RFC 3775 and RFC 3776. If this is a valid packet and there is a Pseudo Home Address Acknowledgement option included, the mobile node examines the Status field inside this mobility option as follows:
当移动节点从归属代理接收到归属测试消息时，它基于RFC 3775和RFC 3776中指定的处理规则来处理分组。如果这是一个有效分组，并且包含一个伪家庭地址确认选项，则移动节点检查该移动选项内的状态字段，如下所示：
o If the Status field indicates that the home address test procedure using the pseudo home address succeeds (the Status field is 0), in addition to what is specified in RFC 3775, the mobile node prepares to use the pseudo home address carried in the Pseudo Home Address Acknowledgement option for the correspondent registration.
o 如果状态字段指示使用伪家庭地址的家庭地址测试过程成功（状态字段为0），则除了RFC 3775中指定的内容外，移动节点还准备使用伪家庭地址确认选项中携带的伪家庭地址进行对应注册。
o If the Status field indicates that the home address test procedure using the pseudo home address fails (the Status field is larger than 127), the mobile node can take steps to correct the cause of the error and retransmit the Home Test Init message, subject to the retransmission limit specified in RFC 3775. If this is not done or it fails, then the mobile node SHOULD record in its Binding Update List that the future home address test procedure SHOULD NOT use the pseudo home address with this correspondent node.
o 如果状态字段指示使用伪归属地址的归属地址测试过程失败（状态字段大于127），则移动节点可以采取步骤纠正错误原因并根据RFC 3775中指定的重传限制重传归属测试初始消息。如果未完成此操作或失败，则移动节点应在其绑定更新列表中记录，未来的归属地址测试过程不应使用此对应节点的伪归属地址。
After the mobile node completes the route-optimized correspondent registration procedure using the pseudo home address, payload packets are sent to the correspondent node with the pseudo home address in the Home Address destination option.
在移动节点使用伪主地址完成路由优化的对应注册过程之后，有效负载分组被发送到对应节点，并在主地址目的地选项中使用伪主地址。
The packet processing rules when sending and receiving route-optimized packets are the same as in RFC 3775 except that pseudo home addresses are used. In addition, if encrypted pseudo home addresses are used, both the mobile node and the correspondent node need to replace the encrypted address with the pseudo home address before passing them to the upper layers.
发送和接收路由优化数据包时的数据包处理规则与RFC 3775中的相同，只是使用了伪主地址。此外，如果使用加密的伪家庭地址，则移动节点和对应节点都需要在将其传递到上层之前用伪家庭地址替换加密的地址。
In the case that the mobile node masks the pseudo home address and uses the reverse-tunneled correspondent binding update procedure, the mobile node performs the operation specified in Section 5.3.4, except that the pseudo home address rather than the real home address is expected.
在移动节点屏蔽伪家庭地址并使用反向隧道对应绑定更新程序的情况下，移动节点执行第5.3.4节中规定的操作，但预期的是伪家庭地址而不是真实家庭地址。
When the Mobile Node receives a Binding Refresh Request message from a correspondent node, the destination IP address may be the pseudo home address. In this case, the mobile node needs to check the corresponding Binding Update List entry for the correspondent node. If the pseudo home address is invalid, the mobile node silently discards this message. Otherwise, the mobile node refreshes the binding with the correspondent node by using the same pseudo home address.
当移动节点从对应节点接收绑定刷新请求消息时，目的地IP地址可以是伪归属地址。在这种情况下，移动节点需要检查对应节点的相应绑定更新列表条目。如果伪主地址无效，移动节点将自动丢弃此消息。否则，移动节点通过使用相同的伪主地址刷新与对应节点的绑定。
In this section, we describe the home agent's operation when the location privacy solution is used.
在本节中，我们将描述使用位置隐私解决方案时归属代理的操作。
The Binding Cache entry is extended with a field that points to a list of currently accepted pseudo home addresses. Note that each registered pseudo home address MUST be unique and all the registered pseudo home addresses SHOULD be organized in such a way that the associated Binding Cache entry can be quickly located when a pseudo home address is used as the key to look up the Binding Cache.
绑定缓存项使用一个字段进行扩展，该字段指向当前接受的伪主地址列表。请注意，每个注册的伪主地址必须是唯一的，并且所有注册的伪主地址的组织方式应确保当伪主地址用作查找绑定缓存的密钥时，可以快速找到关联的绑定缓存项。
If the received Binding Update message contains one or more Pseudo Home Address mobility options, the home agent MUST ignore such an option if it does not recognize it. If the home agent recognizes such an option, a Pseudo Home Address Acknowledgement mobility option is generated and some fields therein are set as follows:
如果接收到的绑定更新消息包含一个或多个伪主地址移动选项，则如果主代理无法识别该选项，则必须忽略该选项。如果归属代理识别出这样的选项，则生成伪归属地址确认移动选项，其中的一些字段设置如下：
o If the Pseudo Home Address field received is empty, the Status field is set to 0 (Success), and the Pseudo Home Address field is empty.
o 如果收到的伪家庭地址字段为空，则状态字段设置为0（成功），并且伪家庭地址字段为空。
o If the Pseudo Home Address field received is set to all zero, the Status field is set is 0 (Success), and a pseudo home address SHOULD be included in the Pseudo Home Address field, if the home agent supports the dynamic pseudo home address assignment; otherwise, the Status field is set to 132 (Dynamic pseudo home address assignment not available) and the Pseudo Home Address field is empty.
o 如果接收到的伪家庭地址字段全部设置为零，则状态字段设置为0（成功），并且如果家庭代理支持动态伪家庭地址分配，则伪家庭地址字段中应包含一个伪家庭地址；否则，状态字段设置为132（动态伪家庭地址分配不可用），并且伪家庭地址字段为空。
o The Pseudo Home Address field received may contain an IPv6 address. If the format of such an IP address is incorrect, the Status field is set to 130 (Incorrect pseudo home address). If such an IP address is invalid, for example, the prefix is not a valid home network prefix or this is detected as a duplicated IP address, the Status field is set to 131 (Invalid pseudo home address). In both cases, the Pseudo Home Address field is empty. If the home agent suggests a different pseudo home address, the Status field is set to 0 (Success), and the new pseudo home address is included in the Pseudo Home Address field. Otherwise, if the home agent accepts the requested pseudo home address, the Status field is set as 0 (Success), and the same IP address is included in the Pseudo Home Address field.
o 接收到的伪家庭地址字段可能包含IPv6地址。如果此类IP地址的格式不正确，则状态字段设置为130（不正确的伪主地址）。如果这样的IP地址无效，例如，该前缀不是有效的家庭网络前缀，或者该前缀被检测为重复的IP地址，则状态字段被设置为131（无效的伪家庭地址）。在这两种情况下，伪家庭地址字段均为空。如果归属代理建议不同的伪归属地址，则状态字段设置为0（成功），并且新的伪归属地址包含在伪归属地址字段中。否则，如果归属代理接受请求的伪归属地址，则状态字段设置为0（成功），并且相同的IP地址包含在伪归属地址字段中。
o If the home agent does not allow the mobile node to use the pseudo home address with the correspondent node, the Status field SHOULD be set as 129 (Administratively prohibited) and the Pseudo Home Address field is empty.
o 如果归属代理不允许移动节点与对应节点一起使用伪归属地址，则状态字段应设置为129（管理禁止），并且伪归属地址字段为空。
o In case that the home agent does not accept the Pseudo Home Address mobility option for all other reasons, the Status field SHOULD be set as 128 (Failure, reason unspecified) and the Pseudo Home Address is empty.
o 如果归属代理出于所有其他原因不接受伪归属地址移动选项，则状态字段应设置为128（失败，原因未指定），并且伪归属地址为空。
When receiving a Binding Update message protected with the IPsec tunnel mode, the home agent performs the operation specified in RFC 4877.
当接收到受IPsec隧道模式保护的绑定更新消息时，归属代理将执行RFC 4877中指定的操作。
When receiving and successfully processing a Binding Update message for de-registration from the mobile node, in addition to what is specified in RFC 3775, the home agent MUST delete data structures related to the location privacy extension.
当从移动节点接收并成功处理用于注销的绑定更新消息时，除了RFC 3775中指定的内容外，归属代理还必须删除与位置隐私扩展相关的数据结构。
When sending a Binding Acknowledgement message protected with the IPsec tunnel mode, the home agent performs the operation specified in RFC 4877.
当发送受IPsec隧道模式保护的绑定确认消息时，归属代理执行RFC 4877中指定的操作。
The processing rules related to the Pseudo Home Address Acknowledgement mobility option are described in Section 6.6.2.
第6.6.2节描述了与伪家庭地址确认移动选项相关的处理规则。
When receiving a Home Test Init message from the mobile node, the home agent first verifies this message based on the IPsec processing rules as specified in RFC 3776. If the verification fails, the home agent acts based on such IPsec processing rules. Otherwise, if the Pseudo Home Address option does not exist in the Home Test Init message, the home agent performs the operation as specified in RFC 3775. Otherwise, the following operation is performed.
当从移动节点接收Home Test Init消息时，归属代理首先根据RFC 3776中指定的IPsec处理规则验证该消息。如果验证失败，归属代理将根据此类IPsec处理规则进行操作。否则，如果Home Test Init消息中不存在Pseudo Home Address选项，则归属代理将执行RFC 3775中指定的操作。否则，执行以下操作。
1. The home agent looks up its Binding Cache by using the real home address as a key. If the pseudo home address carried in the Pseudo Home Address option does not match any pseudo home address associated with the corresponding Binding Cache entry (including when the Pseudo Home Address field is set as zero), it MUST reject the Home Test Init message by sending back a Home Test message including the Pseudo Home Address Acknowledgement option with the Status field set as 131 (Invalid pseudo home address).
1. 归属代理使用真实的归属地址作为密钥来查找其绑定缓存。如果pseudo home address选项中携带的pseudo home address与对应绑定缓存项关联的任何pseudo home address不匹配（包括pseudo home address字段设置为零时），它必须通过发送回包含伪主地址确认选项且状态字段设置为131（无效伪主地址）的主测试消息来拒绝主测试初始化消息。
2. Otherwise, the home agent constructs a Home Test Init message with the pseudo home address as the source IP address, and forwards the Home Test Init message to the correspondent node.
2. 否则，归属代理构造一个以伪归属地址作为源IP地址的归属测试初始化消息，并将归属测试初始化消息转发给对应节点。
When the home agent intercepts a Home Test message using proxy Neighbor Discovery, if the destination IP address matches with one of the real home addresses, the home agent performs the operation as specified in RFC 3775. Otherwise, the home agent uses the destination IP address to look up the Binding Cache to find if there is a matched pseudo home addresses. If not, the home agent discards this message silently. When a matching pseudo home address is found, the home agent generates a Home Test message with a Pseudo Home Address Acknowledgement option and sends it to the mobile node. Inside the Pseudo Home Address Acknowledgement option, the Status field is set to zero (Success) and the Pseudo Home Address field is filled with the found pseudo home address.
当归属代理使用代理邻居发现截获归属测试消息时，如果目标IP地址与真实归属地址之一匹配，则归属代理执行RFC 3775中指定的操作。否则，归属代理将使用目标IP地址查找绑定缓存，以查找是否存在匹配的伪归属地址。否则，归属代理将以静默方式丢弃此消息。当找到匹配的伪归属地址时，归属代理生成具有伪归属地址确认选项的归属测试消息，并将其发送到移动节点。在Pseudo Home Address确认选项中，Status字段设置为零（Success），Pseudo Home Address字段填充找到的Pseudo Home Address。
With the solution described in this section, when the correspondent node is involved in the route-optimized correspondent binding update procedure, there is no new operation if only pseudo home addresses are used without encryption. This specification recommends using encrypted pseudo home addresses to thwart revealing any prefix information about a mobile node. The additional operations are the same as specified in Section 5.5, except that the pseudo home address, instead of the real home address, is used.
使用本节中描述的解决方案，当对应节点参与路由优化的对应绑定更新过程时，如果只使用伪主地址而不加密，则不会有新的操作。本规范建议使用加密的伪家庭地址来阻止透露有关移动节点的任何前缀信息。附加操作与第5.5节中规定的相同，只是使用了伪家庭地址，而不是实际家庭地址。
This section describes the experimental extensions to Mobile IPv6 used in this document. For experimentation purposes, the experimental IPv6 Option Type, the experimental IPv6 Routing Header Type, and the experimental Mobility Option Type as defined in RFC 4727 [12] and RFC 5096 [13] can be used in the Encrypted Home Address destination option, the Encrypted Home Address routing header, the Pseudo Home Address mobility option, and the Pseudo Home Address Acknowledgement mobility option. In the following, we describe the format of each extension for illustration purpose.
本节介绍本文档中使用的对移动IPv6的实验性扩展。出于实验目的，RFC 4727[12]和RFC 5096[13]中定义的实验IPv6选项类型、实验IPv6路由报头类型和实验移动性选项类型可用于加密的家庭地址目的地选项、加密的家庭地址路由报头、伪家庭地址移动性选项，以及伪家庭地址确认移动选项。在下文中，我们将描述每个扩展的格式，以便于说明。
This option is used in the Destination Option extension header (Next Header value = 60).
此选项用于目标选项扩展标头（下一个标头值=60）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Encrypted Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Encrypted Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
选项类型
A type for identifying the use of the encrypted home address in this option. Implementations of this RFC can use the value 0xFE. This value is reserved in RFC 4727 for all experiments involving IPv6 destination options.
用于标识此选项中加密家庭地址的使用的类型。此RFC的实现可以使用值0xFE。RFC 4727中为所有涉及IPv6目标选项的实验保留了该值。
Encrypted Home Address
加密家庭地址
The encrypted home address generated from a either real or pseudo home address.
从真实或伪家庭地址生成的加密家庭地址。
The processing of other fields in the Encrypted Home Address option is the same as that of those fields in the Home Address option described in RFC 3775. Note that if the Encrypted Home Address option is present in a packet, the encrypted home address therein MUST NOT be treated as the real source IP address by the receiver.
加密家庭地址选项中的其他字段的处理与RFC 3775中描述的家庭地址选项中的那些字段的处理相同。注意，如果分组中存在加密的家庭地址选项，则接收机不得将其中的加密家庭地址视为真实源IP地址。
The encrypted home address is carried in this routing header.
加密的家庭地址携带在此路由标头中。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=2 | Routing Type |Segments Left=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Encrypted Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=2 | Routing Type |Segments Left=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Encrypted Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Type
路由类型
A type for identifying the use of the encrypted home address in this option. Implementations of this RFC can use the value 0xFE. This value is reserved in RFC 4727 for all experiments involving IPv6 routing header.
用于标识此选项中加密家庭地址的使用的类型。此RFC的实现可以使用值0xFE。RFC 4727中为所有涉及IPv6路由头的实验保留了该值。
Encrypted Home Address
加密家庭地址
The encrypted home address generated from a either real or pseudo home address.
从真实或伪家庭地址生成的加密家庭地址。
The processing of other fields in the Encrypted Home Address routing header is the same as described in RFC 3775. Note that if this routing header is present in a packet, the encrypted home address therein MUST NOT be treated as the real destination IP address by the receiver.
加密的家庭地址路由报头中的其他字段的处理与RFC 3775中描述的相同。注意，如果该路由报头存在于分组中，则接收机不得将其中的加密家庭地址视为真实目的地IP地址。
This mobility option is included in the mobility header, including the Binding Update message and the Home Test Init message, and carries zero or one pseudo home address. The alignment requirement for this option is 4n.
该移动性选项包括在移动性报头中，包括绑定更新消息和Home Test Init消息，并携带零个或一个伪Home地址。该选项的对齐要求为4n。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |A| Reserved | Prefix length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Pseudo Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |A| Reserved | Prefix length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Pseudo Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
A unique type (together with the 'A' bit in the Reserved field) for identifying the Pseudo Home Address Acknowledgement mobility option. For experimental purpose, the value of this type is 18 as reserved in RFC 5096.
用于标识伪家庭地址确认移动选项的唯一类型（与保留字段中的“A”位一起）。出于实验目的，RFC 5096中保留的该类型的值为18。
Length
长
The length of the Pseudo Home Address mobility option excluding the Type field and the Length field. It MUST be 2 when the Pseudo Home Address field is not present; otherwise, it MUST be 18.
伪主地址移动选项的长度，不包括类型字段和长度字段。当伪家庭地址字段不存在时，它必须为2；否则，它必须是18。
Reserved Field
保留字段
The 'A' bit, which MUST be set to zero to indicate that this is a Pseudo Home Address mobility option. The rest of bits MUST be set as zero by the sender and ignored by the receiver.
“A”位，必须设置为零，以表明这是一个伪家庭地址移动选项。其余的位必须由发送方设置为零，由接收方忽略。
Prefix Length
前缀长度
The length of the home network prefix of the included pseudo home address. When the Pseudo Home Address field is not present, the Prefix Length field MUST be set as zero.
包含的伪家庭地址的家庭网络前缀的长度。当伪家庭地址字段不存在时，前缀长度字段必须设置为零。
Pseudo Home Address
伪家庭地址
If present, the field contains a pseudo home address that the mobile node wants to use for location privacy protection or zero if the mobile node requests a pseudo home address from the home agent. This field is not present if the mobile node only intends to discover whether the home agent supports the location privacy solutions. The Length field is used to detect whether the Pseudo Home Address field is present in the Pseudo Home Address mobility option.
如果存在，则该字段包含移动节点希望用于位置隐私保护的伪家庭地址，如果移动节点从家庭代理请求伪家庭地址，则该字段为零。如果移动节点仅打算发现归属代理是否支持位置隐私解决方案，则此字段不存在。长度字段用于检测伪主地址字段是否存在于伪主地址移动选项中。
This mobility option is included in the mobility header, including the Binding Acknowledgement message and the Home Test message sent to the mobile node, and carries zero or one pseudo home address. This mobility option is used to indicate the status of the pseudo home address registration and/or whether the home agent supports the location privacy solutions. The alignment requirement for this option is 2n.
该移动性选项包括在移动性报头中，包括发送到移动节点的绑定确认消息和归属测试消息，并且携带零个或一个伪归属地址。此移动选项用于指示伪家庭地址注册的状态和/或家庭代理是否支持位置隐私解决方案。该选项的对齐要求为2n。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | Prefix length | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Pseudo Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | Prefix length | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Pseudo Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
A unique type (together with the 'A' bit in the Reserved field) for identifying the Pseudo Home Address Acknowledgement mobility option. For experimental purpose, the value of this type is 18 as reserved in RFC 5096.
用于标识伪家庭地址确认移动选项的唯一类型（与保留字段中的“A”位一起）。出于实验目的，RFC 5096中保留的该类型的值为18。
Length
长
The length of the Pseudo Home Address Acknowledgement mobility option excluding the Type field and the Length field. It MUST be 4 when the Pseudo Home Address field is not present; otherwise, it MUST be 20.
伪家庭地址确认移动选项的长度，不包括类型字段和长度字段。当伪家庭地址字段不存在时，它必须为4；否则，它必须是20。
Reserved
含蓄的
The 'A' bit, which MUST be set to one to indicate that this is a Pseudo Home Address Acknowledgement mobility option. The rest of bits MUST be set as zero by the sender and ignored by the receiver.
“A”位，必须设置为1，以指示这是一个伪家庭地址确认移动选项。其余的位必须由发送方设置为零，由接收方忽略。
Prefix Length
前缀长度
The length of the home network prefix of the included pseudo home address. When the Pseudo Home Address field is not present, the Prefix Length MUST be set as zero.
包含的伪家庭地址的家庭网络前缀的长度。当伪家庭地址字段不存在时，前缀长度必须设置为零。
Status
地位
It indicates the status of the pseudo home address registration. Values from 0 to 127 indicate success. Higher values indicate failure. The following values are reserved:
它指示伪家庭地址注册的状态。从0到127的值表示成功。较高的值表示失败。保留以下值：
0 Success 128 Failure, reason unspecified 129 Administratively prohibited 130 Incorrect pseudo home address 131 Invalid pseudo home address 132 Dynamic pseudo home address assignment not available
0成功128失败，原因不明129管理禁止130错误的伪主地址131无效的伪主地址132动态伪主地址分配不可用
Reserved
含蓄的
This field is reserved for future use. It MUST be set to zero by the sender and ignored by the receiver.
此字段保留供将来使用。发送方必须将其设置为零，接收方必须忽略它。
Pseudo Home Address
伪家庭地址
If present, the field contains a pseudo home address that the home agent registers for the mobile node to use for location privacy protection. This field is not present when the home agent only needs to indicate that it supports the location privacy solutions as a response to the query from the mobile node. The Length field is used to detect whether the Pseudo Home Address field is present in the Pseudo Home Address Acknowledgement mobility option.
如果存在，则该字段包含归属代理为移动节点注册以用于位置隐私保护的伪归属地址。当归属代理仅需要指示其支持位置隐私解决方案作为对来自移动节点的查询的响应时，此字段不存在。长度字段用于检测伪家庭地址字段是否存在于伪家庭地址确认移动选项中。
The solutions proposed in this document address one of the security issues in the mobile environment, i.e., location privacy. Throughout the document, we provide a detailed analysis of how the proposed solutions address the location privacy problem. We carefully design such solutions to make sure that they fit well into the Mobile IPv6 framework; therefore, the same threat analysis, security mechanisms (such as IPsec, the sequence number in binding signaling messages, the return routability procedure), and considerations as described in RFC 3775 still apply. Nevertheless, in the following we provide an in-depth analysis on security threats involving the use of the location privacy solutions and demonstrate that the proposed solutions do not introduce any new vulnerability or weaken the strength of security protection of the original Mobile IPv6 protocol.
本文档中提出的解决方案解决了移动环境中的一个安全问题，即位置隐私。在整个文档中，我们详细分析了建议的解决方案如何解决位置隐私问题。我们仔细设计这些解决方案，以确保它们能够很好地适应移动IPv6框架；因此，RFC 3775中描述的相同威胁分析、安全机制（如IPsec、绑定信令消息中的序列号、返回可路由性过程）和注意事项仍然适用。尽管如此，在下文中，我们对涉及使用位置隐私解决方案的安全威胁进行了深入分析，并证明建议的解决方案不会引入任何新的漏洞或削弱原始移动IPv6协议的安全保护强度。
Given the strong security of the cryptography algorithm used to generate the encrypted home address, eavesdroppers are unable to derive the real home address from the encrypted home address and thus to correlate the care-of address with the real home address. Moreover, the encrypted home address can be updated to prevent eavesdroppers from linking the mobile node's ongoing activities.
由于用于生成加密家庭地址的加密算法具有很强的安全性，窃听者无法从加密家庭地址导出真实家庭地址，从而将转交地址与真实家庭地址关联起来。此外，可以更新加密的家庭地址，以防止窃听者链接移动节点正在进行的活动。
During the pseudo home address registration, the home agent verifies that the requested pseudo home address is not in use by other mobile nodes; therefore, the other mobile node cannot, inadvertently or maliciously, intercept ongoing sessions of a victim mobile node by registering the same pseudo home address.
在伪归属地址注册期间，归属代理验证所请求的伪归属地址未被其他移动节点使用；因此，另一移动节点不能通过注册相同的伪主地址来无意或恶意地拦截受害者移动节点的正在进行的会话。
A mobile node may attempt to register a large number of pseudo home addresses that may exhaust the pool of available pseudo home addresses and prevent other mobile nodes using location privacy protection. The home agent MUST limit the number of pseudo home addresses that can be requested by a mobile node. Also, with the IPsec security association between the home agent and the mobile node, if any misuse of the pseudo home address registration is detected, the home agent can identify the malicious mobile node and take further actions.
移动节点可尝试注册大量伪家庭地址，其可耗尽可用伪家庭地址池并防止其他移动节点使用位置隐私保护。归属代理必须限制移动节点可以请求的伪归属地址的数量。此外，利用归属代理和移动节点之间的IPsec安全关联，如果检测到任何对伪归属地址注册的滥用，归属代理可以识别恶意移动节点并采取进一步的行动。
The return routability procedure using the pseudo home address follows the same principle of the original return routability procedure, i.e., the message exchange verifies that the mobile node is reachable at both the pseudo home address and the care-of address (this is because the pseudo home address is required to be routable). Furthermore, the extended return routability procedure also utilizes the same security mechanisms as defined in RFC 3775, such as the nonce, the node key, and the sequence number, to protect against attacks. Overall, it provides the same security strength as the original return routability procedure.
使用伪归属地址的返回路由性过程遵循与原始返回路由性过程相同的原则，即，消息交换验证移动节点在伪归属地址和转交地址处都是可到达的（这是因为伪归属地址需要是可路由的）。此外，扩展返回可路由性过程还利用RFC 3775中定义的相同安全机制，例如nonce、节点密钥和序列号，以防止攻击。总的来说，它提供了与原始返回可路由性程序相同的安全强度。
The reverse-tunneled correspondent binding update procedure does not weaken security either. Although the real home address is transferred in cleartext on the HA-CN path, eavesdroppers on this path can already perform more serious attacks against the mobile node with the Mobile IPv6 protocol.
反向隧道对应绑定更新过程也不会削弱安全性。虽然真实的家庭地址在HA-CN路径上以明文形式传输，但此路径上的窃听者已经可以使用移动IPv6协议对移动节点执行更严重的攻击。
Using the Encrypted Home Address option in route-optimized packets results in the same security implications when the Home Address option is used in such packets. For example, the Encrypted Home Address option may be used by attackers to launch reflection attacks, e.g., by indicating the IP address of a victim node in the Encrypted Home Address option. Similar to the processing rule for the Home Address option specified in RFC 3775, this document restricts the use of the Encrypted Home Address option: it can be used only if there is an established Binding Cache entry containing the encrypted (pseudo) home address.
在路由优化的数据包中使用加密的Home Address选项会在此类数据包中使用Home Address选项时产生相同的安全影响。例如，攻击者可以使用加密的家庭地址选项来发起反射攻击，例如，通过在加密的家庭地址选项中指示受害者节点的IP地址。与RFC 3775中指定的Home Address选项的处理规则类似，本文档限制使用加密的Home Address选项：仅当存在已建立的包含加密（伪）Home Address的绑定缓存项时，才能使用该选项。
With the proposed location privacy solutions, the Encrypted Home Address routing header is used to carry the encrypted (pseudo) home address. The same threats specified in RFC 3775 for the Type 2 routing header are also possible when the routing header carries the encrypted (pseudo) home address. Similar processing rules are also used in this document to address such a threat: if the encrypted (pseudo) home address in the Encrypted Home Address routing header does not match with that stored in the Binding Update List entry, the packet will be dropped.
在建议的位置隐私解决方案中，加密的家庭地址路由报头用于携带加密（伪）家庭地址。当路由报头携带加密（伪）家庭地址时，RFC 3775中为类型2路由报头指定的相同威胁也可能存在。本文档中还使用了类似的处理规则来解决此类威胁：如果加密的家庭地址路由报头中的加密（伪）家庭地址与绑定更新列表条目中存储的地址不匹配，则数据包将被丢弃。
Our work benefits from previous work and discussion on this topic. Similar to the concept of the pseudo home address, many documents have proposed using a temporary identity to replace the mobile node's home address in the IPsec security association, Mobile IPv6 signaling messages, and data packets. However, the details of how to generate and update this identity are absent. In the following, we provide a survey of related work.
我们的工作得益于以前关于这个主题的工作和讨论。与伪家庭地址的概念类似，许多文档都建议使用临时身份来替换IPsec安全关联中移动节点的家庭地址、移动IPv6信令消息和数据包。但是，关于如何生成和更新此标识的详细信息不存在。下面，我们将对相关工作进行调查。
RFC 4941 [10] specifies a mechanism to generate randomized interface identifiers, which can be used to update the care-of address and the home address. However, with our solution, the prefix of a pseudo home address can be different from that of the real home address and other pseudo home addresses, which prevents eavesdroppers from correlating and analyzing IP traffic based on a common prefix. Furthermore, we also discuss the interval of IP address update in the mobility scenario in order to resist the profiling attack both effectively and efficiently.
RFC 4941[10]指定了一种生成随机接口标识符的机制，该标识符可用于更新转交地址和家庭地址。然而，在我们的解决方案中，伪家庭地址的前缀可以不同于真实家庭地址和其他伪家庭地址的前缀，这可以防止窃听者基于公共前缀关联和分析IP流量。此外，我们还讨论了移动场景中IP地址更新的时间间隔，以有效地抵御仿形攻击。
In [16], the authors propose using a temporary identity, called the Temporary Mobile Identifier (TMI), to replace the home address, and discussed the feasibility of utilizing the Crypto-Based Identifier (CBID), Cryptographically Generated Addresses (CGA), or Mobility Anchor Point (MAP) to further protect location privacy. However, as a 128-bit random number, the TMI is not routable; therefore, it is not suitable to be the source IP address in the Home Test Init message forwarded by the home agent to the correspondent node. Otherwise, the home agent cannot receive the Home Test message from the correspondent node. Furthermore, the document does not specify how to update the TMI to address the profiling attack.
在[16]中，作者建议使用一种称为临时移动标识符（TMI）的临时身份来代替家庭地址，并讨论了利用基于密码的标识符（CBID）、加密生成的地址（CGA）或移动定位点（MAP）来进一步保护位置隐私的可行性。然而，作为128位随机数，TMI不可路由；因此，它不适合作为归属代理转发到对应节点的归属测试初始化消息中的源IP地址。否则，归属代理无法从对应节点接收归属测试消息。此外，该文档没有指定如何更新TMI以应对分析攻击。
In [14], the authors propose a mechanism that uses an identity as the home address and periodically updates such an identity by using a key and a previous identity as inputs to a cryptography algorithm.
在[14]中，作者提出了一种机制，使用身份作为家庭地址，并通过使用密钥和以前的身份作为密码算法的输入定期更新此类身份。
In [15], the authors propose to update the mobile node's home address periodically to hide its movement. The new home address is generated from the current local network prefix, the Binding Update session key, and the previous home address, and updated every time when the return routability procedure is performed. The generated home address is random, routable, recognizable, and recoverable.
在[15]中，作者建议定期更新移动节点的家庭地址以隐藏其移动。新的家庭地址由当前本地网络前缀、绑定更新会话密钥和以前的家庭地址生成，并在每次执行返回可路由性过程时更新。生成的家庭地址是随机的、可路由的、可识别的和可恢复的。
In [18], the authors propose a mechanism to achieve both route optimization and location privacy at the same time. This is done by discovering a tunneling agent near the correspondent node and bidirectionally tunneling data traffic between the mobile node and the tunneling agent.
在[18]中，作者提出了一种同时实现路由优化和位置隐私的机制。这是通过在对应节点附近发现隧道代理并在移动节点和隧道代理之间双向隧道传输数据流量来实现的。
This document creates a new registry "Pseudo Home Address Acknowledgement Status Codes" for the Status field in the Pseudo Home Address Acknowledgement mobility option. The current values are described in Section 7.4 and are the following:
本文档为伪家庭地址确认移动选项中的状态字段创建一个新的注册表“伪家庭地址确认状态代码”。第7.4节描述了电流值，如下所示：
0 Success
0成功
128 Failure, reason unspecified
128失败，原因不明
129 Administratively prohibited
129行政禁止
130 Incorrect pseudo home address
130错误的伪家庭地址
131 Invalid pseudo home address
131无效的伪主地址
132 Dynamic pseudo home address assignment not available
132动态伪家庭地址分配不可用
In this document, we have proposed solutions to address location privacy issues in the context of mobility. The main idea is to hide the binding between the home address and the care-of address from eavesdroppers and the correspondent node. We have described two methods. The first method extends the return routability to hide the real home address in Binding Update and data packets. This method uses the real home address in return routability signaling, and does not require any changes to the home agent. The second method uses pseudo home addresses starting from return routability signaling, and requires some extensions to the home agent operation. This method protects revealing the real home address on the HA-CN path. The two methods provide a means to hide the real home address from eavesdroppers, and the second method can also hide it from the correspondents.
在本文档中，我们提出了解决移动环境中位置隐私问题的解决方案。其主要思想是对窃听者和通信节点隐藏主地址和转交地址之间的绑定。我们描述了两种方法。第一种方法扩展了返回路由能力，在绑定更新和数据包中隐藏真实的家庭地址。该方法在返回路由性信令中使用真实的归属地址，并且不需要对归属代理进行任何更改。第二种方法使用从返回路由性信令开始的伪主地址，并且需要对主代理操作进行一些扩展。此方法可保护在HA-CN路径上显示真实的家庭地址。这两种方法提供了一种对窃听者隐藏真实家庭地址的方法，第二种方法也可以对通信者隐藏真实家庭地址。
The solutions we have proposed are for the basic Mobile IPv6 protocol as specified in RFC 3775. Recently, many extensions to Mobile IPv6 have been proposed, such as the NEMO Basic Support protocol [19], Dual Stack Mobile IPv6 Support [20], Multiple Care-of Addresses Registration [21], Binding Revocation [22], Generic Signaling Message [23]. It is expected that the proposed location privacy solutions can be applied with some modifications, if needed, to address location privacy issues when these extensions are used. One of our future works is to clarify related issues, if any, when the location privacy solutions are used with new Mobile IPv6 extensions.
我们提出的解决方案适用于RFC 3775中规定的基本移动IPv6协议。最近，人们提出了许多对移动IPv6的扩展，如NEMO基本支持协议[19]、双栈移动IPv6支持[20]、多个转交地址注册[21]、绑定撤销[22]、通用信令消息[23]。如果需要的话，可以对提议的位置隐私解决方案进行一些修改，以解决使用这些扩展时的位置隐私问题。我们未来的工作之一是澄清当位置隐私解决方案与新的移动IPv6扩展一起使用时的相关问题（如果有）。
The authors would like to thank the co-authors of previous documents from which this document is derived: Vijay Devarapalli, Hannu Flinck, Charlie Perkins, Feng Bao, Robert Deng, James Kempf, and Jianying Zhou. In addition, sincere appreciation is also extended to Claude Castelluccia, Francis Dupont, Gabriel Montenegro, Greg Daley, Kilian Weniger, Takashi Aramaki, Wassim Haddad, Heejin Jang, and Michael Welzl for their valuable contributions, review, and discussion. Work by Fan Zhao was done while he was at University of California, Davis and Marvell Semiconductor, Inc.
作者要感谢本文件的前几份文件的共同作者：Vijay Devarapalli、Hannu Flinck、Charlie Perkins、Feng Bao、Robert Deng、James Kempf和周剑英。此外，我们还衷心感谢Claude Castelluccia、Francis Dupont、Gabriel Montegon、Greg Daley、Kilian Weniger、Takashi Aramaki、Wassim Haddad、Heejin Jang和Michael Welzl的宝贵贡献、评论和讨论。范朝的工作是在加利福尼亚大学、戴维斯和马维尔半导体公司完成的。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[2] Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[3] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[3] Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[4] Kaufman，C.，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[5] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[6] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[7] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[7] Arkko，J.，Devarapalli，V.，和F.Dupont，“使用IPsec保护移动节点和家庭代理之间的移动IPv6信令”，RFC 37762004年6月。
[8] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007.
[8] Devarapalli，V.和F.Dupont，“使用IKEv2的移动IPv6操作和修订的IPsec架构”，RFC 4877，2007年4月。
[9] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[9] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[10] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[10] Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[11] Koodli, R., "IP Address Location Privacy and Mobile IPv6: Problem Statement", RFC 4882, March 2007.
[11] Koodli，R.，“IP地址位置隐私和移动IPv6：问题声明”，RFC 48822007年3月。
[12] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[12] Fenner，B.，“IPv4、IPv6、ICMPv4、ICMPv6、UDP和TCP报头中的实验值”，RFC 4727，2006年11月。
[13] Devarapalli, V., "Mobile IPv6 Experimental Messages", RFC 5096, December 2007.
[13] Devarapalli，V.，“移动IPv6实验消息”，RFC 50962007年12月。
[14] Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, "Protocol for Protecting Movement of Mobile Nodes in Mobile IPv6", Work in Progress, March 2005.
[14] Bao，F.，Deng，R.，Kempf，J.，Qiu，Y.，和J.Zhou，“移动IPv6中保护移动节点移动的协议”，正在进行的工作，2005年3月。
[15] Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, "Protocol for Hiding Movement of Mobile Nodes in Mobile IPv6", Work in Progress, March 2005.
[15] Bao，F.，Deng，R.，Kempf，J.，Qiu，Y.，和J.Zhou，“移动IPv6中隐藏移动节点移动的协议”，正在进行的工作，2005年3月。
[16] Castelluccia, C., Dupont, F., and G. Montenegro, "A Simple Privacy Extension for Mobile IPv6", Work in Progress, July 2006.
[16] Castelluccia，C.，杜邦，F.，和G.黑山，“移动IPv6的简单隐私扩展”，正在进行的工作，2006年7月。
[17] Daley, G., "Location Privacy and Mobile IPv6", Work in Progress, January 2004.
[17] Daley，G.，“位置隐私和移动IPv6”，正在进行的工作，2004年1月。
[18] Weniger, K. and T. Aramaki, "Route Optimization and Location Privacy using Tunneling Agents (ROTA)", Work in Progress, October 2005.
[18] Weniger，K.和T.Aramaki，“使用隧道代理（ROTA）的路线优化和位置隐私”，正在进行的工作，2005年10月。
[19] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[19] Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[20] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[20] Soliman，H.，“双栈主机和路由器的移动IPv6支持”，RFC 5555，2009年6月。
[21] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009.
[21] Wakikawa，R.，Devarapalli，V.，Tsirtsis，G.，Ernst，T.，和K.Nagami，“多重托管地址注册”，RFC 5648，2009年10月。
[22] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", Work in Progress, October 2009.
[22] Muhanna，A.，Khalil，M.，Gundavelli，S.，Chowdhury，K.，和P.Yegani，“IPv6移动的绑定撤销”，正在进行的工作，2009年10月。
[23] Haley, B. and S. Gundavelli, "Mobile IPv6 Generic Signaling Message", Work in Progress, August 2008.
[23] Haley，B.和S.Gundavelli，“移动IPv6通用信令消息”，正在进行的工作，2008年8月。
Appendix A. Profiling Attack: Discussion
附录A.分析攻击：讨论
Profiling attacks pose a significant threat to user privacy. By collecting and analyzing (either online or offline) IP traffic, attackers can obtain sensitive user information. In the context of mobility, although the profiling attack does not directly lead to compromise of location privacy in the way the disclosure of the binding between the home address and the care-of address does, attackers can infer the mobile node's roaming and track its movement (i.e., handover) by profiling the mobile node's communication based on certain fields in IP packets, such as a constant IPsec SPI used during the home registration. The more information collected, the higher probability location privacy is compromised, which in return results in more targeted profiling.
分析攻击对用户隐私构成重大威胁。通过收集和分析（在线或离线）IP流量，攻击者可以获取敏感用户信息。在移动环境中，尽管仿形攻击不会像公开家庭地址和转交地址之间的绑定那样直接导致位置隐私受损，但攻击者可以推断移动节点的漫游并跟踪其移动（即切换）通过基于IP数据包中的特定字段分析移动节点的通信，例如在家庭注册期间使用的恒定IPsec SPI。收集的信息越多，位置隐私受到损害的概率就越高，这反过来会导致更具针对性的分析。
We have taken the profiling problem into consideration when designing the solution to IP address location privacy; however, not all aspects of profiling attacks are addressed since the profiling problem spans multiple protocol layers. In the following, we provide a broad discussion on the profiling attack and protection mechanisms. Our discussion is organized based on how profiling attacks can be performed. Note that the following sections are not sorted based on any criteria or may not exhaustively list all the possible attack means (for example, profiling attacks based on upper-layer payloads in data packets are not discussed).
我们在设计IP地址位置隐私的解决方案时考虑了配置问题；但是，由于分析问题跨越多个协议层，因此分析攻击的所有方面都没有得到解决。下面，我们将对分析攻击和保护机制进行广泛讨论。我们的讨论是基于如何执行分析攻击来组织的。请注意，以下部分未根据任何标准进行排序，也可能未详尽列出所有可能的攻击手段（例如，未讨论基于数据包中上层有效载荷的分析攻击）。
Eavesdroppers on the MN-HA path and/or the MN-CN path can profile the mobile node's communication by collecting packets with the same care-of address. It is recommended that the mobile node periodically updates its care-of address by using DHCPv6 or IPv6 address privacy extension, even if it does not change its current attachment point. Furthermore, it is even better to change the network prefix of the care-of address periodically, since eavesdroppers may profile IP packets based on the common network prefix.
MN-HA路径和/或MN-CN路径上的窃听者可以通过收集具有相同转交地址的分组来分析移动节点的通信。建议移动节点通过使用DHCPv6或IPv6地址隐私扩展定期更新其转交地址，即使它不更改其当前连接点。此外，周期性地改变转交地址的网络前缀甚至更好，因为窃听者可以基于公共网络前缀来分析IP分组。
Since the binding update procedure needs to be performed once the care-of address is changed, in order to reduce signaling overheads, the mobile node may choose to change its care-of address when the Binding Cache entry at the home agent or the correspondent node is about to expire.
由于一旦转交地址改变就需要执行绑定更新过程，为了减少信令开销，移动节点可以在归属代理或对应节点处的绑定高速缓存条目即将到期时选择改变其转交地址。
Generated from either a real or pseudo home address, the encrypted home address can be dynamically updated, because a new key is generated when a new round of the return routability procedure is
从真实或伪家庭地址生成的加密家庭地址可以动态更新，因为新一轮的返回可路由性过程启动时会生成一个新密钥
performed, which makes the encrypted home address look different in subsequent Binding Update and Acknowledgement messages. Nevertheless, the same encrypted home address is used in payload packets forwarded via the optimized route before the next round of the return routability procedure. Given the cost and overhead of updating the encrypted home address, the proposed location privacy solutions still provide a reasonable level of protection against such profiling attacks.
执行，这使加密的家庭地址在后续绑定更新和确认消息中看起来不同。然而，在下一轮返回可路由性过程之前，在通过优化路由转发的有效负载数据包中使用相同的加密家庭地址。考虑到更新加密家庭地址的成本和开销，建议的位置隐私解决方案仍然可以提供合理的保护级别，以防此类分析攻击。
Eavesdroppers on the MN-HA path can profile the mobile node's communication based on the SPI of an IPsec security association that is for protecting the home Binding Update and Acknowledgement message or for protecting bidirectional-tunneled payload packets.
MN-HA路径上的窃听者可以基于用于保护归属绑定更新和确认消息或用于保护双向隧道有效载荷分组的IPsec安全关联的SPI来评测移动节点的通信。
To resist this kind of profiling attack, the IPsec SPI needs to be periodically updated. One way is that the mobile node and the home agent rekey the IPsec security association or perform re-authentication periodically. This may result in more signaling overhead. Another way is that the mobile node or the home agent generates a new SPI and then notifies each other by exchanging the Binding Update and Acknowledgement messages protected by an existing IPsec security association with a non-null encryption algorithm. In this way, the information of the new SPI is hidden from eavesdroppers. The new SPI MUST not conflict with other existing SPIs; and if the conflict is detected on one end point, another SPI MUST be generated and be synchronized with the other end point. The new SPI is applied to the next packet that needs to be protected by this IPsec security association. This solution requires close interaction between Mobile IP and IPsec. For example, when the home agent receives a new SPI suggested by the mobile node, it needs to change the corresponding Security Association Database (SAD) entry.
为了抵抗这种分析攻击，需要定期更新IPsec SPI。一种方法是移动节点和归属代理定期为IPsec安全关联重新设置密钥或执行重新身份验证。这可能会导致更多的信令开销。另一种方式是，移动节点或归属代理生成一个新的SPI，然后通过使用非空加密算法交换由现有IPsec安全关联保护的绑定更新和确认消息来相互通知。这样，新SPI的信息就对窃听者隐藏起来了。新的SPI不得与其他现有SPI冲突；如果在一个端点上检测到冲突，则必须生成另一个SPI并与另一个端点同步。新的SPI应用于需要受此IPsec安全关联保护的下一个数据包。此解决方案需要移动IP和IPsec之间的密切交互。例如，当归属代理接收到移动节点建议的新SPI时，它需要更改相应的安全关联数据库（SAD）条目。
The IPsec sequence number is required to be larger than that in the previous valid IPsec packet if the anti-replay service is enabled. However, if the increment of the IPsec sequence number is fixed (for example, the IPsec sequence number is sequentially increased), it is possible for eavesdroppers to identify a sequence of IPsec packets that are from/to the same mobile node and to track the mobile node's activities. One possible solution is to randomize the increment of the IPsec sequence number on both end points (i.e., the mobile node and the home agent) of the IPsec security association. The algorithm to generate randomness is implementation specific. It can be, for example, any random number generator, and independently chosen by each end point.
如果启用了反重播服务，则要求IPsec序列号大于上一个有效IPsec数据包中的序列号。然而，如果IPsec序列号的增量是固定的（例如，IPsec序列号顺序增加），则窃听者可以识别来自/到同一移动节点的IPsec分组序列并跟踪移动节点的活动。一种可能的解决方案是随机化IPsec安全关联的两个端点（即移动节点和归属代理）上的IPsec序列号的增量。生成随机性的算法是特定于实现的。例如，它可以是任何随机数生成器，并由每个端点独立选择。
As described in RFC 3775, certain signaling messages may be exchanged on a regular basis. For example, the correspondent registration needs to be performed every MAX_RR_BINDING_LIFETIME seconds and the home binding update procedure needs to be performed regularly, if the lifetime of the home Binding Cache entry is fixed. Such timing allows eavesdroppers to perform traffic analyses and correlate different messages. Due to background traffic and routing dynamics, the timing of messages observed by an eavesdropper at a certain vantage point may be irregular. Nevertheless, a better solution is to randomize the lifetime of the Binding Cache entry in the home agent and the correspondent node.
如RFC 3775中所述，某些信令消息可以定期交换。例如，如果主绑定缓存项的生存期是固定的，则需要每隔MAX_RR_BINDING_生存期秒执行对应注册，并且需要定期执行主绑定更新过程。这样的定时允许窃听者执行流量分析并关联不同的消息。由于背景流量和路由动态，窃听者在某个有利位置观察到的消息时间可能不规则。然而，更好的解决方案是随机化归属代理和对应节点中绑定缓存项的生存期。
RFC 3775 requires that the sequence number in the Binding Update message be larger than that in the previous valid Binding Update message for a particular mobile node. However, if the increment of the sequence number in the home or correspondent Binding Update message is fixed (for example, the sequence number is sequentially increased), it is possible for eavesdroppers on the MN-HA or MN-CN path to identify a sequence of Binding Update messages that are from the same mobile node and to track the mobile node's movement. One possible solution is that the mobile node randomizes the increment of the sequence number used in subsequent Binding Update messages. The algorithm to generate randomness is implementation specific. It can be, for example, any random number generator. Note that such an algorithm is not needed when the sequence number is encrypted, for example, when the home Binding Update message is protected by an IPsec tunnel mode security association.
RFC 3775要求绑定更新消息中的序列号大于特定移动节点的先前有效绑定更新消息中的序列号。然而，如果主绑定或对应绑定更新消息中的序列号增量是固定的（例如，序列号顺序增加），MN-HA或MN-CN路径上的窃听者可以识别来自同一移动节点的绑定更新消息序列并跟踪移动节点的移动。一种可能的解决方案是，移动节点随机化后续绑定更新消息中使用的序列号的增量。生成随机性的算法是特定于实现的。例如，它可以是任何随机数生成器。注意，当序列号被加密时，例如，当主绑定更新消息受IPsec隧道模式安全关联保护时，不需要这样的算法。
It is possible for (colluded) eavesdroppers to correlate the mobile node's different sessions with the same or different correspondent nodes, for example, based on the same pseudo home address and/or the same care-of address. A possible solution is to use different pseudo home addresses and different care-of addresses in different sessions. Note that the mobile node may also use the same pseudo home address with different correspondent nodes, if the pseudo home address is masked by different privacy management keys generated during the return routability procedure with different correspondent nodes. In this way, the encrypted pseudo home addresses used with different correspondent nodes look different to eavesdroppers.
（共谋）窃听者可以例如基于相同的伪家庭地址和/或相同的转交地址，将移动节点的不同会话与相同或不同的对应节点相关联。一种可能的解决方案是在不同的会话中使用不同的伪主地址和不同的转交地址。注意，如果伪家庭地址被在不同对应节点的返回路由性过程中生成的不同隐私管理密钥屏蔽，则移动节点还可以对不同对应节点使用相同的伪家庭地址。这样，不同通信节点使用的加密伪主地址在窃听者看来就不同了。
As discussed above, there exist multiple means for eavesdroppers to correlate observed activities. For example, some IP fields, which contain certain constant values and remain unchanged for a long time, allow eavesdroppers to identify and link the mobile node's activities deterministically. Other means may be less reliable when used for traffic analysis and correlation; nevertheless, they provide additional hints to malicious attackers.
如上所述，窃听者有多种方法来关联观察到的活动。例如，某些IP字段包含某些常量值并长时间保持不变，允许窃听者确定地识别和链接移动节点的活动。当用于流量分析和关联时，其他方法可能不太可靠；然而，它们为恶意攻击者提供了额外的提示。
The solution to the profiling attack is to update certain IP fields periodically. Generally, the more frequently, the higher the probability that the profiling attack is resisted and also the higher the cost in terms of communication and processing overheads and complexity. As eavesdroppers can profile activities based on multiple fields, it may not be cost-effective to update some fields more frequently than others. Furthermore, it may reduce some overheads, if all the related IP fields are updated together with the same frequency.
分析攻击的解决方案是定期更新某些IP字段。通常，频率越高，抵御仿形攻击的概率越高，通信和处理开销以及复杂性方面的成本也越高。由于窃听者可以基于多个字段分析活动，因此更新某些字段的频率可能比更新其他字段的频率更高，这并不划算。此外，如果所有相关的IP字段都以相同的频率更新，则可以减少一些开销。
The profiling attack is a complicated issue. A complete solution would have to consider tradeoffs of many different factors, such as complexity, effectiveness, and efficiency.
分析攻击是一个复杂的问题。一个完整的解决方案必须考虑许多不同因素的权衡，如复杂性、有效性和效率。
Authors' Addresses
作者地址
Ying Qiu Institute for Infocomm Research, Singapore 1 Fusionopolis Way #21-01 Connexis (South Tower) Singapore 138632
新加坡盈秋信息通信研究所Fusionopolis路1号#21-01 Connexis（南塔）新加坡138632
Phone: +65-6408 2053
EMail: qiuying@i2r.a-star.edu.sg
Phone: +65-6408 2053
EMail: qiuying@i2r.a-star.edu.sg
Fan Zhao (editor) Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 US
范昭（编辑）谷歌公司1600圆形剧场公园路山景，加利福尼亚州94043美国
EMail: fanzhao@google.com
EMail: fanzhao@google.com
Rajeev Koodli Cisco Systems
拉吉耶夫·库德利思科系统公司
EMail: rkoodli@cisco.com
EMail: rkoodli@cisco.com