Network Working Group R. Koodli
Request for Comments: 4882 Nokia Siemens Networks
Category: Informational May 2007
Network Working Group R. Koodli
Request for Comments: 4882 Nokia Siemens Networks
Category: Informational May 2007
IP Address Location Privacy and Mobile IPv6: Problem Statement
IP地址位置隐私和移动IPv6：问题陈述
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
In this document, we discuss location privacy as applicable to Mobile IPv6. We document the concerns arising from revealing a Home Address to an onlooker and from disclosing a Care-of Address to a correspondent.
在本文档中，我们将讨论适用于移动IPv6的位置隐私。我们记录了向旁观者透露家庭住址和向通讯员透露转交地址所引起的担忧。
Table of Contents
目录
1. Introduction ....................................................2
2. Definitions .....................................................3
3. Problem Definition ..............................................4
3.1. Disclosing the Care-of Address to the Correspondent Node ...4
3.2. Revealing the Home Address to Onlookers ....................4
3.3. Problem Scope ..............................................4
4. Problem Illustration ............................................5
5. Conclusion ......................................................7
6. Security Considerations .........................................7
7. Acknowledgments .................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................8
Appendix A. Background ............................................10
1. Introduction ....................................................2
2. Definitions .....................................................3
3. Problem Definition ..............................................4
3.1. Disclosing the Care-of Address to the Correspondent Node ...4
3.2. Revealing the Home Address to Onlookers ....................4
3.3. Problem Scope ..............................................4
4. Problem Illustration ............................................5
5. Conclusion ......................................................7
6. Security Considerations .........................................7
7. Acknowledgments .................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................8
Appendix A. Background ............................................10
The problems of location privacy, and privacy when using IP for communication, have become important. IP privacy is broadly concerned with protecting user communication from unwittingly revealing information that could be used to analyze and gather sensitive user data. Examples include gathering data at certain vantage points, collecting information related to specific traffic, and monitoring (perhaps) certain populations of users for activity during specific times of the day, etc. In this document, we refer to this as the "profiling" problem.
位置隐私和使用IP进行通信时的隐私问题变得非常重要。IP隐私广泛关注保护用户通信，防止无意中泄露可用于分析和收集敏感用户数据的信息。示例包括在某些有利位置收集数据、收集与特定流量相关的信息、监控（可能）特定用户群体在一天中特定时间的活动等。在本文档中，我们将此称为“分析”问题。
Location privacy is concerned with the problem of revealing roaming, which we define here as the process of a Mobile Node (MN) moving from one network to another with or without ongoing sessions. A constant identifier with global scope can reveal roaming. Examples are a device identifier such as an IP address, and a user identifier such as a SIP [RFC3261] URI [RFC3986]. Often, a binding between these two identifiers is available, e.g., through DNS [RFC1035]. Traffic analysis of such IP and Upper Layer Protocol identifiers on a single network can indicate device and user roaming. Roaming could also be inferred by means of profiling constant fields in IP communication across multiple network movements. For example, an Interface Identifier (IID) [RFC2462] in the IPv6 address that remains unchanged across networks could suggest roaming. The Security Parameter Index (SPI) in the IPsec [RFC4301] header is another field that may be subject to such profiling and inference. Inferring roaming in this way typically requires traffic analysis across multiple networks, or colluding attackers, or both. When location privacy is compromised, it could lead to more targeted profiling of user communication.
位置隐私涉及到显示漫游的问题，我们在这里将漫游定义为移动节点（MN）通过或不通过正在进行的会话从一个网络移动到另一个网络的过程。具有全局范围的常量标识符可以显示漫游。示例是诸如IP地址的设备标识符和诸如SIP[rfc326]URI[RFC3986]的用户标识符。通常，这两个标识符之间的绑定是可用的，例如，通过DNS[RFC1035]。对单个网络上的此类IP和上层协议标识符的流量分析可以指示设备和用户漫游。漫游也可以通过分析IP通信中跨多个网络移动的常量字段来推断。例如，IPv6地址中的接口标识符（IID）[RFC2462]在网络中保持不变，可能会建议漫游。IPsec[RFC4301]头中的安全参数索引（SPI）是另一个可能受此类分析和推断影响的字段。以这种方式推断漫游通常需要跨多个网络进行流量分析，或共谋攻击者，或两者兼而有之。当位置隐私受到损害时，可能会导致对用户通信进行更有针对性的分析。
As can be seen, the location privacy problem spans multiple protocol layers. Nevertheless, we can examine problems encountered by nodes using a particular protocol layer. Roaming is particularly important to Mobile IP, which defines a global identifier (Home Address) that can reveal device roaming, and in conjunction with a corresponding user identifier (such as a SIP URI), can also reveal user roaming. Furthermore, a user may not wish to reveal roaming to correspondent(s), which translates to the use of a Care-of Address. As with a Home Address, the Care-of Address can also reveal the topological location of the Mobile Node.
可以看出，位置隐私问题跨越多个协议层。然而，我们可以检查使用特定协议层的节点遇到的问题。漫游对于移动IP尤其重要，移动IP定义了一个可以显示设备漫游的全局标识符（家庭地址），并且与相应的用户标识符（例如SIPURI）结合，也可以显示用户漫游。此外，用户可能不希望向通信方透露漫游，这将转换为使用转交地址。与家庭地址一样，转交地址也可以显示移动节点的拓扑位置。
This document scopes the problem of location privacy for the Mobile IP protocol. The primary goal is to prevent attackers on the path between the Mobile Node (MN) and the Correspondent Node (CN) from detecting roaming due to the disclosure of the Home Address. The attackers are assumed to be able to observe, modify, and inject traffic at one point between the MN and the CN. The attackers are
本文档涉及移动IP协议的位置隐私问题。主要目标是防止移动节点（MN）和对应节点（CN）之间的路径上的攻击者由于家庭地址的泄露而检测到漫游。假定攻击者能够在MN和CN之间的某个点观察、修改和注入流量。袭击者是
assumed not to be able to observe at multiple points and correlate observations to detect roaming. For this reason, MAC addresses, IIDs, and other fields that can be profiled to detect roaming are only in scope to the extent that they can be used by an attacker at one point. Upper layer protocol identifiers that expose roaming are out of scope except that a solution to the problem described here needs to be usable as a building block in solutions to those problems.
假设无法在多个点进行观察，并将观察结果关联起来以检测漫游。因此，MAC地址、IID和其他可以分析以检测漫游的字段仅在攻击者可以在某一点上使用的范围内。公开漫游的上层协议标识符不在范围内，除非这里描述的问题的解决方案需要在这些问题的解决方案中用作构建块。
This document also considers the problem from the exposure of a Care-of Address to the CN.
本文件还考虑了向CN披露转交地址的问题。
This document is only concerned with IP address location privacy in the context of Mobile IPv6. It does not address the overall privacy problem. For instance, it does not address privacy issues related to MAC addresses or the relationship of IP and MAC addresses [HADDAD], or the Upper Layer Protocol addresses. Solutions to the problem specified here should provide protection against roaming disclosure due to using Mobile IPv6 addresses from a visited network.
本文档仅涉及移动IP地址的隐私。它没有解决整体隐私问题。例如，它不解决与MAC地址或IP与MAC地址[HADDAD]的关系或上层协议地址相关的隐私问题。此处指定问题的解决方案应提供保护，防止由于使用来自访问网络的移动IPv6地址而导致漫游泄露。
This document assumes that the reader is familiar with the basic operation of Mobile IPv6 [RFC3775] and the associated terminology defined therein. For convenience, we provide some definitions below.
本文档假设读者熟悉移动IPv6[RFC3775]的基本操作以及其中定义的相关术语。为了方便起见，我们在下面提供一些定义。
o Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams around networks
o 移动节点（MN）：在网络中自由漫游的移动IPv6移动节点
o Correspondent Node (CN): A Mobile IPv6 that node corresponds with an MN
o 对应节点（CN）：与MN相对应的移动IPv6节点
o Home Network: The network where the MN is normally present when it is not roaming
o 家庭网络：MN不漫游时通常存在的网络
o Visited Network: A network that an MN uses to access the Internet when it is roaming
o 访问网络：MN在漫游时用于访问Internet的网络
o Home Agent: A router on the MN's home network that provides forwarding support when the MN is roaming
o 归属代理：MN的归属网络上的路由器，在MN漫游时提供转发支持
o Home Address (HoA): The MN's unicast IP address valid on its home network
o 家庭地址（HoA）：MN在其家庭网络上有效的单播IP地址
o Care-of Address (CoA): The MN's unicast IP address valid on the visited network
o 转交地址（CoA）：MN在访问网络上有效的单播IP地址
o Reverse Tunneling or Bidirectional Tunneling: A mechanism used for packet forwarding between the MN and its Home Agent
o 反向隧道或双向隧道：用于MN与其归属代理之间的数据包转发的机制
o Route Optimization: A mechanism that allows direct routing of packets between a roaming MN and its CN, without having to traverse the home network
o 路由优化：一种允许在漫游MN和其CN之间直接路由数据包的机制，无需穿越家庭网络
When a Mobile IP MN roams from its home network to a visited network or from one visited network to another, use of Care-of Address in communication with a correspondent reveals that the MN has roamed. This assumes that the correspondent is able to associate the Care-of Address to the Home Address, for instance, by inspecting the Binding Cache Entry. The Home Address itself is assumed to have been obtained by whatever means (e.g., through DNS lookup).
当移动IP MN从其家庭网络漫游到访问的网络或从一个访问的网络漫游到另一个访问的网络时，在与通信者通信时使用转交地址表明MN已经漫游。这假设通信方能够将转交地址与家庭地址相关联，例如，通过检查绑定缓存条目。家庭地址本身被认为是通过任何方式（例如，通过DNS查找）获得的。
When a Mobile IP MN roams from its home network to a visited network or from one visited network to another, use of a Home Address in communication reveals to an onlooker that the MN has roamed. When a binding of a Home Address to a user identifier (such as a SIP URI) is available, the Home Address can be used to also determine that the user has roamed. This problem is independent of whether the MN uses a Care-of Address to communicate directly with the correspondent (i.e., uses route optimization), or the MN communicates via the Home Agent (i.e., uses reverse tunneling). Location privacy can be compromised when an onlooker is present on the MN - CN path (when route optimization is used). It may also be compromised when the onlooker is present on the MN - HA path (when bidirectional tunneling without encryption is used; see below).
当移动IP MN从其家庭网络漫游到访问的网络或从一个访问的网络漫游到另一个访问的网络时，在通信中使用家庭地址向旁观者揭示MN已经漫游。当家庭地址与用户标识符（例如SIP URI）的绑定可用时，家庭地址还可用于确定用户已漫游。该问题独立于MN是使用转交地址直接与对应方通信（即，使用路由优化），还是MN通过归属代理通信（即，使用反向隧道）。当MN-CN路径上有旁观者时（当使用路由优化时），位置隐私会受到损害。当旁观者出现在MN-HA路径上时（当使用无加密的双向隧道时；见下文），它也可能受到损害。
With existing Mobile IPv6 solutions, there is some protection against location privacy. If a Mobile Node uses reverse tunneling with Encapsulating Security Payload (ESP) encryption, then the Home Address is not revealed on the MN - HA path. So, eavesdroppers on the MN - HA path cannot determine roaming. They could, however, still profile fields in the ESP header; however, this problem is not specific to Mobile IPv6 location privacy.
使用现有的移动IPv6解决方案，可以对位置隐私进行一些保护。如果移动节点使用带有封装安全有效负载（ESP）加密的反向隧道，则在MN-HA路径上不会显示家庭地址。因此，MN-HA路径上的窃听者无法确定漫游。但是，他们仍然可以在ESP标题中分析字段；然而，这个问题并不特定于移动IPv6位置隐私。
When an MN uses reverse tunneling (regardless of ESP encryption), the correspondent does not have access to the Care-of Address. Hence, it cannot determine that the MN has roamed.
当MN使用反向隧道（无论ESP加密如何）时，通信方无法访问转交地址。因此，它无法确定MN是否已漫游。
Hence, the location privacy problem is particularly applicable when Mobile IPv6 route optimization is used or when reverse tunneling is used without protecting the inner IP packet containing the Home Address.
因此，当使用移动IPv6路由优化或在不保护包含归属地址的内部IP分组的情况下使用反向隧道时，位置隐私问题特别适用。
This section is intended to provide an illustration of the problem defined in the previous section.
本节旨在说明上一节中定义的问题。
Consider a Mobile Node at its home network. Whenever it is involved in IP communication, its correspondents can see an IP address valid on the home network. Elaborating further, the users involved in peer-to-peer communication are likely to see a user-friendly identifier such as a SIP URI, and the communication endpoints in the IP stack will see IP addresses. Users uninterested in or unaware of IP communication details will not see any difference when the MN acquires a new IP address. Of course, any user can "tcpdump" or "ethereal" a session, capture IP packets, and map the MN's IP address to an approximate geo-location. This mapping may reveal the home location of a user, but a correspondent cannot ascertain whether the user has actually roamed or not. Assessing the physical location based on IP addresses has some similarities to assessing the geographical location based on the area code of a telephone number. The granularity of the physical area corresponding to an IP address can vary depending on how sophisticated the available tools are, how often an ISP conducts its network re-numbering, etc. Also, an IP address cannot guarantee that a peer is at a certain geographic area due to technologies such as VPN and tunneling.
考虑在其家庭网络中的移动节点。每当涉及到IP通信时，其通信方都可以看到在家庭网络上有效的IP地址。进一步阐述，参与对等通信的用户可能看到用户友好的标识符，例如SIP URI，并且IP堆栈中的通信端点将看到IP地址。当MN获取新的IP地址时，对IP通信细节不感兴趣或不知道的用户将不会看到任何区别。当然，任何用户都可以“tcpdump”或“ethereal”会话，捕获IP数据包，并将MN的IP地址映射到近似的地理位置。此映射可能会显示用户的家庭位置，但通讯员无法确定用户是否实际漫游过。基于IP地址评估物理位置与基于电话号码的区号评估地理位置有一些相似之处。与IP地址对应的物理区域的粒度可能因可用工具的复杂程度、ISP进行网络重新编号的频率等而异。此外，由于VPN和隧道等技术，IP地址无法保证对等方位于特定地理区域。
When the MN roams to another network, the location privacy problem consists of two parts: revealing information to its correspondents and to onlookers.
当MN漫游到另一个网络时，位置隐私问题由两部分组成：向通信者和旁观者透露信息。
With its correspondents, the MN can either communicate directly or reverse-tunnel its packets through the Home Agent. Using reverse tunneling does not reveal the Care-of Address of the MN, although end-to-end delay may vary depending on the particular scenario. With those correspondents with which it can disclose its Care-of Address "on the wire", the MN has the option of using route-optimized communication. The transport protocol still sees the Home Address with route optimization. Unless the correspondent runs some packet capturing utility, the user cannot see which mode (reverse tunneling or route optimization) is being used, but knows that it is communicating with the same peer whose URI it knows. This is similar to conversing with a roaming cellphone user whose phone number, like the URI, remains unchanged.
通过其对应者，MN可以直接通信，也可以通过归属代理反向隧道其数据包。使用反向隧道并不能揭示MN的转交地址，尽管端到端延迟可能根据特定场景而有所不同。对于那些通信者，MN可以在“线路上”公开其转交地址，MN可以选择使用路由优化通信。传输协议仍然可以通过路由优化看到主地址。除非通信方运行一些数据包捕获实用程序，否则用户无法看到正在使用哪种模式（反向隧道或路由优化），但知道它正在与它知道URI的同一对等方通信。这类似于与漫游手机用户交谈，其电话号码（如URI）保持不变。
Regardless of whether the MN uses route optimization or reverse tunneling (without ESP encryption), its Home Address is revealed in data packets. When equipped with an ability to inspect packets "on the wire", an onlooker on the MN - HA path can determine that the MN has roamed and could possibly also determine that the user has roamed. This could compromise the location privacy even if the MN took steps to hide its roaming information from a correspondent.
无论MN是使用路由优化还是反向隧道（不使用ESP加密），其主地址都会在数据包中显示。当装备了“在线”检查数据包的能力时，MN-HA路径上的旁观者可以确定MN已经漫游，也可能确定用户已经漫游。这可能会损害位置隐私，即使MN采取步骤向通讯员隐藏其漫游信息。
The above description is valid regardless of whether a Home Address is statically allocated or is dynamically allocated. In either case, the mapping of IP address to a geo-location will most likely yield results with the same level of granularity. With the freely available tools on the Internet, this granularity is the physical address of the ISP or the organization that registers ownership of a prefix chunk. Since an ISP or an organization is not, rightly, required to provide a blueprint of its subnets, the granularity remains fairly coarse for a mobile wireless network. However, sophisticated attackers might be able to conduct site mapping and obtain more fine-grained subnet information.
无论家庭地址是静态分配还是动态分配，上述描述均有效。在这两种情况下，IP地址到地理位置的映射很可能会产生具有相同粒度级别的结果。使用Internet上免费提供的工具，此粒度是ISP或注册前缀块所有权的组织的物理地址。由于ISP或组织不需要提供其子网的蓝图，因此移动无线网络的粒度仍然相当粗糙。但是，复杂的攻击者可能能够进行站点映射并获得更细粒度的子网信息。
A compromise in location privacy could lead to more targeted profiling of user data. An eavesdropper may specifically track the traffic containing the Home Address, and monitor the movement of the Mobile Node with a changing Care-of Address. The profiling problem is not specific to Mobile IPv6, but could be triggered by a compromise in location privacy due to revealing the Home Address. A correspondent may take advantage of the knowledge that a user has roamed when the Care-of Address is revealed, and modulate actions based on such knowledge. Such information could cause concern to a mobile user, especially when the correspondent turns out be untrustworthy. For these reasons, appropriate security measures on the management interfaces on the MN to guard against the disclosure or misuse of location information should be considered.
位置隐私方面的妥协可能导致对用户数据进行更有针对性的分析。窃听者可以具体地跟踪包含归属地址的通信量，并使用改变的转交地址监视移动节点的移动。分析问题并非特定于移动IPv6，但可能是由于泄露家庭地址导致位置隐私受损而引发的。通信者可以利用当转交地址被揭示时用户已经漫游的知识，并基于这种知识调整动作。这些信息可能会引起移动用户的担忧，特别是当通讯员不可信时。出于这些原因，应考虑在MN上的管理接口上采取适当的安全措施，以防止位置信息的泄露或滥用。
Applying existing techniques to thwart profiling may have implications to Mobile IPv6 signaling performance. For instance, changing the Care-of Address often would cause additional Return Routability [RFC3775] and binding management signaling. And, changing the Home Address often has implications on IPsec security association management. Careful consideration should be given to the signaling cost introduced by changing either the Care-of Address or the Home Address.
应用现有技术阻止分析可能会对移动IPv6信令性能产生影响。例如，更改转交地址通常会导致额外的返回路由性[RFC3775]和绑定管理信令。而且，更改家庭地址通常会影响IPsec安全关联管理。应仔细考虑通过更改转交地址或家庭地址引入的信令成本。
When roaming, an MN may treat its home network nodes as any other correspondents. Reverse tunneling is perhaps sufficient for home network communication, since route-optimized communication will traverse the identical path. Hence, an MN can avoid revealing its Care-of Address to its home network correspondents simply by using
当漫游时，MN可以将其归属网络节点视为任何其他对应者。反向隧道对于家庭网络通信来说可能足够了，因为路由优化通信将穿越相同的路径。因此，MN可以避免仅仅通过使用
reverse tunneling. The Proxy Neighbor Advertisements [RFC2461] from the Home Agent could serve as hints to the home network nodes that the Mobile Node is away. However, they will not be able to know the Mobile Node's current point of attachment unless the MN uses route optimization with them.
反向隧道。来自归属代理的代理邻居播发[RFC2461]可以作为向归属网络节点提示移动节点不在的提示。然而，除非MN使用路由优化，否则他们将无法知道移动节点的当前连接点。
In this document, we have discussed the location privacy problem as applicable to Mobile IPv6. The problem can be summarized as follows: disclosing the Care-of Address to a correspondent and revealing the Home Address to an onlooker can compromise the location privacy of a Mobile Node, and hence that of a user. We have seen that bidirectional tunneling allows an MN to protect its Care-of Address to the CN. And, ESP encryption of an inner IP packet allows the MN to protect its Home Address from the onlookers on the MN - HA path. However, with route optimization, the MN will reveal its Care-of Address to the CN. Moreover, route optimization causes the Home Address to be revealed to onlookers in the data packets as well as in Mobile IPv6 signaling messages. The solutions to this problem are expected to be protocol specifications that use the existing Mobile IPv6 functional entities, namely, the Mobile Node, its Home Agent, and the Correspondent Node.
在本文档中，我们讨论了适用于移动IPv6的位置隐私问题。问题可以总结如下：向通讯员透露转交地址和向旁观者透露家庭地址可能会损害移动节点的位置隐私，从而损害用户的位置隐私。我们已经看到，双向隧道允许MN保护其到CN的转交地址。而且，内部IP数据包的ESP加密允许MN保护其家庭地址不被MN-HA路径上的旁观者看到。然而，通过路由优化，MN将向CN显示其转交地址。此外，路由优化导致在数据包以及移动IPv6信令消息中向旁观者显示家庭地址。该问题的解决方案预计将是使用现有移动IPv6功能实体的协议规范，即移动节点、其归属代理和对应节点。
This document discusses the location privacy problem specific to Mobile IPv6. Any solution must be able to protect (e.g., using encryption) the Home Address from disclosure to onlookers in data packets when using route optimization or reverse tunneling. In addition, solutions must consider protecting the Mobile IPv6 signaling messages from disclosing the Home Address along the MN - HA and MN - CN paths.
本文档讨论移动IPv6特有的位置隐私问题。当使用路由优化或反向隧道时，任何解决方案都必须能够保护（例如，使用加密）家庭地址，使其不会在数据包中泄露给旁观者。此外，解决方案必须考虑保护移动IPv6信令消息，以揭示沿MN-HA和MN-CN路径的家庭地址。
Disclosing the Care-of Address is inevitable if an MN wishes to use route optimization. Regardless of whether the Care-of Address is an on-link address of the MN on the visited link or that of a cooperating proxy, mere presence of a Binding Cache Entry is sufficient for a CN to ascertain roaming. Hence, an MN concerned with location privacy should exercise prudence in determining whether to use route optimization with, especially previously unacquainted, correspondents.
如果MN希望使用路由优化，则披露转交地址是不可避免的。不管转交地址是访问链路上的MN的链路上地址还是协作代理的链路上地址，仅存在绑定缓存条目就足以使CN确定漫游。因此，关注位置隐私的MN应该谨慎地确定是否使用路由优化，尤其是之前不熟悉的通信员。
The solutions should also consider the use of temporary addresses and their implications on Mobile IPv6 signaling as discussed in Section 4, "Problem Illustration". Use of IP addresses with privacy extensions [RFC3041] could be especially useful for Care-of Addresses
解决方案还应考虑使用临时地址及其对移动IPv6信令的影响，如第4节“问题说明”中所讨论的。将IP地址与隐私扩展一起使用[RFC3041]对于地址的保护特别有用
if appropriate trade-offs with Return Routability signaling are taken into account.
如果考虑了返回路由性信令的适当权衡。
James Kempf, Qiu Ying, Sam Xia, and Lakshminath Dondeti are acknowledged for their review and feedback. Thanks to Jari Arkko and Kilian Weniger for the last-call review and for suggesting improvements and text. Thanks to Sam Hartman for providing text to improve the problem scope.
詹姆斯·坎普夫、邱颖、夏三明和拉克希米纳·唐德蒂对他们的评论和反馈表示感谢。感谢Jari Arkko和Kilian Weniger对最后一次通话的回顾，以及对改进和文本的建议。感谢Sam Hartman提供文本以改进问题范围。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[HADDAD] Haddad, W., et al., "Privacy for Mobile and Multi-homed Nodes: Problem Statement" Work in Progress, June 2006.
[HADDAD]HADDAD，W.等人，“移动和多宿节点的隐私：问题陈述”，正在进行的工作，2006年6月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041]Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC 3041，2001年1月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004.
[RFC3825]Polk，J.，Schnizlein，J.，和M.Linsner，“基于坐标的位置配置信息的动态主机配置协议选项”，RFC 38252004年7月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
The location privacy topic is broad and often has different connotations. It also spans multiple layers in the OSI reference model. Besides, there are attributes beyond an IP address alone that can reveal hints about location. For instance, even if a correspondent is communicating with the same endpoint it is used to, the "time of day" attribute can reveal a hint to the user. Some roaming cellphone users may have noticed that their SMS messages carry a timestamp of their "home network" time zone (for location privacy or otherwise), which can reveal that the user is in a different time zone when messages are sent during a "normal" time of the day. Furthermore, tools exist on the Internet that can map an IP address to the physical address of an ISP or the organization that owns the prefix chunk. Taking this to another step, with built-in GPS receivers on IP hosts, applications can be devised to map geo-locations to IP network information. Even without GPS receivers, geo-locations can also be obtained in environments where "Geopriv" is supported, for instance, as a DHCP option [RFC3825]. In summary, a user's physical location can be determined or guessed with some certainty and with varying levels of granularity by different means, even though IP addresses themselves do not inherently provide any geo-location information. It is perhaps useful to bear this broad scope in mind as the problem of IP address location privacy in the presence of IP Mobility is addressed.
位置隐私话题涉及面很广，通常有不同的含义。它还跨越OSI参考模型中的多个层。此外，除了IP地址之外，还有一些属性可以显示有关位置的提示。例如，即使通信者与它使用的同一端点通信，“时间”属性也可以向用户显示提示。一些漫游手机用户可能已经注意到，他们的短信带有“家庭网络”时区的时间戳（出于位置隐私或其他原因），这可能表明用户在一天的“正常”时间发送短信时处于不同的时区。此外，Internet上存在的工具可以将IP地址映射到ISP或拥有前缀块的组织的物理地址。再进一步，通过IP主机上的内置GPS接收器，可以设计应用程序将地理位置映射到IP网络信息。即使没有GPS接收机，也可以在支持“Geopriv”的环境中获取地理位置，例如，作为DHCP选项[RFC3825]。总之，即使IP地址本身并不提供任何地理位置信息，也可以通过不同的方法确定或猜测用户的物理位置，并具有不同的粒度级别。在解决IP移动性中的IP地址位置隐私问题时，记住这一广泛的范围可能是有用的。
Author's Address
作者地址
Rajeev Koodli Nokia Siemens Networks 313 Fairchild Drive Mountain View, CA 94043
加利福尼亚州山景城飞兆半导体大道313号诺基亚西门子网络公司，邮编94043
EMail: rajeev.koodli@nokia.com
EMail: rajeev.koodli@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。