DOCSIS 設定のための BAC 機能
この項では、DOCSIS テクノロジーと関連する BAC の付加価値機能について説明します。
動的設定 TLV
DPE は、動的 DOCSIS 設定の TFTP 要求を受け取るたびに、次の TLV を追加します。
• TLV 19:TFTP サーバのタイムスタンプ(オプション):Configure DOCSIS Defaults ページに TFTP Time Stamp Option として表示されます。詳細については、 表13-3 を参照してください。この TLV では、CMTS および DPE における NTP の同期が必要です。
• TLV 20 および TLV 59:IPv4 と IPv6 用の TFTP サーバのプロビジョニングされたモデム アドレス(オプション):Configure DOCSIS Defaults ページに TFTP Modem Address Option として表示されます。詳細については、 表13-3 を参照してください。
(注) DPE の TFTP IP 検証機能は、Cisco CMTS DSS 機能とは互換性がありません。「DPE TFTP IP 検証」を参照してください。Cisco CMTS に DSS が設定されている場合、TFTP サーバのプロビジョニングされたモデム アドレスをディセーブルにする必要があります。
• TLV 6:CM MIC の設定(必須)
• TLV 7:CMTS MIC の設定(必須):Configure DOCSIS Defaults ページに CMTS Shared Secret として表示されます。詳細については、 表13-3 を参照してください。
• TLV 43.6.x:拡張 CMTS MIC の設定(必須):Configure DOCSIS Defaults ページに CMTS Shared Secret として表示されます。詳細については、 表13-3 を参照してください。
(注) CMTS MIC を設定するときは、次の CMTS IOS リリースの依存関係に注意してください。
• TLV 39 または TLV 40 を含める場合、DOCSIS 2.0 CMTS MIC には CMTS IOS 12.3BC が必要です。
• 次の CMTS IOS コマンドが BAC によって設定されているものとします。
– ip dhcp relay information option
– no ip dhcp relay information check
– cable helper-address x.x.x.x
ここで、 x.x.x.x は Network Registrar DHCP サーバの IP アドレスです。
IPv6 環境では、 cable helper-address の代わりに次のコマンドを使用する必要があります。
ipv6 dhcp relay destination ipv6-address [ interface-type interface-number ]
– cable dhcp-giaddr primary
DPE TFTP IP 検証
DPE TFTP サーバは、動的設定ファイルを対象に、TFTP クライアントの IP アドレスが DOCSIS ケーブル モデムの予期した IP アドレスと一致することを確認します。一致しない場合、要求は破棄されます。この機能に Cisco CMTS DMIC 機能との互換性はありません。
TFTP の動的構成要求における要求者の IP アドレスの検証をディセーブルにするには、 no service tftp 1..1 ipv4 | ipv6 verify-ip コマンドを使用します。詳細については、『 Cisco Broadband Access Center DPE CLI Reference 4.0 』を参照してください。
DOCSIS 1.0、1.1、2.0、および 3.0 のサポート
BAC 4.0 は、DOCSIS 1.0、1.1、2.0、および 3.0 をサポートします。TLV の詳細については、「テンプレート文法」を参照してください。この BAC リリースがサポートする各 DOCSIS バージョンのオプションのリストについては、「DOCSIS オプションのサポート」を参照してください。
DOCSIS バージョンの動的選択
BAC は、ケーブル モデムの DOCSIS バージョンを着信 DHCP 要求から検出できます。また、次の 2 つの方法のいずれかで CMTS の DOCSIS バージョンを検出することもできます。
• DHCPv4 の Option 82 と DHCPv6 の Option 17 を使用して、CMTS をその DOCSIS バージョンを送信するリレー エージェントとして使用する方法。
• GIADDR から CMTS DOCSIS バージョンへのマッピングを行う顧客提供のソースを使用する方法。
この DOCSIS バージョンを使用して、BAC は、デバイスの最適な DOCSIS 設定ファイルを判断します(そのように設定されている場合)。このバージョンが、デバイスと CMTS 間で最も一般的な DOCSIS バージョンです。たとえば、デバイスが DOCSIS 2.0 をサポートし、CMTS が DOCSIS 1.1 をサポートする場合、DOCSIS 1.1 ファイルが使用されます。
モデムの DOCSIS バージョンの判別
BAC は、ケーブル モデムの DOCSIS バージョンを着信 DHCP 要求から検出できます。この要求のモデムの機能を示す Vendor Class Identifier フィールド(Option 60)に文字列が含まれています。たとえば、「docsis1.1: xxxxxx 」では、 xxxxxx はモデムの機能を表す ASCII 文字列です。サービス レベル選択拡張は、「docsis」と「 :xxxxxxx 」16 進文字列間の文字をモデムの DOCSIS バージョンとして使用します。
CMTS の DOCSIS バージョンの判別
この BAC リリースでは、CMTS をイネーブルにしてリレー エージェントとして動作させ、CMTS の DOCSIS バージョンを提供できます。この機能は次のオプションを使用してイネーブルにします。
• DHCPv4 Relay Agent Option 82。このオプションを使用すると、CMTS は CMTS の特定機能を送信(またはアドバタイズ)できます。このオプションは、DOCSIS DHCP ベンダー指定のオプションで、CMTS の DOCSIS バージョンを伝達します。
• DHCPv6 Vendor-specific Information Option 17。このオプションを使用すると、ベンダー固有の情報を指定できます。このオプションは、Relay-forward メッセージと Relay-reply メッセージで伝達され、DHCPv6 リレー エージェントと DHCPv6 サーバ間で情報を送信します。
以前のバージョンと同様、この BAC バージョンは、DHCP GIADDR フィールドを介して CMTS の DOCSIS バージョンを判別します。このフィールドは、CMTS インターフェイスの IP アドレスを指定します。この方法の場合、DOCSIS モデムのサービス レベル選択拡張は、
/docsis/cmts/version/giaddrToVersionMap プロパティを検索します。このプロパティの値は、GIADDR から DOCSIS バージョンへのマッピングを含んでいる外部ファイルの名前です。
このマッピング ファイルには giaddr-docsis-map.txt と名前を付けて、RDU に追加する必要があります。次の方法で、 giaddr-docsis-map.txt ファイルを RDU に追加できます。
• Configuration.addFile() コールを介した API。
• 管理者のユーザ インターフェイス( Configuration > Files を選択してアクセス)。「ファイルの追加」を参照してください。
giaddr-docsis-map.txt ファイルには、次の形式で必要な情報を含める必要があります。
IPv4_dotted_decimal_address_string,DOCSIS_version_string
• IPv4_dotted_decimal_address_string :CMTS インターフェイスの IP アドレスを指定します。
• docsis_version_string :ケーブル モデムがサポートする DOCSIS バージョンを示します。
サービス レベル拡張は、DHCP パケットに含まれる GIADDR アドレスを使用して、CMTS の DOCSIS バージョンを検索します。マッピング ファイルに GIADDR がない場合、拡張は
/docsis/cmts/version/default プロパティの値をケーブル モデムの DOCSIS バージョンの値に使用します。このプロパティのデフォルト値は 1.0 です。
giaddr-docsis-map.txt ファイルを動的に更新するには、 replaceExternalFile API または管理者のユーザ インターフェイスを使用してファイルを編集して RDU 内で置き換えます。
(注) DOCSIS バージョンの選択のプロパティがサービス クラスで指定されていない場合、元のファイルが使用され、ネットワーク全体で体系的なアップグレードが可能になります。
DOCSIS バージョンに基づいたサービス レベルの選択
モデムの DOCSIS バージョンと CMTS を判別後、サービス レベル選択拡張はサポートされる最小限の DOCSIS バージョンを決定して、サービス レベルに /docsis/version プロパティを設定します。このプロパティの値は、DOCSIS バージョン文字列(1.1 など)に設定されます。
(注) DOCSIS バージョンは、設定ファイル ユーティリティを使用して指定できます。詳細については、「設定ファイル ユーティリティの使用方法」を参照してください。このファイル ユーティリティが実行する機能は、RDU DOCSIS Version Selector 機能が CMTS でサポートされる最新の DOCSIS バージョンを判別する RDU の検証とは異なります。
DOCSIS バージョンに基づいた DOCSIS 設定ファイル
BAC は、DOCSIS バージョンを使用して、モデムに送信する DOCSIS 設定ファイルの名前を判別します。
次のサービス クラス プロパティが、BAC の管理者のユーザ インターフェイスと API でサポートされます。
/cos/docsis/file/3.0/IPv4
/cos/docsis/file/3.0/IPv6
DOCSIS 設定ファイル名を特定の DOCSIS バージョンと関連付けるために、これらのプロパティをオプションで DOCSIS サービス クラスに追加できます。これらの各プロパティを設定すると、既存の DOCSIS 設定ファイル名プロパティで行われるように、RDU がサービス クラスとプロパティ値で指定されたファイルとの間にデータベース関係を確立します。
DOCSIS バージョン プロパティが存在する場合、BAC はそのプロパティ値から得られる DOCSIS バージョン文字列を、DOCSIS 設定ファイル名を提供するプロパティの名前に追加してプロパティ名を作成します。
/cos/docsis/file/docsis_version_string
サービス レベル拡張は、モデムのプロパティ階層内でこのプロパティ名を検索します。DOCSIS バージョン プロパティが見つかった場合は、プロパティ値を DOCSIS 設定ファイル名として使用します。DOCSIS バージョン プロパティが見つからない場合、BAC は、DOCSIS バージョン サフィックスのない DOCSIS 設定ファイル名を使用して、デバイス構成で指定するファイル名を提供します。
IPv6 のサポート
この BAC リリースでは、CableLabs DOCSIS 標準の最新リビジョン、DOCSIS 3.0 をサポートしています。DOCSIS 3.0 標準には、以前の DOCSIS 標準に基づき構築された主要な新機能が導入されています。次の機能があります。
• IPv6 デバイスのプロビジョニング。次のものがあります。
–DOCSIS 準拠のケーブル モデムと CMTS
–コンピュータ
–進化する OpenCable Application Platform に基づく RNG-200 STB
–混在 IP モードの PacketCable Multimedia Terminal Adapter(MTA; マルチメディア ターミナル アダプタ)などの、各種 eSAFE(embedded Service/Application Functional Entities)デバイスのバリアント
BAC は、TFTP サービスと ToD サービスに対する IPv6 サポートなど、IPv6 デバイスをプロビジョニングするために必要なサービスを提供します。BAC は IPv6 デバイスの設定ファイルも処理します。
• 拡張されたアドレス指定機能
IPv6 の主な利点は、その拡張されたアドレス指定機能です。IPv6 アドレスでは、アドレス空間が 32 ビットから 128 ビットに拡大されており、事実上、無制限のネットワークとシステムを提供できます。
• ケーブル モデムの IPv6 プロビジョニングと管理。このプロビジョニング フローには、次のものが含まれます。
–サポートされる IP モード:BAC は、IPv4、IPv6、またはデュアル スタック モード(IPv4 および IPv6 プロビジョニング モードで構成)で DOCSIS ケーブル モデムをプロビジョニングします。さまざまなモードの詳細については、「シングル スタックとデュアル スタック」を参照してください。
(注) ケーブル モデムは、IP のプロビジョニング モードに関係なく、IPv4 と IPv6 のトラフィックを転送できます。
–DHCPv6:DOCSIS プロビジョニング フローは、IPv6 の DHCP(DHCPv6 としても知られる)の使用を指定します。DOCSIS の DHCPv6 プロビジョニング フローの詳細については、「DOCSIS DHCPv6 ワークフロー」を参照してください。
BAC における IPv6 デバイスのプロビジョニングをイネーブルにする前に、システムで IPv6 をイネーブルにする必要があります。コンピュータで IPv6 のサポートをイネーブルにするには、 root としてログインして、次のコマンドを入力します。
# ifconfig intf inet6 plumb up
intf は、IPv6 をイネーブルにするインターフェイスを示します。
(注) 物理イーサネット インターフェイスに加えて、ループバック インターフェイスでも plumb を実行してください。次に例を示します。
# ifconfig bge0 inet6 plumb up
# ifconfig lo0 inet6 plumb up
その後、次のコマンドも実行します。
# touch /etc/hostname6.intf
intf は、IPv6 をイネーブルにするインターフェイスを示します。
次の各項では、BAC の IPv6 に関連する概念について説明します。
• 「IPv6 のアドレス指定」
• 「シングル スタックとデュアル スタック」
• 「IPv6 の DHCP オプション」
• 「属性とオプション」
IPv6 のアドレス指定
IPv6 アドレスの長さは 128 ビットで、コロン(:)で区切られた一連の 16 ビットの 16 進数フィールドとして表現されます。16 進数の A、B、C、D、E、および F には、大文字と小文字の区別はありません。次に例を示します。
2031:0000:130f:0000:0000:09c0:876a:130b
このアドレス指定は、次のように短縮できます。
• フィールドの先頭の 0 はオプションであり、09c0 は 9c0、0000 は 0 と記述できます。
• 0 のフィールドが連続する場合は(フィールドの数にかかわらず)、:: と表現できますが、アドレス内で 1 回しか使用できません。これは、複数回使用すると、アドレス パーサーが 0 の各ブロックのサイズを特定できないという理由からです。したがって、前述のアドレスは次のように記述できます。
2031:0:130f::09c0:876a:130b
二重コロンの短縮形を使用すると、多くのアドレスを短縮できます。たとえば、ff01:0:0:0:0:0:1 は ff01::1 になります。
リンクローカル アドレスには、リンクに限定されたスコープがあり、プレフィックス fe80::/10 を使用します。ループバック アドレスのアドレスは、::1 です。マルチキャスト アドレスは、プレフィックス ff00::/8 で識別されます(IPv6 にはブロードキャスト アドレスはありません)。
IPv6 での IPv4 互換アドレスは、:: のプレフィックスを付けた 10 進数の 4 つの IPv4 アドレスです。たとえば、::c0a8:1e01 として解釈される IPv4 アドレスは、::192.168.30.1 と記述できます。
シングル スタックとデュアル スタック
RFC 4213 は、ホストとルータ内の IPv4 と IPv6 の両方のインターネット プロトコルを全面的にサポートするための技術としてデュアル スタックを定義します。IPv4 と IPv6 の両方をサポートするネットワーク スタックは、デュアル スタックと呼ばれ、デュアル スタックを実装するホストは、デュアル スタック ホストと呼ばれます。
BAC は、次の IP モードでケーブル モデムをプロビジョニングします。
• IPv4 のみ:このモードでは、ケーブル モデムは DHCPv4 サーバに、IPv4 アドレスと関連の操作パラメータを要求します。
• IPv6 のみ:このモードでは、ケーブル モデムは DHCPv6 サーバに、IPv6 アドレスと関連の操作パラメータを要求します。モデムは IPv6 アドレスを使用して、現在の Time-of-Day と設定ファイルを取得します。
• デュアル スタック:このモードでは、ケーブル モデムは IPv6 と IPv4 の両アドレス、およびパラメータを、DHCPv6 と DHCPv4 経由でほぼ同時に取得し、IPv6 アドレスの使用優先順位を上げて、Time-of-Day と設定ファイルを取得します。
(注) BAC は、ケーブル モデムがプロビジョニングされている直近の IP モードで検出されたデータのみ保存します。そのため、デバイスを DHCPv4 でブートし、その後 DHCPv6 でブートすると、DHCPv6 のデータのみ検出されて保存されます。
IPv4 および IPv6 モードでプロビジョニングしている間、ケーブル モデムは、所定の時間に IP アドレス タイプ(v4 または v6)の 1 つでのみ動作します。このような理由で、プロビジョニングの IPv4 および IPv6 モードは、シングル スタック モードと呼ばれます。
デュアル スタック モードでは、IPv4 と IPv6 のアドレスを同時に使用してケーブル モデムを管理できます。このモードでは、モデムは動作可能になった後に 2 番目の IP アドレスを取得します。この機能を使用して、DOCSIS ネットワークでの IPv4 から IPv6 への能率的な移行を行えます。
IPv6 の DHCP オプション
DOCSIS 3.0 標準は、DHCPv4 と DHCPv6 の複数の新規オプションを定義します。DHCPv6 オプションは、DHCPv4 オプションは使用しません。DHCPv6 のオプションは固有の別オプションです。BAC がサポートする DHCPv6 オプションのリストについては、『 User Guide for Cisco Network Registrar 7.0 』を参照してください。
属性とオプション
この項では、BAC 4.0 が Network Registrar と通信するときに使用する属性とオプションについて説明します。
BAC は、Network Registrar にインストールされている DHCP 拡張を使用して、そのデータベース内の設定に基づき DHCP メッセージを操作します。これらの拡張を使用して、BAC は DHCP 要求から情報を取得し、DHCP 応答に値を設定します。このようにして、BAC はプロビジョニングするデバイスにカスタマイズされた設定を提供します。
このインタラクションを容易にするために、Network Registrar は、辞書のセットを BAC 拡張に公開します。BAC 拡張は、これらの辞書を使用して Network Registrar と対話します。
辞書には、要求辞書と応答辞書が使用する属性辞書、環境辞書、および通知辞書の 3 種類があります。
• 環境辞書:DHCP サーバが拡張と通信するために使用する辞書に含まれる属性を表します。
• 要求辞書:要求パケットの DHCP オプションと属性を表します。
• 応答辞書:応答パケットの DHCP オプションと属性を表します。
• 通知辞書:BAC 拡張と RDU 間で伝達される情報を表します。
辞書は、BAC と Network Registrar で設定されているさまざまな DHCP オプションと設定を表します。オプションは、DHCP メッセージのオプション フィールドに保存されている DHCP 設定パラメータと他の制御情報です。DHCP クライアントは、要求されているオプションを判別して、DHCP パケットで送信します。
属性は名前と値のペアで、次のようなものがあります。
• DHCPv4 オプション。たとえば、 relay-agent-info 。
• DHCPv4 オプションから取得する情報のサブセット。たとえば、 relay-agent-remote-id は、DHCPv4 Option 82 のサブオプション 2 を表します。
• DHCPv4 オプションのフィールド。たとえば、「file」は DHCPv4 のヘッダーフィールドです。
属性には次のような設定も含めることもできます。
• Network Registrar の動作を制御する設定。たとえば、「drop」はパケットが破棄されることを示します。
• 情報を提供する設定。
BAC 4.0 と Network Registrar 7.0 では、次の 2 つの API バージョンをサポートします。BAC 拡張はそれらの API を使用して、DHCPv4 または DHCPv6 をイネーブルにします。
• DEX API バージョン 1:この API を使用すると、Network Registrar 拡張は、属性を介して DHCPv4 パケットの詳細をクエリーできます。
• DEX API バージョン 2:この API を使用すると、Network Registrar 拡張は、DHCPv4 オプションと DHCPv6 オプション、およびサブオプションに直接クエリーできます。
BAC 拡張は、Network Registrar 拡張の API バージョンが DEX API バージョン 2 であることを検出すると、DHCPv6 のサポートをイネーブルにします。
DHCPv6 用に検出されたデータを制御するプロパティ
BAC 拡張が DHCPv6 用に検出するデータを制御するプロパティには 3 種類のセットがあります。
(注) 管理者のユーザ インターフェイスを使用すると、Configuration > Defaults > NR Defaults ページでこれらのプロパティの設定を確認できます。
• バージョン 4.0 以前の Network Registrar 拡張の動作を制御するプロパティ。 表6-3 を参照してください。
• BAC 4.0 での DHCPv4 の Network Registrar 拡張の動作を制御するプロパティ。 表6-4 を参照してください。
• クライアント(ケーブル モデム)とリレー エージェント(CMTS)に対する、BAC 4.0 での DHCPv6 の Network Registrar 拡張の動作を制御するプロパティ。この違いは、DHCPv4 標準はクライアント メッセージとリレー メッセージを組み合せて 1 つのメッセージにし、それに対して、DHCPv6 標準はそれらのメッセージを分割するという点にあります。 表6-5 を参照してください。
表6-3 は、BAC のバージョン 4.0 以前での Network Registrar 拡張の動作に影響を与えるプロパティについて説明しています。
表6-3 BAC 4.0 以前の Network Registrar 拡張のプロパティ
|
|
/cnrExtension/attributesRequiredInRequest |
RDU に構成生成の要求を送信するために、Network Registrar 要求辞書が拡張に含める必要がある属性のリストを示します。 |
CNR_ATTRIBUTES_REQUIRED_IN_REQUEST_DICTIONARY
|
/cnrExtension/attributesToPullFromRequestAsBytes |
Network Request 要求辞書からバイナリ形式でプルする必要がある属性のリストを示します。 |
CNR_ATTRIBUTES_TO_READ_FROM_REQUEST_DICTIONARY_
AS_BYTES
|
/cnrExtension/attributesToPullFromRequestAsStrings |
Network Registrar 要求辞書から文字列形式でプルする必要がある属性のリストを示します。 |
CNR_ATTRIBUTES_TO_READ_FROM_REQUEST_DICTIONARY_
AS_STRINGS
|
/cnrExtension/attributesToReadFrom EnvironmentDictionary |
Network Registrar 環境辞書からプルする必要がある属性のリストを示します。 |
CNR_ATTRIBUTES_TO_READ_FROM_ENVIRONMENT_
DICTIONARY
|
表6-4 では、BAC 4.0 での DHCPv4 の Network Registrar 拡張の動作を制御するプロパティについて説明しています。
表6-4 BAC 4.0 の DHCPv4 Network Registrar 拡張のプロパティ
|
|
/cnrExtension/attributesRequiredInV4 Request |
RDU に構成生成の要求を送信するために、Network Registrar 要求辞書が拡張に含める必要がある属性のリストを示します。 |
CNR_ATTRIBUTES_REQUIRED_IN_V4_REQUEST_DICTIONARY
|
/cnrExtension/attributesToPullFromV4 RequestAsBytes |
Network Registrar 要求辞書からバイナリ形式でプルする属性のリストを示します。 |
CNR_ATTRIBUTES_TO_READ_FROM_V4_REQUEST_DICTIONARY_
AS_BYTES
|
/cnrExtension/attributesToPullFromV4 RequestAsStrings |
Network Registrar 要求辞書から文字列形式でプルする属性のリストを示します。 |
CNR_ATTRIBUTES_TO_READ_FROM_V4_REQUEST_DICTIONARY_
AS_STRINGS
|
表6-5 では、BAC 4.0 での DHCPv6 の Network Registrar 拡張の動作を制御するプロパティについて説明しています。
表6-5 BAC 4.0 の DHCPv6 Network Registrar 拡張のプロパティ
|
|
|
/cnrExtension/attributesRequiredInV6 Request |
RDU に構成生成の要求を送信するために、Network Registrar DHCPv6 要求辞書が拡張に含める必要がある属性のリストを示します。 |
CNR_ATTRIBUTES_REQUIRED_IN_V6_REQUEST_DICTIONARY
|
/cnrExtension/attributesToPullFromV6 RequestAsBytes |
Network Registrar DHCPv6 要求辞書からバイナリ形式でプルする属性のリストを示します。 |
CNR_ATTRIBUTES_TO_READ_FROM_V6_REQUEST_DICTIONARY_
AS_BYTES
|
/cnrExtension/optionsRequiredInV6 Request |
RDU に構成生成の要求を送信するために、Network Registrar DHCPv6 要求辞書が拡張に含める必要がある DHCP オプションのリストを示します。 |
CNR_OPTIONS_REQUIRED_IN_V6_REQUEST_DICTIONARY
|
/cnrExtension/optionsToPullFromV6 Request AsBytes |
Network Registrar DHCPv6 要求辞書からバイナリ形式でプルする DHCP オプションのリストを示します。 |
CNR_OPTIONS_TO_READ_FROM_V6_REQUEST_DICTIONARY_AS_
BYTES
|
|
/cnrExtension/attributesRequiredInV6 Relay |
RDU に構成生成の要求を送信するために、Network Registrar DHCPv6 Relay-Forward 要求辞書が拡張に含める必要がある属性のリストを示します。 |
CNR_ATTRIBUTES_REQUIRED_IN_V6_RELAY_DICTIONARY
|
/cnrExtension/attributesToPullFromV6 RelayAsBytes |
Network Registrar DHCPv6 Relay-Forward 要求リレー辞書からバイナリ形式でプルする属性のリストを示します。 |
CNR_ATTRIBUTES_TO_READ_FROM_V6_RELAY_DICTIONARY_AS_
BYTES
|
/cnrExtension/optionsRequiredInV6Relay |
RDU に構成生成の要求を送信するために、Network Registrar DHCPv6 Relay-Forward 要求辞書が拡張に含める必要がある DHCP オプションのリストを示します。 |
CNR_OPTIONS_REQUIRED_IN_V6_RELAY_DICTIONARY
|
/cnrExtension/optionsToPullFromV6 RelayAsBytes |
Network Registrar DHCPv6 Relay-Forward 要求リレー辞書からバイナリ形式でプルする DHCP オプションのリストを示します。 |
CNR_OPTIONS_TO_READ_FROM_V6_RELAY_DICTIONARY_AS_
BYTES
|
IPv6 の設定ワークフロー
IPv6 をサポートするための BAC の設定には、2 つの異なるワークフローがあります。
• プロビジョニング グループでの DPE の設定。 表3-3 を参照してください。
• ネットワークでの Network Registrar サーバの設定。 表3-5 を参照してください。
リース クエリー
BAC RDU は、DHCP リース クエリー プロトコルを使用して、Network Registrar に対してデバイスの IP アドレスをクエリーします。その後、BAC はこの情報を IPv4 と IPv6 の両デバイスのデバイス中断や詳細なレポート作成に使用します。
この BAC リリースは、次の構成をサポートしています。
• 「リース クエリーの自動設定」
• 「リース クエリーの送信元 IP アドレス」
リース クエリーの自動設定
RDU は名前解決を実行して、リース クエリーの送信先である Network Registrar サーバの IP アドレスを決定します。DNS で障害が発生すると、リース クエリーは失敗します。この BAC リリースでは、RDU がリース クエリー要求を送信する必要がある、プロビジョニング グループ内の Network Registrar サーバの IP アドレスを直接設定できます。
自動設定をイネーブルにすると、RDU はそのリース クエリーの設定を調整して、プロビジョニング グループ内の Network Registrar サーバから IPv4 と IPv6 の両方のアドレス リストを設定します。RDU は、サーバに現在登録されている情報と RDU データベースに格納されている情報を比較してから、このタスクを実行します。BAC Network Registrar 拡張が 1 つのプロビジョニング グループから別のグループに移動している場合、リース クエリーの設定は変更され、次の内容が削除されます。
• 以前のプロビジョニング グループ オブジェクトに対するリース クエリーの設定に存在する IP アドレス。
• IPアドレス リストにもう存在しない IP アドレス。
RDU は、リース クエリーの設定を検索して、プロビジョニング グループが指定した拡張を使用するように設定されているかどうかを検証します。プロビジョニング グループが拡張を使用するように設定されていない場合、RDU は Network Registrar サーバに登録されているアドレスからアドレスを選択して、プロビジョニング グループのリース クエリーの設定に追加します。
この自動設定をディセーブルにした場合、RDU は Network Registrar サーバでの登録時にそのリース クエリーの設定を変更しません。デフォルトでは、この機能はイネーブルになっています。
プロビジョニング グループ内のリース クエリー アドレスの自動設定をイネーブルまたはディセーブルにするには、管理者ユーザ インターフェイスから LeaseQuery AutoConfig オプションを設定できます。「プロビジョニング グループの表示」を参照してください。
リース クエリーの送信元 IP アドレス
以前のバージョンの BAC では、リース クエリー機能は、リース クエリー要求を送信するための送信元インターフェイスと送信元ポートの選択をオペレーティング システムに依存していました。このリリースではこれがデフォルトの動作ですが、特定のインターフェイスを使用してリース クエリー要求を送信するように RDU を設定することもできます。
リース クエリーの設定
デフォルトでは、BAC は 表 6-1 に記載されている IP アドレスとポートにバインドします。
表 6-1 バインディング用のリース クエリー アドレス
|
|
|
IPv4 |
ワイルドカード |
67 |
IPv6 |
ワイルドカード |
547 |
RDU でポート 547 とポート 67 が利用可能な場合は、リース クエリー要求を送信するために特別な設定を行う必要はありません。RDU のインストール中に、インストール プログラムがこれらのポートのいずれかが他のプロセスで使用されていることを検出した場合、オペレーティング システムが選択する動的ポートを使用することをお勧めします。
次に例を示します。
DHCPv4/DHCPv6 lease query port(s) (Udp/67 and Udp/547) is in use.
Configuring the RDU to use a dynamic port for DHCPv4/DHCPv6 lease query.
インストール プログラムは、 BPR_HOME/rdu/conf/rdu.properties ファイルの次のプロパティに値 0 を設定して動的ポートの選択を自動的にイネーブルにします。
/cnrQuery/clientSocketAddress=0.0.0.0:0
/cnrQuery/ipv6/clientSocketAddress=[::]:0
同じプロパティを使用して、リース クエリーの通信に使用する IP アドレスとポートを設定することもできます。次に例を示します。
/cnrQuery/clientSocketAddress=10.1.2.3:166
/cnrQuery/ipv6/clientSocketAddress=[2001:0DB8:0:0:203:baff:fe12:d5ea]:1547
RDU は、これらのプロパティを使用して、ユーザが指定する IP アドレスとポートにバインドします。
(注) rdu.properties ファイルのプロパティを手動で変更する場合は、必ず RDU を再起動してください。/etc/init.d/bprAgent restart rdu コマンドを使用します。
リース クエリーのリレー エージェントとしての BAC の設定
リレー エージェントとして動作するように BAC を設定できます。リレー エージェントのオプションは次のとおりです。
• IPv4 ではデフォルトでイネーブル化
• IPv6 ではデフォルトでディセーブル化
IPv4 のリース クエリーの場合
BAC が IPv4 リース クエリーのリレー エージェントとして動作する場合、BAC はリース クエリー要求パケットに GIADDR(DHCP サーバが応答する IP アドレス)を提供します。デフォルトでは、RDU は、この目的でコンピュータのプライマリ IP アドレスを使用します。
(注) 配備内のすべての DHCP サーバがこの IP アドレスにアクセスできるようにしてください。また、このプロパティで使用する IP アドレスは、RDU をインストールしたコンピュータに存在する必要があります。
GIADDR フィールドで使用する IP アドレスを変更するには、 rdu.properties ファイルの /cnrQuery/giaddr プロパティの値を変更する必要があります。たとえば、GIADDR を 10.10.10.1 に変更する場合、次のように追加します。
/cnrQuery/giaddr=10.10.10.1
rdu.properties ファイルのプロパティを手動で変更する場合は、 /etc/init.d/bprAgent restart rdu コマンドを使用して RDU を再起動してください。
IPv6 リース クエリーの場合
BAC が IPv6 リース クエリーのリレー エージェントとして動作するように設定するには、 rdu.properties ファイルに次のプロパティを含める必要があります。
/cnrQuery/ipv6/linkAddress=IPv6 address
/cnrQuery/ipv6/peerAddress=IPv6 address
次に例を示します。
/cnrQuery/ipv6/linkAddress=2001:0DB8:0:0:203:baff:fe12:d5ea
/cnrQuery/ipv6/peerAddress=2001:0DB8:0:0:203:baff:fe12:d5ea
(注) リンク アドレスとピア アドレスに入力する値は、BAC と Network Registrar を稼動するネットワークの構成によって異なります。単純なケースでは、リンク アドレスとピア アドレスを RDU ホストの IPv6 アドレスに設定する必要があります。この IPv6 アドレスは Network Registrar にルーティング可能である必要があります。
/etc/init.d/bprAgent restart rdu コマンドを使用して、RDU を再起動します。
例
この例は、リレー エージェント オプションがイネーブルになっている IPv6 リース クエリー要求の出力を示しています。
rdu.example.com: 2007 10 18 19:40:30 EDT: %BAC-RDU-7-DEBUG_DHCP_IF_IPV6: PACE-2:ServerBatch[Batch:rdu.example.com/10.10.10.1:1b994de:115b52abeb4:80000278]: Peer[rdu.example.com:33743]: Querying single prov group for DUID [00:03:00:01:23:45:67:89:98:56] via DHCPv6 LEASEQUERY packet [version V6, message-type 12, hop-count 0, link-address 2001:0DB8:0:0:203:baff:fe12:d5ea, peer-address 2001:0DB8:0:0:203:baff:fe12:d5ea, (relay_msg (9) option (52 bytes) version V6, message-type 14, transaction-id 13401290, (client-identifier (1) option (9 bytes) 00:11:22:33:44:55:66:77:88), (lq-query (44) option (31 bytes) query-type 2, link-address 0:0:0:0:0:0:0:0, (client-identifier (1) option (10 bytes) 00:03:00:01:23:45:67:89:98:56)))]
AIC Echo のイネーブル化
AIC Echo オプションを使用して、標準ポートではなく、要求元のクライアントの送信元ポートに応答を送信するように Network Registrar を設定できます。
たとえば、IP アドレスが 10.1.1.1 のクライアントがポート 1456 を使用して要求を転送し、サーバ上で AIC Echo がディセーブルになっている場合、そのサーバは応答を標準クライアント ポートに返します。プロトコル スタックに応じて、標準クライアント ポートは次のいずれかになります。
• 67 は IPv4
• 546 は IPv6
AIC Echo がイネーブルになっている場合、応答はポート 1456 に転送されます。
IPv4 リース クエリーを要求する場合、AIC Echo はデフォルトでディセーブルになります。このオプションは、デフォルトの IPv4 バインディング ポートが変更された場合にのみ使用されます。
IPv6 リース クエリーを要求する場合、AIC Echo はデフォルトでイネーブルになります。ただし、IPv6 リース クエリー メッセージはデフォルトではリレーされないので、このオプションは、標準クライアント ポートの 546 ではなく、ポート 547 にリース クエリーの応答を返すために使用されます。
リース クエリーのデバッグ
RDU で情報レベル ロギング(6:情報)を使用して、リース クエリー処理に関連する重要な詳細情報を表示できます(RDU でのログ レベルを設定するには、「RDU ログ レベル ツールの使用方法」を参照してください)。
リース クエリー機能をデバッグする場合は、次のプロパティを使用できます。
• dhcpleasequeryv4 :IPv4 リース クエリーのデバッグ
• dhcpleasequeryv6 :IPv6 リース クエリーのデバッグ
プロビジョニング グループ内の全(2 台)Network Registrar サーバにおけるクライアントごとに 1 つのリース
IPv6 に対するフェールオーバー プロトコルがまだ定義されていない状態では、通常、プロビジョニング グループ内の 1 台の Network Registrar サーバのみがクライアントのリース情報を保持します。このケースで、プロビジョニング グループに 2 台の Network Registrar サーバが存在する場合、RDU は両方のサーバにリース クエリー要求を送信しますが、1 台からのみ応答を受信します。IP アドレスはその応答で指定されたものが使用されます。
この IP アドレスは、次の方法で表示できます。
• 管理者のユーザ インターフェイス( Devices > Device Details ページ上)。
• API(リース クエリー マップで client-ipaddress 属性を使用)。
プロビジョニング グループ内の全(2 台)Network Registrar サーバにおけるクライアントごとに複数のリース
まれに、プロビジョニング グループ内の両方の Network Registrar サーバが同じクライアントのリースを保持し、両方のサーバがリース クエリー応答に応答することがあります。この場合、DHCPv6 Leasequery ドラフトごとに、直近の OPTION_CLT_TIME(client-last-transaction-time)がある応答が使用されます。
1 台の Network Registrar サーバのクライアントごとに複数のリース
クライアントが同じサーバの異なる 2 つのリンクにリースを保持している場合、Network Registrar では、応答時の OPTION_LQ_CLIENT_LINK オプションにすべてのリンク アドレスが含まれます。その後、BAC は Network Registrar に個々のリンクをクエリーして、すべての IP アドレスを取得します。このリストでは、BAC は、ループバックでもデバイス中断用のマルチキャスト アドレスでもない最初の IP アドレスを使用します。
管理者のユーザ インターフェイスを使用して、このプロセスで取得した IP アドレスのリストを Devices > Device Details ページで表示できます。
委任プレフィックスがあるデバイスのリース
IP アドレス、または委任プレフィックス、あるいは両方が割り当てられているデバイスのリース クエリー要求を送信できます。
管理者のユーザ インターフェイスを使用して、IP アドレスとプレフィックスを Devices > Device Details ページで表示できます。この IP アドレスを API を使用して取得するには、リース クエリー マップで iaprefix 属性を使用します。