ゲーム・エンタメネットワーク接続性課題検討ワークグループ振り返りと今後の方針について
JAIPA一般公開版

2021年1月

ワークグループ運営

はじめに
本報告書は、２０１９年７月に 一般社団法人日本インターネットプロバイダ協会 運営委員会で承認された、横断ワークグループ「ゲーム・エンタメネットワーク接続性検討ワークグループ」の２０１９年度の活動のまとめと２０２０年度の活動方針を記載した報告書です。
報告は活動内容の報告、ワークグループで仮説を立てて検証した技術的課題、ならびに今後の方向性としてコンテンツIPv６推進についてと来年度に向けての指針を記載します。
不明点などにつきましては、JAIPA 当ワークグループ事務局にお問い合わせいただければ幸いです。

2021年1月 JAIPA webで一般公開に際して、WGで意見交換を目的に使用したプレゼンテーション資料（第５章）については非開示（WGメンバー限り）の内容が含まれているため、削除しております。

目 次

はじめに

2

第１章 ワークグループ概要
概要

3
3

第２章 ワークグループで検討を行った内容
P2PゲームなどのNW接続性課題について
NAT越え課題
NA（P）T種類について
NATの場所について
2.2 IPv6 IPoE環境におけるNW接続性課題（１）接続性課題の解説
課題①：ユーザー利用ポートの枯渇
課題②：P2Pアプリケーションの透過性
課題③：UPnP依存アプリケーションの利用課題
課題④：セッションタイマー課題
課題⑤：NATタイプによる接続課題
補足：ポート共有型NAPT環境でポート開放が難しい理由（２）課題に関して解説している過去WGにおける講演
2.3 IPv4 over IPv6技術の比較
2.4 ゲーム事業者におけるIPv6対応の課題とコスト(1) コンシューマー向けのハードウェアがIPv6に対応していない(2) 長寿コンテンツの移行障壁(3) IPV6対応/運用ノウハウの欠如(4) ゲームユーザのIPv6リテラシーの欠如

4
4
4
4
4
7
9910
1111111213
13
14
14
14
15
15

第３章 今後の方針
方針概要
ゲームハッカソン
中長期的方針
短期的方針

15
15
15
1616

第４章 ワークグループ活動内容
開催履歴
第１回目
第２回目
第３回目第４回目
第５回目
第６回目
第７回目
Slack

171717171818181919
19
1

その他

19

第５章 参考資料
５．過去プレゼンテーション

20
20

2

第１章 ワークグループ概要
1.

概要

CGN及びIPv4/IPv6共存技術の普及に伴い、IPv4アドレスシェアが増大していることに起因して、P2Pゲーム等においてユーザーの「ゲームがプレイできない」、「頻繁に切断される」事象が増加しています。これらのユーザーの問い合わせに対してISPやゲームメーカーが悩むも、要因が複雑で業界内のみの解決は困難であり、またインターネット上に正確な情報も少なくユーザーの不安が更に増大しています。その問題の解決を事象の特定から解決策を探るべくJAIPAの横断ワークグループとして運営委員会に立ち上げの起案をいたしました。
２０１９年７月のJAIPA運営委員会でワークグループが承認され「ゲーム・エンタメネットワーク接続性課題検討WG」が立ち上がりました。
WGは2019年度２月末時点で、全７回が開催され毎回２０社以上、毎回５０名前後の参加者で構成され、課題となっているP２Pゲームなどのユーザー不利益につながる事象について仮説を立てて検証をおこなうとともに、今後の指針の検討を進めました。
２０１９年度内に提言などの策定を目指しましたが、策定には至らず先送りとすることとなりました。

また、提言を見送る対案としてWGのアウトプットとしてコンテンツ関係各社
IPv6推進を目的に「IPv6オンラインゲームハッカソン」開催の準備を進めていましたがコロナウイルス感染拡大のリスクを考慮して中止となりました。さらには、３月に開催を予定しておりました「第8回WG」についても中止とすることになり年度の最終報告などが次回の開催まで延期となっている状況です。
本WGでは月１回の会合をWG参加各社のご好意により会議室をお借りする形で開催されており２０１９年８月の第1回目の開催から２０２０年２月までに計７回の会合を実施しており、毎回ゲストスピーカーによる講演と議論を中心に進められ、会合以外の場ではSlackを駆使したオンラインでの情報交換をおこないました。
これまでの振り返りの意味も含めてWGで検証した内容を第２章に記載いたします。

3

第２章 ワークグループで検討を行った内容
2.

P2PゲームなどのNW接続性課題について
本章の内容はWG会議で議論された内容を元に構成されておりますが、提示している課題については、まだ事実関係の検証や、解決方法の検討などが十分ではないものも含まれます。これを記載をしている理由は、これまで議論された内容をメンバーの方々に共有し、今後の消費者課題解決に役立てていただきたいとの考えからです。ご理解いただけますと幸いです。

2.1

NAT越え課題(1)

NA（P）T種類について(2)

NATの場所について

End to Endの通信において複数箇所でNATを経由している場合が多く、かつそれぞれの相性によって問題が発生するため、問題の切り分けが極めて困難になっています。
昔のシンプルなIP通信網のネットワーク構成例：

4

現在の多くのNATを含んだネットワーク構成例：

NATの種類における制限について
アドレス制限ポート制限

フルコーンNAT

無無アドレス制限NAT

有無ポート制限NAT

無有シンメトリックNAT

有有

NAT同士の相性
5フルコーンNAT

アドレス制限NAT

ポート制限NAT

シンメトリックNAT

フルコーンNAT◯◯◯◯

アドレス制限NAT◯◯◯◯

ポート制限NAT◯◯◯✕

シンメトリックNAT◯◯✕✕

例えば、下記の様なパターンは通信が出来ない。
● ISP A社のキャリアグレードNATがポート制限NAT● ユーザ宅内BのブロードバンドルータがシンメトリックNAT

6

2.2

IPv6 IPoE環境におけるNW接続性課題

IPv6 IPoE環境では、VNEまたはISPによりポート共有型NAPTが行われている事が多く、この環境下ではゲーム、コンテンツアプリケーションの接続性において複数の課題が存在します。（各課題については後述）
ポート共有型NAPT：
複数のユーザーで同じグローバルIPアドレスを共有するNAPT（ポート変換NAT）構成では、このNAPTを行う装置が、グローバルIPアドレスからTCP/UDPポートをユーザーに割り当てます。この動作を、ここではポート共有型NAPTと総称します。
ポート共有型NAPT概要図：IPv6 IPoE環境では、IPv4 over IPv6技術が採用されており、これらの技術ではポート共有型NAPTが行われています。IPv6 IPoEで採用されているIPv4 over IPv6技術は、MAP-E,DS-Liteなどがあります。
ポート共有型NAPTはIPv6 IPoEだけではなく、モバイル網や、CATV環境でも行われており、課題の多くが共通しています。モバイル網や、CATVでは、IPv4枯渇対策としてCGNが採用されているケースが多く、このCGNでポート共有型NAPTが行われています。
IPv4 over IPv6技術：
IPv6シングルスタック上でIPv4トラフィックを転送する技術。VNEもしくはISPはこれを採用することで、ユーザーにIPv4とIPv6のデュアルスタック接続環境を提供します。
IPv6 IPoEサービスのネットワーク基盤であるNGNはIPv6オンリーネットワークですが、この上でIPv4 over IPv6技術を利用することで、ユーザーにIPv4とIPv6のデュアルスタック環境を提供できます。

DS-Lite：Dual-Stack Liteの略で、CGNによる44NAPTとIPv4 in IPv6 トンネルを組み合わせた技術です。ユーザー宅内側CPEをB4（Basic Bridging BroadBand）と呼び、CGNを行うセン
ター側装置をAFTR（Address Family Transition Router）と呼びます。
DS-Lite概要図：7

MAP-E：
MAP-EはMapping of Address and Port Encapsulationの略で、DS-Lite同様、IPv4 in
IPv6 トンネルを利用しますが、44 NAPTを行うのはユーザー宅内側CPEです。MAP-Eでは、CPEをMAP-E CE（Customer Edge）と呼び、センター装置をMAP-E BR（Border Router）と呼びます。
MAP-E概要図:

CGN：
IPv4プライベートアドレスをIPv4グローバルアドレスにNAPT（44NAPT）する技術です。国内ではモバイルキャリア、CATVなどで広く採用されています。
CGN（モバイル）概要図：

CGN（CATV）概要図：8

（１）接続性課題の解説
以下、ポート共有型NAPTにおけるゲーム、コンテンツアプリケーションの接続性課題について解説します。
課題①：ユーザー利用ポートの枯渇
ポート共有型NAPTでは複数ユーザーで共有するグローバルIPアドレスからユーザーにポートを割り当てて利用します。このユーザーに割り当てるポート数が利用上限に達し、そのユーザーが新たにポートを利用出来なくなる状況を、ここではポート枯渇と呼びます。
ポート枯渇時には、ユーザーが新規のTCP/UDP接続が出来ない事があり、ゲーム、コンテンツアプリケーションの利用に影響が出る可能性があります。
MAP-Eは、ユーザー毎に割り当てるポート数は初期の割り当て時に固定されます。これは、MAP-RuleというIPアドレス/ポートを固定で割り当てるルールをMAP-Eを提供するネットワーク全体（MAP Domain）に設定するためです。
MAP-Ruleに設定したユーザー毎の割り当てポート数が少ない場合、ポート枯渇が発生する可能性がありますが、一方で余裕を持たせ過ぎるとグローバルIPアドレスが多く必要になるためユーザーのポート利用予測を考慮し、MAP-Ruleでのユーザーポート数設定が行われています。
DS-LiteやCGNを採用した場合、ポート数を固定せず、その時点で利用可能なグローバルIPアドレスから空いているポートをユーザーへ割り当てることが可能ですが、そのままだと一部ユーザーがポートを大量消費してしまう可能性があるため、ユーザ単位で使用できるポート数に上限が設定されているようです。

9

DS-Lite/CGN：

MAP-E：

課題②：P2Pアプリケーションの透過性
ポート共有型NAPT環境では、一般的に外部からユーザーへの接続は行えないため、P2P接続を必要とするゲームなどでは接続できなくなります。これを可能にするため、NAPTを行う装置で透過性の高いEIM/EIF（またはFull-cone NAT）のNATタイプ動作を行わせた
り、アプリケーション側でSTUNなどの技術を使ったりします（STUNなどの技術は、一般的にUDPホールパンチングとも言われます）
EIM/EIF（Full-cone NAT）は、DS-LiteまたはCGNを採用している環境ではNAPTを行うセンター側装置で実装されています。MAP-E環境ではNAPTを行うHGWや、ホームルータの実装に依存します。EIM/EIFに対応していないHGWや、ホームルータの場合はアプリケーション側の対応が必要になる場合もあります。
DS-Lite/CGNにおけるEIM/EIFとSTUNの組みあわせ例：

課題③：UPnP依存アプリケーションの利用課題

10ポート共有型NAPT環境では、UPnPに依存するアプリケーションが動作しない場合もあります。アプリケーションはUPnPに依存しない実装を考慮する必要があります。
IPv4 over IPv6技術利用環境下でCPEルーターがUPnPを使用するための標準化（RFC8585）も存在しますが、CPE/クライアント実装共にまだ普及していないのが実情です。
特定のポートに依存しないアプリケーション開発が必要です。
課題④：セッションタイマー課題
NAPT装置のセッションタイマー設定よりもアプリケーションの無通信時間の方が長い場合、NAPT装置のセッションが先にタイムアウトして終了してしまい、通信影響が発生する可能性があります。一方で、セッションタイマーが長すぎると、アプリケーションで終了したセッションのポートを再利用するのに時間がかかり、より多くのポートを消費することでポート枯渇が発生しやすくなる可能性があります。そのため、単純にセッションタイマーを長くすれば解決するという問題でもありません。
これに対しては、アプリケーション側で定期的にポーリング通信を行い、セッションタイマーがタイムアウトしないようにする方法もあります。
MAP-E：
セッションタイマーはNAPTを行うMAP-E CE（CPEルータ）の実装に依存します。
DS-Lite：セッションタイマーはNAPTを行うセンター機器で設定します。
課題⑤：NATタイプによる接続課題
課題②とも関連しますが、NAPT装置間でのP2P接続の可否は相互のNATタイプに依存します。そして、アプリケーション側でSTUNなどの技術を使った場合でも、接続が出来ないパターンが存在します（アプリケーション側で対策しても難しいパターン）
片方がSymmetric NATで動作し、もう片方がPort―Restricted cone NATまたはSymmetric
NATで動作するパターンです。UPnPが動作すれば、この環境でも接続に問題はありません。
これに該当する可能性があるのは、MAP-E環境で、CE（CPEルータ）がSymmetric NATで動作し、UPnPが無効化されたPort―Restricted-cone NATまたはSymmetric NATで動作する
NAPT装置配下のユーザーとP2P接続する場合です。
DS-LiteまたはCGNではNAPTを行うセンター装置がEIM/EIF(Full-cone NAT)で動作するため、回避可能です（ただし、B4配下にホームルータが存在する場合には、このルータもEIM/EIFに対応している必要があります）
このMAP-Eのパターンは全体の割合からすると少数と考えられますが、影響を考慮しアプリケーション側の実装により対応することも可能です。P2Pで外部から新規接続を行わず、既に確立済みのNAPT内部からのUDPセッションに相乗りさせる形で再利​用する方法や（同一​UDPポートの組みあわせで既存のNAPTセッションをそのまま使う）、ゲートウェイ経由の接続にフォールバックさせる、等の方法です。

11

NATタイプの組み合わせによりP2P接続が懸念されるパターン：

補足：ポート共有型NAPT環境でポート開放が難しい理由
NAPTを行うルーターで、特定のポート割り当て（ポート指定でのNAPT）を行うことにより外部接続を可能にする方法がありますが、これをポート共有型NAPT環境で行う場合には注意が必要です。

DS-Lite/CGN：
NAPTを行うセンター装置で設定する必要があり、海外ではPCP(Port Control Protocol）で対処している事業者がありますが、国内ではありません。（2020年5月現在）
MAP-E：
NAPTを行うMAP-CE（CPEルータ）で設定を行いますが、MAP-E CEに割り当てられるポートはMAP-Ruleに従って複雑な計算方法となっており、ユーザーが類推することが難しくなっています。1部のMAP-Eのルータでは、管理画面で利用可能なポート番号が閲覧出来るものもあります。

12

MAP-Eのポート割り当て算出方法：（２）課題に関して解説している過去WGにおける講演「CGNにおけるポート消費の傾向について（過去の調査から）」
NTTコミュニケーションズ株式会社

西塚氏

過去のWG講演にて、ポート共有型NAPT環境における消費ポート数の傾向について、過去の調査結果と最新のアプリケーション、プロトコル動作の考察から予測される状況をNTT
コミュニケーションズ 西塚氏に解説いただきました。詳細は以下の資料をご参照下さい。
プレゼンテーションのリンク＜削除＞「NATのポートとセッション 今後の議論」
日本ネットワークイネイブラー株式会社

久保田氏

過去のWG講演にて、検証結果を交えながら、アプリケーションのセッションとNAPTにおける利用ポートの関係、ポート枯渇やNAPTセッションタイマーの課題に対する考察など、実例を交えて深い知見を共有いただきました。詳細は以下の資料をご参照下さい。
プレゼンテーションのリンク＜削除＞

2.3 IPv4 over IPv6技術の比較2.2で紹介したIPv4 over IPv6 技術ですが、IPv6 IPoEサービスを中心に日本国内で利用されています（MAP-E、DS-Liteなど）
それぞれに特徴があり、VNEまたはISPは自社サービスの状況（収容ユーザー数、IPv4グローバルアドレス保有数、既存ネットワーク運用との親和性など）を考慮し、自社のサービス環境に適した技術を採用しています。以下、参考として各技術の比較表を記載します（ここで比較している項目はあくまで一例です）

13

参考）IPv6移行技術の比較表：※ 同一ユーザ数で比較したIPv6移行技術の表です。提供事業者の設計によって変わります。

2.4

ゲーム事業者におけるIPv6対応の課題とコスト

ここまで挙げられた課題の解決方法として、IPv6対応は有効だ。
しかし、IPv6対応自体にも課題がないわけでない。
コンテンツ事業者のIPv6対応に関する議論はこれまでもされてきた。しかし、ゲーム事業者の特殊な事情を加味した議論はあまりされてこなかったため、それを中心に、現状見えている課題を纏めた。
(1) コンシューマー向けのハードウェアがIPv6に対応していない
そもそも、現在国内で大きなユーザ層を持つ家庭用ハード「Nintendo Switch」「PlayStation4」はIPv6に対応していない。
ゲーム開発対象としては同様に大きなシェアを持つ iOS/Android/Windows では対応が可能だが、上記の非対応の話が絡むと、ゲームコンテンツは下記の事情に苦悩する。
●●

同一タイトルが複数のプラットフォームで展開されている（ソースコード等の共有）ことが多く、クライアントサイド/サーバサイド共にIPv6対応の実装/検証が煩雑になる
複数のタイトルでインフラのセグメントが集約されているため、IPv4 onlyのタイトルでもIPv6対応に巻き込まれてコストが発生する(2) 長寿コンテンツの移行障壁
数年〜、ものによっては10年以上運用されているゲームコンテンツがある。
これらのうち多くは、IPv4 only 前提で書かれており、IPv6への対応が難しい。
また、単に難しいだけではなく、様々な理由でコンテンツそのものの "下回り/Network依存の実装が変更できない" 状況下にあることが多い。
そのため、事実上正攻法によるIPv6への対応は不可能と考えられる。
(3) IPV6対応/運用ノウハウの欠如
ゲームがIPv6で動くようになれば、商品としてIPv6対応のゲームを市場に出せるかというと、そうではない。
14

市場に出すためには、実際の開発現場以外に●●●●インフラの運用を行う部門
品質管理を行うQC部門
販売後のユーザサポートを行うカスタマーサポート部門
eSports運営スタッフ

等が、IPv6に対する理解をして、従来のIPv4のNetworkのデバッグ/トラブルシュート/サポートと同じことをIPv6でもできるようにならなければならない。
さらに、昨今問題になりやすい、デュアルスタック時特有の問題/デバッグ手法についても、同様に精通していなければならない。
(4) ゲームユーザのIPv6リテラシーの欠如
ゲームにおけるIPv6の問題はゲーム開発会社側の問題だけではない。
それを遊ぶユーザにも最低限のIPv6リテラシーがないと、問題が発生した場合に、意思疎通がとれない。
いまだにインターネット上のSNS等でみかけるゲームユーザの発言はIPv4ばかりだ。（
IPoEの話題で間接的にIPv6が挙がる事はあるが、ほとんどの場合で、それはIPv6のことではなく、共存技術のことを指している）
ここに自然とNative IPv6の概念が浸透する必要がある。

第３章 今後の方針
3.

方針概要

WGの今後の方針について記載いたします。
当WGでは、課題解決に向けた短期的対策と中長期的対策を推進するために議論を続けます。特にWGのアウトプットとして３月に開催を企画し、中止となりましたIPv6オンラインゲームハッカソンを２０２０年内に開催することを進めていきたいと考えます。
3.1

ゲームハッカソン

WGでは継続的にIPv6オンラインゲームにフォーカスしたゲームハッカソンを実施することで、コンテンツのIPv6化促進に貢献することを期待します。
第一回IPv6ゲームハッカソン資料

15

3.2

中長期課題

・コンテンツベンダかV6推進に踏み切れる客観的データ収集
・ポート消費量の計測・V6化に必要なコスト試算
・アドレスコスト
・機器購入コスト・V6化によるメリット
・P2PゲームのIPv6移行（IPoE接続においてIPv6移行技術不要の接続可能化）
・ゲーム会社に於いてV6化を進めるに値するデータの整備協調提案など
・ネイティブIPv6におけるUPnPの実装
・あるべき姿の議論など
・IPv6技術者の養成と教育方針
・大学や他の団体との協調
3.3

短期課題

・用語の統一・ポート開放・NAT Type 判定の標準化
・ゲーム業界特有の用語統一
・業界横断したサポートセンターの情報共有・ルーターのIPoE（+IPv6移行技術）環境でのUPnPの適切な実装
・すでにルータベンダ、VNE各社の短期的対応
・ユーザーに分かりやすいNAT判定ツール

16

第４章 ワークグループ活動内容

4.
開催履歴
これまでの振り返りとしてWG各回の内容を記載します。
表 1 WG進行マイルストーン

4.1
第１回目
開催日時：２０１９年８月１日（木）開催場所：A10ネットワークス株式会社
参加人数：２９社 ５１名＜開催内容＞
・WG設立の趣旨説明
・ゴールの設定と目標の共有
4.2
第２回目
開催日時：２０１９年９月１０日（火）開催場所：株式会社コナミデジタルエンタテインメント
参加人数：４０社 ６５名＜開催内容＞
意見交換①​ ゲームのネットワーク環境別検証の課題
・ 構成員プレゼンテーションa「オンラインゲームのネットワーク検証の考え方と検証フロー事例」（ｺﾅﾐﾃﾞｼﾞﾀﾙｴﾝﾀﾃｲﾒﾝﾄ佐藤元彦）
・ 構成員プレゼンテーションb「IPv4 over IPv6接続オプションを含むv6コネクトのリリース」（朝日ネット関本義久）
意見交換②​ NAT越えに起因する課題の分析・対策検討
・ 構成員プレゼンテーションc「IPv6移行技術に起因するゲーム関連の問合せ事例ご紹17介」（NECプラットフォームズ川島正伸）

・ 構成員プレゼンテーションd「パナソニックのP2Pの取り組みと課題」（パナソニック前川肇）
意見交換③​ ポート枯渇に起因する課題の分析・対策検討
・ 構成員プレゼンテーションe「CGNにおけるポート消費の傾向について（過去の調査から）」（NTTコミュニケーションズ西塚要）

4.3
第３回目
開催日時：２０１９年１０月１１日（金）開催場所：NTTインターコミュニケーションセンター
参加人数：２７社 ４０名＜開催内容＞
急遽ご登壇
・ NATのポートとセッション 今後の議論（JPNE久保田氏）
意見交換① ​NATセッションタイマー課題分析・対策検討
・ 構成員プレゼンテーションa「家庭用ルーターでのNATセッションタイムアウトと通信障害について」（アイ・オー・データ機器事業戦略本部田畑啓司）
意見交換② ​クラウドゲームのレイテンシ課題分析・対策検討
・ 構成員プレゼンテーションb「クラウドゲーミングにおけるネットワークの位置づけと今後の課題」（ソフトバンク先端技術開発本部堀場勝広）

4.4
第４回目
開催日時：２０１９年１１月２２日（金）開催場所：フクラシア品川クリスタルスクエア
参加人数：２８社 ３６名＜開催内容＞
意見交換①​ 抜本的課題対策としてのP2PゲームのIPv6化の実現性
・ 構成員プレゼンテーションa「ゲームのIPv6化に向けたNGNのIPv6状況について」
NTT東日本 設備企画部 ネットワーク高度化部門 田中一直氏
・ 構成員プレゼンテーションb「64SLBによるコンテンツのIPv6対応」 A10ネットワー
クス パートナーSE部 真野桐郎氏（WG副主査）
・ 構成員プレゼンテーションc「ゲームにおけるIPv4の品質変化と対策事例 〜 現実的なIPv6対応の考え方 〜」コナミデジタルエンタテインメント 技術開発部 佐藤元彦氏（WG副主査）
4.5
第５回目
開催日時：２０１９年１２月１７日（火）開催場所：株式会社NTTぷらら
参加人数：２７社 ４３名＜開催内容＞
意見交換①​ 抜本的課題対策としてのP2PゲームのIPv6化の実現性
・ 構成員プレゼンテーションa「IPv6ハッカソン企画」松本主査
・ 構成員プレゼンテーションb「誰でも使えるサーバーサイドOpen NAT64実証実験」
NTTコミュニケーションズ技術開発部西塚氏
意見交換②​ 5Gとゲームの接続性
・ 構成員プレゼンテーションc「5G時代のゲームの接続性について」NTTドコモコン
シューマビジネス推進部宮坂氏
4.6
第６回目
開催日時：２０２０年１月１７日（金）開催場所：株式会社NTTインターコミュニケーションセンター
参加人数：２７社 ３５名＜開催内容＞
意見交換①​ 抜本的課題対策としてのP2PゲームのIPv6化の実現性
・ 構成員プレゼンテーションa「IPv6クライアントOS実装説明」NECプラットフォーム
ズ川島氏（副主査）※IPv6 Technical Summit 2019での北口先生（東工大）の資料を代理でプレゼン
・ ゲーム事業者IPv6パネルディスカッション（IPv6ハッカソンに向けての前準備）コ18

ナミデジタルエンタテインメント佐藤氏（副主査）

・ 構成員プレゼンテーションb「OpenNATへの参加のご案内」 A10ネットワークス真野氏（副主査）
IPv6ハッカソン検討・ 日時・会場：2020年3月6日（金）（会場品川シーサイドビッグローブ社オフィス）・ 募集方法：Compass等・必要なアドバイザリー募集（「インフラ/環境構築」「エンジニアリング（クライアント）」「エンジニアリング（サーバ）」

4.7
第７回目
開催日時：２０２０年２月１４日（金）開催場所：株式会社セガゲームス
参加人数：２３社 ３２名＜開催内容＞
意見交換① ​ISPから見たクラウドゲーミング
・ 構成員プレゼンテーション ISPから見たクラウドゲーミングと今のゲーミング
ビッグローブ株式会社 平澤庄次郎氏
IPv6ハッカソン中止の経緯
・ 中止の経緯と企画概要振り返り 株式会社NTTぷらら 丹羽健吾氏、ビッグローブ株
式会社 平澤庄次郎氏
4.8
Slack
WGで運用しているSlack登録者は176名。
情報交換、資料の公開などに利用している
4.9

その他

イベント参加：２０１９年１１月２５日にInternet Week 2019と併設で開催されたIPv6
Summit in Tokyoのパネル討論「IPv4 Sunset に向けて〜もうIPv4に手を入れるのはやめようよ〜」に松本が当WGの立場でパネラーとして参加しました。

19

第５章 参考資料
５．過去プレゼンテーション
この章は資料開示にあたり削除しております。
ご了承ください。
以上

20