2. アルゴリズムが動作するコンテキスト (Context in Which the Algorithms Operate)

2. アルゴリズムが動作するコンテキスト

アドレス選択のコンテキストは、宛先アドレスの選択と送信元アドレスの選択を分離する最も一般的な実装アーキテクチャから導出されます。したがって、これらのタスクに対して 2 つの独立したアルゴリズムを提供します。これらのアルゴリズムは連携して動作するよう設計されており、管理者ポリシーの上書きメカニズムを共有します。

この実装アーキテクチャでは、アプリケーションは getaddrinfo() [RFC3493] などの API を使用し、これらの API はアドレスのリストをアプリケーションに返します。このリストには IPv6 と IPv4 の両方のアドレスが含まれる場合があります（IPv4 マップアドレスとして表現されることもあります）。アプリケーションは connect() または sendto() を通じて宛先アドレスをネットワークスタックに渡します。アプリケーションは通常リストの最初のアドレスを試み、有効なアドレスが見つかるまでアドレスリストを循環します。ネットワーク層が複数の候補から宛先アドレスを選択する必要がある状況は発生しません。アプリケーションは bind() で送信元アドレスを指定することもありますが、通常は送信元アドレスは未指定です。したがって、ネットワーク層は複数の候補から送信元アドレスを選択する必要があることが多くあります。

したがって、getaddrinfo() などの API の実装は、ここで規定される宛先アドレス選択アルゴリズムを使用して、返す IPv6 と IPv4 のアドレスリストを並べ替えることを意図しています。また、アプリケーションや上位層が送信元アドレスを指定しない場合、IPv6 ネットワーク層は送信元アドレス選択アルゴリズムを使用します。

行儀の良いアプリケーションは、getaddrinfo() などの API から返された最初のアドレスを単純に使用して失敗したら諦めるべきではありません。多くのアプリケーションでは、有効なアドレスが見つかるまで getaddrinfo() から返されたアドレスリストを反復することが適切です。

アルゴリズムは決定を行う際にいくつかの基準を使用します。総合的な効果は、2 つのアドレスが等しいスコープまたはタイプを持つ宛先/送信元アドレスペアを優先し、宛先アドレスについては大きいスコープより小さいスコープを優先し、非推奨でない送信元アドレスを優先し、ローカルアドレスが利用可能な場合は移行アドレスの使用を避け、他の条件が等しい場合は最長共通プレフィックスを持つアドレスペアを優先することです。

本仕様はオプションとして、管理者がデフォルト動作を上書きできるポリシーを設定できる可能性を許可します。ポリシーの上書きには以下の状態セットが含まれ、設定可能であるべきです。

• ポリシーテーブル (Policy Table)（第 2.1 節）: 宛先プレフィックスの優先度値と優先送信元プレフィックスを指定するテーブル。
• 自動行追加フラグ (Automatic Row Additions flag)（第 2.1 節）: 特定のタイプのアドレスに対してサイト固有の行を自動的に追加することを実装に許可するかどうかを指定するフラグ。
• プライバシー優先フラグ (Privacy Preference flag)（第 5 節）: 両方のタイプが存在する場合、デフォルトで一時送信元アドレスと安定送信元アドレスのどちらを優先するかを指定するフラグ。