Phase 2 Version1 2001/2/18 Version2j 2001/8/3 Version3j 2001/11/7 Version4j 2002/02/12 for -01.txt Kuniaki Kondo IIJ February 2002 Capsulated Network Address Translation with Sub-Address(C-NATS) 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract 現在のIPv4アドレスを利用したネットワークにおいては、様々な理由からネッ トワークのエンドノードでNATなどのアドレス変換技術が多様されている。しか し、これらの技術は場合により、双方向での透過的通信に支障をきたす場合があ る。 　この文書では、これらNATなどのアドレス変換技術を拡張し、任意のホスト間 で双方向で透過的通信を行うことを可能にするために、IPv4アドレスにサブアド レスを付加し、拡張する方法について定義する。 なお、ここで定義するサブアドレスを用いた拡張を以降NATS(Network Address Translation with Sub-Address)と呼ぶ。また、本ドキュメントで規定する方式 をC-NATS(Capsuled NATS)と呼ぶ。ただし、本ドキュメントにおいて'NATS'と表 現されるものは、C-NATSを意味する。 2. Overview 　この文書で定義される拡張には、大きく３つの特徴がある。 　　a) （バックボーンネットワークのような）上位ネットワークに経路制御的 　　　 インパクトを与えない 　　b) 利用エリアを、ネットワークのエンドノードに限定している。 　　c) ホスト、ルータ共に実装が容易である。 つまり、NATSでは、エンドノードが上位ネットワークに接続される（ダイアル アップルータのような）ルータを含むエンドノードセグメントの機器とアプリケ ーションに軽微な変更を加えるだけであり、これ以外のバックボーンネットワー クのような高速性を要求される場面には、影響を与えない。 　この拡張は、IPv4アドレスに付加する形で、IPv4アドレス１つにつき16ビット のサブアドレス空間を持たせる。これらサブアドレスをIPv4ネットワークで一般 的に利用できるようにするため、ここでは、新しいトランスポートレイヤを定義 する。 　このトランスポートレイヤは、8オクテットのNATS制御部分と従来のトランス ポートレイヤをそのまま埋め込むためのTransport Data部分から構成される。 　プロトコルの設計に当たっては、NATS対応機器が未対応パケットを受信した場 合や未対応機器が対応パケットを受信した場合でも、これまでの通信に影響与え ないような互換性を重視して設計する。 　この実装により、仮にNATSを実装していないルータやホストでNATS対応パケッ トを受け取った場合でもそれらの機器には特別な処理を要求しない。 3. パケットフォーマット NATSでは以下のフォーマットを採用する。 NATS Header Format Protocol Number : N/A 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | NATS Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NATS Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transport Data | | ..... | 　NATSで利用するプロトコル番号については、いまだ決まっていない。 　Typeフィールド： Typeフィールドは、NATSヘッダのNATS Data部のデータの種類を指定 　　　　する。詳しくは、後述する。 4. Sub-Address空間 　　Sub-Addressの空間は16bitの空間で指定される。 　　ただし、以下のアドレスは予約されている。 　　0x0000 : Unknown Sub-Address (USA) 5. TypeごとのNATSヘッダフォーマット 　Type番号は以下のように管理される。 　　　0 - 127 : IANA Reserved 128 - 255 : Vendor Specific ただし、初期の割り当てとして以下の種別番号がある。 　　0: Sub-Address指定 通常のデータ通信を行なうときに必要となるSource Sub Address(SSA) とDestination Sub Address(DSA)を指定する。Dataフィールドフォーマ 　　　　ットは以下のとおり。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Transport Num| N/C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Sub-Address (SSA) | Destination Sub-Address(DSA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transport Data | | ..... | 　Transport Num.: Transport Numberは、NATSによってエンコードされるトランスポー 　　　　トプロトコル番号を指定する。 プロトコル番号については、IANAが管理する以下のURLを参照のこと。 http://www.iana.org/assignments/protocol-numbers 　　1: Sub-Address Discovery 本メッセージは、NATSルータからSub-Addressの情報を受け取ったり 　　　　Sub-Addressとローカルネットワーク内のIP Addressとのバインディング 　　　　情報を取得したりするのに利用される。 　　　　このため、本メッセージは、ローカルネットワーク内のホストから 　　　　NATSルータに対して要求が行われる。また、NATSルータは本メッセージ 　　　　を受け取った場合でも、送信元のホストがNATS対応ホストと判断しない。 　　　　ホストがNATS対応であるかどうかの判断は、Type 2の 　　　　Sub-Address Registrationのみによって行われる。 以下に、メッセージのフォーマットを示す。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Error Num. | SA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type番号は1. フォーマットで利用されるError Num.は以下のとおり。 　　　　　0x00 : No Error 0x01 : Unknown IP Address 0x02 : Unknown Sub-Address 　　　　本メッセージを受信したNATSルータは、メッセージ内に含まれる情報 　　　　によって以下に示す挙動を行う。 　　　　- SA = 0x00(USA) / IP Address = 0.0.0.0 NATSルータは、送信元ホストのIP Addressを元に対応するSub-Addressを 　　内部テーブルより検索し、その結果をSAフィールドおよびIP Address 　　フィールドに設定して応答する。 対応するIP Addressが見つからない場合、NATSルータは、Error Num. が0x01(Unknown IP Address)で送信元ホストに応答する。 　　　　- SA != 0x00(USA) / IP Address = 0.0.0.0 NATSルータは、SAフィールドに設定されているSub-Addressを 　　　　　　元に対応するIP Addressを内部テーブルより検索し、その結果を 　　　　　　IP Addressフィールドに設定し応答する。 　　　　　　対応するSub-Addressがない場合には、Error Num.が0x02 (Unknown Sub-Address)で応答する。 　　　　- SA = 0x00(USA) / IP Address != 0.0.0.0 NATSルータは、IP Addressフィールドに設定されているIP Address を元に対応するSub-Addressを内部テーブルより検索し、その結果を 　　　　　　SAフィールドに設定し応答する。 　　対応するIP Addressがない場合には、Error Num.が0x01(Unknown IP Address)で応答する。 　　　　また、一般的にこの要求に対するタイムアウトは任意であるが、デフォ 　　　　ルトで30秒とすることが望ましい。 2. Get I/F Address ホストがNATSルータのI/F Numフィールドに指定されるのIP Addressを 　　　 取得するために用いる。ただし、このメッセージをNATSルータが受け 　　　 取っても、送信元ホストがNATSをサポートしていると判断してはなら 　　　 ない。 　　　 このメッセージは主にNATSルータに割り当てれられている、WAN側 　　　 インタフェースのIP Addressを取得するために利用される。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | I/F Num. | Error Num. | N/C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type番号は2。 　　　 アドレス要求と応答で同一のフォーマットを用いる。 　　　 要求時、Error Num.とIP addressは、0x00でクリアされていることと 　　　 する。 　　　 I/F Num.は対象NATSルータが固有で持つI/F番号とする。一般にSNMP で用いられるI/F番号と同一なのが望ましい。 　　　 尚、I/F Numに OxFFが指定された場合は、デフォルトのインタフェー 　　　 スをさすこととする。 　　　 応答時は、これらすべてのフィールドが適切な値に設定されていなく 　　　 てはならない。 　　　 Error Num.フィールドでは、NATSルータでアドレスを取得するに際し 　　　 エラーが発生し、アドレスを通知できないときにその内容を通知する ために用いられる。エラー番号は以下の通り。 　　　　0: No Error 1: I/F Not Available 指定のI/F番号のインタフェースがNATSルータにない場合に 　　　　　　　用いられる。 2: I/F Not Enabled 　　　　　　　指定のI/FがNATSルータで有効になっていない場合に用い 　　　　　　 られる 3: I/F Not Active 　　　　　　　指定のI/Fにアドレスが割り当てられていないなど、通信が 　　　　　　　できない状態にあるときに用いられる。 4: System Error その他、システムに不具合があり、I/Fの情報が取得できな 　　　　　　　かった場合に用いられる。 　　　 尚、上記エラー１から４の場合、IP Addressフィールドは0x00で 　　　 埋められることとする。 3. Sub-Address Registration SAフィールドに指定されるSub-Addressのホストをルータに通知する。 　　　 ホストは、起動時、もしくはIP Addressが変更になった場合に、この 　　　 パケットを使って、ルータにNATSのサポートホストであることを通知 　　　 する。 Reg.Typeは、0が登録、1が削除である。 　　　 Reg.Typeが0でホストがルータにNATSサポートホストであることを通知 　　　 する際に、ホストがSub-Addressを知らない場合には、SAフィールドに 　　　 USAを指定する。この際、ルータでは、適当なSub-Addressを該当ホスト 　　　 に割り当て、Reg.Typeが3(Assignment)とし、SAフィールドに割り当て たSub-Addressを格納してホストにSub-Addressを通知する。 　　　ホスト終了時などの 　　　 Sub-Addressを開放してよい場合にReg.Typeが1であるパケットを送付 　　　 する。このときのExpire Timeは0(Zero)とする。 　　　 また、SAフィールドがUSA以外の場合には、Expire Timeを指定する必要 　　　 がある。Expire Timeが0の場合は、Default値として1800が指定された 　　　 ものとする。なお、このフィールドの単位は秒である。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reg.Type | SA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expire Time | N/C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Typeは3. Reg.Type : Registration Type 0: Add 1: Delete 2: Assignment 　　　　　　3: Expired ホスト、もくはルータはExpire Timeを管理し、もしSub-Addressの保持時 間がExpireした場合には、ホストはルータに、ルータはホストにReg.Typeが 　　　3(Expired)のパケットを使ってExpireを通知する。 　　　通知を受けたノードは、Reg.Typeが2(Assignment)のパケットを使って継続 を要求することができる。継続ができない場合、SAフィールドにはUSAを格 納して応答する。 　　　継続が拒否された場合、起動時と同じ手順で再度Sub-Addressを獲得する必 　　　要がある。 6. アドレス表記 - 直接指定 !example.com は10進数表記で表現することとする。 　　 参考：ホストがNATS未対応の場合、名前解決の際、FQDNが "!example.com"のアドレスを検索しようとする。この際、DNS 　　　　　 のAレコードに "!example.com"のエントリが解決できるように 　　　　　 設定しておくことで、アクセス対象となるNATSセグメントのゲートウ 　　　　　 エイアドレスが解決できる。これは実質的な解決ではないが、接続の 　　　　　 要求を可能な限り努力するという観点では非常に重要であるため、 NATS拡張のホストをDNSにエントリする際には、このような登録をし 　　　　　 ておくことを推奨する。 　- 名前指定 名前によるアドレス解決は通常のDNSを利用して行なわれる。 　　 DNSでのSub-Addressの解決にHINFOを利用する。HINFOフォーマットは以下の 　　 通り。 　　 hostname HINFO "/SUBA:!/" "" '/SUBA:'から'/'の区間にかかれた受信表示がNATSで利用されるアドレスを表 現し、はSub-Addressを、はIPv4アドレスを表現す る。については、FQDNでの記述がゆるされ、その場合、ホスト側 では、Aレコードを再度検索し、そのアドレスに対して適切な動きをしなくて はならない。 　　 指定部以外の部分は無視されることとする。また、この区間はHINFO内で表現 される文字列のいかなる部分にあっても良いこととする。 　　 HINFOリソースフィールドは、CPU情報とOS情報の２つのフィールドに分かれ 　　 ているが、サブアドレス情報はどちらかに上記フォーマットで記述されてい 　　 れば有効となり、２回以上の指定が合った場合には、最初に指定されたサブ 　　 アドレスが有効となる。 7. 挙動 7.1 ホスト ホストは、コネクションの要求パケットを送出する際、以下の条件に合致す 　るときにパケットをNATSエンコードして送出しなければならない。 　　1. ホスト名をDNSから検索するとき、6章に記述した方法でIP Addressおよび 　　　 Sub-Addressを検索し、Sub-Addressが、USA以外で指定されている場合。 　　2. アプリケーションより直接、Sub-Addressが指定された場合。 また、ホストはNATSエンコードされたパケットによってコネクション要求を 　受け取った場合はの応答は、NATSエンコードしたパケットで返さなくてはなら 　ない。 　　ただし、NATSサポートホストが自Sub-Addressをもたない場合は、いかなる 　場合もNATSエンコードしたパケットを送出しない。 7.2 ルータ 7.2.1 NATSルータに必要な機能 NATSルータは、ルータ内にセグメント内で利用するIP Addressとそのアドレ 　スに対応するSub-Addressのテーブルを保持する必要がある。 仮に、セグメント内から受信したNATSエンコードされたパケットのSSAが既 にルータ内にあるテーブルと一致しない場合は、受信したパケットの Sub-Addressが有効なものとして処理する。 7.2.2 NATSルータによるDNSフックメカニズム NATSルータでは、ローカルセグメントにNATS未対応ホストがつながれている 場合でも極力NATSの効果を発揮できるようにするためにホストからのDNS検索 要求をフックするようなメカニズムを導入する事が望ましい。 以下にDNS検索要求をフックするメカニズムを示す。 　1)NATS対応ルータでは、ローカルネットワーク(LN)からのDNSクエリをフック 　　する。理想的には、LN内からのDNSの向け先は、NATSルータとするが、そう 　　なっていない場合でも、NATS対応ルータを通過するDNSクエリはHookしなけ 　ればならない。 　2)LN内のホストからNATSルータがAレコードのDNSクエリを受信した場合、この クエリを代理でNATSルータがグローバルにあるDNSにクエリを発行する。こ のとき、AレコードおよびHINFOレコードのクエリを発行する。 ただし、クエリが"!"型の場合、HINFOは検索せず、 　　のAレコードのクエリのみを発行し、対象ホストはNATS対応ホス 　　トと判定され、下記4)以降の処理を実施する。 　3)NATSルータが発行したクエリの応答によりHINFOレコードが取得され、且つ 　　HINFOレコードに適切にIPアドレスとサブアドレスが記述されている場合、 　　該当ホストはNATS対応ホストと判定される。 4)DNS検索の結果、検索対象ホストがNATS対応ホストと判断される場合、NATS ルータは、NATS用に確保された仮想のIPアドレスを該当するクエリに対し 　　割り当て、この対をNATSルータ内に記憶する。NATSルータはその仮想のIP 　　アドレスをLN内から受けたAレコードDNSクエリの応答として返す。このとき 　　の応答パケットには、HINFOレコードの値も格納しておく。 　この仕組みにより、LN内のNATS未対応ホストは外部のNATS対応ホストと通 　信する際には、NATS対応ルータより返される仮想のIPアドレスをDestination アドレスとして接続を行う。この接続要求はNATSルータで適切なIPアドレス 　に変換されると共に、サブアドレス付きのNATSパケットに変換され、グロ 　ーバルネットワークに送信されることになる。 　また、接続先ホストから返されるパケットをNATSルータが受信した場合、 そのソースアドレスは先に割り当てた仮想のIPアドレスに変換され接続元 ホストに返される必要がある。 これらの様子を下図に示す。 - Case 1: Normal Case 　NATS non-support host NATS Router DNS Host A (Local Network) | | | | |DNS Query:Host A |DNS Query: 　　　| | |---------------------->| 'A'/'HINFO' RR 　　　 | | | 　 |---------------------->| | | | | | | | DNS Answer | | | | HINFO = | | | | '/SUBA:100!10.0.0.1/'| | | |<----------------------| | | DNS Answer(Assigned) | | | | A = 172.0.0.1 | | | | HINFO = | | | | '/SUBA:100!10.0.0.1/'| | | |<----------------------| | | | | | |Dest = 172.0.0.1 | | |Src = 192.168.0.1 | | |---------------------->|Dest = 100!10.0.0.1 | | |Src = 50!192.168.100.1 | | |---------------------------->| | | | | |Dest = 50!192.168.100.1 | | |Src = 100!10.0.0.1 | | |<----------------------------| |Dest = 192.168.0.1 | | |Src = 172.0.0.1 | | |<----------------------| | | | | - Case 2: Pre-Specified Case 　NATS non-support host NATS Router DNS Host A (Local Network) | | | | |DNS Query:Host A | 　 　　| | |(100!example.com) | | | |---------------------->|DNS Query: 'A' RR 　 | | | 　 |---------------------->| | | | | | | | DNS Answer | | | | A = 10.0.0.1 | | | |<----------------------| | | DNS Answer(Assigned) | | | | A = 172.0.0.1 | | | |<----------------------| | | | | | | |Dest = 172.0.0.1 | | |Src = 192.168.0.1 | | |---------------------->|Dest = 100!10.0.0.1 | | |Src = 50!192.168.100.1 | | |---------------------------->| | | | | |Dest = 50!192.168.100.1 | | |Src = 100!10.0.0.1 | | |<----------------------------| |Dest = 192.168.0.1 | | |Src = 172.0.0.1 | | |<----------------------| | | | | 7.2.3 NATS対応ルータの挙動 - WAN側よりNATS対応パケットを受信した場合、内部のテーブルを参照し、適 切なホストにパケットを転送する。 　　この際、転送先ホストがNATS未対応の場合、ルータではNATSヘッダを取り除 き、NATS未対応のパケットにデコードして転送する必要がある。 　　NATS対応・未対応の判定は、指定のホストがSub-Address Registrationによ ってルータにそのホストが登録されているか否かで判定することができる。 　　指定のSub-Addressに対応するホストが見つからない場合、ルータは、 Sub-Address DiscoveryによりDSAに指定されているホストの検索を試みる。 指定されたSub-Addressをローカルネットワーク内から検索する為の Sub-Address Discoveryは一般には15秒でタイムアウトする事とする。 　　タイムアウトした場合、送信元ホストに対して 　　ICMP_UNREACH/ICMP_UNREACH_HOST_UNKNOWNを返すこととする。 　- WAN側よりNATS未対応パケットを受信した場合、そのパケットはDefault Host に指定されたホストに転送する。しかし、Default Hostの指定がない場合は、 送信元ホストに対してICMP_UNREACH/ICMP_UNREACH_HOST_UNKNOWNを返すこと 　　とする。 　- LAN側よりNATS対応パケットを受信した場合、そのパケットはNATS対応パケ ットのままターゲットホストに転送される。このとき、ルータはIPv4ソース アドレスをWAN側のアドレスに変更してパケットを送出しなくてはならない。 　- LAN側よりNATS未対応パケットを受信した場合、そのパケットはNATS未対応 　　パケットのまま、ターゲットホストに向けて転送される。このとき、ルータ はIPv4ソースアドレスをWAN側のアドレスに変更してパケットを送出しなく てはならない。 ただし、NATSルータにDNS検索フック機構が実装されており、受信したパケ ットのDestinationアドレスがNATSルータより割り当てられたNATS用スプー ルアドレスだった場合、NATSルータはスプールアドレスに関連付けされてい る適切なサブアドレスとIPアドレスでNATSパケットを構成して転送しなくて はならない。 また、このDNS検索フック機能を利用してローカルネットワークから接続さ れたセッションの場合、WAN側より受信したSource Addressを先に割り当て たNATS用スプールアドレスに変換して転送先ホストにパケットを送らなくて はならない。 8. 実装上の推奨 NATSの実装に当たっては、ローカルセグメントとグローバルネットワークを 接続するゲートウエイルータとNATSの機能を利用するすべてのホストに実装さ れることが望ましい。しかし、NATSの機能を利用するすべてのホストに実装す ることは困難である。 　　このため、以下に記述する機器へ実装することによって、ホストへの実装を 最小限に抑える事ができる。 　　1. NATSの機能を利用するセグメントに接続されるすべてのゲートウエイルー タ 2. グローバルなセグメントに接続され、NATSの機能を有するセグメント内の ホストへ接続するすべてのホスト 　　つまり、この段階でNATSルータで分断されているローカルネットワーク内の 　ホストへの実装は必須ではない。 　　また、ルータおよびホストへの実装にあたり、Sub-Address Discovery、 　Get I/F AddressおよびSub-Address Registrationの機能は、ルータ内に適切に サブアドレステーブルを持つことによって代用できるため、これらの機能につい ても実装は必須ではない。 9. IANA Considerations The Type Field value 0 - 3 are assigned in this document. Type Field value 4 - 127 for extended-type are to be assigned by IANA, using the "First Come First Served" policy defined in RFC2434. Type values 128 - 255 for extended types are for vendor-specific types, and values in this range are not to be assigned by IANA. 10. Acknowledgements Thanks to Toshiya Asaba, Ikuo Nakagawa, Ryo Shimizu, Kiyoshi Ishida, Tomokazu Takizawa, Masahiko Tsuda, Junichi Watanabe and Susan Harris for their comments. Appendix 1: Implementations(実装) NATSの実装は、以下の予定で開発されています。 　　- Linux RedHad Linux上でNATSホストおよびNATSルータの実装を行っています。 　　　 3月にテストバージョンをリリース予定です。 　　- Products 　　　 製品としての実装は以下のものを予定しています。 　　　　- IIJ/SEIL - SOHO Router Appendix 2: Mainling Linst NATSに関する議論は、下記のメーリングリストで行われています。 また、NATSに関する情報は、下記のホームページにまとめられています。 　 - メーリングリスト 　　　nats@nats-project.org - nats-ctl@nats-project.org宛てのメールの本体に、 　　　　　"subscribe "とかかれたメールを送付することで 　　　　　登録することができます。 　 - ホームページ 　　　http://www.nats-project.org/ http://www.nats-project.org/index-h.html (日本語) REFERENCES [1] P. Srisuresh and M. Holdrege "IP Network Address Translator (NAT) Terminology and Considerations", RFC2663, August 1999 Authors' Address Kuniaki Kondo IIJ, Inc. 3-13 Kanda, Nishiki-Cho, Chiyoda-ku, Tokyo, Japan Email: kuniaki@iij.ad.jp Full Copyright Statement Copyright (C) The Internet Society (2002). 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.