[要約] RFC 2766は、ネットワークアドレス変換（NAT）-プロトコル変換（NAT-PT）に関するものであり、IPv6とIPv4の相互運用性を提供するための技術を定義しています。このRFCの目的は、IPv6ネットワークでIPv4トラフィックを処理するための方法を提供することです。
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)
ネットワークアドレス変換 - プロトコル翻訳（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.
Copyright（c）The Internet Society（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-to-IPV6遷移メカニズムを指定します。このソリューションは、[NAT-Term]で定義されているように、V4レルムのエンドノードと通信しようとするV6レルムのエンドノードに、その逆の透明ルーティングを提供しようとします。これは、ネットワークアドレスの変換とプロトコル変換の組み合わせを使用して達成されます。説明されているスキームは、エンドノードでデュアルスタック（つまり、V6プロトコルサポートと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.
このメモの以前のバージョンをレビューしてくれたPedro Marquesに感謝します。また、このドキュメントで説明されているメカニズムが最初に彼らとの議論を通じて開発されたため、Alan O'Neillと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.
NAT-PTは、V4-V6の境界全体でセッションが開始されるため、動的ベースでV6ノードへの割り当てのためにV4アドレスのプールを使用します。V4アドレスは、グローバルに一意であると想定されています。プライベートV4アドレスを使用したNAT-PTは、このドキュメントの範囲外であり、さらなる研究のためです。NAT-PTは、V4ネットワークのアドレスをV4ネットワークのアドレスとバインドし、その逆にバインドして、アドレス領域間を通過するデータグラムの透明ルーティング[NAT-Term]を提供します。これには、終了ノードに変更が必要ありません。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
SIITプロトコル翻訳とNATおよび適切なALGSの動的アドレス変換機能と組み合わせることにより、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またはIPv6がIPv4を介して通信手段を介して使用できない場合にのみ使用されます。言い換えれば、目的は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という用語は、[NAT-Term]で説明されているIPv4 NATと非常に似ていますが、同一ではありません。IPv4 NATは、1つのIPv4アドレスを別のIPv4アドレスに変換します。このドキュメントでは、NATはIPv4アドレスのIPv6アドレスへの翻訳とその逆を指します。
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ネットワーク内のホストにアクセスできるようにします。伝統的なナットPTでは、セッションはV6ネットワークからのアウトバウンドであり、一方向です。これは、インバウンド方向とアウトバウンド方向の両方でセッションを許可する双方向ナットPTとは対照的です。
Just as with V4 traditional-NAT, there are two variations to traditional-NAT-PT, namely Basic-NAT-PT and NAPT-PT.
V4 Traditional-Natと同様に、従来のNat-PT、つまりBasic-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.
Basic-Nat-PTを使用すると、V6ホストのアドレスを外部ドメインのV4ホストに発信するため、V4アドレスのブロックを翻訳するために確保されています。V6ドメインからアウトバウンドするパケットの場合、IP、TCP、UDP、ICMPヘッダーチェックサムなどのソースIPアドレスおよび関連フィールドが翻訳されています。インバウンドパケットの場合、宛先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をBasic-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の1つになります。インバウンドパケットの場合、宛先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.
Bi-Directional-Nat-PTを使用すると、V4ネットワークおよびV6ネットワークのホストからセッションを開始できます。V6ネットワークアドレスは、いずれかの方向に接続が確立されると、静的または動的にV4アドレスにバインドされます。V4とV6ネットワークのホスト間の名前スペース（つまり、完全に適格なドメイン名）は、エンドツーエンドの一意であると想定されています。V4 Realm Access V6-RealMホストのホストは、DNSを使用してアドレス解像度を解決します。DNS-ALG [DNS-Alg]は、双方向Nat-PTと併せて使用して、名前を促進してアドレスマッピングを促進する必要があります。具体的には、DNS-ALGは、DNSクエリのV6アドレスをV4-ADDRESSバインディングに変換することができ、その逆も同様であり、DNSパケットはV6とV4レルムの間を横断するためです。
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は、IPv4パケットの意味的に同等のIPv6パケットへの翻訳とその逆を指します。プロトコル変換の詳細は[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].
キーワードは、[キーワード]で説明されているように解釈される場合、キーワードは[キーワード]で説明されているように解釈される場合、[キーワード]で説明されているように解釈する必要がある、必要ではない、、必要ではない、、勧められない、そうでなければならない、そうでなければならない。
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は、透明なルーティング[NAT-TERM]とアドレス/プロトコル翻訳に基づいた簡単なソリューションを提供し、V6およびV4レルムの多数のアプリケーションがこれらのアプリケーションに変更を必要とせずに操作できるようにします。
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の動作と、IPv6ドメインのホストからIPv4ドメインのホストへの接続を従来のnat-pttを介して開始する方法について説明します。
[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
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アドレスは、V6エンドノードのV6アドレスに1対1を割り当てることができます。この場合、V6エンドポイントと同じくらい多くのV4アドレスが必要です。このドキュメントでは、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と通信したいとします。NodeAは次のことを作成します。
Source Address, SA=FEDC:BA98::7654:3210 and Destination
Address, 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.
注：プレフィックスプレフィックス::/96は、NAT-PTによってスタブドメインに宣伝され、このプレフィックスに宛てられたパケットはNAT-PTにルーティングされます。事前に構成されたプレフィックスは、IPv6スタブドメイン内でルーティング可能なだけである必要があるため、ネットワーク管理者が選択するルーティング可能なプレフィックスにすることができます。
The packet is routed via the NAT-PT gateway, where it is translated to IPv4.
パケットは、NAT-PTゲートウェイを介してルーティングされ、IPv4に翻訳されています。
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 =プレフィックス:: 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は、IPv4アドレスごとに最大63K TCPおよび63K UDPセッションを可能にしてから、TCPと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 =プレフィックス:: 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は、割り当てられたV4アドレスからTCPポートの1つを割り当てて、次のように（ソースアドレス、ソース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
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つのサーバーに制限されています。たとえば、図1のノード[IPv6-A]は、V6ドメインで唯一のHTTPサーバー（ポート80）である場合があります。node [ipv4-c]はパケットを送信します。
SA=132.146.243.30, source TCP port = 1025 and
DA=120.130.26.10, destination TCP port = 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
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アドレスはNAT-PTによってV6ノードに割り当てられます。新しいインバウンドセッションの開始の識別は、アウトバウンドセッションとは異なる方法で実行されます。ただし、セッションがV6ノードからアウトバウンドを開始するか、V4ノードからインバウンドを開始するかに関係なく、同じ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は、その場合、「A6」レコードを「A」レコードに翻訳する前に、トランザクションのすべての返信を追跡する必要があります。
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.
NAT-PTデザインの目的の1つは、ネイティブIPv6や何らかの形のトンネルなど、他の通信手段がない場合にのみ翻訳を使用することです。次の説明では、NAT-PTは、IPv4接続に加えて、ネイティブIPv6および/またはトンネル付きIPv6接続を持つ場合があります。
[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)
上の図2では、ノードCの名前リゾルバーがノードAの名前を検索リクエストを送信すると、ルックアップクエリはV6ネットワーク上のDNSサーバーに向けられます。NAT-PTがV4とV6ネットワークのボーダールーターに存在していることを考慮すると、この要求データグラムはNAT-PTルーターを通過します。NAT-PTデバイスのDNS-ALGは、次のようにV6ドメインに入るレコードのDNSクエリを変更します。
a) For Node Name to Node Address Query requests: Change the Query type from "A" to "AAAA" or "A6".
a) ノード名のノードアドレスクエリ要求：クエリタイプを「A」から「AAAA」または「A6」に変更します。
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) ノードアドレスのノード名Queryリクエスト：文字列「in-addr.arpa」を文字列「ip6.int」に置き換えます。文字列「in-addr.arpa」の前のV4アドレスオクテット（逆の順序で）を、対応するV6アドレス（マップが存在する場合）オクテットを逆順に置き換えます。
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) 「AAAA」または「A6」レコードのDNS応答を「A」レコードに翻訳します（名前が完全に解決されたときに「A6」レコードのみを変換します）b）V6 DNSによって解決されたV6アドレスをV4アドレスで内部的に割り当てたアドレスに置き換えます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はこの時点でそれを割り当てます。例として、IPv4-Cは、Node-Aの名前をルックアップ（ "A"レコード）にすることにより、ノードIPv6-Aでセッションを初期化しようとします。名前クエリはローカルDNSに送られ、そこからIPv6ネットワークのDNSサーバーに伝播されます。DNS-Algは、「A」クエリを「AAAA」または「A6」クエリにインターセプトして変換し、次のように返信するIPv6ネットワークのDNSサーバーに転送します。
Node-A AAAA FEDC:BA98::7654:3210,
node-a aaaa redc：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
ノード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:
DNS-ALGは、NAT-PTPでFEDC：BA98 :: 7654：3210および120.130.26.1の間のマッピングも保持しています。「A」レコードはNode-Cに返されます。Node-Cは次のようにセッションを開始できます。
SA=132.146.243.30, source TCP port = 1025 and
DA=120.130.26.1, destination TCP port = 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:
パケットはNAT-PTにルーティングされます。これは、FEDC：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
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リソースレコード（RRS）のTTL値は0に設定して、DNSサーバー/クライアントが一時的にRRSを割り当てないように設定する必要があります。ただし、一部のバグ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.
上記のように、着信セッションのアドレスマッピングは、V6ネットワークに存在するノードの複数のクエリを作成できるため、DNS-ALGがNAT-PTのすべてのV4アドレスをマッピングし、したがって正当な着信セッションをブロックするため、サービス拒否攻撃の対象となります。。したがって、着信セッションのアドレスマッピングは、サービス拒否攻撃の影響を最小限に抑えるためにタイムアウトする必要があります。さらに、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ドメインのDNSサーバーまたはV6ネットワーク内部の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アドレスの前で特定のプレフィックス（プレフィックス::/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から別の例を作成するには、node-aがnode-cでセッションを設定したいと考えています。このNode-Aは、Node-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 NAT-PT which will forward it, also unchanged, to the originating host.
Node-CにはIPv6および/またはIPv4アドレスがある可能性があるため、NAT-PTデバイス上のDNS-ALGは、元のAAAA/A6クエリを外部DNSシステムに変更し、同じノードのAクエリを転送します。宛先にAAAA/A6レコードが存在する場合、これは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
Node-CのAレコードがある場合、返信は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
Nodec A 132.146.243.30、Nodec AAAAプレフィックス:: 132.146.243.30またはNodec A6プレフィックス:: 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は他の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スタブドメイン内のV6 DNSサーバーがV6スタブドメインの外側のV4ドメインにどのように転用するかです。ここにはデュアルスタックノードがないことを忘れないでください。外部V4 DNSサーバーは、V4アドレスを指す必要があります。これは、NAT-PTが利用可能なV4アドレスプールの一部です。NAT-PTは、このV4アドレスと内部V6 DNSサーバーのV6アドレスの間に1対1のマッピングを保持します。他の方向では、V6 DNSサーバーは、Non IPv6ノードを示す外部V4 DNSサーバーのIPv4アドレスとプレフィックス（プレフィックス::/96）によって形成されたV6アドレスを指します。このメカニズムは、セカンダリ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は、すべてのIP/ICMPヘッダーをV4からV6に翻訳し、その逆に翻訳して、エンドツーエンドのIPv6をIPv4通信に可能にします。アドレス変換機能と可能なポートマルチプレックスにより、NAT-PTは上層層プロトコル（TCP/UDP）ヘッダーを適切に調整する必要があります。FTP-Algの別のセクションでは、FTP-ALGがFTPペイロードにV4からV6領域へ、またはその逆に移動する変更について説明しています。
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通信の指定されたプレフィックスです。このプレフィックスを使用するアドレスは、NAT-PTゲートウェイにルーティングされます（プレフィックス::/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は、利用可能なIPv4アドレスのプールからIPv6ソースアドレスと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パケットは、フォームのプレフィックス:: IPv4/96の宛先アドレスを持っています。したがって、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は、IPv4アドレスと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に翻訳され、その逆に翻訳されるため、TCP/UDP/ICMPチェックサムの更新手順をNAT-PTで説明しています。
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.
UDPチェックサムは、非ゼロ値に設定されている場合、TCPチェックサムは、V4からV6へのアドレスの変更を反映するために再計算する必要があります。増分チェックサム調整アルゴリズムは[NAT]から借りることができます。NAPT-PTの場合、TCP/UDPチェックサムを調整して、アドレスとTCP/UDPポートの変更を考慮して、V4からV6アドレスに移動する必要があります。
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ヘッダーチェックサムが計算される場合、チェックサムを調整して追加の擬似ヘッダーを考慮する必要があります。また、ICMP内で運ばれるペイロードのソースおよび宛先アドレスの変更（およびNAPT-PTの場合のTCP/UDP/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チェックサムは、V6からV4へのアドレスの変更を反映するために再計算する必要があります。増分チェックサム調整アルゴリズムは[NAT]から借りることができます。NAPT-PTの場合、TCP/UDPチェックサムは、V6からV4アドレスに移動するアドレスと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ヘッダーのチェックサム計算は、チェックサム調整アルゴリズム[NAT]を実行して、計算からV6擬似ヘッダーを削除することにより、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アプリケーションでは、FTPポートコマンドの引数とPASV応答の引数（成功）が含まれます。IPV4アドレスとTCPポートが含まれます。P2。ただし、[FTP-IPV6]は、最終的にポートおよびPASVコマンドの使用を廃止する意図がある場合、EPRTおよびEPSVコマンド拡張をFTPに示唆しています。これらの拡張機能は、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セッションを発信し、ポートまたはPASVコマンドを使用する場合、FTP-AlgはV6ノードに転送する前に、これらのコマンドをそれぞれEPRTおよびEPSVコマンドに翻訳します。同様に、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
Format of EPSV response(Positive): 229 <text indicating
extended passive mode> (<d><d><d><tcp-port><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ノードからのポートコマンドは、プロトコル<Net-PRT>フィールドをAF＃2（IPv6）に設定し、V4ホストアドレス（H1、H2、H3、H4として表される）をNAT-に変換することにより、EPRTコマンドに変換されます。PTは、<Net-Addr>フィールドの[V6ADDR]で定義されているように、文字列表記でV6アドレスを割り当てました。P1で表されるTCPポート、ポートコマンドのP2は、EPRTコマンドの小数<TCP-PORT>として指定する必要があります。さらに、<tcp-port>翻訳は、Napt-PTの場合にも必要になる場合があります。V4ノードからのPASVコマンドは、<Net-PRT>引数をAF＃2に設定して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は、コマンド自体を変更せずに、これらのコマンドにパラメーターを単純に変換します。プロトコル番号<Net-PRT>フィールドは、AF＃1からAF＃2に翻訳されます。<Net-Addr>は、ASCIIのV4アドレスから、[V6ADDR]で定義されている文字列表記でNAT-PTが割り当てられたV6アドレスに翻訳されます。<TCP-PORT> EPSV応答の引数では、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はコマンド文字列「EPRT」と「EPSV」を変更しておき、<Net-Prt>、<Net-Addr>、<TCP-Port>の引数をV6からNAT-に翻訳します。PT（またはNAPT-PT）はV4情報を割り当てました。<TCP-PORT>は、NAPT-PTの場合にのみ翻訳されています。V4ノードからのEPSV応答についても同じことが言えます。これは、RFC 2428のフォワードサポートを確保するために推奨されるアプローチです。ただし、このアプローチにより、V4ホストは、V4およびV6ホストへのアクセスを可能にするために、EPRTおよびEPSV拡張機能をサポートするためにFTPアプリケーションをアップグレードすることが義務付けられています。
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はコマンド文字列「EPRT」と「EPSV」をv6ノードから等価NAT-PTに割り当てられたV4ノード情報に変換し、「ポート」と「PASV」コマンドに添付します。V4ノードに転送します。同様に、V4ノードからのPASV応答は、ターゲットV6ノードに転送する前にEPSV応答に変換されます。ただし、FTP-ALGは、V6ノードによって発行されたコマンド「EPSV <Sacele>すべて」を翻訳することができません。そのような場合、コマンドを受信する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チェックサムのみが調整が必要です。新しいサイズが以前と異なる場合、FTPコントロールセッションのペイロードの長さの変化を反映するために、TCPシーケンス番号も変更する必要があります。V4ヘッダーのIPパケット長フィールドまたはV6ヘッダーのIPペイロード長フィールドも、新しいペイロードサイズを反映するように変更する必要があります。テーブルは、FTP-Algによって使用され、TCPシーケンスとAuncementの数値を、両方向の制御パケットのTCPヘッダーの確認番号を修正します。
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部分のソースアドレス、ソースデータポート、宛先アドレス、および宛先データポート、アウトバウンド制御パケットのシーケンス番号Delta、およびインバウンド制御パケットのシーケンス番号Deltaが必要です。
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.
アウトバウンドコントロールパケットのシーケンス番号は、アウトバウンドシーケンス番号Deltaによって増加し、同じアウトバウンドパケットの確認番号は、インバウンドシーケンス番号Deltaによって減少します。同様に、インバウンドパケットのシーケンス番号はインバウンドシーケンス番号Deltaによって増加し、同じインバウンドパケットの承認番号は、アウトバウンドシーケンス番号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ルーターを介してルーティングされることは必須です。これを保証する1つの方法は、すべての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アドレスをアドレス形式のプレフィックス:: X.Y.Z.Wから識別できるためです。状態情報。
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].
IPv6の多くのIPv4フィールドが意味を変えており、翻訳は簡単ではありません。たとえば、オプションヘッダーのセマンティクスと構文は、IPv6で大幅に変化しています。IPv4からIPv6プロトコル翻訳の詳細は、[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の応答が署名されていないためにV4エンドノードがV6サーバーにアクセスしない可能性があるため、上記の制限の価格を支払うことです。
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.
DNS-Algのサポートなしで最も単純な形式のNat-PTは、IPv6スタブドメインとIPv4ワールドの間の1つの方法で接続されます。IPv4ノードによって開始されます。これにより、NAT-PTはIPv6ワールドに表示されるサーバーを展開する必要なく、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ノードによってセッションを初期化できるようにします。これにより、NAT-PTは、IPv4ワールドに見えるサーバーを展開する必要があるIPv6のみのスタブネットワークのみに役立ちます。
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、「DNS拡張翻訳者（DNS_ALG）、RFC 2694、1999年9月。
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 2065, March 1999.
[DNSSEC] EastLake、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] Allman、M.、Ostermann、S。、およびC. Metz、「IPv6およびNATのFTP拡張」、RFC 2428、1998年9月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Francis、「The IP Network Address Translator（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. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000.
[SIIT] Nordmark、E。、「Stateless IP/ICMP Translator（SIIT）」、RFC 2765、2000年2月。
[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[Trans] Gilligan、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. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373、1998年7月。
Authors' Addresses
著者のアドレス
George Tsirtsis Internet Futures B29 Room 129 BT Adastral Park IPSWICH IP5 3RE England
George Tsirtsisインターネット先物b29ルーム129 bt adastral park ipswich ip5 3reイングランド
Phone: +44 181 8260073
Fax: +44 181 8260073
EMail: george.tsirtsis@bt.com
EMail (alternative): gtsirt@hotmail.com
Pyda Srisuresh 630 Alder Drive Milpitas, CA 95035 U.S.A.
Pyda Srisuresh 630 Alder Drive Milpitas、CA 95035 U.S.A.
Phone: (408) 519-3849 EMail: srisuresh@yahoo.com
電話：（408）519-3849メール：srisuresh@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。