JP2982727B2 - 認証方法 - Google Patents
認証方法Info
- Publication number
- JP2982727B2 JP2982727B2 JP34217996A JP34217996A JP2982727B2 JP 2982727 B2 JP2982727 B2 JP 2982727B2 JP 34217996 A JP34217996 A JP 34217996A JP 34217996 A JP34217996 A JP 34217996A JP 2982727 B2 JP2982727 B2 JP 2982727B2
- Authority
- JP
- Japan
- Prior art keywords
- interface
- nhrp
- packet
- authentication
- authentication key
- 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
Classifications
-
- 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/08—Network architectures or network communication protocols for network security for authentication of entities
-
- 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
-
- 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/10—Mapping addresses of different types
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Description
【０００１】
【発明の属する技術分野】本発明は、ＮＢＭＡネットワ
ークにおけるＮＨＲＰによるアドレス解決方法に関し、
特にＮＨＲＰパケットの認証の方法に関する。
ークにおけるＮＨＲＰによるアドレス解決方法に関し、
特にＮＨＲＰパケットの認証の方法に関する。
【０００２】
【従来の技術】ＮＨＲＰプロトコルは、ＮＢＭＡネット
ワークにおけるアドレス解決プロトコルとして、ＩＥＴ
Ｆ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａ
ｓｋＦｏｒｃｅ）で議論されており、その仕様はｄｒａ
ｆｔ−ｉｅｔｆ−ｒｏｌｃ−ｎｈｒｐ−０８．ｔｘｔ等
に記述されている。
ワークにおけるアドレス解決プロトコルとして、ＩＥＴ
Ｆ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａ
ｓｋＦｏｒｃｅ）で議論されており、その仕様はｄｒａ
ｆｔ−ｉｅｔｆ−ｒｏｌｃ−ｎｈｒｐ−０８．ｔｘｔ等
に記述されている。
【０００３】これは以下のような方法である。なお以下
ではＮＢＭＡネットワークとしてＡＴＭネットワーク
を、その上位プロトコルとしてはＩＰ（Ｉｎｔｅｒｎｅ
ｔ Ｐｒｏｔｏｃｏｌ）を例に挙げて説明するが、これ
らが他のＮＢＭＡネットワークおよびネットワーク層プ
ロトコルであっても同様である。
ではＮＢＭＡネットワークとしてＡＴＭネットワーク
を、その上位プロトコルとしてはＩＰ（Ｉｎｔｅｒｎｅ
ｔ Ｐｒｏｔｏｃｏｌ）を例に挙げて説明するが、これ
らが他のＮＢＭＡネットワークおよびネットワーク層プ
ロトコルであっても同様である。
【０００４】ＡＴＭネットワーク上でＩＰ通信を行なう
ためには、通信相手のＩＰアドレスから、ＡＴＭアドレ
スを獲得する手段が必要となる。このため、ＮＨＲＰプ
ロトコルでは、ＡＴＭネットワークに接続されているＡ
ＴＭ端末のＩＰアドレスおよびＡＴＭアドレスの対をあ
るエリア毎（例えば論理ＩＰサブネット（ＬＩＳ：Ｌｏ
ｇｉｃａｌ ＩＰ Ｓｕｂｎｅｔ）毎）に置かれたＮＨ
ＲＰサーバ（ＮＨＳ）が分散管理する。
ためには、通信相手のＩＰアドレスから、ＡＴＭアドレ
スを獲得する手段が必要となる。このため、ＮＨＲＰプ
ロトコルでは、ＡＴＭネットワークに接続されているＡ
ＴＭ端末のＩＰアドレスおよびＡＴＭアドレスの対をあ
るエリア毎（例えば論理ＩＰサブネット（ＬＩＳ：Ｌｏ
ｇｉｃａｌ ＩＰ Ｓｕｂｎｅｔ）毎）に置かれたＮＨ
ＲＰサーバ（ＮＨＳ）が分散管理する。
【０００５】あるＡＴＭ端末がある通信相手のＩＰアド
レスに対するＡＴＭアドレスを解決したい場合、あらか
じめ決められたＮＨＳにＮＨＲＰ Ｒｅｓｏｌｕｔｉｏ
ｎＲｅｑｕｅｓｔパケットを送信する。ＮＨＲＰ Ｒｅ
ｓｏｌｕｔｉｏｎ Ｒｅｑｕｅｓｔパケットを受信した
ＮＨＳは、アドレスを解決できる場合にはＮＨＲＰＲｅ
ｓｏｌｕｔｉｏｎ ＲｅｐｌｙパケットをＡＴＭ端末に
返送する。解決できない場合には、解決すべきＩＰアド
レスを管理していると思われる別のＮＨＳの方向にその
ＮＨＲＰ Ｒｅｓｏｌｕｔｉｏｎ Ｒｅｑｕｅｓｔパケ
ットを転送する。すなわち、ＮＨＲＰ Ｒｅｓｏｌｕｔ
ｉｏｎ Ｒｅｑｕｅｓｔパケットは、アドレスを解決で
きるＮＨＳに到着するまで、複数のＮＨＳ間を次々と転
送されて行く。
レスに対するＡＴＭアドレスを解決したい場合、あらか
じめ決められたＮＨＳにＮＨＲＰ Ｒｅｓｏｌｕｔｉｏ
ｎＲｅｑｕｅｓｔパケットを送信する。ＮＨＲＰ Ｒｅ
ｓｏｌｕｔｉｏｎ Ｒｅｑｕｅｓｔパケットを受信した
ＮＨＳは、アドレスを解決できる場合にはＮＨＲＰＲｅ
ｓｏｌｕｔｉｏｎ ＲｅｐｌｙパケットをＡＴＭ端末に
返送する。解決できない場合には、解決すべきＩＰアド
レスを管理していると思われる別のＮＨＳの方向にその
ＮＨＲＰ Ｒｅｓｏｌｕｔｉｏｎ Ｒｅｑｕｅｓｔパケ
ットを転送する。すなわち、ＮＨＲＰ Ｒｅｓｏｌｕｔ
ｉｏｎ Ｒｅｑｕｅｓｔパケットは、アドレスを解決で
きるＮＨＳに到着するまで、複数のＮＨＳ間を次々と転
送されて行く。
【０００６】この結果、通信相手が異なるＬＩＳに属し
ている場合であっても、その通信相手がＡＴＭネットワ
ークに直接接続されている場合にはその通信相手自身の
ＡＴＭアドレスを解決することができる。通信相手がＡ
ＴＭネットワークに直接接続されていない場合には、Ａ
ＴＭネットワークの中からの出口のルータ（ゲートウェ
イ）のＡＴＭアドレスを解決することができる。
ている場合であっても、その通信相手がＡＴＭネットワ
ークに直接接続されている場合にはその通信相手自身の
ＡＴＭアドレスを解決することができる。通信相手がＡ
ＴＭネットワークに直接接続されていない場合には、Ａ
ＴＭネットワークの中からの出口のルータ（ゲートウェ
イ）のＡＴＭアドレスを解決することができる。
【０００７】ＮＨＲＰにおける従来の認証方法は、ＮＨ
ＲＰパケットの拡張部（Ｅｘｔｅｎｓｉｏｎ ｐａｒ
ｔ）に、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓ
ｉｏｎを付加して行なうと規定されている。認証のタイ
プとして、「Ｋｅｙｅｄ ＭＤ５」および「クリアテキ
ストパスワード」が規定されている（以下各々「ＭＤ
５」および「クリアテキスト」という）。ＮＨＲＰパケ
ットの拡張部は必須ではないので、Ａｕｔｈｅｎｔｉｃ
ａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎを付加しない場合もあ
る。これを認証タイプ「なし」とすると、全部で３つの
異なる認証タイプが規定されていることになる。
ＲＰパケットの拡張部（Ｅｘｔｅｎｓｉｏｎ ｐａｒ
ｔ）に、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓ
ｉｏｎを付加して行なうと規定されている。認証のタイ
プとして、「Ｋｅｙｅｄ ＭＤ５」および「クリアテキ
ストパスワード」が規定されている（以下各々「ＭＤ
５」および「クリアテキスト」という）。ＮＨＲＰパケ
ットの拡張部は必須ではないので、Ａｕｔｈｅｎｔｉｃ
ａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎを付加しない場合もあ
る。これを認証タイプ「なし」とすると、全部で３つの
異なる認証タイプが規定されていることになる。
【０００８】ＮＨＲＰパケットを受信したＮＨＳは、パ
ケットの種類に応じて、ｅｎｄ−ｔｏ−ｅｎｄに認証を
行なう（ＮＨＲＰ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｒｅｑ
ｕｅｓｔおよびＮＨＲＰ Ｒｅｇｉｓｔｒａｔｉｏｎ
Ｒｅｐｌｙの時）か、またはｈｏｐ−ｂｙ−ｈｏｐに認
証を行なう（それ以外のパケットの時）。
ケットの種類に応じて、ｅｎｄ−ｔｏ−ｅｎｄに認証を
行なう（ＮＨＲＰ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｒｅｑ
ｕｅｓｔおよびＮＨＲＰ Ｒｅｇｉｓｔｒａｔｉｏｎ
Ｒｅｐｌｙの時）か、またはｈｏｐ−ｂｙ−ｈｏｐに認
証を行なう（それ以外のパケットの時）。
【０００９】
【発明が解決しようとする課題】従来のＮＨＲＰでは、
認証のタイプとして複数の異なるタイプが規定されてい
るにも関わらず、これらの異なる認証タイプの扱いが明
らかでない。このため、特にｈｏｐ−ｂｙ−ｈｏｐの認
証の対象になるＮＨＲＰパケットが、あるＬＩＳから別
のＬＩＳに転送される場合、その２つのＬＩＳ間で認証
タイプが異なった場合の動作は実装に任せられることに
なる。
認証のタイプとして複数の異なるタイプが規定されてい
るにも関わらず、これらの異なる認証タイプの扱いが明
らかでない。このため、特にｈｏｐ−ｂｙ−ｈｏｐの認
証の対象になるＮＨＲＰパケットが、あるＬＩＳから別
のＬＩＳに転送される場合、その２つのＬＩＳ間で認証
タイプが異なった場合の動作は実装に任せられることに
なる。
【００１０】例えば、あるネットワークの管理ドメイン
では、異なる認証タイプのＬＩＳ間ではＮＨＲＰパケッ
トを転送しないという方針をとりたいかもしれない。ま
た、ある別のネットワークの管理ドメインでは、異なる
認証タイプのＬＩＳ間でもＮＨＲＰパケットを転送して
も良いという方針をとりたいかもしれない。すなわち、
ネットワークの管理ドメイン毎に、異なる認証タイプの
ＬＩＳ間でのＮＨＲＰパケットの扱いの方針を決定でき
ることが望ましい。
では、異なる認証タイプのＬＩＳ間ではＮＨＲＰパケッ
トを転送しないという方針をとりたいかもしれない。ま
た、ある別のネットワークの管理ドメインでは、異なる
認証タイプのＬＩＳ間でもＮＨＲＰパケットを転送して
も良いという方針をとりたいかもしれない。すなわち、
ネットワークの管理ドメイン毎に、異なる認証タイプの
ＬＩＳ間でのＮＨＲＰパケットの扱いの方針を決定でき
ることが望ましい。
【００１１】しかし、従来のＮＨＲＰでは、異なるベン
ダのＮＨＲＰサーバ間での認証に関する相互運用性が保
てなくなるという問題があった。つまり、上記のような
管理ドメイン毎の認証方針でＮＨＲＰを運用することが
できないという問題があった。
ダのＮＨＲＰサーバ間での認証に関する相互運用性が保
てなくなるという問題があった。つまり、上記のような
管理ドメイン毎の認証方針でＮＨＲＰを運用することが
できないという問題があった。
【００１２】また更に、同一のＮＢＭＡネットワーク上
の複数の管理ドメイン間で、お互いに同一の認証タイプ
を用いるか異なる認証タイプを用いるかに関わらず、異
なる管理ドメイン間ではＮＨＲＰパケットを転送しない
という方針をとりたいことがあるかもしれない。逆に、
別の複数の管理ドメイン間では、お互いに同一の認証タ
イプを用いるか異なる認証タイプを用いるかに関わら
ず、異なる管理ドメイン間でもＮＨＲＰパケットを転送
しても良いという方針をとりたいかもしれない。すなわ
ち、ネットワークの管理ドメイン間では、ＮＨＲＰパケ
ットの転送の扱いの方針を決定できることが望ましい。
の複数の管理ドメイン間で、お互いに同一の認証タイプ
を用いるか異なる認証タイプを用いるかに関わらず、異
なる管理ドメイン間ではＮＨＲＰパケットを転送しない
という方針をとりたいことがあるかもしれない。逆に、
別の複数の管理ドメイン間では、お互いに同一の認証タ
イプを用いるか異なる認証タイプを用いるかに関わら
ず、異なる管理ドメイン間でもＮＨＲＰパケットを転送
しても良いという方針をとりたいかもしれない。すなわ
ち、ネットワークの管理ドメイン間では、ＮＨＲＰパケ
ットの転送の扱いの方針を決定できることが望ましい。
【００１３】しかし、従来のＮＨＲＰでは、上記のよう
な管理ドメイン間の認証方針でＮＨＲＰを運用すること
ができないという問題があった。
な管理ドメイン間の認証方針でＮＨＲＰを運用すること
ができないという問題があった。
【００１４】従って本発明の目的は、ＬＳＩ間で認証タ
イプが異なった時のＮＨＲＰパケットの転送のモードお
よび管理ドメイン間でＮＨＲＰパケットの転送を行なう
時のモードを、管理ドメイン毎に設定できる方法を提供
することにある。
イプが異なった時のＮＨＲＰパケットの転送のモードお
よび管理ドメイン間でＮＨＲＰパケットの転送を行なう
時のモードを、管理ドメイン毎に設定できる方法を提供
することにある。
【００１５】本発明の他の目的は、上記の動作を明らか
にすることにより、異なるベンダのＮＨＳ間でも相互運
用性が保てる方法を提供することにある。
にすることにより、異なるベンダのＮＨＳ間でも相互運
用性が保てる方法を提供することにある。
【００１６】
【課題を解決するための手段】メディア共有型でないネ
ットワーク（ＮＢＭＡネットワーク）における、ネット
ワーク層アドレスからデータリンク層アドレスへの変換
（アドレスを解決するという）を行なうＮＨＲＰプロト
コルにおいて、前記アドレス解決機能を提供するＮＨＲ
Ｐサーバがｎ個のサブネットワークに所属するためのｎ
個のインターフェイスを有している場合、前記ＮＨＲＰ
サーバが前記ｎ個のインターフェイスに各々割り当てら
れている認証キーおよびそのタイプを保持する手段と、
前記ＮＨＲＰサーバが、前記ｎ個のインターフェイスの
うちあるインターフェイスからＮＨＲＰパケットを受け
とった場合、前記インターフェイスに割り当てられてい
る認証キーを用いて前記ＮＨＲＰパケットの認証を行な
い、認証が不正の場合に前記ＮＨＲＰパケットを破棄す
る手段を具備する。
ットワーク（ＮＢＭＡネットワーク）における、ネット
ワーク層アドレスからデータリンク層アドレスへの変換
（アドレスを解決するという）を行なうＮＨＲＰプロト
コルにおいて、前記アドレス解決機能を提供するＮＨＲ
Ｐサーバがｎ個のサブネットワークに所属するためのｎ
個のインターフェイスを有している場合、前記ＮＨＲＰ
サーバが前記ｎ個のインターフェイスに各々割り当てら
れている認証キーおよびそのタイプを保持する手段と、
前記ＮＨＲＰサーバが、前記ｎ個のインターフェイスの
うちあるインターフェイスからＮＨＲＰパケットを受け
とった場合、前記インターフェイスに割り当てられてい
る認証キーを用いて前記ＮＨＲＰパケットの認証を行な
い、認証が不正の場合に前記ＮＨＲＰパケットを破棄す
る手段を具備する。
【００１７】前記ＮＨＲＰサーバが受信した前記ＮＨＲ
Ｐパケットが前記インターフェイスに割り当てられてい
る認証キーで認証された場合で、前記インターフェイス
（第１のインターフェイス）から他のインターフェイス
（第２のインターフェイス）に前記ＮＨＲＰパケットを
転送する必要がある場合において、前記第１のインター
フェイスに割り当てられている認証キーのタイプと前記
第２のインターフェイスに割り当てられている認証キー
のタイプが異なる場合、前記ＮＨＲＰパケットを破棄す
る手段を具備する。
Ｐパケットが前記インターフェイスに割り当てられてい
る認証キーで認証された場合で、前記インターフェイス
（第１のインターフェイス）から他のインターフェイス
（第２のインターフェイス）に前記ＮＨＲＰパケットを
転送する必要がある場合において、前記第１のインター
フェイスに割り当てられている認証キーのタイプと前記
第２のインターフェイスに割り当てられている認証キー
のタイプが異なる場合、前記ＮＨＲＰパケットを破棄す
る手段を具備する。
【００１８】前記ＮＨＲＰサーバが受信した前記ＮＨＲ
Ｐパケットが前記インターフェイスに割り当てられてい
る認証キーで認証された場合で、前記第１のインターフ
ェイスから前記第２のインターフェイスに転送する必要
がある場合において、前記第１のインターフェイスに割
り当てられている認証キーのタイプと前記第２のインタ
ーフェイスに割り当てられている認証キーのタイプが異
なる場合、前記ＮＨＲＰパケットの認証キー部を前記第
２のインターフェイスに割り当てられている認証キーに
付け替えて、前記ＮＨＲＰパケットを前記第２のインタ
ーフェイスから転送する手段を具備する。
Ｐパケットが前記インターフェイスに割り当てられてい
る認証キーで認証された場合で、前記第１のインターフ
ェイスから前記第２のインターフェイスに転送する必要
がある場合において、前記第１のインターフェイスに割
り当てられている認証キーのタイプと前記第２のインタ
ーフェイスに割り当てられている認証キーのタイプが異
なる場合、前記ＮＨＲＰパケットの認証キー部を前記第
２のインターフェイスに割り当てられている認証キーに
付け替えて、前記ＮＨＲＰパケットを前記第２のインタ
ーフェイスから転送する手段を具備する。
【００１９】前記ＮＨＲＰサーバが受信した前記ＮＨＲ
Ｐパケットが前記インターフェイスに割り当てられてい
る認証キーで認証された場合で、前記第１のインターフ
ェイスから前記第２のインターフェイスに転送する必要
がある場合において、前記第１のインターフェイスに割
り当てられている認証キーのタイプと前記第２のインタ
ーフェイスに割り当てられている認証キーのタイプが異
なる場合、前記ＮＨＲＰサーバの第１のインターフェイ
スのアドレス情報を返送する手段を具備する。
Ｐパケットが前記インターフェイスに割り当てられてい
る認証キーで認証された場合で、前記第１のインターフ
ェイスから前記第２のインターフェイスに転送する必要
がある場合において、前記第１のインターフェイスに割
り当てられている認証キーのタイプと前記第２のインタ
ーフェイスに割り当てられている認証キーのタイプが異
なる場合、前記ＮＨＲＰサーバの第１のインターフェイ
スのアドレス情報を返送する手段を具備する。
【００２０】返送するアドレス情報として、前記第１の
インターフェイスが属するサブネットワークと前記第２
のインターフェイスが属するサブネットワーク間でパケ
ットの転送を行なうルータの、前記第１のインターフェ
イスが属するサブネットワーク側のインターフェイスの
アドレス情報を用いる。
インターフェイスが属するサブネットワークと前記第２
のインターフェイスが属するサブネットワーク間でパケ
ットの転送を行なうルータの、前記第１のインターフェ
イスが属するサブネットワーク側のインターフェイスの
アドレス情報を用いる。
【００２１】前記第１のインターフェイスに割り当てら
れている認証キーのタイプと前記第２のインターフェイ
スに割り当てられている認証キーのタイプに関わらず、
前記ＮＨＲＰパケットを処理する。
れている認証キーのタイプと前記第２のインターフェイ
スに割り当てられている認証キーのタイプに関わらず、
前記ＮＨＲＰパケットを処理する。
【００２２】
【発明の実施の形態】本発明の実施の形態について図面
を参照して説明する。
を参照して説明する。
【００２３】以下では便宜上、ＮＢＭＡネットワークと
してＡＴＭネットワークを、その上位プロトコルをＩＰ
として説明するが、これらが他のＮＢＭＡネットワーク
およびネットワーク層プロトコルであっても同様であ
る。
してＡＴＭネットワークを、その上位プロトコルをＩＰ
として説明するが、これらが他のＮＢＭＡネットワーク
およびネットワーク層プロトコルであっても同様であ
る。
【００２４】図１において、１つのＡＴＭネットワーク
１上に複数のＬＩＳ（ＬＩＳ−Ａ１０、ＬＩＳ−Ｂ ２
０、ＬＩＳ−Ｃ ３０、ＬＩＳ−Ｄ ４０）が定義され
ているものとする。このＡＴＭネットワーク１に直接接
続されている端末（例えば端末１１および端末４１）は
お互いにＡＴＭレベルでＳＶＣ（ＳｗｉｔｃｈｅｄＶｉ
ｒｔｕａｌ Ｃｏｎｎｅｃｔｉｏｎ）をセットアップす
ることができるものとする。なお、図１では、ＡＴＭネ
ットワークを構成するＡＴＭスイッチは省略してある。
また、これらを互いに接続する接続線等は一部を除き省
略してある。
１上に複数のＬＩＳ（ＬＩＳ−Ａ１０、ＬＩＳ−Ｂ ２
０、ＬＩＳ−Ｃ ３０、ＬＩＳ−Ｄ ４０）が定義され
ているものとする。このＡＴＭネットワーク１に直接接
続されている端末（例えば端末１１および端末４１）は
お互いにＡＴＭレベルでＳＶＣ（ＳｗｉｔｃｈｅｄＶｉ
ｒｔｕａｌ Ｃｏｎｎｅｃｔｉｏｎ）をセットアップす
ることができるものとする。なお、図１では、ＡＴＭネ
ットワークを構成するＡＴＭスイッチは省略してある。
また、これらを互いに接続する接続線等は一部を除き省
略してある。
【００２５】ＮＨＳ−Ａ １００、ＮＨＳ−Ｂ ２００
およびＮＳＨ−Ｃ ３００はＮＨＲＰサーバである。Ｎ
ＨＳ−Ａ １００はＬＩＳ−Ａ １０およびＬＩＳ−Ｂ
２０に属するインターフェイスを持ち、ＮＨＳ−Ｂ
２００はＬＩＳ−Ｂ ２０およびＬＩＳ−Ｃ ３０に属
するインターフェイスを持ち、ＮＨＳ−Ｃ ３００はＬ
ＩＳ−Ｃ ３０およびＬＩＳ−Ｄ ４０に属するインタ
ーフェイスを持つ。
およびＮＳＨ−Ｃ ３００はＮＨＲＰサーバである。Ｎ
ＨＳ−Ａ １００はＬＩＳ−Ａ １０およびＬＩＳ−Ｂ
２０に属するインターフェイスを持ち、ＮＨＳ−Ｂ
２００はＬＩＳ−Ｂ ２０およびＬＩＳ−Ｃ ３０に属
するインターフェイスを持ち、ＮＨＳ−Ｃ ３００はＬ
ＩＳ−Ｃ ３０およびＬＩＳ−Ｄ ４０に属するインタ
ーフェイスを持つ。
【００２６】例えば、ＮＨＳ−Ａ １００はＬＩＳ−Ａ
１０を管理し、ＮＨＳ−Ｂ ２００はＬＩＳ−Ｂ ２
０を管理し、ＮＨＳ−Ｃ ３００はＬＩＳ−Ｃ ３０お
よびＬＩＳ−Ｄ ４０を管理するようにあらかじめ設定
されているものとする。
１０を管理し、ＮＨＳ−Ｂ ２００はＬＩＳ−Ｂ ２
０を管理し、ＮＨＳ−Ｃ ３００はＬＩＳ−Ｃ ３０お
よびＬＩＳ−Ｄ ４０を管理するようにあらかじめ設定
されているものとする。
【００２７】図１において、ネットワーク管理者が、認
証タイプおよびそのキーをＬＩＳ毎に決める。例えばＬ
ＩＳ−Ａ １０においては、ＭＤ５による認証を行な
い、ＭＤ５用のキーＡを用いることとする。同様に、Ｌ
ＩＳ−Ｂ ２０ではＭＤ５による認証（キーＢ）、ＬＩ
Ｓ−Ｃ ３０ではクリアテキストによる認証（キー
Ｃ）、ＬＩＳ−Ｄ ４０ではクリアテキストによる認証
（キーＤ）とする。
証タイプおよびそのキーをＬＩＳ毎に決める。例えばＬ
ＩＳ−Ａ １０においては、ＭＤ５による認証を行な
い、ＭＤ５用のキーＡを用いることとする。同様に、Ｌ
ＩＳ−Ｂ ２０ではＭＤ５による認証（キーＢ）、ＬＩ
Ｓ−Ｃ ３０ではクリアテキストによる認証（キー
Ｃ）、ＬＩＳ−Ｄ ４０ではクリアテキストによる認証
（キーＤ）とする。
【００２８】各ＬＩＳに属するステーションには全て、
そのＬＩＳ毎に決められた認証キーおよびタイプを設定
する。例えば端末１１にはキーＡを設定する。なお、認
証キーの設定の仕方については任意の方法で良い。
そのＬＩＳ毎に決められた認証キーおよびタイプを設定
する。例えば端末１１にはキーＡを設定する。なお、認
証キーの設定の仕方については任意の方法で良い。
【００２９】また、ＮＨＳは一般に複数のインターフェ
イスを持っているので、各インターフェイス毎に認証キ
ーを設定する。図２にＮＨＳのブロック図を示す。ＮＨ
ＲＰサーバ処理部２０１はインターフェイス２１０、２
１１、２１２を介してＡＴＭネットワークに接続されて
いる。図２において、認証キー記憶部２０２はＮＨＲＰ
サーバ処理部２０１と接続され、各インターフェイス毎
の認証キーおよびそのタイプを設定する。
イスを持っているので、各インターフェイス毎に認証キ
ーを設定する。図２にＮＨＳのブロック図を示す。ＮＨ
ＲＰサーバ処理部２０１はインターフェイス２１０、２
１１、２１２を介してＡＴＭネットワークに接続されて
いる。図２において、認証キー記憶部２０２はＮＨＲＰ
サーバ処理部２０１と接続され、各インターフェイス毎
の認証キーおよびそのタイプを設定する。
【００３０】図３に、図２における認証キー記憶部２０
２に記憶された認証キーテーブルの一般的な構成を示
す。この認証キーテーブルには、インターフェイス番号
フィールド、認証キーフィールド、および認証タイプフ
ィールドから成るエントリが、そのＮＨＳが持つインタ
ーフェイス分（２１０、２１１、２１２）だけ設定され
る。例えばＮＨＳ−Ｂ ２００の認証キーテーブルの内
容は図４のようになる。
２に記憶された認証キーテーブルの一般的な構成を示
す。この認証キーテーブルには、インターフェイス番号
フィールド、認証キーフィールド、および認証タイプフ
ィールドから成るエントリが、そのＮＨＳが持つインタ
ーフェイス分（２１０、２１１、２１２）だけ設定され
る。例えばＮＨＳ−Ｂ ２００の認証キーテーブルの内
容は図４のようになる。
【００３１】図２の認証モード記憶部２０３には、どの
入力インターフェイスからどの出力インターフェイスへ
ＮＨＲＰパケットを転送する場合にどの認証モード（ド
ロップモード、フォワードモード、ゲートウェイモード
のいずれか（後述））を用いるかを設定する。図５に、
図２における認証モード記憶部２０３に記憶された認証
モードテーブルの一般的な構成を示す。認証モードテー
ブルには、入力インターフェイス番号フィールド、出力
インターフェイス番号フィールド、認証モードから成る
エントリが、必要なだけ設定される。例えばＮＨＳ−Ｂ
２００において、ＬＩＳ−Ｂ ２０からＬＩＳ−Ｃ
３０へＮＨＲＰパケットを転送する必要がある場合はフ
ォワードモード、逆にＬＩＳ−Ｃ ３０からＬＩＳ−Ｂ
２０へＮＨＲＰパケットを転送する必要がある場合は
ドロップモードで運用したいとすると、ＮＨＳ−Ｂ ２
００の認証モード記憶部の内容は図６のようになる。
入力インターフェイスからどの出力インターフェイスへ
ＮＨＲＰパケットを転送する場合にどの認証モード（ド
ロップモード、フォワードモード、ゲートウェイモード
のいずれか（後述））を用いるかを設定する。図５に、
図２における認証モード記憶部２０３に記憶された認証
モードテーブルの一般的な構成を示す。認証モードテー
ブルには、入力インターフェイス番号フィールド、出力
インターフェイス番号フィールド、認証モードから成る
エントリが、必要なだけ設定される。例えばＮＨＳ−Ｂ
２００において、ＬＩＳ−Ｂ ２０からＬＩＳ−Ｃ
３０へＮＨＲＰパケットを転送する必要がある場合はフ
ォワードモード、逆にＬＩＳ−Ｃ ３０からＬＩＳ−Ｂ
２０へＮＨＲＰパケットを転送する必要がある場合は
ドロップモードで運用したいとすると、ＮＨＳ−Ｂ ２
００の認証モード記憶部の内容は図６のようになる。
【００３２】上記認証キーおよび認証モードの設定の仕
方は任意の手段で良く、例えば各端末やＮＨＳ毎にファ
イルに記述する方法でも良いし、ネットワークを介して
設定する方法でも構わない。
方は任意の手段で良く、例えば各端末やＮＨＳ毎にファ
イルに記述する方法でも良いし、ネットワークを介して
設定する方法でも構わない。
【００３３】また図２において、ＩＰデータ転送部２０
４はＩＰ層の働きをする。すなわち、インターフェイス
２１０、２１１、２１２を介してＩＰパケットが入力さ
れた場合、ＮＨＲＰサーバ処理部２０１は何もせず、Ｉ
Ｐデータ転送部２０４がそのパケットを処理するものと
する。
４はＩＰ層の働きをする。すなわち、インターフェイス
２１０、２１１、２１２を介してＩＰパケットが入力さ
れた場合、ＮＨＲＰサーバ処理部２０１は何もせず、Ｉ
Ｐデータ転送部２０４がそのパケットを処理するものと
する。
【００３４】ＩＰルーティングテーブル２０５はＩＰデ
ータ転送部２０４と接続されて、ＩＰデータ転送部２０
４があるインターフェイスから受信したＩＰパケットを
別のインターフェイスに転送する時に用いられる。更
に、ＩＰルーティングテーブル２０５はＮＨＲＰサーバ
処理部２０１とも接続され、ＮＨＲＰサーバ処理部２０
１があるインターフェイスから受信したＮＨＲＰパケッ
トを別のインターフェイスに転送する時にも用いられ
る。
ータ転送部２０４と接続されて、ＩＰデータ転送部２０
４があるインターフェイスから受信したＩＰパケットを
別のインターフェイスに転送する時に用いられる。更
に、ＩＰルーティングテーブル２０５はＮＨＲＰサーバ
処理部２０１とも接続され、ＮＨＲＰサーバ処理部２０
１があるインターフェイスから受信したＮＨＲＰパケッ
トを別のインターフェイスに転送する時にも用いられ
る。
【００３５】ＩＰルーティングテーブル２０５の内容
は、ネットワーク管理者により静的に設定されている
か、ＲＩＰまたはＯＳＰＦなどの既存のＩＰレベルのル
ーティングプロトコルを用いて動的に設定するものとす
る。
は、ネットワーク管理者により静的に設定されている
か、ＲＩＰまたはＯＳＰＦなどの既存のＩＰレベルのル
ーティングプロトコルを用いて動的に設定するものとす
る。
【００３６】なお図２において、ＩＰデータ転送部２０
４およびＩＰルーティングテーブル２０５はＮＨＳの内
部に存在しているように記述されているが、ＮＨＲＰサ
ーバ処理部２０１とインターフェイス（２１０、２１
１、２１２）が共用できるのであれば、必ずしもＮＨＳ
内に存在する必要はない。
４およびＩＰルーティングテーブル２０５はＮＨＳの内
部に存在しているように記述されているが、ＮＨＲＰサ
ーバ処理部２０１とインターフェイス（２１０、２１
１、２１２）が共用できるのであれば、必ずしもＮＨＳ
内に存在する必要はない。
【００３７】まず、第１の実施の形態の動作について説
明する。
明する。
【００３８】図１において、端末１１が、例えば、端末
４１と通信しようとする場合を説明する。
４１と通信しようとする場合を説明する。
【００３９】端末１１はキーＡを付加したＮＨＲＰ Ｒ
ｅｓｏｌｕｔｉｏｎ Ｒｅｑｕｅｓｔ（認証タイプがＭ
Ｄ５なので、キーＡを用いて送信するＮＨＲＰパケット
のＭＤ５ダイジェストを計算し、これをＡｕｔｈｅｎｔ
ｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎに入れる）をＮＨ
Ｓ−Ａ １００に送信する。
ｅｓｏｌｕｔｉｏｎ Ｒｅｑｕｅｓｔ（認証タイプがＭ
Ｄ５なので、キーＡを用いて送信するＮＨＲＰパケット
のＭＤ５ダイジェストを計算し、これをＡｕｔｈｅｎｔ
ｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎに入れる）をＮＨ
Ｓ−Ａ １００に送信する。
【００４０】ＮＨＳ−Ａ １００では受信したＮＨＲＰ
パケットに付加されているＡｕｔｈｅｎｔｉｃａｔｉｏ
ｎ Ｅｘｔｅｎｓｉｏｎと、このＮＨＲＰパケットを受
信したインターフェイスに割り当てられているキーＡで
認証を行なう（認証タイプがＭＤ５なので、Ａｕｔｈｅ
ｎｔｉｃａｔｉｏｎ ＥｘｔｅｎｓｉｏｎからＭＤ５ダ
イジェストを取り出し、ＮＨＳ−Ａ １００が持つキー
Ａを用いてこのＮＨＲＰパケットのＭＤ５ダイジェスト
を再度計算した結果と比較する）。端末１１は正当なキ
ーＡを持っていたので、このＮＨＲＰパケットは正当な
ものであると判断される。
パケットに付加されているＡｕｔｈｅｎｔｉｃａｔｉｏ
ｎ Ｅｘｔｅｎｓｉｏｎと、このＮＨＲＰパケットを受
信したインターフェイスに割り当てられているキーＡで
認証を行なう（認証タイプがＭＤ５なので、Ａｕｔｈｅ
ｎｔｉｃａｔｉｏｎ ＥｘｔｅｎｓｉｏｎからＭＤ５ダ
イジェストを取り出し、ＮＨＳ−Ａ １００が持つキー
Ａを用いてこのＮＨＲＰパケットのＭＤ５ダイジェスト
を再度計算した結果と比較する）。端末１１は正当なキ
ーＡを持っていたので、このＮＨＲＰパケットは正当な
ものであると判断される。
【００４１】ここで、もし端末１２のように不正なキー
を持った端末がＮＨＳ−Ａ １００にＮＨＲＰ Ｒｅｓ
ｏｌｕｔｉｏｎ Ｒｅｑｕｅｓｔを送信しても、不正な
ＮＨＲＰパケットとして、エラー（ＮＨＲＰ Ｅｒｒｏ
ｒ Ｉｎｄｉｃａｔｉｏｎで、エラーコードがＡｕｔｈ
ｅｔｉｃａｔｉｏｎ Ｆａｉｌｕｒｅ）が送り返され、
当該ＮＨＲＰパケットは破棄される。
を持った端末がＮＨＳ−Ａ １００にＮＨＲＰ Ｒｅｓ
ｏｌｕｔｉｏｎ Ｒｅｑｕｅｓｔを送信しても、不正な
ＮＨＲＰパケットとして、エラー（ＮＨＲＰ Ｅｒｒｏ
ｒ Ｉｎｄｉｃａｔｉｏｎで、エラーコードがＡｕｔｈ
ｅｔｉｃａｔｉｏｎ Ｆａｉｌｕｒｅ）が送り返され、
当該ＮＨＲＰパケットは破棄される。
【００４２】以上のようにして、ＮＨＳ−Ａ １００に
不正にアクセスしようとした端末１２を排除することが
できる。
不正にアクセスしようとした端末１２を排除することが
できる。
【００４３】また、ＬＩＳ−Ｃ ３０のように、認証タ
イプがクリアテキストのＬＩＳにおいても同様である。
すなわち、端末１１において、ＭＤ５ダイジェストをＡ
ｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎに入
れる代わりに、単にキーＡそのもの（テキスト形式）を
Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎに
入れる。また、ＮＨＳ−Ａ １００において、ＭＤ５ダ
イジェストを再度計算して比較する代わりに、単にキー
をＡｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎ
から取り出し、ＮＨＳ−Ａ １００の持つそれと比較す
る。
イプがクリアテキストのＬＩＳにおいても同様である。
すなわち、端末１１において、ＭＤ５ダイジェストをＡ
ｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎに入
れる代わりに、単にキーＡそのもの（テキスト形式）を
Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎに
入れる。また、ＮＨＳ−Ａ １００において、ＭＤ５ダ
イジェストを再度計算して比較する代わりに、単にキー
をＡｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎ
から取り出し、ＮＨＳ−Ａ １００の持つそれと比較す
る。
【００４４】なお、認証タイプがＭＤ５でもクリアテキ
ストでも、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎ
ｓｉｏｎを付加することを単に「キーを付加する」とい
うことにする。また、同様に、Ａｕｔｈｅｎｔｉｃａｔ
ｉｏｎ Ｅｘｔｅｎｓｉｏｎと、ＮＨＳの持つキーとで
認証を行なうことを単に「キーで認証する」ということ
にする。
ストでも、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｅｘｔｅｎ
ｓｉｏｎを付加することを単に「キーを付加する」とい
うことにする。また、同様に、Ａｕｔｈｅｎｔｉｃａｔ
ｉｏｎ Ｅｘｔｅｎｓｉｏｎと、ＮＨＳの持つキーとで
認証を行なうことを単に「キーで認証する」ということ
にする。
【００４５】次に第２の実施の形態の動作について説明
する。
する。
【００４６】図１において、ＮＨＳ−Ｂ ２００の認証
モード記憶部にはあらかじめ、入力インターフェイスか
ら出力インターフェイスへの転送の場合に「ドロップモ
ード」、「フォワードモード」、「ゲートウェイモー
ド」のいずれの認証モードを用いるかを設定しておく。
これにより、ある管理ドメインの境界に設置されている
ＮＨＳにおいて、用いられている認証タイプが上記管理
ドメイン内と管理ドメイン外で異なっている場合、上記
管理ドメインから外へＮＨＲＰパケットを転送すること
は許すが、上記管理ドメイン外からのＮＨＲＰパケット
は受け付けない、というような運用を可能にすることが
できる。
モード記憶部にはあらかじめ、入力インターフェイスか
ら出力インターフェイスへの転送の場合に「ドロップモ
ード」、「フォワードモード」、「ゲートウェイモー
ド」のいずれの認証モードを用いるかを設定しておく。
これにより、ある管理ドメインの境界に設置されている
ＮＨＳにおいて、用いられている認証タイプが上記管理
ドメイン内と管理ドメイン外で異なっている場合、上記
管理ドメインから外へＮＨＲＰパケットを転送すること
は許すが、上記管理ドメイン外からのＮＨＲＰパケット
は受け付けない、というような運用を可能にすることが
できる。
【００４７】ここで、上記３つの認証モードについて説
明する。
明する。
【００４８】「ドロップモード」とは、「認証タイプが
異なるＬＩＳ間でのＮＨＲＰパケットの転送を行なわな
い」という認証モードである。ドロップモードは本発明
で記述される認証モードのうち、最も強い認証を与え
る。
異なるＬＩＳ間でのＮＨＲＰパケットの転送を行なわな
い」という認証モードである。ドロップモードは本発明
で記述される認証モードのうち、最も強い認証を与え
る。
【００４９】「フォワードモード」とは、「認証タイプ
が異なるＬＩＳ間でもＡｕｔｈｅｎｔｉｃａｔｉｏｎ
Ｅｘｔｅｎｓｉｏｎ内の認証キーを付け替えてＮＨＲＰ
パケットの転送を継続して行なう」という認証モードで
ある。フォワードモードは本発明で記述される認証モー
ドのうち、最も弱い認証を与える。
が異なるＬＩＳ間でもＡｕｔｈｅｎｔｉｃａｔｉｏｎ
Ｅｘｔｅｎｓｉｏｎ内の認証キーを付け替えてＮＨＲＰ
パケットの転送を継続して行なう」という認証モードで
ある。フォワードモードは本発明で記述される認証モー
ドのうち、最も弱い認証を与える。
【００５０】「ゲートウェイモード」とは、認証タイプ
が異なるＬＩＳ間のＮＨＲＰ Ｒｅｓｏｌｕｔｉｏｎ
Ｒｅｑｕｅｓｔの場合は、ＮＨＳまたは他のルータのア
ドレス情報をリプライすることにより、送信端末からセ
ットアップされるＳＶＣを一旦このＮＨＳまたはルータ
で終端し、このＮＨＳまたはルータのＩＰ層に、受信す
るＩＰパケットの処理を任せるという、認証モードであ
る。ゲートウェイモードは本発明で記述される認証モー
ドのうち、ドロップモードより弱く、フォワードモード
より強い認証を与える。
が異なるＬＩＳ間のＮＨＲＰ Ｒｅｓｏｌｕｔｉｏｎ
Ｒｅｑｕｅｓｔの場合は、ＮＨＳまたは他のルータのア
ドレス情報をリプライすることにより、送信端末からセ
ットアップされるＳＶＣを一旦このＮＨＳまたはルータ
で終端し、このＮＨＳまたはルータのＩＰ層に、受信す
るＩＰパケットの処理を任せるという、認証モードであ
る。ゲートウェイモードは本発明で記述される認証モー
ドのうち、ドロップモードより弱く、フォワードモード
より強い認証を与える。
【００５１】上記各認証モードにおけるＮＨＲＰパケッ
トの処理の例を図７に示す。
トの処理の例を図７に示す。
【００５２】なお、認証モードの設定の仕方は任意の手
段で良く、例えば各ＮＨＳ毎にファイルに記述する方法
でも良いし、ネットワークを介して設定する方法でも構
わない。
段で良く、例えば各ＮＨＳ毎にファイルに記述する方法
でも良いし、ネットワークを介して設定する方法でも構
わない。
【００５３】第２の実施の形態の場合、ＮＨＳ−Ｂ ２
００ではインターフェイス１から２へ転送の場合にはド
ロップモードを用いるように設定してあるものとする。
００ではインターフェイス１から２へ転送の場合にはド
ロップモードを用いるように設定してあるものとする。
【００５４】図１において、あるＮＨＲＰパケット（例
えば端末４１のＡＴＭアドレスを解決するためのＮＨＲ
Ｐ Ｒｅｓｏｌｕｔｉｏｎ Ｒｅｑｕｅｓｔパケット）
がＮＨＳ−Ａ １００からＮＨＳ−Ｂ ２００に到着し
た場合を説明する。この場合、このＮＨＲＰパケットは
ＮＨＳ−Ｂ ２００では処理せず、ＮＨＳ−Ｃ ３００
へ転送される必要がある。
えば端末４１のＡＴＭアドレスを解決するためのＮＨＲ
Ｐ Ｒｅｓｏｌｕｔｉｏｎ Ｒｅｑｕｅｓｔパケット）
がＮＨＳ−Ａ １００からＮＨＳ−Ｂ ２００に到着し
た場合を説明する。この場合、このＮＨＲＰパケットは
ＮＨＳ−Ｂ ２００では処理せず、ＮＨＳ−Ｃ ３００
へ転送される必要がある。
【００５５】上記の場合のＮＨＳ−Ｂ ２００の動作
は、図８のフローチャートに従う。
は、図８のフローチャートに従う。
【００５６】まずステップ５０１で、ＮＨＲＰパケット
の種類を判断する。ＮＨＲＰ Ｒｅｇｉｓｔｒａｔｉｏ
ｎ ＲｅｑｕｅｓｔまたはＮＨＲＰ Ｒｅｇｉｓｔｒａ
ｔｉｏｎ Ｒｅｐｌｙパケットであったら、ステップ５
０２で、ｅｎｄ−ｔｏ−ｅｎｄの認証処理を行なう（従
来技術につき詳細省略）。
の種類を判断する。ＮＨＲＰ Ｒｅｇｉｓｔｒａｔｉｏ
ｎ ＲｅｑｕｅｓｔまたはＮＨＲＰ Ｒｅｇｉｓｔｒａ
ｔｉｏｎ Ｒｅｐｌｙパケットであったら、ステップ５
０２で、ｅｎｄ−ｔｏ−ｅｎｄの認証処理を行なう（従
来技術につき詳細省略）。
【００５７】ＮＨＲＰパケットの種類が上記以外ならｈ
ｏｐ−ｂｙ−ｈｏｐの認証を行なう。ステップ５０３
で、図２の認証キーテーブル２０２から認証キーおよび
タイプを取り出し、ステップ５０４で認証を行なう。こ
の結果、不正なＮＨＲＰパケットと判断されたら、ステ
ップ５０５でこのＮＨＲＰパケットを破棄し、このＮＨ
ＲＰパケットの送信者にエラーを送り返す。ここまでは
第１の実施の形態と同様である。
ｏｐ−ｂｙ−ｈｏｐの認証を行なう。ステップ５０３
で、図２の認証キーテーブル２０２から認証キーおよび
タイプを取り出し、ステップ５０４で認証を行なう。こ
の結果、不正なＮＨＲＰパケットと判断されたら、ステ
ップ５０５でこのＮＨＲＰパケットを破棄し、このＮＨ
ＲＰパケットの送信者にエラーを送り返す。ここまでは
第１の実施の形態と同様である。
【００５８】このＮＨＲＰパケットが正当であった場
合、これをＮＨＳ−Ｂ ２００自身が処理すべきか、そ
れとも他のＮＨＳに転送する必要があるかどうかをステ
ップ５０６で判断する。端末４１のアドレス情報はＮＨ
Ｓ−Ｂ ２００では管理されていないため、このＮＨＲ
ＰパケットはＮＨＳ−Ｃ ３００に転送する必要がある
ので、ステップ５０８で、ＮＨＳ−Ｃ ３００に送信す
るためのインターフェイスに割り当てられている認証キ
ーおよびそのタイプを図２の認証キーテーブル２０２か
ら取り出す。
合、これをＮＨＳ−Ｂ ２００自身が処理すべきか、そ
れとも他のＮＨＳに転送する必要があるかどうかをステ
ップ５０６で判断する。端末４１のアドレス情報はＮＨ
Ｓ−Ｂ ２００では管理されていないため、このＮＨＲ
ＰパケットはＮＨＳ−Ｃ ３００に転送する必要がある
ので、ステップ５０８で、ＮＨＳ−Ｃ ３００に送信す
るためのインターフェイスに割り当てられている認証キ
ーおよびそのタイプを図２の認証キーテーブル２０２か
ら取り出す。
【００５９】ステップ５０９で、パケットを受信したイ
ンターフェイスの認証キーのタイプと、送信すべきイン
ターフェイスの認証キーのタイプが同じかどうか判断す
る。同じ場合はステップ５１０で、送信すべきインター
フェイスの認証キーに付け替えてＮＨＲＰパケットを送
信する。ＮＨＳ−Ｂ ２００では認証タイプが異なるの
で、ステップ５１１で図２の認証モード記憶部２０３か
ら、入力インターフェイス１から出力インターフェイス
２へ転送する際の認証モードを取り出す。
ンターフェイスの認証キーのタイプと、送信すべきイン
ターフェイスの認証キーのタイプが同じかどうか判断す
る。同じ場合はステップ５１０で、送信すべきインター
フェイスの認証キーに付け替えてＮＨＲＰパケットを送
信する。ＮＨＳ−Ｂ ２００では認証タイプが異なるの
で、ステップ５１１で図２の認証モード記憶部２０３か
ら、入力インターフェイス１から出力インターフェイス
２へ転送する際の認証モードを取り出す。
【００６０】ここでは、ＮＨＳ−Ｂ １００の入力イン
ターフェイス１から出力インターフェイス２へ転送する
際の認証モードはドロップモードと仮定する。そのた
め、ステップ５１２に進む。ステップ５１２で、このＮ
ＨＲＰパケットがＮＨＲＰ Ｒｅｓｏｌｕｔｉｏｎ Ｒ
ｅｑｕｅｓｔパケットかどうかを判断する。ＮＨＲＰＲ
ｅｓｏｌｕｔｉｏｎ Ｒｅｑｕｅｓｔパケットだった
ら、ステップ５１４で、Ｎｅｇａｔｉｖｅ Ｒｅｐｌｙ
を返す。それ以外のパケットだったらステップ５１３
で、このＮＨＲＰパケットを破棄し、エラーを返す。
ターフェイス１から出力インターフェイス２へ転送する
際の認証モードはドロップモードと仮定する。そのた
め、ステップ５１２に進む。ステップ５１２で、このＮ
ＨＲＰパケットがＮＨＲＰ Ｒｅｓｏｌｕｔｉｏｎ Ｒ
ｅｑｕｅｓｔパケットかどうかを判断する。ＮＨＲＰＲ
ｅｓｏｌｕｔｉｏｎ Ｒｅｑｕｅｓｔパケットだった
ら、ステップ５１４で、Ｎｅｇａｔｉｖｅ Ｒｅｐｌｙ
を返す。それ以外のパケットだったらステップ５１３
で、このＮＨＲＰパケットを破棄し、エラーを返す。
【００６１】以上の動作により、認証タイプが異なるＬ
ＩＳ間でのＮＨＲＰパケットの転送を行なわないという
認証モード「ドロップモード」を実現できる。
ＩＳ間でのＮＨＲＰパケットの転送を行なわないという
認証モード「ドロップモード」を実現できる。
【００６２】次に第３の実施の形態の動作について説明
する。
する。
【００６３】第３の実施の形態の場合、ＮＨＳ−Ｂ ２
００の入力インターフェイス１から出力インターフェイ
ス２へ転送する際の認証モードはフォワードモードに設
定してあるものとする。
００の入力インターフェイス１から出力インターフェイ
ス２へ転送する際の認証モードはフォワードモードに設
定してあるものとする。
【００６４】ＮＨＳ−Ｂ ２００がＮＨＲＰパケットを
受信したとする。ステップ５０１からステップ５１１ま
では、第２の実施の形態と同様である。
受信したとする。ステップ５０１からステップ５１１ま
では、第２の実施の形態と同様である。
【００６５】ステップ５１１において、ＮＨＳ−Ｂ １
００の入力インターフェイス１から出力インターフェイ
ス２へ転送する際の認証モードはフォワードモードであ
ると仮定すると、ステップ５１０に進む。ステップ５１
０では、ＮＨＲＰパケットのＡｕｔｈｅｔｉｃａｔｉｏ
ｎ Ｅｘｔｅｎｓｉｏｎ内の認証キーを送信すべきイン
ターフェイスの認証キーに付け替えてＮＨＲＰパケット
を送信する。
００の入力インターフェイス１から出力インターフェイ
ス２へ転送する際の認証モードはフォワードモードであ
ると仮定すると、ステップ５１０に進む。ステップ５１
０では、ＮＨＲＰパケットのＡｕｔｈｅｔｉｃａｔｉｏ
ｎ Ｅｘｔｅｎｓｉｏｎ内の認証キーを送信すべきイン
ターフェイスの認証キーに付け替えてＮＨＲＰパケット
を送信する。
【００６６】以上の動作により、認証タイプが異なるＬ
ＩＳ間でもＮＨＲＰパケットの転送を継続して行なうと
いう認証モード「フォワードモード」を実現できる。
ＩＳ間でもＮＨＲＰパケットの転送を継続して行なうと
いう認証モード「フォワードモード」を実現できる。
【００６７】次に第４の実施の形態の動作について説明
する。
する。
【００６８】第４の実施の形態の場合、ＮＨＳ−Ｂ ２
００の入力インターフェイス１から出力インターフェイ
ス２へ転送する際の認証モードはゲートウェイモードに
設定してあるものとする。
００の入力インターフェイス１から出力インターフェイ
ス２へ転送する際の認証モードはゲートウェイモードに
設定してあるものとする。
【００６９】ＮＨＳ−Ｂ ２００がパケットを受信した
とする。ステップ５０１からステップ５１１までは、第
２の実施の形態と同様である。
とする。ステップ５０１からステップ５１１までは、第
２の実施の形態と同様である。
【００７０】ステップ５１１において、ＮＨＳ−Ｂ ２
００の認証モードはゲートウェイモードであると仮定す
ると、ステップ５１５に進む。
００の認証モードはゲートウェイモードであると仮定す
ると、ステップ５１５に進む。
【００７１】ステップ５１５で、このＮＨＲＰパケット
がＮＨＲＰ ＲｅｓｏｌｕｔｉｏｎＲｅｑｕｅｓｔパケ
ットかどうかを判断する。ＮＨＲＰ Ｒｅｓｏｌｕｔｉ
ｏｎ Ｒｅｑｕｅｓｔパケットでなかったら、ステップ
５１９で、このＮＨＲＰパケットを破棄し、エラーを返
す。ＮＨＲＰ Ｒｅｓｏｌｕｔｉｏｎ Ｒｅｑｕｅｓｔ
であったら、ステップ５１６で、「解決すべきＩＰアド
レスがＮＨＳ−Ｂ２００からＩＰ ｒｅａｃｈａｂｌｅ
か（ＩＰ的に到達可能か）どうか」をＩＰルーティング
テーブル２０５を参照して判断する。ＩＰ ｒｅａｃｈ
ａｂｌｅでなかったら、ステップ５１８で、Ｎｅｇａｔ
ｉｖｅ Ｒｅｐｌｙを返す。ＩＰｒｅａｃｈａｂｌｅで
あったら、ステップ５１７で、このＮＨＲＰパケットを
受信したインターフェイスのアドレス情報をリプライす
る（Ｐｏｓｉｔｉｖｅ Ｒｅｐｌｙ）。
がＮＨＲＰ ＲｅｓｏｌｕｔｉｏｎＲｅｑｕｅｓｔパケ
ットかどうかを判断する。ＮＨＲＰ Ｒｅｓｏｌｕｔｉ
ｏｎ Ｒｅｑｕｅｓｔパケットでなかったら、ステップ
５１９で、このＮＨＲＰパケットを破棄し、エラーを返
す。ＮＨＲＰ Ｒｅｓｏｌｕｔｉｏｎ Ｒｅｑｕｅｓｔ
であったら、ステップ５１６で、「解決すべきＩＰアド
レスがＮＨＳ−Ｂ２００からＩＰ ｒｅａｃｈａｂｌｅ
か（ＩＰ的に到達可能か）どうか」をＩＰルーティング
テーブル２０５を参照して判断する。ＩＰ ｒｅａｃｈ
ａｂｌｅでなかったら、ステップ５１８で、Ｎｅｇａｔ
ｉｖｅ Ｒｅｐｌｙを返す。ＩＰｒｅａｃｈａｂｌｅで
あったら、ステップ５１７で、このＮＨＲＰパケットを
受信したインターフェイスのアドレス情報をリプライす
る（Ｐｏｓｉｔｉｖｅ Ｒｅｐｌｙ）。
【００７２】送信端末（例えば図１の端末１１）が、こ
のリプライを受信すると、ＮＨＳ−Ｂ ２００までＳＶ
Ｃをセットアップすることができる。この結果、送信端
末が送信したＩＰパケットは一旦、ＮＨＳ−Ｂ ２００
のＩＰデータ転送部２０４に到着することになる。この
ＩＰパケットの扱いはＮＨＳ−Ｂ ２００のＩＰデータ
転送部２０４に任せることとする。これにより、ＩＰレ
ベルでのパケットフィルタリング等の機能を使うことが
できる（ＩＰデータ転送部２０４の処理については本発
明の範囲外であるので省略する）。
のリプライを受信すると、ＮＨＳ−Ｂ ２００までＳＶ
Ｃをセットアップすることができる。この結果、送信端
末が送信したＩＰパケットは一旦、ＮＨＳ−Ｂ ２００
のＩＰデータ転送部２０４に到着することになる。この
ＩＰパケットの扱いはＮＨＳ−Ｂ ２００のＩＰデータ
転送部２０４に任せることとする。これにより、ＩＰレ
ベルでのパケットフィルタリング等の機能を使うことが
できる（ＩＰデータ転送部２０４の処理については本発
明の範囲外であるので省略する）。
【００７３】以上の動作により、認証タイプが異なるＬ
ＩＳ間のＮＨＲＰ Ｒｅｓｏｌｕｔｉｏｎ Ｒｅｑｕｅ
ｓｔの場合は、ＮＨＳのアドレス情報をリプライするこ
とにより、送信端末からセットアップされるＳＶＣを一
旦このＮＨＳで終端し、このＮＨＳのＩＰデータ転送部
に、受信するＩＰパケットの処理を任せるという、認証
モード「ゲートウェイモード」を実現できる。
ＩＳ間のＮＨＲＰ Ｒｅｓｏｌｕｔｉｏｎ Ｒｅｑｕｅ
ｓｔの場合は、ＮＨＳのアドレス情報をリプライするこ
とにより、送信端末からセットアップされるＳＶＣを一
旦このＮＨＳで終端し、このＮＨＳのＩＰデータ転送部
に、受信するＩＰパケットの処理を任せるという、認証
モード「ゲートウェイモード」を実現できる。
【００７４】次に第５の実施の形態の動作について説明
する。
する。
【００７５】第５の実施の形態の場合、ＮＨＳ−Ｂ ２
００の入力インターフェイス１から出力インターフェイ
ス２へ転送する際の認証モードはゲートウェイモードに
設定してあるものとする。また、ＮＨＳ−Ｂ ２００に
はルータ４００のアドレス情報が設定されているものと
する。
００の入力インターフェイス１から出力インターフェイ
ス２へ転送する際の認証モードはゲートウェイモードに
設定してあるものとする。また、ＮＨＳ−Ｂ ２００に
はルータ４００のアドレス情報が設定されているものと
する。
【００７６】ＮＨＳ−Ｂ ２００がＮＨＲＰパケットを
受信したとする。ステップ５０１からステップ５１５ま
では、第４の実施の形態と同様である。
受信したとする。ステップ５０１からステップ５１５ま
では、第４の実施の形態と同様である。
【００７７】ステップ５１６で、「解決すべきＩＰアド
レスが、ルータ４００からＩＰ ｒｅａｃｈａｂｌｅか
どうか」を判断する。この判断の仕方は、例えば「ルー
タ４００からＬＩＳ−Ｄ ４０へはＩＰ ｒｅａｃｈａ
ｂｌｅである」と静的に設定されている情報（ファイル
など）を元にしても良いし、ＮＨＳ−Ｂ ２００がルー
タ４００とルーティングプロトコルによりＩＰルーティ
ング情報を交換している場合、その交換しているルーテ
ィング情報を元に行なっても良い。
レスが、ルータ４００からＩＰ ｒｅａｃｈａｂｌｅか
どうか」を判断する。この判断の仕方は、例えば「ルー
タ４００からＬＩＳ−Ｄ ４０へはＩＰ ｒｅａｃｈａ
ｂｌｅである」と静的に設定されている情報（ファイル
など）を元にしても良いし、ＮＨＳ−Ｂ ２００がルー
タ４００とルーティングプロトコルによりＩＰルーティ
ング情報を交換している場合、その交換しているルーテ
ィング情報を元に行なっても良い。
【００７８】ＩＰ ｒｅａｃｈａｂｌｅでなかった場合
は第１の実施の形態の場合と同様Ｎｅｇａｔｉｖｅ Ｒ
ｅｐｌｙを返す。ＩＰ ｒｅａｃｈａｂｌｅであった
ら、ステップ５１７で、ルータ４００のＬＩＳ−Ｂ ２
００側のインターフェイスのアドレス情報をリプライす
る（Ｐｏｓｉｔｉｖｅ Ｒｅｐｌｙ）。
は第１の実施の形態の場合と同様Ｎｅｇａｔｉｖｅ Ｒ
ｅｐｌｙを返す。ＩＰ ｒｅａｃｈａｂｌｅであった
ら、ステップ５１７で、ルータ４００のＬＩＳ−Ｂ ２
００側のインターフェイスのアドレス情報をリプライす
る（Ｐｏｓｉｔｉｖｅ Ｒｅｐｌｙ）。
【００７９】送信端末（例えば図１の端末１１）が、こ
のリプライを受信すると、ルータ４００までＳＶＣをセ
ットアップすることができる。この結果、送信端末が送
信したＩＰパケットは一旦、ルータ４００のＩＰ層に到
着することになる。このＩＰパケットの扱いはルータ４
００のＩＰ層に任せることができる。これにより、ＩＰ
レベルでのパケットフィルタリング等の機能を使うこと
ができる（ルータ４００のＩＰ層の処理については本発
明の範囲外であるので省略する）。
のリプライを受信すると、ルータ４００までＳＶＣをセ
ットアップすることができる。この結果、送信端末が送
信したＩＰパケットは一旦、ルータ４００のＩＰ層に到
着することになる。このＩＰパケットの扱いはルータ４
００のＩＰ層に任せることができる。これにより、ＩＰ
レベルでのパケットフィルタリング等の機能を使うこと
ができる（ルータ４００のＩＰ層の処理については本発
明の範囲外であるので省略する）。
【００８０】以上の動作により、認証タイプが異なるＬ
ＩＳ間のＮＨＲＰ Ｒｅｓｏｌｕｔｉｏｎ Ｒｅｑｕｅ
ｓｔの場合は、他のルータのアドレス情報をリプライす
ることにより、送信端末からセットアップされるＳＶＣ
を一旦このルータで終端し、このルータのＩＰ層に、受
信するＩＰパケットの処理を任せるという、認証モード
「ゲートウェイモード」を実現できる。
ＩＳ間のＮＨＲＰ Ｒｅｓｏｌｕｔｉｏｎ Ｒｅｑｕｅ
ｓｔの場合は、他のルータのアドレス情報をリプライす
ることにより、送信端末からセットアップされるＳＶＣ
を一旦このルータで終端し、このルータのＩＰ層に、受
信するＩＰパケットの処理を任せるという、認証モード
「ゲートウェイモード」を実現できる。
【００８１】次に第６の実施の形態の動作について説明
する。第６の実施の形態の動作は、第２の実施の形態か
ら第５の実施の形態の動作と基本的には同様である。但
し、入力インターフェイスおよび出力インターフェイス
に割り当てられている認証タイプに関わらず、設定され
ている認証モードに従ってＮＨＲＰパケットを処理す
る。例えば、ＮＨＳ−Ｂ ２００がＮＨＲＰパケットを
受信したとする。ステップ５０１からステップ５０８ま
では、第２の実施の形態から第５の実施の形態の場合と
同様である。
する。第６の実施の形態の動作は、第２の実施の形態か
ら第５の実施の形態の動作と基本的には同様である。但
し、入力インターフェイスおよび出力インターフェイス
に割り当てられている認証タイプに関わらず、設定され
ている認証モードに従ってＮＨＲＰパケットを処理す
る。例えば、ＮＨＳ−Ｂ ２００がＮＨＲＰパケットを
受信したとする。ステップ５０１からステップ５０８ま
では、第２の実施の形態から第５の実施の形態の場合と
同様である。
【００８２】ステップ５０９で、パケットを受信したイ
ンターフェイスの認証キーのタイプと、送信すべきイン
ターフェイスの認証キーのタイプが同じかどうか判断す
る処理をせず、そのままステップ５１１に進む。
ンターフェイスの認証キーのタイプと、送信すべきイン
ターフェイスの認証キーのタイプが同じかどうか判断す
る処理をせず、そのままステップ５１１に進む。
【００８３】ステップ５１１で、図２の認証モード記憶
部２０３から、入力インターフェイス１から出力インタ
ーフェイス２へ転送する際の認証モードを取り出す。以
降、この認証モードに従って第２の実施の形態から第５
の実施の形態の場合と同様に処理する。
部２０３から、入力インターフェイス１から出力インタ
ーフェイス２へ転送する際の認証モードを取り出す。以
降、この認証モードに従って第２の実施の形態から第５
の実施の形態の場合と同様に処理する。
【００８４】なお、認証モード記憶部２０３に、該当す
る認証モードが設定されていない時は、例えば、フォワ
ードモードと同様の処理を行なう。
る認証モードが設定されていない時は、例えば、フォワ
ードモードと同様の処理を行なう。
【００８５】
【発明の効果】第１の効果は、ＬＩＳ間で認証タイプが
異なった時のＮＨＲＰパケットの転送のモードおよび管
理ドメイン間でＮＨＲＰパケットの転送を行なう時のモ
ードを、管理ドメイン毎に設定できることにある。
異なった時のＮＨＲＰパケットの転送のモードおよび管
理ドメイン間でＮＨＲＰパケットの転送を行なう時のモ
ードを、管理ドメイン毎に設定できることにある。
【００８６】その理由は、各ＮＨＳが認証モードテーブ
ルを持ち、これをネットワーク管理者が「ドロップモー
ド」、「フォワードモード」、「ゲートウェイモード」
のいずれかに設定することにより、各ＮＨＳがＮＨＲＰ
パケットの転送時の認証の方法を変えるためである。
ルを持ち、これをネットワーク管理者が「ドロップモー
ド」、「フォワードモード」、「ゲートウェイモード」
のいずれかに設定することにより、各ＮＨＳがＮＨＲＰ
パケットの転送時の認証の方法を変えるためである。
【００８７】第２の効果は、認証の方法について異なる
ベンダのＮＨＳ間でも相互運用性が保てることにある。
ベンダのＮＨＳ間でも相互運用性が保てることにある。
【００８８】その理由は、第１の効果の通り、認証のた
めの動作を明らかにしたためである。
めの動作を明らかにしたためである。
【図１】本発明が対象とするネットワーク
【図２】ＮＨＳの構成のブロック図
【図３】認証キーテーブルの一般的構成
【図４】認証キーテーブルの例
【図５】認証モード記憶部の一般的構成
【図６】認証モード記憶部の例
【図７】各認証モードにおけるＮＨＲＰパケットの処理
【図８】本発明の認証方法のフローチャート
１ ＡＴＭネットワーク １１、１２、４１ 端末 １０、２０、３０、４０ ＬＩＳ １００、２００、３００ ＮＨＳ ４００ ルータ ２０１ ＮＨＲＰサーバ処理部 ２０２ 認証キー記憶部 ２０３ 認証モード記憶部 ２０４ ＩＰデータ転送部 ２０５ ＩＰルーティングテーブル
フロントページの続き (56)参考文献 特開 平10−65735（ＪＰ，Ａ) 特開 平10−65734（ＪＰ，Ａ) 特開 平９−149036（ＪＰ，Ａ) 信学技報 ＳＳＥ96−51 信学技報 ＳＳＥ96−105 1996年信学総合大会 Ｂ−807 ｄｒａｆｔ−ｉｅｔｆ−ｒｏｌｃ−ｎ ｈｒｐ−11．ｔｘｔ ｄｒａｆｔ−ｉｅｔｆ−ｒｏｌｃ−ｐ ｉｍ−ａｔｍ−00．ｔｘｔ (58)調査した分野(Int.Cl.6，ＤＢ名) H04L 12/56 H04L 12/28
Claims (6)
- 【請求項１】ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒ
ａｎｓｆｅｒ Ｍｏｄｅ）等のメディア共有型でないネ
ットワーク（ＮＢＭＡ：Ｎｏｎ−Ｂｒｏａｄｃａｓｔ，
Ｍｕｌｔｉ−Ａｃｃｅｓｓ）におけるネットワーク層ア
ドレスを、データリンク層アドレスへ変換するアドレス
解決を行なうＮＨＲＰプロトコル（ＮＨＲＰ：Ｎｅｘｔ
Ｈｏｐ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）
におけるＮＨＲＰパケットの認証方法において、 前記アドレス解決を行なう機能を提供するＮＨＲＰサー
バがｎ個のサブネットワークに所属するためのｎ個のイ
ンタフェースを有している場合、前記ＮＨＲＰサーバが
前記ｎ個のインタフェースに各々割り当てられている認
証キーおよびそのタイプを保持し、 前記ＮＨＲＰサーバが、前記ｎ個のインタフェースのう
ちあるインタフェースからＮＨＲＰパケットを受けとっ
た場合、前記インタフェースに割り当てられている認証
キーを用いて前記ＮＨＲＰパケットの認証を行ない、認
証が不正の場合に前記ＮＨＲＰパケットを破棄すること
を特徴とするＮＨＲＰパケットの認証方法。 - 【請求項２】前記ＮＨＲＰサーバが受信した前記ＮＨＲ
Ｐパケットが前記インターフェイスに割り当てられてい
る認証キーで認証され、第１のインターフェイスから第
２のインターフェイスに前記ＮＨＲＰパケットを転送す
る必要があり、前記第１のインターフェイスに割り当て
られている認証キーのタイプと前記第２のインターフェ
イスに割り当てられている認証キーのタイプが異なる場
合、前記ＮＨＲＰパケットを破棄することを特徴とする
請求項１に記載のＮＨＲＰパケットの認証方法。 - 【請求項３】前記ＮＨＲＰサーバが受信した前記ＮＨＲ
Ｐパケットが前記インターフェイスに割り当てられてい
る認証キーで認証され、第１のインターフェイスから第
２のインターフェイスに転送する必要があり、前記第１
のインターフェイスに割り当てられている認証キーのタ
イプと前記第２のインターフェイスに割り当てられてい
る認証キーのタイプが異なる場合、前記ＮＨＲＰパケッ
トの認証キー部を前記第２のインターフェイスに割り当
てられている認証キーに付け替えて、前記ＮＨＲＰパケ
ットを前記第２のインターフェイスから転送することを
特徴とする請求項１に記載のＮＨＲＰパケットの認証方
法。 - 【請求項４】前記ＮＨＲＰサーバが受信した前記ＮＨＲ
Ｐパケットが前記インターフェイスに割り当てられてい
る認証キーで認証され、前記第１のインターフェイスか
ら前記第２のインターフェイスに転送する必要があり、
前記第１のインターフェイスに割り当てられている認証
キーのタイプと前記第２のインターフェイスに割り当て
られている認証キーのタイプが異なる場合、前記ＮＨＲ
Ｐサーバの前記第１のインターフェイスのアドレス情報
を返送することを特徴とする請求項１に記載のＮＨＲＰ
パケットの認証方法。 - 【請求項５】前記返送するアドレス情報として、 前記第１のインターフェイスが属するサブネットワーク
と前記第２のインターフェイスが属するサブネットワー
クとの間でパケットの転送を行なうルータの、前記第１
のインターフェイスが属するサブネットワーク側のイン
ターフェイスのアドレス情報を用いることを特徴とする
請求項４に記載のＮＨＲＰパケットの認証方法。 - 【請求項６】前記第１のインターフェイスに割り当てら
れている認証キーのタイプと前記第２のインターフェイ
スに割り当てられている認証キーのタイプが異なるか異
ならないかに関わらず、設定されている認証モードに従
って、前記ＮＨＲＰパケットを処理することを特徴とす
る請求項２、３、４、５に記載のＮＨＲＰパケットの認
証方法。
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP34217996A JP2982727B2 (ja) | 1996-08-15 | 1996-12-20 | 認証方法 |
| US08/910,170 US6009102A (en) | 1996-08-15 | 1997-08-13 | NHRP packet authentication method and NHRP server |
| DE69735915T DE69735915T2 (de) | 1996-08-15 | 1997-08-13 | NHRP-Paketauthentifizierungsverfahren und NHRP-Server |
| EP97113967A EP0825745B1 (en) | 1996-08-15 | 1997-08-13 | NHRP packet authentication method and NHRP server |
| CA002213045A CA2213045C (en) | 1996-08-15 | 1997-08-14 | Nhrp packet authentication method and nhrp server |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP21574696 | 1996-08-15 | ||
| JP8-215746 | 1996-08-15 | ||
| JP34217996A JP2982727B2 (ja) | 1996-08-15 | 1996-12-20 | 認証方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10112709A JPH10112709A (ja) | 1998-04-28 |
| JP2982727B2 true JP2982727B2 (ja) | 1999-11-29 |
Family
ID=26521031
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP34217996A Expired - Fee Related JP2982727B2 (ja) | 1996-08-15 | 1996-12-20 | 認証方法 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US6009102A (ja) |
| EP (1) | EP0825745B1 (ja) |
| JP (1) | JP2982727B2 (ja) |
| CA (1) | CA2213045C (ja) |
| DE (1) | DE69735915T2 (ja) |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3094937B2 (ja) * | 1997-03-28 | 2000-10-03 | 日本電気株式会社 | Ａｔｍ論理ｉｐサブネットワークの障害復旧方式 |
| FI105753B (fi) * | 1997-12-31 | 2000-09-29 | Ssh Comm Security Oy | Pakettien autentisointimenetelmä verkko-osoitemuutosten ja protokollamuunnosten läsnäollessa |
| US6252857B1 (en) * | 1998-03-04 | 2001-06-26 | At&T Corp. | Method and apparatus for provisioned and dynamic quality of service in a communications network |
| US6976093B2 (en) | 1998-05-29 | 2005-12-13 | Yahoo! Inc. | Web server content replication |
| US7143193B1 (en) | 1998-05-29 | 2006-11-28 | Yahoo! Inc. | Content collection |
| US7581006B1 (en) * | 1998-05-29 | 2009-08-25 | Yahoo! Inc. | Web service |
| JP4080599B2 (ja) * | 1998-06-17 | 2008-04-23 | 富士通株式会社 | 通信制御装置およびマルチキャスト対応ｌａｎに適用される通信制御方法 |
| AU5901499A (en) | 1998-08-26 | 2000-03-21 | Nortel Networks Limited | Non-broadcast, multiple access inverse next hop resolution protocol (innhrp) |
| JP2000295274A (ja) * | 1999-04-05 | 2000-10-20 | Nec Corp | パケット交換装置 |
| US6226752B1 (en) * | 1999-05-11 | 2001-05-01 | Sun Microsystems, Inc. | Method and apparatus for authenticating users |
| EP1085727A1 (en) | 1999-09-16 | 2001-03-21 | BRITISH TELECOMMUNICATIONS public limited company | Packet authentication |
| US6898200B1 (en) * | 1999-10-29 | 2005-05-24 | Nortel Networks Limited | Method for improving signaling efficiency and performing service load balancing in a connection oriented network |
| CN1297104C (zh) * | 2002-12-04 | 2007-01-24 | 华为技术有限公司 | 实现基于端口认证和基于传输层认证兼容的方法 |
| JP4174392B2 (ja) * | 2003-08-28 | 2008-10-29 | 日本電気株式会社 | ネットワークへの不正接続防止システム、及びネットワークへの不正接続防止装置 |
| US7716406B1 (en) * | 2005-03-02 | 2010-05-11 | Crossroads Systems, Inc. | Method and system for persistent reservation handling in a multi-initiator environment |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5600644A (en) * | 1995-03-10 | 1997-02-04 | At&T | Method and apparatus for interconnecting LANs |
| US5583862A (en) * | 1995-03-28 | 1996-12-10 | Bay Networks, Inc. | Method and apparatus for routing for virtual networks |
| US5617540A (en) * | 1995-07-31 | 1997-04-01 | At&T | System for binding host name of servers and address of available server in cache within client and for clearing cache prior to client establishes connection |
| US5699347A (en) * | 1995-11-17 | 1997-12-16 | Bay Networks, Inc. | Method and apparatus for routing packets in networks having connection-oriented subnetworks |
| JP2728064B2 (ja) * | 1995-11-20 | 1998-03-18 | 日本電気株式会社 | アドレス解決方法 |
| US5809233A (en) * | 1995-12-05 | 1998-09-15 | Lucent Technologies Inc. | Method of mapping from ATMARP to NHRP |
| US5828844A (en) * | 1996-10-08 | 1998-10-27 | At&T Corp. | Internet NCP over ATM |
-
1996
- 1996-12-20 JP JP34217996A patent/JP2982727B2/ja not_active Expired - Fee Related
-
1997
- 1997-08-13 US US08/910,170 patent/US6009102A/en not_active Expired - Lifetime
- 1997-08-13 EP EP97113967A patent/EP0825745B1/en not_active Expired - Lifetime
- 1997-08-13 DE DE69735915T patent/DE69735915T2/de not_active Expired - Lifetime
- 1997-08-14 CA CA002213045A patent/CA2213045C/en not_active Expired - Fee Related
Non-Patent Citations (5)
| Title |
|---|
| １９９６年信学総合大会 Ｂ−８０７ |
| ｄｒａｆｔ−ｉｅｔｆ−ｒｏｌｃ−ｎｈｒｐ−１１．ｔｘｔ |
| ｄｒａｆｔ−ｉｅｔｆ−ｒｏｌｃ−ｐｉｍ−ａｔｍ−００．ｔｘｔ |
| 信学技報 ＳＳＥ９６−１０５ |
| 信学技報 ＳＳＥ９６−５１ |
Also Published As
| Publication number | Publication date |
|---|---|
| EP0825745B1 (en) | 2006-05-24 |
| CA2213045C (en) | 2000-11-28 |
| EP0825745A2 (en) | 1998-02-25 |
| DE69735915T2 (de) | 2007-01-18 |
| CA2213045A1 (en) | 1998-02-15 |
| EP0825745A3 (en) | 2003-10-08 |
| US6009102A (en) | 1999-12-28 |
| JPH10112709A (ja) | 1998-04-28 |
| DE69735915D1 (de) | 2006-06-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11283772B2 (en) | Method and system for sending a message through a secure connection | |
| Luciani et al. | NBMA next hop resolution protocol (NHRP) | |
| JP2728064B2 (ja) | アドレス解決方法 | |
| JP2982727B2 (ja) | 認証方法 | |
| FI118619B (fi) | Menetelmä ja järjestelmä tiedon salaamiseksi ja tallentamiseksi | |
| CA2169493C (en) | Method and apparatus for interconnecting atm emulated lans | |
| US8082447B2 (en) | Systems and methods for end-to-end resource reservation authentication | |
| JPH09252323A (ja) | 通信システムおよび通信装置 | |
| Armitage et al. | IPv6 over Non-Broadcast Multiple Access (NBMA) networks | |
| GB2374497A (en) | Facilitating legal interception of IP connections | |
| Richardson et al. | Opportunistic encryption using the internet key exchange (ike) | |
| Eronen et al. | IKEv2 clarifications and implementation guidelines | |
| JP2845207B2 (ja) | アドレス解決装置 | |
| US6347338B1 (en) | Precomputed and distributed security system for a communication network | |
| US7895648B1 (en) | Reliably continuing a secure connection when the address of a machine at one end of the connection changes | |
| US10841283B2 (en) | Smart sender anonymization in identity enabled networks | |
| Luciani et al. | RFC2332: NBMA Next Hop Resolution Protocol (NHRP) | |
| Beasley | NETWORKING HARDWARE | |
| EP1568184A1 (en) | Scalable and secure packet server-cluster | |
| JP3757547B2 (ja) | 認証機能を有する交換機 | |
| Piscitello et al. | Network Working Group J. Luciani Request for Comments: 2332 Bay Networks Category: Standards Track D. Katz cisco Systems | |
| Armitage et al. | RFC2491: IPv6 over Non-Broadcast Multiple Access (NBMA) networks | |
| Jork et al. | Network Working Group G. Armitage Request for Comments: 2492 Lucent Technologies Category: Standards Track P. Schulter BrightTiger Technologies | |
| Analyzer | NBMA Next Hop Resolution Protocol (NHRP) |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 19990824 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080924 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080924 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090924 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090924 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100924 Year of fee payment: 11 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110924 Year of fee payment: 12 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120924 Year of fee payment: 13 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130924 Year of fee payment: 14 |
|
| LAPS | Cancellation because of no payment of annual fees |