Network Working Group H. Levkowetz
Request for Comments: 3519 ipUnplugged
Category: Standards Track S. Vaarala
Netseal
April 2003
Mobile IP Traversal of Network Address Translation (NAT) Devices
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic.
モバイルIPデータグラムのトンネリングは、ネットワークアドレス変換（NAT）と互換性がありません。この文書では、モバイルIPプロトコルやNATデバイスによって公共のインターネットから分離されているプライベートアドレスネットワークで動作するように、モバイルIPを用いた移動ノードを許可するトンネリング方式への拡張を提供します。 NATトラバーサルは、カプセル化されたデータトラフィックのためのモバイルIPホームエージェントUDPポートを使用することに基づいています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problem description . . . . . . . . . . . . . . . . . . 3
1.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . 4
2. NAT Traversal Overview. . . . . . . . . . . . . . . . . . . . 5
2.1 Basic Message Sequence. . . . . . . . . . . . . . . . . 5
3. New Message Formats . . . . . . . . . . . . . . . . . . . . . 6
3.1 UDP Tunnel Request Extension. . . . . . . . . . . . . . 6
3.1.1 F (Force) Flag. . . . . . . . . . . . . . . . . . 7
3.1.2 R (Registration through FA Required) flag . . . . 8
3.1.3 Reserved Fields . . . . . . . . . . . . . . . . . 8
3.1.4 Encapsulation . . . . . . . . . . . . . . . . . . 8
3.1.5 Mobile IP Registration Bits . . . . . . . . . . . 9
3.2 UDP Tunnel Reply Extension. . . . . . . . . . . . . . . 9
3.2.1 Reply Code. . . . . . . . . . . . . . . . . . . . 10
3.3 MIP Tunnel Data Message . . . . . . . . . . . . . . . . 10
3.4 UDP Tunnelling Flag in Agent Advertisements . . . . . . 11
3.5 New Registration Reply Codes. . . . . . . . . . . . . . 12
4. Protocol Behaviour. . . . . . . . . . . . . . . . . . . . . . 12
4.1 Relation to standard MIP tunnelling . . . . . . . . . . 12
4.2 Encapsulating IP Headers in UDP . . . . . . . . . . . . 13
4.3 Decapsulation . . . . . . . . . . . . . . . . . . . . . 15
4.4 Mobile Node Considerations. . . . . . . . . . . . . . . 15
4.5 Foreign Agent Considerations. . . . . . . . . . . . . . 16
4.6 Home Agent Considerations . . . . . . . . . . . . . . . 18
4.6.1 Error Handling. . . . . . . . . . . . . . . . . . 19
4.7 MIP signalling versus tunnelling. . . . . . . . . . . . 20
4.8 Packet fragmentation. . . . . . . . . . . . . . . . . . 21
4.9 Tunnel Keepalive. . . . . . . . . . . . . . . . . . . . 21
4.10 Detecting and compensating for loss of NAT mapping. . . 22
4.11 Co-located registration through FA. . . . . . . . . . . 24
5. Implementation Issues . . . . . . . . . . . . . . . . . . . . 24
5.1 Movement Detection and Private Address Aliasing . . . . 24
5.2 Mobility Binding Lifetime . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6.1 Traffic Redirection Vulnerabilities . . . . . . . . . . 27
6.1.1 Manipulation of the Registration
Request Message . . . . . . . . . . . . . . . . . 27
6.1.2 Sending a Bogus Keepalive Message . . . . . . . . 27
6.2 Use of IPsec. . . . . . . . . . . . . . . . . . . . . . 28
6.3 Firewall Considerations . . . . . . . . . . . . . . . . 28
7. UNSAF Considerations. . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. Intellectual Property Rights. . . . . . . . . . . . . . . . . 30
10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 31
11. Normative References. . . . . . . . . . . . . . . . . . . . . 31
12. Informative References. . . . . . . . . . . . . . . . . . . . 32
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 33
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 34
The Mobile IP related terminology described in RFC 3344 [10] is used in this document. In addition, the following terms are used:
RFC 3344 [10]に記載のモバイルIPに関連する用語は、本書で使用されています。また、以下の用語が使用されます。
Forward Tunnel A tunnel that forwards packets towards the mobile node. It starts at the home agent, and ends at the mobile node's care-of address.
前方にトンネルモバイルノードに向けてパケットを転送するトンネル。これは、ホームエージェントで開始し、モバイルノードの気付アドレスで終了します。
Reverse Tunnel A tunnel that starts at the mobile node's care-of address and terminates at the home agent.
トンネルにモバイルノードの気付アドレスで始まり、ホームエージェントで終わるトンネルを逆にします。
NAT Network Address Translation. "Traditional NAT would allow hosts within a private network to transparently access hosts in the external network, in most cases. In a traditional NAT, sessions are uni-directional, outbound from the private network." -- RFC 2663 [11]. Basic NAT and NAPT are two varieties of NAT.
NATネットワークアドレス変換。 「従来のNATは、プライベートネットワーク内のホストは、ほとんどの場合、外部ネットワーク内のホストに透過的にアクセスできるようになる。伝統的なNATでは、セッションは、プライベートネットワークからのアウトバウンド単方向です。」 - RFC 2663 [11]。基本NATとNAPTは、NATの2種類です。
Basic NAT "With Basic NAT, a block of external addresses are set aside for translating addresses of hosts in a private domain as they originate sessions to the external domain. For packets outbound from the private network, the source IP address and related fields such as IP, TCP, UDP and ICMP header checksums are translated. For inbound packets, the destination IP address and the checksums as listed above are translated." -- RFC 2663 [11].
、外部アドレスのブロックは、彼らが外部ドメインへのセッションを発信などのプライベートドメイン内のホストのアドレスを変換するために脇に設定されている基本的なNATの基本的なNAT」。プライベートネットワークからのパケットの発信のために、送信元IPアドレスおよび関連分野などIP、TCP、UDP及びICMPヘッダチェックサムが翻訳される。着信パケットは、宛先IPアドレスとチェックサム上記のように翻訳されます。」 - RFC 2663 [11]。
NAPT Network Address Port Translation. "NAPT extends the notion of translation one step further by also translating transport identifier (e.g., TCP and UDP port numbers, ICMP query identifiers). This allows the transport identifiers of a number of private hosts to be multiplexed into the transport identifiers of a single external address. NAPT allows a set of hosts to share a single external address. Note that NAPT can be combined with Basic NAT so that a pool of external addresses are used in conjunction with port translation." -- RFC 2663 [11].
NAPTネットワークポート変換アドレス。 「NAPTは、これはプライベートホストの数のトランスポート識別子は、単一のトランスポート識別子に多重化することができます。また、トランスポート識別子（例えば、TCPやUDPのポート番号、ICMP問合せ識別子）を翻訳することにより、さらに一歩翻訳の概念を拡張します外部アドレス。NAPTは、ホストのセットは、単一の外部アドレスを共有することができます。外部アドレスのプールがポート変換と組み合わせて使用されるように、NAPTは、基本NATと組み合わせることができることに注意してください。」 - RFC 2663 [11]。
In this document, the more general term NAT is used to cover both NATs and NAPTs. In most deployment cases today, we believe that the NATs used are of the NAPT variety.
この文書では、より一般的な用語のNATはNATのとNAPTsの両方をカバーするために使用されます。ほとんどの展開例では、今日、我々は、使用するNATは、NAPT品種であると考えています。
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 [6].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[6]。
A basic assumption that Mobile IP [10] makes is that mobile nodes and foreign agents are uniquely identifiable by a globally routable IP address. This assumption breaks down when a mobile node attempts to communicate from behind a NAT.
モバイルIPは、[10]になり、基本的な仮定は、モバイルノードと外部エージェントは、グローバルにルーティング可能なIPアドレスによって一意に識別されていることです。この仮定は、モバイルノードがNATの背後から通信しようとしたときに分解します。
Mobile IP relies on sending traffic from the home network to the mobile node or foreign agent through IP-in-IP tunnelling. IP nodes which communicate from behind a NAT are reachable only through the NAT's public address(es). IP-in-IP tunnelling does not generally contain enough information to permit unique translation from the common public address(es) to the particular care-of address of a mobile node or foreign agent which resides behind the NAT; in particular there are no TCP/UDP port numbers available for a NAT to work with. For this reason, IP-in-IP tunnels cannot in general pass through a NAT, and Mobile IP will not work across a NAT.
モバイルIPは、IPインIPトンネルを介して、移動ノードまたは外部エージェントにホームネットワークからのトラフィックを送ることに頼っています。 NATの背後から通信するIPノードはNATのパブリックアドレス（複数可）を介して到達可能です。 IP内IPトンネリングは、一般的に共通の公開アドレス（複数可）から特定のケア - のNATの背後にあるモバイルノードまたは外部エージェントのアドレスに独自の翻訳を可能にするのに十分な情報が含まれていません。特にで動作するようにNATのために利用可能なTCP / UDPポート番号はありません。このため、IP内IPトンネルは、一般的なNATを通過し、モバイルIPにNAT越えては機能しませんすることはできません。
Mobile IP's Registration Request and Reply will on the other hand be able to pass through NATs and NAPTs on the mobile node or foreign agent side, as they are UDP datagrams originated from the inside of the NAT or NAPT. When passing out, they make the NAT set up an address/port mapping through which the Registration Reply will be able to pass in to the correct recipient. The current Mobile IP protocol does however not permit a registration where the mobile node's IP source address is not either the CoA, the Home Address, or 0.0.0.0.
モバイルIPの登録要求と応答は、他の一方で、彼らはUDPデータグラムがNATまたはNAPTの内側から発信されているように、モバイルノードまたは外国人のエージェント側でNATをしてNAPTsを通過することができるようになります。アウト渡すとき、彼らはNATが登録応答が正しい受信者に渡すことができるようになり、それを通してアドレス/ポートマッピングを設定します。現在のモバイルIPプロトコルは、しかし、移動ノードのIP送信元アドレスはCoAを、ホームアドレス、または0.0.0.0のいずれかではありません登録を許可していません。
What is needed is an alternative data tunnelling mechanism for Mobile IP which will provide the means needed for NAT devices to do unique mappings so that address translation will work, and a registration mechanism which will permit such an alternative tunnelling mechanism to be set up when appropriate.
必要なものは、アドレス変換が動作するように独自のマッピングを行うにはNATデバイスのために必要な手段を提供するモバイルIPのための代替データトンネリングメカニズム、および適切な場合に設定されるように、このような代替トンネリングメカニズムを可能にする登録メカニズムであります。
This mechanism will address 3 different scenarios:
このメカニズムは、3の異なるシナリオに対処します：
- A mobile node with co-located address behind a NAT; no FA
- NATの背後にある同一位置のアドレスを有するモバイルノード。無FA
- A mobile node registered with an FA where both the mobile node and the FA are behind the same NAT
- モバイルノードとFAの両方が同じNATの背後にあるFAに登録され、モバイルノード
- A mobile node with co-located address using an FA which demands that registrations pass through the FA (sets the "R" bit) where both the mobile node and the FA are behind the same NAT
- 登録は、モバイルノードとFAの両方が同じNATの背後にあるFA（「R」ビットをセットする）を通過することを要求FAを用いて同一位置アドレスを有するモバイルノード
The primary assumption in this document is that the network allows communication between an UDP port chosen by the mobile node and the home agent UDP port 434. If this assumption does not hold, neither Mobile IP registration nor data tunnelling will work.
この文書の主な仮定は、ネットワークは、この仮定が成立しない場合は、モバイルノードとホームエージェントUDPポート434が選択したUDPポート間の通信を可能にする、モバイルIP登録やデータトンネリングどちらも動作するということです。
This document does NOT assume that mobility is constrained to a common IP address space. On the contrary, the routing fabric between the mobile node and the home agent may be partitioned into a
この文書では、移動度は、共通のIPアドレス空間に制約されていることを前提としていません。逆に、モバイルノードとホームエージェントとの間のルーティングファブリックは、に分割することができます
"private" and a "public" network, and the assumption is that some mechanism is needed in addition to vanilla Mobile IP according to RFC 3344 [10] in order to achieve mobility within disparate IP address spaces.
「プライベート」と「パブリック」ネットワーク、および仮定は、異なるIPアドレス空間内の移動度を達成するために、RFC 3344 [10]によると、いくつかのメカニズムは、バニラ、モバイルIPに加えて必要とされることです。
For a more extensive discussion of the problems with disparate address spaces, and how they may be solved, see RFC 3024 [9].
より広範な異なるアドレス空間の問題の議論、およびそれらがどのように解決することができるため、RFC 3024 [9]を参照してください。
The reverse tunnels considered here are symmetric, that is, they use the same configuration (encapsulation method, IP address endpoints) as the forward tunnel.
ここで考慮逆方向トンネルは、それらが前方にトンネルと同様の構成（カプセル化方式、IPアドレスのエンドポイント）を使用し、すなわち、対称です。
This section gives a brief overview of the MIP UDP tunnelling mechanism which may be used to achieve NAT traversal for Mobile IP.
このセクションでは、モバイルIPのためのNATトラバーサルを達成するために使用することができるMIP UDPトンネル機構の概要を示します。
In MIP UDP tunnelling, the mobile node may use an extension (described below) in its Registration Request to indicate that it is able to use Mobile IP UDP tunnelling instead of standard Mobile IP tunnelling if the home agent sees that the Registration Request seems to have passed through a NAT. The home agent may then send a registration reply with an extension indicating acceptance (or denial). After assent from the home agent, MIP UDP tunnelling will be available for use for both forward and reverse tunnelling. UDP tunnelled packets sent by the mobile node use the same ports as the registration request message. In particular, the source port may vary between new registrations, but remains the same for all tunnelled data and re-registrations. The destination port is always 434. UDP tunnelled packets sent by the home agent uses the same ports, but in reverse.
MIP UDPトンネルでは、モバイルノードは、ホームエージェントは登録要求を持っているように見えることを見れば、モバイルIP、UDPトンネリングの代わりに、標準のモバイルIPトンネルを使用することが可能であることを示すために、その登録要求に（後述）の拡張子を使用することができますNATを通過しました。ホームエージェントは、受諾（または拒否）を示す拡張子が登録応答を送信することができます。ホームエージェントからの同意後、MIP UDPトンネリングは、両方のフォワードおよびリバーストンネリングのために使用できるようになります。 UDPは、登録要求メッセージと同じポートを使用するモバイルノードによって送信されたパケットをトンネリング。具体的には、送信元ポートが新規登録の間で変化してもよいが、同じことが、すべてのトンネルデータと再登録のために残っています。宛先ポートはUDPが同じポートを使用するホームエージェントによって送信されたパケットをトンネルさが、逆に、常に434です。
The message sequence diagram below exemplifies setting up and using a Mobile IP UDP tunnel as described in this document. The tunnel is set up by the use of specific extensions in the initial Mobile IP Registration Request and Reply exchange. Thereafter, any traffic from the home agent to the mobile node is sent through the UDP tunnel. The mobile node may at its discretion use the UDP tunnel for reverse tunnelling or not, although in most cases where MIP UDP tunnelling is needed, reverse tunnelling will also be needed.
メッセージ・シーケンス図は、以下の設定と、この文書に記載されているように、モバイルIP UDPトンネルを使用して例示します。トンネルは最初のモバイルIP登録要求と応答の交換で特定の拡張子を使用して設定されています。その後、移動ノードにホームエージェントからのすべてのトラフィックはUDPトンネルを経由して送信されます。モバイルノードMIP UDPトンネルが必要とされるほとんどの場合、トンネリングを逆が、その裁量で、リバーストンネリングかのためにUDPトンネルを使用することができるにも必要となります。
mobile node NAT home agent
| | |
| | |
| Registration | |
| Request with | |
|-----------------///--------------->>|
|UDP Tunnel Request| |
| | +
| | || IP Source and
| | || CCoA address
| | || discrepancy
| | || seen
| | Registration +
| | Reply with |
|<<---------------///-----------------|
| | UDP Tunnel Reply.|
| | |
| UDP tunnelled pkg| |
|=================///===============>>|
| | UDP tunnelled pkg|
|<<===============///=================|
| | ||absence of
| | ||traffic for
| | ||UDP keepalive
| UDP keepalive | ||period
|-----------------///--------------->>+
. . +
. . .
. . .
This extension is a skippable extension. It signifies that the sender is capable of handling MIP UDP tunnelling, and optionally that a particular encapsulation format is requested in the MIP UDP tunnel. The format of this extension is as shown below. It adheres to the short extension format described in [10].
この拡張はスキップ可能な拡張機能です。これは、送信者が特定のカプセル化フォーマットはMIP UDPトンネル内で要求されたMIP UDPトンネルを処理すること、及び任意であることを意味します。この拡張のフォーマットは以下のように示されています。これは、[10]に記載のショート拡張フォーマットに準拠します。
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 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|R| Reserved 2| Encapsulation | Reserved 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ|サブタイプ|予約1 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | F | R |予約2 |カプセル化|予約3 | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Type 144
タイプ144
Length 6. Length in bytes of this extension, not including the Type and Length bytes.
タイプと長さバイトを含まないこの拡張のバイト単位の長さ6の長さ、。
Sub-Type 0
サブタイプ0
Reserved 1 Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception.
将来の使用のために1予約を予約。送信時に0に設定しなければならなくて、レセプションで無視しなければなりません。
F F (Force) flag. Indicates that the mobile node wants to force MIP UDP tunnelling to be established.
F F（強制）フラグ。モバイルノードが確立されるMIP UDPトンネルを強制的に望んでいることを示します。
R R (Registration through FA Required) flag. Indicates that the R bit was set in the FA's Agent Advertisement. Registration is being made using a co-located care-of address, but through the FA.
R R（FA必須を通して登録）フラグ。 RビットがFAのエージェント広告に設定されたことを示します。登録は同じ場所に配置さ気付アドレスを使用して作られたが、FA通じています。
Reserved 2 Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception.
将来の使用のために2予約を予約。送信時に0に設定しなければならなくて、レセプションで無視しなければなりません。
Encapsulation Indicates the type of tunnelled data, using the same numbering as the IP Header Protocol Field.
カプセル化は、IPヘッダーのプロトコルフィールドと同じ番号を使用して、トンネルされるデータの種類を示します。
Reserved 3 Reserved for future use. MUST be set to 0 on sending, MUST be verified as 0 on receipt; otherwise the extension must be handled as not understood and silently skipped.
将来の使用のために3予約を予約。 、送信時に0に設定しなければなら領収書に0として検証する必要があります。そうでなければ拡張は理解されていないとして扱われ、静かにスキップしなければなりません。
Indicates that the mobile node wants to use traversal regardless of the outcome of NAT detection performed by the home agent. This is useful if the route between the mobile node and the home agent works for Mobile IP signalling packets, but not for generic data packets (e.g., because of firewall filtering rules). If the home agent supports this protocol, it SHOULD either accept the traversal and reply with a UDP Tunnel Reply Extension or reject the Registration Request. In case of the registration failing, the Home Agent SHOULD send a Registration Reply with Code field set to 129 ("administratively prohibited").
モバイルノードがホームエージェントによって実行されるNAT検出の結果にかかわらずトラバーサルを使用したいことを示します。これは、（なぜならファイアウォールフィルタリング規則の例えば、）一般的なデータパケットをモバイルノードとホームエージェントとの間の経路は、モバイルIPシグナリングパケットに対して動作する場合に有用である、ではありません。ホームエージェントは、このプロトコルをサポートしている場合、それはトラバーサルを受け入れ、UDPトンネルで応答すべきであるいずれかの拡張子を返信または登録要求を拒否します。失敗登録の場合には、ホームエージェントは、（「管理上禁止」）129へのコードのフィールドを設定した登録応答を送るべきです。
If the HA does not understand the UDP Tunnel Request Extension, it will silently discard it, and if everything else is fine, it will reply with a registration reply with reply code 0 (registration accepted), but without any UDP Tunnel Reply Extension. In this case, the mobile node MUST NOT use MIP UDP tunnelling.
HAは、UDPトンネル要求拡張を理解していない場合、それは静かにそれを破棄し、そして他のすべてが罰金であれば、それは回答コード0（登録受理）に登録応答を返信させていただきますが、任意のUDPトンネルせずに拡張を返信します。この場合、移動ノードはMIP UDPトンネルを使用してはなりません。
This flag MUST be set by the mobile node when it is using a co-located address, but registering through an FA because it has received an Agent Advertisement with the 'R' bit set.
それは同じ場所に配置アドレスを使用して、それは「R」ビットを設定して、エージェント広告を受信しているため、FAを介して登録されている場合、このフラグは、移動ノードによって設定されなければなりません。
The 'Reserved 1' and 'Reserved 2' fields must be ignored on receipt, while the 'Reserved 3' field must be 0 on receipt, otherwise this extension MUST be handled as not understood and silently skipped. This permits future additions to this extension to be made which either can co-exist with old implementations, or will force a rejection of the extension from an old implementation.
「予約済み3」フィールドは、領収書に0にする必要がありながら、「予約1」と「予約2」フィールドが理解さサイレントスキップされないようにそうでなければこの拡張を処理する必要があり、受信時には無視されなければなりません。これは、どちらかが古い実装と共存することができ、または古い実装から延長の拒否を強制的に行われるために、この拡張機能に将来の追加が可能になります。
The 'Encapsulation' field defines the mode of encapsulation requested if MIP UDP tunnelling is accepted by the home agent. This field uses the same values as the IP header Protocol field:
MIP UDPトンネルがホームエージェントによって受け入れられた場合は、「カプセル化」フィールドは、要求されたカプセル化のモードを定義します。このフィールドは、IPヘッダのプロトコルフィールドと同じ値を使用します。
4 IP header (IP-in-UDP tunnelling) RFC 2003 [4]
4 IPヘッダ（IPインUDPトンネリング）RFC 2003 [4]
47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]
47 GREヘッダ（GRE型UDPトンネリング）RFC 2784 [8]
55 Minimal IP encapsulation header RFC 2004 [5]
55最小IPカプセル化ヘッダRFC 2004 [5]
If the home agent finds that UDP tunnelling is not needed, the encapsulation will be determined by the 'M' and 'G' flags of the registration request; but if the home agent finds that MIP UDP tunnelling should be done, the encapsulation is determined from the value of the Encapsulation field. If the value of this field is zero, it defaults to the value of 'M' and 'G' fields in the Registration Request message, but if it is non-zero, it indicates that a particular encapsulation is desired.
ホームエージェントは、UDPトンネリングが必要とされていないことが判明した場合、カプセル化は、「M」と登録要求の「G」のフラグによって決定されます。ホームエージェントはMIP UDPトンネリングが行われるべきであることを見つけた場合は、カプセル化は、カプセル化フィールドの値から決定されます。このフィールドの値がゼロである場合に「M」の値は、デフォルト値と登録要求メッセージに「G」フィールドが、それが非ゼロである場合、それは特定のカプセル化が望まれていることを示しています。
The Mobile IP registration bits S, B, D, M, G and T retain their meaning as described in RFC 3344 [10] and RFC 3024 [9] (except that the significance of the M and G bits may be modified by the Encapsulation field when MIP UDP tunnelling is used, as described above). The use of the M and G bits together with MIP UDP tunnelling is also touched upon in Section 4.1.
モバイルIP登録ビットS、B、D、RFC 3344に記載されているように、M、GおよびTは、それらの意味を保持している[10]およびRFC 3024 [9]（MおよびGビットの重要性は、カプセル化によって修飾することができることを除い上述したようにMIP UDPトンネルが使用されるフィールド）。 MIPのUDPトンネルと共にMおよびGビットの使用はまた、4.1節で触れています。
When the MN requests MIP UDP tunnelling, the 'D' bit (Decapsulation by the mobile node) MUST be set, otherwise UDP tunnelling would not be meaningful.
MNはMIP UDPトンネリングを要求すると、「D」ビット（モバイルノードによって脱カプセル化）は、そうでなければUDPトンネリングは意味がない、設定しなければなりません。
Both the MN and the FA SHOULD set the 'T' bit when requesting MIP UDP tunnelling, even if not all traffic will be reverse tunnelled. This ensures that a HA which is not prepared to accept reverse tunnelling will not accept a registration which may later turn out to be unusable. Also see the discussion of use of the 'T' bit in Foreign Agent Considerations (Section 4.5).
MIPのUDPトンネリングを要求する際にMNとFAの両方がいないすべてのトラフィックは、逆トンネル化された場合でも、「T」ビットを設定する必要があります。これは、リバーストンネリングを受け入れるように準備されていないHAは、後に使用不可能になるかもしれない登録を受け付けないことを保証します。また、外国エージェント問題（4.5節）で「T」ビットの使用の説明を参照してください。
This extension is a non-skippable extension. It is sent in reply to a UDP Tunnel Request extension, and indicates whether or not the HA will use MIP UDP tunnelling for the current mobility binding. The format of this extension is as shown below.
この拡張は、非スキップ可能な拡張機能です。これは、UDPトンネル要求拡張への応答で送信され、HAは、結合現在のモビリティのためのMIP UDPトンネルを使用するかどうかを示しています。この拡張のフォーマットは以下のように示されています。
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 | Reply Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Reserved | Keepalive Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ|サブタイプ|コードを返信| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | F |予約|キープアライブ間隔| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Type 44
タイプ44
Length 6. Length in bytes of this extension, not including the Type and Length bytes.
タイプと長さバイトを含まないこの拡張のバイト単位の長さ6の長さ、。
Sub-Type 0
サブタイプ0
Reply Code Indicates whether the HA assents or declines to use UDP tunnelling for the current mobility binding. See Section 3.2.1 below.
コードは、HAのassentsまたは減少が結合現在のモビリティのためのUDPトンネリングを使用するかどうかを示し返信。以下のセクション3.2.1を参照してください。
F F (Forced) flag. Indicates that tunnelling is being forced because the F flag was set in the tunnelling request, irrespective of the detection of a NAT or not.
F F（強制）フラグ。かかわらず、NATの検出の有無、Fフラグはトンネリング要求に設定されたため、トンネルが強制されていることを示します。
Keepalive Interval Specifies the NAT keepalive interval that the mobile node SHOULD use. A keepalive packet SHOULD be sent if Keepalive Interval seconds have elapsed without any signalling or data traffic being sent. If this field is set to 0, the mobile node MUST use its default configured keepalive interval.
キープアライブ間隔は、モバイルノードが使用するNATキープアライブ間隔を指定します。キープアライブ間隔の秒が任意のシグナリングまたはデータトラフィックが送信されずに経過した場合は、キープアライブパケットを送ってください。このフィールドが0に設定されている場合、モバイルノードは、デフォルト設定されたキープアライブ間隔を使用しなければなりません。
Reserved Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception.
予約済み将来の使用のために予約されています。送信時に0に設定しなければならなくて、レセプションで無視しなければなりません。
The Reply Code field of the UDP Tunnel Reply Extension indicates if UDP tunnelling have been accepted and will be used by the HA. Values in the range 0 .. 63 indicate assent, i.e., that tunnelling will be done, while values in the range 64 .. 255 indicate that tunnelling should not be done. More information may be given by the value of the response code.
UDPトンネルの応答コードフィールドは、UDPトンネリングが受け入れられているとHAによって使用される場合には延長が示す返信。範囲64の値.. 255がトンネリングが行われるべきでないことを示しながら、範囲0の値は.. 63は同意を示し、すなわち、そのトンネルは、行われます。詳細には、応答コードの値によって与えられてもよいです。
The following response codes are defined for use in the code field of the UDP Tunnel Reply Extension:
次の応答コードは、UDPトンネル返信拡張のコードフィールドでの使用のために定義されています。
0 Will do tunnelling
0は、トンネリングを行います
64 Tunnelling declined, reason unspecified
64トンネリングは、不特定の理由を辞退しました
This MIP message header serves to differentiate traffic tunnelled through the well-known port 434 from other Mobile IP messages, e.g., Registration Requests and Registration Replies.
このMIPメッセージヘッダは、他のモバイルIPメッセージ、例えば、登録要求および登録応答からwell-knownポート434を介してトンネリングトラフィックを区別するのに役立ちます。
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 | Next Header | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 4
タイプ4
Next Header Indicates the type of tunnelled data, using the same numbering as the IP Header Protocol Field.
次ヘッダは、IPヘッダのプロトコルフィールドと同じ番号を使用して、トンネルデータのタイプを示します。
Reserved Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception.
予約済み将来の使用のために予約されています。送信時に0に設定しなければならなくて、レセプションで無視しなければなりません。
The Next Header field uses the same values as the IP header Protocol field. Immediately relevant for use with Mobile IP are the following values:
次ヘッダフィールドは、IPヘッダのプロトコルフィールドと同じ値を使用します。モバイルIPで使用するためにすぐに関連するには、以下の値は次のとおりです。
4 IP header (IP-in-UDP tunnelling) RFC 2003 [4]
4 IPヘッダ（IPインUDPトンネリング）RFC 2003 [4]
47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]
47 GREヘッダ（GRE型UDPトンネリング）RFC 2784 [8]
55 Minimal IP encapsulation header RFC 2004 [5]
55最小IPカプセル化ヘッダRFC 2004 [5]
The receiver of a tunnelled packet MUST check that the Next Header value matches the tunnelling mode established for the mobility binding with which the packet was sent. If a discrepancy is detected, the packet MUST be dropped. A log entry MAY be written, but in this case the receiver SHOULD ensure that the amount of log entries written is not excessive.
トンネルパケットの受信機は、次ヘッダ値は、パケットが送信されたとの結合モビリティのために確立されたトンネリングモードと一致することをチェックしなければなりません。不一致が検出された場合、パケットは廃棄されなければなりません。ログエントリが書き込まれてもよいが、この場合、受信機は、書き込まれたログエントリの量が過剰でないことを保証すべきです。
In addition to the encapsulation forms listed above, the MIP UDP tunnelling can potentially support other encapsulations, by use of the Next Header field in the MIP Tunnel Data Header and the Encapsulation Header field of the UDP Tunnel Request Extension (Section 3.1).
上記カプセル化形態に加えて、MIP UDPトンネルは、潜在的にMIPトンネルデータヘッダ及びUDPトンネル要求拡張（セクション3.1）のカプセル化ヘッダフィールドの次ヘッダフィールドを使用することにより、他のカプセル化をサポートすることができます。
The only change to the Mobility Agent Advertisement Extension defined in RFC 3344 [10] is a flag indicating that the foreign agent generating the Agent Advertisement supports MIP UDP Tunnelling. The flag is inserted after the flags defined in [10].
[10] RFC 3344で定義されたモビリティエージェント広告拡張にのみ変更はエージェント広告を生成する外部エージェントは、MIP UDPトンネリングをサポートしていることを示すフラグです。フラグは[10]で定義されたフラグの後に挿入されます。
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 | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime |R|B|H|F|M|G|r|T|U| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero or more Care-of Addresses | | ... |
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ|シーケンス番号| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |寿命| R | B | H | F | M | G | R | T | U |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ゼロ個以上の気付アドレス| | ... |
The flag is defined as follows:
次のようにフラグが定義されます。
U UDP Tunnelling support. This Agent supports MIP UDP Tunnelling as specified in this document. This flag SHOULD be set in advertisements sent by a foreign agent which supports MIP UDP tunnelling and is situated behind a NAT. It MUST NOT be set in advertisements from foreign agents which are not situated behind a NAT, and thus has no need to advertise the capability.
U UDPトンネリングをサポート。このエージェントは、この文書で指定されているMIP UDPトンネリングをサポートしています。このフラグは、MIP UDPトンネリングをサポートし、NATの後ろに位置している外国人のエージェントによって送られた広告に設定する必要があります。それは、NATの後ろに位置し、したがって機能をアドバタイズする必要がないされていない外国人のエージェントからの広告に設定してはいけません。
One new registration reply code is defined:
一つの新しい登録応答コードが定義されています。
ERROR_HA_UDP_ENCAP_UNAVAIL Requested UDP tunnel encapsulation unavailable
使用できないERROR_HA_UDP_ENCAP_UNAVAIL要求されたUDPトンネルカプセル化
This is used by the HA to distinguish the registration denial caused by an unavailable UDP tunnel encapsulation mode from a denial caused by unavailable standard tunnel encapsulation requested by use of the 'T' bit together with either 'M' or 'G' bit.
これは、いずれかの「M」または「G」ビットと一緒に「T」ビットを使用することによって要求された利用不可能標準トンネルカプセル化によって引き起こされる妨害から利用できないUDPトンネルカプセル化モードによって引き起こさ登録拒否を区別するために、HAによって使用されています。
The default encapsulation mode for MIP UDP tunnelling is IP-in-UDP encapsulation. The mobile node MAY request alternative forms of encapsulation to be used with UDP tunnelling by setting the 'M' bit and/or the 'G' bit of a Mobile IP registration request, or by explicitly requesting a particular encapsulation for the MIP UDP tunnel by using the Encapsulation field. The M and G bits retain the meaning as described in RFC 3344 [10] within the context of MIP UDP tunnelling. The UDP tunnelling version of the classic MIP encapsulation methods can be summarised as:
MIP UDPトンネリングのデフォルトのカプセル化モードは、IP-で-UDPカプセル化したものです。モバイルノードは、「M」ビット、および/またはモバイルIP登録要求の「G」ビットを設定することにより、または明示によりMIP UDPトンネルの特定のカプセル化を要求することにより、UDPトンネリングで使用するカプセル化の別の形態を要求することができますカプセル化フィールドを使用して。 MIP UDPトンネルのコンテキスト内RFC 3344 [10]に記載のようにMおよびGビットが意味を保持します。古典的なMIPカプセル化法のUDPトンネリングバージョンは次のように要約することができます。
IP in UDP. When Mobile IP UDP tunnelling is used, this is the default encapsulation type. Any home agent and mobile node that implements Mobile IP UDP tunnelling MUST implement this encapsulation type.
UDPでIP。モバイルIP、UDPトンネリングを使用する場合、これがデフォルトのカプセル化タイプです。モバイルIP UDPトンネリングを実装するすべてのホームエージェントと、モバイルノードは、このカプセル化タイプを実装しなければなりません。
GRE in UDP. If the 'G' bit is set in a registration request and the Encapsulation field is zero, the mobile node requests that its home agent use GRE encapsulation [3] for datagrams tunnelled to the mobile node. If MIP UDP tunnelling is also requested and accepted, GRE-in-UDP encapsulation SHALL be used in the same cases as GRE in IP encapsulation would be used if the MIP UDP tunnelling had not been requested.
UDPでGRE。 「G」ビットは登録要求とカプセル化フィールドに設定されている場合、そのホームエージェントがモバイルノードにトンネリングされたデータグラムのための[3] GREカプセル化を使用するモバイルノード要求、ゼロです。 MIP UDPトンネルも要求し、受理された場合、GRE・イン・UDPカプセル化は、IPカプセル化でGREと同じ例で使用しなければならないMIP UDPトンネルが要求されていない場合に使用されます。
Minimal encapsulation in UDP. If the 'M' bit is set and the Encapsulation field is zero, the mobile node requests that its home agent use minimal encapsulation [5] for datagrams tunnelled to the mobile node. If MIP UDP tunnelling is also used, minimal encapsulation in UDP SHALL be used in the same cases as minimal encapsulation according to RFC 2004 [5] would be used if the MIP UDP tunnelling had not been requested.
UDPでの最小限のカプセル化。 「M」ビットがセットされ、カプセル化フィールドは、そのホームエージェントは、モバイルノードにトンネリングされたデータグラムのための[5]最小限のカプセル化を使用するモバイルノードの要求がゼロであるされている場合。 MIP UDPトンネリングも使用されている場合、UDPでの最小限のカプセル化は、RFC 2004によると、最小限のカプセル化と同じ例で使用しなければならないMIP UDPトンネルが要求されていない場合は、[5]に使用されます。
When the Encapsulation field is non-zero, a particular encapsulation format is requested for the MIP UDP tunnel. If tunnelling is indicated, the request MUST either be accepted using the requested encapsulation, or rejected with the error code ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation unavailable" defined in Section 3.5. On receipt of this error, the mobile node MAY choose to send a new Registration Request with different requirements on MIP UDP tunnelling encapsulation.
カプセル化フィールドが非ゼロである場合、特定のカプセル化フォーマットは、MIP UDPトンネルのために要求されます。トンネリングが示された場合、要求は、要求されたカプセル化を使用して、受け入れられた、またはエラーコードERROR_HA_UDP_ENCAP_UNAVAILで拒否されなければならないのいずれかで、セクション3.5で定義される「UDPトンネルカプセル化が使用不可要求します」。このエラーを受信すると、モバイルノードは、MIP UDPトンネルカプセル化に異なる要件を持つ新しい登録リクエストを送信することを選択するかもしれません。
MIP IP-in-UDP tunnelling, or UDP tunnelling for short, is done in a manner analogous to that described for IP-in-IP tunnelling in RFC 2003 [4], with the exception of the addition of an UDP header [1] and MIP Message header [10] between the outer and inner IP header.
MIP IPインUDPトンネリング、略してUDPトンネリングは、[1] UDPヘッダの付加を除いて、[4] RFC 2003でIPインIPトンネルについて記載のものと同様の方法で行われます外側と内側のIPヘッダとの間及びMIPメッセージヘッダ[10]。
Mobile IP Registration Requests and Registration Replies are already in the form of UDP messages, and SHALL NOT be tunnelled even when MIP IP-in-UDP tunnelling is in force.
モバイルIP登録要求及び登録応答がUDPメッセージの形式に既にある、とMIP IP-で-UDPトンネリングが力にある場合でも、トンネル化されないものとします。
To encapsulate an IP datagram using MIP IP-in-UDP encapsulation, an outer IP header [2], UDP header [1] and MIP Message header [10] is inserted before the datagram's existing IP header, as follows:
MIP IP-に-UDPカプセル化、外側のIPヘッダ[2]、UDPヘッダを使用してIPデータグラムをカプセル化するために[1]、MIPメッセージヘッダ[10]以下のように、データグラムの既存のIPヘッダの前に挿入されます。
+---------------------------+
| |
| Outer IP Header |
+---------------------------+
| |
| UDP Header |
+---------------------------+
| MIP Tunnel Data |
| Message Header |
+---------------------------+ +---------------------------+
| | | |
| IP Header | | IP Header |
+---------------------------+ ====> +---------------------------+
| | | |
| IP Payload | | IP Payload |
| | | |
| | | |
+---------------------------+ +---------------------------+
The outer IP header Source Address and Destination Address, together with the UDP header Source Port and Destination Port, identify the "endpoints" of the tunnel. The inner IP header Source Address and Destination Addresses identify the original sender and the recipient of the datagram, respectively. The inner IP header is not changed by the encapsulator, except to decrement the TTL by one if the tunnelling is being done as part of forwarding the datagram as noted in RFC 2003 [4], and remains unchanged during its delivery to the tunnel exit point. No change to IP options in the inner header occurs during delivery of the encapsulated datagram through the tunnel. Note that the security options of the inner IP header MAY affect the choice of security options for the encapsulating (outer) IP header.
外側IPヘッダの送信元アドレスと宛先アドレス、一緒にUDPヘッダ送信元ポートと宛先ポートと、トンネルの「エンドポイント」を識別する。内側のIPヘッダの送信元アドレスおよび宛先アドレスは、それぞれ、元の送信者と、データグラムの受信者を識別する。一つTTLをデクリメントする以外は、RFC 2003で述べたように、トンネリングは、データグラムの転送の一部として実行されている場合、内側IPヘッダは、カプセル化によって変更されていない[4]、及びトンネル出口ポイントへのその送達中に変化しないままで。内部ヘッダ内のIPオプションの変更は、トンネルを介してカプセル化されたデータグラムの配信中に発生しません。内側のIPヘッダのセキュリティオプションは、カプセル化（外側）IPヘッダのセキュリティオプションの選択に影響を与える可能性があることに注意してください。
Minimal Encapsulation and GRE encapsulation is done in an analogous manner, following RFC 2004 [5] for Minimal Encapsulation and RFC 2784 [8] for GRE Encapsulation, but using outer IP, UDP and MIP headers in place of the outer IP header.
最小のカプセル化とGREカプセル化は[5] [8] GREカプセル化のために最小のカプセル化、およびRFC 2784は、RFC 2004、以下、同様の方法で行ったが、外側IPヘッダの代わりに外側のIP、UDP及びMIPヘッダを使用しています。
All other provisions and requirements of RFC 2003 [4] and RFC 3024 [9] are in force, except in one respect, as covered in Packet Fragmentation (Section 4.8).
他のすべての条項及びRFC 2003の要件[4]及びRFC 3024 [9]パケットフラグメンテーション（セクション4.8）で覆われたように、一つの点を除いて、力です。
Before decapsulation is actually done, the decapsulating node MUST verify that the outer IP addresses and UDP port numbers exactly match the values used for the tunnel, with the exception of tunnels that are "half bound" (as described in Section 4.11) where the source UDP port can change.
デカプセル化が実際に行われる前に、デカプセルノードがどこソース外部IPアドレス及びUDPポート番号が正確に（セクション4.11に記載のように）「半結合」されているトンネルを除いて、トンネルに使用される値と一致することを確認しなければなりませんUDPポートを変更することができます。
IP-in-UDP encapsulated traffic is decapsulated simply by stripping off the outer IP, UDP and MIP header, which leaves the original IP packet which is forwarded as is.
IPインUDPトラフィックがあるように転送され、元のIPパケットを離れる外側IP、UDP及びMIPヘッダを剥ぎ取ることによって簡単にデカプセル化されカプセル化されました。
Minimal IP encapsulation is processed by the receiver conceptually as follows. First, the UDP and the Mobile IP headers are removed from the packet, and the Protocol field of the IP header replaced with the Next Header field in the MIP Tunnel Data header. Second, the remaining IP header total length and checksum are adjusted to match the stripped packet. Third, ordinary minimal IP encapsulation processing is done.
次のように最小限のIPカプセル化は概念的に受信機によって処理されます。まず、UDP及びモバイルIPヘッダをパケットから取り出し、IPヘッダのプロトコルフィールドは、MIPトンネルデータヘッダ内の次ヘッダフィールドで置き換えられます。第二に、残りのIPヘッダの合計長さとチェックサムが剥離パケットに一致するように調整されます。第三に、通常の最小限のIPカプセル化処理が行われます。
GRE encapsulated traffic is processed according to RFC 2784 [8] and RFC 1701 [3], with the delivery header consisting of the outer IP, UDP and MIP headers.
GREは、トラフィックがRFC 2784に従って処理されたカプセル化された[8]およびRFC 1701 [3]は、外側のIP、UDP及びMIPヘッダからなる配信ヘッダを有します。
The UDP Tunnel Request Extension MAY be used in a Mobile IP Registration Request from the mobile node to the home agent when the mobile node uses a co-located care-of address. It SHALL NOT be used by the mobile node when it is registering with a foreign agent care-of address.
モバイルノードが同じ場所に配置さ気付アドレスを使用する場合にUDPトンネルリクエスト拡張は、ホームエージェントにモバイルノードからモバイルIP登録要求に使用されるかもしれません。それは外国人のエージェントの気付アドレスの登録をされている場合には、移動ノードで使用してはなりません。
The purpose of this extension is to indicate to the home agent that the mobile node is able to accept MIP UDP tunnelling if the home agent has an indication that the mobile node resides behind a NAT or NAPT. It thus functions as a conditional solicitation for the use of MIP UDP tunnelling.
この拡張の目的は、モバイルノードがホームエージェントは、モバイルノードがNATまたはNAPTの背後にある旨の表示がある場合MIP UDPトンネルを受け入れることができるホームエージェントに示すことです。これはMIP UDPトンネルを使用するための条件勧誘として機能します。
As per Section 3.2 and 3.6.1.3 of RFC 3344 [10], the mobile node MUST place this Extension before the Mobile-Home Authentication Extension in registration messages, so that it is covered by the Mobile-Home Authentication Extension.
3.2節およびRFC 3344の3.6.1.3あたりとして、[10]それはモバイル・ホーム認証拡張によって覆われるように、モバイルノードは、登録メッセージでのモバイル・ホーム認証拡張する前に、この拡張を置かなければなりません。
If the mobile node includes the UDP Tunnel Request extension in a registration request, but receives a registration reply without a UDP Tunnel Reply extension, it MUST assume that the HA does not understand this extension, and it MUST NOT use UDP tunnelling. If the mobile node is in fact behind a NAT, the registration may then succeed, but traffic will not be able to traverse the NAT.
モバイルノードが登録要求でUDPトンネル要求拡張が含まれていますが、UDPトンネル返信延長せずに登録応答を受信した場合には、HAは、この拡張を理解しないと仮定しなければなりません、そして、それはUDPトンネリングを使用してはなりません。モバイルノードがNATの背後にある事実にある場合は、登録はその後、成功する可能性がありますが、トラフィックがNATを通過することはできません。
When the mobile node sends MIP UDP tunnelled data, it MUST use the same UDP source port as was used for the most recent registration request.
モバイルノードは、MIP UDPがデータをトンネリングし送信すると、最新の登録要求のために使用されたとして、それは同じUDPソースポートを使用しなければなりません。
When the mobile node re-registers without having moved, it SHOULD take care to use the same source port as was used for the original registration of the current mobility binding. Otherwise, while the home agent would change destination port on acceptance of the new registration, and the mobile node would presumably start listening on the new port, the packets in flight from the home agent at the time of change will be dropped when arriving at the mobile node's old port. (This does not mean that the home agent should refuse a registration request using MIP UDP tunnelling where a new port have been used, as this might be the result of the NAT dropping state, the mobile node re-booting, changing interface, etc.)
せずにモバイルノード再登録が移動した場合、それが結合現在のモビリティの元の登録のために使用したのと同じソースポートを使用するように注意しなければなりません。おそらく新しいポートで待機開始するホームエージェントは、新規登録、及びモバイルノードの受け入れの宛先ポートを変更するだろうがに到着したときにそれ以外の場合は、変更時のホームエージェントから飛行中のパケットはドロップされますモバイルノードの古い港。 （これはこれは、モバイルノードの再起動、インターフェースの変更、などNAT落下状態の結果であるかもしれないとして、ホームエージェントは、新しいポートが使用されているMIP UDPトンネルを使用して登録要求を拒否しなければならないという意味ではありません）
If a mobile node is registering through a foreign agent but using a co-located care-of address, and the agent advertisement from the foreign agent had the 'U' bit set, the mobile node MUST set the 'R' flag in its UDP Tunnel Request Extension, in order to make the HA use MIP UDP tunnelling. In this case, the mobile node also MUST send a keepalive as soon as its registration has been accepted.
モバイルノードが持っていた「U」ビットセットを外国人のエージェントを介して登録するが、外国人のエージェントから同じ場所に配置さ気付アドレス、およびエージェント広告を使用している場合、モバイルノードは、そのUDPでR「」フラグを設定しなければなりませんHAの利用MIP UDPトンネルを作るために、トンネル要求拡張、。この場合、移動ノードはまた、すぐにその登録が受理されたとして、キープアライブを送らなければなりません。
If a mobile node is registering through a foreign agent but using a co-located care-of address, and the agent advertisement from the foreign agent does not have the 'U' bit set, the mobile node MUST NOT include a UDP Tunnel Request Extension in the registration request.
モバイルノードが外国人のエージェントを通して登録したが「U」ビットが設定されていない同じ場所に配置さ気付アドレス、および外部エージェントからエージェント広告を使用している場合、モバイルノードは、UDPトンネル要求拡張を含んではいけません登録要求インチ
The UDP Tunnel Request Extension MAY be used by a foreign agent when it is forwarding a Mobile IP Registration Request to a home agent, when the foreign agent is situated behind a NAT or has some other compelling reason to require MIP UDP tunnelling.
それはホームエージェントにモバイルIP登録要求を転送しているとき、外国人のエージェントがNATの後ろに位置またはMIP UDPトンネリングを必要とする他のいくつかの魅力的な理由がされたときにUDPトンネルリクエスト拡張は、外国人のエージェントによって使用されるかもしれません。
The purpose of this extension is to indicate to the home agent that the foreign agent is able to accept MIP UDP tunnelling if the home agent has an indication that the foreign agent resides behind a NAT or NAPT. It thus functions as a conditional solicitation for the use of MIP UDP tunnelling.
この拡張の目的は、外国人のエージェントがホームエージェントは、外部エージェントは、NATやNAPTの背後にある旨の表示がある場合MIP UDPトンネルを受け入れることができるホームエージェントに示すことです。これはMIP UDPトンネルを使用するための条件勧誘として機能します。
A foreign agent which requires the mobile node to register through a foreign agent by setting the 'R' bit in the agent advertisement, MUST NOT add the UDP Tunnel Request Extension when forwarding a registration request which uses a co-located care-of address, as this will lead to a UDP tunnel being set up from the home agent to the foreign agent instead of to the mobile node.
同じ場所に配置さ気付アドレスを使用して登録要求を転送するときにUDPトンネル要求拡張を追加してはならない、エージェント広告に「R」ビットを設定することで、外国人のエージェントを介して登録するには、モバイルノードを必要と外国人のエージェント、これはUDPトンネルにつながるとして、外国人のエージェントにホームエージェントからではなく、モバイルノードに設定されています。
As per Section 3.2 and 3.7.2.2 of RFC 3344 [10], the foreign agent when using this extension MUST place it after the Mobile-Home Authentication Extension in registration messages. If the foreign agent shares a mobility security association with the home agent and therefore appends a Foreign-Home Authentication Extension, the UDP Tunnel Request Extension MUST be placed before the Foreign-Home Authentication Extension.
3.2節およびRFC 3344の3.7.2.2あたりとして、[10]、外国人のエージェントこの拡張機能を使用する際に、登録メッセージにモバイル・ホーム認証拡張した後にそれを置かなければなりません。外国人のエージェントがホームエージェントとの移動性セキュリティ仲間を共有するため、外国ホーム認証拡張を追加した場合は、UDPトンネルリクエスト拡張は外国ホーム認証拡張前に置かなければなりません。
As the home agent detects the presence of a NAT in the path between the sender and itself by seeing a mismatch between the IP source address and the care-of address given in the registration request, it is REQUIRED that the foreign agent, when using this extension, sends the registration request with an IP source address matching the care-of address.
ホームエージェントは、送信元IPアドレスと気付けアドレス登録要求に与えられたとの不一致を見て、送信者と自身の間のパスでNATの存在を検出すると、これを使用している場合、それは、外国人のエージェントが必要です拡張子は、気付アドレスと一致するIP送信元アドレスの登録要求を送信します。
A foreign agent using MIP UDP tunnelling to a home agent because the FA is situated behind a NAT may be configured to encourage reverse tunnelling, or be neutral about it, depending on the characteristics of the NAT. If the NAT translates all source addresses of outgoing packets to its own public address, it will not be possible to maintain sessions when moving away from this network if the mobile node has used triangular routing instead of reverse tunnelling. On the other hand, if it is known that the NAT is smart enough to not translate publicly routable source addresses, AND does not do ingress filtering, triangular routing may succeed. The leg from the home agent to the foreign agent will still use MIP UDP tunnelling to pass through the NAT.
ホームエージェントにMIP UDPトンネルを使用して外部エージェントFAは、NATの後ろに位置しているので、NATの特性に応じて、逆のトンネリングを奨励する、またはそれについて中立であるように構成することができます。 NATは、自身のパブリックアドレスへの発信パケットのすべての送信元アドレスを変換する場合、モバイルノードがリバーストンネリングの代わりに三角形のルーティングを使用している場合は、このネットワークから離れて移動するときのセッションを維持することはできません。それは、NATは、パブリックにルーティング可能な送信元アドレスを変換しないように十分にスマートで、イングレスフィルタリングをしないことが知られている一方、三角ルーティングが成功する可能性があります。外国人のエージェントにホームエージェントからの足はまだNATを通過するMIP UDPトンネルを使用します。
Therefore, if it is known when configuring a foreign agent behind a NAT that the NAT will translate public as well as private addresses, or it is known that ingress filtering is being done between the private and public networks, the foreign agent SHOULD reply to registration requests which don't have the 'T' bit set with a reply code 75, "reverse tunnel is mandatory and 'T' bit not set".
NATは、公共だけでなく、プライベートアドレスを変換します、または入口フィルタリングは、プライベートとパブリックネットワーク間で行われていることが知られているNATの背後にある外国人のエージェントを構成するとき、それがわかっている場合はそのため、外国人のエージェントは、登録に返信すべきです「T」ビットは応答コード75が設定されていない要求は、「リバーストンネルは必須であり、 『T』ビットが設定されていません」。
Conversely, if it is known that the NAT is smart about not translating public addresses, and no ingress filtering is done, so it is reasonable to believe that a mobile node with a publicly routable address may be able to keep up sessions when moving to or from this network, the foreign agent MAY be configured to forward registration requests even if they don't have the 'T' bit set.
逆に、それはNATがパブリックアドレスを変換し、何の入口フィルタリングが行われないない程度スマートなので、パブリックにルーティング可能なアドレスを持つモバイルノードがへの移動セッションを維持することができることを信じることが妥当であることが分かっている場合か、このネットワークから、外国人のエージェントは、彼らが「T」ビットが設定されていない場合でも、登録要求を転送するように構成することができます。
If the behaviour of the NAT is unknown in this respect, it SHOULD be assumed that it will translate all addresses, thus the foreign agent SHOULD be configured to reply to registration requests which don't have the 'T' bit set with a reply code 75, "reverse tunnel is mandatory and 'T' bit not set".
NATの動作は、この点では不明である場合、すべてのアドレスを変換することが想定されるべきであるので、外国人のエージェントは「T」ビットは応答コードで設定されていない登録要求に応答するように設定する必要があります75、「リバーストンネルは必須であり、 『T』ビットが設定されていません」。
The purpose of the MIP UDP Tunnel Reply Extension is to indicate whether or not the home agent accepts the use of MIP UDP tunnelling for this mobility binding, and to inform the mobile node or foreign agent of the suggested tunnel keepalive interval to be used.
MIP UDPトンネルの目的は、拡張は、ホームエージェントはこの結合のモビリティのためのMIP UDPトンネルの使用を受け入れるかどうかを示すために、そして使用されることが示唆トンネルキープアライブ間隔のモバイルノードまたは外部エージェントに通知することで返信。
The UDP Tunnel Reply Extension MUST be used in a Mobile IP Registration Reply from the home agent to the mobile node when it has received and accepted a UDP Tunnel Request (Section 3.1) from a mobile node.
UDPトンネルは延長返信それが受信され、移動ノードからUDPトンネル要求（3.1節）を受け入れたとき、モバイルノードにホームエージェントからモバイルIP登録応答に使用されなければなりません。
The home agent MUST use a mismatch between source IP address and care-of address in the Mobile IP Registration Request message as the indication that a mobile node may reside behind a NAT. If the Registration Request also contains the UDP Tunnel Request extension without the 'R' flag set, and the home agent is capable of, and permits MIP UDP tunnelling, the home agent SHALL respond with a registration reply containing an assenting UDP Tunnel Reply Extension as described in Section 3.2. If the 'R' flag is set, special considerations apply, as described below.
ホームエージェントは、モバイルノードがNATの背後に存在することができることを示すものとして、モバイルIP登録要求メッセージの送信元のIPアドレスと気付アドレスの間のミスマッチを使用しなければなりません。登録要求にも「R」のフラグが設定されていないUDPトンネルの要求拡張が含まれており、ホームエージェントが可能であり、MIPのUDPトンネリングを許可している場合、ホームエージェントはassenting UDPトンネルのように拡張子を返信含む登録応答で応答します3.2節で説明しました。 「R」フラグが設定されている場合、以下に説明するように、特別な考慮事項が適用されます。
If the home agent receives a Registration Request with matching source IP address and co-located care-of address which contains a MIP UDP Tunnel Request Extension, the home agent SHOULD respond with a Registration Reply containing a declining UDP Tunnel Reply - unless tunnelling has been explicitly requested by the mobile node using the 'F' flag as described in Section 3.1.
ホームエージェントが一致する送信元IPアドレスと同じ場所に配置さ気付アドレスMIP UDPトンネルの要求拡張が含まれているとの登録リクエストを受信した場合、ホームエージェントは減少UDPトンネル返信を含む登録応答で応答する必要があります - トンネリングがされていない限り、セクション3.1で説明したように明示的に「F」フラグを使用してモバイルノードによって要求されました。
If the home agent assents to UDP tunnelling, it MUST use the source address of the registration request as the effective care-of address, rather than the care-of address given in the registration request, except in the case where the 'R' flag is set in the UDP Tunnel Request Extension.
ホームエージェントは、UDPトンネリングにassents場合、それは「R」のフラグ場合を除いて、効果的な気付アドレス、むしろ気付けアドレス登録要求に与えられたよりとして登録要求の送信元アドレスを使用しなければなりませんUDPトンネル要求拡張に設定されています。
If the home agent receives a Registration Request with the 'R' flag set in the UDP Tunnel Request Extension, it SHOULD reply with an assenting UDP Tunnel Reply Extension if it is capable of, and permits MIP UDP tunnelling. In this case, however, the source address and port of the registration request may be a NAT'ed version of the foreign agent source address and port. In order to direct tunnelled traffic correctly to the mobile node, the home agent MUST wait for the first keepalive packet from the mobile node to arrive, before it can send traffic back to the correct NAT port (the one which is mapped to the MN). In this case, the home agent MUST check that the outer source address (but not the port) of this keepalive packet is identical with the source address of the corresponding registration request. The inner source address (that of the encapsulated ICMP echo request) MUST be the home address of the mobile node, and the inner destination address MUST be that of the home agent. If all this holds, the outer source address and port of this keepalive packet SHALL be used by the HA as the outer destination address and port of the MIP UDP tunnel when forwarding traffic to the mobile node.
ホームエージェントは、UDPトンネル要求拡張に設定された「R」フラグを付けて登録リクエストを受信した場合、それはassenting UDPトンネルで応答すべきで、それが可能であれば拡張子を返信し、MIP UDPトンネリングを許可します。しかし、この場合には、登録要求の送信元アドレスおよびポートは、外部エージェントの元アドレスとポートのNATによるバージョンであってもよいです。それが正しいNATポート（MNにマップされている1）に戻ってトラフィックを送信する前に、モバイルノードに正しくトンネリングされたトラフィックを指示するためには、ホームエージェントは、到着するモバイルノードから最初のキープアライブパケットを待つ必要があります。この場合、ホームエージェントは、このキープアライブパケットの外側のソースアドレス（ただし、ポート）は、対応する登録要求の送信元アドレスと同一であることを確認しなければなりません。内部ソースアドレス（カプセル化されたICMPエコー要求のもの）は、移動ノードのホームアドレスでなければなりません、そして内側宛先アドレスがホームエージェントのものでなければなりません。このすべてが保持している場合、モバイルノードにトラフィックを転送する際に、このキープアライブパケットの外側のソースアドレスとポートがMIP UDPトンネルの外側の宛先アドレスとポートとしてHAによって使用されなければなりません。
The home agent SHOULD be consistent in acknowledging support for UDP tunnelling or not. A home agent which understands the UDP Tunnel Request Extension and is prepared to respond positively to such a request SHOULD also respond with a UDP Tunnel Reply Extension containing a declining reply code if use of MIP UDP tunnelling is not indicated for a session. The mobile node MUST NOT assume such behaviour from the home agent, since the home agent may undergo a software change with reboot, a policy change or a replacement; and consequently a change of behaviour.
ホームエージェントは、UDPトンネリングかのサポートを認めるで一貫している必要があります。 UDPトンネル要求拡張を理解し、また、UDPトンネルで応答する必要があります、このような要求に積極的に対応する用意があるホームエージェントはMIP UDPトンネルの使用がセッションのために示されていない場合は減少応答コードを含む拡張を返信します。ホームエージェントは再起動を伴うソフトウェアの変更、ポリシーの変更または交換を受ける可能性があるため、モバイルノードは、ホームエージェントから、このような行動を仮定してはいけません。その結果、行動の変化を。
The following actions take place when things go wrong.
物事がうまくいかない場合は、次のアクションが実行されます。
The HA does not support the UDP Tunnel Request extension:
HAは、UDPトンネル要求拡張をサポートしていません。
The home agent ignores the extension and proceeds normally, which would be to refuse the registration if the IP source address does not match the care-of address, the home address or 0.0.0.0. Even if the HA mistakenly does accept the registration, the mobile node will not be able to receive forward tunnelled data if it is behind a NAT.
ホームエージェントは、IP送信元アドレスは、気付アドレス、ホームアドレスまたは0.0.0.0と一致しない場合は登録を拒否するだろうこれ、拡張子を無視し、正常に進行します。 HAが誤って登録を受け付けない場合でも、モバイルノードは、それがNATの背後にある場合、前方トンネリングされたデータを受信することはできません。
(It would be beneficial to have the mobile node de-register in this case. The mobile node, however, normally has no way of telling that it is behind a NAT if it does not receive a UDP Tunnelling Reply.)
（それは、この場合には、移動ノードの登録ドを持っていることは有益であろう。モバイルノードは、しかし、通常はそれがUDPトンネリング返信を受信しない場合、それはNATの背後にあることを伝える方法がありません。）
NAT detected by home agent, but traversal not allowed:
NATは、ホームエージェントによって検出されたが、トラバーサルは許可されていません。
In some cases the home agent may disable NAT traversal even though it supports the UDP Tunnel Request extension and a NAT is detected. In this case, the home agent SHOULD send a Registration Reply with the Code field set to 129, "administratively prohibited".
それはUDPトンネル要求拡張をサポートし、NATが検出されていても、いくつかのケースでは、ホームエージェントは、NATトラバーサルを無効にすることができます。この場合、ホームエージェントは、「管理上禁止」129に設定されたコードフィールドで登録応答を送るべきです。
NAT not detected, 'F' flag set, but home agent does not allow forced use of MIP UDP tunnelling:
NAT「F」フラグが設定され、検出されないが、ホームエージェントは、MIP UDPトンネルの強制使用を許可していません。
The home agent SHOULD send a Registration Reply with the Code field set to 129, "administratively prohibited".
ホームエージェントは129に設定され、コードフィールドに登録応答を送るべきで、「管理上禁止」。
UDP Tunnel Request extension sent by the mobile node (placed before the MN-HA authentication extension), but 'D' bit in registration request header not set:
モバイルノードによって送信されたUDPトンネル要求拡張は、登録要求ヘッダーの「D」ビットがセットされていない（MN-HA認証拡張の前に配置）、しかし：
The home agent SHOULD send a Registration Reply with the Code field set to 134, "poorly formed Request".
ホームエージェントは134に設定されたコードフィールド、「難形成要求」と登録応答を送るべきです。
UDP Tunnel Request extension sent by the foreign agent (placed after the MN-HA authentication extension), but 'D' bit is set:
UDPトンネル要求拡張（MN-HA認証拡張の後に配置）フォーリンエージェントによって送信されたが、「D」ビットが設定されています。
The home agent SHOULD send a Registration Reply with the Code field set to 134, "poorly formed Request".
ホームエージェントは134に設定されたコードフィールド、「難形成要求」と登録応答を送るべきです。
Reserved 3 field of UDP Tunnel Request extension is nonzero:
UDPトンネルリクエスト延長の予約3フィールドがゼロでありません。
The home agent SHOULD send a Registration Reply with the Code field set to 134, "poorly formed Request".
ホームエージェントは134に設定されたコードフィールド、「難形成要求」と登録応答を送るべきです。
Encapsulation type requested in UDP Tunnel Request extension is unsupported:
UDPトンネルリクエスト延長で要求カプセル化タイプがサポートされていません。
The home agent SHOULD send a Registration Reply with the Code field set to ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation unavailable" defined in Section 3.5.
ホームエージェントは、ERROR_HA_UDP_ENCAP_UNAVAILに設定コードフィールドとセクション3.5で定義された「使用できない要求UDPトンネルカプセル化を」登録応答を送るべきです。
UDP tunnelling SHALL be used only for data packets, and only when the mobility binding used for sending was established using the UDP Tunnel Request, and accepted by an UDP Tunnel Reply from the home agent. After MIP UDP tunnelling has been established for a mobility binding, data packets that are forward or reverse tunnelled using this mobility binding MUST be tunnelled using MIP UDP tunnelling, not IP-in-IP tunnelling or some other tunnelling method.
UDPトンネリングは、データ・パケットのみに使用するものとし、送信するために使用される移動性結合は、UDPトンネル要求を使用して確立し、ホームエージェントからのUDPトンネル返信に受け入れられたときにのみ。 MIP UDPトンネルは移動性結合のために確立された後、前方にあるか、この結合モビリティを使用してトンネルさ逆方向データパケットはないIP内IPトンネリングまたは他のいくつかのトンネリング方式、MIP UDPトンネルを使用してトンネルされなければなりません。
As a consequence:
結果として：
- Mobile IP signalling is never tunnelled.
- モバイルIPシグナリングがトンネリングされることはありません。
- When using simultaneous bindings, each binding may have a different type (i.e., UDP tunnelling bindings may be mixed with non-UDP tunnelling bindings).
- 同時バインディングを使用する場合、各々が異なるタイプ（すなわち、UDPトンネリングバインディングが非UDPトンネルバインディングと混合することができる）を有することができる結合。
- Tunnelling is only allowed for the duration of the binding lifetime.
- トンネルにのみ結合寿命の期間中に許可されています。
From RFC 3022 [12]:
RFC 3022 [12]から：
"Translation of outbound TCP/UDP fragments (i.e., those originating from private hosts) in NAPT set-up are doomed to fail. The reason is as follows. Only the first fragment contains the TCP/UDP header that would be necessary to associate the packet to a session for translation purposes. Subsequent fragments do not contain TCP/UDP port information, but simply carry the same fragmentation identifier specified in the first fragment. Say, two private hosts originated fragmented TCP/UDP packets to the same destination host. And, they happened to use the same fragmentation identifier. When the target host receives the two unrelated datagrams, carrying same fragmentation id, and from the same assigned host address, it is unable to determine which of the two sessions the datagrams belong to. Consequently, both sessions will be corrupted."
アウトバウンドTCP / UDPフラグメントの「翻訳（すなわち、プライベートホストから発信されるもの）NAPTでは、セットアップを失敗する運命にある。次のような理由がある。最初のフラグメントだけを関連付けることが必要であろうTCP / UDPヘッダが含まれています翻訳の目的のためにセッションへのパケット。その後の断片はTCP / UDPポート情報が含まれていますが、単に最初のフラグメントに指定したのと同じフラグメンテーション識別子を運ぶことはありません。と言う、2つのプライベートホストが同じ宛先ホストに断片化されたTCP / UDPパケットを発信した。そして、ターゲットホストが同じフラグメンテーションIDを保有する、2つの無関係なデータグラムを受信した場合、それらは同じ断片識別子を使用するように起こって、同じ割り当てられたホストアドレスから、データグラムが属する2つのセッションのかを決定することができないものである。したがって、両方のセッションが破損します。」
Because of this, if the mobile node or foreign agent for any reason needs to send fragmented packets, the fragmentation MUST be done prior to the encapsulation. This differs from the case for IP-in-IP tunnelling, where fragmentation may be done before or after encapsulation, although RFC 2003 [4] recommends doing it before encapsulation.
何らかの理由で、移動ノードや外国人のエージェントが断片化されたパケットを送信する必要がある場合このため、断片化は、カプセル化に先立って行われなければなりません。これは、RFC 2003 [4]カプセル化する前にそれを行うことをお勧めしますが、フラグメンテーションは、カプセル化の前または後に行うことができるIPインIPトンネリングのためのケースとは異なります。
A similar issue exists with some firewalls, which may have rules that only permit traffic on certain TCP and UDP ports, and not arbitrary outbound (or inbound) IP traffic. If this is the case and the firewall is not set to do packet reassembly, a home agent behind a firewall will also have to do packet fragmentation before MIP UDP encapsulation. Otherwise, only the first fragment (which contains the UDP header) will be allowed to pass from the home agent out through the firewall.
同様の問題は、特定のTCPおよびUDPポート、およびない任意のアウトバウンド（またはインバウンド）IPトラフィックのトラフィックを許可するルールを持っているかもしれないいくつかのファイアウォール、存在します。このような場合は、ファイアウォールがパケットの再構成を行うように設定されていない場合は、ファイアウォールの背後にあるホームエージェントは、MIP UDPカプセル化の前にパケットの断片化を行う必要があります。そうでない場合には、（UDPヘッダを含んでいる）は最初のフラグメントは、ファイアウォールを介してホームエージェントから通過させるであろう。
For this reason, the home agent SHOULD do packet fragmentation before it does MIP UDP encapsulation.
それはMIP UDPカプセル化を行う前に、このような理由から、ホームエージェントは、パケットの断片化を行う必要があります。
As the existence of the bi-directional UDP tunnel through the NAT is dependent on the NAT keeping state information associated with a session, as described in RFC 2663 [11], and as the NAT may decide that the session has terminated after a certain time, keepalive messages may be needed to keep the tunnel open. The keepalives should be sent more often than the timeout value used by the NAT.
RFC 2663に記載されるようにNATを介して双方向UDPトンネルの存在は、セッションに関連する状態情報を維持するNATに依存しているように[11]、及びNATは、セッションが一定時間後に終了したことを決定することができるように、キープアライブメッセージが開いたトンネルを維持するために必要な場合があります。キープアライブは、NATが使用するタイムアウト値よりも頻繁に送信する必要があります。
This timeout may be assumed to be a couple of minutes, according to RFC 2663 [11], but it is conceivable that shorter timeouts may exist in some NATs.
このタイムアウトは、RFC 2663 [11]によれば、数分であると仮定することができるが、より短いタイムアウトは、いくつかのNATに存在することが考えられます。
For this reason the extension used to set up the UDP tunnel has the option of setting the keepalive message interval to another value than the default value, see Section 3.2.
UDPトンネルを設定するために使用される拡張がデフォルト値よりも別の値にキープアライブメッセージの間隔を設定するオプションを持っている。このような理由から、3.2節を参照してください。
The keepalive message sent MUST consist of a properly UDP encapsulated ICMP echo request directed to the home agent.
ホームエージェントに向け適切にUDPカプセル化されたICMPエコー要求で構成する必要があります送信されたキープアライブメッセージ。
For each mobility binding which has UDP tunnelling established, the non-HA endpoint of the Mobile-IP UDP tunnel MUST send a keepalive packet if no other packet to the HA has been sent in K seconds. Here K is a parameter with a default value of 110 seconds. K may be set to another value by the HA as described in the UDP tunnelling reply extension (Section 3.2).
HAへの他のパケットは、K秒で送信されていない場合UDPトンネリング確立を有する結合各モビリティのために、モバイルIP UDPトンネルの非HAのエンドポイントは、キープアライブパケットを送信しなければなりません。ここでKは、110秒のデフォルト値を持つパラメータです。 UDPトンネル応答拡張（3.2節）に記載されるようにKは、HAによって別の値に設定されてもよいです。
Except for the case where the mobile node registers with a co-located address through an FA (see Section 4.11) MIP UDP tunnelling is done using the same ports that have already been used for the registration request / reply exchange. The MN or FA will send its first keepalive message at the earliest K seconds after the registration request was sent. The same UDP source port MUST be used for the keepalive messages as was used for the original Registration Messages and for data messages.
モバイルノードがFAを介して同一位置アドレスに登録する場合を除いて（セクション4.11を参照）MIP UDPトンネルは、登録要求が/交換を返信するために既に使用された同じポートを使用して行われます。登録要求が送信された後にMNまたはFAは最も初期のK秒でその最初のキープアライブメッセージを送信します。オリジナルの登録メッセージ用とデータメッセージのために使用されたのと同じUDPソースポートは、キープアライブメッセージを使用しなければなりません。
The remote UDP tunnel endpoint MUST use two-way keepalives consisting of UDP encapsulated ICMP Echo Request/Reply messages. The rationale for using two-way keepalives is two-fold:
リモートUDPトンネルエンドポイントは、UDPからなる双方向キープアライブはICMPエコー要求/応答メッセージをカプセル化使用しなければなりません。双方向キープアライブを使用する理論的根拠は二つあります：
1. Two-way keepalives allow the mobile node to detect loss of a NAT mapping. Detection of NAT mapping loss in turn allows the MN to compensate by re-registering and using a shorter keepalive to avoid loss of NAT mappings in the future.
1.双方向キープアライブは、モバイルノードがNATマッピングの損失を検出することを可能にします。ターンでのNATマッピング損失の検出は、MNは、再登録および将来のNATマッピングの損失を回避するために、短いキープアライブを使用することによって補正することができます。
2. One-way keepalives (keepalives sent by MN or FA, but without any reply from the home agent) actually cause more keepalive traffic overhead; the keepalive messages have to be sent more frequently to compensate for occasional loss of keepalive messages. In contrast, two-way keepalives are acknowledged, and retransmissions occur only when a response is not received for a keepalive request within a reasonable time.
2.ワンウェイキープアライブ（MNまたはFAにより送信されたキープアライブが、ホームエージェントからの任意の応答なし）は、実際に多くのキープアライブトラフィックのオーバーヘッドを引き起こします。キープアライブメッセージは、キープアライブメッセージの臨時の損失を補うために、より頻繁に送信する必要があります。これとは対照的に、双方向キープアライブが認められ、再送信は、応答が妥当な時間内にキープアライブ要求のために受信されない場合にのみ発生します。
When a mobile node is using UDP encapsulated ICMP Echo Request/Reply messages as keepalives, it will have to deal with the possibility that a NAT mapping is lost by a NAT device. The crucial thing here is of course not the loss of the NAT mapping in itself; but rather that the home agent, in the absence of a Registration Request through the new mapping, will continue to send traffic to the NAT port associated with the old mapping.
モバイルノードは、UDPを使用している場合は、ICMPエコー要求/キープアライブとしてメッセージを返信カプセル化された、それはNATマッピングがNATデバイスによって失われている可能性に対処する必要があります。ここで重要な事は、もちろん、それ自体ではNATマッピングの損失ではありません。ではなく、ホームエージェントは、新しいマッピングによる登録要求が存在しない場合には、古いマッピングに関連付けられたNATのポートにトラフィックを送信し続けること。
If the mobile node does not get a reply to its UDP encapsulated ICMP Echo Request even after a number of retransmissions, and is still connected to the same router that was used to establish the current mobility binding, the mobile node SHOULD re-register with the home agent by sending an Registration Request. This lets the HA know about the new NAT mapping and restores connectivity between mobile node and home agent.
モバイルノードがさえ再送回数後にUDPカプセル化されたICMPエコー要求に対する応答を取得していない、とまだ結合現在の移動性を確立するために使用したのと同じルーターに接続されている場合は、モバイルノードはで再登録する必要があります登録リクエストを送信することにより、ホームエージェント。これは、HAは、新しいNATマッピングについて知っていると、モバイルノードとホームエージェント間の接続を復元することができます。
Having established a new mobility binding, the mobile node MAY use a shorter keepalive interval than before the NAT mapping was lost; in particular, the mobile node MAY deviate from the keepalive interval assigned by the home agent. If the binding loss continues to occur, the mobile node may shorten the keepalive interval each time it re-registers, in order to end up with a keepalive interval that is sufficient to keep the NAT mapping alive. The strategy used to arrive at a keepalive interval when a NAT mapping is lost is implementation dependent. However, the mobile node MUST NOT use a keepalive less than 10 seconds.
NATマッピングが失われた前のバインディング新しいモビリティを確立した、モバイルノードは、短いキープアライブ間隔よりもを使用することができます。具体的には、モバイルノードは、ホームエージェントによって割り当てられたキープアライブ間隔から逸脱してもよいです。結合損失が引き続き発生する場合、モバイルノードは、生きているNATマッピングを維持するのに十分であるキープアライブ間隔で終わるために、キープアライブ間隔にそれは、レジスタ再各時間を短縮することができます。 NATマッピングが失われたキープアライブ間隔に到達するために使用される戦略は、実装依存です。しかし、モバイルノードは、以下10秒以上キープアライブを使用してはなりません。
Note that the above discussion only applies when the mobile node is re-registering through the same router, and thus presumably through the same NAT device that lost a NAT mapping earlier. If the MN moves and still finds itself behind a NAT, it SHOULD return to its original keepalive interval (the default value, or as assigned by the home agent) and it SHOULD NOT do any keepalive interval compensation unless it discovers a loss of NAT mapping in the new environment.
上記の議論は、モバイルノードが同じルータを介して再登録している場合にのみ適用され、したがって、おそらく以前のNATマッピングを失った同じNATデバイスを通っていることに注意してください。 MNが移動し、まだNATの背後に自分自身を見つけた場合、それは元のキープアライブ間隔（デフォルト値、またはホームエージェントによって割り当てなど）を返すべきで、それがNATマッピングの損失を発見しない限り、それは任意のキープアライブ間隔の補償をすべきではありません新しい環境インチ
The home agent MUST NOT attempt to detect or compensate for NAT binding loss by dynamically changing the keepalive interval assigned in the Registration Reply; the home agent does not have enough information to do this reliably and should thus not do it at all. The mobile node is in a much better position to determine when a NAT mapping has actually been lost. Note also that a MN is allowed to let a NAT mapping expire if the MN no longer needs connectivity.
ホームエージェントは動的に登録応答に割り当てられたキープアライブ間隔を変更することにより、検出またはNAT結合損失を補償しようと試みてはなりません。ホームエージェントは確実にこれを実行するのに十分な情報を持っていないので、すべてでそれをやるべきではありません。モバイルノードは、NATマッピングが実際に失われたときを決定するためにはるかに良い位置にあります。 MNは、MNは、もはや接続を必要とする場合、NATマッピングが失効させないために許可されていることにも注意してください。
The discussion above does only in a limited sense apply to a foreign agent which is situated behind a NAT and using MIP UDP tunnelling. In this case, it is a matter of permanently configuring the FA to use a keepalive interval which is lower than the NAT mapping lifetime, rather than trying to dynamically adapt to the binding lifetimes of different NATs.
上記の議論は、限られた意味でのNATの後ろに位置し、MIP UDPトンネルを使用している外国人のエージェントに適用されます。この場合、それは永久にNATマッピング寿命より低いキープアライブ間隔を使用するためにFAを設定するのではなく、動的に異なるのNAT結合寿命に適応しようとしているの問題です。
This section summarizes the protocol details which have been necessary in order to handle and support the case when a mobile node registers with a co-located address through a foreign agent, due to the FA advertisements having the 'R' bit set. It gives background information, but lists no new requirements.
このセクションでは、ハンドルと、モバイルノードが原因「R」ビットセットを有するFA広告に、外部エージェントを介して同一位置アドレスを登録する場合をサポートするために必要であったプロトコルの詳細をまとめたものです。これは、背景情報が得られますが、新たな要件を示していません。
When a mobile registers a co-located care-of address through an FA, the registration request which reaches the HA will have a different care-of address in the registration request compared to the source address in the registration request IP-header. If the registration request also contains a UDP Tunnel Request Extension, the HA will erroneously set up a UDP tunnel, which will go to the FA instead of the MN. For this reason, as mentioned in Section 4.4, the mobile node must not include a UDP Tunnel Request Extension in the registration if it is registering a co-located address through an FA which does not have the 'U' bit set in its advertisements.
モバイルはFAを介して同一位置気付アドレスを登録する際に、HAに到達登録要求は、登録要求IPヘッダ内の送信元アドレスと比較して異なる気付アドレス登録要求にを有するであろう。登録要求もUDPトンネル要求拡張が含まれている場合は、HAは、誤ってFAの代わりに、MNに行くUDPトンネルを設定します。 4.4節で述べたように、それは「U」ビットは、その広告に設定されていませんFAを通じて同じ場所に配置アドレスを登録している場合は、このような理由から、モバイルノードは、登録時にUDPトンネルリクエスト拡張子を含めることはできません。
In order to still be able to use MIP UDP tunnelling in this case, foreign agents which are situated behind a NAT are encouraged to send advertisements which have the 'U' bit set, as described in Section 3.4.
まだこのような場合にはMIP UDPトンネルを使用することができるようにするためには、NATの後ろに位置している外国人のエージェントは、3.4節で説明したように、「U」ビットがセットされている広告を送信することをお勧めします。
If the FA advertisement has the 'U' bit set, indicating that it is behind a NAT, and also the 'R' bit set, and the mobile node wishes to use a co-located care-of address, it MUST set the 'R' flag in the UDP Tunnel Request Extension, in order to inform the HA of the situation so that it may act appropriately, as described in Section 4.4.
FAの広告は、NATの背後にあることを示し、「U」ビット・セットを有しており、また、R「」はビットセット、およびモバイルノードが同一位置気付アドレスを使用したい、それは設定する必要がある場合セクション4.4で説明したようにUDPトンネルリクエスト拡張でR」フラグは、状況をHAに通知するためには、適切に機能することができるようになっています。
Because the UDP tunnel is now taking another path than the registration requests, the home agent, when handling registrations of this type, must wait till the arrival of the first keepalive packet before it can set up the tunnel to the correct address and port. To reduce the possibility of tunnel hijacking by sending a keepalive with a phony source address, it is required that only the port of the keepalive packet may be different from that of the registration request; the source address must be the same. This means that if the FA and MN are communicating with the HA through different NATs, the connection will fail.
UDPトンネルは現在、登録要求よりも別のパスを取っているので、それが正しいアドレスとポートにトンネルを設定する前に、ホームエージェントは、このタイプの登録を取り扱う際は、最初のキープアライブパケットの到着まで待たなければなりません。偽のソースアドレスとキープアライブを送信することによってトンネルのハイジャックの可能性を低減するためには、キープアライブパケットのポートのみが登録要求のものとは異なっていてもよいことが要求されます。送信元アドレスは同じでなければなりません。これは、FAとMNが異なるNATを通過HAと通信している場合、接続が失敗することを意味します。
In providing a mobile node with a mechanism for NAT traversal of Mobile IP traffic, we expand the address space where a mobile node may function and acquire care-of addresses. With this comes a new problem of movement detection and address aliasing. We here have a case which may not occur frequently, but is mentioned for completeness:
モバイルIPトラフィックのNATトラバーサルのための機構をモバイルノードを提供する際に、私たちは、モバイルノードが機能して気付アドレスを取得することができるアドレス空間を展開します。これにより、動き検出とアドレスエイリアシングの新たな問題が来ます。ここでは頻繁に発生していないこと場合がありますが、完全性のために言及されています。
Since private networks use overlapping address spaces, they may be mistaken for one another in some situations; this is referred to as private address aliasing in this document. For this reason, it may be necessary for mobile nodes implementing this specification to monitor the link layer address(es) of the gateway(s) used for sending packets. A change in the link layer address indicates probable movement to a new network, even if the IP address remains reachable using the new link layer address.
プライベートネットワークは、重複するアドレス空間を使用しているので、彼らはいくつかの状況で、互いのために誤解することができます。これは、本文書にエイリアシングプライベートアドレスと呼ばれています。このため、パケットの送信に使用するゲートウェイ（複数可）のリンク層アドレスを監視するために、この仕様を実装する移動ノードのために必要であるかもしれません。リンク層アドレスの変更は、IPアドレスが新しいリンク層アドレスを使用して到達可能な残っていても、新しいネットワークに可能性の高い動きを示しています。
For instance, a mobile node may obtain the co-located care-of address 10.0.0.1, netmask 255.0.0.0, and gateway 10.255.255.254 using DHCP from network #1. It then moves to network #2, which uses an identical addressing scheme. The only difference for the mobile node is the gateway's link layer address. The mobile node should store the link layer address it initially obtains for the gateway (using ARP, for instance). The mobile node may then detect changes in the link layer address in successive ARP exchanges as part of its ordinary movement detection mechanism.
例えば、モバイルノードは、ネットワーク＃1からDHCPを使用して、同じ場所に配置アドレス10.0.0.1の気付、ネットマスク255.0.0.0、およびゲートウェイ10.255.255.254を得ることができます。その後、同一のアドレス指定方式を使用する、＃2のネットワークに移動します。モバイルノードのための唯一の違いは、ゲートウェイのリンク層アドレスです。モバイルノードは、（例えば、ARPを使用して、）それが最初にゲートウェイに取得リンク層アドレスを格納すべきです。モバイルノードは、その通常の動き検出機構の一部として連続ARP交換におけるリンク層アドレスの変更を検出してもよいです。
In rare cases the mobile nodes may not be able to monitor the link layer address of the gateway(s) it is using, and may thus confuse one point of attachment with another. This specification does not explicitly address this issue. The potential traffic blackout caused by this situation may be limited by ensuring that the mobility binding lifetime is short enough; the re-registration caused by expiration of the mobility binding fixes the problem (see Section 5.2).
まれに、モバイルノードは、それが使用しているゲートウェイ（S）のリンク層アドレスを監視することができない場合があり、したがって、互いに1つの結合点を混同することができます。この仕様は、明示的にこの問題に対処しません。このような状況によって引き起こされる可能性のあるトラフィックの停電は、モビリティバインディング寿命が十分に短いことを確実にすることによって制限することができます。修正に問題がモビリティ結合の満了によって引き起こされる再登録（5.2節を参照してください）。
When responding to a registration request with a registration reply, the home agent is allowed to decrease the lifetime indicated in the registration request, as covered in RFC 3344 [10]. When using UDP tunnelling, there are some cases where a short lifetime is beneficial.
登録応答の登録要求に応答する際にRFC 3344 [10]に覆われたように、ホームエージェントは、登録要求に示された寿命を減少させることができます。 UDPトンネリングを使用する場合は、短い寿命が有益である場合があります。
First, if the NAT mapping maintained by the NAT device is dropped, a connection blackout will arise. New packets sent by the mobile node (or the foreign agent) will establish a new NAT mapping, which the home agent will not recognize until a new mobility binding is established by a new registration request.
NATデバイスによって維持NATマッピングが削除される場合、最初に接続停電が発生します。モバイルノード（または外部エージェント）によって送信された新たなパケットがバインディング新しいモビリティは新規登録要求によって確立されるまで、ホームエージェントは認識しません新しいNATマッピングを確立します。
A second case where a short lifetime is useful is related to the aliasing of private network addresses. In case the mobile node is not able to detect mobility and ends up behind a new NAT device (as described in Section 5.1), a short lifetime will ensure that the traffic blackout will not be exceedingly long, and is terminated by a re-registration.
短い寿命が有用である第二の場合は、プライベートネットワークアドレスのエイリアシングに関連しています。 （第5.1節に記載されているように）、短い寿命は、トラフィック停電が極めて長くならないことを保証し、再登録することによって終了した場合に、移動ノードは、移動性を検出することができず、新しいNATデバイスの背後に終わります。
The definition of "short lifetime" in this context is dependent on the requirements of the usage scenario. Suggested maximum lifetime returned by the home agent is 60 seconds, but in case the abovementioned scenarios are not considered a problem, longer lifetimes may of course be used.
この文脈での「短い寿命」の定義は、利用シナリオの要件に依存しています。ホームエージェントによって返された推奨最大寿命は60秒ですが、場合には、上記のシナリオは、長い寿命はもちろん使用することができる問題とはみなされません。
The ordinary Mobile IP security mechanisms are also used with the NAT traversal mechanism described in this document. However, there is one noticeable change: the NAT traversal mechanism requires that the HA trust unauthenticated address (and port) fields possibly modified by NATs.
通常のモバイルIPのセキュリティメカニズムも、この文書で説明したNATトラバーサル機構が使用されています。しかし、1つの目立った変化があった：NATトラバーサルメカニズムは、HAの信頼認証されていないアドレス（およびポート）フィールドは、おそらくNATのによって変更されている必要があります。
Relying on unauthenticated address information when forming or updating a mobility binding leads to several redirection attack vulnerabilities. In essence, an attacker may do what NATs do, i.e., modify addresses and ports and thus cause traffic to be redirected to a chosen address. The same vulnerabilities apply to both MN-HA and FA-HA NAT traversal.
いくつかのリダイレクション攻撃の脆弱性につながるモビリティバインディングを形成するか、更新するときに認証されていないアドレス情報に頼ります。本質的には、攻撃者は、すなわち、NATのは何を行うアドレスとポートを変更するので、トラフィックが選ばれたアドレスにリダイレクトされる可能性があります。同じ脆弱性は、MN-HAおよびFA-HA NATトラバーサルの両方に適用されます。
In more detail: without a NAT, the care-of address in the registration request will be directly used by the HA to send traffic back to the MN (or the FA), and the care-of address is protected by the MN-HA (or FA-HA) authentication extension. When communicating across a NAT, the effective care-of address from the HA point of view is that of the NAT, which is not protected by any authentication extension, but inferred from the apparent IP source address of received packets. This means that by using the mobile IP registration extensions described in this document to enable traversal of NATs, one is opening oneself up to having the care-of address of a MN (or a FA) maliciously changed by an attacker.
NATなしで、気付けアドレス登録要求では、直接MN（またはFA）に戻ってトラフィックを送信するHAによって使用され、気付アドレスはMN-HAによって保護されています。より詳細に（またはFA-HA）認証拡張子。 NAT、ビューのHA点から気付アドレスの有効を横切って通信するときに任意の認証拡張で保護が、受信したパケットの見かけのIPソースアドレスから推測されていないNATのことです。これは、NATをトラバースのを可能にするために、この文書に記載され、モバイルIP登録の拡張を用いることにより、一つの悪意の攻撃者によって変更気付MN（又はFA）のアドレスを有することに自分自身を開放されることを意味します。
Some, but not all, of the attacks could be alleviated to some extent by using a simple routability check. However, this document does not specify such a mechanism for simplicity reasons and because the mechanism would not protect against all redirection attacks. To limit the duration of such redirection attacks, it is RECOMMENDED to use a conservative (that is, short) mobility binding lifetime when using the NAT traversal mechanism specified in this document.
すべてではないが、攻撃のいくつかは、単純なルーティング性チェックを使用することである程度軽減することができます。しかし、この文書は簡潔上の理由やメカニズムは、すべてのリダイレクション攻撃から保護しない。なぜなら、そのようなメカニズムを指定していません。そのようなリダイレクション攻撃の持続時間を制限するために、この文書で指定されたNATトラバーサルメカニズムを使用する場合、保存的（すなわち、短い）モビリティバインディング存続期間を使用することが推奨されます。
The known security issues are described in the sections that follow.
既知のセキュリティ問題は、以下のセクションで説明されています。
An attacker on the route between the mobile node (or foreign agent) and the home agent may redirect mobility bindings to a desired address simply by modifying the IP and UDP headers of the Registration Request message. Having modified the binding, the attacker no longer needs to listen to (or manipulate) the traffic. The redirection is in force until the mobility binding expires or the mobile node re-registers.
モバイルノード（または外部エージェント）とホームエージェントとの間の経路上の攻撃者は、単に登録要求メッセージのIP及びUDPヘッダを変更することにより、所望のアドレスへのモビリティバインディングをリダイレクトすることができます。結合修飾され、攻撃者は、もはやトラフィックをに耳を傾ける（または操作）する必要はありません。モビリティバインディングの有効期限が切れるか、モバイルノード再登録するまで、リダイレクトは力です。
This vulnerability may be used by an attacker to read traffic destined to a mobile node, and to send traffic impersonating the mobile node. The vulnerability may also be used to redirect traffic to a victim host in order to cause denial-of-service on the victim.
この脆弱性は、モバイルノード宛てのトラフィックを読み取るために、モバイルノードを偽装トラフィックを送信する攻撃者によって使用されてもよいです。脆弱性はまた、被害者にサービス拒否を引き起こすために、被害者のホストへのトラフィックをリダイレクトするために使用することができます。
The only defense against this vulnerability is to have a short time between re-registrations, which limits the duration of the redirection attack after the attacker has stopped modifying registration messages.
この脆弱性に対する唯一の防衛は、攻撃者が登録メッセージを変更停止した後にリダイレクト攻撃の期間を制限する、再登録の間の短い時間を持つことです。
When registering through an FA using a co-located care-of address, another redirection vulnerability opens up. Having exchanged Registration Request/Reply messages with the HA through the FA, the MN is expected to send the first keepalive message to the HA, thus finalizing the mobility binding (the binding will remain in a "half bound" state until the keepalive is received).
同じ場所に配置さ気付アドレスを使用してFAを通して登録する場合は、別のリダイレクトの脆弱性が開きます。キープアライブが受信されるまで結合（登録要求/ FAを通じてHAとメッセージを返信交換し、MNは、このように移動性結合を最終決定、HAへの最初のキープアライブメッセージを送信することが期待されて持つことは、「半分の束縛」状態のままになります）。
Having observed a Registration Request/Reply exchange, an attacker may send a bogus keepalive message assuming that the mobility binding is in the "half bound" state. This opens up a similar redirection attack as discussed in Section 6.1.1. Note, however, that the attacker does not need to be able to modify packets in flight; simply being able to observe the Registration Request/Reply message exchange is sufficient to mount the attack.
登録要求/応答交換を観察した、攻撃者は、モビリティバインディングは「半拘束」状態にあると仮定して偽のキープアライブメッセージを送信することができます。 6.1.1項で述べたように、これは同様のリダイレクション攻撃を開きます。攻撃者は、飛行中のパケットを変更できるようにする必要がないこと、しかし、注意してください。単に登録要求を観察することができること/メッセージ交換が攻撃をマウントするのに十分である返信。
With this in mind, the home agent MUST NOT accept a keepalive message from a different source IP address than where the Registration Request came from, as specified in Section 4.6. This requirement limits the extent of the attack to redirecting the traffic to a bogus UDP port, while the IP address must remain the same as in the initial Registration Request.
このことを念頭に、ホームエージェントは、4.6節で指定された登録要求は、どこから来たのとは異なるソースIPアドレスからのキープアライブメッセージを受け入れてはいけません。 IPアドレスは、初期登録要求の場合と同じでなければなりませんしながら、この要件は、偽のUDPポートへのトラフィックをリダイレクトする攻撃の範囲を制限します。
The only defenses against this vulnerability are: (1) to have a short time between re-registrations, which limits the duration of the redirection attack after the attacker has stopped sending bogus keepalive messages, and (2) to minimize the time the binding is in a "half bound" state by having the mobile node send the first keepalive message immediately after receiving an affirmative registration reply.
この脆弱性に対する唯一の防御は、（1）再登録との間の短い時間を有するように、攻撃者は偽のキープアライブメッセージの送信を停止しており、（2）時間を最小限にするために結合された後、リダイレクション攻撃の持続時間を制限しますモバイルノードを有することにより、「半結合した」状態に肯定的な登録応答を受信した直後に最初のキープアライブメッセージを送信します。
If the intermediate network is considered insecure, it is recommended that IPsec be used to protect user data traffic. However, IPsec does not protect against the redirection attacks described previously, other than to protect confidentiality of hijacked user data traffic.
中間ネットワークが安全でないとみなされる場合には、IPsecはユーザデータトラフィックを保護するために使用することをお勧めします。しかし、IPsecは乗っ取らユーザデータトラフィックの機密性を保護する以外に、前述のリダイレクション攻撃を防ぐことはできません。
The NAT traversal mechanism described in this document allows all IPsec-related traffic to go through NATs without any modifications to IPsec. In addition, the IPsec security associations do not need to be re-established when the mobile node moves.
このドキュメントで説明NATトラバーサルメカニズムは、すべてのIPsec関連のトラフィックは、IPSecへの変更なしでNATを通過することができます。モバイルノードが移動した場合また、IPsecセキュリティアソシエーションは再確立する必要はありません。
This document does not specify a general firewall traversal mechanism. However, the mechanism makes it possible to use only a single address and a port for all MN-HA (or FA-HA) communication. Furthermore, using the same port for the MIP UDP tunnelled traffic as for control messages makes it quite probable that if a MIP registration can reach the home agent, MIP tunnelling and reverse tunnelling using the described mechanism will also work.
この文書では、一般的なファイアウォールトラバーサルメカニズムを指定していません。しかし、メカニズムは、すべてのMN-HA（またはFA-HA）の通信のためにのみ単一のアドレスとポートを使用することが可能となります。 MIP登録がホームエージェント、MIPトンネリングを達することができた場合にも動作するようなメカニズムを使用してトンネリングを逆にすることを、それはかなりの可能性になり、制御メッセージ用としてさらに、MIP UDPに同じポートを使用すると、トラフィックをトンネルさ。
The mechanism described in this document is not an "UNilateral Self-Address Fixing" (UNSAF) mechanism. Although the mobile node makes no attempt to determine or use the NAT translated address, the mobile node through the registration process does attempt to keep the NAT mapping alive through refresh messages. This section attempts to address issues that may be raised through this usage through the framework of the unsaf considerations IAB document [13].
この文書で説明するメカニズムは、「一方的な自己アドレス固定」（UNSAF）メカニズムではありません。モバイルノードがNAT変換されたアドレスを決定または使用を試みませんが、登録プロセスを介して移動ノードは、リフレッシュメッセージを介して生きているNATマッピングを維持しようとする試みを行います。このセクションでは、UNSAF考慮IAB文書[13]の枠組みを通してこの使用を介して上昇させてもよい問題に対処しようと試みます。
1. Precise definition. This proposal extends the Mobile IP v4 registration process to work across intervening NATs. The Home Agent detects the presence of the NAT by examining the source address in the packet header and comparing it with the address contained in the registration message.
1.正確な定義。この提案は、介在するNATを越えて動作するモバイルIP v4の登録プロセスを拡張します。ホームエージェントは、パケットヘッダの送信元アドレスを調べ、登録メッセージに含まれるアドレスと比較することにより、NATの存在を検知します。
The NAT address and port detected by the home agent are not exported or communicated to any other node anywhere.
ホーム・エージェントによって検出されたNATアドレスとポートは、エクスポートまたはどこか他のノードに伝達されていません。
2. Exit strategy. This mechanism will go out of use as IPv6 and Mobile IP v6 is deployed, obviating the need for MIPv4 NAT traversal.
2.出口戦略。 IPv6およびモバイルIP V6として使用の外に移動します。このメカニズムは、MIPv4のNATトラバーサルの必要性をなくす、展開されています。
It can also be noted that this mechanism makes no changes to the base MIPv4 protocol which makes it dependent on the presence of NATs or the current extensions - i.e., no additional protocol changes would be needed if NATs were to go away.
NATのは、離れて行くした場合、すなわち、追加のプロトコルの変更が必要とされないであろう - また、このメカニズムはNATの存在下または現在の拡張機能に依存させ、ベースのMIPv4プロトコルを変更しませんことに注目することができます。
3. Issues making systems more brittle. The specific issue which is relevant here is that the effective care-of address (being the source address in the IP header received by the HA) is not protected by the Mobile IP authentication extension, and therefore may be spoofed. This is discussed in some detail in Section 6, Security Considerations.
システムがより脆く3.問題。ここで関連している特定の問題は、有効な気付アドレス（HAによって受信したIPヘッダの送信元アドレスである）は、モバイルIP認証拡張で保護されていないので、スプーフィングされ得ることです。これは、第6節、セキュリティについての考慮事項にある程度詳細に議論されています。
4. Requirements for longer term solutions. The trivial long term solution is a transition to an environment where NATs are not required. The most obvious such environment would be an IPv6 based internet.
長期的なソリューションのための4要件。些細な長期的な解決策は、NATのが必要とされていない環境への移行です。最も明白なこのような環境では、IPv6ベースのインターネットでしょう。
In the presence of NATs, an improved solution would require
NATの存在下で、改良された解決策は、必要とするであろう
* the ability to discover the translations done by each NAT along the route
*ルートに沿って各NATによって行わ翻訳を発見する能力
* the ability to validate the authority of each NAT to do those translations
*これらの翻訳を行うには、各NATの権限を検証する能力を
* communicating as part of the signed registration request the address of the NAT closest to the HA, for use as the effective care-of address from the viewpoint of the HA.
* HAの観点から有効な気付アドレスとして使用するために、署名された登録要求をHAに最も近いNATのアドレスの一部として通信します。
* configuration of all intermediate NATs to accept only packets from the neighbour NATs.
*すべての中間のNATの設定は、隣人のNATからのパケットのみを受け入れます。
5. Impact on existing, deployed NATs. One precursor of the mechanism described here has been used successfully across deployed NATs in Sweden, Germany, England, Japan and the USA, without necessitating neither adjustments of the NATs in question, nor adjustment of any protocol parameters. At the time of writing, little experience exist with the exact implementation proposed in this document, but effort has been put into making this mechanism even more robust and adaptive than its precursors.
既存5.インパクトは、NATのを導入しました。ここで説明するメカニズムの一つの前駆体は、問題のNATのどちらの調整を必要とせず、スウェーデン、ドイツ、イングランド、日本と米国で展開NATを越えて正常に使用、また任意のプロトコルパラメータの調整されています。執筆時点では、少しの経験は、この文書で提案されている正確な実装に存在しますが、努力は、このメカニズムは、より堅牢でその前駆体よりも適応することに置かれています。
With respect to the base Mobile IP specification, the impact of this document is that an increased frequency of registration requests is recommended from a security perspective when the NAT traversal mechanism is used.
ベースのモバイルIP仕様に関しては、このドキュメントの影響は、NATトラバーサルメカニズムが使用される場合、登録要求の頻度の増加は、セキュリティの観点から推奨されることです。
The numbers for the extensions defined in this document have been taken from the numbering space defined for Mobile IP messages, registration extensions and error codes defined in RFC 3344 [10]. This document proposes one new message, two new extensions and a new error code that require type numbers and an error code value that have been assigned by IANA. The two new extensions also introduce two new sub-type numbering spaces to be managed by IANA.
この文書で定義された拡張の数字は、モバイルIPメッセージ、登録拡張およびRFC 3344 [10]で定義されたエラーコードに対して定義されたナンバリング空間からとられています。この文書では、つの新しいメッセージ、二つの新しい拡張機能やタイプ番号とIANAによって割り当てられているエラーコード値を必要とする新しいエラーコードを提案しています。 2つの新しい拡張機能もIANAによって管理される2つの新しいサブタイプのナンバリングスペースをご紹介します。
Section 3.1 defines a new Mobile IP extension, the UDP Tunnel Request Extension. The type number for this extension is 144. This extension introduces a new sub-type numbering space where the value 0 has been assigned to this extension. Approval of new Tunnel Request Extension sub-type numbers is subject to Expert Review, and a specification is required [7].
3.1節では、新たなモバイルIP内線、UDPトンネル要求拡張を定義します。この拡張のタイプ番号は144である。この拡張は、値0は、この拡張に割り当てられた新たなサブタイプの番号空間を導入します。新しいトンネル要請拡張サブタイプ番号の承認は、専門家レビューの対象であり、仕様が必要とされる[7]。
Section 3.2 defines a new Mobile IP extension, the UDP Tunnel Reply Extension. The type value for this extension is 44. This extension introduces a new sub-type numbering space where the value 0 has been assigned to this extension. Approval of new Tunnel Reply Extension sub-type numbers is subject to Expert Review, and a specification is required [7].
3.2節では、新たなモバイルIP内線、UDPトンネル返信拡張を定義します。この拡張のタイプ値は44である。この拡張は、値0は、この拡張に割り当てられた新たなサブタイプの番号空間を導入します。新しいトンネル返信拡張サブタイプ番号の承認は、専門家レビューの対象であり、仕様が必要とされる[7]。
Section 3.3 defines a new Mobile IP message, the Tunnel Data message. The type value for this message is 4.
3.3節では、新たなモバイルIPメッセージ、トンネルデータメッセージを定義します。このメッセージのタイプ値は4です。
Section 3.5 defines a new error code, ERROR_HA_UDP_ENCAP_UNAVAIL: "Requested UDP tunnel encapsulation unavailable", from the numbering space for values defined for use with the Code field of Mobile IP Registration Reply Messages. Code number 142 has been assigned from the subset "Error Codes from the Home Agent".
3.5節は、新しいエラーコード、ERROR_HA_UDP_ENCAP_UNAVAILを定義します。モバイルIP登録応答メッセージのコードフィールドで使用するために定義された値の番号空間から、「使用できないUDPトンネルカプセル化を要求しました」。コード番号142は、サブセット「ホームエージェントからのエラーコード」から割り当てられています。
The values for the Next Header field in the MIP Tunnel Data Message (Section 3.3) shall be the same as those used for the Protocol field of the IP header [2], and requires no new number assignment.
MIPトンネルデータメッセージのNext Headerフィールド（セクション3.3）の値は、[2] IPヘッダのプロトコルフィールドに使用されるものと同じであり、新たな番号の割り当てを必要としないものとします。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights (www.ietf.org/ipr.html).
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、特許請求権（www.ietf.org/ipr.html）のオンラインリストを参照してください。
Much of the text in Section 4.2 has been taken almost verbatim from RFC 2003, IP Encapsulation within IP [4].
4.2節内のテキストの多くは、[4] IP内IPカプセル化、RFC 2003からほとんど逐語的に撮影されています。
Adding support for the FA case was suggested by George Tsirtsis and Frode B. Nilsen. Roy Jose pointed out a problem with binding updates, and Frode, Roy and George pointed out that there are cases where triangular routes may work, and suggested that reverse tunnelling need not be mandatory. Roy and Qiang Zhang drew attention to a number of sections which needed to be corrected or stated more clearly.
FAの場合の追加サポートはジョージTsirtsisとフローデ・B.ニルセンによって示唆されました。ロイ・ホセは、バインディングアップデートに問題があることを指摘し、フローデ、ロイとジョージは三角形のルートが動作する可能性例があることを指摘し、逆トンネリングが必須である必要がないことが示唆されました。ロイと強張を修正またはより明確に記載すべき必要なセクションの数に注意を喚起しました。
Phil Roberts helped remove a number of rough edges. Farid Adrangi pointed out the DoS issue now covered in Security Considerations (Section 6). Francis Dupont's helpful comments made us extend the Security Considerations section to make it more comprehensive and clear. Milind Kulkarni and Madhavi Chandra pointed out the required match between the FA source and care-of addresses when the mechanism is used by an FA, and also contributed a number of clarifications to the text.
フィル・ロバーツは、荒削りの番号を削除助けました。ファリドAdrangiは現在、セキュリティに関する注意事項（第6節）でカバーされたDoS問題を指摘しました。フランシス・デュポンの有益なコメントは、私たちはそれがより包括的かつ明確にするためにSecurity Considerations部を拡張しました。本部Milind Kulkarniさんとマダビチャンドラ機構がFAで使用されるときFA源と気付アドレスとの間の必要な一致を指摘し、また、テキストに明確化の数に貢献しました。
Thanks also to our co-workers, Ilkka Pietikainen, Antti Nuopponen and Timo Aalto at Netseal and Hans Sjostrand, Fredrik Johansson and Erik Liden at ipUnplugged. They have read and re-read the text, and contributed many valuable corrections and insights.
また、私たちの同僚、イルッカPietikainen、アンティNuopponenとNetsealでティモ・アアルトとハンスSjostrand、フレドリック・ヨハンソンとipUnpluggedでエリックLidenに感謝します。彼らは読んでテキストを再読み込み、および多くの貴重な修正や洞察力を貢献してきました。
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[1]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[2]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[3] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[3]ハンクス、S.、李、T.、ファリナッチ、D.とP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 1701、1994年10月。
[4] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[4]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[5] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[5]パーキンス、C.、 "IP内の最小カプセル化"、RFC 2004、1996年10月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[7] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[8] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[8]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.とP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[9] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[9]モンテネグロ、G.、 "改訂モバイルIPのためのリバーストンネリング、"、RFC 3024、2001年1月。
[10] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[10]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[11] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[11] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[12] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[12] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[13] Daigle, L., Editor, and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF)", RFC 3424, November 2002.
[13] Daigle氏、L.、エディタ、およびIAB、 "一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）"、RFC 3424、2002年11月。
Henrik Levkowetz ipUnplugged AB Arenavagen 23 Stockholm S-121 28 SWEDEN
ヘンリックLevkowetz ipUnplugged AB Arenavagen 23ストックホルムS-121 28 SWEDEN
Phone: +46 708 32 16 08 EMail: henrik@levkowetz.com
電話：+46 708 32 16 08 Eメール：henrik@levkowetz.com
Sami Vaarala Netseal Niittykatu 6 Espoo 02201 FINLAND
サミVaarala Netsealメドーストリート6 02201エスポーフィンランド
Phone: +358 9 435 310 EMail: sami.vaarala@iki.fi
電話：+358 9 435 310 Eメール：sami.vaarala@iki.fi
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。