Appendix F. Multiple Interfaces to Same Network
(2) 標準 OSPF ヘッダの checksum フィールドは計算されず、代わりに 0 に設定されます。
(3) Key ID（Figure 18 参照）は、選択した鍵の Key ID に設定されます。
(4) Auth Data Len フィールドは、OSPF パケットに付加されるメッセージダイジェストの長さ（バイト単位）に設定されます。認証アルゴリズムとして MD5 を使用する場合、Auth Data Len は 16 になります。
(5) 32 ビット Cryptographic sequence number（Figure 18 参照）は、非減少の値（すなわち、インターフェースから送信された最後の値以上の値）に設定されます。cryptographic sequence number フィールドで使用する正確な値は実装依存です。たとえば、単純なカウンタに基づくか、システムのクロックに基づく場合があります。
(6) その後、メッセージダイジェストが計算され、OSPF パケットに付加されます。ダイジェストの計算に使用される認証アルゴリズムは、鍵自体によって示されます。認証アルゴリズムへの入力は、OSPF パケットと秘密鍵で構成されます。認証アルゴリズムとして MD5 を使用する場合、メッセージダイジェストの計算は次のように進みます。
(a) 16 バイトの MD5 鍵が OSPF パケットに付加されます。
(b) [Ref17] で指定されているとおり、末尾のパッドおよび長さフィールドが追加されます。
(c) MD5 認証アルゴリズムが、OSPF パケット、秘密鍵、パッド、および長さフィールドの連結に対して実行され、16 バイトのメッセージダイジェストが生成されます（[Ref17] 参照）。
(d) MD5 ダイジェストは、OSPF 鍵上に書き込まれます（すなわち、元の OSPF パケットに付加されます）。ダイジェストは OSPF パケットの長さフィールドにはカウントされませんが、パケットの IP 長さフィールドには含まれます。ダイジェストを超える末尾のパッドまたは長さフィールドは、カウントも送信もされません。
D.5 Message verification（メッセージ検証）
インターフェースで OSPF パケットを受信したとき、それは認証される必要があります。認証手順は、標準 OSPF パケットヘッダの Autype の設定によって示され、これは受信 OSPF インターフェースの Autype の設定と一致します。
OSPF プロトコルパケットが真正なものとして受け入れられた場合、セクション 8.2 で指定されたとおりパケットの処理が続行されます。認証に失敗したパケットは破棄されます。
D.5.1 Verifying Null authentication（Null 認証の検証）
Null 認証を使用する場合、OSPF ヘッダの checksum フィールドを検証する必要があります。これは、認証フィールドを除く、パケット内のすべての 16 ビットワードの 1 の補数和の 16 ビット 1 の補数に設定されている必要があります。（パケットの長さが 16 ビットワードの整数倍でない場合、チェックサム計算前にゼロのバイトでパディングされます。）
D.5.2 Verifying Simple password authentication（単純パスワード認証の検証）
単純パスワード認証を使用する場合、受信した OSPF パケットは次のように認証されます。
(1) OSPF ヘッダの checksum フィールドを検証する必要があります。これは、認証フィールドを除く、パケット内のすべての 16 ビットワードの 1 の補数和の 16 ビット 1 の補数に設定されている必要があります。（パケットの長さが 16 ビットワードの整数倍でない場合、チェックサム計算前にゼロのバイトでパディングされます。）
(2) OSPF パケットヘッダの 64 ビット認証フィールドは、インターフェースに対して設定された 64 ビットパスワード（すなわち認証キー）と等しくなければなりません。
D.5.3 Verifying Cryptographic authentication（暗号認証の検証）
暗号認証を使用する場合、受信した OSPF パケットは次のように認証されます。
(1) 受信 OSPF パケットで指定された Key ID と等しい Key ID を持つ、受信インターフェースの設定済み鍵を探します（Figure 18 参照）。鍵が見つからない場合、または鍵が受信用として有効でない場合（すなわち 現在時刻 < KeyStartAccept または 現在時刻 >= KeyStopAccept）、OSPF パケットは破棄されます。
(2) OSPF ヘッダで見つかった cryptographic sequence number（Figure 18 参照）が、送信ネイバーのデータ構造に記録された cryptographic sequence number より小さい場合、OSPF パケットは破棄されます。
(3) 付加されたメッセージダイジェストを次の手順で検証します。
(a) 受信したダイジェストを確保（set aside）します。
(b) セクション D.4.3 のステップ 6 で指定されたとおり、新しいダイジェストを計算します。
(c) 計算されたダイジェストと受信したダイジェストを比較します。一致しない場合、OSPF パケットは破棄されます。一致する場合、OSPF プロトコルパケットは真正なものとして受け入れられ、ネイバーのデータ構造内の「cryptographic sequence number」がパケットの OSPF ヘッダで見つかったシーケンス番号に設定されます。
E. An algorithm for assigning Link State IDs（Link State ID を割り当てるアルゴリズム）
AS-external-LSAs および summary-LSAs の Link State ID は、通常、記述されるネットワークの IP アドレスに設定されます。しかし、必要に応じて、ネットワークのホストビットの 1 つ以上を Link State ID に設定できます。これにより、ルーターは同じアドレスであってもマスクの異なるネットワークに対して別個の LSA を発信できます。そのようなネットワークは、スーパーネット（supernetting）およびサブネット 0 の存在下で発生する可能性があります（[Ref10] 参照）。
この付録は、Link State ID にホストビットを設定する 1 つの可能なアルゴリズムを示します。そのようなアルゴリズムの選択はローカルの決定事項です。影響を受けるのはルーター自身が発信する LSA のみであるため、別個のルーターは異なるアルゴリズムを自由に使用できます。使用されるアルゴリズムに課される唯一の要件は、可能な限りネットワークの IP アドレスを Link State ID として使用することです。これは RFC 1583 以前の OSPF 実装との相互運用性を最大化します。
以下のアルゴリズムは AS-external-LSAs に対して記述されています。これは明確にするためだけのものです。まったく同じアルゴリズムを summary-LSAs にも使用できます。ルーターがアドレス NA とマスク NM1 を持つネットワークの AS-external-LSA を発信したいと仮定します。次に、LSA の Link State ID を決定するために以下の手順が使用されます。
(1) ルーターがすでに Link State ID が NA に等しい AS-external-LSA を発信しているかどうかを判断します（そのような LSA では、ルーター自身が LSA の Advertising Router としてリストされます）。発信していない場合、Link State ID は NA に等しく設定され、アルゴリズムは終了します。そうでない場合は、以下のとおりです。
(2) すでに存在する AS-external-LSA の本体からネットワークマスクを取得します。このマスクを NM2 と呼びます。次に 2 つの場合があります。
o NM1 は NM2 より長い（すなわちより具体的である）。この場合、新しい LSA の Link State ID を、すべてのホストビットがセットされたネットワーク [NA,NM1]（すなわち、NM1 でセットされていないすべてのビットと NA を OR したもの、これはネットワーク [NA,NM1] のブロードキャストアドレスに等しい）に設定します。
o NM2 は NM1 より長い。この場合、Link State ID が NA の既存の LSA を、シーケンス番号をインクリメントし、本体のマスクを NM1 に変更して新しいネットワークのコストを挿入することで、新しいネットワーク [NA,NM1] を参照するように変更します。その後、古いネットワーク [NA,NM2] の新しい LSA を、Link State ID が NA と NM2 でセットされていないビットを OR したもの（すなわちネットワーク [NA,NM2] のブロードキャストアドレス）に等しくなるように発信します。