Summary

  • RADEXTの作業草案は、RFC 7930が実験的に定めたRADIUSパケットコード52、Protocol-Errorの標準化を提案する。IANA登録簿の参照先は現在もRFC 7930だ。
  • エラーにはError-CauseとOriginal-Packet-Codeの両方が必要になる。後者は同じIdentifierを異なる種類の要求が使ったとき、どの処理で失敗したかを特定する。
  • このエラーは隣接する一ホップごとの情報だ。原因502と505なら、プロキシは別の接続または宛先を試すべきで、失敗した接続への再送は禁止される。

RADIUSでは、返事がないという事実が多くを背負いすぎてきた。認証サーバーが混雑しているのか、要求が処理できないのか、さらに先のプロキシが行き止まりになったのか。アクセス装置からは、どれもタイムアウトに見えることがある。装置は自分の設定に従って再送する。同じ経路を使う装置が一斉に動けば、障害中の経路へ追加の負荷が集まる。

コード52は、より具体的な知らせを返すためのものだ。「要求は受け取ったが、処理できなかった」。草案はアクセス認証、課金記録、認可変更、切断の各要求を例に挙げる。課金記録を書けなかったなら処理失敗と伝えればよい。認証処理の技術的な故障を利用者への拒否という判断に置き換える必要もない。2016年のRFC 7930はこのパケットを実験として導入した。11月の草案はクライアントとサーバーの振る舞いを広く定めようとしている。

診断の宛先を間違えないため、二つの属性を必須とする。Error-Causeは原因、Original-Packet-Codeはエラーを生んだ要求の種類を示す。RADIUSのIdentifierは要求種別が違えば同じ数字になり得る。番号だけを照合すると、課金の障害をログインの結果として扱いかねない。応答は元のIdentifierを写し、元のコードに一致する処理中の要求がなければ、クライアントはその応答を破棄する。誤った案件に貼った正確な診断書は、単なる無応答より厄介だ。

故障した接続を管理するのは誰か

草案の第4節はProtocol-Errorをホップごとのパケットと定める。受け取ったプロキシはそのまま転送できず、Error-Causeを見てプロキシ網の故障か、ホームサーバーからの報告かを分ける。下流の接続を選んだのはプロキシであり、アクセス装置が知るのはプロキシまでの経路だ。復旧判断の場所もそれに従う。

502のRequest Not Routable (Proxy)と505のOther Proxy Processing Errorは、草案ではプロキシ網の故障を示す。プロキシは同じ宛先への別接続か、別の宛先を試すべきだ。直前に失敗した接続には要求を送り直せない。この一行が自動復旧と自動増幅を分ける。同じ行き止まりへ高速で投げ続けても通信は回復しない。代替経路の順番、試行回数、時間の上限は草案がすべて決めてくれるわけではなく、運用側の設計事項として残る。

それ以外の原因は、原則としてホームサーバー由来と解釈する。プロキシは受け取った原因を含む新しいProtocol-Errorを自分のクライアントへ送る。これは下流のパケットを素通りさせる操作ではなく、プロキシの判断を経た上流への報告だ。調査時には最初の要求、次ホップの応答、プロキシの経路選択、アクセス装置が見た最終結果を一本につなぐ必要がある。エラーそのものが利用者の認証完了や課金記録の保存を証明することはない。

移行、協議、具体的にいつエラーを返すかについては、草案にまだTBDが残る。二段のプロキシを通した実運用の記録も公式資料にはない。管理された試験で、要求種別とIdentifier、原因、使わなくなった接続、新経路、アクセス装置の最終動作を記録すれば、提案された責任分担が実装で守られるか分かる。

RADEXT草案 · Datatracker · RFC 7930 · IANA登録簿