Phase 2 Version1 2001/2/18 Version2j 2001/8/3 Version3j 2001/11/7 Version4j 2002/02/12 for -01.txt Version5j 2002/03/13 for -02.txt Version6j 2002/04/25 for -02_01.txt Version7j 2002/05/23 for -02_02.txt Version8j 2002/06/19 for -02_02.txt Version9J 2002/06/22 for -02_02.txt Version10J 2002/12/19 for -03.txt Kuniaki Kondo Intec NetCore, Inc. December 2002 Capsulated Network Address Translation with Sub-Address(C-NATS) 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などのアドレス変換技術を拡張し、任意のホスト間 で双方向で透過的通信を行うことを可能にするために、IPアドレスにサブアド レスを付加し、拡張する方法について定義する。 なお、ここで定義するサブアドレスを用いた拡張を以降NATS(Network Address Translation with Sub-Address)と呼ぶ。また、本ドキュメントで規定する方式 をC-NATS(Capsuled NATS)と呼ぶ。ただし、本ドキュメントにおいて'NATS'と表 現されるものは、特別な意味がない限りC-NATSを意味する。 2. Overview 　この文書で定義される拡張には、大きく３つの特徴がある。 　　a) （バックボーンネットワークのような）上位ネットワークに経路制御的 　　　 インパクトを与えない 　　b) 利用エリアを、ネットワークのエンドノードに限定している。 　　c) ホスト、ルータ共に実装が容易である。 つまり、NATSでは、エンドノードが上位ネットワークに接続される（ダイアル アップルータのような）ルータを含むエンドノードセグメントの機器とアプリケ ーションに軽微な変更を加えるだけであり、これ以外のバックボーンネットワー クのような高速性を要求される場面には、影響を与えない。 　この拡張は、IPアドレスに付加する形で、IPアドレス１つにつき32ビットのサ ブアドレス空間を持たせる。これらサブアドレスをIPv4ネットワークで一般的に 利用できるようにするため、ここでは、新しいUDPを利用したプロトコルを定義 する。 　プロトコルの設計に当たっては、NATS対応機器が未対応パケットを受信した場 合や未対応機器が対応パケットを受信した場合でも、これまでの通信に影響与え ないような互換性を重視して設計する。 　この実装により、仮にNATSを実装していないルータやホストでNATS対応パケッ トを受け取った場合でもそれらの機器には特別な処理を要求しない。 3. Sub-Address 　　Sub-Addressの空間は32bitの空間で指定される。 Sub-Addressの表記は、RFC1035[2]に記述されているIPv4の記法と同様に1オ クテットずつを'.'(ドット)で区切り、10進数で表現される。 　　ただし、以下のアドレスは予約されている。 　　0.0.0.0 : Unknown Sub-Address (USA) 4. パケットフォーマット 　NATSでは、IPv4で利用されているローカルネットワークに利用されているIP アドレスをサブアドレスとしてそのまま利用することができる。このため、 　The Internetを通過するすべてのNATSパケットはUDPを利用したトンネルのよ 　うに動作する。 　　この際のパケットフォーマットは至って単純であり、"IP in IP Tunneling" [1]をUDPを利用するように拡張したようなフォーマットとなる。 +---------------------------+ | Outer IP Header | +---------------------------+ | UDP Header | +---------------------------+ +---------------------------+ | IP Header | | Inner IP Header | +---------------------------+ ====> +---------------------------+ | | | | | IP Payload | | IP Payload | | | | | +---------------------------+ +---------------------------+ 　この際のUDPポート番号は、Source/Destination共にNNを利用する。 　上記に示したNATSにカプセル化されたパケットにおいてInner IP Headerの 　Source/Destination IP Addressは、本文書ではサブアドレスと定義される。 5. NATS制御パケット 　 NATSでは、ローカルネットワークに接続されたホストとNATSルータの間で NATSの制御情報等を交換する必要がある。 　　NATSルータでは、ローカル側インタフェースよりUDPのポート番号MMで ローカル側インタフェースをDestination Addressとして受信したパケットは 　このNATS制御パケットと識別し、以降に定義する処理を行う。 　　以下にNATS制御パケットのフォーマットを示す。 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 | | ..... | 　Typeフィールドは、NATS制御パケットのNATS Dataフィールドの情報の種類 　を示す。 　Type番号は以下のように管理される。 　　　0 - 127 : IANA Reserved 128 - 255 : Vendor Specific ただし、初期の割り当てとして以下の種別番号がある。 　　0: Reserve 1. 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. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type番号は1。 　　　 アドレス要求と応答で同一のフォーマットを用いる。 　　　 要求時、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で 　　　 埋められることとする。 2. NATS Support Confirmation NATSルータがローカルネットワーク内のホストにパケットを転送する際 　　　 に、転送先ホストがNATSをサポートしているかどうかを確認するために 　　　 利用する。 　　　 以下にパケットフォーマットを記述する。 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 | Confirm. Code |Confirmation ID| Return Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Typeは2. Confirmation Code: 0: Confirmation Request 1: Conftimation Answer Return Code: 0: NATS Not Supported 1: NATS Supported Confirmationの要求と応答で同一のフォーマットを用いる。 　　　 要求は、NATS対応ルータから転送先ホストに送られる。この際、NATS対 　　　 応ルータは、ルータ内で固有のConfirmation IDを割り当て、Confirmation IDフィールドに格納して送付しなくてはならない。 　　　 Confirmation IDは8ビット空間であり、0-255の間で任意に利用可能であ る。 Return Codeは、要求を受け取ったホストがNATS対応かどうかをルータに 　　　 応答するときに利用される。ルータが要求を送信する際、このフィールド 　　　 は0でクリアされていることとする。 　　　 NATSルータは、この要求によって得られた応答からホストがNATS対応か 　　　 否かを知った場合、パフォーマンス上の観点よりその情報を一定期間ル ータ内で保持することを推奨する。保持する期間は、任意であるが30分 　　　 をデフォルトとすることが望ましい。 　　　 NATSルータは、この要求を送信した場合、しばしばその応答を得られな 　　　 いことがある。このため、NATSルータは、要求に対する応答を一定時間 　　　 待ち、待機状態をExpireしてもよい。待機時間は任意であるが、15秒を 　　　 デフォルトとすることが望ましい。 　　　 待機時間を過ぎて受け取った応答は、破棄されるものとする。 6. アドレス表記 - 直接指定 !example.com は3章で規定される表記で表現することとする。 　　 参考：ホストが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. 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 address : 192.168.0.1 - NATS Router WAN I/F Address : 10.10.10.1 - Spool Address for NATS : 172.0.0.0/16 - Destination IPv4 Address : 10.0.0.1 - Destination Sub-Address : 192.168.0.100 　NATS non-support host NATS Router DNS Host A (Local Network) | | | | |DNS Query:Host A |DNS Query: 　　　| | |---------------------->| 'A'/'HINFO' RR 　　　 | | | 　 |---------------------->| | | | | | | | DNS Answer | | | | HINFO = | | | | '/SUBA:192.168.0.100!10.0.0.1/' | |<----------------------| | | DNS Answer(Assigned) | | | | A = 172.0.0.1 | | | | HINFO = | | | | '/SUBA:192.168.0.100!10.0.0.1/' | | |<----------------------| | | | | | |Dest = 172.0.0.1 | | |Src = 192.168.0.1 | | |---------------------->|Dest = 192.168.0.100!10.0.0.1| | |Src = 192.168.0.1!10.10.10.1 | | |---------------------------->| | | | | |Dest = 192.168.0.1!10.10.10.1| | |Src = 192.168.0.100!10.0.0.1 | | |<----------------------------| |Dest = 192.168.0.1 | | |Src = 172.0.0.1 | | |<----------------------| | | | | - Case 2: Pre-Specified Case - NATS non-support host address : 192.168.0.1 - NATS Router WAN I/F Address : 10.10.10.1 - Spool Address for NATS : 172.0.0.0/16 - Destination IPv4 Address : 10.0.0.1(example.com) - Destination Sub-Address : 192.168.0.100 　NATS non-support host NATS Router DNS Host A (Local Network) | | | | |DNS Query:Host A | 　 　　| | |(192.168.0.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 = 192.168.0.100!10.0.0.1| | |Src = 192.168.0.1!10.10.10.1 | | |---------------------------->| | | | | |Dest = 192.168.0.1!10.10.10.1| | |Src = 192.168.0.100!10.0.0.1 | | |<----------------------------| |Dest = 192.168.0.1 | | |Src = 172.0.0.1 | | |<----------------------| | | | | 8. アドレス変換 　　NATSルータでは、ローカルセグメントから受信したパケットおよびWANから 　受信したパケットに対して、適切にアドレス変換を行うことによって、エンド 　toエンド間の通信を提供する。 　　以下にアドレス変換の方法について記述する。 8.1 NATS対応ホストからの通信 8.1.1 NATS対応ホストがNATSの通信を行う条件 ホストは、コネクションの要求パケットを送出する際、以下の条件に合致す 　るときにパケットをNATSエンコードして送出しなければならない。 　　1. ホスト名をDNSから検索するとき、7章に記述した方法でIP Addressおよび 　　　 Sub-Addressを検索し、Sub-Addressが、USA以外で指定されている場合。 　　2. アプリケーションより直接、Sub-Addressが指定された場合。 また、ホストがNATSエンコードされたパケットによってコネクション要求を 　受け取った場合は応答は、NATSエンコードしたパケットで返さなくてはならな 　い。 　　ただし、NATSサポートホストが自Sub-Addressをもたない場合は、いかなる 　場合もNATSエンコードしたパケットを送出しない。 8.1.2 NATS対応ホストから送出するパケットのエンコーディング 　NATS対応ホストからNATSエンコーディングのパケットを送出する際には、 　NATSルータで行うようなカプセリング処理をホスト自身で行う必要がある。 　　ただし、Inner HeaderとOuter Headerの内容は、プロトコル番号とアドレス 　情報を除けば同一の値が利用できる。 　　以下にNATS対応ホストからNATSエンコーディングされたパケットを送出する 　際の留意点について記述する。 　　- Inner Header 　　　Source IP Address : 自ホストのI/F Address Destination IP Address : 送付先Sub-Address Other Header Value : 通常と同じ 　　- Outer Header Source IP Address : 自ホストのI/F Address Destination IP Address : 送付先IP Address 　　　Protocol Number : UDP Other Header Value : Inner Headerと同じ - UDP Header 第4章の規定による。 8.2 ローカルセグメントからのNATS未対応パケットの処理 　　NATS対応ルータがローカルセグメントよりNATSエンコーディングされて 　いないパケットを受信した場合、以下に定義する処理を行い、パケットを転送 　する。 　　- Destination IP Addressが７章で定義されているDNSフックメカニズムに 　　　よって発行されたSpool Addressの場合は、NATSエンコーディングされた 　　　パケットに変換して転送する。エンコーディング時に利用されるヘッダ 　　　情報は以下のとおり。 　　　- Inner Header Destination IP Address : Spool Addressに対応する送付先 Sub-Address Other Header Value : Originalと同じ 　　　- Outer Header Source IP Address : ルータのWAN側IP Address Destination IP Address : Spool Addressに対応する送付先 IP Address Protocol Number : UDP 　　　　TTL : OriginalのTTLから１減算したもの Other Header Value : Inner Headerと同じ - UDP Header 第4章の規定による。 - 上記に該当しない場合は、通常のNAPTの処理を実施し、転送する。 8.3 ローカルセグメントからのNATS対応パケットの処理 　　NATS対応ルータがローカルセグメントよりNATSエンコーディングされたパケ 　ットを受信した場合、NATSルータはOuter Headerに対して通常のNATの処理を 　促しパケットを転送する。この際、UDPポート番号の変換は行わない。 8.4 WANから受信したNATS対応パケットの処理 　　NATS対応ルータがWANインタフェースよりNATSエンコーディングされている 　パケットを受信した場合、受信したパケットのInner Headerにある Destination IP Address(Sub-Address)のホストをがNATS対応か否かによって 　動作を変える必要がある。 　　転送先のホストがNATS対応であるか否かは、5章で規定されるNATS Support Confirmationを利用して確認できる。 　　以下にそれぞれの場合の処理について記述する。 - 送付先がNATS未対応ホストの場合 　　　送付先がNATS未対応の場合は、NATSエンコードを解き、通常のIPパケット 　　　デコードした上で、送付先ホストに転送する必要がある。 　　　通常のIPパケットのヘッダ情報は以下のように変換される。 　　　Source IP Address : Outer HeaderのSource IP Address Destination IP Address : Inner HeaderのDestination IP Address TTL : Outer HeaderのTTLを１減算したもの 　　　Other Header Value : Inner Headerと同じ 　　- 送付先がNATS対応ホストの場合 　　　送付先がNATS対応の場合は、NATSエンコードされたパケットのまま転送す 　　　るが、一部のヘッダ情報の変換が必要である。 　　　以下に変換が必要なヘッダ情報を記述する。 　　　- Outer Header Destination IP Address : Inner HeaderのDestination IP Address (Sub-Address) Other Header Value : 変更なし 　　　- Inner Header 変更なし。 9. 実装上の推奨 NATSの実装に当たっては、ローカルセグメントとグローバルネットワークを 接続するゲートウエイルータとNATSの機能を利用するすべてのホストに実装さ れることが望ましい。しかし、NATSの機能を利用するすべてのホストに実装す ることは困難である。 　　このため、以下に記述する機器へ実装することによって、ホストへの実装を 最小限に抑える事ができる。 　　1. NATSの機能を利用するセグメントに接続されるすべてのゲートウエイルー タ 2. グローバルなセグメントに接続されており、NATSの機能を必要とするホ 　　　 スト 　　つまり、この段階でNATSルータで分断されているローカルネットワーク内の 　ホストへの実装は必須ではない。 　　また、ルータおよびホストへの実装にあたり、Get I/F AddressおよびNATS Support Confirmationの機能は、ルータ内に適切にサブアドレステーブルを持 　つことによって代用できるため、これらの機能についても実装は必須ではない。 10. UDP Port Number Considerations 本ドキュメントでは、NATSプロトコルを実現するために以下の２つのUDPポ 　ート番号を要求している。 　　1. NATSカプセリングされたデータパケットをやり取りするためのUDPポート。 　　　 NATS Data Portと呼ぶ。文書内ではNNとして表現されている。 　　2. NATSルータとホストの間でNATSに関連する制御情報をやり取りするため 　　　 に利用するUDPポート。 　　　 NATS Control Portと呼ぶ。文書内ではMMとして表現されている。 　　これら2つのポート番号は現在のところIANAから割り当てられていない。 11. 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. 12. 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ルータの実装を行っています。 　　- Products 　　　 製品としての実装は以下のものを予定しています。 　　　　- IIJ/SEIL - Edge Router Appendix 2: Mainling Linst NATSに関する議論は、下記のメーリングリストで行われています。 また、NATSに関する情報は、下記のホームページにまとめられています。 　 - メーリングリスト 　　　nats@nats-project.org - nats-ctl@nats-project.org宛てのメールの本体に、 　　　　　"subscribe "とかかれたメールを送付することで 　　　　　登録することができます。 　　　nats-j@nats-project.org (日本語) - nats-j-ctl@nats-project.org宛てのメールの本体に、 　　　　　"subscribe "とかかれたメールを送付することで 　　　　　登録することができます。 　 - ホームページ 　　　http://www.nats-project.org/ http://www.nats-project.org/index-h.html (日本語) Appendix 3: Address Family Enhancement for BSD socket interface NATS Project Team have been proposing following socket interface for NATS. #include int s; unsigned long ip, subip; struct sockaddr_ins ins; ins.sins_addr.s_addr = htonl(ip); ins.sins_addr.s_subaddr = htonl(subip); connect(s, (struct sockaddr *)&ins, sizeof(struct sockaddr_ins)); REFERENCES [1] W. Simpson, "IP in IP Tunneling", RFC1853, October 1995 [2] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" RFC1035, November 1987 [3] P. Srisuresh and M. Holdrege "IP Network Address Translator (NAT) Terminology and Considerations", RFC2663, August 1999 Authors' Address Kuniaki Kondo Intec NetCore, Inc. 1-3-3 Shinsuna, Koutou-ku, Tokyo, Japan Email: kuniaki@inetcore.com 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.