Network Working Group G. Tsirtsis
Request for Comments: 2766 BT
Category: Standards Track P. Srisuresh
Campio Communications
February 2000
Network Address Translation - Protocol Translation (NAT-PT)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified in [TRANS]. This solution attempts to provide transparent routing, as defined in [NAT-TERM], to end-nodes in V6 realm trying to communicate with end-nodes in V4 realm and vice versa. This is achieved using a combination of Network Address Translation and Protocol Translation. The scheme described does not mandate dual-stacks (i.e., IPv4 as well as V6 protocol support) or special purpose routing requirements (such as requiring tunneling support) on end nodes. This scheme is based on a combination of address translation theme as described in [NAT-TERM] and V6/V4 protocol translation theme as described in [SIIT].
この文書は、すでに[TRANS]で指定されたものに加えて、IPv4の対のIPv6移行メカニズムを指定します。 [NAT-TERM]で定義されるように、この溶液は、V4レルムおよびその逆にエンド・ノードと通信しようとしてV6レルム内のノードを終了し、透明なルーティングを提供しようとします。これは、ネットワークアドレス変換およびプロトコル変換の組み合わせを使用して達成されます。デュアルスタックを強制しない説明の方式（すなわち、IPv4の同様V6プロトコルサポート）またはエンドノードに（例えばトンネリングサポートを必要とするような）特別な目的のルーティング要件。このスキームは[SIIT]に記載されているように[NAT-TERM]とV6 / V4プロトコル変換テーマに記載されるようにアドレス変換テーマの組み合わせに基づいています。
Acknowledgements
謝辞
Special thanks to Pedro Marques for reviewing an earlier version of this memo. Also, many thanks to Alan O'Neill and Martin Tatham, as the mechanism described in this document was initially developed through discussions with them.
このメモの以前のバージョンを検討するためのペドロ・マルケスに感謝します。また、アラン・オニールとMartin Tatham氏に多くのおかげで、このドキュメントで説明するメカニズムとして最初に彼らとの議論を通じて開発されました。
Table of Contents
目次
1. Introduction.................................................. 2
2. Terminology................................................... 3
2.1 Network Address Translation (NAT)......................... 4
2.2 NAT-PT flavors............................................ 4
2.2.1 Traditional-NAT-PT................................... 4
2.2.2 Bi-directional-NAT-PT................................ 5
2.3 Protocol Translation (PT)................................. 5
2.4 Application Level Gateway (ALG)........................... 5
2.5 Requirements.............................................. 5
3. Traditional-NAT-PT operation (V6 to V4)....................... 6
3.1 NAT-PT Outgoing Sessions.................................. 6
3.2 NAPT-PT Outgoing Sessions................................. 7
4. Use of DNS-ALG for Address assignment......................... 8
4.1 V4 Address Assignment for Incoming Connections (V4 to V6). 9
4.2 V4 Address Assignment for Outgoing Connections (V6 to V4). 11
5. Protocol Translation Details.................................. 12
5.1 Translating IPv4 Headers to IPv6 Headers.................. 13
5.2 Translating IPv6 Headers to IPv4 Headers.................. 13
5.3 TCP/UDP/ICMP Checksum Update.............................. 13
6. FTP Application Level Gateway (FTP-ALG) Support............... 14
6.1 Payload modifications for V4 originated FTP sessions...... 15
6.2 Payload modifications for V6 originated FTP sessions...... 16
6.3 Header updates for FTP control packets.................... 16
7. NAT-PT Limitations and Future Work............................ 17
7.1 Topology Limitations...................................... 17
7.2 Protocol Translation Limitations.......................... 17
7.3 Impact of Address Translation............................. 18
7.4 Lack of End-to-End Security............................... 18
7.5 DNS Translation and DNSSEC................................ 18
8. Applicability Statement....................................... 18
9. Security Considerations....................................... 19
10. References................................................... 19
Authors' Addresses............................................... 20
Full Copyright Statement......................................... 21
IPv6 is a new version of the IP protocol designed to modernize IPv4 which was designed in the 1970s. IPv6 has a number of advantages over IPv4 that will allow for future Internet growth and will simplify IP configuration and administration. IPv6 has a larger address space than IPv4, an addressing model that promotes aggressive route aggregation and a powerful autoconfiguration mechanism. In time, it is expected that Internet growth and a need for a plug-and-play solution will result in widespread adoption of IPv6.
IPv6は、1970年代に設計されたのIPv4を近代化するために設計されたIPプロトコルの新バージョンです。 IPv6は、将来のインターネットの成長を可能にするとIPの設定と管理を簡素化しますのIPv4に比べて多くの利点を持っています。 IPv6はIPv4の、積極的なルート集約と強力な自動設定メカニズムを促進取り組むモデルよりも大きなアドレス空間を持ちます。時間では、インターネットの成長とプラグアンドプレイソリューションの必要性は、IPv6の普及につながることが期待されます。
There is expected to be a long transition period during which it will be necessary for IPv4 and IPv6 nodes to coexist and communicate. A strong, flexible set of IPv4-to-IPv6 transition and coexistence mechanisms will be required during this transition period.
IPv4およびIPv6ノードが共存と通信することが必要となり、その間に長い移行期間があることが予想されます。 IPv4からIPv6移行と共存メカニズムの強い、柔軟なセットは、この移行期間中に必要とされるであろう。
The SIIT proposal [SIIT] describes a protocol translation mechanism that allows communication between IPv6-only and IPv4-only nodes via protocol independent translation of IPv4 and IPv6 datagrams, requiring no state information for the session. The SIIT proposal assumes that V6 nodes are assigned a V4 address for communicating with V4 nodes, and does not specify a mechanism for the assignment of these addresses.
SIIT提案[SIIT]はセッションのための状態情報を必要としない、IPv4およびIPv6データグラムのプロトコル依存性翻訳を介してIPv6のみとIPv4専用ノード間の通信を可能にするプロトコル変換機構が記載されています。 SIIT提案はV6ノードがV4ノードと通信するためのV4アドレスが割り当てられていることを前提とし、これらのアドレスの割り当てのための機構を指定していません。
NAT-PT uses a pool of V4 addresses for assignment to V6 nodes on a dynamic basis as sessions are initiated across V4-V6 boundaries. The V4 addresses are assumed to be globally unique. NAT-PT with private V4 addresses is outside the scope of this document and for further study. NAT-PT binds addresses in V6 network with addresses in V4 network and vice versa to provide transparent routing [NAT-TERM] for the datagrams traversing between address realms. This requires no changes to end nodes and IP packet routing is completely transparent [NAT-TERM] to end nodes. It does, however, require NAT-PT to track the sessions it supports and mandates that inbound and outbound datagrams pertaining to a session traverse the same NAT-PT router. You will note that the topology restrictions on NAT-PT are the same with those described for V4 NATs in [NAT-TERM]. Protocol translation details specified in [SIIT] would be used to extend address translation with protocol syntax/semantics translation. A detailed applicability statement for NAT-PT may be found at the end of this document in section 7.
セッションがV4-V6の境界を越えて開始されたとしてNAT-PTは、動的にV6ノードへの割り当てのためのV4アドレスのプールを使用しています。 V4アドレスはグローバルに一意であると仮定されます。プライベートV4アドレスを持つNAT-PTは、この文書の範囲外と今後の検討課題です。 NAT-PTはV4ネットワークとアドレスレルム間横断データグラムの透過的なルーティング[NAT-TERM]を提供するために、その逆のアドレスとV6ネットワーク内のアドレスをバインドします。これは、エンド・ノードへの変更を必要とせず、IPパケットのルーティングは、ノードを終了する完全に透明[NAT-TERM]です。それは、しかし、それがサポートするセッションと、インバウンドとアウトバウンドのデータグラムが同じNAT-PTルータを横断セッションに関係することを義務を追跡するために、NAT-PTを必要としません。あなたは、NAT-PTのトポロジー制限が[NAT-TERM]でV4 NATのために説明したものと同じであることに注意します。 [SIIT]で指定されたプロトコル変換の詳細は、プロトコル構文/セマンティクス翻訳でアドレス変換を拡張するために使用されるだろう。 NAT-PTの詳細な適用性ステートメントは、セクション7で、この文書の最後に見つけることができます。
By combining SIIT protocol translation with the dynamic address translation capabilities of NAT and appropriate ALGs, NAT-PT provides a complete solution that would allow a large number of commonly used applications to interoperate between IPv6-only nodes and IPv4-only
NATの動的アドレス変換機能と適切なのALGでSIITプロトコル変換を組み合わせることによって、NAT-PTは、IPv6専用ノードとIPv4のみの間で相互運用するために一般的に使用される多数のアプリケーションを可能にする完全なソリューションを提供します
A fundamental assumption for NAT-PT is only to be use when no other native IPv6 or IPv6 over IPv4 tunneled means of communication is possible. In other words the aim is to only use translation between IPv6 only nodes and IPv4 only nodes, while translation between IPv6 only nodes and the IPv4 part of a dual stack node should be avoided over other alternatives.
NAT-PTのための基本的な仮定が可能である通信手段をトンネリングする際ない他のネイティブIPv6のIPv4またはIPv6上のみ使用することです。 IPv6のノードだけとデュアルスタックノードのIPv4の部分との間の変換は、他の選択肢の上に避けるべきである一方、他の言葉でその目的は、IPv6のみのノードのみとIPv4のみのノード間の変換を使用することです。
The majority of terms used in this document are borrowed almost as is from [NAT-TERM]. The following lists terms specific to this document.
本書で使用する用語の大部分は、[NAT-TERM]からなるほぼとして借りれます。この文書に固有の次のリストの用語。
The term NAT in this document is very similar to the IPv4 NAT described in [NAT-TERM], but is not identical. IPv4 NAT translates one IPv4 address into another IPv4 address. In this document, NAT refers to translation of an IPv4 address into an IPv6 address and vice versa.
この文書における用語のNATは、IPv4 NATは、[NAT-TERM]で説明するのは非常に類似しているが、同一ではありません。 IPv4のNATは、別のIPv4アドレスに1つのIPv4アドレスを変換します。この文書では、NATは、IPv6アドレスおよびその逆に、IPv4アドレスの変換を指します。
While the V4 NAT [NAT-TERM] provides routing between private V4 and external V4 address realms, NAT in this document provides routing between a V6 address realm and an external V4 address realm.
V4 NAT [NAT-TERM]はプライベートV4と外部V4アドレスレルム間のルーティングを提供するが、この文書に記載されているNATはV6アドレス領域と外部V4アドレスレルム間のルーティングを提供します。
Just as there are various flavors identified with V4 NAT in [NAT-TERM], the following NAT-PT variations may be identified in this document.
[NAT-TERM]でV4 NATで識別様々な味があるのと同様に、以下のNAT-PTの変動は、この文書に識別することができます。
Traditional-NAT-PT would allow hosts within a V6 network to access hosts in the V4 network. In a traditional-NAT-PT, sessions are uni-directional, outbound from the V6 network. This is in contrast with Bi-directional-NAT-PT, which permits sessions in both inbound and outbound directions.
伝統-NAT-PTはV6ネットワーク内のホストがV4ネットワーク内のホストにアクセスできるようになります。伝統的な-NAT-PTでは、セッションは、V6ネットワークからのアウトバウンド単方向です。これは、インバウンドとアウトバウンドの両方向にセッションを許可する双方向-NAT-PT、とは対照的です。
Just as with V4 traditional-NAT, there are two variations to traditional-NAT-PT, namely Basic-NAT-PT and NAPT-PT.
ただ、V4伝統的な-NATと同様に、伝統的な-NAT-PT、すなわち基本-NAT-PTとNAPT-PTの2つのバリエーションがあります。
With Basic-NAT-PT, a block of V4 addresses are set aside for translating addresses of V6 hosts as they originate sessions to the V4 hosts in external domain. For packets outbound from the V6 domain, 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-PTでは、V4アドレスのブロックは、それらが外部ドメインのV4ホストへのセッションを発信ようV6ホストのアドレスを変換するために確保されています。 V6ドメイン、送信元IPアドレスや、IP、TCP、UDP及びICMPヘッダチェックサムのような関連分野からのパケットの送信のために翻訳されます。着信パケットの場合、送信先のIPアドレスと、上記のようにチェックサムが翻訳されています。
NAPT-PT 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 V6 hosts to be multiplexed into the transport identifiers of a single assigned V4 address. NAPT-PT allows a set of V6 hosts to share a single V4 address. Note that NAPT-PT can be combined with Basic-NAT-PT so that a pool of external addresses are used in conjunction with port translation.
NAPT-PTはまた、トランスポート識別子（例えば、TCPおよびUDPポート番号、ICMP問合せ識別子）を変換することによって、さらに一歩翻訳の概念を拡張します。これはV6ホストの数のトランスポート識別子は、単一の割り当てられたV4アドレスのトランスポート識別子に多重化されることを可能にします。 NAPT-PTはV6ホストのセットは、単一のV4アドレスを共有することを可能にします。外部アドレスのプールは、ポート変換と組み合わせて使用されるように、NAPT-PTは基本-NAT-PTと組み合わせることができることに注意してください。
For packets outbound from the V6 network, NAPT-PT 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.
V6ネットワークからのパケットの送信のために、NAPT-PTは、送信元IPアドレス、送信元トランスポート識別子、およびそのようなIP、TCP、UDP及びICMPヘッダチェックサムのような関連分野の翻訳になります。トランスポート識別子は、TCP / UDPポートまたはICMPクエリIDのいずれかになります。着信パケットは、宛先IPアドレス、送信先トランスポート識別子とIPトランスポートヘッダチェックサムのために翻訳されます。
With Bi-directional-NAT-PT, sessions can be initiated from hosts in V4 network as well as the V6 network. V6 network addresses are bound to V4 addresses, statically or dynamically as connections are established in either direction. The name space (i.e., their Fully Qualified Domain Names) between hosts in V4 and V6 networks is assumed to be end-to-end unique. Hosts in V4 realm access V6-realm hosts by using DNS for address resolution. A DNS-ALG [DNS-ALG] must be employed in conjunction with Bi-Directional-NAT-PT to facilitate name to address mapping. Specifically, the DNS-ALG must be capable of translating V6 addresses in DNS Queries and responses into their V4-address bindings, and vice versa, as DNS packets traverse between V6 and V4 realms.
双方向-NAT-PTでは、セッションはV4ネットワーク内のホストだけでなく、V6ネットワークから開始することができます。接続がどちらの方向にも確立されているようV6ネットワークアドレスは、静的または動的、V4アドレスにバインドされています。 V4およびV6ネットワーク内のホスト間で名前空間（すなわち、それらの完全修飾ドメイン名）は、エンドツーエンド一意であると仮定されます。アドレス解決にDNSを使用して、V4レルムアクセスV6・レルムのホストでホスト。 DNS-ALG [DNS-ALG]はマッピングに対処するための名前を容易にするために双方向-NAT-PTと組み合わせて使用されなければなりません。 DNSパケットがV6とV4レルム間横断として具体的には、DNS-ALGは、そのV4アドレスバインディング、およびその逆にDNSクエリおよび応答でV6アドレスを変換することができなければなりません。
PT in this document refers to the translation of an IPv4 packet into a semantically equivalent IPv6 packet and vice versa. Protocol translation details are described in [SIIT].
この文書に記載されているPTは意味的に等価なIPv6パケット、およびその逆にIPv4パケットの翻訳を指します。プロトコル変換の詳細は[SIIT]で説明されています。
Application Level Gateway (ALG) [NAT-TERM] is an application specific agent that allows a V6 node to communicate with a V4 node and vice versa. Some applications carry network addresses in payloads. NAT-PT is application unaware and does not snoop the payload. ALG could work in conjunction with NAT-PT to provide support for many such applications.
アプリケーションレベルゲートウェイ（ALG）[NAT-TERM]はV6ノードがV4ノードとその逆と通信することを可能にするアプリケーション固有のエージェントです。一部のアプリケーションでは、ペイロードにネットワークアドレスを運びます。 NAT-PTは、アプリケーション認識していないとペイロードをスヌープしません。 ALGは、このような多くのアプリケーションのサポートを提供するために、NAT-PTと一緒に仕事ができます。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [KEYWORDS].
彼らは、この文書に表示される[キーワード]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
NAT-PT offers a straight forward solution based on transparent routing [NAT-TERM] and address/protocol translation, allowing a large number of applications in V6 and V4 realms to inter-operate without requiring any changes to these applications.
NAT-PTは、これらのアプリケーションに変更を必要とすることなく相互運用にV6とV4レルムで多数のアプリケーションを可能にする、透明なルーティング[NAT-TERM]とアドレス/プロトコル変換に基づく単純なソリューションを提供します。
In the following paragraphs we describe the operation of traditional-NAT-PT and the way that connections can be initiated from a host in IPv6 domain to a host in IPv4 domain through a traditional-NAT-PT
次の段落では、我々は、伝統的な-NAT-PTとの接続は、伝統的な-NAT-PTによってIPv6ドメインのホストからのIPv4ドメインでホストに開始することができる方法の動作を説明します
[IPv6-B]-+
| +==============+
[IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C]
| +==============+
(pool of v4 addresses)
Figure 1: IPv6 to IPv4 communication Node IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210 Node IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211 Node IPv4-C has an IPv4 address -> 132.146.243.30
図1：IPv4の通信ノードのIPv6-Aは、IPv6アドレスを持つに対するIPv6 - > FEDC：BA98 :: 7654：3210ノードのIPv6-Bは、IPv6アドレスを持っています - > FEDC：BA98 :: 7654：3211ノードのIPv4-Cは、IPv4を有しますアドレス - > 132.146.243.30
NAT-PT has a pool of addresses including the IPv4 subnet 120.130.26/24
NAT-PTは、IPv4サブネット120.130.26 / 24を含むアドレスのプールを有します
The V4 addresses in the address pool could be allocated one-to-one to the V6 addresses of the V6 end nodes in which case one needs as many V4 addresses as V6 end points. In this document we assume that the V6 network has less V4 addresses than V6 end nodes and thus dynamic address allocation is required for at least some of them.
アドレスプール内V4アドレスは、1対1の一方がV6エンドポイントと同数V4アドレスを必要とする場合にはV6エンドノードのV6アドレスに割り当てることができました。この文書では、V6ネットワークがV6エンドノードよりも少ないV4アドレスを持っているため、動的アドレス割り当てはそれらの少なくともいくつかのために必要であることを前提としています。
Say the IPv6 Node A wants to communicate with the IPv4 Node C. Node A creates a packet with:
IPv6のノードAがIPv4ノードCノードAと通信したいとパケットを作成し、言います：
Source Address, SA=FEDC:BA98::7654:3210 and Destination Address, DA = PREFIX::132.146.243.30
ソースアドレス、SA = FEDC：BA98 :: 7654：3210、宛先アドレス、DA = PREFIX :: 132.146.243.30
NOTE: The prefix PREFIX::/96 is advertised in the stub domain by the NAT-PT, and packets addressed to this PREFIX will be routed to the NAT-PT. The pre-configured PREFIX only needs to be routable within the IPv6 stub domain and as such it can be any routable prefix that the network administrator chooses.
注：プレフィックスPREFIX :: / 96はNAT-PTによってスタブドメインで宣伝され、パケットはこのPREFIX宛するNAT-PTにルーティングされます。事前に設定PREFIXは、IPv6のみのスタブドメイン内でルーティング可能である必要があり、そのように、それは、ネットワーク管理者が選択した任意のルーティング可能なプレフィックスすることができます。
The packet is routed via the NAT-PT gateway, where it is translated to IPv4.
パケットは、それがIPv4のに翻訳されるNAT-PTゲートウェイを介してルーティングされます。
If the outgoing packet is not a session initialisation packet, the NAT-PT SHOULD already have stored some state about the related session, including assigned IPv4 address and other parameters for the translation. If this state does not exist, the packet SHOULD be silently discarded.
発信パケットがセッション初期化パケットでない場合は、NAT-PTは、既に割り当てられたIPv4アドレスおよび翻訳のための他のパラメータを含む、関連のセッションについていくつかの状態を保存している必要があります。この状態が存在しない場合、パケットは静かに捨てられるべきです。
If the packet is a session initialisation packet, the NAT-PT locally allocates an address (e.g: 120.130.26.10) from its pool of addresses and the packet is translated to IPv4. The translation parameters are cached for the duration of the session and the IPv6 to IPv4 mapping is retained by NAT-PT.
パケットがセッション初期化パケットである場合には、NAT-PTは、ローカルアドレス（例えば：120.130.26.10）を割り当て、そのアドレスのプールおよびパケットからのIPv4に変換されます。翻訳パラメータは、セッションの間キャッシュされているとIPv6はIPv4へのマッピングは、NAT-PTによって保持されます。
The resulting IPv4 packet has SA=120.130.26.10 and DA=132.146.243.30. Any returning traffic will be recognised as belonging to the same session by NAT-PT. NAT-PT will use the state information to translate the packet, and the resulting addresses will be SA=PREFIX::132.146.243.30, DA=FEDC:BA98::7654:3210. Note that this packet can now be routed inside the IPv6-only stub network as normal.
得られたIPv4パケットをSA = 120.130.26.10及びDA = 132.146.243.30を有しています。どれ帰国トラフィックは、NAT-PTによって同じセッションに属するものとして認識されます。 NAT-PTはパケットを変換するために、状態情報を使用し、そして得られたアドレスは、SA = PREFIXになります:: 132.146.243.30、DA = FEDC：BA98 :: 7654：3210。このパケットは、現在、通常のようにIPv6のみのスタブネットワーク内でルーティングすることができることに注意してください。
NAPT-PT, which stands for "Network Address Port Translation + Protocol Translation", would allow V6 nodes to communicate with the V4 nodes transparently using a single V4 address. The TCP/UDP ports of the V6 nodes are translated into TCP/UDP ports of the registered V4 address.
「ネットワークポート変換+プロトコル変換アドレス」の略でNAPT-PTは、V6ノードは透過的に、単一のV4アドレスを使用してV4ノードと通信することができるようになります。 V6・ノードのTCP / UDPポートが登録されたV4アドレスのTCP / UDPポートに変換されます。
While NAT-PT support is limited to TCP, UDP and other port multiplexing type of applications, NAPT-PT solves a problem that is inherent with NAT-PT. That is, NAT-PT would fall flat when the pool of V4 addresses assigned for translation purposes is exhausted. Once the address pool is exhausted, newer V6 nodes cannot establish sessions with the outside world anymore. NAPT-PT, on the other hand, will allow for a maximum of 63K TCP and 63K UDP sessions per IPv4 address before having no TCP and UDP ports left to assign.
NAT-PTのサポートはTCP、UDP、およびアプリケーションの他のポート多重型に限られている間、NAPT-PTは、NAT-PTに固有である問題を解決します。翻訳の目的のために割り当てられたV4アドレスのプールが枯渇された場合には、NAT-PTは、フラット下落するだろうさ。アドレスプールが枯渇したら、新しいV6ノードはもう外の世界とのセッションを確立することはできません。 NAPT-PTが、一方、TCPおよびUDPポート割り当てる左を有していない前のIPv4アドレスあたり63K TCPと63K UDPセッションの最大を可能にします。
To modify the example sited in figure 1, we could have NAPT-PT on the border router (instead of NAT-PT) and all V6 addresses could be mapped to a single v4 address 120.130.26.10.
図1に土地を選定例を変更するには、我々は、（代わりにNAT-PTの）境界ルータのNAPT-PTを持つことができ、すべてのV6アドレスが単一v4のアドレス120.130.26.10にマッピングすることができます。
IPv6 Node A would establish a TCP session with the IPv4 Node C as follows:
次のようにIPv6のノードAは、IPv4ノードCとのTCPセッションを確立します：
Node A creates a packet with:
ノードAはでパケットを作成します。
Source Address, SA=FEDC:BA98::7654:3210 , source TCP port = 3017 and Destination Address, DA = PREFIX::132.146.243.30, destination TCP port = 23.
ソースアドレス、SA = FEDC：BA98 :: 7654：3210、ソースTCPポート= 3017と宛先アドレス、DA = PREFIX :: 132.146.243.30、宛先TCPポート= 23。
When the packet reaches the NAPT-PT box, NAPT-PT would assign one of the TCP ports from the assigned V4 address to translate the tuple of (Source Address, Source TCP port) as follows:
パケットがNAPT-PTボックスに到達すると、以下のように、NAPT-PTは、（送信元アドレス、送信元TCPポート）のタプルを変換するために割り当てられたV4アドレスからのTCPポートのいずれかを割り当てます：
SA=120.130.26.10, source TCP port = 1025 and DA=132.146.243.30, destination TCP port = 23.
SA = 120.130.26.10、送信元TCPポート= 1025 DA = 132.146.243.30、宛先TCPポート= 23。
The returning traffic from 132.146.243.30, TCP port 23 will be recognised as belonging to the same session and will be translated back to V6 as follows:
132.146.243.30、TCPポート23からの戻りのトラフィックは、同じセッションに属するものとして認識され、次のようにV6に戻って変換されます。
SA = PREFIX::132.146.243.30, source TCP port = 23; DA = FEDC:BA98::7654:3210 , destination TCP port = 3017
SA = PREFIX :: 132.146.243.30、送信元TCPポート= 23; DA = FEDC：BA98 :: 7654：3210、宛先TCPポート= 3017
Inbound NAPT-PT sessions are restricted to one server per service, assigned via static TCP/UDP port mapping. For example, the Node [IPv6-A] in figure 1 may be the only HTTP server (port 80) in the V6 domain. Node [IPv4-C] sends a packet:
インバウンドNAPT-PTセッションは、静的なTCP / UDPポートマッピングを経由して割り当てられ、サービスごとに一つのサーバに制限されています。例えば、図1におけるノード〔のIPv6-A]はV6ドメイン内のみHTTPサーバ（ポート80）であってもよいです。ノード[IPv4の-C]はパケットを送信します。
SA=132.146.243.30, source TCP port = 1025 and DA=120.130.26.10, destination TCP port = 80
SA = 132.146.243.30、送信元TCPポート= 1025 DA = 120.130.26.10、宛先TCPポート= 80
NAPT-PT will translate this packet to:
NAPT-PTはこのパケットを翻訳します。
SA=PREFIX::132.146.243.30, source TCP port = 1025 DA=FEDC:BA98::7654:3210, destination TCP port = 80
SA = PREFIX :: 132.146.243.30、送信元TCPポート= 1025 DA = FEDC：BA98 :: 7654：、宛先TCPポート= 80 3210
In the above example, note that all sessions which reach NAPT-PT with a destination port of 80 will be redirected to the same node [IPv6- A].
上記の例では、80の宛先ポートとNAPT-PTに到達するすべてのセッションが同じノード[IPv6- A]にリダイレクトされることに注意。
An IPv4 address is assigned by NAT-PT to a V6 node when NAT-PT identifies the start of session, inbound or outbound. Identification of the start of a new inbound session is performed differently than for outbound sessions. However, the same V4 address pool is used for assignment to V6 nodes, irrespective of whether a session is initiated outbound from a V6 node or initiated inbound from a V4 node.
NAT-PTは、インバウンドまたはアウトバウンド、セッションの開始を識別する際のIPv4アドレスは、V6ノードにNAT-PTによって割り当てられます。新しいインバウンドセッションの開始の同定は、アウトバウンドのセッションのためとは異なる行われます。しかし、同じV4アドレスプールに関係なく、セッションがV6ノードからの発信を開始したか、V4ノードから着信が開始されているかどうかの、V6ノードへの割り当てのために使用されます。
Policies determining what type of sessions are allowed and in which direction and from/to which nodes is out of the scope of this document.
セッションのタイプを決定するポリシーが許可され、どの方向にされ/からこの文書の範囲外であるノードれます。
IPv4 name to address mappings are held in the DNS with "A" records. IPv6 name to address mappings are at the moment held in the DNS with "AAAA" records. "A6" records have also been defined but at the time of writing they are neither fully standardized nor deployed.
アドレスマッピングへのIPv4名は「A」レコードをDNSに保持されています。アドレスマッピングへのIPv6名は「AAAA」レコードをDNSで開催された時点です。 「A6」レコードも定義されているが、執筆時点で、彼らはどちらも完全には標準化されていませも配備されています。
In any case, the DNS-ALG's principle of operation described in this section is the same with either "AAAA" or "A6" records. The only difference is that a name resolution using "A6" records may require more than one query - reply pairs. The DNS-ALG SHOULD, in that case, track all the replies in the transaction before translating an "A6" record to an "A" record.
いずれにせよ、このセクションで説明する操作のDNS-ALGの原則は「AAAA」または「A6」の記録のいずれかと同じです。回答のペア - 唯一の違いは、「A6」レコードを使用して名前解決が複数のクエリを必要とするかもしれないということです。 DNS-ALGは、その場合には、「A」レコードに「A6」レコードを変換する前に、トランザクション内のすべての応答を追跡する必要があります。
One of the aims of NAT-PT design is to only use translation when there is no other means of communication, such as native IPv6 or some form of tunneling. For the following discussion NAT-PT, in addition to the IPv4 connectivity that it has it may also have a native IPv6 and/or a tunneled IPv6 connection.
そのようなネイティブのIPv6トンネリングや何らかの形のような通信の他の手段で、存在しない場合にNAT-PT設計の目的の一つは、唯一の翻訳を使用することです。それはまた、ネイティブIPv6および/またはトンネリングされたIPv6接続を有することができる持っているIPv4接続に加えて、以下の議論NAT-PTについて。
[DNS]--+
| [DNS]------[DNS]-------[DNS]
[IPv6-B]-+ | |
| +==============+ |
[IPv6-A]-+----[NAT-PT]------| IPv4 network |--[IPv4-C]
| +==============+
(pool of v4 addresses)
Figure 2: IPv4 to IPv6 communication
Node IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210
Node IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
Node IPv4-C has an IPv4 address -> 132.146.243.30
NAT-PT has a pool of addresses including the IPv4 subnet 120.130.26/24
NAT-PTは、IPv4サブネット120.130.26 / 24を含むアドレスのプールを有します
In figure 2 above, when Node C's name resolver sends a name look up request for Node A, the lookup query is directed to the DNS server on the V6 network. Considering that NAT-PT is residing on the border router between V4 and V6 networks, this request datagram would traverse through the NAT-PT router. The DNS-ALG on the NAT-PT device would modify DNS Queries for A records going into the V6 domain as follows: (Note that a TCP/UDP DNS packet is recognised by the fact that its source or destination port number is 53)
ノードCのネームリゾルバは、名前ノードAの要求を調べるを送る時には、上記の図2では、検索クエリはV6ネットワーク上のDNSサーバに向けられています。 NAT-PTがV4とV6ネットワーク間の境界ルータに常駐していることを考慮すると、この要求データグラムは、NAT-PTルータを横断でしょう。 （TCP / UDP DNSパケットの送信元または宛先ポート番号が53であるという事実によって認識されることに注意してください）：DNS-ALG NAT-PTデバイスには、次のようにV6ドメインに入るレコードをDNSクエリを変更します
a) For Node Name to Node Address Query requests: Change the Query type from "A" to "AAAA" or "A6".
a）のノード名のアドレス照会要求をノードへ：「AAAA」または「A6」に「A」からクエリの種類を変更します。
b) For Node address to Node name query requests: Replace the string "IN-ADDR.ARPA" with the string "IP6.INT". Replace the V4 address octets (in reverse order) preceding the string "IN-ADDR.ARPA" with the corresponding V6 address (if there exists a map) octets in reverse order.
B）ノード名のクエリ要求へのノードアドレスの場合：文字列「IP6.INT」と文字列「IN-ADDR.ARPA」を交換してください。 （逆の順序で）V4アドレスオクテット対応V6アドレスを文字列「IN-ADDR.ARPAを」先行逆順に（地図が存在する場合）のオクテットを置き換えます。
In the opposite direction, when a DNS response traverses from the DNS server on the V6 network to the V4 node, the DNS-ALG once again intercepts the DNS packet and would:
DNS応答がV6ネットワーク上のDNSサーバからV4ノードに横断するときに反対方向に、DNS-ALGは再びDNSパケットをインターセプトします：
a) Translate DNS responses for "AAAA" or "A6" records into "A" records, (only translate "A6" records when the name has completely been resolved) b) Replace the V6 address resolved by the V6 DNS with the V4 address internally assigned by the NAT-PT router.
a）は、「A」レコードに「AAAA」または「A6」のレコードのDNS応答を翻訳（名前が完全に解決された場合にのみ、「A6」の記録を翻訳）b）のV4アドレスとV6 DNSによって解決V6アドレスを交換してください内部NAT-PTルータによって割り当てられました。
If a V4 address is not previously assigned to this V6 node, NAT-PT would assign one at this time. As an example say IPv4-C attempts to initialise a session with node IPv6-A by making a name lookup ("A" record) for Node-A . The name query goes to the local DNS and from there it is propagated to the DNS server of the IPv6 network. The DNS-ALG intercepts and translates the "A" query to "AAAA" or "A6" query and then forwards it to the DNS server in the IPv6 network which replies as follows: (The example uses AAAA records for convenience)
V4アドレスが前もってこのV6ノードに割り当てられていない場合、NAT-PTは、この時点では1を割り当てます。一例としてのIPv4-Cは、ノードAの名前ルックアップ（「A」レコード）を行うことで、ノードのIPv6-Aとのセッションを初期化しようと言います。名前クエリがローカルDNSへ行き、そこからは、IPv6ネットワークのDNSサーバーに伝達されます。 DNS-ALGをインターセプトし、次のように応答したIPv6ネットワーク内のDNSサーバーに転送し、次いで「A」のクエリに「AAAA」または「A6」クエリとを変換は：（例では便宜上、AAAAレコードを使用して）
Node-A AAAA FEDC:BA98::7654:3210,
ノードA AAAA FEDC：BA98 :: 7654：3210、
this is returned by the DNS server and gets intercepted and translated by the DNS-ALG to:
これは、DNSサーバーによって返され、にDNS-ALGによって傍受され、翻訳さ：
Node-A A 120.130.26.1
のでーあ あ １２０。１３０。２６。１
The DNS-ALG also holds the mapping between FEDC:BA98::7654:3210 and 120.130.26.1 in NAT-PT. The "A" record is then returned to Node-C. Node-C can now initiate a session as follows:
BA98 :: 7654：3210と120.130.26.1 NAT-PTでDNS-ALGもFEDCとの間のマッピングを保持しています。 「A」レコードが、その後-Cをノードに返されます。次のようにノードCは現在のセッションを開始することができます。
SA=132.146.243.30, source TCP port = 1025 and DA=120.130.26.1, destination TCP port = 80
SA = 132.146.243.30、送信元TCPポート= 1025 DA = 120.130.26.1、宛先TCPポート= 80
the packet will be routed to NAT-PT, which since it already holds a mapping between FEDC:BA98::7654:3210 and 120.130.26.1 can translate the packet to:
パケットは、それがすでにFEDCとの間のマッピングを保持しているため、NAT-PT、にルーティングされます：BA98 :: 7654：3210と120.130.26.1はにパケットを変換することができます。
SA=PREFIX::132.146.243.30, source TCP port = 1025 DA=FEDC:BA98::7654:3210, destination TCP port = 80
SA = PREFIX :: 132.146.243.30、送信元TCPポート= 1025 DA = FEDC：BA98 :: 7654：、宛先TCPポート= 80 3210
the communication can now proceed as normal.
通信は現在、通常のように進行することができます。
The TTL values on all DNS resource records (RRs) passing through NAT-PT SHOULD be set to 0 so that DNS servers/clients do not cache temporarily assigned RRs. Note, however, that due to some buggy DNS client implementations a value of 1 might in some cases work better. The TTL values should be left unchanged for statically mapped addresses.
NAT-PTを通過するすべてのDNSリソースレコード（RR）のTTL値はようにDNSサーバ/クライアントは一時的に割り当てられたRRをキャッシュしません0に設定する必要があります。ただし、何らかのバグのDNSクライアントの実装にいくつかのケースでは1つのかもしれないの価値がよりよく機能すること。 TTL値は、静的にマップされたアドレスのためにそのまま残しておく必要があります。
Address mappings for incoming sessions, as described above, are subject to denial of service attacks since one can make multiple queries for nodes residing in the V6 network causing the DNS-ALG to map all V4 addresses in NAT-PT and thus block legitimate incoming sessions. Thus, address mappings for incoming sessions should time out to minimise the effect of denial of service attacks. Additionally, one IPv4 address (using NAPT-PT, see 3.2) could be reserved for outgoing sessions only to minimise the effect of such attacks to outgoing sessions.
上述したように、1つはNAT-PTにおいて全てV4アドレスをマッピングし、こうして正規着信セッションをブロックするためにDNS-ALGを引き起こすV6ネットワークに存在するノードのための複数のクエリを作ることができるので、着信セッションのアドレスマッピングは、サービス拒否攻撃の対象となっています。このように、着信セッションのためのアドレスマッピングは、サービス妨害攻撃の影響を最小限に抑えるためにタイムアウト必要があります。さらに、1つのIPv4アドレス（NAPT-PTを用いたが、3.2を参照）のみ発信セッションにこのような攻撃の影響を最小限に抑えるために、送信セッションのために予約することができます。
V6 nodes learn the address of V4 nodes from the DNS server in the V4 domain or from the DNS server internal to the V6 network. We recommend that DNS servers internal to V6 domains maintain a mapping of names to IPv6 addresses for internal nodes and possibly cache mappings for some external nodes. In the case where the DNS server in the v6 domain contains the mapping for external V4 nodes, the DNS queries will not cross the V6 domain and that would obviate the need for DNS-ALG intervention. Otherwise, the queries will cross the V6 domain and are subject to DNS-ALG intervention. We recommend external DNS servers in the V4 domain cache name mapping for external nodes (i.e., V4 nodes) only. Zone transfers across IPv4 - IPv6 boundaries are strongly discouraged.
V6ノードがV4ドメイン内またはV6ネットワークへの内部DNSサーバからDNSサーバからV4ノードのアドレスを学習します。私たちは、V6ドメインへの内部DNSサーバーは、内部ノードのIPv6アドレスに名前といくつかの外部ノードのための、おそらくキャッシュマッピングのマッピングを維持することをお勧めします。 V6ドメイン内のDNSサーバが外部のV4ノードのマッピングが含まれている場合は、DNSクエリはV6ドメインを越えないであろうと、それはDNS-ALGの介入の必要性をなくすでしょう。そうしないと、クエリはV6ドメインを横断し、DNS-ALG介入の対象となります。私たちは、外部ノード（すなわち、V4ノード）のためのV4ドメインキャッシュ名マッピングで外部DNSサーバーをお勧めします。 IPv4の間でゾーン転送 - IPv6の境界が強く推奨されています。
In the case of NAPT-PT, a TCP/UDP source port is assigned from the registered V4 address upon detection of each new outbound session.
NAPT-PTの場合、TCP / UDPソースポートが各新しいアウトバウンドセッションの検出時に登録V4アドレスから割り当てられます。
We saw that a V6 node that needs to communicate with a V4 node needs to use a specific prefix (PREFIX::/96) in front of the IPv4 address of the V4 node. The above technique allows the use of this PREFIX without any configuration in the nodes.
我々は、V4のノードと通信する必要があるV6ノードがV4ノードのIPv4アドレスの前に特定のプレフィックス（PREFIX :: / 96）を使用する必要があることを見ました。上記の技術は、ノード内の任意の設定せずにこのプレフィックスの使用を可能にします。
To create another example from Figure 2 say Node-A wants to set up a session with Node-C. For this Node-A starts by making a name look-up ("AAAA" or "A6" record) for Node-C.
図2からの別の例を作成するにはノードAがノードCとのセッションをセットアップしたいと言います。このノードAのノード-Cの名前ルックアップ（「AAAA」または「A6」の記録）を行うことによって開始します。
Since Node-C may have IPv6 and/or IPv4 addresses, the DNS-ALG on the NAT-PT device forwards the original AAAA/A6 query to the external DNS system unchanged, as well as an A query for the same node. If an AAAA/A6 record exists for the destination, this will be returned to
ノードCは、IPv6および/またはIPv4アドレスを持っているかもしれないので、NAT-PTデバイス上のDNS-ALGは、外部DNSシステム変わらずに元のAAAA / A6がクエリ、ならびに同じノードに対するクエリを転送します。 AAAA / A6レコードが先に存在する場合、これはに返されます
NAT-PT which will forward it, also unchanged, to the originating host.
元ホストに、変わらずも、それを転送するNAT-PT。
If there is an A record for Node-C the reply also returns to the NAT-PT. The DNS-ALG then, translates the reply adding the appropriate PREFIX and forwards it to the originating device with any IPv6 addresses that might have learned. So, if the reply is
ノードCのレコードがある場合、応答はまた、NAT-PTに戻ります。 DNS-ALGはその後、適切な接頭辞を追加する返信を変換し、学んできたかもしれない任意のIPv6アドレスと送信元デバイスに転送します。だから、返信がある場合
NodeC A 132.146.243.30, it is translated to NodeC AAAA PREFIX::132.146.243.30 or to NodeC A6 PREFIX::132.146.243.30
ノードC A 132.146.243.30、それがノードC AAAA PREFIX :: 132.146.243.30またはノードC A6 PREFIX :: 132.146.243.30に変換されます
Now Node A can use this address like any other IPv6 address and the V6 DNS server can even cache it as long as the PREFIX does not change.
今、ノードAはさえ限りPREFIXが変化しないようにそれをキャッシュすることができ、他のIPv6アドレスとV6のDNSサーバのように、このアドレスを使用することができます。
An issue here is how the V6 DNS server in the V6 stub domain talks to the V4 domain outside the V6 stub domain. Remember that there are no dual stack nodes here. The external V4 DNS server needs to point to a V4 address, part of the V4 pool of addresses, available to NAT-PT. NAT-PT keeps a one-to-one mapping between this V4 address and the V6 address of the internal V6 DNS server. In the other direction, the V6 DNS server points to a V6 address formed by the IPv4 address of the external V4 DNS servers and the prefix (PREFIX::/96) that indicates non IPv6 nodes. This mechanism can easily be extended to accommodate secondary DNS servers.
ここでの問題は、V6のスタブドメイン外のV4ドメインへV6のスタブドメインの会談でどのようにV6のDNSサーバです。何のデュアルスタックノードがここに存在しないことに注意してください。外部のV4のDNSサーバーがV4アドレス、NAT-PTに利用可能なアドレスのV4プールの一部を指している必要があります。 NAT-PTはこのV4アドレスと内部V6のDNSサーバのV6アドレス間の1対1のマッピングを保持します。他の方向では、外部のV4のDNSサーバのIPv4アドレスおよび非IPv6ノードを示す接頭辞（PREFIX :: / 96）により形成されたV6アドレスにV6のDNSサーバポイント。このメカニズムは、簡単にセカンダリDNSサーバに対応するために拡張することができます。
Note that the scheme described in this section impacts DNSSEC. See section 7.5 of this document for details.
スキームは、このセクションの影響のDNSSECで説明していることに注意してください。詳細については、この文書のセクション7.5を参照してください。
The IPv4 and ICMPv4 headers are similar to their V6 counterparts but a number of field are either missing, have different meaning or different length. NAT-PT SHOULD translate all IP/ICMP headers from v4 to v6 and vice versa in order to make end-to-end IPv6 to IPv4 communication possible. Due to the address translation function and possible port multiplexing, NAT-PT SHOULD also make appropriate adjustments to the upper layer protocol (TCP/UDP) headers. A separate section on FTP-ALG describes the changes FTP-ALG would make to FTP payload as an FTP packet traverses from V4 to V6 realm or vice versa.
IPv4およびICMPv4のヘッダは、そのV6の対応に似ていますが、フィールドの数は、いずれかの不足している、別の意味または異なる長さを持っています。 NAT-PTは、可能なIPv4の通信にエンドツーエンドのIPv6を作るためにV4からV6およびその逆に、すべてのIP / ICMPヘッダを変換すべきです。アドレス変換機能と可能なポート多重に、NAT-PTはまた、上位層プロトコル（TCP / UDP）ヘッダーへの適切な調整を行う必要があります。 FTP-ALG上の別のセクションは、FTPパケットはその逆V4からV6レルムに横断又はFTP-ALGは、FTPペイロードになるだろう変更を記述する。
Protocol Translation details are described in [SIIT], but there are some modifications required to SIIT because of the fact that NAT-PT also performs Network Address Translation.
プロトコル変換の詳細は[SIIT]で説明するが、なぜならNAT-PTは、ネットワークアドレス変換を実行するという事実をSIITに必要ないくつかの変更がされています。
This is done exactly the same as in SIIT apart from the following fields:
これは、次のフィールドから離れSIITと全く同様に行われます。
Source Address: The low-order 32 bits is the IPv4 source address. The high-order 96 bits is the designated PREFIX for all v4 communications. Addresses using this PREFIX will be routed to the NAT-PT gateway (PREFIX::/96)
ソースアドレス：下位32ビットは、IPv4ソースアドレスです。上位96ビットが全てV4通信用の指定PREFIXあります。このプレフィクスを使用してアドレスはNAT-PTゲートウェイ（PREFIX :: / 96）にルーティングされます
Destination Address: NAT-PT retains a mapping between the IPv4 destination address and the IPv6 address of the destination node. The IPv4 destination address is replaced by the IPv6 address retained in that mapping.
宛先アドレス：NAT-PTは、IPv4宛先アドレスと宛先ノードのIPv6アドレス間のマッピングを保持します。 IPv4宛先アドレスがそのマッピングに保持IPv6アドレスに置き換えられます。
This is done exactly the same as in SIIT apart from the Source Address which should be determined as follows:
これは別に、以下のように決定されるべきである送信元アドレスからSIITと全く同様に行われます。
Source Address: The NAT-PT retains a mapping between the IPv6 source address and an IPv4 address from the pool of IPv4 addresses available. The IPv6 source address is replaced by the IPv4 address retained in that mapping.
送信元アドレス：NAT-PTは、IPv6送信元アドレスと利用可能なIPv4アドレスのプールからIPv4アドレスの間のマッピングを保持します。 IPv6送信元アドレスがそのマッピングに保持IPv4アドレスに置き換えられます。
Destination Address: IPv6 packets that are translated have a destination address of the form PREFIX::IPv4/96. Thus the low-order 32 bits of the IPv6 destination address is copied to the IPv4 destination address.
宛先アドレス：翻訳されたIPv6パケットは、フォームPREFIXの宛先アドレス:: / 96のIPv4を持っています。したがってIPv6宛先アドレスの下位32ビットがIPv4宛先アドレスにコピーされます。
NAT-PT retains mapping between IPv6 address and an IPv4 address from the pool of IPv4 addresses available. This mapping is used in the translation of packets that go through NAT-PT.
NAT-PTは、IPv6アドレスおよび利用可能なIPv4アドレスのプールからIPv4アドレスの間のマッピングを保持します。このマッピングは、NAT-PTを通過するパケットの翻訳に使用されています。
The following sub-sections describe TCP/UDP/ICMP checksum update procedure in NAT-PT, as packets are translated from V4 to V6 and vice versa.
パケットがV4からV6に及びその逆に翻訳される次のサブセクションでは、NAT-PTにTCP / UDP / ICMPチェックサム更新手順を記述しています。
UDP checksums, when set to a non-zero value, and TCP checksum SHOULD be recalculated to reflect the address change from v4 to v6. The incremental checksum adjustment algorithm may be borrowed from [NAT]. In the case of NAPT-PT, TCP/UDP checksum should be adjusted to account for the address and TCP/UDP port changes, going from V4 to V6 address.
非ゼロ値、およびTCPチェックサムに設定UDPチェックサムは、V6へのV4からアドレスの変更を反映するために再計算する必要があります。増分チェックサム調整アルゴリズムは、[NAT]から借用されてもよいです。 NAPT-PTの場合、TCP / UDPチェックサムがV4からV6アドレスへ行き、アドレスおよびTCP / UDPポートの変更を考慮して調整する必要があります。
When the checksum of a V4 UDP packet is set to zero, NAT-PT MUST evaluate the checksum in its entirety for the V6-translated UDP packet. If a V4 UDP packet with a checksum of zero arrives in fragments, NAT-PT MUST await all the fragments until they can be assembled into a single non-fragmented packet and evaluate the checksum prior to forwarding the translated V6 UDP packet.
V4 UDPパケットのチェックサムがゼロに設定されている場合、NAT-PTはV6翻訳UDPパケットのためにその全体がチェックサムを評価する必要があります。ゼロのチェックサムとV4 UDPパケットが断片的に到着した場合、NAT-PTは、彼らは、単一の非フラグメントパケットに組み立てることができるまで、すべての断片を待つと翻訳されたV6 UDPパケットを転送する前にチェックサムを評価しなければなりません。
ICMPv6, unlike ICMPv4, uses a pseudo-header, just like UDP and TCP during checksum computation. As a result, when the ICMPv6 header checksum is computed [SIIT], the checksum needs to be adjusted to account for the additional pseudo-header. Note, there may also be adjustments required to the checksum due to changes in the source and destination addresses (and changes in TCP/UDP/ICMP identifiers in the case of NAPT-PT) of the payload carried within ICMP.
ICMPv6のは、ICMPv4のとは異なり、単にUDP及びTCPのようなチェックサム計算中に、疑似ヘッダを使用します。 ICMPv6のヘッダチェックサムが[SIIT]計算されたときに結果として、チェックサムは、追加の疑似ヘッダを考慮して調整する必要があります。メモ、またによる送信元と宛先アドレス（およびNAPT-PTの場合のTCP / UDP / ICMP識別子の変化）ICMP内で搬送ペイロードの変化にチェックサムに必要な調整があってもよいです。
TCP and UDP checksums SHOULD be recalculated to reflect the address change from v6 to v4. The incremental checksum adjustment algorithm may be borrowed from [NAT]. In the case of NAPT-PT, TCP/UDP checksums should be adjusted to account for the address and TCP/UDP port changes, going from V6 to V4 addresses. For UDP packets, optionally, the checksum may simply be changed to zero.
TCPとUDPチェックサムは、V4へV6からアドレスの変更を反映するために再計算する必要があります。増分チェックサム調整アルゴリズムは、[NAT]から借用されてもよいです。 NAPT-PTの場合、TCP / UDPチェックサムはV4アドレスにV6から行く、アドレスおよびTCP / UDPポートの変更を考慮して調整する必要があります。 UDPパケットのために、必要に応じて、チェックサムは単にゼロに変更してもよいです。
The checksum calculation for a V4 ICMP header needs to be derived from the V6 ICMP header by running the checksum adjustment algorithm [NAT] to remove the V6 pseudo header from the computation. Note, the adjustment must additionally take into account changes to the checksum as a result of updates to the source and destination addresses (and transport ports in the case of NAPT-PT) made to the payload carried within ICMP.
V4 ICMPヘッダのチェックサム計算は計算からV6擬似ヘッダを除去するために、チェックサム調整アルゴリズム[NAT]を実行して、V6 ICMPヘッダから派生する必要があります。調整はさらに、ICMP内で実施ペイロードになさ（NAPT-PTの場合の搬送ポート）送信元アドレスと宛先アドレスの更新の結果として、チェックサムのアカウントの変更を考慮する必要があり、注意してください。
Because an FTP control session carries, in its payload, the IP address and TCP port information for the data session, an FTP-ALG is required to provide application level transparency for this popular Internet application.
FTP制御セッションを伝送するので、そのペイロードに、データセッションのためのIPアドレスとTCPポート情報は、FTP-ALGは、この一般的なインターネットアプリケーションのためのアプリケーションレベルの透明性を提供するために必要とされます。
In the FTP application running on a legacy V4 node, arguments to the FTP PORT command and arguments in PASV response(successful) include an IP V4 address and a TCP port, both represented in ASCII as h1,h2,h3,h4,p1,p2. However, [FTP-IPV6] suggests EPRT and EPSV command extensions to FTP, with an intent to eventually retire the use of PORT and PASV commands. These extensions may be used on a V4 or V6 node. FTP-ALG, facilitating transparent FTP between V4 and V6 nodes, works as follows.
レガシーV4ノード上で実行されているFTPアプリケーションでは、PASV応答（成功）でFTP PORTコマンドと引数の引数は、IP V4アドレスとTCPポートを備え、H1、H2、H3、H4、P1とASCIIで表現の両方、 P2。ただし、[FTP-IPV6]は、最終的PORTとPASVコマンドの使用を引退する目的で、FTPにEPRTとEPSVコマンド拡張機能を示唆しています。これらの拡張機能は、V4またはV6のノード上で使用することができます。次のようにV4とV6ノード間の透明FTPを促進FTP-ALGは、動作します。
A V4 host may or may not have the EPRT and EPSV command extensions implemented in its FTP application. If a V4 host originates the FTP session and uses PORT or PASV command, the FTP-ALG will translate these commands into EPRT and EPSV commands respectively prior to forwarding to the V6 node. Likewise, EPSV response from V6 nodes will be translated into PASV response prior to forwarding to V4 nodes. The format of EPRT and EPSV commands and EPSV response may be specified as follows[FTP-IPV6].
V4ホストがFTPまたはそのアプリケーションに実装EPRTとEPSVコマンド拡張機能を持っていない可能性があります。 V4ホストがFTPセッションを発信し、PORTまたはPASVコマンドを使用している場合、FTP-ALGはEPRTにこれらのコマンドを変換し、EPSVはそれぞれV6ノードに転送する前のコマンド。同様に、V6ノードからのEPSV応答がV4ノードに転送する前にPASV応答に翻訳されるであろう。 EPRTとEPSVコマンドとEPSV応答の形式は次のように指定することができる[FTP-IPV6]。
EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d> EPSV<space><net-prt> (or) EPSV<space>ALL
EPRT <スペース> <D> <ネット-PRT> <D> <ネット-addrに> <D> <TCPポート> <D> EPSV <スペース> <ネット-PRT>（または）EPSV <スペース> ALL
Format of EPSV response(Positive): 229 <text indicating extended passive mode> (<d><d><d><tcp-port><d>)
EPSV応答のフォーマット（ポジティブ）：229 <拡張パッシブモードを示すテキスト>（<D> <D> <D> <TCPポート> <D>）
PORT command from a V4 node is translated into EPRT command, by setting the protocol <net-prt> field to AF #2 (IPV6) and translating the V4 host Address (represented as h1,h2,h3,h4) into its NAT-PT assigned V6 address in string notation, as defined in [V6ADDR] in the <net-addr> field. TCP port represented by p1,p2 in PORT command must be specified as a decimal <tcp-port> in the EPRT command. Further, <tcp-port> translation may also be required in the case of NAPT-PT. PASV command from a V4 node is be translated into a EPSV command with the <net-prt> argument set to AF #2. EPSV response from a V6 node is translated into PASV response prior to forwarding to the target V4 host.
V4ノードからPORTコマンドは、<ネットPRT>フィールドAFに＃2（IPV6）プロトコルを設定し、そのNAT-に（H1、H2、H3、H4として表される）V4ホストアドレスを変換することによって、EPRTコマンドに変換され<ネット-ADDR>フィールドの[V6ADDR]で定義されるように、PTは、ストリング表記でV6アドレスを割り当て。 TCPポートP1に代表される、PORTコマンドでp2はEPRTコマンドの小数点<TCPポート>として指定する必要があります。さらに、<TCPポート>翻訳もNAPT-PTの場合には必要とされ得ます。 V4ノードからのPASVコマンドは、AF＃2に設定<ネットPRT>引数でEPSVコマンドに翻訳されます。 V6ノードからのEPSV応答が目標V4ホストに転送する前にPASV応答に翻訳されます。
If a V4 host originated the FTP session and was using EPRT and EPSV commands, the FTP-ALG will simply translate the parameters to these commands, without altering the commands themselves. The protocol Number <net-prt> field will be translated from AF #1 to AF #2. <net-addr> will be translated from the V4 address in ASCII to its NAT-PT assigned V6 address in string notation as defined in [V6ADDR]. <tcp-port> argument in EPSV response requires translation only in the case of NAPT-PT.
V4ホストがFTPセッションを開始したとEPRTを使用し、EPSVコマンドをされた場合は、FTP-ALGは、単純にコマンドそのものを変更することなく、これらのコマンドにパラメータを変換します。プロトコル番号<ネットPRT>フィールドはAF＃2にAF＃1から翻訳されるであろう。 【V6ADDR]で定義されるように、<ネット-addrが>ストリング表記でそのNAT-PT割り当てられたV6アドレスにASCIIにおけるV4アドレスから変換されます。 EPSV応答で<TCPポート>引数はNAPT-PTの場合には翻訳が必要です。
If a V6 host originates the FTP session, however, the FTP-ALG has two approaches to pursue. In the first approach, the FTP-ALG will leave the command strings "EPRT" and "EPSV" unaltered and simply translate the <net-prt>, <net-addr> and <tcp-port> arguments from V6 to its NAT-PT (or NAPT-PT) assigned V4 information. <tcp-port> is translated only in the case of NAPT-PT. Same goes for EPSV response from V4 node. This is the approach we recommend to ensure forward support for RFC 2428. However, with this approach, the V4 hosts are mandated to have their FTP application upgraded to support EPRT and EPSV extensions to allow access to V4 and V6 hosts, alike.
V6ホストがFTPセッションを発信する場合は、しかし、FTP-ALGは追求するには、2つのアプローチがあります。最初のアプローチでは、FTP-ALGは、「EPSV」変更されていないコマンド文字列「EPRT」とを離れて、単に<ネット-PRT>、<ネット-addrに>と<TCPポート>引数V6からのNAT-に変換しますPT（又はNAPT-PT）割り当てV4情報。 <TCPポート>は唯一のNAPT-PTの場合に変換されます。同じことがV4ノードからのEPSV応答のために行きます。これは、我々は、このアプローチで、V4ホストが同様に、V4とV6のホストへのアクセスを許可するようにEPRTとEPSV拡張をサポートするようにアップグレード彼らのFTPアプリケーションを持つことが義務付けられている、しかし、RFC 2428のための前方サポートを確実にするためにお勧めのアプローチです。
In the second approach, the FTP-ALG will translate the command strings "EPRT" and "EPSV" and their parameters from the V6 node into their equivalent NAT-PT assigned V4 node info and attach to "PORT" and "PASV" commands prior to forwarding to V4 node. Likewise, PASV response from V4 nodes is translated into EPSV response prior to forwarding to the target V6 nodes. However, the FTP-ALG would be unable to translate the command "EPSV<space>ALL" issued by V6 nodes. In such a case, the V4 host, which receives the command, may return an error code indicating unsupported function. This error response may cause many RFC 2428 compliant FTP applications to simply fail, because EPSV support is mandated by RFC 2428. The benefit of this approach, however, is that is does not impose any FTP upgrade requirements on V4 hosts.
第2のアプローチでは、FTP-ALGは、それらと同等のNAT-PT割り当てられたV4ノード情報に「EPRT」と「EPSV」とV6ノードからそのパラメータをコマンド文字列を翻訳し、「PORT」に接続し、「PASV」は前のコマンドV4ノードに転送します。同様に、V4ノードからのPASV応答がターゲットV6ノードに転送する前EPSV応答に翻訳されます。しかし、FTP-ALGはV6ノードによって発行されたコマンド「EPSV <スペース> ALL」を翻訳することができないであろう。このような場合には、コマンドを受け取るV4ホストは、サポートされない機能を示すエラーコードを返すことができます。 EPSVサポートはRFC 2428で、このアプローチの利点を義務付けられているため、このエラー応答は、単に失敗する多くのRFC 2428に準拠したFTPアプリケーションを引き起こす可能性があり、しかし、それはV4ホスト上の任意のFTPアップグレード要件を課さないです。
All the payload translations considered in the previous sections are based on ASCII encoded data. As a result, these translations may result in a change in the size of packet.
前のセクションで考慮されるすべてのペイロード翻訳はASCIIエンコードされたデータに基づいています。結果として、これらの変換は、パケットのサイズの変化をもたらすことができます。
If the new size is the same as the previous, only the TCP checksum needs adjustment as a result of the payload translation. If the new size is different from the previous, TCP sequence numbers should also be changed to reflect the change in the length of the FTP control session payload. The IP packet length field in the V4 header or the IP payload length field in the V6 header should also be changed to reflect the new payload size. A table is used by the FTP-ALG to correct the TCP sequence and acknowledgement numbers in the TCP header for control packets in both directions.
新しいサイズが前と同じである場合には、唯一のTCPチェックサムは、ペイロードの翻訳の結果としての調整を必要とします。新しいサイズが前の、TCPのシーケンス番号と異なる場合もFTP制御セッションペイロードの長さの変化を反映するように変更する必要があります。 V4ヘッダーまたはV6ヘッダ内のIPペイロード長フィールドにIPパケット長フィールドは、新しいペイロードサイズを反映するように変更されなければなりません。表は、両方向で制御パケットのTCPヘッダ内のTCPシーケンスおよび確認応答番号を修正するために、FTP-ALGによって使用されます。
The table entries should have the source address, source data port, destination address and destination data port for V4 and V6 portions of the session, sequence number delta for outbound control packets and sequence number delta for inbound control packets.
テーブルエントリは、セッションのV4およびV6部分、着信制御パケットの発信制御パケットとシーケンス番号デルタのシーケンス番号デルタのソース・アドレス、ソース・データ・ポート、宛先アドレス及び宛先データポートを有していなければなりません。
The sequence number for an outbound control packet is increased by the outbound sequence number delta, and the acknowledgement number for the same outbound packet is decreased by the inbound sequence number delta. Likewise, the sequence number for an inbound packet is increased by the inbound sequence number delta and the acknowledgement number for the same inbound packet is decreased by the outbound sequence number delta.
アウトバウンド制御パケットのシーケンス番号は、送信順序番号デルタだけ増加され、そして同じ発信パケットの確認応答番号は、着信シーケンス番号デルタだけ減少されます。同様に、着信パケットのシーケンス番号は、着信シーケンス番号デルタだけ増加され、同一のインバウンドパケットの確認応答番号は、発信シーケンス番号デルタだけ減少されます。
All limitations associated to NAT [NAT-TERM] are also associated to NAT-PT. Here are the most important of them in detail, as well as some unique to NAT-PT.
NAT [NAT-TERM]に関連する全ての制約もNAT-PTに関連付けられています。ここではNAT-PTに詳細にそれらの最も重要なだけでなく、いくつかのユニークです。
There are limitations to using the NAT-PT translation method. It is mandatory that all requests and responses pertaining to a session be routed via the same NAT-PT router. One way to guarantee this would be to have NAT-PT based on a border router that is unique to a stub domain, where all IP packets are either originated from the domain or destined to the domain. This is a generic problem with NAT and it is fully described in [NAT-TERM].
NAT-PT変換方法の使用には制限があります。セッションに関連するすべての要求と応答が同じNAT-PTルータを経由してルーティングされることが必須です。これを保証する一つの方法は、すべてのIPパケットがいずれかのドメインから発信またはドメイン宛てのスタブドメインに固有である境界ルータに基づくNAT-PTを持っているだろう。これはNATとの一般的な問題であり、それは完全に[NAT-TERM]で説明されています。
Note, this limitation does not apply to packets originating from or directed to dual-stack nodes that do not require packet translation. This is because in a dual-stack set-up, IPv4 addresses implied in a V6 address can be identified from the address format PREFIX::x.y.z.w and a dual-stack router can accordingly route a packet between v4 and dual-stack nodes without tracking state information.
注意、この制限はから発信やパケットの変換を必要としないデュアルスタックノード宛のパケットには適用されません。デュアルスタックセットアップにおいて、V6アドレスに暗黙IPv4アドレスは、アドレスフォーマットプレフィックス:: XYZWから同定することができるからである缶に応じてルートトラッキング無しV4とデュアルスタックノード間のパケットデュアルスタックルータ状態情報。
This should also not affect IPv6 to IPv6 communication and in fact only actually use translation when no other means of communication is possible. For example NAT-PT may also have a native IPv6 connection and/or some kind of tunneled IPv6 connection. Both of the above connections should be preferred over translation when possible. The above makes sure that NAT-PT is a tool only to be used to assist transition to native IPv6 to IPv6 communication.
また、これはIPv6通信へのIPv6に影響を与えないとコミュニケーションの他の手段が可能でないとき、実際にのみ、実際に翻訳を使用する必要があります。例えば、NAT-PTはまた、ネイティブのIPv6接続および/またはトンネリングされたIPv6接続のいくつかの種類を持っていることがあります。上記の接続の両方が翻訳可能な場合よりも優先されなければなりません。上記のNAT-PTは、IPv6のみの通信にネイティブIPv6への移行を支援するために使用されるツールであることを確認します。
A number of IPv4 fields have changed meaning in IPv6 and translation is not straightforward. For example, the option headers semantics and syntax have changed significantly in IPv6. Details of IPv4 to IPv6 Protocol Translation can be found in [SIIT].
IPv4のフィールドの数は、IPv6で意味が変わってきたし、翻訳は簡単ではありません。例えば、オプションヘッダのセマンティクスと構文は、IPv6で大幅に変更されました。 IPv6のプロトコル変換へのIPv4の詳細は[SIIT]で見つけることができます。
Since NAT-PT performs address translation, applications that carry the IP address in the higher layers will not work. In this case Application Layer Gateways (ALG) need to be incorporated to provide support for those applications. This is a generic problem with NAT and it is fully described in [NAT-TERM].
NAT-PTは、アドレス変換を実行するので、より高い層でIPアドレスを運ぶのアプリケーションが動作しません。この場合、アプリケーション層ゲートウェイ（ALG）では、それらのアプリケーションのサポートを提供するために組み込まれる必要があります。これはNATとの一般的な問題であり、それは完全に[NAT-TERM]で説明されています。
One of the most important limitations of the NAT-PT proposal is the fact that end-to-end network layer security is not possible. Also transport and application layer security may not be possible for applications that carry IP addresses to the application layer. This is an inherent limitation of the Network Address Translation function.
NAT-PTの提案の中で最も重要な制限の1つは、エンドツーエンドのネットワーク層セキュリティが不可能であるという事実です。また、輸送およびアプリケーション層のセキュリティは、アプリケーション層にIPアドレスを運ぶアプリケーションのためにできない場合があります。これは、ネットワークアドレス変換機能の固有の限界です。
Independent of NAT-PT, end-to-end IPSec security is not possible across different address realms. The two end-nodes that seek IPSec network level security must both support one of IPv4 or IPv6.
NAT-PTの独立した、エンド・ツー・エンドのIPSecセキュリティは異なるアドレスレルム間では不可能です。 IPSecのネットワークレベルのセキュリティを求める2つのエンドノードは両方のIPv4またはIPv6のいずれかをサポートしなければなりません。
The scheme described in section 4.2 involves translation of DNS messages. It is clear that this scheme can not be deployed in combination with secure DNS. I.e., an authoritative DNS name server in the V6 domain cannot sign replies to queries that originate from the V4 world. As a result, an V4 end-node that demands DNS replies to be signed will reject replies that have been tampered with by NAT-PT.
セクション4.2で説明したスキームは、DNSメッセージの翻訳を必要とします。この方式は、安全なDNSと組み合わせて展開することができないことは明らかです。すなわち、V6ドメインにおける権威DNSネームサーバがV4の世界から発信クエリへの応答を署名することはできません。結果として、DNS署名する返信要求V4エンドノードは、NAT-PTによって改ざんされた応答を拒否します。
The good news, however, is that only servers in V6 domain that need to be accessible from the V4 world pay the price for the above limitation, as V4 end-nodes may not access V6 servers due to DNS replies not being signed.
良いニュースは、しかし、V4の世界からアクセスする必要がV6ドメイン内のサーバーのみが署名されていない返信のDNSに起因するV6・サーバにアクセスすることはできませんV4エンド・ノードとして、上記の制限のために代償を払うことです。
Also note that zone transfers between DNS-SEC servers within the same V6 network are not impacted.
また、同じV6ネットワーク内のDNS-SECサーバー間でゾーン転送が影響を受けないことに注意してください。
Clearly, with DNS SEC deployment in DNS servers and end-host resolvers, the scheme suggested in this document would not work.
明らかに、DNSサーバとエンドホストのリゾルバでDNS SECの展開で、この文書で提案方式では動作しません。
NAT-PT can be a valuable transition tool at the border of a stub network that has been deployed as an IPv6 only network when it is connected to an Internet that is either V4-only or a combination of V4 and V6.
NAT-PTは、それがいずれかV4のみ又はV4およびV6の組み合わせであるインターネットに接続されている場合のIPv6のみのネットワークとして展開されたスタブ・ネットワークの境界に有益な移行ツールであることができます。
NAT-PT, in its simplest form, without the support of DNS-ALG, provides one way connectivity between an IPv6 stub domain and the IPv4 world meaning that only sessions initialised by IPv6 nodes internal to the IPv6 stub domain can be translated, while sessions initiated by IPv4 nodes are dropped. This makes NAT-PT a useful tool to IPv6 only stub networks that need to be able to maintain connectivity with the IPv4 world without the need to deploy servers visible to the IPv4 world.
NAT-PT、DNS-ALGのサポートなしで最も単純な形では、翻訳することができるのIPv6スタブドメインとIPv6によって初期化セッションのみがIPv6スタブドメインへの内部ノードという意味のIPv4の世界との間に一方向の接続性を提供し、セッション中にIPv4ノードによって開始はドロップされます。これは、NAT-PTのIPv4の世界に見えるサーバーを展開することなく、IPv4の世界との接続を維持できるようにする必要があるのIPv6のみのスタブネットワークに有用なツールとなります。
NAT-PT combined with a DNS-ALG provides bi-directional connectivity between the IPv6 stub domain and the IPv4 world allowing sessions to be initialised by IPv4 nodes outside the IPv6 stub domain. This makes NAT-PT useful for IPv6 only stub networks that need to deploy servers visible to the IPv4 world.
NAT-PT DNS-ALGと組み合わされたセッションは、IPv6スタブドメイン外のIPv4ノードによって初期化されることを可能にするIPv6のスタブドメインとIPv4の世界との間の双方向接続性を提供します。これは、IPv4の世界に見えるサーバーを展開する必要があるのIPv6のみのスタブネットワーク用のNAT-PT有用となります。
Some applications count on a certain degree of address stability for their operation. Dynamic address reuse by NAT-PT might not be agreeable for these applications. For hosts running such address critical applications, NAT-PT may be configured to provide static address mapping between the host's V6 address and a specific V4 address. This will ensure that address related changes by NAT-PT do not become a significant source of operational failure.
一部のアプリケーションでは、その動作のためのアドレス安定性のある程度にカウントされます。 NAT-PTによる動的アドレスの再利用は、これらのアプリケーションのための快適ではないかもしれません。このようなアドレスクリティカルなアプリケーションを実行しているホストでは、NAT-PTは、ホストのV6アドレスと特定のV4アドレス間の静的アドレスマッピングを提供するように構成することができます。これは、NAT-PTによるアドレスに関連した変化は、動作不良の大きな原因になっていないことを確認します。
Section 7.4 of this document states that end-to-end network and transport layer security are not possible when a session is intercepted by a NAT-PT. Also application layer security may not be possible for applications that carry IP addresses in the application layer.
このドキュメントのセクション7.4は、セッションがNAT-PTによって遮られたときにエンドツーエンドのネットワークとトランスポート層セキュリティが不可能であることを述べています。また、アプリケーション層のセキュリティは、アプリケーション層でIPアドレスを運ぶアプリケーションのためにできない場合があります。
Section 7.5 of this document states that the DNS-ALG can not be deployed in combination with secure DNS.
このドキュメントのセクション7.5には、DNS-ALGは、セキュアDNSと組み合わせて展開することができないと述べています。
Finally, all of the security considerations described in [NAT-TERM] are applicable to this document as well.
最後に、[NAT-TERM]で説明されているセキュリティ上の考慮事項の全ては、同様に、この文書に適用されます。
[DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999.
[DNS-ALG] Srisuresh、P.、Tsirtsis、G.、Akkiraju、P.およびA. Heffernanのは、RFC 2694、1999年9月の "ネットワークへのDNS拡張は、翻訳者（DNS_ALG）をアドレス"。
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 2065, March 1999.
[DNSSEC]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2065、1999年3月。
[FTP-IPV6] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998.
[FTP-IPV6]オールマン、M.、Ostermann、S.とC.メッツ、 "IPv6とNATsのためのFTP拡張機能"、RFC 2428、1998年9月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[NAT] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.
[NAT] Egevang、K.およびP.フランシス、 "IPネットワークアドレス変換（NAT）"、RFC 1631、1994年5月。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-TERM] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000.
[SIIT] Nordmarkと、E.、 "ステートレスIP / ICMPトランスレータ（SIIT）"、RFC 2765、2000年2月。
[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[TRANS]ギリガン、R.およびE. Nordmarkと、 "IPv6ホストとルータの移行メカニズム"、RFC 1933、1996年4月。
[V6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[V6ADDR] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
Authors' Addresses
著者のアドレス
George Tsirtsis Internet Futures B29 Room 129 BT Adastral Park IPSWICH IP5 3RE England
ジョージTsirtsisインターネット先物B29ルーム129 BT Adastral公園IPSWICH IP5 3REイングランド
Phone: +44 181 8260073 Fax: +44 181 8260073 EMail: george.tsirtsis@bt.com EMail (alternative): gtsirt@hotmail.com
電話：+44 181 8260073ファックス：+44 181 8260073 Eメール：george.tsirtsis@bt.com Eメール（代替）：gtsirt@hotmail.com
Pyda Srisuresh 630 Alder Drive Milpitas, CA 95035 U.S.A.
Pyda Srisuresh 630アルダードライブミルピタス、CA 95035 U.S.A.
Phone: (408) 519-3849 EMail: srisuresh@yahoo.com
電話：（408）519-3849 Eメール：srisuresh@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。