要約

  • PPPアクセスではLCPの後にIPv6CPが続く一方、RADIUS認証・認可はアドレス割り当てより先に終わることがある。そのためNASは、ホストがIPv4、IPv6、または両方を使うかまだ分からない場合がある。
  • RFC 3162は一つのRADIUSメッセージに両アドレスファミリーの属性を含めることを認め、クライアントが使えるものだけをNASが適用する設計にした。認可された値は、アドレス、プレフィックス、経路、稼働中のサービスが既に存在する証拠ではない。

答えより先に質問が来る

加入者のセッションを開くには、アクセスサーバーは先にポリシー判断を得る必要がある。しかし、RADIUSサーバーに利用者を許可するか問い合わせる時点では、ホストが最終的に使うネットワーク層の構成がまだ決まっていないことがある。2001年8月に公開されたRFC 3162「RADIUS and IPv6」で、特に示唆的なのはこの順序である。

この文書が扱うのは、関連はあるが別々の二つの仕事だ。一つはRADIUS自体をIPv6上で動かすこと。もう一つはユーザーにIPv6ネットワークアクセスを提供する属性をRADIUSメッセージに載せることだ。RADIUSの転送にIPv6アドレスを使うことは、加入者にIPv6プレフィックスが割り当てられたことを意味しない。RFCは両方を扱うが、ここで問題となる時間差は後者にある。

RFC 3162はPPPアクセスで順序を説明する。Link Control Protocol（LCP）の後にIPv6 Control Protocol（IPv6CP）が続く。RADIUSによる認証と認可は、アドレス割り当てより先に完了する場合がある。したがってNetwork Access Server（NAS）がAccess-Requestを送る際、ホストがIPv4、IPv6、あるいはその両方を使うか前もって分からないことがある。

この順序では、先に使用するアドレスファミリーを尋ね、それに合う属性だけを返すという単純な設計はできない。NASは後続の交渉が答えを出す前に、ポリシー判断を必要とする。RFC 3162の解決策は推測ではない。IPv4関連属性とIPv6関連属性を一つのRADIUSメッセージで併用し、適用対象をNASが選ぶ。NASはクライアントが実際に使えるアドレスとプレフィックスだけを割り当てるべきだ。

認可は設定完了を意味しない

属性の役割も区別されている。NAS-IPv6-Addressは認証を求める装置を識別する。Framed-Interface-IdはIPv6のインターフェース識別子を扱う。Framed-IPv6-Prefixはユーザーに設定するプレフィックスと対応経路を渡す。Framed-IPv6-Routeはルーティング情報を提供し、Framed-IPv6-Poolはプレフィックス割り当てに使う設定済みプールを示す。これらは異なる制御点であり、接続性の証拠として互いに置き換えられるものではない。

一部の値は明示的にヒントとして扱われる。IPv6CPでInterface-Identifierオプションの交渉が成功すれば、NASは好みの識別子をAccess-Requestに含める。RADIUSサーバーがその希望を尊重することは推奨されるが、義務ではない。NASはIPv6プレフィックスを希望として送ることもでき、サーバーはそれを採用しなくてもよい。Access-Acceptはポリシー応答であり、端末インターフェースが希望を受け入れた記録でも、パケットがインターネットに到達できる証明でもない。

RFC 3162は返された情報の適用にも注意を促す。IPv6だけを扱えるホストにIPv4アドレスを予約する必要はなく、IPv4のみ、または6to4を使うホストにもIPv6プレフィックスは不要だ。この限定的な指摘は責任の境界を示す。RADIUSサーバーはポリシー属性を返し、NASは交渉済みのセッションを見て、クライアントが使えないアドレスファミリーの設定を避ける。

つまり認可交換は、不確実な段階では広めの応答を許し、その後でより多くのセッション情報を持つ場所が実際の利用を絞る。これは単なるメッセージ形式の選択ではない。中央のポリシーサーバーが前もって認可できることと、アクセス装置がプロトコル交渉後にようやく分かることの境界である。

各段階は分けて考える

その後にも工程は残る。要求にはNASの希望が含まれるかもしれない。応答はプレフィックスを許可・返却するかもしれない。IPv6CPはインターフェース識別子を交渉し、NASはアドレスや経路を設定するかもしれない。サービスが到達可能かは、さらに端から端までの試験で確かめる必要がある。RFC 3162は属性と交換中の位置を定義するが、実際の加入者セッションを報告したり、その後の結果を保証したりはしない。

認証、認可、アカウンティングがしばしば「アクセス」という一語にまとめられるからこそ、この区別が重要になる。認証成功の返答はアドレス設定ではなく、プレフィックスの設定もサービスの動作を意味しない。運用者は記録の証拠がどの層を説明しているのかを見分ける必要がある。

RFC 3162はIPv6関係のRADIUS情報のため、属性番号95から100まで六つを割り当てた。その後、RFC 4818は委任プレフィックス属性を定義し、RFC 6911はIPv6アクセス属性を追加し、RFC 8044はRADIUSのデータ型ガイダンスを更新した。従って2001年の文書を現代のアクセス構成全体の目録と見なすべきではない。その歴史的な貢献は、セッションのアドレスファミリーが未確定でも、両方を認可対象にできるようにした点にある。

Lu HengのNote 20は、形式的な記述と観測できるシステム状態は異なる層だという編集上の視点を与える。このRFCに当てはめれば、属性はサーバーが何を要求し、希望し、認可したかを示すが、NASが実際に何を設定したか、利用者が何に到達できたかまでは証明しない。これは編集的解釈であり、RFC著者の主張ではない。

参考資料

  1. RFC 3162 — RADIUS and IPv6
  2. RFC Editor の RFC 3162 レコード
  3. RFC 2865 — Remote Authentication Dial In User Service (RADIUS)
  4. RFC 2866 — RADIUS Accounting
  5. RFC 2868 — RADIUS Attributes for Tunnel Protocol Support
  6. RFC 2472 — IP Version 6 over PPP
  7. RFC 2460 — Internet Protocol, Version 6 Specification
  8. RFC 3056 — Connection of IPv6 Domains via IPv4 Clouds
  9. RFC 4818 — RADIUS Delegated-IPv6-Prefix Attribute
  10. RFC 6911 — RADIUS Attributes for IPv6 Access Networks
  11. RFC 8044 — Data Types in RADIUS
  12. RFC 2044 — UTF-8, a Transformation Format of Unicode and ISO 10646
  13. Lu Heng, Note 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile