[要約] 要約：RFC 3519は、モバイルIPがネットワークアドレス変換（NAT）デバイスを通過する方法について説明しています。 目的：このRFCの目的は、モバイルIPを使用してNATデバイスを通過するためのプロトコルと手順を提案することです。
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
ネットワークアドレス変換（NAT）デバイスのモバイルIPトラバーサル
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.
Copyright（c）The Internet Society（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プロトコルの拡張機能と、モバイルIPを使用してモバイルノードを使用して、NATデバイスによってパブリックインターネットから分離されたプライベートアドレスネットワークで動作できるトンネルメソッドを提示します。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は、2つの種類のNATです。
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].
BASIC NAT "Basic 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クエリ識別子など）を翻訳することにより、翻訳の概念をさらに1つのステップに拡張します。これにより、多くのプライベートホストの輸送識別子を単一の輸送識別子の輸送識別子に多重化することができます。外部アドレス。NAPTでは、一連のホストが単一の外部アドレスを共有できます。NAPTをBasic 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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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-in-IPトンネルを介して、ホームネットワークからモバイルノードまたは外国人エージェントにトラフィックを送信することに依存しています。NATの後ろから通信するIPノードは、NATのパブリックアドレス（ES）からのみ到達可能です。IP-in-IPトンネリングには、一般に、一般的なパブリックアドレス（ES）からNATの後ろにあるモバイルノードまたは外国人エージェントの特定のケアのケアへの一意の翻訳を許可するのに十分な情報は含まれていません。特に、NATが操作できるTCP/UDPポート番号はありません。このため、IP-in-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の登録リクエストと返信は、NATまたはNAPTの内側から発信されたUDPデータグラムであるため、モバイルノードまたは外国のエージェント側の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を使用して共同配置アドレスを備えたモバイルノードは、登録がFAを通過することを要求します（モバイルノードとFAの両方が同じNATの後ろにある場合があります。
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トンネリングの代わりにモバイルIP UDPトンネルを使用できることを示すことができます。NATを通過しました。ホームエージェントは、受け入れ（または拒否）を示す拡張機能を備えた登録返信を送信できます。ホームエージェントからの同意の後、MIP UDPトンネルは、前方トンネルと逆トンネリングの両方に使用できます。モバイルノードから送信されたUDPトンネルパケットは、登録要求メッセージと同じポートを使用します。特に、ソースポートは新しい登録によって異なる場合がありますが、すべてのトンネルデータと再登録で同じままです。宛先ポートは常に434です。Homeエージェントが送信したUDPトンネルパケットは、同じポートを使用しますが、逆です。
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トンネルを介して送信されます。モバイルノードは、その裁量で逆トンネルのためにUDPトンネルを使用するかどうかを使用する場合がありますが、ほとんどの場合、MIP 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 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のエージェント広告に設定されたことを示します。登録は、Co-Located Care of Addressを使用して行われていますが、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トンネルリクエストの延長を理解していない場合、それは静かに廃棄し、他のすべてが問題ない場合は、Reply Code 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.
「予約済み1」および「予約済み2」フィールドは受領時に無視する必要がありますが、「予約された3」フィールドは受信時に0でなければなりません。そうしないと、この拡張機能は理解されていないと静かにスキップする必要があります。これにより、古い実装と共存できるか、古い実装から拡張機能を強制することができるこの拡張機能への将来の追加が可能になります。
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-in-UDPトンネリング）RFC 2003 [4]
47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]
47 GREヘッダー（GRE-IN-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、M、G、Tは、RFC 3344 [10]およびRFC 3024 [9]に記載されているように、その意味を保持しています（MおよびGビットの重要性がカプセル化によって変更される可能性があることを除きます上記のように、MIP UDPトンネルが使用されるときのフィールド）。MIP UDPトンネリングとMIPおよび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).
MNとFAの両方が、MIP UDPトンネルを要求するときに「T」ビットを設定する必要があります。これにより、逆トンネリングを受け入れる準備ができていないHAが登録を受け入れないことが保証されます。また、外国のエージェントに関する「T」ビットの使用に関する議論（セクション4.5）も参照してください。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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アセントまたは現在のモビリティ結合に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.
Keepalive間隔は、モバイルノードが使用するNAT Keepalive間隔を指定します。キープライブ間隔秒がシグナリングやデータトラフィックが送信されずに経過した場合は、キープライブパケットを送信する必要があります。このフィールドが0に設定されている場合、モバイルノードはデフォルトの設定されたKeepAliveインターバルを使用する必要があります。
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で使用されます。範囲の値0 .. 63は同意を示します。つまり、トンネリングが行われることを示します。一方、範囲64 .. 255の値は、トンネリングを実行すべきではないことを示します。より多くの情報が、応答コードの値によって提供される場合があります。
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メッセージヘッダーは、よく知られているポート434を介して他のモバイルIPメッセージ、たとえば登録リクエストや登録返信からトンネルのトラフィックを区別するのに役立ちます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4 Next Header Indicates the type of tunnelled data, using the same numbering as the IP Header Protocol Field.
タイプ4次のヘッダーは、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-in-UDPトンネリング）RFC 2003 [4]
47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]
47 GREヘッダー（GRE-IN-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].
RFC 3344 [10]で定義されているモビリティエージェント広告拡張機能の唯一の変更は、エージェント広告を生成する外国人エージェントが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 |
| ... |
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:
1つの新しい登録返信コードが定義されています。
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.
これは、HAが使用して、「M」または「G」ビットとともに「T」ビットを使用することにより要求された利用できない標準トンネルカプセル化によって引き起こされる拒否によって引き起こされる拒否から生じるUDPトンネルカプセル化モードから引き起こされる登録拒否を区別するために使用されます。
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-in-UDPカプセル化です。モバイルノードは、モバイルIP登録リクエストの「M」ビットおよび/または「G」ビットを設定するか、MIP UDPトンネルの特定のカプセル化をMIP UDPトンネルの特定のカプセル化を明示的に要求して、UDPトンネルで使用する代替形式のカプセル化を要求する場合があります。カプセル化フィールドを使用します。MおよびGビットは、MIP UDPトンネルのコンテキスト内でRFC 3344 [10]で説明されているように意味を保持します。クラシック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」ビットが登録要求で設定され、カプセル化フィールドがゼロの場合、モバイルノードは、モバイルノードにトンネルしたデータグラムにホームエージェントがGREカプセル化[3]を使用することを要求します。MIP UDPトンネルも要求され、受け入れられた場合、MIP UDPトンネルが要求されていない場合、IPカプセル化のGREと同じケースでGRE-in-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トンネルも使用される場合、MIP UDPトンネルが要求されていない場合、RFC 2004 [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で拒否される必要があります。このエラーを受け取ったとき、モバイルノードは、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-in-UDPトンネル、または略してUDPトンネルは、UDPヘッダー[1]の追加を除き、RFC 2003 [4]でIP-in-IPトンネルについて説明した方法に類似した方法で行われます[1]外側と内的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-in-UUDPトンネルが有効である場合でもトンネルを抑えてはなりません。
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-in-UDPカプセル化を使用してIPデータグラムをカプセル化するには、外部IPヘッダー[2]、UDPヘッダー[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ヘッダーソースアドレスと宛先アドレスは、それぞれデータグラムの元の送信者と受信者を識別します。内側のIPヘッダーは、RFC 2003 [4]に記載されているようにデータグラムの転送の一部としてトンネリングが行われている場合、TTLを1つずつ減らすことを除いて、カプセレータによって変更されません。。内側のヘッダーの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のカプセル化は、最小限のカプセル化の場合はRFC 2004 [5]、GREカプセル化にはRFC 2784 [8]に従って、外部IP、UDP、およびMIPヘッダーを使用して外側IPヘッダーの代わりに使用して、同様に行われます。
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]の他のすべての規定と要件は、1つの点で、パケットの断片化でカバーされていることを除いて有効です（セクション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ポート番号がトンネルに使用される値と正確に一致することを確認する必要があります。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-in-UUDPカプセル化されたトラフィックは、外側の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.
RFC 3344 [10]のセクション3.2および3.6.1.3によると、モバイルノードは、モバイルホーム認証拡張機能の前にこの拡張機能を配置する必要があります。そうすれば、モバイルホーム認証拡張機能でカバーされます。
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を使用するために、トンネル要求拡張機能を要求します。この場合、モバイルノードは、登録が受け入れられるとすぐにキープライブを送信する必要があります。
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.
UDPトンネルリクエスト延長は、外国人エージェントがNATの後ろに位置する場合、またはMIP UDPトンネリングを必要とする他の説得力のある理由がある場合、モバイルIP登録要求をホームエージェントに転送しているときに、外国人エージェントが使用することができます。
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.
エージェント広告に「R」ビットを設定して外国人エージェントを介してモバイルノードを登録する必要がある外国人エージェントは、共同住宅のケアのケアのケアを使用する登録要求を転送するときにUDPトンネルリクエスト拡張機能を追加してはなりません。これにより、モバイルノードではなく、ホームエージェントから外国人エージェントに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.
RFC 3344 [10]のセクション3.2および3.7.2.2によると、この拡張機能を使用する場合は、登録メッセージのモバイルホーム認証拡張機能の後に配置する必要があります。外国人エージェントがホームエージェントとモビリティセキュリティ協会を共有し、したがって、外国の在宅認証拡張機能を追加する場合、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.
ホームエージェントが送信者とそれ自体の間のパスにNATの存在を検出すると、IPソースアドレスと登録リクエストで与えられたケアのケアの間の不一致を確認することで、これを使用する場合は外国人エージェントが必要です拡張機能は、登録リクエストを送信して、Care of Addressに一致する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.
FAはNATの後ろに位置するため、NATの特性に応じて、FAがNATの後ろに位置するか、逆トンネリングを促進するか、それについて中立にするように構成される可能性があるため、外国人エージェントがホームエージェントに使用されます。NATが発信パケットのすべてのソースアドレスを独自のパブリックアドレスに翻訳する場合、モバイルノードが逆トンネリングの代わりに三角形のルーティングを使用している場合、このネットワークから離れるときにセッションを維持することはできません。一方、NATが公開されているソースアドレスを翻訳しないほどスマートであり、侵入フィルターを実行しないことがわかっている場合、三角形のルーティングが成功する可能性があります。ホームエージェントから外国人エージェントへの脚は、MIP UDPトンネルを使用してNATを通過します。
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の背後にある外国人エージェントを構成するときにNATがパブリックとプライベートアドレスを翻訳することがわかっている場合、またはイングレスフィルタリングがプライベートネットワークとパブリックネットワークの間で行われていることが知られている場合、外国人エージェントは登録に返信する必要があります返信コード75で「t」ビットが設定されていないリクエスト「リバーストンネルは必須であり、「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がパブリックアドレスを翻訳しておらず、イングレスフィルタリングが行われないことについてNATがスマートであることがわかっている場合、公開されているアドレスを持つモバイルノードがORに移動するときにセッションを維持できる可能性があると信じるのは合理的です。このネットワークから、「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の動作がこの点で不明な場合は、すべてのアドレスを翻訳することを想定する必要があります。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アドレスとモバイルIP登録要求メッセージのケアのケアの間の不一致を使用する必要があります。登録要求に「R」フラグセットなしのUDPトンネルリクエスト延長も含まれており、ホームエージェントがMIP UDPトンネリングを許可することができる場合、ホームエージェントは、同意する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.
ホームエージェントが、MIP UDPトンネルリクエスト延長を含む一致するソースIPアドレスと共同配置されたケアオブアドレスを備えた登録要求を受け取った場合、ホームエージェントは、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トンネルに同意する場合、登録要求のケアのケアのケアではなく、登録リクエストのソースアドレスを効果的なケアアドレスとして使用する必要があります。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.
HomeエージェントがUDPトンネルリクエスト拡張機能に「R」フラグが設定された登録要求を受け取った場合、MIP UDPトンネリングが可能である場合は、UDPトンネル応答拡張を同意することで返信する必要があります。ただし、この場合、登録要求のソースアドレスとポートは、外国のエージェントソースアドレスとポートのNAT'edバージョンである場合があります。トンネルトラフィックをモバイルノードに正しく向けるために、ホームエージェントは、モバイルノードから最初のキープライブパケットが到着するのを待つ必要があります。。この場合、ホームエージェントは、このKeepAliveパケットの外側のソースアドレス（ポートではなく）が、対応する登録要求のソースアドレスと同一であることを確認する必要があります。内側のソースアドレス（カプセル化された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トンネルリクエストの拡張機能を理解し、そのようなリクエストに積極的に応答する準備ができているホームエージェントは、MIP UDPトンネルの使用がセッションに示されていない場合、Repling Replyコードを含む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トンネルリクエスト拡張機能（MN-HA認証拡張子の前に配置）が、登録リクエストヘッダーの「d」ビットが設定されていません。
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.
ホームエージェントは、セクション3.5で定義されているudpトンネルカプセル化が利用できないudpトンネルのカプセル化を要求した "要求された" erry_ha_udp_encap_unavailに設定されたコードフィールドで登録返信を送信する必要があります。
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-in-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トンネルバインディングは、非UUDPトンネルバインディングと混合される場合があります）。
- 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."
「NAPTセットアップにおけるアウトバウンドTCP/UDPフラグメント（つまり、プライベートホストから発生したもの）の翻訳は失敗する運命にあります。理由は次のとおりです。最初のフラグメントのみにのみ、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.
このため、何らかの理由でモバイルノードまたは外国エージェントが断片化されたパケットを送信する必要がある場合、カプセル化の前に断片化を行う必要があります。これは、IP-in-IPトンネルのケースとは異なります。この場合、カプセル化の前後に断片化が行われる可能性がありますが、RFC 2003 [4]はカプセル化前に行うことを推奨しています。
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.
NATを通る双方向UDPトンネルの存在は、RFC 2663 [11]で説明されているように、セッションに関連するNATを維持する状態情報に依存し、NATは一定の時間後にセッションが終了したと決定する可能性があるため、トンネルを開いたままにしておくために、キープライブメッセージが必要になる場合があります。Keepaliveは、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トンネルのセットアップに使用される拡張機能には、デフォルト値よりも別の値にKeepAliveメッセージ間隔を設定するオプションがあります。セクション3.2を参照してください。
The keepalive message sent MUST consist of a properly UDP encapsulated ICMP echo request directed to the home agent.
送信されたKeepAliveメッセージは、ホームエージェントに向けられた適切に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).
UDPトンネルが確立されている各モビリティバインディングについて、モバイルIP UDPトンネルの非HAエンドポイントは、K秒でHAに他のパケットが送信されていない場合、KeepAliveパケットを送信する必要があります。ここで、kはデフォルト値が110秒のパラメーターです。Kは、UDPトンネルの応答拡張に記載されているように、HAによって別の値に設定される場合があります（セクション3.2）。
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秒で最初のKeepAliveメッセージを送信します。元の登録メッセージやデータメッセージに使用されたのと同じ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エコーリクエスト/返信メッセージで構成される双方向のキープライブを使用する必要があります。双方向のkeepAlivesを使用するための理論的根拠は2つあります。
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から送信されたキープライブですが、ホームエージェントからの返信がない）は、実際にはより多くのキープアライブなトラフィックを引き起こします。KeepAliveメッセージは、キープライブメッセージの時折の喪失を補うために、より頻繁に送信する必要があります。対照的に、双方向のkeepAlivesは認められ、再送信は、合理的な時間内にキープライブの要求に対して応答が受信されない場合にのみ発生します。
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エコーリクエスト/返信メッセージをKeepAlivesとして使用している場合、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秒未満のKeepAliveを使用してはなりません。
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の背後に自分自身を見つける場合、元のKeepaliveインターバル（デフォルト値、またはホームエージェントによって割り当てられた）に戻る必要があり、NATマッピングの損失を発見しない限り、Keepalive Interval補正を行うべきではありません。新しい環境で。
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トンネルを使用している外国人エージェントに限られた意味でのみ適用されます。この場合、FAを永続的に構成して、異なるNATの結合寿命に動的に適応しようとするのではなく、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.
このセクションでは、FA広告が「R」ビットセットを搭載しているため、外国人エージェントを介してモバイルノードが登録されたときに、モバイルノードが登録されたときにケースを処理およびサポートするために必要なプロトコルの詳細を要約します。背景情報を提供しますが、新しい要件はリストされていません。
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-Headerのソースアドレスと比較して、登録リクエストに異なるケアのケアを行います。登録要求にもUDPトンネルリクエスト拡張機能が含まれている場合、HAは誤ってUDPトンネルをセットアップします。これはMNの代わりにFAに送られます。このため、セクション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トンネリングを使用できるようにするために、セクション3.4で説明されているように、NATの後ろにある外国人エージェントは「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広告に「u」ビットセットがあり、それがNATの背後にあることを示し、また「R」ビットセットを示し、モバイルノードが共同住宅のケアのケアを使用したい場合、それは 'を設定する必要があります。セクション4.4で説明されているように、HAに適切に動作するように、HAにHAに通知するために、UDPトンネルリクエスト拡張のr 'フラグ。
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トンネルは登録要求以外の別のパスを取得しているため、ホームエージェントは、このタイプの登録を処理するときに、正しいアドレスとポートにトンネルをセットアップできるようにする前に、最初のKeepAliveパケットが到着するまで待つ必要があります。偽のソースアドレスでKeepaliveを送信することでトンネルハイジャックの可能性を減らすために、KeepAliveパケットのポートのみが登録要求のポートとは異なる場合があります。ソースアドレスは同じでなければなりません。これは、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.
プライベートネットワークはオーバーラップアドレススペースを使用しているため、状況によっては互いに間違っている場合があります。これは、このドキュメントでエイリアシングのプライベートアドレスと呼ばれます。このため、この仕様を実装するモバイルノードがパケットの送信に使用されるゲートウェイのリンクレイヤーアドレス（es）を監視する必要がある場合があります。リンクレイヤーアドレスの変更は、新しいリンクレイヤーアドレスを使用して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、NetMask 255.0.0.0、およびGateway 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).
まれに、モバイルノードは、使用しているゲートウェイのリンクレイヤーアドレスを監視できない可能性があり、したがって、あるポイントのアタッチメントを別のポイントと混同する可能性があります。この仕様では、この問題に明示的に対処しません。この状況によって引き起こされる潜在的なトラフィックの停電は、モビリティ結合の寿命が十分に短くなることを保証することで制限される可能性があります。モビリティ結合の有効期限によって引き起こされる再登録により、問題は修正されます（セクション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.
短い寿命が有用な2番目のケースは、プライベートネットワークアドレスのエイリアシングに関連しています。モバイルノードがモビリティを検出できず、新しいNATデバイスの後ろに終わる場合（セクション5.1で説明されているように）、短い寿命により、トラフィックブラックアウトが非常に長くなく、再登録によって終了することが保証されます。。
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がなければ、登録リクエストのケアオブアドレスがHAによって直接使用され、MN（またはFA）にトラフィックを送り返し、住所の世話はMN-HAによって保護されます（またはFA-HA）認証拡張機能。NATを横切って通信する場合、HAの観点からの効果的なケアのケアは、NATのそれであり、認証拡張機能によって保護されていませんが、受信したパケットの見かけのIPソースアドレスから推測されます。これは、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).
Co-Located Care of Addressを使用してFAを介して登録すると、別のリダイレクトの脆弱性が開きます。登録リクエスト/返信メッセージをFAを介してHAとの回答メッセージを交換した後、MNは最初のKeepALiveメッセージをHAに送信することが期待されているため、モビリティバインディングが最終的になります（バインディングは、KeepAliveが受信されるまで「ハーフバインド」状態のままです。）。
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アドレスからキープライブメッセージを受け入れてはなりません。この要件により、攻撃の範囲は、トラフィックを偽のUDPポートにリダイレクトしますが、IPアドレスは最初の登録要求と同じままでなければなりません。
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）拘束力のある時間を最小化するために（2）モバイルノードに肯定的な登録返信を受け取った直後に最初のKeepAliveメッセージを送信することにより、「ハーフバウンド」状態で。
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 UDPトンネルトラフィックに同じポートを使用すると、コントロールメッセージと同じように、MIP登録がホームエージェントに到達できる場合、記載されたメカニズムを使用したMIPトンネルと逆トンネリングも機能します。
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. 正確な定義。この提案は、モバイルIP V4登録プロセスを拡張して、介在するNATを横切って動作します。ホームエージェントは、パケットヘッダーのソースアドレスを調べ、登録メッセージに含まれるアドレスと比較することにより、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の存在または現在の拡張機能に依存するベースMIPV4プロトコルに変更を加えないことに注意することもできます。つまり、NATがなくなった場合、追加のプロトコルの変更は必要ありません。
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への影響。ここで説明するメカニズムの1つの前駆体は、問題の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.
このドキュメントで定義されている拡張機能の数字は、RFC 3344 [10]で定義されているモバイルIPメッセージ、登録拡張機能、エラーコードのために定義された番号付けスペースから取得されています。このドキュメントでは、1つの新しいメッセージ、2つの新しい拡張機能、および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トンネルReply拡張機能を定義しています。この拡張機能のタイプ値は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では、モバイルIP登録応答メッセージのコードフィールドで使用するために定義された値の番号付けスペースから、新しいエラーコード、ERROR_HA_UDP_ENCAP_UNAVAIL：「要求された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トンネルデータメッセージ（セクション3.3）の次のヘッダーフィールドの値は、IPヘッダー[2]のプロトコルフィールドに使用されている値と同じであり、新しい番号割り当ては必要ありません。
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のテキストの多くは、RFC 2003、IP内のIPカプセル化からほぼ逐語的に撮影されています[4]。
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ケースのサポートを追加することは、George TsirtsisとFrode B. Nilsenによって提案されました。ロイ・ホセは、バインディングの更新に関する問題を指摘し、Frode、Roy、Georgeは、三角形のルートが機能する場合がある場合があることを指摘し、逆トンネリングは必須ではないことを示唆しました。RoyとQiang Zhangは、より明確に修正または述べる必要がある多くのセクションに注意を向けました。
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.
フィル・ロバーツは、いくつかの荒いエッジを削除するのを手伝いました。Farid Adrangiは、現在セキュリティの考慮事項でカバーされているDOS問題を指摘しました（セクション6）。フランシス・デュポンの有用なコメントにより、セキュリティ上の考慮事項を拡張して、より包括的かつ明確にしました。Milind KulkarniとMadhavi Chandraは、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.
同僚であるイルッカ・ピエティカイネン、アントティ・ヌオプポネン、ティモ・アールト、イプンプルーグのイルッカ・ヌプポネンとティモ・アールト、ハンス・ヨハンソン、エリック・ライデンにも感謝します。彼らはテキストを読んで読み直し、多くの貴重な修正と洞察を提供しました。
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[1] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[2] Postel、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] Hanks、S.、Li、T.、Farinacci、D。およびP. Traina、「一般的なルーティングカプセル化（GRE）」、RFC 1701、1994年10月。
[4] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[4] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[5] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[5] Perkins、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、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] Perkins、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. Holdrege、「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
Henrik Levkowetz Ipunplugged AB Arenavagen 23 Stockholm S-121 28 Sweden
Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com
Sami Vaarala Netseal Niittykatu 6 Espoo 02201 FINLAND
SAMI VAARALA NETSEAL NIITTYKATU 6 ESPOO 02201フィンランド
Phone: +358 9 435 310
EMail: sami.vaarala@iki.fi
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。