RFC3519 日本語訳
3519 Mobile IP Traversal of Network Address Translation (NAT) Devices.H. Levkowetz, S. Vaarala. April 2003. (Format: TXT=80522 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Levkowetz
Request for Comments: 3519 ipUnplugged
Category: Standards Track S. Vaarala
Netseal
April 2003
Levkowetzがコメントのために要求するワーキンググループH.をネットワークでつないでください: 3519はカテゴリをipUnpluggedしました: 標準化過程S.Vaarala Netseal2003年4月
Mobile IP Traversal of Network Address Translation (NAT) Devices
ネットワークアドレス変換(NAT)装置のモバイルIP縦断
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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のデータグラムトンネルはNetwork Address Translation(NAT)と非互換です。 このドキュメントはNAT装置によって公共のインターネットと切り離されるプライベート・アドレスネットワークで作動するのにモバイルIPを使用することで可動のノードを可能にするモバイルIPプロトコルとトンネル方法に拡大を提示します。 NAT縦断は要約のデータ通信量にモバイルIPホームエージェントUDP港を使用するのに基づいています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problem description . . . . . . . . . . . . . . . . . . 3
1.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . 4
2. NAT Traversal Overview. . . . . . . . . . . . . . . . . . . . 5
2.1 Basic Message Sequence. . . . . . . . . . . . . . . . . 5
3. New Message Formats . . . . . . . . . . . . . . . . . . . . . 6
3.1 UDP Tunnel Request Extension. . . . . . . . . . . . . . 6
3.1.1 F (Force) Flag. . . . . . . . . . . . . . . . . . 7
3.1.2 R (Registration through FA Required) flag . . . . 8
3.1.3 Reserved Fields . . . . . . . . . . . . . . . . . 8
3.1.4 Encapsulation . . . . . . . . . . . . . . . . . . 8
3.1.5 Mobile IP Registration Bits . . . . . . . . . . . 9
3.2 UDP Tunnel Reply Extension. . . . . . . . . . . . . . . 9
3.2.1 Reply Code. . . . . . . . . . . . . . . . . . . . 10
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 1.1Terminology. . . . . . . . . . . . . . . . . . . . . . 2 1.2Problem記述. . . . . . . . . . . . . . . . . . 3 1.3Assumptions. . . . . . . . . . . . . . . . . . . . . . 4 2。 NAT縦断概観。 . . . . . . . . . . . . . . . . . . . 5 2.1 基本的なメッセージ系列。 . . . . . . . . . . . . . . . . 5 3. 新しいメッセージ・フォーマット. . . . . . . . . . . . . . . . . . . . . 6 3.1UDPは要求拡張子にトンネルを堀ります。 . . . . . . . . . . . . . 6 3.1 .1F(力)が弛みます。 . . . . . . . . . . . . . . . . . 7 3.1 .2 R(FA Requiredを通した登録)旗の.83.1.3Reservedフィールズ.83.1.4Encapsulation. . . . . . . . . . . . . . . . . . 8 3.1.5のモバイルIP Registration Bits.93.2UDP Tunnel Reply Extension。 . . . . . . . . . . . . . . 9 3.2 .1 回答コード。 . . . . . . . . . . . . . . . . . . . 10
Levkowetz & Vaarala Standards Track [Page 1] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[1ページ]。
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
3.3 MIPはエージェント広告. . . . . . 11 3.5新規登録回答コードでデータメッセージ. . . . . . . . . . . . . . . . 10 3.4UDPトンネル旗にトンネルを堀ります。 . . . . . . . . . . . . . 12 4. ふるまいについて議定書の中で述べてください。 . . . . . . . . . . . . . . . . . . . . . 12 4.1 UDP. . . . . . . . . . . . 13 4.3Decapsulation. . . . . . . . . . . . . . . . . . . . . 15 4.4のモバイルNode Considerationsの.124.2Encapsulating IP Headersにトンネルを堀る標準のMIPとの関係。 . . . . . . . . . . . . . . 15 4.5 外国エージェント問題。 . . . . . . . . . . . . . 16 4.6 ホームエージェント問題. . . . . . . . . . . . . . . 18 4.6.1エラー処理。 . . . . . . . . . . . . . . . . . 19 4.7 トンネルに対して合図するMIP。 . . . . . . . . . . . 20 4.8 パケット断片化。 . . . . . . . . . . . . . . . . . 21 4.9はKeepaliveにトンネルを堀ります。 . . . . . . . . . . . . . . . . . . . 21 4.10 NATマッピングの損失を検出して、補います。 . . 22 4.11はFAを通した登録の共同場所を見つけました。 . . . . . . . . . . 24 5. 実現は、.245.1運動に検出を発行して、移動性の拘束力がある生涯. . . . . . . . . . . . . . . 25 6をプライベート・アドレスエイリアシング. . . . 24 5.2に発行します。 登録要求メッセージ. . . . . . . . . . . . . . . . . 27 6.1.2がにせのKeepaliveメッセージ. . . . . . . . 27 6.2を送る.276.1.1操作が使用するIPsecのセキュリティ問題. . . . . . . . . . . . . . . . . . . 26 6.1交通リダイレクション脆弱性。 . . . . . . . . . . . . . . . . . . . . . 28 6.3 ファイアウォール問題. . . . . . . . . . . . . . . . 28 7。 UNSAF問題。 . . . . . . . . . . . . . . . . . . . . 28 8. IANA問題. . . . . . . . . . . . . . . . . . . . . 30 9。 知的所有権はまっすぐになります。 . . . . . . . . . . . . . . . . 30 10. 承認。 . . . . . . . . . . . . . . . . . . . . . . 31 11. 引用規格。 . . . . . . . . . . . . . . . . . . . . 31 12. 有益な参照。 . . . . . . . . . . . . . . . . . . . 32 13. 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . 33 14. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 34
1. Introduction
1. 序論
1.1 Terminology
1.1 用語
The Mobile IP related terminology described in RFC 3344 [10] is used in this document. In addition, the following terms are used:
RFC3344[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.
前方に、Tunnel Aはそんなに前方に可動のノードに向かってパケットにトンネルを堀ります。 It starts at the home agent, and ends at the mobile node's care-of address.
Levkowetz & Vaarala Standards Track [Page 2] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[2ページ]。
Reverse Tunnel
A tunnel that starts at the mobile node's care-of address and
terminates at the home agent.
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では、セッションは、uni方向上であって、私設のネットワークから外国行きです。」 -- RFC2663[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].
基本的なNATは「Basic NAT、ブロックの外部アドレスで、傍らに彼らが外部のドメインにセッションを溯源するので個人的なドメインでホストのアドレスを翻訳するのに設定されます」。 私設のネットワークからの外国行きのパケットに関しては、IPや、TCPや、UDPやICMPヘッダーチェックサムなどのソースIPアドレスと関連分野は翻訳されます。 「本国行きのパケットに関して、送付先IPアドレスと上に記載されているチェックサムは翻訳されます。」 -- RFC2663[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は、より遠くにまた、輸送識別子を翻訳することによって1ステップで翻訳の概念について敷衍しています(例えば、TCPとUDPは数を移植します、ICMP質問識別子)。」 これは、多くの個人的なホストの輸送識別子がただ一つの外部アドレスに関する輸送識別子に多重送信されるのを許容します。 NAPTは1セットのホストにただ一つの外部アドレスを共有させます。 「外部アドレスのプールがポート翻訳に関連して使用されるように、Basic NATにNAPTを結合できることに注意してください。」 -- RFC2663[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というより一般的な用語は、NATsとNAPTsの両方を覆うのに使用されます。 今日のほとんどの展開場合では、私たちは、使用されるNATsがNAPTのバラエティーのものであると信じています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [6].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[6])で説明されるように本書では解釈されることであるべきです。
1.2 Problem description
1.2 問題記述
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を伝えるのを試みるとき、この仮定に失敗します。
Levkowetz & Vaarala Standards Track [Page 3] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[3ページ]。
Mobile IP relies on sending traffic from the home network to the mobile node or foreign agent through IP-in-IP tunnelling. IP nodes which communicate from behind a NAT are reachable only through the NAT's public address(es). IP-in-IP tunnelling does not generally contain enough information to permit unique translation from the common public address(es) to the particular care-of address of a mobile node or foreign agent which resides behind the NAT; in particular there are no TCP/UDP port numbers available for a NAT to work with. For this reason, IP-in-IP tunnels cannot in general pass through a NAT, and Mobile IP will not work across a NAT.
IPにおけるIPトンネルでモバイルIPは可動のノードかホームネットワークから外国人のエージェントまでの送付交通に依存します。 後ろからNATを伝えるIPノードはNATの場内放送(es)だけを通して届いています。 一般に、IPにおけるIPトンネルがユニークな一般的な場内放送(es)から特定の場内放送までの翻訳を可能にすることができるくらいの情報を含んでいない、注意、-、NATの後ろにある可動のノードか外国人のエージェントのアドレス。 NATが働くように有効などんなTCP/UDPポートナンバーも特にありません。 この理由で、一般に、IPにおけるIPトンネルはNATを通り抜けることができません、そして、モバイルIPはNATの向こう側に働かないでしょう。
Mobile IP's Registration Request and Reply will on the other hand be able to pass through NATs and NAPTs on the mobile node or foreign agent side, as they are UDP datagrams originated from the inside of the NAT or NAPT. When passing out, they make the NAT set up an address/port mapping through which the Registration Reply will be able to pass in to the correct recipient. The current Mobile IP protocol does however not permit a registration where the mobile node's IP source address is not either the CoA, the Home Address, or 0.0.0.0.
他方では、モバイルIPのRegistration RequestとReplyは可動のノードか外国エージェント側の上のNATsとNAPTsを通り抜けることができるでしょう、彼らがNATの内部から溯源されたUDPデータグラムかNAPTであるので。 意識不明になるとき、彼らはNATにRegistration Replyができるアドレス/ポートマッピングを正しい受取人に通るセットアップさせます。 しかしながら、プロトコルがする現在のモバイルIPは可動のノードのIPソースアドレスがCoA、ホームAddress、または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.
必要であるものは、モバイルIPのためのアドレス変換が利くようにNAT装置がユニークなマッピングをするのに必要である手段を提供する代替のデータトンネルメカニズムと、そのような代替のトンネルメカニズムがいつに適切な状態で設定されるかを可能にする登録メカニズムです。
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
- 可動のノードは同じNATの後ろに可動のノードとFAの両方がある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
- 共同見つけられたアドレスが登録証明書が同じNATの後ろに可動のノードとファの両方があるところにFA(「R」ビットを設定する)を通り抜けるのを要求するFAを使用している可動のノード
1.3 Assumptions
1.3 仮定
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ポートと家のエージェントUDP港434とのコミュニケーションを許容するということです。 この仮定が成立しないと、モバイル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アドレス空間に抑制されると仮定しません。 これに反して、可動のノードと家のエージェントの間のルーティング織物はaに仕切られるかもしれません。
Levkowetz & Vaarala Standards Track [Page 4] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[4ページ]。
"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.
RFC3344によると、何らかのメカニズムが[10] 異種のIPアドレス空間の中で移動性を達成するのにバニラのモバイルIPに加えて必要であるという「個人的」、そして、「公共」のネットワーク、および仮定があります。
For a more extensive discussion of the problems with disparate address spaces, and how they may be solved, see RFC 3024 [9].
異種のアドレス空間と、それらがどう解決されるかもしれないかに関する問題の、より大規模な議論に関しては、RFC3024[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アドレス終点)を使用します。
2. NAT Traversal Overview
2. NAT縦断概観
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トンネルでは、可動のノードが、家のエージェントが、Registration Requestが、NATを通り抜けたように思えるのがわかるなら標準のモバイルIPトンネルの代わりにトンネルを堀るモバイルIP UDPは使用できるのを示すのに、Registration Requestで拡張子(以下で、説明される)を使用するかもしれません。 そして、家のエージェントは拡大が承認(または、否定)を示している登録回答を送るかもしれません。 家のエージェントからの賛成の後に、MIP UDPトンネルは前進のものと同様に逆のトンネルの使用に利用可能になるでしょう。 UDPは同じくらいが登録要求メッセージとして移植する可動のノード使用で送られたパケットにトンネルを堀りました。 ソース港は、特に、新しい登録証明書の間で異なるかもしれませんが、すべてのトンネルを堀られたデータと再登録証明書に同じままで残っています。 いつも仕向港は434です。 トンネルを堀られたパケットが送ったUDPは家のエージェントで同じポートを使用しますが、逆であり使用します。
2.1 Basic Message Sequence
2.1 基本的なメッセージ系列
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 Registration RequestとReply交換における特定の拡張子の使用で設立されます。 その後、UDPトンネルを通してどんな家のエージェントから可動のノードまでの交通も送ります。 可動のノードは逆のトンネルに多くの場合、MIP UDPトンネルが必要であるところであるところで自己判断でUDPトンネルを使用するかもしれません、また、逆のトンネルが必要でしょう。
Levkowetz & Vaarala Standards Track [Page 5] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[5ページ]。
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
|-----------------///--------------->>+
. . +
. . .
. . .
可動のノードNAT家のエージェント| | | | | | | 登録| | | 要求| | |-----------------///--------------->>| |UDPトンネル要求| | | | + | | || そしてIPソース。| | || CCoAアドレス| | || 食い違い| | || 見られます。| | 登録+| | 返信します。| | <<、-、-、-、-、-、-、-、-、-、-、-、-、-、--///-----------------| | | UDPトンネル回答、|| | | | UDPはpkgにトンネルを堀りました。| | |=================///===============>>|、|、| UDPはpkgにトンネルを堀りました。| |=<<=======///=================| | | ||不在| | ||取引します。| | ||UDP keepalive| UDP keepalive| ||期間|-----------------///--------------->>++ ……
3. New Message Formats
3. 新しいメッセージ・フォーマット
3.1 UDP Tunnel Request Extension
3.1 UDPトンネル要求拡張子
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].
この拡大はskippable拡張子です。 送付者が取り扱いMIP UDPのトンネルを堀ることができるのが意味して、任意に、特定のカプセル化書式がMIP UDPで要求されているのはトンネルを堀ります。 以下で示されるとしてこの拡大の形式があります。 それは[10]で説明された短い拡大形式を固く守ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Reserved 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|R| Reserved 2| Encapsulation | Reserved 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| サブタイプ| 予約された1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|R| 予約された2| カプセル化| 予約された3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Levkowetz & Vaarala Standards Track [Page 6] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[6ページ]。
Type 144
144をタイプしてください。
Length 6. Length in bytes of this extension, not
including the Type and Length bytes.
長さ6。 TypeとLengthバイトを含まないこの拡大のバイトで表現される長さ。
Sub-Type 0
サブタイプ0
Reserved 1 Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
今後の使用のための予約された1Reserved。 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 Requiredを通した登録)旗。 RビットがFAのエージェントAdvertisementに設定されたのを示します。 共同見つけられたaを使用することで登録をしている、注意、-、しかし、FAを通して記述します。
Reserved 2 Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
今後の使用のための予約された2Reserved。 0への発信のセットでなければならなく、レセプションで無視しなければなりません。
Encapsulation Indicates the type of tunnelled data, using
the same numbering as the IP Header Protocol
Field.
カプセル化、IP HeaderプロトコルFieldと同じ付番を使用するトンネルを堀られたデータのタイプのIndicates。
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.
今後の使用のための予約された3Reserved。 発信のときに0にセットしてください、領収書の上で0を確かめなければならないということでなければなりません。 さもなければ、理解されて、静かにスキップされないように拡大を扱わなければなりません。
3.1.1 F (Force) Flag
3.1.1 F(力)旗
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合図パケットのために利くなら役に立ちますが、これは一般的なデータ・パケット(例えば、ファイアウォールフィルタリング規則による)のために役に立つというわけではありません。 エージェントは家であるならこのプロトコルをサポートします、それ。SHOULDはUDP Tunnel Reply Extensionとの縦断と回答を受け入れるか、またはRegistration Requestを拒絶します。 登録失敗の場合には、ホームのエージェントSHOULDは129(「行政上禁止されている」)にCode分野セットがあるRegistration Replyを送ります。
Levkowetz & Vaarala Standards Track [Page 7] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[7ページ]。
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 Tunnel Request Extensionを理解していないと、静かにそれを捨てるでしょう、そして、ものが他の何もかもすばらしいなら、登録回答で、回答コード0(登録は受け入れました)にもかかわらず、少しもUDP Tunnel Reply Extensionなしで返答するでしょう。 この場合、可動のノードはMIP UDPトンネルを使用してはいけません。
3.1.2 R (Registration through FA Required) flag
3.1.2 R(FA Requiredを通した登録)旗
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'ビットでエージェントAdvertisementを受けたのでFAを通して登録するのはセットしました。
3.1.3 Reserved Fields
3.1.3 予約された分野
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であるに違いなく、さもなければ、この拡大を理解されていないように扱われて、静かにサボらなければなりませんが。 これは古い実現と共存できるか、または古い実現から拡大の拒絶を強制するされるこの拡大への今後の追加を可能にします。
3.1.4 Encapsulation
3.1.4 カプセル化
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ヘッダー(UDPのIPトンネル)RFC2003[4]
47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]
47 GRE Header(UDPのGREトンネル)RFC2784[8]
55 Minimal IP encapsulation header RFC 2004 [5]
55 最小量のIPカプセル化ヘッダーRFC2004[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トンネルを完了するべきであるのがわかるなら、カプセル化はEncapsulation分野の値から決定しています。 この分野の値がゼロであるなら、Registration Requestメッセージの'M'と'G'分野の値をデフォルトとしますが、非ゼロであるなら、それは、特定のカプセル化が望まれているのを示します。
Levkowetz & Vaarala Standards Track [Page 8] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[8ページ]。
3.1.5 Mobile IP Registration Bits
3.1.5 モバイルIP登録ビット
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はRFC3344[10]とRFC3024[9]で説明されるように(MIP UDPトンネルが使用されているとき、MとGビットの意味が上で説明されるようにEncapsulation分野によって変更されるかもしれないのを除いて)それらの意味を保有します。 また、MIP UDPトンネルに伴うMとGビットの使用はセクション4.1で触れられます。
When the MN requests MIP UDP tunnelling, the 'D' bit (Decapsulation by the mobile node) MUST be set, otherwise UDP tunnelling would not be meaningful.
ミネソタがMIP UDPトンネルを要求すると、'D'ビット(可動のノードによる被膜剥離術)を設定しなければなりません。さもなければ、UDPトンネルは重要でないでしょう。
Both the MN and the FA SHOULD set the 'T' bit when requesting MIP UDP tunnelling, even if not all traffic will be reverse tunnelled. This ensures that a HA which is not prepared to accept reverse tunnelling will not accept a registration which may later turn out to be unusable. Also see the discussion of use of the 'T' bit in Foreign Agent Considerations (Section 4.5).
すべての交通がどんな逆になるというわけではなくてもMIP UDPトンネルを要求するとき'T'が噛み付いたミネソタとFA SHOULDセットの両方がトンネルを堀りました。 これは、逆のトンネルを受け入れるように準備されないHAが、後で判明するかもしれない登録が使用不可能であると受け入れないのを確実にします。 また、議論がForeignエージェントConsiderations(セクション4.5)で'T'ビットで役に立つのを見てください。
3.2 UDP Tunnel Reply Extension
3.2 UDPトンネル回答拡張子
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.
この拡大は非skippable拡張子です。 それは、UDP Tunnel Request拡張子に対して送られて、HAが現在の移動性結合のためにトンネルを堀るMIP UDPを使用するかどうかを示します。 以下で示されるとしてこの拡大の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Reply Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Reserved | Keepalive Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| サブタイプ| 回答コード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| 予約されます。| Keepalive間隔| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 44
44をタイプしてください。
Length 6. Length in bytes of this extension, not
including the Type and Length bytes.
長さ6。 TypeとLengthバイトを含まないこの拡大のバイトで表現される長さ。
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を使用するのを断ることにかかわらずCode Indicatesは返答します。 セクション3.2.1未満を見てください。
Levkowetz & Vaarala Standards Track [Page 9] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[9ページ]。
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(強制されます)旗。 F旗がNATの検出の如何にかかわらずトンネル要求に設定されたので、トンネルが強制されているのを示します。
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 Interval Specifies NATは可動のノードSHOULDが費やす間隔をkeepaliveします。 AはパケットSHOULDをkeepaliveします。Keepalive Interval秒がどんな合図も送られるデータ通信量なしで経過したなら、送ってください。 この分野が0に設定されるなら、可動のノードはデフォルトの構成されたkeepalive間隔を費やさなければなりません。
Reserved Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
今後の使用のための予約されたReserved。 0への発信のセットでなければならなく、レセプションで無視しなければなりません。
3.2.1 Reply Code
3.2.1 回答コード
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 Tunnel Reply ExtensionのReply Code分野は、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 Tunnel Reply Extensionのコード分野での使用のために定義されます:
0 Will do tunnelling
0はトンネルをするでしょう。
64 Tunnelling declined, reason unspecified
64 傾けられて、理由不特定の状態でトンネルを堀ること。
3.3 MIP Tunnel Data Message
3.3 MIPトンネルデータメッセージ
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メッセージ、例えば、Registration Requestsからトンネルを堀られた交通とRegistration Repliesを微分するのに勤めます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Next Header | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 次のヘッダー| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4
4をタイプしてください。
Levkowetz & Vaarala Standards Track [Page 10] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[10ページ]。
Next Header Indicates the type of tunnelled data, using
the same numbering as the IP Header Protocol
Field.
次のIP HeaderプロトコルFieldと同じ付番を使用するトンネルを堀られたデータのタイプのHeader Indicates。
Reserved Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
今後の使用のための予約されたReserved。 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:
Next Header分野はIPヘッダープロトコル分野と同じ値を使用します。 すぐに、モバイルIPとの使用において関連しているのは、以下の値です:
4 IP header (IP-in-UDP tunnelling) RFC 2003 [4]
4 IPヘッダー(UDPのIPトンネル)RFC2003[4]
47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]
47 GRE Header(UDPのGREトンネル)RFC2784[8]
55 Minimal IP encapsulation header RFC 2004 [5]
55 最小量のIPカプセル化ヘッダーRFC2004[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.
トンネルを堀られたパケットの受信機は、Next Header値がパケットが送られた移動性結合のために確立されたトンネルモードに合っているのをチェックしなければなりません。 食い違いが検出されるなら、パケットを下げなければなりません。 ログエントリーは書かれているかもしれませんが、この場合、受信機SHOULDは書かれた航空日誌記入事項の量が確実に過剰にならないようにします。
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 Tunnel Data HeaderにおけるNext Header分野の使用とUDP Tunnel Request Extension(セクション3.1)のEncapsulation Header分野のそばで。
3.4 UDP Tunnelling Flag in Agent Advertisements
エージェント広告における3.4UDPトンネル旗
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].
RFC3344[10]で定義されたMobilityエージェントAdvertisement Extensionへの唯一の変化がエージェントAdvertisementを生成する外国人のエージェントがMIP UDP Tunnellingをサポートするのを示す旗です。 旗は[10]で定義された旗の後に挿入されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |R|B|H|F|M|G|r|T|U| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生涯|R|B|H|F|M|G|r|T|U| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロか以上、Care、-、Addresses| | ... |
Levkowetz & Vaarala Standards Track [Page 11] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[11ページ]。
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 Tunnellingサポート。 このエージェントは本書では指定されるとしてのMIP UDP Tunnellingをサポートします。 この旗のSHOULDはMIP UDPトンネルをサポートする外国人のエージェントによって送られた広告に設定されて、NATの後ろに位置しています。 それは、外国人のエージェントからのNATの後ろに位置していない広告に設定されてはいけなくて、その結果、能力の広告を出す必要性を全く持っていません。
3.5 New Registration Reply Codes
3.5 新規登録回答コード
One new registration reply code is defined:
1つの新規登録回答コードが定義されます:
ERROR_HA_UDP_ENCAP_UNAVAIL Requested UDP tunnel encapsulation
unavailable
入手できないERROR_HAの_UDP_ENCAP_UNAVAIL Requested UDPトンネルカプセル化
This is used by the HA to distinguish the registration denial caused by an unavailable UDP tunnel encapsulation mode from a denial caused by unavailable standard tunnel encapsulation requested by use of the 'T' bit together with either 'M' or 'G' bit.
これは、'M'か'G'のどちらかビットと共に'T'ビットの使用で要求された入手できない標準のトンネルカプセル化によって引き起こされた否定から入手できないUDPトンネルカプセル化モードで引き起こされた登録否定を区別するのにHAによって使用されます。
4. Protocol Behaviour
4. プロトコルのふるまい
4.1 Relation to standard MIP tunnelling
4.1 標準のMIPトンネルとの関係
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トンネルのためのデフォルトカプセル化モードはUDPのIPカプセル化です。 モバイルノードは、モバイルIP登録要求の'M'ビット、そして/または、'G'ビットを設定するか、またはEncapsulation分野を使用することによって明らかにMIP UDPトンネルに特定のカプセル化を要求することによってトンネルを堀るUDPと共に使用されるよう選択方式のカプセル化に要求するかもしれません。 MとGビットはMIP UDPトンネルの文脈の中でRFC3344[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'ビットが登録要求に設定されて、Encapsulation分野がゼロであるなら、ホームのエージェントがデータグラムにGREカプセル化[3]を使用するというモバイルノード要求はモバイルノードにトンネルを堀りました。 MIP UDPトンネルをまた、要求して、受け入れるなら、IPカプセル化におけるGREが同じ場合は使用されているでしょうが、UDPのGREカプセル化SHALLは受け入れます。
Levkowetz & Vaarala Standards Track [Page 12] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[12ページ]。
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'ビットが設定されて、Encapsulation分野がゼロであるなら、ホームのエージェントがデータグラムに最小量のカプセル化[5]を使用するというモバイルノード要求はモバイルノードにトンネルを堀りました。 また、MIP UDPトンネルがUDP SHALLの中古の、そして、最小量のカプセル化であるなら、同じ場合に最小量で使用されて、MIP UDPトンネルが要求されていないならRFC2004[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.
Encapsulation分野が非ゼロであるときに、特定のカプセル化書式はMIP UDPトンネルに要求されます。 トンネルが示されて、エラーコードERROR_HA_UDP_ENCAP_UNAVAILと共に要求を要求されたカプセル化を使用することで受け入れなければならないか、または拒絶しなければならないなら、セクション3.5で定義された「要求されたUDPは入手できないカプセル化にトンネルを堀ります」。 この誤りを受け取り次第、モバイルノードは、MIP UDPに関する異なった要件がカプセル化にトンネルを堀っている新しいRegistration Requestを送るのを選ぶかもしれません。
4.2 Encapsulating IP Headers in UDP
4.2 UDPでIPがヘッダーであるとカプセル化すること。
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.
外側の、そして、内側のIPヘッダーの間のUDPヘッダー[1]とMIP Messageヘッダー[10]の追加を除いて、RFC2003[4]でトンネルを堀りながら、IPにおけるIPのために説明されたそれへの類似の方法でUDPのMIP IPトンネル、または略してUDPトンネルをします。
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のRegistration RequestsとRegistration RepliesがUDPメッセージ、およびSHALL NOTの形に既にあります。UDPのMIP IPトンネルが有効でさえあるときには、トンネルを堀られてください。
Levkowetz & Vaarala Standards Track [Page 13] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[13ページ]。
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:
IPデータグラムがUDPのMIP IPカプセル化を使用して、外側のIPヘッダー[2]と、UDPヘッダー[1]とMIP Messageであるとカプセル化するために、ヘッダー[10]はデータグラムの既存のIPヘッダーの前に挿入されます、以下の通りです:
+---------------------------+
| |
| Outer IP Header |
+---------------------------+
| |
| UDP Header |
+---------------------------+
| MIP Tunnel Data |
| Message Header |
+---------------------------+ +---------------------------+
| | | |
| IP Header | | IP Header |
+---------------------------+ ====> +---------------------------+
| | | |
| IP Payload | | IP Payload |
| | | |
| | | |
+---------------------------+ +---------------------------+
+---------------------------+ | | | 外側のIPヘッダー| +---------------------------+ | | | UDPヘッダー| +---------------------------+ | MIPトンネルデータ| | メッセージヘッダー| +---------------------------+ +---------------------------+ | | | | | IPヘッダー| | IPヘッダー| +---------------------------+ ====>+---------------------------+ | | | | | IP有効搭載量| | IP有効搭載量| | | | | | | | | +---------------------------+ +---------------------------+
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のヘッダーSource AddressとDestination AddressはUDPヘッダーのSource PortとDestination Portと共にトンネルの「終点」を特定します。 内側のIPのヘッダーSource AddressとDestination Addressesはそれぞれ元の送り主とデータグラムの受取人を特定します。 内側のIPヘッダーがencapsulatorによって変えられないで、減少する以外に、1のTTLはトンネルが存在であるならRFC2003[4]に述べられるように推進の一部としてデータグラムをして、配送の間、トンネルエキジットポイントに変わりがありません。 内側のヘッダーのIPオプションへの変化は全くトンネルを通るカプセル化されたデータグラムの配送の間、起こりません。 内側のIPヘッダーのセキュリティオプションが要約(外側の)のIPヘッダーのためのセキュリティオプションの選択に影響するかもしれないことに注意してください。
Minimal Encapsulation and GRE encapsulation is done in an analogous manner, following RFC 2004 [5] for Minimal Encapsulation and RFC 2784 [8] for GRE Encapsulation, but using outer IP, UDP and MIP headers in place of the outer IP header.
類似の方法で最小量のEncapsulationとGREカプセル化をします、Minimal EncapsulationのためのRFC2004[5]とGRE EncapsulationのためのRFC2784[8]に続きますが、外側のIPヘッダーに代わって外側のIP、UDP、およびMIPヘッダーを使用して。
All other provisions and requirements of RFC 2003 [4] and RFC 3024 [9] are in force, except in one respect, as covered in Packet Fragmentation (Section 4.8).
RFC2003[4]とRFC3024[9]の他のすべての条項と要件は有効です、1つの点を除いて、Packet Fragmentation(セクション4.8)でカバーされるように。
Levkowetz & Vaarala Standards Track [Page 14] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[14ページ]。
4.3 Decapsulation
4.3 被膜剥離術
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.
被膜剥離術が実際に完了している前に、decapsulatingノードは、外側のIPアドレスとUDPポートナンバーがまさにトンネルに使用される値に合っていることを確かめなければなりません、ソースUDP港が変化できるところで「半分制限された」(セクション4.11で説明されるように)トンネルを除いて。
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.
UDPのトラフィックであるとカプセル化されたIPは、単に外側のIPとUDPとMIPヘッダーを全部はぎ取ることによって、decapsulatedされます。(ヘッダーはそのままで進められるオリジナルのIPパケットを残します)。
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ヘッダーはパケット、およびMIP Tunnel DataヘッダーのNext Header分野に取り替えられたIPヘッダーのプロトコル分野から取り外されます。 2番目に、全長とチェックサムが調整される残っているIPヘッダーは剥取られたパケットに合っています。 3番目に、普通の最小量の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.
RFC2784[8]とRFC1701[3]によると、トラフィックであるとカプセル化されたGREは処理されます、配送ヘッダーが外側のIP、UDP、およびMIPヘッダーから成っていて。
4.4 Mobile Node Considerations
4.4 モバイルノード問題
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.
モバイルノードが共同見つけられたaを使用するとUDP Tunnel Request ExtensionがモバイルIP Registration Requestでモバイルノードからホームのエージェントまで使用されるかもしれない、注意、-、アドレス。 それ、SHALL NOT、モバイルノードで、それがアドレスの外国人のエージェント注意とともに記名しているときには、使用されてください。
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の後ろに住んでいるという指示があるならトンネルを堀るMIP UDPかNAPTを受け入れることができるのをホームのエージェントに示すことです。 その結果、それは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.
.3RFC3344[10]、モバイルノードがセクション3.2と3.6.1に従ってそうしなければならないように、登録メッセージにモバイルホームAuthentication Extensionの前にこのExtensionを置いてください、それがモバイルホームAuthentication Extensionでカバーされているように。
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
モバイルノードが登録要求にUDP Tunnel Request拡張子を含んでいますが、UDP Tunnel Reply拡張子なしで登録回答を受け取るなら、それは、HAがそうしないと仮定しなければなりません。
Levkowetz & Vaarala Standards Track [Page 15] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[15ページ]。
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トンネルを使用してはいけません。 事実上、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.)
モバイルノードがいつ有なしで再登録するかは移行して、それはSHOULDです。注意して、現在の移動性結合のオリジナルの登録に使用されたのと同じソースポートを使用してください。 モバイルノードの古いポートに到着するとき、さもなければ、ホームのエージェントが新規登録の承認のときに仕向港を変えて、おそらく、モバイルノードが、新しいポートの上で聴き始めているだろうという間、変化時点のホームのエージェントからのフライトでのパケットは下げられるでしょう。 (これは、ホームのエージェントが新しいポートが使用したところでMIP UDPトンネルを使用するのがこれがNATが状態を下げるという結果であるかもしれないので使用されて、モバイルノードリブート、変化が連結するという登録要求などを拒否するべきであることを意味しません)
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.
アドレス、および外国人のエージェントからのエージェント広告はそうしました。モバイルノードが通じて外国人のエージェントを登録しますが、aが共同場所を見つけた使用である、注意、-、'U'ビットはセットして、モバイルノードは'R'旗をUDP Tunnel Request Extensionにはめ込まなければなりません、HAにMIP UDPトンネルを使用させるように。 この場合、登録を受け入れるとすぐに、モバイルノードもkeepaliveを送らなければなりません。
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.
アドレス、および外国人のエージェントからのエージェント広告は含んでいません。モバイルノードが通じて外国人のエージェントを登録しますが、aが共同場所を見つけた使用である、注意、-、'U'ビットを設定させてください、そして、モバイルノードは登録要求にUDP Tunnel Request Extensionを含んではいけません。
4.5 Foreign Agent Considerations
4.5 外国エージェント問題
The UDP Tunnel Request Extension MAY be used by a foreign agent when it is forwarding a Mobile IP Registration Request to a home agent, when the foreign agent is situated behind a NAT or has some other compelling reason to require MIP UDP tunnelling.
モバイルIP Registration Requestをホームのエージェントに送っているとき、UDP Tunnel Request Extensionは外国人のエージェントによって使用されるかもしれません、外国人のエージェントに、NATの後ろに位置しているか、またはMIP UDPトンネルを必要とするある他のやむにやまれない理由があるとき。
The purpose of this extension is to indicate to the home agent that the foreign agent is able to accept MIP UDP tunnelling if the home agent has an indication that the foreign agent resides behind a NAT or NAPT. It thus functions as a conditional solicitation for the use of MIP UDP tunnelling.
この拡大の目的は外国人のエージェントがホームのエージェントに外国人のエージェントがNATの後ろに住んでいるという指示があるならトンネルを堀るMIP UDPかNAPTを受け入れることができるのをホームのエージェントに示すことです。 その結果、それは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
外国人のエージェントを通して'R'を設定することによって登録するためにモバイルノードを必要とする外国人のエージェントはエージェント広告で噛み付いて、aを進めるとき、NOTはUDP Tunnel Request Extensionを加えなければなりませんか?
Levkowetz & Vaarala Standards Track [Page 16] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[16ページ]。
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.
aがそれの用途の共同場所を見つけた登録要求、注意、-、これがモバイルノードの代わりにホームのエージェントから外国人のエージェントまでセットアップされるUDPトンネルに通じるとき、扱います。
As per Section 3.2 and 3.7.2.2 of RFC 3344 [10], the foreign agent when using this extension MUST place it after the Mobile-Home Authentication Extension in registration messages. If the foreign agent shares a mobility security association with the home agent and therefore appends a Foreign-Home Authentication Extension, the UDP Tunnel Request Extension MUST be placed before the Foreign-Home Authentication Extension.
に従って、セクション3.2と3.7 .2 .2RFC3344[10]、この拡張子を使用するとき、外国人のエージェントは登録メッセージにモバイルホームAuthentication Extensionの後にそれを置かなければなりません。 外国人のエージェントがホームのエージェントとの移動性セキュリティ仲間を共有して、したがって、Foreign-ホームAuthentication Extensionを追加するなら、Foreign-ホームAuthentication Extensionの前にUDP Tunnel Request Extensionを置かなければなりません。
As the home agent detects the presence of a NAT in the path between the sender and itself by seeing a mismatch between the IP source address and the care-of address given in the registration request, it is REQUIRED that the foreign agent, when using this extension, sends the registration request with an IP source address matching the care-of address.
そして、ホームのエージェントが送付者と間のミスマッチを見るのによるIPソースアドレス自体の間の経路でのNATの存在を検出する、注意、-、アドレス、登録要求で与えます、この拡張子を使用するとき、IPソースアドレスが合っていて外国人のエージェントが登録要求を送るのが、REQUIREDである、注意、-、アドレス
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の後ろに位置しているのでホームのエージェントにトンネルを堀るMIP UDPを使用している外国人のエージェントは逆のトンネルを奨励するか、またはそれに関して中立であるために構成されるかもしれません、NATの特性によって。 モバイルノードが逆のトンネルの代わりに三角形のルーティングを使用したならこのネットワークから遠くに移行するとき、NATが出発しているパケットのすべてのソースアドレスをそれ自身の場内放送に翻訳すると、セッションを維持するのは可能でないでしょう。 他方では、NATが公的に発送可能なソースアドレスを翻訳しないほど賢く、イングレスフィルタリングをしないのが知られているなら、三角形のルーティングは成功するかもしれません。 それでも、ホームのエージェントから外国人のエージェントまでの脚は、NATを通り抜けるのにMIP UDPトンネルを使用するでしょう。
Therefore, if it is known when configuring a foreign agent behind a NAT that the NAT will translate public as well as private addresses, or it is known that ingress filtering is being done between the private and public networks, the foreign agent SHOULD reply to registration requests which don't have the 'T' bit set with a reply code 75, "reverse tunnel is mandatory and 'T' bit not set".
したがって、NATの後ろで外国人のエージェントを構成するとき、NATが公共の、そして、個人的なアドレスを翻訳するのが知られているか、またはイングレスフィルタリングが個人的が完了していて、公衆通信回線であることが知られているなら、外国人のエージェントSHOULDは回答コード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が場内放送にもかかわらず、イングレスを全く翻訳しないことに関して賢いのを知っているなら逆に、フィルタリングをするので、公的に発送可能なアドレスがあるモバイルノードがネットワークかこのネットワークから移行して、それらが'T'ビットを設定させないでも外国人のエージェントが登録要求を転送するために構成されるかもしれないセッションに保つことができるかもしれないと信じているのは妥当です。
Levkowetz & Vaarala Standards Track [Page 17] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[17ページ]。
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のふるまいはこの点で未知であり、それはSHOULDです。想定されて、'T'ビットを持っていない登録要求に答えるために構成されていて、アドレス、その結果すべての外国人のエージェントSHOULDを翻訳するために望んでいるのが回答コード75でセットして、「逆のトンネルは義務的です、そして、'T'ビットはセットしなかった」ということになってください。
4.6 Home Agent Considerations
4.6 ホームエージェント問題
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 Tunnel Reply Extensionの目的は、ホームのエージェントが、MIP UDPトンネルのこの移動性の使用は拘束力があると受け入れるかどうかを示して、使用されるために提案されたトンネルkeepalive間隔についてモバイルノードか外国人のエージェントに知らせることです。
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 Tunnel Request(セクション3.1)を受けて、受け入れたとき、モバイルIP Registration ReplyでホームのエージェントからモバイルノードまでUDP Tunnel Reply Extensionを使用しなければなりません。
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.
そして、ホームのエージェントがソースIPアドレスの間のミスマッチを使用しなければならない、注意、-、モバイルIPでは、モバイルノードがNATの後ろに住むかもしれないという指示としてRegistration Requestがメッセージであると扱ってください。 Registration Requestがまた、'Rのない'旗が設定して、ホームのエージェントはできるUDP Tunnel Request拡張子を含んでいて、MIP UDPトンネルを可能にするなら、登録回答がセクション3.2で説明されるように賛成UDP Tunnel Reply Extensionを含んでいて、ホームのエージェントSHALLは応じます。 'R'旗が設定されるなら、特別な問題は以下で説明されるように適用されます。
If the home agent receives a Registration Request with matching source IP address and co-located care-of address which contains a MIP UDP Tunnel Request Extension, the home agent SHOULD respond with a Registration Reply containing a declining UDP Tunnel Reply - unless tunnelling has been explicitly requested by the mobile node using the 'F' flag as described in Section 3.1.
ホームのエージェントが合っているソースIPアドレスでRegistration Requestを受け取って、共同見つけられている、注意、-、MIP UDP Tunnel Request Extensionを含むアドレス、トンネルがモバイルノードによってセクション3.1で説明されるように'F'旗を使用することで明らかに要求されていない場合Registration Replyが減退しているUDP Tunnel Replyを含んでいて、ホームのエージェントSHOULDは応じます。
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トンネルに同意するなら、有効として登録要求のソースアドレスを使用しなければならない、注意、-、むしろ扱う、注意、-、アドレス、登録要求では、'R'旗がUDP Tunnel Request Extensionに設定されるケースの中を除いて、与えます。
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
ホームのエージェントが受信するなら'R'旗があるRegistration RequestがUDP Tunnel Request Extensionにセットして、賛成UDP Tunnel Reply ExtensionとのSHOULD回答である、それは、できて、MIP UDPトンネルを可能にします。 しかしながら、この場合、登録要求のソースアドレスとポートは外国エージェントソースアドレスとポートのNAT'edバージョンであるかもしれません。 正しくモバイルノード、エージェントが待たなければならないホームにトンネルを堀られたトラフィックを向けます。
Levkowetz & Vaarala Standards Track [Page 18] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[18ページ]。
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.
到着するモバイルノードからの最初のkeepaliveパケット、発信できる前に正しいNATへのトラフィック後部は(ミネソタに写像されるもの)を移植します。 この場合、ホームのエージェントは、このkeepaliveパケットの外側のソースアドレス(しかし、ポートでない)が対応する登録要求のソースアドレスと同じであることをチェックしなければなりません。 内側のソースアドレス(カプセル化されたICMPエコー要求のもの)はモバイルノードに関するホームアドレスであるに違いありません、そして、内側の送付先アドレスはホームのエージェントのものであるに違いありません。 このkeepaliveパケットSHALLのこれが持っているすべて、外側のソースアドレス、およびポートが使用されているなら、モバイルノードにトラフィックを送るときには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.
ホームのエージェントSHOULD、UDPトンネルのサポートを承諾する際に、一貫してください。 UDP Tunnel Request Extensionを理解して、またMIP UDPトンネルの使用がセッションのために示されないならUDP Tunnel Reply Extensionが減退している回答コードを含んでいてSHOULDが反応させるそのような要求に積極的に対応する用意ができているホームのエージェント。 モバイルノードはホームのエージェントからそのようなふるまいを仮定してはいけません、ホームのエージェントがリブートがあるソフトウェア変化、政策変更または交換品を受けるかもしれないので。 そして、その結果ふるまいの変化。
4.6.1 Error Handling
4.6.1 エラー処理
The following actions take place when things go wrong.
いろいろなことが支障をきたすと、以下の動作は行われます。
The HA does not support the UDP Tunnel Request extension:
HAは、UDP Tunnel Requestが拡大であるとサポートしません:
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 Tunnelling Replyを受けないなら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 Tunnel Request拡張子をサポートしますが、ホームのエージェントはNAT縦断を無効にするかもしれません、そして、NATは検出されます。 この場合、ホームのエージェントSHOULDは「行政上禁止された」129にCode分野セットがあるRegistration Replyを送ります。
Levkowetz & Vaarala Standards Track [Page 19] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[19ページ]。
NAT not detected, 'F' flag set, but home agent does not allow forced use of MIP UDP tunnelling:
検出された'F'旗のセットではなく、ホームのエージェントが許さないNATはMIP UDPトンネルの使用を強制しました:
The home agent SHOULD send a Registration Reply with the Code
field set to 129, "administratively prohibited".
ホームのエージェントSHOULDは「行政上禁止された」129にCode分野セットがあるRegistration Replyを送ります。
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:
しかし、モバイルノード(ミネソタ-HA認証拡張子の前に置かれる)によって送られたUDP Tunnel Request拡張子、登録で噛み付いた'D'は、ヘッダーがセットしなかったよう要求します:
The home agent SHOULD send a Registration Reply with the Code
field set to 134, "poorly formed Request".
ホームのエージェントSHOULDは134に設定されたCode分野、「不十分に形成されたRequest」があるRegistration Replyを送ります。
UDP Tunnel Request extension sent by the foreign agent (placed after the MN-HA authentication extension), but 'D' bit is set:
UDP Tunnel Request拡張子が外国人のエージェント(ミネソタ-HA認証拡張子の後に置かれる)によって送られて、'D'ビットだけが設定されます:
The home agent SHOULD send a Registration Reply with the Code
field set to 134, "poorly formed Request".
ホームのエージェントSHOULDは134に設定されたCode分野、「不十分に形成されたRequest」があるRegistration Replyを送ります。
Reserved 3 field of UDP Tunnel Request extension is nonzero:
UDP Tunnel Request拡張子の予約された3分野は非零です:
The home agent SHOULD send a Registration Reply with the Code
field set to 134, "poorly formed Request".
ホームのエージェントSHOULDは134に設定されたCode分野、「不十分に形成されたRequest」があるRegistration Replyを送ります。
Encapsulation type requested in UDP Tunnel Request extension is unsupported:
UDP Tunnel Request拡張子で要求されたカプセル化タイプはサポートされないです:
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.
ホームのエージェントSHOULDはERROR_HA_UDP_ENCAP_UNAVAILに設定されたCode分野、「要求されたUDPは入手できないカプセル化にトンネルを堀ること」があるセクション3.5で定義されたRegistration Replyを送ります。
4.7 MIP signalling versus tunnelling
4.7 トンネルに対して合図するMIP
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 Tunnel Requestを使用することで確立されていただけであるか間、使用されて、UDP Tunnel Replyによってホームのエージェントから受け入れられて、SHALLにトンネルを堀るUDP。 MIP UDPトンネルが移動性結合のために設立された後に、IPにおけるIPトンネルかある他のトンネルメソッドではなく、MIP UDPトンネルを使用して、前方にあるデータ・パケットかこの移動性結合を使用することでトンネルを堀られた逆にトンネルを堀らなければなりません。
As a consequence:
結果として:
- Mobile IP signalling is never tunnelled.
- モバイルIP合図は決してトンネルを堀られません。
- When using simultaneous bindings, each binding may have a
different type (i.e., UDP tunnelling bindings may be mixed with
non-UDP tunnelling bindings).
- 同時の結合を使用するとき、各結合には、異なったタイプがあるかもしれません(すなわち、UDPトンネル結合は非UDPトンネル結合に混ぜられるかもしれません)。
Levkowetz & Vaarala Standards Track [Page 20] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[20ページ]。
- Tunnelling is only allowed for the duration of the binding
lifetime.
- トンネルは拘束力がある生涯の持続時間のために許容されているだけです。
4.8 Packet fragmentation
4.8 パケット断片化
From RFC 3022 [12]:
RFC3022[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."
"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."
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.
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.
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.
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.
For this reason, the home agent SHOULD do packet fragmentation before it does MIP UDP encapsulation.
For this reason, the home agent SHOULD do packet fragmentation before it does MIP UDP encapsulation.
4.9 Tunnel Keepalive
4.9 Tunnel Keepalive
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.
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.
Levkowetz & Vaarala Standards Track [Page 21] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz & Vaarala Standards Track [Page 21] RFC 3519 NAT Traversal for Mobile IP April 2003
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.
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.
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.
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.
The keepalive message sent MUST consist of a properly UDP encapsulated ICMP echo request directed to the home agent.
The keepalive message sent MUST consist of a properly UDP encapsulated ICMP echo request directed to the home agent.
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).
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).
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.
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.
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:
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:
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. 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.
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. 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.
4.10 Detecting and compensating for loss of NAT mapping
4.10 Detecting and compensating for loss of NAT mapping
When a mobile node is using UDP encapsulated ICMP Echo Request/Reply messages as keepalives, it will have to deal with the possibility
When a mobile node is using UDP encapsulated ICMP Echo Request/Reply messages as keepalives, it will have to deal with the possibility
Levkowetz & Vaarala Standards Track [Page 22] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz & Vaarala Standards Track [Page 22] RFC 3519 NAT Traversal for Mobile IP April 2003
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Levkowetz & Vaarala Standards Track [Page 23] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz & Vaarala Standards Track [Page 23] RFC 3519 NAT Traversal for Mobile IP April 2003
4.11 Co-located registration through FA
4.11 Co-located registration through FA
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
5. Implementation Issues
5. Implementation Issues
5.1 Movement Detection and Private Address Aliasing
5.1 Movement Detection and Private Address Aliasing
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
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
Levkowetz & Vaarala Standards Track [Page 24] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz & Vaarala Standards Track [Page 24] RFC 3519 NAT Traversal for Mobile IP April 2003
problem of movement detection and address aliasing. We here have a case which may not occur frequently, but is mentioned for completeness:
problem of movement detection and address aliasing. We here have a case which may not occur frequently, but is mentioned for completeness:
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.
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.
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.
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.
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).
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 Mobility Binding Lifetime
5.2 Mobility Binding Lifetime
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.
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.
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.
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.
A second case where a short lifetime is useful is related to the aliasing of private network addresses. In case the mobile node is
A second case where a short lifetime is useful is related to the aliasing of private network addresses. In case the mobile node is
Levkowetz & Vaarala Standards Track [Page 25] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz & Vaarala Standards Track [Page 25] RFC 3519 NAT Traversal for Mobile IP April 2003
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.
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.
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.
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.
6. Security Considerations
6. Security Considerations
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.
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.
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.
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.
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.
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.
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.
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.
The known security issues are described in the sections that follow.
The known security issues are described in the sections that follow.
Levkowetz & Vaarala Standards Track [Page 26] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz & Vaarala Standards Track [Page 26] RFC 3519 NAT Traversal for Mobile IP April 2003
6.1 Traffic Redirection Vulnerabilities
6.1 Traffic Redirection Vulnerabilities
6.1.1 Manipulation of the Registration Request Message
6.1.1 Manipulation of the Registration Request Message
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.
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.
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.
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.
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.
6.1.2 Sending a Bogus Keepalive Message
6.1.2 Sending a Bogus Keepalive Message
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).
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).
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.
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.
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.
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.
Levkowetz & Vaarala Standards Track [Page 27] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz & Vaarala Standards Track [Page 27] RFC 3519 NAT Traversal for Mobile IP April 2003
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.
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.
6.2 Use of IPsec
6.2 Use of IPsec
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.
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.
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.
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.
6.3 Firewall Considerations
6.3 Firewall Considerations
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.
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.
7. UNSAF Considerations
7. UNSAF Considerations
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].
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].
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. 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.
Levkowetz & Vaarala Standards Track [Page 28] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz & Vaarala Standards Track [Page 28] RFC 3519 NAT Traversal for Mobile IP April 2003
The NAT address and port detected by the home agent are not
exported or communicated to any other node anywhere.
The NAT address and port detected by the home agent are not exported or communicated to any other node anywhere.
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. Exit strategy. This mechanism will go out of use as IPv6 and Mobile IP v6 is deployed, obviating the need for MIPv4 NAT traversal.
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.
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.
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. 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.
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. 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.
In the presence of NATs, an improved solution would require
In the presence of NATs, an improved solution would require
* the ability to discover the translations done by each NAT along
the route
* the ability to discover the translations done by each NAT along the route
* the ability to validate the authority of each NAT to do those
translations
* the ability to validate the authority of each NAT to do those translations
* 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.
* 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.
* configuration of all intermediate NATs to accept only packets
from the neighbour NATs.
* configuration of all intermediate NATs to accept only packets from the neighbour NATs.
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. 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.
Levkowetz & Vaarala Standards Track [Page 29] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz & Vaarala Standards Track [Page 29] RFC 3519 NAT Traversal for Mobile IP April 2003
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.
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.
8. IANA Considerations
8. IANA Considerations
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.
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.
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].
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].
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 Tunnel Reply Extensionを定義します。 この拡大のためのタイプ値は44です。 この拡大は、値0をこの拡大に割り当ててあるスペースに付番しながら、新しいサブタイプを導入します。 新しいTunnel Reply Extensionサブ形式数の承認はExpert Reviewを受けることがあります、そして、仕様は必要な[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メッセージ、Tunnel Dataメッセージを定義します。 このメッセージのためのタイプ値は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".
ERROR_HA_UDP_ENCAP_UNAVAIL、セクション3.5は新しいエラーコードを定義します: 「要求されたUDPは入手できないカプセル化にトンネルを堀ります」、使用のためにモバイルIP Registration Reply MessagesのCode分野で定義された値のための付番スペースから。 「誤りはホームのエージェントからコード化する」部分集合からコード番号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 Tunnel Data Message(セクション3.3)のNext Header分野への値は、IPヘッダー[2]のプロトコル分野に使用されるものと同じであり、どんな新しい数の課題も必要としません。
9. Intellectual Property Rights
9. 知的所有権
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)のオンラインリストに相談してください。
Levkowetz & Vaarala Standards Track [Page 30] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[30ページ]。
10. Acknowledgements
10. 承認
Much of the text in Section 4.2 has been taken almost verbatim from RFC 2003, IP Encapsulation within IP [4].
RFC2003、IP[4]の中のIP Encapsulationからセクション4.2における、テキストの多くをほぼ逐語的に取りました。
Adding support for the FA case was suggested by George Tsirtsis and Frode B. Nilsen. Roy Jose pointed out a problem with binding updates, and Frode, Roy and George pointed out that there are cases where triangular routes may work, and suggested that reverse tunnelling need not be mandatory. Roy and Qiang Zhang drew attention to a number of sections which needed to be corrected or stated more clearly.
FAケースのサポートを加えるのはジョージTsirtsisとFrode B.Nilsenによって勧められました。 ロイ・ホセが拘束力があるアップデートに関する問題を指摘して、Frode、ロイ、およびジョージは、ケースが三角形のルートが利くかもしれないところにあると指摘して、逆のトンネルが義務的である必要はないと示唆しました。 ロイとQiangチャンは、より明確に修正されるか、または述べられている必要があった多くのセクションに、注意を向けました。
Phil Roberts helped remove a number of rough edges. Farid Adrangi pointed out the DoS issue now covered in Security Considerations (Section 6). Francis Dupont's helpful comments made us extend the Security Considerations section to make it more comprehensive and clear. Milind Kulkarni and Madhavi Chandra pointed out the required match between the FA source and care-of addresses when the mechanism is used by an FA, and also contributed a number of clarifications to the text.
フィル・ロバーツは、多くの荒い優勢を取り除くのを助けました。 ファリドAdrangiは現在Security Considerations(セクション6)でカバーされているDoS問題を指摘しました。 フランシス・デュポンの役に立つコメントで、私たちは、それをより包括的で明確にするようにSecurity Considerations部を広げました。 そして、Milind KulkarniとMadhaviチャンドラがFAソースの間の必要なマッチから指した、注意、-、メカニズムがテキストへのFAによって使用された、また、寄付されたa番号の明確化であるときに、記述します。
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.
また、ipUnpluggedのNetseal、ハンス・シェストランド、フレドリック・ヨハンソン、およびエリックLidenで私たちの仕事仲間、Ilkka Pietikainen、Antti Nuopponen、およびティモAaltoをありがとうございます。 彼らは、テキストを読んで、再読して、多くの貴重な修正と洞察を寄付しました。
11. Normative References
11. 引用規格
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[1] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[2] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[3] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
Encapsulation (GRE)", RFC 1701, October 1994.
[3]一かせとS.と李とT.とファリナッチとD.とP.Traina、「一般ルーティングのカプセル化(GRE)」、RFC1701 1994年10月。
[4] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[4] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[5] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[5] パーキンス、C.、「IPの中の最小量のカプセル化」、RFC2004、1996年10月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Levkowetz & Vaarala Standards Track [Page 31] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[31ページ]。
[8] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[8] ファリナッチとD.と李とT.とハンクスとS.とマイヤーとD.と2000年のP.Traina、「一般ルーティングのカプセル化(GRE)」、RFC2784行進。
[9] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC
3024, January 2001.
[9] モンテネグロ、G. RFC3024、「モバイルIPのためにTunnelingを逆にして、改訂され」て、2001年1月。
[10] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2002.
[10] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
12. Informative References
12. 有益な参照
[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)用語と問題をネットワークでつなぐ」RFC2663、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)」、RFC3022、2001年1月。
[13] Daigle, L., Editor, and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF)", RFC 3424, November 2002.
[13]Daigle、L.、エディタ、およびIAB、「一方的な自己アドレス修理(UNSAF)のためのIAB問題」、RFC3424、2002年11月。
Levkowetz & Vaarala Standards Track [Page 32] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[32ページ]。
13. Authors' Addresses
13. 作者のアドレス
Henrik Levkowetz ipUnplugged AB Arenavagen 23 Stockholm S-121 28 SWEDEN
Henrik Levkowetz ipUnplugged AB Arenavagen23ストックホルムS-121 28スウェーデン
Phone: +46 708 32 16 08 EMail: henrik@levkowetz.com
以下に電話をしてください。 +46 708 32 16 08はメールされます: henrik@levkowetz.com
Sami Vaarala Netseal Niittykatu 6 Espoo 02201 FINLAND
サミVaarala Netseal Niittykatu6エスポー02201フィンランド
Phone: +358 9 435 310 EMail: sami.vaarala@iki.fi
以下に電話をしてください。 +358 9 435 310はメールされます: sami.vaarala@iki.fi
Levkowetz & Vaarala Standards Track [Page 33] RFC 3519 NAT Traversal for Mobile IP April 2003
Levkowetz&Vaarala規格は2003年4月にモバイルIPのためにRFC3519NAT縦断を追跡します[33ページ]。
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Levkowetz & Vaarala Standards Track [Page 34]
Levkowetz&Vaarala標準化過程[34ページ]
一覧
スポンサーリンク
