RFC4651 日本語訳
4651 A Taxonomy and Analysis of Enhancements to Mobile IPv6 RouteOptimization. C. Vogt, J. Arkko. February 2007. (Format: TXT=79226 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Vogt
Request for Comments: 4651 Universitaet Karlsruhe (TH)
Category: Informational J. Arkko
Ericsson Research NomadicLab
February 2007
コメントを求めるワーキンググループC.フォークトの要求をネットワークでつないでください: 4651年のUniversitaetカールスルーエ(TH)カテゴリ: 情報のJ.Arkkoエリクソン研究NomadicLab2007年2月
A Taxonomy and Analysis of Enhancements to
Mobile IPv6 Route Optimization
モバイル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).
IETFが信じる著作権(C)(2007)。
IESG Note:
IESGは以下に注意します。
This RFC is a product of the Internet Research Task Force and is not a candidate for any level of Internet Standard. The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment.
このRFCはインターネットResearch Task Forceの製品であり、インターネットStandardのどんなレベルの候補ではありません。 IRTFはインターネット関連の研究開発活動の結果を発表します。 これらの結果は展開に適していないかもしれません。
Abstract
要約
This document describes and evaluates strategies to enhance Mobile IPv6 Route Optimization, on the basis of existing proposals, in order to motivate and guide further research in this context. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.
このドキュメントは、モバイルIPv6 Route Optimizationを高めるために戦略を説明して、評価します、既存の提案に基づいて、このような関係においてはさらなる研究を動機づけて、誘導するために。 このドキュメントはIP Mobility Optimizations(MobOpts)研究Groupの製品です。
Vogt & Arkko Informational [Page 1] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[1ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. A Note on Public-Key Infrastructures .......................4
1.2. A Note on Source Address Filtering .........................5
2. Objectives for Route Optimization Enhancement ...................7
2.1. Latency Optimizations ......................................8
2.2. Security Enhancements ......................................8
2.3. Signaling Optimizations ....................................9
2.4. Robustness Enhancements ....................................9
3. Enhancements Toolbox ............................................9
3.1. IP Address Tests ..........................................10
3.2. Protected Tunnels .........................................10
3.3. Optimistic Behavior .......................................11
3.4. Proactive IP Address Tests ................................11
3.5. Concurrent Care-of Address Tests ..........................12
3.6. Diverted Routing ..........................................13
3.7. Credit-Based Authorization ................................14
3.8. Heuristic Monitoring ......................................17
3.9. Crypto-Based Identifiers ..................................18
3.10. Pre-Configuration ........................................19
3.11. Semi-Permanent Security Associations .....................20
3.12. Delegation ...............................................21
3.13. Mobile Networks ..........................................21
3.14. Location Privacy .........................................22
4. Discussion .....................................................22
4.1. Cross-Layer Interactions ..................................23
4.2. Experimentation and Measurements ..........................23
4.3. Future Research ...........................................24
5. Security Considerations ........................................24
6. Conclusions ....................................................25
7. Acknowledgments ................................................25
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................26
1. 序論…3 1.1. 公開鍵暗号基盤に関する注…4 1.2. ソースアドレスフィルタリングに関する注…5 2. 経路最適化増進のための目的…7 2.1. 潜在最適化…8 2.2. セキュリティ増進…8 2.3. シグナリング最適化…9 2.4. 丈夫さ増進…9 3. 増進道具箱…9 3.1. IPアドレスはテストされます…10 3.2. Tunnelsを保護します…10 3.3. 楽観的な振舞い…11 3.4. IPアドレスがテストであると予測してください…11 3.5. 同時発生、注意、-、テストを扱ってください…12 3.6. ルート設定を紛らします…13 3.7. クレジットベースの承認…14 3.8. 発見的なモニター…17 3.9. 暗号ベースの識別子…18 3.10. プレ構成…19 3.11. 半永久的なセキュリティ協会…20 3.12. 委譲…21 3.13. モバイルネットワーク…21 3.14. 位置のプライバシー…22 4. 議論…22 4.1. 交差している層の相互作用…23 4.2. 実験と測定値…23 4.3. 今後の研究…24 5. セキュリティ問題…24 6. 結論…25 7. 承認…25 8. 参照…26 8.1. 標準の参照…26 8.2. 有益な参照…26
Vogt & Arkko Informational [Page 2] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[2ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
1. Introduction
1. 序論
Mobility support for IPv6, or Mobile IPv6, enables mobile nodes to migrate active transport connections and application sessions from one IPv6 address to another. The Mobile IPv6 specification, RFC 3775 [1], introduces a "home agent", which proxies a mobile node at a permanent "home address". A roaming mobile node connects to the home agent through a bidirectional tunnel and can so communicate, from its local "care-of address", as if it was present at the home address. The mobile node keeps the home agent updated on its current care-of address via IPsec-protected signaling messages [40].
IPv6、またはモバイルIPv6の移動性サポートは、モバイルノードが移行するのを可能にします。能動輸送接続と別の1つのIPv6アドレスからアドレスまでのアプリケーションセッション。 モバイルIPv6仕様(RFC3775[1])は「ホームのエージェント」を導入して、どのプロキシが永久的な「ホームアドレス」でモバイルノードであるか。 移動しているモバイルノードは、双方向のトンネルを通ってホームのエージェントに接するので、交信できます、ローカルから「注意、-、アドレス、」、まるでそれがホームアドレスで存在しているかのように。 モバイルノードが、電流でホームのエージェントにアップデートし続ける、注意、-、IPsecによって保護されたシグナリングで、メッセージが[40]であると扱ってください。
In case the correspondent node lacks appropriate mobility support, it communicates with the mobile node's home address, and thus all data packets are routed via the home agent. This mode, Bidirectional Tunneling, increases packet-propagation delays. RFC 3775 hence defines an additional mode for Route Optimization, which allows peers to communicate on the direct path. It requires that the correspondent node can cache a binding between the mobile node's home address and current care-of address. The challenge with Route Optimization is that an administrative relationship between the mobile node and the correspondent node can generally not be presupposed. So how can the two authenticate and authorize the signaling messages that they exchange?
通信員ノードが適切な移動性サポートを欠いているといけないので、モバイルノードのホームアドレスで交信します、そして、その結果、すべてのデータ・パケットがホームのエージェントを通して発送されます。 このモード(Bidirectional Tunneling)はパケット伝播遅延を増強します。 したがって、RFC3775はRoute Optimizationのために追加モードを定義します。(Route Optimizationは同輩に直接路について話し合わせます)。 それが、通信員ノードがモバイルノードのホームアドレスと電流の間の結合をキャッシュできるのを必要とする、注意、-、アドレス。 Route Optimizationとの挑戦は一般に、モバイルノードと通信員ノードとの管理関係を予想できないということです。 それで、2は、どうしたら、それらが交換するシグナリングメッセージを認証して、認可できますか?
Mobile IPv6 solves this problem by verifying a routing property of the mobile node. Specifically, the mobile node is checked to be reachable at its home address and current care-of address in that it must prove the reception of a home and care-of keygen token, respectively. This is called the "return-routability procedure". It takes place right before a mobile node registers a new care-of address with a correspondent node and is periodically repeated in case the mobile node does not move for a while.
モバイルIPv6は、モバイルノードのルーティングの特性について確かめることによって、この問題を解決します。 そして、明確に、モバイルノードがホームアドレスで届いて現在になるようにチェックされる、注意、-、ホームのレセプションを立証しなければならないので扱う、注意、-、それぞれkeygenトークン。 これは「リターン-routability手順」と呼ばれます。 モバイルノードが新しい状態でaを登録するまさしく前にそれが行われる、注意、-、モバイルノードがしばらく動かさない場合で通信員ノードで扱って、定期的にたびたびです。
The advantage of the return-routability procedure is that it is lightweight and does not require pre-shared authentication material. It also requires no state at the correspondent node. On the other hand, the two reachability tests can lead to a handoff delay unacceptable for many real-time or interactive applications such as Voice over IP (VoIP) and video conferencing. Also, the security that the return-routability procedure guarantees might not be sufficient for security-sensitive applications. And finally, periodically refreshing a registration at a correspondent node implies a hidden signaling overhead that may prevent mobile nodes from hibernation during times of inactivity.
リターン-routability手順の利点は、それが軽量であるということであり、あらかじめ共有された認証の材料を必要としません。 また、それは通信員ノードで状態を全く必要としません。 他方では、2つの可到達性テストが多くのボイス・オーバー IP(VoIP)やビデオ会議などのリアルタイムであるか対話的なアプリケーションに、容認できない移管遅れにつながることができます。 また、リターン-routability手順が保証するセキュリティもセキュリティ敏感なアプリケーションに十分でないかもしれません。 そして、通信員ノードで定期的に登録をリフレッシュすると、最終的に、不活発の倍の間に冬眠からモバイルノードを防ぐかもしれない隠されたシグナリングオーバーヘッドは含意されます。
Manifold enhancements for Route Optimizations have hence been suggested. This document describes and evaluates various strategies
したがって、Route Optimizationsのための多岐管増進は示されました。 このドキュメントは、様々な戦略を説明して、評価します。
Vogt & Arkko Informational [Page 3] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[3ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
on the basis of existing proposals. It is meant to provide a conceptual framework for further work, which was found to be inevitable in the context of Route Optimization. Many scientists volunteered to review this document. Their names are duly recorded in Section 7. Section 2 analyzes the strengths and weaknesses of Route Optimization and identifies potential objectives for enhancement. Different enhancement strategies are discussed, based on existing proposals, in Section 3. Section 4 discusses the different approaches and identifies opportunities for further research. Section 5 and Section 6 conclude the document.
既存の提案に基づいて。 それはさらなる仕事に概念の構成を提供することになっています。(それは、Route Optimizationの文脈で必然であることがわかりました)。 多くの科学者が、このドキュメントを再検討するのを買って出ました。 それらの名前は正しくセクション7に記録されます。 セクション2は、Route Optimizationの長所と短所を分析して、増進のために潜在的目的を特定します。 既存の提案に基づいてセクション3で異なったエンハンス戦略について議論します。 セクション4は、異なるアプローチについて論じて、さらなる調査の機会を特定します。 セクション5とセクション6はドキュメントを結論づけます。
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 MIP6 Working Group. At the time of this writing, some of the ideas presented in this document have been adopted by the Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) Working Group in the IETF.
このドキュメントはMobOpts Research Groupのコンセンサスを表します。 それは仕事の特定の領域で活発なResearch Groupメンバーによって見直されました。 彼らのいすの依頼で、このドキュメントはIETF MIP6作業部会の複数の活発な貢献者によって包括的に再検討されました。 この書くこと時点で、本書では提示された考えについて何かがIPのためにMobilityによって採用されました: パフォーマンス、IETFのシグナリングと移管最適化(mipshop)作業部会。
1.1. A Note on Public-Key Infrastructures
1.1. 公開鍵暗号基盤に関する注
Mobile IPv6 Route Optimization verifies a mobile node's authenticity through a routing property. An alternative is cryptographic authentication, which requires a binding between a node's identity and some sort of secret information. Although some proposals suggest installing shared secrets into end nodes when possible (see Section 3.10), pre-configuration is not an option for general Internet use for scalability reasons. Authentication based on a Public-Key Infrastructure (PKI) does not require pair-wise pre-configuration. Here, the secret information is the private component of a public/private-key pair, and the binding between a node's identity and private key exists indirectly through the cryptographic properties of public/private-key pairs and a binding between the identity and the public key. An authority trusted by both end nodes issues a certificate that effects this latter binding.
モバイルIPv6 Route Optimizationはルーティング所有地を通してモバイルノードの信憑性について確かめます。 代替手段は暗号の認証です。(その認証はノードのアイデンティティとある種の秘密の情報の間の結合を必要とします)。 いくつかの提案が、可能であるときに、共有秘密キーをエンドノードにインストールするのを示しますが(セクション3.10を見てください)、プレ構成はスケーラビリティ理由の一般的なインターネットの利用のためのオプションではありません。 公開鍵暗号基盤(PKI)に基づく認証は対状プレ構成を必要としません。 ここで、秘密の情報は1公衆/秘密鍵組の個人的なコンポーネントです、そして、ノードのアイデンティティと秘密鍵の間の結合はアイデンティティと公開鍵の間に公衆/秘密鍵組と結合の暗号の所有地を通して間接的に存在しています。 両方のエンドノードによって信じられた権威はこの後者の結合に作用する証明書を発行します。
Large-scale use of a PKI, however, was considered unsuitable for mobility management due to the following reasons.
しかしながら、PKIの大規模な使用は以下の理由のために移動性管理に不適当であると考えられました。
o There are differing opinions on whether a PKI could scale up to
hundreds of millions of mobile nodes. Some people argue they do,
as there are already examples of certification authorities
responsible for millions of certificates. But more important than
the expected increase in the number of certificates would be a
shift in application patterns. Nowadays, public-key cryptography
is used only for those applications that require strong,
cryptographic authentication.
o PKIが何億ものモバイルノードまで比例できたかどうかに関する異なった意見があります。 人々の中には何百万通もの証明書に責任がある証明当局に関する例が既にあって彼らがすると主張する人もいます。 しかし、証明書の数の予想された増加より重要であるのは、アプリケーションパターンでシフトでしょう。 この頃は、公開鍵暗号は強くて、暗号の認証を必要とするそれらのアプリケーションにだけ使用されます。
Vogt & Arkko Informational [Page 4] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[4ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
If it was used for mobility management as well, certificate checks
would become mandatory for any type of application, leading to
more checks per user. Busy servers with mobility support might be
unwilling to spent the processing resources required for this
depending on the service they provide.
それがまた、移動性管理に使用されるなら、証明書チェックはどんなタイプの適用にも義務的になるでしょうに、より多くの1ユーザあたりのチェックに通じて。 サポートが不本意であるかもしれない移動性がある忙しいサーバはこの依存に必要である処理リソースをそれらが提供するサービスに費やしました。
o Revoked certificates are identified on Certificate Revocation
Lists (CRLs), which correspondent nodes with mobility support
would have to acquire from certification authorities. CRLs must
be kept up to date, requiring periodic downloads. This and the
act of checking a certificate against a CRL create overhead that
some correspondent nodes might be unwilling to spend.
o 取り消された証明書はCertificate Revocation Lists(CRLs)で特定されます。(移動性サポートがある通信員ノードは証明当局からCertificate Revocation Listsを獲得しなければならないでしょう)。 周期的なダウンロードを必要として、CRLsは時代について行かなければなりません。 これとCRLに対して証明書をチェックする行為は費やすために不本意な状態でいくつかの通信員ノードがそうであるオーバーヘッドを作成します。
o Certificate verification may take some time and hence interrupt
ongoing applications. This can be disturbing from the user's
perspective, especially when Route Optimization starts in the
middle of a session, or the session is very short-term anyway.
o 証明書検証は、ある程度時間がかかっていて、したがって、進行中のアプリケーションを中断するかもしれません。 これはユーザの見解から不穏である場合があります、特に、Route Optimizationがセッションの途中で始まるか、またはセッションがとにかく非常に短期的であるときに。
o The bigger a PKI grows, the more attractive it becomes as an
attack target, endangering the Internet as a whole.
o PKIが、より大きくなればなるほど、全体でインターネットを危険にさらして、それは攻撃目標として、より魅力的になります。
o There is little experience with using home addresses as
identifiers in certificates. Although the home address could
theoretically be placed into a certificate's Subject Alternate
Name field, the entities responsible for IP-address assignment and
certification are usually not the same, and it may not be easy to
coordinate the two.
o 証明書には識別子としてホームアドレスを使用する経験がほとんどありません。 理論的に証明書のSubject Alternate Name分野にホームアドレスを置くことができましたが、通常、IP-アドレス課題に原因となる実体と証明は同じではありません、そして、2を調整するのは簡単でないかもしれません。
For these reasons, this document does not consider direct authentication of mobile nodes based on a PKI. Nevertheless, it does evaluate certificate-based techniques that make the problems identified above more tractable (see Section 3.12).
これらの理由で、このドキュメントはPKIに基づくモバイルノードのダイレクト認証を考えません。 それにもかかわらず、それは以上上で特定された問題を御しやすくする証明書ベースのテクニックを評価します(セクション3.12を見てください)。
1.2. A Note on Source Address Filtering
1.2. ソースアドレスフィルタリングに関する注
RFC 3775 uses care-of-address tests to probe a mobile node's presence at its claimed location. Alternatively, verification of care-of addresses may be based on infrastructure in the mobile node's local access network. For instance, the infrastructure can verify that the IP source addresses of all packets leaving the network are correct. "Ingress filtering" [38][43] provides this feature to the extent that it inspects the prefix of IP source addresses and ensures topological correctness. Network-access providers that use ingress filtering normally deploy the technique in their first-hop and site-exit routers. Similarly, ISPs may filter packets originating from a downstream network.
RFC3775は、要求された位置でモバイルノードの存在を調べるのにアドレスの注意テストを使用します。 あるいはまた、検証、注意、-、アドレスはモバイルノードのローカルのアクセスネットワークでインフラストラクチャに基づくかもしれません。 例えば、インフラストラクチャは、ネットワークを出るすべてのパケットのIPソースアドレスが正しいことを確かめることができます。 「イングレスフィルタリング」[38][43]はIPソースアドレスの接頭語を点検するという範囲にこの特徴を提供して、位相的な正当性を確実にします。 通常、イングレスフィルタリングを使用するネットワークアクセスプロバイダーがそれらの最初に、ホップとサイト出口のテクニックにルータを配布します。 同様に、ISPは川下のネットワークから発するパケットをフィルターにかけるかもしれません。
Vogt & Arkko Informational [Page 5] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[5ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
Ingress filtering may eventually provide a way to replace care-of- address tests. But there are still a number of uncertainties today:
イングレスフィルタリングが結局注意を取り替える方法を提供するかもしれない、-、アドレステストについて。 しかし、まだ、今日、多くの不明確なことがあります:
o By definition, ingress filtering can prevent source-address
spoofing only from those networks that do deploy the technique.
As a consequence, ingress filtering needs to be widely, preferably
universally, deployed in order to constitute Internet-wide
protection. As long as an attacker can get network access without
filters, all Internet nodes remain vulnerable.
o 定義上、イングレスフィルタリングは単にテクニックを配布するそれらのネットワークからソースアドレススプーフィングを防ぐことができます。 結果として、イングレスフィルタリングは、インターネット全体の保護を構成するために広く望ましくは一般に配布される必要があります。 攻撃者がフィルタなしでネットワークアクセスを得ることができる限り、すべてのインターネット接続装置が被害を受け易いままで残っています。
o There is little incentive for ISPs to deploy ingress filtering
other than conscientiousness. Legal or regulatory prescription as
well as financial motivation does not exist. A corrupt ISP might
even have a financial incentive not to deploy the technique, if
redirection-based denial-of-service (DoS) attacks using Route
Optimization ever become possible and are exploited for financial
gain. A similar issue was observed with, for example, email spam.
o ISPがイングレスが誠実さ以外のフィルタリングであると配布する誘因がほとんどありません。 財政的な動機と同様に法的であるか規定の処方箋は存在していません。 不正なISPには、テクニックを配布しない金銭的誘因がありさえするかもしれません、Route Optimizationを使用するリダイレクションベースのサービスの否定(DoS)攻撃が可能になって、金融上の利益に利用されるなら。 同様の問題は例えば、メールスパムで観測されました。
o Ingress filtering is most effective, and easiest to configure, at
the first-hop router. However, since only prefixes are checked,
the filters inevitably get less precise the further upstream they
are enforced. This issue is inherent in the technique, so the
best solution is checking packets as close to the originating
nodes as possible, preferably in the first-hop routers themselves.
o 最初に、ホップルータで、イングレスフィルタリングは、最も効果的であって、最も構成しやすいです。 しかしながら、接頭語だけがチェックされるので、フィルタは必然的にそれらが、より遠くに上流へ、実施されれば実施するほど、より正確でなくなります。 この問題はテクニックが固有であるので、最も良いソリューションは可能であるとしての起因するノードの近くようにパケットをチェックしています、望ましくは、最初に、ホップルータ自体で。
o A popular implementation of ingress filtering is "Reverse Path
Forwarding" (RPF). This technique relies on routes to be
symmetric, which is oftentimes the case between edge networks and
ISPs, but far less often between peering ISPs. Alternatives to
RPF are either manually configured access lists or dynamic
approaches that are more relaxed, and thereby less secure, than
RPF [43].
o イングレスフィルタリングのポピュラーな実装は「逆の経路推進」(RPF)です。 このテクニックは、左右対称になるようにルートを当てにします(しばしば縁のネットワークとISP、しかし、遠くによりしばしばじっと見るISPの間のケースです)。 RPFへの代替手段は手動で安全な状態でさらにリラックスするアクセスリストかダイナミックなアプローチが構成されて、その結果、以下を構成されます、RPF[43]より。
o Another problem with ingress filtering is multi-homing. When a
router attempts to forward to one ISP a packet with a source-
address prefix from another ISP, filters at the second ISP would
block the packet. The IETF seeks to find a way around this [39].
For instance, one could tunnel the packet to the topologically
correct ISP, or one could allow source-address changes by means of
a locator-identifier split [45].
o イングレスフィルタリングに関する別の問題はマルチホーミングです。 ルータが、ソースアドレス接頭語があるパケットを別のISPから1つのISPに送るのを試みるとき、第2ISPにおけるフィルタはパケットを妨げるでしょう。 IETFはこの[39]の周りで方法を見つけようとします。 例えば、1つがパケットにトンネルを堀るかもしれない、ISPを位相的に修正してください、1つはロケータ識別子分裂[45]によってソースアドレス変化を許容するかもしれません。
o Finally, RFC 3775 defines an Alternative Care-of Address option
that mobile nodes can use to carry a care-of address within a
Binding Update message outside of the IPv6 header. Such an
address is not subject to inspection by ingress filtering and
would have to be verified through other means [14].
o 最終的に、RFC3775が定義する、Alternative Care、-、モバイルノードが運ぶのに使用できるAddressオプション、注意、-、アドレス、Binding Updateの中では、IPv6ヘッダーの外で通信してください。 そのようなアドレスは、イングレスフィルタリングで点検を受けることがなくて、他の手段[14]で確かめられなければならないでしょう。
Vogt & Arkko Informational [Page 6] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[6ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
Although these problems are expected to get solved eventually, there is currently little knowledge on how applicable and deployable, as a candidate for care-of-address verification, ingress filtering will be. High investments or administrative hurdles could prevent a large, preferably universal deployment of ingress filtering, which would hinder Internet-wide protection, as mentioned in the first bullet. For these reasons, this document does not consider ingress filtering as a viable alternative to care-of-address tests, although things may be different in the future.
結局これらの問題が解決されると予想されますが、現在、フィルタリングがアドレス検査の注意、イングレスの候補としてどれくらい適切であるか、そして、配布可能になるかに関する知識がほとんどありません。 高い投資か管理ハードルが多、望ましくはインターネット全体の保護を妨げるだろうイングレスフィルタリングの普遍的な展開を防ぐかもしれません、最初の弾丸で言及されるように。 これらの理由で、このドキュメントは、イングレスフィルタリングが実行可能な代案であるとアドレスの注意テストにみなしません、いろいろなことが将来、異なるかもしれませんが。
2. Objectives for Route Optimization Enhancement
2. 経路最適化増進のための目的
Wireless environments with frequently moving nodes feature a number of salient properties that distinguish them from environments with stationary nodes or nodes that move only occasionally. One important aspect is the efficiency of mobility management. Nodes may not bother about a few round-trip times of handoff latency if they do not change their point of IP attachment often. But the negative impact that a mobility protocol can have on application performance increases with the level of mobility. Therefore, in order to maximize user satisfaction, it is important to reduce the handoff latency that the mobility protocol adds to existing delays in other places of the network stack. A related issue is the robustness of the mobility protocol, given that temporary outage of mobility support can render mobile nodes incapable of continuing to communicate.
頻繁に感動的なノードのワイヤレスの環境は時折だけ移行する静止したノードかノードで環境とそれらを区別する多くの顕著な特性を特徴とします。 1つの重要な一面が移動性管理の効率です。 ノードはしばしば自己のIP付属のポイントを変えるというわけではないなら移管潜在の往復の数倍を心配しないかもしれません。 しかし、移動性のレベルに従って、移動性プロトコルがアプリケーション性能のときに持つことができる負の衝撃は増えます。 したがって、ユーザ満足を最大にして、移動性プロトコルがネットワークスタックの他の場所の既存の遅れに加えるのは、移管レイテンシを減少させるために重要です。 関連する問題は移動性プロトコルの丈夫さです、交信し続けることができないのに移動性サポートの一時的な供給停止がモバイルノードを表すことができるなら。
Furthermore, the wireless nature of data transmissions makes it potentially easier for an attacker to eavesdrop on other nodes' data or send data on behalf of other nodes. While applications can usually authenticate and encrypt their payload if need be, similar security measures may not be feasible for signaling packets of a mobility protocol, in particular if communicating end nodes have no pre-existing relationship.
その上、データ伝送のワイヤレスの本質で、攻撃者が他のノードを代表して他のノードのデータか送信データを立ち聞きするのが潜在的により簡単になります。 必要なら、通常、アプリケーションがそれらのペイロードを認証して、暗号化できる間、移動性プロトコルのシグナリングパケットには、同様の安全策が可能でないかもしれない、交信するなら、エンドノードに特に、先在しない関係があります。
Given the typically limited bandwidth in a wireless medium, resources ought to be spent in an economic matter. This is especially important for the amount of signaling that a mobility protocol requires.
ワイヤレスの媒体における通常限られた帯域幅を考えて、リソースは経済件に費やされるべきです。 移動性プロトコルが必要とするシグナリングの量に、これは特に重要です。
Endeavors to enhance RFC 3775 Route Optimization generally strive for reduced handoff latency, higher security, lower signaling overhead, or increased protocol robustness. These objectives are herein discussed from a requirements perspective; the technical means to reach the objectives is not considered, nor is the feasibility of achieving them.
一般に、RFC3775Route Optimizationを高める努力は減少している移管潜在、より高いセキュリティ、低いシグナリングオーバーヘッド、または増強されたプロトコル丈夫さを求めて努力します。 要件見解からこれらの目的についてここに議論します。 目標を達成する技術手段は、考えられないで、それらを達成することに関する実現の可能性です。
Vogt & Arkko Informational [Page 7] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[7ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
2.1. Latency Optimizations
2.1. 潜在最適化
One important objective for improving Route Optimization is to reduce handoff latencies. Assuming that the home-address test dominates the care-of-address test in terms of latency, a Mobile IPv6 handoff takes one round-trip time between the mobile node and the home agent for the home registration, a round-trip time between the mobile node and the home agent plus a round-trip time between the home agent and the correspondent node for the home-address test, and a one-way time from the mobile node to the correspondent node for the propagation of the Binding Update message. The first packet sent to the new care-of address requires an additional one-way time to propagate from the correspondent node to the mobile node. The mobile node can resume communications right after it has dispatched the Binding Update message. But if it requests a Binding Acknowledgment message from the correspondent node, communications are usually delayed until this is received.
Route Optimizationを改良するための1つの重要な目的は移管潜在を減少させることです。 ホームアドレステストが潜在に関してアドレスの注意テストを支配すると仮定して、モバイルIPv6移管は本国登録とモバイルノードとホームのエージェントの間の往復の時間とホームアドレステストのためのホームのエージェントと通信員ノードと、Binding Updateメッセージの伝播のための一方通行のモバイルノードから通信員ノードまでの時間の間の往復の時間のために往復の1回の間、モバイルノードとホームのエージェントをはさみます。 最初のパケットが新しさに発信した、注意、-、アドレスは通信員ノードからモバイルノードまで伝播する追加一方通行の時間を必要とします。 Binding Updateメッセージを派遣したまさしく後にモバイルノードはコミュニケーションを再開できます。 しかし、通信員ノードからBinding Acknowledgmentメッセージを要求するなら、これが受け取られているまで、通常、コミュニケーションは遅れます。
These delays are additive and are not subsumed by other delays at the IP layer or link layer. They can cause perceptible quality degradations for interactive and real-time applications. TCP bulk- data transfers are likewise affected since long handoff latencies may lead to successive retransmission timeouts and degraded throughput.
これらの遅れは、付加的であり、IP層かリンクレイヤの他の遅れによって包括されていません。 彼らは対話的でリアルタイムのアプリケーションのための知覚可能な品質劣化を引き起こす場合があります。 TCP嵩長い移管潜在が連続した再送タイムアウトと降格しているスループットにつながるかもしれないので、データ転送は同様に影響を受けます。
2.2. Security Enhancements
2.2. セキュリティ増進
The return-routability procedure was designed with the objective to provide a level of security that compares to that of today's non- mobile Internet [46]. As such, it protects against impersonation, denial of service, and redirection-based flooding attacks that would not be possible without Route Optimization. This approach is based on an assumption that a mobile Internet cannot become any safer than the non-mobile Internet.
リターン-routability手順は目的で設計されていて、今日の非モバイルインターネットの[46]のものと比較されるセキュリティのレベルを提供しました。 そういうものとして、それはRoute Optimizationなしで可能でないものまね、サービスの否定、およびリダイレクションベースのフラッディング攻撃から守ります。 このアプローチはモバイルインターネットが非モバイルインターネットより少しも安全になることができないという仮定に基づいています。
Applications that require a security level higher than what the return-routability procedure can provide are generally advised to use end-to-end protection such as IPsec or Transport Layer Security (TLS). But even then they are vulnerable to denial of service. This motivates research for stronger Route Optimization security. Security enhancements may also become necessary if future technological improvements mitigate some of the existing mobility- unrelated vulnerabilities.
一般に、リターン-routability手順が提供できるものより高いセキュリティー・レベルを必要とするアプリケーションがIPsecかTransport Layer Security(TLS)などの終わりから終わりへの保護を使用するように教えられます。 しかし、その時でさえ、それらはサービスの否定に被害を受け易いです。 これは、より強いRoute Optimizationセキュリティのための研究を動機づけます。 また、今後の技術の進歩が既存の移動性関係ない脆弱性のいくつかを緩和するなら、セキュリティ増進は必要になるかもしれません。
One particular issue with Route Optimization is location privacy because route-optimized packets carry both home and care-of addresses in plaintext. A standard workaround is to fall back to Bidirectional Tunneling when location privacy is needed. Packets with the care-of address are then transferred only between the mobile node and the
そして、ルートで最適化されたパケットがともに家まで運ばれるのでRoute Optimizationの特定の1冊が位置のプライバシーである、注意、-、平文では、扱います。 標準の回避策は位置のプライバシーが必要であるときに、Bidirectional Tunnelingへ後ろへ下がることです。 そしてパケット、注意、-、次に、モバイルノードだけの間にアドレスを移す。
Vogt & Arkko Informational [Page 8] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[8ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
home agent, where they can be encrypted through IPsec Encapsulating Security Payload (ESP) [42]. But even Bidirectional Tunneling requires the mobile node to periodically re-establish IPsec security associations with the home agent so as to become untraceable through Security Parameter Indexes (SPIs).
IPsec Encapsulating Security有効搭載量(超能力)[42]を通してそれらを暗号化できるところのホームのエージェント。 しかし、Bidirectional Tunnelingさえ、Security Parameter Indexes(SPIs)を通して追跡不可能になるようにホームのエージェントとのIPsecセキュリティ仲間を定期的に復職させるためにモバイルノードを必要とします。
2.3. Signaling Optimizations
2.3. シグナリング最適化
Route Optimization requires periodic signaling even when the mobile node does not move. The signaling overhead amounts to 7.16 bits per second if the mobile node communicates with a stationary node [6]. It doubles if both peers are mobile. This overhead may be negligible when the nodes communicate, but it can be an issue for mobile nodes that are inactive and stay at the same location for a while. These nodes typically prefer to go to standby mode to conserve battery power. Also, the periodic refreshes consume a fraction of the wireless bandwidth that one could use more efficiently. Optimizations for reduced signaling overhead could mitigate these issues.
モバイルノードが移行しないと、ルートOptimizationは周期的なシグナリングを必要とします。 モバイルノードが静止したノード[6]とコミュニケートするなら、シグナリングオーバーヘッドは7.16のbpsに達します。 両方の同輩モバイルであるなら、それは倍増します。 ノードが交信するとき、このオーバーヘッドが取るにたらないかもしれませんが、それは、不活発なモバイルノードのための問題であり、しばらく、同じ位置にいることができます。 これらのノードは、電池残量を保存しに待ち受け状態に行くのを通常好みます。 また、周期的をリフレッシュします。1つが、より効率的に使用できたワイヤレス帯域幅の部分を消費してください。 減少しているシグナリングオーバーヘッドのための最適化はこれらの問題を緩和するかもしれません。
2.4. Robustness Enhancements
2.4. 丈夫さ増進
Route Optimization could conceptually enable continued communications during periods of temporary home-agent unavailability. The protocol defined in RFC 3775 does not achieve this independence, however, as the home agent plays an active role in the return-routability procedure. Appropriate enhancements could increase the independence from the home agent and thus enable robust Route Optimization even in the absence of the home agent.
ルートOptimizationは一時的なホームエージェント使用不能の期間、概念的に継続的なコミュニケーションを可能にすることができました。 しかしながら、ホームのエージェントがリターン-routability手順で活動するとき、RFC3775で定義されたプロトコルはこの独立を実現しません。 適切な増進は、ホームのエージェントから独立を増強して、その結果、ホームのエージェントがないときでさえ強健なRoute Optimizationを有効にするかもしれません。
3. Enhancements Toolbox
3. 増進道具箱
A large body of effort has recently gone into improving Mobile IPv6 Route Optimization. Some of the proposed techniques are modifications to the return-routability procedure, while others replace the procedure by alternative mechanisms. Some of them operate end-to-end; others introduce network-side mobility support. In most cases, it is the combination of a set of techniques that is required to gain a complete -- that is, efficient and secure -- route-optimization mechanism.
取り組みの大きいボディーは最近、モバイルIPv6 Route Optimizationを改良するために入りました。 提案されたテクニックのいくつかがリターン-routability手順への変更です、他のものは代替のメカニズムに手順を置き換えますが。彼らの何人かが終わらせる端を操作します。 他のものはネットワークサイド移動性サポートを導入します。 多くの場合、それは完全--すなわち、効率的で安全--の経路最適化メカニズムを獲得するのに必要である1セットのテクニックの組み合わせです。
Vogt & Arkko Informational [Page 9] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[9ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
3.1. IP Address Tests
3.1. IPアドレステスト
RFC 3775 uses IP-address tests to ensure that a mobile node is live and on the path to a specific destination address: The home-address test provides evidence that the mobile node is the legitimate owner of its home address; the care-of-address test detects spoofed care-of addresses and prevents redirection-based flooding attacks. Both tests can be performed in parallel.
RFC3775は、モバイルノードが確実にライブになるようにして、特定の目的地への経路で以下を扱うのにIP-アドレステストを使用します。 ホームアドレステストはモバイルノードがホームアドレスの正統の所有者であるという証拠を提供します。 偽造されて、アドレスの注意テストが検出する、注意、-、リダイレクションベースのフラッディング攻撃を扱って、防ぎます。 平行で両方のテストを実行できます。
A home-address test should be initiated by the mobile node so that the correspondent node can delay state creation until the mobile node has authenticated. The care-of-address test can conceptually be initiated by either side. It originates with the mobile node in RFC 3775, but with the correspondent node in [16] and [22]. The correspondent-node-driven approach suggests itself when authentication is done through other means than a home-address test.
ホームアドレステストは、認証されて、通信員ノードがモバイルノードが遅らせるまで州の作成を遅らせることができるように、モバイルノードによって開始されるべきです。 どちらの側は概念的にアドレスの注意テストを開始できます。 それは、RFC3775にモバイルノードを発しますが、通信員ノードが[16]と[22]にある状態で、発します。 ホームアドレステスト以外の手段で認証すると、運転された通信員ノードアプローチは連想されます。
Important advantages of IP-address tests are zero-configurability and the independence of ancillary infrastructure. As a disadvantage, IP-address tests can only guarantee that a node is on the path to the probed address, not that the node truly owns this address. This does not lead to new security threats, however, because the types of attacks that an on-path attacker can do with Route Optimization are already possible in the non-mobile Internet [46].
IP-アドレステストの重要な利点は、無configurabilityと付属のインフラストラクチャからの独立です。 不都合として、IP-アドレステストは、調べられたアドレスにはノードが経路にあるのを保証できるだけであって、本当に、ノードはこのアドレスを所有しているというわけではありません。 経路の攻撃者がRoute Optimizationと共にできる攻撃がタイプが非モバイルインターネット[46]で既に可能であるので、しかしながら、これは新しい軍事的脅威に通じません。
3.2. Protected Tunnels
3.2. 保護されたTunnels
RFC 3775 protects certain signaling messages, exchanged between a mobile node and its home agent, through an authenticated and encrypted tunnel. This prevents unauthorized nodes on that path, including eavesdroppers in the mobile node's wireless access network, from listening in on these messages.
RFC3775は認証されて暗号化されたトンネルを通ってモバイルノードとそのホームのエージェントの間で交換されたあるシグナリングメッセージを保護します。 これはその経路の権限のないノードを防ぎます、モバイルノードのワイヤレス・アクセスネットワークに立ち聞きする者を含んでいて、これらのメッセージで聴くのから。
Given that a pre-existing end-to-end security relationship between the mobile node and the correspondent node cannot generally be assumed, this protection exists only for the mobile node's side. If the correspondent node is immobile, the path between the home agent and the correspondent node remains unprotected. This is a path between two stationary nodes, so all types of attacks that a villain could wage on this path are already possible in the non-mobile Internet. In case the correspondent node is mobile, it has its own home agent, and only the path between the two (stationary) home agents remains unprotected.
一般にモバイルノードと通信員ノードの間の終わりから終わりへの先在の安全保障関係を想定できないなら、この保護はモバイルノードの側だけに存在しています。 通信員ノードが不動であるなら、ホームのエージェントと通信員ノードの間の経路は保護がないままで残っています。 これが2つの静止したノードの間の経路であるので、悪人がこの経路で行うことができたすべてのタイプの攻撃は非モバイルインターネットで既に可能です。 通信員ノードモバイルであるといけないので、それには、それ自身のホームのエージェントがいます、そして、2人の(静止する)のホームのエージェントの間の経路だけが保護がないままで残っています。
Vogt & Arkko Informational [Page 10] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[10ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
3.3. Optimistic Behavior
3.3. 楽観的な振舞い
Many Mobile IPv6 implementations [29][31] defer a correspondent registration until the associated home registration has been completed successfully. In contrast to such "conservative" behavior, a more "optimistic" approach is to begin the return-routability procedure in parallel with the home registration [52]. Conservative behavior avoids a useless return-routability procedure in case the home registration fails. This comes at the cost of additional handoff delay when the home registration is successful. Optimistic behavior saves this delay, but the return-routability procedure will be in vain should the corresponding home registration be unsuccessful.
関連本国登録が首尾よく終了するまで、多くのモバイルIPv6実装[29][31]が通信員登録を延期します。 そのような「保守的な人」振舞いと対照して、より「楽観的な」アプローチは本国登録[52]と平行してリターン-routability手順を始めることです。 本国登録が失敗するといけないので、保守的な振舞いは役に立たないリターン-routability手順を避けます。 本国登録がうまくいっているとき、これは追加移管遅れの費用で来ます。 楽観的な振舞いはこの遅れを保存しますが、対応する本国登録が失敗しているなら、リターン-routability手順は空しくなるでしょう。
While a parallelization of the home registration and the return- routability procedure is feasible within the bounds of RFC 3775, the specification does not permit mobile nodes to continue with the correspondent registration, by sending a Binding Update message to the correspondent node, until a Binding Acknowledgment message indicating successful home registration has been received. This is usually not a problem because the return-routability procedure is likely to take longer than the home registration anyway. However, some optimizations (see Section 3.4) reduce the delay caused by the return-routability procedure. A useful improvement is then to allow Binding Update messages to be sent to correspondent nodes even before the home registration has been acknowledged.
本国登録とリターンroutability手順の並列化がRFC3775の領域の中で可能である間、仕様は、モバイルノードが通信員登録を続行することを許可しません、Binding Updateメッセージを通信員ノードに送ることによって、うまくいっている本国登録を示すBinding Acknowledgmentメッセージを受け取るまで。 リターン-routability手順が本国登録より長い間とにかくかかりそうであるので、通常、これは問題ではありません。 しかしながら、いくつかの最適化(セクション3.4を見る)がリターン-routability手順で引き起こされた遅れを減少させます。 役に立つ改良はそして、本国登録が承諾される前にさえ通信員ノードに送られるべきメッセージをBinding Updateに許容することです。
The drawback of optimistic behavior is that a lost, reordered, or rejected Binding Update message can cause data packets to be discarded. Nevertheless, packet loss would have similar negative impacts on conservative approaches, so the mobile node needs to be prepared for the possible loss of these packets in any case.
楽観的な振舞いの欠点は無くなっているか、再命令されたか、拒絶されたBinding Updateメッセージでデータ・パケットを捨てることができるということです。 それにもかかわらず、パケット損失は保守的なアプローチに同様の負の衝撃を持っているでしょう、したがって、モバイルノードがどのような場合でも、これらのパケットの可能な損失のために準備される必要があります。
3.4. Proactive IP Address Tests
3.4. IPアドレスがテストであると予測してください。
The critical handoff phase, during which the mobile node and the correspondent node cannot fully communicate, spans the home registration and the correspondent registration, including the return-routability procedure. One technique to shorten this phase is to accomplish part of the signaling proactively before the handoff. In particular, the home-address test can be done in advance without violating the specifications of RFC 3775 [52][51].
きわどい移管段階(モバイルノードと通信員ノードは、完全に交信できるというわけではない)は本国登録と通信員登録にかかっています、リターン-routability手順を含んでいて。 このフェーズを短くする1つのテクニックは移管の前にシグナリングの一部を予測して達成することです。 RFC3775[52][51]の仕様に違反しないで、特に、あらかじめ、ホームアドレステストができます。
In order to have a fresh home keygen token ready for a future handoff, the mobile node should initiate a proactive home-address test at least once per token lifetime, that is, every 3.5 minutes. This does at most double the signaling overhead spent on home-address tests given that correspondent registrations must be refreshed every
新鮮なホームkeygenトークンを今後の移管の準備ができるようにするように、モバイルノードは少なくともトークン生涯に一度先を見越すホームアドレステスト、すなわち、3.5分毎を開始するはずです。 これが通信員登録証明書をリフレッシュしなければならないならホームアドレステストに費やされたシグナリングオーバーヘッドを高々倍にする、あらゆる
Vogt & Arkko Informational [Page 11] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[11ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
7 minutes even when the mobile node does not move for a while. An optimization is possible where the mobile node's local link layer can anticipate handoffs and trigger the home-address test in such a case. [6] or [54] reduce the frequency of home-address tests even further. Proactive care-of-address tests are possible only if the mobile node is capable of attaching to two networks simultaneously. Dual attachment is possible if the link-layer technology enables it with a single interface [10], or if the mobile node is endowed with multiple interfaces [7].
モバイルノードでさえあるときに、7分はしばらく、移行しません。 モバイルノードの地方のリンクレイヤがこのような場合にはhandoffsを予期して、ホームアドレステストの引き金となることができるところで最適化は可能です。 [6]か[54]がホームアドレステストの頻度をさらにさえ減少させます。 モバイルノードが同時に2つのネットワークに付くことができる場合にだけ、先を見越すアドレスの注意テストは可能です。 リンクレイヤ技術が単一のインタフェース[10]でそれを可能にするか、またはモバイルノードが複数のインタフェース[7]に恵まれているなら、二元的な付属は可能です。
3.5. Concurrent Care-of Address Tests
3.5. 同時発生、注意、-、テストを扱ってください。
Without the assumption that a mobile node can simultaneously attach to multiple networks, proactive care-of-address tests, executed prior to handoff, are not an option. A correspondent node may instead authorize a mobile node to defer the care-of-address test until an early, tentative binding has been registered [52][51]. This in combination with a technique to eliminate the handoff delay of home- address tests (see Section 3.4 and Section 3.9) facilitates early resumption of bidirectional communications subsequent to handoff. The care-of address is called "unverified" during the concurrent care-of-address test, and it is said to be "verified" once the correspondent node has obtained evidence that the mobile node is present at the address. A tentative binding's lifetime can be limited to a few seconds.
モバイルノードが同時に複数のネットワークに付くことができるという仮定がなければ、移管の前に実行された先を見越すアドレスの注意テストはオプションではありません。 通信員ノードは、モバイルノードがアドレスの注意テストを延期するのを早くて、一時的な結合が登録された[52][51]になるまで代わりに認可するかもしれません。 ホームアドレステスト(セクション3.4とセクション3.9を見る)の移管遅れを排除するテクニックと組み合わせたこれは移管へのその後の双方向のコミュニケーションの早めの再開を容易にします。 注意、-、アドレス、アドレスの注意がテストして、対応であっているノードがいったん、モバイルノードがアドレスに存在しているという証拠を得ると「確かめられ」て、それが言われている同時発生の間、"非検証"であると呼ばれます。 数秒まで一時的な結合の生涯を制限できます。
Home-address tests must not be accomplished concurrently, however, given that they serve the purpose of authentication. They guarantee that only the legitimate mobile node can create or update a binding pertaining to a particular home address.
しかしながら、認証の目的に役立つなら、同時にホームアドレステストを実行してはいけません。 彼らは、正統のモバイルノードだけが特定のホームアドレスに関係する結合を作成するか、またはアップデートできるのを保証します。
Vogt & Arkko Informational [Page 12] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[12ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
mobile node home agent correspondent node
| | |
| | |
|--Home Test Init------>|---------------------->|
| | |
| | |
|<----------------------|<-----------Home Test--|
| | |
| |
~~+~~ handoff |
| |
|--Early Binding Update------------------------>| -+-
|--Care-of Test Init -------------------------->| |
| | |
| | | care-of
|<----------------Early Binding Acknowledgment--| | address
|<-------------------------------Care-of Test---| | unverified
| | |
| | |
|--Binding Update------------------------------>| -+-
| |
| |
|<----------------------Binding Acknowledgment--|
| |
モバイルノードホームエージェント通信員ノード| | | | | | |--ホームテストイニット------>|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、| |<----------------------|<-----------家では、テストしてください--| | | | | | ~~+ ~~移管| | | |--事前バインディングアップデート------------------------>| -+- |--注意、-、イニットをテストしてください。-------------------------->|、|、|、|、|、|、|、| 注意、-| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--事前バインディング承認--| | アドレス|<-------------------------------注意、-、テスト---| | 非検証しました。| | | | | | |--拘束力があるアップデート------------------------------>| -+- | | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--拘束力がある承認--| | |
Figure 1: Concurrent Care-of Address Tests
図1: 同時発生、注意、-、テストを扱ってください。
Figure 1 illustrates how concurrent care-of-address tests are used in [52][51]: As soon as the mobile node has configured a new care-of address after a handoff, it sends to the correspondent node an Early Binding Update message. Only a home keygen token, obtained from a proactive home-address test, is required to sign this message. The correspondent node creates a tentative binding for the new, unverified care-of address when it receives the Early Binding Update message. This address can be used immediately. The mobile node finally sends a (standard) Binding Update message to the correspondent node when the concurrent care-of-address test is complete. Credit-Based Authorization (see Section 3.7) prevents misuse of care-of addresses while they are unverified.
図1は同時発生のアドレスの注意テストが[52][51]でどう使用されるかを例証します: モバイルノードが新しい状態でaを構成するとすぐに、注意、-、移管の後のアドレス、それはEarly Binding Updateメッセージを通信員ノードに送ります。 先を見越すホームアドレステストから得られたホームkeygenトークンだけが、このメッセージに署名するのに必要です。 通信員ノードが新しく、非検証にされるののための一時的な結合を作成する、注意、-、それであるときに、アドレスはEarly Binding Updateメッセージを受け取ります。 すぐに、このアドレスを使用できます。 同時発生のアドレスの注意テストが完全であるときに、モバイルノードは最終的に(標準)の拘束力があるUpdateメッセージを通信員ノードに送ります。 ベースのクレジットAuthorization(セクション3.7を見る)が誤用を防ぐ、注意、-、アドレスはそれらである間、非検証されます。
3.6. Diverted Routing
3.6. 紛らされたルート設定
Given that a home registration is faster than a correspondent registration in the absence of additional optimizations, the mobile node may request its traffic to be routed through the home address until a new binding has been set up at the correspondent node [52][51]. The performance of such diverted routing depends on the propagation properties of the involved routes, however.
本国登録が追加最適化がないとき通信員登録より速いなら、モバイルノードは、新しい結合が通信員ノード[52][51]でセットアップされるまでホームアドレスを通して発送されるようトラフィックに要求するかもしれません。 しかしながら、そのような紛らされたルーティングの性能はかかわったルートの伝播所有地に依存します。
Vogt & Arkko Informational [Page 13] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[13ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
For packets to be diverted via the home address, signaling is necessary with both the home agent and the correspondent node. The home agent must be informed about the new care-of address so that it can correctly forward packets intercepted at the home address. The correspondent node continues to send packets to the old care-of address until it receives a Binding Update message indicating that the current binding is no longer valid and ought to be removed. This request requires authentication through a home-address test in order to prevent denial of service by unauthorized nodes. The test can be accomplished in a proactive way (see Section 3.4).
パケットがホームアドレスで紛らされるために、シグナリングがホームのエージェントと通信員ノードの両方によって必要です。 ホームのエージェントは新しさに関して知識があるに違いない、注意、-、正しくホームアドレスで妨害されたパケットを進めることができるように、扱います。 通信員ノードが、パケットを老人に送り続けている、注意、-、Binding Updateメッセージを受け取るまで、アドレスを現在の結合がもう有効でないことを示して、取り除くべきです。 この要求は、権限のないノードでサービスの否定を防ぐためにホームアドレステストで認証を必要とします。 先を見越す方法でテストを実行できます(セクション3.4を見てください)。
The mobile node may send packets via the home address as soon as it has dispatched the Binding Update message to the home agent. It may send outgoing packets along the direct path once a Binding Update message for the new care-of address has been sent to the correspondent node.
Binding Updateメッセージをホームのエージェントに派遣するとすぐに、モバイルノードはホームアドレスでパケットを送るかもしれません。 a Binding Updateがいったん通信すると新しさのために直接路に沿って出発しているパケットを送るかもしれない、注意、-、通信員ノードにアドレスを送りました。
It depends on the propagation latency on the end-to-end path via the home agent relative to the latency on the direct path for how long the correspondent node should continue to send packets to the home address. If the former path is slow, it may be better to queue some of the packets until the correspondent registration is complete and packets can be sent along the direct route.
通信員ノードが、どれくらい長い間パケットをホームアドレスに送り続けるはずであるように、それは直接路の潜在に比例したホームのエージェントを通して終わりから端への経路の伝播潜在によるか。 前の経路が遅いなら、通信員登録が完全であり、直航路に沿ってパケットを送ることができるまでいくつかのパケットを列に並ばせるほうがよいかもしれません。
3.7. Credit-Based Authorization
3.7. クレジットベースの承認
Concurrent care-of-address tests (see Section 3.5) require protection against spoofed unverified care-of addresses and redirection-based flooding attacks. Credit-Based Authorization [50] is a technique that provides such protection based on the following three hypotheses:
偽造されることに対するテスト(セクション3.5を見る)が必要とするアドレスの同時発生の注意保護が非検証された、注意、-、アドレスとリダイレクションベースのフラッディング攻撃。 ベースのクレジットAuthorization[50]は以下の3つの仮説に基づくそのような保護を提供するテクニックです:
1. A flooding attacker typically seeks to somehow multiply the
packets it assembles for the purpose of the attack because
bandwidth is an ample resource for many attractive victims.
1. 帯域幅が多くの魅力的な犠牲者への十分なリソースであるので、氾濫攻撃者はどうにかそれが攻撃の目的のために組み立てるパケットを通常掛けようとします。
2. An attacker can always cause unamplified flooding by generating
bogus packets itself and sending them to its victim directly.
2. 攻撃者は、それ自体でにせのパケットを生成して、直接それらを犠牲者に送ることによって、非増幅された氾濫をいつも引き起こす場合があります。
3. Consequently, the additional effort required to set up a
redirection-based flooding attack pays off for the attacker only
if amplification can be obtained this way.
3. その結果、この道に増幅を得ることができる場合にだけ、リダイレクションベースのフラッディング攻撃をセットアップするのに必要である追加取り組みは攻撃者にうまく行きます。
On this basis, rather than eliminating malicious packet redirection in the first place, Credit-Based Authorization prevents any amplification that can be reached through it. This is accomplished by limiting the data a correspondent node can send to an unverified care-of address of a mobile node by the data that the correspondent
第一に悪意があるパケットリダイレクションを排除するよりむしろこのベースでは、ベースのCredit Authorizationはそれを通して達することができるどんな増幅も防ぎます。 これが通信員ノードが発信できるデータを制限することによって達成される、非検証、注意、-、それはデータによるモバイルノードを扱う、通信員
Vogt & Arkko Informational [Page 14] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[14ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
node has recently received from that mobile node. (See Section 3.5 for a definition on when a care-of address is verified and when it is unverified.) A redirection-based flooding attack is thus no more attractive than pure direct flooding, where the attacker itself sends bogus packets to the victim. It is actually less attractive given that the attacker must keep Mobile IPv6 state to coordinate the redirection.
ノードは最近、そのモバイルノードから受信しました。 (いつa定義に関してセクション3.5を見てくださいか、注意、-、アドレス、確かめられて、それが非検証されると) その結果、リダイレクションベースのフラッディング攻撃は、攻撃者自身がにせのパケットを犠牲者に送るところで浸水しながら、魅力的であるというよりもダイレクトに純粋です。 攻撃者がリダイレクションを調整するためにモバイルIPv6状態を維持しなければならないなら、実際にそれほど魅力的ではありません。
mobile node correspondent node
| |
| |
address |--data----------------->| credit += size(data)
verified | |
|--data----------------->| credit += size(data)
|<-----------------data--| don't change credit
| |
address + address change |
unverified |<-----------------data--| credit -= size(data)
|--data----------------->| credit += size(data)
|<-----------------data--| credit -= size(data)
| |
|<-----------------data--| credit -= size(data)
| X credit < size(data)
| | ==> Do not send!
address | |
verified |<-----------------data--| don't change credit
| |
モバイルノード通信員ノード| | | | アドレス|--データ----------------->| サイズ(データ)が確かめたクレジット+=| | |--データ----------------->| クレジット+=サイズ(データ)| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--データ--| クレジットを変えないでください。| | アドレス+アドレス変化| 非検証しました。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--データ--| クレジット-=サイズ(データ)|--データ----------------->| クレジット+=サイズ(データ)| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--データ--| クレジット-=サイズ(データ)| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--データ--| クレジット-=サイズ(データ)| Xクレジット<サイズ(データ)| | ==>はアドレスを送りません。| | 確かめられます。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--データ--| クレジットを変えないでください。| |
Figure 2: Credit-Based Authorization
図2: クレジットベースの承認
Figure 2 illustrates Credit-Based Authorization for an exemplifying exchange of data packets: The correspondent node measures the bytes received from the mobile node. When the mobile node registers a new care-of address, the correspondent node labels this address "unverified" and sends packets there as long as the sum of the packet sizes does not exceed the measured, received data volume. A concurrent care-of-address test is meanwhile performed. Once the care-of address has been verified, the correspondent node relabels the address from "unverified" to "verified". Packets can then be sent to the new care-of address without restrictions. When insufficient credit is left while the care-of address is still "unverified", the correspondent node stops sending further packets to the address until the verification completes. The correspondent node may drop these packets, direct them to the mobile node's home address, or buffer them for later transmission when the care-of address is verified. Figure 2 does not show Mobile IPv6 signaling packets.
図2はデータ・パケットの例示交換のためにベースのCredit Authorizationを例証します: 通信員ノードはモバイルノードから受け取られたバイトを測定します。 モバイルノードが新しい状態でaを登録する、注意、-、アドレス、パケットサイズの合計が測定されて、容認されたデータボリュームを超えていない限り、通信員ノードは"非検証"であったこのアドレスを分類して、パケットをそこに送ります。 一方、同時発生のアドレスの注意テストは実行されます。 一度、注意、-、アドレス、確かめられて、通信員ノードが"非検証"から「確かめられる」までアドレスを再ラベルするということでした。 次に、パケットを新しさに送ることができる、注意、-、制限のないアドレス。 いつ、不十分なクレジットがあるかがいなくなった、注意、-、アドレス、静かな「非検証(検証まで一層のパケットをアドレスに送ると終了する通信員ノード停止)でした」。 通信員ノードがこれらのパケットを下げるかもしれなくて、ダイレクトそれらがモバイルノードのホームアドレス、または後のトランスミッションのための、よりもみ皮製のそれらにいつか、注意、-、アドレス、確かめられます。 図2は、モバイルIPv6がパケットに合図するのを示しません。
Vogt & Arkko Informational [Page 15] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[15ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
The correspondent node ensures that the mobile node's acquired credit gradually decreases over time. This "aging" prevents the mobile node from building up credit over a long time. A malicious node with a slow Internet connection could otherwise provision for a burst of redirected packets that does not relate to its own upstream capacity.
通信員ノードは、モバイルノードの後天的なクレジットが時間がたつにつれて徐々に減少するのを確実にします。 この「年をとること」は、モバイルノードが長い間上でクレジットを確立するのを防ぎます。 遅いインターネット接続との悪意があるノードはそうでなければ、それ自身の上流の容量に関連しない向け直されたパケットの炸裂への支給をそうすることができました。
Allocating the mobile node's credit based on the packets that the mobile node sends and reducing the credit based on packets that the mobile node receives is defined as "Inbound Mode". (The correspondent node is in control of credit allocation, and it computes the credit based on inbound packets received from the mobile node.) A nice property of Inbound Mode is that it does not require support from the mobile node. The mobile node neither needs to understand that Credit-Based Authorization is effective at the correspondent node, nor does it have to have an idea of how much credit it has at a particular point in time.
モバイルノードが送るパケットに基づくモバイルノードのクレジットを割り当てて、モバイルノードが受けるパケットに基づくクレジットを減少させるのは「本国行きのモード」と定義されます。 (通信員ノードはクレジット配分のコントロール中であり、それはモバイルノードから受け取られた本国行きのパケットに基づくクレジットを計算します。) Inbound Modeの良い特性はモバイルノードから支持を要しないということです。 モバイルノードはベースのCredit Authorizationが通信員ノードで有効であり、それにはそれが時間内にどのくらいのクレジットに特定のポイントに攻撃するかという考えがある必要はないのをどちらも理解する必要はありません。
Inbound Mode works fine with applications that send comparable data volumes into both directions. On the other hand, the mode may prevent the mobile node from collecting the amount of credit it needs for a handoff when applications with asymmetric traffic patterns are in use. For instance, file transfers and media streaming are characterized by high throughput towards the client, typically the mobile node, and comparably little throughput towards the serving correspondent node.
本国行きのModeは匹敵するデータ量を両方の方向に送るアプリケーションできめ細かに働いています。 他方では、モードは、非対称のトラフィック・パターンがあるアプリケーションが使用中であるときに、モバイルノードがそれが移管に必要とする信用金額を集めるのを防ぐかもしれません。 例えば、ファイル転送とメディアストリーミングは高生産性によってほとんど給仕通信員ノードに向かったスループットにクライアント、通常モバイルノードに向かって比較できるほどに特徴付けられません。
An additional "Outbound Mode" was designed to better accommodate applications with asymmetric traffic patterns. In Outbound Mode, packets that the correspondent node sends to the mobile node determine both, how much the credit increases while the current care-of address is verified, and how much the credit shrinks while the care-of address is unverified. This resolves the issue with asymmetric traffic patterns.
追加「外国行きのモード」は、非対称のトラフィック・パターンがあるアプリケーションをよりよく収容するように設計されました。 Outbound Modeでは、通信員ノードがモバイルノードに送るパケットが両方を決定して、電流である間、どのくらいのクレジットが増加であるか、注意、-、アドレスが確かめられて、クレジット精神科医がどのくらいゆったり過ごすかをそうされる、注意、-、アドレス、非検証されます。 これは非対称のトラフィック・パターンの問題を解決します。
The security of Outbound Mode is based on the further hypothesis that the mobile node invests comparable effort for packet reception and transmission in terms of bandwidth, memory, and processing capacity. This justifies why credit, allocated for packets received by the mobile node, can be turned into packets that the correspondent node sends. The question is, though, how the correspondent node can determine how many of the packets sent to a mobile node are actually received and processed by that mobile node. Relying on transport- layer acknowledgments is not an option as such messages can easily be faked. Outbound Mode hence defines its own feedback mechanism, Care-of Address Spot Checks, which is robust to spoofing. The correspondent node periodically tags packets that it sends to the mobile node with a random, unguessable number, a so-called Spot Check Token. When the mobile node receives a packet with an attached Spot
Outbound Modeのセキュリティはモバイルノードがパケットレセプションとトランスミッションのために帯域幅、メモリ、および処理容量に関して匹敵する取り組みを注ぎ込むというさらなる仮説に基づいています。 これはモバイルノードによって受け取られたパケットのために割り当てられたクレジットを通信員ノードが送るパケットに変えることができる理由を正当化します。 もっとも、質問は通信員ノードが、モバイルノードに送られたパケットのいくつがそのモバイルノードによって実際に受け取られて、処理されるかをどう決定できるかということです。 容易にそのようなメッセージを見せかけることができるので、輸送層の承認に依存するのは、オプションではありません。 したがって、外国行きのModeがそれ自身のフィードバック・メカニズムを定義する、Care、-、Address Spot Checks。(そのChecksはスプーフィングに強健です)。 無作為の、そして、「蹄-可能」な数(いわゆるスポット・チェックToken)で通信員ノードはそれがモバイルノードに送るパケットに定期的にタグ付けをします。 モバイルノードが付属Spotと共にパケットを受けるとき
Vogt & Arkko Informational [Page 16] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[16ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
Check Token, it buffers the token until it sends the next packet to the correspondent node. The Spot Check Token is then included in this packet. Upon reception, the correspondent node verifies whether the returned Spot Check Token matches a token recently sent to the mobile node. New credit is allocated in proportion to the ratio between the number of successfully returned Spot Check Tokens and the total number of tokens sent. This implies that new credit is approximately proportional to the fraction of packets that have made their way at least up to the mobile node's IP stack. The preciseness of Care-of Address Spot Checks can be traded with overhead through the frequency with which packets are tagged with Spot Check Tokens.
Tokenをチェックしてください、そして、それは次のパケットを通信員ノードに送るまでトークンをバッファリングします。 そして、スポット・チェックTokenはこのパケットに含まれています。 レセプションでは、通信員ノードは、返されたスポット・チェックTokenが最近モバイルノードに送られたトークンに合っているかどうか確かめます。 首尾よく返されたスポット・チェックTokensの数とトークンの総数の間に送られた比率に比例して新しいクレジットを割り当てます。 これは、新しいクレジットが少なくともモバイルノードのIPスタックまで進んでいたパケットの部分にほとんど比例しているのを含意します。 正確さ、Care、-、パケットがスポット・チェックTokensと共にタグ付けをされる頻度を通してAddressスポット・チェックをオーバーヘッドに取り引きできます。
An interesting question is whether Outbound Mode could be misused by an attacker with asymmetric Internet connection. Widespread digital subscriber lines (DSL), for example, typically have a much higher download rate than upload rate. The limited upload rate would render most denial-of-service attempts through direct flooding meaningless. But the attacker could leverage the strong download rate to build up credit at one or multiple correspondent nodes. It could then illegitimately spend the credit on a stronger, redirection-based flooding attack. The reason why this has so far not been considered an issue is that, in order to accumulate enough credit at the remote end, the attacker would first have to expose itself to the same packet flood that it could then redirect towards the victim.
面白い質問は攻撃者が非対称のインターネット接続と共にOutbound Modeを誤用できたかどうかということです。 広範囲のデジタル加入者線(DSL)で、例えば、アップロードよりはるかに高いダウンロード率は通常評価します。 限られたアップロード率はダイレクト氾濫によるほとんどのサービスの否定試みを無意味にするでしょう。 しかし、攻撃者は、1か複数の通信員ノードでクレジットを確立するために強いダウンロード率を利用することができました。 そして、それは不合理により強くて、リダイレクションベースのフラッディング攻撃にクレジットを費やすかもしれません。 これが今までのところ問題であることは考えられていない理由が攻撃者が最初にリモートエンドで十分なクレジットを蓄積するために次にそれが犠牲者に向かって向け直すことができた同じパケット洪水へのそれ自体を暴露しなければならないだろうということです。
3.8. Heuristic Monitoring
3.8. 発見的なモニター
Heuristic approaches to prevent misuse of unverified care-of addresses (see Section 3.5) are conceivable as well. A heuristic, implemented at the correspondent node and possibly supplemented by a restrictive lifetime limit for tentative bindings, can prevent, or at least effectually discourage such misuse. The challenge here seems to be a feasible heuristic: On one hand, the heuristic must be sufficiently rigid to quickly respond to malicious intents at the other side. On the other hand, it should not have a negative impact on a fair-minded mobile node's communications.
誤用を防ぐ発見的なアプローチが非検証された、注意、-、また、アドレス(セクション3.5を見る)は想像できます。 通信員ノードで実装している、ことによると一時的な結合のための制限している生涯限界で補われたヒューリスティックは、そのような誤用に防ぐか、または有効に少なくとも水をさすことができます。 ここでの挑戦は可能なヒューリスティックであるように思えます: 一方では、ヒューリスティックは反対側で急速に悪意がある「不-テント」に反応できるくらい堅くなければなりません。 他方では、それは公平なモバイルノードのコミュニケーションでマイナスの影響があるべきではありません。
Another problem with heuristics is that they are usually reactive. The correspondent node can only respond to misbehavior after it appeared. If sanctions are imposed quickly, attacks may simply not be worthwhile. Yet premature measures should be avoided. One must also bear in mind that an attacker may be able to use different home addresses, and it is in general impossible for the correspondent node to see that the set of home addresses belongs to the same node. The attacker may furthermore exploit multiple correspondent nodes for its attack in an attempt to amplify the result.
発見的教授法に関する別の問題は通常、それらが反応しているということです。 現れた後に通信員ノードは不正行為に応じることができるだけです。 制裁がすぐに課されるなら、攻撃は絶対に価値がないかもしれません。 しかし、時期尚早な測定は避けられるべきです。 また、攻撃者が異なったホームアドレスを使用できるかもしれないのを覚えておかなければなりません、そして、一般に、それは覚えておきます。通信員ノードが、ホームアドレスのセットが同じノードに属すのがわかるのは、不可能です。 その上、攻撃者は結果を増幅する試みにおける攻撃のための複数の通信員ノードを利用するかもしれません。
Vogt & Arkko Informational [Page 17] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[17ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
3.9. Crypto-Based Identifiers
3.9. 暗号ベースの識別子
A Crypto-Based Identifier (CBID) is an identifier with a strong cryptographic binding to the public component of its owner's public/private-key pair [33]. This allows the owner to prove its claim on the CBID: It signs a piece of data with its private key and sends this to the verifier along with its public key and the parameters necessary to recompute the CBID. The verifier recomputes the CBID and checks the owner's knowledge of the corresponding private key.
ベースのCrypto Identifier(CBID)は所有者の公衆/秘密鍵組[33]の公共のコンポーネントとの強い暗号の結合がある識別子です。 これで、所有者はCBIDのクレームを立証できます: それは、1つのデータと秘密鍵を契約して、CBIDを再計算するのに必要な公開鍵とパラメタに伴う検証にこれを送ります。 検証は、CBIDを再計算して、対応する秘密鍵に関する所有者の知識をチェックします。
CBIDs offer three main advantages: First, spoofing attacks against a CBID are much harder than attacks against a non-cryptographic identifier like a domain name or a Mobile IPv6 home address. Though an attacker can always create its own CBID, it is unlikely to find a public/private-key pair that produces someone else's. Second, a CBID does not depend on a PKI given its inherent binding to the owner's public key. Third, a CBID can be used to bind a public key to an IP address, in which case it is called a Cryptographically Generated Address (CGA) [44][34][47]. A CGA is syntactically just an ordinary IPv6 address. It has a standard routing prefix and an interface identifier generated from a hash on the CGA owner's public key and additional parameters.
CBIDsは3つの主な利点を示します: まず最初に、CBIDに対するスプーフィング攻撃はドメイン名のような非暗号の識別子に対する攻撃かモバイルIPv6ホームアドレスよりはるかに困難です。 攻撃者はいつもそれ自身のCBIDを作成できますが、それは他の誰かのものを生産する公衆/秘密鍵組を見つけそうにはありません。 2番目に、所有者の公開鍵との固有の結合を考えて、CBIDはPKIによりません。 3番目に、IPアドレスに公開鍵を縛るのにCBIDを使用できます、その場合、それはCryptographically Generated Address(CGA)[44][34][47]と呼ばれます。 CGAはシンタクス上そうです。まさしく普通のIPv6アドレス。 それで、CGA所有者の公開鍵と追加パラメタでハッシュから標準のルーティング接頭語とインタフェース識別子を生成します。
Many applications are conceivable where CGAs are advantageous. In Mobile IPv6, CGAs can bind a mobile node's home address to its public key [35][5] and so avoid the home-address test in most correspondent registrations. This accelerates the registration process and allows the peers to communicate independently of home-agent availability.
多くのアプリケーションがCGAsが有利であるところで想像できます。 公開鍵[35][5]にモバイルノードのホームアドレスを縛るので、モバイルIPv6では、CGAsはほとんどの通信員登録証明書でホームアドレステストを避けることができます。 これは、登録手続を加速して、同輩がホームエージェントの有用性の如何にかかわらず交信するのを許容します。
Since only the interface identifier of a CGA is cryptographically protected, its network prefix can be spoofed, and flooding attacks against networks are still an issue. An initial home-address test is hence required to validate the network prefix even when the home address is a CGA. For the same reason, CGAs are rarely used as care-of addresses.
CGAに関するインタフェース識別子だけが暗号で保護されるので、ネットワーク接頭語を偽造することができます、そして、ネットワークに対するフラッディング攻撃は発行です。 したがって、初期のホームアドレステストが、ホームアドレスがCGAでさえあるときに、ネットワーク接頭語を有効にするのに必要です。 同じ理由から、CGAsがめったに使用されない、注意、-、アドレス。
One limitation of CGAs compared to other types of CBIDs is that the cryptographically protected portion is only at most 62 bits long. The rest of the address is occupied by a 64-bit network prefix as well as the universal/local and individual/group bits. (The specification in [44] further hard-codes a 3-bit security parameter into the address, reducing the cryptographically protected portion to 59 bits.) A brute-force attack might thus reveal a public/private key public/private-key pair that produces a certain CGA. This vulnerability can be contained by including the network prefix in the hash computation for the interface identifier so that an attacker, in
CBIDsの他のタイプと比較されたCGAsの1つの限界は暗号で保護された部分が高々だけ長さ62ビットであるということです。 アドレスの残りは普遍的な/と同様にローカルの64ビットのネットワーク接頭語と個人/グループビットによって占領されます。 ([44] 暗号で保護された部分を59ビットまで減少させるアドレスへのさらに困難なコードのa3ビットのセキュリティパラメタの仕様。) その結果、全数探索法はあるCGAを生産する公衆/秘密鍵公衆/秘密鍵組を明らかにするかもしれません。 したがって、インタフェース識別子のためのハッシュ計算にネットワーク接頭語を含んでいて、この脆弱性を含むことができる、それ、攻撃者、コネ
Vogt & Arkko Informational [Page 18] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[18ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
case it did find the right public/private key public/private-key pair, could not form CGAs for multiple networks from it.
それがしたケースは正しい公衆/秘密鍵公衆/秘密鍵組に当たって、それから複数のネットワークのためのCGAsを形成できませんでした。
To resolve collisions in generating CGAs, a collision count is part of the input to the hash function. Changing this produces a different CGA. Unfortunately, the collision count also reduces the complexity of a brute-force attack against a CGA because it allows the same private/public-key pair to be used to generate multiple CGAs. The collision count is therefore limited to a few values only.
CGAsを生成する際に衝突を決議するために、衝突カウントはハッシュ関数への入力の一部です。 これを変えると、異なったCGAは生産されます。 残念ながら、同じ私設の/公開鍵組が複数のCGAsを生成するのに使用されるのを許容するので、衝突カウントはまた、CGAに対して全数探索法の複雑さを変えます。 したがって、衝突カウントはいくつかの値だけに制限されます。
Higher security can be achieved through longer CBIDs. For example, a node's primary identifier in the Host Identity Protocol [21] is a 128-bit hash on the node's public key. It is used as an IP-address replacement at stack layers above IP. This CBID is not routable, so there needs to be some external localization mechanism if a node wants to contact a peer of which it only knows the identifier.
より長いCBIDsを通して、より高いセキュリティを達成できます。 例えば、Host Identityプロトコル[21]のノードの基本識別子はノードの公開鍵に関する128ビットのハッシュです。 それはIP-アドレス交換としてIPの上のスタック層で使用されます。 このCBIDが発送可能でないので、ノードがそれが識別子を知っているだけである同輩に連絡したいなら、何らかの外部の局在機構があるのが必要です。
3.10. Pre-Configuration
3.10. プレ構成
Where mobile and correspondent nodes can be pre-configured with a shared key, bound to the mobile node's home address, authentication through a home-address test can be replaced by a cryptographic mechanism. This has three advantages. First, cryptography allows for stronger authentication than address tests. Second, strong authentication facilitates binding lifetimes longer than the 7- minute limit that RFC 3775 defines for correspondent registrations. Third, handoff delays are usually shorter with cryptographic approaches because the round-trips of the home-address test can be spared. The disadvantage of pre-configuration is its limited applicability.
モバイルノードのホームアドレスに縛られた共有されたキーでモバイルと通信員ノードをあらかじめ設定できるところでは、ホームアドレステストによる認証を暗号のメカニズムに取り替えることができます。 これには、3つの利点があります。 まず最初に、暗号はテストを扱うより強い認証を考慮します。 2番目に、強い認証はRFC3775が通信員登録証明書のために定義する7の微小な限界より長い間、拘束力がある生涯を容易にします。 3番目に、通常、移管遅れは、ホームアドレステストの周遊旅行を割くことができるので、暗号のアプローチで、より少しです。 プレ構成の不都合は限られた適用性です。
Two proposals for pre-configuration are currently under discussion within the IETF. [25] endows mobile nodes with the information they need to compute home and care-of keygen tokens themselves rather than having to obtain them through the return-routability procedure. [15] uses the Internet Key Exchange protocol to establish an IPsec security association between the peers.
IETFの中にプレ構成のための2つの提案は現在、議論中であります。 そして、[25]が彼らがホームを計算するために必要とする情報にモバイルノードを寄付する、注意、-、リターン-routability手順でそれらを得なければならないよりむしろトークン自体をkeygenします。 [15] インターネットKey Exchangeが同輩の間のIPsecセキュリティ協会を証明するために議定書の中で述べる用途。
From a technical standpoint, pre-configuration can only replace a home-address test. A test of the care-of address is still necessary to verify the mobile node's presence at that address. The problem is circumvented in [25] by postulating that the correspondent node has sufficient trust in the mobile node to believe that the care-of address is correct. This assumption discourages the use of pre- configuration in scenarios where such trust is unavailable, however. For example, a mobile-phone operator may be able to configure subscribers with secret keys for authorization to a particular service, but it may not be able to vouch that all subscribers use
技術的な見地から、プレ構成はホームアドレステストを置き換えることができるだけです。 Aがテストする、注意、-、アドレス、そのアドレスでモバイルノードの存在について確かめるのに必要なスチール写真はそうです。 通信員ノードにはモバイルノードのそれを信じることができるくらいの信頼があるのを仮定することによって問題が[25]で回避される、注意、-、アドレス、正しいです。 この仮定は. 例えば、携帯電話オペレータが、しかし、特定のサービス、それへの承認のための秘密鍵をもっている加入者が太鼓判を押すことができないかもしれないのを構成できるかもしれないしかしながら、そのような信頼が入手できないシナリオにおけるプレ構成のすべての加入者が使用する使用に水をさしています。
Vogt & Arkko Informational [Page 19] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[19ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
this service in a responsible manner. And even if users are trustworthy, their mobile nodes may become infected with malware and start behaving unreliably.
責任ある態度におけるこのサービス。 そして、ユーザが信頼できても、彼らのモバイルノードは、マルウェアに感染するようになって、当てにならずに振る舞い始めるかもしれません。
Another way to avoid care-of-address verification is to rely on access networks to filter out packets with incorrect IP source addresses [38][43]. This approach is taken in [15]. The problem with local filtering is that it can only protect a network from becoming the source of an attack, not from falling victim to an attack. The technique is hence potentially unreliable unless deployed in access networks worldwide (see Section 1.2).
アドレス検査の注意を避ける別の方法は不正確なIPソースアドレス[38][43]があるパケットを無視するためにアクセスネットワークを当てにすることです。 [15]でこのアプローチを取ります。 地方のフィルタリングに関する問題は攻撃の犠牲になるのから保護するのではなく、攻撃の源になるのからネットワークを保護できるだけであるということです。 したがって、世界中のアクセスネットワークで配布されない場合、テクニックは潜在的に頼り無いです(セクション1.2を見てください)。
Care-of-address tests facilitate the use of pre-configuration in spite of lacking trust relationships or the existence of access networks without local filtering techniques. For increased performance, concurrent care-of-address tests can be used in combination with Credit-Based Authorization or heuristic monitoring.
欠いている信頼関係かアクセスネットワークの存在にもかかわらず、アドレスの注意テストはローカルのフィルター技術なしでプレ構成の使用を容易にします。 増強された性能のために、ベースのCredit Authorizationか発見的なモニターと組み合わせて同時発生のアドレスの注意テストを使用できます。
3.11. Semi-Permanent Security Associations
3.11. 半永久的なセキュリティ協会
A compromise between the return-routability procedure and pre- configuration are semi-permanent security associations. A semi- permanent security association is established between a mobile node and a correspondent node upon first contact, and it is used to authenticate the mobile node during subsequent correspondent registrations. Semi-permanent security associations eliminate the need for periodic home-address tests and permit correspondent registrations with lifetimes longer than the 7-minute limit specified in RFC 3775.
リターン-routability手順とプレ構成の間の感染は半永久的なセキュリティ協会です。 準永久的なセキュリティ協会はモバイルノードと最初に、接触の通信員ノードの間に設立されます、そして、それは、その後の通信員登録証明書の間、モバイルノードを認証するのに使用されます。 半永久的なセキュリティ協会は7分の限界がRFC3775で指定したより長い間、生涯で周期的なホームアドレステストと許可証通信員登録証明書の必要性を排除します。
It is important to verify a mobile node's home address before a security association is bound to it. An impersonator could otherwise create a security association for a victim's IP address and then redirect the victim's traffic at will until the security association expires. An initial home-address test mitigates this vulnerability because it requires the attacker to be on the path between the victim and the victim's peer at least while the security association is being established. Stronger security can be obtained through cryptographically generated home addresses (see Section 3.9).
セキュリティ協会がそれに縛られる前にモバイルノードのホームアドレスについて確かめるのは重要です。 セキュリティ協会が期限が切れるまで、ものまね役者は、そうでなければ、犠牲者のIPアドレスのためにセキュリティ協会を創設して、次に、犠牲者のトラフィックを自由自在に向け直すことができました。 犠牲者と少なくとも犠牲者の同輩の間の経路にあるのが攻撃者を必要とするので、セキュリティ協会が設立されている間、初期のホームアドレステストはこの脆弱性を緩和します。 通じてより強いセキュリティを得ることができます。暗号で、ホームアドレス(セクション3.9を見る)であると生成します。
Semi-permanent security associations alone provide no verification of care-of addresses and must therefore be supplemented by care-of- address tests. These may be performed concurrently for reduced handoff delays. Semi-permanent security associations were first developed in [8] where they were called "purpose-built keys".
半永久的なセキュリティ協会だけが検証を全く提供しない、注意、-、アドレス、したがって、注意で補わなければならない、-、アドレステストについて。 これらは減少している移管遅れのために同時に実行されるかもしれません。 半永久的なセキュリティ協会は最初に、それらが「特注のキー」と呼ばれた[8]で発展しました。
Vogt & Arkko Informational [Page 20] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[20ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
3.12. Delegation
3.12. 委譲
Section 1.1 lists numerous problems of PKIs with respect to authentication of mobile nodes. These problems become more tractable, however, if correspondent nodes authenticate home agents rather than mobile nodes, and the home agents vouch for the authenticity and trustworthiness of the mobile nodes [37]. Such delegation of responsibilities solves the scalability issue with PKIs given that home agents can be expected to be much less numerous than mobile nodes. Certificate revocation becomes less delicate as well because home agents are commonly administrated by a mobility provider and should as such be more accountable than mobile nodes.
セクション1.1はモバイルノードの認証に関してPKIsの多数の問題を記載します。 しかしながら、通信員ノードがモバイルノードよりむしろホームのエージェントを認証するなら、これらの問題は、より御しやすくなります、そして、ホームのエージェントはモバイルノード[37]の信憑性と信頼できることを保証します。 ホームのエージェントがモバイルノードよりはるかに多数でないと予想できるなら、責任のそのような委譲はPKIsのスケーラビリティ問題を解決します。 ホームのエージェントは移動性プロバイダーによって一般的に管理されて、モバイルノードよりそういうものとして責任があるべきであるので、証明書取消しはまた、よりデリケートでなくなります。
Another advantage of delegation is that it avoids public-key computations at mobile nodes. On the other hand, the processing overhead at correspondent nodes increases. This may or may not be an issue depending on resources available at the correspondent node relative to the services that the correspondent node provides. The correspondent node may also be mobile itself, in which case cryptographic operations would be problematic. Furthermore, the increased overhead implies a higher risk to resource-exhaustion attacks.
委譲の別の利点はモバイルノードで公開鍵計算を避けるということです。 他方では、通信員ノードにおける処理オーバヘッドは上がります。 これは通信員ノードで通信員ノードが備えるサービスに比例して利用可能なリソースによる問題であるかもしれません。 また、通信員ノードそれ自体でモバイルであるかもしれない、その場合、暗号の操作は問題が多いでしょう。 その上、増強されたオーバーヘッドはリソース疲労困憊攻撃により高い危険を含意します。
3.13. Mobile Networks
3.13. モバイルネットワーク
Mobile nodes may move as a group and attach to the Internet via a "mobile router" that stays with the group. This happens, for example, in trains or aircraft where passengers communicate via a local wireless network that is globally interconnected through a satellite link.
モバイルノードは、グループと共に滞在する「モバイルルータ」を通してグループとして移行して、インターネットに付くかもしれません。 例えば、これは乗客が衛星中継を通してグローバルにインタコネクトされるローカルのワイヤレス・ネットワークを通って交信する列車か航空機で起こります。
It is straightforward to support such network mobility [41] with a single home agent and a tunnel between the mobile router and this home agent. The mobile nodes themselves then do not have to be mobility-aware. However, Route Optimization for moving networks [36][26][27][55] is more complicated. One possibility is to have the mobile router handle Route Optimization on behalf of the mobile nodes. This requires the mobile router to modify incoming and outgoing packets such that they can be routed on the direct path between the end nodes. The mobile router would also have to perform Mobile IPv6 signaling on behalf of the mobile nodes. Similarly, a network of correspondent nodes can communicate with mobile nodes, through a "correspondent router", in a route-optimized way without providing mobility support themselves.
モバイルルータとこのホームのエージェントの間には、独身のホームのエージェントとトンネルがある状態でそのようなネットワークの移動性が[41]であるとサポートするのは簡単です。 モバイルノード自体はその時、移動性意識している必要はありません。 しかしながら、感動的なネットワーク[36][26][27][55]のためのRoute Optimizationは、より複雑です。 1つの可能性はモバイルルータにモバイルノードを代表してRoute Optimizationを扱わせることです。 これは、エンドノードの間の直接路でそれらを発送できるように送受信のパケットを変更するためにモバイルルータを必要とします。 また、モバイルルータはモバイルノードを代表してモバイルIPv6シグナリングを実行しなければならないでしょう。 同様に、通信員ノードのネットワークは「通信員ルータ」を通した移動性サポートを提供することのないルートで最適化された方法によるモバイルノード自体とコミュニケートできます。
Vogt & Arkko Informational [Page 21] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[21ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
3.14. Location Privacy
3.14. 位置のプライバシー
RFC 3775 fails to conceal a mobile node's current position as route- optimized packets always carry both home and care-of addresses. Both the correspondent node and a third party can therefore track the mobile node's whereabouts. A workaround is to fall back to bidirectional tunneling where location privacy is needed. Packets carrying the mobile node's care-of address are thus only transferred between the mobile node and the home agent, where they can be encrypted through IPsec ESP [42]. But even then should the mobile node periodically re-establish its IPsec security associations so as to become untraceable through its SPIs. Early efforts on location privacy in Route Optimization include [17][13][24][30].
そして、ルートの最適化されたパケットがいつもともに家まで運ばれるときRFC3775がモバイルノードの現在の位置を隠さない、注意、-、アドレス。 したがって、通信員ノードと第三者の両方がモバイルノードの居場所を追跡できます。 回避策は位置のプライバシーが必要であるところから双方向のトンネリングへ後ろへ下がることです。 このようにしてモバイルノードとホームのエージェントの間にアドレスを移すだけです、IPsecを通してそれらを暗号化できるところで。モバイルノードのものを運ぶパケット、注意、-、超能力[42]。 その時でさえ、モバイルノードは、SPIsを通して追跡不可能になるようにIPsecセキュリティ協会を定期的に復職させるはずですか? Route Optimizationの位置のプライバシーに関する早めの取り組みは[17][13][24][30]を含んでいます。
4. Discussion
4. 議論
Common to the proposals discussed in Section 3 is that all of them affect a trade-off between effectiveness, on one hand, and economical deployability, administrative overhead, and wide applicability, on the other. Effectiveness may be equated with low latency, strong security, reduced signaling, or increased robustness. Economy implies no, or only moderate requirements in terms of hardware upgrades and software modifications. Administrative overhead relates to the amount of manual configuration and intervention that a technique needs.
セクション3で議論した提案に共通であるのは、片手の有効性と、経済的なdeployabilityの間のトレードオフに影響するということです、頭上の管理の、そして、広い適用性、もう片方で。 有効性は低遅延、強いセキュリティ、減少しているシグナリング、または増強された丈夫さと同一視されるかもしれません。 経済はハードウェアアップグレードとソフトウェア変更でいいえ、または適度の要件だけを含意します。 管理オーバーヘッドはテクニックが必要とする手動の構成と介入の量に関連します。
The standard return-routability procedure avoids costly pre- configuration or new network entities. This minimizes both deployment investments as well as administrative expenses. Variants with optimistic behavior and proactive or concurrent IP-address tests have these advantages as well. CBIDs allow for public-key authentication without a PKI. They constitute a more secure alternative to home-address tests and are as such most effective when combined with concurrent reachability verification. CBID-based authentication may require nodes to be programmed with a mapping between human-readable identifiers and the corresponding CBIDs. Pre-configuration is another approach to avoid home-address tests. It does without computationally expensive public-key algorithms, but requires pair-wise credentials and, therefore, administrative maintenance. Where suitable infrastructure is available, end nodes may delegate authentication and encryption tasks to trusted network entities which, in turn, vouch for the end nodes. Delegation could resurrect the use of certificates for the purpose of mobility support. But it introduces a dependency on the delegatees, adds the provisioning costs for new network entities, and is likely to be limited to communities of authorized nodes.
標準のリターン-routability手順は高価なプレ構成か新しいネットワーク実体を避けます。 これは展開投資と一般管理費の両方を最小にします。 楽観的な振舞いと先を見越すか同時発生のIP-アドレステストがある異形には、また、これらの利点があります。 CBIDsはPKIなしで公開鍵認証を考慮します。 それらは、ホームアドレステストへの、より安全な代替手段を構成して、同時発生の可到達性検証に結合されると、そういうものとして最も効果的です。 CBIDベースの認証は、人間読み込み可能な識別子と対応するCBIDsの間には、マッピングがある状態でノードがプログラムされるのを必要とするかもしれません。 プレ構成はホームアドレステストを避ける別のアプローチです。 それは、計算上高価な公開鍵アルゴリズムなしでしますが、対状資格証明書を必要として、その結果管理メインテナンスを必要とします。 適当なインフラストラクチャが入手できるところに、エンドノードは順番にエンドノードを保証する信じられたネットワーク実体への認証と暗号化タスクを代表として派遣するかもしれません。 委譲は証明書の移動性サポートの目的の使用を復活させるかもしれません。 しかし、それは、「反-遺産受取人」で依存を導入して、新しいネットワーク実体のために食糧を供給するコストを言い足して、認可されたノードの一致に制限されそうです。
Vogt & Arkko Informational [Page 22] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[22ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
4.1. Cross-Layer Interactions
4.1. 交差している層の相互作用
The performance of Route Optimization, as evaluated in this document, should be put into perspective of handoff-related activities in other parts of the network stack. These include link-layer attachment procedures; link-layer security mechanisms such as negotiation, authentication, and key agreement; as well as IPv6 router discovery, address configuration, and movement detection. A complete network attachment in a typical IEEE 802.11 commercial deployment requires over twenty link- and IP-layer messages. Current protocol stacks also have a number of limitations in addition to long attachment delays, such as denial-of-service vulnerabilities, difficulties in trusting a set of access nodes distributed to physically insecure locations, or the inability to retrieve sufficient information for making a handoff decision [2].
ネットワークスタックの他の一部で移管関連の活動の見解に本書では評価されるRoute Optimizationの性能を入れるべきです。 これらはリンクレイヤ付属手順を含んでいます。 交渉や、認証や、主要な協定などのリンクレイヤセキュリティー対策。 IPv6ルータ発見と同様に、構成、および動きが検出であると扱ってください。 典型的なIEEE802.11商業展開における完全なネットワーク付属は20以上リンクとIP-層のメッセージを必要とします。 また、現在のプロトコル・スタックには、長い付属遅れに加えた多くの制限があります、サービスの弱点の否定、ノードが広げたアクセスのセットを物理的に不安定な位置に任せることにおける苦労、または移管決定を[2]にするための十分な情報を検索できないことなどのように。
A number of proposals have been put forth to improve handoff performance on different parts of the network stack, mostly focusing on handoff performance. These include link-layer parameter tuning [49] and network-access authentication [18][2][32], as well as IPv6 router discovery [11][12], address configuration [23], and movement detection [19][20]. It is uncertain how far this optimization can be taken by only looking at the different parts individually. An integrated approach may eventually become necessary [4][53].
ネットワークスタックの異なった一部に関する移管性能を向上させるために多くの提案を差し出しました、移管性能にほとんど焦点を合わせて。 これらはリンクレイヤパラメタチューニング[49]とネットワークアクセス認証[18][2][32]を含んでいます、IPv6ルータ発見[11][12]、アドレス構成[23]、および動き検出[19][20]と同様に。 どれくらい遠くに個別に異なった部品を見るだけでこの最適化を取ることができるかは不確実です。 統合的アプローチは結局、必要な[4][53]になるかもしれません。
4.2. Experimentation and Measurements
4.2. 実験と測定値
The number and diversity of mobility-related activities within a typical network stack oftentimes render theoretical analyses insufficient and call for additional, extensive experimentation or simulation. The following is a non-exhaustive list of areas where practical experience is likely to yield valuable insight.
典型的なネットワークスタックの中の移動性関連の活動の数と多様性は、しばしば理論上の分析を不十分に表して、追加していて、大規模な実験かシミュレーションを求めます。 ↓これは実用的な経験が貴重な見識をもたらしそうである領域に関する非完全なりストです。
o Conception of a set of standard scenarios that can be used as a
reference for comparable measurements and experimentation.
Ideally, such standard scenarios ought to be derived from real-
world environments, and they should include all features that
would likely be needed in a commercial deployment. These features
include link-layer access control, for instance.
o 匹敵する測定値と実験の参照として使用できる1セットの標準のシナリオに関する概念。 理想的に、本当の世界環境からそのような標準のシナリオを得るべきです、そして、それらは商業展開でおそらく必要であるすべての特徴を含むべきです。 これらの特徴は例えばリンクレイヤアクセスコントロールを含んでいます。
o Measurements of the performance impacts that existing enhancement
proposals have on the different parts of the stack.
o 性能の測定値は提案がスタックの異なった一部に持っているその既存の増進に影響を与えます。
o Comparisons of different implementations that are based on the
same specification. For instance, it would be valuable to know
how much implementations differ with regards to the use of
parallelism that RFC 3775 allows in home and correspondent
registrations.
o 同じ仕様に基づいている異なった実装の比較。 例えば、どのくらいの実装がRFC3775がホームと通信員登録証明書で許容する平行関係の使用にあいさつと異なっているかを知るのは貴重でしょう。
Vogt & Arkko Informational [Page 23] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[23ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
o Measurements of the impact that network conditions such as packet
loss can have on existing and new optimizations.
o パケット損失などのネットワーク状態が存在と新しい最適化のときに持つことができる影響力の測定値。
o Statistical data collection on the behavior of mobile nodes in
different networks. Several Route Optimization techniques behave
differently depending on the degree of mobility.
o 異なったネットワークにおける、モバイルノードの動きに関する統計データ収集。 移動性の度合いに異なってよって、いくつかのRoute Optimizationのテクニックが振る舞います。
o Measurements of the performance that Route Optimization schemes
show under different application scenarios, such as the use of
applications with symmetric vs. asymmetric traffic patterns.
o Route Optimizationが計画する性能の測定値は異なったアプリケーションシナリオの下で目立っています、非対称のトラフィックに対して左右対称のパターンがあるアプリケーションの使用などのように。
4.3. Future Research
4.3. 今後の研究
Future research that goes beyond the techniques discussed in this document may consider the following items.
本書では議論したテクニックを越える今後の研究は以下の項目を考えるかもしれません。
o Local mobility support or local route-repair mechanisms that do
not require expensive configuration. This includes
infrastructure-based Route Optimization like [48].
o 地方の移動性サポートか高価な構成を必要としないローカルのルート修理メカニズム。 これは[48]のようなインフラストラクチャベースのRoute Optimizationを含んでいます。
o Care-of-address verification mechanisms that are based on Secure
Neighbor Discovery.
o Secure Neighborディスカバリーに基づいているアドレス検査の注意メカニズム。
o The introduction of optimizations developed in the context of
Mobile IPv6 to other mobility protocols, such as the Host Identity
Protocol, the Stream Control Transmission Protocol, the Datagram
Congestion Control Protocol, or link-layer mobility solutions.
o 最適化の導入はモバイルIPv6の文脈で他の移動性プロトコルに展開しました、Host Identityプロトコル、Stream Control Transmissionプロトコル、データグラムCongestion Controlプロトコル、またはリンクレイヤ移動性溶液などのように。
o The extension of the developed mobility techniques to full multi-
addressing, including multi-homing.
o マルチホーミングを含む完全なマルチアドレシングへの開発された移動性のテクニックの拡大。
o Further strategies that are based on "asymmetric cost wars" [3],
such as Credit-Based Authorization.
o ベースのCredit Authorizationなどのように「非対称の費用戦争」[3]に基づいているさらなる戦略。
o Integrated techniques taking into account both link- and IP-layer
mobility tasks.
o 両方のリンクとIP-層の移動性タスクを考慮に入れる統合テクニック。
5. Security Considerations
5. セキュリティ問題
Standard Route Optimization enables mobile nodes to redirect IP packets at a remote peer from one IP address to another IP address. This ability introduces new security issues, which are explained and discussed in depth in [46]. The alternative Route Optimization techniques described in this document may introduce new security threats that go beyond those identified in [46]. Where such new threats exist, they are discussed and analyzed along with the description of the respective technique in Section 3.
標準のRoute Optimizationは、モバイルノードがリモート同輩で1つのIPアドレスから別のIPアドレスまでIPパケットを向け直すのを可能にします。 この能力は新しい安全保障問題を紹介します。([46]で安全保障問題について、徹底的に説明されて、議論します)。 Route Optimizationのテクニックが説明した代替手段は本書では[46]で特定されたものを越える新しい軍事的脅威を導入するかもしれません。 そのような新しい脅威が存在しているところでは、それらは、セクション3における、それぞれのテクニックの記述と共に議論して、分析されます。
Vogt & Arkko Informational [Page 24] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[24ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
6. Conclusions
6. 結論
Mobile IPv6 Route Optimization reduces packet-propagation latencies so as to facilitate interactive and real-time applications in mobile environments. Unfortunately, the end-to-end protocol's high handoff latencies hinder exactly these applications. A large body of effort has therefore recently been dedicated to Route Optimization improvements. Some of the proposed techniques operate on an end-to- end basis, others require new or extended infrastructure in the network; some need pre-configuration, others are zero-configurable. This document has compared and evaluated the different strategies based on a selected set of enhancement proposals. It stands out that all proposals make a trade-off between effectiveness, on one hand -- be it in terms of reduced handoff latency, increased security, or lower signaling overhead -- and pre-configuration costs or requisite network upgrades, on the other. An optimization's investment requirements, in turn, are in relation to its suitability for widespread deployment.
モバイルIPv6 Route Optimizationは、モバイル環境における対話的でリアルタイムのアプリケーションを容易にするためにパケット伝播潜在を減少させます。 残念ながら、終わりから終わりへのプロトコルの高い移管潜在はまさにこれらのアプリケーションを妨げます。 したがって、取り組みの大きいボディーは最近、Route Optimization改良に捧げられました。 提案されたテクニックのいくつかが終わりから終わりへのベースを作動させて、他のものはネットワークで新しいか拡張しているインフラストラクチャを必要とします。 或るものはプレ構成を必要として、他のものは無構成可能です。 このドキュメントは、選択されたセットのエンハンス提案に基づく異なった戦略を、比較して、評価しました。 すべての提案が減少している移管潜在、増強されたセキュリティ、または低いシグナリングオーバーヘッドにかかわらず片手の有効性とプレ構成コストか必要なネットワークアップグレードの間でトレードオフをするのは際立っています、もう片方で。 最適化の投資要件は順番に広範囲の展開への適合と関連しています。
However, the real-life performance of end-to-end mobility does not only depend on enhancements of Route Optimization, but ultimately on all parts of the protocol stack [2]. Related optimization endeavors are in fact gaining momentum, and a comprehensive approach towards Route Optimization must incorporate the most suitable solutions amongst them [4]. Whichever proposals will eventually reach a maturity level sufficient for standardization, any effort should be expended to arrive at that point within the foreseeable future. Route Optimization requires support from both peers and depends on a solid basis of installed implementations in correspondent nodes. This should hence be included in emerging IPv6 stacks early on. Although IPv6 deployment is yet far away from becoming widespread, the sooner efficient Route Optimization will be available, the more likely that it will in the end be ubiquitously supported.
しかしながら、終わりから終わりへの移動性の現実の性能はRoute Optimizationの増進によるだけではなく、結局、プロトコルのすべての部分の上で[2]を積み重ねます。 事実上、関連最適化努力ははずみがついています、そして、Route Optimizationに向かった包括的なアプローチはそれらの中に最も適当なソリューションを組み込まなければなりません。[4]。 結局標準化に十分な成熟レベルに達するどの提案、どんな取り組みも、予見できる未来中にその時到着するように費やされるべきであるか。 ルートOptimizationは両方の同輩から支持を要して、通信員ノードのインストールされた実装しっかりしたベースに依存します。 したがって、これは早くからIPv6スタックとして現れる際に含まれるべきです。 IPv6展開が広範囲になるのからまだほど遠いのですが、効率的なRoute Optimizationが、より早く利用可能になればなるほど、それは結局、遍在して、よりサポートされそうでしょう。
7. Acknowledgments
7. 承認
This document was thoroughly reviewed, in alphabetical order, by Samita Chakrabarti, Francis Dupont, Thierry Ernst, Gerardo Giaretta, James Kempf, Rajeev Koodli, Gabriel Montenegro, Vidya Narayanan, and Fan Zhao. The authors wish to thank these folks for their valuable comments and suggestions.
このドキュメントは徹底的に再検討されました、アルファベット順に、Samita Chakrabarti、フランシス・デュポン、ティエリー・エルンスト、ヘラルドGiaretta、ジェームス・ケンフ、Rajeev Koodli、ガブリエル・モンテネグロ、Vidyaナラヤナン、およびFanチャオ。 作者は彼らの貴重なコメントと提案についてこれらの人々に感謝したがっています。
Vogt & Arkko Informational [Page 25] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[25ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[1] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
8.2. Informative References
8.2. 有益な参照
[2] Alimian, A. and B. Aboba, "Analysis of Roaming Techniques",
IEEE Contribution 802.11-04/0377r1, March 2004.
[2]AlimianとA.とB.Aboba、「ローミングのテクニックの分析」、IEEE貢献802.11-04/0377r1、2004年3月。
[3] Arkko, J. and P. Nikander, "Weak Authentication: How to
Authenticate Unknown Principals without Trusted Parties",
Proceedings of Security Protocols Workshop 2002, Cambridge, UK,
April 2002.
[3]Arkko、J.、およびP.Nikander、「弱い認証:」 「信じられた党なしで未知の主体をどう認証する」、セキュリティプロトコルワークショップ2002、ケンブリッジ、イギリス、4月2002日の議事
[4] Arkko, J., Eronen, P., Nikander, P., and V. Torvinen, "Secure
and Efficient Network Access", Proceedings of the DIMACS
Workshop on Mobile and Wireless Security, November 2004.
[4]Arkko、J.、Eronen、P.、Nikander、P.、および「安全で効率的なネットワークアクセス」、モバイルの、そして、ワイヤレスのセキュリティ(2004年11月)におけるDIMACSワークショップの議事対Torvinen
[5] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", Work in Progress, August 2006.
[5]ArkkoとJ.とフォークト、C.とW.ハダド、「モバイルIPv6"のための高められた経路最適化、処理中の作業、2006年8月。」
[6] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding
Lifetime Extension", Work in Progress, May 2004.
[6] 「拘束力がある生涯拡大のためのクレジットベースの承認」というArkko、J.、およびC.フォークトは進歩、2004年5月に働いています。
[7] Bahl, P., Adya, A., Padhye, J., and A. Walman, "Reconsidering
Wireless Systems With Multiple Radios", ACM SIGCOMM Computer
Communication Review, ACM Press, Vol. 34, No. 5, October 2004.
[7]Bahl、P.、Adya、A.、Padhye、J.、および「複数のラジオでワイヤレスシステムを再考すること」でのACM SIGCOMMコンピュータコミュニケーションレビュー、ACMが押すA.Walman、Vol.34、No.5(2004年10月)。
[8] Bradner, S., Mankin, A., and J. Schiller, "A Framework for
Purpose-Built Keys (PBK)", Work in Progress, June 2003.
[8] ブラドナー、S.、マンキン、A.、およびJ.シラー、「特注のキー(PBK)のためのフレームワーク」は進歩、2003年6月に働いています。
[9] Castellucia, C., Montenegro, G., Laganier, J., and C. Neumann,
"Hindering Eavesdropping via IPv6 Opportunistic Encryption",
Proceedings of the European Symposium on Research in Computer
Security, Lecture Notes in Computer Science, Springer-Verlag,
September 2004.
[9] コンピュータSecurityのResearch、コンピュータScienceのLecture Notes、Springer-Verlag(2004年9月)の上のCastelluciaとC.とモンテネグロとG.とLaganier、J.とC.ノイマン、「IPv6 Opportunistic Encryptionを通してEavesdroppingを妨げます」、ヨーロッパのSymposiumのProceedings。
[10] Chandra, R., Bahl, P., and P. Bahl, "MultiNet: Connecting to
Multiple IEEE 802.11 Networks Using a Single Wireless Card",
Proceedings of the IEEE INFOCOM, Vol. 2, August 2004.
[10] チャンドラ、R.、Bahl、P.、およびP.Bahl、「MultiNet:」 「単一のワイヤレス・カードを使用するIEEE802.11がネットワークでつなぐ倍数に接続する」IEEE INFOCOM、Vol.2、2004年8月の議事。
[11] Daley, G., Pentland, B., and R. Nelson, "Effects of Fast
Routers Advertisement on Mobile IPv6 Handovers", Proceedings of
the IEEE International Symposium on Computers and
Communication, Vol. 1, June 2003.
[11] デイリーとG.とPentlandとB.とR.ネルソンと「モバイルIPv6身柄の引き渡しへの速いルータ広告の効果」とコンピュータにおけるIEEE国際シンポジウムの議事とコミュニケーション、Vol.1、2003年6月。
Vogt & Arkko Informational [Page 26] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[26ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
[12] Daley, G., Pentland, B., and R. Nelson, "Movement Detection
Optimizations in Mobile IPv6", Proceedings of the IEEE
International Conference on Networks, September 2003.
[12] デイリーとG.とPentland、B.とR.ネルソン、「モバイルIPv6"の動き検出最適化、ネットワークにおけるIEEE国際会議の議事、2003年9月。」
[13] Daley, G., "Location Privacy and Mobile IPv6", Work in
Progress, January 2004.
[13] デイリーとG.と「位置のプライバシーとモバイルIPv6"、処理中の作業、2004年1月。」
[14] Dupont, F., "A Note about 3rd Party Bombing in Mobile IPv6",
Work in Progress, July 2006.
[14] デュポン、F.、「2006年7月にモバイルIPv6"、進行中の仕事で爆撃される第3パーティに関する注。」
[15] Dupont, F. and J. Combes, "Using IPsec between Mobile and
Correspondent IPv6 Nodes", Work in Progress, August 2004.
[15] 「モバイルと通信員IPv6ノードの間でIPsecを使用し」て、デュポン、F.、およびJ.コンブは進歩、2004年8月に働いています。
[16] Dupont, F. and J. Combes, "Care-of Address Test for MIPv6 using
a State Cookie", Work in Progress, July 2006.
[16] デュポン、F.、およびJ.コンブ、「注意、-、州のクッキーを使用して、MIPv6のためにテストを扱ってください、」、7月2006、進行中で、働いてください。
[17] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., and B.
Patil, "Privacy for Mobile and Multi-homed Nodes: MoMiPriv
Problem Statement", Work in Progress, June 2006.
そして、[17] ハダド、W.、Nordmark、E.、デュポン、F.、Bagnulo、M.、およびB.パティル、「モバイルのためのプライバシー、マルチ、家へ帰り、ノード:、」 「MoMiPriv問題声明」、処理中の作業、2006年6月。
[18] "IEEE Standard for Local and Metropolitan Area Networks: Port-
Based Network Access Control", IEEE Standard 802.1X, December
2004.
[18]、「地方とメトロポリタンエリアネットワークのIEEE規格:」 「ポートはネットワークアクセスコントロールを基礎づけた」IEEEの標準の802.1X、2004年12月。
[19] Choi, J. and E. Nordmark, "DNA with Unmodified Routers: Prefix
List Based Approach", Work in Progress, January 2006.
[19] チェ、J.、およびE.Nordmark、「変更されていないルータがあるDNA:」 「接頭語のリストのベースのアプローチ」、進行中の仕事、2006年1月。
[20] Narayanan, S., Ed., "Detecting Network Attachment in IPv6
Networks (DNAv6)", Work in Progress, October 2006.
[20] エドナラヤナン、S.、処理中の作業、「IPv6ネットワーク(DNAv6)でネットワーク付属を見つける」10月2006日
[21] Moskowitz, R., Nikander, P., Jokela, Ed., P., and T. Henderson,
"Host Identity Protocol", Work in Progress, June 2006.
[21] マスコウィッツ、R.、Nikander、P.、Jokela、エド、6月2006、P.、およびT.ヘンダーソン、「ホストアイデンティティプロトコル」は進行中で働いています。
[22] Henderson, T., Ed., "End-Host Mobility and Multihoming with the
Host Identity Protocol", Work in Progress, June 2006.
[22] ヘンダーソン、T.、エド、6月2006、「ホストアイデンティティプロトコルがある終わりホストの移動性とマルチホーミング」は進行中で働いています。
[23] Moore, N., "Optimistic Duplicate Address Detection (DAD) for
IPv6", RFC 4429, April 2006.
[23] ムーア、N.、「IPv6"、RFC4429、2006年4月のための楽観的な写しアドレス検出(おとうさん)。」
[24] Koodli, R., "IP Address Location Privacy and Mobile IPv6:
Problem Statement", Work in Progress, October 2006.
[24]Koodli、R.、「IPは、位置がプライバシーとモバイルIPv6であると扱います」。 「問題声明」、処理中の作業、2006年10月。
[25] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a
Static Shared Key", RFC 4449, June 2006.
[25] パーキンス、C.、「モバイルIPv6が静的な共有されたキーを使用する経路最適化であると機密保護します」、RFC4449、2006年6月。
[26] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility
Route Optimization Problem Statement", Work in Progress,
September 2006.
[26] ウン、C.、P.と亘理、M.とF.チャオ、「ネットワーク移動性経路最適化問題声明」というThubertは進行中(2006年9月)で働いています。
Vogt & Arkko Informational [Page 27] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[27ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
[27] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility
Route Optimization Solution Space Analysis", Work in Progress,
September 2006.
[27] ウン、C.、チャオ、F.、亘理、M.、およびP.Thubertは「移動性経路最適化ソリューション宇宙分析をネットワークでつなぎます」、処理中の作業、2006年9月。
[28] Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Work
in Progress, October 2003.
[28] 「半径への移管拡大」というArbaugh、W.、およびB.Abobaは進歩、2003年10月に働いています。
[29] "Kame-Shisa", Mobile IPv6 for FreeBSD.
[29]「ケイム-Shisa」、無料OSの一つのためのモバイルIPv6。
[30] Koodli, R., Devarapalli, V., Flinck, H., and C. Perkins,
"Solutions for IP Address Location Privacy in the Presence of
IP Mobility", Work in Progress, February 2005.
[30] R.、Devarapalli、V.、フリンク、H.、およびC.パーキンス、「IPの移動性があるときIPアドレス位置のプライバシーのためのソリューション」というKoodliは進行中(2005年2月)で働いています。
[31] Nuorvala, V., Petander, H., and A. Tuominen, "Mobile IPv6 for
Linux (MIPL)".
[31]Nuorvala、V.、Petander、H.、およびA.Tuominen、「リナックス(MIPL)のためのモバイルIPv6。」
[32] Mishra, A., Shin, M., Petroni Jr., N., Clancy, C., and W.
Arbaugh, "Proactive Key Distribution Using Neighbor Graphs",
IEEE Wireless Communications, Vol. 11, No. 1, February 2004.
[32] Mishra(A.)はよじ登ります、M.、ペトローニJr.、N.、クランシー、C.とW.Arbaugh、「隣人グラフを使用して、主要な分配を予測してください」IEEE無線通信、Vol.11、No.1、2004年2月。
[33] Montenegro, G. and Claude. Castelluccia, "Crypto-Based
Identifiers (CBIDs): Concepts and Applications", ACM
Transactions on Information and System Security Vol.7, No. 1,
February 2004.
[33] モンテネグロ、G.、およびクロード。 Castelluccia、「暗号ベースの識別子(CBIDs):」 「概念とアプリケーション」、情報に関するACMトランザクションとシステムセキュリティVol.7、No.1、2月2004日
[34] Nikander, P., "Denial-of-Service, Address Ownership, and Early
Authentication in the IPv6 World", Revised papers from the
International Workshop on Security Protocols, Springer-Verlag,
April 2002.
[34] Revisedは、Securityプロトコルの国際WorkshopからNikanderと、P.と、「サービス妨害、アドレス所有権、およびIPv6世界での早めの認証」に紙を張ります、Springer-Verlag、2002年4月。
[35] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6",
ACM SIGCOMM Computer Communication Review, April 2001.
[35] オシアとG.とM.魚卵、「MIPv6"のための子供にとって安全な認証、ACM SIGCOMMコンピュータコミュニケーションレビュー、2001年4月。」
[36] Perera, E., Sivaraman, V., and A. Seneviratne, "Survey on
Network Mobility Support", ACM SIGCOMM Computer Communication
Review, Vol. 8, No. 2, ACM Press, April 2004.
[36] ペレラとE.とSivaraman、V.とA.Seneviratne、「ネットワーク移動性サポートの調査」ACM SIGCOMMコンピュータコミュニケーションレビュー、Vol.8、No.2、ACMは押します、2004年4月。
[37] Bao, F., Deng, R., Qiu, Y., and J. Zhou, "Certificate-
basedBinding Update Protocol (CBU)", Work in Progress, March
2005.
[37] バオ、F.、?、R.、Qiu、Y.、およびJ.周が進歩、2005年3月に働いていると「basedBindingアップデートプロトコル(CBU)は証明します」。
[38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[38] ファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[39] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003.
[39]Abley、J.、黒、B.、およびV.エラ、「IPv6サイトマルチホーミングアーキテクチャの目標」、RFC3582、2003年8月。
Vogt & Arkko Informational [Page 28] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[28ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
[40] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[40]Arkko、J.、Devarapalli、V.、およびF.デュポン、「モバイルノードとホームのエージェントの間で合図するモバイルIPv6を保護するのにIPsecを使用します」、RFC3776(2004年6月)。
[41] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[41]Devarapalli、V.、Wakikawa、R.、ペトレスク、A.、およびP.Thubert、「ネットワークの移動性(ネモ)の基本的なサポートプロトコル」、RFC3963、2005年1月。
[42] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[42] ケント、S.、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC4303、2005年12月。
[43] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[43] ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
[44] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC
3972, March 2005.
[44] 香気(T.)が「暗号で、アドレス(CGA)を作った」、RFC3972、3月2005日
[45] Huston, G., "Architectural Approaches to Multi-homing for
IPv6", RFC 4177, September 2005.
[45] ヒューストン、G.、「IPv6"、RFC4177、2005年9月のためのマルチホーミングへの建築アプローチ。」
[46] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005.
[46]Nikander、P.、Arkko、J.、香気、T.、モンテネグロ、G.、およびE.Nordmark、「モバイルIPバージョン6経路最適化セキュリティはバックグラウンドを設計します」、RFC4225、2005年12月。
[47] Roe, M., Aura, T., O'Shea, G., and J. Arkko, "Authentication of
Mobile IPv6 Binding Updates and Acknowledgments", Work in
Progress, February 2002.
「モバイルIPv6拘束力があるアップデートと承認の認証」という[47]魚卵、M.、香気、T.、オシア、G.、およびJ.Arkkoは進行中(2002年2月)で働いています。
[48] Vadali, R., Li, J., Wu, Y., and G. Cao, "Agent-Based Route
Optimization for Mobile IP", Proceedings of the IEEE Vehicular
Technology Conference, October 2001.
[48]Vadali、R.、李、J.、ウー、Y.、およびG.ツァオ、「モバイルIPのためのエージェントベースの経路最適化」、IEEE車両技術部会コンファレンス(2001年10月)の議事。
[49] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b
MAC Layer Handoff Time", Laboratory for Communication Networks,
KTH, Royal Institute of Technology, Stockholm, Sweden, TRITA-
IMIT-LCN R 03:02, April 2003.
通信ネットワーク、KTH、王立の工科大学、ストックホルム(スウェーデン)TRITA- IMIT-LCN R03:02、2003年4月の[49]Velayos、H.とG.カールソン、「IEEE 802.11b MAC層の移管時間を短縮するテクニック」研究所。
[50] Vogt, C., "Credit-Based Authorization for Concurrent IP-Address
Tests", Proceedings of the IST Mobile and Wireless
Communications Summit, June 2005.
[50] フォークト、C.、「同時発生のIP-アドレステストのためのクレジットベースの認可」、ISTのモバイルの、そして、無線のコミュニケーションサミット、2005年6月の議事。
[51] Vogt, C., Bless, R., Doll, M., and T. Kuefner, "Early Binding
Updates for Mobile IPv6", Proceedings of the IEEE Wireless
Communications and Networking Conference, IEEE, Vol. 3, March
2005.
フォークト、C.が祝福する[51]、R.、人形、M.とT.Kuefner、「早めの結合はモバイルIPv6"、IEEEの議事のために無線通信とネットワークコンファレンスをアップデートします、IEEE、Vol.3、2005年3月。」
Vogt & Arkko Informational [Page 29] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[29ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
[52] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in
IPv6", Proceedings of the IEEE Wireless Communications and
Networking Conference, April 2006.
[52] フォークト、C.、およびM.は、「IPv6"での終わりから終わりへの移動性効率的なサポート、IEEE無線通信とネットワークコンファレンスの議事、2006年4月」をめかします。
[53] Vogt, C., "A Comprehensive Delay Analysis for Reactive and
Proactive Handoffs with Mobile IPv6 Route Optimization",
Institute of Telematics, Universitaet Karlsruhe (TH),
Karlsruhe, Germany, TM-2006-1, January 2006.
フォークト、C.、「モバイルIPv6経路最適化との反応していて先を見越すHandoffsに、包括的な遅れ分析」が設けるテレマティックス、Universitaet(TH)、カールスルーエカールスルーエ(ドイツ)TM-2006-1(2006年1月)の[53]。
[54] Zhao, F., Wu, F., and S. Jung, "Extensions to Return
Routability Test in MIP6", Work in Progress, February 2005.
[54] チャオとF.とウー、F.とS.ユング、「2005年2月にMIP6"でのRoutabilityテスト、進行中の仕事を返す拡大。」
[55] Calderon, M., Bernardos, C., Bagnulo, M., Soto, I., and A. de
la Oliva, "Design and Experimental Evaluation of a Route
Optimisation Solution for NEMO", IEEE Journal on Selected Areas
in Communications, Vol. 24, No. 9, September 2006.
[55] カルデロン、M.、Bernardos、C.、Bagnulo、M.、ソト、I.、A.de laオリバ、および「ネモのためのaルート最適化解決のデザインと実験的な評価」、CommunicationsのSelected Areasの上のIEEE Journal、Vol.24、No.9(2006年9月)
Authors' Addresses
作者のアドレス
Christian Vogt Institute of Telematics Universitaet Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany
クリスチャンのフォークトテレマティックスUniversitaetカールスルーエ研究所(TH)P.O. Box6980 76128カールスルーエドイツ
EMail: chvogt@tm.uka.de
メール: chvogt@tm.uka.de
Jari Arkko Ericsson Research NomadicLab FI-02420 Jorvas Finland
ヤリ・Arkkoエリクソン研究NomadicLab FI-02420 Jorvasフィンランド
EMail: jari.arkko@ericsson.com
メール: jari.arkko@ericsson.com
Vogt & Arkko Informational [Page 30] RFC 4651 MIP6 Route Optimization Enhancements February 2007
フォークトとArkkoの情報[30ページ]のRFC4651MIP6は2007年2月に最適化増進を発送します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Vogt & Arkko Informational [Page 31]
フォークトとArkko情報です。[31ページ]
一覧
スポンサーリンク
