この文書はRFC2766の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
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]で指定されたののほかに、ＩＰｖ４からＩＰｖ６
への移行メカニズムを指定します。この解決は、Ｖ６領域の終端ノードがＶ
４領域の終端ノードと通信する、又は逆の、[NAT-TERM]で定義される、透過
的ルーティング供給する試みです。これはネットワークアドレス翻訳とプロ
トコル翻訳の組合わせで達成します。記述された案はデュアルスタック（す
なわち、ＩＰｖ６とＩＰｖ４プロトコルをサポート）や、終端ノードの特別
な目的の経路条件（トンネルサポートのような）を要請しません。この案は、
[NAT-TERM]で記述されるようにアドレス翻訳と[SIIT]で記述されたＶ６／Ｖ
４プロトコル翻訳の組合わせに基づいています。
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
1. はじめに
2. Terminology
2. 専門用語
2.2 NAT-PT flavors
2.2 ＮＡＴ−ＰＴ風味
2.2.1 Traditional NAT-PT
2.2.1 伝統的なＮＡＴ−ＰＴ
2.2.2 Bi-Directional-NAT-PT
2.2.2 双方向ＮＡＴ−ＰＴ
2.3 Protocol Translation (PT)
2.3 プロトコル翻訳（ＰＴ）
2.4 Application Level Gateway (ALG)
2.4 アプリケーションレベルゲートウェイ（ＡＬＧ）
2.5 Requirements
2.5 要求条件
3. Traditional-NAT-PT Operation (V6 to V4)
3. 伝統的なＮＡＴ−ＰＴオペレーション（Ｖ６からＶ４）
3.1 Basic-NAT-PT Operation
3.1 基本的ＮＡＴ−ＰＴ処理
3.2 NAPT-PT Operation
3.2 ＮＡＰＴ−ＰＴオペレーション
4. Use of DNS-ALG for Address Assignment
4. アドレス割当てへのＤＮＳ−ＡＬＧの使用
4.1 V4 Address assignment for incoming connections (V4 to V6)
4.1 入接続（Ｖ４からＶ６）のＶ４アドレス割当て
4.2 V4 Address assignment for outgoing connections (V6 to V4)
4.2 外向接続（Ｖ６からＶ４）のためのＶ４アドレス割当て
5. Protocol Translation Details
5. プロトコル翻訳細部
5.1 Translating IPv4 headers to IPv6 headers
5.1 ＩＰｖ４ヘッダからＩＰｖ６ヘッダへの変換
5.2 Translating IPv6 headers to IPv4 headers
5.2 ＩＰｖ６ヘッダからＩＰｖ４ヘッダへの翻訳
5.3 TCP/UDP/ICMP Checksum Update
5.3 TCP/UDP/ICMPチェックサム更新
6. FTP Application Level Gateway (FTP-ALG) Support
6. ＦＴＰアプリケーションレベルゲートウェイ（ＦＴＰ−ＡＬＧ）サポート
6.1 Payload modifications for V4 originated FTP sessions
6.1 Ｖ４からのＦＴＰセッションのペイロード修正
6.2 Payload modifications for V6 originated FTP sessions
6.2 Ｖ６からのＦＴＰセッションのペイロード修正
6.3 Header updates for FTP control packets
6.3 ＦＴＰ制御パケットのヘッダ更新
7. NAT-PT Limitations and Future Work
7. ＮＡＴ−ＰＴの限界と将来の仕事
7.1 Topology limitations
7.1 トポロジー限界
7.2 Protocol Translation Limitations
7.2 プロトコル翻訳限界
7.3 Impact of Address Translation
7.3 アドレス翻訳の影響
7.4 Lack of end-to-end security
7.4 エンドエンドセキュリティの欠如
7.5 DNS Translation and DNSSEC
7.5 ＤＮＳ翻訳とＤＮＳＳＥＣ
8. Applicability Statement
8. 適用性宣言
9. Security Considerations
9. セキュリティの考慮
10. REFERENCES
10. 参考文献
Authors' Addresses
著者のアドレス
Full Copyright Statement
著作権表示全文
1. Introduction
1. はじめに
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.
ＩＰｖ６は１９７０年代に設計されたＩＰｖ４を近代化するよう意図される
ＩＰプロトコルの新しい版です。ＩＰｖ６はＩＰｖ４より未来のインターネッ
トの成長を考慮した多くの利点を持っていて、ＩＰ設定と管理を単純化する
でしょう。ＩＰｖ６はＩＰｖ４より大きなアドレス空間を持ち、積極的な経
路集約を促進するアドレスモデルと強力な自動設定メカニズムを持っていま
す。インターネットの成長とプラグアンドプレイの必要性がＩＰｖ６の広範
囲にわたる採用をもたらすと思われます。
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.
ＩＰｖ４とＩＰｖ６ノードが共存して、通信が必要な長い移行時期があるこ
とを想定されます。ＩＰｖ４からＩＰｖ６への移行と共存メカニズムの強く
柔軟な道具がこの移行時期の間に必要とされるでしょう。
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]は、ＩＰｖ６のみとＩＰｖ４のみのノード間で、ＩＰｖ４と
ＩＰｖ６データグラムのプロトコルに依存しない翻訳によって、セッション
の状態情報をもたずに、通信を許すプロトコル翻訳機構を記述します。SIIT
提案はＶ６ノードがＶ４ノードと通信する際にＶ４アドレスを割り当てられ
ると想定し、これらのアドレスの割当てのためにメカニズムを指定しません。
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.
ＮＡＴ−ＰＴは、セッションがV４-V６境界線を超えて始められる時、ダイ
ナミックベースでV６ノードに割当てるために V４ アドレスプールを使い
ます。V４ アドレスは世界的規模でユニークであると考えられます。プラ
イベートのV４アドレスを持つＮＡＴ−ＰＴはこの文書の範囲外で、研究中
です。ＮＡＴ−ＰＴがV４ネットワークアドレスとV６ネットワークアドレ
スをくくりつけ、逆もまた同様で、アドレス領域間でデータグラム転送の
透過的ルーティング[NAT-TERM]を提供します。これは終端ノードの変更を
要求せず、ＩＰパケットルーティングは完全に終端ノードに透過[NAT-TERM]
です。ＮＡＴ−ＰＹは扱っているセッションの追跡を要求し、セッション
に関する内行きと外行きのデータグラムが同じＮＡＴ−ＰＴルーターを通
るのが必須です。ＮＡＴ−ＰＴのトポロジー制限がV４ＮＡＴに記述された
それらと同じである事を指摘します[NAT-TERM]。[SIIT]で指定したプロト
コル翻訳の細部がプロトコル構文論／意味論翻訳でアドレス翻訳を拡張す
るために使われるでしょう。ＮＡＴ−ＰＴのための詳細な適用性宣言がこ
の文書の終わりの７章で見つかるでしょう。
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プロトコル翻訳とＮＡＴのダイナミックなアドレス翻訳能力の組合わせ
と、適切なアプリケーションゲートウェイによって、ＮＡＴ−ＰＴは多数の
一般に使われるアプリケーションについてＩＰｖ６のみのノードとＩＰｖ４
のみのノードの間を仲立ちする完全な解決策を供給します。
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.
ＮＡＴ−ＰＴの基本的な仮定は、他のネイティブＩＰｖ６やＩＰｖ４上のＩ
Ｐｖ６トンネル手段で通信が可能でない場合に使用する、ということだけで
す。換言すれば狙いはＩＰｖ６だけのノードとＩＰｖ４だけのノード間の翻
訳に使うだけで、ＩＰｖ６だけのノードとＩＰｖ４デュアルスタックノード
間は他の方法で通信します。
2. Terminology
2. 専門用語
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]から借用されます。以下にこ
の文書に特有な用語をリストアップします。
2.1 Network Address Translation (NAT)
2.1 ネットワークアドレス翻訳（ＮＡＴ）
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-TERM]で記述されているＩＰｖ４ＮＡＴに非
常に類似していますが、同一ではありません。ＩＰｖ４ＮＡＴは１つのＩＰ
ｖ４アドレスを他のＩＰｖ４アドレスに翻訳します。この文書で、ＮＡＴは
ＩＰｖ４アドレスをＩＰｖ６アドレスへ翻訳する事と、その逆を参照します。
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.
Ｖ４ＮＡＴ[NAT-TERM]がプライベートV４と外部V４アドレス領域の間にルー
ティングを供給するが、この文書のＮＡＴはV６アドレス領域と外部V４アド
レス領域間にルーティングを供給します。
2.2 NAT-PT flavors
2.2 ＮＡＴ−ＰＴ風味
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]のＶ４ＮＡＴでいくつもの風味があるように、次のＮＡＴ−
ＰＴの種類がこの文書で識別されるかもしれません。
2.2.1 Traditional NAT-PT
2.2.1 伝統的なＮＡＴ−ＰＴ
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.
伝統的なＮＡＴ−ＰＴはV６ネットワークのホストがV４ネットワークのホ
ストにアクセスを許すでしょう。伝統的なＮＡＴ−ＰＴで、セッションは
Ｖ６ネットワークから外向きの一方通行です。これは双方向性のＮＡＴ−
ＰＴと対照的である、双方向性は内行き方向と外行き方向のセッションを
認めます。
Just as with V4 traditional-NAT, there are two variations to
traditional-NAT-PT, namely Basic-NAT-PT and NAPT-PT.
ちょうどＶ４の伝統的ＮＡＴと同じように、伝統的ＮＡＴ−ＰＴに２種類、
すなわち、基本ＮＡＴ−ＰＴとＮＡＰＴ−ＰＴがあります。
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.
基本ＮＡＴ−ＰＴで、Ｖ６ホストが外部ドメインのＶ４ホストへのセッショ
ンを作る時、Ｖ４のブロックアドレスがアドレス翻訳用に設定されます。Ｖ
６ドメインから外行きのパケットで、ソースＩＰアドレスとＩＰとＴＣＰと
ＵＤＰとＩＣＭＰヘッダのチェックサムのような関連したフィールドが翻訳
されます。内行きのパケットで、宛先ＩＰアドレスと上記と同じチェックサ
ムが翻訳されます。
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.
ＮＡＰＴ−ＰＴがさらに同じく転送識別子（例えば、ＴＣＰやＵＤＰポート
番号やＩＣＭＰ問合せ識別子）を翻訳することによって翻訳１つのステップ
の考えを拡張します。これは多くのＶ６ホストの転送識別子をひとつのＶ４
アドレスの転送識別子の中に多重することを許します。ＮＡＰＴ−ＰＴはＶ
６ホストの集団が１つのＶ４アドレスを共有することを許します。ＮＡＰＴ−
ＰＴは、基本ＮＡＴ−ＰＴと、ポート変換と拡張アドレスプールの組合わせ
でできることに注意してください。
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.
Ｖ６ネットワークから外行きのパケットのために、ＮＡＰＴ−ＰＴはソース
ＩＰアドレスとソース転送識別子とＩＰやＴＣＰやＵＤＰやＩＣＭＰのチェッ
クサムのような関連したフィールドを翻訳するでしょう。転送識別子はＴＣ
Ｐ／ＵＤＰポートやＩＣＭＰ問合せ識別子のどれかです。内行きのパケット
に対して、宛先ＩＰアドレスと宛先転送識別子とＩＰと転送ヘッダーチェッ
クサムは翻訳されます。
2.2.2 Bi-Directional-NAT-PT
2.2.2 双方向ＮＡＴ−ＰＴ
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.
双方向ＮＡＴ−ＰＴを使うと、Ｖ６ネットワークと同様に、Ｖ４ネットワー
クでホストからセッションが始められます。いずれかの方向で接続が指示で
確立される時、Ｖ６ネットワークアドレスが、静的か動的にＶ４アドレスに
拘束されます。Ｖ４とＶ６ネットワークホストの名前空間（すなわち、ホス
トの完全に指定されたドメイン名）は両者にユニークと考えられます。Ｖ４
領域のホストがアドレス解決のためにＤＮＳを使いってＶ６領域ホストにア
クセスします。ＤＮＳ−ＡＬＧ[DNS-ALG]が名前とアドレスのマッピングの
ために双方向性のＮＡＴ−ＰＴと関連して使用されなくてはなりません。特
に、DNS-ALGは、ＤＮＳパケットがＶ６とＶ４領域を行き交えるように、Ｄ
ＮＳ問合せと回答ののＶ６アドレスを対応するＶ４アドレスに変換し、逆も
出来なければなりません。
2.3 Protocol Translation (PT)
2.3 プロトコル翻訳（ＰＴ）
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].
この文書でＰＴとは、ＩＰｖ４パケットを意味的に同じＩＰｖ６パケットに
翻訳、又は逆のことです。プロトコル翻訳の細部が[SIIT]で記述されます。
2.4 Application Level Gateway (ALG)
2.4 アプリケーションレベルゲートウェイ（ＡＬＧ）
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.
アプリケーションレベルゲートウェイ（ＡＬＧ）[NAT-TERM]はアプリケー
ション特有のエージェントで、Ｖ６ノードがＶ４ノードと通信を、又は逆の
通信を許します。あるアプリケーションがペイロードでネットワークアドレ
スを運びます。ＮＡＴ−ＰＴアプリケーションに無頓着で、ペイロードの中
身をみません。多くのこのようなアプリケーションに対するサポートを供給
するために、ＡＬＧはＮＡＴ−ＰＴと連携して動作します。
2.5 Requirements
2.5 要求条件
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].
この文章に表れるキーワードMUSTとMUST NOTとREQUIREDとSHALLとSHALL NOT
とSHOULDとSHOULD NOTとRECOMMENDEDとMAYとOPTIONALは[KEYWORDS]で記述さ
れるように解釈されるはずです。
3. Traditional-NAT-PT Operation (V6 to V4)
3. 伝統的なＮＡＴ−ＰＴオペレーション（Ｖ６からＶ４）
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-TERM]とアドレス／プロトコル翻
訳に基づいたまっすぐな解決策を提供し、アプリケーションに対する変更を
必要としないでV６とV４領域の多数のアプリケーションの相互運用を許しま
す。
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
次の段落で伝統的なＮＡＴ−ＰＴ運用と、伝統的なＮＡＴ−ＰＴを通しての
ＩＰｖ６ドメインのホストからＩＰｖ４ドメインのホストへの接続を始める
方法を記述します。
3.1 Basic-NAT-PT Operation
3.1 基本的ＮＡＴ−ＰＴ処理
[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
ＩＰｖ６−ＡノードのＩＰｖ６アドレス → FEDC:BA98::7654:3210
Node IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
ＩＰｖ６−ＢノードのＩＰｖ６アドレス → FEDC:BA98::7654:3211
Node IPv4-C has an IPv4 address -> 132.146.243.30
ＩＰｖ４−ＣノードのＩＰｖ４アドレス → 132.146.243.30
NAT-PT has a pool of addresses including the IPv4 subnet
120.130.26/24
ＮＡＴ−ＰＴはＩＰｖ４サブネット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.
アドレスプールの中のV４アドレスはV６エンドノードのV６アドレスと１対１
で割り当てできます、その場合V６エンドポイントと同じだけの多くのV４ア
ドレスを必要とします。この文書で我々はV６ネットワークがV６エンドノー
ドより少ないV４アドレスだけを持っていて、ダイナミックなアドレス割当て
が少なくともいくつかのノードに必要とされると想定します。
Say the IPv6 Node A wants to communicate with the IPv4 Node C. Node
A creates a packet with:
ＩＰｖ６ノードＡがＩＰｖ４ノードCと通信を望んでるとします。ノードＡが
パケットを作ります：
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はＮＡＴ−ＰＴによって末端ドメイン
で広告され、このプレフィックスのアドレスへのパケットがＮＡＴ−ＰＴに
転送されるでしょう。事前設定されたPREFIXはＩＰｖ６末端ドメイン内でルー
チングできる必要があるだけで、ネットワーク管理者はどんなプレフィック
スでも選択できます。
The packet is routed via the NAT-PT gateway, where it is translated
to 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.
もし外向パケットがセッション初期化パケットではないなら、ＮＡＴ−ＰＴ
はすでに、関連したセッションの翻訳のための割当てＩＰｖ４アドレスと他
のパラメータを含む状態を、記憶しています。もしこの状態が存在しないな
ら、パケットは静かに捨てられるべきです。
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.
もしパケットがセッション初期化パケットであるなら、ＮＡＴ−ＰＴはアド
レスプールからローカルにアドレス（例えば：120.130.26.10）を割り当て、
そしてパケットはＩＰｖ４に翻訳されます。翻訳パラメータはセッションと
共にキャッシュされ、ＩＰｖ６とＩＰｖ４の対応関係はＮＡＴ−ＰＴによっ
て保存されます。
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.
出来上がったＩＰｖ４パケットはSA=120.130.26.10とDA=132.146.243.30です。
戻りのトラフィックはＮＡＴ−ＰＴによって同じセッションに属していると
見なされるでしょう。ＮＡＴ−ＰＴはパケットを翻訳するために状態情報を
使い、結果アドレスはSA=PREFIX::132.146.243.30とDA=FEDC:BA98::7654:3210
でしょう。このパケットが正常にＩＰｖ６のみの末端ネットワーク内で転送
できることに注意してください。
3.2 NAPT-PT Operation
3.2 ＮＡＰＴ−ＰＴオペレーション
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.
「ネットワークアドレスポート翻訳＋プロトコル翻訳」を表すＮＡＰＴ−Ｐ
ＴはＶ６ノードにＶ４アドレスを使って透過的にＶ４ノードと通信すること
を許すでしょう。Ｖ６ノードのＴＣＰ／ＵＤＰポートは登録されたＶ４アド
レスのＴＣＰ／ＵＤＰポートに変換されます。
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.
ＮＡＴ−ＰＴがＴＣＰとＵＤＰと他のアプリケーションポートタイプを多重
送信することに限定されているが、ＮＡＰＴ−ＰＴはＮＡＴ−ＰＴ固有の問
題を解きます。すなわち、ＮＡＴ−ＰＴは、翻訳目的で割り当てられたＶ４
アドレスプールが使い果たされる時パンクします。アドレスプールが使い尽
くされると、新しいＶ６ノードが外の世界とセッションを確立できません。
他方ＮＡＰＴ−ＰＴは、どのＴＣＰとＵＤＰポートも割当てられていなけれ
ば、最大６３ＫのＴＣＰと６３ＫのＵＤＰセッションを許します。
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.
図１の例を修正し、境界ルータ上に（ＮＡＴ−ＰＴの代わりに）ＮＡＰＴ−
ＰＴを持つことができ、すべてのＶ６アドレスはひとつのＶ４アドレス
120.130.26.10に変換できます。
IPv6 Node A would establish a TCP session with the IPv4 Node C as
follows:
ＩＰｖ６ノードＡが次のようにＩＰｖ４ノードＣとＴＣＰセッションを確立
するでしょう：
Node A creates a packet with:
ノードＡはパケットを生成します
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、ソースＴＣＰポート = 3017と、
宛先アドレスDA = PREFIX::132.146.243.30、宛先ＴＣＰポート = 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:
パケットがＮＡＰＴ−ＰＴボックスに達する時、ＮＡＰＴ−ＰＴは次のよう
に（ソースアドレス、ソースＴＣＰポート）の２項組みを翻訳するために、
割当てＶ４アドレスのＴＣＰポートの１つを割り当てるでしょう：
SA=120.130.26.10, source TCP port = 1025 and
DA=132.146.243.30, destination TCP port = 23.
SA=120.130.26.10、ソースＴＣＰポート = 1025と、
DA=132.146.243.30、宛先ＴＣＰポート = 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でＴＣＰポート２３からの戻っているトラフィックが同じ
セッションに所属して認識され、以下の様にＶ６に翻訳されるでしょう：
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、ソースＴＣＰポート = 23と、
DA = FEDC:BA98::7654:3210、宛先ＴＣＰポート = 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:
内行きのＮＡＰＴ−ＰＴセッションは、静的スタティックなＴＣＰ／ＵＤＰ
ポートのマッピングに基づき、サービス毎に１つのサーバーに制限されます。
例えば、図１でのノード[IPv6-A]はＶ６ドメインで唯一のＨＴＴＰ（ポート
８０）かもしれません。ノード[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、ソースＴＣＰポート = 1025と、
DA=120.130.26.10、宛先ＴＣＰポート = 80。
NAPT-PT will translate this packet to:
ＮＡＰＴ−ＰＴはこのパケットを翻訳するでしょう：
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、ソースＴＣＰポート = 1025と、
DA=FEDC:BA98::7654:3210、宛先ＴＣＰポート = 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].
上記の例で、８０の宛先ポートでＮＡＰＴ−ＰＴに達するすべてのセッショ
ンが同じノード[IPv6-A]に転送されることに注意して下さい。
4. Use of DNS-ALG for Address Assignment
4. アドレス割当てへのＤＮＳ−ＡＬＧの使用
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.
ＮＡＴ−ＰＴが内行きか外行きセッションの開始を識別する時、ＮＡＴ−Ｐ
ＴによってＶ６ノードにＩＰｖ４アドレスが割り当てられます。新しい内行
きのセッションの開始の識別は外行きのセッションと異なります。しかしな
がら、Ｖ６ノードから外行きに開始するかＶ４ノードから内行きに開始する
かにかかわらず、同じＶ４アドレスプールがＶ６ノードへの割当てのために
使用できます。
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.
ＩＰｖ４名とアドレスの変換はＤＮＳの「Ａ」レコードで行います。ＩＰｖ
６名からアドレスへの変換は今のところＤＮＳの「ＡＡＡＡ」レコードで行
います。「Ａ６」レコードが定義されていますが、執筆時点で完全に標準化
されていても、配置されたもいません。
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.
この章で記述されたＤＮＳ−ＡＬＧオペレーションの原則は「ＡＡＡＡ」で
も「Ａ６」レコードでも同じです。唯一の相違は「Ａ６」レコードの名前解
決が複数のの質問と答えを必要とするかもしれないということです。ＤＮＳ
−ＡＬＧは、このような場合に、「Ａ６」レコードを「Ａ」レコードに翻訳
する前に、すべての答えを追跡するべきです。
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.
ＮＡＴ−ＰＴデザインの目的は、ネイティブＩＰｖ６やトンネルのような
他の通信手段がなにもない時にだけ、翻訳を使うことです。次のＮＡＴ−
ＰＴ論議で、ＩＰｖ４接続性のほかに、ネイティブＩＰｖ６とトンネル接
続をもつかもしれません。
4.1 V4 Address assignment for incoming connections (V4 to V6)
4.1 入接続（Ｖ４からＶ６）のＶ４アドレス割当て
[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
ノードＩＰｖ６−ＡのＩＰｖ６アドレス→ FEDC:BA98::7654:3210
Node IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
ノードＩＰｖ６−ＢのＩＰｖ６アドレス→ FEDC:BA98::7654:3211
Node IPv4-C has an IPv4 address -> 132.146.243.30
ノードＩＰｖ４−ＣのＩＰｖ４アドレス→ 132.146.243.30
NAT-PT has a pool of addresses including the IPv4 subnet
120.130.26/24
ＮＡＴ−ＰＴはＩＰｖ４サブネット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)
上記図２で、ノードＣのネームリゾルバがノードＡに名前検索リクエストを
送る時、検索の問合せはＶ６ネットワーク上のＤＮＳサーバーに向けられま
す。ＮＡＴ−ＰＴがＶ４とＶ６ネットワークの境界ルータに位置すると想定
すると、このリクエストはＮＡＴ−ＰＴルータをとおります。ＮＡＴ−ＰＴ
装置上のＤＮＳ−ＡＬＧはＡレコードのＤＮＳ問合せをＶ６ドメインに以下
の様に修正するでしょう：（ＴＣＰ／ＵＤＰのＤＮＳパケットがソースか宛
先ポート番号が５３であるという事によって認識されることに注意して下さ
い）。
a) For Node Name to Node Address Query requests: Change the Query
type from "A" to "AAAA" or "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) ノードアドレスからノード名の問合せ：文字列「IN-ADDR.ARPA」を文
字列「IP6.INT」で置き換えます。「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:
反対方向に、ＤＮＳ回答がＶ６ネットワークのＤＮＳサーバーからＶ４ノー
ドへ送られる時、ＤＮＳ−ＡＬＧはもう１度ＤＮＳパケットを途中で捕えて、
以下の様にします：
a) Translate DNS responses for "AAAA" or "A6" records into "A"
records, (only translate "A6" records when the name has
completely been resolved)
a) 「ＡＡＡＡ」か「Ａ６」レコードのＤＮＳ回答を「Ａ」レコードに翻
訳します（名前が完全に変換された時だけ、「Ａ６」レコードを翻訳
します）。
b) Replace the V6 address resolved by the V6 DNS with the V4
address internally assigned by the NAT-PT router.
b) Ｖ６ＤＮＳによって変換されたＶ６アドレスをＮＡＴ−ＰＴルーター
の割り当てたＶ４アドレスで置き換えます。
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)
もしＶ４アドレスが前にこのＶ６ノードに割り当てられていないなら、ＮＡ
Ｔ−ＰＴはアドレスを１つを割り当てるでしょう。例えば、ノードＡの名前
検索（「Ａ」レコード）によってＩＰｖ４-ＣがノードＩＰｖ６-Ａとセッショ
ンを初期化しようと試みるとします。名前の問合せはローカルなＤＮＳに行
き、そこからＩＰｖ６ネットワークのＤＮＳサーバーに行きます。ＤＮＳ−
ＡＬＧはそれを横取りし、「Ａ」問合せを「ＡＡＡＡ」か「Ａ６］問い合わ
せへ翻訳し、これをＩＰｖ６ネットワークのＤＮＳサーバへ送り、ＤＮＳサー
バは以下の様に返事をします：（例は便利さのためにＡＡＡＡレコードを使
います）。
Node-A AAAA FEDC:BA98::7654:3210,
this is returned by the DNS server and gets intercepted and
translated by the DNS-ALG to:
これはＤＮＳサーバーから返され、ＤＮＳ−ＡＬＧが横取りして翻訳します：
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:
ＤＮＳ−ＡＬＧはＮＡＴ−ＰＴにFEDC:BA98::7654:3210と120.130.26.1の対
応を保持します。「Ａ」レコードはノードＣから返されます。ノードＣが次
のようにセッションを開始できます：
SA=132.146.243.30, source TCP port = 1025 and
DA=120.130.26.1, destination TCP port = 80
SA=132.146.243.30、ソースＴＣＰポート = 1025と、
DA=120.130.26.1、宛先ＴＣＰポート = 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: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、ソースＴＣＰポート = 1025と、
DA=FEDC:BA98::7654:3210、宛先ＴＣＰポート = 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.
ＮＡＴ−ＰＴを通るすべてのＤＮＳ資源レコード（ＲＲ）のＴＴＬ値は、サー
バ／クライアントがキャッシュしないように０を設定するべきです。あるＤ
ＮＳクライアントの実装誤りのため、１を設定したほうがうまく動く事例が
あることに注意してください。ＴＴＬ値は静的に対応したアドレスでは変更
しないでおくべきです。
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.
入セッションのアドレスのマッピングは、上記のように、Ｖ６ネットワーク
のノートの問合せを多数行うとＤＮＳ−ＡＬＧがＮＡＴ−ＰＴの全Ｖ４アド
レスを使ってしまい、正しい入セッションの邪魔をするので、サービス妨害
攻撃の適用を受けます。それで、入セッションのアドレスマッピングがサー
ビス妨害攻撃の効果を最小にするためにタイムアウトするべきです。さらに、
１つのＩＰｖ４アドレスを（ＮＡＰＴ−ＰＴを使って、３.２章参照）を外
向セッションに予約すると、このような攻撃の外向きセッションへの効果を
最小にすることができます。
4.2 V4 Address assignment for outgoing connections (V6 to V4)
4.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.
Ｖ６ノードは、Ｖ４ドメインのＤＮＳサーバか、内部Ｖ６ネットワークのＤ
ＮＳサーバーからＶ４ノードのアドレスを学習します。我々はＶ６ドメイン
の内部ＤＮＳサーバーが内部ノードのＩＰｖ６アドレスと名前の対応を維持
し、可能なら外部ノードのマッピングをキャッシュすることを勧めます。Ｖ
６ドメインのＤＮＳサーバーが外部Ｖ４ノードのマッピングを含む場合、Ｄ
ＮＳ問合せはＶ６ドメインを通らず、ＤＮＳ−ＡＬＧの仲介の必要性を取り
除くでしょう。さもなければ、問合せはＶ６ドメインを通り、ＤＮＳ−ＡＬ
Ｇの仲介を受けます。我々はＶ４ドメインの外部ＤＮＳサーバが、外部ノー
ド（つまりＶ４ノード）だけの名前マッピングのキャッシュをするのを勧め
ます。ＩＰｖ４−ＩＰｖ６境界を超えたゾーン転送は強く反対します。
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.
ＮＡＰＴ−ＰＴの場合、発見された新しい外向セッション毎にＶ４アドレス
のＴＣＰ／ＵＤＰソースポートが割り当てられます。
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.
我々はＶ４ノードと通信する必要があるＶ６ノードが、Ｖ４ノードのＩＰｖ
４アドレスの前特定のプレフィックス (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.
図２から他の例を作り、ノード-Ａがノード-Ｃとセッションを確立すること
を望むと考えてください。これはノード-Ａがノード-Ｃの名前検索（「ＡＡ
ＡＡ」あるいは「Ａ６」レコード）をすることによって開始します。
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.
ノードＣがＩＰｖ６とＩＰｖ４アドレスを持っているかもしれないので、Ｎ
ＡＴ−ＰＴ装置上のＤＮＳ−ＡＬＧが、同じノードへのＡ問合せ同様に、オ
リジナルのＡＡＡＡ／Ａ６問合せ変えずに外部ＤＮＳシステムへ転送します。
もしＡＡＡＡ／Ａ６レコードが宛先のために存在するなら、これはＮＡＴ−
ＰＴに返されて、ＮＡＴ−ＰＴは同じく変更せずに出発点ホストに転送する
でしょう。
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
もしノードＣのＡレコードがあるなら、答えは同じくＮＡＴ−ＰＴに戻りま
す。ＤＮＳ−ＡＬＧはそれから、適切なプレフィックスを加えている答えを
翻訳し、そして学んだかＩＰｖ６アドレスと共にそれを出発点の装置に転送
します。それの答えが以下でしょう。
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 PREFIX::132.146.243.30か
NodeC 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.
今ノードＡが他のＩＰｖ６アドレス同様にこのアドレスも使うことができ、
Ｖ６ＤＮＳサーバーは、プレフィックスが変化しない限り、それをキャッシュ
できます。
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.
ここでの問題がどのようにＶ６末端ドメインのＶ６ＤＮＳサーバーがＶ６末
端ドメイン外のＶ４ドメインと話をするかです。ここにデュアルスタックノー
ドがないことを思い出してください。外部のＶ４ＤＮＳサーバーは、ＮＡＴ−
ＰＴに利用可能なＶ４アドレスプールの一部のＶ４アドレス、を指し示す必
要があります。ＮＡＴ−ＰＴは内部Ｖ６ＤＮＳサーバーのＶ４アドレスとＶ
６アドレスの間の１対１のマッピングを保持します。他の方向で、Ｖ６ＤＮ
Ｓサーバーは、非ＩＰｖ６ノードを示すプレフィックス(PREFIX::/96)と外
部のＶ４ＤＮＳサーバーのＩＰｖ４アドレスから作られたＶ６アドレスを指
し示します。このメカニズムは第２のＤＮＳサーバーを受け入れるために容
易に拡張できます。
Note that the scheme described in this section impacts DNSSEC. See
section 7.5 of this document for details.
この章で記述した案はＤＮＳＳＥＣに影響を与えるのに注意してください。
細部はこの文書の７.５章を見てください。
5. Protocol Translation Details
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.
ＩＰｖ４とＩＣＭＰｖ４のヘッダはＶ６対応するものと類似していますが、
多くのフィールドはなくなったり、意味が変わったり、長さが変わっていま
す。エンドエンドのＩＰｖ６からＩＰｖ４への通信を可能にするために、Ｎ
ＡＴ−ＰＴがＶ４からＶ６へすべてのＩＰ／ＩＣＭＰヘッダーを翻訳するべ
きで、逆もまた同様です。アドレス翻訳機能とポート多重のために、ＮＡＴ
−ＰＴは上位レイヤプロトコル（ ＴＣＰ／ＵＤＰ）ヘッダーに同じく適切
な調整をするべきです。別の章のＦＴＰ−ＡＬＧに、ＦＴＰペイロードがＶ
４からＶ６へ通るためあるいは逆を行うための、ＦＴＰ−ＡＬＧの修正動作
を記述します。
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]で記述されますが、ＮＡＴ−ＰＴが同じくネッ
トワークアドレス翻訳を行うという事実のためにＳＩＩＴに若干の修正が必
要です。
5.1 Translating IPv4 headers to IPv6 headers
5.1 ＩＰｖ４ヘッダからＩＰｖ６ヘッダへの変換
This is done exactly the same as in SIIT apart from the following
fields:
これは次のフィールド以外は正確にＳＩＩＴと同じです：
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)
ソースアドレス
下位３２ビットはＩＰｖ４アドレス。上位９６ビットはＩＰｖ４アド
レスに共通な決められたPREFIX。このPREFIXを使うアドレスはＮＡＴ
−ＰＴゲートウェイ(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.
宛先アドレス
ＮＡＴ−ＰＴは宛先ノードのＩＰｖ４宛先アドレスとＩＰｖ６アドレ
ス間の対応を維持します。ＩＰｖ４宛先アドレスは対応したＩＰｖ６
アドレスによって置き換えられます。
5.2 Translating IPv6 headers to IPv4 headers
5.2 ＩＰｖ６ヘッダからＩＰｖ４ヘッダへの翻訳
This is done exactly the same as in SIIT apart from the Source
Address which should be determined as follows:
これはソースアドレス以外はＳＩＴＴと正確に同じで、ソースアドレスは以
下のように正確にされるべきです：
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.
ソースアドレス：
ＮＡＴ−ＰＴはＩＰｖ６ソースアドレスと利用可能なＩＰｖ４アドレ
スプールからのＩＰｖ４アドレスの間の対応関係を維持します。ＩＰ
ｖ６ソースアドレスはその対応関係でＩＰｖ４アドレスに置き換えら
れます。
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.
宛先アドレス：
翻訳されるＩＰｖ６パケットがPREFIX::IPv4/96形式のプレフィック
スを宛先アドレスに持ちます。ＩＰｖ６宛先アドレスの下位３２ビッ
トがＩＰｖ４宛先アドレスにコピーされます。
5.3 TCP/UDP/ICMP Checksum Update
5.3 TCP/UDP/ICMPチェックサム更新
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.
ＮＡＴ−ＰＴは利用可能なＩＰｖ４アドレスプールからＩＰｖ６アドレスと
ＩＰｖ４アドレスの対応関係を維持します。この対応はＮＡＴ−ＰＴでのパ
ケットの翻訳で使われます。
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.
次の章は細別は、パケットがＶ４からＶ６に翻訳されるときや逆のときの、
ＮＡＴ−ＰＴのTCP/UDP/ICMPチェックサム更新手順を示します。
5.3.1 TCP/UDP/ICMP Checksum Update from IPv4 to IPv6
5.3.1 ＩＰｖ４からＩＰｖ６の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.
ゼロ以外の値のＵＤＰチェックサムとＴＣＰチェックサムは、Ｖ４からＶ６
へのアドレス変化を反映するために計算し直されるべきです。逐次的なチェッ
クサム調整アルゴリズムは[NAT]から借用されるかもしれません。ＮＡＰＴ
−ＰＴの場合、 ＴＣＰ／ＵＤＰチェックサムが、Ｖ４からＶ６アドレスま
で行って、アドレスとＴＣＰ／ＵＤＰポート変更を説明するように調整され
るべきです。
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.
Ｖ４ＵＤＰ パケットのチェヘックサムがゼロに瀬って言うされる時、ＮＡ
Ｔ−ＰＴはＶ６によって翻訳されたＵＤＰパケットのために全部のチェッ
クサムを評価しなくてはなりません。もしゼロのチェックサムのＶ４ＵＤＰ
パケッの断片が到着するなら、ＮＡＴ−ＰＴはひとつの分割パケットが組み
立てられるまで、すべての断片を待ち受けて、そしてＶ６ＵＤＰパケットの
転送の前にチェックサムを評価しなくてはなりません。
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と異なり、チェックサム計算の際に、ＵＤＰやＴＣＰと同
様に疑似ヘッダーを使います。結果的に、 ICMPv6ヘッダチェックサムが計
算される時[SIIT]、チェックサムは追加の疑似ヘッダを計算するように調整
する必要があります。ノート、ＩＣＭＰの中で運ばれたペイロードのソース
と宛先アドレス（そしてＮＡＰＴ−ＰＴの場合TCP/UDP/ICMP識別子の変更）
の変更が同じくチェックサムに必要とされる調整であるかもしれません。
5.3.2 TCP/UDP/ICMP Checksum Update from IPv6 to IPv4
5.3.2 ＩＰｖ６からＩＰｖ４の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.
Ｖ６からＶ４へのアドレス変更を反映して、ＴＣＰとＵＤＰのチェックサム
が計算し直されるべきです。逐次的なチェックサム調整アルゴリズムが[NAT]
から借用されるかもしれません。ＮＡＰＴ−ＰＴの場合で、ＴＣＰ／ＵＤＰ
チェックサムが、Ｖ６からＶ４へのアドレスとＴＣＰ／ＵＤＰポート変更を
計算するように調整されるべきです。ＵＤＰパケットで、オプションで、
チェックサムはゼロに変えられるだけかもしれません。
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.
Ｖ４ＩＣＭＰヘッダのチェックサム計算はＶ６擬似ヘッダを計算から取り除
くためにチェックサム調整アルゴリズム[NAT]を走らせることによってＶ６
ＩＣＭＰヘッダから得られる必要があります。ノートは、調整はさらにＩＣ
ＭＰの運ぶペイロードのソースと宛先アドレス（とＮＡＰＴ−ＰＴの場合は
ポート番号）の更新の結果のチェックサムの変更を考慮しなければなりませ
ん。
6. FTP Application Level Gateway (FTP-ALG) Support
6. ＦＴＰアプリケーションレベルゲートウェイ（ＦＴＰ−ＡＬＧ）サポート
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.
ＦＴＰ制御セッションがペイロードにデータセッションのＩＰアドレスとＴ
ＣＰポート情報を伴うため、ＦＴＰ−ＡＬＧがこの人気が高いインターネッ
トアプリケーションにアプリケーションレベル透過性を提供するように要求
されます。
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.
旧式なＶ４ノード上で走っているＦＴＰアプリケーションで、FTPのPORTコ
マンドへの引数と（成功した）PASV回答の引数はＩＰｖ４アドレスとポート
番号を両方ともASCIIでh1,h2,h3,h4,p1,p2と示します。しかしながら、
[FTP-IPV6]はFTPでPORTとPASVコマンドの使用を止めるために、EPRTとEPSV
コマンド拡張を提案します。これらの拡張はV4かV6ノード上で使われるかも
しれません。ＦＴＰ−ＡＬＧは、Ｖ４とＶ６ノード間の透過的ＦＴＰ機能は、
次のように働きます。
6.1 Payload modifications for V4 originated FTP sessions
6.1 Ｖ４からのＦＴＰセッションのペイロード修正
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].
Ｖ４ホストがＦＴＰアプリケーションでEPRTとEPSVコマンド拡張を実装する
かもしれないし、しないかもしれません。もしＶ４ホストがＦＴＰセッショ
ンを作り、PORTかPASVコマンドを使うなら、ＦＴＰ−ＡＬＧはＶ６ノードに
それぞれを転送する前にこれらのコマンドをEPRTとEPSVコマンドに変換する
でしょう。同じく、Ｖ６ノードのEPSV回答が、Ｖ４ノードに転送する前に
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>)
EPSV回答フォーマット（肯定） ： 229 <拡張受動モードを
示すテキスト> (<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.
Ｖ４ノードからのPORTコマンドが、プロトコル<net-prt>フィールドをAF #2
(IPV6)にして、<net-addr>フィールドに（ h1,h2,h3,h4で表現される）Ｖ４
ホストアドレスをＮＡＴ−ＰＴの割当てたＶ６アドレスに変換し[V6ADDR]で
定義した文字列表記で設定することで、EPRTコマンドに変換します。PORTコ
マンドでp1,p2 p１と表記されるTCPポートが、EPRTコマンドでは１０進数
<tcp-port>で表記されなければなりません。さらに、<tcp-port>翻訳がＮＡ
ＰＴ−ＰＴの場合必要かもしれません。Ｖ４ノードからのPASVコマンドは、
<net-prt>引数をAF #2に設定することでEPSVコマンドに翻訳されます。Ｖ６
ノードからのEPSV回答が目標Ｖ４ホストに転送する前に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.
もしＶ４ホストがFTPセッションを作り、EPRTとEPSVコマンドを使っていたな
ら、ＦＴＰ−ＡＬＧはコマンド自身を変えないで、パラメータをこれらのコ
マンドに翻訳するでしょう。プロトコル番号<net-prt>フィールドはAF #1か
らAF #2に翻訳されるでしょう。<net-addr>はASCIIのＶ４アドレスから
[V6ADDR]で定義される表記のＮＡＴ−ＰＴ割り当てられたＶ６アドレスに翻
訳されるでしょう。EPSV 回答での<tcp-port>引数はＮＡＰＴ−ＰＴの場合で
だけ翻訳を必要とします。
6.2 Payload modifications for V6 originated FTP sessions
6.2 Ｖ６からのＦＴＰセッションのペイロード修正
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.
もしＶ６ホストがＦＴＰセッションを作るなら、ＦＴＰ−ＡＬＧは追跡する
２つの方法を持っています。最初の方法で、ＦＴＰ−ＡＬＧはコマンド文字
列"EPRT"と"EPSV"を変えず、<net-prt>と<net-addr>と<tcp-port>引数をＶ
６からＮＡＴ−ＰＴ（又はＮＡＰＴ−ＰＴ）の割当てたＶ４情報に翻訳する
でしょう。<tcp-port>はＮＡＰＴ−ＰＴの場合でだけ翻訳されます。Ｖ４ノー
ドからのEPSV回答も同様にします。これはRFC2428の前進的なサポートを保
証するために勧める方法です。しかしながら、この方法でＶ４ホストは、
Ｖ４とＶ６ホストのアクセスを許すためにＦＴＰアプリケーションがEPRT
とEPSV拡張をサポートする様にアップグレードされることを命じられます。
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.
２番目の方法では、ＦＴＰ−ＡＬＧはＶ６ノードからのコマンド文字列
"EPRT"と"EPSV"とパラメータを、対応するＮＡＴ−ＰＴの割当てたＶ４ノー
ド情報に翻訳し、"PORT"と"PASV"コマンドに設定しＶ４ノードに送ります。
同じく、Ｖ４ノードからのPASV回答がEPSV回答に翻訳されてＶ６ノードに送
られます。しかしながら、ＦＴＰ−ＡＬＧはＶ６ノードの出した
"EPSV<space>ALL"コマンドを翻訳することは不可能でしょう。このような場
合、コマンドを受け取るＶ４ホストはサポートされていない機能を示すエラー
コードを返すかもしれません。EPSVサポートがRFC2428で義務化されている
ので、このエラー回答は多くのRFC2428準拠ＦＴＰアプリケーションをただ
失敗させるかもしれません。この方法の利益は、Ｖ４ホストにＦＴＰアップ
グレードの条件を課さない事です。
6.3 Header updates for FTP control packets
6.3 ＦＴＰ制御パケットのヘッダ更新
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.
もしペイロード翻訳の結果が前のと同じならＴＣＰチェックサムだけが調整
を必要とします。もし前と異なっているなら、ＴＣＰシーケンス番号がＦＴ
Ｐ制御セッションペイロードの長さの変更を反映するために変えられるべき
です。Ｖ４ヘッダのＩＰパケット長さフィールドやＶ６ヘッダのＩＰペイロー
ド長フィールドが新しいペイロードサイズを反映するために変えられるべき
です。ＦＴＰ−ＡＬＧが双方向で制御パケットのＴＣＰヘッダのＴＣＰシー
ケンス番号と応答番号を直すために、表が使われます。
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.
表項目は、Ｖ４とＶ６のセッションのソースアドレスとソースデータポート
と宛先アドレスと宛先データポートと、外向きシーケンス番号差分と内向き
シーケンス番号差分を持つべきです。
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.
外向き制御パケットのシーケンス番号は、外行きシーケンス番号差分を加え
られ、同じパケットの応答番号からは内向きシーケンス番号差分が減算され
ます。同じく、内行きパケットのシーケンス番号に内向きシーケンス番号差
分が加算され、同じパケットの応答番号からは外向きシーケンス番号差分が
減算されます。
7. NAT-PT Limitations and Future Work
7. ＮＡＴ−ＰＴの限界と将来の仕事
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-TERM]はＮＡＴ−ＰＴでも同様です。ここ
にＮＡＴ−ＰＴ特有の重要な限界の詳細を記述します。
7.1 Topology limitations
7.1 トポロジー限界
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-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.
この限界がパケット翻訳を必要としないデュアルスタックノードからと宛て
のパケットに当てはまらないのに注意してください。これはデュアルスタッ
クの構成によるもので、Ｖ６アドレスから暗示されたＩＰｖ４アドレスはア
ドレスフォーマットPREFIX::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.
これは同じくＩＰｖ６からＩＰｖ６への通信にも影響がなく、そして実際に
他の通信手段がない時だけに翻訳を使うべきです。例えばＮＡＴ−ＰＴが同
じくネイティブのＩＰｖ６接続とある種のトンネルＩＰｖ６接続を持つかも
しれません。可能なら、上記の接続の両方が翻訳より優先されるべきです。
上記は、ＮＡＴ−ＰＴがネイティブのＩＰｖ６からＩＰｖ６けの通信への移
行を支援するために使われる道具であることを確かにします。
7.2 Protocol Translation Limitations
7.2 プロトコル翻訳限界
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].
多くのＩＰｖ４フィールドがＩＰｖ６で意味を変え、そして翻訳は簡単では
ありません。例えば、オプションヘッダの文法と意味はＩＰｖ６で際立って
変化しました。IPｖ４からＩＰｖ６へのプロトコル翻訳の詳細は[SIIT]にあ
ります。
7.3 Impact of Address Translation
7.3 アドレス翻訳の影響
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-TERM]
で完全に記述されます。
7.4 Lack of end-to-end security
7.4 エンドエンドセキュリティの欠如
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.
ＮＡＴ−ＰＴ提案の最も重要な限界の１つがエンドエンドネットワーク層セ
キュリティが可能でないという事実です。同じく転送アプリケーションレイ
ヤセキュリティがアプリケーションレイヤでＩＰアドレスを運ぶアプリケー
ションで可能ではないかもしれません。これはネットワークアドレス翻訳機
能の固有の限界です。
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.
ＮＡＴ−ＰＴと独立にエンドエンドＩＰｓｅｃセキュリティは異なったアド
レス領域で可能ではありません。ＩＰｓｅｃネットワークレベルセキュリティ
を求める２つのエンドノードはＩＰｖ４あるいはＩＰｖ６のどちらかを共通
にサポートしなくてはなりません。
7.5 DNS Translation and DNSSEC
7.5 ＤＮＳ翻訳とＤＮＳＳＥＣ
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.
４.２章で記述された案はＤＮＳメッセージの翻訳を伴います。この案がセ
キュアＤＮＳと両立できないことは明確です。すなわち、Ｖ６ドメインでの
正式なＤＮＳネームサーバーがＶ４世界から発する問合せの答えに署名する
ことができません。結果として、ＤＮＳ回答に署名を要求するＶ４エンドノー
ドがＮＡＴ−ＰＴによって不法に変更された答えを拒絶するでしょう。
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.
しかしながらいいニュースは、Ｖ４エンドノードが署名されていないＤＮＳ
回答のためにＶ６サーバーにアクセスしないかもしれないのに対し、ただＶ
４世界からアクセス可能である必要があるＶ６ドメインでのサーバーだけが
上記の制限に対応が必要だということです。
Also note that zone transfers between DNS-SEC servers within the same
V6 network are not impacted.
また、同じＶ６ネットワーク内のＤＮＳＳＥＣサーバの間のゾーン転送への
影響がないことに注意してください。
Clearly, with DNS SEC deployment in DNS servers and end-host
resolvers, the scheme suggested in this document would not work.
明らかに、ＤＮＳサーバとエンドホストリゾルバでのＤＮＳＳＥＣ配置で、
この文書で提案された案は働かないでしょう。
8. Applicability Statement
8. 適用性宣言
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.
ＮＡＴ−ＰＴは末端ネットワークの境界での貴重な移行ツールで、Ｖ６のみ
のネットワークがV４のみかＶ４とＶ６の両インターネットワークに接続す
るときに設置されます。
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 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.
ＤＮＳ−ＡＬＧとＮＡＴ−ＰＴの組合わせは、はＩＰｖ６エンドドメインと
ＩＰｖ４世界の双方向の接続性を供給し、ＩＰｖ６エンドドメインの外のＩ
Ｐｖ４ノードから始めるセッションを許します。これはＰｖ４世界に見える
サーバーを配置する必要があるＩＰｖ６だけのエンドネットワークでＮＡＴ−
ＰＴを有用にだけにします。
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.
あるアプリケーションがオペレーションのためにある程度のアドレス安定性
を当てにします。ＮＡＴ−ＰＴによるダイナミックなアドレス再利用がこれ
らのアプリケーションに快くないかもしれません。ホストがこのようなアド
レスクリティカルなアプリケーションを走らせる際に、ＮＡＴ−ＰＴはホス
トのＶ６アドレスと特定のＶ４アドレスの間に静的なアドレスのマッピング
を供給ように設定されるかもしれません。これはＮＡＴ−ＰＴによるアドレ
ス関連の変更が操作上の失敗の重要な原因にならないことを保証するでしょ
う。
9. Security Considerations
9. セキュリティの考慮
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.
この文書の７.４章が、ＮＡＴ−ＰＴが途中でセッションを捕える時に、エン
ドエンドネットワークと輸送層セキュリティが可能ではないと述べます。同
じくアプリケーションレイヤセキュリティがアプリケーションレイヤでＩＰ
アドレスを運ぶアプリケーションのために可能ではないかもしれません。
Section 7.5 of this document states that the DNS-ALG can not be
deployed in combination with secure DNS.
この文書の７.５章がＤＮＳ−ＡＬＧがセキュアＤＮＳと共に実装できないと
述べます。
Finally, all of the security considerations described in [NAT-TERM]
are applicable to this document as well.
最後に[NAT-TERM]で記述されたセキュリティの考慮のすべてが同様にこの文
書に適用できます。
10. REFERENCES
10. 参考文献
[DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A.
Heffernan, "DNS extensions to Network Address Translators
(DNS_ALG)", RFC 2694, September 1999.
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions",
RFC 2065, March 1999.
[FTP-IPV6] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for
IPv6 and NATs", RFC 2428, September 1998.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[NAT] Egevang, K. and P. Francis, "The IP Network Address
Translator (NAT)", RFC 1631, May 1994.
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC
2765, February 2000.
[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, April 1996.
[V6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
Authors' Addresses
著者のアドレス
George Tsirtsis
Internet Futures
B29 Room 129
BT Adastral Park
IPSWICH IP5 3RE
England
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.
Phone: (408) 519-3849
EMail: srisuresh@yahoo.com
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（Ｃ）インターネット学会（２０００）。すべての権利は保留される。
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。