| Prev | Next |
ルータは、アプリケーション層プロトコルをサポートする必要がない場合はトランスポート層を実装する必要はない。実際は、これは大半のルータが転送制御プロトコル (TCP) とユーザデータグラムプロトコル (UDP) の両方を実装することを意味する。
ユーザデータグラムプロトコル (UDP) は、[TRANS:1] で規定される。
UDP を実装するルータは、以下を除いて [INTRO:2] の要件に準拠しなければならず (MUST)、無条件に準拠すべきである (SHOULD)。
DISCUSSION
特定のアプリケーションプロトコルは、受信した
UDP データグラムが UDP チェックサムを含んでいなければならないことを要求してもよいが、受信した
UDP データグラムが UDP チェックサムを含むという一般的な要件はない。無論、もし
UDP チェックサムが受信した UDP に提供されたら、そのチェックサムをチェックし、もし不正ならば破棄しなければならない。
転送制御プロトコル (TCP) は、[TRANS:2] で規定される。
TCP を実装するルータは、以下を除いて [INTRO:2] の要件に準拠しなければならず (MUST)、無条件に準拠すべきである (SHOULD)。
DISCUSSION
ルータ中の TCP 実装は、[INTRO:2]
の次の要件に適合しなければならないことに、特に注意すべきである。
一般に適用されるパラダイムは、もし特定のインタフェースがルータの外側で見えるならば、そのインタフェースに対する全ての要件に従わなければならない。例えばもしルータが telnet 機能を提供するならばトラフィックを生成し、外部ネットワークに振り分けられるだろう。従って、サービスタイプを正しく設定できなければならず、さもなくば telnet トラフィックが通じないかもしれない。
技術的、経済的、時々政治的な理由により、インターネットルーティングシステムは二つの構成要素で構成される。それは、内部ルーティングと外部ルーティングである。自律システム (AS) の概念は、このドキュメントのセクション 2.2.4 で定義されているように、外部ルーティングから内部ルーティングを切り離す際にキーの役割を果たし、この概念により、内部から外部への変更が発生する一組のルータを正確に捉えることが可能になる。IP データグラムは、宛先に到達するために二つ以上の自律システムのルータを横断しなければならないかもしれず、そうした転送を可能にするために、自律システムは互いにトポロジ情報を提供しなければならない。内部ゲートウェイプロトコル (IGP) は、AS の範囲内でルーティング情報を分散するために使用される (イントラ AS ルーティング) 。外部ゲートウェイはプロトコルは、AS 間でルーティング情報を交換するために使用される。
ルーティングは、安定性原理 (受信するものに寛大であれ) が適用されない箇所の一つである。ルータは、他のルーティングシステムからルーティングデータを受信する際、比較的疑い深くあるべきである。
ルータはルーティング情報の送信元を、最も信頼できるものから最も信頼できないものまでランク付けする能力を提供し、最も信頼できる送信元から特定の宛先に関するルーティング情報を最初に受信すべきである (SHOULD)。これは、EGP や様々な内部ルーティングプロトコルを使用する元のコア/スタブ自律システムルーティングモデルにおいて暗黙的であった。それは中央の信頼できるコアが無くなってもさらに重要である。
ルータは、明白に不正な経路 (例えばネット 127) をフィルターするメカニズムを提供すべきである (SHOULD)。
ルータはデフォルトで、自分自身が使用していない、信頼していない、正当であるとみなしていないルーティングデータを再配布してはならない (MUST NOT)。希なケースで、疑わしい情報を再配布することが必要かもしれないが、これはある人間の機関による直接の調停下でのみ起こすべきである。
ルータは、どこかからルーティングデータを受信することは、少なくとも若干は恐れなければならず、別のパーティーによって提供されたルーティング情報を配布する時、特に注意しなければならない。特定の指針については、以下を参照されたい。
特定のルーティングプロトコルの規約で規定しているものを除き、ルータはルーティングトラフィックを運ぶ IP データグラムの IP 優先度値を 6 (INTERNETWORK CONTROL) に設定すべきである (SHOULD)。
DISCUSSION
ルーティングトラフィックはほとんど例外無く、如何なるネットワークにおいても最も高い優先度であるべきである。もしシステムのルーティングトラフィックが通じなければ、他の機会は無いだろう。
ペアツーペアの認証は幾つかのテストを伴う。メッセージパスワードと明示的に受諾できる隣接者リストのアプリケーションは、過去に経路データベースの強靭性を改善した。ルータは、正しいルーティング隣接者の明示的なリスト化を可能にする管理制御を実装すべきである (SHOULD IMPLEMENT)。ルータは、それをサポートしているルーティングプロトコルのためのペアツーペアの認証を実装すべきである (SHOULD IMPLEMENT)。
ルータは、送信元アドレスとメッセージを受信したインタフェースに基づいてルーティング隣接者を評価すべきである (SHOULD)。すなわち、サブネットと仮定したインタフェースを経由して、あるいはアンナンバードインタフェースを経由してルータと通信するために、直接接続されたサブネット内の隣接者に限定されるべきである (SHOULD)。他のインタフェース上で受信したメッセージは、黙って破棄すべきである (SHOULD)。
DISCUSSION
セキュリティ破りや多数のルーティング問題は、この基本的なテストによって避けられる。
内部ゲートウェイプロトコル (IGP) は、特定の AS 内の様々なルータ間でルーティング情報を配布するために使用される。特定の IGP を実装するために使用されるアルゴリズムには関係なく、以下の機能を実現すべきである。
インターネットで今日使用される現在の IGP は、距離ベクトルかリンク状態アルゴリズムのいずれかに基づくものとして特徴付けられる。
最も一般的に使用されるものや、将来広く使用されると思われる最近開発されたプロトコルを含め、幾つかの IGP についてはこのセクションで詳細に説明する。イントラ AS ルーティングで使用することを意図した数多くの他のプロトコルが、インターネット社会に存在する。
ルーティングプロトコル (静的経路以外) を実装しているルータは、OSPF (セクション [7.2.2] 参照) を実装しなければならない (MUST IMPLEMENT)。ルータは追加の IGP を実装してもよい (MAY)
最短パス優先 (SPF: Shortest Path First) ベースのルーティングプロトコルは、Dijkstra の最短パスアルゴリズムに基づくリンク状態アルゴリズムの一つのクラスである。SPF ベースのアルゴリズムは大体 ARPANET の頃から存在するが、IP と OSI 社会の両方で主に使われるようになったのはほんの最近のことである。SPF ベースのシステムでは、各々のルータはフラッディングと呼ばれるプロセスを通じてトポロジ全体のデータベースを得る。フラッディングは情報の信頼できる転送を保証する。そして各々のルータは、IP ルーティングテーブルを作成するために、自身のデータベースに対して SPF アルゴリズムを実行する。OSPF ルーティングプロトコルは、SPF アルゴリズムの実装である。現在のバージョンは、[ROUTE:1] で規定されている OSPF バージョン 2 である。OSPF バージョン 1 を規定している RFC-1131 は廃止されたことに注意されたい。
このメモのセクション [8.3] に従うために、OSPF を実装するルータは OSPF MIB [MGT:14] を実装しなければならない (MUST)。
米国規格協会 (ANSI) X3S3.3 委員会は、内部ドメインルーティングプロトコルを定義した。このプロトコルは、中間システムツー中間システムルーティング交換プロトコルと名づけられた。
IP ネットワークへのそのアプリケーションは [ROUTE:2] で定義され、二重 IS-IS (あるいは統合 IS-IS) と呼ばれている。IS-IS はリンク状態 (SPF) ルーティングアルゴリズムに基づき、プロトコルのこのクラスの長所を全て共有する。
外部ゲートウェイプロトコルは、特定の自律システムへの一連のネットワークの到達性情報を、隣接する自律システムと交換するための自律システム間ルーティングとして利用される。
AS 間ルーティングの分野は、インターネット技術作業団体内の現在の調査トピックである。セクション [付録 F.1] で規定されている外部ゲートウェイプロトコル (EGP) は、伝統的にえり抜きの AS 間プロトコルであるが、現在は歴史的である。ボーダーゲートウェイプロトコル (BGP) は EGP の数多くの制限や限定を取り除き、その結果急速に普及しつつある。ルータは AS 間ルーティングプロトコルを実装する必要はない。しかし、もしルータが EGP を実装するならば、BGP も実装しなければならない (MUST IMPLEMENT)。外部ゲートウェイプロトコルとして設計されてはいないが、RIP (セクション [7.2.4] で規定) は時々 AS 間ルーティングのために使用されることがある。
ボーダーゲートウェイプロトコル (BGP-4) は、他の BGP スピーカーとネットワーク到達性情報を交換する AS 間ルーティングプロトコルである。ネットワークの情報は、そのネットワークに到達するためにトラフィックが通過しなければならない AS の完全なリストを含む。そして、この情報はループフリーパスを保証するために使用できる。この情報は AS の接続性のグラフを構成するのに十分であり、そのグラフによってルーティングループを取り除いたり、AS レベルのポリシー決定を施行してもよい。
BGP は [ROUTE:4] によって定義される。[ROUTE:5] は、インターネットにおける BGP の適切な使用方法を規定し、有効な実装上のヒントとポリシーを提供する。[ROUTE:12] と [ROUTE:13] は、追加の有効情報を提供する。
このメモのセクション [8.3] に従うには、BGP を実装するルータは BGP MIB [MGT:15] を実装する必要がある。
BGP の使用を施行できる一連のポリシー決定を特徴付けるために、AS が隣接 AS に自分自身が使用している経路だけを通知する規則に焦点を合わせなければならない。この規則は、現在のインターネットを通じて一般的に使用されているホップバイホップのルーティングパラダイムを反映している。幾つかのポリシーはホップバイホップのルーティングパラダイムによってサポートできず、従って送信元ルーティングを施行する等の技術が必要であることに注意されたい。例えば BGP では、隣接 AS でのトラフィクの起動によって採用されたものから、トラフィックが異なる経路を採用することを意図して、ある AS が隣接 AS にトラフィックを送信することができない。一方、BGP はホップバイホップのルーティングパラダイムに適合する如何なるポリシーもサポートできる。
BGP の実装者は、[ROUTE:5] のセクション 6 で概説された推奨に従うことを強く推奨される。
BGP は ([ROUTE:5] のセクション 4.2 の例に見られるような) 極めて複雑なルーティングポリシーのサポートを提供するが、全ての BGP 実装者がそのようなポリシーをサポートする必要があるわけではない。しかし、最低限 BGP 実装は、
二つの別個の、標準の内部ルーティングプロトコルの間で標準の外部ルーティングプロトコルを使用せずに、二つの自律システムかルーティングドメイン間で、ルーティング情報を交換することは可能である。これを行う最も一般的な方法は、二つのプロセス間の経路情報の交換を行う境界ルータの一つで、独立して両方の内部プロトコルを実行することである。
EGP から IGP への情報の交換において、適切な制御がなければ、単一ルータにおける二つの IGP 間のルーティング情報のこれらの交換は、ルーティングループを生成しそうである。
静的ルーティングは、特定の宛先に対するルータからの次ホップを明示的に定義する手段を提供する。ルータは宛先への静的経路を定義する手段を提供すべきである (SHOULD)。その場合、宛先はネットワークプレフィクスによって定義される。そのメカニズムは、各々の静的経路に対してメトリックの指定も可能にすべきである (SHOULD)。
動的ルーティングプロトコルをサポートするルータは、使用するルーティングプロトコルにおいて正しいメトリックで静的経路を定義することを可能にしなければならない (MUST)。ルータは、ルーティングプロトコルを通じて通知するかもしれない静的経路のリストを、ユーザが指定する能力を提供しなければならない (MUST)。加えて、もしその情報を使用できるルーティングプロトコルをサポートするならば、ルータは以下の追加情報をサポートすべきである (SHOULD)。
DISCUSSION
所定のルーティングプロトコルに有効なものだけをサポートする必要かあることを意図している。TOS
の必要性は、もしそれを使用しないならば、ベンダに他の部分の実装を要求すべきでない。
ルータが動的経路 (等) 上で静的経路をより好むか否かや、静的と動的経路が衝突する際に、割り当てられたメトリックを選択するのに使用するか否かは、各々の静的経路に対して設定可能にすべきである (SHOULD)。
ルータは、サポートする各々のルーティングドメインのための静的経路に、メトリックを割り当てることを可能にしなければならない (MUST)。そうした各々のメトリックは、特定のルーティングドメインに明示的に割り当てなければならない (MUST)。例えば、
route 10.0.0.0/8 via 192.0.2.3 rip metric 3
route 10.21.0.0/16 via 192.0.2.4 ospf inter-area metric 27
route 10.22.0.0/16 via 192.0.2.5 egp 123 metric 99
DISCUSSION
理想的には、静的経路はメトリックではなく優先度値を持つべきであることが提案されている
(メトリックは同じルーティングドメインの中の他の経路のメトリックとしか比較できないので、静的経路のメトリックは他の静的経路のメトリックとしか比較できない)。これは、静的経路が実際にメトリックを持ち、それらのメトリックが特定の動的経路を同じ宛先への静的経路に上書きするか否かを決定するために使用されるような、幾つかの実装とは正反対である。従って、このドキュメントは優先度ではなくメトリックという用語を使用する。
この技術は、本質的に RIP 経路か OSPF 経路 (あるいはメトリックのドメインに依存した何か) の中に、静的経路を作成する。従って、そのドメインの経路検索アルゴリズムが適用できる。しかし、静的経路を動的ルーティングドメインの中に強いることは、ルータがその経路を動的ルーティングドメインに再配布する権限を与えないので、これは経路漏れではない。
特定のルーティングドメインに置かれない静的経路のために、経路検出アルゴリズムは
最終ステップは必要ないかもしれないが、一つのインタフェース上に主要静的経路、代替インタフェース上に第二静的経路を持ちたい場合に有効である。その場合、もし主要経路のインタフェースが障害ならば代替パスにフェイルオーバーできる。
ネットワーク内のルータは、転送データグラムダース内に含まれた情報に基づいて転送決定を下す。単純なネットワークでは、データベースの内容は静的に設定可能かもしれない。ネットワークがより複雑になるにつれ、転送データベースの動的更新の必要性がネットワークの効率的な運用のために重要である。
もしネットワークを通じたデータフローを可能な限り効率的にするならば、転送データベースを作成するためにルータが使用する情報の通知を制御するメカニズムを提供することが必要である。この制御はルーティング情報の送信元が信頼できるものを選択し、信用できる情報の部分を選択するという形態を取る。その結果の転送データベースは、利用可能な経路情報のフィルタされたバージョンである。
効率性に加え、ルーティング情報の通知を制御することは、不正なあるいは悪いルーティング情報の広がりを防ぐことによって不安定さを減らす。
幾つかのケースで、ローカルポリシーは広く通知しない完全なルーティング情報を必要とするかもしれない。
これらのフィルタリング要件は、非 SPF ベースのプロトコルにのみ適用される (従って距離ベクトルアルゴリズムを実装しないルータには全く適用されない)。
もし更新を受信したルーティングプロトコルが、それらの値を特別な経路 (例えばデフォルト経路) を符号化するために使用しないならば、ルータはこのメモの規定に違反した経路を通知しているルーティング更新を、エラーとしてログに記録すべきである (SHOULD)。
ルーティング情報のフィルタリングは、受信したパケットを転送するためにルータによって使用されるパスの制御を可能にする。ルータはルーティング情報のどの送信元をリッスンするか、どの経路を信じるかを選択可能にすべきである。従って、ルータは以下を指定する能力を提供しなければならない (MUST)。
あるルーティングプロトコルは、論理インタフェースをルーティング情報の送信元として認識しない。そのような場合、ルータは以下を指定する能力を提供しなければならない (MUST)。
例えば、一つ以上のリーフネットワークを、主要な部分やより大きなネットワークのバックボーンに接続しているルータを想定する。リーフネットワークの各々は入出力のパスを一つしか持っていないので、ルータは単にデフォルト経路に送信することができる。ルータはリーフネットワークを主ネットワークに通知する。
ネットワークのトポロジがより複雑になるにつれて、より複雑な経路フィルタリングの必要性が増している。従って、ルータは各々のルーティングプロトコルに依存せずに、以下を指定する能力を提供すべきである (SHOULD)。
多くの状況では、別のルータから受信したルーティング情報に、上記の第一段落に示されている単に信用するか信用しないかの選択の代わりに、信頼性の順位を割り当てることが望ましい。ルータは以下を指定する能力を提供してもよい (MAY)。
もしルータが優先度の割り当てをサポートするならば、ルータは第一パーティ情報として好まない経路を通知してはならない (MUST NOT)。もし経路を通知するために使用しているルーティングプロトコルが、第一と第三のパーティ情報を区別できないならば、ルータは好まない経路を通知してはならない (MUST NOT)。
DISCUSSION
例えば、ルータがルータ R からネットワーク C までの経路とルータ
S から同じネットワークまでの経路を受信すると仮定する。もしルータ
R がルータ S よりも信頼性が高いと見なすならば、ネットワーク C
向けのトラフィックは、ルータ S から受信した経路に関わらずルータ
R に転送されるだろう。
ルータが使用しない経路のルーティング情報 (上記の例ではルータ S) は、他のルータに渡してはならない (MUST NOT)。
もし同じルータの中で複数の独立した IP ルーティングプロセスを実行できるならば、ルータは別々の IP 内部ルーティングプロトコル間で、ルーティング情報を交換できなればならない (MUST)。ルータが二つの別個の内部ルーティングプロセス間でルーティング情報の 2 方向の交換を行うために設定される時、ルータはルーティングループを避けるためのメカニズムを提供しなければならない (MUST)。ルータは独立したルーティングプロセスから経路を選択するために、幾つかの優先度メカニズムを提供しなければならない (MUST)。ルータは、管理上の境界をまたがって使用する場合、IGP-IGP 交換の管理上の制御を提供すべきである (SHOULD)。
ルータは、ネットワーク毎に翻訳、あるいは変換メトリックのための幾つかのメカニズムを提供すべきである (SHOULD)。ルータ (あるいはルーティングプロトコル) は、IGP にインポートされる外部経路のグローバルな優先度を可能にしてもよい (MAY)。
DISCUSSION
異なる IGP は異なるメトリックを使用し、情報をあるプロトコルからメトリックの異なる形式を持つ別のプロトコルに導入する時、翻訳技術を必要とする。幾つかの
IGP は、同じルータかルータのセットの中に複数のインスタンスを実行することができる。この場合、メトリック情報は正確に保持するか翻訳することができる。
異なるルーティングプロセスの間で翻訳するのに、少なくとも二つの技術が存在する。静的 (あるいは到達可能性) アプローチは、所定のメトリックで他の IGP における経路通知を生成するために、ある IGP における経路通知の存在を使用する。翻訳あるいは表のアプローチは、機能 (定数値を追加する等) か表検索のいずれかを使用して、他の IGP におけるメトリックを生成するために、ある IGP のメトリックを使用する。
ルーティング情報の 2 方向の交換は、フィードバックを制限するための制御メカニズム無しでは危険である。これは、距離ベクトルルーティングプロトコルが水平分割技術を取り上げたり、EGP がサードパーティ規則を取り上げることと同じ問題である。ルーティングループは、許可/拒否経路のテーブルかリストを使用することによって明示的に避けることができ、また水平分割規則や非サードパーティ規則や経路タグ付けメカニズムを使用することによって暗黙的に避けることができる。ベンダは、ネットワーク運用者の管理をより容易にすることを可能にするために、暗黙的なメカニズムを使用することが推奨される。
このチャプタは [INTRO:3] の "遠隔管理" で述べられている要件に取って代わることに注意されたい。
ルータは SNMP [MGT:3] によって管理しなければならない (MUST)。SNMP は、トランスポートとネットワークプロトコルとして、UDP/IP を使用して運用しなければならない (MUST)。他のもの ([MGT:25], [MGT:26], [MGT:27], [MGT:28] 参照) をサポートしてもよい (MAY)。SNMP 管理運用は、あたかもルータ自身に SNMP が実装されているように運用しなければならない (MUST)。特に、管理運用はルータのインタフェースに割り当てられた IP アドレスに、SNMP 管理要求を送信することによって実施しなければならない (MUST)。実際の管理運用は、ルータかルータのためのプロクシのいずれかによって実現してもよい。
DISCUSSION
この言葉は、プロクシ装置がパケットの宛先アドレスフィールドにルータの IP アドレスの一つを持つ SNMP パケットに応答する場合はプロクシによって、あるいはルータ自身の中に
SNMP を直接実装し、パケットを受信して適切な方法で応答を返すことによってのいずれかで管理できることを意図している。
管理運用をルータの IP アドレスの一つに送信できることは重要である。ネットワークの問題を診断する際、使用可能なルータを識別する唯一のものは、ルータの IP アドレスの一つかもしれない。それは、恐らく別のルータのルーティングテーブルを見ることによって獲得されるだろう。
あらゆる SNMP 運用 (get, get-next, get-response, set, trap) を実装しなければならない (MUST)。
ルータは、SNMP トラップメッセージの生成を制限する割合を指定するメカニズムを提供しなければならない (MUST)。ルータは、[MGT:5] で説明されている非同期警告管理のアルゴリズムを通じて、このメカニズムを提供してもよい (MAY)。
DISCUSSION
トラップの割合制限の必要性についての一般合意はあるが、これをどのように最善に実現するかについてコンセンサスがまだない。引用されている参照は実験と見なされる。
この規約の目的のために、ルータ内に抽象的な 'コミュニティテーブル' が存在すると仮定する。このテーブルは幾つかのエントリを含み、特定のコミュニティに対する各エントリは、そのコミュニティの属性を完全に定義するために必要なパラメタを含む。抽象的なコミュニティテーブルを実際に実装する方法は、無論実装特定である。
ルータのコミュニティテーブルは少なくとも一つのエントリを可能にしなければならず (MUST)、少なくとも二つのエントリを可能にすべきである (SHOULD)。
DISCUSSION
容量がゼロのコミュニティテーブルは無意味である。それはルータが如何なるコミュニティも認識せず、従って全ての
SNMP 運用が拒否されることを意味する。
従って、一エントリはテーブルの最低限の有効サイズである。二つのエントリを持つことにより、一つのエントリは読み込みだけのアクセスを許可し、他方には書き込み能力を持たせることが可能になる。
ルータは、SNMP コミュニティテーブル中のエントリをチェック、追加、削除をユーザが手動で (SNMP を使用せずに) 行えるようにしなければならない (MUST)。ユーザはコミュニティ名を設定するか、MIB ビューを生成できなければならない (MUST)。ユーザは、コミュニティを読み込みだけ (すなわち SET 不許可) か読み書き可能 (すなわち SET 許可) としてコミュニティを設定できなければならない (MUST)。
もしトラップを使用するならば、ユーザは各々のコミュニティか MIB ビューのための通知を送信する、少なくとも一つの IP アドレスを定義できなければならない (MUST)。これらのアドレスは、コミュニティか MIB ビューに基づいて定義可能にすべきである (SHOULD)。コミュニティか MIB ビューに基づく通知の可/不可の設定を可能にすべきである (SHOULD)。
ルータは、特定のコミュニティの正しいネットワーク管理者のリストを指定する能力を提供すべきである (SHOULD)。もし可能ならば、ルータは SNMP データグラムの送信元アドレスをリストに対して評価しなければならず (MUST)、もしそのアドレスが無ければ、データグラムを破棄しなければならない (MUST)。もしデータグラムを破棄したら、ルータは SNMP 認証失敗に対する適切な全てのアクションを行わなければならない (MUST)。
DISCUSSION
これはむしろ限定された認証システムであるが、様々なパケットフィルタリングの形式と組み合わせて、ある程度セキュリティを高めてもよい。
コミュニティテーブルは、不揮発性の記憶装置に保存しなければならない (MUST)。
コミュニティテーブルの初期状態は、公のコミュニティ名文字列と読み込みのみのアクセス権を持つ一つのエントリを含むべきである (SHOULD)。このエントリのデフォルト状態はトラップを送信してはならない (MUST)。もしそれが実装されているならば、このエントリは管理者がそれを変更する、または削除するまで、コミュニティテーブルに残ったままでなければならない (MUST)。
DISCUSSION
デフォルトでは、トラップはこのコミュニティに送信されない。トラップ
PDU は、ユニキャスト IP アドレスに送信される。このアドレスは、ある方法でルータ内に設定しなければならない。設定する前はそうしたアドレスは存在しないので、誰にトラップを送信すべきか
? よって、公のコミュニティへのトラップの送信は、デフォルトで不可である。これはもちろん一旦ルータを操作すれば、管理上の運用により変更可能である。
ルータの設定に関連する全ての MIBS を実装すべきである。以下の通り。
インターネット標準と実験上の MIB は、ネットワーク要素で利用可能な統計、状態、設定、制御の情報の全体の範囲をカバーしていない。しかし、これらの情報は極めて有効である。ルータ (や他のネットワーク装置) のベンダは通常、この情報をカバーする MIB 拡張を開発している。これらの MIB 拡張は、ベンダ特定 MIB と呼ばれる。
ルータのベンダ特定 MIB は、実装された標準や実験上の MIB を通じて利用できない統計、状態、設定、制御の全ての情報へのアクセスを提供しなければならない (MUST)。この情報は監視と制御操作の両方で利用できなければならない (MUST)。
DISCUSSION
この要件の意図は、コンソール等を通じて実行できる
SNMP によって、ルータ上で何かを実行する能力を提供することである。SNMP
が操作できる前に、ある最低限の量の設定が必要である (例えばルータが
IP アドレスを持たなければならない)。この初期設定は SNMP を通じて行うことができない。しかし、一旦初期設定を行ったら、ネットワーク管理を通じて完全な機能を利用可能にすべきである。
ベンダは、全てのベンダ特定 MIB の規約を利用可能にすべきである (SHOULD)。これらの規約は SMI [MGT:1] に適合し、その説明は [MGT:4] で規定された形式でなければならない (MUST)。
DISCUSSION
ベンダ特定 MIB をユーザに利用可能にすることは必要である。この情報が無ければ、ユーザはベンダ特定パラメタにアクセス可能な自分達のネットワーク管理システムを設定できないだろう。すると、これらのパラメタは無意味になる。
MIB 記述の形式もまた規定されている。MIB 記述を読み、ネットワーク管理ステーションに必要なテーブルを生成する解析器もまた利用可能である。これらの解析器は通常、標準的な MIB 形式のみを理解する。
SNMP によって変更されたパラメタは、不揮発性記憶装置に保存してもよい (MAY)。
DISCUSSION
この要件が MAY である理由は以下の通り。
ルータが実装する全ての追加アプリケーションプロトコルに対して、ルータは [INTRO:3] の関連要件に従わなければならず (MUST)、無条件に従うべきである (SHOULD)。
ブートストラッププロトコル (BOOTP) は、起動するホストがユーザの管理無しに自分自身を動的に設定することを可能にする、UDP/IP ベースのプロトコルである。BOOTP は、自身に割り当てられた IP アドレス、ブートサーバホストの IP アドレス、メモリにロードされ実行されるファイルの名前をホストに通知する手段を提供する ([APPL:1])。ローカルプレフィクス長、サブネットマスク、ローカルタイムオフセット、デフォルトルータのアドレス、様々なインターネットサーバのアドレス等の他の設定情報も、BOOTP を使用するホストに通知できる ([APPL:2])。
多くの場合、BOOTP クライアントとそれに関係する BOOTP サーバは、同じ IP (サブ) ネットワーク上には存在しない。そのような場合、クライアントとサーバ間で BOOTP メッセージを転送するために、サードパーティエージェントが必要である。そうしたエージェントは、元々 BOOTP 転送エージェントと呼ばれる。しかし、ルータの IP 転送機能との混同を避けるために、BOOTP 配送エージェントという名前が代わりに適用される。
DISCUSSION
BOOTP 配送エージェントは、ルータの通常の IP 転送機能とは別のタスクを実現する。ルータは通常ネットワーク間でほぼ透過的に IP データグラムを交換するが、BOOTP
配送エージェントは、より正確には最終宛先として BOOTP メッセージを受信し、その結果として新しい
BOOTP メッセージを生成するものと考えられる。規則的なパケットの様に単純に BOOTP メッセージを直に転送するという考えは控えるべきである。
(クライアント (サブ) ネットに直接接続された場合は、代わりにホスト内に配置されるが)、この配送エージェント機能はクライアントとサーバ間を相互接続するルータ内に配置するのが最も都合がよい。
ルータは BOOTP 配送エージェント能力を提供してもよい (MAY)。もし提供するならば、ルータは [APPL:3] の規定に適合しなければならない (MUST)。
セクション [5.2.3] は、パケットがローカルに (ルータに) 配送される環境を論じている。UDP 宛先ポート番号が BOOTPS (67) であるローカルに配送される全ての UDP メッセージは、ルータの論理的な BOOTP 配送エージェントによる特別な処理と見なされる。
セクション [4.2.2.11] と [5.3.7] は、不正な IP 送信元アドレスについて論じている。これらの規則に従い、ルータは IP 送信元アドレスが 0.0.0.0 である受信データグラムを転送してはならない。しかし、BOOTP 配送エージェントをサポートするルータは、配送エージェントへのローカル配送で、IP 送信元アドレスが 0.0.0.0 である BOOTREQUEST メッセージを受け入れなければならない (MUST)。
このチャプタは "IP モデルの拡張" に関連する [INTRO:3] の要件に取って代わる。
運用と保守 (O&M) 活動をサポートする設備は、ルータ実装の本質的な部分を形成する。これらの機能は相互運用性とは直接関連しないように見えるが、ルータを相互運用しなければならず、運用できない場合に問題を追跡しなければならないネットワーク管理者にとっては重要である。このチャプタは、ルータの初期化やネットワークを安全で経済的にする際にネットワーク管理者を補助する設備についての議論も含む。
ルータの O&M には、以下の種類の活動が含まれる。
ルータや接続された通信回線は、集中化された O&M 組織によるシステムとしてしばしば運用される。この組織は、O&M 機能を実施するために、(内部) ネットワーク運用センター、または NOC を維持するかもしれない。ルータは NOC と同じネットワークに接続されないかもしれないので、NOC からインターネットパスを通じた遠隔制御や監視をサポートすることは重要である。ネットワーク障害により一時的にネットワークアクセスが妨げられるかもしれないので、多くの NOC はルータがネットワーク管理のために代替手段、大抵はルータのコンソールポートに接続されたダイアルアップモデム、を通じてアクセス可能であることを強く要求する。
インターネットを通過する IP パケットは、しばしば一つ以上の NOC の制御の下でルータを使用するので、インターネット問題の診断はしばしば一つ以上の NOC の人員協力を巻き込むだろう。ある場合、同じルータを一つ以上の NOC で監視する必要があるかもしれないが、極端な監視はルータのパフォーマンスに強く影響するので、必要な場合に限られる。
NOC で監視するために利用できるツールは、広範囲な精巧さをカバーしてもよい。現在の実装は、複数ウィンドウやルータシステム全体の動的表示を含む。自動問題診断のための AI 技術の使用は、将来的に要求される。
ここで論じられるルータの O&M 設備は、インターネット管理の大きくて難しい問題の部分のみである。これらの問題は複数管理組織だけでなく、複数のプロトコル層も含む。例えば、インターネット体系の発展の現段階では、ホスト TCP 実装と終局のルータシステム内の IP レベルの輻輳との間に強い関連性がある [OPER:1]。 従って輻輳問題の診断は、時々ホスト中で TCP 統計の監視を必要とするだろう。インターネット管理の分野の発展や、より特殊なルータ O&M に現在数多くの R&D 活動がある。これらの R&D の活動は既にルータ O&M の標準を作成した。これは、ベンダの創造性が重要な貢献となり得る分野でもある。
ルータがパケットを転送する前に満足させなければならない最低限の一連の条件がある。ルータは以下のいずれかを満たさなければ、如何なる物理インタフェースにも転送を可能にしてはならない (MUST NOT)。
これらのパラメタは明示的に設定しなければならない (MUST)。
DISCUSSION
ベンダがインタフェースに対してインストールしたデフォルトアドレスを持ってルータが出荷される実体がある。幾つかのケースにおいて、このことによりこれらのデフォルトアドレスが活性なネットワークに通知される結果を招く。
ルータは、自身の IP アドレスとアドレスマスクかプレフィクス長を静的に設定し、不揮発性記憶装置に保存できなければならない (MUST)。
ルータは、自身の IP アドレスとそれに対応するアドレスマスクを、システムの初期化処理の副作用で動的に獲得してもよい (MAY)。(セクション [10.2.3] 参照)
もし動的な方法を提供するならば、特定のルータで使用する方法の選択は設定可能でなければならない (MUST)。
セクション [4.2.2.11] で説明されているように、IP アドレスは <Host-number> か <Network-prefix> フィールドに 0 か -1 の値を持つことは許されない。従って、ルータは IP アドレスかアドレスマスクを、これらの上記のフィールドに 0 か -1 を持たせるような値に設定することを可能にすべきではない (SHOULD NOT)。
DISCUSSION
ルーティングが曖昧になる状況を生み出すために任意のアドレスマスクを使用することは可能である
(例えば異なるが、同時に特定のサブネットマスクを持つ二つの経路が、ある特定の宛先アドレスに一致する)。これはネットワークプレフィクスを使用する最も強力な論拠の一つであり、連続していないサブネットマスクの使用を許さない理由である。
ルータはインストールするアドレスマスクに対して以下のチェックを施すべきである (SHOULD)。
DISCUSSION
経路に割り当てられたマスクは時々サブネットマスクと呼ばれ、このテストはそれらに適用されるべきではない。
どのようにルータをネットワークから起動できるか、あるいは起動すべきかについて多くの議論がある。これらの議論は BOOTP や TFTP の周辺を巻き込んでいる。現在、ネットワークから TFTP によって起動するルータが存在する。起動イメージがそこからロードされるべきサーバを配置するために BOOTP を使用できない理由はない。
BOOTP は終端システムを起動するためのプロトコルであり、ルータでの使用に適応させるには拡張する必要がある。もしルータが BOOTP を使用するならば、現在の起動ホストを配置するために、最初のインタフェースに対する自分のハードウェアアドレスを持つ BOOTP 要求を、あるいはもし別途事前に設定されているならば、BOOTP パケットのハードウェアアドレスフィールドに指定するための別のインタフェースのハードウェアアドレスか別の番号を持つ BOOTP 要求を送信すべきである。これはハードウェアアドレス無しで (同期回線だけのルータの様に)、起動ロード検出で BOOTP の使用を可能にするためである。その後 BOOTP 応答で検出したイメージを取り込むために TFTP を使用することができる。もし使用するインタフェースか番号を設定していなければ、ルータは BOOTP サーバによって一致するものが検出されるまで、インタフェースハードウェアアドレスを通じて巡回してもよい (MAY)。
ルータは、BOOTP を通じて認識したパラメタをローカルの不揮発性記憶装置中に格納する能力を実装すべきである (SHOULD IMPLEMENT)。ルータは、ネットワーク上でロードされるシステムイメージをローカルの固定記憶装置中に格納する能力を実装してもよい (MAY)。
ルータは、ルータが新しいブートイメージの取得するよう、リモートユーザが要求することを可能にする設備を持ってもよい (MAY)。三つの場所: 要求に含まれた場所、最後に起動イメージを取得したサーバ、サーバを配置するために BOOTP を使用、の一つから新しい起動イメージを取得することを区別すべきである。
O&M 機能をルータ上で実現するのに可能なモデルの範囲がある。極端なものはローカルだけのモデルで、O&M 機能をローカルにのみ (例えば、ルータ機器に接続された端末から) 実行できる。別の極端なものは、絶対的に最低限なローカルに実行される機能 (起動の強制等) のみを許した完全なリモートモデルで、NOC から最もリモートに行われる O&M を持つ。NOC の人員が、ローカルにも呼び出すことのできる機能を実行するために、telnet プロトコルを使用してホストのようにルータにログインする等の中間のモデルがある。ローカルのみのモデルは幾つかのルータのインストールでは適切かもしれないが、NOC からの遠隔操作が通常必要とされ、従って遠隔 O&M の準備が大半のルータに必要である。
遠隔 O&M 機能は、制御エージェント (プログラム) を通じて実施される。直接のアプローチでは、ルータは遠隔 O&M 機能を標準的なインターネットプロトコル (SNMP や UDP、TCP 等) を使用して、NOC から直接サポートする。直接でないアプローチでは、制御エージェントはこれらのプロトコルをサポートし、専用プロトコルを使用してルータ自身を制御する。どちらのアプローチもアクセス可能であるが、直接アプローチの方が好ましい。重要な追加投資を必要とする専門のホストハードウェアやソフトウェアの使用は推奨されない。それでもやはり、あるベンダはルータが一つの構成要素であるネットワークの統合された一部として、制御エージェントの提供を選択するかもしれない。もしこのケースであるならば、インターネットプロトコルとパスとローカルエージェント端末に関して同等の機能性を使用して、遠隔サイトから制御エージェントを操作するために利用可能な手段が必要である。
制御エージェントとベンダが提供する他の NOC ソフトウェアツールは、標準的なオペレーションシステムでユーザプログラムとして操作することが望ましい。ルータとの通信で標準的なインターネットプロトコル UDP と TCP を使用することは、これを容易にするはずである。
遠隔ルータ監視と (特に) 遠隔ルータ制御は、取り組まなければなければならない重要なアクセス制御問題をもたらす。これらの機能のためのルータ資源の使用の制御を保証することも注意しなければならない。例えばルータの CPU 時間の制限された配分よりも、ルータ監視により多く取らせることは望ましいことではない。一方、ルータが輻輳した時は大抵 O&M が最も必要とされるケースなので、その場合は O&M 機能の役割を行使できるよう優先させなければならない。
ルータは帯域外アクセス (OOB) をサポートしなければならない (MUST)。OOB アクセスは帯域内アクセスと同じ機能を提供すべきである (SHOULD)。このアクセスは権限外のアクセスを防ぐために、アクセス制御を実装すべきである (SHOULD)。
DISCUSSION
この帯域外アクセスは、ネットワークアクセスが使用不可の場合の間、NOC
が分離されたルータにアクセスするための方法を可能にするだろう。
帯域外アクセスは、ネットワーク管理のための重要な管理ツールである。ネットワークコネクションに依存しない装置のアクセスを可能にする。このアクセスを遂行する方法は数多く存在する。どれを使用するにしても、アクセスがネットワークコネクションに無依存であることは重要である。帯域外アクセスの例は、ルータへのダイアルアップを提供するモデムに接続するシリアルポートである。
OOB アクセスが帯域内アクセスと同じ機能性を提供することは重要である。帯域内アクセス、あるいは既存のネットワークコネクションを通じてアクセスする装置は、大半時間のために制限され、なぜ未到達かを解決するために管理者は装置を到達させる必要がある。帯域内アクセスは、ルータを設定するためやより微妙な問題を解析するために、依然として非常に重要である。
各々のルータは、ローカルハードウェアの保守のために、スタンドアロンデバイスとして運用すべきである (SHOULD)。オンサイトツールのみを使用して、ルータ側で診断プログラムを実行する手段が利用可能であるべきである (SHOULD)。ルータは、障害の場合に診断を実行できるべきである (SHOULD)。提案されたハードウェア/ソフトウェア診断については、セクション [10.3.3] を参照されたい。
ルータは、ネットワーク管理者がルータをリロード、停止、再起動できるためのメカニズムを、帯域内と帯域外の両方に含まなければならない (MUST)。ルータは、ソフトウェアかハードウェアの障害によりハングした場合に、ルータを自動的にリロードするメカニズムも含むべきである (SHOULD)。
ルータは、ルータのメモリ (とクラッシュ後のベンダでのデバッグのために有効な他の状態) の内容をダンプ採取するためのメカニズムと、ルータのローカルな固定記憶装置デバイスに保存するか、TFTP 等の活性回線採取メカニズムを通じて別のホストに保存する ([OPER:2], [INTRO:3] 参照) かのいずれかを実装すべきである (SHOULD IMPLEMENT)。
全てのルータは、設定が必要かもしれない設定パラメタを持っている。ルータを再起動せずにパラメタの更新を可能にすべきである (SHOULD)。最悪、再開始を要求してもよい (MAY)。ルータを再起動せずにパラメタを変更することができない (例えば、インタフェースの IP アドレスを変更する) 場合があるかもしれない。これらの場合、ルータや周辺のネットワークの中断を最小限にする注意を払うべきである。
手動か自動のいずれかでネットワーク上でルータを設定する方法があるべきである (SHOULD)。ルータはホストか別のルータから、自分のパラメタをアップロードかダウンロードできるべきである (SHOULD)。パラメタ形式と人間が編集可能な形式との間を変換する手段を、アプリケーションプログラムかルータの機能で提供すべきである (SHOULD)。ルータは、自身の設定を格納する、ある種の固定記憶装置を持つべきである (SHOULD)。ルータは RAPP や ICMP アドレスマスク応答等のプロトコルを信じるべきでなく (SHOULD NOT)、BOOTP を信じなくてもよい (MAY)。
DISCUSSION
将来的に RAPP や ICMP
アドレスマスク応答、BOOTP、その他のメカニズムは、ルータの自動設定を可能にするために必要とされるかもしれないことを、ここに注記する必要がある。将来ルータは自動的に設定できるかもしれないが、ここでの意図は、自動設定がより完全に試験されるまで、製品環境でのこの実践を推奨しないということである。その意図は、自動設定を全く推奨しないということではない。ルータが自身の設定を自動的に取得することが期待される場合、それが現れた時にルータが信じ、設定を取得した後で無視することを可能にすることは賢いだろう。
ルータは自身のシステムイメージを、PROM や NVRAM 等のローカルの不揮発性記憶装置に保持すべきである (SHOULD)。ネットワーク上でホストや別のルータからシステムソフトウェアをロードできてもよい (MAY)。
自身のシステムイメージをローカルの不揮発性記憶装置に保持できるルータは、ネットワーク上でシステムイメージを起動するよう設定可能であってもよい (MAY)。このオプションを提供するルータは、ネットワーク上でシステムイメージを起動できない場合に、不揮発性のローカル記憶装置中のシステムイメージを起動するよう設定可能にすべきである (SHOULD)。
DISCUSSION
ルータが立ち上がり、自分自身を実行できることは重要である。NVRAM
は大規模ネットワークで使用されるルータにとっての特定の解決方法かもしれない。なぜなら、PROM
の変更は、数多くの、あるては地理的に散在したルータに責任を持つネットワーク管理者が極めて時間を消費するからである。ルータがバク修正や新機能を
PROM のインストールよりも速く取得するための容易な方法があるべきなので、システムイメージをネット起動できることは重要である。さらに、もしルータが
PROM ではなく NVRAM を持っているならば、そのイメージをネット起動して、その後
NVRAM に置くだろう。
ルータは、誤ったイメージを検出して恐らく保護するために、ロードされたイメージに対して基本的な一貫性チェックを実行すべきである (SHOULD)。
ルータは実行しているソフトウェアに基づいて、異なる設定を区別できてもよい (MAY)。もし設定コマンドが、あるソフトウェアのバージョンを別のものに変更したら、そのソフトウェアと互換性のある設定を使用できれば便利である。
設定誤りを検出し、応答するメカニズムが存在しなければならない (MUST)。もし誤ったコマンドが実行されたら、ルータはエラーメッセージを提供すべきである (SHOULD)。ルータは不完全な形式のコマンドを、あたかも正常であるかのように受け入れるべきではない (SHOULD NOT)。
DISCUSSION
エラーを検出できない場合がある。それは、コマンドは正しい形式だがネットワークに関連して誤っている場合である。これはルータで検出してもよいが、検出できなくともよい。
設定誤りの別の形態は、ルータが接続されているネットワークの設定誤りである。ルータは、ネットワークの設定誤りを検出してもよい (MAY)。ルータは、これらの検出をルータかホスト上のファイルにログ採取してもよい (MAY)。それにより、ネットワーク管理者はネットワーク上に起こり得る問題があることが分かるだろう。
DISCUSSION
こうした設定誤りの例は、問題あるか誤ったアドレスマスクを持つルータと同じアドレスを持つ別のルータである。もしルータがこうした問題を検出したら、ルータがその状況を修正することは恐らく最善の考えではない。それは百害あって一利無しである。
ルータの設定変更によるネットワークへの影響は最小限にすべきである (SHOULD)。ルーティングテーブルは簡単な変更がルータに施された時、不必要に消去すべきでない (SHOULD NOT)。もし、ルータが幾つかのルーティングプロトコルを実行しているならば、一つのネットワークが一つ以上のルーティングプロトコルによって認識される場合を除いて、一つのルーティングプロトコルの停止により、他のルーティングプロトコルを中断すべきでない (SHOULD NOT)。
DISCUSSION
ネットワークの利用者が有り得る最善の接続性を得るよう、ネットワークを実行することがネットワーク管理の目標である。簡単な設定変更でルータを再起動することは、ルーティングの中断を引き起こし、最終的にネットワークとその利用者の中断を引き起こす。もしルーティングテーブルが不必要に消去されたら、ネットワーク内のサイトへの特定の経路だけでなく、例えばデフォルト経路が失われるだろう。この種類の中断は、利用者の重要な故障時間を引き起こすだろう。このセクションの目的は、可能な場合は常にこれらの中断が回避されるべきであると指摘することである。
(1) ルータは、帯域内ネットワークアクセスを提供しなければならない (MUST) が、(セクション [8.2] の要件を除いて) セキュリティを考慮した場合、このアクセスはデフォルトで不能にすべきである (SHOULD)。ベンダは、如何なる帯域内アクセスのデフォルト状態もドキュメント化しなければならない (MUST)。このアクセスは、権限外のアクセスを防ぐためにアクセス制御を実装すべきである (SHOULD)。
DISCUSSION
帯域内アクセスは基本的に、ルータの永久的な運用状態に影響を与えるかもしれないし、与えないかもしれない通常のネットワークプロトコルを通じたアクセスのことを言う。これは
Telnet/RLOGIN 制御アクセスや SNMP 操作を含むが、それらに限定されるわけではない。
これは、箱の外の操作と箱の分担外の安全性との間の論点であった。ルータへの自動的なアクセスは危険性を持ち込むかもしれないが、消費者がルータを接続したら直ぐにネットワーク上でアクセスできることは、より重要かもしれない。少なくとも一つのベンダは外部コンソール制御無しでルータを供給し、設定を完全にするためにネットワークを通じてルータにアクセスできることに依存している。
帯域内アクセスがデフォルトで可能か否かはベンダ次第であるが、危険性が伴うことを消費者に知らせることはベンダの責任でもある。
(2) ルータは ICMP エコー要求を起動する能力を提供しなければならない (MUST)。以下のオプションを実装すべきである (SHOULD)。
以下の追加オプションを実装してもよい (MAY)。
(3) ルータは、traceroute を起動する能力を提供すべきである (SHOULD)。もし traceroute を提供するならば、サードパーティ traceroute を実装すべきである (SHOULD)。
上記の三つの設備の各々は (もし実装するならば)、権限を持たない人による悪用を防ぐことを念頭において、アクセス制限を持たせるべきである (SHOULD)。
監査と請求はネットワーク運用者の悩みの種であるが、ネットワークセキュリティを担当する人や料金を支払う責任のある人に最も必要とされる二つの機能である。セキュリティの文脈では、資源の価値以上のコストをかけずにネットワークの動作維持を助け、悪用から資源を保護するのであれば、会計監査は望ましい。
(1) 設定変更
ルータは、たとえそれがオペレータによる起動と変更時間を記録する程度に簡単なものであっても、ルータの設定変更に対して監査する方法を提供すべきである
(SHOULD)。
DISCUSSION
設定変更 (誰が設定変更を施し、何が何時変更されたか)
のログ採取は非常に有効である。特に、トラフィックが町を通り過ぎる際に、突然アラスカを通る経路になった場合に有効である。そして、以前の設定に復帰させる機能も有効である。
(2) パケット計算
ベンダは、相手のホストやネットワーク間のトラフィックレベルを追跡するためのシステムを提供することを強く考慮すべきである。この情報を集めることについて、ホストやネットワークの特定の相手に制限するメカニズムもまた、強く推奨される。
DISCUSSION
上記で説明されているホストトラフィックマトリクスは、他の統計情報では明白でないトラフィックの傾向を、ネットワーク運用者に一見して分からせる。接続されたネットワークの構造を厳密に調査することは、ホストやネットワークの識別も可能にする。例えば、接続されたネットワークのネットワークアドレスの範囲内の全ての
IP アドレスにパケットを送信しようとする単一の外部ホストである。
(3) セキュリティ監査
ルータは、以下を含む障害や違反に関連するセキュリティを監査する方法を提供しなければならない
(MUST)。
ルータはそうした監査を制限し無効にする方法を提供しなければならない (MUST) が、デフォルトでは監査すべきである (SHOULD)。監査で有り得る方法は、もし存るならコンソールへの違反一覧表示、内部的なログ採取やカウント、SNMP トラップメカニズムか適切な Unix ログ採取メカニズムを通じたリモートセキュリティサーバへのログ採取を含む。ルータは、これらの通知メカニズムを少なくとも一つは実装しなければならず (MUST)、一つ以上実装してもよい (MAY)。
ベンダはルータのソフトウェア/ファームウェアのロードの生成において、優れた設定制御の実施を用いることに責任を持つ。特に、もしベンダがインターネット上での更新やロードを可能にするならば、ベンダは消費者がそのロードが正当なものであることを確認する方法、恐らくロード上でチェックサムを照合することによる、も提供すべきである。
DISCUSSION
多くのベンダは現在、ソフトウェア製品の短い更新通知をインターネットを通じて提供している。これは良い傾向であり、推奨されるべきであるが、設定制御プロセスの弱点を晒すことになる。
もしベンダが消費者がルータの設定パラメタを遠隔で変更する機能、例えば Telnet セションを通じて、を提供するならば、それを実施する機能は設定可能であるべきであり (SHOULD)、デフォルトはオフにすべきである (SHOULD)。ルータは遠隔再設定を許可する前に、正当な認証を必要とすべきである (SHOULD)。この認証手続きでは、認証機密をネットワーク上に送信すべきでない (SHOULD NOT)。例えば、もし telnet が実装されるならば、ベンダは Kerberos か S-Key、あるいはそれと同様の認証手続きを実装すべきである (SHOULD IMPLEMENT)。
DISCUSSION
適切に確認されたネットワーク運用者がルータをいじることを許可することは必要であり、そうでない人にそれを許可することは無謀である。
ルータは、ドキュメント化されていない裏口アクセスとマスタパスワードを持ってはならない (MUST NOT)。ベンダは製品が消費者に渡る前に、デバッグ目的や製品開発で追加されたそうしたアクセスを削除することを保証しなければならない (MUST)。
DISCUSSION
ベンダは、意図したコード中の弱点、例えば帯域内アクセス、を消費者が知ることを保証する責任がある。意図的かあるいは意図しないトラップドアや裏口、マスタパスワードは、比較的安全なルータをネットワーク運用上の主要な問題に変える。想定される運用上の利点は、潜在的な問題により釣り合わない。
| Prev | Next |