Phase 2 Version1 2001/2/18 Kuniaki Kondo IIJ November 2001 Network Address Translation with Sub-Address(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[1]などのアドレス変換技術が多様されている。しか し、これらの技術は場合により、双方向での透過的通信に支障をきたす場合があ る。 　この文書では、これらNATなどのアドレス変換技術を拡張し、任意のホスト間 で双方向で透過的通信を行うことを可能にするために、IPv4アドレスにサブアド レスを付加し、拡張する方法について定義する。 なお、ここで定義するプロトコルを以降NATS(Network Address Translation with Sub-Address)と呼ぶ。 2. Overview 　この文書で定義される拡張には、大きく３つの特徴がある。 　　a) 利用エリアを、ネットワークのエンドノードに限定している。 　　b) ホスト、ルータ共に実装が容易である。 つまり、NATSでは、エンドノードが上位ネットワークに接続される（ダイアル アップルータのような）ルータを含むエンドノードセグメントの機器とアプリケ ーションに軽微な変更を加えるだけである。 　この拡張は、IPv4アドレスに付加する形で、IPv4アドレス１つにつき16ビット のサブアドレス空間を持たせる。このサブアドレス空間は、IPv4アドレスと同様 に、ソースアドレスとディスティネーションアドレスをもち、これらをIPv4パケ ットのオプションフィールドに挿入することで実現する。 　この実装により、仮にNATSを実装していないルータやホストでNATS対応パケッ トを受け取った場合でもそれらの機器には特別な処理を要求しない。 　プロトコルの設計に当たっては、NATS対応機器が未対応パケットを受信した場 合や未対応機器が対応パケットを受信した場合でも、これまでの通信に影響与え ないような互換性を重視して設計する。 3. NATSの認識 　NATSによるサブアドレスの認識は、IPv4パケットのOptionフィールドを検査し なくてはならない。ただし、バックボーンルータのような場面においては、特に この部分を気にする必要はなく、従来のIPv4プロトコルに規定される動作を行え ば問題ない。オプションにNATSのオプションが付加されていなければ、通常の IPv4として利用し、NASTオプションが付加されていればNATSパケットと認識して、 以降に定義する挙動をしなくてはならない。 4. IP Option Header Format Copied Flag : copied : 1 Option Class : Control : 0 Option Numebr : Not Defined : N/A Option Length : Fixed : 8 Octets - Optionフォーマット 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 100nnnn | 00001000 | Type | N/C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N/C: Not Care: 通常は0x00を指定する。 4.1 Typeフィールド Typeフィールドは、NATSのOptionヘッダのDataフィールドの種類を指定する。 Typeフィールドに指定できる値は以下のとおり。 　　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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSA | DSA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 　　1: Sub-Address Discovery SAフィールドに指定されるSub-Addressに対する検索要求をおこなう。 　　　　このパケットは、特定セグメント内にブロードキャストされる。 セグメント内のすべてのホストのSub-Addressをすべて知りたい場合は 　　　　SAフィールドをUSAにして送出する。 　　　　ホストは、要求メッセージ送出後、その応答を指定されるexpire time だけ待たなくてはならない。このexpire timeはデフォルトで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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA | N/C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2: Sub-Address Response 　　　　"Sub-Address Discovery"に対する応答を返す。 　　　　"Sub-Address Discovery"によって送出されるブロードキャストパケッ 　　　　トが自ホストに割り当てられているSub-Addressだった場合、この応答 をSource Addressに対して返答する。 SSAフィールドには自ホストのSub-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA | N/C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 特殊なSub Address Sub-Addressは16ビットで構成され、0〜65535の値が利用できますが、特殊 　なアドレスとして、以下のアドレスが予約されている。 0x0000 : Unknown Sub Address (USA) 6. 挙動 6.1 ホスト ホストは、コネクションの要求パケットを送出する際、以下の条件に合致す 　るときにNATSオプションヘッダを追加して送出しなければならない。 　　1. ホスト名をDNSから検索するとき、6章に記述した方法でIP Addressおよび 　　　 Sub-Addressを検索し、Sub-Addressが、USA以外で指定されている場合。 　　2. アプリケーションより直接、Sub-Addressが指定された場合。 また、ホストはNATS対応のパケットによってコネクション要求を 　受け取った場合はの応答は、NATS対応のパケットで返さなくてはなら 　ない。 　　ただし、NATSサポートホストが自Sub-Addressをもたない場合は、いかなる 　場合もNATSエンコードしたパケットを送出しない。 6.2 ルータ 6.2.1 NATSルータに必要な機能 NATSルータは、ルータ内にセグメント内で利用するIP Addressとそのアドレ 　スに対応するSub-Addressのテーブルを保持する必要がある。 仮に、セグメント内から受信したNATSエンコードされたパケットのSSAが既 にルータ内にあるテーブルと一致しない場合は、受信したパケットの Sub-Addressが有効なものとして処理する。 6.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アドレスに変換され接続元 ホストに返される必要がある。 6.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用スプールアドレスに変換して転送先ホストにパケットを送らなくて はならない。 7. アドレス表記 - 直接指定 !example.com は10進数表記で表現することとする。 　　 参考：ホストがNATS未対応の場合、名前解決の際、FQDNが "!example.com"のアドレスを検索しようとする。この際、DNS 　　　　　 のAレコードに "!example.com"のエントリが解決できるように 　　　　　 設定しておくことで、アクセス対象となるNATSセグメントのゲートウ 　　　　　 エイアドレスが解決できる。これは実質的な解決ではないが、接続の 　　　　　 要求を可能な限り努力するという観点では非常に重要であるため、 NATS拡張のホストをDNSにエントリする際には、このような登録をし 　　　　　 ておくことを推奨する。 　- 名前指定 名前によるアドレス解決は通常のDNSを利用して行なわれる。 　　 DNSでのSub-Addressの解決にHINFOを利用する。HINFOフォーマットは以下の 　　 通り。 　　 hostname HINFO "/SUBA:!/" "" '/SUBA:'から'/'の区間にかかれた受信表示がSub-Addressを表現し、それ以 　　 外の部分は無視されることとする。また、この区間はHINFO内で表現される文 　　 字列のいかなる部分にあっても良いこととする。 　　 HINFOリソースフィールドは、CPU情報とOS情報の２つのフィールドに分かれ 　　 ているが、サブアドレス情報はどちらかに上記フォーマットで記述されてい 　　 れば有効となり、２回以上の指定が合った場合には、最初に指定されたサブ 　　 アドレスが有効となる。 　　 ホスト側では、指定の名前をDNSで検索しHINFOを参照することにより、IP AddressとSub-Addressを解決できることとなる。 8. Acknowledgements TBD. 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 (2001). 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.