3.2 Parsing and Modifying (解析と変更)

3.2 Parsing and Modifying (解析と変更)

3.2.1 General Summary (一般的な概要)

テキスト表現のすべての可能な方法において, 各アプリケーションは, どのように表現されていても同じアドレスを意味するように IPv6 アドレスを解析する関数へのモジュール, オブジェクト, リンクなどを含める必要があります。企業顧客向けに複雑なコンピュータシステムを統合する多くのシステムエンジニアは, お気に入りのツールがこの機能を持っていないことに気づいたり, 顧客のためにマクロやスクリプトを書き直さなければならないなどの困難に遭遇したりするでしょう。

3.2.2 Logging (ロギング)

アプリケーションがフル形式でアドレスを表したログサマリを出力する場合 (2001:0db8:0000:0000:1111:2222:3333:4444 など), 出力は IPv4 出力と比較して非常に読みにくいでしょう。アドレスは人間が読むために有用にするために解析および再フォーマットされる必要があります。時には重要なシステムのロギングは, 同じトラフィックを 2 つの異なるシステムにミラーリングすることによって行われます。ログ出力が何であっても, ログが同等になるように解析されるよう注意する必要があります。

3.2.3 Auditing: Case 1 (監査: ケース 1)

ルーターまたはその他のネットワークアプライアンスマシンの構成が監査される場合, ノードの構成情報を比較する多くの方法があります。時には監査は毎日行われた変更を比較するだけで行われます。この場合, 新しいエンジニアが 2001:db8::1 が 2001:0db8:0000:0000:0000:0000:0000:0001 に変更されたのが良いと感じたという理由だけで構成が行われた場合, 単純な diff は異なるアドレスが構成されたことを示します。これが広範囲のネットワークで行われた場合, 人々は実際の監査を行う代わりに「なぜ余分なゼロが入れられたのか」に焦点を当てるでしょう。多くのツールはアドレス表現ルールを考慮しない単純な diff です。

3.2.4 Auditing: Case 2 (監査: ケース 2)

ノード構成は IP アドレスを管理する情報システムと照合されます。出力記法が異なる場合, これをカバーするために実装されるスクリプトが必要になります。SNMP GET 操作の結果をテキストに変換し, 人間によって書かれたテキストアドレスと比較することは, 最初の試みで一致する可能性は非常に低いです。

3.2.5 Verification (検証)

一部のプロトコルは特定のデータフィールドを検証することを要求します。この一例は X.509 証明書です。証明書内の IPv6 アドレスフィールドがテキストに変換し, 他のアドレスと単純なテキスト比較を行うことによって誤って検証された場合, テキスト表現方法の違いにより証明書が誤って無効として示される可能性があります。

3.2.6 Unexpected Modifying (予期しない変更)

時には, システムがアドレスを取得し, 便宜上それを変更することがあります。たとえば, システムが 2001:0db8:0::1 の入力を受け取り, 出力を 2001:db8::1 にする場合があります。ゼロが理由があって入力された場合, 結果は多少予期しないものになる可能性があります。