Network Working Group S. Vaarala
Request for Comments: 5265 Codebay
Category: Standards Track E. Klovning
Birdstep
June 2008
Mobile IPv4 Traversal across IPsec-Based VPN Gateways
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document outlines a solution for the Mobile IPv4 (MIPv4) and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely.
この文書は、企業ユーザのためのモバイルIPv4（MIPv4の）およびIPsec共存問題の解決策を概説します。ソリューションは、企業のリモートアクセスのシナリオでセッションモビリティのためのモバイルIPv4およびIPsecを使用するための適用性声明、しっかりと信頼できる内部ネットワークを検出するために必要なメカニズムで構成されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Related Work . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Terms and Abbreviations . . . . . . . . . . . . . . . . . 5
1.5. Requirement Levels . . . . . . . . . . . . . . . . . . . . 6
1.6. Assumptions and Rationale . . . . . . . . . . . . . . . . 7
1.7. Why IPsec Lacks Mobility . . . . . . . . . . . . . . . . . 8
2. The Network Environment . . . . . . . . . . . . . . . . . . . 9
2.1. Access Mode: 'c' . . . . . . . . . . . . . . . . . . . . . 12
2.2. Access Mode: 'f' . . . . . . . . . . . . . . . . . . . . . 13
2.3. Access Mode: 'cvc' . . . . . . . . . . . . . . . . . . . . 13
2.4. Access Mode: 'fvc' . . . . . . . . . . . . . . . . . . . . 14
2.5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 14
3. Internal Network Detection . . . . . . . . . . . . . . . . . . 15
3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Implementation Requirements . . . . . . . . . . . . . . . 16
3.2.1. Separate Tracking of Network Interfaces . . . . . . . 16
3.2.2. Connection Status Change . . . . . . . . . . . . . . . 16
3.2.3. Registration-Based Internal Network Detection . . . . 17
3.2.4. Registration-Based Internal Network Monitoring . . . . 17
3.3. Proposed Algorithm . . . . . . . . . . . . . . . . . . . . 19
3.4. Trusted Networks Configured (TNC) Extension . . . . . . . 20
3.5. Implementation Issues . . . . . . . . . . . . . . . . . . 20
3.6. Rationale for Design Choices . . . . . . . . . . . . . . . 21
3.6.1. Firewall Configuration Requirements . . . . . . . . . 21
3.6.2. Registration-Based Internal Network Monitoring . . . . 22
3.6.3. No Encryption When Inside . . . . . . . . . . . . . . 22
3.7. Improvements . . . . . . . . . . . . . . . . . . . . . . . 22
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Mobile Node Requirements . . . . . . . . . . . . . . . . . 23
4.2. VPN Device Requirements . . . . . . . . . . . . . . . . . 23
4.3. Home Agent Requirements . . . . . . . . . . . . . . . . . 24
5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Comparison against Guidelines . . . . . . . . . . . . . . 24
5.2. Packet Overhead . . . . . . . . . . . . . . . . . . . . . 26
5.3. Latency Considerations . . . . . . . . . . . . . . . . . . 27
5.4. Firewall State Considerations . . . . . . . . . . . . . . 27
5.5. Intrusion Detection Systems (IDSs) . . . . . . . . . . . . 28
5.6. Implementation of the Mobile Node . . . . . . . . . . . . 28
5.7. Non-IPsec VPN Protocols . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6.1. Internal Network Detection . . . . . . . . . . . . . . . . 29
6.2. Mobile IPv4 versus IPsec . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Packet Flow Examples . . . . . . . . . . . . . . . . 34
A.1. Connection Setup for Access Mode 'cvc' . . . . . . . . . . 34
The Mobile IP working group set out to explore the problem and solution spaces of IPsec and Mobile IP coexistence. The problem statement and solution requirements for Mobile IPv4 case were first documented in [RFC4093]. This document outlines a solution for IPv4.
モバイルIPワーキンググループは、IPsecとモバイルIP共存の問題と解決策スペースを探検するために着手しました。モバイルIPv4の場合の問題文と溶液の要件は、最初の[RFC4093]に記載されました。この文書では、IPv4のためのソリューションの概要を説明します。
The document contains two parts:
文書には2つの部分が含まれています。
o a basic solution that is an applicability statement of Mobile IPv4 and IPsec to provide session mobility between enterprise intranets and external networks, intended for enterprise mobile users; and
企業モバイルユーザーを対象企業のイントラネットと外部ネットワークとの間のセッションモビリティを提供するために、モバイルIPv4およびIPsecの適用文、ある塩基性溶液Oであり;そして
o a technical specification and a set of requirements for secure detection of the internal and the external networks, including a new extension that must be implemented by a mobile node and a home agent situated inside the enterprise network.
技術仕様および企業ネットワーク内に位置し、移動ノードとホームエージェントによって実装されなければならない新しい拡張機能を含む内部の安全な検出と外部ネットワークの要件、一連のO。
There are many useful ways to combine Mobile IPv4 and IPsec. The solution specified in this document is most applicable when the assumptions documented in the problem statement [RFC4093] are valid; among others that the solution:
モバイルIPv4およびIPsecを組み合わせるための多くの有用な方法があります。問題文[RFC4093]で文書化の仮定が有効であるときは、この文書で指定されたソリューションは、最も適切です。解決策その中でも：
o must minimize changes to existing firewall/VPN/DMZ (DeMilitarized Zone) deployments;
oは既存のファイアウォール/ VPN / DMZ（非武装地帯）の展開への変更を最小限に抑える必要があります。
o must ensure that traffic is not routed through the DMZ when the mobile node is inside (to avoid scalability and management issues);
oは（スケーラビリティや管理の問題を避けるために）、モバイルノードが内部にあるときにトラフィックがDMZ経由でルーティングされていないことを確認する必要があります。
o must support foreign networks with only foreign agent access;
oは唯一の外国人のエージェントのアクセスを持つ外国人のネットワークをサポートしている必要があります。
o should not require changes to existing IPsec or key exchange protocols;
oは既存のIPsecまたは鍵交換プロトコルの変更を必要とすべきではありません。
o must comply with the Mobile IPv4 protocol (but may require new extensions or multiple instances of Mobile IPv4); and
Oは、モバイルIPv4プロトコルに従わなければならない（ただし、新しい拡張またはモバイルIPv4の複数のインスタンスを必要とするかもしれません）。そして
o must propose a mechanism to avoid or minimize IPsec re-negotiation when the mobile node moves.
oは、移動ノードの移動のIPsecの再交渉を回避または最小化するためのメカニズムを提案する必要があります。
Typical corporate networks consist of three different domains: the Internet (untrusted external network), the intranet (trusted internal network), and the DMZ, which connects the two networks. Access to the internal network is guarded both by a firewall and a VPN device;
インターネット（信頼できない外部ネットワーク）、イントラネット（信頼できる内部ネットワーク）、および2つのネットワークを接続するDMZ、典型的な企業ネットワークは、3つの異なるドメインからなります。内部ネットワークへのアクセスは、ファイアウォールやVPNデバイスの両方によって守られています。
access is only allowed if both firewall and VPN security policies are respected.
両方のファイアウォールとVPNのセキュリティポリシーが尊重されている場合はアクセスは許可されます。
Enterprise mobile users benefit from unrestricted seamless session mobility between subnets, regardless of whether the subnets are part of the internal or the external network. Unfortunately, the current Mobile IPv4 and IPsec standards alone do not provide such a service [tessier].
エンタープライズモバイルユーザーには関係なく、サブネットが内部または外部のネットワークの一部であるかどうかの、サブネット間の無制限のシームレスなセッションモビリティの恩恵を受ける。残念ながら、現在のモバイルIPv4およびIPsecの規格だけでは、そのようなサービス[テッシェ]を提供していません。
The solution is to use standard Mobile IPv4 (except for a new extension used by the home agent in the internal network to aid in network detection) when the mobile node is in the internal network, and to use the VPN tunnel endpoint address for the Mobile IPv4 registration when outside. IPsec-based VPN tunnels require re-negotiation after movement. To overcome this limitation, another layer of Mobile IPv4 is used underneath IPsec, in effect making IPsec unaware of movement. Thus, the mobile node can freely move in the external network without disrupting the VPN connection.
溶液は、モバイルノードが内部ネットワークにある場合（ネットワーク検出を助けるために、内部ネットワーク内のホームエージェントによって使用される新しい拡張を除く）標準モバイルIPv4を使用すること、およびモバイルVPNトンネルのエンドポイントアドレスを使用することですIPv4の登録時に外。 IPsecベースのVPNトンネルは、移動後に再交渉を要求します。この制限を克服するために、モバイルIPv4の他の層は、運動を知らないIPsecを作る実際に、IPsecの下に使用されます。したがって、モバイルノードは、自由にVPN接続を中断することなく外部のネットワークに移動することができます。
Briefly, when outside, the mobile node:
簡単に言うと、とき外、モバイルノード：
o detects that it is outside (Section 3);
Oは、外部（セクション3）であることを検出します。
o registers its co-located or foreign agent care-of address with the external home agent;
Oその共同設置または外部エージェントの気付アドレス外部ホームエージェントを登録します。
o establishes a VPN tunnel using, e.g., Internet Key Exchange Protocol (IKE) (or IKEv2) if security associations are not already available;
セキュリティアソシエーションが既に利用可能でない場合oは、例えば、インターネット鍵交換プロトコル（IKE）（又はIKEv2の）を使用してVPNトンネルを確立します。
o registers the VPN tunnel address as its co-located care-of address with the internal home agent; this registration request is sent inside the IPsec tunnel.
Oの同一位置気付アドレス内部ホームエージェントと同様にVPNトンネルアドレスを登録します。この登録要求は、IPsecトンネルの内部に送られます。
The solution requires control over the protocol layers in the mobile node. It must be capable of (1) detecting whether it is inside or outside in a secure fashion, and (2) controlling the protocol layers accordingly. For instance, if the mobile node is inside, the IPsec layer needs to become dormant.
溶液は、移動ノードのプロトコル層の制御を必要とします。それは、（1）それは安全な方法で内側または外側であるかどうかを検出し、（2）それに応じてプロトコル層を制御することができなければなりません。モバイルノードが内部である場合、例えば、IPSecレイヤは、休止状態になる必要があります。
Except for the new Mobile IPv4 extension to improve security of internal network detection, current Mobile IPv4 and IPsec standards, when used in a suitable combination, are sufficient to implement the solution. No changes are required to existing VPN devices or foreign agents.
適切な組み合わせで使用する場合、内部ネットワーク検出のセキュリティを改善するための新しいモバイルIPv4拡張を除いて、現在のモバイルIPv4およびIPsec規格は、ソリューションを実装するのに十分です。変更は、既存のVPNデバイスや外国人のエージェントに必要ありません。
The solution described is compatible with different kinds of IPsec-based VPNs, and no particular kind of VPN is required. Because the appropriate Security Policy Database (SPD) entries and other IKE and IPsec specifics differ between deployed IPsec-based VPN products, these details are not discussed in the document.
記載された解決策は、IPsecベースのVPNの異なる種類と互換性があり、そしてVPNのいかなる特定の種類を必要としません。適切なセキュリティポリシーデータベース（SPD）エントリおよびその他のIKEおよびIPsec仕様が展開されたIPsecベースのVPN製品間で異なるので、これらの詳細は、文書で説明されていません。
This document describes a solution for IPv4 only. The downside of the described approach is that an external home agent is required and that the packet overhead (see Section 5) and overall complexity increase. Optimizations would require significant changes to Mobile IPv4 and/or IPsec, and are out of scope of this document.
この文書では、IPv4のみのための解決策を説明しています。記載されているアプローチの欠点は、外部ホームエージェントが必要なことであると、パケットのオーバーヘッド（セクション5を参照）、全体的な複雑さの増加という。最適化は、モバイルIPv4および/またはIPsecのに大幅な変更を必要とし、この文書の範囲外であるでしょう。
VPN, in this document, refers to an IPsec-based remote access VPN. Other types of VPNs are out of scope.
VPNは、この文書では、IPsecベースのリモートアクセスVPNを指します。 VPNの他のタイプの範囲外です。
Related work has been done on Mobile IPv6 in [RFC3776], which discusses the interaction of IPsec and Mobile IPv6 in protecting Mobile IPv6 signaling. The document also discusses dynamic updating of the IPsec endpoint based on Mobile IP signaling packets.
関連する作業は、モバイルIPv6シグナリングを保護するIPsecとモバイルIPv6の相互作用を説明した、[RFC3776]にモバイルIPv6で行われています。文書は、モバイルIPシグナリングパケットに基づいてのIPsecエンドポイントの動的更新を論じています。
The "transient pseudo-NAT" attack, described in [pseudonat] and [mipnat], affects any approach that attempts to provide security of mobility signaling in conjunction with NAT devices. In many cases, one cannot assume any cooperation from NAT devices, which thus have to be treated as any other networking entity.
記載された「過渡疑似NAT」攻撃、[pseudonat]及び[mipnat]、NATデバイスに関連してモビリティシグナリングのセキュリティを提供しようとする任意のアプローチに影響を与えます。多くの場合、1は、このように、他のネットワークエンティティとして扱われなければならNATデバイスから任意の協力を負いかねます。
The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555] provides better mobility for IPsec. This would allow the external Mobile IPv4 layer described in this specification to be removed. However, deploying MOBIKE requires changes to VPN devices, and is thus out of scope of this specification.
IKEv2のモビリティとマルチホーミングプロトコル（MOBIKE）[RFC4555]はIPsecのためのより良いモビリティを提供します。これは、本明細書に記載の外部モバイルIPv4層を除去することを可能にします。しかし、MOBIKEを展開するVPN装置への変更を必要とし、この仕様の範囲外のことです。
co-CoA: co-located care-of address.
CO-CoAの：共存気付アドレス。
DMZ: (DeMilitarized Zone) a small network inserted as a "neutral zone" between a company's private network and the outside public network to prevent outside users from getting direct access to the company's private network.
DMZ（非武装地帯）、企業のプライベートネットワークと企業のプライベートネットワークへの直接アクセスを得ることから外部のユーザーを防ぐために、外部のパブリックネットワークとの間に「中立地帯」として挿入小規模ネットワーク。
external network: the untrusted network (i.e., Internet). Note that a private network (e.g., another corporate network) other than the mobile node's internal network is considered an external network.
外部ネットワーク：信頼できないネットワーク（すなわち、インターネット）。モバイルノードの内部ネットワーク以外のプライベートネットワーク（例えば、別の企業ネットワーク）は、外部ネットワークとみなされることに留意されたいです。
FA: mobile IPv4 foreign agent.
FA：モバイルIPv4の外国人のエージェント。
FA-CoA: foreign agent care-of address.
FA-CoAを：外国人のエージェントの気付アドレス。
FW: firewall.
FW：ファイアウォール。
internal network: the trusted network; for instance, a physically secure corporate network where the i-HA is located.
内部ネットワーク：信頼できるネットワーク。例えば、I-HAが配置されている物理的に安全な企業ネットワーク。
i-FA: Mobile IPv4 foreign agent residing in the internal network.
I-FA：内部ネットワークに存在するモバイルIPv4外部エージェント。
i-HA: Mobile IPv4 home agent residing in the internal network; typically has a private address [privaddr].
I-HA：内部ネットワークに存在するモバイルIPv4ホームエージェント。通常、[privaddr]プライベートアドレスを持っています。
i-HoA: home address of the mobile node in the internal home agent.
I-のHoA：内部ホームエージェントにおけるモバイルノードのホームアドレス。
MN: mobile node.
MN：モバイルノード。
NAI: Network Access Identifier [RFC4282].
NAI：ネットワークアクセス識別子[RFC4282]。
R: router.
R：ルータ。
VPN: Virtual Private Network based on IPsec.
VPN：IPsecのに基づいて、仮想プライベートネットワーク。
VPN-TIA: VPN tunnel inner address, the address(es) negotiated during IKE phase 2 (quick mode), assigned manually, using IPsec-DHCP [RFC3456], using the "de facto" standard Internet Security Association and Key Management Protocol (ISAKMP) configuration mode, or by some other means. Some VPN clients use their current care-of address as their Tunnel Inner Address (TIA) for architectural reasons.
VPN-TIA：VPNトンネル内部アドレス、アドレス（複数可）は、「事実上の」標準的なインターネットセキュリティアソシエーションおよび鍵管理プロトコルを（使用して、IPsecでDHCP [RFC3456]を使用して、手動で割り当てられたIKEフェーズ2（クイックモード）、中にネゴシエートISAKMP）コンフィギュレーションモード、または何らかの他の手段によって。一部のVPNクライアントは、建築的な理由のための彼らのトンネル内部アドレス（TIA）として彼らの現在の気付アドレスを使用します。
VPN tunnel: an IPsec-based tunnel; for instance, IPsec tunnel mode IPsec connection, or Layer 2 Tunneling Protocol (L2TP) combined with IPsec transport connection.
VPNトンネル：IPSecベーストンネル。例えば、IPsecトンネル・モードのIPsec接続、またはレイヤ2トンネリングプロトコル（L2TP）のIPsecトランスポート接続と組み合わせます。
x-FA: Mobile IPv4 foreign agent residing in the external network.
X-FA：外部ネットワークに存在するモバイルIPv4外部エージェント。
x-HA: Mobile IPv4 home agent residing in the external network.
X-HA：外部ネットワークに存在するモバイルIPv4ホームエージェント。
x-HoA: home address of the mobile node in the external home agent.
X-のHoA：外部ホームエージェントでは、モバイルノードのホームアドレス。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
The solution is an attempt to solve the problem described in [RFC4093]. The major assumptions and their rationale is summarized below.
溶液は、[RFC4093]に記載された問題を解決するための試みです。主要な仮定とその根拠を以下に要約されます。
Changes to existing firewall and VPN deployments should be minimized:
既存のファイアウォールとVPNの展開への変更を最小限にする必要があります。
o The current deployment of firewalls and IPsec-based VPNs is much larger than corresponding Mobile IPv4 elements. Thus, a solution should work within the existing VPN infrastructure.
ファイアウォールとIPsecベースのVPNの現在の配備oをモバイルIPv4の対応する要素よりはるかに大きいです。したがって、解決策は、既存のVPNインフラストラクチャ内で動作するはずです。
o Current enterprise network deployments typically centralize management of security and network access into a compact DMZ.
O現在の企業ネットワークの展開は、一般的にコンパクトなDMZにセキュリティとネットワークアクセスの管理を一元化します。
When the mobile node is inside, traffic should not go through the DMZ network:
モバイルノードが内部にある場合は、トラフィックがDMZネットワークを介して行ってはなりません。
o Routing all mobile node traffic through the DMZ is seen as a performance problem in existing deployments of firewalls. The more sophisticated firewall technology is used (e.g., content scanning), the more serious the performance problem is.
DMZを介してすべてのモバイルノードのトラフィックをルーティングoをファイアウォールの既存の展開におけるパフォーマンスの問題として見られています。より洗練されたファイアウォール技術が使用されている（例えば、コンテンツスキャン）は、より深刻なパフォーマンスの問題があります。
o Current deployments of firewalls and DMZs in general have been optimized for the case where only a small minority of total enterprise traffic goes through the DMZ. Furthermore, users of current VPN remote access solutions do not route their traffic through the DMZ when connected to an internal network.
O一般的には、ファイアウォールやDMZのの現在の展開では、全企業のトラフィックのごく少数がDMZを経由する場合に最適化されています。内部ネットワークに接続したときにさらに、現在のVPNリモートアクセスソリューションのユーザーは、DMZを通るルートのトラフィックをしません。
A home agent inside the enterprise cannot be reached directly from outside, even if the home agent contains IPsec functionality:
企業内のホームエージェントは、ホームエージェントは、IPsecの機能が含まれている場合でも、外部から直接アクセスすることはできません。
o Deployment of current combined IPsec/MIPv4 solutions are not common in large installations.
O現在の組み合わせのIPsec / MIPv4のソリューションの展開は、大規模なインストールでは一般的ではありません。
o Doing decryption in the home agents "deep inside" the enterprise effectively means having a security perimeter much larger than the typical, compact DMZ used by a majority of enterprises today.
ホームエージェントで復号化を行う「心の奥底」O企業が効果的に、今日の企業の大半で使用される典型的な、コンパクトなDMZよりも境界セキュリティを持つはるかに大きいことを意味します。
o In order to maintain a security level equal to current firewall/ DMZ deployments, every home agent decapsulating IPsec would need to do the same firewalling as the current DMZ firewalls (content scanning, connection tracking, etc.).
O現在のファイアウォール/ DMZの展開と同等のセキュリティレベルを維持するために、IPsecをデカプセル化すべてのホームエージェントは、現在のDMZファイアウォール（コンテンツスキャン、接続の追跡など）と同じファイアウォールを実行する必要があります。
Traffic cannot be encrypted when the mobile node is inside:
モバイルノードが内部にあるときに、トラフィックを暗号化することができません。
o There is a considerable performance impact on home agents (which currently do rather light processing) and mobile nodes (especially for small devices). Note that traffic throughput inside the enterprise is typically an order (or more) of magnitude larger than the remote access traffic through a VPN.
O家（現在はむしろ光処理を行う）の薬剤と（特に小型デバイス用）モバイルノードにかなりのパフォーマンスへの影響はあります。企業内のトラフィックのスループットは、典型的には、VPNを介してリモート・アクセス・トラフィックよりも大きい大きさのオーダー（またはそれ以上）であることに留意されたいです。
o Encryption consumes processing power and has a significant impact on device battery life.
Oの暗号化処理電力を消費し、デバイスのバッテリ寿命に大きな影響を与えます。
o There is also a usability issue involved; the user needs to authenticate the connection to the IPsec layer in the home agent to gain access. For interactive authentication mechanisms (e.g., SecurID), this always means user interaction.
O関与ユーザビリティの問題もあります。ユーザーがアクセスするために、ホームエージェントのIPsec層への接続を認証する必要があります。インタラクティブ認証メカニズム（例えば、SecurIDの）のために、これは常にユーザの相互作用を意味します。
o Furthermore, if there is a separate VPN device in the DMZ for remote access, the user needs to authenticate to both devices, and might need to have separate credentials for both.
リモートアクセスのためのDMZ内の別々のVPNデバイスがある場合は、Oさらに、ユーザーは両方のデバイスに対して認証する必要があり、両方のための別の資格情報を持っている必要があるかもしれません。
o Current Mobile IPv4 home agents do not typically incorporate IPsec functionality, which is relevant for the solution when we assume zero or minimal changes to existing Mobile IPv4 nodes.
O現在のモバイルIPv4ホームエージェントは、一般的に、我々は、既存のモバイルIPv4ノードにゼロまたは最小限の変更を前提としたときにソリューションに関連するIPsecの機能は、内蔵されていません。
o Note, however, that the assumption (no encryption when inside) does not necessarily apply to all solutions in the solution space; if the above mentioned problems were resolved, there is no fundamental reason why encryption could not be applied when inside.
O仮定（内部暗号化なし）は必ず解空間内のすべてのソリューションには適用されないこと、しかし、注意してください。上記の問題が解決された場合、内部の暗号化が適用されなかった理由根本的な理由はありません。
IPsec, as currently specified [RFC4301], requires that a new IKE negotiation be done whenever an IPsec peer moves, i.e., changes care-of address. The main reason is that a security association is unidirectional and identified by a triplet consisting of (1) the destination address (which is the outer address when tunnel mode is used), (2) the security protocol (Encapsulating Security Payload (ESP) or Authentication Header (AH)), and (3) the Security Parameter Index (SPI) ([RFC4301], Section 4.1). Although an implementation is not required to use all of these for its own Security Associations (SAs), an implementation cannot assume that a peer does not.
IPsecのような現在指定[RFC4301]は、IPsecピアが移動する、すなわち、気付アドレスを変更するたびに、新しいIKEネゴシエーションが行われることを必要とします。主な理由は、セキュリティアソシエーションが一方向と（トンネルモードを使用する外側アドレスである）（1）宛先アドレスからなるトリプレットにより同定、（2）セキュリティプロトコル（カプセル化セキュリティペイロード（ESP）またはであることです認証ヘッダー（AH））、および（3）セキュリティパラメータインデックス（SPI）（[RFC4301]、セクション4.1）。実装は、独自のセキュリティアソシエーション（SA）のためにこれらのすべてを使用する必要はありませんが、実装は、ピアがないと仮定することはできません。
When a mobile IPsec peer sends packets to a stationary IPsec peer, there is no problem; the SA is "owned" by the stationary IPsec peer, and therefore the destination address does not need to change. The (outer) source address should be ignored by the stationary peer (although some implementations do check the source address as well).
モバイルIPSecピアが静止IPsecピアにパケットを送信するとき、問題はありません。 SAは、静止したIPsecピアによって「所有」されているため、宛先アドレスは変更する必要はありません。 （外側の）ソースアドレスが固定のピア（いくつかの実施態様は、同様に送信元アドレスを確認しないが）によって無視されるべきです。
The problem arises when packets are sent from the stationary peer to the mobile peer. The destination address of this SA (SAs are unidirectional) is established during IKE negotiation, and is effectively the care-of address of the mobile peer at time of negotiation. Therefore, the packets will be sent to the original care-of address, not a changed care-of address.
パケットがモバイルピアに固定ピアから送信されたときに問題が生じます。このSA（SAが一方向である）の宛先アドレスは、IKEネゴシエーション中に確立し、ネゴシエーション時に効果的に移動ピアの気付アドレスです。したがって、パケットは、元の気付アドレスではなく、変更された気付けアドレスに送信されます。
The IPsec NAT traversal mechanism can also be used for limited mobility, but UDP tunneling needs to be used even when there is no NAT in the route between the mobile and the stationary peers. Furthermore, support for changes in current NAT mapping is not required by the NAT traversal specification [RFC3947].
IPsecのNATトラバーサル機構はまた、限られた移動性のために使用することができるが、UDPトンネリングはモバイルと固定のピアとの間の経路にはNATが存在しない場合にも使用する必要があります。さらに、現在のNATマッピングの変化のためのサポートは、NATトラバーサル仕様[RFC3947]によって必要とされません。
In summary, although the IPsec standard does not as such prevent mobility (in the sense of updating security associations on-the-fly), the standard does not include a built-in mechanism (explicit or implicit) for doing so. Therefore, it is assumed throughout this document that any change in the addresses comprising the identity of an SA requires IKE re-negotiation, which implies too heavy computation and too large latency for useful mobility.
IPsecの規格では、そのようなものが（オンザフライセキュリティアソシエーションを更新するという意味での）移動性を妨げないようものの要約すると、標準ではそうするために（明示的または暗黙的な）組み込みのメカニズムが含まれていません。したがって、SAのアイデンティティを備えたアドレスに変更が重すぎる計算と便利なモビリティのためにあまりにも大きな遅延を意味IKEの再交渉を必要とし、この文書全体を想定しています。
The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555] provides better mobility for IPsec. This would allow the external Mobile IPv4 layer described in this specification to be removed. However, deploying MOBIKE requires changes to VPN devices, and is thus out of scope of this specification.
IKEv2のモビリティとマルチホーミングプロトコル（MOBIKE）[RFC4555]はIPsecのためのより良いモビリティを提供します。これは、本明細書に記載の外部モバイルIPv4層を除去することを可能にします。しかし、MOBIKEを展開するVPN装置への変更を必要とし、この仕様の範囲外のことです。
Enterprise users will access both the internal and external networks using different networking technologies. In some networks, the MN will use FAs and in others it will anchor at the HA using co-located mode. The following figure describes an example network topology illustrating the relationship between the internal and external networks, and the possible locations of the mobile node (i.e., (MN)).
エンタープライズ・ユーザーは、異なるネットワーク技術を使用して、内部ネットワークと外部ネットワークの両方にアクセスします。一部のネットワークでは、MNは、Fasを使用し、他の人にそれが同じ場所に配置モードを使用したHAで固定します。次の図は、内部と外部ネットワークとの間の関係を示す一例のネットワークトポロジーを記述し、モバイルノードの可能な位置（すなわち、（MN））。
(MN) {fvc} {home} (MN) [i-HA]
! \ /
.--+---. .-+---+-.
( ) ( )
`--+---' [VPN] `--+----'
\ ! !
[R/FA] [x-HA] .--+--. [R]
\ / ( DMZ ) !
.-+-------+--. `--+--' .-----+------.
( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net )
( ) ( )
`--+---------' `---+---+----'
/ / \
[DHCP] [R] [DHCP] [R] [R] [i-FA]
\ / \ / \ /
.+--+---. .-+-+--. .--+--+-.
( ) ( ) ( )
`---+---' `--+---' `---+---'
! ! !
(MN) {cvc} (MN) {c} (MN) {f}
Figure 1: Basic topology, possible MN locations, and access modes
図1：基本的なトポロジー、可能なMNの位置、およびアクセスモード
In every possible location described in the figure, the mobile node can establish a connection to the corresponding HA(s) by using a suitable "access mode". An access mode is here defined to consist of:
図に記載のすべての可能な位置では、モバイルノードは、適切な「アクセスモード」を用いて、対応するHA（S）への接続を確立することができます。アクセスモードは、ここから構成されると定義されています。
1. a composition of the mobile node networking stack (i-MIP or x-MIP/VPN/i-MIP); and
1.モバイルノードネットワークスタックの組成物（I-MIPまたはX-MIP / VPN / I-MIP）。そして
2. registration mode(s) of i-MIP and x-MIP (if used); i.e., co-located care-of address or foreign agent care-of address.
2.登録モード（S）I-MIPとX-MIP（使用する場合）。すなわち、気付アドレス又はフォーリンエージェント気付アドレスを同じ場所に配置。
Each possible access mode is encoded as "xyz", where:
可能な各アクセスモードは「XYZ」、としてエンコードされます。
o "x" indicates whether the x-MIP layer is used, and if used, the mode ("f" indicates FA-CoA, "c" indicates co-CoA, absence indicates not used);
O、X-MIP層が使用されているか否かを示す "×" と使用される場合、モード（ "F" はFA-CoAを示し、 "c" は、不在を使用しない示しCO-CoAが示します）。
o "y" indicates whether the VPN layer is used ("v" indicates VPN used, absence indicates not used); and
O「Y」はVPN層が使用されているかどうかを示す（「V」のVPNが使用示し、不在は使用されない示します）。そして
o "z" indicates mode of i-MIP layer ("f" indicates FA-CoA, "c" indicates co-CoA).
O "Z" は（ "F" は、FA-CoAを示し、 "C" は、CO-CoAを示す）I-MIP層のモードを示します。
This results in four access modes:
これは、4つのアクセスモードでの結果：
c: i-MIP with co-CoA
f: i-MIP with FA-CoA
cvc: x-MIP with co-CoA, VPN-TIA as i-MIP co-CoA
fvc: x-MIP with FA-CoA, VPN-TIA as i-MIP co-CoA
This notation is more useful when optimizations to protocol layers are considered. The notation is preserved here so that work on the optimizations can refer to a common notation.
プロトコル層への最適化を考慮すると、この表記法は、より便利です。最適化の作業は、一般的な表記法を参照することができるように表記法をここに保存されています。
The internal network is typically a multi-subnetted network using private addressing [privaddr]. Subnets may contain internal home agent(s), DHCP server(s), and/or foreign agent(s). Current IEEE 802.11 wireless LANs are typically deployed in the external network or the DMZ because of security concerns.
内部ネットワークは、典型的には、[privaddr]アドレッシングプライベート用いたマルチサブネットのネットワークです。サブネットは内部ホームエージェント（s）は、DHCPサーバ（複数可）、および/または外部エージェント（複数可）を含んでいてもよいです。現在のIEEE 802.11無線LANは、通常、セキュリティ保護のため、外部ネットワークまたはDMZ内に展開されています。
The figure leaves out a few details worth noticing:
図は、注目に値するいくつかの詳細を抜けて：
o There may be multiple NAT devices anywhere in the diagram.
Oのどこかの図に、複数のNATデバイスがあるかもしれません。
* When the MN is outside, the NAT devices may be placed between the MN and the x-HA or the x-HA and the VPN.
MNが外部である場合*、NATデバイスは、MNと、X-HAまたはX-HAとVPNとの間に配置されてもよいです。
* There may also be NAT(s) between the VPN and the i-HA, or a NAT integrated into the VPN. In essence, any router in the figure may be considered to represent zero or more routers, each possibly performing NAT and/or ingress filtering.
*また、VPNおよびI-HA、またはVPNに統合NAT間のNAT（複数可）があるかもしれません。本質的には、図中の任意のルータは、ゼロ以上のルータ、各おそらく行うNAT及び/又はイングレスフィルタリングを表すと考えることができます。
* When the MN is inside, there may be NAT devices between the MN and the i-HA.
* MNが内部にある場合には、MNとI-HAとの間にNATデバイスがあるかもしれません。
o Site-to-site VPN tunnels are not shown. Although mostly transparent, IPsec endpoints may perform ingress filtering as part of enforcing their policy.
OサイトツーサイトVPNトンネルは表示されません。ほとんど透明が、IPsecのエンドポイントは、そのポリシーを適用の一部としてイングレスフィルタリングを実行することができます。
o The figure represents a topology where each functional entity is illustrated as a separate device. However, it is possible that several network functions are co-located in a single device. In fact, all three server components (x-HA, VPN, and i-HA) may be co-located in a single physical device.
Oの図は、各機能エンティティは、別個のデバイスとして示されているトポロジーを表します。しかし、いくつかのネットワーク機能が単一デバイス内に一緒に配置されることが可能です。実際には、すべての3つのサーバコンポーネント（X-HA、VPN、およびI-HA）は、単一の物理デバイス内に一緒に配置されてもよいです。
The following issues are also important when considering enterprise mobile users:
企業のモバイルユーザーを検討する際、以下の問題も重要です。
o Some firewalls are configured to block ICMP messages and/or fragments. Such firewalls (routers) cannot be detected reliably.
O一部のファイアウォールは、ICMPメッセージおよび/またはフラグメントをブロックするように設定されています。そのようなファイアウォール（ルータ）を確実に検出することができません。
o Some networks contain transparent application proxies, especially for HTTP. Like firewalls, such proxies cannot be detected reliably in general. IPsec and Mobile IPv4 are incompatible with such networks.
Oネットワークによっては、特にHTTPのために、透明アプリケーションプロキシが含まれています。ファイアウォールのように、そのようなプロキシは、一般的に確実に検出することはできません。 IPsecとモバイルIPv4は、ネットワークと互換性がありません。
Whenever a mobile node obtains either a co-CoA or an FA-CoA, the following conceptual steps take place:
モバイルノードが共同のCoAまたはFA-CoAのいずれかを取得するたびに、以下の概念の手順が行われます。
o The mobile node detects whether the subnet where the care-of address was obtained belongs to the internal or the external network using the method described in Section 3 (or a vendor-specific mechanism fulfilling the requirements described).
モバイルノードoを気付アドレスを取得したサブネットが第3（又は説明した要件を満たすベンダー固有のメカニズム）に記載された方法を用いて、内部または外部のネットワークに属しているか否かを検出します。
o The mobile node performs necessary registrations and other connection setup signaling for the protocol layers (in the following order):
Oモバイルノードは、（次の順序で）プロトコル層のために必要な登録および他の接続セットアップシグナリングを実行します。
* x-MIP (if used);
* X-MIP（使用する場合）。
* VPN (if used); and
* VPN（使用する場合）。そして
* i-MIP.
* I-MIP。
Note that these two tasks are intertwined to some extent: detection of the internal network results in a successful registration to the i-HA using the proposed network detection algorithm. An improved network detection mechanism not based on Mobile IPv4 registration messages might not have this side effect.
内部ネットワークの結果の検出をI-HAへの登録が成功で提案されているネットワークの検出アルゴリズムを使用してこれらの2つのタスクはある程度絡み合っていることに注意してください。モバイルIPv4登録メッセージに基づいていない改良されたネットワークの検出機構は、この副作用を持っていないかもしれません。
The following subsections describe the different access modes and the requirements for registration and connection setup phase.
以下のサブセクションでは、異なるアクセス・モードと登録や接続設定フェーズのための要件について説明します。
This access mode is standard Mobile IPv4 [RFC3344] with a co-located address, except that:
このアクセスモードは点を除いて、同じ場所に配置アドレスを持つ標準モバイルIPv4 [RFC3344]です。
o the mobile node MUST detect that it is in the internal network; and
Oモバイルノードは、内部ネットワークにあることを検出しなければなりません。そして
o the mobile node MUST re-register periodically (with a configurable interval) to ensure it is still inside the internal network (see Section 4).
Oモバイルノードが内部ネットワーク内に依然としてあることを確認する（設定間隔で）定期的に再登録しなければならない（セクション4を参照）。
This access mode is standard Mobile IPv4 [RFC3344] with a foreign agent care-of address, except that
このアクセス・モードは、ことを除いて、外国人のエージェントの気付アドレスを持つ標準のモバイルIPv4 [RFC3344]であります
o the mobile node MUST detect that it is in the internal network; and
Oモバイルノードは、内部ネットワークにあることを検出しなければなりません。そして
o the mobile node MUST re-register periodically (with a configurable interval) to ensure it is still inside the internal network (see Section 4).
Oモバイルノードが内部ネットワーク内に依然としてあることを確認する（設定間隔で）定期的に再登録しなければならない（セクション4を参照）。
Steps:
ステップ：
o The mobile node obtains a care-of address.
Oモバイルノードが気付アドレスを取得します。
o The mobile node detects it is not inside and registers with the x-HA, where
Oモバイルノードは、それが内部ない検出し、X-HA、に登録します
* T-bit MAY be set (reverse tunneling), which minimizes the probability of firewall-related connectivity problems
* Tビットは、ファイアウォール関連の接続の問題の可能性を最小にする、（トンネリングを逆）に設定されるかもしれません
o If the mobile node does not have an existing IPsec security association, it uses IKE to set up an IPsec security association with the VPN gateway, using the x-HoA as the IP address for IKE/ IPsec communication. How the VPN-TIA is assigned is outside the scope of this document.
移動ノードが既存のIPsecセキュリティアソシエーションを有していない場合、Oは、IKE / IPsec通信のためのIPアドレスとして、XのHoAを使用して、VPNゲートウェイとのIPsecセキュリティアソシエーションを設定するためにIKEを使用します。どのようにVPN-TIAが割り当てられ、この文書の範囲外です。
o The mobile node sends a MIPv4 Registration Request (RRQ) to the i-HA, registering the VPN-TIA as a co-located care-of address, where
モバイルノードは、ここで、同一位置気付アドレスとしてVPN-TIA登録、I-HAへのMIPv4登録要求（RRQ）を送信oを
* T-bit SHOULD be set (reverse tunneling) (see discussion below)
* Tビットが設定されるべきである（逆トンネリング）（以下の議論を参照されたいです）
Reverse tunneling in the inner Mobile IPv4 layer is often required because of IPsec security policy limitations. IPsec selectors define allowed IP addresses for packets sent inside the IPsec tunnel. Typical IPsec remote VPN selectors restrict the client address to be VPN-TIA (remote address is often unrestricted). If reverse tunneling is not used, the source address of a packet sent by the MN will be the MN's home address (registered with i-HA), which is different from the VPN-TIA, thus violating IPsec security policy. Consequently, the packet will be dropped, resulting in a connection black hole.
内側のモバイルIPv4層におけるリバーストンネリングはしばしばIPsecのセキュリティポリシー制限の必要です。 IPsecのセレクタは、IPsecトンネル内で送信されたパケットのために許可されたIPアドレスを定義します。典型的なのIPsecリモートVPNセレクタVPN-TIA（リモートアドレスは、多くの場合、無制限である）であることをクライアントアドレスを制限します。リバーストンネリングを使用しない場合は、MNによって送信されたパケットの送信元アドレスは、このようにIPsecセキュリティポリシーに違反し、VPN-TIAは異なっている（I-HAに登録）MNのホームアドレスになります。したがって、パケットは、接続ブラックホールで、その結果、削除されます。
Some types of IPsec-based VPNs, in particular L2TP/IPsec VPNs (PPP-over-L2TP-over-IPsec), do not have this limitation and can use triangular routing.
IPsecベースのVPNの種類によっては、特に、L2TP / IPsecのVPNの（PPPオーバL2TPオーバーのIPsec）、この制限を持っていないと三角ルーティングを使用することができます。
Note that although the MN can use triangular routing, i.e., skip the inner MIPv4 layer, it MUST NOT skip the VPN layer for security reasons.
MN、すなわち、内側のMIPv4層をスキップし、三角ルーティングを使用できるが、それはセキュリティ上の理由のためにVPN層をスキップしない必要があります。
Steps:
ステップ：
o The mobile node obtains a foreign agent advertisement from the local network.
Oモバイルノードは、ローカルネットワークからの外国人のエージェント広告を取得します。
o The mobile node detects it is outside and registers with the x-HA, where
Oモバイルノードは、それが外部で検出し、X-HA、に登録します
* T-bit MAY be set (reverse tunneling), which minimizes the probability of firewall-related connectivity problems
* Tビットは、ファイアウォール関連の接続の問題の可能性を最小にする、（トンネリングを逆）に設定されるかもしれません
o If necessary, the mobile node uses IKE to set up an IPsec connection with the VPN gateway, using the x-HoA as the IP address for IKE/IPsec communication. How the VPN-TIA is assigned is outside the scope of this document.
必要に応じてO、モバイルノードがIKE / IPsec通信のためのIPアドレスとして、XのHoAを使用して、VPNゲートウェイとのIPsec接続をセットアップするためにIKEを使用します。どのようにVPN-TIAが割り当てられ、この文書の範囲外です。
o The mobile node sends a MIPv4 RRQ to the i-HA, registering the VPN-TIA as a co-located care-of address, where
モバイルノードOなどのVPN-TIAを登録、I-HAへのMIPv4 RRQを送り、同じ場所に配置、どこ気付アドレス
* T-bit SHOULD be set (reverse tunneling) (see discussion in Section 2.3)
* Tビットが設定されるべきである（逆トンネリング）（2.3節での議論を参照されたいです）
Note that although the MN can use triangular routing, i.e., skip the inner MIPv4 layer, it MUST NOT skip the VPN layer for security reasons.
MN、すなわち、内側のMIPv4層をスキップし、三角ルーティングを使用できるが、それはセキュリティ上の理由のためにVPN層をスキップしない必要があります。
NAT devices may affect each layer independently. Mobile IPv4 NAT traversal [mipnat] SHOULD be supported for x-MIP and i-MIP layers, while IPsec NAT traversal [RFC3947][RFC3948] SHOULD be supported for the VPN layer.
NATデバイスは、独立してそれぞれの層に影響を与える可能性があります。 IPsecのNATトラバーサル[RFC3947]、[RFC3948]はVPN層のためにサポートされるべきであるモバイルIPv4 NATトラバーサルは、[mipnat]、X-MIPおよびI-MIP層のためにサポートされるべきです。
Note that NAT traversal for the internal MIPv4 layer may be necessary even when there is no separate NAT device between the VPN gateway and the internal network. Some VPN implementations NAT VPN tunnel inner addresses before routing traffic to the intranet. Sometimes this is done to make a deployment easier, but in some cases this approach makes VPN client implementation easier. Mobile IPv4 NAT traversal is required to establish a MIPv4 session in this case.
VPNゲートウェイと内部ネットワークとの間に別のNATデバイスが存在しない場合でも内部のMIPv4層用NATトラバーサルが必要であり得ることに留意されたいです。いくつかのVPNの実装NAT VPNトンネル内部アドレスイントラネットへのトラフィックをルーティングする前に。時には、これは、展開を容易にするために行われているが、いくつかのケースでは、このアプローチは、より簡単にVPNクライアントの実装を行います。モバイルIPv4 NATトラバーサルは、このケースでのMIPv4セッションを確立するために必要です。
Secure detection of the internal network is critical to prevent plaintext traffic from being sent over an untrusted network. In other words, the overall security (confidentiality and integrity of user data) relies on the security of the internal network detection mechanism in addition to IPsec. For this reason, security requirements are described in this section.
内部ネットワークのセキュリティで保護され、検出は信頼できないネットワークを介して送信される平文のトラフィックを防ぐために重要です。換言すれば、全体的なセキュリティ（ユーザデータの機密性と完全性）はIPsecのに加えて、内部ネットワークの検出機構のセキュリティに依存しています。このため、セキュリティ要件は、このセクションで説明されています。
In addition to detecting entry into the internal network, the mobile node must also detect when it has left the internal network. Entry into the internal network is easier security-wise: the mobile node can ensure that it is inside the internal network before sending any plaintext traffic. Exit from the internal network is more difficult to detect, and the MN may accidentally leak plaintext packets if the event is not detected in time.
それは内部ネットワークを去ったときに、内部ネットワークへの侵入を検出することに加えて、モバイルノードは、検出しなければなりません。内部ネットワークへの参入が容易にセキュリティが賢明です：モバイルノードは、それがどんな平文トラフィックを送信する前に、内部ネットワーク内にあることを確認することができます。内部ネットワークからの出口を検出することがより困難であり、イベントが時間内に検出されない場合MNが誤って平文パケットをリークすることがあります。
Several events can cause the mobile node to leave the internal network, including:
いくつかのイベントには、内部ネットワークを残すために、モバイルノードを引き起こす可能性があります：
o a routing change upstream;
上流のルーティング変更O。
o a reassociation of 802.11 on layer 2 that the mobile node software does not detect;
O層2上に802.11の再会合モバイルノードのソフトウェアが検出されないこと。
o a physical cable disconnect and reconnect that the mobile node software does not detect.
O物理的なケーブルの切断とは、モバイルノードのソフトウェアが検出されないことを再接続します。
Whether the mobile node can detect such changes in the current connection reliably depends on the implementation and the networking technology. For instance, some mobile nodes may be implemented as pure layer three entities. Even if the mobile node software has access to layer 2 information, such information is not trustworthy security-wise, and depends on the network interface driver.
モバイルノードが現在の接続で、このような変化を検出することができるかどうか、確実な実装とネットワーク技術に依存します。例えば、いくつかのモバイルノードは、純粋なレイヤ3つのエンティティとして実装されてもよいです。モバイルノードのソフトウェアは、レイヤ2の情報へのアクセスを有する場合であっても、そのような情報は、信頼できるセキュリティ単位ではなく、ネットワーク・インターフェース・ドライバに依存します。
If the mobile node does not detect these events properly, it may leak plaintext traffic into an untrusted network. A number of approaches can be used to detect exit from the internal network, ranging from frequent re-registration to the use of layer two information.
モバイルノードが適切にこれらのイベントを検出しない場合は、それが信頼できないネットワークに平文トラフィックを漏らすことがあります。多くのアプローチは、レイヤ2情報の使用に頻繁に再登録に至るまで、内部ネットワークからの退出を検出するために使用することができます。
A mobile node MUST implement a detection mechanism fulfilling the requirements described in Section 3.2; this ensures that basic security requirements are fulfilled. The basic algorithm described in Section 3.3 is one way to do that, but alternative methods may be used instead or in conjunction. The assumptions that the requirements and the proposed mechanism rely upon are described in Section 3.1.
モバイルノードは、セクション3.2で説明した要件を満たす検出メカニズムを実装しなければなりません。これは基本的なセキュリティ要件が満たされていることを保証します。セクション3.3で説明した基本的なアルゴリズムは、それを行うための一つの方法であるが、別の方法が代わりに又は組み合わせて使用することができます。要件と提案されたメカニズムが依存仮定は、セクション3.1で説明されています。
The enterprise firewall MUST be configured to block traffic originating from external networks going to the i-HA. In other words, the mobile node MUST NOT be able to perform a successful Registration Request/Registration Reply (RRQ/RRP) exchange (without using IPsec) unless it is connected to the trusted internal network; the mobile node can then stop using IPsec without compromising data confidentiality.
企業のファイアウォールがi-HAに行く外部のネットワークから発信されたトラフィックをブロックするように設定する必要があります。換言すれば、移動ノードは、それが信頼できる内部ネットワークに接続されていない場合（IPsecを使用せずに）成功した登録要求/登録応答（RRQ / RRP）交換を実行することができてはいけません。モバイルノードは、データの機密性を損なうことなく、IPsecを使用して停止することができます。
If this assumption does not hold, data confidentiality is compromised in a potentially silent and thus dangerous manner. To minimize the impact of this scenario, the i-HA is also required to check the source address of any RRQ to determine whether it comes from a trusted (internal network) address. The i-HA needs to indicate to the MN that it supports the checking of trusted source addresses by including a Trusted Networks Configured extension in its registration reply. This new extension, which needs to be implemented by both i-HA and the MN, is described in Section 3.4.
この仮定が成立しない場合は、データの機密性は、潜在的にサイレントので、危険な方法で損なわれています。このシナリオの影響を最小限に抑えるために、I-HAはまた、それが信頼できる（内部ネットワーク）アドレスから来ているかどうかを決定するために任意RRQの送信元アドレスをチェックする必要があります。 I-HAは、その登録応答で拡張子を設定した信頼できるネットワークを含むことにより、信頼できるソースアドレスのチェックをサポートしているMNに指示する必要があります。 I-HAとMNの両方で実装する必要があります。この新しい拡張機能は、3.4節に記述されています。
The firewall MAY be configured to block registration traffic to the x-HA originating from within the internal network, which makes the network detection algorithm simpler and more robust. However, as the registration request is basically UDP traffic, an ordinary firewall (even a stateful one) would typically allow the registration request to be sent and a registration reply to be received through the firewall.
ファイアウォールは、ネットワーク検出アルゴリズムは、よりシンプルで堅牢になり、内部ネットワーク内からのx-HA発信元に登録トラフィックをブロックするように構成することができます。登録要求は、基本的にUDPトラフィックのようしかし、通常のファイアウォール（さえステートフル1）は、典型的には、送信される登録要求および登録応答がファイアウォールを介して受信されることを可能にします。
Any mechanism used to detect the internal network MUST fulfill the requirements described in this section. An example of a network detection mechanism fulfilling these requirements is given in Section 3.3.
内部ネットワークを検出するために使用される任意の機構は、このセクションで説明した要件を満たさなければなりません。これらの要件を満たすネットワーク検出メカニズムの例はセクション3.3に記載されています。
The mobile node implementation MUST track each network interface separately. Successful registration with the i-HA through interface X does not imply anything about the status of interface Y.
モバイルノードの実装では、個別のネットワークインタフェースを追跡しなければなりません。インタフェースXからi-HAで成功登録はインタフェースYの状況について何を意味するものではありません。
When the mobile node detects that its connection status on a certain network interface changes, the mobile node MUST: o immediately stop relaying user data packets;
モバイルノードは、特定のネットワークインターフェースの変更上のその接続状態を検出すると、モバイルノードがなければなりません：O直ちにユーザ・データ・パケットを中継停止します。
o detect whether this interface is connected to the internal or the external network; and
Oこのインタフェースは、内部または外部のネットワークに接続されているか否かを検出します。そして
o resume data traffic only after the internal network detection and necessary registrations and VPN tunnel establishment have been completed.
O内部ネットワークの検出と、必要な登録やVPNトンネルの確立が完了した後にのみデータトラフィックを再開する。
The mechanisms used to detect a connection status change depends on the mobile node implementation, the networking technology, and the access mode.
接続状態の変化を検出するために使用されるメカニズムは、モバイルノードの実装、ネットワーク技術、およびアクセスモードに依存します。
The mobile node MUST NOT infer that an interface is connected to the internal network unless a successful registration has been completed through that particular interface to the i-HA, the i-HA registration reply contained a Trusted Networks Configured extension (Section 3.4), and the connection status of the interface has not changed since.
モバイルノードが登録成功は、I-HAへの特定のインタフェースを介して完了されていない限り、インタフェースは、内部ネットワークに接続されていることを推測してはいけません、I-HA登録応答は、信頼できるネットワークコンフィグレーション拡張（セクション3.4）を含有し、そしてインタフェースの接続状態が以来変更されていません。
Some leak of plaintext packets to a (potentially) untrusted network cannot always be completely prevented; this depends heavily on the client implementation. In some cases, the client cannot detect such a change, e.g., if upstream routing is changed.
（潜在的に）信頼できないネットワークに平文パケットの一部漏れは、常に完全に防止することができません。これは、クライアントの実装に大きく依存します。上流のルーティングが変更された場合、いくつかのケースでは、クライアントは、例えば、そのような変化を検出することができません。
More frequent re-registrations when the MN is inside is a simple way to ensure that the MN is still inside. The MN SHOULD start re-registration every (T_MONITOR - N) seconds when inside, where N is a grace period that ensures that re-registration is completed before T_MONITOR seconds are up. To bound the maximum amount of time that a plaintext leak may persist, the mobile node must fulfill the following security requirements when inside:
MNは内部でより頻繁な再登録はMNが内部に残っていることを保証するための簡単な方法です。 MNは、再登録を開始すべきであるすべての（T_MONITOR - N）秒ときNはT_MONITOR秒がアップする前に再登録が完了していることを保証猶予期間である内部、。平文漏れが持続できる時間の最大量を結合するタイミング内部、モバイルノードは、以下のセキュリティ要件を満たさなければなりません。
o The mobile node MUST NOT send or receive a user data packet if more than T_MONITOR seconds have elapsed since the last successful (re-)registration with the i-HA.
Oモバイルノードが送信または以上T_MONITOR秒I-HAと最後に成功した（再）登録から経過した場合は、ユーザデータパケットを受信することもできません。
o If more than T_MONITOR seconds have elapsed, data packets MUST be either dropped or queued. If the packets are queued, the queues MUST NOT be processed until the re-registration has been successfully completed without a connection status change.
T_MONITOR秒以上が経過している場合は、O、データパケットは、廃棄またはキューに入れられなければなりません。パケットがキューイングされている場合は再登録が正常に接続状態を変更せずに完了するまで、キューが処理されてはなりません。
o The T_MONITOR parameter MUST be configurable, and have the default value of 60 seconds. This default is a trade-off between traffic overhead and a reasonable bound to exposure.
O T_MONITORパラメータが設定可能で、60秒のデフォルト値を持たなければなりません。このデフォルトでは、トラフィックのオーバーヘッドと暴露に合理的なバウンドとのトレードオフです。
This approach is reasonable for a wide range of mobile nodes (e.g., laptops), but has unnecessary overhead when the mobile node is idle (not sending or receiving packets). If re-registration does not complete before T_MONITOR seconds are up, data packets must be queued or dropped as specified above. Note that re-registration packets MUST be sent even if bidirectional user data traffic is being relayed: data packets are no substitute for an authenticated re-registration.
このアプローチは、モバイルノード（例えば、ラップトップ）の広い範囲のために妥当であるが、モバイルノードが（パケットを送信または受信していない）アイドル状態のときに不要なオーバーヘッドを有します。 T_MONITOR秒がアップする前に再登録が完了しない場合、データパケットはキューに入れなければなりませんか、上記指定としてドロップ。双方向のユーザデータトラフィックが中継されている場合でも、その再登録パケットを送信する必要があります：データパケットが認証された再登録のための代替ではありません。
To minimize traffic overhead when the mobile node is idle, re-registrations can be stopped when no traffic is being sent or received. If the mobile node subsequently receives or needs to send a packet, the packet must be dropped or queued (as specified above) until a re-registration with the i-HA has been successfully completed. Although this approach adds packet processing complexity, it may be appropriate for small, battery-powered devices, which may be idle much of the time. (Note that ordinary re-registration before the mobility binding lifetime is exhausted should still be done to keep the MN reachable.)
トラフィックが送信されないまたは受信されているとき、移動ノードがアイドル状態のとき、トラフィックのオーバーヘッドを最小限に抑えるために、再登録を停止することができます。モバイルノードは、その後に受け取るか、またはパケットを送信する必要がある場合（上記のよう）は、i-HAによる再登録が正常に完了するまで、パケットは廃棄されるか、またはキューに登録する必要があります。このアプローチは、パケット処理の複雑さを追加しているが、それは多くの時間アイドル状態であってもよい小さな、バッテリ駆動デバイスに適切であり得ます。 （モビリティバインディング寿命が排出される前に、通常の再登録を注意することは、まだ到達可能なMNを維持するために行われる必要があります。）
T_MONITOR is required to be configurable so that an administrator can determine the required security level for the particular deployment. Configuring T_MONITOR in the order of a few seconds is not practical; alternative mechanisms need to be considered if such confidence is required.
T_MONITORは、管理者が特定の展開のために必要なセキュリティレベルを決定することができるように構成する必要があります。数秒のオーダーでT_MONITORを設定することは現実的ではありません。代替メカニズムは、そのような信頼が必要な場合は考慮する必要があります。
The re-registration mechanism is a worst-case fallback mechanism. If additional information (such as layer two triggers) is available to the mobile node, the mobile node SHOULD use the triggers to detect MN movement and restart the detection process to minimize exposure.
再登録メカニズムは、最悪の場合のフォールバックメカニズムです。 （このような層の2つのトリガーなど）関連情報は、移動ノードに利用可能である場合、移動ノードはMNの動きを検出して露出を最小限にするために、検出プロセスを再起動するためにトリガーを使用すべきです。
Note that re-registration is required by Mobile IPv4 by default (except for the atypical case of an infinite binding lifetime); however, the re-registration interval may be much larger when using an ordinary Mobile IPv4 client. A shorter re-registration interval is usually not an issue, because the internal network is typically a fast, wired network, and the shortened re-registration interval applies only when the mobile node is inside the internal network. When outside, the ordinary Mobile IPv4 re-registration process (based on binding lifetime) is used.
なお、再登録は、（無限結合ライフタイムの異型の場合を除く）、デフォルトでモバイルIPv4によって必要とされます。通常のモバイルIPv4クライアントを使用する場合しかし、再登録の間隔ははるかに大きくてもよいです。内部ネットワークは、典型的には、高速有線ネットワークであり、モバイルノードは、内部ネットワーク内にある場合にのみ、短縮再登録間隔が適用されるため、より短い再登録間隔は、通常は問題ではありません。場合外部、（結合寿命に基づく）通常のモバイルIPv4再登録プロセスが使用されます。
When the MN detects that it has changed its point of network attachment on a certain interface, it issues two simultaneous registration requests, one to the i-HA and another to the x-HA. These registration requests are periodically retransmitted if reply messages are not received.
MNは、それが特定のインターフェイス上のネットワーク接続ポイントを変更したことを検出すると、それは2つの同時登録要求、X-HAとI-HAへの1つ、別のを発行します。応答メッセージが受信されない場合は、これらの登録要求は、定期的に再送信されます。
Registration replies are processed as follows:
次のように登録応答が処理されます。
o If a response from the x-HA is received, the MN stops retransmitting its registration request to the x-HA and tentatively determines it is outside. However, the MN MUST keep on retransmitting its registration to the i-HA for a period of time. The MN MAY postpone the IPsec connection setup for some period of time while it waits for a (possible) response from the i-HA.
X-HAからの応答が受信された場合、O、MNは、x-HAへの登録要求を再送信を停止し、仮にそれが外部であるかを判断します。しかし、MNは、しばらくの間、I-HAへの登録を再送し続けなければなりません。それは、I-HAから（可能性）応答を待つ間、MNは、しばらくの間のIPsec接続設定を延期するかもしれません。
o If a response from the i-HA is received and the response contains the Trusted Networks Configured extension (Section 3.4), the MN SHOULD determine that it is inside. In any case, the MN MUST stop retransmitting its registration requests to both i-HA and x-HA.
I-HAからの応答が受信され、応答が信頼できるネットワーク設定さエクステンション（セクション3.4）が含まれている場合、O、MNは、それが内部であることを決定すべきです。いずれにせよ、MNがi-HAおよびX-HAの両方への登録要求を再送信するのを止めなければなりません。
o When successfully registered with the i-HA directly, MN SHOULD de-register with the x-HA.
成功した直接I-HAに登録すると、O、MNは、x-HAに登録解除すべきです。
If the MN ends up detecting that it is inside, it MUST re-register periodically (regardless of binding lifetime); see Section 3.2.4. If the re-registration fails, the MN MUST stop sending and receiving plaintext traffic, and MUST restart the detection algorithm.
MNは、それが内部であることを検出してしまう場合には（かかわらず、結合寿命の）定期的に再登録しなければなりません。 3.2.4項を参照してください。再登録が失敗した場合、MNは、平文トラフィックの送信と受信を停止しなければならない、と検出アルゴリズムを再起動する必要があります。
Plaintext re-registration messages are always addressed either to the x-HA or the i-HA, not to both. This is because the MN knows, after initial registration, whether it is inside or outside. (However, when the mobile node is outside, it re-registers independently with the x-HA using plaintext, and with the i-HA through the VPN tunnel.)
平文再登録メッセージは、常にではないの両方に、X-HAまたはI-HAのいずれかに対処しています。 MNは、それが内部または外部であるかどうか、初期登録後に、知っているからです。 （モバイルノードが外部である場合しかし、それは、VPNトンネルを介してX-HA平文を用いた、およびI-HAと独立してレジスタを再。）
Postponing the IPsec connection setup could prevent aborted IKE sessions. Aborting IKE sessions may be a problem in some cases because IKE does not provide a reliable, standardized, and mandatory-to-implement mechanism for terminating a session cleanly.
中止されたIKEセッションを防ぐことができるのIPsec接続設定を延期。 IKEがきれいにセッションを終了するため、信頼性の高い標準化、および実装に必須のメカニズムを提供していないため、IKEセッションを中止するいくつかのケースで問題になることがあります。
If the x-HA is not reachable from inside (i.e., the firewall configuration is known), a detection period of zero is preferred, as it minimizes connection setup overhead and causes no timing problems. Should the assumption have been invalid and a response from the i-HA received after a response from the x-HA, the MN SHOULD re-register with the i-HA directly.
X-HAは、内側から到達できない場合、接続セットアップのオーバーヘッドを最小化しないタイミングの問題が発生しないように、ゼロの検出期間が、好適である（すなわち、ファイアウォール構成が知られています）。仮定が無効となっていると、I-HAからの応答は、x-HAからの応答の後に受信する必要があり、MNは直接I-HAに再登録する必要があります。
This extension is a skippable extension. An i-HA sending the extension must fulfill the requirements described in Section 4.3, while an MN processing the extension must fulfill the requirements described in Section 4.1. The format of the extension is described below. It adheres to the short extension format described in [RFC3344]:
この拡張はスキップ可能な拡張機能です。拡張子を処理MNは、4.1節で説明した要件を満たす必要がありながら、I-HAエクステンションを送信するには、4.3節で説明した要件を満たす必要があります。拡張のフォーマットは以下の通りです。これは[RFC3344]で説明短い拡張フォーマットに準拠します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 149
タイプ149
Length 2
長さ2
Sub-Type 0
サブタイプ0
Reserved Set to 0 when sending, ignored when receiving
受信時に無視され、0に設定された予約を送信するとき
When the MN uses a parallel detection algorithm and is using an FA, the MN sends two registration requests through the same FA with the same Media Acces Control (MAC) address (or equivalent) and possibly even the same home address. Although this is not in conflict with existing specifications, it is an unusual scenario; hence some FA implementations may not work properly in such a situation. However, testing against deployed foreign agents seems to indicate that a majority of available foreign agents handle this situation.
MNは、並列検出アルゴリズムを使用し、FAを使用している場合は、MNは、同じメディアアクセスも制御（MAC）アドレス（または同等）と可能性も、同じホームアドレスと同じFAを介して2つの登録要求を送信します。これは、既存の仕様と矛盾しませんが、それは珍しいシナリオです。したがって、いくつかのFAの実装は、このような状況では正常に動作しない場合があります。しかし、展開外部エージェントに対するテストが可能な外国人のエージェントの大半は、この状況を扱うことを示していると思われます。
When the x-HA and i-HA addresses are the same, the scenario is even more difficult for the FA, and it is almost certain that existing FAs do not deal with the situation correctly. Therefore, it is required that x-HA and i-HA addresses MUST be different.
X-HAとI-HAアドレスが同一である場合には、シナリオはさらに困難FA用であり、既存のFAが正しく状況に対処していないことはほぼ確実です。したがって、X-HAとI-HAアドレスが異なっていてもしなければならないことが要求されます。
Regardless, if the MN detects that i-HA and x-HA have the same address, it MUST assume that it is in the external network and bypass network detection to avoid confusing the FA. Because the HA addresses are used at different layers, achieving connectivity is possible without address confusion.
MNは、I-HAおよびX-HAが同じアドレスを持っていることを検出した場合にかかわらず、それがFAを混乱を避けるために、外部ネットワークとバイパスネットワーク検出であると仮定しなければなりません。 HAアドレスが異なる層で使用されているので、接続性を実現することは、アドレスの混乱なしに可能です。
The mobile node MAY use the following hints to determine that it is inside, but MUST verify reachability of the i-HA anyway: o a domain name in a DHCPDISCOVER / DHCPOFFER message
モバイルノードは、それが内側にあることを決定するには、次のヒントを使用することができるが、とにかく-HAの到達可能性を検証しなければならない：ドメイン名O DHCPDISCOVER / DHCPOFFERメッセージで
o an NAI in a foreign agent advertisement
外国人のエージェント広告におけるNAI O
o a list of default gateway MAC addresses that are known to reside in the internal network (i.e., configured as such, or have been previously verified to be inside)
O内部ネットワーク内に存在することが知られているデフォルトゲートウェイのMACアドレスのリスト（すなわち、このように構成された、または以前に内側であることが確認されています）
For instance, if the MN has reason to believe it is inside, it MAY postpone sending a registration request to the x-HA for some time. Similarly, if the MN has reason to believe it is outside, it may start IPsec connection setup immediately after receiving a registration reply from the x-HA. However, should the MN receive a registration reply from the i-HA after IPsec connection setup has been started, the MN SHOULD still switch to using the i-HA directly.
MNは、それが内部であると信じる理由がある場合たとえば、それはいくつかの時間のためのx-HAに登録要求を送信延期するかもしれません。 MNは、それが外であると信じる理由がある場合同様に、それは、x-HAからの登録応答を受信した直後にIPsec接続のセットアップを開始することができます。しかし、IPsec接続のセットアップが開始された後、MNは、I-HAからの登録応答を受信する必要があり、MNは、まだ直接I-HAの使用に切り替えるべきです。
The requirement that the i-HA cannot be reached from the external network is necessary. If not, a successful registration with the i-HA (without IPsec) cannot be used as a secure indication that the mobile node is inside. A possible solution to the obvious security problem would be to define and deploy a secure internal network detection mechanism based on, e.g., signed FA advertisement or signed DHCP messages.
I-HAは、外部ネットワークから到達できない要件が必要です。そうでない場合、（IPsecのなし）のI-HAとの登録が成功は、モバイルノードが内部であることを安全な指標として用いることができません。明白なセキュリティ上の問題に対する可能な解決策は、例えば、に基づいて、安全な内部ネットワークの検出機構を定義して展開することで、FAの広告または署名されたDHCPメッセージに署名しました。
However, unless the mechanism is defined for both FA and DHCP messages and is deployed in every internal network, it has limited applicability. In other words, the mobile node MUST NOT assume it is in the internal network unless it receives a signed FA or DHCP message (regardless of whether or not it can register directly with the i-HA). If it receives an unsigned FA or DHCP message, it MUST use IPsec; otherwise, the mobile node can be easily tricked into using plaintext.
メカニズムはFAとDHCPメッセージの両方のために定義されており、すべての内部ネットワークに展開されていない限り、しかし、それは限られた利用可能性を有します。それが署名されたFA又はDHCPメッセージを受信しない限り、換言すれば、移動ノードは（かかわらず、I-HAに直接登録することができるか否か）が内部ネットワークにあると仮定してはいけません。それは符号なしFAやDHCPメッセージを受信した場合、それは、IPsecを使用する必要があります。そうでない場合、モバイルノードは容易に平文を使用してだまさすることができます。
Assuming that all FA and DHCP servers in the internal network are upgraded to support such a feature does not seem realistic; it is highly desirable to be able to take advantage of existing DHCP and FA deployments. Similar analysis seems to apply regardless of what kind of additional security mechanism is defined.
内部ネットワーク内のすべてのFAとDHCPサーバは、このような機能をサポートするようにアップグレードされていると仮定すると、現実的なようではありません。既存のDHCPおよびFAの展開を利用できることが非常に望ましいです。同様の分析は関係なく、追加のセキュリティ・メカニズムの種類が定義されているものの適用ようです。
Because a firewall configuration error can have catastrophic data security consequences (silent exposure of user data to external attackers), a separate protection mechanism is provided by the i-HA. The i-HA must be configured, by the administrator, with a list of trusted networks. The i-HA advertises that it knows which registration request source addresses are trusted, using a registration reply extension (Trusted Networks Configured extension, Section 3.4). Without this extension, an MN may not rely on a successful registration to indicate that it is connected to the internal network. This ensures that user data compromise does not occur unless both the firewall and the i-HA are configured incorrectly. Further, occurrences of registration requests from untrusted addresses should be logged by the i-HA, exposing them to administrator review.
ファイアウォールの設定エラーが壊滅的なデータセキュリティへの影響（外部の攻撃者にユーザーデータのサイレント露出）を持つことができるので、別の保護メカニズムは、I-HAによって提供されます。 I-HAは、信頼できるネットワークのリストで、管理者は、設定する必要があります。 I-HAは、登録要求の送信元アドレスが登録応答拡張子（拡張子を設定した信頼できるネットワーク、セクション3.4）を使用して、信頼されているかを知っていることを通知します。この拡張機能がなければ、MNは、それが内部ネットワークに接続されていることを示すために、登録が成功に依存しないことがあります。これは、ファイアウォールとI-HAの両方が正しく構成されていない限り、ユーザーデータの妥協が発生しないことを保証します。さらに、信頼されていないアドレスからの登録要求の発生は、管理者の審査にさらす、I-HAによってログに記録されなければなりません。
This issue also affects IPsec client security. However, as IPsec specifications take no stand on how and when client IPsec policies are configured or changed (for instance, in response to a change in network connectivity), the issue is out of scope for IPsec. Because this document describes an algorithm and requirements for (secure) internal network detection, the issue is in scope of the document.
この問題はIPsecクライアントのセキュリティに影響を与えます。しかし、IPsecの仕様は、クライアントIPsecポリシーが設定または変更されている場合（例えば、ネットワーク接続の変化に応じて）、問題はIPsecのためのスコープ外でどのように何の立場を取らないと。この文書は、アルゴリズムと（安全な）内部のネットワーク検出のための要件を記述しているので、問題は文書の範囲です。
The current requirement for internal network monitoring was added as a fallback mechanism.
内部ネットワーク監視のための電流要件は、フォールバックメカニズムとして添加しました。
If encryption was applied also when MN was inside, there would be no security reason to monitor the internal network periodically.
MNは内部だったときの暗号化にも適用された場合は、定期的に内部ネットワークを監視するセキュリティ上の理由はないだろう。
The main rationale for why encryption cannot be applied when the MN is inside was given in Section 1.6. In short, the main issues are (1) power consumption; (2) extra CPU load, especially because internal networks are typically switched networks and a lot of data may be routinely transferred; (3) existing HA devices do not typically integrate IPsec functionality; (4) (IPsec) encryption requires user authentication, which may be interactive in some cases (e.g., SecurID) and thus a usability issue; and (5) user may need to have separate credentials for VPN devices in the DMZ and the HA.
MNが内部の場合に暗号化を適用することができない理由のための主な根拠は、1.6節で与えられました。要するに、主な問題は、（1）消費電力です。 （2）余分なCPU負荷、特に内部ネットワークは、典型的には、ネットワークを切り替えてデータの多くは、日常的に転送することができるからです。 （3）既存のHAデバイスは、通常のIPsec機能を統合していません。 （4）（IPsec）の暗号化がある場合には、対話型であってもよい、ユーザ認証を必要とする（例えば、SecurIDの）ので、ユーザビリティの問題。 （5）利用者は、DMZおよびHAにおけるVPNデバイス用に別の資格情報を持っている必要があるかもしれません。
The registration process can be improved in many ways. One simple way is to make the x-HA detect whether a registration request came from inside or outside the enterprise network. If it came from inside the enterprise network, the x-HA can simply drop the registration request.
登録プロセスは、多くの方法で改善することができます。一つの簡単な方法は、x-HAは、登録要求が企業ネットワークの内部または外部から来たのかどうかを検出することです。それが企業ネットワーク内部から来た場合は、X-HAは、単に登録要求をドロップすることができます。
This approach is feasible without protocol changes in scenarios where a corporation owns both the VPN and the x-HA. The x-HA can simply determine based on the incoming interface identifier (or the router that relayed the packet) whether or not the registration request came from inside.
このアプローチは、企業はVPNやX-HAの両方を所有しているシナリオでプロトコルを変更することなく実現可能です。登録要求が内部から来たか否かをX-HAは単に着信インターフェイス識別子（又はパケットを中継ルータ）に基づいて決定することができます。
In other scenarios, protocol changes may be needed. Such changes are out of scope of this document.
他のシナリオでは、プロトコルの変更が必要とされ得ます。このような変化は、この文書の範囲外です。
The mobile node MUST implement an internal network detection algorithm fulfilling the requirements set forth in Section 3.2. A new configurable MN parameter, T_MONITOR, is required. The value of this parameter reflects a balance between security and the amount of signaling overhead, and thus needs to be configurable. In addition, when doing internal network detection, the MN MUST NOT disable IPsec protection unless the registration reply from the i-HA contains a Trusted Networks Configured extension (Section 3.4).
モバイルノードは、セクション3.2に記載された要件を満たす内部ネットワーク検出アルゴリズムを実装しなければなりません。新しい設定可能なMNパラメータ、T_MONITORは、必要とされます。このパラメータの値は、セキュリティとシグナリングオーバーヘッドの量とのバランスを反映し、したがって、設定する必要があります。内部ネットワーク検出を行う場合、I-HAからの登録応答が信頼できるネットワーク構成された拡張子（3.4節）が含まれていない限り、また、MNは、IPsec保護を無効にしてはなりません。
The mobile node MUST support access modes c, f, cvc, fvc (Section 2).
モバイルノードは、アクセスモードのC、F、CVC、FVC（セクション2）をサポートしなければなりません。
The mobile node SHOULD support Mobile IPv4 NAT traversal [mipnat] for both internal and external Mobile IP.
モバイルノードは、[mipnat】内部と外部の両方のモバイルIPのためのモバイルIPv4 NATトラバーサルをサポートしなければなりません。
The mobile node SHOULD support IPsec NAT traversal [RFC3947] [RFC3948].
モバイルノードは、IPsec NATトラバーサル[RFC3947]、[RFC3948]をサポートすべきです。
When the mobile node has direct access to the i-HA, it SHOULD use only the inner Mobile IPv4 layer to minimize firewall and VPN impact.
モバイルノードは、I-HAへの直接アクセスを有する場合、それは、ファイアウォール及びVPNへの影響を最小限に抑えるためだけ内側モバイルIPv4層を使用すべきです。
When the mobile node is outside and using the VPN connection, IPsec policies MUST be configured to encrypt all traffic sent to and from the enterprise network. The particular Security Policy Database (SPD) entries depend on the type and configuration of the particular VPN (e.g., plain IPsec vs. L2TP/IPsec, full tunneling or split tunneling).
モバイルノードは、外部とのVPN接続を使用している場合、IPSecポリシーは、企業ネットワークへ及びから送信されたすべてのトラフィックを暗号化するように構成されなければなりません。特定のセキュリティポリシーデータベース（SPD）エントリは、特定のVPN（L2TP / IPsecの対例えば、無地のIPsec、フルトンネリングまたはスプリットトンネリング）の種類や構成によって異なります。
The VPN security policy MUST allow communication using UDP to the internal home agent(s), with home agent port 434 and any remote port. The security policy SHOULD allow IP-IP to internal home agent(s) in addition to UDP port 434.
VPNのセキュリティポリシーは、ホームエージェントポート434および任意のリモートポートと、内部のホームエージェント（複数可）にUDPを用いた通信を許可する必要があります。セキュリティポリシーは、UDPポート434に加えて、内部のホームエージェント（複数可）にIP-IPを許可する必要があります。
The VPN device SHOULD implement the IPsec NAT traversal mechanism described in [RFC3947] and [RFC3948].
VPN装置は、[RFC3947]及び[RFC3948]に記載されたIPsec NATトラバーサル機構を実装する必要があります。
The home agent SHOULD implement the Mobile IPv4 NAT traversal mechanism described in [mipnat]. (This also refers to the i-HA: NAT traversal is required to support VPNs that NAT VPN tunnel addresses or block IP-IP traffic.)
ホームエージェントは、[mipnat]で説明したモバイルIPv4 NATトラバーサルメカニズムを実装する必要があります。 （これはまた、I-HAを意味：NATトラバーサルは、そのNAT VPNトンネルアドレスまたはブロックIP-IPトラフィックのVPNをサポートするために必要とされます。）
To protect user data confidentiality against firewall configuration errors, the i-HA:
ファイアウォールの設定エラーに対するユーザデータの機密性を保護するために、I-HA：
o MUST be configured with a list of trusted IP subnets (containing only addresses from the internal network), with no subnets being trusted by default.
oはないサブネットが、デフォルトで信頼されなかった状態で、（内部ネットワークからのアドレスのみを含む）信頼できるIPサブネットのリストを設定する必要があります。
o MUST reject (drop silently) any registration request coming from a source address that is not inside any of the configured trusted subnets. These dropped registration requests SHOULD be logged.
oは（サイレントドロップ）構成信頼サブネットのいずれか内にない送信元アドレスから任意の登録要求を拒絶しなければなりません。これらのドロップされた登録要求は、ログインする必要があります。
o MUST include a Trusted Networks Configured extension (Section 3.4) in a registration reply sent in response to a registration request coming from a trusted address.
oは、信頼できるアドレスからの登録要求に応答して送信される登録応答に信頼されたネットワーク構成された拡張子（3.4節）を含まなければなりません。
This section provides a comparison against guidelines described in Section 6 of the problem statement [RFC4093] and additional analysis of packet overhead with and without the optional mechanisms.
このセクションでは、問題文[RFC4093]を有すると任意のメカニズムなしでパケットのオーバーヘッドの追加の分析のセクション6で説明したガイドラインとの比較を提供します。
Preservation of existing VPN infrastructure
既存のVPNインフラストラクチャの保全
o The solution does not mandate any changes to existing VPN infrastructure, other than possibly changes in configuration to avoid stateful filtering of traffic.
Oソリューションは、トラフィックのステートフルフィルタリングを回避するために、構成の可能性の変化よりも、他の既存のVPNインフラストラクチャへの変更を、強制しません。
Software upgrades to existing VPN clients and gateways
既存のVPNクライアントとゲートウェイへのソフトウェアのアップグレード
o The solution described does not require any changes to VPN gateways or Mobile IPv4 foreign agents.
O説明した解決策は、VPNゲートウェイ、またはモバイルIPv4外部エージェントへの変更を必要としません。
IPsec protocol
IPsecプロトコル
o The solution does not require any changes to existing IPsec or key exchange standard protocols, and does not require implementation of new protocols in the VPN device.
Oソリューションは、既存のIPsecまたは鍵交換の標準プロトコルを変更する必要はありません。また、VPNデバイスの新しいプロトコルの実装を必要としません。
Multi-vendor interoperability
マルチベンダーの相互運用性
o The solution provides easy multi-vendor interoperability between server components (VPN device, foreign agents, and home agents). Indeed, these components need not be aware of each other.
溶液oをサーバコンポーネント（VPN装置、外部エージェントとホームエージェント）との間の容易なマルチベンダの相互運用性を提供します。確かに、これらのコンポーネントは、互いを意識する必要はありません。
o The mobile node networking stack is somewhat complex to implement, which may be an issue for multi-vendor interoperability. However, this is a purely software architecture issue, and there are no known protocol limitations for multi-vendor interoperability.
Oモバイルノードのネットワークスタックは、マルチベンダーの相互運用性のために問題となり得る、実装が多少複雑です。しかし、これは純粋にソフトウェアアーキテクチャの問題であり、マルチベンダーの相互運用性のための既知のプロトコルの制限はありません。
MIPv4 protocol
MIPv4のプロトコル
o The solution adheres to the MIPv4 protocol, but requires the new Trusted Networks Configured extension to improve the trustworthiness of internal network detection.
Oソリューションは、MIPv4のプロトコルに準拠しますが、内部のネットワーク検出の信頼性を向上させるために拡張を設定された新しい信頼できるネットワークが必要です。
o The solution requires the use of two parallel MIPv4 layers.
O溶液は、二つの平行のMIPv4層の使用を必要とします。
Handoff overhead
ハンドオフのオーバーヘッド
o The solution provides a mechanism to avoid VPN tunnel SA renegotiation upon movement by using the external MIPv4 layer.
O溶液は、外部のMIPv4層を使用して移動時VPNトンネルSAの再ネゴシエーションを回避するための機構を提供します。
Scalability, availability, reliability, and performance
スケーラビリティ、可用性、信頼性、およびパフォーマンス
o The solution complexity is linear with the number of MNs registered and accessing resources inside the intranet.
Oソリューションの複雑さは、MNの登録およびイントラネット内のリソースへのアクセス数と直線的です。
o Additional overhead is imposed by the solution.
O追加のオーバーヘッドは、溶液によって課されます。
Functional entities
機能エンティティ
o The solution does not impose any new types of functional entities or required changes to existing entities. However, an external HA device is required.
Oソリューションは、機能エンティティまたは既存のエンティティに必要な変更のいずれかの新しいタイプを課しません。しかし、外部HAデバイスが必要です。
Implications of intervening NAT gateways
NATゲートウェイを介在の意味
o The solution leverages existing MIPv4 NAT traversal [mipnat] and IPsec NAT traversal [RFC3947] [RFC3948] solutions and does not require any new functionality to deal with NATs.
Oソリューションは、既存のMIPv4 NATトラバーサル[mipnat]とIPsec NATトラバーサル[RFC3947] [RFC3948]のソリューションを活用し、NATのに対処するための新たな機能を必要としません。
Security implications
セキュリティへの影響
o The solution requires a new mechanism to detect whether the mobile node is in the internal or the external network. The security of this mechanism is critical in ensuring that the security level provided by IPsec is not compromised by a faulty detection mechanism.
O溶液は、モバイルノードは、内部または外部ネットワークにあるかどうかを検出するための新しいメカニズムを必要とします。このメカニズムのセキュリティは、IPsecによって提供されるセキュリティレベルは、故障検知機構によって損なわれないことを確保する上で重要です。
o When the mobile node is outside, the external Mobile IPv4 layer may allow some traffic redirection attacks that plain IPsec does not allow. Other than that, IPsec security is unchanged.
モバイルノードが外部である場合、O、外部モバイルIPv4層が無地IPsecは許可しないといういくつかのトラフィックリダイレクション攻撃を可能にすることができます。それ以外は、IPsecセキュリティは変更されません。
o More security considerations are described in Section 6.
Oその他のセキュリティの考慮事項は、第6節で説明されています。
The maximum packet overhead depends on access mode as follows:
次のように最大パケットオーバーヘッドは、アクセスモードによって異なります。
o f: 0 octets
O F：0オクテット
o c: 20 octets
OのC：20個のオクテット
o fvc: 77 octets
O FVC：77個のオクテット
o cvc: 97 octets
CVC O：97個のオクテット
The maximum overhead of 97 octets in the 'cvc' access mode consists of the following:
「CVCのアクセス・モードで97オクテットの最大のオーバーヘッドは以下で構成されています。
o IP-IP for i-MIPv4: 20 octets
I-MIPv4のためのIP-IP O：20個のオクテット
o IPsec ESP: 57 octets total, consisting of 20 (new IP header), 4+4+8 = 16 (SPI, sequence number, cipher initialization vector), 7+2 = 9 (padding, padding length field, next header field), 12 (ESP authentication trailer)
IPsecのESP O：57個のオクテット20（新しいIPヘッダ）からなる、合計4 + 4 + 8 = 16（SPI、シーケンス番号、暗号初期化ベクトル）、7 + 2 = 9（パディング、パディング長フィールド、次ヘッダフィールド）、12（ESP認証トレーラ）
o IP-IP for x-MIPv4: 20 octets
X-MIPv4のためのIP-IP O：20個のオクテット
When IPsec is used, a variable amount of padding is present in each ESP packet. The figures were computed for a cipher with 64-bit block size, padding overhead of 9 octets (next header field, padding length field, and 7 octets of padding; see Section 2.4 of [RFC4303]), and ESP authentication field of 12 octets (HMAC-SHA1-96 or HMAC-MD5-96). Note that an IPsec implementation MAY pad with more than a minimum amount of octets.
IPsecを使用する場合、パディングの可変量は、各ESPパケットの中に存在します。 （[RFC4303]のセクション2.4を参照して次のヘッダフィールド、パディング長フィールド、及びパディングの7つのオクテット）、および12オクテットのESP認証フィールドの数値は、64ビットのブロックサイズ、9つのオクテットのパディングオーバーヘッドで暗号について計算しました。 （HMAC-SHA1-96またはHMAC-MD5-96）。オクテットの最小量以上とのIPsec実装MAYパッドことに注意してください。
NAT traversal overhead is not included, and adds 8 octets when IPsec NAT traversal [RFC3947] [RFC3948] is used and 12 octets when MIP NAT traversal [mipnat] is used. For instance, when using access mode cvc, the maximum NAT traversal overhead is 12+8+12 = 32 octets. Thus, the worst case scenario (with the above mentioned ESP assumptions) is 129 octets for cvc.
NATトラバーサルオーバーヘッドが含まれており、MIP NATトラバーサルは、[mipnat】使用する場合にIPsec NATトラバーサル[RFC3947]、[RFC3948]が使用される8つのオクテット12個のオクテットを追加していません。アクセスモードCVCを使用する場合、例えば、最大NATトラバーサルオーバーヘッドは12 + 8 + 12 = 32オクテットです。従って、（上記ESP仮定で）最悪の場合のシナリオは、CVCのために129オクテットです。
When the MN is inside, connection setup latency does not increase compared to standard MIPv4 if the MN implements the suggested parallel registration sequence (see Section 3.3). Exchange of RRQ/ RRP messages with the i-HA confirms the MN is inside, and the MN may start sending and receiving user traffic immediately. For the same reason, handovers in the internal network have no overhead relative to standard MIPv4.
MNが内部にある場合は、接続設定待ち時間は、MNが提案パラレル登録シーケンスを実装している場合（3.3節を参照）は、標準のMIPv4に比べて増加しません。 I-HAとのRRQ / RRPメッセージの交換は、MNが内部で確認し、MNは、送信とすぐにユーザトラフィックの受信を開始することができます。同じ理由のために、内部ネットワークにおけるハンドオーバは、標準のMIPv4へのオーバーヘッド相対がありません。
When the MN is outside, the situation is slightly different. Initial connection setup latency essentially consists of (1) registration with the x-HA, (2) optional detection delay (waiting for i-HA response), (3) IPsec connection setup (IKE), and (4) registration with the i-HA. All but (4) are in addition to standard MIPv4.
MNが外にある場合は、状況は少し異なります。初期接続セットアップ待ち時間は、本質的に、X-HA、I（2）任意の検出遅れ（I-HAの応答を待っている）、（3）のIPsec接続設定（IKE）、および（4）登録を用いて（1）登録から成り - HA。すべてが、（4）は、標準のMIPv4に追加されます。
However, handovers in the external network have performance comparable to standard MIPv4. The MN simply re-registers with the x-HA and starts to send IPsec traffic to the VPN gateway from the new address.
しかし、外部ネットワークにおけるハンドオーバは、標準のMIPv4に匹敵する性能を持っています。 MNは、単にX-HAに再登録され、新しいアドレスからVPNゲートウェイへのIPsecトラフィックの送信を開始します。
The MN may minimize latency by (1) not waiting for an i-HA response before triggering IKE if the x-HA registration succeeds and (2) sending first the RRQ most likely to succeed (e.g., if the MN is most likely outside). These can be done based on heuristics about the network, e.g., addresses, MAC address of the default gateway (which the mobile node may remember from previous access); based on the previous access network (i.e., optimize for inside-inside and outside-outside movement); etc.
MNは、x-HAの登録が成功すると、（2）最初に成功する可能性が最も高いRRQを送信した場合、IKEをトリガーする前に、（1）は、i-HA応答を待っていないことで、待ち時間を最小限にすることができる（例えば、MNは、外部の最も可能性がある場合） 。これらは、ネットワークに関するヒューリスティック、例えば、アドレス、（モバイルノードが前のアクセスから思い出すことができる）デフォルトゲートウェイのMACアドレスに基づいて行うことができます。前のアクセスネットワークに基づいて（すなわち、インサイド内外-外移動のために最適化）。等
A separate firewall device or an integrated firewall in the VPN gateway typically performs stateful inspection of user traffic. The firewall may, for instance, track TCP session status and block TCP segments not related to open connections. Other stateful inspection mechanisms also exist.
別のファイアウォールデバイスまたはVPNゲートウェイに統合されたファイアウォールは、典型的には、ユーザトラフィックのステートフルインスペクションを行います。ファイアウォールは、例えば、ではない接続を開くために、関連するTCPセッションの状態とブロックTCPセグメントを追跡することができます。その他のステートフルインスペクションメカニズムも存在します。
Firewall state poses a problem when the mobile node moves between the internal and external networks. The mobile node may, for instance, initiate a TCP connection while inside, and later go outside while expecting to keep the connection alive. From the point of view of the firewall, the TCP connection has not been initiated, as it has not witnessed the TCP connection setup packets, thus potentially resulting in connectivity problems.
ファイアウォールの状態は、モバイルノードは、内部ネットワークと外部ネットワークとの間で移動させるという問題があります。モバイルノードは、例えば、内部の間、TCP接続を開始し、生きている接続を維持するために期待しながら、後に外に出ることがあります。それは、このように潜在的に接続の問題が生じ、TCP接続設定パケットを目撃していないとして、ファイアウォールの観点からは、TCP接続は、開始されていません。
When the VPN-TIA is registered as a co-located care-of address with the i-HA, all mobile node traffic appears as IP-IP for the firewall.
VPN-TIAが共同設置気付アドレスI-HAのように登録されている場合は、すべてのモバイルノードのトラフィックはファイアウォールのIP-IPとして表示されます。
Typically, firewalls do not continue inspection beyond the IP-IP tunnel, but support for deeper inspection is available in many products. In particular, an administrator can configure traffic policies in many firewall products even for IP-IP encapsulated traffic. If this is done, similar statefulness issues may arise.
一般的に、ファイアウォールは、IP-IPトンネルを超えて検査を継続していませんが、より深い検査のためのサポートは、多くの製品で利用可能です。具体的には、管理者がさえIP-IPカプセル化されたトラフィックのために多くのファイアウォール製品のトラフィックポリシーを設定することができます。これが行われた場合、同様のステートフルの問題が生じる可能性があります。
In summary, the firewall must allow traffic coming from and going into the IPsec connection to be routed, even though they may not have successfully tracked the connection state. How this is done is out of scope of this document.
要約すると、ファイアウォールは、トラフィックがから来て、彼らは接続状態を成功裏に追跡されていなくても、ルーティングするIPsec接続に入ることができなければなりません。これはどのように行われ、この文書の範囲外です。
Many firewalls incorporate intrusion detection systems monitoring network traffic for unusual patterns and clear signs of attack. Since traffic from a mobile node implementing this specification is UDP to i-HA port 434, and possibly IP-IP traffic to the i-HA address, existing IDSs may treat the traffic differently than ordinary VPN remote access traffic. Like firewalls, IDSs are not standardized, so it is impossible to guarantee interoperability with any particular IDS system.
多くのファイアウォールでは珍しいパターンと攻撃の明確な兆候が侵入検知システム監視、ネットワークトラフィックを組み込みます。この仕様を実装するモバイルノードからのトラフィックので、IDSは、通常のVPNリモートアクセストラフィックとは異なるトラフィックを処理することが、既存の、I-HAアドレスにI-HAポート434、そしておそらくIP-IPトラフィックにUDPをです。ファイアウォールのように、IDSは、特定のIDSシステムとの相互運用性を保証することは不可能であるので、標準化されていません。
Implementation of the mobile node requires the use of three tunneling layers, which may be used in various configurations depending on whether that particular interface is inside or outside. Note that it is possible that one interface is inside and another interface is outside, which requires a different layering for each interface at the same time.
モバイルノードの実装は、その特定のインターフェイスが内部または外部であるかに応じて様々な構成で使用することができる3つのトンネル層の使用を必要とします。一つのインタフェースは内部であり、別のインタフェースが同時にインタフェースごとに異なるレイヤリングを必要とする、外部であることが可能であることに留意されたいです。
For multi-vendor implementation, the IPsec and MIPv4 layers need to interoperate in the same mobile node. This implies that a flexible framework for protocol layering (or protocol-specific APIs) is required.
マルチベンダの実装のために、IPsecとMIPv4の層は、同じモバイルノードで相互運用する必要があります。これは、積層プロトコル（またはプロトコル固有のAPI）のための柔軟なフレームワークが必要であることを意味します。
The solution also works for VPN tunneling protocols that are not IPsec-based, provided that the mobile node is provided IPv4 connectivity with an address suitable for registration. However, such VPN protocols are not explicitly considered.
溶液はまた、モバイルノードが登録のために適切なアドレスをIPv4接続が設けられていることを条件とする、IPsecベースれていないVPNトンネリングプロトコルのために働きます。しかし、そのようなVPNプロトコルは、明示的に考慮されていません。
If the mobile node by mistake believes it is in the internal network and sends plaintext packets, it compromises IPsec security. For this reason, the overall security (confidentiality and integrity) of user data is a minimum of (1) IPsec security and (2) security of the internal network detection mechanism.
誤ってモバイルノードは、それが内部ネットワークであると考えているし、平文のパケットを送信する場合、それはIPsecセキュリティを損ないます。このため、ユーザデータの全体的なセキュリティ（機密性と完全性）（1）IPsecセキュリティと内部ネットワークの検出機構の（2）セキュリティの最小値です。
Security of the internal network detection relies on a successful registration with the i-HA. For standard Mobile IPv4 [RFC3344], this means HMAC-MD5 and Mobile IPv4 replay protection. The solution also assumes that the i-HA is not directly reachable from the external network, requiring careful enterprise firewall configuration. To minimize the impact of a firewall configuration problem, the i-HA is separately required to be configured with trusted source addresses (i.e., addresses belonging to the internal network), and to include an indication of this in a new Trusted Networks Configured extension. The MN is required not to trust a registration as an indication of being connected to the internal network, unless this extension is present in the registration reply. Thus, to actually compromise user data confidentiality, both the enterprise firewall and the i-HA have to be configured incorrectly, which reduces the likelihood of the scenario.
内部のネットワーク検出のセキュリティがi-HAに登録が成功に依存しています。標準モバイルIPv4 [RFC3344]のために、これはHMAC-MD5およびモバイルIPv4リプレイ保護を意味します。溶液はまた、I-HAは注意企業ファイアウォールの設定を必要とする外部ネットワークから直接に到達できないことを想定しています。ファイアウォール構成の問題の影響を最小限に抑えるために、I-HAは、別々に、信頼できるソースアドレス（すなわち、内部ネットワークに属するアドレス）で設定する必要がある、と新たな信頼できるネットワーク設定さエクステンションでこの指示を含めること。 MNは、この拡張は、登録応答内に存在しない限り、内部ネットワークに接続されているの指標として登録を信用しないことが要求されます。したがって、実際にユーザデータの機密性を妥協する、企業のファイアウォールとI-HAの両方のシナリオの可能性を減少させる、正しく構成されなければなりません。
When the mobile node sends a registration request to the i-HA from an untrusted network that does not go through the IPsec tunnel, it will reveal the i-HA's address, its own identity including the NAI and the home address, and the Authenticator value in the authentication extensions to the untrusted network. This may be a concern in some deployments.
モバイルノードは、IPsecトンネルを経由しない、信頼できないネットワークからI-HAに登録要求を送信すると、それがi-HAのアドレス、NAI、ホームアドレスを含む独自のアイデンティティ、及び認証値を明らかにする信頼できないネットワークへの認証の拡張インチこれは、いくつかの展開で問題となる場合があります。
When the connection status of an interface changes, an interface previously connected to the trusted internal network may suddenly be connected to an untrusted network. Although the same problem is also relevant to IPsec-based VPN implementations, the problem is especially relevant in the scope of this specification.
インターフェイスの変更の場合の接続状態、以前に信頼できる内部ネットワークに接続されたインタフェースが突然信頼できないネットワークに接続されてもよいです。同じ問題は、IPsecベースのVPNの実装に関連しているが、問題は、この明細書の範囲に特に適切です。
In most cases, mobile node implementations are expected to have layer 2 information available, making connection change detection both fast and robust. To cover cases where such information is not available (or fails for some reason), the mobile node is required to periodically re-register with the internal home agent to verify that it is still connected to the trusted network. It is also required that this re-registration interval be configurable, thus giving the administrator a parameter by which potential exposure may be controlled.
ほとんどの場合、モバイルノードの実装は、高速かつ堅牢な両方の接続変更の検出を行う利用可能なレイヤ2情報を有することが期待されます。そのような情報が利用できない（または何らかの理由で失敗した）場合をカバーするために、モバイルノードは、定期的にそれがまだ信頼できるネットワークに接続されていることを確認するために、内部のホームエージェントに再登録する必要があります。また、このように管理者に潜在的な露出を制御することができることにより、パラメータを与え、この再登録間隔を設定することが必要です。
MIPv4 and IPsec have different goals and approaches for providing security services. MIPv4 typically uses a shared secret for authentication of signaling traffic, while IPsec typically uses IKE (an authenticated Diffie-Hellman exchange) to set up session keys. Thus, the overall security properties of a combined MIPv4 and IPsec system depend on both mechanisms.
MIPv4のとIPsecは、セキュリティサービスを提供するためのさまざまな目標とアプローチを持っています。 IPsecは、典型的には、セッション鍵をセットアップするためにIKE（認証されたDiffie-Hellman交換）を使用しながらのMIPv4は、典型的には、トラフィックシグナリングの認証のために共有秘密を使用します。したがって、組み合わされたMIPv4とIPsecシステムの全体的なセキュリティ特性は、両方のメカニズムに依存します。
In the solution outlined in this document, the external MIPv4 layer provides mobility for IPsec traffic. If the security of MIPv4 is broken in this context, traffic redirection attacks against the IPsec traffic are possible. However, such routing attacks do not affect other IPsec properties (confidentiality, integrity, replay protection, etc.), because IPsec does not consider the network between two IPsec endpoints to be secure in any way.
このドキュメントで概説ソリューションでは、外部のMIPv4層は、IPsecトラフィックのモビリティを提供します。 MIPv4ののセキュリティは、この文脈で壊れている場合は、IPsecトラフィックに対するトラフィックリダイレクション攻撃が可能です。 IPsecはどのような方法で安全であるために、2つのIPsecエンドポイント間のネットワークを考慮していないので、しかし、そのようなルーティング攻撃は、他のIPsecの特性（機密性、完全性、再生保護、など）には影響しません。
Because MIPv4 shared secrets are usually configured manually, they may be weak if easily memorizable secrets are chosen, thus opening up redirection attacks described above. Note especially that a weak secret in the i-HA is fatal to security, as the mobile node can be fooled into dropping encryption if the i-HA secret is broken.
MIPv4の共有秘密は通常、手動で設定されているので、容易に記憶可能秘密は、上述したリダイレクション攻撃を、選択されたこのよう開放されている場合、それらは弱いかもしれません。 I-HA秘密が壊れている場合、モバイルノードが落下暗号化にだまされることが可能とI-HAの弱い秘密は、セキュリティに致命的であることに特に注意してください。
Assuming the MIPv4 shared secrets have sufficient entropy, there are still at least the following differences and similarities between MIPv4 and IPsec worth considering:
検討する価値のMIPv4とIPsecとの間に、少なくとも以下の相違点と類似点が残っている、MIPv4のは秘密が十分なエントロピーを持っていると仮定すると、共有：
o Both IPsec and MIPv4 are susceptible to the "transient pseudo NAT" attack described in [pseudonat] and [mipnat], assuming that NAT traversal is enabled (which is typically the case). "Pseudo NAT" attacks allow an attacker to redirect traffic flows, resulting in resource consumption, lack of connectivity, and denial of service. However, such attacks cannot compromise the confidentiality of user data protected using IPsec.
O IPsecとMIPv4の両方がNATトラバーサル（通常ケースである）が有効であると仮定すると、[mipnat] [pseudonat]および記載された「過渡疑似NAT」攻撃を受けやすいです。 「疑似NAT」攻撃では、攻撃者が資源消費、接続性の欠如、およびサービス拒否が生じ、トラフィックフローをリダイレクトすることができます。しかし、このような攻撃は、IPsecを使用して保護されたユーザデータの機密性を妥協することはできません。
o When considering a "pseudo NAT" attack against standard IPsec and standard MIP (with NAT traversal), redirection attacks against MIP may be easier because:
（NATトラバーサル付き）標準IPsecと標準MIPに対する「疑似NAT」攻撃を考慮すると、O、MIPに対するリダイレクション攻撃があるため容易になることがあります。
* MIPv4 re-registrations typically occur more frequently than IPsec SA setups (although this may not be the case for mobile hosts).
*のMIPv4（これはモバイルホストのための場合ではないかもしれないが）、再登録は、通常のIPsec SAのセットアップよりも頻繁に起こります。
* It suffices to catch and modify a single registration request, whereas attacking IKE requires that multiple IKE packets are caught and modified.
*これは、IKEを攻撃すると、複数のIKEパケットがキャッチされ、修正されている必要があり、一方、単一の登録要求をキャッチして修正すればよいです。
o There may be concerns about mixing of algorithms. For instance, IPsec may be using HMAC-SHA1-96, while MIP is always using HMAC-MD5 (RFC 3344) or prefix+suffix MD5 (RFC 2002). Furthermore, while IPsec algorithms are typically configurable, MIPv4 clients typically use only HMAC-MD5 or prefix+suffix MD5. Although this is probably not a security problem as such, it is more difficult to communicate to users.
Oアルゴリズムの混合についての懸念があるかもしれません。 MIPは常にHMAC-MD5（RFC 3344）または接頭辞+接尾MD5（RFC 2002）を使用している間、例えば、IPsecは、HMAC-SHA1-96を使用してもよいです。 IPsecアルゴリズムは、一般的に構成されている間、さらに、MIPv4のクライアントは、一般的にのみHMAC-MD5または接頭語+接尾MD5を使用します。これはおそらくのようなセキュリティ上の問題ではありませんが、ユーザーと通信することがより困難です。
o When IPsec is used with a Public Key Infrastructure (PKI), the key management properties are superior to those of basic MIPv4. Thus, adding MIPv4 to the system makes key management more complex.
IPsecは公開鍵基盤（PKI）を使用する場合は、O、鍵管理プロパティは、基本のMIPv4のものよりも優れています。このように、システムへのMIPv4を追加すると、鍵の管理がより複雑になります。
o In general, adding new security mechanisms increases overall complexity and makes the system more difficult to understand.
O一般的には、新しいセキュリティ機構を追加して、全体的な複雑さを増し、理解するシステムをより困難にします。
This document specifies a new skippable extension (in the short format) in Section 3.4, whose Type and Sub-Type values have been assigned.
この文書では、タイプとサブタイプの値が割り当てられているセクション3.4、中（短い形式）新しいスキップ可能な拡張子を指定します。
Allocation of new Sub-Type values can be made via Expert Review and Specification Required [RFC5226].
新しいサブタイプ値の割当ては、専門家のレビューと仕様が必要である[RFC5226]を介して行うことができます。
This document is a joint work of the contributing authors (in alphabetical order):
この文書は、（アルファベット順）寄稿者の共同作業です。
- Farid Adrangi (Intel Corporation)
- Nitsan Baider (Check Point Software Technologies, Inc.)
- Gopal Dommety (Cisco Systems)
- Eli Gelasco (Cisco Systems)
- Dorothy Gellert (Nokia Corporation)
- Espen Klovning (Birdstep)
- Milind Kulkarni (Cisco Systems)
- Henrik Levkowetz (ipUnplugged AB)
- Frode Nielsen (Birdstep)
- Sami Vaarala (Codebay)
- Qiang Zhang (Liqwid Networks, Inc.)
The authors would like to thank the MIP/VPN design team, especially Mike Andrews, Gaetan Feige, Prakash Iyer, Brijesh Kumar, Joe Lau, Kent Leung, Gabriel Montenegro, Ranjit Narjala, Antti Nuopponen, Alan O'Neill, Alpesh Patel, Ilkka Pietikainen, Phil Roberts, Hans Sjostrand, and Serge Tessier for their continuous feedback and helping us improve this document. Special thanks to Radia Perlman for giving the document a thorough read and a security review. Tom
著者は、特にマイク・アンドリュース、ガエタンFeige、プラカシュアイヤル、Brijesh Kumar氏、ジョー・ラウ、ケントレオン、ガブリエルモンテネグロ、ランジットNarjala、アンティNuopponen、アラン・オニール、Alpeshパテル、イルッカ、MIP / VPNの設計チームに感謝したいと思いますPietikainen、フィル・ロバーツ、ハンスSjostrand、およびセルジュテッシェ彼らの継続的なフィードバックのために、私たちはこの文書を改善を支援。文書に徹底した読み取りおよびセキュリティレビューを与えるためのラディア・パールマンに感謝します。トム
Hiller pointed out issues with battery-powered devices. We would also like to thank the previous Mobile IP working group chairs (Gabriel Montenegro, Basavaraj Patil, and Phil Roberts) for important feedback and guidance.
ヒラーは、バッテリ駆動デバイスの問題を指摘しました。我々はまた、重要なフィードバックと指導のために、以前のモバイルIPワーキンググループチェア（ガブリエルモンテネグロ、Basavarajパティル、フィル・ロバーツ）を感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A.、およびV.ボルペ、 "IKEにおけるNATトラバーサルのネゴシエーション"、RFC 3947、2005年1月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "IPsecパケットのUDPカプセル化"、RFC 3948、2005年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[mipnat] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003.
[mipnat] Levkowetz、H.とS. Vaarala、 "モバイルIPトラバーサルネットワークのアドレス変換（NAT）デバイス"、RFC 3519、2003年4月。
[privaddr] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
【privaddr] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、デ・グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[RFC2002]パーキンス、C.、 "IPモビリティサポート"、RFC 2002、1996年10月。
[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
[RFC3456]パテル、B.、Aboba、B.、ケリー、S.、およびV.グプタ、 "IPsecのトンネルモードの動的ホスト構成プロトコル（DHCPv4の）設定"、RFC 3456、2003年1月。
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[RFC3776] Arkko、J.、Devarapalli、V.、およびF.デュポン、 "モバイルノードとホームエージェント間のモバイルIPv6シグナリングを保護するためにIPsecを使用する"、RFC 3776、2004年6月。
[RFC4093] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, August 2005.
[RFC4093] Adrangi、F.およびH. Levkowetz、 "問題文：仮想プライベートネットワーク（VPN）ゲートウェイのモバイルIPv4トラバーサル"、RFC 4093、2005年8月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555] Eronen、P.、 "IKEv2のモビリティとマルチホーミングプロトコル（MOBIKE）"、RFC 4555、2006年6月。
[pseudonat] Dupont, F. and J. Bernard, "Transient pseudo-NAT attacks or how NATs are even more evil than you believed", Work in Progress, June 2004.
[pseudonat]デュポン、F.およびJ.バーナード、進歩、2004年6月に、仕事を「一時疑似NAT攻撃やどのようにNATは、さらにあなたが信じよりも悪です」。
[tessier] Tessier, S., "Guidelines for Mobile IP and IPsec VPN Usage", Work in Progress, December 2002.
[テッシェ]テッシェ、S.、 "モバイルIPおよびIPsec VPNの使用のためのガイドライン"、進歩、2002年12月の作業。
Appendix A. Packet Flow Examples
付録A.パケットフローの例
A.1. Connection Setup for Access Mode 'cvc'
A.1。アクセスモード「CVC」の接続設定
The following figure illustrates connection setup when the mobile node is outside and using a co-located care-of address. IKE connection setup is not shown in full, and involves multiple round trips (4.5 round trips when using main mode followed by quick mode).
モバイルノードが外部と同一位置気付アドレスを使用している場合は、次の図は、接続設定を示します。 IKE接続設定をフルに示されており、（クイックモードが続くメインモードを使用するときに4.5往復）、複数のラウンドトリップを必要とされていません。
MN-APP MN x-HA VPN i-HA CN
! ! ! ! ! !
! ! -------> ! ! ! !
! ! rrq ! ! ! !
! ! -----------------X ! ! ! rrq not
! ! rrq ! ! ! ! received
! ! ! ! ! ! by i-HA
! ! <------- ! ! ! !
! ! rrp ! ! ! !
! ! ! ! ! !
! [wait for detection period for response from i-HA] !
! [may also retransmit to i-HA, depending on config] ! no rrp
! ! ! ! ! ! from i-HA
! ! ==(1)==> ! ! ! !
! ! ike {1a}! -------> ! ! !
! ! ! ike ! ! !
! ! ! <------- ! ! !
! ! <==(1)== ! ike ! ! !
! ! ike ! ! ! !
: : : : : :
: : : : : :
! ! ! ! ! !
! ! ==(2)==> ! ! ! !
! ! rrq {2a}! ==(1)==> ! ! !
! ! ! rrq {2b}! -------> ! !
! ! ! ! rrq {2c}! !
! ! ! ! <------- ! !
! ! ! <==(1)== ! rrp ! !
! ! <==(2)== ! rrp ! ! !
! ! rrp ! ! ! !
! ! ! ! ! !
[[--- connection setup ok, bidirectional connection up ---]]
! ! ! ! ! !
! -------> ! ! ! ! !
! pkt {3a}! ==(3)==> ! ! ! !
! ! pkt {3b}! ==(2)==> ! ! !
! ! ! pkt {3c}! ==(1)==> ! !
! ! ! ! pkt {3d}! -------> !
! ! ! ! ! pkt {3e}!
! ! ! ! ! <------- !
! ! ! ! <==(1)== ! pkt !
! ! ! <==(2)== ! pkt ! !
! ! <==(3)== ! pkt ! ! !
! <------ ! pkt ! ! ! !
! pkt ! ! ! ! !
: : : : : :
: : : : : :
The notation "==(N)==>" or "<==(N)==" indicates that the innermost packet has been encapsulated N times, using IP-IP, ESP, or MIP NAT traversal.
表記 "==（N）==>" または "<==（N）==" 最も内側のパケットがIP-IP、ESP、またはMIP NATトラバーサルを使用して、N回カプセル化されたことを示します。
Packets marked with {xx} are shown in more detail below. Each area represents a protocol header (labeled). Source and destination addresses or ports are shown underneath the protocol name when applicable. Note that there are no NAT traversal headers in the example packets.
{XX}でマークされたパケットは、以下でより詳細に示されています。各領域は、プロトコルヘッダ（ラベル）を表します。送信元および宛先アドレスやポートは、該当する場合、プロトコル名の下に示されています。例えば、パケットにはNATトラバーサルヘッダが存在しないことに注意してください。
Packet {1a}
.------------------------------------.
! IP ! IP ! UDP ! IKE !
! co-CoA ! x-HoA ! 500 ! !
! x-HA ! VPN-GW ! 500 ! !
`------------------------------------'
Packet {2a}
.--------------------------------------------------------.
! IP ! IP ! ESP ! IP ! UDP ! MIP RRQ !
! co-CoA ! x-HoA ! ! VPN-TIA ! ANY ! !
! x-HA ! VPN-GW ! ! i-HA ! 434 ! !
`--------------------------------------------------------'
Packet {2b}
.----------------------------------------------.
! IP ! ESP ! IP ! UDP ! MIP RRQ !
! x-HoA ! ! VPN-TIA ! ANY ! !
! VPN-GW ! ! i-HA ! 434 ! !
`----------------------------------------------'
Packet {2c}
.----------------------------.
! IP ! UDP ! MIP RRQ !
! VPN-TIA ! ANY ! !
! i-HA ! 434 ! !
`----------------------------'
Packet {3a}
.-------------------.
! IP ! user !
! i-HoA ! protocol !
! CN ! !
`-------------------'
Packet {3b}
.------------------------------------------------------- -
! IP ! IP ! ESP ! IP ! IP ! user \
! co-CoA ! x-HoA ! ! VPN-TIA ! i-HoA ! protocol../
! x-HA ! VPN-GW ! ! i-HA ! CN ! \
`------------------------------------------------------- -
- - -----------------.
\..user ! ESP !
/ protocol ! trailer !
\ ! !
- - -----------------'
Packet {3c}
.--------------------------------------------------------.
! IP ! ESP ! IP ! IP ! user ! ESP !
! x-HoA ! ! VPN-TIA ! i-HoA ! protocol ! trailer !
! VPN-GW ! ! i-HA ! CN ! ! !
`--------------------------------------------------------'
Packet {3d}
.------------------------------.
! IP ! IP ! user !
! VPN-TIA ! i-HoA ! protocol !
! i-HA ! CN ! !
`------------------------------'
Packet {3e}
.-------------------.
! IP ! user !
! i-HoA ! protocol !
! CN ! !
`-------------------'
Packet {3b} with all NAT traversal headers (x-MIP, ESP, and i-MIP) is shown below for comparison.
すべてのNATトラバーサルヘッダ（X-MIP、ESP、及びI-MIP）を有するパケット{3bは}比較のために以下に示されています。
Packet {3b} (with NAT traversal headers)
.------------------------------------------------- -
! IP ! UDP ! MIP ! IP ! UDP ! ESP.. \
! co-CoA ! ANY ! tunnel ! x-HoA ! 4500 ! /
! x-HA ! 434 ! data ! VPN-GW ! 4500 ! \
`------------------------------------------------- -
<=== external MIPv4 ====> <=== IPsec ESP ======== = =
- - ------------------------------------------------ -
\..ESP ! IP ! UDP ! MIP ! IP ! user \
/ ! VPN-TIA ! ANY ! tunnel ! i-HoA ! protocol../
\ ! i-HA ! 434 ! data ! CN ! \
- - ------------------------------------------------ -
= ===> <==== internal MIPv4 ====> <== user packet == =
- - -----------------.
\..user ! ESP !
/ protocol ! trailer !
\ ! !
- - -----------------'
= = ======> <= ESP =>
Authors' Addresses
著者のアドレス
Sami Vaarala Codebay P.O. Box 63 Espoo 02601 FINLAND
サミVaarala Codebayの私書箱ボックス63エスポー02601 FINLAND
Phone: +358 (0)50 5733 862 EMail: sami.vaarala@iki.fi
電話番号：+358（0）50 5733 862 Eメール：sami.vaarala@iki.fi
Espen Klovning Birdstep Bryggegata 7 Oslo 0250 NORWAY
エスペンKlovning BirdstepのBryggegata 7オスロ0250 NORWAY
Phone: +47 95 20 26 29 EMail: espen@birdstep.com
電話：+47 95 20 26 29 Eメール：espen@birdstep.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。