[要約] 要約： RFC 2663は、IPネットワークアドレス変換（NAT）の用語と考慮事項について説明しています。NATの目的は、プライベートIPアドレスをパブリックIPアドレスに変換することで、インターネット接続を改善することです。目的： - NATの用語と概念を明確に定義する。 - NATの実装と運用に関連する考慮事項を提供する。 - プライベートネットワークとパブリックネットワークの接続を改善する。
Network Working Group P. Srisuresh
Request for Comments: 2663 M. Holdrege
Category: Informational Lucent Technologies
August 1999
IP Network Address Translator (NAT) Terminology and Considerations
IPネットワークアドレス変換（NAT）の用語と考慮事項
Status of this 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）The Internet Society（1999）。全著作権所有。
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.
このドキュメントの背後にある動機は、ネットワークアドレストランスレータと組み合わせて使用される用語を明確にすることです。 「ネットワークアドレストランスレータ」という用語は、さまざまなコンテキストでさまざまなことを意味します。このドキュメントの目的は、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メンバーのスコットブラドナー、ヴァーンパクソン、トーマスナーテンにも感謝します。
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.
ネットワークアドレス変換は、ホストに透過的なルーティングを提供するために、あるレルムから別のレルムにIPアドレスをマッピングする方法です。従来、NATデバイスは、プライベートな未登録アドレスを持つ隔離されたアドレスレルムを、グローバルに一意の登録アドレスを持つ外部レルムに接続するために使用されていました。このドキュメントでは、NATデバイスの操作と関連する考慮事項を一般的に説明し、NATのさまざまな種類を識別するために使用される用語を定義しようとしています。
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 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機能は、それ自体ではすべてのアプリケーションを透過的にサポートすることはできず、このため、多くの場合、アプリケーションレベルゲートウェイ（ALG）と共存する必要があります。 NATベースのソリューションの導入を検討している人は、まずアプリケーション要件を決定し、環境にアプリケーションの透過性を提供するために必要なNAT拡張（つまり、ALG）を評価する必要があります。
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パケットのエンドポイントアドレスを保持することを目的としたIPsec手法は、実際のほとんどのアプリケーションではNATの途中では機能しません。 AHやESPなどの手法は、IPヘッダー（送信元アドレスと宛先アドレスを含む）の内容を変更から保護します。しかし、NATの基本的な役割は、パケットのIPヘッダーのアドレスを変更することです。
Terms most frequently used in the context of NAT are defined here for reference.
ここでは、NATのコンテキストで最も頻繁に使用される用語を参照用に定義します。
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環境）
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には、透過ルーティングの詳細な説明があります。
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ポート）のタプルによって一意に識別されます。 ICMPクエリセッションは、（ソースIPアドレス、ICMPクエリID、ターゲットIPアドレス）のタプルで識別されます。他のすべてのセッションは、（ソースIPアドレス、ターゲットIPアドレス、IPプロトコル）のタプルによって特徴付けられます。
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節を参照）。
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で定義）であっても、すべてのアプリケーションがレルム間で動作することが保証されているわけではありません。
For the reminder of this document, we will refer TCP/UDP ports associated with an IP address simply as "TU ports".
このドキュメントを思い出させるために、IPアドレスに関連付けられたTCP / UDPポートを単に「TUポート」と呼びます。
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を使用します。接続を開始しようとするクライアントは、通常、1024〜65535の範囲の送信元TUポートを選択します。ただし、この規則は一般的ではなく、常に従うとは限りません。一部のクライアントステーションは、0〜1023の範囲のソースTUポート番号を使用して接続を開始し、1024〜65535の範囲のTUポート番号でリッスンしているサーバーがあります。
A list of assigned TU port services may be found in RFC 1700 [Ref 2].
割り当てられたTUポートサービスのリストは、RFC 1700 [参照2]に記載されています。
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セッションの最初のパケットは、TCPフラグのSYNビットの存在と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で定義）を持つ最初のパケットを想定することです。
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 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.
TCPセッションの終了は、FINがセッションの両方の半分によって確認されたとき、またはTCPフラグフィールドのRSTビットを持つセグメントをいずれか半分が受け取ったときに検出されます。ただし、NATデバイスは、見たパケットが実際に宛先に配信されるかどうか（NATデバイスと宛先の間でドロップされる可能性がある）を知ることができないため、FINまたはSYNはセッションの最後のパケットになります（つまり、再送信される可能性があります）。したがって、セッションは、この検出から4分間後にのみ終了したと見なすことができます。この延長された待機期間の必要性はRFC 793 [参照7]で説明されており、TIME-WAIT期間が2 * MSL（最大セグメントライフタイム）または4分であることを示唆しています。
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.
また、NATデバイスがイベントを認識しなくてもTCP接続が終了する可能性があることに注意してください（たとえば、一方または両方のピアが再起動する場合）。その結果、存在しない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.
セッションを終了するために、多くのヒューリスティックなアプローチが使用されます。たとえば、24時間使用されなかったTCPセッションと、数分間使用されなかった非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.
セッションの終了を処理する別の方法は、エントリにタイムスタンプを付けてできるだけ長く保持し、必要に応じて最長のアイドルセッションをリタイアすることです。
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.
グローバルネットワークまたはパブリックネットワークは、Internet Assigned Numbers Authority（IANA）または同等のアドレスレジストリによって割り当てられた一意のネットワークアドレスを持つアドレスレルムです。このネットワークは、NATの議論では外部ネットワークとも呼ばれます。
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.
プライベートネットワークは、外部ネットワークアドレスに依存しないアドレスレルムです。プライベートネットワークは、ローカルネットワークとも呼ばれます。プライベートレルムと外部レルムのホスト間の透過的なルーティングは、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 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.
RFC 1918 [参照1]には、プライベートネットワークのアドレス空間割り当てに関する推奨事項があります。 Internet Assigned Numbers Authority（IANA）には、IPアドレス空間の3つのブロック、つまり10 / 8、172.16 / 12、および192.168 / 16がプライベートインターネット用に確保されています。 CIDR以前の表記では、最初のブロックは単一のクラスAネットワーク番号に過ぎず、2番目のブロックは16の隣接するクラスBネットワークのセットであり、3番目のブロックは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を有効にする必要があります。
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ポートを含むもの。アプリケーションレベルゲートウェイ（ALG）は、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.
ALGは常にNAT状態情報を利用するとは限りません。アプリケーションのペイロードを収集し、NATに単に状態情報を追加するよう通知するだけの場合もあります。 ALGはプロキシに似ており、ALGとプロキシの両方がクライアントとサーバー間のアプリケーション固有の通信を容易にします。プロキシは、特別なプロトコルを使用してプロキシクライアントと通信し、クライアントデータをサーバーにリレーしたり、その逆を行います。プロキシとは異なり、ALGはアプリケーションクライアントとの通信に特別なプロトコルを使用せず、アプリケーションクライアントへの変更を必要としません。
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.
ネットワークアドレス変換は、IPアドレスを1つのアドレスレルムから別のレルムにマッピングする方法であり、エンドホストへの透過的なルーティングを提供します。さまざまなアプリケーションに適したアドレス変換には多くのバリエーションがあります。ただし、NATデバイスのすべてのフレーバーは、次の特性を共有する必要があります。
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) 透過的なアドレス割り当て。 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
Figure 1: A typical NAT operation scenario
図1：典型的なNAT操作シナリオ
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つのタイプのアドレス割り当てについて説明します。
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がセッションフローでアドレス管理を管理する必要がなくなります。
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実装に固有です。
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ルーターは2つのアドレスレルム間の境界に位置し、IPヘッダー内のアドレスを変換するので、パケットが1つのレルムを出て別のレルムに入るときに、正しくルーティングできます。 NATデバイスは複数のアドレスレルムに接続しているため、ネットワークに関する情報を（ルーティングプロトコルなどを介して）あるアドレスレルムから別のアドレスレルムに不適切に伝播しないように注意する必要があります。
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.
アドレス変換には、次の3つのフェーズがあります。これらのフェーズにより、NATデバイスを通過するセッションの状態の作成、保守、終了が行われます。
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.
新しい各セッションの開始により、セッションに関連するデータグラムの変換を容易にする状態が作成されます。単一のアドレスバインディングに基づいて、同じホストから発信される多数の同時セッションが存在する可能性があります。
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.
データグラムのアドレスまたはトランスポート識別子の変換により、データグラムが送信元アドレスレルムから宛先アドレスレルムに転送され、ネットワークアドレスが適切に更新されます。
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を参照してください。
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エラーメッセージ（リダイレクトメッセージタイプを除く）を変更する必要があります。 NATの変更が必要なICMPエラーメッセージタイプには、Destination-Unreachable、Source-Quench、Time-Exceeded、およびParameter-Problemが含まれます。 NATはリダイレクトメッセージタイプを変更しようとするべきではありません。
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ヘッダーのチェックサムフィールドをそれに応じて変更し、付随するトランスポートヘッダーを変更する必要があります。 ICMPヘッダーチェックサムも、ペイロードのIPおよびトランスポートヘッダーに加えられた変更を反映するように変更する必要があります。さらに、通常のIPヘッダーも変更する必要があります。
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フレーバーを説明するための基本モデルとして使用されます。アドレスAddr-Aを持つHost-Aは、ネットワークN-Priで表されるプライベートレルムにあります。 N-Priは、NATルーターを介して外部ネットワークから分離されています。アドレスAddr-Xを持つHost-Xは、ネットワークN-Extで表される外部レルムにあります。それぞれが1つのレルムに接続された2つのインターフェースを持つNATルーターは、2つのレルム間の透過的なルーティングを提供します。外部レルムへのインターフェースにはAddr-Nxのアドレスが割り当てられ、プライベートレルムへのインターフェースにはAddr-Npのアドレスが割り当てられます。さらに、アドレスAddr-AおよびAddr-NpはN-Priネットワークに対応し、アドレスAddr-XおよびAddr-NxはN-Extネットワークに対応することが理解され得る。
________________
( )
( External ) +--+
( Address Realm )-- |__|
( (N-Ext) ) /____\
(________________) Host-X
| (Addr-X)
|(Addr-Nx)
+--------------+
| |
| NAT router |
| |
+--------------+
|(Addr-Np)
|
----------------
( )
+--+ ( Private )
|__|------( Address Realm )
/____\ ( (N-pri) )
Host-A (________________)
(Addr-A)
Figure 2: A base model to illustrate NAT terms.
図2：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では、セッションは一方向であり、プライベートネットワークから発信されます。これは、双方向のNATとは対照的です。双方向NATは、着信方向と発信方向の両方でセッションを許可します。双方向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.
以下は、従来のNATでサポートされているレルムのプロパティの説明です。外部ネットワーク内のホストのIPアドレスは一意であり、外部ネットワークとプライベートネットワークで有効です。ただし、プライベートネットワーク内のホストのアドレスは、プライベートネットワーク内でのみ一意であり、外部ネットワークでは有効でない場合があります。つまり、NATはプライベートネットワークを外部レルムにアドバタイズしません。ただし、外部レルムのネットワークは、プライベートネットワーク内でアドバタイズされる場合があります。プライベートネットワーク内で使用されるアドレスは、外部アドレスと重複してはなりません。特定のアドレスは、プライベートアドレスまたは外部アドレスである必要があります。両方ではありません。
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.
図2の従来のNATルーターでは、ホストAがホストXへのセッションを開始できますが、その逆はできません。また、N-ExtはN-Pri内からルーティング可能ですが、N-PriはN-Extからルーティングできない場合があります。
Traditional NAT is primarily used by sites using private addresses that wish to allow outbound sessions from their site.
従来のNATは主に、サイトからの発信セッションを許可するプライベートアドレスを使用するサイトで使用されます。
There are two variations to traditional NAT, namely Basic NAT and NAPT (Network Address Port Translation). These are discussed in the following sub-sections.
従来のNATには、基本NATとNAPT（ネットワークアドレスポート変換）の2つのバリエーションがあります。これらについては、次のサブセクションで説明します。
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.
基本NATでは、外部ドメインへのセッションを開始するときに、プライベートドメイン内のホストのアドレスを変換するために、外部アドレスのブロックが確保されます。プライベートネットワークから送信されるパケットの場合、送信元IPアドレスと、IP、TCP、UDP、ICMPヘッダーチェックサムなどの関連フィールドが変換されます。インバウンドパケットの場合、上記の宛先IPアドレスとチェックサムが変換されます。
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.
図2の基本NATルーターは、N-Priを外部アドレスのブロック（たとえば、外部ネットワークN-Extから選択されたAddr-iからAddr-n）に変換するように構成できます。
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は、トランスポート識別子（TCPおよびUDPポート番号、ICMPクエリ識別子など）も変換することにより、変換の概念をさらに一歩拡張します。これにより、複数のプライベートホストのトランスポート識別子を単一の外部アドレスのトランスポート識別子に多重化できます。 NAPTを使用すると、一連のホストが単一の外部アドレスを共有できます。 NAPTを基本NATと組み合わせて、外部アドレスのプールをポート変換と組み合わせて使用できることに注意してください。
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.
プライベートネットワークから送信されるパケットの場合、NAPTは送信元IPアドレス、送信元トランスポート識別子、およびIP、TCP、UDP、ICMPヘッダーチェックサムなどの関連フィールドを変換します。トランスポート識別子は、TCP / UDPポートまたはICMPクエリIDのいずれかです。着信パケットの場合、宛先IPアドレス、宛先トランスポートID、およびIPとトランスポートヘッダーのチェックサムが変換されます。
A NAPT router in figure 2 may be configured to translate sessions originated from N-Pri into a single external address, say Addr-i.
図2のNAPTルーターは、N-Priから開始されたセッションを単一の外部アドレス、たとえばAddr-iに変換するように構成できます。
Very often, the external interface address Addr-Nx of NAPT router is used as the address to map N-Pri to.
NAPTルーターの外部インターフェイスアドレスAddr-NxがN-Priをマップするアドレスとして使用されることがよくあります。
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.
双方向NATを使用すると、プライベートネットワークだけでなくパブリックネットワークのホストからセッションを開始できます。プライベートネットワークアドレスは、接続がいずれかの方向で確立されると、静的または動的にグローバルに一意のアドレスにバインドされます。プライベートネットワークと外部ネットワークのホスト間の名前空間（つまり、完全修飾ドメイン名）は、エンドツーエンドで一意であると見なされます。外部レルムのホストは、アドレス解決にDNSを使用してプライベートレルムホストにアクセスします。名前とアドレスのマッピングを容易にするために、DNS-ALGを双方向NATと組み合わせて使用する必要があります。具体的には、DNSパケットがプライベートレルムと外部レルムの間を行き来するときに、DNS-ALGはDNSクエリのプライベートレルムアドレスと応答を外部レルムアドレスバインディングに変換できる必要があります。
The address space requirements outlined for traditional NAT routers are applicable here as well.
従来のNATルーターで説明されているアドレス空間の要件は、ここでも適用されます。
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.
図2の双方向NATルーターにより、Host-AがHost-Xへのセッションを開始し、Host-XがHost-Aへのセッションを開始することができます。従来のNATと同様に、N-ExtはN-Pri内からルーティングできますが、N-PriはN-Extからルーティングできない場合があります。
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は、データグラムがアドレスレルムを通過するときに送信元アドレスと宛先アドレスの両方がNATによって変更されるという点で、NATのバリエーションです。これは、1つのアドレス（送信元または宛先）のみが変換される従来のNATおよび双方向NATとは対照的です。 「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 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が必要です。これが発生する最も一般的なケースは、サイトが別の組織に割り当てられているパブリックアドレスを使用して内部ノードに（不適切に）番号を付けた場合です。あるいは、あるプロバイダーから別のプロバイダーに変更されたサイトが、最初のプロバイダーによって割り当てられたアドレスを（内部で）保持するように選択されている場合もあります。そのプロバイダーは、後でそれらのアドレスを他の誰かに再割り当てする可能性があります。このような場合の重要な問題は、外部レルムのホストのアドレスに、ローカルサイト内のホストと同じアドレスが割り当てられている可能性があることです。そのアドレスがパケットに現れる場合、NATデバイスを介して外部レルムに転送されるのではなく、内部ノードに転送されます。 Twice-NATは、パケットがレルムを遷移するときに、IPパケットの送信元アドレスと宛先アドレスの両方を変換することにより、これらのレルムをブリッジしようとします。
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は次のように機能します。 Host-AがHost-Xへのセッションを開始したい場合、Host-Xに対してDNSクエリを発行します。 DNS-ALGはDNSクエリをインターセプトし、Host-Aに返された応答でDNS-ALGはHost-Xのアドレスをローカルサイトで適切にルーティング可能なアドレス（Host-XPRIMEなど）に置き換えます。次に、ホストAはHost-XPRIMEとの通信を開始します。パケットがNATデバイスを通過すると、送信元IPアドレスが変換され（従来のNATの場合と同様）、宛先アドレスがHost-Xに変換されます。同様の変換は、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.
次に、Twice-NATでサポートされるレルムのプロパティについて説明します。外部ネットワーク内のホストのネットワークアドレスは、外部ネットワーク内では一意ですが、プライベートネットワーク内ではありません。同様に、プライベートネットワーク内のホストのネットワークアドレスは、プライベートネットワーク内でのみ一意です。つまり、プライベートネットワークとパブリックネットワークでホストを見つけるためにプライベートネットワークで使用されるアドレススペースは、プライベートネットワークとパブリックネットワークでホストを見つけるためにパブリックネットワークで使用されるアドレススペースとは無関係です。 Twice NATは、ローカルネットワークを外部ネットワークに、またはその逆にアドバタイズすることはできません。
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.
図2のTwice NATルーターは、Host-AがHost-Xへのセッションを開始し、Host-XがHost-Aへのセッションを開始することを許可します。ただし、N-Ext（またはN-Extのサブセット）はN-Pri内からルーティングできず、N-Priは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は通常、プライベートネットワークで使用されるアドレススペースがパブリックスペースで使用されるアドレスと重複する場合に使用されます。たとえば、プライベートサイトが、パブリックインターネットの別のサイトに正式に割り当てられている200.200.200.0/24アドレススペースを使用しているとします。プライベートスペースのHost_A（200.200.200.1）は、パブリックスペースのHost_X（200.200.200.100）に接続しようとします。この接続を機能させるために、Host_XのアドレスはHost_Aの別のアドレスにマップされ、その逆も同様です。プライベートサイトの境界にあるTwice NATは、次のように構成できます。
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)
a) Within private network
a) プライベートネットワーク内
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) 2回のNAT変換後
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)
データグラムフローHost_X（パブリック）-> Host_A（プライベート）
a) Within Public network
a) パブリックネットワーク内
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) 2回のNAT変換後、プライベートネットワーク
SA: 200.200.200.1 DA: 172.16.1.100
SA：200.200.200.1 DA：172.16.1.100
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.
NATの使用には制限があります。たとえば、NATルーターはセッションを通じて確立されたセッションの状態情報を維持するため、セッションに関連する要求と応答は同じNATルーター経由でルーティングする必要があります。このため、NATルーターは、スタブドメインに固有の境界ルーター上で運用することをお勧めします。この場合、すべてのIPパケットはドメインから発信されるか、ドメイン宛てです。ただし、このような構成では、NATルーターが単一障害点になります。
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.
NATリンクの1つに障害が発生した場合でも、プライベートネットワークが外部ネットワークとの接続を確実に維持するために、プライベートドメインからの複数の接続を持つプライベートネットワークを同じまたは複数のサービスプロバイダーにマルチホーム化することが望ましい場合があります。同じまたは異なるNATボックス。
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.
たとえば、プライベートネットワークには2つの異なるプロバイダーへのリンクがあり、プライベートホストからのセッションは、宛先に最適なメトリックを持つNATルーターを通過できます。 NATルーターの1つに障害が発生すると、他のルーターがすべての接続のトラフィックをルーティングする可能性があります。
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.
同じNAT構成を共有する複数のNATボックスまたは同じNATボックス上の複数のリンクは、相互にフェイルセーフバックアップを提供できます。このような場合、プライマリNATに障害が発生したときにバックアップNATが透過的にセッションの負荷を引き受けることができるように、バックアップNATデバイスが状態情報を交換する必要があります。構成が静的マップに基づいている場合、NATバックアップはより簡単になります。
"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.
「レルム固有のIP」（RSIP）は、プライベートレルム内のレルム対応ホストの機能を特徴付けるために使用されます。これは、レルム固有のIPアドレスがプライベートまたは外部レルムのホストと通信することを前提としています。
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.
「レルム固有のIPクライアント」（RSIPクライアント）は、プライベートネットワーク内のホストで、外部レルムのホストに接続してエンドツーエンドの通信を行うときに外部レルムのアドレスを採用します。このような設定でいずれかの端のホストによって生成されるパケットは、外部レルムでエンドツーエンドで一意であり、中間プロセスによる変換を必要としないアドレスに基づいています。
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.
「レルム固有のIPサーバー」（RSIPサーバー）は、プライベートレルムと外部レルムの両方に常駐するノードであり、プライベートレルム内の外部レルムパケットのルーティングを容易にすることができます。これらのパケットは、RSIPクライアントから発信されたか、RSIPクライアントに送信された可能性があります。 RSIP-Serverは、外部レルムアドレスをRSIP-Clientに割り当てるノードと同じである場合もあります。
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.
RSIPには、レルム固有のアドレスIP（RSA-IP）とレルム固有のアドレスとポートIP（RSAP-IP）の2つのバリエーションがあります。これらのバリエーションについては、次のサブセクションで説明します。
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.
レルム固有アドレスIP（RSA-IP）クライアントは、外部レルムのホストに接続するときに、外部アドレススペースのIPアドレスを採用します。 RSA-IPクライアントが外部アドレスを引き継ぐと、そのアドレスがRSA-IPクライアントによって解放されるまで、プライベートドメインまたは外部ドメインの他のホストが同じアドレスを引き受けることはできません。
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 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).
以下は、プライベートレルム内のエンドツーエンドのRSA-IPパケットに対して実行される可能性のある代替ルーティングの説明です。 1つの方法は、パケットを宛先にトンネルすることです。外部ヘッダーは、内部ヘッダーで使用されるアドレスに影響を与えることなく、通常どおりNATによって変換できます。別のアプローチは、RSA-IPクライアントと2つのアドレス領域にまたがる境界ルーターの間に双方向トンネルをセットアップすることです。クライアントとの間のパケットはトンネリングされますが、パケットは通常どおり境界ルータとリモート宛先間で転送されます。クライアントから境界ルーターへのトンネルは必要ない場合があることに注意してください。パケットを直接転送できる場合もあります。これは、内部ネットワークが送信元アドレス（この場合は外部アドレス）に基づいてパケットをフィルタリングしていない限り機能します。
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:
例として、上記の図2のHost-Aは、外部レルムからのアドレスAddr-kを想定し、RSA-IP-Clientとして機能して、Addr-kとAddr-X間のエンドツーエンドセッションを許可できます。プライベートレルム内のエンドツーエンドパケットのトラバーサルは、次のように示されます。
First method, using NAT router enroute to translate:
===================================================
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-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-A>,
embedding <End-to-end packet,
with src=Addr-X, Dest=Addr-k>
<--------------------------------------
Second method, using a tunnel within private realm:
==================================================
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>
----------------------------->
<End-to-end packet, with
src=Addr-k, Dest=Addr-X>
------------------------------->
. . .
。 。 。
<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.
追求する他のアプローチがあるかもしれません。
An RSA-IP-Client has the following characteristics. The collective set of operations performed by an RSA-IP-Client may be termed "RSA-IP".
RSA-IP-Clientには次の特性があります。 RSA-IP-Clientによって実行される操作の集合は、「RSA-IP」と呼ばれることがあります。
1. Aware of the realm to which its peer nodes belong.
1. ピアノードが属するレルムを認識している。
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. そのレルム内のホストと通信するときに、外部レルムからのアドレスを想定します。そのようなアドレスは、静的に割り当てられるか、外部レルムからアドレスを割り当てることができるノードから（まだ定義されていないプロトコルを通じて）動的に取得されます。 RSA-IP-Serverは、外部レルムアドレスの割り当てを調整するノードである可能性があります。
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. RSA-IP-Serverに対応できるアプローチを使用して、パケットを外部ホストにルーティングします。すべての場合において、RSA-IP-Clientは、トンネルのエンドポイントとして機能する必要があり、リターンパスで転送およびカプセル化を解除しながらエンドツーエンドのパケットをカプセル化することができます。
"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.
「レルム固有アドレスIPサーバー」（RSA-IPサーバー）は、プライベートレルムと外部レルムの両方に常駐するノードであり、プライベートレルム内のRSA-IPクライアントに固有の外部レルムパケットのルーティングを容易にします。 RSA-IP-Serverは、次の特性を持つと説明できます。
1. May be configured to assign addresses from external realm to RSA-IP-Clients, either statically or dynamically.
1. 外部レルムからRSA-IP-Clientに静的または動的にアドレスを割り当てるように構成できます。
2. Must be a router resident on both the private and external address realms.
2. プライベートアドレス領域と外部アドレス領域の両方に常駐するルーターである必要があります。
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. プライベートレルム内で外部レルムパケットをルーティングするメカニズムを提供できる必要があります。説明した2つのアプローチのうち、最初のアプローチでは、RSA-IP-Serverが外部ヘッダーに透過的なルーティングを提供するNATルーターである必要があります。このアプローチでは、外部ピアがトンネルエンドポイントである必要があります。
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.
2番目のアプローチでは、RSA-IP-Serverは、RSA-IP-Clientsとのトンネルエンドポイントになることができる任意のルーター（NATルーターを含む）にすることができます。これは、RSA-IP-Clientから送信されて外部ホストに転送されるエンドツーエンドパケットをトンネリングしません。リターンパスでは、エンドツーエンドパケットの宛先アドレスに基づいてRSA-IP-Clientトンネルを見つけ、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-Clientは、IPsec技術、つまりトランスポートまたはトンネルモードの認証と、埋め込まれたパケットのAHおよびESPヘッダーを使用した機密性を追求できます。 RSA-IP-ClientとRSA-IP-Serverの間、またはRSA-IP-Clientと外部ホストの間のカプセル化のために、任意のトンネリング技術を適合させることができます。たとえば、IPsecトンネルモードのカプセル化は、埋め込まれたエンドツーエンドパケットのIPsec認証と機密性を保証する有効なタイプのカプセル化です。
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).
レルム固有のアドレスとポートIP（RSAP-IP）は、複数のプライベートホストが単一の外部アドレスを使用し、トランスポートID（つまり、TCP / UDPポート番号とICMPクエリID）を多重化するRSIPのバリエーションです。
"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」は、RSA-IP-Clientと同様に定義できますが、RSAP-IP-Clientが、外部レルムのホストに接続してエンドツーコミュニケーションを終了します。そのため、RSAP-IP-Clientの外部ノードとの通信は、TCP、UDP、およびICMPセッションに制限される場合があります。
"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」は、プライベートレルム内のRSAP-IPクライアントに固有の外部レルムパケットのルーティングを容易にする点で、RSA-IP-Serverに似ています。通常、RSAP-IP-Serverは、RSAP-IP-Clientにトランスポートタプルを割り当てるものでもあります。
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.
外部カプセル化がTCP / UDPベースであり、RSAP-IP-Clientと外部ピア間でアドレス指定されている場合、NAPTルーターの途中はRSAP-IP-Serverとして機能します。このアプローチでは、外部ピアがTCP / UDPベースのトンネルのエンドポイントである必要があります。このアプローチを使用すると、RSAP-IP-Clientsは、IPsec技術、つまり、トランスポートモードまたはトンネルモードの認証と、埋め込みパケットのAHおよびESPヘッダーを使用した機密性を追求できます。ただし、NAPTルーターはAHおよびESPプロトコルにルーティングの透過性を提供できないため、IPsecトンネルモードは有効なカプセル化のタイプではありません。
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.
あるいは、RSAP-IP-ServerがRSAP-IP-Clientから送信されて外部ホストに転送されるパケットをトンネリングしないように、RSAP-IP-ClientとRSAP-IP-Serverの間でパケットをトンネリングすることもできます。戻りパスでは、RSAP-IP-Serverは（宛先アドレス、トランスポート識別子）のタプルに基づいてRSAP-IP-Clientトンネルを見つけ、RSAP-IP-Clientに転送するためにトンネル内に元のパケットをカプセル化します。このアプローチでは、RSAP-IP-ClientとRSAP-IP-Serverの間で採用されているトンネリング技術に制限はありません。ただし、エンドツーエンドパケットにIPsecベースのセキュリティを適用するには制限があります。トランスポートモードベースの認証と整合性を実現できます。ただし、RSAP-IP-Serverはインバウンドパケットの転送先のRSAP-IPトンネルを識別するために宛先トランスポート識別子を検査できる必要があるため、機密性は許可されません。このため、AHおよびESP認証によって保護されたトランスポートモードのTCP、UDP、およびICMPパケットのみが、このアプローチを使用してRSAP-IP-Serverを通過できます。
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.
例として、上記の図2のHost-AがNAPTルーターから（Addr-Nx、TCPポートT-Nx）のタプルを取得し、RSAP-IP-Clientとして機能して、ホストとのエンドツーエンドTCPセッションを開始するとします。 -バツ。プライベートレルム内のエンドツーエンドパケットのトラバーサルは、次のように示されます。最初の方法では、Host-Aからの発信パケットの外側の層が（プライベートアドレスAddr-A、送信元ポートT-Na）をHost-Xと通信する送信元タプルとして使用します。 NAPTルーターエンルートは、このタプルを（Addr-Nx、Port T-Nxa）に変換します。この変換は、埋め込みパケットで使用されるRSAP-IP-Clientタプルパラメータとは無関係です。
First method, using NAPT router enroute to translate:
====================================================
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-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-A,
Dest Port=T-Na>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<-----------------------------------
Second method, using a tunnel within private realm:
==================================================
Host-A NAPT router 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>
----------------------------->
<End-to-end packet, with
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>
<----------------------------------
<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>
<----------------------------------
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.
以下のサブセクションでは、トンネルが（a）アドレス変換と組み合わせて使用される場合と（b）変換なしで使用される場合の2つのシナリオについて説明します。
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).
前のセクションで説明したアドレス変換のすべてのバリエーションは、直接接続されたリンクだけでなく、トンネルや仮想プライベートネットワーク（VPN）にも適用できます。
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を2回使用することが可能です。トンネルの一端または両端にNATデバイスが存在する可能性があります。すべての場合において、VPNを通過するトラフィックは、セキュリティ上の目的で暗号化できます。ここでのセキュリティとは、VPN間のトラフィックのみのセキュリティを指します。エンドツーエンドのセキュリティでは、プライベートネットワーク内のNATデバイスを信頼する必要があります。
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.
バックボーンパーティション化されたスタブは、パーティション化されていないスタブであるかのように動作する必要があります。つまり、すべてのパーティションのルーターは、すべてのパーティションのローカルアドレススペースへのルートを維持する必要があります。もちろん、（パブリック）バックボーンはローカルアドレスへのルートを維持しません。したがって、境界ルータはカプセル化を使用してバックボーンを介して（VPNを使用して）トンネリングする必要があります。これを行うには、各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ヘッダーのカプセル化を解除し、パケットを内部でルーティングします。このプロセスではアドレス変換は行われないことに注意してください。外部ネットワークトンネルバックボーンを介してプライベートネットワークパケットを転送するだけです。
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.
NATデバイスは、変換がIP / TCP / UDP / ICMPヘッダーとICMPエラーメッセージのみに制限されるという点で、アプリケーションを認識しません。ペイロードはアプリケーション固有である傾向があるため、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デバイス（ALGを含めない）は、トランスポートペイロードを検査または変更しません。このため、多くの場合、NATデバイスはアプリケーションに対して透過的です。ただし、NATデバイスが問題を引き起こすことが多い2つの領域があります。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アドレスを使用しない、またはIPアドレスに依存しないアプリケーション層のセキュリティ技術は、NAT（TLS、SSL、sshなど）が存在する場合でも正しく機能します。対照的に、IPSecトランスポートモードやTCP MD5シグネチャオプションRFC 2385 [参照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とESPの両方に、ペイロード全体をカバーする整合性チェックがあります。ペイロードがTCPまたはUDPの場合、TCP / UDPチェックサムは整合性チェックの対象になります。 NATデバイスがアドレスを変更すると、チェックサムは新しいアドレスに対して無効になります。通常、NATはチェックサムも更新しますが、これはAHおよびESPが使用されている場合は無効です。その結果、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.
埋め込まれたパケットの内容が外部IPヘッダー変換の影響を受けない限り、IPsecトンネルモードのESPは許容されます。この手法は従来のNAT展開（つまり、NATが存在することをホストが認識していない）では機能しませんが、セクション5.0で説明されているように、この手法はレルム固有の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.
エンドツーエンドのESPベースのトランスポートモード認証および機密性は、ICMPなどのIPペイロードコンテンツが外部IPヘッダー変換の影響を受けないパケットで許可されていることにも注意してください。
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 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.
また、NATデバイスは、Secure DNS RFC 2535 [参照18]や署名付き公開鍵を使用したX.509証明書などの公開鍵配布インフラストラクチャによる基本的な前提を破っています。セキュア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ペイロードに1つのレルムに固有のアドレスやトランスポートIDが含まれておらず、他のレルムには含まれていない限り、IKEセッションはNAT全体で許可されます。 IKEはIPSecアソシエーションのセットアップに使用され、NAT機能を介してIPSecを機能させる既知の方法は現在ないため、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.
最も一般的なインターネットアプリケーションの1つである「FTP」は、前述のNATの定義では機能しません。次のサブセクションでは、NATデバイスでのFTPのサポート方法について説明します。 FTP ALGは、ほとんどのNAT実装に不可欠な部分です。一部のベンダーは、NATデバイス上の他のアプリケーションをカスタムサポートするために追加のALGを含めることを選択する場合があります。
"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応答の引数は、ASCIIのIPアドレスとTCPポートです。ペイロードに含まれる情報がエンドノードに関連するように、FTPコントロールセッションペイロードを監視および更新するには、FTP ALGが必要です。また、ALGは、NATがFTPデータセッションの状態情報を設定できるように、適切なデータセッションタプルとセッション指向で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でエンコードされているため、パケットのサイズが変化する可能性があります。たとえば、10、18、177、42、64、87は18文字のASCII文字ですが、193、45、228、137、64、87は20文字のASCII文字です。新しいサイズが以前と同じである場合、データの変更の結果として調整が必要なのはTCPチェックサムだけです。新しいサイズが以前のサイズより小さいまたは大きい場合は、FTP制御データ部分の長さの変更を反映するように、TCPシーケンス番号も変更する必要があります。 ALGは、TCPシーケンスを修正して番号を確認するために特別なテーブルを使用できます。シーケンス番号と確認応答の修正は、接続の将来のすべてのパケットで実行する必要があります。
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.
すべてのアプリケーションがNATデバイスによるアドレス変換に簡単に適しているわけではありません。特に、ペイロード内でIPアドレス（およびNAPTの場合はTUポート）を運ぶアプリケーション。このようなアプリケーションに関連するパケットの変換を実行するには、アプリケーションレベルゲートウェイ（ALG）を使用する必要があります。 ALGはオプションで、NATによって行われたアドレス（およびTUポート）割り当てを利用し、アプリケーションに固有の変換を実行できます。 NAT機能とALGの組み合わせでは、IPsecによって保証されるエンドツーエンドのセキュリティは提供されません。ただし、トンネルモードのIPsecは、NATルーターがトンネルエンドポイントとして機能することで実現できます。
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 MIB変換を実行するために、SNMP固有のALGがNATルーターに常駐することは珍しくありません。
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.
ただし、H.323などのアプリケーションでは、1つ以上の制御セッションを使用して、後続のセッションの特性を制御セッションペイロードに設定します。このようなアプリケーションでは、必要に応じて、ペイロードを解釈および変換できるアプリケーション固有のALGを使用する必要があります。ペイロードの解釈は、NATが後続のデータセッションに備えるのに役立ちます。
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ルーター。
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.
フラグメント化されたFTP制御パケットの変換は、パケットに「PORT」コマンドまたは「PASV」コマンドへの応答が含まれている場合は注意が必要です。明らかに、これは病的なケースです。 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.
さらに別のケースは、「PORT」コマンドまたは「PASV」への応答を含むパケットの各文字が、フラグメント化されていない個別のデータグラムで送信される場合です。この場合、NATはTCPペイロードを変換せずに、パケットを通過させるだけで済みます。もちろん、ペイロードを変更する必要がある場合、アプリケーションは失敗します。ペイロードの内容が変更を加えなくても両方のレルムで有効である場合は、アプリケーションがまだ機能する可能性があります。たとえば、FTP制御セッションがPASVコマンドを使用してデータセッションを確立している限り、プライベートホストから発信されたFTPは、従来のNATまたは双方向NATデバイスを通過している間も機能します。その理由は、PASV応答でFTPサーバーによって指定されたアドレスとポート番号（複数のフラグメント化されていないパケットとして送信される）は、そのままプライベートホストに対して有効であるためです。 NATデバイスは、後続のデータセッション（これもプライベートホストから発信されたもの）を独立したTCPセッションとして単に表示します。
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デバイスの処理能力が回線処理速度を超えている限り、これは問題になりません。
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 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デバイスとALGが信頼された境界内にない場合、ALGがエンドユーザーのトラフィックペイロードをスヌーピングする可能性があるため、これは主要なセキュリティ問題です。ペイロードにIPアドレスやレルムの1つでのみ有効なトランスポート識別子が含まれていない限り、セッションレベルのペイロードをエンドツーエンドで暗号化できます。 RSIPを除いて、現在のIPsec技術によって保証されているエンドツーエンドのIPネットワークレベルのセキュリティは、間に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機能、ALG、およびファイアウォールの組み合わせにより、プライベートネットワーキングドメインに透過的な作業環境が提供されます。 RSIPを除き、プライベートネットワーク内のエンドホストでは、IPsecによって保証されるエンドツーエンドのネットワークセキュリティを実現できません（RSIPの動作については、セクション5.0を参照）。それ以外の場合はすべて、エンドツーエンドのIPsecを使用する場合、パスにNATデバイスを含めることはできません。 NATデバイスが信頼された境界の一部であると仮定すると、トンネルモードのIPsecは、NATルーター（またはNAT、ALGとファイアウォールの組み合わせ）をトンネルエンドポイントとして機能させることで実現できます。
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.
NATデバイスは、ALGと組み合わせると、インターネットに挿入されるデータグラムのヘッダーまたはペイロードにプライベートアドレスがないことを確認できます。これらの要件を満たさないアプリケーションは、ファイアウォールフィルターを使用して削除される場合があります。このため、プライベートネットワークの境界でセキュリティを提供するために、NAT、ALG、およびファイアウォール機能が共存することは珍しくありません。 NATゲートウェイをトンネルエンドポイントとして使用して、外部ネットワークドメイン全体でパケットデータの安全なVPNトランスポートを提供できます。
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.
セッションごとにデータグラムを追跡するのではなく、単一の統合セッションへの同じアドレスバインディングを使用する複数の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ルーターのセキュリティの弱点のもう1つの原因です。ここでも、ファイアウォールはNATルーターと同じセキュリティのジレンマに直面しています。
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フラッド攻撃やpingフラッド攻撃など、さまざまな攻撃の標的になる可能性があります。 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.、Moskowitz、B.、Karrenberg、D.、de Groot、G。 E.リア、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October, 1994.
[2] Reynolds、J。およびJ. Postel、「Assigned Numbers」、STD 2、RFC 1700、1994年10月。
[3] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[3] ブレーデン、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[4] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[4] Braden、R。、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[5] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[5] ベイカー、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[6] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[6] Postel、J。およびJ. Reynolds、「File Transfer Protocol（FTP）」、STD 9、RFC 959、1985年10月。
[7] Postel, J., "Transmission Control Protocol (TCP) Specification", STD 7, RFC 793, September 1981.
[7] Postel、J。、「Transmission Control Protocol（TCP）Specification」、STD 7、RFC 793、1981年9月。
[8] Postel, J., "Internet Control Message Protocol Specification" STD 5, RFC 792, September 1981.
[8] Postel、J。、「インターネット制御メッセージプロトコル仕様」STD 5、RFC 792、1981年9月。
[9] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, August 1980.
[9] Postel、J。、「User Datagram Protocol（UDP）」、STD 6、RFC 768、1980年8月。
[10] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985.
[10] Mogul、J。およびJ. Postel、「インターネット標準サブネット化手順」、STD 5、RFC 950、1985年8月。
[11] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behavior Today", RFC 2101, February 1997.
[11] Carpenter、B.、Crowcroft、J。およびY. Rekhter、「IPv4 Address Behavior Today」、RFC 2101、1997年2月。
[12] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[12] ケントS.およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[13] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[13] Kent、S。およびR. Atkinson、「IP Encapsulating Security Payload（ESP）」、RFC 2406、1998年11月。
[14] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[14] ケント、S.、R。アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[15] Harkins、D.およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[16] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[16] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[17] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[17] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[18] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[18] Eastlake、D。、「ドメインネームシステムセキュリティ拡張機能」、RFC 2535、1999年3月。
Authors' Addresses
著者のアドレス
Pyda Srisuresh Lucent Technologies 4464 Willow Road Pleasanton, CA 94588-8519 U.S.A.
Pyda Srisuresh Lucent Technologies 4464 Willow Road Pleasanton、CA 94588-8519 U.S.A.
Phone: (925) 737-2153 Fax: (925) 737-2110 EMail: srisuresh@lucent.com
電話：（925）737-2153ファックス：（925）737-2110メール：srisuresh@lucent.com
Matt Holdrege Lucent Technologies 1701 Harbor Bay Parkway Alameda, CA 94502
Matt Holdrege Lucent Technologies 1701 Harbour Bay Parkway Alameda、CA 94502
Phone: (510) 769-6001 EMail: holdrege@lucent.com
電話：（510）769-6001メール：holdrege@lucent.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、この文書自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。