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 はじめに

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

OpenRoaming でキャプティブポータルを併用するこ証と無線接続が行われる．この方式では，高いセキュとは強く非推奨とされている．近年，OpenRoaming

リティと自動接続によって利便性の高い無線 LAN 利の普及に伴い，現地情報の提示が重要視されるように用環境が実現されるが，現地に固有の利用規約や注なった．無線 LAN の接続時に，利用者の操作がなく意事項，現地案内などの情報を利用者に提示する手段ても通信が遮断されないような，情報提示のための仕が十分に整備されていない．eduroam の参加機関や，様が幾つか現れている．

OpenRoaming を導入する店舗・施設などから，この本研究では，現地情報の提供方法と，主要なオペレーような情報提示を行いたいという要望が出ることがあ

ティングシステム (OS) によるサポート状況を調査しる．一方，公衆無線 LAN で現在主流のウェブ認証方た．また，新しい仕様に対応できていない OS もサ式では，キャプティブポータル (Captive Portal) のポートできるように，キャプティブポータル技術の併仕組みを利用した情報提示が可能であるが，セキュリ用・応用の技術を含めて，情報提示の仕組みとソフトティ上の問題が多く，Enterprise 型のような自動接続ウェアを開発した．これを用いると，WPA2/WPA3が難しい．

Enterprise のネットワークにおいても，利用者が容易

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

種 OS に対応したシステムを構築するのは容易ではななる．これにより，様々な無線 LAN サービスの利便い．オープンソースの実装としては，CoovaChilli [4]性向上が期待される．

や openNDS [5] などがある．

本稿では，初めに，現行のキャプティブポータルのキャプティブポータルの仕組みの標準化が推進され動向と，新しい情報提示の仕組みを説明する．本研究て，現在は RFC 8908, 8910 としてまとめられていで目標とするシステム要件を明らかにする．続いて，る [6, 7]. OS 側の基本的な動作は，以下のようにな

最近の各種 OS における現地情報 (Venue Info) 提示

る．端末が無線 LAN に接続され，DHCP (Dynamicのサポート状況，および，キャプティブポータルの仕Host Conﬁguration Protocol) によって IP アドレス組みを利用した代替手段について解説する．最後に，を取得する際に，DHCP option 114 (DHCPv4) ま各機関において極力小さなシステム変更で導入できたは Router Advertisement option 37 (DHCPv6) にることを目指して開発した，情報提示のためのソフト

よって Captive Portal API のアドレスを受け取る．

ウェアを紹介する．

OS はこの API とやり取りをして，ポータルサイトの2 キャプティブポータルと現地情報提示アドレスなどを受け取り，必要に応じて利用者に通知したりポップアップ画面を出す．また，必要に応じて，公衆無線 LAN で広く使われているキャプティブ

ポータルサイト側で利用者認証や利用許諾の手続きをポータルは，基本的には利用者認証ないし利用規約提進める．API では venue-info-url というパラメータが示・同意取得，および，アクセス制御を目的としたシ定義されており，これらの処理を省略しても，任意のステムである．このため，利用者が認証情報を入力すウェブサイトのアドレスを利用者に通知することがでるか，利用規約に同意するための操作を行うまでは，きる．現地情報の通知だけが目的で，OS がそのようポータルサイト以外への通信は遮断される．

な機能を提供しているなら，僅か数個の固定パラメー

キャプティブポータルの初期の実装では，ルータでタを JSON (JavaScript Object Notation) 形式で返ARP (Address Resolution Protocol) テーブルの値をすスクリプトと，DHCP サーバへのオプション追加の書き換えたり，ポート 80/TCP をリダイレクトするみで実装できる．

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

トに誘導していた．この手法は広く使われているものが使われている．Passpoint Release 3 で Venue URLの，HTTPS (Hypertext Transfer Protocol Secure)と呼ばれる属性値が追加された．この属性値を使うこの利用が一般的になった現在では，利用者が明示的とで，現地情報 (Venue Info) などを含むウェブサイトにウェブブラウザに HTTP のアドレスを入力するまのアドレスを利用者に通知できる．しかしながら，執で機能しないという，実用性に乏しいものである．原

筆時点において，この属性値は有効に利用されていな

理的には中間者攻撃 (Man-In-The-Middle (MITM)いようである．また，Passpoint を使わない eduroamAttack) と変わらず，HTTPS に適用すると不正な証などの無線 LAN では，利用できない．

明書のエラーが表示されるという，セキュリティ上の問題もある．

本研究で開発するシステムでは，現地情報の提示が主目的である．Captive Portal API が利用できない

利便性とセキュリティの向上のために，現在は主要環境では，古いキャプティブポータルの仕組みを使うな OS に独自のキャプティブポータル検出 (Captiveこともやむを得えないと考えられる．目標とするシス

Portal Detection, CPD) の仕組みが組み込まれておテム要件を以下に示す．

り，ネットワークの接続時に自動的に 80/TCP の通信が開始される．基本的な原理としては，OS が特定のウェブページにアクセスして，規定の応答があればキャプティブポータルなしと判断する．もし特定アドレスの通信先が変更されていて，規定と異なる応答が• 情報提示を主目的として，利用者の操作をできるだけ排除できること．

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

図 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 の

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

独自仕様によるキャプティブポータルしか利用できすることで，ウェブブラウザがポータルサイトを表示ない．

するようにできる．

Android 11 以降では，無線 LAN に接続されると通3.2

iOS/iPadOS

知音が鳴り，ステータスバーに通知アイコンが追加さ

実機で調査した限り，iOS/iPadOS 15 以降が Cap-れる（図 1）．この通知は venue-info-url と関連付けら

port API に対応しており，実際に API へのアクセスれており，利用者は随時この通知をタップするだけでが確認された．

ポータルサイトに移動できる．

API で ”captive”: false を返した場合，15 と 16 でこの実装は，大きなポップアップ画面で操作を邪魔は利用者への通知が一切ない．iOS/iPadOS 17 では，するようなことがなく，ほぼ確実に利用者にポータル

Wi-Fi 設定の SSID をタップしたところに「ポータルmacOS 12 (Monterey) では，Capport API へのアクセスがなかった．Apple 独自のキャプティブポータ
ル機能を実装することで，上記と同様の CNA 画面を表示させることは可能である．

Apple からは，2020 年に Captive Portal API の紹介記事 [9] が出ている．今後，情報通知のみのユーザ
図 4 iOS のキャプティブポータル.

インタフェースが洗練されることを願っている．

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 のキャプティブポータル.

取り，別の文字列を返す．OS はキャプティブポータ
ルありと判断して，別のファイルからポータルサイトのアドレスを読み取り，ウェブブラウザでそのサイトページを開く」という表示が追加された（図 3）．しかしながら，通知アイコンも通知音もないため，利用者がこれに気付くのは難しいと考えられる．

を自動的に開く．
この実装では，端末が新しいネットワークに接続されるたびにウェブブラウザのタブが増えていくといAPI で ”captive”: true を返した場合，ネットワーう鬱陶しさがある．しかしながら，確実に情報提示でク接続時に端末に全画面のポップアップが表示される

きる上に，利用者が随時参照できるという点では好ま（図 4）．利用者には邪魔になるかもしれないが，ほぼしい．

確実に利用者に見て欲しい情報がある場合には，このWindows は，ネットワークの利用中に，上記の確認ような通知方法を採用するしかなさそうである．僅か用ページを 20〜30 秒間隔程度でポーリングする．このタップ数でキャプティブポータル画面を抜けられる

れは NCSI (Network Connectivity Status Indicator)ような実装が望ましい．の機能であり，もし規定の文字列が得られなかった場

なお，iOS/iPadOS はキャプティブポータルを抜け合はネットワーク切断状態と判断して，画面上のアイた後でも，定期的に API をポーリングして，ネットコンが地球儀の表示になる．ネットワークが利用可能

ワーク接続状況を確認する．API は端末の接続中にな状態であっても，このような表示は利用者に不安を”captive”: false を返し続けるように実装する必要が与えるため，Windows 向けの実装では正常接続の表ある．

示を出すような工夫が必要になる．

3.3 macOS

3.5

macOS 13 (Ventura) 以降が Capport API に対応しており，実際に API へのアクセスが観測された．

ChromeOS

ChromeOS は，学校向けの Chromebook 端末として採用例が多いことから，十分な利便性の確保が必

しかしながら，API で ”captive”: false を返した

要である．しかしながら，Android と同じ Google 発

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

でありながら，現行のバージョン 117 でも Captivetrue を返した場合，画面中央に Captive Network As-

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

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

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

iOS/iPadOS と同様に，利用者に見て欲しい情報があタル機能が利用できる．ネットワーク接続の際に，端る場合には，このポップアップ画面に頼るしかなさそ

末 は ま ず http://www.gstatic.com/generate 204 にうである．

アクセスする．ステータスコード 204 No Contentあっても，利用者のポータルサイトへの誘導が難しい．
このため，Apple 独自のキャプティブポータル機能を追加した．

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

多 く の キ ャ プ テ ィ ブ ポ ー タ ル 実 装 で は ，特 定 のHTTP アクセスを横取りする仕組みが必要である．
端末に対して正規と異なる A/AAAA レコードを返すが返ってきた場合は，キャプティブポータルなしと判ために，手元の実装では Dnsmasq [12] を用いている．

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

他の DNS サーバを組み合わせることもできる．

RFC 8908 による venue-info-url の通知を除き，他

4 Venue Info Handler による通知機能の実装の手法では，API が個々の端末を識別し，状態を把握しながら応答を返す必要がある．現状の OS の仕様

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

では，OS 内部のキャプティブポータル機能が HTTP者ごとに実装する必要がある．大学や中小事業者，あサーバにリクエストを送る際に，端末の識別・追跡に利るいは個人でも容易に実装できるように，現地情報の用できるようなユニークな属性値を送出しない．API

提示を主目的とする API プログラム群を開発して，側は，IP アドレスを頼りに端末を識別する以外にな

Venue Info Handler という名前でパッケージ化した．

い．従って，Venue Info Handler の CGI プログラム

このプログラム群は，オープンソースソフトウェアとは，NAT (Network Address Translation) を越えるとして GitHub で公開予定である．

正常に動作しない．Venue Info Handler は，基地局とopenNDS [5] などの既存のキャプティブポータル実同じネットワークセグメントに設置する必要がある．

装と異なり，Venue Info Handler にはアクセス制御

この制約は実装の手間につながるが，現行の OS の仕関係のコードが含まれていない．このため，ファイア様では致し方ない．

ウォールとの組み合わせを考える必要がなく，HTTP評価用の無線 LAN システムを研究室内に構築して，サーバと DHCP サーバ，および，DNS サーバの設定

Venue Info Handler を追加した．各種 OS を用いて，変更のみで実装が可能である．唯一，データベース機

OS ごとの挙動を分析しながら，動作確認を行った．

能として Redis [11] を用いているが，他のデータベー

図 1〜6 は，構築したシステムを利用して実際の画面スシステムと比べて，Redis サーバの設定と起動は容をキャプチャしたものである．

易である．

Venue Info Handler では，まず RFC 8908/8910 を5 むすび利用する情報提示のための API を実装した．具体的

eduroam や OpenRoaming などの WPA2/WPA3には，venue-info-url を含む JSON データを返すだけEnterprise の無線 LAN では，接続が自動化されていの，簡便な CGI (Common Gateway Interface) プロるため，現地に固有の利用規約や現地案内などの情グラムが主体である．端末に API の所在を知らせる報を利用者に提示する仕組みが十分に整備されていために，DHCP option 114 や RA option 37 を追加なかった．ポータルサイトへの誘導のために，キャプするが，これは多くの DHCP サーバで容易に設定でティブポータルを併用した場合，利便性の大幅な低下きる．

を招く問題があった．本研究では，なるべく利用者に前章で説明したように，最近の主要な OS であっても，Captive Portal API (RFC 8908) のみでは十分負担を強いないように，ポータルサイトへのアクセス手段を提供する仕組みを検討した．

な情報提示が難しい．Apple 製の OS（iOS/iPadOS,現地情報の提供方法と，主要 OS によるサポート状macOS）では，RFC 8908 に準拠したバージョンで況を調査した．また，新しい仕様に対応できていないOS もサポートできるような，情報提示の仕組みとソポットネットワークへのシームレスでセキュアフトウェアを開発した．これにより，Enterprise 型でな接続を実現.” https://www.wi-fi.org/ja/

も利用者が容易にポータルサイトを見つけ，有益な情

discover-wi-fi/passpoint/

報を得ることができるようになり，無線 LAN サービ(2023 年 10 月 5 日参照)

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

[9] Apple,

現時点では，OS ベンダの独自実装によるキャプティ“How to modernize your captivenetwork.”

https://developer.apple.com/

ブポータルの仕組みに頼らざるを得ないことが多い．

news/?id=q78sq5rv

今後，Captive Portal API (RFC 8908/8910) の普及(2023 年 10 月 5 日参照)に伴って実装の煩わしさは減っていくものと考えら[10] Venue Info Handler:

https://github.com/

れるが，現地情報の提示という観点では必ずしも使い

hgot07/VenueInfoHandler/

やすいユーザインタフェースにはなっていないことか(2023 年 10 月 5 日参照)

ら，OS ベンダや無線 LAN 業界に対して改良を働き[11] Redis: https://redis.io/

かけていく予定である．

(2023 年 10 月 5 日参照)

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

https://thekelleys.org.uk/

仕組みは，Enterprise 型の自動接続という利点を少な

dnsmasq/doc.html

からず犠牲にする．eduroam や OpenRoaming への(2023 年 10 月 5 日参照)

採用は慎重に行うべきである．
本研究の一部は，令和 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 ホットス