Phase 2 Version1 2001/2/18 Version2j 2001/8/3 Version3j 2001/11/7 Kuniaki Kondo IIJ November 2001 Capsuled 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 SAフィールドに指定されるSub-Addressに対する検索要求をおこなう。 　　　　- 指定するSub-Addressに割り当てられているIP Addressを知りたい 　　　　　場合 　　　　　　1. SAフィールドに指定のSub-Addressを格納し、IP Addressを 　　　　　　 0.0.0.0としてセグメント内にブロードキャストする。 2. 指定のSub-Addressを持つホストがそのパケットを受け取っ 　　　　　　　 た場合、そのホストは、IP Address部にそのパケットを受け 取ったインターフェースのIP Addressを格納して、送付元の ホストに送り返す。 　　　　- 指定するIP Addressに割り当てられているSub-Addressを知りたい 　　　　　場合 　　　　　　1. SAフィールドにUSAを格納し、IP Address部に指定のIP Address を格納して、IP Address部に指定されたIP Addressに向かって 　　　　　　　 要求を送付する 　　　　　　2. 指定のホストがそのパケットを受け取った場合、そのホストは、 　　　　　　　 SAフィールドに自分のSub-Addressを格納して、送付元ホストに 　　　　　　　 送り返す。 　　　　また、一般的にこの要求に対するタイムアウトは任意であるが、デフォ 　　　　ルトで30秒とすることが望ましい。 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 | 0x00 | SA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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検索要求をフックするメカニズムを示す。 　　NATS対応ルータでは、ローカルネットワーク(LN)からのDNSクエリをフック 　　する。理想的には、LN内からのDNSの向け先は、NATSルータとするが、そう 　　なっていない場合でも、NATS対応ルータを通過するDNSクエリはHookしなけ 　　ればならない。 　　LN内のホストからNATSルータがAレコードのDNSクエリを受信した場合、この クエリを代理でNATSルータがグローバルにあるDNSにクエリを発行する。こ のとき、AレコードおよびHINFOレコードのクエリを発行する。 　　NATSルータが発行したクエリの応答によりHINFOレコードが取得され、且つ 　　HINFOレコードに適切にIPアドレスとサブアドレスが記述されている場合、 　　該当ホストはNATS対応ホストと判定される。 DNS検索の結果、検索対象ホストがNATS対応ホストと判断される場合、NATS ルータは、NATS用に確保された仮想のIPアドレスを該当するクエリに対し 　　割り当て、この対をNATSルータ内に記憶する。NATSルータはその仮想のIP 　　アドレスをLN内から受けたAレコードDNSクエリの応答として返す。このとき 　　の応答パケットには、HINFOレコードの値も格納しておく。 　　この仕組みにより、LN内のNATS未対応ホストは外部のNATS対応ホストと通 　　信する際には、NATS対応ルータより返される仮想のIPアドレスをDestination アドレスとして接続を行う。この接続要求はNATSルータで適切なIPアドレス 　　に変換されると共に、サブアドレス付きのNATSパケットに変換され、グロ 　　ーバルネットワークに送信されることになる。 　　また、接続先ホストから返されるパケットをNATSルータが受信した場合、 そのソースアドレスは先に割り当てた仮想のIPアドレスに変換され接続元 ホストに返される必要がある。 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および Sub-Address Registrationの機能は、ルータ内に適切にサブアドレステーブル 　を持つことによって代用できるため、これらの機能についても実装は必須では ない。 9. IANA Considerations The Type Field value 0 - 2 are assigned in this document. Type Field value 3 - 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 TBD. 11. References RFC791: Internet Protocol. J. Postel. [STD0005] RFC768: User Datagram Protocol. J. Postel. [STD0006] RFC793: Transmission Control Protocol. J. Postel. [STD0007] 12. Author Information Kuniaki Kondo IIJ, Inc. 3-13 Kanda, Nishiki-Cho, Chiyoda-ku, Tokyo, Japan Email: kuniaki@iij.ad.jp 13. Full Copyright Statement