eduroam/OpenRoaming
における現地情報通知
SENAC
Vol. 57, No. （1 2024.
1）― 31 ―［大学 ICT 推進協議会 2023 年度年次大会論文集より］

eduroam/OpenRoaming における現地情報通知
後藤英昭 1) ,原田寛之 2) ,漆谷重雄 3)1) 東北大学 サイバーサイエンスセンター
2) 札幌学院大学 情報処理課
3) 国立情報学研究所

Venue Information Notiﬁcation on eduroam/OpenRoaming
Hideaki Goto1) , Hiroyuki Harada2) , Shigeo Urushidani3)
1) Cyberscience Center, Tohoku University
2) Information Processing Division, Sapporo Gakuin University3) National Institute of Informatics
概要

教育・研究機関向けの無線 LAN ローミング基盤である eduroam や，市民一般向けの OpenRoaming では，WPA2/WPA3 Enterprise による利用者認証と無線接続が行われる．この方式では，高いセキュリティと自動接続によって利便性の高い無線 LAN 利用環境が実現されるが，現地に固有の利用規約や注意事項，現地案内などの情報を利用者に提示する手段が十分に整備されていない．eduroam の参加機関や，OpenRoaming を導入する店舗・施設などから，このような情報提示を行いたいという要望が出ることがある．一方，公衆無線 LAN で現在主流のウェブ認証方式は，キャプティブポータルの仕組みを利用した情報提示が可能であるが，セキュリティ上の問題が多く，Enterprise 型のような自動接続が難しい．近年の OpenRoaming の普及に伴い，現地情報の提示が重要視されるようになり，そのための仕様が幾つか現れている．本研究では，現地情報の提供方法と，主要なオペレーティングシステム (OS) によるサポート状況を調査した．また，新しい仕様に対応できていない OS もサポートできるように，キャプティブポータル技術の併用・応用の技術を含めて，情報提示の仕組みとソフトウェアを開発した．

Enterprise 型でも，利用者が容易にポータルサイトを見つけ，有益な情報を得ることができ，サービスの利便性向上が期待される．

一般にキャプティブポータルは，利用者の通信を1 はじめに遮断し，利用者のログイン後に開放するという利用る eduroam [1] や，市民一般向けの OpenRoaming [2]LAN システムとは相反するものであり，eduroam や教育・研究機関向けの無線 LAN ローミング基盤であでは，WPA2/WPA3 Enterprise [3] による利用者認形態である．このため，自動接続を至上とする無線

OpenRoaming でキャプティブポータルを併用するこ証と無線接続が行われる．この方式では，高いセキュとは強く非推奨とされている．近年，OpenRoaming用環境が実現されるが，現地に固有の利用規約や注なった．無線 LAN の接続時に，利用者の操作がなくリティと自動接続によって利便性の高い無線 LAN 利

意事項，現地案内などの情報を利用者に提示する手段が十分に整備されていない．eduroam の参加機関や，OpenRoaming を導入する店舗・施設などから，このような情報提示を行いたいという要望が出ることがあの普及に伴い，現地情報の提示が重要視されるようにても通信が遮断されないような，情報提示のための仕様が幾つか現れている．

本研究では，現地情報の提供方法と，主要なオペレーティングシステム (OS) によるサポート状況を調査しる．一方，公衆無線 LAN で現在主流のウェブ認証方た．また，新しい仕様に対応できていない OS もサ

仕組みを利用した情報提示が可能であるが，セキュリ用・応用の技術を含めて，情報提示の仕組みとソフト式では，キャプティブポータル (Captive Portal) のティ上の問題が多く，Enterprise 型のような自動接続が難しい．

ポートできるように，キャプティブポータル技術の併ウェアを開発した．これを用いると，WPA2/WPA3Enterprise のネットワークにおいても，利用者が容易

― 32 ―

SENAC Vol. 57, No. （1 2024. 1）にポータルサイトを見つけ，有益な情報を得ることあれば，キャプティブポータルありと判断して，接続約を提示したり，ポータルサイトや車内・機内 Wi-Fiる．ただし，OS ベンダごとの独自手法に依るため，各を支援できる．サービスの提供者の視点では，利用規先のシステムから提示されるページを利用者に提示すサービスのメニューなどに利用者を誘導できるように

種 OS に対応したシステムを構築するのは容易ではな性向上が期待される．

や openNDS [5] などがある．

動向と，新しい情報提示の仕組みを説明する．本研究て，現在は RFC 8908, 8910 としてまとめられてい最近の各種 OS における現地情報 (Venue Info) 提示

る．端末が無線 LAN に接続され，DHCP (Dynamicなる．これにより，様々な無線 LAN サービスの利便
本稿では，初めに，現行のキャプティブポータルので目標とするシステム要件を明らかにする．続いて，い．オープンソースの実装としては，CoovaChilli [4]キャプティブポータルの仕組みの標準化が推進され

る [6, 7]. OS 側の基本的な動作は，以下のようになのサポート状況，および，キャプティブポータルの仕Host Conﬁguration Protocol) によって IP アドレス

各機関において極力小さなシステム変更で導入できたは Router Advertisement option 37 (DHCPv6) にウェアを紹介する．

OS はこの API とやり取りをして，ポータルサイトの組みを利用した代替手段について解説する．最後に，ることを目指して開発した，情報提示のためのソフト

2 キャプティブポータルと現地情報提示

公衆無線 LAN で広く使われているキャプティブ

ポータルは，基本的には利用者認証ないし利用規約提示・同意取得，および，アクセス制御を目的としたシステムである．このため，利用者が認証情報を入力するか，利用規約に同意するための操作を行うまでは，を取得する際に，DHCP option 114 (DHCPv4) ま

よって Captive Portal API のアドレスを受け取る．
アドレスなどを受け取り，必要に応じて利用者に通知したりポップアップ画面を出す．また，必要に応じて，ポータルサイト側で利用者認証や利用許諾の手続きを進める．API では venue-info-url というパラメータが定義されており，これらの処理を省略しても，任意のウェブサイトのアドレスを利用者に通知することができる．現地情報の通知だけが目的で，OS がそのようポータルサイト以外への通信は遮断される．

な機能を提供しているなら，僅か数個の固定パラメーARP (Address Resolution Protocol) テーブルの値をすスクリプトと，DHCP サーバへのオプション追加のキャプティブポータルの初期の実装では，ルータでタを JSON (JavaScript Object Notation) 形式で返書き換えたり，ポート 80/TCP をリダイレクトするみで実装できる．

スしようとする通信経路を捻じ曲げて，ポータルサイ加えて，Passpoint [8] による基地局自動選択の仕組みことによって，利用者が任意のウェブサイトにアクセ

OpenRoaming では，WPA2/WPA3 Enterprise にトに誘導していた．この手法は広く使われているものが使われている．Passpoint Release 3 で Venue URLの利用が一般的になった現在では，利用者が明示的とで，現地情報 (Venue Info) などを含むウェブサイトの，HTTPS (Hypertext Transfer Protocol Secure)と呼ばれる属性値が追加された．この属性値を使うこにウェブブラウザに HTTP のアドレスを入力するまのアドレスを利用者に通知できる．しかしながら，執理的には中間者攻撃 (Man-In-The-Middle (MITM)いようである．また，Passpoint を使わない eduroamで機能しないという，実用性に乏しいものである．原Attack) と変わらず，HTTPS に適用すると不正な証明書のエラーが表示されるという，セキュリティ上の問題もある．

利便性とセキュリティの向上のために，現在は主要な OS に独自のキャプティブポータル検出 (CaptivePortal Detection, CPD) の仕組みが組み込まれており，ネットワークの接続時に自動的に 80/TCP の通信が開始される．基本的な原理としては，OS が特定のウェブページにアクセスして，規定の応答があればキャプティブポータルなしと判断する．もし特定アドレスの通信先が変更されていて，規定と異なる応答が筆時点において，この属性値は有効に利用されていななどの無線 LAN では，利用できない．

本研究で開発するシステムでは，現地情報の提示が主目的である．Captive Portal API が利用できない環境では，古いキャプティブポータルの仕組みを使うこともやむを得えないと考えられる．目標とするシス
テム要件を以下に示す．

• 情報提示を主目的として，利用者の操作をできるだけ排除できること．

• やむを得ず利用者の操作が必要となる場合でも，僅かの操作に留められること．

eduroam/OpenRoaming における現地情報通知― 33 ―

図 1 Android の Venue Info 通知（左上に扇型のア

図 2 Android のキャプティブポータルの例.

イコン）.

• ネットワーク接続の際に利用者に気付かれやすい通知を出しつつ，あまり邪魔にならないようにできること．

• 新しい Captive Portal API の利用を優先すること．

• モバイル端末で用いられる多様な OS に対応できること．特に，学校・大学で利用されることの多い Android, iOS/iPadOS, macOS, Windows,ChromeOS に対応することが望ましい．

• 極力，実装が容易であり，既存システムに組み入れやすいこと．

図 3 iOS のポータルページ通知.

3 各種 OS のキャプティブポータル/現地情報通知の対応状況

3.1 Android

Android 11 以降で，Captive Portal API に対応している．API で ”captive”: false とした JSON デー

サイトを知らせることができるという点で，現時点で最も用途に合致していると考えられる．

Android 11 以降では，Captive Portal API に準拠

タを端末に返すことで，ポータルサイトへのリンクをしたログイン画面を表示することもできる．実装例を独自仕様によるキャプティブポータルしか利用できすることで，ウェブブラウザがポータルサイトを表示端末に通知できる．Android 10 以前では，Google のない．

Android 11 以降では，無線 LAN に接続されると通知音が鳴り，ステータスバーに通知アイコンが追加される（図 1）．この通知は venue-info-url と関連付けられており，利用者は随時この通知をタップするだけでポータルサイトに移動できる．

この実装は，大きなポップアップ画面で操作を邪魔するようなことがなく，ほぼ確実に利用者にポータル

図 2 に示す．ログイン画面に置かれたリンクをタップするようにできる．

3.2

iOS/iPadOS

実機で調査した限り，iOS/iPadOS 15 以降が Cap-port API に対応しており，実際に API へのアクセスが確認された．

API で ”captive”: false を返した場合，15 と 16 では利用者への通知が一切ない．iOS/iPadOS 17 では，Wi-Fi 設定の SSID をタップしたところに「ポータル

― 34 ―

SENAC Vol. 57, No. （1 2024. 1）

macOS 12 (Monterey) では，Capport API へのアクセスがなかった．Apple 独自のキャプティブポータ

ル機能を実装することで，上記と同様の CNA 画面を表示させることは可能である．

Apple からは，2020 年に Captive Portal API の紹

図 4 iOS のキャプティブポータル.

介記事 [9] が出ている．今後，情報通知のみのユーザインタフェースが洗練されることを願っている．

3.4

Windows

Windows 10, 11 はいずれも Captive Portal API に非対応である．

Microsoft 独 自 の キ ャ プ テ ィ ブ ポ ー タ ルの 実 装 で は ，ネ ッ ト ワ ー ク 接 続 の 際 に ま ず

http://www.msftconnecttest.com/connecttest.txtを読み込む（Windows 10 Version 1511 以前では動作が異なる）．規定の文字列 “Microsoft Connect Test”が返ってきた場合はキャプティブポータルなしと判断
図 5 macOS のキャプティブポータル.

ページを開く」という表示が追加された（図 3）．しかしながら，通知アイコンも通知音もないため，利用者する．基地局まわりのネットワークでこの接続を乗っ取り，別の文字列を返す．OS はキャプティブポータ

ルありと判断して，別のファイルからポータルサイトのアドレスを読み取り，ウェブブラウザでそのサイトを自動的に開く．

この実装では，端末が新しいネットワークに接続さがこれに気付くのは難しいと考えられる．

れるたびにウェブブラウザのタブが増えていくとい

ク接続時に端末に全画面のポップアップが表示される

きる上に，利用者が随時参照できるという点では好ま

API で ”captive”: true を返した場合，ネットワー（図 4）．利用者には邪魔になるかもしれないが，ほぼ確実に利用者に見て欲しい情報がある場合には，このう鬱陶しさがある．しかしながら，確実に情報提示でしい．

Windows は，ネットワークの利用中に，上記の確認ような通知方法を採用するしかなさそうである．僅か用ページを 20～30 秒間隔程度でポーリングする．こような実装が望ましい．の機能であり，もし規定の文字列が得られなかった場のタップ数でキャプティブポータル画面を抜けられる

なお，iOS/iPadOS はキャプティブポータルを抜けた後でも，定期的に API をポーリングして，ネットワーク接続状況を確認する．API は端末の接続中に”captive”: false を返し続けるように実装する必要がある．

れは NCSI (Network Connectivity Status Indicator)

合はネットワーク切断状態と判断して，画面上のアイコンが地球儀の表示になる．ネットワークが利用可能な状態であっても，このような表示は利用者に不安を与えるため，Windows 向けの実装では正常接続の表示を出すような工夫が必要になる．

3.3 macOS

3.5

しており，実際に API へのアクセスが観測された．て採用例が多いことから，十分な利便性の確保が必

場 合 は 利 用 者 へ の 通 知 が な い ．API で ”captive”:

でありながら，現行のバージョン 117 でも Captive

sistant (CNA) の大きな画面が表示される（図 5）．

ChromeOS では，Google 独自のキャプティブポー

macOS 13 (Ventura) 以降が Capport API に対応
しかしながら，API で ”captive”: false を返した

true を返した場合，画面中央に Captive Network As-

ChromeOS

ChromeOS は，学校向けの Chromebook 端末とし要である．しかしながら，Android と同じ Google 発

Portal API には対応していない．

iOS/iPadOS と同様に，利用者に見て欲しい情報があタル機能が利用できる．ネットワーク接続の際に，端うである．

アクセスする．ステータスコード 204 No Contentる場合には，このポップアップ画面に頼るしかなさそ

末 は ま ず http://www.gstatic.com/generate 204 にeduroam/OpenRoaming における現地情報通知― 35 ―

あっても，利用者のポータルサイトへの誘導が難しい．
このため，Apple 独自のキャプティブポータル機能を追加した．

Windows と ChromeOS は，いずれも現行バージョンが RFC 8908 に非対応のため，Microsoft と Googleのベンダ独自仕様のキャプティブポータル機能も追加

図 6 ChromeOS のポータルサイト通知.

した．

多 く の キ ャ プ テ ィ ブ ポ ー タ ル 実 装 で は ，特 定 のHTTP アクセスを横取りする仕組みが必要である．

端末に対して正規と異なる A/AAAA レコードを返すが返ってきた場合は，キャプティブポータルなしと判ために，手元の実装では Dnsmasq [12] を用いている．

れをウェブブラウザ開くための通知が表示される（図いため，同様のアドレス書き換えが実現できるならば，断する．HTTP のコンテンツが返された場合は，そ6）．

4 Venue Info Handler による通知機能の実装

現地情報を通知する機能は，基地局を提供する事業

Venue Info Handler は DNS サーバの種類に依存しな他の DNS サーバを組み合わせることもできる．

RFC 8908 による venue-info-url の通知を除き，他の手法では，API が個々の端末を識別し，状態を把握しながら応答を返す必要がある．現状の OS の仕様

では，OS 内部のキャプティブポータル機能が HTTP者ごとに実装する必要がある．大学や中小事業者，あサーバにリクエストを送る際に，端末の識別・追跡に利提示を主目的とする API プログラム群を開発して，側は，IP アドレスを頼りに端末を識別する以外になるいは個人でも容易に実装できるように，現地情報の用できるようなユニークな属性値を送出しない．APIVenue Info Handler という名前でパッケージ化した．

い．従って，Venue Info Handler の CGI プログラムして GitHub で公開予定である．

正常に動作しない．Venue Info Handler は，基地局と装と異なり，Venue Info Handler にはアクセス制御

この制約は実装の手間につながるが，現行の OS の仕このプログラム群は，オープンソースソフトウェアとopenNDS [5] などの既存のキャプティブポータル実関係のコードが含まれていない．このため，ファイアウォールとの組み合わせを考える必要がなく，HTTPは，NAT (Network Address Translation) を越えると同じネットワークセグメントに設置する必要がある．
様では致し方ない．

評価用の無線 LAN システムを研究室内に構築して，サーバと DHCP サーバ，および，DNS サーバの設定

Venue Info Handler を追加した．各種 OS を用いて，能として Redis [11] を用いているが，他のデータベー

図 1～6 は，構築したシステムを利用して実際の画面易である．

5 むすび変更のみで実装が可能である．唯一，データベース機

スシステムと比べて，Redis サーバの設定と起動は容Venue Info Handler では，まず RFC 8908/8910 を利用する情報提示のための API を実装した．具体的

OS ごとの挙動を分析しながら，動作確認を行った．
をキャプチャしたものである．

eduroam や OpenRoaming などの WPA2/WPA3には，venue-info-url を含む JSON データを返すだけEnterprise の無線 LAN では，接続が自動化されていグラムが主体である．端末に API の所在を知らせる報を利用者に提示する仕組みが十分に整備されていの，簡便な CGI (Common Gateway Interface) プロために，DHCP option 114 や RA option 37 を追加するが，これは多くの DHCP サーバで容易に設定できる．

前章で説明したように，最近の主要な OS であっても，Captive Portal API (RFC 8908) のみでは十分な情報提示が難しい．Apple 製の OS（iOS/iPadOS,macOS）では，RFC 8908 に準拠したバージョンでるため，現地に固有の利用規約や現地案内などの情なかった．ポータルサイトへの誘導のために，キャプティブポータルを併用した場合，利便性の大幅な低下を招く問題があった．本研究では，なるべく利用者に負担を強いないように，ポータルサイトへのアクセス手段を提供する仕組みを検討した．

現地情報の提供方法と，主要 OS によるサポート状況を調査した．また，新しい仕様に対応できていない

― 36 ―

SENAC Vol. 57, No. （1 2024. 1）

OS もサポートできるような，情報提示の仕組みとソポットネットワークへのシームレスでセキュアも利用者が容易にポータルサイトを見つけ，有益な情

discover-wi-fi/passpoint/

フトウェアを開発した．これにより，Enterprise 型で報を得ることができるようになり，無線 LAN サービ

スの利便性向上が期待される．

現時点では，OS ベンダの独自実装によるキャプティ

ブポータルの仕組みに頼らざるを得ないことが多い．
今後，Captive Portal API (RFC 8908/8910) の普及に伴って実装の煩わしさは減っていくものと考えられるが，現地情報の提示という観点では必ずしも使いやすいユーザインタフェースにはなっていないことから，OS ベンダや無線 LAN 業界に対して改良を働きかけていく予定である．

なお，キャプティブポータルの画面を強制表示する

仕組みは，Enterprise 型の自動接続という利点を少なからず犠牲にする．eduroam や OpenRoaming への採用は慎重に行うべきである．

本研究の一部は，令和 5 年度国立情報学研究所公募型共同研究の助成を受けた．

参考文献[1] eduroam JP: https://www.eduroam.jp/(2023 年 10 月 5 日参照)

[2] WBA OpenRoaming:

https://wballiance.com/openroaming/(2023 年 10 月 5 日参照)

[3] Wi-Fi Alliance, “Discover Wi-Fi, Security.”
https://www.wi-fi.org/ja/
discover-wi-fi/security/(2023 年 10 月 5 日参照)

[4] CoovaChilli: https://coova.github.io/(2023 年 10 月 5 日参照)

[5] openNDS:

https://github.com/openNDS/openNDS/(2023 年 10 月 5 日参照)

[6] T. Pauly and D. Thakore, “Captive PortalAPI.” https://datatracker.ietf.org/doc/html/rfc8910(2023 年 10 月 5 日参照)

[7] W. Kumari and E. Kline,“Captive-Portal Identiﬁcation in DHCP and
Router Advertisements (RAs).”:https://datatracker.ietf.org/doc/html/rfc8910(2023 年 10 月 5 日参照)

[8] Wi-Fi Alliance, “Passpoint – Wi-Fi ホットスな接続を実現.” https://www.wi-fi.org/ja/(2023 年 10 月 5 日参照)

[9] Apple,“How to modernize your captivenetwork.”

https://developer.apple.com/

news/?id=q78sq5rv(2023 年 10 月 5 日参照)

[10] Venue Info Handler:

https://github.com/

hgot07/VenueInfoHandler/(2023 年 10 月 5 日参照)

[11] Redis: https://redis.io/(2023 年 10 月 5 日参照)

[12] Dnsmasq:

https://thekelleys.org.uk/

dnsmasq/doc.html(2023 年 10 月 5 日参照)