JP4236364B2 - 通信データ中継装置 - Google Patents
通信データ中継装置 Download PDFInfo
- Publication number
- JP4236364B2 JP4236364B2 JP2000102702A JP2000102702A JP4236364B2 JP 4236364 B2 JP4236364 B2 JP 4236364B2 JP 2000102702 A JP2000102702 A JP 2000102702A JP 2000102702 A JP2000102702 A JP 2000102702A JP 4236364 B2 JP4236364 B2 JP 4236364B2
- Authority
- JP
- Japan
- Prior art keywords
- domain
- relay
- address
- destination
- communication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/04—Interdomain routing, e.g. hierarchical routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/2514—Translation of Internet protocol [IP] addresses between local and global IP addresses
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/2521—Translation architectures other than single NAT servers
- H04L61/2535—Multiple local networks, e.g. resolving potential IP address conflicts
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワークの中継装置に関する。
【０００２】
【従来の技術】
（ドメインの概念）
従来からルーティングドメインとは、１以上のネットワークからなり、一つ以上の互いに協調する経路制御プロトコルにより管理され、その経路情報によりネットワーク層パケットが到達可能な範囲と定義されていた。例えば、インターネットはさまざまな経路制御プロトコルが動作している複数のネットワークから構成されている。このため、インターネットは１つのルーティングドメインである（以下ルーティングドメインを単にドメインと省略する）。
【０００３】
今日まで、多くの企業が自社の情報インフラとしてインターネットの技術を用いた企業内網を構築してきた。こうしたネットワークにおいては、企業の秘密を守るため、あるいは外部からの妨害を避けるため、インターネットとの間にファイアウォール装置が配置されていた。このファイアウォール装置により、インターネットとの間の通信が監視・制限されていた。こうしたネットワークではセキュリティ上の理由から、企業内網の内部経路をインターネットに配布しないのが一般的であった。また、IPv4アドレスが不足しているため、企業内網でプライベートアドレスを用いるのが一般的であった。
【０００４】
プライベートアドレスは企業ユーザが自由に利用できるインタネットアドレスの範囲である。しかし、インターネットにこれらの経路を配布することは禁止されていた。そのため、プライベートアドレスを使用する企業内網は、インターネットとは直接通信できなかった。したがって、企業内網はインターネットとは独立したドメインである。
【０００５】
こうした企業内網が、インターネットと通信するためにはNAT（IP Network Address Translator）装置を使用する必要があった。NAT装置は、プライベートアドレスを持つパケットをグローバルアドレスで経路制御されるインターネットに通すために、両ドメイン境界においてパケットに付されたプライベートアドレスをグローバルアドレスに変換する。
【０００６】
さらに、企業内網構成の複雑化、ルータ機能の多様化に対応するため、ルータ装置がNAT機能を持つようになった（以下これをNATルータという）。このようなルータ装置は、二つのドメインを管理することができた。
【０００７】
このような状況において、プライベートアドレスによるドメイン（以下プライベートアドレスドメインという）からグローバルアドレスによるドメイン（以下グローバルアドレスドメインという）への通信は、以下のように行われていた。
【０００８】
すなわち、プライベートアドレスドメイン内の各ルータにおいて、宛先アドレスが企業内網内部以外であるパケットを全てNATルータへ送信するように、デフォルト経路が設定された。これにより、グローバルアドレスドメイン宛のパケットをドメイン境界に置かれた中継装置（以下ドメイン境界中継装置という）に送ることが可能であった。
【０００９】
中継装置は、プライベートアドレスドメインの経路情報をグローバルアドレスドメインへ流さないが、グローバルアドレスドメインから得た経路情報をプライベートアドレスドメインへ流す。これにより、プライベートアドレスドメイン内の各ホスト（ノード）は、グローバルアドレスドメイン宛のパケットを中継装置に送ることが可能であった。
【００１０】
ドメイン境界中継装置は、グローバルアドレスドメインから受け取った経路情報から、グローバルアドレスドメイン内の次ホップルータを知る（実際には、中継装置において、デフォルトルートとして外部ルータが指定してされている場合もある）。こうして、ドメイン境界中継装置は、グローバルアドレスドメインへ向いたインタフェースへパケットを中継できた。このとき、実際にはドメイン境界中継装置は、中継する前にパケットのアドレスを変換した。
【００１１】
アドレス変換にはいくつかの方法があった。例えば、まず、ドメイン境界に置かれた中継装置がグローバルアドレスをいくつかプールしておく。このドメイン境界中継装置は、到着したパケットのプライベートアドレスである送信元アドレスをプールしてあるグローバルアドレスの一つと置きかえる（以下このアドレスをエイリアスアドレスという）。
【００１２】
次に、このドメイン境界中継装置が、あたかもグローバルアドレスドメイン内の送信ホストであるかのように送信する。このとき、ドメイン境界中継装置は、置き換えた送信元アドレスとそのエイリアスアドレスの対応を記録する。そして、ドメイン境界中継装置が、グローバルアドレスドメインから送信したパケットに対する応答トラフィックを受信したとき、プライベートアドレスドメイン内の本来の送信ホストへ中継する。
【００１３】
また、プライベートアドレスドメインからグローバルアドレスドメインへ送信したパケットに対する応答パケットが返ってきた場合、宛先アドレスは上記エイリアスアドレスである。つまり、グローバルアドレスドメインにおいてはパケットの送信元が中継装置のエイリアスアドレスである。このため、ドメイン境界中継装置は、先のプライベートアドレスとグローバルアドレスとの変換テーブルを参照し、パケットの宛先アドレスをプライベートアドレスドメインの送信元アドレスに変換できる。こうして、ドメイン境界中継装置は、返信パケットをプライベートアドレスドメインへ接続されたインタフェースへと中継する。
【００１４】
以上のようなアドレス変換機能により両ドメイン間の通信が可能であった。フォワード方向の通信では宛先ドメインにおける経路テーブルが必要であった。一方、プライベートアドレスとグローバルアドレスの変換テーブルにフォワード方向パケットを受信したインタフェースも併せて記録しておけば、中継装置は、バックワードのパケットをその受信インターフェースへ転送すればよい。その際、送信元ドメインの経路情報を検索し、プライベートアドレスドメインにおける次ホップルータを決定し、上記インターフェースへ転送する。
【００１５】
従来、ドメイン境界中継装置は、複数のルーティングプロトコルを終端する経路制御プログラムとただ一つの経路テーブルを有していた。なお、ここでいう経路テーブルとはパケット中継時に出力インタフェースと次ホップルータとを決定するために検索するテーブルを指す。
【００１６】
従来の中継装置は、このような複数のルーティングプロトコルによって知り得た経路情報を相互に混合するか否かという管理上の制御を行っていた。しかし、相互に混合する場合、従来の中継装置では、このような複数のルーティングプロトコルから知り得た経路情報を全て同一の経路テーブルに書き込んでいた。つまり、プライベートアドレスドメインとグローバルアドレスドメイン境界の中継装置は、各ドメインから知り得た経路情報を一つのテーブル内で管理していた。
（Lucent Technologies社のIP Navigatorの例）
図１９にLucent Technologies社のIP Navigatorの処理概要を示す。IP Navigatorは複数のルーティングテーブルをサポートする通信プログラムであった。IP navigatorはISP(Internet Sevice Provider)向けのMPLS(MultiProtocol Label Switching)プロトコルを実装する中継装置（以下ルータという）上で動作した。
【００１７】
このIP navigatorは、LSR（ラベル・スイッチ・ルータ）において、複数の経路テーブル毎に、各ルータ間を接続するLSP（ラベル・スイッチ・パス）を対応付けることでISP（インターネット・サービス・プロバイダ）ネットワークをパーティションに分割した。そして、IP navigatorは、それぞれのパーティションを企業ユーザなどにプライベートネットワークとして提供することを目的としていた。この方式では複数のドメインに対してそれぞれ経路テーブルを持った。ただし、この方式では、任意の組み合わせのドメインが互いにアドレス変換機能を介して、通信することはできなかった。
（IPv6ルータの実装）
現在まで、代表的なネットワーク層プロトコルとしてIPプロトコル（IPversion4、以下IPv4という）が用いられてきた。さらに、IPアドレスの枯渇に対応するため、IPプロトコルの新バージョン(IPversion6、以下IPv6という)が登場した。今日、IPv4とIPv6とは混在している。一般的には、このIPv4のドメインとIPv6のドメインとは、アドレス変換装置を用いて互いに通信する。両ドメインに対応するルータとして、IPv4経路テーブルを持つIPv4ドメインとIPv6の経路テーブルを持つIPｖ6ドメインとをアドレス変換により通信可能とするものがあった（株式会社日立製作所NR60など）。
【００１８】
このようなルータは、IPv4,v6という二つのドメインに対しては複数の経路テーブルを持ち、両者の間でアドレス変換による通信が可能であった。しかし、ユーザがIPアドレス空間にさらにドメインを定義し、二つ以上のドメイン間をアドレス変換によって自由に接続することはできなかった。
（片方向NAT）
図２０に片方向NATの概要を示す。片方向NATは、プライベートアドレスとグローバルアドレスのように、ドメイン１の経路情報をドメイン２に配布できないという条件下で通信を実現した。ドメイン１はドメイン２への経路を知り得るので、ドメイン１は、ドメイン２宛のパケットを中継可能である。
【００１９】
NAT装置は、通過するパケットの送信元アドレスをドメイン２へ向いた自装置インタフェースのエイリアスアドレスに変換する。NAT装置は、アドレスを変換したパケットをドメイン２に送出するとともに、そのエイリアスアドレスと変換前の送信元アドレスを記憶する。
【００２０】
これによりドメイン２内の受信ホストは、そのエイリアスアドレスに向けて応答パケットを送信する。すなわち、ドメイン２はドメイン１への経路は知らないが変換されたNAT装置のエイリアスアドレスへは返信可能である。
【００２１】
さらに、NAT装置は、このエイリアスアドレスで受信したパケットを記憶しておいたドメイン１側の本来の送信元アドレスへ向けて再送信する。
この場合、NAT装置の経路テーブルはドメイン１とドメイン２とを混合したテーブルであった。ドメイン２からドメイン１宛のパケットをフォワーディングインタフェースで受けてしまうと経路テーブルを参照しフォワードされる可能性があった。このため、不正パケットに対するフィルタが必要であった。
（両方向NAT）
図２１に両方向NATの概要を示す。両方向NATは、IPv4ドメインとIPv6ドメインのように、ドメイン１の経路情報もドメイン２の経路情報もお互いに交換できないという条件下で通信を実現した。ドメイン１内のホストがドメイン２内のホストへ通信を開始するとき、ドメイン１内のホストは通信に先だってDNSによる名前解決を実行する。
【００２２】
ドメイン１内の解決要求はドメイン１内のDNSサーバを経由しNAT装置上の変換サーバでドメイン２内の解決要求に変換される。ドメイン２のDNSサーバから解決応答が戻ってくると、NAT装置はプールしてあるドメイン１とドメイン２とに向いたそれぞれのエイリアスアドレスを各インタフェースに設定する。そしてNAT装置は、ドメイン１の問い合わせホストにはこのドメイン１側のエイリアスアドレスを通知する。NAT装置は各エイリアスアドレスとドメイン２から受け取った解決アドレスの対応を記録しておく。
【００２３】
送信ホストはNAT装置のドメイン１側のエイリアスアドレスへ向けてパケットを送信する。NAT装置は上記の対応を用いてヘッダの送信先アドレスを、解決応答によりドメイン２のDNSから得たアドレスに、送信元アドレスをドメイン２側のエイリアスアドレスに変更する。この場合、IPv4、v6のように全くアドレス体系が異なる場合は問題ない。しかし、両ドメインがIPv4アドレス空間の一部であるような構成において、NAT装置がエイリアスアドレス以外のインタフェースアドレスで悪意のあるパケットを受信した場合、フィルタが正しく設定されていないと、NAT装置は、このパケットをフォワードする可能性があった。
（アプリケーションゲートウェイ）
アプリケーションゲートウェイを使用してもドメインを分離可能であった。図２２にアプリケーションゲートウェイの概要を示す。
【００２４】
アプリケーションゲートウェイでは、一旦ゲートウェイ上のアプリケーションプログラム４０がドメイン１からの通信を終端し、データを受け取る。さらに、このアプリケーションプログラム４０は、ドメイン２側のコネクション上に再度データを送信する。この方式では、エンドホストが使うアプリケーションに対応したアプリケーションプログラム４０をゲートウェイ上にも用意する必要があった。また、この方式では、処理が重いという問題点があった。
【００２５】
（複数ドメインに対応したアドレス変換装置）
複数ドメインに対応した中継装置も提案されている。ただ、従来の中継装置には、単一の経路テーブルが備えられていた。また、ドメイン間でアドレス変換ポリシに合致しないパケットが通過しないようにフィルタが用いられていた。単純な設定では、このような中継装置も利用できた。しかし、従来の中継装置では、管理ドメインが多数になると処理が複雑になった。また、全パケットについてドメイン間通信の判定を行う必要があった。
（問題点）
NAT等のアドレス変換の手法によれば、フォワード方向のパケット転送では、中継装置は、アドレス変換処理を施した後、経路テーブルを検索して転送を行う。中継装置は、パケットの送受信アドレスに対してフィルタを設定することで、パケットの中継の可否を判断してしていた。一方でバックワード方向のパケットに対しては、グローバルアドレスドメインに対し中継装置があたかも送信元ホストであるかのように振舞う。そして、中継装置は、エンドホストとして、中継装置にプールされていたグローバルアドレス宛のパケットを終端していた。
【００２６】
同様に、グローバルアドレスドメインから到着したプライベートアドレスドメイン宛のパケットに対して、中継装置は、パケットフィルタによりドメイン間での中継判定を行っていた。このため、万が一プライベートアドレスドメイン宛の悪意のあるパケットが中継装置に到着した場合、フィルタが正しく設定されていないと、中継装置は唯一の経路テーブルを参照し、プライベートアドレスドメインにフォワードしてしまう可能性があった。これは予期せぬ不特定多数のパケットをインターネットから受信してしまう可能性を示しており、セキュリティホールとなり得た。
【００２７】
また、複数のドメインに接続可能な中継装置において、各ドメインが同一プライベートアドレス空間を採用した場合を想定する。この場合、中継装置が、各ドメインから得られた経路情報を一つの経路テーブルに書き込んでしまうと、経路テーブルに矛盾が生じる。
【００２８】
上記のような問題に対してパケットフィルタにより、グローバルアドレスドメインからのパケットをフォワードしないよう制限することも可能であった。しかし、管理可能なドメイン数が増加すると設定が複雑になった。
【００２９】
例えば、パケットフィルタでは、入力インターフェース、出力インターフェース、送信元アドレス、宛先アドレスやL4ポート番号等をキーとしてパケットの中継を制限可能であった。しかし、多くのインターフェースを持つルータでドメインを多数接続した場合、ドメインの組み合わせ毎にフィルタ条件を設定するのは煩雑であった。また、このような構成の中継装置では、設定ミスを誘発する可能性があった。さらに、このような複雑なフィルタ処理は、中継装置の負荷となり、高速な中継処理が困難であった。
【００３０】
【発明が解決しようとする課題】
本発明はこのような従来の技術の問題点に鑑みてなされたものであり、複数のドメイン間をアドレス変換によって中継する中継装置において、ドメイン間、ドメイン内通信が混在している場合にも、ドメイン間では複雑なフィルタを設定せずにセキュリティを確保した通信を実行し、ドメイン内においては高速にパケットを中継することを技術的課題とする。
【００３１】
【課題を解決するための手段】
本発明は前記課題を解決するために、以下の手段を採用した。
すなわち、本発明は、１以上のネットワークを接続した、そのような２以上のドメイン間を中継する通信データ中継装置であって、中継元のドメインが中継先のドメインへの経路情報を有している場合、
ネットワークにアクセスするための２以上のインターフェース部と、
１以上のネットワークからなるドメインを定義するドメイン定義部と、
ドメイン間における通信の可否を定義するドメイン間通信定義部と、
通信データの中継先を示す経路情報を前記ドメインごと区分して記憶する経路情報記憶部と、
通信データの中継を制御する中継制御部とを備えたものである。この通信データ中継装置において、中継制御部は、同一ドメイン内の中継においてはそのドメインに対応する経路情報記憶部を参照して通信データの中継を制御し、異なるドメイン間の中継においては前記ドメイン間通信定義部の定義に従い中継の可否を判定する。
【００３２】
この通信データ中継装置は、中継先ドメインに対する宛先アドレス検索部をさらに備え、中継元のドメインが中継先のドメインへの経路情報を有していない場合に、宛先アドレス検索部は、中継元のドメイン内の送信元通信装置からの要求に対してその中継先のドメイン内の宛先アドレスを検索し、その宛先アドレスに対応付けられる中継元ドメイン内の中継アドレスを送信元通信装置へ通知する。
【００３３】
中継制御部は、中継アドレス宛の通信データを中継先ドメインの宛先アドレスへ中継することができる。
この宛先アドレス検索部とは、例えば通信装置のネットワーク上の名称からそのアドレスを検索するものをいう。この宛先アドレス検索部は、他の通信装置に宛先アドレスの検索を依頼するものであってもよい。
【００３４】
この通信データ中継装置は、通信データを処理する通信データ処理装置を接続したドメインへの経路制御情報記憶部をさらに備え、
前記中継制御部は、通信データの中継を制御するときに、この通信データ処理装置に通信データを処理させ、処理された通信データを中継するようにしてもよい。ここで、通信データ処理装置とは、例えば通信データの内容をチェックする装置である。
【００３５】
【発明の実施の形態】
以下、本発明の好適な実施の形態を図面を参照して説明する。
（第１実施形態）
以下、本発明の第１実施形態を図１から図１２の図面に基いて説明する。
【００３６】
図１は第１実施形態におけるネットワーク構成図であり、図２は図１に示したルータ３のハードウェア構成図であり、図３は、このルータ３の機能構成図であり、図４及び図５は、図２に示したＣＰＵ１４で実行される制御プログラムの処理を示すフローチャートであり、図６から図１２はＣＰＵ１４が取り扱うデータのデータ構造を示す図である。
＜ネットワークの構成＞
図１に第１実施形態におけるネットワーク構成図を示す。図１のように、本実施形態においては、ルータ３がイントラネットＡ、イントラネットＢ、イントラネットＣ、及びインターネットを接続している。図１のようにルータ３は、各ネットワークを論理的なインターフェースde0、de1、de2、及び、de3を介して接続する（インターフェース部に相当）。
【００３７】
イントラネットＡのプライベートアドレスは、10.25.165.0/24である。イントラネットＡは、単独でドメイン１を構成している。イントラネットＡは、ルータ３のインターフェースde1に接続されている。このイントラネットＡは、ルータ３においてアドレス変換されることにより、インターネットと接続可能である。
【００３８】
イントラネットＢのプライベートアドレスは、192.168.0.0/16である。このイントラネットＢには、通信装置192.168.5.1が接続されている。イントラネットＢは、ルータ３のインターフェースde2に接続されている。このイントラネットＢもルータ３を介してインターネットと接続可能である。
【００３９】
イントラネットＣのプライベートアドレスは、192.172.0.0/16である。イントラネットＣは、ルータ３のインターフェースde3に接続されている。このイントラネットＣもルータ３を介してインターネットと接続可能である。また、上記イントラネットＢとイントラネットＣとは、ドメイン２を構成する。
【００４０】
インターネットは、グローバルアドレスでアクセスされる。また、インターネットには、ネットワーク４と、ネットワーク５とが接続されている。さらに、インターネットは、ルータ３のインターフェースde0に接続されている。
【００４１】
ネットワーク４のグローバルアドレスは、100.10.5.0/24である。また、ネットワーク４には、通信装置100.10.5.2が接続されている。
ネットワーク５のグローバルアドレスは、150.10.23.0/24である。また、ネットワーク５には、通信装置150.10.23.5が接続されている。
【００４２】
以上のインターネット、ネットワーク４及びネットワーク５は、ドメイン０を構成している。
図１に示した各ドメインは相互にネットワーク層での到達性がない独立した経路制御を行っている。さらに本実施形態においては、ドメイン２からドメイン０及び１に対して、アドレス変換を行うことで接続が許可されている。また、ドメイン１からドメイン２への通信は許可されていない。ドメイン１からドメイン０へは、アドレス変換を行うことで接続が許可されている。
＜ルータ３のハードウェア構成＞
図２に本実施形態に係るルータ３のハードウェア構成図を示す。
【００４３】
このルータ３は、制御プログラムやデータを記憶するメモリ１３と、メモリ１３に記憶された制御プログラムを実行するＣＰＵ１４と、ＣＰＵ１４から制御されて他の通信装置と通信する複数の物理インターフェース１５ａ、１５ｂ、１５ｃとを備えている。
【００４４】
メモリ１３は、ＣＰＵ１４が実行する制御プログラムやＣＰＵ１４が処理するデータを記憶する。
ＣＰＵ１４は、メモリ１３に記憶された制御プログラムを実行し、中継装置１としての機能を提供する。
【００４５】
物理インターフェース１５ａ、１５ｂ、１５ｃは、ＣＰＵ１４からの指令により通信データをネットワーク１０に送出し、またはネットワークから通信データを受信する。
＜機能構成＞
図３にルータ３の機能の構成図を示す。ＣＰＵ１４は、中継制御プログラム３１と経路制御プログラム３０とを実行することによりルータ３の機能を提供する。また、中継制御プログラム部分は、ＣＰＵによらず、ハードウェアにより構成してもよい。
【００４６】
中継制御プログラム３１は、パケット受信部２８、経路検索部２５、ドメイン間通信判定部２６、アドレス変換部２７、及びパケット送信部２９からなる。この中継制御プログラム３１を実行するＣＰＵ１４が中継制御部に相当する。
【００４７】
一方、ＣＰＵ１４は、上記中継制御プログラム３１とは、別に経路制御プログラム３０を実行している。これにより、ＣＰＵ１４は、他の通信装置及び他のルータとの間で経路情報を交換する。
[宛先ドメイン経路テーブル２０］
宛先ドメイン経路テーブル２０は、宛先ネットワークに対応する送信先インタフェース（以下送信インターフェースという）を登録したテーブルである。
【００４８】
図８、図９及び図１０に、各々ドメイン０、ドメイン１及びドメイン２を宛先とする宛先ドメイン経路テーブル２０の例を示す。本実施形態において、宛先ドメイン経路テーブル２０は、例えば、図８に示すように宛先ネットワークのアドレス、次ホップゲートウェイのアドレス、及びその宛先ネットワークに対応する送信インターフェースを識別する情報を有している。
【００４９】
また、図８、図９及び図１０に示すように、本実施形態では宛先ドメイン経路テーブル２０は、宛先ドメインごとに独立したテーブル構造を有する。
ＣＰＵ１４は、パケットを中継する際に宛先ドメイン経路テーブル２０を参照し、出力インターフェースを決定する。
[受信インターフェースドメイン経路テーブル２１］
受信インターフェースドメイン経路テーブル２１は、パケットを受信したインターフェース（以下受信インターフェースという）に対応するドメインの経路情報を格納する。この受信インターフェースドメイン経路テーブル２１と上記宛先ドメイン経路テーブル２０とが経路情報記憶部に相当する。
[ドメイン定義テーブル２２]
ドメイン定義テーブル２２は、各インタフェースに対応するドメインを定義したテーブルである（ドメイン定義部に相当）。図６に本実施形態におけるドメイン定義テーブル２２の定義例を示す。
【００５０】
図６のように、本実施形態においては、ドメイン定義テーブル２２はインターフェースを識別する情報（インターフェース番号）とドメインを識別する情報（ドメイン番号）とを有している。例えば、インターフェース番号de0に対応するドメインは、ドメイン０である。
【００５１】
なお、インターフェースとしては、物理的なインターフェースだけでなく、論理的なインターフェースを登録してもよい。
[ドメイン間通信定義テーブル２３]
ドメイン間通信定義テーブル２３は、ドメイン定義テーブル２２で定義した各ドメインに対して、他のドメインとの接続の可否を定義したテーブルである（ドメイン間通信定義部に相当）。図７に本実施形態におけるドメイン間通信定義テーブル２３の定義例を示す。
【００５２】
図７のように、ドメイン間通信定義テーブル２３は、送信元ドメイン->宛先ドメインの指定、そのドメイン間の通信の可否、及び、変換ルール（アドレス変換の方式）の組み合わせからなるレコードで構成される。本実施形態における設定では、例えば、ドメイン０からドメイン１及びドメイン２への通信は許可されない。また、ドメイン２からドメイン０及び１への通信は許可され、かつ、変換ルールとしてＮＡＴが適用される。
[アドレス変換テーブル２４]
アドレス変換テーブル２４は、アドレス変換前後の情報を対にしたレコードからなるテーブルである。図１１に本実施形態におけるアドレス変換テーブル２４の例を示す。
【００５３】
図１１のように、アドレス変換テーブル２４は変換前後の送信元アドレス、宛先アドレス及び送受信インターフェースを１組にしたレコードから構成される。これらの情報は、送信元から宛先へのパケットが中継装置１を最初に通過するときに設定される。その後、２つ目以降のパケットの通信においては、アドレス変換テーブル２４が参照される。
[経路検索部２５］
経路検索部２５は、パケットの宛先アドレスをキーとして、経路テーブルを検索する。
[ドメイン間通信判定部２６］
ドメイン間通信判定部２６は、パケットヘッダ情報やネームサービス（通信装置のホスト名称に対応するアドレスを示すプログラム）等を用いて、宛先の通信装置がどのドメインに属するか判定する。
[アドレス変換部２７］
アドレス変換部２７は、ドメイン間通信判定部２６から、変換前後の情報（送信元アドレス、宛先アドレス）を受ける。この情報に従い、アドレス変換部２７は、パケットのヘッダ内容を変換する。
[パケット受信部２８］
パケット受信部２８は、物理インターフェース１５ａ等を監視する。そして、パケット受信部２８は、物理インターフェース１５ａ等に接続したネットワークからパケットを受信する。
[パケット送信部２９］
パケット送信部２９は、物理インターフェース１５ａ等を制御し、物理インターフェース１５ａ等に接続したネットワークへパケットを送信する。
[経路制御プログラム３０］
経路制御プログラム３０は、経路制御プロトコルを実行する。すなわち、経路制御プログラム３０は、ドメイン内に流れる経路情報１０２を受信し、受信した経路情報１０２に合わせて自ルータの経路テーブルを変更する。また、経路制御プログラム３０は、自ルータから同一ドメイン内の他ルータへのネットワーク到達性情報や接続コスト等を経路情報１０２に入れて、他ルータへ配布する。本実施形態では経路制御プログラム３０はドメイン毎に個別用意する。各経路制御プログラム３０は、各々対応するドメインと経路情報を交換する。その結果得られたドメインごとの経路情報は、宛先ドメインごとに宛先ドメイン経路テーブル２０に保存される。
【００５４】
なお、経路制御プロトコルとしては、RIP(Routing Information Protocol、インターネットに関するドキュメントRFC1058参照)、OSPF(Open Shortest Path First、RFC1131参照)等が知られている。
＜機能概要＞
以下図３に従い、ルータ３の機能概要を説明する。
（１）ルータ３はパケット受信部２８により宛先ホストを指定されたパケット１００を受信する。
（２）まず、経路検索部２５は、受信インタフェースが属するドメインへの経路テーブル（受信インターフェースドメイン経路テーブル２１）を検索する。受信インターフェースドメイン経路テーブル２１の検索がヒットした場合、経路検索部２５は、ドメイン内ルーティングとして中継する。すなわち、経路検索部２５はパケット送信部２９に指示し、出力インタフェースにパケットを出力させる。
【００５５】
受信インタフェースドメイン経路テーブル２１の検索がヒットしない場合、（３）以下に示す手順が実行される。
（３）ドメイン間通信判定部２６は、受信したパケットのヘッダ情報、受信インタフェースなどをキーとしてアドレス変換テーブルを順引き、逆引きで検索する。 順引き、逆引きのどちらかで検索がヒットした場合は、ドメイン間通信判定部２６は、アドレス変換手段にパケットを渡す。
【００５６】
検索がヒットしない場合、ドメイン間通信判定部２６は、パケットのヘッダ情報、宛先ドメイン経路テーブル２０及びドメイン定義テーブル２２から受信したパケットの宛先アドレスがどのドメインに属するかを調べる。次に、ドメイン間通信判定部２６は、ドメイン定義テーブル２２に登録された受信インターフェースが属するドメインを調べる。次に、ドメイン間通信判定部２６は、ドメイン間通信定義テーブル２３を参照し、受信インタフェースが属するドメインと宛先ドメインとの間の通信の可否を判断する。なお、ドメイン間通信定義テーブル２３にはアドレス変換ルールも示されている。
（４）ドメイン間通信判定部は、受信インタフェースが属するドメインと宛先ドメインとの通信が可能な場合は、宛先ドメイン経路テーブル２０を参照するよう経路検索部２５に通知する。
（５）経路検索部２５は、ドメイン間通信判定部２６から起動され、宛先ドメイン経路テーブル２０を検索する。この検索では、パケットヘッダ情報の宛先アドレスをキーとして使用する。
（６）アドレス変換部２７はパケットに対しドメイン間通信定義テーブル２４に記された変換ルールに従いパケットヘッダ情報を変換する。
（７）パケット送信部２９は、検索された出力インタフェースにパケットを出力する。
（８）経路制御プログラム３０は各ドメイン毎に起動し、各ドメインへの宛先ドメイン経路テーブル２０及び受信インターフェースドメイン経路テーブル２１を修正する。
＜通常処理＞
以下に、本実施形態におけるネットワーク間の接続条件を示す。
［接続条件１］イントラネットA(10.25.165.0)はルータ３によりアドレス変換されることでインタネットと通信可能である。
［接続条件２］イントラネットB(192.168.0.0)はルータ３を通してブランチオフィスであるイントラネットC(192.172.0.0)と接続される。
［接続条件３］イントラネットB,Cは共にルータ３を介してインターネットに接続可能である。
【００５７】
図４及び図５に上記接続を実現するための中継制御プログラム３１の処理を示す。この中継制御プログラム３１は、ＣＰＵ１４において実行される。
まず、順方向の通信（送信元通信装置から宛先通信装置へのパケット送信）に対する処理を説明する。
（１）ルータ３でのパケット受信
今、ルータ３が、インターフェースde2を介して、ドメイン２に属するネットワーク192.168.100.０からパケットを受信した場合の処理を説明する。このパケットの宛先アドレスは、100.10.5.2、送信元アドレスは、192.168.5.1である。
（２）自局宛てパケット判定
まず、ルータ３のＣＰＵ１４は、このパケットがルータ３そのものへ宛てられた（以下自局宛てという。自局宛を自ノード宛ともいう）パケットか否かを判定する（ステップＳ１、以下Ｓ１と略す）。自局宛てパケットは、ルータ３自身への通信パケットととして処理される（Ｓ３）。
【００５８】
本実施形態では、自局宛てパケットは、ルータ３への環境設定パケットである。この環境設定パケットは、ネットワーク管理者がルータ３にリモートログインすることで発せられる。ルータ３の環境設定そのものに関する説明は省略する。
【００５９】
今、パケットは、環境設定パケットではないため、Ｓ２の判定は、Noである。従って、ＣＰＵ１４は、処理をドメイン内通信判定（Ｓ４）に進める。
（３）ドメイン内通信判定
次に、ＣＰＵ１４は、このパケットが同一ドメイン内の宛先に宛てられているか否かを判定する（Ｓ４）。この判定では受信インタフェースが属するドメイン宛の宛先経路テーブル（受信インターフェースドメイン経路テーブル２１）を検索する。その検索がヒットした場合は（Ｓ５の判定でYesの場合）、受信インターフェースに対応する送信元ドメインと宛先ドメインとが同一であることを意味する。すなわち、同一ドメイン内でパケットを中継すればよい（Ｓ６）。
【００６０】
ヒットしなかった場合（Ｓ５の判定でNoの場合）は、ドメイン間通信判定部２６に処理を渡す（Ｓ７）。この例では、同一ドメイン内の通信でないため、ＣＰＵ１４は制御をＳ７の処理に進める。
（４）ドメイン間通信判定部２６、アドレス変換部２７、及びパケット送信部２９の処理
ドメイン間通信判定部２６では、受信したパケットの宛先アドレス、送信元アドレスをキーとして図１１のアドレス変換テーブル２４を検索する。アドレス変換テーブル２４の検索がヒットした場合は（Ｓ８の判定でYesの場合）、検索結果とともにパケットがアドレス変換部２７に送られる（Ｓ９）。これは順方向通信でアドレス変換すべきパケットであることを示している。アドレス変換部２７では、与えられた検索結果を元にパケットのヘッダを書き換える。また、ＣＰＵ１４は、アドレス変換テーブル２４（図１１）から送信インターフェースを求める。
【００６１】
次に、ＣＰＵ１４は、パケット送信部２９に制御を移し、パケットを上記送信インターフェースからネットワークに送信する（Ｓ１１）。
この検索がヒットしない場合は（Ｓ８の判定でNoの場合）、ＣＰＵ１４は、図５に示す処理に制御を移す。すなわち、ＣＰＵ１４は、パケットの宛先アドレスをアドレス変換テーブル２４における変換後の送信元アドレスとして、パケットの送信元アドレスをアドレス変換テーブル２４における変換後の宛先アドレスとして、アドレス変換テーブル２４を検索する（Ｓ１２）。
【００６２】
ここで、検索がヒットした場合は（Ｓ１３の判定でYesの場合）、ＣＰＵ１４は、パケットが順方向通信に対する応答通信（逆方向通信）のパケットであると判断する。そこで、ＣＰＵ１４は、検索された内容と共にパケットをアドレス変換部２７に渡す。さらにＣＰＵ１４は、アドレス逆変換を指示する（Ｓ１４）。その結果、ＣＰＵ１４は、パケットの宛先をアドレス変換テーブルにおける変換前の送信元アドレスに書き換える。また、ＣＰＵ１４は、アドレス変換テーブル２４から返信先インターフェース（図１１の受信インターフェース）を求める。
【００６３】
次に、ＣＰＵ１４は、パケット送信部２９に制御を移し、パケットを上記送信インターフェースからネットワークに送信する（Ｓ１６）。
どちらにもヒットしない場合は（Ｓ１３の判定でNoの場合）、ＣＰＵ１４は、ドメインをまたがる通信を行うかどうかを判断する（Ｓ１７及びＳ１８の処理）。これは新たにドメイン間通信を開始する場合に必要な処理である。
【００６４】
すなわち、ＣＰＵ１４は、宛先アドレスをキーとして宛先ドメイン経路テーブル２０の全体を検索して、送信インターフェースを求める。
今、宛先アドレスが、100.10.5.2であるので、ＣＰＵ１４は、送信インターフェースとしてde0を得る。次にＣＰＵ１４は、この送信インターフェースをキーとしてドメイン定義テーブル２２を検索して宛先ドメインを求める。今、送信インターフェースがde0であるので、ＣＰＵ１４は、宛先ドメインとしてドメイン0を得る。さらに、ＣＰＵ１４は、受信インターフェースをキーとして、ドメイン定義テーブル２２を検索する。ＣＰＵ１４は、パケットを受信したインタフェース番号とドメイン定義テーブル２２（図６）とから、ＣＰＵ１４は、送信元ドメインとしてドメイン２を得る（Ｓ１７）。
【００６５】
次に、ＣＰＵ１４は、得られた送信元ドメイン及び宛先ドメインをキーとして、図７のドメイン間通信定義テーブル２３を検索する（Ｓ１８）。
今、この検索はヒットするので（Ｓ１９でYesの場合）、両ドメインの接続が許可されていることが分かる。また、NATによるアドレス変換が指定されていることが分かる。
【００６６】
本実施例形態で実現するNATでは送信元アドレスのみが変換される。この変換には、宛先ドメインごとにプールされているIPアドレスが使用される
このとき、ＣＰＵ１４は、図１１のアドレス変換テーブル２４に、変換前のアドレスと変換後のアドレスを対応させて登録する（Ｓ２０）。
【００６７】
また、ＣＰＵ１４は、受信インターフェース、送信インターフェースもアドレス変換テーブル２４に登録する（Ｓ２１）。
次に、ＣＰＵ１４は、パケット送信部２９に制御を移し、パケットを上記送信インターフェースからネットワークに送信する（Ｓ２２）。
【００６８】
Ｓ１８の判定において、２つのドメイン間の接続が不許可の場合は（Ｓ１９の判定でNoの場合）、ＣＰＵ１４は、パケットを廃棄する（Ｓ２３）。
＜効果＞
以上によれば順方向、逆方向ともにドメイン間通信判定部２６により許可されたパケットのみが宛先ドメイン経路テーブル２４を参照可能となるため、悪意のあるパケットを誤って中継してしまうことを回避できる。
【００６９】
また、本実施形態のルータ３では、宛先ドメインごとに経路テーブルを分離し、かつ、パケットを受信した段階で受信インタフェースドメイン経路テーブル２１を優先的に参照する。このため、受信インタフェースに対応するドメイン宛のパケット（同一ドメイン内の宛先に対するパケット）に対しては、経路テーブルの検索は、そのドメインに対応する経路テーブル（受信インタフェースドメイン経路テーブル２１）に限定される。その結果、同一ドメイン宛パケットの中継が効率化される。
【００７０】
一方、インターネットからイントラネットに侵入する悪意のあるパケットを排除するためのドメイン間通信判定部２６の処理は、上記のような同一ドメイン宛以外のパケットに対して実行すればよい。
＜変形例＞
上記第１実施形態においては、宛先ドメイン経路テーブル２０と受信インターフェース経路テーブル２１とが異なるテーブルとして構成された。しかし、本発明の実施は、このような構成に限定されるものではない。例えば、受信インターフェース経路テーブル２１を宛先ドメイン経路テーブル２０の一部として構成してもよい。ただし、上記第１実施形態と同様に、宛先ドメイン経路テーブル２０は、各宛先ドメイン毎に論理的に独立したテーブル構造を有するものとする。
【００７１】
この場合は、パケット受信部でパケットを受信した際、パケットを受信したインターフェースをキーとして、ドメイン定義テーブルを検索し、受信ドメインを決定し、適するドメイン経路テーブルを選択する。
【００７２】
上記第１実施形態では、経路制御プログラム３０は、各宛先ドメイン毎に個別に用意した。しかし、本発明の実施は、このような構成には、限定されない。例えば、１つの経路制御プログラム３０（経路制御プロトコルを実行するＣＰＵ１４上の１つのプロセス）を備えてもよい。その場合、このプログラムが宛先ドメインごとに経路情報を交換する処理を順次繰り返すようにすればよい。
【００７３】
上記第１実施形態では、ルータ３は、論理的なインターフェースde0、de1、またはde2をドメインに対応付けた 。しかし、本発明の実施は、このような構成には、限定されない。例えば、論理的なインターフェースde0等を使用せず、直接物理インターフェース１５ａ、１５ｂ、または１５ｃを各ドメインに対応付けてもよい。この場合は、物理インターフェース１５ａ等がインターフェース部に相当する。
【００７４】
上記実施形態においては、宛先ドメイン経路テーブル２０は、図８から図１０のように宛先ドメインごとに分離して構成した。しかし、本発明の実施は、このような構成に限定されない。例えば、図１２に示したように単一のテーブルで宛先ドメイン経路テーブル２０を構成しても、テーブルを構成するレコードが宛先ドメインごとに分離されていればよい。
【００７５】
上記実施形態の中継装置１では、ドメイン間で最初に通信されるパケットの宛先アドレスに基づき、全ての宛先ドメイン経路テーブルの全体を検索して出力インターフェースを求めた。そして、その出力インターフェースから宛先ドメインを決定し、送信元ドメインと宛先ドメインとのドメイン間の接続の可否を判定した（図５のＳ１７及びＳ１８の処理）。しかし、本発明の実施はこのような処理手順には限定されない。すなわち、宛先ドメイン経路テーブル間で、アドレスに重複がある場合を考慮し、Ｓ１８の処理を先に行てもよい。まず、ドメイン間通信定義テーブル２３を検索し、通信が許可されている受信ドメインを決定しておく。そして、そのような通信が許可されているドメインの経路テーブルのみを検索し、出力インターフェースを求めることも可能である（図５においてＳ１８の処理を先に実行し、Ｓ１７の処理を後から実行することに相当する）。
（第２実施形態）
図１３から図１７を参照して、本発明の第２実施形態を説明する。図１３は、本実施形態のネットワーク構成図であり、図１４は本実施形態に係るルータ３の機能構成図であり、図１５は、ルータ３のＣＰＵ１４で実行されるアドレス事前登録部２５の処理を示すフローチャートであり、図１６はアドレス事前登録部２５の処理結果を示す図であり、図１７はルータ３のＣＰＵ１４で実行される中継制御プログラム３１の処理を示す図である。
【００７６】
上記第１実施形態では、宛先ドメイン経路テーブル２０及び受信インターフェースドメイン経路テーブル２１を備えたルータ３を説明した。この場合、上記第１実施形態では、ドメイン２においては、ドメイン０への経路が既知であった。
【００７７】
本実施形態では、ルータ３に接続される２つのドメインにおいて互いに相手の経路が不明である場合の中継処理を説明する。ただし、送信元ドメインは相手ドメインのホスト名から相手ドメイン内のアドレスを知る手段があるものとする。他の構成及び作用については、第１形態と同様であるので、同一の構成については、同一の符号を付してその説明を省略する。また、必要に応じて図１から図１２の図面を参照する。
＜構成＞
図１３に本実施形態に係るネットワーク構成図を示す。本実施形態では、互いに相手への経路が不明なドメイン０とドメイン２とを接続するルータ３を説明する。
【００７８】
図１３のようにドメイン０には、sub1.0の名称で示されるネットワーク４が含まれている。また、ネットワーク４には、ホスト名n0.sub1.0のホストが接続されている。このホストn0.sub1.0のアドレスは、100.10.5.2である。
【００７９】
また、ドメイン２には、アドレス192.168.5.1で示されるホストが接続されている。ドメイン０とドメイン２とは、互いに相手ドメインへの経路が不明である。ただし、本実施形態では、ドメイン２のホスト192.168.5.1は、宛先ホストのホスト名n0.sub1.0を知っているものとする。
【００８０】
このような場合、本実施形態においては、送信元ホスト192.168.5.1は、ルータ３に対して宛先の名称に対応するアドレスを問い合わせることができる。
図１４に本実施形態におけるルータ３の機能構成を示す。図１４の構成は、アドレス変換事前登録部２５（アドレス検索部に相当）が追加されている点で、図３に示した第１実施形態の構成と相違する。
【００８１】
アドレス変換事前登録部２５は、事前にアドレス変換テーブル２４に変換前後の情報を登録する機能を有する。
＜アドレス変換事前登録部２５における処理＞
以下、送信元ホスト192.168.5.1が、ルータ３に宛先のホスト名称に対応する宛先アドレスを問い合わせた場合の処理を説明する。
【００８２】
図１５にルータ３のＣＰＵ１４が実行するアドレス変換事前登録部２５の処理を示す。まず、ＣＰＵ１４は、ネームサービス（ＲＦＣ９２１）を実行する不図示のサーバにその宛先のホスト名称n0.sub1.0に対応するドメイン0内のアドレスを問い合わせる（Ｓ４１）。その結果、ＣＰＵ１４は、宛先ホストのアドレス100.10.5.2を得る。
【００８３】
次に、ＣＰＵ１４は、宛先ホストのドメイン番号0に基づき、宛先ドメインごとに区分された宛先ドメイン経路テーブル２０を検索し、出力インターフェースde0を求める（Ｓ４２）。
【００８４】
次にＣＰＵ１４は、上記第１実施形態と同様に受信インターフェースde2の属するドメイン２を求める（Ｓ４３）。
次にＣＰＵ１４は、２つドメイン間の接続可否（ドメイン２からドメイン０への接続可否）をドメイン間通信定義テーブル２３に従って判定する（Ｓ４４）。２つのドメイン間の通信が認められない場合（Ｓ４４の判定でNoの場合）、ルータ３は、その旨を送信元192.168.5.1へ通知する（Ｓ４５）。
【００８５】
一方、ドメイン２からドメイン０への通信が認められる場合（Ｓ４４の判定でYesの場合）、ＣＰＵ１４は、予めプールしておいたドメイン２におけるエイリアスアドレス192.168.5.2を求める（Ｓ４６）（以下、このエイリアスアドレスを受信インターフェースアドレスと呼ぶ）。また、ＣＰＵ１４は、予めプールしておいたドメイン０におけるエイリアスアドレス120.10.4.2を求める（以下、このエイリアスアドレスを送信インターフェースアドレスと呼ぶ）。
【００８６】
そして、ＣＰＵ１４は、送信元アドレス192.168.5.1、受信インターフェースアドレス192.168.5.2、受信インターフェースde2、送信インターフェースアドレス120.10.4.2、宛先アドレス100.10.5.2、送信インターフェースde0をアドレス変換テーブル２４に登録する（Ｓ４７）。この登録された結果を図１６に示す。
【００８７】
次に、ルータ３は、送信元192.168.5.1に対し、本受信インタフェースアドレス192.168.5.2を予め通知する（Ｓ４８）。これによって、送信元192.168.5.1は、その受信インタフェースアドレス192.168.5.2にパケットを送信すれば、所望の宛先ホストn0.sub1.0にパケットを送信できることを知る。
【００８８】
以上の処理は、通信に先だって、送信元192.168.5.1とルータ３との間で実行される。このような設定の後、上記受信インターフェースアドレス192.168.5.2宛のパケットを受信したルータ３は、アドレス変換テーブル２４に従い、宛先をアドレス100.10.5.2に変換し、出力インターフェースde0から送信する。この結果パケットは、ドメイン２からドメイン０に中継される。
＜受信インターフェースアドレスによる接続処理＞
図１７に受信インターフェースアドレスによる接続処理のフローチャートを示す。この処理は、ルータ３のＣＰＵ１４が、中継制御プログラム３１として実行する。
（１）パケット受信
今、ルータ３が、インターフェースde2を介して、ドメイン２に属するネットワーク192.168.0.0からパケットを受信した場合の処理を説明する。このパケットの宛先アドレスは、192.168.5.2（上記受信インターフェースアドレス）、送信元アドレスは、192.168.5.1である。
（２）自局宛てパケット判定
まず、ルータ３のＣＰＵ１４は、このパケットが自局宛てパケットか否かを判定する（Ｓ１）。
【００８９】
本実施形態で、自局宛てパケットとは、ルータ３自身へのへの環境設定パケット、または上記通知した受信インターフェースアドレス宛のパケットである。
今、パケットは、受信インターフェースアドレス宛のパケットであるため、Ｓ２の判定は、Yesである。従って、ＣＰＵ１４は、制御をＳ３１以下の処理に進める。
（３）自局あてパケット処理
次に、ＣＰＵ１４は、送信元アドレス192.168.5.1と宛先アドレス192.168.5.2とをキーにしてアドレス変換テーブル２４を検索する（Ｓ３１）。
【００９０】
上記２つのアドレスの組み合わせは、アドレス変換テーブル２４に登録済みであるので（図１６参照）、この検索はヒットする（Ｓ３２の判定でYesとなる）。そこでＣＰＵ１４は、Ｓ３３以下の処理に制御を進める。
【００９１】
すなわち、ＣＰＵ１４は、アドレス変換部２７を実行する（Ｓ３３）。その結果、受信インターフェースアドレス192.168.5.2に対応するドメイン０内の宛先アドレス100.10 5.2及び送信インターフェースde0が求められる。
【００９２】
次にＣＰＵ１４は、パケット送信部２９を実行し、上記宛先100.10 5.2に送信インターフェースde0からパケットを送信する。
（４）パケット返信処理
上記宛先100.10 5.2からの返信パケットの処理は、第１実施形態で説明した図５のフローチャートのＳ１２からＳ１６の処理と同様であるので、その説明を省略する。
【００９３】
以上のように互いに経路情報を交換しない２つのドメイン間に対しても、ルータ３にアドレス変換事前登録部２５を備えることで本発明の実施は可能である。
また、本実施形態のルータ３では、宛先ドメイン経路テーブル２０を宛先ドメインごとに分離して構成する。従って、複数のドメイン間でプライベートアドレスが重複する場合でも、アドレス事前登録部２５は、適切な出力インターフェースを宛先ドメイン経路テーブル２０から求めることができる。
＜変形例＞
上記第２実施形態においては、互いに経路情報を交換しない２つのドメイン間を接続するルータ３を説明した。しかし、本発明の実施は、このようなドメイン間の接続に限定されない。すなわち、中継される２つのドメインの一方のみが、他方への経路情報を有していない場合にも本発明は同様に実施できる。つまり、中継先ドメインへの経路情報を有していないドメインから中継先へ通信する場合に、第２実施形態で説明したルータ３は、上記同様にパケットを中継できる。
（第３実施形態）
上記第１実施形態では、宛先ドメイン経路テーブル２０及び受信インターフェースドメイン経路テーブル２１を備えたルータ３を説明した。
【００９４】
本実施形態では、上記第１実施形態の構成おいて、アドレス変換部２７の提供する機能の一部（コンテンツチェック）を他のドメイン上のサーバ（通信データ処理装置に相当）に実行させるルータ３について説明する。
【００９５】
図１８を参照して、本発明の第３実施形態を説明する。図１８は、本実施形態に係るルータ３の機能構成図である。図１８は、サーバドメイン経路テーブル３１及びコンテンツチェックサーバ３２が付加されている点で第１実施形態の図３と相違する。他の構成及び作用については、第１実施形態及び第２実施形態と同様であり、同一の構成については、同一の符号を付してその説明を省略する。また、必要に応じて、図１から図１７の図面を参照する。
【００９６】
図１８のように、本実施形態のルータ３のＣＰＵ１４は、サーバへの経路情報を保持するサーバドメイン経路テーブル３１を備えている。ＣＰＵ１４は、このサーバドメイン経路テーブル３１を検索する。この検索結果に従い、ＣＰＵ１４は中継するパケットのアドレスをコンテンツチェックサーバ３２宛に変換して送信する。次にＣＰＵ１４は、コンテンツチェックが終わったパケットを受信する。次にＣＰＵ１４は、そのパケットをアドレス逆変換し、本来の宛先ドメインへアドレス変換する。
【００９７】
このようにコンテンツチェックをコンテンツチェックサーバ３２に実行させることにより、ルータ３の負荷が低減され、高速な中継処理が実現される。
【００９８】
【発明の効果】
以上説明したように、本発明によれば、１以上のネットワークを接続した、そのような２以上のドメイン間を中継する通信データ中継装置であって、
１以上のネットワークからなるドメインを定義するドメイン定義部と、
ドメイン間における通信の可否を定義するドメイン間通信定義部と、
通信データの中継先を示す経路情報を前記ドメインごと区分して記憶する経路情報記憶部とを備え、同一ドメイン内の中継においてはそのドメインに対応する経路情報記憶部を参照して通信データの中継を制御し、異なるドメイン間の中継においては前記ドメイン間通信定義部の定義に従い中継の可否を判定する。従って、ドメイン間、ドメイン内通信が混在している場合にも、ドメイン内においては高速にパケットを中継し、ドメイン間では複雑なフィルタを設定せずにセキュリティを確保した通信を実行することができる。
【図面の簡単な説明】
【図１】本発明の第１実施形態におけるネットワーク構成図
【図２】本発明の第１実施形態におけるルータのハードウェア構成図
【図３】本発明の第１実施形態におけるルータの機能構成図
【図４】制御プログラムの処理を示すフローチャート（１）
【図５】制御プログラムの処理を示すフローチャート（２）
【図６】ドメイン定義テーブルのデータ構造を示す図
【図７】ドメイン間通信定義テーブルのデータ構造を示す図
【図８】宛先ドメイン経路テーブルのデータ構造を示す図（１）
【図９】宛先ドメイン経路テーブルのデータ構造を示す図（２）
【図１０】経路テーブルのデータ構造を示す図（３）
【図１１】アドレス変換テーブルのデータ構造を示す図
【図１２】実際の経路テーブルのデータ構造例を示す図
【図１３】本発明の第２実施形態におけるネットワーク構成図
【図１４】本発明の第２実施形態におけるルータの機能構成図
【図１５】アドレス事前登録部の処理を示すフローチャート
【図１６】アドレス事前登録部によるアドレス変換テーブルへの登録結果
【図１７】受信インターフェースアドレスによる中継処理を示すフローチャート
【図１８】本発明の第３実施形態におけるルータの機能構成図
【図１９】従来技術ＬＳＰ（ラベル・スイッチ・パス）の概要
【図２０】従来技術片方向ＮＡＴの概要
【図２１】従来技術両方向ＮＡＴの概要
【図２２】従来技術アプリケーションゲートウェイの概要
【符号の説明】
３ ルータ
１３ ＣＰＵ１
１４ メモリ
１５ａ 物理インターフェース
１５ｂ 物理インターフェース
１５ｃ 物理インターフェース
２０ 宛先ドメイン経路テーブル
２１ 受信インターフェース経路テーブル
２２ ドメイン定義テーブル
２３ ドメイン間通信定義テーブル
２４ アドレス変換テーブル
【発明の属する技術分野】
本発明は、ネットワークの中継装置に関する。
【０００２】
【従来の技術】
（ドメインの概念）
従来からルーティングドメインとは、１以上のネットワークからなり、一つ以上の互いに協調する経路制御プロトコルにより管理され、その経路情報によりネットワーク層パケットが到達可能な範囲と定義されていた。例えば、インターネットはさまざまな経路制御プロトコルが動作している複数のネットワークから構成されている。このため、インターネットは１つのルーティングドメインである（以下ルーティングドメインを単にドメインと省略する）。
【０００３】
今日まで、多くの企業が自社の情報インフラとしてインターネットの技術を用いた企業内網を構築してきた。こうしたネットワークにおいては、企業の秘密を守るため、あるいは外部からの妨害を避けるため、インターネットとの間にファイアウォール装置が配置されていた。このファイアウォール装置により、インターネットとの間の通信が監視・制限されていた。こうしたネットワークではセキュリティ上の理由から、企業内網の内部経路をインターネットに配布しないのが一般的であった。また、IPv4アドレスが不足しているため、企業内網でプライベートアドレスを用いるのが一般的であった。
【０００４】
プライベートアドレスは企業ユーザが自由に利用できるインタネットアドレスの範囲である。しかし、インターネットにこれらの経路を配布することは禁止されていた。そのため、プライベートアドレスを使用する企業内網は、インターネットとは直接通信できなかった。したがって、企業内網はインターネットとは独立したドメインである。
【０００５】
こうした企業内網が、インターネットと通信するためにはNAT（IP Network Address Translator）装置を使用する必要があった。NAT装置は、プライベートアドレスを持つパケットをグローバルアドレスで経路制御されるインターネットに通すために、両ドメイン境界においてパケットに付されたプライベートアドレスをグローバルアドレスに変換する。
【０００６】
さらに、企業内網構成の複雑化、ルータ機能の多様化に対応するため、ルータ装置がNAT機能を持つようになった（以下これをNATルータという）。このようなルータ装置は、二つのドメインを管理することができた。
【０００７】
このような状況において、プライベートアドレスによるドメイン（以下プライベートアドレスドメインという）からグローバルアドレスによるドメイン（以下グローバルアドレスドメインという）への通信は、以下のように行われていた。
【０００８】
すなわち、プライベートアドレスドメイン内の各ルータにおいて、宛先アドレスが企業内網内部以外であるパケットを全てNATルータへ送信するように、デフォルト経路が設定された。これにより、グローバルアドレスドメイン宛のパケットをドメイン境界に置かれた中継装置（以下ドメイン境界中継装置という）に送ることが可能であった。
【０００９】
中継装置は、プライベートアドレスドメインの経路情報をグローバルアドレスドメインへ流さないが、グローバルアドレスドメインから得た経路情報をプライベートアドレスドメインへ流す。これにより、プライベートアドレスドメイン内の各ホスト（ノード）は、グローバルアドレスドメイン宛のパケットを中継装置に送ることが可能であった。
【００１０】
ドメイン境界中継装置は、グローバルアドレスドメインから受け取った経路情報から、グローバルアドレスドメイン内の次ホップルータを知る（実際には、中継装置において、デフォルトルートとして外部ルータが指定してされている場合もある）。こうして、ドメイン境界中継装置は、グローバルアドレスドメインへ向いたインタフェースへパケットを中継できた。このとき、実際にはドメイン境界中継装置は、中継する前にパケットのアドレスを変換した。
【００１１】
アドレス変換にはいくつかの方法があった。例えば、まず、ドメイン境界に置かれた中継装置がグローバルアドレスをいくつかプールしておく。このドメイン境界中継装置は、到着したパケットのプライベートアドレスである送信元アドレスをプールしてあるグローバルアドレスの一つと置きかえる（以下このアドレスをエイリアスアドレスという）。
【００１２】
次に、このドメイン境界中継装置が、あたかもグローバルアドレスドメイン内の送信ホストであるかのように送信する。このとき、ドメイン境界中継装置は、置き換えた送信元アドレスとそのエイリアスアドレスの対応を記録する。そして、ドメイン境界中継装置が、グローバルアドレスドメインから送信したパケットに対する応答トラフィックを受信したとき、プライベートアドレスドメイン内の本来の送信ホストへ中継する。
【００１３】
また、プライベートアドレスドメインからグローバルアドレスドメインへ送信したパケットに対する応答パケットが返ってきた場合、宛先アドレスは上記エイリアスアドレスである。つまり、グローバルアドレスドメインにおいてはパケットの送信元が中継装置のエイリアスアドレスである。このため、ドメイン境界中継装置は、先のプライベートアドレスとグローバルアドレスとの変換テーブルを参照し、パケットの宛先アドレスをプライベートアドレスドメインの送信元アドレスに変換できる。こうして、ドメイン境界中継装置は、返信パケットをプライベートアドレスドメインへ接続されたインタフェースへと中継する。
【００１４】
以上のようなアドレス変換機能により両ドメイン間の通信が可能であった。フォワード方向の通信では宛先ドメインにおける経路テーブルが必要であった。一方、プライベートアドレスとグローバルアドレスの変換テーブルにフォワード方向パケットを受信したインタフェースも併せて記録しておけば、中継装置は、バックワードのパケットをその受信インターフェースへ転送すればよい。その際、送信元ドメインの経路情報を検索し、プライベートアドレスドメインにおける次ホップルータを決定し、上記インターフェースへ転送する。
【００１５】
従来、ドメイン境界中継装置は、複数のルーティングプロトコルを終端する経路制御プログラムとただ一つの経路テーブルを有していた。なお、ここでいう経路テーブルとはパケット中継時に出力インタフェースと次ホップルータとを決定するために検索するテーブルを指す。
【００１６】
従来の中継装置は、このような複数のルーティングプロトコルによって知り得た経路情報を相互に混合するか否かという管理上の制御を行っていた。しかし、相互に混合する場合、従来の中継装置では、このような複数のルーティングプロトコルから知り得た経路情報を全て同一の経路テーブルに書き込んでいた。つまり、プライベートアドレスドメインとグローバルアドレスドメイン境界の中継装置は、各ドメインから知り得た経路情報を一つのテーブル内で管理していた。
（Lucent Technologies社のIP Navigatorの例）
図１９にLucent Technologies社のIP Navigatorの処理概要を示す。IP Navigatorは複数のルーティングテーブルをサポートする通信プログラムであった。IP navigatorはISP(Internet Sevice Provider)向けのMPLS(MultiProtocol Label Switching)プロトコルを実装する中継装置（以下ルータという）上で動作した。
【００１７】
このIP navigatorは、LSR（ラベル・スイッチ・ルータ）において、複数の経路テーブル毎に、各ルータ間を接続するLSP（ラベル・スイッチ・パス）を対応付けることでISP（インターネット・サービス・プロバイダ）ネットワークをパーティションに分割した。そして、IP navigatorは、それぞれのパーティションを企業ユーザなどにプライベートネットワークとして提供することを目的としていた。この方式では複数のドメインに対してそれぞれ経路テーブルを持った。ただし、この方式では、任意の組み合わせのドメインが互いにアドレス変換機能を介して、通信することはできなかった。
（IPv6ルータの実装）
現在まで、代表的なネットワーク層プロトコルとしてIPプロトコル（IPversion4、以下IPv4という）が用いられてきた。さらに、IPアドレスの枯渇に対応するため、IPプロトコルの新バージョン(IPversion6、以下IPv6という)が登場した。今日、IPv4とIPv6とは混在している。一般的には、このIPv4のドメインとIPv6のドメインとは、アドレス変換装置を用いて互いに通信する。両ドメインに対応するルータとして、IPv4経路テーブルを持つIPv4ドメインとIPv6の経路テーブルを持つIPｖ6ドメインとをアドレス変換により通信可能とするものがあった（株式会社日立製作所NR60など）。
【００１８】
このようなルータは、IPv4,v6という二つのドメインに対しては複数の経路テーブルを持ち、両者の間でアドレス変換による通信が可能であった。しかし、ユーザがIPアドレス空間にさらにドメインを定義し、二つ以上のドメイン間をアドレス変換によって自由に接続することはできなかった。
（片方向NAT）
図２０に片方向NATの概要を示す。片方向NATは、プライベートアドレスとグローバルアドレスのように、ドメイン１の経路情報をドメイン２に配布できないという条件下で通信を実現した。ドメイン１はドメイン２への経路を知り得るので、ドメイン１は、ドメイン２宛のパケットを中継可能である。
【００１９】
NAT装置は、通過するパケットの送信元アドレスをドメイン２へ向いた自装置インタフェースのエイリアスアドレスに変換する。NAT装置は、アドレスを変換したパケットをドメイン２に送出するとともに、そのエイリアスアドレスと変換前の送信元アドレスを記憶する。
【００２０】
これによりドメイン２内の受信ホストは、そのエイリアスアドレスに向けて応答パケットを送信する。すなわち、ドメイン２はドメイン１への経路は知らないが変換されたNAT装置のエイリアスアドレスへは返信可能である。
【００２１】
さらに、NAT装置は、このエイリアスアドレスで受信したパケットを記憶しておいたドメイン１側の本来の送信元アドレスへ向けて再送信する。
この場合、NAT装置の経路テーブルはドメイン１とドメイン２とを混合したテーブルであった。ドメイン２からドメイン１宛のパケットをフォワーディングインタフェースで受けてしまうと経路テーブルを参照しフォワードされる可能性があった。このため、不正パケットに対するフィルタが必要であった。
（両方向NAT）
図２１に両方向NATの概要を示す。両方向NATは、IPv4ドメインとIPv6ドメインのように、ドメイン１の経路情報もドメイン２の経路情報もお互いに交換できないという条件下で通信を実現した。ドメイン１内のホストがドメイン２内のホストへ通信を開始するとき、ドメイン１内のホストは通信に先だってDNSによる名前解決を実行する。
【００２２】
ドメイン１内の解決要求はドメイン１内のDNSサーバを経由しNAT装置上の変換サーバでドメイン２内の解決要求に変換される。ドメイン２のDNSサーバから解決応答が戻ってくると、NAT装置はプールしてあるドメイン１とドメイン２とに向いたそれぞれのエイリアスアドレスを各インタフェースに設定する。そしてNAT装置は、ドメイン１の問い合わせホストにはこのドメイン１側のエイリアスアドレスを通知する。NAT装置は各エイリアスアドレスとドメイン２から受け取った解決アドレスの対応を記録しておく。
【００２３】
送信ホストはNAT装置のドメイン１側のエイリアスアドレスへ向けてパケットを送信する。NAT装置は上記の対応を用いてヘッダの送信先アドレスを、解決応答によりドメイン２のDNSから得たアドレスに、送信元アドレスをドメイン２側のエイリアスアドレスに変更する。この場合、IPv4、v6のように全くアドレス体系が異なる場合は問題ない。しかし、両ドメインがIPv4アドレス空間の一部であるような構成において、NAT装置がエイリアスアドレス以外のインタフェースアドレスで悪意のあるパケットを受信した場合、フィルタが正しく設定されていないと、NAT装置は、このパケットをフォワードする可能性があった。
（アプリケーションゲートウェイ）
アプリケーションゲートウェイを使用してもドメインを分離可能であった。図２２にアプリケーションゲートウェイの概要を示す。
【００２４】
アプリケーションゲートウェイでは、一旦ゲートウェイ上のアプリケーションプログラム４０がドメイン１からの通信を終端し、データを受け取る。さらに、このアプリケーションプログラム４０は、ドメイン２側のコネクション上に再度データを送信する。この方式では、エンドホストが使うアプリケーションに対応したアプリケーションプログラム４０をゲートウェイ上にも用意する必要があった。また、この方式では、処理が重いという問題点があった。
【００２５】
（複数ドメインに対応したアドレス変換装置）
複数ドメインに対応した中継装置も提案されている。ただ、従来の中継装置には、単一の経路テーブルが備えられていた。また、ドメイン間でアドレス変換ポリシに合致しないパケットが通過しないようにフィルタが用いられていた。単純な設定では、このような中継装置も利用できた。しかし、従来の中継装置では、管理ドメインが多数になると処理が複雑になった。また、全パケットについてドメイン間通信の判定を行う必要があった。
（問題点）
NAT等のアドレス変換の手法によれば、フォワード方向のパケット転送では、中継装置は、アドレス変換処理を施した後、経路テーブルを検索して転送を行う。中継装置は、パケットの送受信アドレスに対してフィルタを設定することで、パケットの中継の可否を判断してしていた。一方でバックワード方向のパケットに対しては、グローバルアドレスドメインに対し中継装置があたかも送信元ホストであるかのように振舞う。そして、中継装置は、エンドホストとして、中継装置にプールされていたグローバルアドレス宛のパケットを終端していた。
【００２６】
同様に、グローバルアドレスドメインから到着したプライベートアドレスドメイン宛のパケットに対して、中継装置は、パケットフィルタによりドメイン間での中継判定を行っていた。このため、万が一プライベートアドレスドメイン宛の悪意のあるパケットが中継装置に到着した場合、フィルタが正しく設定されていないと、中継装置は唯一の経路テーブルを参照し、プライベートアドレスドメインにフォワードしてしまう可能性があった。これは予期せぬ不特定多数のパケットをインターネットから受信してしまう可能性を示しており、セキュリティホールとなり得た。
【００２７】
また、複数のドメインに接続可能な中継装置において、各ドメインが同一プライベートアドレス空間を採用した場合を想定する。この場合、中継装置が、各ドメインから得られた経路情報を一つの経路テーブルに書き込んでしまうと、経路テーブルに矛盾が生じる。
【００２８】
上記のような問題に対してパケットフィルタにより、グローバルアドレスドメインからのパケットをフォワードしないよう制限することも可能であった。しかし、管理可能なドメイン数が増加すると設定が複雑になった。
【００２９】
例えば、パケットフィルタでは、入力インターフェース、出力インターフェース、送信元アドレス、宛先アドレスやL4ポート番号等をキーとしてパケットの中継を制限可能であった。しかし、多くのインターフェースを持つルータでドメインを多数接続した場合、ドメインの組み合わせ毎にフィルタ条件を設定するのは煩雑であった。また、このような構成の中継装置では、設定ミスを誘発する可能性があった。さらに、このような複雑なフィルタ処理は、中継装置の負荷となり、高速な中継処理が困難であった。
【００３０】
【発明が解決しようとする課題】
本発明はこのような従来の技術の問題点に鑑みてなされたものであり、複数のドメイン間をアドレス変換によって中継する中継装置において、ドメイン間、ドメイン内通信が混在している場合にも、ドメイン間では複雑なフィルタを設定せずにセキュリティを確保した通信を実行し、ドメイン内においては高速にパケットを中継することを技術的課題とする。
【００３１】
【課題を解決するための手段】
本発明は前記課題を解決するために、以下の手段を採用した。
すなわち、本発明は、１以上のネットワークを接続した、そのような２以上のドメイン間を中継する通信データ中継装置であって、中継元のドメインが中継先のドメインへの経路情報を有している場合、
ネットワークにアクセスするための２以上のインターフェース部と、
１以上のネットワークからなるドメインを定義するドメイン定義部と、
ドメイン間における通信の可否を定義するドメイン間通信定義部と、
通信データの中継先を示す経路情報を前記ドメインごと区分して記憶する経路情報記憶部と、
通信データの中継を制御する中継制御部とを備えたものである。この通信データ中継装置において、中継制御部は、同一ドメイン内の中継においてはそのドメインに対応する経路情報記憶部を参照して通信データの中継を制御し、異なるドメイン間の中継においては前記ドメイン間通信定義部の定義に従い中継の可否を判定する。
【００３２】
この通信データ中継装置は、中継先ドメインに対する宛先アドレス検索部をさらに備え、中継元のドメインが中継先のドメインへの経路情報を有していない場合に、宛先アドレス検索部は、中継元のドメイン内の送信元通信装置からの要求に対してその中継先のドメイン内の宛先アドレスを検索し、その宛先アドレスに対応付けられる中継元ドメイン内の中継アドレスを送信元通信装置へ通知する。
【００３３】
中継制御部は、中継アドレス宛の通信データを中継先ドメインの宛先アドレスへ中継することができる。
この宛先アドレス検索部とは、例えば通信装置のネットワーク上の名称からそのアドレスを検索するものをいう。この宛先アドレス検索部は、他の通信装置に宛先アドレスの検索を依頼するものであってもよい。
【００３４】
この通信データ中継装置は、通信データを処理する通信データ処理装置を接続したドメインへの経路制御情報記憶部をさらに備え、
前記中継制御部は、通信データの中継を制御するときに、この通信データ処理装置に通信データを処理させ、処理された通信データを中継するようにしてもよい。ここで、通信データ処理装置とは、例えば通信データの内容をチェックする装置である。
【００３５】
【発明の実施の形態】
以下、本発明の好適な実施の形態を図面を参照して説明する。
（第１実施形態）
以下、本発明の第１実施形態を図１から図１２の図面に基いて説明する。
【００３６】
図１は第１実施形態におけるネットワーク構成図であり、図２は図１に示したルータ３のハードウェア構成図であり、図３は、このルータ３の機能構成図であり、図４及び図５は、図２に示したＣＰＵ１４で実行される制御プログラムの処理を示すフローチャートであり、図６から図１２はＣＰＵ１４が取り扱うデータのデータ構造を示す図である。
＜ネットワークの構成＞
図１に第１実施形態におけるネットワーク構成図を示す。図１のように、本実施形態においては、ルータ３がイントラネットＡ、イントラネットＢ、イントラネットＣ、及びインターネットを接続している。図１のようにルータ３は、各ネットワークを論理的なインターフェースde0、de1、de2、及び、de3を介して接続する（インターフェース部に相当）。
【００３７】
イントラネットＡのプライベートアドレスは、10.25.165.0/24である。イントラネットＡは、単独でドメイン１を構成している。イントラネットＡは、ルータ３のインターフェースde1に接続されている。このイントラネットＡは、ルータ３においてアドレス変換されることにより、インターネットと接続可能である。
【００３８】
イントラネットＢのプライベートアドレスは、192.168.0.0/16である。このイントラネットＢには、通信装置192.168.5.1が接続されている。イントラネットＢは、ルータ３のインターフェースde2に接続されている。このイントラネットＢもルータ３を介してインターネットと接続可能である。
【００３９】
イントラネットＣのプライベートアドレスは、192.172.0.0/16である。イントラネットＣは、ルータ３のインターフェースde3に接続されている。このイントラネットＣもルータ３を介してインターネットと接続可能である。また、上記イントラネットＢとイントラネットＣとは、ドメイン２を構成する。
【００４０】
インターネットは、グローバルアドレスでアクセスされる。また、インターネットには、ネットワーク４と、ネットワーク５とが接続されている。さらに、インターネットは、ルータ３のインターフェースde0に接続されている。
【００４１】
ネットワーク４のグローバルアドレスは、100.10.5.0/24である。また、ネットワーク４には、通信装置100.10.5.2が接続されている。
ネットワーク５のグローバルアドレスは、150.10.23.0/24である。また、ネットワーク５には、通信装置150.10.23.5が接続されている。
【００４２】
以上のインターネット、ネットワーク４及びネットワーク５は、ドメイン０を構成している。
図１に示した各ドメインは相互にネットワーク層での到達性がない独立した経路制御を行っている。さらに本実施形態においては、ドメイン２からドメイン０及び１に対して、アドレス変換を行うことで接続が許可されている。また、ドメイン１からドメイン２への通信は許可されていない。ドメイン１からドメイン０へは、アドレス変換を行うことで接続が許可されている。
＜ルータ３のハードウェア構成＞
図２に本実施形態に係るルータ３のハードウェア構成図を示す。
【００４３】
このルータ３は、制御プログラムやデータを記憶するメモリ１３と、メモリ１３に記憶された制御プログラムを実行するＣＰＵ１４と、ＣＰＵ１４から制御されて他の通信装置と通信する複数の物理インターフェース１５ａ、１５ｂ、１５ｃとを備えている。
【００４４】
メモリ１３は、ＣＰＵ１４が実行する制御プログラムやＣＰＵ１４が処理するデータを記憶する。
ＣＰＵ１４は、メモリ１３に記憶された制御プログラムを実行し、中継装置１としての機能を提供する。
【００４５】
物理インターフェース１５ａ、１５ｂ、１５ｃは、ＣＰＵ１４からの指令により通信データをネットワーク１０に送出し、またはネットワークから通信データを受信する。
＜機能構成＞
図３にルータ３の機能の構成図を示す。ＣＰＵ１４は、中継制御プログラム３１と経路制御プログラム３０とを実行することによりルータ３の機能を提供する。また、中継制御プログラム部分は、ＣＰＵによらず、ハードウェアにより構成してもよい。
【００４６】
中継制御プログラム３１は、パケット受信部２８、経路検索部２５、ドメイン間通信判定部２６、アドレス変換部２７、及びパケット送信部２９からなる。この中継制御プログラム３１を実行するＣＰＵ１４が中継制御部に相当する。
【００４７】
一方、ＣＰＵ１４は、上記中継制御プログラム３１とは、別に経路制御プログラム３０を実行している。これにより、ＣＰＵ１４は、他の通信装置及び他のルータとの間で経路情報を交換する。
[宛先ドメイン経路テーブル２０］
宛先ドメイン経路テーブル２０は、宛先ネットワークに対応する送信先インタフェース（以下送信インターフェースという）を登録したテーブルである。
【００４８】
図８、図９及び図１０に、各々ドメイン０、ドメイン１及びドメイン２を宛先とする宛先ドメイン経路テーブル２０の例を示す。本実施形態において、宛先ドメイン経路テーブル２０は、例えば、図８に示すように宛先ネットワークのアドレス、次ホップゲートウェイのアドレス、及びその宛先ネットワークに対応する送信インターフェースを識別する情報を有している。
【００４９】
また、図８、図９及び図１０に示すように、本実施形態では宛先ドメイン経路テーブル２０は、宛先ドメインごとに独立したテーブル構造を有する。
ＣＰＵ１４は、パケットを中継する際に宛先ドメイン経路テーブル２０を参照し、出力インターフェースを決定する。
[受信インターフェースドメイン経路テーブル２１］
受信インターフェースドメイン経路テーブル２１は、パケットを受信したインターフェース（以下受信インターフェースという）に対応するドメインの経路情報を格納する。この受信インターフェースドメイン経路テーブル２１と上記宛先ドメイン経路テーブル２０とが経路情報記憶部に相当する。
[ドメイン定義テーブル２２]
ドメイン定義テーブル２２は、各インタフェースに対応するドメインを定義したテーブルである（ドメイン定義部に相当）。図６に本実施形態におけるドメイン定義テーブル２２の定義例を示す。
【００５０】
図６のように、本実施形態においては、ドメイン定義テーブル２２はインターフェースを識別する情報（インターフェース番号）とドメインを識別する情報（ドメイン番号）とを有している。例えば、インターフェース番号de0に対応するドメインは、ドメイン０である。
【００５１】
なお、インターフェースとしては、物理的なインターフェースだけでなく、論理的なインターフェースを登録してもよい。
[ドメイン間通信定義テーブル２３]
ドメイン間通信定義テーブル２３は、ドメイン定義テーブル２２で定義した各ドメインに対して、他のドメインとの接続の可否を定義したテーブルである（ドメイン間通信定義部に相当）。図７に本実施形態におけるドメイン間通信定義テーブル２３の定義例を示す。
【００５２】
図７のように、ドメイン間通信定義テーブル２３は、送信元ドメイン->宛先ドメインの指定、そのドメイン間の通信の可否、及び、変換ルール（アドレス変換の方式）の組み合わせからなるレコードで構成される。本実施形態における設定では、例えば、ドメイン０からドメイン１及びドメイン２への通信は許可されない。また、ドメイン２からドメイン０及び１への通信は許可され、かつ、変換ルールとしてＮＡＴが適用される。
[アドレス変換テーブル２４]
アドレス変換テーブル２４は、アドレス変換前後の情報を対にしたレコードからなるテーブルである。図１１に本実施形態におけるアドレス変換テーブル２４の例を示す。
【００５３】
図１１のように、アドレス変換テーブル２４は変換前後の送信元アドレス、宛先アドレス及び送受信インターフェースを１組にしたレコードから構成される。これらの情報は、送信元から宛先へのパケットが中継装置１を最初に通過するときに設定される。その後、２つ目以降のパケットの通信においては、アドレス変換テーブル２４が参照される。
[経路検索部２５］
経路検索部２５は、パケットの宛先アドレスをキーとして、経路テーブルを検索する。
[ドメイン間通信判定部２６］
ドメイン間通信判定部２６は、パケットヘッダ情報やネームサービス（通信装置のホスト名称に対応するアドレスを示すプログラム）等を用いて、宛先の通信装置がどのドメインに属するか判定する。
[アドレス変換部２７］
アドレス変換部２７は、ドメイン間通信判定部２６から、変換前後の情報（送信元アドレス、宛先アドレス）を受ける。この情報に従い、アドレス変換部２７は、パケットのヘッダ内容を変換する。
[パケット受信部２８］
パケット受信部２８は、物理インターフェース１５ａ等を監視する。そして、パケット受信部２８は、物理インターフェース１５ａ等に接続したネットワークからパケットを受信する。
[パケット送信部２９］
パケット送信部２９は、物理インターフェース１５ａ等を制御し、物理インターフェース１５ａ等に接続したネットワークへパケットを送信する。
[経路制御プログラム３０］
経路制御プログラム３０は、経路制御プロトコルを実行する。すなわち、経路制御プログラム３０は、ドメイン内に流れる経路情報１０２を受信し、受信した経路情報１０２に合わせて自ルータの経路テーブルを変更する。また、経路制御プログラム３０は、自ルータから同一ドメイン内の他ルータへのネットワーク到達性情報や接続コスト等を経路情報１０２に入れて、他ルータへ配布する。本実施形態では経路制御プログラム３０はドメイン毎に個別用意する。各経路制御プログラム３０は、各々対応するドメインと経路情報を交換する。その結果得られたドメインごとの経路情報は、宛先ドメインごとに宛先ドメイン経路テーブル２０に保存される。
【００５４】
なお、経路制御プロトコルとしては、RIP(Routing Information Protocol、インターネットに関するドキュメントRFC1058参照)、OSPF(Open Shortest Path First、RFC1131参照)等が知られている。
＜機能概要＞
以下図３に従い、ルータ３の機能概要を説明する。
（１）ルータ３はパケット受信部２８により宛先ホストを指定されたパケット１００を受信する。
（２）まず、経路検索部２５は、受信インタフェースが属するドメインへの経路テーブル（受信インターフェースドメイン経路テーブル２１）を検索する。受信インターフェースドメイン経路テーブル２１の検索がヒットした場合、経路検索部２５は、ドメイン内ルーティングとして中継する。すなわち、経路検索部２５はパケット送信部２９に指示し、出力インタフェースにパケットを出力させる。
【００５５】
受信インタフェースドメイン経路テーブル２１の検索がヒットしない場合、（３）以下に示す手順が実行される。
（３）ドメイン間通信判定部２６は、受信したパケットのヘッダ情報、受信インタフェースなどをキーとしてアドレス変換テーブルを順引き、逆引きで検索する。 順引き、逆引きのどちらかで検索がヒットした場合は、ドメイン間通信判定部２６は、アドレス変換手段にパケットを渡す。
【００５６】
検索がヒットしない場合、ドメイン間通信判定部２６は、パケットのヘッダ情報、宛先ドメイン経路テーブル２０及びドメイン定義テーブル２２から受信したパケットの宛先アドレスがどのドメインに属するかを調べる。次に、ドメイン間通信判定部２６は、ドメイン定義テーブル２２に登録された受信インターフェースが属するドメインを調べる。次に、ドメイン間通信判定部２６は、ドメイン間通信定義テーブル２３を参照し、受信インタフェースが属するドメインと宛先ドメインとの間の通信の可否を判断する。なお、ドメイン間通信定義テーブル２３にはアドレス変換ルールも示されている。
（４）ドメイン間通信判定部は、受信インタフェースが属するドメインと宛先ドメインとの通信が可能な場合は、宛先ドメイン経路テーブル２０を参照するよう経路検索部２５に通知する。
（５）経路検索部２５は、ドメイン間通信判定部２６から起動され、宛先ドメイン経路テーブル２０を検索する。この検索では、パケットヘッダ情報の宛先アドレスをキーとして使用する。
（６）アドレス変換部２７はパケットに対しドメイン間通信定義テーブル２４に記された変換ルールに従いパケットヘッダ情報を変換する。
（７）パケット送信部２９は、検索された出力インタフェースにパケットを出力する。
（８）経路制御プログラム３０は各ドメイン毎に起動し、各ドメインへの宛先ドメイン経路テーブル２０及び受信インターフェースドメイン経路テーブル２１を修正する。
＜通常処理＞
以下に、本実施形態におけるネットワーク間の接続条件を示す。
［接続条件１］イントラネットA(10.25.165.0)はルータ３によりアドレス変換されることでインタネットと通信可能である。
［接続条件２］イントラネットB(192.168.0.0)はルータ３を通してブランチオフィスであるイントラネットC(192.172.0.0)と接続される。
［接続条件３］イントラネットB,Cは共にルータ３を介してインターネットに接続可能である。
【００５７】
図４及び図５に上記接続を実現するための中継制御プログラム３１の処理を示す。この中継制御プログラム３１は、ＣＰＵ１４において実行される。
まず、順方向の通信（送信元通信装置から宛先通信装置へのパケット送信）に対する処理を説明する。
（１）ルータ３でのパケット受信
今、ルータ３が、インターフェースde2を介して、ドメイン２に属するネットワーク192.168.100.０からパケットを受信した場合の処理を説明する。このパケットの宛先アドレスは、100.10.5.2、送信元アドレスは、192.168.5.1である。
（２）自局宛てパケット判定
まず、ルータ３のＣＰＵ１４は、このパケットがルータ３そのものへ宛てられた（以下自局宛てという。自局宛を自ノード宛ともいう）パケットか否かを判定する（ステップＳ１、以下Ｓ１と略す）。自局宛てパケットは、ルータ３自身への通信パケットととして処理される（Ｓ３）。
【００５８】
本実施形態では、自局宛てパケットは、ルータ３への環境設定パケットである。この環境設定パケットは、ネットワーク管理者がルータ３にリモートログインすることで発せられる。ルータ３の環境設定そのものに関する説明は省略する。
【００５９】
今、パケットは、環境設定パケットではないため、Ｓ２の判定は、Noである。従って、ＣＰＵ１４は、処理をドメイン内通信判定（Ｓ４）に進める。
（３）ドメイン内通信判定
次に、ＣＰＵ１４は、このパケットが同一ドメイン内の宛先に宛てられているか否かを判定する（Ｓ４）。この判定では受信インタフェースが属するドメイン宛の宛先経路テーブル（受信インターフェースドメイン経路テーブル２１）を検索する。その検索がヒットした場合は（Ｓ５の判定でYesの場合）、受信インターフェースに対応する送信元ドメインと宛先ドメインとが同一であることを意味する。すなわち、同一ドメイン内でパケットを中継すればよい（Ｓ６）。
【００６０】
ヒットしなかった場合（Ｓ５の判定でNoの場合）は、ドメイン間通信判定部２６に処理を渡す（Ｓ７）。この例では、同一ドメイン内の通信でないため、ＣＰＵ１４は制御をＳ７の処理に進める。
（４）ドメイン間通信判定部２６、アドレス変換部２７、及びパケット送信部２９の処理
ドメイン間通信判定部２６では、受信したパケットの宛先アドレス、送信元アドレスをキーとして図１１のアドレス変換テーブル２４を検索する。アドレス変換テーブル２４の検索がヒットした場合は（Ｓ８の判定でYesの場合）、検索結果とともにパケットがアドレス変換部２７に送られる（Ｓ９）。これは順方向通信でアドレス変換すべきパケットであることを示している。アドレス変換部２７では、与えられた検索結果を元にパケットのヘッダを書き換える。また、ＣＰＵ１４は、アドレス変換テーブル２４（図１１）から送信インターフェースを求める。
【００６１】
次に、ＣＰＵ１４は、パケット送信部２９に制御を移し、パケットを上記送信インターフェースからネットワークに送信する（Ｓ１１）。
この検索がヒットしない場合は（Ｓ８の判定でNoの場合）、ＣＰＵ１４は、図５に示す処理に制御を移す。すなわち、ＣＰＵ１４は、パケットの宛先アドレスをアドレス変換テーブル２４における変換後の送信元アドレスとして、パケットの送信元アドレスをアドレス変換テーブル２４における変換後の宛先アドレスとして、アドレス変換テーブル２４を検索する（Ｓ１２）。
【００６２】
ここで、検索がヒットした場合は（Ｓ１３の判定でYesの場合）、ＣＰＵ１４は、パケットが順方向通信に対する応答通信（逆方向通信）のパケットであると判断する。そこで、ＣＰＵ１４は、検索された内容と共にパケットをアドレス変換部２７に渡す。さらにＣＰＵ１４は、アドレス逆変換を指示する（Ｓ１４）。その結果、ＣＰＵ１４は、パケットの宛先をアドレス変換テーブルにおける変換前の送信元アドレスに書き換える。また、ＣＰＵ１４は、アドレス変換テーブル２４から返信先インターフェース（図１１の受信インターフェース）を求める。
【００６３】
次に、ＣＰＵ１４は、パケット送信部２９に制御を移し、パケットを上記送信インターフェースからネットワークに送信する（Ｓ１６）。
どちらにもヒットしない場合は（Ｓ１３の判定でNoの場合）、ＣＰＵ１４は、ドメインをまたがる通信を行うかどうかを判断する（Ｓ１７及びＳ１８の処理）。これは新たにドメイン間通信を開始する場合に必要な処理である。
【００６４】
すなわち、ＣＰＵ１４は、宛先アドレスをキーとして宛先ドメイン経路テーブル２０の全体を検索して、送信インターフェースを求める。
今、宛先アドレスが、100.10.5.2であるので、ＣＰＵ１４は、送信インターフェースとしてde0を得る。次にＣＰＵ１４は、この送信インターフェースをキーとしてドメイン定義テーブル２２を検索して宛先ドメインを求める。今、送信インターフェースがde0であるので、ＣＰＵ１４は、宛先ドメインとしてドメイン0を得る。さらに、ＣＰＵ１４は、受信インターフェースをキーとして、ドメイン定義テーブル２２を検索する。ＣＰＵ１４は、パケットを受信したインタフェース番号とドメイン定義テーブル２２（図６）とから、ＣＰＵ１４は、送信元ドメインとしてドメイン２を得る（Ｓ１７）。
【００６５】
次に、ＣＰＵ１４は、得られた送信元ドメイン及び宛先ドメインをキーとして、図７のドメイン間通信定義テーブル２３を検索する（Ｓ１８）。
今、この検索はヒットするので（Ｓ１９でYesの場合）、両ドメインの接続が許可されていることが分かる。また、NATによるアドレス変換が指定されていることが分かる。
【００６６】
本実施例形態で実現するNATでは送信元アドレスのみが変換される。この変換には、宛先ドメインごとにプールされているIPアドレスが使用される
このとき、ＣＰＵ１４は、図１１のアドレス変換テーブル２４に、変換前のアドレスと変換後のアドレスを対応させて登録する（Ｓ２０）。
【００６７】
また、ＣＰＵ１４は、受信インターフェース、送信インターフェースもアドレス変換テーブル２４に登録する（Ｓ２１）。
次に、ＣＰＵ１４は、パケット送信部２９に制御を移し、パケットを上記送信インターフェースからネットワークに送信する（Ｓ２２）。
【００６８】
Ｓ１８の判定において、２つのドメイン間の接続が不許可の場合は（Ｓ１９の判定でNoの場合）、ＣＰＵ１４は、パケットを廃棄する（Ｓ２３）。
＜効果＞
以上によれば順方向、逆方向ともにドメイン間通信判定部２６により許可されたパケットのみが宛先ドメイン経路テーブル２４を参照可能となるため、悪意のあるパケットを誤って中継してしまうことを回避できる。
【００６９】
また、本実施形態のルータ３では、宛先ドメインごとに経路テーブルを分離し、かつ、パケットを受信した段階で受信インタフェースドメイン経路テーブル２１を優先的に参照する。このため、受信インタフェースに対応するドメイン宛のパケット（同一ドメイン内の宛先に対するパケット）に対しては、経路テーブルの検索は、そのドメインに対応する経路テーブル（受信インタフェースドメイン経路テーブル２１）に限定される。その結果、同一ドメイン宛パケットの中継が効率化される。
【００７０】
一方、インターネットからイントラネットに侵入する悪意のあるパケットを排除するためのドメイン間通信判定部２６の処理は、上記のような同一ドメイン宛以外のパケットに対して実行すればよい。
＜変形例＞
上記第１実施形態においては、宛先ドメイン経路テーブル２０と受信インターフェース経路テーブル２１とが異なるテーブルとして構成された。しかし、本発明の実施は、このような構成に限定されるものではない。例えば、受信インターフェース経路テーブル２１を宛先ドメイン経路テーブル２０の一部として構成してもよい。ただし、上記第１実施形態と同様に、宛先ドメイン経路テーブル２０は、各宛先ドメイン毎に論理的に独立したテーブル構造を有するものとする。
【００７１】
この場合は、パケット受信部でパケットを受信した際、パケットを受信したインターフェースをキーとして、ドメイン定義テーブルを検索し、受信ドメインを決定し、適するドメイン経路テーブルを選択する。
【００７２】
上記第１実施形態では、経路制御プログラム３０は、各宛先ドメイン毎に個別に用意した。しかし、本発明の実施は、このような構成には、限定されない。例えば、１つの経路制御プログラム３０（経路制御プロトコルを実行するＣＰＵ１４上の１つのプロセス）を備えてもよい。その場合、このプログラムが宛先ドメインごとに経路情報を交換する処理を順次繰り返すようにすればよい。
【００７３】
上記第１実施形態では、ルータ３は、論理的なインターフェースde0、de1、またはde2をドメインに対応付けた 。しかし、本発明の実施は、このような構成には、限定されない。例えば、論理的なインターフェースde0等を使用せず、直接物理インターフェース１５ａ、１５ｂ、または１５ｃを各ドメインに対応付けてもよい。この場合は、物理インターフェース１５ａ等がインターフェース部に相当する。
【００７４】
上記実施形態においては、宛先ドメイン経路テーブル２０は、図８から図１０のように宛先ドメインごとに分離して構成した。しかし、本発明の実施は、このような構成に限定されない。例えば、図１２に示したように単一のテーブルで宛先ドメイン経路テーブル２０を構成しても、テーブルを構成するレコードが宛先ドメインごとに分離されていればよい。
【００７５】
上記実施形態の中継装置１では、ドメイン間で最初に通信されるパケットの宛先アドレスに基づき、全ての宛先ドメイン経路テーブルの全体を検索して出力インターフェースを求めた。そして、その出力インターフェースから宛先ドメインを決定し、送信元ドメインと宛先ドメインとのドメイン間の接続の可否を判定した（図５のＳ１７及びＳ１８の処理）。しかし、本発明の実施はこのような処理手順には限定されない。すなわち、宛先ドメイン経路テーブル間で、アドレスに重複がある場合を考慮し、Ｓ１８の処理を先に行てもよい。まず、ドメイン間通信定義テーブル２３を検索し、通信が許可されている受信ドメインを決定しておく。そして、そのような通信が許可されているドメインの経路テーブルのみを検索し、出力インターフェースを求めることも可能である（図５においてＳ１８の処理を先に実行し、Ｓ１７の処理を後から実行することに相当する）。
（第２実施形態）
図１３から図１７を参照して、本発明の第２実施形態を説明する。図１３は、本実施形態のネットワーク構成図であり、図１４は本実施形態に係るルータ３の機能構成図であり、図１５は、ルータ３のＣＰＵ１４で実行されるアドレス事前登録部２５の処理を示すフローチャートであり、図１６はアドレス事前登録部２５の処理結果を示す図であり、図１７はルータ３のＣＰＵ１４で実行される中継制御プログラム３１の処理を示す図である。
【００７６】
上記第１実施形態では、宛先ドメイン経路テーブル２０及び受信インターフェースドメイン経路テーブル２１を備えたルータ３を説明した。この場合、上記第１実施形態では、ドメイン２においては、ドメイン０への経路が既知であった。
【００７７】
本実施形態では、ルータ３に接続される２つのドメインにおいて互いに相手の経路が不明である場合の中継処理を説明する。ただし、送信元ドメインは相手ドメインのホスト名から相手ドメイン内のアドレスを知る手段があるものとする。他の構成及び作用については、第１形態と同様であるので、同一の構成については、同一の符号を付してその説明を省略する。また、必要に応じて図１から図１２の図面を参照する。
＜構成＞
図１３に本実施形態に係るネットワーク構成図を示す。本実施形態では、互いに相手への経路が不明なドメイン０とドメイン２とを接続するルータ３を説明する。
【００７８】
図１３のようにドメイン０には、sub1.0の名称で示されるネットワーク４が含まれている。また、ネットワーク４には、ホスト名n0.sub1.0のホストが接続されている。このホストn0.sub1.0のアドレスは、100.10.5.2である。
【００７９】
また、ドメイン２には、アドレス192.168.5.1で示されるホストが接続されている。ドメイン０とドメイン２とは、互いに相手ドメインへの経路が不明である。ただし、本実施形態では、ドメイン２のホスト192.168.5.1は、宛先ホストのホスト名n0.sub1.0を知っているものとする。
【００８０】
このような場合、本実施形態においては、送信元ホスト192.168.5.1は、ルータ３に対して宛先の名称に対応するアドレスを問い合わせることができる。
図１４に本実施形態におけるルータ３の機能構成を示す。図１４の構成は、アドレス変換事前登録部２５（アドレス検索部に相当）が追加されている点で、図３に示した第１実施形態の構成と相違する。
【００８１】
アドレス変換事前登録部２５は、事前にアドレス変換テーブル２４に変換前後の情報を登録する機能を有する。
＜アドレス変換事前登録部２５における処理＞
以下、送信元ホスト192.168.5.1が、ルータ３に宛先のホスト名称に対応する宛先アドレスを問い合わせた場合の処理を説明する。
【００８２】
図１５にルータ３のＣＰＵ１４が実行するアドレス変換事前登録部２５の処理を示す。まず、ＣＰＵ１４は、ネームサービス（ＲＦＣ９２１）を実行する不図示のサーバにその宛先のホスト名称n0.sub1.0に対応するドメイン0内のアドレスを問い合わせる（Ｓ４１）。その結果、ＣＰＵ１４は、宛先ホストのアドレス100.10.5.2を得る。
【００８３】
次に、ＣＰＵ１４は、宛先ホストのドメイン番号0に基づき、宛先ドメインごとに区分された宛先ドメイン経路テーブル２０を検索し、出力インターフェースde0を求める（Ｓ４２）。
【００８４】
次にＣＰＵ１４は、上記第１実施形態と同様に受信インターフェースde2の属するドメイン２を求める（Ｓ４３）。
次にＣＰＵ１４は、２つドメイン間の接続可否（ドメイン２からドメイン０への接続可否）をドメイン間通信定義テーブル２３に従って判定する（Ｓ４４）。２つのドメイン間の通信が認められない場合（Ｓ４４の判定でNoの場合）、ルータ３は、その旨を送信元192.168.5.1へ通知する（Ｓ４５）。
【００８５】
一方、ドメイン２からドメイン０への通信が認められる場合（Ｓ４４の判定でYesの場合）、ＣＰＵ１４は、予めプールしておいたドメイン２におけるエイリアスアドレス192.168.5.2を求める（Ｓ４６）（以下、このエイリアスアドレスを受信インターフェースアドレスと呼ぶ）。また、ＣＰＵ１４は、予めプールしておいたドメイン０におけるエイリアスアドレス120.10.4.2を求める（以下、このエイリアスアドレスを送信インターフェースアドレスと呼ぶ）。
【００８６】
そして、ＣＰＵ１４は、送信元アドレス192.168.5.1、受信インターフェースアドレス192.168.5.2、受信インターフェースde2、送信インターフェースアドレス120.10.4.2、宛先アドレス100.10.5.2、送信インターフェースde0をアドレス変換テーブル２４に登録する（Ｓ４７）。この登録された結果を図１６に示す。
【００８７】
次に、ルータ３は、送信元192.168.5.1に対し、本受信インタフェースアドレス192.168.5.2を予め通知する（Ｓ４８）。これによって、送信元192.168.5.1は、その受信インタフェースアドレス192.168.5.2にパケットを送信すれば、所望の宛先ホストn0.sub1.0にパケットを送信できることを知る。
【００８８】
以上の処理は、通信に先だって、送信元192.168.5.1とルータ３との間で実行される。このような設定の後、上記受信インターフェースアドレス192.168.5.2宛のパケットを受信したルータ３は、アドレス変換テーブル２４に従い、宛先をアドレス100.10.5.2に変換し、出力インターフェースde0から送信する。この結果パケットは、ドメイン２からドメイン０に中継される。
＜受信インターフェースアドレスによる接続処理＞
図１７に受信インターフェースアドレスによる接続処理のフローチャートを示す。この処理は、ルータ３のＣＰＵ１４が、中継制御プログラム３１として実行する。
（１）パケット受信
今、ルータ３が、インターフェースde2を介して、ドメイン２に属するネットワーク192.168.0.0からパケットを受信した場合の処理を説明する。このパケットの宛先アドレスは、192.168.5.2（上記受信インターフェースアドレス）、送信元アドレスは、192.168.5.1である。
（２）自局宛てパケット判定
まず、ルータ３のＣＰＵ１４は、このパケットが自局宛てパケットか否かを判定する（Ｓ１）。
【００８９】
本実施形態で、自局宛てパケットとは、ルータ３自身へのへの環境設定パケット、または上記通知した受信インターフェースアドレス宛のパケットである。
今、パケットは、受信インターフェースアドレス宛のパケットであるため、Ｓ２の判定は、Yesである。従って、ＣＰＵ１４は、制御をＳ３１以下の処理に進める。
（３）自局あてパケット処理
次に、ＣＰＵ１４は、送信元アドレス192.168.5.1と宛先アドレス192.168.5.2とをキーにしてアドレス変換テーブル２４を検索する（Ｓ３１）。
【００９０】
上記２つのアドレスの組み合わせは、アドレス変換テーブル２４に登録済みであるので（図１６参照）、この検索はヒットする（Ｓ３２の判定でYesとなる）。そこでＣＰＵ１４は、Ｓ３３以下の処理に制御を進める。
【００９１】
すなわち、ＣＰＵ１４は、アドレス変換部２７を実行する（Ｓ３３）。その結果、受信インターフェースアドレス192.168.5.2に対応するドメイン０内の宛先アドレス100.10 5.2及び送信インターフェースde0が求められる。
【００９２】
次にＣＰＵ１４は、パケット送信部２９を実行し、上記宛先100.10 5.2に送信インターフェースde0からパケットを送信する。
（４）パケット返信処理
上記宛先100.10 5.2からの返信パケットの処理は、第１実施形態で説明した図５のフローチャートのＳ１２からＳ１６の処理と同様であるので、その説明を省略する。
【００９３】
以上のように互いに経路情報を交換しない２つのドメイン間に対しても、ルータ３にアドレス変換事前登録部２５を備えることで本発明の実施は可能である。
また、本実施形態のルータ３では、宛先ドメイン経路テーブル２０を宛先ドメインごとに分離して構成する。従って、複数のドメイン間でプライベートアドレスが重複する場合でも、アドレス事前登録部２５は、適切な出力インターフェースを宛先ドメイン経路テーブル２０から求めることができる。
＜変形例＞
上記第２実施形態においては、互いに経路情報を交換しない２つのドメイン間を接続するルータ３を説明した。しかし、本発明の実施は、このようなドメイン間の接続に限定されない。すなわち、中継される２つのドメインの一方のみが、他方への経路情報を有していない場合にも本発明は同様に実施できる。つまり、中継先ドメインへの経路情報を有していないドメインから中継先へ通信する場合に、第２実施形態で説明したルータ３は、上記同様にパケットを中継できる。
（第３実施形態）
上記第１実施形態では、宛先ドメイン経路テーブル２０及び受信インターフェースドメイン経路テーブル２１を備えたルータ３を説明した。
【００９４】
本実施形態では、上記第１実施形態の構成おいて、アドレス変換部２７の提供する機能の一部（コンテンツチェック）を他のドメイン上のサーバ（通信データ処理装置に相当）に実行させるルータ３について説明する。
【００９５】
図１８を参照して、本発明の第３実施形態を説明する。図１８は、本実施形態に係るルータ３の機能構成図である。図１８は、サーバドメイン経路テーブル３１及びコンテンツチェックサーバ３２が付加されている点で第１実施形態の図３と相違する。他の構成及び作用については、第１実施形態及び第２実施形態と同様であり、同一の構成については、同一の符号を付してその説明を省略する。また、必要に応じて、図１から図１７の図面を参照する。
【００９６】
図１８のように、本実施形態のルータ３のＣＰＵ１４は、サーバへの経路情報を保持するサーバドメイン経路テーブル３１を備えている。ＣＰＵ１４は、このサーバドメイン経路テーブル３１を検索する。この検索結果に従い、ＣＰＵ１４は中継するパケットのアドレスをコンテンツチェックサーバ３２宛に変換して送信する。次にＣＰＵ１４は、コンテンツチェックが終わったパケットを受信する。次にＣＰＵ１４は、そのパケットをアドレス逆変換し、本来の宛先ドメインへアドレス変換する。
【００９７】
このようにコンテンツチェックをコンテンツチェックサーバ３２に実行させることにより、ルータ３の負荷が低減され、高速な中継処理が実現される。
【００９８】
【発明の効果】
以上説明したように、本発明によれば、１以上のネットワークを接続した、そのような２以上のドメイン間を中継する通信データ中継装置であって、
１以上のネットワークからなるドメインを定義するドメイン定義部と、
ドメイン間における通信の可否を定義するドメイン間通信定義部と、
通信データの中継先を示す経路情報を前記ドメインごと区分して記憶する経路情報記憶部とを備え、同一ドメイン内の中継においてはそのドメインに対応する経路情報記憶部を参照して通信データの中継を制御し、異なるドメイン間の中継においては前記ドメイン間通信定義部の定義に従い中継の可否を判定する。従って、ドメイン間、ドメイン内通信が混在している場合にも、ドメイン内においては高速にパケットを中継し、ドメイン間では複雑なフィルタを設定せずにセキュリティを確保した通信を実行することができる。
【図面の簡単な説明】
【図１】本発明の第１実施形態におけるネットワーク構成図
【図２】本発明の第１実施形態におけるルータのハードウェア構成図
【図３】本発明の第１実施形態におけるルータの機能構成図
【図４】制御プログラムの処理を示すフローチャート（１）
【図５】制御プログラムの処理を示すフローチャート（２）
【図６】ドメイン定義テーブルのデータ構造を示す図
【図７】ドメイン間通信定義テーブルのデータ構造を示す図
【図８】宛先ドメイン経路テーブルのデータ構造を示す図（１）
【図９】宛先ドメイン経路テーブルのデータ構造を示す図（２）
【図１０】経路テーブルのデータ構造を示す図（３）
【図１１】アドレス変換テーブルのデータ構造を示す図
【図１２】実際の経路テーブルのデータ構造例を示す図
【図１３】本発明の第２実施形態におけるネットワーク構成図
【図１４】本発明の第２実施形態におけるルータの機能構成図
【図１５】アドレス事前登録部の処理を示すフローチャート
【図１６】アドレス事前登録部によるアドレス変換テーブルへの登録結果
【図１７】受信インターフェースアドレスによる中継処理を示すフローチャート
【図１８】本発明の第３実施形態におけるルータの機能構成図
【図１９】従来技術ＬＳＰ（ラベル・スイッチ・パス）の概要
【図２０】従来技術片方向ＮＡＴの概要
【図２１】従来技術両方向ＮＡＴの概要
【図２２】従来技術アプリケーションゲートウェイの概要
【符号の説明】
３ ルータ
１３ ＣＰＵ１
１４ メモリ
１５ａ 物理インターフェース
１５ｂ 物理インターフェース
１５ｃ 物理インターフェース
２０ 宛先ドメイン経路テーブル
２１ 受信インターフェース経路テーブル
２２ ドメイン定義テーブル
２３ ドメイン間通信定義テーブル
２４ アドレス変換テーブル
Claims (3)
- １以上のネットワークからなる、そのような２以上のドメイン間を中継する通信データ中継装置であって、中継元のドメインが中継先のドメインへの経路情報を有している場合、
前記ネットワークにアクセスするための２以上のインターフェース部と、
１以上のネットワークからなるドメインを定義するドメイン定義部と、
ドメイン間における通信の可否を定義するドメイン間通信定義部と、
通信データの中継先を示す経路情報を前記ドメインごと区分して記憶する経路情報記憶部と、
通信データの中継を制御する中継制御部とを備え、
前記中継制御部は、同一ドメイン内の中継においてはそのドメインに対応する経路情報記憶部を参照して通信データの中継を制御し、異なるドメイン間の中継においては前記ドメイン間通信定義部の定義に従い中継の可否を判定する通信データ中継装置。 - 前記通信データ中継装置は中継先ドメインに対する宛先アドレス検索部をさらに備え、中継元のドメインが中継先のドメインへの経路情報を有していない場合に、
前記宛先アドレス検索部は、中継元のドメイン内の送信元通信装置からの要求に対してその中継先のドメインへの宛先アドレスを検索し、その宛先アドレスに対応付けられる中継元ドメイン内の中継アドレスを送信元通信装置へ通知し、
前記中継制御部は、前記中継アドレス宛の通信データを前記中継先ドメインの宛先アドレスへ中継する請求項１記載の通信データ中継装置。 - 通信データを処理する通信データ処理装置を接続したドメインへの経路制御情報記憶部をさらに備え、
前記中継制御部は、通信データの中継を制御するときに、前記通信データ処理装置に通信データを処理させ、処理された通信データを中継する請求項１記載のの通信データ中継装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000102702A JP4236364B2 (ja) | 2000-04-04 | 2000-04-04 | 通信データ中継装置 |
| US09/825,178 US7574522B2 (en) | 2000-04-04 | 2001-04-03 | Communication data relay system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000102702A JP4236364B2 (ja) | 2000-04-04 | 2000-04-04 | 通信データ中継装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001292163A JP2001292163A (ja) | 2001-10-19 |
| JP4236364B2 true JP4236364B2 (ja) | 2009-03-11 |
Family
ID=18616532
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000102702A Expired - Fee Related JP4236364B2 (ja) | 2000-04-04 | 2000-04-04 | 通信データ中継装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7574522B2 (ja) |
| JP (1) | JP4236364B2 (ja) |
Families Citing this family (42)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7054328B2 (en) * | 2001-07-23 | 2006-05-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Signal transfer point with internet protocol capability within a telecommunications network |
| US7586940B1 (en) * | 2001-07-24 | 2009-09-08 | Cisco Technology, Inc. | Forwarding packets in a gateway performing network address translation (NAT) |
| KR100424457B1 (ko) * | 2001-08-29 | 2004-03-26 | 삼성전자주식회사 | 디지털 가입자 회선 가입자측 단말장치의 인터넷 프로토콜패킷 필터링방법 |
| JP2003087297A (ja) * | 2001-09-13 | 2003-03-20 | Toshiba Corp | パケット転送装置およびパケット転送方法 |
| US7039052B2 (en) * | 2001-09-19 | 2006-05-02 | International Business Machines Corporation | Selective routing of multi-recipient communications |
| US7533183B1 (en) * | 2001-12-28 | 2009-05-12 | Nortel Networks Limited | Central control of multiple address domains within a router |
| US7356031B1 (en) * | 2002-02-01 | 2008-04-08 | Cisco Technology, Inc. | Inter-v4 realm routing |
| JP2004040476A (ja) * | 2002-07-03 | 2004-02-05 | Mitsubishi Electric Corp | アドレス変換装置 |
| JP2004120534A (ja) * | 2002-09-27 | 2004-04-15 | Matsushita Electric Ind Co Ltd | ルータと中継装置、フォワーディング方法 |
| US7760729B2 (en) * | 2003-05-28 | 2010-07-20 | Citrix Systems, Inc. | Policy based network address translation |
| US7924725B2 (en) * | 2003-11-10 | 2011-04-12 | Nortel Networks Limited | Ethernet OAM performance management |
| US20050198352A1 (en) * | 2004-02-23 | 2005-09-08 | Nokia Corporation | Automated data migration |
| WO2005101217A1 (ja) * | 2004-04-14 | 2005-10-27 | Nippon Telegraph And Telephone Corporation | アドレス変換方法、アクセス制御方法、及びそれらの方法を用いた装置 |
| US20050271047A1 (en) * | 2004-06-02 | 2005-12-08 | Huonder Russell J | Method and system for managing multiple overlapping address domains |
| US8462808B2 (en) * | 2004-09-02 | 2013-06-11 | Brother Kogyo Kabushiki Kaisha | Information server and communication apparatus |
| EP1672849B1 (fr) * | 2004-12-16 | 2011-10-19 | France Telecom | Procédé d'exploitation d'un réseau informatique local relié à un réseau distant privé par un tunnel IPsec |
| US7535926B1 (en) * | 2005-01-07 | 2009-05-19 | Juniper Networks, Inc. | Dynamic interface configuration for supporting multiple versions of a communication protocol |
| JP4482465B2 (ja) * | 2005-02-09 | 2010-06-16 | 株式会社エヌ・ティ・ティ・ドコモ | 中継装置、端末装置、通信システムおよび通信制御方法 |
| CN1878126A (zh) * | 2005-06-07 | 2006-12-13 | 华为技术有限公司 | 通信网络中实现信令代理的方法 |
| US8966113B2 (en) * | 2006-03-03 | 2015-02-24 | Cisco Technology, Inc. | Technique for dynamically restoring original TE-LSP attributes for interdomain TE-LSPs |
| JP4630225B2 (ja) * | 2006-05-15 | 2011-02-09 | 富士通株式会社 | 通信制御システム |
| US7983164B2 (en) * | 2006-12-01 | 2011-07-19 | Electronics And Telecommunications Research Institute | Apparatus and method for merging internet traffic mirrored from multiple links |
| WO2008111206A1 (ja) | 2007-03-15 | 2008-09-18 | Fujitsu Limited | 中継ノード |
| WO2008129637A1 (ja) * | 2007-04-12 | 2008-10-30 | Fujitsu Limited | シグナリング装置及びシグナリング方法 |
| US7924810B2 (en) * | 2007-06-21 | 2011-04-12 | Hewlett-Packard Development Company, L.P. | Method and computing system for controlling access |
| US8028090B2 (en) * | 2008-11-17 | 2011-09-27 | Amazon Technologies, Inc. | Request routing utilizing client location information |
| JP5051238B2 (ja) * | 2007-11-13 | 2012-10-17 | 富士通株式会社 | 制御代理装置 |
| JP4667473B2 (ja) * | 2008-01-15 | 2011-04-13 | 日本電信電話株式会社 | データ中継装置、データ中継方法およびデータ中継プログラム |
| US20100124220A1 (en) * | 2008-11-18 | 2010-05-20 | Morris Robert P | Method And Systems For Incrementally Resolving A Host Name To A Network Address |
| JP5672779B2 (ja) * | 2010-06-08 | 2015-02-18 | ソニー株式会社 | 送信制御装置、および送信制御方法 |
| KR101300245B1 (ko) * | 2010-12-03 | 2013-08-26 | 한국전자통신연구원 | 프로세스 통신을 지원하는 서버 및 그의 동작 방법 |
| WO2012094602A1 (en) * | 2011-01-07 | 2012-07-12 | Interdigital Patent Holdings, Inc. | Client and server group sso with local openid |
| US9716619B2 (en) | 2011-03-31 | 2017-07-25 | NextPlane, Inc. | System and method of processing media traffic for a hub-based system federating disparate unified communications systems |
| CN102959906B (zh) * | 2011-04-08 | 2015-04-15 | 华为技术有限公司 | 多归属站点内主机的路由选择方法和装置 |
| JP5440574B2 (ja) * | 2011-08-31 | 2014-03-12 | ブラザー工業株式会社 | ノード装置、情報通信方法及びプログラム |
| US20130308496A1 (en) * | 2012-05-21 | 2013-11-21 | Broadcom Corporation | System and Method for Generic Multi-Domain Network Pruning |
| JP6127618B2 (ja) * | 2013-03-15 | 2017-05-17 | 株式会社リコー | 情報処理装置、情報処理システム、中継方法およびプログラム |
| US20140359457A1 (en) * | 2013-05-30 | 2014-12-04 | NextPlane, Inc. | User portal to a hub-based system federating disparate unified communications systems |
| KR20150006747A (ko) * | 2013-07-09 | 2015-01-19 | 한국전자통신연구원 | 식별자/위치자 분리 환경에서의 패킷 포워딩 방법 및 장치 |
| JP6340875B2 (ja) * | 2014-03-31 | 2018-06-13 | 沖電気工業株式会社 | 中継装置 |
| US9819573B2 (en) * | 2014-09-11 | 2017-11-14 | Microsoft Technology Licensing, Llc | Method for scalable computer network partitioning |
| US10210347B2 (en) * | 2015-06-22 | 2019-02-19 | Symantec Corporation | Techniques for managing privacy of a network communication |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5493607A (en) * | 1992-04-21 | 1996-02-20 | Boston Technology | Multi-system network addressing |
| JP3446047B2 (ja) | 1994-07-26 | 2003-09-16 | 日本電信電話株式会社 | マルチメディアサービスアクセス方法及びマルチメディアサービスアクセス方式 |
| US5684800A (en) * | 1995-11-15 | 1997-11-04 | Cabletron Systems, Inc. | Method for establishing restricted broadcast groups in a switched network |
| US7272625B1 (en) * | 1997-03-10 | 2007-09-18 | Sonicwall, Inc. | Generalized policy server |
| US6345299B2 (en) * | 1997-11-26 | 2002-02-05 | International Business Machines Corporation | Distributed security system for a communication network |
| JP3859369B2 (ja) * | 1998-09-18 | 2006-12-20 | 株式会社東芝 | メッセージ中継装置及び方法 |
| US6192051B1 (en) * | 1999-02-26 | 2001-02-20 | Redstone Communications, Inc. | Network router search engine using compressed tree forwarding table |
| US6952401B1 (en) * | 1999-03-17 | 2005-10-04 | Broadcom Corporation | Method for load balancing in a network switch |
| US7139838B1 (en) * | 1999-10-21 | 2006-11-21 | Nortel Networks Limited | Apparatus and method of distributing routing information |
| US7016980B1 (en) * | 2000-01-18 | 2006-03-21 | Lucent Technologies Inc. | Method and apparatus for analyzing one or more firewalls |
| US6615273B1 (en) * | 2000-01-20 | 2003-09-02 | Lucent Technologies Inc. | Method for performing enhanced target identifier (TID) address resolution |
-
2000
- 2000-04-04 JP JP2000102702A patent/JP4236364B2/ja not_active Expired - Fee Related
-
2001
- 2001-04-03 US US09/825,178 patent/US7574522B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US7574522B2 (en) | 2009-08-11 |
| JP2001292163A (ja) | 2001-10-19 |
| US20020023152A1 (en) | 2002-02-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4236364B2 (ja) | 通信データ中継装置 | |
| JP7004405B2 (ja) | 仮想ネットワークにおける分散型フロー状態ｐ２ｐ設定のためのシステムおよび方法 | |
| EP1164754B1 (en) | Methods and arrangements in a telecommunications system | |
| CA2412096C (en) | Method and arrangement for handling information packets via user selectable relay nodes | |
| JP5645139B2 (ja) | ネットワークシステム、コントローラ、ネットワーク制御方法 | |
| US7886062B2 (en) | Packet relaying method and packet relaying system | |
| US20060056420A1 (en) | Communication apparatus selecting a source address | |
| JP4766976B2 (ja) | ノード間接続方法及び装置 | |
| JP2004364141A (ja) | Ｉｐアドレス変換装置およびパケット転送装置 | |
| CN115150312B (zh) | 一种路由方法及设备 | |
| Cisco | DECnet Commands | |
| Cisco | DECnet Commands | |
| Cisco | DECnet Commands | |
| Cisco | DECnet Commands | |
| Cisco | DECnet Commands | |
| Cisco | DECnet Commands | |
| Cisco | DECnet Commands | |
| Cisco | DECnet Commands | |
| Cisco | DECnet Commands | |
| WO2006131057A1 (fr) | Procédé et appareil d’implémentation du proxy de signalisation | |
| Cisco | DECnet Commands | |
| Cisco | DECnet Commands | |
| Cisco | DECnet Commands | |
| Cisco | DECnet Commands | |
| Cisco | DECnet Commands |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20061113 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20081114 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20081202 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20081216 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111226 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111226 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121226 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121226 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131226 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |