この文書はRFC 4882の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


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).

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
   1.  はじめに
   2.  Definitions
   2.  定義
   3.  Problem Definition
   3.  問題定義
      3.1.  Disclosing the Care-of Address to the Correspondent Node
      3.1.  ケアオブアドレスの通信相手へ露出
      3.2.  Revealing the Home Address to Onlookers
      3.2.  見物人にホームアドレスを示すこと
      3.3.  Problem Scope
      3.3.  問題範囲
   4.  Problem Illustration
   4.  問題説明
   5.  Conclusion
   5.  結論
   6.  Security Considerations
   6.  セキュリティの考察
   7.  Acknowledgments
   7.  謝辞
   8.  References
   8.  参考文献
      8.1.  Normative References
      8.1.  参照する参考文献

      8.2.  Informative References
      8.2.  益な参考文献
   Appendix A.  Background
   付録A,背景

1.  Introduction
1.  はじめに

   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プライバシーは広く懸念さ
   れています。これは、ある有利な地位の集会データ、特定のトラヒックの情
   報の収集、1日の特定の時間の行動について(恐らく)ユーザのある集団をモ
   ニタする事、などを含みます。この文書ではこれを「プロファイリング」問
   題と言います。

   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.
   位置のプライバシーはローミングの開示の問題に関係があります、ここでロー
   ミングは、進行中のセッションのあるなしにかかわらず1つのネットワーク
   から別のネットワークへ移動するモバイルノード(MN)の処理と定義します。
   グローバルな範囲で静的な識別子はローミングを明らかにすることができま
   す。例えば、IPアドレスなどのデバイス識別子や、SIP[RFC3261]やU
   RI[RFC3986]などのユーザ識別子です。しばしば、これらの2つの識別子
   は、たとえば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で特
   に重要で、これは装置ローミングを明らかにするグローバル識別子(ホーム
   アドレス)を定義し、関連してユーザローミングを明らかにします。その上、
   ユーザが通信相手にローミングを明らかにしたくないかもしれず、ケアオブ
   アドレスを使用します。ホームアドレスのようにケアオブアドレスもモバイ
   ルノードの位相的な位置を明らかにできます。

   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
   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.
   この文書は、モバイルIPプロトコルの位置プライバシ問題を扱います。主
   な目的は、ホームアドレスの公開により、移動ノード(MN)と相手先(C
   N)の間の攻撃者に、移動が検出されるのを防ぐことです。攻撃者は、MN
   とCNの間のある所でトラヒックを観察し、修正し、注入することができる
   と仮定します。攻撃者は、複数の場所で観察することはできず、移動を見つ
   けるために相関の観察はできないと仮定します。この理由で、移動の検出に
   使えるMACアドレスとIIDとその他のフィールドは、1点にいつ攻撃者
   が使える範囲に限定されます。移動を露出させる上層プロトコル識別子は、
   ここで記述される問題の解決策がそれらの問題の解決策の一部として使える
   場合を除き、範囲外です。

   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.
   この文書はモバイルIPv6環境で、IPアドレス位置プライバシーに関心
   を持つだけです。全体的なプライバシー問題に対処しません。たとえば、M
   ACアドレスまたはIPとMACアドレスの関係付け[HADDAD]と関連した問
   題に、あるいは上位層プロトコルが対処するプライバシーに対処しません。
   ここで指定される問題の解決策は、移動先ネットワークからモバイルIPv
   6アドレスを使うことで移動が公表されることからの保護を提供しなければ
   なりません。

   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]の基本的な動作とその中で
   定められる関連用語をよく知っていると仮定します。便宜上、我々は下記の
   いくつかの定義を提供します。

2.  Definitions
2.  定義

   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が移動中にインターネットにアクセスするため
      に使うネットワーク

   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の間で、ホームネットワーク
      を経由せずに、パケットの直接のルーティングを可能にするメカニズム

3.  Problem Definition
3.  問題定義

3.1.  Disclosing the Care-of Address to the Correspondent Node
3.1.  ケアオブアドレスの通信相手へ露出

   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検索を通して)で得
   る事ができると仮定します。

3.2.  Revealing the Home Address to Onlookers
3.2.  見物人にホームアドレスを示すこと

   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がそのホームネットワークから訪問先ネットワークへ、
   または、1つの訪問先ネットワークから別へ移動するとき、通信でホーム
   アドレスを使用する事で、見物人にMNが移動したことが露見します。ユー
   ザ識別子(例えばSIP URI)とホームアドレスの対応が利用できるとき、
   ホームアドレスはユーザが移動したと確定するのに用いることができます。
   この問題はMNが通信相手と直接と情報交換するためにケアオブアドレス
   を使うかどうか(すなわち経路最適化の使用)や、MNがホームエージェ
   ントと通信する(すなわち、逆トンネルの使用)とは、別問題です。見物
   人がMN−HA経路間にいる時(暗号化のない双方向トンネルが使われる
   時;下記参照)もこれは危険になるかもしれません。

3.3.  Problem Scope
3.3.  問題範囲

   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パケットを
   保護することなく使われる時に、特に適用できます。

4.  Problem Illustration
4.  問題説明

   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が新しいI
   Pアドレスを得るとき、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が他のネットワークに移動する、位置プライバシ問題は2つの部分か
   ら成ります:通信相手へと、見物人への、情報の暴露。

   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は経路最適化された通
   信を使うオプションがあります。トランスポートプロトコルは、経路最適
   化でもホームアドレスを見ます。通信相手が何らかのパケットキャプチャ
   を動かさない限り、ユーザはどのモード(逆トンネリングまたは経路最適
   化)が使われているか見ることができませんが、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アドレスと地
   理的位置への対応は、たぶん同じ程度の精度の結果を与えます。インター
   ネットで自由に入手可能なツールで、この精度はプレフィックスの塊の所
   有者として登録されているる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.
   プロファイリングを妨害する既存の技術を適用することは、モバイルIP
   v6の信号処理の性能に影響を与えるかもしれません。たとえば、ケアオ
   ブアドレスを頻繁に変えることは、追加の帰路経路[RFC3775]と結合管理
   信号を発生します。そして、ホームアドレスを頻繁に変えることは、IP
   secセキュリティ連携管理に影響を与えます。ケアオブアドレスやホー
   ムアドレスを変えることで発生する信号コストは慎重に考慮しなければな
   りません。

   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
   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.
   移動中、MNはそのホームネットワークノードを他の通信相手とみなすか
   もしれません。経路最適化された通信が同一の経路を通るので、逆トンネ
   リングはおそらくホームネットワークとの通信に十分です。それゆえに、
   MNは逆トンネリングを用いて、単純にそのホームネットワーク通信相手
   にケアオブアドレスを示すことを避けることができます。ホームエージェ
   ントからのプロキシ近隣広告[RFC2461]は、ホームネットワークノードに、
   モバイルノードがいないというヒントとして用いることができました。し
   かし、MNが彼らと経路最適化を使わない限り、彼らはモバイルノードの
   現在の存在位置を知ることができません。

5.  Conclusion
5.  結論

   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に適用できる位置プライバシー問題を議
   論しました。問題は、以下の通りにまとめることができます:ケアオブア
   ドレスを通信相手に明らかにする事や、見物人にホームアドレスを示すこ
   とは、モバイルノードのの位置プライバシと、それゆえに、ユーザの位置
   プライバシを露見させることができます。我々は、双方向性トンネリング
   がCNに対し、MNのケアオブアドレスを保護するのを許すのを見ました。
   そして、内部のIPパケットのESP暗号化は、MN−HA間経路上の見
   物人に対し、MNのホームアドレスの保護を許します。しかし、経路最適
   化で、MNはCNにそのケアオブアドレスを示します。さらに、経路最適
   化は、モバイルIPv6信号メッセージ同様に、データパケット内のホー
   ムアドレスを見物人に示す原因になります。既存のモバイルIPv6機能
   実体、すなわち、モバイルノード、そのホームエージェントと通信相手の
   使うプロトコル仕様で、この問題の解決策が期待されます。

6.  Security Considerations
6.  セキュリティの考察

   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固有の位置プライバシ問題を議論します。
   解決策は経路最適化または逆のトンネリングを使うとき、データパケット
   内のホームアドレスを見物人への公開に対し保護できなければなりません
   (例えば、暗号化を使う)。そのうえ、解決策MN−HAとMN−CN経
   路間でホームアドレスを公開することに対し、モバイルIPv6信号メッ
   セージの保護を考えなければなりません。

   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
   if appropriate trade-offs with Return Routability signaling are taken
   into account.
   解決は、4章「問題説明」で議論したように、一時的アドレスの使用とその
   モバイルIPv6信号への影響を考慮すべきです。帰路経路信号での適切な
   取り扱いが考慮されるならば、プライバシ拡張[RFC3041]のIPアドレスの
   使用は特にケアオブアドレスに役立ちます。

7.  Acknowledgments
7.  謝辞

   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.
   James KempfとQiu YingとSam XiaとLakshminath Dondetiのレビューと
   フィードバックに感謝します。最後の文書の示唆と改良のレビューに対し
   Jari ArkkoとKilian Wenigerに感謝します。問題がある範囲を改善する文
   書の提供に対しSam Hartmanに感謝します。

8.  References
8.  参考文献

8.1.  Normative References
8.1.  参照する参考文献


   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

8.2.  Informative References
8.2.  益な参考文献

   [HADDAD]   Haddad, W., et al., "Privacy for Mobile and Multi-homed
              Nodes: Problem Statement" Work in Progress, June 2006.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461, December
              1998.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
              Stateless Address Autoconfiguration in IPv6", RFC 3041,
              January 2001.

   [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.

   [RFC3825]  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
              Configuration Protocol Option for Coordinate-based
              Location Configuration Information", RFC 3825, July 2004.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

Appendix A.  Background
付録A,背景

   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アドレス以外に場
   所の明らかにするヒントの属性があります。例えば、通信相手が過去と同じ
   相手と通信しているなら、「時刻」属性はユーザーにヒントを示すことがで
   きます。あるローミング携帯電話ユーザは(位置プラバシか他の理由で)S
   MSメッセージで「ホーム網」の時間のタイムスタンプを示します、それら
   のSMSメッセージが「標準的」時間に送られるなら、異なる時間帯にいる
   ことを明らかにするかもしれません。さらに、IPアドレスをプレフィック
   ス群を所有するISPあるいは組織の物理アドレスに変換できるツールがイ
   ンターネットに存在します。他の考えとして、GPS受信機が組み込まれた
   IPホストで、位置情報とIPネットワーク情報を対応付けるアプリケーショ
   ンが考案できます。GPS受信機なしででも、例えばDHCPオプション
   [RFC3825]として「Geopriv」がサポートされる環境で、位置情報が入手でき
   ます。概略すれば、IPアドレス自身が本質的に位置情報を提供しないが、
   ユーザーの物理的な場所は、異なった手段によって、ある確からしさと様々
   なレベルの精度で推測や決定できます。IPアドレスの位置プライバシの問
   題がIP移動性で扱われるとき、この広い範囲を心に留めておくことは多分
   有用です。

Author's Address
著者のアドレス

   Rajeev Koodli
   Nokia Siemens Networks
   313 Fairchild Drive
   Mountain View, CA 94043

   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.
   この文書はBCP78に含まれる権利と許可と制限の適用を受け、そして
   この中に明らかにされる以外は著者がすべての権利を維持します。

   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文書の権利に関する手続
   きの情報はBCP78とBCP79を見てください。

   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事務局に公開されたIPRの写しと、利用可能な許可証と、仕様書
   の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
   試みの結果は、http://www.ietf.org/iprにあるIETFオンライン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-ipr@ietf.orgのIETFに情報を伝えてください。

Acknowledgement
謝辞

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

[]Japanese translation by Ishida So