前へ

次へ

目次

TCP/IP Services の本リリースでは， OpenVMS ノードをMobile IPv6 コレスポンデント・ノードとして動作させることができます。これは，インターネット・ドラフト版の『Mobility Support in IPv6』 ( draft-ietf-mobileip-ipv6-15.txt) に定義されています。

Mobile IPv6 環境では，ノードは次のような役割を担うことができます。

• モバイル・ノード --- 1 つのリンクから別のリンクへ接続ポイントを変更でき，しかも，そのホーム・アドレスを介して到達可能なノード (ホストまたはルータ)。

• コレスポンデント・ノード --- モバイル・ノードが通信を行うピア・ノード。コレスポンデント・ノード (ホストまたはルータ) は，モバイルまたは固定のいずれかにすることができます。

• ホーム・エージェント --- モバイル・ノードのホーム・リンク上のルータ。モバイル・ノードはこれを使用して現在の「気付」アドレスを登録します (現在のところ，OpenVMS はホーム・エージェントとして動作することはできません)。

IPv6 は，拡張可能ヘッダ構造，アドレス自動構成，セキュリティ (IPsec)，およびトンネリングを介して移動性をサポートするように設計されています。

ノードにはホーム・アドレスがあり，それは変更されません。つまり，ノードは，常にそのホーム・アドレスによってアドレス指定可能です。モバイル・ノードがそのホーム・リンク上にある場合には，「家にいる (at home)」と見なされます。モバイル・ノードのホーム・アドレスに宛てられたパケットは，標準 IP ルーティング・メカニズムを介して引き渡されます。モバイル・ノードが外部リンクに移動した場合は，「外出している (away from home)」と見なされます。

外部リンク上では，モバイル・ノードは気付アドレスを構成し，ホーム・エージェントにバインディングの更新を送信することにより，この新しいバインディングをホーム・エージェントに登録します。この新しいアドレスはモバイル・ノードの一次気付アドレスです。ホーム・エージェントは，モバイル・ノードにバインディグの肯定応答を返すことにより，バインディングの更新に対して応答します。

コレスポンデント・ノードによりモバイル・ノードのホーム・アドレスに送信されたパケットは，ホーム・リンクに到着します。ホーム・エージェントはパケットを途中でインターセプトして，それらをカプセル化し，モバイル・ノードの登録されている気付アドレスへトンネルします。

モバイル・ノードは，ホーム・エージェントからトンネルされたパケットを受信し，トンネルされたパケットのヘッダにある一次気付アドレスを認識します。モバイル・ノードは，元の送信を行ったコレスポンデント・ノードがそのモバイル・ノードのバインディング・キャッシュ・エントリを持っていないものと見なします。そうでなければ，コレスポンデント・ノードは，ルーティング・ヘッダを使用して，パケットを直接モバイル・ノードに送信するはずです。モバイル・ノードはコレスポンデント・ノードにバインディングの更新を返します。

すると，コレスポンデント・ノードはモバイル・ノードの気付アドレスをキャッシュします。これにより，コレスポンデント・ノードからモバイル・ノードへの以降のパケットの最適なルーティングが可能になります。このルーティングでは，モバイル・ノードのホーム・エージェントとホーム・リンクでの輻湊が除去されます。また，これらのノードとリンクは，モバイル・ノードへのほとんどのパケットの引き渡しに関わらないため，ホーム・エージェント，ホーム・リンク，またはホーム・リンクに繋がる介在ネットワークに何らかの障害が発生した場合の影響が減少します。

コレスポンデント・ノードとして動作し，モバイル・ノードと通信を行うには，次の TCP/IP 管理コマンドを入力します。

$ TCPIP TCPIP> sysconfig -r ipv6 mobileipv6_enabled=1

Mobile IPv6 バインディング・キャッシュの内容を表示するには， netstatコマンドに -bオプションを指定して使用します。

1.2 NTP Version 4

TCP/IP Services の本リリースでは， NTP V3 アルゴリズムに新機能と改善点を組み込むことにより， NTP Version 4 (NTP V4) をサポートしています。 NTP Version 1 の対称モードを除き，NTP Version 4 は旧バージョンとの下位互換性があります。

この節では，NTP V4 と NTP V3 の相違点についてまとめます。 NTP の管理についての情報は，『 Compaq TCP/IP Services for OpenVMS Release Notes Supplement 』の Appendix B を参照してください。

• NTP Version 4 に対する主なコードのクリーンアップは完了しました。

• 現在ではほとんどの計算は，64 ビット固定小数点形式ではなく， 64 ビット倍精度浮動小数点形式を使用して行われます。固定小数点形式は，まだ生のタイム・スタンプで使用されています。生のタイム・スタンプを処理するアルゴリズムでは，倍精度浮動小数点形式に変換する前に，固定小数点の相違を生成します。

• クロック調整アルゴリズムは，正確さが向上して，ネットワーク・ジッタの影響が減り，ポーリングの間隔を 1 日を超えて設定できるように設計し直されています。 NTP V4 の設計では，ピアと直接同期をとる場合でも，サーバはポーリングの間隔を長くすることができます。 NTP V3 では，そのような場合のポーリング間隔は，最小値 (通常は 64 秒) に固定されていました。何百ものクライアントを持つサーバでは，新しい設計によりネットワーク負荷が劇的に削減されます。

• NTP V4 には，2 つの新しい結合モードが含まれており，ほとんどのアプリケーションでは，ホストごとのコンフィギュレーションが不要になります。

  • マルチキャスト・モードでは，サーバは，指定されたマルチキャスト・グループ・アドレスを使用し，一定の間隔でメッセージを送信します。一方，クライアントはこれらのアドレスで待機します。メッセージを受信すると，クライアントとサーバ間のマルチキャスト伝播遅延を測定するため，クライアントはサーバといくつかのメッセージを交換します。

  • メニーキャスト・モードでは，クライアントは指定されたマルチキャスト・グループ・アドレスへメッセージを送信し，1 つまたは複数のサーバが応答するのを期待します。巧みに設計されたアルゴリズムを使用して，クライアントは受信したメッセージから適切なサーバのサブセットを選択し，通常のクライアント/サーバ動作を続行します。メニーキャスト・モードでは，追加のネットワーク負荷を生じることなく，マルチキャスト・モードよりもすぐれた正確性が提供されます。

  
  どちらのモードでも，予めサーバまたはクライアントを識別しておかなくても，サーバおよびクライアントの自動発見およびコンフィギュレーションが提供されます。

• 次のバースト・モード機能が利用可能です。

  • 結合が最初にモバイル化されるときに，クロックを素早く設定することが重要である場合は，サーバ・コンフィギュレーション・コマンドで iburstキーワードを使用します。

  • ネットワークの接続で最初の呼び出しまたはトレーニング・プロシージャが必要な場合は，サーバ・コンフィギュレーション・コマンドで burstキーワードを使用します。

• ごくわずかな場合を除きすべての場合において，すべてのタイミングの間隔がランダム化されるので，特に，多数のコンフィギュレーション済み結合で，自己同期化とメッセージの集合化の傾向が最小限にされます。

• enableコマンドおよび disableコマンドの引数が変更されました。また， authenticateコマンドが削除されています。

• 特殊な制御メッセージは，古いコンフィギュレーション・ファイルによる偽のネットワーク・トラフィックのレベルを低減させるのに役立ちます。これが有効にされていて，パケットがサービスを拒否されているか，またはクライアントの制限を超えている場合，準拠しているサーバはクライアントに制御メッセージを送信します。また，準拠しているクライアントは，以降の伝送を止めて，NTP ログ・ファイルにメッセージを送信します。

• フィルタ・アルゴリズムは，非対称遅延の間のエラーを削減します (電話モデムを使用した PPP 接続および，かなりの量のトラフィックのダウンロードまたはアップロードの特性)。

• NTP V4 の ntpdcユーティリティは，以前のバージョンの NTP では動作しません。また，以前のバージョンの ntpdcユーティリティは，NTP V4 では動作しません。

1.3 BIND Version 9

DNS (Domain Name System) は，インターネット・ホストに関する情報の保守と配布を行います。DNS は，インターネット上にあるエンティティの名前，名前に関する委託権限についての規則，およびメールのルーティング情報を含む階層構造のデータベース，および，名前をインターネット・アドレスにマップするシステムの実装から構成されます。

OpenVMS 環境では，DNS は Berkeley Internet Name Domain (BIND) ソフトウェアによって実装されます。 Compaq TCP/IP Services for OpenVMS では，Internet Software Consortium (ISC) の BIND Version 9 (BIND 9) に基づいて BIND サーバを実装します。

BIND の管理についての情報は，『 Compaq TCP/IP Services for OpenVMS Release Notes Supplement 』の Appendix C を参照してください。

1.3.1 BIND 9 の機能

BIND 9 は，基礎となる BIND アーキテクチャをほとんどすべての面において大幅に書き換えています。 BIND 9 の重要な機能のいくつかは，次のとおりです。

• DNS セキュリティ

  • DNSSEC (サイン付きゾーン)

  • TSIG (サイン付き DNS 要求)

  • アクセス制御リスト

  • 動的更新のセキュリティ・ポリシ

  • TKEY 共用シークレット

  • SIG(0) トランザクション・シグネチャ

• IPv6

  • IPv6 ソケット上の DNS クエリへの応答

  • IPv6 リソース・レコード (A6，DNAME など)

  • ビット列ラベル

• DNS プロトコルの拡張

  • IXFR，DDNS，Notify，EDNS0

  • 標準準拠の向上

• ビュー
  1 つのサーバ・プロセスは，DNS ネーム・スペースの複数のビューを提供することができます (たとえば，特定のクライアントに対しては内部ビュー，その他のクライアントに対しては外部ビュー)。

• マルチプロセッサのサポート

• マルチスレッド

BIND 9 で提供されているマルチプロセッサおよびマルチスレッドのサポートを利用するには，マルチプロセッサ・システム上の OpenVMS SYSGEN パラメータ MULTITHREAD をゼロ以外の値にする必要があります。このパラメータはシステム単位であり，他の TCP/IP または POSIX スレッドを使用する OpenVMS のコンポーネントに影響を及ぼすことに注意してください。

1.3.2 BIND 8 から BIND 9 への移行

BIND 9 は，BIND 8 と互換性を持つように設計されています。次は，BIND 9 と BIND 8 の相違点をまとめたものです。

• コンフィギュレーション・ファイルの互換性

  • BIND 9 では，BIND 8 の TCPIP$BIND.CONF オプションのほとんどをサポートしていますが，すべてではありません。
    TCPIP$BIND.CONF ファイルで未実装のオプションが使用されている場合， BIND 9 サーバは警告メッセージをログに出力します。省略時の設定が変更されているオプションに関するメッセージも，そのオプションが TCPIP$BIND.CONF で明示的に設定されていなければ，ログに出力されます。

  • transfer-formatオプションの省略時の設定が one-answerから many-answersへ変更されています。 many-answersゾーン転送フォーマットを理解しない古いバージョンの TCP/IP Services を実行しているスレーブ・サーバがある場合は， options文または server文のいずれかで次のように指定する必要があります。

    transfer-format one-answer;

  • BIND 9 では，TCPIP$BIND.CONF でエラーを検出した場合，BIND サーバは起動しません。 BIND の以前のバージョンでは，エラーにかかわらず起動して，サーバは部分的なコンフィギュレーションで実行されます。以降の再ロード中にエラーが検出されても，サーバは終了しません。
    マスタ・ファイルのエラーでサーバが終了することはありませんが，ゾーンがロードされないようにします。

  • BIND 9 のロギング・カテゴリのセットは，BIND 8 のものとは異なります。ロギングをカテゴリ・ベースでカスタマイズしている場合には，新しいカテゴリを使用するように logging文を変更する必要があります。
    logging文が有効になるのは， TCPIP$BIND.CONF ファイル全体が読み込まれた後だけです。このため，サーバが初めて起動するときには， logging文の内容に関わらず，コンフィギュレーション・ファイルのエラーに関するすべてのメッセージは必ず TCPIP$BIND_RUN.LOG ファイルに登録されます。 BIND 8 では， logging文が読み込まれると，新しいロギングのコンフィギュレーションは直ちに有効になりました。

  • Notify メッセージおよび Refresh クエリのソース・アドレスとポートは，現在では，BIND 8 の query-sourceオプションではなく，それぞれ notify-sourceおよび transfer-sourceオプションで制御されています。

  • 複数のクラスは，各クラスの明示ビューに入れる必要があります。

• ゾーン・ファイルの互換性

  • BIND 9 は，ゾーン・ファイルでの time-to-live (TTL) 値の省略に関する RFC 1035 および RFC 2308 の規則に厳密に準拠しています。省略された TTL 値は，$TTL 指示文で指定された値で置き換えられるか，または， $TTL 指示文がない場合は，以前に指定された TTL 値で置き換えられます。
    $TTL 指示文がなく，ファイル内の最初のリソース・レコード (RR) に明示的な TTL フィールドがない場合，最初の RR の TTL 値が定義されていないため，ゾーン・ファイルは違法になります。 BIND 4 および BIND 8 の多くのバージョンでは，そのようなファイルを警告なしで受け付けて，未定義の TTL 値に対する省略時の値として SOA MINTTL フィールドの値を使用します。
    BIND 9 は非標準の BIND 4/8 の SOA MINTTL の動作をエミュレートしてファイルをロードしますが (SOA がファイル内の最初のレコードの場合)，次の警告メッセージも表示します。

    No TTL specified; using SOA MINTTL instead

    
    この問題を回避するには，各ゾーン・ファイルで $TTL 指示文を使用します。

  • BIND のいくつかのバージョンでは，ピリオドを含む SOA のシリアル番号 (たとえば 3.002) が許可されており，その番号を整数に変換します。この機能は BIND 9 ではサポートされておらず，シリアル番号は整数でなければなりません。

  • 引用符の指定が不一致の TXT レコード (たとえば 'host TXT "foo') は， BIND のいくつかのバージョンではエラーになりません。 BIND 9 では，ゾーン・ファイルにこのようなレコードが含まれていた場合，次のような分かり難いメッセージが生成されることがあります。

    Unexpected end of file

    
    これは，BIND 9 では，次の引用符までのすべてをリテラル文字列として解釈するためです。

  • BIND のいくつかのバージョンでは，カッコを使用して正しく引用されていない改行を含む RR を受け入れます。たとえば，次のような SOA です。

    @ IN SOA ns.example. hostmaster.example. ( 1 3600 1800 1814400 3600 )

    
    これは正当なマスタ・ファイルの構文ではなく，BIND 9 はこれをエラーとして扱います。この問題を修正するには，左カッコを最初の行に移動します。

  • ドメイン名にリテラルのドル記号 ($) を指定するための $$構文はお勧めしません。代わりに \$構文を使用してください。

• 新しいプロトコルの機能

  • IPv6 を経由して DNS クエリを受け取りたい場合は， TCPIP$BIND.CONF ファイルに次のように指定する必要があります。

    listen-on-v6 {any; };

    
    これは省略時の設定ではありません。

  • EDNS0
    BIND 9 は，EDNS0 を使用して受信バッファ・サイズを通知します。また，DNSSEC 応答を受信したいことを示すため，クエリに EDNS フラグをセットします。
    BIND の以前のバージョンを含め，EDNS0 をサポートしないほとんどの古いサーバでは，これらのクエリに応答してエラーを送信します。これが起こった場合，BIND 9 は自動的に EDNS0 を使用しないでクエリの再試行を行います。
    非 BIND のネーム・サーバの実装のなかには，エラー応答を送信する代わりに，これらのクエリを，メッセージを表示することなく無視するものもあります。このタイプのサーバが使用されているゾーンでは，名前解決が非常に遅かったり，失敗することもあります。
    BIND 9 が，EDNS0 をサポートするサーバ (別の BIND 9 サーバなど) と通信する場合には，4096 バイトまでの応答は，単一の UDP データグラムとして送信されることがありますが，IP レベルで断片化されます。ファイアウォールで IP の断片が間違ってドロップすると，名前解決が著しく遅くなったり，あるいは失敗することがあります。

  • 現在，送信ゾーン転送では，省略時の設定により many-answersフォーマットを使用します。このフォーマットは，BIND 4 の古いバージョンでは理解されません。この問題を修正するには，次のオプションを使用します。

    transfer-format one-answer;

    
    セキュリティの問題を防止するため，スレーブ・サーバをアップグレードしてください。

  • Windows 2000 DNS サーバへのゾーン転送では，16K より大きな DNS メッセージを正しく処理できない場合があります。この問題を修正するには，次のオプションを使用します。

    transfer-format one-answer;

• BIND 9 では，ドメイン名の文字セットを制限していません。完全に 8 ビット互換です。
  DNS 内で発行されたホスト名は，RFC 952 で示されている規則に従うべきですが， BIND 9 では，規則に従うことを強制していません。
  予期しない文字を含んでいる名前があると，ネットワークからのデータを十分にチェックしないアプリケーションを実行するシステム上で，セキュリティの問題が生じます。 BIND の以前のバージョンでは，ホスト名やメール・アドレスに不適切と思われる文字を含んでいるデータを廃棄することにより，これらのアプリケーションを攻撃から保護しようとします。この機能は，TCPIP$BIND.CONF の check-namesオプションによって制御されていました。 BIND 9 では，このような保護を提供していません。このようなタイプの欠陥のあるアプリケーションはアップグレードすべきです。

• サーバ管理ツール:

  • ndcユーティリティは，リモート操作が可能な rndcユーティリティで置き換えられています。 ndcと異なり， rndcはコンフィギュレーション・ファイルを必要とします。 TCPIP$CONFIG.COM コマンド・プロシージャを使用してBIND サーバを有効にする場合，テンプレート・ファイルは，TCPIP$ETC 論理名によってポイントされるディレクトリに書き込まれます。コンフィギュレーション・ファイルを生成する最も簡単な方法は，次のコマンドを使用することがです。

    $ rndc_confgen

    ---

    前へ

    次へ

    目次