RFC2663 日本語訳
2663 IP Network Address Translator (NAT) Terminology andConsiderations. P. Srisuresh, M. Holdrege. August 1999. (Format: TXT=72265 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Srisuresh
Request for Comments: 2663 M. Holdrege
Category: Informational Lucent Technologies
August 1999
Srisureshがコメントのために要求するワーキンググループP.をネットワークでつないでください: 2663年のM.Holdregeカテゴリ: 情報のルーセントテクノロジーズ1999年8月
IP Network Address Translator (NAT) Terminology and Considerations
IPネットワークアドレス変換機構(NAT)用語と問題
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Preface
序文
The motivation behind this document is to provide clarity to the terms used in conjunction with Network Address Translators. The term "Network Address Translator" means different things in different contexts. The intent of this document is to define the various flavors of NAT and standardize the meaning of terms used.
このドキュメントの後ろの動機はNetwork Address Translatorsに関連して使用される用語まで明快を提供することです。 「ネットワーク・アドレス翻訳者」という用語は異なった文脈で別物を意味します。 このドキュメントの意図は、NATの様々な風味を定義して、使用される用語の意味を標準化することです。
The authors listed are editors for this document and owe the content to contributions from members of the working group. Large chunks of the document titled, "IP Network Address Translator (NAT)" were extracted almost as is, to form the initial basis for this document. The editors would like to thank the authors Pyda Srisuresh and Kjeld Egevang for the same. The editors would like to thank Praveen Akkiraju for his contributions in describing NAT deployment scenarios. The editors would also like to thank the IESG members Scott Bradner, Vern Paxson and Thomas Narten for their detailed review of the document and adding clarity to the text.
記載された作者は、このドキュメントのためのエディタであり、貢献からワーキンググループのメンバーから内容を借りています。 題をつけられたドキュメントの大きい塊、「IPネットワーク・アドレス翻訳者(NAT)」は、このドキュメントの初期の基礎を形成するためにほぼそのままで抽出されました。 エディタは同じくらいについて作者のPyda SrisureshとKjeld Egevangに感謝したがっています。 エディタは彼の貢献についてNAT展開シナリオについて説明する際にPraveen Akkirajuに感謝したがっています。 また、エディタは彼らのテキストへのドキュメントと付加明快の詳細なレビューについてIESGメンバーのスコット・ブラドナー、バーン・パクソン、およびトーマスNartenに感謝したがっています。
Abstract
要約
Network Address Translation is a method by which IP addresses are mapped from one realm to another, in an attempt to provide transparent routing to hosts. Traditionally, NAT devices are used to connect an isolated address realm with private unregistered addresses to an external realm with globally unique registered addresses. This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT.
ネットワークAddress TranslationはIPアドレスが1つの分野から別の分野まで写像されるメソッドです、見え透いたルーティングをホストに提供する試みで。 伝統的に、NATデバイスは、グローバルにユニークな登録されたアドレスで外部の分野への個人的な登録されていないアドレスに孤立しているアドレス分野を接続するのに使用されます。 このドキュメントは、NATデバイスの操作と一般に、関連問題について説明して、NATの様々な風味を特定するのに使用される用語を定義するのを試みます。
Srisuresh & Holdrege Informational [Page 1] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[1ページ]のRFC2663NAT用語と問題1999年8月
1. Introduction and Overview
1. 序論と概要
The need for IP Address translation arises when a network's internal IP addresses cannot be used outside the network either because they are invalid for use outside, or because the internal addressing must be kept private from the external network.
外の使用に、それらが無効であるか、または外部のネットワークから個人的に内部のアドレシングを保たなければならないのでネットワークの外でネットワークの内部のIPアドレスを使用できないとき、IP Address翻訳の必要性は起こります。
Address translation allows (in many cases, except as noted in sections 8 and 9) hosts in a private network to transparently communicate with destinations on an external network and vice versa. There are a variety of flavors of NAT and terms to match them. This document attempts to define the terminology used and to identify various flavors of NAT. The document also attempts to describe other considerations applicable to NAT devices in general.
アドレス変換で、私設のネットワークのホストは外部のネットワークの目的地で透過的に逆もまた同様に交信できます(セクション8と9で注意されるのを除いた多くの場合で)。 それらを合わせるために、NATと用語のさまざまな風味があります。 このドキュメントは、使用される用語を定義して、NATの様々な風味を特定するのを試みます。 また、ドキュメントは、一般に、NATデバイスに適切な他の問題について説明するのを試みます。
Note, however, this document is not intended to describe the operations of individual NAT variations or the applicability of NAT devices.
しかしながら、このドキュメントが個々のNAT変化の操作かNATデバイスの適用性について説明することを意図しないことに注意してください。
NAT devices attempt to provide a transparent routing solution to end hosts trying to communicate from disparate address realms. This is achieved by modifying end node addresses en-route and maintaining state for these updates so that datagrams pertaining to a session are routed to the right end-node in either realm. This solution only works when the applications do not use the IP addresses as part of the protocol itself. For example, identifying endpoints using DNS names rather than addresses makes applications less dependent of the actual addresses that NAT chooses and avoids the need to also translate payload contents when NAT changes an IP address.
NATデバイスは、異種のアドレス分野から交信しようとするホストを終わらせるために透明なルーティング解決法を提供するのを試みます。これが途中で、エンドノードアドレスを変更して、これらのアップデートのために状態を維持することによって達成されるので、セッションまで関係するデータグラムはどちらの分野でも正しいエンドノードに発送されます。 アプリケーションがプロトコル自体の一部としてIPアドレスを使用しないと、このソリューションは働いているだけです。 例えば、アドレスよりむしろDNS名を使用する場合依存するようにアプリケーションでしない絶対番地の終点を特定して、そのNATは、また、NATがIPアドレスを変えるときペイロードコンテンツを翻訳する必要性を選んで、避けます。
The NAT function cannot by itself support all applications transparently and often must co-exist with application level gateways (ALGs) for this reason. People looking to deploy NAT based solutions need to determine their application requirements first and assess the NAT extensions (i.e., ALGs) necessary to provide application transparency for their environment.
NAT機能は、それ自体で透過的にすべてのアプリケーションをサポートすることができるというわけではなくて、この理由で、しばしばアプリケーションレベルゲートウェイ(ALGs)と共存しなければなりません。 NATがベースのソリューションであると配布するのを目指している人々は、最初に、それらのアプリケーション要件を決定して、アプリケーション透明を彼らの環境に提供するのに必要なNAT拡大(すなわち、ALGs)を評価する必要があります。
IPsec techniques which are intended to preserve the Endpoint addresses of an IP packet will not work with NAT enroute for most applications in practice. Techniques such as AH and ESP protect the contents of the IP headers (including the source and destination addresses) from modification. Yet, NAT's fundamental role is to alter the addresses in the IP header of a packet.
IPパケットのEndpointアドレスを保存することを意図するIPsecのテクニックは途中で、ほとんどのアプリケーションのために実際にはNATで利かないでしょう。 AHや超能力などのテクニックは変更からIPヘッダー(ソースと送付先アドレスを含んでいる)のコンテンツを保護します。 しかし、NATの基本的な役割はパケットのIPヘッダーでアドレスを変更することです。
2. Terminology and concepts used
2. 用語と使用される概念
Terms most frequently used in the context of NAT are defined here for reference.
NATの文脈で最も頻繁に使用される用語は参照のためにここで定義されます。
Srisuresh & Holdrege Informational [Page 2] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[2ページ]のRFC2663NAT用語と問題1999年8月
2.1. Address realm or realm
2.1. アドレス分野か分野
An address realm is a network domain in which the network addresses are uniquely assigned to entities such that datagrams can be routed to them. Routing protocols used within the network domain are responsible for finding routes to entities given their network addresses. Note that this document is limited to describing NAT in IPv4 environment and does not address the use of NAT in other types of environment. (e.g. IPv6 environments)
アドレス分野はネットワーク・アドレスがデータグラムをそれらに発送できるように唯一実体に割り当てられるネットワークドメインです。 それらのネットワーク・アドレスを考えて、ネットワークドメインの中で使用されたルーティング・プロトコルは実体にルートを見つけるのに原因となります。 このドキュメントがIPv4環境におけるNATについて説明するのに制限されて、他のタイプの環境におけるNATの使用を扱わないことに注意してください。 (例えば、IPv6環境)
2.2. Transparent routing
2.2. 見え透いたルーティング
The term "transparent routing" is used throughout the document to identify the routing functionality that a NAT device provides. This is different from the routing functionality provided by a traditional router device in that a traditional router routes packets within a single address realm.
「見え透いたルーティング」という用語は、NATデバイスが提供するルーティングの機能性を特定するのにドキュメント中で使用されます。 これは伝統的なルータがただ一つのアドレス分野の中でパケットを発送するので伝統的なルータデバイスによって提供されたルーティングの機能性と異なっています。
Transparent routing refers to routing a datagram between disparate address realms, by modifying address contents in the IP header to be valid in the address realm into which the datagram is routed. Section 3.2 has a detailed description of transparent routing.
見え透いたルーティングは異種のアドレス分野の間にデータグラムを発送するのを示します、データグラムが発送されるアドレス分野で有効になるようにIPヘッダーでアドレスコンテンツを変更することによって。 セクション3.2には、見え透いたルーティングの詳述があります。
2.3. Session flow vs. Packet flow
2.3. セッション流動対Packet流動
Connection or session flows are different from packet flows. A session flow indicates the direction in which the session was initiated with reference to a network interface. Packet flow is the direction in which the packet has traveled with reference to a network interface. Take for example, an outbound telnet session. The telnet session consists of packet flows in both inbound and outbound directions. Outbound telnet packets carry terminal keystrokes and inbound telnet packets carry screen displays from the telnet server.
接続かセッション流れがパケット流れと異なっています。 セッション流動はセッションがネットワーク・インターフェースに関して開始された方向を示します。 パケット流動はパケットがネットワーク・インターフェースに関して移動した方向です。 例えば外国行きのtelnetセッションを取ってください。 telnetセッションは本国行きの、そして、外国行きの両方の方向のパケット流れから成ります。 外国行きのtelnetパケットは端末のキーストロークを運びます、そして、本国行きのtelnetパケットはtelnetサーバからスクリーンディスプレイを運びます。
For purposes of discussion in this document, a session is defined as the set of traffic that is managed as a unit for translation. TCP/UDP sessions are uniquely identified by the tuple of (source IP address, source TCP/UDP port, target IP address, target TCP/UDP port). ICMP query sessions are identified by the tuple of (source IP address, ICMP query ID, target IP address). All other sessions are characterized by the tuple of (source IP address, target IP address, IP protocol).
このドキュメントにおける議論の目的のために、セッションは翻訳のために一体にして管理されるトラフィックのセットと定義されます。 TCP/UDPセッションは(ソースIPアドレス、ソースTCP/UDP港、目標IPアドレス、目標TCP/UDPポート)のtupleによって唯一特定されます。 ICMP質問セッションは(ソースIPアドレス、ICMP質問ID、目標IPアドレス)のtupleによって特定されます。 他のすべてのセッションが(ソースIPアドレス、目標IPアドレス、IPプロトコル)のtupleによって特徴付けられます。
Address translations performed by NAT are session based and would include translation of incoming as well as outgoing packets belonging to that session. Session direction is identified by the direction of the first packet of that session (see sec 2.5).
NATによって実行されたアドレス変換は、基づくセッションであり、そのセッションに属する入って来て出発しているパケットに関する翻訳を含んでいるでしょう。 セッション方向はそのセッションの最初のパケットの方向で特定されます(秒2.5に遭遇してください)。
Srisuresh & Holdrege Informational [Page 3] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[3ページ]のRFC2663NAT用語と問題1999年8月
Note, there is no guarantee that the idea of a session, determined as above by NAT, will coincide with the application's idea of a session. An application might view a bundle of sessions (as viewed by NAT) as a single session and might not even view its communication with its peers as a session. Not all applications are guaranteed to work across realms, even with an ALG (defined below in section 2.9) enroute.
注意、同じくらい上でNATで決定したセッションの考えがアプリケーションのセッションの考えと一致するという保証が全くありません。 アプリケーションは、ただ一つのセッションとしてセッション(NATによって見られるように)のバンドルを見なして、同輩とのコミュニケーションをセッションであるとみなしてさえいないかもしれません。 すべてのアプリケーションが、途中で分野の向こう側にALG(以下では、セクション2.9で、定義される)があっても働くために保証されるというわけではありません。
2.4. TU ports, Server ports, Client ports
2.4. TUポート、Clientが移植するServerポート
For the reminder of this document, we will refer TCP/UDP ports associated with an IP address simply as "TU ports".
このドキュメントを思い出させるものについて、私たちは単に「TUポート」としてIPアドレスに関連しているTCP/UDPポートを参照するつもりです。
For most TCP/IP hosts, TU port range 0-1023 is used by servers listening for incoming connections. Clients trying to initiate a connection typically select a source TU port in the range of 1024- 65535. However, this convention is not universal and not always followed. Some client stations initiate connections using a source TU port number in the range of 0-1023, and there are servers listening on TU port numbers in the range of 1024-65535.
ほとんどのTCP/IPホストのために、TUポート範囲0-1023は接続要求の聞こうとするサーバによって使用されます。 接続を開始しようとするクライアントがTUが1024- 65535の範囲で移植するソースを通常選びます。 しかしながら、このコンベンションは、普遍的でなくていつも続かれるというわけではありません。 いくつかのクライアントステーションが0-1023の範囲でソースTUポートナンバーを使用することで接続を開始します、そして、1024-65535の範囲でTUポートナンバーで聴かれるサーバがあります。
A list of assigned TU port services may be found in RFC 1700 [Ref 2].
割り当てられたTU港湾業務のリストはRFC1700[審判2]で見つけられるかもしれません。
2.5. Start of session for TCP, UDP and others
2.5. TCP、UDP、および他のもののためのセッションの始まり
The first packet of every TCP session tries to establish a session and contains connection startup information. The first packet of a TCP session may be recognized by the presence of SYN bit and absence of ACK bit in the TCP flags. All TCP packets, with the exception of the first packet, must have the ACK bit set.
あらゆるTCPセッションの最初のパケットは、セッションを確立しようとして、接続始動情報を含んでいます。 TCPセッションの最初のパケットはSYNビットの存在とTCP旗で噛み付かれたACKの不在で認識されるかもしれません。 最初のパケット以外のすべてのTCPパケットで、ACKビットを設定しなければなりません。
However, there is no deterministic way of recognizing the start of a UDP based session or any non-TCP session. A heuristic approach would be to assume the first packet with hitherto non-existent session parameters (as defined in section 2.3) as constituting the start of new session.
しかしながら、UDPのベースのセッションかどんな非TCPセッションの始まりも認識するどんな決定論的な方法もありません。 発見的なアプローチは新しいセッションの始まりを構成するとしてこれまで実在しないセッションパラメタ(セクション2.3で定義されるように)がある最初のパケットを仮定するだろうことです。
2.6. End of session for TCP, UDP and others
2.6. TCP、UDP、および他のもののためのセッションの終わり
The end of a TCP session is detected when FIN is acknowledged by both halves of the session or when either half receives a segment with the RST bit in TCP flags field. However, because it is impossible for a NAT device to know whether the packets it sees will actually be delivered to the destination (they may be dropped between the NAT device and the destination), the NAT device cannot safely assume that the segments containing FINs or SYNs will be the last packets of the session (i.e., there could be retransmissions). Consequently, a session can be assumed to have been terminated only after a period of
どちらかが半分受信するとき、TCPセッションの終わりは検出されて、いつFINがセッションの両方の半分で承認されるかということであるかRSTビットがTCPにあるセグメントが分野に旗を揚げさせます。 しかしながら、NATデバイスが、それが見るパケットが実際に送付先に提供されるかどうかを(それらはNATデバイスと目的地の間に下げられるかもしれません)知るのが、不可能であるので、NATデバイスは、FINsかSYNsを含むセグメントがセッションの最後のパケットになると安全に仮定できません(すなわち、「再-トランスミッション」があるかもしれません)。 その結果、期間の後にだけセッションが終えられたと思うことができます。
Srisuresh & Holdrege Informational [Page 4] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[4ページ]のRFC2663NAT用語と問題1999年8月
4 minutes subsequent to this detection. The need for this extended wait period is described in RFC 793 [Ref 7], which suggests a TIME- WAIT duration of 2 * MSL (Maximum Segment Lifetime) or 4 minutes.
この検出へのその後の4分。 この延ばされた待ちの期間の必要性はRFC793[審判7]で説明されます。(RFCは(最大のSegment Lifetime)か4分間2*MSLのタイム誌のWAIT持続時間を勧めます)。
Note that it is also possible for a TCP connection to terminate without the NAT device becoming aware of the event (e.g., in the case where one or both peers reboot). Consequently, garbage collection is necessary on NAT devices to clean up unused state about TCP sessions that no longer exist. However, it is not possible in the general case to distinguish between connections that have been idle for an extended period of time from those that no longer exist. In the case of UDP-based sessions, there is no single way to determine when a session ends, since UDP-based protocols are application specific.
また、TCP接続がイベントを意識するようになるNATデバイスなしで終わるのも、可能であることに注意してください(例えば、ものか同輩の両方がリブートする場合で)。 その結果、ガーベージコレクションがもう存在しないTCPおよそセッション未使用の状態にきれいにするNATデバイスで必要です。 しかしながら、一般的な場合では、もう存在しないものからの時間の長期間の間無駄である接続を見分けるのは可能ではありません。 UDPベースのセッションの場合には、セッションがいつ終わるかを決定するどんなただ一つの方法もありません、UDPベースのプロトコルがアプリケーション特有であるので。
Many heuristic approaches are used to terminate sessions. You can make the assumption that TCP sessions that have not been used for say, 24 hours, and non-TCP sessions that have not been used for a couple of minutes, are terminated. Often this assumption works, but sometimes it doesn't. These idle period session timeouts vary a great deal both from application to application and for different sessions of the same application. Consequently, session timeouts must be configurable. Even so, there is no guarantee that a satisfactory value can be found. Further, as stated in section 2.3, there is no guarantee that NAT's view of session termination will coincide with that of the application.
多くの発見的なアプローチが、セッションを終えるのに使用されます。 あなたはそれが使用されていないTCPセッションが言うという仮定をすることができて、24時間、および2、3分間費やされていない非TCPセッションは終えられます。 しばしば、この仮定は働いていますが、時々それは働いているというわけではありません。 これらの活動していない期間のセッションタイムアウトはアプリケーションからアプリケーションまで同じアプリケーションの異なったセッションように多くを変えます。 その結果、セッションタイムアウトは構成可能でなければなりません。 たとえそうだとしても、満足できる値を見つけることができる保証が全くありません。 さらに、セクション2.3で述べられているように、NATのセッション終了の視点がアプリケーションのものと一致するという保証が全くありません。
Another way to handle session terminations is to timestamp entries and keep them as long as possible and retire the longest idle session when it becomes necessary.
タイムスタンプエントリーにはセッション終了を扱う別の方法があります、そして、できるだけ長くそれらを保ってください、そして、それが必要になる最も長い無駄なセッションを回収してください。
2.7. Public/Global/External network
2.7. 公共であるかグローバルであるか外部のネットワーク
A Global or Public Network is an address realm with unique network addresses assigned by Internet Assigned Numbers Authority (IANA) or an equivalent address registry. This network is also referred as External network during NAT discussions.
GlobalかPublic Networkがユニークなネットワーク・アドレスがインターネットAssigned民数記Authority(IANA)か同等なアドレス登録によって割り当てられているアドレス分野です。 また、ExternalがNATの間議論をネットワークでつなぐとき、このネットワークは参照されます。
2.8. Private/Local network
2.8. 個人的であるかローカルのネットワーク
A private network is an address realm independent of external network addresses. Private network may also be referred alternately as Local Network. Transparent routing between hosts in private realm and external realm is facilitated by a NAT router.
私設のネットワークは外部のネットワーク・アドレスの如何にかかわらずアドレス分野です。 また、私設のネットワークはLocal Networkとして交互に参照されるかもしれません。 私設の分野と外部の分野のホストの間の見え透いたルーティングはNATルータによって容易にされます。
RFC 1918 [Ref 1] has recommendations on address space allocation for private networks. Internet Assigned Numbers Authority (IANA) has three blocks of IP address space, namely 10/8, 172.16/12, and 192.168/16 set aside for private internets. In pre-CIDR notation, the
RFC1918[審判1]は私設のネットワークのためのアドレス空間配分に推薦を持っています。 インターネットAssigned民数記Authority(IANA)は個人的なインターネットのためにすなわち、3ブロックのIPアドレス空間、10/8、172.16/12、および192.168/16を取っておかせます。 プレCIDR記法で
Srisuresh & Holdrege Informational [Page 5] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[5ページ]のRFC2663NAT用語と問題1999年8月
first block is nothing but a single class A network number, while the second block is a set of 16 contiguous class B networks, and the third block is a set of 256 contiguous class C networks.
最初のブロックはただただ一つのクラスAネットワーク・ナンバーです、2番目のブロックが1セットの16の隣接のクラスBネットワークです、そして、3番目のブロックは1セットの256の隣接のクラスCネットワークですが。
An organization that decides to use IP addresses in the address space defined above can do so without coordination with IANA or any other Internet registry such as APNIC, RIPE and ARIN. The address space can thus be used privately by many independent organizations at the same time. However, if those independent organizations later decide they wish to communicate with each other or the public Internet, they will either have to renumber their networks or enable NAT on their border routers.
上で定義されたアドレス空間にIPアドレスを使用すると決める組織がIANAかAPNICや、RIPEやARINなどのいかなる他のインターネット登録でもコーディネートなしでそうできます。 その結果、多くの独立機関は同時に、アドレス空間を個人的に使用できます。 しかしながら、それらの独立機関が、後で互いか公共のインターネットで交信したがっていると決めると、それらは、それらのネットワークに番号を付け替えさせなければならないか、または境界ルータでNATを可能にしなければならないでしょう。
2.9. Application Level gateway (ALG)
2.9. アプリケーションLevelゲートウェイ(ALG)
Not all applications lend themselves easily to translation by NAT devices; especially those that include IP addresses and TCP/UDP ports in the payload. Application Level Gateways (ALGs) are application specific translation agents that allow an application on a host in one address realm to connect to its counterpart running on a host in different realm transparently. An ALG may interact with NAT to set up state, use NAT state information, modify application specific payload and perform whatever else is necessary to get the application running across disparate address realms.
すべてのアプリケーションがNATデバイスで容易に自分たちを翻訳に与えるというわけではありません。 特にペイロードのIPアドレスとTCP/UDPポートを含んでいるもの。 アプリケーションLevel Gateways(ALGs)は対応者に接するために異なった分野で透過的にホストで走りながら1つのアドレス分野でホストの上でアプリケーションを許すアプリケーションの特定の翻訳エージェントです。 アプリケーションを異種のアドレス分野に出くわさせるのに必要であっても、他のことなら何でもALGは、状態を設立して、NAT州の情報を使用して、アプリケーションの特定のペイロードを変更して、働くためにNATと対話するかもしれません。
ALGs may not always utilize NAT state information. They may glean application payload and simply notify NAT to add additional state information in some cases. ALGs are similar to Proxies, in that, both ALGs and proxies facilitate Application specific communication between clients and servers. Proxies use a special protocol to communicate with proxy clients and relay client data to servers and vice versa. Unlike Proxies, ALGs do not use a special protocol to communicate with application clients and do not require changes to application clients.
ALGsはいつもNAT州の情報を利用するかもしれないというわけではありません。 彼らは、アプリケーションペイロードを収集して、いくつかの場合、NATが追加州の情報を加えるように単に通知するかもしれません。 ALGsがProxiesと同様である、それでは、ALGsとプロキシの両方がクライアントとサーバとのApplicationの特定のコミュニケーションを容易にします。 プロキシは、プロキシクライアントとリレークライアントデータで逆もまた同様にサーバに伝えるのに特別なプロトコルを使用します。 Proxiesと異なって、ALGsはアプリケーションクライアントとコミュニケートするのに特別なプロトコルを使用しないで、またアプリケーションクライアントに釣り銭がいません。
3. What is NAT?
3. NATは何ですか?
Network Address Translation is a method by which IP addresses are mapped from one address realm to another, providing transparent routing to end hosts. There are many variations of address translation that lend themselves to different applications. However, all flavors of NAT devices should share the following characteristics.
ネットワークAddress TranslationはIPアドレスが1つのアドレス分野から別の分野まで写像されるメソッドです、ホストを終わらせるために見え透いたルーティングを提供して。 異なったアプリケーションに自分たちを与えるアドレス変換の多くの変化があります。 しかしながら、NATデバイスのすべての風味が以下の特性を共有するべきです。
Srisuresh & Holdrege Informational [Page 6] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[6ページ]のRFC2663NAT用語と問題1999年8月
a) Transparent Address assignment.
b) Transparent routing through address translation.
(routing here refers to forwarding packets, and not
exchanging routing information)
c) ICMP error packet payload translation.
a) わかりやすいAddress課題b) アドレス変換による見え透いたルーティング。 (ここでのルーティングはパケットを進めて、ルーティング情報を交換しないのを示します) c) ICMP誤りパケットペイロード翻訳。
Below is a diagram illustrating a scenario in which NAT is enabled on a stub domain border router, connected to the Internet through a regional router made available by a service provider.
以下に、ダイヤグラムがNATがスタッブドメイン境界ルータで可能にされるシナリオを例証しながら、あります、サービスプロバイダーによって利用可能にされた地方のルータを通してインターネットに関連しています。
\ | / . /
+---------------+ WAN . +-----------------+/
|Regional Router|----------------------|Stub Router w/NAT|---
+---------------+ . +-----------------+\
. | \
. | LAN
. ---------------
Stub border
\ | / . / +---------------+ WAN+-----------------+/ |地方のルータ|----------------------|NATがあるスタッブルータ|--- +---------------+ . +-----------------+\ . | \ . | ラン。--------------- スタッブ境界
Figure 1: A typical NAT operation scenario
図1: 典型的なNAT操作シナリオ
3.1. Transparent Address Assignment
3.1. わかりやすいアドレス課題
NAT binds addresses in private network with addresses in global network and vice versa to provide transparent routing for the datagrams traversing between address realms. The binding in some cases may extend to transport level identifiers (such as TCP/UDP ports). Address binding is done at the start of a session. The following sub-sections describe two types of address assignments.
NATは、アドレス分野の間で横断されるデータグラムに見え透いたルーティングを供給するためにアドレスで私設のネットワークにアドレスを逆もまた同様に世界的なネットワークに向かわせます。いくつかの場合、結合は、平らな識別子(TCP/UDPポートなどの)を輸送するために広がるかもしれません。 セッションの始めでアドレス結合をします。 以下の小区分は2つのタイプのアドレス課題について説明します。
3.1.1. Static Address assignment
3.1.1. 静的なAddress課題
In the case of static address assignment, there is one-to-one address mapping for hosts between a private network address and an external network address for the lifetime of NAT operation. Static address assignment ensures that NAT does not have to administer address management with session flows.
静的なアドレス課題の場合には、NAT操作の生涯のための個人的なネットワーク・アドレスと外部のネットワーク・アドレスの間には、ホストへの1〜1つのアドレス・マッピングがあります。 静的なアドレス課題は、NATがセッション流れに伴うアドレス管理を管理する必要はないのを確実にします。
3.1.2. Dynamic Address assignment
3.1.2. ダイナミックなAddress課題
In this case, external addresses are assigned to private network hosts or vice versa, dynamically based on usage requirements and session flow determined heuristically by NAT. When the last session using an address binding is terminated, NAT would free the binding so that the global address could be recycled for later use. The exact nature of address assignment is specific to individual NAT implementations.
この場合、外部アドレスは、個人的なネットワークホストに割り当てられるか、またはNATで逆もまた同様です、ダイナミックに用法要件と発見的に決定するセッション流動に基づいています。 アドレス結合を使用する納会が終えられるとき、NATは、後の使用のためにグローバルアドレスを再生できるように結合を解放するでしょう。 アドレス課題の正確な本質は個々のNAT実装に特定です。
Srisuresh & Holdrege Informational [Page 7] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[7ページ]のRFC2663NAT用語と問題1999年8月
3.2. Transparent routing
3.2. 見え透いたルーティング
A NAT router sits at the border between two address realms and translates addresses in IP headers so that when the packet leaves one realm and enters another, it can be routed properly. Because NAT devices have connections to multiple address realms, they must be careful to not improperly propagate information (e.g., via routing protocols) about networks from one address realm into another, where such an advertisement would be deemed unacceptable.
NATルータは、パケットが1つの分野を出て、別のものに入るとき、適切にそれを発送できるように2つのアドレス分野の間の境界に座って、IPヘッダーでアドレスを翻訳します。 NATデバイスには複数のアドレス分野には接続があるので、彼らがネットワークに関して別のものへの1つのアドレス分野から情報を不適切に伝播しないのに(例えば、ルーティング・プロトコルで)慎重であるに違いありません。(そこでは、そのような広告が容認できないと考えられるでしょう)。
There are three phases to Address translation, as follows. Together these phases result in creation, maintenance and termination of state for sessions passing through NAT devices.
以下のAddress翻訳への三相があります。 これらのフェーズはNATデバイスを通り抜けるセッションのための状態の作成、メインテナンス、および終了を一緒に、もたらします。
3.2.1. Address binding
3.2.1. アドレス結合
Address binding is the phase in which a local node IP address is associated with an external address or vice versa, for purposes of translation. Address binding is fixed with static address assignments and is dynamic at session startup time with dynamic address assignments. Once the binding between two addresses is in place, all subsequent sessions originating from or to this host will use the same binding for session based packet translation.
アドレス結合はローカルのノードIPアドレスが外部アドレスに関連しているか、逆もまた同様ですフェーズです、翻訳の目的のために。 アドレス結合は、静的なアドレス課題で固定されていて、セッション始動時間にダイナミックなアドレス課題でダイナミックです。 2つのアドレスの間の結合がいったん適所にあるようになると、ホストかこのホストに起因するのがセッションのために付きながら同じように使用するすべてのその後のセッションがパケット翻訳を基礎づけました。
New address bindings are made at the start of a new session, if such an address binding didn't already exist. Once a local address is bound to an external address, all subsequent sessions originating from the same local address or directed to the same local address will use the same binding.
そのようなアドレス結合が既に存在しなかったなら新しいセッションの始めで新しいアドレス結合をします。 ローカルアドレスがいったん外部アドレスに縛られると、同じローカルアドレスに同じローカルアドレスから発するか、または向けられたすべてのその後のセッションが同じ結合を使用するでしょう。
The start of each new session will result in the creation of a state to facilitate translation of datagrams pertaining to the session. There can be many simultaneous sessions originating from the same host, based on a single address binding.
それぞれの新しいセッションの始まりは、セッションに関してデータグラムに関する翻訳を容易にするために状態の創設に結果として生じるでしょう。 ただ一つのアドレス結合に基づいて同じホストから発するのが多くの同時のセッションにあることができます。
3.2.2. Address lookup and translation
3.2.2. アドレスルックアップと翻訳
Once a state is established for a session, all packets belonging to the session will be subject to address lookup (and transport identifier lookup, in some cases) and translation.
状態がセッションのためにいったん設置されると、セッションに属するすべてのパケットが、ルックアップ(いくつかの場合における識別子ルックアップを輸送する)と翻訳を扱うためになることがあるでしょう。
Address or transport identifier translation for a datagram will result in the datagram forwarding from the origin address realm to the destination address realm with network addresses appropriately updated.
データグラムのためのアドレスか輸送識別子翻訳が適切にネットワーク・アドレスをアップデートしている状態で発生源アドレス分野から目的地アドレス分野までのデータグラム推進をもたらすでしょう。
Srisuresh & Holdrege Informational [Page 8] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[8ページ]のRFC2663NAT用語と問題1999年8月
3.2.3. Address unbinding
3.2.3. アドレスの解くこと
Address unbinding is the phase in which a private address is no longer associated with a global address for purposes of translation. NAT will perform address unbinding when it believes that the last session using an address binding has terminated. Refer section 2.6 for some heuristic ways to handle session terminations.
アドレスの解くのはプライベート・アドレスがもう翻訳の目的のためのグローバルアドレスに関連していないフェーズです。 アドレス結合を使用する納会が終わったのが信じているとき、NATはアドレスの解くことを実行するでしょう。 セッション終了を扱ういくつかの発見している方法についてセクション2.6を参照してください。
3.3. ICMP error packet translation
3.3. ICMP誤りパケット翻訳
All ICMP error messages (with the exception of Redirect message type) will need to be modified, when passed through NAT. The ICMP error message types needing NAT modification would include Destination- Unreachable, Source-Quench, Time-Exceeded and Parameter-Problem. NAT should not attempt to modify a Redirect message type.
NATを通り抜けると、すべてのICMPエラーメッセージ(Redirectメッセージタイプを除いた)が、変更される必要があるでしょう。 手が届かなく、Source-焼き入れであって、Timeによって超えられていた状態で、NAT変更を必要とするエラーメッセージがタイプするICMPはDestinationを含んでいるでしょう。そして、Parameter-問題。 NATは、Redirectメッセージタイプを変更するのを試みるべきではありません。
Changes to ICMP error message will include changes to the original IP packet (or portions thereof) embedded in the payload of the ICMP error message. In order for NAT to be completely transparent to end hosts, the IP address of the IP header embedded in the payload of the ICMP packet must be modified, the checksum field of the same IP header must correspondingly be modified, and the accompanying transport header. The ICMP header checksum must also be modified to reflect changes made to the IP and transport headers in the payload. Furthermore, the normal IP header must also be modified.
ICMPエラーメッセージへの変化はICMPエラーメッセージのペイロードに埋め込まれたオリジナルのIPパケット(または、それの部分)への変化を含むでしょう。 NATがホストを終わらせるために完全に透明です、ICMPパケットのペイロードに埋め込まれたIPヘッダーのIPアドレスを変更しなければならなくて、同じIPヘッダーのチェックサム分野を対応する変更しなければならないということである命令、および付随の輸送ヘッダーで。 また、IPにされた変更と輸送ヘッダーをペイロードに反映するようにICMPヘッダーチェックサムを変更しなければなりません。 その上、また、普通のIPヘッダーを変更しなければなりません。
4.0. Various flavors of NAT
4.0. NATの様々な風味
There are many variations of address translation that lend themselves to different applications. NAT flavors listed in the following sub- sections are by no means exhaustive, but they do capture the significant differences that abound.
異なったアプリケーションに自分たちを与えるアドレス変換の多くの変化があります。 以下のサブセクションで記載されたNAT風味は決して徹底的ではありませんが、それらは富む著しい違いを得ます。
The following diagram will be used as a base model to illustrate NAT flavors. Host-A, with address Addr-A is located in a private realm, represented by the network N-Pri. N-Pri is isolated from external network through a NAT router. Host-X, with address Addr-X is located in an external realm, represented by the network N-Ext. NAT router with two interfaces, each attached to one of the realms provides transparent routing between the two realms. The interface to the external realm is assigned an address of Addr-Nx and the interface to private realm is assigned an address of Addr-Np. Further, it may be understood that addresses Addr-A and Addr-Np correspond to N-Pri network and the addresses Addr-X and Addr-Nx correspond to N-Ext network.
以下のダイヤグラムは、NAT風味を例証するのにベース・モデルとして使用されるでしょう。 アドレスでAを接待しているAddr-AはネットワークN-Priによって表された私設の分野に位置しています。 N-Priは外部のネットワークからNATルータまで隔離されます。 アドレスでXを接待しているAddr-XはネットワークN-Extによって表された外部の分野に位置しています。 2つのインタフェースがあるNATルータ、分野の1つに付けられたそれぞれが2つの分野の間に見え透いたルーティングを提供します。Addr-Nxのアドレスは外部の分野へのインタフェースに割り当てられます、そして、Addr-Npのアドレスは私設の分野へのインタフェースに割り当てられます。 さらに、アドレスAddr-AとAddr-NpがN-Priネットワークに対応するのが理解されるかもしれなくて、アドレスのAddr-XとAddr-NxはN-Extネットワークに対応しています。
Srisuresh & Holdrege Informational [Page 9] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[9ページ]のRFC2663NAT用語と問題1999年8月
________________
( )
( External ) +--+
( Address Realm )-- |__|
( (N-Ext) ) /____\
(________________) Host-X
| (Addr-X)
|(Addr-Nx)
+--------------+
| |
| NAT router |
| |
+--------------+
|(Addr-Np)
|
----------------
( )
+--+ ( Private )
|__|------( Address Realm )
/____\ ( (N-pri) )
Host-A (________________)
(Addr-A)
________________ ( ) (外部)です。 +--+ (アドレス分野)--|__| ((N-Ext)) /____\(________________)ホストX| (Addr-X) |(Addr-Nx) +--------------+ | | | NATルータ| | | +--------------+ |(Addr-Np) | ---------------- ( ) +--+(個人的な)|__|------(アドレス分野) /____Aを接待している(________________)\(N-pri)(Addr-a)
Figure 2: A base model to illustrate NAT terms.
図2: NAT用語を例証するベース・モデル。
4.1. Traditional NAT (or) Outbound NAT
4.1. 伝統的なNAT(or)外国行きのNAT
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. This is in contrast with Bi-directional NAT, which permits sessions in both inbound and outbound directions. A detailed description of Bi-directional NAT may be found in section 4.2.
多くの場合、伝統的なNATで、外部のネットワークで私設のネットワークの中のホストは透過的にホストにアクセスできるでしょう。 伝統的なNATでは、セッションは、uni方向上であって、私設のネットワークから外国行きです。 これはBi方向のNAT、どれがセッションのともに本国行きで入るのを許すか、そして、および外国行きの方向と比べています。 Bi方向のNATの詳述はセクション4.2で見つけられるかもしれません。
The following is a description of the properties of realms supported by traditional NAT. IP addresses of hosts in external network are unique and valid in external as well as private networks. However, the addresses of hosts in private network are unique only within the private network and may not be valid in the external network. In other words, NAT would not advertise private networks to the external realm. But, networks from the external realm may be advertised within the private network. The addresses used within private network must not overlap with the external addresses. Any given address must either be a private address or an external address; not both.
The following is a description of the properties of realms supported by traditional NAT. IP addresses of hosts in external network are unique and valid in external as well as private networks. However, the addresses of hosts in private network are unique only within the private network and may not be valid in the external network. In other words, NAT would not advertise private networks to the external realm. But, networks from the external realm may be advertised within the private network. The addresses used within private network must not overlap with the external addresses. Any given address must either be a private address or an external address; not both.
Srisuresh & Holdrege Informational [Page 10] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh & Holdrege Informational [Page 10] RFC 2663 NAT Terminology and Considerations August 1999
A traditional NAT router in figure 2 would allow Host-A to initiate sessions to Host-X, but not the other way around. Also, N-Ext is routable from within N-Pri, whereas N-Pri may not be routable from N-Ext.
A traditional NAT router in figure 2 would allow Host-A to initiate sessions to Host-X, but not the other way around. Also, N-Ext is routable from within N-Pri, whereas N-Pri may not be routable from N-Ext.
Traditional NAT is primarily used by sites using private addresses that wish to allow outbound sessions from their site.
Traditional NAT is primarily used by sites using private addresses that wish to allow outbound sessions from their site.
There are two variations to traditional NAT, namely Basic NAT and NAPT (Network Address Port Translation). These are discussed in the following sub-sections.
There are two variations to traditional NAT, namely Basic NAT and NAPT (Network Address Port Translation). These are discussed in the following sub-sections.
4.1.1. Basic NAT
4.1.1. 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.
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.
A Basic NAT router in figure 2 may be configured to translate N-Pri into a block of external addresses, say Addr-i through Addr-n, selected from the external network N-Ext.
A Basic NAT router in figure 2 may be configured to translate N-Pri into a block of external addresses, say Addr-i through Addr-n, selected from the external network N-Ext.
4.1.2. Network Address Port Translation (NAPT)
4.1.2. Network Address Port Translation (NAPT)
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.
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.
For packets outbound from the private network, NAPT would translate the source IP address, source transport identifier and related fields such as IP, TCP, UDP and ICMP header checksums. Transport identifier can be one of TCP/UDP port or ICMP query ID. For inbound packets, the destination IP address, destination transport identifier and the IP and transport header checksums are translated.
For packets outbound from the private network, NAPT would translate the source IP address, source transport identifier and related fields such as IP, TCP, UDP and ICMP header checksums. Transport identifier can be one of TCP/UDP port or ICMP query ID. For inbound packets, the destination IP address, destination transport identifier and the IP and transport header checksums are translated.
Srisuresh & Holdrege Informational [Page 11] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh & Holdrege Informational [Page 11] RFC 2663 NAT Terminology and Considerations August 1999
A NAPT router in figure 2 may be configured to translate sessions originated from N-Pri into a single external address, say Addr-i.
A NAPT router in figure 2 may be configured to translate sessions originated from N-Pri into a single external address, say Addr-i.
Very often, the external interface address Addr-Nx of NAPT router is used as the address to map N-Pri to.
Very often, the external interface address Addr-Nx of NAPT router is used as the address to map N-Pri to.
4.2. Bi-directional NAT (or) Two-Way NAT
4.2. Bi-directional NAT (or) Two-Way NAT
With a Bi-directional NAT, sessions can be initiated from hosts in the public network as well as the private network. Private network addresses are bound to globally unique addresses, statically or dynamically as connections are established in either direction. The name space (i.e., their Fully Qualified Domain Names) between hosts in private and external networks is assumed to be end-to-end unique. Hosts in external realm access private realm hosts by using DNS for address resolution. A DNS-ALG must be employed in conjunction with Bi-Directional NAT to facilitate name to address mapping. Specifically, the DNS-ALG must be capable of translating private realm addresses in DNS Queries and responses into their external realm address bindings, and vice versa, as DNS packets traverse between private and external realms.
With a Bi-directional NAT, sessions can be initiated from hosts in the public network as well as the private network. Private network addresses are bound to globally unique addresses, statically or dynamically as connections are established in either direction. The name space (i.e., their Fully Qualified Domain Names) between hosts in private and external networks is assumed to be end-to-end unique. Hosts in external realm access private realm hosts by using DNS for address resolution. A DNS-ALG must be employed in conjunction with Bi-Directional NAT to facilitate name to address mapping. Specifically, the DNS-ALG must be capable of translating private realm addresses in DNS Queries and responses into their external realm address bindings, and vice versa, as DNS packets traverse between private and external realms.
The address space requirements outlined for traditional NAT routers are applicable here as well.
The address space requirements outlined for traditional NAT routers are applicable here as well.
A Bi-directional NAT router in figure 2 would allow Host-A to initiate sessions to Host-X, and Host-X to initiate sessions to Host-A. Just as with traditional NAT, N-Ext is routable from within N-Pri, but N-Pri may not be routable from N-Ext.
A Bi-directional NAT router in figure 2 would allow Host-A to initiate sessions to Host-X, and Host-X to initiate sessions to Host-A. Just as with traditional NAT, N-Ext is routable from within N-Pri, but N-Pri may not be routable from N-Ext.
4.3. Twice NAT
4.3. Twice NAT
Twice NAT is a variation of NAT in that both the source and destination addresses are modified by NAT as a datagram crosses address realms. This is in contrast to Traditional-NAT and Bi- Directional NAT, where only one of the addresses (either source or destination) is translated. Note, there is no such term as 'Once- NAT'.
Twice NAT is a variation of NAT in that both the source and destination addresses are modified by NAT as a datagram crosses address realms. This is in contrast to Traditional-NAT and Bi- Directional NAT, where only one of the addresses (either source or destination) is translated. Note, there is no such term as 'Once- NAT'.
Twice NAT is necessary when private and external realms have address collisions. The most common case where this would happen is when a site had (improperly) numbered its internal nodes using public addresses that have been assigned to another organization. Alternatively, a site may have changed from one provider to another, but chosen to keep (internally) the addresses it had been assigned by the first provider. That provider might then later reassign those addresses to someone else. The key issue in such cases is that the address of the host in the external realm may have been assigned the
Twice NAT is necessary when private and external realms have address collisions. The most common case where this would happen is when a site had (improperly) numbered its internal nodes using public addresses that have been assigned to another organization. Alternatively, a site may have changed from one provider to another, but chosen to keep (internally) the addresses it had been assigned by the first provider. That provider might then later reassign those addresses to someone else. The key issue in such cases is that the address of the host in the external realm may have been assigned the
Srisuresh & Holdrege Informational [Page 12] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh & Holdrege Informational [Page 12] RFC 2663 NAT Terminology and Considerations August 1999
same address as a host within the local site. If that address were to appear in a packet, it would be forwarded to the internal node rather than through the NAT device to the external realm. Twice-NAT attempts to bridge these realms by translating both source and destination address of an IP packet, as the packet transitions realms.
same address as a host within the local site. If that address were to appear in a packet, it would be forwarded to the internal node rather than through the NAT device to the external realm. Twice-NAT attempts to bridge these realms by translating both source and destination address of an IP packet, as the packet transitions realms.
Twice-NAT works as follows. When Host-A wishes to initiate a session to Host-X, it issues a DNS query for Host-X. A DNS-ALG intercepts the DNS query, and in the response returned to Host-A the DNS-ALG replaces the address for Host-X with one that is properly routable in the local site (say Host-XPRIME). Host A then initiates communication with Host-XPRIME. When the packets traverse the NAT device, the source IP address is translated (as in the case of traditional NAT) and the destination address is translated to Host-X. A similar translation is performed on return packets coming from Host-X.
Twice-NAT works as follows. When Host-A wishes to initiate a session to Host-X, it issues a DNS query for Host-X. A DNS-ALG intercepts the DNS query, and in the response returned to Host-A the DNS-ALG replaces the address for Host-X with one that is properly routable in the local site (say Host-XPRIME). Host A then initiates communication with Host-XPRIME. When the packets traverse the NAT device, the source IP address is translated (as in the case of traditional NAT) and the destination address is translated to Host-X. A similar translation is performed on return packets coming from Host-X.
The following is a description of the properties of realms supported by Twice-NAT. Network address of hosts in external network are unique in external networks, but not within private network. Likewise, the network address of hosts in private network are unique only within the private network. In other words, the address space used in private network to locate hosts in private and public networks is unrelated to the address space used in public network to locate hosts in private and public networks. Twice NAT would not be allowed to advertise local networks to the external network or vice versa.
The following is a description of the properties of realms supported by Twice-NAT. Network address of hosts in external network are unique in external networks, but not within private network. Likewise, the network address of hosts in private network are unique only within the private network. In other words, the address space used in private network to locate hosts in private and public networks is unrelated to the address space used in public network to locate hosts in private and public networks. Twice NAT would not be allowed to advertise local networks to the external network or vice versa.
A Twice NAT router in figure 2 would allow Host-A to initiate sessions to Host-X, and Host-X to initiate sessions to Host-A. However, N-Ext (or a subset of N-Ext) is not routable from within N- Pri, and N-Pri is not routable from N-Ext.
A Twice NAT router in figure 2 would allow Host-A to initiate sessions to Host-X, and Host-X to initiate sessions to Host-A. However, N-Ext (or a subset of N-Ext) is not routable from within N- Pri, and N-Pri is not routable from N-Ext.
Twice NAT is typically used when address space used in a Private network overlaps with addresses used in the Public space. For example, say a private site uses the 200.200.200.0/24 address space which is officially assigned to another site in the public internet. Host_A (200.200.200.1) in Private space seeks to connect to Host_X (200.200.200.100) in Public space. In order to make this connection work, Host_X's address is mapped to a different address for Host_A and vice versa. The twice NAT located at the Private site border may be configured as follows:
Twice NAT is typically used when address space used in a Private network overlaps with addresses used in the Public space. For example, say a private site uses the 200.200.200.0/24 address space which is officially assigned to another site in the public internet. Host_A (200.200.200.1) in Private space seeks to connect to Host_X (200.200.200.100) in Public space. In order to make this connection work, Host_X's address is mapped to a different address for Host_A and vice versa. The twice NAT located at the Private site border may be configured as follows:
Srisuresh & Holdrege Informational [Page 13] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh & Holdrege Informational [Page 13] RFC 2663 NAT Terminology and Considerations August 1999
Private to Public : 200.200.200.0/24 -> 138.76.28.0/24
Public to Private : 200.200.200.0/24 -> 172.16.1.0/24
Private to Public : 200.200.200.0/24 -> 138.76.28.0/24 Public to Private : 200.200.200.0/24 -> 172.16.1.0/24
Datagram flow : Host_A(Private) -> Host_X(Public)
Datagram flow : Host_A(Private) -> Host_X(Public)
a) Within private network
a) Within private network
DA: 172.16.1.100 SA: 200.200.200.1
DA: 172.16.1.100 SA: 200.200.200.1
b) After twice-NAT translation
b) After twice-NAT translation
DA: 200.200.200.100 SA: 138.76.28.1
DA: 200.200.200.100 SA: 138.76.28.1
Datagram flow Host_X (Public) -> Host_A (Private)
Datagram flow Host_X (Public) -> Host_A (Private)
a) Within Public network
a) Within Public network
DA: 138.76.28.1 SA: 200.200.200.100
DA: 138.76.28.1 SA: 200.200.200.100
b) After twice-NAT translation, in private network
b) After twice-NAT translation, in private network
SA: 200.200.200.1 DA: 172.16.1.100
SA: 200.200.200.1 DA: 172.16.1.100
4.4. Multihomed NAT
4.4. Multihomed NAT
There are limitations to using NAT. For example, requests and responses pertaining to a session must be routed via the same NAT router, as a NAT router maintains state information for sessions established through it. For this reason, it is often suggested that NAT routers be operated on a border router unique to a stub domain, where all IP packets are either originated from the domain or destined to the domain. However, such a configuration would turn a NAT router into a single point of failure.
There are limitations to using NAT. For example, requests and responses pertaining to a session must be routed via the same NAT router, as a NAT router maintains state information for sessions established through it. For this reason, it is often suggested that NAT routers be operated on a border router unique to a stub domain, where all IP packets are either originated from the domain or destined to the domain. However, such a configuration would turn a NAT router into a single point of failure.
In order for a private network to ensure that connectivity with external networks is retained even as one of the NAT links fail, it is often desirable to multihome the private network to same or multiple service providers with multiple connections from the private domain, be it from same or different NAT boxes.
In order for a private network to ensure that connectivity with external networks is retained even as one of the NAT links fail, it is often desirable to multihome the private network to same or multiple service providers with multiple connections from the private domain, be it from same or different NAT boxes.
For example, a private network could have links to two different providers and the sessions from private hosts could flow through the NAT router with the best metric for a destination. When one of NAT routers fail, the other could route traffic for all connections.
For example, a private network could have links to two different providers and the sessions from private hosts could flow through the NAT router with the best metric for a destination. When one of NAT routers fail, the other could route traffic for all connections.
Srisuresh & Holdrege Informational [Page 14] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh & Holdrege Informational [Page 14] RFC 2663 NAT Terminology and Considerations August 1999
Multiple NAT boxes or multiple links on the same NAT box, sharing the same NAT configuration can provide fail-safe backup for each other. In such a case, it is necessary for backup NAT device to exchange state information so that a backup NAT can take on session load transparently when the primary NAT fails. NAT backup becomes simpler, when configuration is based on static maps.
Multiple NAT boxes or multiple links on the same NAT box, sharing the same NAT configuration can provide fail-safe backup for each other. In such a case, it is necessary for backup NAT device to exchange state information so that a backup NAT can take on session load transparently when the primary NAT fails. NAT backup becomes simpler, when configuration is based on static maps.
5.0. Realm Specific IP (RSIP)
5.0. Realm Specific IP (RSIP)
"Realm Specific IP" (RSIP) is used to characterize the functionality of a realm-aware host in a private realm, which assumes realm- specific IP address to communicate with hosts in private or external realm.
"Realm Specific IP" (RSIP) is used to characterize the functionality of a realm-aware host in a private realm, which assumes realm- specific IP address to communicate with hosts in private or external realm.
A "Realm Specific IP Client" (RSIP client) is a host in a private network that adopts an address in an external realm when connecting to hosts in that realm to pursue end-to-end communication. Packets generated by hosts on either end in such a setup would be based on addresses that are end-to-end unique in the external realm and do not require translation by an intermediary process.
A "Realm Specific IP Client" (RSIP client) is a host in a private network that adopts an address in an external realm when connecting to hosts in that realm to pursue end-to-end communication. Packets generated by hosts on either end in such a setup would be based on addresses that are end-to-end unique in the external realm and do not require translation by an intermediary process.
A "Realm Specific IP Server" (RSIP server) is a node resident on both private and external realms, that can facilitate routing of external realm packets within a private realm. These packets may either have been originated by an RSIP client or directed to an RSIP-client. RSIP-Server may also be the same node that assigns external realm addresses to RSIP-Clients.
A "Realm Specific IP Server" (RSIP server) is a node resident on both private and external realms, that can facilitate routing of external realm packets within a private realm. These packets may either have been originated by an RSIP client or directed to an RSIP-client. RSIP-Server may also be the same node that assigns external realm addresses to RSIP-Clients.
There are two variations to RSIP, namely Realm-specific Address IP (RSA-IP) and Realm-Specific Address and Port IP (RSAP-IP). These variations are discussed in the following sub-sections.
There are two variations to RSIP, namely Realm-specific Address IP (RSA-IP) and Realm-Specific Address and Port IP (RSAP-IP). These variations are discussed in the following sub-sections.
5.1. Realm Specific Address IP (RSA-IP)
5.1. Realm Specific Address IP (RSA-IP)
A Realm Specific Address IP (RSA-IP) client adopts an IP address from the external address space when connecting to a host in external realm. Once an RSA-IP client assumes an external address, no other host in private or external domain can assume the same address, until that address is released by the RSA-IP client.
A Realm Specific Address IP (RSA-IP) client adopts an IP address from the external address space when connecting to a host in external realm. Once an RSA-IP client assumes an external address, no other host in private or external domain can assume the same address, until that address is released by the RSA-IP client.
The following is a discussion of routing alternatives that may be pursued for the end-to-end RSA-IP packets within private realm. One approach would be to tunnel the packet to the destination. The outer header can be translated by NAT as normal without affecting the addresses used in the internal header. Another approach would be to set up a bi-directional tunnel between the RSA-IP Client and the border router straddling the two address realms. Packets to and from the client would be tunneled, but packets would be forwarded as
The following is a discussion of routing alternatives that may be pursued for the end-to-end RSA-IP packets within private realm. One approach would be to tunnel the packet to the destination. The outer header can be translated by NAT as normal without affecting the addresses used in the internal header. Another approach would be to set up a bi-directional tunnel between the RSA-IP Client and the border router straddling the two address realms. Packets to and from the client would be tunneled, but packets would be forwarded as
Srisuresh & Holdrege Informational [Page 15] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh & Holdrege Informational [Page 15] RFC 2663 NAT Terminology and Considerations August 1999
normal between the border router and the remote destination. Note, the tunnel from the client TO the border router may not be necessary. You might be able to just forward the packet directly. This should work so long as your internal network isn't filtering packets based on source addresses (which in this case would be external addresses).
normal between the border router and the remote destination. Note, the tunnel from the client TO the border router may not be necessary. You might be able to just forward the packet directly. This should work so long as your internal network isn't filtering packets based on source addresses (which in this case would be external addresses).
As an example, Host-A in figure 2 above, could assume an address Addr-k from the external realm and act as RSA-IP-Client to allow end-to-end sessions between Addr-k and Addr-X. Traversal of end-to- end packets within private realm may be illustrated as follows:
As an example, Host-A in figure 2 above, could assume an address Addr-k from the external realm and act as RSA-IP-Client to allow end-to-end sessions between Addr-k and Addr-X. Traversal of end-to- end packets within private realm may be illustrated as follows:
First method, using NAT router enroute to translate: ===================================================
First method, using NAT router enroute to translate: ===================================================
Host-A NAT router Host-X ------ ----------- ------
Host-A NAT router Host-X ------ ----------- ------
<Outer IP header, with src=Addr-A, Dest=Addr-X>, embedding <End-to-end packet, with src=Addr-k, Dest=Addr-X> ----------------------------->
<Outer IP header, with src=Addr-A, Dest=Addr-X>, embedding <End-to-end packet, with src=Addr-k, Dest=Addr-X> ----------------------------->
<Outer IP header, with
src=Addr-k, Dest=Addr-X>,
embedding
<End-to-end packet, with
src=Addr-k, Dest=Addr-X>
--------------------------->
<Outer IP header, with src=Addr-k, Dest=Addr-X>, embedding <End-to-end packet, with src=Addr-k, Dest=Addr-X> --------------------------->
.
.
.
. . .
<Outer IP header, with
src=Addr-X, Dest=Addr-k>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-k>
<---------------------------------
<Outer IP header, with src=Addr-X, Dest=Addr-k>, embedding <End-to-end packet, with src=Addr-X, Dest=Addr-k> <---------------------------------
<Outer IP header, with
src=Addr-X, Dest=Addr-A>,
embedding <End-to-end packet,
with src=Addr-X, Dest=Addr-k>
<--------------------------------------
<Outer IP header, with src=Addr-X, Dest=Addr-A>, embedding <End-to-end packet, with src=Addr-X, Dest=Addr-k> <--------------------------------------
Srisuresh & Holdrege Informational [Page 16] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh & Holdrege Informational [Page 16] RFC 2663 NAT Terminology and Considerations August 1999
Second method, using a tunnel within private realm: ==================================================
Second method, using a tunnel within private realm: ==================================================
Host-A NAT router Host-X ------ ----------- ------
Host-A NAT router Host-X ------ ----------- ------
<Outer IP header, with src=Addr-A, Dest=Addr-Np>, embedding <End-to-end packet, with src=Addr-k, Dest=Addr-X> ----------------------------->
<Outer IP header, with src=Addr-A, Dest=Addr-Np>, embedding <End-to-end packet, with src=Addr-k, Dest=Addr-X> ----------------------------->
<End-to-end packet, with
src=Addr-k, Dest=Addr-X>
------------------------------->
<End-to-end packet, with src=Addr-k, Dest=Addr-X> ------------------------------->
.
.
.
. . .
<End-to-end packet, with
src=Addr-X, Dest=Addr-k>
<--------------------------------
<End-to-end packet, with src=Addr-X, Dest=Addr-k> <--------------------------------
<Outer IP header, with
src=Addr-Np, Dest=Addr-A>,
embedding <End-to-end packet,
with src=Addr-X, Dest=Addr-k>
<----------------------------------
<Outer IP header, with src=Addr-Np, Dest=Addr-A>, embedding <End-to-end packet, with src=Addr-X, Dest=Addr-k> <----------------------------------
There may be other approaches to pursue.
There may be other approaches to pursue.
An RSA-IP-Client has the following characteristics. The collective set of operations performed by an RSA-IP-Client may be termed "RSA- IP".
An RSA-IP-Client has the following characteristics. The collective set of operations performed by an RSA-IP-Client may be termed "RSA- IP".
1. Aware of the realm to which its peer nodes belong.
1. Aware of the realm to which its peer nodes belong.
2. Assumes an address from external realm when communicating with
hosts in that realm. Such an address may be assigned statically
or obtained dynamically (through a yet-to-be-defined protocol)
from a node capable of assigning addresses from external realm.
RSA-IP-Server could be the node coordinating external realm
address assignment.
2. Assumes an address from external realm when communicating with hosts in that realm. Such an address may be assigned statically or obtained dynamically (through a yet-to-be-defined protocol) from a node capable of assigning addresses from external realm. RSA-IP-Server could be the node coordinating external realm address assignment.
Srisuresh & Holdrege Informational [Page 17] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh & Holdrege Informational [Page 17] RFC 2663 NAT Terminology and Considerations August 1999
3. Route packets to external hosts using an approach amenable to
RSA-IP-Server. In all cases, RSA-IP-Client will likely need
to act as a tunnel end-point, capable of encapsulating
end-to-end packets while forwarding and decapsulating in the
return path.
3. Route packets to external hosts using an approach amenable to RSA-IP-Server. In all cases, RSA-IP-Client will likely need to act as a tunnel end-point, capable of encapsulating end-to-end packets while forwarding and decapsulating in the return path.
"Realm Specific Address IP Server" (RSA-IP server) is a node resident on both private and external realms, that facilitates routing of external realm packets specific to RSA-IP clients inside a private realm. An RSA-IP-Server may be described as having the following characteristics.
"Realm Specific Address IP Server" (RSA-IP server) is a node resident on both private and external realms, that facilitates routing of external realm packets specific to RSA-IP clients inside a private realm. An RSA-IP-Server may be described as having the following characteristics.
1. May be configured to assign addresses from external realm to
RSA-IP-Clients, either statically or dynamically.
1. May be configured to assign addresses from external realm to RSA-IP-Clients, either statically or dynamically.
2. Must be a router resident on both the private and external
address realms.
2. Must be a router resident on both the private and external address realms.
3. Must be able to provide a mechanism to route external realm
packets within private realm. Of the two approaches described,
the first approach requires RSA-IP-Server to be a NAT router
providing transparent routing for the outer header. This
approach requires the external peer to be a tunnel end-point.
3. Must be able to provide a mechanism to route external realm packets within private realm. Of the two approaches described, the first approach requires RSA-IP-Server to be a NAT router providing transparent routing for the outer header. This approach requires the external peer to be a tunnel end-point.
With the second approach, an RSA-IP-Server could be any router
(including a NAT router) that can be a tunnel end-point with
RSA-IP-Clients. It would detunnel end-to-end packets outbound
from RSA-IP-Clients and forward to external hosts. On the
return path, it would locate RSA-IP-Client tunnel, based on the
destination address of the end-to-end packet and encapsulate the
packet in a tunnel to forward to RSA-IP-Client.
With the second approach, an RSA-IP-Server could be any router (including a NAT router) that can be a tunnel end-point with RSA-IP-Clients. It would detunnel end-to-end packets outbound from RSA-IP-Clients and forward to external hosts. On the return path, it would locate RSA-IP-Client tunnel, based on the destination address of the end-to-end packet and encapsulate the packet in a tunnel to forward to RSA-IP-Client.
RSA-IP-Clients may pursue any of the IPsec techniques, namely transport or tunnel mode Authentication and confidentiality using AH and ESP headers on the embedded packets. Any of the tunneling techniques may be adapted for encapsulation between RSA-IP-Client and RSA-IP-Server or between RSA-IP-Client and external host. For example, IPsec tunnel mode encapsulation is a valid type of encapsulation that ensures IPsec authentication and confidentiality for the embedded end-to-end packets.
RSA-IP-Clients may pursue any of the IPsec techniques, namely transport or tunnel mode Authentication and confidentiality using AH and ESP headers on the embedded packets. Any of the tunneling techniques may be adapted for encapsulation between RSA-IP-Client and RSA-IP-Server or between RSA-IP-Client and external host. For example, IPsec tunnel mode encapsulation is a valid type of encapsulation that ensures IPsec authentication and confidentiality for the embedded end-to-end packets.
5.2 Realm Specific Address and port IP (RSAP-IP)
5.2 Realm Specific Address and port IP (RSAP-IP)
Realm Specific Address and port IP (RSAP-IP) is a variation of RSIP in that multiple private hosts use a single external address, multiplexing on transport IDentifiers (i.e., TCP/UDP port numbers and ICMP Query IDs).
Realm Specific Address and port IP (RSAP-IP) is a variation of RSIP in that multiple private hosts use a single external address, multiplexing on transport IDentifiers (i.e., TCP/UDP port numbers and ICMP Query IDs).
Srisuresh & Holdrege Informational [Page 18] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh & Holdrege Informational [Page 18] RFC 2663 NAT Terminology and Considerations August 1999
"RSAP-IP-Client" may be defined similar to RSA-IP-Client with the variation that RSAP-IP-Client assumes a tuple of (external address, transport Identifier) when connecting to hosts in external realm to pursue end-to-end communication. As such, communication with external nodes for an RSAP-IP-Client may be limited to TCP, UDP and ICMP sessions.
"RSAP-IP-Client" may be defined similar to RSA-IP-Client with the variation that RSAP-IP-Client assumes a tuple of (external address, transport Identifier) when connecting to hosts in external realm to pursue end-to-end communication. As such, communication with external nodes for an RSAP-IP-Client may be limited to TCP, UDP and ICMP sessions.
"RSAP-IP-Server" is similar to RSA-IP-Server in that it facilitates routing of external realm packets specific to RSAP-IP clients inside a private realm. Typically, an RSAP-IP-Server would also be the one to assign transport tuples to RSAP-IP-Clients.
"RSAP-IP-Server" is similar to RSA-IP-Server in that it facilitates routing of external realm packets specific to RSAP-IP clients inside a private realm. Typically, an RSAP-IP-Server would also be the one to assign transport tuples to RSAP-IP-Clients.
A NAPT router enroute could serve as RSAP-IP-Server, when the outer encapsulation is TCP/UDP based and is addressed between the RSAP-IP- Client and external peer. This approach requires the external peer to be the end-point of TCP/UDP based tunnel. Using this approach, RSAP-IP-Clients may pursue any of the IPsec techniques, namely transport or tunnel mode authentication and confidentiality using AH and ESP headers on the embedded packets. Note however, IPsec tunnel mode is not a valid type of encapsulation, as a NAPT router cannot provide routing transparency to AH and ESP protocols.
A NAPT router enroute could serve as RSAP-IP-Server, when the outer encapsulation is TCP/UDP based and is addressed between the RSAP-IP- Client and external peer. This approach requires the external peer to be the end-point of TCP/UDP based tunnel. Using this approach, RSAP-IP-Clients may pursue any of the IPsec techniques, namely transport or tunnel mode authentication and confidentiality using AH and ESP headers on the embedded packets. Note however, IPsec tunnel mode is not a valid type of encapsulation, as a NAPT router cannot provide routing transparency to AH and ESP protocols.
Alternately, packets may be tunneled between RSAP-IP-Client and RSAP-IP-Server such that RSAP-IP-Server would detunnel packets outbound from RSAP-IP-Clients and forward to external hosts. On the return path, RSAP-IP-Server would locate RSAP-IP-Client tunnel, based on the tuple of (destination address, transport Identifier) and encapsulate the original packet within a tunnel to forward to RSAP- IP-Client. With this approach, there is no limitation on the tunneling technique employed between RSAP-IP-Client and RSAP-IP- Server. However, there are limitations to applying IPsec based security on end-to-end packets. Transport mode based authentication and integrity may be attained. But, confidentiality cannot be permitted because RSAP-IP-Server must be able to examine the destination transport Identifier in order to identify the RSAP-IP- tunnel to forward inbound packets to. For this reason, only the transport mode TCP, UDP and ICMP packets protected by AH and ESP- authentication can traverse a RSAP-IP-Server using this approach.
Alternately, packets may be tunneled between RSAP-IP-Client and RSAP-IP-Server such that RSAP-IP-Server would detunnel packets outbound from RSAP-IP-Clients and forward to external hosts. On the return path, RSAP-IP-Server would locate RSAP-IP-Client tunnel, based on the tuple of (destination address, transport Identifier) and encapsulate the original packet within a tunnel to forward to RSAP- IP-Client. With this approach, there is no limitation on the tunneling technique employed between RSAP-IP-Client and RSAP-IP- Server. However, there are limitations to applying IPsec based security on end-to-end packets. Transport mode based authentication and integrity may be attained. But, confidentiality cannot be permitted because RSAP-IP-Server must be able to examine the destination transport Identifier in order to identify the RSAP-IP- tunnel to forward inbound packets to. For this reason, only the transport mode TCP, UDP and ICMP packets protected by AH and ESP- authentication can traverse a RSAP-IP-Server using this approach.
As an example, say Host-A in figure 2 above, obtains a tuple of (Addr-Nx, TCP port T-Nx) from NAPT router to act as RSAP-IP-Client to initiate end-to-end TCP sessions with Host-X. Traversal of end-to- end packets within private realm may be illustrated as follows. In the first method, outer layer of the outgoing packet from Host-A uses (private address Addr-A, source port T-Na) as source tuple to communicate with Host-X. NAPT router enroute translates this tuple into (Addr-Nx, Port T-Nxa). This translation is independent of RSAP- IP-Client tuple parameters used in the embedded packet.
As an example, say Host-A in figure 2 above, obtains a tuple of (Addr-Nx, TCP port T-Nx) from NAPT router to act as RSAP-IP-Client to initiate end-to-end TCP sessions with Host-X. Traversal of end-to- end packets within private realm may be illustrated as follows. In the first method, outer layer of the outgoing packet from Host-A uses (private address Addr-A, source port T-Na) as source tuple to communicate with Host-X. NAPT router enroute translates this tuple into (Addr-Nx, Port T-Nxa). This translation is independent of RSAP- IP-Client tuple parameters used in the embedded packet.
Srisuresh & Holdrege Informational [Page 19] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh & Holdrege Informational [Page 19] RFC 2663 NAT Terminology and Considerations August 1999
First method, using NAPT router enroute to translate: ====================================================
First method, using NAPT router enroute to translate: ====================================================
Host-A NAPT router Host-X ------ ----------- ------
Host-A NAPT router Host-X ------ ----------- ------
<Outer TCP/UDP packet, with src=Addr-A, Src Port=T-Na, Dest=Addr-X>, embedding <End-to-end packet, with src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X> ----------------------------->
<Outer TCP/UDP packet, with src=Addr-A, Src Port=T-Na, Dest=Addr-X>, embedding <End-to-end packet, with src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X> ----------------------------->
<Outer TCP/UDP packet, with
src=Addr-Nx, Src Port=T-Nxa,
Dest=Addr-X>,
embedding
<End-to-end packet, with
src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X>
--------------------------------------->
<Outer TCP/UDP packet, with src=Addr-Nx, Src Port=T-Nxa, Dest=Addr-X>, embedding <End-to-end packet, with src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X> --------------------------------------->
.
.
.
. . .
<Outer TCP/UDP packet with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nxa>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<----------------------------------
<Outer TCP/UDP packet with src=Addr-X, Dest=Addr-Nx, Dest Port=T-Nxa>, embedding <End-to-end packet, with src=Addr-X, Dest=Addr-Nx, Dest Port=T-Nx> <----------------------------------
<Outer TCP/UDP packet, with
src=Addr-X, Dest=Addr-A,
Dest Port=T-Na>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<-----------------------------------
<Outer TCP/UDP packet, with src=Addr-X, Dest=Addr-A, Dest Port=T-Na>, embedding <End-to-end packet, with src=Addr-X, Dest=Addr-Nx, Dest Port=T-Nx> <-----------------------------------
Srisuresh & Holdrege Informational [Page 20] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[20ページ]のRFC2663NAT用語と問題1999年8月
Second method, using a tunnel within private realm: ==================================================
私設の分野の中でトンネルを使用する2番目のメソッド: ==================================================
Host-A NAPT router Host-X ------ ----------- ------
Aを接待しているNAPTルータHost-X------ ----------- ------
<Outer IP header, with src=Addr-A, Dest=Addr-Np>, embedding <End-to-end packet, with src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X> ----------------------------->
src=Addr-A、src=Addr-Nx、Src Port=T-Nx、Dest=Addr-X>で<Endから終わりへのパケットを埋め込むDest=Addr-Np>がある<の外側のIPヘッダー----------------------------->。
<End-to-end packet, with
src=Addr-Nx, Src Port=T-Nx,
Dest=Addr-X>
-------------------------------->
src=Addr-Nx、Src Port=T-Nx、Dest=Addr-X>がある<エンドから終わりへのパケット-------------------------------->。
.
.
.
. . .
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<----------------------------------
src=Addr-X、Dest=Addr-Nx、Dest Port=T-Nx><がある<エンドから終わりへのパケット----------------------------------
<Outer IP header, with
src=Addr-Np, Dest=Addr-A>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<----------------------------------
src=Addr-Np、src=Addr-X、Dest=Addr-Nx、Dest Port=T-Nx><で<Endから終わりへのパケットを埋め込むDest=Addr-A>がある<の外側のIPヘッダー----------------------------------
6.0. Private Networks and Tunnels
6.0. 私設のネットワークとトンネル
Let us consider the case where your private network is connected to the external world via tunnels. In such a case, tunnel encapsulated traffic may or may not contain translated packets depending upon the characteristics of address realms a tunnel is bridging.
あなたの私設のネットワークがトンネルを通って外界に接続されるケースを考えましょう。 このような場合には、トラフィックであるとカプセル化されたトンネルはトンネルがブリッジしているアドレス分野の特性に依存する翻訳されたパケットを含むかもしれません。
The following subsections discuss two scenarios where tunnels are used (a) in conjunction with Address translation, and (b) without translation.
以下の小区分は、Address翻訳に関連してトンネルが中古の(a)である2つのシナリオについて議論して、翻訳なしで(b)について議論します。
Srisuresh & Holdrege Informational [Page 21] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[21ページ]のRFC2663NAT用語と問題1999年8月
6.1. Tunneling translated packets
6.1. トンネリングはパケットを翻訳しました。
All variations of address translations discussed in the previous section can be applicable to direct connected links as well as tunnels and virtual private networks (VPNs).
前項で議論したアドレス変換のすべての変化がトンネルと同様に接続リンクと仮想私設網(VPNs)を指示するのにおいて適切である場合があります。
For example, a private network connected to a business partner through a VPN could employ traditional NAT to communicate with the partner. Likewise, it is possible to employ twice NAT, if the partner's address space overlapped with the private network. There could be a NAT device on one end of the tunnel or on both ends of the tunnel. In all cases, traffic across the VPN can be encrypted for security purposes. Security here refers to security for traffic across VPNs alone. End-to-end security requires trusting NAT devices within private network.
例えば、VPNを通してビジネスパートナーに接続された私設のネットワークは、パートナーとコミュニケートするのに伝統的なNATを使うことができました。 同様に、NATであり、アドレス空間がパートナーのものであるなら私設のネットワークに重なったのは、二度雇用に可能です。 トンネルの片端の上、または、トンネルの両端の上にNATデバイスがあるかもしれません。 すべての場合では、セキュリティ目的のためにVPNの向こう側のトラフィックを暗号化できます。 ここのセキュリティはVPNsの向こう側にトラフィックについて単独でセキュリティについて言及します。 終わりから終わりへのセキュリティは、私設のネットワークの中でNATデバイスを信じるのを必要とします。
6.2. Backbone partitioned private Networks
6.2. バックボーンは個人的なNetworksを仕切りました。
There are many instances where a private network (such as a corporate network) is spread over different locations and use public backbone for communications between those locations. In such cases, it is not desirable to do address translation, both because large numbers of hosts may want to communicate across the backbone, thus requiring large address tables, and because there will be more applications that depend on configured addresses, as opposed to going to a name server. We call such a private network a backbone-partitioned private network.
それらの位置の間には、多くのインスタンスが私設のネットワーク(企業ネットワークなどの)が別の場所に広がって、コミュニケーションに公共のバックボーンを使用することであるところにあります。 そのような場合、アドレス変換をするのは望ましくはありません、その結果、ともに、多くのホストがバックボーンの向こう側に交信したがっているかもしれなくて、構成されたアドレスによるより多くの利用があるのでネームサーバに行くことと対照的に私たちが. そのような私設のネットワークをバックボーンで仕切られた私設のネットワークと呼んで、大きいアドレス・テーブルを必要とするので。
Backbone-partitioned stubs should behave as though they were a non- partitioned stub. That is, the routers in all partitions should maintain routes to the local address spaces of all partitions. Of course, the (public) backbones do not maintain routes to any local addresses. Therefore, the border routers must tunnel (using VPNs) through the backbones using encapsulation. To do this, each NAT box will set aside a global address for tunneling.
バックボーンで仕切られたスタッブはまるでそれらが非仕切られたスタッブであるかのように振る舞うはずです。 すなわち、すべてのパーティションにおけるルータはすべてのパーティションのローカルアドレス空間にルートを維持するべきです。 もちろん、(公共)のバックボーンはどんなローカルのアドレスにもルートを維持しません。 したがって、カプセル化を使用することで境界ルータはバックボーンを通してトンネルを堀らなければなりません(VPNsを使用します)。 これをするために、それぞれのNAT箱はトンネリングのためにグローバルアドレスをかたわらに置くでしょう。
When a NAT box x in stub partition X wishes to deliver a packet to stub partition Y, it will encapsulate the packet in an IP header with destination address set to the global address of NAT box y that has been reserved for encapsulation. When NAT box y receives a packet with that destination address, it decapsulates the IP header and routes the packet internally. Note, there is no address translation in the process; merely transfer of private network packets over an external network tunnel backbone.
スタッブパーティションXにおけるNAT箱xがパーティションYを引き抜くためにパケットを提供したがっているとき、それはIPヘッダーでカプセル化のために予約されたNAT箱yのグローバルアドレスに設定された送付先アドレスでパケットをカプセルに入れるでしょう。 NAT箱yがその送付先アドレスでパケットを受けるとき、それは、IPヘッダーをdecapsulatesして、内部的にパケットを発送します。 アドレス変換が全くプロセスにないことに注意してください。 単に外部のネットワークトンネルバックボーンの上の個人的なネットワークパケットの転送。
Srisuresh & Holdrege Informational [Page 22] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[22ページ]のRFC2663NAT用語と問題1999年8月
7.0. NAT operational characteristics
7.0. NATの操作上の特性
NAT devices are application unaware in that the translations are limited to IP/TCP/UDP/ICMP headers and ICMP error messages only. NAT devices do not change the payload of the packets, as payloads tend to be application specific.
翻訳がIP/TCP/UDP/ICMPヘッダーとICMPエラーメッセージだけに制限されるので、NATデバイスはアプリケーション気づきません。 ペイロードが、アプリケーション特有である傾向があるとき、NATデバイスはパケットのペイロードを変えません。
NAT devices (without the inclusion of ALGs) do not examine or modify transport payload. For this reason, NAT devices are transparent to applications in many cases. There are two areas, however, where NAT devices often cause difficulties: 1) when an application payload includes an IP address, and 2) when end-to-end security is needed. Note, this is not a comprehensive list.
NATデバイス(ALGsの包含のない)は、輸送ペイロードを調べもしませんし、変更もしません。 この理由で、多くの場合、NATデバイスはアプリケーションに透明です。 しかしながら、2つの領域がNATデバイスがしばしば困難を引き起こすところにあります: 1) アプリケーションペイロードがIPアドレスを含んで、終わりから終わりへのセキュリティであるときに2が)必要であるときに。 これが総覧でないことに注意してください。
Application layer security techniques that do not make use of or depend on IP addresses will work correctly in the presence of NAT (e.g., TLS, SSL and ssh). In contrast, transport layer techniques such as IPSec transport mode or the TCP MD5 Signature Option RFC 2385 [Ref 17] do not.
IPアドレスに利用しないか、またはよらない応用層セキュリティのテクニックはNAT(例えば、TLS、SSL、およびセキュアシェル (SSH))があるとき正しく利くでしょう。 対照的に、IPSec交通機関かTCP MD5 Signature Option RFC2385[審判17]などのトランスポート層のテクニックはそうしません。
In IPSec transport mode, both AH and ESP have an integrity check covering the entire payload. When the payload is TCP or UDP, the TCP/UDP checksum is covered by the integrity check. When a NAT device modifies an address the checksum is no longer valid with respect to the new address. Normally, NAT also updates the checksum, but this is ineffective when AH and ESP are used. Consequently, receivers will discard a packet either because it fails the IPSec integrity check (if the NAT device updates the checksum), or because the checksum is invalid (if the NAT device leaves the checksum unmodified).
IPSec交通機関で、保全は、全体のペイロードをカバーしながら、AHと超能力の両方でチェックします。 ペイロードがTCPかUDPであるときに、TCP/UDPチェックサムは保全チェックでカバーされています。 NATデバイスがアドレスを変更するとき、チェックサムはもう新しいアドレスに関して有効ではありません。 また、通常、NATはチェックサムをアップデートしますが、AHと超能力が使用されているとき、これは効力がありません。 その結果、IPSec保全チェックに失敗するか(NATデバイスがチェックサムをアップデートするなら)、またはチェックサムが無効であるので(NATデバイスがチェックサムを変更されていないままにするなら)、受信機はパケットを捨てるでしょう。
Note that IPsec tunnel mode ESP is permissible so long as the embedded packet contents are unaffected by the outer IP header translation. Although this technique does not work in traditional NAT deployments (i.e., where hosts are unaware that NATs are present), the technique is applicable to Realm-Specific IP as described in Section 5.0.
そのIPsecトンネルモードに注意してください。埋め込まれたパケットコンテンツが影響を受けない限り、超能力は外側のIPヘッダー翻訳で許されています。 このテクニックは伝統的なNAT展開では利きませんが(すなわち、どこで、ホストはNATsが存在しているのを気づきませんか)、テクニックはセクション5.0で説明されるようにRealm特有のIPに適切です。
Note also that end-to-end ESP based transport mode authentication and confidentiality are permissible for packets such as ICMP, whose IP payload content is unaffected by the outer IP header translation.
IPペイロード内容が外側のIPヘッダー翻訳で影響を受けないICMPなどのパケットにおいて、超能力が基礎づけたその終わりから端にも交通機関認証と秘密性が許されていることに注意してください。
NAT devices also break fundamental assumptions by public key distribution infrastructures such as Secure DNS RFC 2535 [Ref 18] and X.509 certificates with signed public keys. In the case of Secure
また、NATデバイスはSecure DNS RFC2535などの公開鍵分配インフラストラクチャ[審判18]と署名している公開鍵があるX.509証明書で基本的仮説を破ります。 Secureの場合で
Srisuresh & Holdrege Informational [Page 23] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[23ページ]のRFC2663NAT用語と問題1999年8月
DNS, each DNS RRset is signed with a key from within the zone. Moreover, the authenticity of a specific key is verified by following a chain of trust that goes all the way to the DNS root. When a DNS- ALG modifies addresses (e.g., as in the case of Twice-NAT), verification of signatures fails.
DNS、各DNS RRsetはゾーンからキーで署名されます。 そのうえ、特定のキーの信憑性は、はるばるDNS根まで行く信頼のチェーンに続くことによって、確かめられます。 DNS- ALGがアドレスを変更すると(例えば、Twice-NATに関するケースのように)、署名の検証は失敗します。
It may be of interest to note that IKE (Session key negotiation protocol) is a UDP based session layer protocol and is not protected by network based IPsec security. Only a portion of the individual payloads within IKE are protected. As a result, IKE sessions are permissible across NAT, so long as IKE payload does not contain addresses and/or transport IDs specific to one realm and not the other. Given that IKE is used to setup IPSec associations, and there are at present no known ways of making IPSec work through a NAT function, it is a future work item to take advantage of IKE through a NAT box.
関心では、IKE(セッションの主要な交渉プロトコル)がUDPのベースのセッション層プロトコルであり、ネットワークによって保護されないことに注意するのがIPsecセキュリティを基礎づけたということであるかもしれません。 IKEの中の個々のペイロードの一部だけが保護されます。 その結果、IKEセッションはNATの向こう側に許されています、IKEペイロードがもう片方ではなく、1つの分野に特定のアドレス、そして/または、輸送IDを含んでいない限り。 IKEがIPSec協会をセットアップするのに使用されて、IPSecにNAT機能を終えさせる方法が現在のところ知られていないなら、NAT箱を通してIKEを利用するのは、将来の仕事項目です。
One of the most popular internet applications "FTP" would not work with the definition of NAT as described. The following sub-section is devoted to describing how FTP is supported on NAT devices. FTP ALG is an integral part of most NAT implementations. Some vendors may choose to include additional ALGs to custom support other applications on the NAT device.
最もポピュラーなインターネットアプリケーション「FTP」の1つは説明されるようにNATの定義で働いていないでしょう。 以下の小区分はFTPがNATデバイスでどうサポートされるかを説明するのにささげられます。 FTP ALGはほとんどのNAT実装の不可欠の部分です。 ベンダーの中にはNATデバイスにおけるカスタムサポート他のアプリケーションに追加ALGsを含めるのを選ぶものもあるかもしれません。
7.1. FTP support
7.1. FTPサポート
"PORT" command and "PASV" response in FTP control session payload identify the IP address and TCP port that must be used for the data session it supports. The arguments to the PORT command and PASV response are an IP address and a TCP port in ASCII. An FTP ALG is required to monitor and update the FTP control session payload so that information contained in the payload is relevant to end nodes. The ALG must also update NAT with appropriate data session tuples and session orientation so that NAT could set up state information for the FTP data sessions.
FTPコントロールセッションペイロードにおける"PORT"コマンドと"PASV"応答はそれがサポートするデータセッションに使用しなければならないIPアドレスとTCPポートを特定します。 PORTコマンドとPASV応答への議論は、IPアドレスとASCIIでTCPポートです。 FTP ALGがFTPコントロールセッションペイロードをモニターして、アップデートするのに必要であるので、ペイロードに含まれた情報はノードを終わらせるために関連しています。 また、ALGは、NATがFTPデータセッションのための州の情報をセットアップできるように、適切なデータセッションtuplesとセッションオリエンテーションでNATをアップデートしなければなりません。
Because the address and TCP port are encoded in ASCII, this may result in a change in the size of packet. For instance, 10,18,177,42,64,87 is 18 ASCII characters, whereas 193,45,228,137,64,87 is 20 ASCII characters. If the new size is same as the previous, only the TCP checksum needs adjustment as a result of change of data. If the new size is less than or greater than the previous, TCP sequence numbers must also be changed to reflect the change in length of FTP control data portion. A special table may be used by the ALG to correct the TCP sequence and acknowledge numbers. The sequence number and acknowledgement correction will need to be performed on all future packet of the connection.
アドレスとTCPポートがASCIIでコード化されるので、これはパケットのサイズにおける変化をもたらすかもしれません。 例えば、193、4522万8137、64、87は20人のASCII文字ですが、10、1万8177、42、64、87は18人のASCII文字です。 新しいサイズが前と同じであるなら、TCPチェックサムだけがデータの変化の結果、調整を必要とします。 また、新しいサイズが前であるよりさらに少ないか、または大きいなら、FTPコントロールデータ部の長さにおける変化を反映するためにTCP一連番号を変えなければなりません。 特別なテーブルは、TCP系列を修正して、数を承認するのにALGによって使用されるかもしれません。 一連番号と承認修正は、接続のすべての将来のパケットに実行される必要があるでしょう。
Srisuresh & Holdrege Informational [Page 24] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[24ページ]のRFC2663NAT用語と問題1999年8月
8.0. NAT limitations
8.0. NAT制限
8.1. Applications with IP-address Content
8.1. IP-アドレス内容とのアプリケーション
Not All applications lend themselves easily to address translation by NAT devices. Especially, the applications that carry IP address (and TU port, in case of NAPT) inside the payload. Application Level Gateways, or ALGs must be used to perform translations on packets pertaining to such applications. ALGs may optionally utilize address (and TU port) assignments made by NAT and perform translations specific to the application. The combination of NAT functionality and ALGs will not provide end-to-end security assured by IPsec. However, tunnel mode IPsec can be accomplished with NAT router serving as tunnel end point.
どんなAllアプリケーションもNATデバイスで容易に自分たちをアドレス変換に与えません。 特にIPアドレス(そして、NAPTの場合のTUポート)をペイロードに載せるアプリケーション。 アプリケーションLevel Gateways、またはALGsは使用しなければなりません。使用されて、そのようなアプリケーションに関しながら、パケットに翻訳を実行してください。 ALGsは任意にNATによってされたアドレス(そして、TUポート)課題を利用して、アプリケーションに特定の翻訳を実行するかもしれません。 NATの機能性とALGsの組み合わせは終わりから終わりへのIPsecによって保証されたセキュリティを提供しないでしょう。 しかしながら、トンネルエンドポイントとしてNATルータ給仕でトンネルモードIPsecを達成できます。
SNMP is one such application with address content in payload. NAT routers would not translate IP addresses within SNMP payloads. It is not uncommon for an SNMP specific ALG to reside on a NAT router to perform SNMP MIB translations proprietary to the private network.
SNMPはアドレス内容がペイロードにあるそのようなアプリケーションの1つです。 NATルータはSNMPペイロードの中にIPアドレスを翻訳しないでしょう。 SNMPの特定のALGが私設のネットワークに独占であるSNMP MIB翻訳を実行するためにNATルータに住んでいるのは、珍しくはありません。
8.2. Applications with inter-dependent control and data sessions
8.2. 互いに依存しているコントロールとデータセッションによるアプリケーション
NAT devices operate on the assumption that each session is independent. Session characteristics like session orientation, source and destination IP addresses, session protocol, and source and destination transport level identifiers are determined independently at the start of each new session.
NATデバイスはそれぞれのセッションが独立しているという前提を作動させます。 セッションオリエンテーション、ソース、送付先IPアドレス、セッションプロトコル、およびソースと目的地輸送レベル識別子のようなセッションの特性はそれぞれの新しいセッションの始めで独自に決定しています。
However, there are applications such as H.323 that use one or more control sessions to set the characteristics of the follow-on sessions in their control session payload. Such applications require use of application specific ALGs that can interpret and translate the payload, if necessary. Payload interpretation would help NAT be prepared for the follow-on data sessions.
しかしながら、それらのコントロールセッションペイロードにおける、フォローオンセッションの特性を設定するのに1つ以上のコントロールセッションを使用するH.323などの利用があります。 そのようなアプリケーションは必要なら、ペイロードを解釈して、翻訳できるアプリケーションの特定のALGsの使用を必要とします。 有効搭載量解釈は、NATがフォローオンデータセッションのために準備されるのを助けるでしょう。
8.3. Debugging Considerations
8.3. デバッグ問題
NAT increases the probability of mis-addressing. For example, same local address may be bound to different global address at different times and vice versa. As a result, any traffic flow study based purely on global addresses and TU ports could be confused and might misinterpret the results.
NATは誤アドレシングの確率を増強します。 例えば、同じローカルアドレスはいろいろな時間に逆もまた同様に異なったグローバルアドレスに縛られるかもしれません。 その結果、純粋にグローバルなアドレスとTUポートに基づくどんな交通の流れ研究も、混乱できて、結果を誤解するかもしれません。
If a host is abusing the Internet in some way (such as trying to attack another machine or even sending large amounts of junk mail or something) it is more difficult to pinpoint the source of the trouble because the IP address of the host is hidden in a NAT router.
ホストが何らかの方法(別のマシンを攻撃しようとするか、または多量のダイレクトメールか何かを送りさえすることなどの)でインターネットを乱用しているなら、ホストのIPアドレスがNATルータに隠されるので、問題の発生原因を正確に指摘するのは、より難しいです。
Srisuresh & Holdrege Informational [Page 25] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[25ページ]のRFC2663NAT用語と問題1999年8月
8.4. Translation of fragmented FTP control packets
8.4. 断片化しているFTPコントロールパケットに関する翻訳
Translation of fragmented FTP control packets is tricky when the packets contain "PORT" command or response to "PASV" command. Clearly, this is a pathological case. NAT router would need to assemble the fragments together first and then translate prior to forwarding.
パケットが「移植」コマンドか"PASV"コマンドへの応答を含むとき、断片化しているFTPコントロールパケットの翻訳は扱いにくいです。 明確に、これは病理学的なそうです。 NATルータは、最初に、断片を一緒に組み立てて、次に、推進の前に翻訳する必要があるでしょう。
Yet another case would be when each character of packets containing "PORT" command or response to "PASV" is sent in a separate datagram, unfragmented. In this case, NAT would simply have to let the packets through, without translating the TCP payload. Of course, the application will fail if the payload needed to be altered. The application could still work in a few cases, where the payload contents can be valid in both realms, without modifications enroute. For example, FTP originated from a private host would still work while traversing a traditional NAT or bi-directional NAT device, so long as the FTP control session employed PASV command to establish data sessions. The reason being that the address and port number specified by FTP server in the PASV response (sent as multiple unfragmented packets) is valid to the private host, as is. The NAT device will simply view the ensuing data session (also originating from private host) as an independent TCP session.
さらに別のケースは「移植」コマンドを含むパケットの各キャラクタか"PASV"への応答が別々のデータグラムで送られて、非断片化されている時でしょう。 この場合、TCPペイロードを翻訳しないで、NATは単にパケットを通さなければならないでしょう。 もちろん、ペイロードが、変更される必要があったなら、アプリケーションは失敗するでしょう。 アプリケーションはいくつかの場合でまだ動作できました、途中変更なしで。(そこでは、ペイロードコンテンツが両方の分野で有効である場合があります)。 例えば、個人的なホストから溯源されたFTPは伝統的なNATか双方向のNATデバイスを横断している間、まだ働いているでしょう、FTPコントロールセッションがデータセッションを確立するPASVコマンドを使った限り。 個人的なホストにとって、アドレスとポートナンバーがPASV応答(倍数がパケットを非断片化したとき、発信する)におけるFTPサーバで指定したということである理由は有効です、そのままです。 NATデバイスは独立しているTCPセッションとして単に、続いているデータセッション(また、個人的なホストから、発する)を見なすでしょう。
8.5. Compute intensive
8.5. 徹底的に、計算してください。
NAT is compute intensive even with the help of a clever checksum adjustment algorithm, as each data packet is subject to NAT lookup and modifications. As a result, router forwarding throughput could be slowed considerably. However, so long as the processing capacity of the NAT device exceeds line processing rate, this should not be a problem.
NATは賢明なチェックサム調整アルゴリズムの助けがあっても徹底的に計算することです、それぞれのデータ・パケットがNATルックアップと変更を受けることがあるとき。 その結果、ルータ推進スループットをかなり遅くすることができました。 しかしながら、NATデバイスの処理容量が系列プロセスレートを超えている限り、これは問題であるべきではありません。
9.0. Security Considerations
9.0. セキュリティ問題
Many people view traditional NAT router as a one-way (session) traffic filter, restricting sessions from external hosts into their machines. In addition, when address assignment in NAT router is done dynamically, that makes it harder for an attacker to point to any specific host in the NAT domain. NAT routers may be used in conjunction with firewalls to filter unwanted traffic.
外部のホストからのセッションを彼らのマシンに制限して、多くの人々が一方向(セッション)トラフィックフィルタであると伝統的なNATルータをみなします。 さらに、NATルータにおけるアドレス課題がダイナミックに完了していると、それで、攻撃者がNATドメインでどんな特定のホストも指さすのが、より困難になります。 NATルータは、求められていないトラフィックをフィルターにかけるのにファイアウォールに関連して使用されるかもしれません。
If NAT devices and ALGs are not in a trusted boundary, that is a major security problem, as ALGs could snoop end user traffic payload. Session level payload could be encrypted end to end, so long as the payload does not contain IP addresses and/or transport identifiers that are valid in only one of the realms. With the exception of RSIP, end-to-end IP network level security assured by current IPsec
信じられた境界の中にNATデバイスとALGsがないなら、それは主要な警備上の問題です、ALGsがエンドユーザトラフィックペイロードについて詮索できたとき。 セッションレベルペイロードは終わらせる暗号化された終わりであるかもしれません、ペイロードが分野の1だけで有効なIPアドレス、そして/または、輸送識別子を含んでいない限り。RSIPを除いて、終わりから終わりへのIPネットワークレベルセキュリティは現在のIPsecによって保証されました。
Srisuresh & Holdrege Informational [Page 26] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[26ページ]のRFC2663NAT用語と問題1999年8月
techniques is not attainable with NAT devices in between. One of the ends must be a NAT box. Refer section 7.0 for a discussion on why end-to-end IPsec security cannot be assured with NAT devices along the route.
NATデバイスが中間である状態で、テクニックは達成できません。 終わりの1つはNAT箱であるに違いありません。 ルートに沿ってNATデバイスで終わりから終わりへのIPsecセキュリティを保証できない理由についての議論についてセクション7.0を参照してください。
The combination of NAT functionality, ALGs and firewalls will provide a transparent working environment for a private networking domain. With the exception of RSIP, end-to-end network security assured by IPsec cannot be attained for end-hosts within the private network (Refer section 5.0 for RSIP operation). In all other cases, if you want to use end-to-end IPsec, there cannot be a NAT device in the path. If we make the assumption that NAT devices are part of a trusted boundary, tunnel mode IPsec can be accomplished with NAT router (or a combination of NAT, ALGs and firewall) serving as tunnel end point.
NATの機能性、ALGs、およびファイアウォールの組み合わせは個人的なネットワークドメインに透明な作業環境を提供するでしょう。 RSIP以外に、終わりから終わりへのネットワークIPsecによって保証されたセキュリティに終わりホストのために私設のネットワークの中で達することができません(RSIP操作についてセクション5.0を参照してください)。 他のすべての場合には、あなたが終わりから終わりへのIPsecを使用したいと思うなら、NATデバイスが経路にあるはずがありません。 私たちがNATデバイスが信じられた境界の一部であるという仮定をするなら、トンネルエンドポイントとしてNATルータ(または、NAT、ALGs、およびファイアウォールの組み合わせ)給仕でトンネルモードIPsecを達成できます。
NAT devices, when combined with ALGs, can ensure that the datagrams injected into Internet have no private addresses in headers or payload. Applications that do not meet these requirements may be dropped using firewall filters. For this reason, it is not uncommon to find NAT, ALG and firewall functions co-exist to provide security at the borders of a private network. NAT gateways can be used as tunnel end points to provide secure VPN transport of packet data across an external network domain.
ALGsに結合されると、NATデバイスは、インターネットに注がれたデータグラムがヘッダーかペイロードのプライベート・アドレスを全く持っていないのを確実にすることができます。 これらの必要条件を満たさないアプリケーションは、ファイアウォールフィルタを使用することで下げられるかもしれません。 この理由で、NAT、ALG、およびファイアウォール機能が私設のネットワークの境界でセキュリティを提供するために共存するのがわかるのは珍しくはありません。 提供するトンネルエンドポイントが、外部のネットワークドメインの向こう側にVPNがパケットデータの輸送であると機密保護するとき、NATゲートウェイを使用できます。
Below are some additional security considerations associated with NAT routers.
以下に、NATルータに関連しているいくつかの追加担保問題があります。
1. UDP sessions are inherently unsafe. Responses to a datagram
could come from an address different from the target address
used by sender ([Ref 4]). As a result, an incoming UDP packet
might match the outbound session of a traditional NAT router
only in part (the destination address and UDP port number of
the packet match, but the source address and port number may
not). In such a case, there is a potential security compromise
for the NAT device in permitting inbound packets with partial
match. This UDP security issue is also inherent to firewalls.
1. UDPセッションは本来危険です。 データグラムへの応答は送付者([審判4])によって使用されたあて先アドレスと異なったアドレスから来ることができました。 その結果、入って来るUDPパケットは一部だけ伝統的なNATルータの外国行きのセッションに合うかもしれません(パケットの送付先アドレスとUDPポートナンバーは合っていますが、ソースアドレスとポートナンバーは合うかもしれないというわけではありません)。 このような場合には、部分的なマッチで本国行きのパケットを可能にするのにおいてNATデバイスのための潜在的セキュリティ感染があります。 また、このUDP安全保障問題もファイアウォールに固有です。
Traditional NAT implementations that do not track datagrams on
a per-session basis but lump states of multiple UDP sessions
using the same address binding into a single unified session
could compromise the security even further. This is because,
the granularity of packet matching would be further limited to
just the destination address of the inbound UDP packets.
1セッションあたり1個のベースのデータグラムではなく、ただ一つの統一されたセッションまで同じアドレス結合を使用する複数のUDPセッションの塊の州を追跡する伝統的なNAT実装はさらにさえセキュリティに感染するかもしれません。 これがそう、パケットマッチングの粒状はさらにまさしく本国行きのUDPパケットの送付先アドレスに制限されるでしょう。
2. Multicast sessions (UDP based) are another source for security
weakness for traditional-NAT routers. Once again, firewalls face
the same security dilemma as the NAT routers.
2. マルチキャストセッション(基づくUDP)は伝統的なNATルータのためのセキュリティ弱点のための別のソースです。 もう一度、ファイアウォールはNATルータと同じセキュリティジレンマに直面しています。
Srisuresh & Holdrege Informational [Page 27] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[27ページ]のRFC2663NAT用語と問題1999年8月
Say, a host on private network initiated a multicast session.
Datagram sent by the private host could trigger responses in the
reverse direction from multiple external hosts. Traditional-NAT
implementations that use a single state to track a multicast
session cannot determine for certain if the incoming UDP packet
is in response to an existing multicast session or the start of
new UDP session initiated by an attacker.
私設のネットワークのホストがマルチキャストセッションを開始したと言ってください。 個人的なホストによって送られたデータグラムは複数の外部のホストから反対の方向に応答の引き金となるかもしれません。 マルチキャストセッションを追跡するのにただ一つの状態を使用する伝統的なNAT実装は、入って来るUDPパケットが攻撃者によって開始された新しいUDPセッションの既存のマルチキャストセッションか始まりに対応しているかを確かに決定できません。
3. NAT devices can be a target for attacks.
3. NATデバイスは攻撃のための目標であるかもしれません。
Since NAT devices are Internet hosts they can be the target of a
number of different attacks, such as SYN flood and ping flood
attacks. NAT devices should employ the same sort of protection
techniques as Internet-based servers do.
NATデバイスがインターネット・ホストであるので、彼らは多くの異なった攻撃の目標であるかもしれません、SYNフラッドやピング洪水攻撃のように。 NATデバイスはインターネットを利用するサーバとしてのテクニックがする保護の同じ種類を使うはずです。
REFERENCES
参照
[1] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,G. and E.
Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.
[1] Rekhter(Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.、およびE.リア)は「個人的なインターネットのための配分を扱います」、BCP5、RFC1918、1996年2月。
[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October, 1994.
[2] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[3] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC 1122, October 1989.
[3] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[4] Braden, R., "Requirements for Internet Hosts -- Application and
Support", STD 3, RFC 1123, October 1989.
[4] ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[5] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[5] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[6] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD
9, RFC 959, October 1985.
[6] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD9、RFC959、1985年10月。
[7] Postel, J., "Transmission Control Protocol (TCP) Specification",
STD 7, RFC 793, September 1981.
[7] ポステル、J.、「通信制御プロトコル(TCP)仕様」、STD7、RFC793、1981年9月。
[8] Postel, J., "Internet Control Message Protocol Specification"
STD 5, RFC 792, September 1981.
[8] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル仕様」STD5、RFC792、1981年9月。
[9] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768,
August 1980.
[9] ポステル、J.、「ユーザー・データグラム・プロトコル(UDP)」、STD6、RFC768、1980年8月。
[10] Mogul, J. and J. Postel, "Internet Standard Subnetting
Procedure", STD 5, RFC 950, August 1985.
[10] ムガール人とJ.とJ.ポステル、「インターネットの標準のサブネッティング手順」、STD5、RFC950、1985年8月。
Srisuresh & Holdrege Informational [Page 28] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[28ページ]のRFC2663NAT用語と問題1999年8月
[11] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behavior Today", RFC 2101, February 1997.
[11]大工、B.、クロウクロフト、J.、およびY.Rekhter、「IPv4は今日振舞いを扱う」RFC2101、1997年2月。
[12] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[12] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[13] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[13] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[14] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[14] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[15] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[16] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[16] パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[17] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[17] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[18] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[18] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
Authors' Addresses
作者のアドレス
Pyda Srisuresh Lucent Technologies 4464 Willow Road Pleasanton, CA 94588-8519 U.S.A.
4464年のPyda Srisureshルーセントテクノロジーズ柳のRoadプレザントン、カリフォルニア94588-8519米国
Phone: (925) 737-2153 Fax: (925) 737-2110 EMail: srisuresh@lucent.com
以下に電話をしてください。 (925) 737-2153 Fax: (925) 737-2110 メールしてください: srisuresh@lucent.com
Matt Holdrege Lucent Technologies 1701 Harbor Bay Parkway Alameda, CA 94502
Parkwayアラメダ、マットHoldregeルーセントテクノロジーズ1701港Bayカリフォルニア 94502
Phone: (510) 769-6001 EMail: holdrege@lucent.com
以下に電話をしてください。 (510) 769-6001 メールしてください: holdrege@lucent.com
Srisuresh & Holdrege Informational [Page 29] RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh&Holdregeの情報[29ページ]のRFC2663NAT用語と問題1999年8月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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機能のための基金は現在、インターネット協会によって提供されます。
Srisuresh & Holdrege Informational [Page 30]
Srisuresh&Holdrege情報です。[30ページ]
一覧
スポンサーリンク
