A Detailed Guide to the v6plus
byAkimichi Ogawa and Satoshi Kubota

本書は「著作権法」によって権利が保護されている著作物です。
本書中の会社名や製品名は該当する各社の商標または登録商標です。

「v6 プラス」は、NTT フレッツ網を利用するユーザが、IPv6 とともに、IPv6 IPoE を経由して IPv4 インターネットとの通信ができるサービスです。IPv6 IPoE を経由する
ことで、IPv4 PPPoE を経由せずに IPv4 インターネットとの通信を行うため、ユーザのパケットが通る経路が変わります。この経路の違いが通信品質に大きな影響を与える場合もあります。
本書はもともと、v6 プラスの技術的側面を解説する書籍として、JPNE†1 のニーズを受けて企画がスタートしたものです。企画段階で目指したのは、対象読者として
v6 プラス導入を検討している方々、v6 プラスの技術に興味がある方々、ISP 関係者の方々を想定し、インターネットの仕組みからボトムアップに v6 プラスの全体像を解説していくような内容でした。しかし、文章を書き進めるにつれ、「何ができるのか？」「どうしてそうなっているのか？」「どうしてそのようなサービス設計になったのか？」という部分こそが、こうした対象読者の方々にとって大事なのではないかと考え始めました。その結果、技術的な背景の説明に焦点を当てることこそが誤読による誤解を避ける手助けとなるはずであり、またすでに誤解してしまっている方々の誤解を解くきっかけとなるだろうという結論に至りました。
本書ではまず、v6 プラスがどのようなサービスであり、何ができるのか、あるいは何ができないのかを説明します。そのうえで後半では、それらに対する「なぜ」の部
分を技術的視点で読み解けるように、背景知識を説明していく構成としています。
v6 プラスはフレッツ網という環境に特化したサービスです。高度な技術的課題をユーザ向けのサービスとするために、基礎技術の積み重ねへと落とし込んで実現されています。ネットワーク、インターネット、TCP/IP という視点で考えたとき、v6 プラスは応用の応用ぐらいのレベル感の話題だといえます。したがって、その内容を読み解くためのハードルは決して低くはありません。それでもサービスの使い方に留ま†1

v6 プラスは JPNE（日本ネットワークイネーブラー株式会社）のサービスとして始まりました。JPNE

は 2023 年 1 月に日本インターネットエクスチェンジ株式会社と合併して株式会社 JPIX になってい
ます。

iv

はじめに

らない書籍、サービスの設計思想が垣間見えるような書籍になることを目指しました。その試みが成功していることを祈ります。

小川晃通2020 年 1 月

刊行 寄
v6 プラスとは、IPv6 上で IPv4 サービスへの接続性（IPv4 over IPv6）を提供する、
JPNE による商用サービスの名称です。この名前は世間的な認知を得るようになりま

したが、その結果として、IPv4 over IPv6 全体を指す名称と勘違いされてしまう場面も見聞きするようになりました。IPv4 over IPv6 には複数の実現技術があり、それぞれに長所短所があり、国内においても複数の方式が採用されていることから、それらがひとくくりに「v6 プラス」と称されることは、今後の発展に向けての動向を見誤る
ことにつながりかねません。
本書は、v6 プラスについての技術的な解説を行う唯一無二の書籍です。その内容は、著者の一人である小川晃通氏の既刊書と同じく、わかりやすさを心がけつつ、技
術的正確性を犠牲にしないという立場を貫いたものとなりました。本書が日本のインターネットの健全な発展に寄与するものとなることを期待します。

日本ネットワークイネイブラー株式会社 代表取締役社長（刊行当時）
石田慶樹
2020 年 1 月

［書籍版では空白のページです］

目次

はじめに

iii

刊行に寄せてv

第1章

1v6 プラスとは

1.1 v6 プラスの背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2 v6 プラスの全体像 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.3 本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

第2章

IPv4 と IPv6

13

2.1 IPv4 アドレス在庫枯渇問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 IPv6 アドレスの基礎 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 インターネットは IPv4 と IPv6 のデュアルスタック . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 キャッシュ DNS サーバと CDN による通信効率の低下 . . . . . . . . . . . . . . . . . . . . . . . 21

第3章

フレッツ網からの IPv6 インターネット接続（IPv6 IPoE）

25

3.1 IPv6 IPoE 方式と IPv6 PPPoE 方式がある背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 IPv6 IPoE 方式と IPv6 PPPoE 方式の違い . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 IPv6 PPPoE 方式の詳細 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 IPv6 IPoE 方式の詳細 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

viii

目次

第4章

MAP-E による IPv4 インターネット接続

37

4.1 IP トンネル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 MAP 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 PSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 MAP ドメインで使う IPv6 アドレス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5 MAP ルール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.6 MAP における IPv4 NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

第5章

IPv4 NAT

47

5.1 一般の NAT の背景と仕組み . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2 いわゆる「NAT 越え」 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3 NAT 機器に要求される挙動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4 大規模な NAT（CGN）とその課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

第6章

v6 プラス詳解81

6.1 通信までの一般的シーケンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.2 ひかり電話の有無で変わる IPv6 ネットワーク構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.3 「v6 プラス」固定 IP サービス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

第7章

エンドユーザ側の必要条件と設定

91

7.1 v6 プラスの利用条件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.2 v6 プラス IPv4 設定ソフトウェア . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

第8章

FAQ とトラブルシューティング

97

8.1 v6 プラスへの申し込み . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.2 v6 プラスがつながらない？ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
8.3 アプリケーションの通信ができない？ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.4 ユーザ側の機器に問題はないか . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.5 問題の切り分けと確認 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

目次

第9章

DS-Lite と A+P

105

9.1 DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.2 A+P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

索引

111

ix

x

更新履歴

更新履歴
各刷における主な修正点および追加点は下記のとおり。その他の変更点に関しては
ラムダノートの Web サイト（https://www.lambdanote.com）の本書のページを参照してください。
■ 第 1 版第 2 刷（2021 年 3 月）

r いわゆる「NAT 越え」の詳細を加筆（第 5 章）
r 固定 IPv4 アドレスサービスについて加筆（第 6 章）
r 対応機器の情報を更新（第 7 章）

■ 第 1 版第 3 刷（2023 年 1 月）

r 合併に伴う JPNE から JPIX への社名変更に対応

第1章

v6 プラスとは

本章の目的は、v6 プラスの全体像が見渡せるような地図を作ることです。v6 プラ
スは、インターネットや国内のネットワーク環境の複雑な背景を前提として誕生したサービスであることから、その概要を知るだけでもさまざまな要素の理解が必要になります。詳細な説明については個別の章で後から解説することとし、本章では v6 プ
ラスをめぐる全体像を示すことにします。

1.1 v6 プラスの背景
v6 プラスの「v6」は、IPv6（インターネットプロトコルバージョン 6）の「v6」です。v6 プラスがどのようなサービスであるかを知るには、まず「IPv6 とは何であるか」を説明しなければなりません。

1.1.1 IPv4 と IPv6
どのようなデータをどのような方法で送受信するかについての取り決めのことを、プロトコル（protocol）と呼びます。特にインターネットでの通信を実現するためのデータ形式や手順などを取り決めたものが、インターネットプロトコル、すなわち IP（Internet Protocol）です。
現在のインターネットでは、IPv4 と IPv6 という、2 種類の異なる方式の IP が利用されています。言い換えると、現在の世界には、IPv4 を使って構築されている IPv4 イ
ンターネットと、IPv6 を使って構築されている IPv6 インターネットという、互いに異なる方式の 2 種類のインターネットが存在しています。
世界中で使われている現在のインターネットは、IPv4 を利用して普及しました。
IPv4 では、通信の相手やネットワークの範囲を特定するための識別子（IP アドレス）

2

第1章

v6 プラスとはの総数が、およそ 43 億（232 ）個と規定されています。この総数は、現在のインターネットを利用する端末の数に比べると少なすぎます。そこで、アドレスの総数を 2128
個に増やし、それをユーザに効率的に割り当てるような方式として、IPv6 が開発されました。
IPv6 は、IPv4 に比べてアドレスの総数が多いだけでなく、さまざまな点で IPv4 と異なります。そのため、従来の IPv4 との間には直接的な互換性がありません。IPv4 とIPv6 は、似て非なる独立した別々のプロトコルなのです。従来の IPv4 インターネッ

トでアドレスだけを IPv6 のそれに置き換えればそのまま IPv6 を利用できる、という
わけにはいきません。IPv6 に対応するインターネットを新たに整備し、それと従来のインターネットをうまく共存させる仕組みが必要になります。
結果として、IPv4 インターネットと IPv6 インターネットが共存しているのが現在のインターネットの状況というわけです。個々のプロトコルの理解に加えて、これら
IPv4 インターネットと IPv6 インターネットの共存にかかわる仕組みの理解は、v6 プラスに限らず現在のインターネットをめぐる環境を理解するうえでは欠かせないものになっています。

NOTE
IPv6 と IPv4 については、「第 2 章 IPv4 と IPv6」で改めて詳しく説明します。

1.1.2 フレッツ網と VNE
日本においては、ある特別な事情によって、さらに複雑な状況が生まれています。
それは、インターネット接続の入り口として多くのユーザが利用している NTT 東西†1のフレッツ網です。フレッツ網は、歴史的経緯により、いくつかの通信方式が混在したネットワークです。2021 年 2 月現在、一般ユーザが新規申し込みを行って提供されるサービスは、NTT 東西が IPv6 を使って構築した通信網である NTT NGN（次世代ネットワーク、Next Generation Network）によるものです。
NTT NGN は、IPv6 インターネットとは切り離された巨大な IPv6 ネットワーク（IPv6 閉域網）です。同じ IPv6 を利用しながら、フレッツ網が IPv6 インターネットと切り離された閉域網になっている背景には、NTT 法という法律の存在があります。
NTT 法による制限により、NTT 東西はユーザに対して直接インターネット接続サービスを提供できないので、フレッツ網は IPv6 インターネットとは直接やり取りがで†1

本書では、東日本電信電話株式会社のことを「NTT 東日本」、西日本電信電話株式会社のことを「NTT 西日本」と表記しています。また、両者を合わせて「NTT 東西」と表記することがあります。

1.1 v6 プラスの背景

きないような設計になっているのです。
では、NTT 東西と接続してフレッツ網のサービスに加入しているユーザは、どのよ
うにしてインターネットへの接続を実現しているのでしょうか。
従来の IPv4 インターネットへの接続については、ユーザが ISP 事業者と契約し、ISP事業者を通じてインターネットへと接続しています。その際には、一般に「PPPoE」という技術を使い、間のフレッツ網をトンネリングして IPv4 による通信を実現しています（図 1.1）。

契約
IPv4
アドレス

家庭内ネットワーク

フレッツ網（IPv6閉域網）

ISP

IPv4インターネット▲

図 1.1 フレッツ網を通じた IPv4 インターネット接続

IPv6 インターネットとの接続サービスについては、フレッツ網でどのように提供すべきかについて、2008 年ごろから日本国内で議論されました。NTT 東西の次世代
ネットワーク（後のフレッツ・ネクスト）を利用した商用サービスに関する活用業務の認可申請が 2007 年に行われ、意見募集等のプロセスを経て翌年認可されたことが背景としてあります。日本国内で非常に大きなシェアがある NTT 東西の回線において、IPv6 インターネット接続サービスがどのような方式で提供されるのかは、日本の IPv6 インターネットの形を左右するテーマでした。そのため、NTT NGN におけるIPv6 インターネット接続サービスをどのように提供すべきかの議論が白熱しました。

当時、さまざまな案が検討されましたが、従来の IPv4 インターネットへの接続方式と類似した方式である「IPv6 PPPoE」を含め 4 つの案にまで絞られました。そのうちのひとつとして、従来とは異なる「IPv6 IPoE」という方式もありました。最終的に認可されたのは、IPv6 PPPoE と IPv6 IPoE という 2 つの方式です。
IPv6 IPoE には、IPv6 PPPoE と違い、ISP 事業者が IPv6 による通信データを直接扱

わないという特徴があります。NTT 東西と契約して IPv6 IPoE によるインターネット
接続を提供するのは、VNE（Virtual Network Enabler）と呼ばれる事業者です。ISP
事業者は、VNE から IPv6 IPoE インターネット接続サービスの卸提供を受けて、自社のユーザに対してこれを自社のサービスとして提供します（図 1.2）
。

3

4

第1章

v6 プラスとは

ISP

契約

契約
IPv6
アドレス

家庭内ネットワーク

フレッツ網（IPv6閉域網）

VNE

IPv6インターネット▲

図 1.2 フレッツ網で IPv6 IPoE サービスを提供する VNE■ JPIX による VNE 事業
2008 年時点では、技術的な制限により IPv6 IPoE 方式を利用可能な事業者数は 3 者に限定されていました†2 。当時、候補となった事業者から 3 者を選ぶ方法として NTT
東西が提案し総務省も認めたものが、「卸サービスとして利用する ISP の FTTH サービスのエンドユーザの総数を比較し、上位 3 者を選択する」という方法でした。
2009 年 12 月の IPv6 IPoE 方式のサービス開始時点に、NTT 東西から VNE として選定された 3 者は、BBIX 株式会社、インターネットマルチフィード株式会社、日本イン
ターネットエクスチェンジ株式会社（以後 JPIX）でした。BBIX はソフトバンク、インターネットマルチフィードは NTT、JPIX は KDDI の系列会社であり、日本国内の大手
3 キャリアで 3 つの枠を分け合っていた格好です。

その後、2010 年 2 月に KDDI と JPIX が「ブロードバンドアクセスエクスチェンジ
企画株式会社」を設立しました。そして 2010 年 8 月、ISP 4 社の出資により、事業会社として「日本ネットワークイネイブラー株式会社」（JPNE）を発足し、JPIX から
VNE 事業に関する契約と、VNE 事業のために取得した IPv6 アドレスなどを継承しました。JPNE が IPv6 IPoE サービスを ISP に卸提供開始したのは、発足から約 11 ヶ月後の 2011 年 7 月です†3 。v6 プラスも JPNE によって提供されていましたが、2023 年 1†22008 年段階では IPv6 IPoE 方式を利用可能な事業者数は 3 でしたが、その後は最大で 16 の事業者まで増やせるような方向で検討が進められました。現在では VNE の数も当初の 3 者から増えています。
†3

http://www.jpne.co.jp/2011/07/26/242/

1.2 v6 プラスの全体像

月 1 日には JPIX と JPNE が合併して株式会社 JPIX†4 となり、VNE 事業を継承していま
す†5 。

NOTE

フレッツ網と VNE については、「第 3 章 フレッツ網からの IPv6 インターネット接続（IPv6 IPoE）」で改めて詳しく説明します。

1.2 v6 プラスの全体像
前節では、IPv4 アドレスの枯渇と IPv6 の開発、フレッツ網という IPv6 閉域網、さらにその上で IPv6 IPoE により IPv6 インターネット接続を提供する VNE について簡単に説明してきました。これでようやく本書の主題である v6 プラスが何のためのサービスであるかを説明できます。
まずは、v6 プラスという名前の由来を説明します。v6 プラスは、IPv6 にプラスして IPv4 も使えるという意図の名称です。IPv6 をプラスで使えるという意図であると誤解されがちなのですが、逆なのです。
すなわち v6 プラスは、JPIX が VNE 事業として提供する IPv6 IPoE のインターネッ
ト接続サービスにプラスして、IPv4 インターネットへの接続サービスも使えるというサービスです。IPv6 IPoE でのサービスを提供する VNE として JPNE という企業が設立され、JPIX として IPv6 IPoE サービスが提供され続けるなかで、v6 プラスというサービスが後から生まれたという歴史的経緯が垣間見えるネーミングでもあります。
では、v6 プラスを利用したときにユーザのトラフィックがどうなるのかをひとつずつ見ていきましょう。まずは IPv6 トラフィックです（図 1.3）。
v6 プラスでの IPv6 サービスは、JPIX を VNE とした通常の IPv6 IPoE です。フレッ

ツ網を通じてユーザトラフィックが JPIX へと転送され、JPIX を通じて IPv6 インターネットと接続します。しかし、実はこれだけでは v6 プラスの機能の半分も説明できていません。v6 プラスは、IPv4 インターネットへの接続性をプラスするというサービスなのですから。

†4

この新しい JPIX は略称ではなく正式な社名（英文表記 “Japan Internet Xing Co., Ltd.”、読み方は「ジャパン・インターネット・クロッシング」）です。
†5

https://www.jpne.co.jp/2022/12/07/2638/

5

6

第1章

v6 プラスとは

IPv6
アドレス

CPE

家庭内ネットワーク

フレッツ網（IPv6閉域網）

JPIX

IPv6インターネット▲

図 1.3 v6 プラスでの IPv6 インターネット接続

1.2.1 IPv6 トンネルによる IPv4 インターネット接続サービス
フレッツ光ネクストなど、フレッツ網を利用したサービスを契約しているエンド
ユーザの宅内には、ホームゲートウェイなどの CPE（Customer Premises Equipment）
が設置されています。v6 プラスでは、図 1.4 のように、すでに家庭内ネットワークなどに設置されている CPE と JPIX のネットワークに設置された BR（Border Relay）と呼ばれる装置との間で IPv6 トンネルを構築し、JPIX を通じて家庭内の IPv4 ネット
ワークを IPv4 インターネットへと接続します。

IPv4
アドレス

MAP-E対応
Border Relay

CPE

IPv6トンネル

家庭内ネットワーク

フレッツ網（IPv6閉域網）

▲

図 1.4

JPIX

IPv4インターネット

v6 プラスによる IPv6 トンネル

v6 プラスで IPv4 パケットを運ぶ IPv6 トンネルには、MAP-E という方式が採用され

ています。

NOTE
MAP-E については、「第 4 章 MAP-E による IPv4 インターネット接続」で詳しく説明します。

1.2 v6 プラスの全体像

MAP-E の特徴のひとつとして、複数の CPE で同一の IPv4 アドレスを共有することが挙げられます。これにより ISP では効率よく IPv4 アドレスを利用できます（図 1.5）。
CPE 間での IPv4 アドレスの共有に使われているのは、IPv4 アドレスを変換する
NAT（Network Address Translation）の技術です。NAT そのものは新しい技術ではなく、1990 年代から通常の家庭内ネットワークなどでも広く使われてきました。
MAP-E における NAT は、複数の契約にわたって 1 つの IPv4 アドレスを共有するという違いはありますが、通常の家庭で利用されてきた IPv4 NAT と根本的な技術は同じです。MAP-E の特徴を理解するうえでは IPv4 NAT に関連する技術の理解も必要に
なります。

NOTE
NAT そのものについては、「第 5 章 IPv4 NAT」で詳しく解説します。

IPv4アドレス
CPE

MAP-E対応
Border Relay

NAT
IPv4アドレス
IPv6トンネル
IPv4アドレス
CPE

IPv4インターネット
JPIX

NAT
IPv4アドレスフレッツ網（IPv6閉域網）

家庭内ネットワーク

▲

図 1.5

v6 プラスにおける IPv4 NAT

MAP-E で NAT が利用されているからか、「v6 プラスを利用すると対戦ゲームに悪影響がある」という意見も耳にします。しかし、同様の問題は通常の家庭用 NAT でも発生する場合もあるため、v6 プラスで利用される MAP-E だけが原因で発生するわけではありません。
なお v6 プラスには、MAP-E による IPv4 アドレス共有サービスのほかに、通常の IP

7

8

第1章

v6 プラスとはトンネルによってユーザに対して固定 IPv4 アドレスを割り当てるサービスもあります。どちらも v6 プラスという名称ですが、その実現技術は異なり、固定 IPv4 アドレ
スサービスのほうでは 1、8、16、32、64 個の固定 IPv4 アドレスを占有できます。固定 IPv4 アドレスでの v6 プラスについては 6.3.1 項で説明します。

1.2.2 v6 プラス利用時の IPv6 トラフィック
v6 プラスを利用する ISP のユーザは、JPIX を VNE とした IPv6 IPoE サービスを利用することになります。そのため、ユーザの IPv6 パケットはフレッツ網を通じて VNE
である JPIX へと転送され、そのまま IPv6 インターネットとの通信が実現します（図
1.6）
。

IPv6
アドレス

CPE

家庭内ネットワーク

フレッツ網（IPv6閉域網）

JPIX

IPv6インターネット▲

図 1.6 v6 プラスでの IPv6 インターネット接続（再掲）

この場合、ユーザの家庭内で利用される IPv6 アドレスは、JPIX に割り振りされたグ
ローバル IPv6 アドレスのプレフィックスから割り当てられます。したがって、ユー
ザが IPv6 を利用して IPv6 インターネットと通信するとき、ユーザの家庭内も含めてすべてがグローバル IPv6 アドレスによる IPv6 インターネットに含まれます。ユーザの家庭内もグローバル IPv6 アドレスによる IPv6 インターネットの一部になるのです。
（JPIX は BGP によって IPv6 インターネットとつながっているため、JPIX も IPv6 イン
ターネットの一部であるともいえます。
）

NOTE
JPIX は B2B 企業なので、消費者に対して直接インターネット接続サービスを提供しているわけではありません。ただし、JPIX では、ISP が v6 プラスという名称を利用して一般消費者（エンドユーザ）に対して販売することを許可しています。このため、個々のISP が提供するサービスに、メニューとして v6 プラスという名称が掲載されることがあ1.2 v6 プラスの全体像

ります。エンドユーザから見ると、JPIX が提供するサービスをその ISP が提供しているような形になります。
そして、このような事業形態が、v6 プラスという名称に多少のわかりにくさを発生させている要因かもしれません。v6 プラスという名称は、IPv6 IPoE にプラスして IPv4 イ
ンターネットへの接続性を提供しているという意味ですが、IPv6 IPoE と IPv4 サービスの両方を含めて「v6 プラス」なのか、それとも IPv6 IPoE に対するオプションサービス
として「v6 プラス」が存在しているのか、エンドユーザに対してサービスを販売している ISP によって、そのサービスメニューの見え方に多少の違いがあります。
JPIX をはじめとする VNE は、エンドユーザにとっては黒子のような存在といえます。
VNE に関しては、フレッツ網に関連する解説を行っている第 3 章で解説します。

1.2.3 v6 プラスで IPv6 と IPv4 の両方を VNE 経由に
v6 プラスのポイントは、フレッツ網を利用したサービスからのインターネット接続

で IPv4 のための経路を別に用意することなく、IPv6 パケットが運ばれる経路で IPv4
パケットも運ばれる点です。図 1.7 のように、IPv4 パケットは IPv6 トンネルを通じてJPIX へと運ばれ、IPv4 と IPv6 の両方が JPIX を通じてインターネットへと運ばれるよ

うになります。

IPv4インターネット

IPv6トンネル
IPv4アドレス

CPE

MAP-E対応
Border Relay

IPv6アドレス家庭内ネットワーク
フレッツ網（IPv6閉域網）

JPIX

IPv6インターネット▲

図 1.7 v6 プラスを利用する場合

次の 1.2.4 項で触れるように、v6 プラスが使われていない状態では、IPv6 パケッ
トと IPv4 パケットがまったく異なる経路を通じてそれぞれインターネットへと運ばれることになります。JPIX という同じ組織を通じて IPv4 インターネットと IPv6 イン
ターネットに接続できることから、両者の経路が異なる場合に発生する CDN などに

9

10

第1章

v6 プラスとは関連した性能低下を回避できる可能性があります（2.4 節を参照）。

1.2.4 v6 プラスを利用しない場合の IPv4 トラフィック
フレッツ網で直接 IPv4 インターネットに接続するためのサービスとしては、IPv4
PPPoE を利用する以外の方法はありません。

ここまでの説明を注意深く読んだ読者のなかには、これを聞いて、「あれ、v6 プラ
スではフレッツ網で IPv4 インターネットへの接続が提供されるのではないか」と思った方もいるでしょう。v6 プラスは、フレッツ網で直接 IPv4 インターネット接続を提供するサービスではなく、あくまでもフレッツ網での IPv6 インターネット接続サービスを通じて IPv4 インターネットとの通信を行うサービスなのです。
IPv4 の PPPoE で IPv4 インターネット接続サービスを利用しつつ、IPv6 IPoE による
IPv6 インターネット接続サービスを利用する場合の典型的なトラフィックを図 1.8 に示します。IPv6 は VNE（JPIX）を通じて、IPv4 は ISP を通じてインターネットと通信します。

ISP（IPv4）

IPv4インターネット

IPv4網終端装置

PPPoEトンネル
IPv4アドレスCPE

IPv6アドレス家庭内ネットワーク
フレッツ網（IPv6閉域網）

JPIX

IPv6インターネット▲

図 1.8 IPv4 PPPoE と IPv6 IPoE を同時に利用する場合 (v6 プラスを利用しない場合 )v6 プラスを利用する場合には、IPv4 インターネットとの接続に IPv4 PPPoE を使う必要がなくなります。そのため、IPv4 PPPoE に関連する原因で途中のネットワーク
における通信性能が出ない場合などに、IPv4 での通信性能が向上する可能性があります。

1.3 本章のまとめ

1.3 本章のまとめ
本章では v6 プラスの概要を紹介しました。きちんと定義を与えていない技術用語もいくつか使いましたが、それらは次章以降で順番に解説していきます。
本章で見たように、v6 プラスを説明するには、「IPv6 とは何か」、「MAP-E によるネットワークのトンネルとは」、「IPv4 NAT とは」といった個別の技術的な疑問に答えると同時に、「なぜフレッツ網に限定される話なのか」といった日本のインターネッ
ト環境の歴史にまでさかのぼる知見が必要になります。v6 プラスというサービスは、
TCP/IP というインターネットの仕組みの基礎から見ると、応用のさらにまた応用のようなレベル感の内容だといえるかもしれません。
v6 プラスは、IPv6 をめぐる日本のネットワーク事情から生まれたサービスであることからわかるように、そもそもの動機からして理解に必要な前提知識が多いサービスです。たとえば、IPv6 ネットワーク上で IPv4 インターネットとの接続を実現するた
めに IPv4 パケットをトンネルさせている理由、さらに、そのための技術として MAP-Eが採用された理由を知るためには、IPv4 アドレスとポート番号を変換する NAT の技術に対する深い理解まで求められます。次章以降では、こうした一つひとつの「なぜ」を紐解いていきながら、さらに深く v6 プラスを紹介していきます。

11［書籍版では空白のページです］

第2章

IPv4 と IPv6v6 プラスを知るうえでまず必要なのは、IPv4 と IPv6 の現状に対する正しい認識です。よく知られているように、IPv6 は「IPv4 アドレス在庫枯渇問題」を背景に開発されたプロトコルです。そこで本章では、まずこの IPv4 アドレス在庫枯渇問題が何であったのかを説明します。そのうえで IPv4 と IPv6 の違いと、現在のインターネット
で両者がどのように使われているのかを説明します。
なお、v6 プラスの設計の背景には、日本の多くの家庭などでインターネット接続の入り口として利用されているフレッツ網という IPv6 ネットワークの事情も大きく関与しています。フレッツ網をめぐる事情については、章を改めて、次章以降で順次説明していきます。

2.1 IPv4 アドレス在庫枯渇問題
インターネットでは、IP アドレスで示される宛先へとパケットが届けられます。すべてのパケットのヘッダには、そのパケットが送り届けられる「宛先 IP アドレス」と、そのパケットを送信した「送信元 IP アドレス」が記載されています。
その IP アドレスが足りなくなってしまったのが IPv4 アドレス在庫枯渇問題です。
これはすでに現実に起きている問題であり、2011 年には、インターネットの誕生からずっと使われている IPv4 アドレスの中央在庫は枯渇しています。
IPv4 アドレスの在庫が枯渇すると何が起こるのでしょうか。ものすごく単純に言えば、IPv4 によるインターネットがこれ以上は拡大しにくくなります。
図 2.1 を見てください。かつてのインターネットでは、新規にインターネットに参加したい人や法人がいた場合、そのたびに新しい IPv4 アドレスを割り当てていました。参加者が増えるぶんだけ新しく IPv4 アドレスの割り当てが可能な状態だったの

14

第2章

IPv4 と IPv6です。これが「IPv4 アドレスの在庫がある」状態です。IPv4 インターネットは、IPv4
アドレスの在庫という資源に制約されることなく、どんどん拡大できました。
IPアドレス在庫

IPアドレス在庫

IP アドレスを使いたい▲

図 2.1 IPv4 アドレス在庫枯渇前の状態

ところが IPv4 アドレスの在庫が枯渇すると、新しく参加したい人が現れても、限られた IPv4 アドレスの範囲内で対処しなければならなくなります。限られたアドレス
空間に、次々と新しい参加者を詰め込んでいく状態です。こうなると、図 2.2 のように、参加者あたりで利用できる IPv4 アドレス数が減ってしまいます。IPv4 アドレス
在庫枯渇によって発生する状態は、この「詰め込み度合い」の上昇です。
IPアドレス在庫（枯渇）IPアドレス在庫（枯渇）IP アドレスを使いたい

▲

図 2.2

IPv4 アドレス在庫枯渇後の状態

この問題への暫定的な対策として従来からインターネットで広く採用されているのは、プライベート IP アドレスと NAT による「詰め込み度合い」の上昇の制御です。
実際、現在のインターネットでは、家庭内や企業などの多くでプライベート IP アドレスと NAT が利用されています。さらに、ISP などのサービス事業者のネットワークで大規模な NAT が利用されることもあります。NAT に関しては、第 5 章でやや詳しく説明します。
一方、IPv4 アドレス在庫枯渇問題に対する根本的な解決策としては、新しい IP アド

2.2 IPv6 アドレスの基礎

レス空間を持ったインターネットを作る必要があるとも考えられました。

2.2 IPv6 アドレスの基礎
多くの人々が「インターネット」として知っている世界規模の巨大ネットワークは、
インターネットプロトコルのバージョン 4、すなわち IPv4 で作られました。IPv4 で使われる IPv4 アドレスは、インターネットで必要とされる数を満たすには十分でなく、そのうち IPv4 アドレスが足りなくなることは予想されていました。その対策として開発されたのが、インターネットプロトコルのバージョン 6、すなわち IPv6 です。
IPv6 が最初に RFC 1883 として標準化されたのは 1995 年のことです。その後もさまざまな更新が加えられながら、現在でも標準化の作業は続けられています。本書執筆時点での IPv6 そのものに対する仕様は RFC 8200 にまとめられています。
1995 年に最初の標準化が行われたものの、IPv6 は 2011 年ごろまではあまり普及しませんでした。それでも 2011 年に IPv4 アドレスの中央在庫が枯渇してから、少しずつ IPv6 の普及には弾みがついています。

2.2.1 IPv4 アドレスとの違い
IPv6 の最大の特徴は、IPv4 よりもアドレスのビット数が大きく、表現できるアドレ

スの数が圧倒的に多いことです。IPv4 アドレスの長さは 32 ビット、IPv6 アドレスの長さはその 4 倍の 128 ビットなので、表現できるアドレスの個数は IPv4 の 2 の 96 乗
倍になります。
IPv4 アドレスと IPv6 アドレスの違いは、ビット数が増えたことによるアドレスの総数の違いだけではありません。IP アドレスは、ネットワークを示す部分とインターフェースを示す部分とに分けて使われますが、この区分も IPv4 と IPv6 とでは異なります。両者の違いを図 2.3 に示します。
IPv4 アドレスは「ネットワーク部」と「ホスト部」で構成されます。一方、IPv6 アド

レスは、「サブネットプレフィックス」と「インターフェース識別子」（IID、Interface
Identiﬁer）で構成されます。一見すると名称の違いだけのようにも思えますが、この名称に IPv4 と IPv6 の大きな違いが示されています。
IPv4 アドレスは、1989 年に発行された RFC 1122 に「Network-number および
Host-number で構成される」と記述されていることからわかるように、機器である「ホスト」そのものを示しています。
「パケットの転送を行うルータは別として、末端のノードは基本的に 1 つだけしかネットワークインターフェースを持たないので、そこで必要な IPv4 アドレスも 1 つだけ」という前提が垣間見えます。

15

16

第2章

IPv4 と IPv6

ホスト部
IPv4
アドレス

ネットワーク部
32ビット

IPv6
アドレス

サブネットプレフィックス

インターフェース識別子
128ビット▲

図 2.3 IPv4 と IPv6 での IP アドレス構成要素の違い

一方、IPv6 では、1 つのネットワークインターフェースに複数の IPv6 アドレスが付く場合が最初から想定されています。IPv6 アドレスのインターフェース識別子は、文字どおり、ホストではなく「インターフェース」を識別するものなのです。「IPv6 ア
ドレスはあくまでもネットワークインターフェースを識別するものであり、必ずしもホストのような機器を識別するものではない」という前提が垣間見えます。
実際、IPv6 では、同じ 1 つのネットワークインターフェースに対して、「サブネットプレフィックスは異なるがインターフェース識別子は同じ」という IPv6 アドレスを複数設定できます。

2.3 インターネットは IPv4 と IPv6 のデュアルスタック
IPv6 は、IPv4 アドレス枯渇問題の根本的な解決策ではありますが、直接的な解決策としては設計されておらず、IPv4 とは互換性がないプロトコルとして開発されました。互換性がないので、「インターネットのためのプロトコル」という視点で見ると、
IPv4 と IPv6 とではまったく別々のネットワークになります。今後しばらくは、それ

ぞれ互換性がないプロトコルを利用する「IPv4 インターネット」と「IPv6 インターネット」という 2 種類のインターネットが、利用者から見れば 1 つのインターネット
として同時に運用されている状態が続くことになります。
ある特定のプロトコルを扱うためのソフトウェアの実装をプロトコルスタックと呼びます。インターネットが IPv4 だけで実現していたときのプロトコルスタックは、図2.4 のような階層構造として表現できます。ほとんどの層には複数のプロトコルが存在していますが、ネットワーク層だけは IPv4 という単一のプロトコルである点に注目してください。

2.3 インターネットは IPv4 と IPv6 のデュアルスタック

SSH

HTTP

電子メール

アプリケーション

SSL/TLS
TCP

QUIC

UDP

IPv4
PPP

ネットワーク層
データリンク層

イーサネット
光ファイバ ツイストペア
ケーブル

携帯電話網

トランスポート層

無線LAN

物理層

▲

図 2.4 IPv4 のみの場合のプロトコルスタック

しかし、IPv4 よりアドレス空間が広い IPv6 が利用されるようになった現在では、図2.5 のように、ネットワーク層に IPv4 と IPv6 の両方が存在している状態です。

SSH

HTTP

電子メール

アプリケーション

SSL/TLS
TCP

IPv4
PPP

UDP

QUIC

IPv6

ネットワーク層
データリンク層

イーサネット
光ファイバ ツイストペア
ケーブル

携帯電話網

トランスポート層

無線LAN

物理層

▲

図 2.5 IPv4 と IPv6 の両方が存在する場合

IPv4 と IPv6 は互換性のない別々のネットワーク層プロトコルなので、プロトコル

スタックとしても別々です。このようにまったく異なる 2 つのプロトコルスタックが使える状態をデュアルスタックと呼びます。
かつては IPv4 という単一のプロトコルが前提であったネットワーク層に、IPv4 とIPv6 が並行して存在する現在のインターネットは、デュアルスタック環境になっています。インターネットがこのようなデュアルスタック環境であることを意識しなければならない場面は、サーバやネットワークの管理者、通信が関連するプログラムを書くプログラマだけでなく、一般のインターネット利用者にとっても増えていくと考え

17

18

第2章

IPv4 と IPv6

られます。

NOTE

本書で解説する v6 プラスは、このようなデュアルスタック環境のインターネットを
NTT 東西のフレッツ網を利用しているユーザに提供するための仕組みのひとつだといえるでしょう。フレッツ網に契約しているユーザの家庭内ネットワークなどから、IPv6
IPoE 方式と MAP-E を通じて IPv6 インターネットと IPv4 インターネットの両方への接続性を提供するサービスが、v6 プラスというわけです。

2.3.1 IPv6 と IPv4 の 2 つのインターネットを 1 つに見せる DNS
IPv4 は、その誕生時点から世界中に普及した現在に至るまでインターネットで使われてきたプロトコルです。一方の IPv6 は、これから普及していくプロトコルです。
これら 2 種類のプロトコルが同時に運用されている状態で、「1 つのインターネット」
を実現するために重要になるのが、名前解決です。
ネットワーク層が IPv4 と IPv6 のデュアルスタックになっても、ネットワークを利用する側の視点で見れば、「インターネットは 1 つ」でなければ困ります。IPv4 と IPv6
を並行して利用できる現在の状況は、ネットワーク層プロトコルで見れば 2 つの別のプロトコルによって実現される 2 つのインターネットだが、インターネットとしては
あくまでも 1 つという、非常にややこしい状況にあるといえるでしょう。
現在のインターネットでは、この「2 つであるが 1 つ」という状態を仮想的に実現するために、DNS（Domain Name System）を利用しています。DNS は、インター
ネットでの通信に必要な、「通信相手の IP アドレスを名前から得る」ための名前解決に利用されている仕組みです。現在のインターネットは、2 つの異なるインターネッ
トプロトコルで「1 つのインターネット」を実現するために、名前空間をあえて共有しています。そして、そのために DNS で IPv4 と IPv6 の両方に対応する名前を扱っているのです。
DNS では、ドメイン名という名前から IP アドレスを解決するために、レコードと呼ばれる仕組みを利用しています。レコードは、IPv4 アドレス用と IPv6 アドレス用とを別々に設定できます。たとえば、「www.example.com」という 1 つの名前に対し、
IPv4 と IPv6 の両方の IP アドレスを登録できるようになっています。IPv4 アドレス用

は A レコード、IPv6 アドレス用は AAAA レコード（「クアッド・エー」）と呼びます。
なぜ、1 つの名前に対して 2 つの IP アドレスを登録できることが重要なのでしょうか？ Web における通信を例に考えてみましょう。
「http://www.example.com/」2.3 インターネットは IPv4 と IPv6 のデュアルスタックという URL を持つサーバと通信をするときにユーザがアクセスしたいのは、通信が IPv4 によるか、それとも IPv6 によるかにかかわらず、「www.example.com」が指し示す Web ページです。仮に IPv4 と IPv6 とで名前空間がまったく異なるとし
たら、IPv4 で「example.com」というドメイン名を登録している組織と、IPv6 で「example.com」というドメイン名を登録している組織が別々である可能性もあります。もしそうなっていたら、IPv4 で通信する場合と IPv6 で通信する場合とで、同じ「http://www.example.com」という URL でアクセスできる Web ページも別物になってしまいます。それではユーザが混乱してしまうでしょう。DNS が使う名前空間のための「Root」（根っこ）は、「1 つ」であることが重要なのです（RFC 2826）。
IPv4 インターネットと IPv6 インターネットがまったく異なるネットワークであるのは、あくまで通信プロトコル上の話であり、名前空間を含めたいわゆる「インターネット」としては「1 つ」でなければならないのです。

2.3.2 IPv6 か IPv4 かを選ぶのはユーザ側
IPv4 だけを利用する場合には IPv4 アドレスに対する名前解決が行われ、IPv6 だけを利用する場合には IPv6 アドレスだけの名前解決が行われます。IPv4 と IPv6 の両方の利用を試みる場合には、IPv4 と IPv6 の両方に対する名前解決が行われます。
ここで重要になるのが、「IPv4 と IPv6 のどちらを使って通信するかを誰がどのように判断するか」です。結論から言うと、この判断をするのはユーザです。ただし、厳密にはユーザが利用しているパソコンやスマートフォンなど端末機器の OS や個々のソフトウェアが判断しており、ユーザ自身は気づかない場合がほとんどです。いずれにしても、Web サーバなどではなく、ユーザ側で IPv4 と IPv6 のどちらを使うのかを判断しているということが、ここでは大きなポイントです。
一般的に、IPv4 と IPv6 の両方の問い合わせを DNS に対してひとつの問い合わせとして同時に行うことはできません。そのためユーザは、名前に関して IPv4 と IPv6 の問い合わせを別々に行う必要があります。別々の問い合わせを行うということは、
ユーザ側が明示的に IPv4 と IPv6 の両方について名前解決をしたいと DNS サーバに問い合わせるということです。
DNS サーバは、個々の問い合わせにそれぞれ回答するだけです。DNS サーバが「あなたは IPv4 を使いなさい」とか「あなたは IPv6 を使いなさい」などという指示を出すことはありません。
IPv4 と IPv6 の両方で運用されている Web サーバへの接続を例に考えてみましょう。

サーバ側は、たとえ IPv4 と IPv6 の両方で TCP ソケットを使って接続されるのを待っ

19

20

第2章

IPv4 と IPv6ていたとしても、ユーザ側が IPv6 で接続してくれなければ IPv6 で通信できません。
たとえば、「www.example.com」というドメイン名の Web サイトが、IPv4 と IPv6の両方で運用されていたとします。この Web サーバに対して、ユーザが Web ブラウ
ザで接続する場合には、まず DNS で「www.example.com」の名前解決を試みる必要があります。その際には、IPv4 の A レコードと IPv6 の AAAA レコードの両方に対して
名前解決を試みます。もし両方ともに結果が返ってきた場合、IPv4 で接続するのか、それとも IPv6 で接続するのかを判断するのは、Web ブラウザです。接続に IPv4 を使
うのか、それとも IPv6 を使うのかを判断するのは、個々のアプリケーションの仕事だからです。
他の環境がすべて同じであったとしても、IPv4 と IPv6 のどちらを使うべきかがア
プリケーションによって異なる可能性もあります。アプリケーションプログラマは、
IPv4 を使うのか、それとも IPv6 を使うのかを判断するコードを、アプリケーション

ごとに書く必要があります。
かつては IPv6 で運用されているサーバがほとんどなかったので、IPv4 と IPv6 のどちらで通信するかをアプリケーションプログラマが考える必要は事実上ありませんでした。TCP で通信するならば、IPv4 アドレスを名前解決で得たのちに TCP で接続するだけだったのです。しかし、本書執筆時点（2021 年 2 月）では、IPv4 を使うのか、それとも IPv6 を使うのかを判断するアプリケーションプログラムを書くことが強く推奨されるようになっています。
とはいえ、IPv4 と IPv6 のそれぞれで TCP の接続が成功するかどうかは、実際に接続を試みないとわかりません。そのため、図 2.6 のように、IPv4 と IPv6 の両方を同時に接続してしまい、先に成功したほうの接続を使うという方法もあります。

NOTE
IPv6 がさらに普及し、IPv4 の利用が少なくなれば、今度は IPv6 だけで接続すればよくなるので、再び IPv4 と IPv6 のどちらのプロトコルを使うのかを判断する必要がなくな
るかもしれません。そのころには本節のような説明も不要になり、「昔は IPv4 というものもありました」という軽い紹介だけで済むでしょう。もちろんそのころには、IPv4 イ
ンターネットとの接続性を提供する v6 プラスのようなサービスも不要になっているはずです。

2.4 キャッシュ DNS サーバと CDN による通信効率の低下

IPv4インターネット

Webブラウザなどのアプリケーション

IPv4ソケット

データ

IPv4

データ

IPv6

ブロードバンド
ルータ

Webサーバなど

IPv6ソケット

IPv6インターネット▲

図 2.6 IPv4 と IPv6 の両方で接続を試みる

2.4 キャッシュ DNS サーバと CDN による通信効率の低下
本章の最後に、IPv6 インターネット接続と IPv4 インターネット接続がまったく異なる組織を経由する状況が、通信効率の低下を招く可能性について言及しておきます。
これは、Web トラフィックなどの負荷分散を目的として利用される CDN（Content
Delivery Network）で、キャッシュ DNS サーバの IP アドレスが利用される場合に起こりうる問題です。この問題は、IPv6 インターネット接続と IPv4 インターネット接続を同じ組織のネットワーク経由で提供する v6 プラスを利用することで回避できる可能性があるという点に注目してください。
まず、この問題が発生している状況を図 2.7 に示します。DNS 問い合わせを行った
キャッシュ DNS サーバに応じて、DNS 権威サーバが回答する IP アドレスを変更する
ことにより、CDN を実現しているような環境です。
図 2.7 では、IPv6 インターネット接続は VNE によって提供され、IPv4 インターネッ
ト接続は ISP によって提供されています。ユーザが利用しているパソコンでは、IPv4を利用している ISP のキャッシュ DNS サーバが設定されているとします。
図 2.7 の環境で、CDN によって負荷分散されているコンテンツをユーザが取得する
ときの流れを見てみましょう。まず、ユーザが ISP にあるキャッシュ DNS サーバを利用して名前解決を行います。このユーザは IPv4 インターネットと IPv6 インターネッ
トの接続性を両方とも持っているので、AAAA レコードによる問い合わせを先に行っているものとします。
また、この例ではユーザが ISP のキャッシュ DNS サーバを利用しているので、AAAA

21

22

第2章

IPv4 と IPv6

フレッツ網

名前解決ではISPのIPv6アドレスを取得

ISPのCDNから
コンテンツを取得

ISP

DNSキャッシュ
サーバ

CDNキャッシュ
サーバ（IPv6）

VNE

IPv4インターネット

権威DNS
サーバ

CDNキャッシュ
サーバ（IPv6）

IPv6インターネット▲

図 2.7 IPv6 と IPv4 で違う組織を通る場合に発生する可能性がある CDN の問題

レコードの問い合わせは IPv4 での問い合わせになります。
ISP にあるキャッシュ DNS サーバは、権威 DNS サーバに AAAA レコードの問い合わせを行い、回答を得ます。いま、図 2.7 のように、ISP は IPv4 と IPv6 の両方を運用しており、IPv6 で運用された CDN キャッシュサーバを保持しているとします。すると、権威 DNS サーバからキャッシュ DNS サーバへ返答されるのは、問い合わせを行った
キャッシュ DNS サーバの最寄りにあるコンテンツのアドレス、つまり CDN キャッシュサーバのアドレスです。
キャッシュ DNS サーバから名前解決の結果を受け取ったユーザのパソコンでは、
CDN キャッシュサーバからコンテンツを取得します。このとき、コンテンツの取得に利用されるのは IPv6 なので、ユーザは VNE を経由して CDN キャッシュサーバにあるコンテンツを取得することになります。
しかし、もし VNE にも CDN キャッシュサーバがあれば、これではユーザが遠回りをしてコンテンツを取得していることになってしまいます。このような遠回りが発生するのは、CDN による負荷分散の仕組みの一部である権威 DNS サーバが、「ユーザのパソコンは ISP 経由で接続している」と認識しているために発生しています。
ユーザが VNE にある CDN キャッシュサーバから IPv6 でコンテンツを取得するには、VNE のキャッシュ DNS サーバを利用すればいいのですが、今度は逆に IPv4 による CDN キャッシュサーバからのコンテンツ取得が遠回りになってしまう可能性があります。
IPv4 の A レコードを取得するときと、IPv6 の AAAA レコードを取得するときで、利用するキャッシュ DNS サーバを切り替えられればよいのですが、そのような使い分
けが行われることは稀です。

2.4 キャッシュ DNS サーバと CDN による通信効率の低下

このような CDN の問題は、IPv4 インターネットと IPv6 インターネットのデュアルスタック環境における相性問題ともいえるでしょう。v6 プラスを利用することで、
IPv6 IPoE による IPv6 インターネットへのトラフィックと、v6 プラスを経由する IPv4

トラフィックが両方とも JPIX を通じてインターネットとつながります。そのため、このような問題を回避できます。
既存の CDN の構築手法が、ある意味で力技なので、IPv6 の技術的な欠陥というよりは、既存の運用では十分に効率化が難しい問題であるという解釈も可能です。

23

［書籍版では空白のページです］

第3章

フレッツ網からの IPv6 インターネット
接続（IPv6 IPoE）

本章では、v6 プラスの背景となるフレッツ網における IPv6 インターネット接続
サービスについて解説します。
現在、フレッツ網における IPv6 インターネットとの通信サービスの実現手段には、
次の 2 種類の方式があります。

r IPv6 IPoE 方式（ネイティブ方式）
r IPv6 PPPoE 方式（トンネル方式）
IPv6 IPoE 方式は、ネイティブ方式という別名が示すように、純粋にイーサネット

上で IPv6 を伝送するものです。わざわざ「IPoE」と呼ばれているのは、もう一つの方式である IPv6 PPPoE 方式との対比で命名されたことによります。基本的にはイーサ
ネット上で通常の IPv6 のフレームをやり取りしますが、フレッツ網に対処するために日本独自の部分があります。
それに対して、IPv6 PPPoE 方式は、Point-to-Point リンクをイーサネット上でエミュレートするために考案された技術です。イーサネット上でエンドユーザの認証を伴う回線収容を実現する技術として、IPv4 インターネット接続サービスで広く利用されてきました。IPv6 インターネット接続をこれと同じ方式で実現するのが IPv6
PPPoE 方式だといえます。

3.1 IPv6 IPoE 方式と IPv6 PPPoE 方式がある背景
まず、IPv6 IPoE 方式と IPv6 PPPoE 方式の 2 つがフレッツ網における IPv6 インターネット接続で利用されている背景を改めて説明しましょう。
そもそもフレッツ（FLET’S）というのは、NTT 東日本と NTT 西日本（NTT 東西）が

26

第3章

フレッツ網からの IPv6 インターネット接続（IPv6 IPoE）

提供するデータ通信サービスの名称です。このデータ通信サービスの基盤となるネットワークが、「フレッツ網」や「NTT NGN」
（Next Generation Network、次世代ネットワークの意味）などと呼ばれています。
1.1 節でも簡単に触れましたが、フレッツ網はインターネットとは切り離された「閉域網」です。「日本電信電話株式会社等に関する法律」、通称 NTT 法による制限
で、NTT 東西はインターネット接続サービスを直接提供することが許されていません。そのため、利用者に対するインターネット接続サービスは ISP により提供されています。
閉域網ではありますが、フレッツ網では全体の IPv6 ネットワーク化が進められており、そこではグローバルユニキャスト IPv6 アドレスが利用されます。たとえば NTT
東西が展開する「フレッツ光」の回線を契約すると、利用者にはこの閉域網からグ
ローバル IPv6 アドレスが割り振られます。
このように現在のフレッツ網が成立しているのは、NTT 法による制限と、NTT 東
西によるネットワーク設計上の判断による結果です。しかし、この閉域網で使われているグローバルユニキャスト IPv6 アドレスが、いわゆる「NTT NGN IPv6 マルチプレ
フィックス問題」を発生してしまうという懸念がありました。これは IPv6 がそもそも抱えている技術的な課題だといえます。
この懸念を解消する方法が、2011 年にサービスが開始された IPv6 PPPoE 方式とIPv6 IPoE 方式でした。逆にいうと「NTT NGN IPv6 マルチプレフィックス問題」とは、IPv6 IPoE 方式や IPv6 PPPoE 方式といった解決策がなければフレッツ網で発生してしまう可能性があった NTT NGN 固有の現象だといえます。すでに解決されているので問題ではないのですが、これらの方式が考案された背景を知るという意味では重要なので、何が懸念されていたのかを少し掘り下げて説明します。

3.1.1 通信できない IPv6 環境の例
NTT NGN IPv6 マルチプレフィックス問題は、フレッツ網に限らず、IPv6 をマルチ

ホームな環境で利用するネットワークで起きうる問題です。そこで、まず一般論として、マルチホーム環境における IPv6 マルチプレフィックス問題とは何かを説明します。
図 3.1 では、ホストが接続された 1 台のルータが 2 つの上流ネットワークと接続しています。この状況では、2 つの上流ネットワークから、それぞれのネットワークプ
レフィックスがルータに対して広告されます。
実は、IPv6 では 1 つのネットワークインターフェースに対して複数の IPv6 アドレ

3.1 IPv6 IPoE 方式と IPv6 PPPoE 方式がある背景

ポート1
ホスト

ルータ1

ポート2
ルータ
ルータ2

▲

図 3.1 IPv6 マルチプレフィックス問題が発生する状況

スを設定できます。そのため、図 3.1 のようにネットワークプレフィックスが 2 つ広告される状況では、ホストに対しても 2 つのグローバル IPv6 アドレスが設定される可能性があります。これが IPv6 環境で一般に発生しうる「IPv6 マルチプレフィックス」という状況です。
IPv6 マルチプレフィックスの状態であっても、個々の通信では単一の IPv6 アドレ

スが利用されるので、通信そのものに支障はありません。ただし、IPv6 マルチプレ
フィックスの状態にあるホストは、何らかの方法で通信に利用する IPv6 アドレスを複数の中から選択する必要があります。その選択によって通信結果が異なる場合や、悪影響が生じる場合もあります。

3.1.2 アドレス選択による悪影響
IPv6 マルチプレフィックス環境でアドレス選択により生じる悪影響について、図3.2 のような状況で説明します。

この例では、家庭内ネットワークが ISP A と ISP B の両方につながっています。この家庭内には、ISP A とつながったルータと、ISP B とつながったルータの 2 つのルータがあるとします。両方のルータは同じネットワークセグメントに接続しています。
家庭内には、ネットワークインターフェースが 1 つだけあるパソコンが設置されています。そのパソコンのネットワークインターフェースには、次の 2 つのグローバル
IPv6 アドレスが設定されます。

r ISP A からの IPv6 アドレス 2001:db8::ar ISP B からの IPv6 アドレス 3ffe::b
いま、何らかの理由で ISP B における IPv6 インターネットの接続性に一時的な障害

27

28

第3章

フレッツ網からの IPv6 インターネット接続（IPv6 IPoE）

ISP A
2001:db8::/48

ルータ1

ISP B

2001:db8::a
3ffe::b3ffe::/48
IPv6インターネット
ルータ2▲

図 3.2 IPv6 アドレス選択が悪影響を与える例 1が発生したとしましょう。図 3.2 の状況で家庭内のパソコンが IPv6 インターネットとの通信を成功させるには、次の 3 つの点が満たされている必要があります。

r 適切な Next Hop を選択してパケットを送信できること
ISP B で IPv6 インターネットとの通信障害が発生している状態で、ISP B につながっているルータに向けてパケットを送信しても、パケットは IPv6 インターネットへと到達できません。

r 適切な送信元 IPv6 アドレスを利用してパケットを送信できること
ユーザが送信する IPv6 パケットの送信元 IPv6 アドレスが ISB B からの IPv6 アドレスであった場合、IPv6 インターネットから戻ってくる IPv6 パケットが ISP B に向けて送信されてしまいます。しかし、ISP B は IPv6 インターネットとの通信障害によって通信が失敗する状態にあります。そのため、ユーザが送信するパケットの送信元 IPv6 アドレスが ISP B のものの場合、通信が失敗してしまいます。

r 適切なキャッシュ DNS サーバを選択できること
これは、キャッシュ DNS サーバの選択によって宛先 IPv6 アドレスが変わる可能性があるためです。通信相手が DNS を利用した負荷分散を行っている場合に、ユー
ザが選択するキャッシュ DNS サーバによって通信相手が変わる可能性があります。
ポイントは、送信元 IPv6 アドレスの選択と経路の選択が互いに独立している点です。
ISP A 経由での通信を成功させるには、図 3.3 のように、家庭内にあるパソコンが送

信元 IPv6 アドレスとして ISP A からの 2001:db8::a を選択したうえで、ISP A とつながっているルータを Next Hop として選択する必要があります。

3.1 IPv6 IPoE 方式と IPv6 PPPoE 方式がある背景

ISP A
2001:db8::/48
送信元

2001:db8::a
v6
v4

v6

ルータ1

ISP B

2001:db8::a
3ffe::b

宛先

2001:db8::a

3ffe::/48
IPv6インターネット
ルータ2▲

図 3.3 IPv6 アドレス選択が悪影響を与える例 2

図 3.4 のように、家庭内にあるパソコンが送信元 IPv6 アドレスとして ISP B からの
3ffe::b を選択し、ISP A とつながっているルータ経由で IPv6 インターネット上にあるサーバとの通信を試みる場合には、家庭内のパソコンからサーバまでのパケットは到達するものの、サーバから家庭までのパケットは到達せず、通信が成立しません。

ISP A
2001:db8::/48
送信元

3ffe::b
v6

ルータ1

ISP B

2001:db8::a
3ffe::b3ffe::/48v6

宛先

3ffe::bIPv6インターネット
ルータ2▲

図 3.4 IPv6 アドレス選択が悪影響を与える例 3

図 3.4 のような環境では、Next Hop の選択によってはまったく通信ができません。
家庭内のパソコンが Next Hop としてルータ 2 を選択した場合、送信元 IPv6 アドレスの選択にかかわらず、すべての通信が失敗してしまいます。
ここまで、何らかの理由で ISP B における IPv6 インターネットの接続性に一時的な障害が発生したという想定で説明していますが、正常な運用時に類似する問題が発生する場合もあります。これは、上流ネットワークが下流ネットワークとして認識しているネットワークプレフィックスではない、別の IPv6 アドレスを送信元 IPv6 アド

29

30

第3章

フレッツ網からの IPv6 インターネット接続（IPv6 IPoE）

レスとするパケットが、上流ネットワーク宛に送信されてしまうためです。ユーザが選択する送信元 IPv6 アドレスが適切でないとき、ユーザにとっての上流ネットワー
クとなる ISP にとっては、ISP が管理しておらず存在しないはずのネットワークプレ
フィックスからのパケットが届いているように見えてしまいます。
2000 年に発行された RFC 2827（BCP 38）では、各自が管理するネットワークで偽装されたパケットを出して DDoS 攻撃などの発信源になることで DDoS 攻撃に加担してしまうことを防ぐため、RPF（Reverse Path Forwarding）という手法が提案されています。これは、各パケットの送信元へのユニキャストの経路を参照しつつ、「そのパケットがその方向からくることが正しいかどうか」を確認するというものです。ISP
で BCP 38 が実施されている環境では、送信元 IPv6 アドレスと経由するネットワーク
が一致してない場合にパケットが破棄されてしまう可能性があります。

3.1.3 フレッツ網における IP マルチプレフィックス問題
ユーザが ISP と契約し、IPv6 閉域網であるフレッツ網を介して IPv6 インターネットへ接続する場合には、IPv6 マルチプレフィックスと似た状況が発生します。仮にフレッツ網で IPv6 マルチプレフィックス問題が発生するとしたら、フレッツ網からのIPv6 アドレスと、ISP からの IPv6 アドレスの 2 つが、同時にユーザの機器に設定される場合です。この問題を発生させずにフレッツ網から IPv6 インターネットへ接続する方法として考案されたのが、IPv6 IPoE 方式と IPv6 PPPoE 方式です。
IPv6 PPPoE 方式と IPv6 IPoE 方式では、IPv6 インターネットへの接続時に、フレッ

ツ網からの IPv6 アドレスが利用者のネットワーク内には割り当てされないようにします。フレッツ網内で提供されるサービスの通信と、IPv6 インターネット接続の通信の両方を、グローバル IPv6 アドレスが 1 つだけの状態で実現する仕組みです。ユーザが利用するホストに対しては複数のプレフィックスを提供せず、シングルプレフィッ
クスにすることで、問題を根本的に回避する手法といえます。
さらに、閉域網であるということは、フレッツ網内部にあるサービスとの通信は正常にできても、常に IPv6 インターネットとは通信できない状態です。これはつまり、フレッツ網を介した IPv6 インターネットへの接続では、図 3.4 に近い状況が発生するということです。ユーザの機器において「フレッツ網内部との通信では宛先と送信
元をフレッツ網からの IPv6 アドレスにし、IPv6 インターネットとの通信では他方のIPv6 アドレスを送信元にする」という選択が自動的にできれば何も問題になりません

が、それにはユーザの機器での設定や特別なソフトウェアのインストールが必要になります。そうした要求をせずに自動的な切り替えをすることが困難であったという要3.2 IPv6 IPoE 方式と IPv6 PPPoE 方式の違い

因もありました。

3.2 IPv6 IPoE 方式と IPv6 PPPoE 方式の違い
NTT 東西で提供されている IPv6 IPoE 方式と IPv6 PPPoE 方式の詳細について説明する前に、両者の違いを整理しておきます（表 3.1）。

▲

表 3.1 NTT 東西で提供されている IPv6 PPPoE と IPv6 IPoE の相違点

項目

IPv6 PPPoE 方式

ユーザの IPv6 アドレス

ISP の IPv6 アドレス

ユーザの追加機器

IPv6 トンネルアダプタ

特になし

インターネット接続

ISP 経由VNE 経由PPPoE

その他の特徴IPv4 と IPv6 で別々のPPPoE セッションが必要

トンネルアダプタ内でNAT66 を実施

IPv6 IPoE 方式
VNE から NTT に預けられた
IPv6 アドレス

IPv6 用の PPPoE は不要
NGN 内で送信元 IPv6 アドレスをもとにした Policy Based
ルーティングを実施

表 3.1 から読み取れるように、IPv6 IPoE 方式においてインターネット接続サービスを提供する事業者は、ISP ではなく VNE（Virtual Network Enabler）と呼ばれます。
IPv6 でも、IPv4 のときと同じく、インターネット接続のためにユーザが契約するのはISP です。しかし、IPv6 IPoE 方式の場合には ISP が VNE と契約し、実際の通信はそのVNE を通じて行われることになります。VNE については後ほど 3.4 節で改めて解説します。なお、v6 プラスを提供する JPIX も、ISP ではなく VNE です。
ISP がユーザに対して IPv6 インターネット接続サービスを提供するときに、どちらの方式を採用するかは、ISP ごとの判断となります。ユーザは、ISP の対応状況を見な
がら IPv6 PPPoE 方式と IPv6 IPoE 方式のどちらを利用するのかを判断し、ISP のサー
ビスに申し込むことになります。IPv4 用の ISP と IPv6 用の ISP を別々に利用することも、技術的には可能です。

3.3 IPv6 PPPoE 方式の詳細
IPv6 PPPoE 方式は、フレッツ網で IPv4 インターネット接続サービスを使う場合と同様に、PPPoE を利用して IPv6 インターネット接続を提供する方式です。「トンネル

31

32

第3章

フレッツ網からの IPv6 インターネット接続（IPv6 IPoE）

方式」という別名があるとおり、IPv6 PPPoE 方式では、ユーザの家庭内にある IPv6
トンネルアダプタからフレッツ網内にある IPv6 終端装置までトンネルが張られます。

3.3.1 IPv6 インターネットへの接続
IPv6 PPPoE 方式では、ISP との接続や認証に PPP（Point-to-Point Protocol）を利用します。IPv6 終端装置は ISP のネットワークと接続されており、認証に成功すればISP を経由して IPv6 インターネットとの通信が可能になります（図 3.5）。

IPv6トンネル
アダプタ

IPv6
網終端装置

CPE
IPv6 PPPoE
トンネル

フレッツ網

▲

図 3.5

ISP（IPv6）

IPv6インターネット

IPv6 PPPoE

IPv6 PPPoE 方式でユーザが利用する IPv6 アドレスは、ISP に割り振られた IPv6 ア

ドレスです。ISP からは、IPv6 トンネルアダプタに接続しているユーザの家庭内ネッ
トワークに対し、IPv6 のネットワークプレフィックスが割り当てられます。この ISP
から割り当てられるネットワークプレフィックスのみが、ユーザの家庭内ネットワー
クで利用されます。

3.3.2 フレッツ網内のサービスへの接続
IPv6 PPPoE 方式でユーザに割り当てられた IPv6 アドレスは、そのままではフレッ

ツ網内宛の IPv6 による通信には利用できません。そこで、フレッツ網内で提供されるサービスとの通信には、IPv6 アドレスを別の IPv6 アドレスへと変換する NAT66 が利用されます。トラフィックの宛先がフレッツ網内の場合には、IPv6 トンネルアダプ
タで、送信元 IPv6 アドレスをフレッツ網の IPv6 ネットワークプレフィックスに変換
してから転送するのです（図 3.6）。このように IPv6 PPPoE 方式では、NAT66 を利用することで、フレッツ網内宛の通信と IPv6 インターネット宛の通信が両方とも可能になっています。

3.4 IPv6 IPoE 方式の詳細

フレッツ網内のサービス

IPv6トンネル
アダプタ

IPv6
網終端装置

CPE

NAT66
として機能

フレッツ網

ISP（IPv6）

IPv6インターネット▲

図 3.6 IPv6 PPPoE のトンネルアダプタで行われる NAT66

3.3.3 IPv4 インターネットへの接続
一般のユーザは、IPv6 インターネットだけではなく、IPv4 インターネットもよく利用します。その場合には、IPv6 PPPoE に加えて、IPv4 PPPoE も利用することになります。具体的には、図 3.7 のように、IPv4 PPPoE の接続はホームゲートウェイが担
当し、IPv6 PPPoE は IPv6 トンネルアダプタが担当するという構成になります。なお、
これは必ずしも別々の機器が必要という意味ではなく、IPv4 PPPoE と IPv6 トンネル
アダプタの両方の機能が搭載されたホームゲートウェイが使われる場合もあります。

ISP（IPv4）
IPv4
網終端装置

IPv4インターネット

IPv6
網終端装置

IPv6トンネル
CPE
アダプタ
IPv6トンネル

フレッツ網

ISP（IPv6）

IPv6インターネット▲

図 3.7 IPv6 PPPoE と IPv4 PPPoE が両方使われる場合

3.4 IPv6 IPoE 方式の詳細
IPv6 IPoE 方式では、VNE 事業者が NTT 東西と契約し、他の ISP に代わってフレッツ網を介した IPv6 インターネット接続サービスを提供します（図 3.8）
。ISP は、VNE と契約して VNE の顧客となることで、ユーザに対して IPv6 インターネット接続サービ

33

34

第3章

フレッツ網からの IPv6 インターネット接続（IPv6 IPoE）

スを提供します。v6 プラスも、VNE のひとつである JPIX によって提供される、IPv6
IPoE 方式の IPv6 インターネット接続サービスです。
VNE は、フレッツ網とインターネットの相互接続を行うために、自社で IPv6 ネット

ワークを運用します。パケットを処理するのは VNE なので、IPv6 IPoE 方式では ISP が通信データを直接扱いません。ISP の役割はパケットを処理することではなく、ユー
ザのアカウントや課金を管理することに特化されます。

NOTE
ISP から見ると、IPv6 IPoE 方式での接続形態はローミングサービスに似ています。フ

レッツ網からの IPv6 インターネット接続を、VNE が ISP に対しローミングサービスとして提供するというわけです。

フレッツ網内
のサービス

VNE 1

CPE

IPv6アドレス

IPv6インターネット
フレッツ網

VNE 2

▲

図 3.8 IPv6 IPoE と VNE

3.4.1 IPv6 インターネットへの接続
IPv6 IPoE 方式では、ユーザから IPv6 インターネット宛のパケットが、VNE との相互接続地点に設置されたゲートウェイルータまでフレッツ網内を転送されます。このとき、「送信元 IPv6 アドレスをもとにした Policy Based ルーティング」という、少し特殊な転送方式が使われます。通常の IPv6 ユニキャストパケットは、IPv6 ヘッダに記載された宛先 IPv6 アドレスに応じて転送されるのですが、「送信元 IPv6 アドレスをもとにした Policy Based ルーティング」では、送信元 IPv6 アドレスも考慮してルーティングが行われるのです。
このような仕組みになっているのは、どの VNE を経由して IPv6 インターネットへ3.4 IPv6 IPoE 方式の詳細と転送するかを、各ユーザの IPv6 アドレスに応じて決定する必要があるからです。
VNE との相互接続地点にあるゲートウェイルータでは、各パケットの送信元アドレス

を見て、そのパケットを適切な VNE へと転送します。
IPv6 IPoE 方式でユーザに割り当てられるのは VNE の IPv6 アドレスです。もう少し詳しく言うと、ユーザが ISP と契約して「IPv6 IPoE 方式によるインターネット接続サービス」に申し込んだ場合、そのユーザには「VNE から NTT に預けられた IPv6 アドレス」が割り当てられます。IPv6 PPPoE 方式では ISP の IPv6 アドレスプレフィック
スがユーザに割り当てられるので、この点は両方式の大きな違いのひとつです。
なお、IPv6 IPoE 方式には、ユーザが利用可能な VNE は 1 社だけという制約があります。ユーザは、ひとつの回線契約で同時に複数の VNE と契約することができません。これは、ユーザに対して割り当てられる IPv6 アドレスプレフィックスが、VNE のIPv6 アドレスであるためです。

3.4.2 フレッツ網内のサービスへの接続
IPv6 インターネットとの通信でなくフレッツ網内のサービスとの IPv6 による通信

では、ユーザから送信される IPv6 パケットの宛先 IPv6 アドレスがフレッツ網内のものになっています。そのような IPv6 パケットは、フレッツ網内のサーバへと、そのまま転送されます。フレッツ網内との通信で NAT66 が必要な IPv6 PPPoE 方式と比べると、仕組みも比較的シンプルです。
IPv6 IPoE 方式には、NTT 東西側の設定だけで実現できるという特徴があります。

そのため、IPv6 PPPoE 方式では必要になる IPv6 トンネルアダプタのような追加機器が必要ありません。

3.4.3 網内折り返し
IPv6 IPoE 方式には、フレッツ網における網内折り返しが利用できるという利点があります。網内折り返しは、VNE を経由せず、フレッツ網内で通信が可能になるという機能です（ただし NTT 東西をまたがるような通信に関しては、VNE を経由して折り返されます）。
網内折り返しは、インターネット接続に関するサービスではないので、ISP との契約で提供される機能ではありません。網内折り返しを利用したいユーザは、ISP との契約とは独立に、NTT 東西と「フレッツ・v6 オプション」に契約する必要があります。

35

36

第3章

フレッツ網からの IPv6 インターネット接続（IPv6 IPoE）

3.4.4 IPv4 PPPoE を利用した IPv4 インターネットへの接続
IPv6 IPoE 方式は、IPv6 インターネットを利用するためのサービスなので、IPv4 イ

ンターネット接続サービスには別途契約が必要です。従来の PPPoE 方式での IPv4 イ
ンターネット接続サービスを提供している ISP と契約した場合、家庭内ネットワーク
からインターネットへの接続は図 3.9 のような構成になります。

フレッツ網

ISP（IPv4）
IPv4
網終端装置

IPv4インターネット

CPE

CPE

網内
折り返し
通信
フレッツ網内のサービス

VNE

IPv6インターネット▲

図 3.9 IPv6 IPoE 方式と IPv4 PPPoE 方式を併用した構成

図 3.9 の構成では、各家庭内のホームゲートウェイを経由して、IPv4 インターネッ
トへの接続サービスと IPv6 インターネットへの接続サービスの両方が提供されます。
IPv4 インターネットへのパケットは、ホームゲートウェイから IPv4 網終端装置まで

フレッツ網内をトンネルで転送され、そこから ISP を経由して運ばれます。

3.4.5 IPv4 over IPv6 を利用した IPv4 インターネットへの接続
v6 プラスでは、IPv6 IPoE 方式による IPv6 インターネット接続に加えて、IPv4 イン

ターネット接続サービスも提供されています。この IPv4 インターネット接続サービ
スでは、IPv4 PPPoE を利用するのではなく、IPv6 IPoE の上を経由する IPv4 over IPv6
トンネルが利用されています。IPv4 PPPoE を使わずに IPv4 インターネット接続ができることは、v6 プラスの非常に大きなポイントです。
v6 プラスにおける IPv4 over IPv6 トンネルは、MAP-E と呼ばれる技術です。MAP-E

については第 4 章で詳しく説明します。

第4章

MAP-E による IPv4 インターネット接続

v6 プラスでは、IPv4 パケットを IPv6 パケットでカプセル化して IPv4 インターネッ

トへと配送するための技術として、MAP-E が採用されています。本章では、この
MAP-E の基本的な仕組みを説明します。
MAP-E の「MAP」は、Mapping of Address and Port の略称です。
「アドレスとポートのマッピング」という名前が示すとおり、IPv4 アドレスとポート番号を IPv6 アド
レスにマッピングするのが MAP の大きな特長です。

NOTE

アドレスとポートのマッピングにより IPv4 パケットを IPv6 ネットワークを通じてやり取りする技術としては、MAP-E が採用しているカプセル化による方法のほか、パケッ
トの変換による MAP-T という方法もあります。MAP-E は RFC 7597 で、MAP-T は RFC
7599 で、それぞれ規定されています。v6 プラスは MAP-E を採用しているので、本書では主に MAP-E を中心に解説しますが、MAP-E と MAP-T の共通部分について説明すると
きは「MAP」と表記します。

4.1 IP トンネル
MAP-E は、IP パケットの中に別の IP パケットをカプセル化してそのまま運ぶという技術です。このような技術は一般に IP トンネルと呼ばれます。
カプセル化されたパケットにとって、IP トンネルはまさに「トンネル」のような存在であり、通り抜けた先のネットワークまでそのまま届きます。MAP-E では、IPv6
ネットワーク内に掘られた IPv6 トンネルを通じて配送されるので、このような IP ト
ンネルは IPv4 over IPv6 と呼ばれています。

38

第4章

MAP-E による IPv4 インターネット接続

IP トンネルは、v6 プラスで MAP-E により実現されている IPv6 トンネルだけでな

く、さまざまなところで利用されている技術です。トンネルとカプセル化される IP のバージョンの組み合わせにより、以下の 4 種類の IP トンネルが考えられます。

r IPv4 パケットを IPv6 パケットでカプセル化（IPv4 over IPv6）
r IPv4 パケットを IPv4 パケットでカプセル化（IPv4 over IPv4）
r IPv6 パケットを IPv6 パケットでカプセル化（IPv6 over IPv6）
r IPv6 パケットを IPv4 パケットでカプセル化（IPv6 over IPv4）
MAP-E は、このうちの「IPv4 パケットを IPv6 パケットでカプセル化」に相当します。カプセル化された IPv4 パケットが、IPv6 ネットワーク内に掘られた IPv6 トンネ
ルを通じて配送されます。

NOTE
IPv4 パケットを IPv6 ネットワークでやり取りする方法としては、カプセル化のほかにパケットの変換による手法もあります。

「IPv4 パケットを IPv4 パケットでカプセル化」する技術や「IPv6 パケットを IPv6
パケットでカプセル化」する技術は、IPv4 ネットワークや IPv6 ネットワークで VPN（Virtual Private Network）を実現するためなどに利用されることがあります。
「IPv6 パケットを IPv4 パケットでカプセル化」する技術は、IPv6 インターネットとの直接の接続性がないネットワークを、IPv4 ネットワーク経由で IPv6 インターネッ
トと接続するためなどに利用されます。

4.1.1 IPv4 over IPv6 としての MAP-E
IPv4 over IPv6 が利用される主な動機として、IPv6 と IPv4 の両方を同時に運用するデュアルスタックネットワークを可能な限り減らし、ネットワークの運用コストを削減するという側面があります。ネットワークの基幹部分を IPv6 のみで構成し、IPv4については最小限の運用コストに抑えようという動機です。
この IPv4 over IPv6 をフレッツ網における IPv6 IPoE と組み合わせて、IPv6 ネット
ワークを通じて IPv4 インターネットとの接続性を実現しようというのが、v6 プラスが採用している MAP-E です。なお、フレッツ網で VNE を経由して IPv4 インターネッ
トへの接続性を実現する手法としては、MAP-E のほかに第 9 章で説明する DS-Lite という技術もあります。

4.2 MAP 概要

他の IPv4 over IPv6 の手法と比べた MAP-E の特長として、複数のユーザで 1 つのIPv4 アドレスを共有する大規模な IPv4 NAT 環境を、CGN ではない形で実現できるというものもあります。これにより IPv4 インターネット接続サービスを提供する事業者が IPv4 アドレスを効率的に利用できます。
さらに、IPv4 と IPv6 の間での変換が軽量であることも MAP-E の特長です。CGN では複数ユーザの大規模な状態管理が必要になりますが、MAP-E では状態管理をユーザ側に設置されている機器へと分散できます。

4.2 MAP 概要
MAP（MAP-E および MAP-T）は、IPv6 のみで構成されたバックボーンネットワー

クに接続するユーザに対し、グローバル IPv6 アドレスとプライベート IPv4 アドレスによるネットワークを提供するための手法です。図 4.1 に、MAP が利用される環境の全体構成を示します。

ユーザのプライベート
IPv4ネットワーク

MAP
+
NAT44

MAP CE

MAPドメインサービス提供者のIPv6ネットワーク

ユーザのプライベート
IPv4ネットワーク

MAP CE

グローバル
IPv4ネットワーク（インターネット）

MAP BR

MAP
+
NAT44

▲

図 4.1 MAP の概要

MAP を利用して IPv4 パケットをやり取りする IPv6 ネットワークのことを、MAP ド

メインと呼びます。
MAP ドメインでユーザ側に設置される装置を MAP CE（Customer Edge）と呼びます。一般に家庭内ネットワークなどに設置される CPE（ホームゲートウェイやレジ
デンシャルゲートウェイとも呼ばれる機器）が、MAP CE として機能することになり

39

40

第4章

MAP-E による IPv4 インターネット接続

ます。
一方、サービス提供者側に設置される装置を MAP BR（Border Relay）と呼びます。
MAP BR は、グローバル IPv4 アドレスを宛先とするパケットを MAP ドメインから転送するために利用されます。
IPv6 アドレス宛のパケットについては、カプセル化や変換はせずに、そのまま通信します。ネイティブに IPv6 インターネットと接続している形です。IPv6 パケットがそのまま ISP などのネットワークへと転送されます。
IPv4 インターネットへの接続については、IPv4 over IPv6 トンネルを経由して通信します。その際には、プライベート IPv4 アドレスとグローバル IPv4 アドレスの変換も必要です。そのため CPE では、IPv4 パケットと IPv6 パケットのカプセル化や変換という MAP そのものの機能に加えて、NAT ルータとしての機能も提供します。このMAP における NAT ルータの機能は、IPv4 アドレスと IPv4 アドレスの変換を行うという意味で、NAT44 と呼ばれることもあります。
MAP CE は、ユーザからの IPv4 パケットの宛先を確認し、それが MAP ドメイン外の IPv4 アドレスであれば、MAP BR の IPv6 アドレスを宛先として IPv6 ネットワーク
で送信します。このとき、MAP-E の場合には IPv4 パケットを IPv6 パケットでカプセ
ル化し、MAP-T の場合には IPv4 ヘッダを IPv6 ヘッダに変換して送信します。
MAP による IPv4 パケットの送信では、トランスポート層プロトコルが使えるポート番号の範囲が MAP CE ごとに決められています。これにより、複数の MAP CE で単一のグローバル IPv4 アドレスを共有できるようになっています。この方法で IPv4 ア
ドレスとポート番号の範囲により MAP CE を特定する仕組みは、IPv6 アドレスのマッピングでもうまく利用されており、MAP ドメインで利用する IPv6 アドレスから自動的に計算できるような工夫が施されています。ユーザ側の MAP CE で通信のステートを管理できることから、サービス提供者側の装置ではステートレスな運用が可能です。

4.3 PSID
各 MAP CE が利用するポート番号群は、CE ごとに割り当てられた PSID（Port-Set
Identiﬁers）と呼ばれる識別子からアルゴリズムで決定されます。PSID からポート番

号をマッピングするアルゴリズムは、GMA（Generalized Modulus Algorithm）と呼
ばれ、RFC 7597 の Appendix B で紹介されています。
PSID は、16 ビットのポート番号の一部に対するマスク値として運用されます。あ

る MAP CE が扱えるポート番号は、この PSID をその一部として含むようなものです。

4.4 MAP ドメインで使う IPv6 アドレス

連続したポート番号でも飛び飛びのポート番号でも表現可能です。MAP CE は基本的に同じ PSID を使い続けるので、事実上、PSID が MAP CE に割り当てられたポート番
号を示すことになります。
図 4.2 に、16 ビットのポート番号に k ビットの PSID が含まれている状態を示します。各 MAP CE が利用できるポート番号は、PSID の部分を固定値とし、A および M の部分を任意の値とするようなものになります。ただし、IANA によってシステムポー
トとして割り当てられている番号を利用してしまわないように、A の値は 0 より大きくする必要があります（A の長さ a が 0 でない場合）
。
16ビット
A

PSID

M

aビット kビット▲

図 4.2 MAP-E および MAP-T の概要

説明だけだとわかりにくいので、例を見てみましょう。たとえば、a が 4、k が 8、PSID が 0xfe という割り当てを受けた MAP CE が使えるポート番号のセットを考えます。A が 0 となるポート番号は使えないので、この MAP CE が使えるポート番号は表4.1 に示す範囲です。

▲

表 4.1 a が 4、k が 8、PSID が 0xfe の場合の利用可能なポート番号のセット
ポート番号の最小値

ポート番号の最大値（括弧内は 10 進表記）

（括弧内は 10 進表記）

ポートセット 1

0x1fe0（8160）

0x1fef（8175）

ポートセット 2

0x2fe0（12256）

0x2fef（12271）

セット番号

...

...

...

ポートセット 14

0xefe0（61408）

0xefef（61423）

ポートセット 15

0xffe0（65504）

0xffef（65519）

4.4 MAP ドメインで使う IPv6 アドレス
MAP ドメインで使われる MAP CE の IPv6 アドレスは、PSID、MAP ドメインに共通の情報（Rule IPv6 プレフィックス）、それに宛先の IPv4 ネットワークを示す Rule
IPv4 プレフィックスから、図 4.3 のように決まります。

41

42

第4章

MAP-E による IPv4 インターネット接続

宛先IPv4アドレス（32ビット）
Rule IPv4プレフィックス

ポート番号（16ビット）
PSID

サフィックスMAP IPv6アドレス（128ビット）
Rule IPv6プレフィックス

サフィックスPSID

サブネットID

インターフェース識別子

EAビット

▲

図 4.3 IPv4 アドレスとポート番号は EA ビットとして IPv6 アドレスに埋め込まれる

MAP CE の IPv4 アドレスとポート番号の情報が埋め込まれている部分は、「EA ビット」と呼ばれます。
「サブネット ID」は、IPv6 プレフィックスが 64 ビット未満の場合に使われるフィールドです。
「インターフェース識別子」については、MAP-E が定義されている RFC 7597 では
図 4.4 のように生成方法が定義されています。
0

79 80

63 64

IPv6プレフィックス

0

111 112

IPv4アドレス

127

PSID

※IPv4アドレスがプレフィックスの場合には左詰めでゼロによりパディング、
PSIDが16ビット未満の場合は右詰めでゼロによりパディングされる。
IPv6プレフィックスが64ビットを超える場合は上位の0が上書きされる。

▲

図 4.4

MAP で利用されるインターフェース識別子

この MAP ドメインに共通の情報から生成される IPv6 アドレスから、MAP CE や
MAP BR の IPv4 アドレスとポート番号の情報が取り出せます。

例を使って説明しましょう。ある MAP CE で、EA ビットの長さと、Rule IPv4 プレ
フィックスおよび Rule IPv6 プレフィックスが、それぞれ以下のように設定されていたとします。

r EA ビットの長さ：16 ビット
r Rule IPv6 プレフィックス：2001:db8:0000::/40
r Rule IPv4 プレフィックス：192.0.2.0/24
ま た 、こ の MAP CE に 割 り 当 て ら れ た IPv6 ア ド レ ス の プ レ フ ィ ッ ク ス は
2001:db8:0012:3400::/56 だったとします。
Rule IPv4 プレフィックスの長さが 24 ビットなので、図 4.3 のサフィックスの部分の長さは 8 ビットと決まります。IPv6 のプレフィックス 2001:db8:0012:3400::/56

4.5 MAP ルールのサフィックス（先頭の 40 ビットに続く 8 ビット）の部分は十進表記で 18 なので、IPv4 アドレスは 192.0.2.18 です。

さらに、この CE では EA ビットの長さが 16 ビットとされているので、サフィック
スの 8 ビットを除くと PSID の長さが 8 ビットに決まります。IPv6 のプレフィックス
2001:db8:0012:3400::/56 のサフィックスに続く 8 ビットの部分は十進表記で 34なので、PSID は 34 とわかり、ここから GMA によりポート番号群が計算できます。

NOTE

この節で解説しているインターフェース識別子は、MAP-E の RFC である RFC 7597 に書いてある内容です。v6 プラスでは、RFC になる前の提案文書である Internet Draft（draft-ietf-softwire-map）に記載されているインターフェース識別子を採用しています。そのため、v6 プラスの MAP で利用される IPv6 アドレスでのインターフェース識別
子は、この節で解説されているものとは異なるという点にご注意ください。v6 プラスが採用している Internet Draft のバージョンは非公開であるため、本書では v6 プラス
で利用しているインターフェース識別子の具体的なフォーマットを割愛しています。

4.5 MAP ルール
MAP ドメイン内で MAP CE や MAP BR が使う共通の情報は、MAP ルールと呼ばれる情報として伝えられます。MAP ルールには、Rule IPv6 プレフィックス、Rule IPv4
プレフィックス、EA ビットの長さが含まれ、どのような場面で使われるかに応じて 3つの種類が規定されています。

r Basic Mapping Rule（RFC 7597）
MAP CE の設定にとって必須の MAP ルールで、4.4 節の方法で IPv6 アドレスから
IPv4 アドレスとポート番号を導出するのに使われるルールです。

r Forwarding Mapping Rule（RFC 7597）
MAP CE 同士の直接接続で使われる MAP ルールです。

r Default Mapping Rule（RFC 7599）
IPv4 パケットに該当する Forwarding Mapping Rule が存在しない場合に選択される MAP ルールです。外部との接続性を提供する MAP BR の IPv6 アドレスが設定されます。
v6 プラスでは、下記のような用途に応じて、3 種類すべてが利用されています。

43

44

第4章

MAP-E による IPv4 インターネット接続

r Basic Mapping Rule ： MAP ドメインの中で自分の所属するルールセットとの通信

r Forwarding Mapping Rule ： MAP ドメインの中で自分の所属するルールセット
以外との通信r Default Mapping Rule ： その他の IPv4 通信
MAP では、MAP CE および MAP BR 自身でポートのマッピングに使う MAP ルール

や PSID を何らかの方法で取得し、設定する必要があります。MAP CE に対して各種の設定情報を伝えるための標準的な仕組みとしては、IETF の softwire ワーキンググ
ループにて標準化された RFC 7598 に、MAP 用の DHCPv6 オプションがあります†1 。
ただし、v6 プラスでは DHCPv6 オプションによる MAP ルールの配布は行われていません（6.1 節を参照）。

4.6 MAP における IPv4 NAT
MAP の特長として、IPv4 インターネット接続サービス提供にあたって必要となる

グローバル IPv4 アドレスを節約できるという点が挙げられます。
グローバル IPv4 アドレスの節約については、従来、ISP のネットワークなどで大規模 NAT（CGN、Carrier Grade NAT）を導入するという手法が知られています。CGNによる NAT では、「ユーザによるプライベート IPv4 アドレスでのネットワーク」、「ISP
での CGN 配下の IPv4 ネットワーク」、「IPv4 インターネット」という 3 種類の IPv4
ネットワーク間で変換を行うことから、NAT444 と呼ばれます。
これに対し、図 4.1 における「NAT44」は、MAP CE に割り当てられたポート番号の範囲内で IPv4 アドレス同士の変換を実行する NAT の機能を示しています。NAT44
では、NAT444 と異なり、ユーザが IPv4 インターネットと通信するまでに NAT を 2段経由する必要がありません。
MAP-E が他の手法に比べて運用コストが低い背景には、サービス提供者側をステー

トレスにできるという点だけでなく、このように 2 段 NAT を回避できるという側面もあります。
IPv4 NAT については、CGN 全般の課題を含め、第 5 章で詳しく説明します。

†1

RFC 7598 は、MAP だけではなく、IPv6 ネットワークを通じて IPv4 を提供するための一般的な
DHCPv6 オプションを定義するものです。

4.6 MAP における IPv4 NAT

4.6.1 NAT44 機能の無効化
MAP-E でポート番号による IPv4 アドレス共有機能を使わず、NAT44 としての機能を無効化することもできます。その場合、DS-Lite の AFTR と互換性があるプロトコ
ルになります。実際、NAT44 としての機能を無効化した MAP CE で、MAP BR として
DS-Lite AFTR の IPv6 アドレスを設定すると、DS-Lite AFTR を通じて IPv4 インターネットとの通信が行えます。v6 プラスには「1 つの IPv4 アドレス割当プラン」という固定 IP サービスもあり、このサービスでは MAP CE の NAT44 としての機能を無効化することができる CPE もあります。

45

［書籍版では空白のページです］

第5章

IPv4 NAT

NAT（Network Address Translation）は、IP パケットが持つ IP アドレスを、別のIP アドレスに変換する技術です。

よく知られているのは、家庭内ネットワークなどのプライベート IPv4 アドレスとグローバル IPv4 アドレスの変換に利用されている NAT でしょう。一般に家庭内ネットワークでは複数台の機器から同時にインターネットに接続できますが、ISP などがユーザに割り当てる IPv4 アドレスは通常は 1 つだけです。この 1 つの IPv4 アドレスを使って、複数の機器から IPv4 インターネットに接続するために、IPv4 NAT が利用されています。
ユーザに IPv4 インターネットへの接続サービスを提供する v6 プラスでも、途中経路上の機器では IPv4 NAT が利用されています。そのため、v6 プラスについて理解するうえでは、一般的な家庭内ネットワークなどにおける IPv4 NAT の仕組みを知ると同時に、その制約についてもよく認識する必要があります。
さらに、v6 プラスの技術を正しく理解するうえでは、CGN（Carrier Grade NAT）と呼ばれる大規模 NAT に関連した課題にも目を向ける必要があります。CGN は、IPv4
アドレス在庫枯渇問題に関連して、サービス提供者側でグローバル IPv4 アドレスを節約するために導入されることが増えている技術です。CGN の導入により、複数の契約者間で 1 つの IPv4 アドレスを共有できますが、同時にさまざまな課題を引き起こすことも知られています。
一方、v6 プラスでは、MAP-E を採用していることで、CGN を導入することなく複数の契約者間で 1 つの IPv4 アドレスを共有できます。MAP-E の採用という技術的選択の意味を知るために、本章では CGN の概要と課題についても概説します。

48

第5章

IPv4 NATNOTE
NAT に関する最初の仕様は、1994 年 5 月に発行された RFC 1631 です。RFC 1631 で説明されている NAT は、IP アドレスだけを変換する技術でした。
これから本章で説明するように、現在の NAT では、TCP と UDP のポート番号を考慮することで、単一の IP アドレスを複数のユーザが同時に利用できるようになっています。
これを特に NAPT（Network Address Port Translation）と呼び、IP アドレスだけを変換する NAT とは区別する場合もよくあります。実際、2001 年に発行された RFC 3022
では、RFC 1631 で定義されていた NAT を「Basic NAT」
、Basic NAT と NAPT を合わせて「Traditional NAT」と表現しています。
ただし、昨今では NAPT のことを含んで NAT と表現することが多く、最近の RFC でも
NAT という表現で NAPT を含んでいることが多々あります。そのため、本書でも NATといったら基本的に NAPT を含むものとします。
なお、1999 年に発行された RFC 2663 では、NAT に関連する用語の定義が紹介されています。

5.1 一般の NAT の背景と仕組み
まずは、家庭内ネットワークなどで使われる一般の NAT とプライベート IPv4 アド
レスについて、その背景と仕組みを簡単に振り返ります。
両者は密接に関係がある仕組みであり、IPv4 アドレス在庫枯渇問題に対する短期的な解決策もしくは緩和策として、現在の IPv4 インターネットでは広く利用されています。v6 プラスが提供する IPv4 インターネット接続サービスにおいても、ユーザ側のネットワーク環境の重要な構成要素になっています。

5.1.1 家庭内ネットワークにおいて NAT が普及するまで
NAT は、インターネットが作られた当初は存在していなかった技術です。NAT という技術が誕生し、広く利用されるようになっていったのは、インターネットが一般家庭などにまで急速に普及し始めた 1990 年代以降のことでした。
NAT の普及を支えたのは「ISP から提供される 1 つのグローバル IPv4 アドレスを利用して、プライベートなネットワーク内で複数の機器をインターネットに接続する」という用途です。その状況を説明するために、日本における商用インターネット接続
サービスの黎明期までさかのぼってみましょう。
日本で一般向けの商用インターネット接続サービスが開始されたのは、1990 年代前半のことです。まだ一般家庭にインターネット専用の回線が敷設されていることは稀だったので、主に電話線を利用したダイアルアップ接続によりインターネットに接5.1 一般の NAT の背景と仕組み続していました。モデムと呼ばれる機器をコンピュータに接続し、それを通じてアク
セスポイントまで電話をかけ、そこからインターネットに接続するという方式です。
1 つの電話回線で同時にインターネットにつなげるパソコンは 1 台だけですが、一家に 1 台パソコンがあれば最先端だった時代です。いまのように、パソコンもテレビも
スマホも、あるいは家電までもがインターネットにつながる環境ではなかったので、複数の機器をインターネットに接続する必要は通常はありませんでした。
しかし、インターネットの普及につれて、パソコン自体の普及も進みました。さらに、従量課金の電話回線だけでなく、ISDN や ADSL といったインターネットへの常時接続サービスも登場してきました。その結果、家庭内で複数台のパソコンを同時にイ
ンターネットに接続したいという要求も増えるようになりました。
通常、IPv4 インターネットに接続したいユーザは、ISP と契約して IPv4 アドレスを割り当ててもらいます。このとき、一般的な ISP のサービスでは、ユーザに対してサ
ブネット単位で IPv4 アドレスが割り当てられるわけではありません。ISP に割り振りされている IPv4 アドレスのブロックから、「単一の IPv4 アドレス」がユーザに対して割り当てられます。
つまり、特別な契約をしない限り、ISP がユーザに提供する IPv4 アドレスは 1 つだ
けです。IPv4 アドレスが 1 つだけなので、ユーザがインターネットにつなげられる機器は同時に 1 つだけに制限されます。IPv4 インターネット側からは、その IPv4 アドレスを持つ 1 台の機器が接続されているように見えます。
このような環境で、複数の機器をインターネットに接続するために登場したのがNAT ルータです。個々の機器には「プライベート IPv4 アドレス」を設定し、それをNAT ルータによって「ISP から割り当てられた単一のグローバル IPv4 アドレス」に変換することで、複数の機器をインターネットと通信可能にします。本来ならば 1 台しかつなげないところを、NAT ルータが仲介することによって、複数の機器が同時に通信できるようにするわけです。NAT ルータによって IPv4 アドレスという限られた資源を複数の機器で共有している点がポイントです。

NOTE

家庭用の簡易な NAT ルータは、「SOHO ルータ」や「ブロードバンドルータ」、あるいは無線 LAN のアクセスポイントとしても機能する「無線 LAN ルータ」という名前で販売されています。

49

50

第5章

IPv4 NAT

5.1.2 プライベート IPv4 アドレスの登場
NAT ルータを利用する際、インターネットに直接接続されていない閉じた環境では、プライベート IPv4 アドレスが利用されます。プライベート IPv4 アドレスは、家庭内ネットワークのほか、マンションで共用回線を使う場合のマンション内 LAN、会
社内で使う LAN、スマホなどでのテザリングでも利用されます。
いまでは当たり前のように閉じた環境で使われているプライベート IPv4 アドレス
ですが、NAT と同様、インターネットが誕生した当初は存在していませんでした。プライベート IPv4 アドレスが IANA に予約されたことを示す RFC 1597 は、1994 年 3 月に発行されたものであり、途中で追加された仕様であることがわかります。
なお、RFC 1597 が発行された 1994 年 3 月は、NAT に関する最初の仕様である RFC
1631 が発行された 1994 年 5 月とわずか 2 ヶ月しか違いません。この 2 ヶ月というのは、RFC として発行されるまでのさまざまな議論や準備に伴う差にすぎず、両者は事実上同時に成立した仕組みです。実際、IETF では、NAT とプライベート IPv4 アドレスの両方について同時に議論されていました。
プライベート IPv4 アドレスが登場する以前も、インターネットと直接接続しない
閉じた環境で TCP/IP を使う通信システムは存在していました。そのようなシステム
では、通信手段として TCP/IP を利用する以上、それぞれの通信機器に対して何らかの IP アドレスを割り当てる必要があります。当時は、そのような閉じた環境であっても、世界で一意の IPv4 アドレスが利用されていました。
しかし、インターネットと通信するわけではない閉じた環境における通信であれば、その組織内においてのみ一意性が保たれる IPv4 アドレスを使えば十分です。インターネットと接続しない閉じた環境のために、世界で一意の IPv4 アドレスが消費されていけば、いつか IPv4 アドレスが足りなくなってしまいます。そこで「閉じた環境であれば自由に使ってよい IPv4 アドレスブロック」として生まれたのがプライ
ベート IPv4 アドレスです。
言い換えると、プライベート IPv4 アドレスは、1994 年ごろに考えられた IPv4 アド
レス在庫枯渇対策とも考えられます。IANA において IPv4 アドレスの中央在庫が実際に枯渇したのは 2011 年のことですが、もしプライベート IPv4 アドレスという概念が存在しなかったなら、IPv4 アドレス在庫の枯渇はもっと早かったことでしょう。

5.1.3 一般的な NAT の仕組み
家庭用の NAT ルータでは、インターネット側のことを指して「WAN」（Wide Area
Network）、家庭内ネットワーク側のことを指して「LAN」（Local Area Network）と

5.1 一般の NAT の背景と仕組み表現されていることがよくあります。以降の説明でも、この WAN および LAN という表現を使います。

ISP
割り当て

プライベートIPv4アドレス

プライベートIPv4アドレス▲

図 5.1

プライベートIPv4アドレスグローバル
IPv4アドレス

プライベートIPv4アドレスNAT
IPv4インターネット

グローバル IPv4 アドレス空間とプライベート IPv4 アドレス空間の境界で運用される NAT

図 5.1 のような環境で家庭内のパソコンからインターネットに接続するときはプラ
イベート IPv4 アドレスが使われます。プライベート IPv4 アドレスはあくまでも閉じたネットワークで利用されることを前提としたアドレスであり、インターネットで扱ってはなりません。実際、プライベート IPv4 アドレスが送信元や宛先になっているパケットは、インターネットでの転送が禁止されています。
そこで LAN 側の送信元プライベート IPv4 アドレスは、NAT ルータによりグローバ
ル IPv4 アドレスへと変換されます。NAT ルータには、「パケットに記載されている
IPv4 アドレスやポート番号をどのように変換するか」が設定されており、それに従って IPv4 パケットの情報が変換されます。
たとえば、LAN 側にあるユーザの手もとの機器から、NAT ルータを介して、インターネットにある Web サーバに接続するとします。このとき、ユーザの手もとの機器に設定されている IPv4 アドレスはプライベート IP アドレスなので、送信される IP
パケットの情報は以下のようになっています。

r 送信元 IPv4 アドレス：プライベート IP アドレス
r 宛先 IPv4 アドレス：Web サーバのグローバル IP アドレス
NAT ルータを経由してインターネットに送信される IP パケットでは、これらの情報のうち送信元 IPv4 アドレスが変換され、次のようになっています。

r 送信元 IPv4 アドレス：NAT ルータの WAN 側 IPv4 アドレス（ISP から割り当てら

51

52

第5章

IPv4 NATれたもの）

r 宛先 IPv4 アドレス：Web サーバのグローバル IP アドレス（変化しない）
NAT ルータによる変換の結果、「LAN 側での送信元 IPv4 アドレス」と「NAT ルー

タを経由した WAN 側での送信元 IPv4 アドレス」の組み合わせなど、LAN 側と WAN側のそれぞれのパケットの対応関係を表す情報が決まります。この組み合わせ情報は
NAT binding と呼ばれ、NAT ルータはその個々のエントリを NAT テーブルに保持し

ます。

NOTE
NAT binding は、RFC 3424、RFC 4787、RFC 5780 などで使われている用語で、
「結

合する」、
「組み合わせる」、「束ねて縛る」などの意味を持った “bind” という英単語に由来した表現です。「どのような対応づけが行われているのか」という文脈では、NAT
mapping と表現されることもあります。

NAT ルータの実装に依存しますが、多くの場合は以下の 9 種類の情報が NAT テー

ブルに保持されます。

r プロトコル（TCP、UDP、ICMP など）
r LAN 側での送信元 IP アドレス
r LAN 側での送信元ポート番号
r LAN 側での宛先 IP アドレス
r LAN 側での宛先ポート番号
r WAN 側での送信元 IP アドレス
r WAN 側での送信元ポート番号
r WAN 側での宛先 IP アドレス
r WAN 側での宛先ポート番号
これらの情報は、プロトコル以外を「LAN 側から見た送信元」、「LAN 側から見た宛先」、「WAN 側から見た送信元」、「WAN 側から見た宛先」とまとめて考えて、5 タプ
ルと表現されることもあります。それぞれ NAT ルータの実装などでは「内部ローカ
ル」、「内部グローバル」、「外部ローカル」、「外部グローバル」と呼ばれることもあります。

5.1 一般の NAT の背景と仕組み■ LAN 側から WAN 側に接続するにはNAT ルータを経由してインターネットへと転送された IPv4 パケットは、通常のIPv4 パケットと何も変わりません。つまり、インターネットを流れている IPv4 パケッ

トが NAT ルータを経由したものであるかそうではないのか、IPv4 パケットを見ただ
けでは判別できないのです。言い換えると、「インターネットで通信している相手との間に NAT があるかどうか」を判別しにくいということでもあります。
たとえば図 5.2 のように、同じ NAT ルータを利用する 2 人のユーザが、2 台の PC から同時に、インターネット上のある Web サーバと通信する場合を考えてみましょう。
NAT ルータを経由した IP パケットの送信元 IPv4 アドレスは、PC1 と PC2 の両方の IP

パケットともに、NAT ルータの WAN 側に設定された IPv4 アドレスに変換されます。

PC2
10.0.0.22（プライベート）PC1

送信元
198.51.100.33

198.51.100.33（グローバル）

10.0.0.11（プライベート）

PC1の通信 v4
PC2の通信 v4

10.0.0.1（プライベート）

NAT

送信元
198.51.100.33

IPv4インターネット▲

図 5.2 NAT ルータの例

Web サーバに到達した PC1 と PC2 の IPv4 パケットは、同じ送信元 IPv4 アドレスを持つパケットになっているので、Web サーバにとっては「同じ IPv4 アドレスからの通信」に見えてしまいます。このように、NAT ルータが介在する現在の一般的なイン
ターネット通信では、実際に通信をしている相手が複数台あったとしても、インター
ネット側からは 1 つに見えてしまうのです。
今度は、図 5.2 で NAT ルータが行っている作業をもう少し詳しく見るために、図5.3 のような状況を考えてみましょう。
NAT ルータの LAN 側ネットワークは 10.0.0.0/24 というプライベート IPv4 アド

レス空間です。それぞれの機器には次のようなプライベート IPv4 アドレスが設定されています。

r NAT ルータの LAN 側インターフェースの IPv4 アドレス：10.0.0.1（PC1 のデ
フォルトゲートウェイになる）

53

54

第5章

IPv4 NAT

PC1

10.0.0.11（プライベート）

宛先 203.0.113.99
送信元 10.0.0.11
宛先ポート番号 80
送信元ポート番号 11111

TCP SYN

198.51.100.33（グローバル）

宛先 203.0.113.99
送信元 198.51.100.33
宛先ポート番号 80
送信元ポート番号 33333

TCP SYN

203.0.113.99（グローバル）v4

v4

10.0.0.1

NAT

WebサーバＡ（プライベート）

IPv4インターネット▲

図 5.3 NAT ルータの例

r PC1 の IPv4 アドレス：10.0.0.11
一方、NAT ルータの WAN 側インターフェースには、ISP から割り当てられたグロー
バル IPv4 アドレスが設定されています。

r NAT ルータの WAN 側インターフェースの IPv4 アドレス：198.51.100.33
このような環境で、PC1 からインターネット上にある 203.0.113.99 というグロー
バル IPv4 アドレスを持つ Web サーバ A への通信を考えます。Web サーバ A では TCPの 80 番ポートで Web サーバを立ち上げています。
PC1 から最初に送信されるのは、Web サーバ A の TCP 80 番ポートに接続するための TCP SYN パケットです。この TCP SYN パケットの送信元ポート番号は 11111 番になっているものとしましょう。まとめると、この TCP SYN パケットには次のような情報が設定されています。

r 宛先 IPv4 アドレス：203.0.113.99
r 送信元 IPv4 アドレス：10.0.0.11
r 宛先ポート番号：80r 送信元ポート番号：11111
PC1 から Web サーバ A に対する TCP SYN パケットは、デフォルトゲートウェイである NAT ルータの LAN 側インターフェースへと送信されます。この TCP SYN パケットを受け取った NAT ルータは、TCP SYN パケットの送信元 IPv4 アドレスを 10.0.0.11
から 198.51.100.33 へと変更します。さらに、TCP SYN パケットの送信元 TCP ポー
ト番号も変更します。ここでは 11111 から 33333 に変更したとしましょう。

5.1 一般の NAT の背景と仕組み

r 送信元 IPv4 アドレス：10.0.0.11 → 198.51.100.33
r 送信元ポート番号：11111 → 33333
そして、これらの変更前と変更後の情報の組み合わせを、NAT ルータ内の NAT テー
ブルへと記録しておきます。NAT テーブルには表 5.1 のようなエントリが記録されることになります。

▲

表 5.1 NAT テーブルのエントリ 1

プロトコル

TCP

LAN 側での宛先 IPv4 アドレスとポート

203.0.113.99:80

LAN 側での送信元 IPv4 アドレスとポート

10.0.0.11:11111

WAN 側での宛先 IPv4 アドレスとポート

203.0.113.99:80

WAN 側での送信元 IPv4 アドレスとポート

198.51.100.33:33333

NOTE

ここでは送信元 IPv4 アドレスと送信元ポート番号の変更について説明していますが、これは「IP パケットのヘッダでそれぞれに該当するフィールドを変更する」という意味
では必ずしもありません。IP ヘッダと TCP ヘッダには、パケットに含まれるデータが途中で破損していないことを確認するために、パケットのデータをもとに計算されるチェックサムという値のためのフィールドがあります。NAT ルータではパケットを書き換えるので、このチェックサムを再計算したうえで、そのフィールドの値も変更する必要があります。NAT ルータで変更が必要になるのは、IP ヘッダにある IPv4 アドレスと TCP ヘッダにあるポート番号のフィールドだけではないのです。

NAT ルータで変換された TCP SYN パケットは、NAT ルータの WAN 側ネットワー

クインターフェースの IPv4 アドレスを送信元とするパケットとして、Web サーバ Aに到着します。Web サーバ A では、TCP SYN パケットの接続を許可するために、TCP
SYN+ACK パケットを返信します。この TCP SYN+ACK パケットは、送信元 IPv4 アド

レスが 203.0.113.99 で、宛先 TCP ポート番号は 33333 になっています。
NAT ルータは、WAN 側ネットワークインターフェースからパケットを受け取ると、
NAT テーブルを確認します。NAT テーブルには上記のようなエントリがあるので、203.0.113.99 からの宛先 TCP ポート番号 33333 のパケットは、PC1 へのパケットに変換して LAN 側へと転送します。結果、LAN 側にいる PC1 は特に何も気にするこ

55

56

第5章

IPv4 NATとなく Web サーバ A と通信できます。
では、このとき PC2 も Web サーバ A との通信を開始するとどうなるでしょうか。
NAT ルータの挙動をわかりやすくするために、PC2 から Web サーバ A への送信元
TCP ポート番号も 11111 になっているとします。
PC2 か ら Web サ ー バ A に 向 け た TCP SYN パ ケ ッ ト が NAT ル ー タ に 到 着 す ると 、NAT ル ー タ は TCP SYN パ ケ ッ ト の 送 信 元 IPv4 ア ド レ ス を 10.0.0.22 か ら
198.51.100.33 へ変更します。このとき、送信元 TCP ポート番号についても 11111

から別の値に変更するのですが、ここでは 33334 へ変更したものとしましょう。PC1からの通信のときとは、WAN 側に対する送信元ポート番号が異なっていることに注目してください。

r 送信元 IPv4 アドレス：10.0.0.11 → 198.51.100.33
r 送信元ポート番号：11111 → 33334
この変更についても、パケット情報の変更の記録が NAT テーブルに作成されます（表 5.2）。

▲

表 5.2 NAT テーブルのエントリ 2

プロトコル

TCP

LAN 側での宛先 IPv4 アドレスとポート

10.0.0.22:80

LAN 側での送信元 IPv4 アドレスとポート

10.0.0.1:11111

WAN 側での宛先 IPv4 アドレスとポート

203.0.113.99:80

WAN 側での送信元 IPv4 アドレスとポート

198.51.100.33:33334

WAN 側での送信元ポート番号が PC1 からのものとは異なるので、Web サーバ A から返信されてくる TCP SYN+ACK パケットの宛先 TCP ポート番号も異なります。それを受け取った NAT ルータでは、NAT テーブルを参照することで、このパケットをLAN 側に転送する際には PC2 宛のものに変換すればいいとわかります。
NAT ルータでは、このような仕組みにより、グローバル IPv4 アドレスで運用されているインターネット側から NAT ルータに到達したパケットをプライベートネット
ワーク内の適切な機器へと転送処理します。IP アドレスとポート番号の変換を同時に行うことで 1 つの IPv4 アドレスを複数台で有効に利用できるようにする仕組みがNAT というわけです。

最後に、視点を変えてインターネット側から LAN 側との通信を考えてみましょう。

5.1 一般の NAT の背景と仕組み

上記で説明した、同じ NAT ルータを利用する 2 台の PC からの Web サーバ A への通信
は、Web サーバ A からはどのように見えるのでしょうか。
言われてみれば当たり前の話だと思いますが、Web サーバ A 側からは、1 つのグ
ローバル IPv4 アドレス 203.0.113.99 から 2 つの TCP のセッションが張られている
ようにしか見えません。つまり、インターネットの側にあるサーバからの視点で見ると、PC1 と PC2 という別々の機器からの通信には見えません。1 つの IPv4 アドレスを複数台で使えるようにする NAT ルータの存在は、実際にどの端末がインターネットに接続しているかをわかりにくくする存在だといえるのです。

NOTE
TCP/IP では、送信元アドレスとポート、宛先アドレスとポート、およびプロトコルの5 種類の情報で決まる 1 つの通信をフローと呼びます。NAT ルータでは「同じフローに属するパケットが同じフローとして扱われる」ようにパケットが変換されているともい
えます。

■ NAT テーブルからの削除
NAT ルータでは、LAN 側からの通信で生成した NAT テーブルのエントリをいつまでも保持するわけではありません。NAT ルータは物理的な機器であり、記録などに使える資源は有限です。通信がまったく行われていないセッションに割かれている資源
は、いつか解放する必要があります。NAT テーブルでエントリを継続する期間は生存時間や lifetime と呼ばれます。lifetime をどのように設定するかは、NAT ルータの性能にも影響する重要な要素であり、NAT ルータの実装や設計に依存します。
一見すると、通信セッションが完了したタイミングでエントリを削除すればよさそうに思えるかもしれません。しかし、たとえば Web ブラウジング中にいきなりパソコンの通信ケーブルを抜いてしまい、さらにパソコンの電源を落とした状況を考えてみましょう。Web サーバと通信している最中のパソコンは、Web サーバに対して「TCP接続を終了する」という連絡ができないまま電源を落とされてしまっています。このように、インターネットでは通信セッションが突然途切れることもあるので、「確実にセッションが切れた」判断ができないことが少なくないのが現状です。
この場合、Web サーバ側にはパソコン側で起きた変化を知る術がないので、通信相手が復帰した場合に備えて TCP 接続の状態を一定時間維持します。つまり TCP では、
いったん接続が成立すると、相手が突然音信不通になっても一定の期間は TCP 接続状
態が維持されるのです。

57

58

第5章

IPv4 NAT

Web サーバでは、その一定時間が経過すれば TCP 接続の状態を破棄できます。しかし、途中経路には NAT ルータもあります。NAT ルータには、Web サーバにおいて
TCP 接続の状態が破棄された瞬間を知ることはできません。NAT ルータがある環境

では、LAN 側のパソコンと WAN 側の Web サーバのどちらか片方、もしくは両方が明示的に TCP 接続を終了せずに TCP セッションが消えてしまったような場合、NAT
ルータの NAT テーブルに使われることがないゴミが残ってしまうのです。
そのため NAT ルータでは、NAT テーブルに含まれている利用されていない TCP 通
信を削除するタイミングを自身で決める必要があります。「この TCP 通信は破棄された」と判断するタイミングが lifetime というわけです。

5.1.4 TCP 以外のプロトコルの扱い
ここまでは TCP 通信を例に一般的な NAT について説明してきましたが、NAT は
TCP 以外のプロトコルにも対応しています。ただし、IPv4 パケットの送信元 IPv4 ア

ドレスとポート番号、宛先 IPv4 アドレスとポート番号をそれぞれ別のものに変換するという単純な処理だけでは実装できません。
まず UDP については、TCP 同様にポート番号があるので、UDP のポート番号をもとに NAT テーブルにエントリを追加することで基本的な動作は実現できます。ただし UDP には、TCP における SYN、FIN、RST のような「通信の開始や終了を明示する
パケット」が存在しません。そのため TCP のように接続の開始や維持が明示的でなく、その点で NAT での扱いが難しくなります。NAT ルータの実装では、「LAN 側から通信が発生したときの UDP パケットのポート番号を参考にして NAT テーブルのエントリを追加しつつ、該当するエントリが一定時間使われなければタイムアウトする」
といった処理が施されています†1 。
ICMP も、UDP と同様に、通信の開始と終了を把握するのが困難なプロトコルです。

そのうえ、ICMP には TCP や UDP におけるポート番号のような通信のフローを明確にする識別子が存在しないので、NAT での扱いはさらに難しくなります。NAT ルータの実装では、ICMP パケットのタイプフィールドや中に含まれているメッセージの内容に応じ、ICMP パケットが変換されています。ICMP パケットが運んでいるデータ部
分に IPv4 アドレスが記述されている場合には、その情報も適切に変更する必要があります。
さらに NAT における扱いが困難なプロトコルとして、ファイル転送で利用され†1

タイムアウト処理自体は TCP のエントリに対しても実装が必要です。前述のように、TCP においても FIN や RST などが送信されずに接続が終了する状況が考えられるからです。

5.1 一般の NAT の背景と仕組み

る FTP（File Transfer Protocol）や、IP 電話などで使われる SIP（Session Initiation
Protocol）があります。FTP や SIP では、TCP セッションが確立した後、その TCP セッ

ションを通じて IPv4 アドレスの情報をやり取りします。同時に張られた複数のセッションを識別して既存セッション中で新規セッションの情報を伝えるために、ペイロード中に IPv4 アドレスやポート番号を情報して含むことがあるのです。そのため
NAT ルータでは、FTP や SIP の IPv4 パケットを変換する場合、IP ヘッダだけではな

く TCP パケットのデータ部分に含まれるメッセージの中身も変換する必要があります。TCP パケットの中身を含めて変換する機能は、もはや単なる NAT ではなく、ALG（Application Level Gateway）と呼ばれています。
■ ALG
SIP や FTP は、ペイロードに IP アドレスに関する情報を含みます。そのようなパケットで NAT ルータが介在し、IP ヘッダやトランスポート層のヘッダを変更しただ
けだと、通信が成立しなくなる可能性があります。ペイロードに IP アドレスなどの情報を含む通信では、NAT ルータにおいてペイロードの中身も含めた変換が必要なのです。
この問題を解決するため、各プロトコルの中身を理解しつつ通信に利用されるパケットの変換を行う機器を、ALG（Application Level Gateway）と呼びます。NATを考えるうえでは、いわゆる NAT だけではなく、ALG の存在も忘れないことが重要です。
なお、ALG は万能ではありません。たとえば、IPsec を利用して通信が暗号化されている場合には、変換が必要な IP アドレスなどの情報がパケットの暗号化された部分に含まれている可能性があります。途中経路にある NAT ルータは、ALG としての機能を持っていても、その通信の内容を復号できなければパケットを適切に変換できません。

5.1.5 通常の NAT と v6 プラスの NAT の違い
本節では、プライベート IPv4 アドレスとグローバル IPv4 アドレスを変換するという、一般的な NAT ルータの動作を簡単に説明しました。最後に、v6 プラスにおけるNAT と一般的な NAT の違いを整理しておきます。
v6 プラスでは、フレッツ網で IPv6 IPoE を利用し、JPIX と IPv4 over IPv6 トンネルを張ることで、プライベート IPv4 アドレス空間から IPv4 インターネットへと接続できます。その際、NAT に対してグローバル IPv4 アドレスを割り当てているのは JPIXになります。すなわち、WAN 側のグローバル IPv4 アドレスとして設定されるのは、

59

60

第5章

IPv4 NAT

JPIX に割り振られたグローバル IPv4 アドレスです。
v6 プラスにおける NAT は、第 4 章で説明した MAP-E によるものであり、通常のNAT とは異なる部分があります。通常の NAT では、図 5.4 のように、1 つの回線契約に対して 1 つのグローバル IPv4 アドレスが割り当てられます。

グローバル
IPv4アドレス

ISPなど
198.51.100.33
198.51.100.36
198.51.100.39

割り当て

198.51.100.34
198.51.100.37
198.51.100.40
198.51.100.35
198.51.100.38
198.51.100.41▲

図 5.4 通常の NAT

一方、v6 プラスが利用している MAP-E では、図 5.5 のように複数の回線契約ごとに 1 つのグローバル IPv4 アドレスが割り当てられます。そして、この 1 つのグローバ
ル IPv4 アドレスを複数の回線契約で共有するために、それぞれ TCP や UDP におけるポート番号の範囲が割り振られるようになっています。

IPv4アドレス同一

IPv4アドレス同一

IPv4アドレス同一

グローバル
IPv4アドレス＋ 利用可能な
ポート番号

ISPなど
198.51.100.33
12240〜12255

198.51.100.33
16320〜16335

198.51.100.33
20400〜20415

198.51.100.34
12240〜12255

198.51.100.34
16320〜16335

198.51.100.34
20400〜20415

▲

図 5.5

v6 プラスでの NAT

割り当て

5.2 いわゆる「NAT 越え」

v6 プラスでは、NAT ルータが自分自身に割り当てられたグローバル IPv4 アドレスとポート番号の範囲を知るのに、MAP-E において必要な情報を配信するためのルール
配信サーバを利用しています。NAT ルータは、JPIX のネットワークで運用されているルール配信サーバから必要な情報を取得し、指定されたポート番号の範囲での NAT。
が可能になります（図 5.6）
JPIX

プライベートIPv4アドレス

プライベートIPv4アドレス

プライベートIPv4アドレスグローバル
IPv4アドレス＋利用可能な
ポート番号

プライベートIPv4アドレス

ルール配信
サーバ

MAP CE（NAT）

IPv4インターネット▲

図 5.6 ルール配信サーバで MAP-E に必要な情報を配信

したがって v6 プラスで利用される NAT ルータでは、通常の NAT ルータとしての機能だけでなく、MAP-E のルール配信サーバから割り当てられる範囲のポート番号のみを利用した NAT を実行できる必要があります。これには、「v6 プラス対応 NATルータ」を利用するか、「既存の NTT ホームゲートウェイに対して JPNE ソフトウェ
ア（7.2 節を参照）をインストールする」という 2 通りの方法があります。

NOTE
MAP-E の仕組みについては第 4 章を参照してください。また、MAP-E を活用した v6 プ

ラスのサービスの詳細については、第 6 章で説明します。

5.2 いわゆる「NAT 越え」
NAT ルータの内側にあるネットワークは、プライベート IPv4 アドレスで運用されています。インターネットからは分離されたネットワークですが、内側から外側であるインターネットへの通信が開始された時点で NAT テーブルのエントリが作成され、それによってインターネット側から内側への通信が可能になる場合もあります。言い換えると、インターネット側から内側への通信が可能な場合でも、そのような通信の開始が可能であるとは限りません。また、インターネット側から観測可能なのはあく

61

62

第5章

IPv4 NAT

までもグローバルアドレスなので、NAT の内側で運用されている機器は観測できず、したがってインターネット側から内側の機器を指定する手段も通常はありません。
インターネット側から NAT の内側に向けた通信は、NAT 機器の実装依存という面はありますが、一般には著しく制限されています。これを可能にしたい場合には、内側にいる通信相手をどのように指定すればよいかを、インターネット側のサーバなどが知る手段が必要です。そのような手法をめぐる課題は UNSAF（UNilateral
Self-Address Fixing）と呼ばれており、RFC 3424 で満たすべき要件が定義されています†2 。
UNSAF に対する具体的なプロトコルとしては、STUN（Session Traversal Utilities
for NAT）や TURN（Traversal Using Relays around NAT）といったものがあります。STUN や TURN は、P2P 的な接続を利用している対戦ゲームや、音声およびビデ
オ通話のアプリケーションなどで使われています。

5.2.1 STUNNAT の内側で運用されている機器は、自分自身ではインターネット側で見えている自分のグローバル IPv4 アドレスを知ることができません。これは P2P 的な接続を行うときに問題になります。
たとえば、図 5.7 のような、NAT で運用されたネットワークに接続された機器同士による通信を考えます。図 5.7 の PC A と PC B は、それぞれ別のネットワークに接続されていますが、両方とも自分自身の IPv4 アドレスを 10.0.0.2 としています。このとき、PC A も PC B も、自分自身の情報だけでは、NAT ルータの外側で使われているグローバル IPv4 アドレスを知ることができません。このため、このままでは PC Aと PC B の間で P2P の通信を開始しようと思っても、相手の IPv4 アドレスを指定できません。
プライベート
IPv4ネットワーク
PC A

プライベート
IPv4ネットワーク

NATルータ10.0.0.2（プライベート）

192.0.2.99（グローバル）

NATルータインターネット

203.0.113.0（グローバル）

PC B

10.0.0.2（プライベート）▲

図 5.7 NAT で運用されたネットワークに接続された機器同士†2

RFC 3424 は IAB による Informational な RFC です。

5.2 いわゆる「NAT 越え」

このような状況で P2P 的な通信を実現するためのツールとして考えられたのがSTUN です。図 5.8 のように、グローバル IPv4 アドレスを持つ STUN サーバに対してNAT ルータの内側で運用されている PC が問い合わせを行い、STUN サーバが PC A

に対して「PC A からの通信で利用されているグローバル IPv4 アドレス」などを伝えます。
STUNサーバ

プライベート
IPv4ネットワーク

PC A

NATルータ

192.0.2.99

10.0.0.2（グローバル）（プライベート）「私から見えるあなたの IPv4 アドレスは192.0.2.99 です」

インターネット

プライベート
IPv4ネットワーク

PC B

203.0.113.0（グローバル）

10.0.0.2（プライベート）▲

図 5.8 STUN によるグローバル IPv4 アドレスの把握

NOTE
STUN は、最初は RFC 3489 として定義されました。RFC 3489 での STUN は “Simple
Traversal of UDP through NAT” を意味していました。しかし、RFC 3489 は 2008 年に RFC 5389 によって上書きされる形で廃止となり、この RFC 5389 において STUN は“Session Traversal Utilities for NAT” の略とされました（RFC 5389 は 2020 年に RFC
8489 によって廃止されています）。RFC 5389 によって名前だけではなくプロトコルの中身も変わった STUN に対し、RFC 3489 で定義されていたプロトコルは旧 STUN と呼ばれることもあります。

5.2.2 TURN
NAT ルータによっては、そもそも外部との直接通信ができない場合もあります。そのような場合には、通信を仲介する機器の手助けが必要になります。その仲介のためのプロトコルが、RFC 5766 で定義されている TURN です。TURN は STUN に対する拡張として定義されています（RFC 5766 のタイトルの趣旨も “Relay Extensions to
STUN” です）。
TURN の動作環境例を図 5.9 に示します。TURN サーバは、STUN による NAT 越え

が困難な環境に対応するための中継サーバとして機能します。TURN クライアント
は、NAT の内側のプライベート IPv4 アドレス環境に接続されており、TURN サーバ
を経由して「ピア」と呼ばれる他のノードと通信が可能になります。

63

64

第5章

IPv4 NATTURNサーバ

プライベート
IPv4ネットワーク

中継

NATルータプライベート
IPv4ネットワーク

NATルータPC A（TURNクライアント）

インターネット

▲

図 5.9

PC B
（ピア）

TURN の概要

5.2.3 NAT における「ポート開放」
NAT ルータが特定のポート番号へのパケットをインターネットから受け取ったときに、そのパケットを NAT の内側の指定した機器へと転送するという手法もあります。こうした方法は「ポート開放」と呼ばれることもあります。
「ポート開放」は、技術的に定義のある用語というわけでなく、指定したポート番号に対する「インターネット側から内側への通信」を可能にする設定を指す慣用的な表現です。ある特定のポート宛のパケットを通過させることから、「ポートフォワー
ディング」と表現されることもあります。5.1.3 項では、「内部から外部」に送信される TCP SYN などに伴って NAT テーブルが追加されることを紹介しました。ポート開放を行うと、さらに「外部から内部」に対してトラフィックを開始することも可能にするような NAT テーブルのエントリが追加されます。
たとえば、家庭内 LAN にある 10.1.2.3 というプライベート IPv4 アドレスを持つ機器で、その TCP 54321 番ポートに対してインターネット側からアクセスができるようにしたいという状況を考えてみてください。家庭内 LAN に設置した NAT において「ポート開放」が設定されていない場合は、そのための NAT テーブルのエントリが存在せず、インターネット側からの SYN パケットは NAT ルータで破棄されます（図5.10）。

ここで NAT ルータにおいて、インターネット側からの TCP 54321 番ポートへの転送が可能になるように NAT テーブルにエントリを追加することで、インターネット
側から 10.1.2.3 の機器への TCP 54321 番への SYN パケットが転送されるようになります（図 5.11）。
実際に NAT ルータでポート開放を行う手法としては、UPnP IGD（Universal Plugand Play Internet Gateway Device）というプロトコルを利用する方法と、手動でNAT ルータの転送設定を追加する方法があります。
UPnP IGD は、パソコンなどのクライアントが NAT ルータに対してポート番号な5.2 いわゆる「NAT 越え」

TCPポート54321で待ち受け中

198.51.100.33

203.0.113.99（グローバル）（ゲームのホストを立ち上げているなど）（グローバル）10.1.2.3

PC2（プライベート）

NAT

PC1

NATテーブルにエントリがないので破棄される

v4

TCP SYN

宛先 198.51.100.33
送信元 203.0.113.99
宛先ポート番号 54321
送信元ポート番号 61111

IPv4インターネット▲

図 5.10 ポート開放なし

TCPポート54321で待ち受け中

198.51.100.33（プライベート）v4

TCP SYN

宛先 10.1.2.3
送信元 203.0.113.99
宛先ポート番号 54321
送信元ポート番号 61111（グローバル）

NAT

10.1.2.3

PC1

203.0.113.99（グローバル）（ゲームのホストを立ち上げているなど）

（ポート
開放中）

PC2
v4

TCP SYN

NATテーブルに 宛先 198.51.100.33
エントリがある 送信元 203.0.113.99
54321
ので転送される 宛先ポート番号
送信元ポート番号 61111

IPv4インターネット▲

図 5.11 ポート開放あり

どを指定するという仕組みです。UPnP IGD を使う場合には、NAT ルータ側で UPnPIGD を利用する設定を有効にしたうえで、UPnP IGD に対応したアプリケーションをユーザが利用する必要があります。ただし、UPnP IGD はセキュリティ上の理由で有効にすることが推奨されていない場合もあるので注意してください。
手動で転送を設定する場合は、NAT テーブルへの追加が必要な TCP や UDP などのプロトコルとポート番号をユーザ自身が把握し、それらを各 NAT ルータが提供している手順で設定することになります。

5.2.4 v6 プラスでの「ポート開放」
v6 プラスでも、IPv4 NAT を行うのはユーザ側に設置されている NAT ルータです。

そのため、NAT の外側から内側への通信が必要になるアプリケーションを利用した
い場合には、前述した STUN や TURN を利用して NAT 越えのためのポート番号を自動的に取得するか、NAT ルータに対する「ポート開放」の設定が必要になります。
v6 プラスで IPv4 NAT のポート開放を設定するときに注意が必要なのは、NAT ルー

65

66

第5章

IPv4 NAT

タから IPv4 インターネットへと送信されるパケットの TCP や UDP のポート番号が、JPIX によって割り振られた範囲内になっている必要がある点です。JPIX によって割り振られた範囲外のポート番号を利用してポート開放を設定することはできません。
その NAT ルータに割り振られていないポート番号を開放を試みる設定はエラーになります。仮に NAT ルータにおいて範囲外のポート番号の設定そのものに成功したとしても、その NAT ルータまでパケットが届かないため、通信が成功しないのです。これは、範囲外のポート番号を宛先とするパケットは JPIX にある MAP BR（第 4 章を参照）で破棄されてしまい、ユーザの NAT ルータまで到達できないからです。
一方、MAP-E のルール配信サーバから割り当てられたポート番号の範囲内であれ
ば、インターネット側からユーザの NAT ルータまで、そのポート番号を宛先とするパケットが届きます。したがって v6 プラスでポート開放を設定する際は、MAP-E のルール配信サーバから割り当てられたポート番号に合致した範囲内で NAT テーブルのエントリを手動で追加する方法をとることになります。
また、v6 プラスではない通常のインターネット接続サービスを利用した IPv4 NAT
では、UPnP IGD によるポート開放が利用されることもあります。しかし UPnP IGD
は、多くの場合、v6 プラスの環境とは相性が良くありません。v6 プラスでは、図 5.5のように、複数の契約者が 1 つのグローバル IPv4 アドレスを共有し、各契約者にはある範囲のポート番号が割り当てられます。この各契約者に割り当てられているポート
番号とは異なるポート番号を UPnP IGD クライアントが指定した場合、NAT ルータにおけるポート開放が設定されたとしても、そのポート番号に対するパケットがイン
ターネット側から NAT ルータへと届くことがないのです。UPnP IGD クライアントが組み込まれたアプリケーションにおいて、「NAT ルータに設定されている、MAP-E のルール配信サーバから割り当てられたポート番号を STUN や TURN などを用いて把握し、そのうえで NAT ルータに対する要求を行う際に状況に合致するポート番号を指定する」ことが可能であれば、UPnP IGD によるポート開放が利用できるでしょう。

5.3 NAT 機器に要求される挙動
前節では多くの NAT の動作を「NAT ルータの実装に依存する」として説明しました。このことからわかるように、NAT には明確な仕様が決まっているわけではありません。
とはいえ、NAT 機器に要求される挙動については、RFC 4787 と RFC 5382 でまとめられています。あくまでも大まかな要求事項であり、NAT という仕組みを詳細に定義しているわけではありませんが、NAT 越えに影響を与える仕様なども紹介され

5.3 NAT 機器に要求される挙動ています。

r RFC 4787 “Network Address Translation (NAT) Behavioral Requirements for
Unicast UDP”

ユニキャスト UDP における NAT 機器の挙動とそれに対する要求がまとめられています。

r RFC 5382 “NAT Behavioral Requirements for TCP”
RFC 4787 に書かれている内容を前提として、TCP における NAT 機器の挙動とそれに対する要求がまとめられています。
NAT 機器の挙動を論じるにあたり、RFC 4787 と RFC 5382 では、「マッピング」と「フィルタリング」という 2 つの側面に分けて考えられています。

r NAT 内部で使われる IPv4 アドレスおよびポートと、外部で使われる IPv4 アドレ
スおよびポートの対応（マッピング）には、どういう基準が必要か

r NAT 内部への転送を許可（フィルタリング）するには、外部からのパケットの何を判断基準とすべきか
たとえば、家庭内ネットワークから IPv4 インターネット宛のパケットに含まれる情報を NAT ルータでどのように変換するかは、マッピングに依存します。一方で、外部から内部への通信の許可や拒否をどう考えるかは、フィルタリングの方法に依存します。マッピングとフィルタリングはまったく別の動作なので、どのようなフィルタリング方法を採用するかがマッピングの手法に依存することはありません。
いわゆる NAT 越えを考えるときは、越えるべき NAT 機器がどのようなマッピング
手法とフィルタリング手法を採用しているかが重要になります。それにより NAT 越えを行う際に利用可能なアプローチが推測可能となるからです。

5.3.1 NAT 機器におけるマッピングの動作の種類
プライベート IPv4 アドレス空間から送信されるパケットは、NAT 機器により、グ
ローバル IPv4 アドレス空間用のパケットへと書き換えられます。NAT 内部のノード
から外部のノードへの通信が開始されると、NAT 機器では、パケットの送信元 IPv4
アドレスとポート番号を変換して送り出します。
いま、図 5.12 のような状況で、NAT 内部のノード X から NAT 外部のノード Y1 お
よびノード Y2 への通信を考えます。
図 5.12 では、ノードの IPv4 アドレスを大文字で、ポート番号を小文字で表しています。ノード X からノード Y1 に送信されるパケットの送信元は X:x、宛先は Y1:y1

67

68

第5章

IPv4 NAT

内部
X

X:x

外部

NAT

X:x

Y1:y1 Y1

X1':x1'X2':x2'
Y2:y2

Y2

▲

図 5.12 内部ノードから外部ノードへの 2 つの通信です。NAT 機器により、送信元は X1':x1' に変換されます。
ここで、同じノード X からノード Y2 へ通信を開始したとします。そのパケットの送信元は X:x、宛先は Y2:y2 です。NAT 機器では、やはり送信元を X2':x2' に変換しますが、このとき同じノード X からの通信として、Y1 への通信のときと同じ X1':x1'
を X2':x2' として使うべきでしょうか。それとも、宛先が別であれば送信元のマッ
ピングも別にして、X1':x1' とは異なる X2':x2' を使うべきでしょうか。
RFC 4787 では、この問題について、EIM、ADM、APDM という 3 種類の動作が示されています。

r EIM（Endpoint-Independent Mapping、エンドポイント非依存マッピング）
X:x が同じであれば、宛先が Y1:y1 か Y2:y2 によらず、X1':x1' と X2':x2' として同じ値を使います。つまり、NAT 内部の IPv4 アドレスとポート番号の組を、イ
ンターネット側にあるノードの IPv4 アドレスとポート番号によらず同じものに変換するという動作です。
たとえば NAT 内部から、グローバル IPv4 アドレス 192.0.2.1 を持つインターネッ
ト側のノードと、UDP で通信したとします。このとき、NAT 機器によって変換されたインターネット側での送信元ポート番号が 30000 であったとしましょう。さらに同じノードから、別のグローバル IP アドレス 203.0.113.2 に対する通信が行われたときも、192.0.2.1 に対する通信のときと同じ 30000 というポート番号を再利用するのが EIM です。文字どおり、インターネット側のエンドポイントには依存せず、マッピングを再利用します。
EIM の概要を図 5.13 に示します。

r ADM（Address-Dependent Mapping、アドレス依存マッピング）
同じ内部ノードから、同じグローバル IPv4 アドレスを持つインターネット側の

5.3 NAT 機器に要求される挙動

送信元 X':x'

NAT

Y1

v4

X
Y2

v4

送信元 X':x'▲

図 5.13 EIM（エンドポイント非依存マッピング）

ノードへの通信では、マッピングを再利用します。異なるグローバル IPv4 アドレスを持つノード宛の通信は、同じ NAT 内部のノードからの通信であっても、異なるマッピングとします。
ADM の概要を図 5.14 に示します。

送信元 X':x1'

NAT

Y1

v4
v4

X

送信元 X':x1'

v4

Y2

送信元 X':x2'▲

図 5.14 ADM（アドレス依存マッピング）

r APDM（Address and Port-Dependent Mapping、アドレスとポート依存マッピン
グ）
ADM に加えて、さらにインターネット側ノードのポート番号が同じ場合にのみマッピングを再利用します。
APDM の概要を図 5.15 に示します。
RFC 4787 と RFC 5382 では、NAT 機器が満たすべき必須の要件として、EIM によるマッピングを挙げています。EIM により、UNSAF のプロセスが実行できるようになるからです。v6 プラスにおける NAT でも、v6 プラス対応メーカーの実装に依存しま
すが、EIM を実装することが推奨されています。

69

70

第5章

IPv4 NAT

送信元 X':x1'

Y1

v4

NAT

v4

X

送信元 X':x2'

Y2

v4

内部

送信元 X':x3'

外部▲

図 5.15 APDM（アドレスとポート依存マッピング）

5.3.2 NAT 機器におけるフィルタリングの動作の種類
NAT 内部のノード X（X:x）から、外部のノード Y（Y:y）への通信が新たに開始されると、NAT 機器では X:x と Y:y の対応が決まります。このとき、送信元を Y:y とするパケットを外部から受け取った NAT 機器は、それを内部に転送すべきでしょうか。それともフィルタリングすべきでしょうか。
RFC 4787 では、フィルタリングの動作についても 3 種類の基準を示しています。

r EIF（Endpoint-Independent Filtering、エンドポイント非依存フィルタリング）
送信元によらず、内部ノード X:x を宛先としないパケットのみが破棄されます。
つまり、内部ノード X:x から任意のグローバル IPv4 アドレスへの通信があれば、NAT 内部へとパケットが転送される穴が NAT 機器に構築されます。
EIF の概要を図 5.16 に示します。

宛先 Y1:y1
送信元 X:xv4

宛先 X:x
送信元 Y1:y1'

X

Y1

v4

v4

NAT X:x▲

図 5.16

宛先 X:x
送信元 Y2:y2

Y2

EIF（エンドポイント非依存フィルタリング）5.3 NAT 機器に要求される挙動

r ADF（Address-Dependent Filtering、アドレス依存フィルタリング）
内部ノード X:x を宛先としないパケットは破棄されます。それに加えて、内部からの送信先になったことがある外部の IPv4 アドレスを送信元とする返信パケット
のみを NAT 内部へと転送します。つまり、NAT 内部からグローバル IPv4 アドレスに対してパケットが送信されたことがあれば、そのグローバル IPv4 アドレスから
NAT 内部へのパケットを通過させるという動作です。
ADF の概要を図 5.17 に示します。

宛先 Y1:y1
送信元 X:xv4

宛先 X:x
送信元 Y1:y1'

X

Y1

v4

v4

NAT X:xY2

宛先 X:x
送信元 Y2:y2▲

図 5.17 ADF（アドレス依存フィルタリング）

r APDF（Address and Port-Dependent Filtering、アドレスとポート依存フィルタリ
ング）
ADF に加えて、インターネット側からのパケットの送信元のポート番号についてもフィルタリングの対象にします。つまり、APDF が採用されている NAT では、内部からの送信先になったことがある外部の IPv4 アドレスとポートを送信元とする返信パケットのみを NAT 内部へと転送します。
APDF の概要を図 5.18 に示します。

宛先 Y1:y1
送信元 X:x

X

v4

Y1

v4

宛先 X:x
送信元 Y1:y1
v4

宛先 X:x
送信元 Y1:y1'

NAT X:xv4

Y2

宛先 X:x
送信元 Y2:y2▲

図 5.18 APDF（アドレス依存フィルタリング）

71

72

第5章

IPv4 NAT

注意が必要なのは、マッピングとフィルタリングは異なる概念である点です。つまり、マッピングの動作が EIM であるか ADM であるか、あるいは APDM であるかは、フィルタリングの動作に影響しません。NAT 機器の挙動は、マッピングの挙動とフィルタリングの挙動の組み合わせとしてとらえられます。たとえば、マッピングの挙動
は EIM である一方で、フィルタリングの挙動は APDF という実装も考えられます†3 。
RFC 4787 では、通信の透過性が重要である場合には EIF によるフィルタリングを推奨しています。UNSAF では、外部からの通信が NAT 機器を越えられるようにする
ために、通信に使うべきアドレスとポート番号を測定します。NAT 機器を通してリ
アルタイムメディアやオンラインゲームなどの P2P 的な接続を利用できるようにする
ことが考慮された要件だといえるでしょう。
v6 プラスにおける NAT では、フィルタリングは v6 プラス対応メーカーの実装に依存します。

5.3.3 NAT 機器が満たすべき要件
NAT 機器に対する要求仕様の詳細については、本節で説明したアドレスとポートのマッピングおよびフィルタリングに関する挙動をはじめ、さまざまな NAT の挙動に対する考慮が必要になります。RFC 4787 では NAT の挙動を次のように分類しています。

r アドレスとポートのマッピング
r ポート割り当てr ポートパリティ（ポート番号の偶奇）r ポートの連続性
r マッピングの更新
r 外部 IP アドレス空間と内部 IP アドレス空間の競合に関する挙動
r フィルタリングr ヘアピニング（NAT 機器を通じたエンドノード同士の通信）r ALG
r 決定論的な性質
r ICMP Destination Unreachable の挙動
r フラグメンテーションに関する挙動
そのうえで RFC 4728 では、NAT に対する 14 の要求事項を規定しています。たと†3

すでに廃止された RFC 3489 において定義されていた Port Restricted Cone がまさにそれです。

5.4 大規模な NAT（CGN）とその課題

えば、ヘアピニングに対応することが必須とされていたり、RTP と RTCP がそれぞれ偶数と奇数のポート番号を利用する仕様を考慮してポートパリティの維持が推奨されたりしています。
■ NAT はファイアウォールではない
NAT 機器では、内部から外部への通信に応じて、動的にフィルタが追加されます。

これは SFI（Stateful Filter Implementation）と呼ばれ、簡易なセキュリティのための手法としてとらえられることがあります。「NAT が使われない IPv6 は IPv4 よりも攻撃を受けやすい」と考えられることさえあります。
そうした考え方に対し、RFC 4864 では、NAT 機器が実現する簡易なセキュリティ
機能は「ないよりマシ程度（‘better than nothing’ level of protection）」でしかないと反論しています。NAT 機器による SFI は、セキュリティを実現する目的で設計されているのではなく、あくまでも NAT を実現するためのものです。RFC 4864 によれば、SFI はファイアウォールでも実現可能であり、IPv4 において NAT のセキュリ
ティ上の貢献だと信じられている機能は IPv6 においても SFI で実現できるとされています。

5.4 大規模な NAT（CGN）とその課題
IPv4 アドレス在庫枯渇問題が発生する数年前ごろから、グローバル IPv4 アドレスの利用数を圧縮するために、CGN（Carrier Grade NAT）と呼ばれる大規模な NAT の利用に注目が集まるようになりました。CGN は、その名のとおり、通信事業者などのネットワークで大規模に運用される形態の NAT です。本書を執筆している 2021 年 2月の時点では、ISP、CATV 網、スマホ向け IPv4 インターネット接続などの環境において CGN が使われることがあります。
第 4 章で説明したように、v6 プラスでは IPv4 インターネット接続に MAP-E を採用しており、これにより大規模 NAT の機能も実現されています。そのため、CGN そのものを導入しなくても、必要なグローバル IPv4 アドレスの利用数を圧縮して節約できています。
とはいえ、IPv4 アドレス在庫枯渇問題に伴って発生しがちな一般的な課題について
は、v6 プラスでも似た問題への対処が必要になるでしょう。MAP-E で実現している
NAT について理解するという意味でも、CGN に関連する議論を背景として押さえておくと v6 プラスへの理解が深まるでしょう。
そこで本書では、v6 プラスにおける NAT の解説を補足するために、ISP で導入され

73

74

第5章

IPv4 NAT

ることがある CGN について紹介します。

5.4.1 CGN と一般の NAT の違い
CGN の仕組みは、基本的には家庭内ネットワークなどで利用される一般の NAT と同じです。ただし、導入の目的と利用環境（1 つの IPv4 アドレスを利用する契約の数）が CGN と一般の NAT とでは大きく異なります。
■ 導入目的の違い
一般の NAT には、「ISP から割り当てられる 1 つの IPv4 アドレスで複数の機器をイ
ンターネットにつなぐ」という目的があります。通常、ユーザが ISP と契約すると、その契約回線に対して動的にグローバル IPv4 アドレスが割り当てられます。この 1つのグローバル IPv4 アドレスで、プライベート IPv4 アドレス空間に接続した複数の機器からインターネットを利用するのが一般の NAT の導入目的です。
それに対し、CGN の導入目的は、グローバル IPv4 アドレスの利用数を節約することにあります。具体的には、1 つの回線契約ごとに 1 つのグローバル IPv4 アドレスを割り当てるのではなく、1 つのグローバル IPv4 アドレスを複数の回線契約で共有することを目指します。1 つの回線契約ごとに 1 つのグローバル IPv4 アドレスを割り当てると、回線契約数と同じ数だけのグローバル IPv4 アドレスが必要になりますが、複数の回線契約を集約することで、より少ないグローバル IPv4 アドレスでのインターネット接続サービスを多くのユーザに提供できるようになります。
■ 利用環境の違い
CGN は、グローバル IPv4 アドレスとプライベート IPv4 アドレスを変換する NAT 機器の場所も、一般の NAT とは異なります。
一般的な NAT では、回線契約を行っているユーザ側が運用する NAT 機器によりアドレス変換を行います。それに対し、CGN では、ISP のような通信事業者の構内で
NAT 機器を運用し、その 1 つの機器に多くの契約者が集約されます。

一般的な NAT 機器が扱うグローバル IPv4 アドレスは、1 つのプライベートネット
ワークごとに 1 つだけです。一方、CGN では、単一の NAT 機器が複数のグローバル
IPv4 アドレスを利用します。CGN では扱っているプライベートネットワークの規模が大きいので、1 つのプライベートネットワークに対して複数のグローバル IPv4 アド
レスを使うことになるからです。
なぜ、プライベートネットワークの規模が大きくなると、複数のグローバル IPv4 ア
ドレスが必要になるのでしょうか。実は、NAT 機器には同時に扱える通信セッショ

5.4 大規模な NAT（CGN）とその課題

ン数に論理的な上限があり、その上限では大規模なネットワークにおける接続サービスに支障が生じるのです。
ここで、NAT 機器では「同じフローに属するパケットが同じフローとして扱われる」ようにパケットを変換するということを思い出してください。すでに説明したよ
うに、フローは、送信元アドレスとポート、宛先アドレスとポート、およびプロトコ
ルの 5 種類の情報で決まります。このフローを一意に識別できる数が、NAT における同時通信セッション数の論理的な上限になります。
TCP の 80 番ポートを利用する Web 通信で考えてみましょう。TCP ヘッダのポート

番号フィールドは 16 ビットなので、ポートとして利用できる値は 65536（もしくは、
16 ビットがすべて 0 の場合とすべて 1 の場合を除いた 65534）個です。したがって、

グローバル IPv4 アドレスが 1 つであれば、一意に識別できるフローは 65536 が上限になります。ある特定のグローバル IPv4 アドレスに対して NAT が扱える通信セッ
ションの数は、NAT で利用されるグローバル IPv4 アドレスの数によって論理的に制限されてしまうということです。このように論理的な同時接続数の上限が存在するので、大規模なプライベートネットワーク向けの CGN では、複数のグローバル IPv4 ア
ドレスを利用する必要があるのです。
さらに、ユーザごとに同時に通信が可能なセッション数に上限を設定できる機能がCGN に要求される場合もあります。複数のグローバル IPv4 アドレスを多数のユーザで共有して使うことが前提なので、たとえば単一のユーザが大量の TCP セッションを確立してしまうと、他のユーザが使える論理的な TCP セッション数が減ってしまうからです。論理的なセッション数の上限だけではなく、CGN の物理的なメモリ量などの物理的な制約もあるので、セッション数の上限についても複数ユーザが条件を共有しなければなりません。

5.4.2 CGN が抱える課題
IPv4 アドレス在庫が枯渇すると、ISP はこれまでのように「必要になったら新しい
IPv4 アドレスを申請して割り振りを受ける」ことができなくなります。これは、IPv4

アドレスの総量がこれ以上増えなくなるということであり、ISP はそれまで割り振りを受けた IPv4 アドレスを節約しながら使い続けなければなりません。その節約の手段として CGN が活用されることが増えていますが、CGN には単純にユーザに対してグローバル IPv4 アドレスを配布する従来型のインターネット接続サービスと比較す
ると、さまざまな課題もあります。
v6 プラスは CGN とは直接関係しないので、ここで挙げる課題は v6 プラスが抱える

75

76

第5章

IPv4 NAT問題というわけではありません。ただし、CGN に限らず大規模 NAT で一般的に課題となりうる問題については、v6 プラスで採用されている MAP-E でも類似した問題が発生する可能性があります。
■ サーバのアクセスログに関する対応
IPv4 でのインターネット接続サービスの裏側で、ISP などが CGN を利用することが増えると、すでに家庭内ネットワークに設置されている NAT と合わせて、経路全体で2 段階の NAT が関与する環境が増えます。これに伴い、Web サービスなどを提供している側にも対応を迫られる課題があります。多くのユーザが同じ IPv4 アドレスにまとめられてしまうので、Web サーバ側でプログラムを書いたりサーバを管理したりする側の視点から見ると、ユーザとして見える相手の IPv4 アドレスのバリエーショ
ンが劇的に減ることになるからです。
具体的な対応としては、サーバ側でアクセスログに記載する項目で TCP 送信元ポー
ト番号を追加する必要が生じます。ISP などが CGN を導入すると、その CGN 通過後のグローバル IPv4 アドレスは複数の契約者によって利用されているものとみなせます。そのため、IPv4 アドレスをアクセスログに残すだけでは、実際に通信を行った契約回線を特定できません。契約回線を特定するためには、IPv4 アドレスと TCP ポー
ト番号の両方が必要になるのです。
RFC 6302 では、インターネットに接続されたサーバでは以下の項目をログとして保存することを推奨しています。

r 送信元ポート番号r タイムスタンプr トランスポートプロトコル（たとえば UDP や TCP）
r アプリケーションが複数のポート番号を利用する場合には、宛先ポート番号もISP などで CGN が使われるようになる前は、TCP や UDP のポート番号を Web サー

バなどのアクセスログに記載することは稀でした。CGN の普及に伴い、現在では Web
サーバなどのアクセスログにポート番号を記録することが求められるようになりつつあります。日本では、平成 27 年（2015 年）12 月 9 日にプロバイダ責任制限法（「特定電気通信役務提供者の損害賠償責任の制限及び発信者情報の開示に関する法律」）の
第 4 条第 1 項「発信者情報を定める省令」の一部を改正する省令が公布され、開示の5.4 大規模な NAT（CGN）とその課題対象となる発信者情報にポート番号が追加されました†4 。
なお、サーバのアクセスログについては、NAT 機器での時刻情報とサーバログでの時刻情報をどのように同期すればよいかという課題もあります。
サーバのアクセスログに関する大規模 NAT の課題は、v6 プラスで IPv4 アドレス共有を実現している MAP-E においても同様に対処が必要になります。
■ P2P 的な通信への対応
対戦型のオンラインゲームや通話アプリケーションなど、ユーザ同士が直接通信するタイプの P2P（Peer-to-Peer）通信は、一般に NAT の存在により阻害される可能性があります。CGN では、NAT が家庭だけではなく ISP などのネットワークでも行われることになるので、P2P 的な通信がさらに困難になります。
たとえば、多くの SOHO ルータで実装されている UPnP IGD による NAT 越えは、CGN 環境下では利用できません。UPnP は、その名のとおり、ネットワークに接続された機器を「プラグアンドプレイ」するための標準です。マルチキャストで対応機器を発見し、発見した対応機器に対して SOAP を使って情報取得や制御を行います。IGD は、UPnP でインターネットに接続されたゲートウェイを制御するための機能です。
UPnP IGD は、主にユーザセグメントでの利用を想定された仕様です。実際、UPnPで利用されるマルチキャストアドレスは 239.255.255.250 であり、家庭内にある
NAT ルータを越えるようなマルチキャストルーティングは考慮されていません。主

に同一セグメント内での利用が想定されており、CGN が存在するような環境は想定されていないのです。
ただし、いわゆる NAT 越えには UPnP 以外にもさまざまな手法があります（そもそもセキュリティ上の理由によって UPnP 機能がデフォルトでは無効の機器も増えています）。たとえば、WebRTC などで利用される STUN も、そうした NAT 越えのための手法のひとつです。CGN が存在する環境での P2P 的な通信は、そうした他の手法を使って対応していくことになるでしょう。
■ 通信セッションの生存時間
CGN が存在する環境では、TCP や UDP などの通信セッションの生存時間をどれく†4「特定電気通信役務提供者の損害賠償責任の制限及び発信者情報の開示に関する法律第四条第一項の発信者情報を定める省令」：
https://elaws.e-gov.go.jp/search/elawsSearch/elaws_search/lsg0500/detail?
lawId=414M60000008057

77

78

第5章

IPv4 NATらいにするかという課題もあります。通信がまったく発生していないセッションに割かれている資源をいつ解放するかによって、単一の NAT 機器で収容できるユーザ数も変わってきます。
インターネットにおける通信セッションは、突然途切れることもあるので、「確実にセッションが切れた」と判断できないことも多くあります。たとえば、Web サイトの閲覧中にいきなりパソコンの通信ケーブルを抜けば、その瞬間の TCP 接続は途切れてしまいます。
しかし、Web サーバ側にはインターネットの向こう側にいるパソコンの状態はわからないので、通信相手が復帰した場合に備えて、その際の TCP 接続の状態が一定時間は維持されます。一定時間が経過すれば Web サーバにおける TCP 接続の状態も破棄されますが、途中経路に存在する CGN 機器には、Web サーバにおいて TCP 接続の状態が破棄された瞬間はわかりません。
そのため、何らかの期間を設定することで「通信が破棄された」ことを自分で判断しなければなりません。この期間が短いと、通信は継続しているにもかかわらずパケットが一定時間送信されなかったことで CGN における状態が破棄されてしまい、
通信が切断されてしまうという問題が発生する可能性が高まります。その一方で、この期間が長いと利用可能なポート番号が枯渇してしまい、新しい通信セッションが確立できなくなるという問題が発生する可能性が高まります。
■ ジオロケーション
IPv4 アドレスは、あまり正確な手法とは言い難いものの、通信相手が物理的に存在している地域の推定に使われることがあります。CGN は複数のユーザを 1 つのグロー
バル IPv4 アドレスに集約するので、CGN によって集約される範囲によっては、従来よりも IPv4 アドレスによる物理的な位置情報の推定誤差が大きくなる可能性があります。
■ ブラックリスト
ネットへの悪質な書き込みや、迷惑メール送信行為に対するブラックリストとして、IPv4 アドレスが利用されることがあります。CGN が存在する環境では、複数のユーザが同時に同じグローバル IPv4 アドレスを利用するので、ブラックリストにそのうちの一部の IPv4 アドレスが登録されてしまうと無実のユーザまでもが影響を受ける可能性があります。
■ 運用コストの増大
CGN では、複数の契約を 1 つの IPv4 アドレスに集約するために、多くの契約ユー

5.4 大規模な NAT（CGN）とその課題

ザについて NAT による変換作業を大規模に実行する必要があります。これに伴う運用コストは、CGN の大きな欠点とされています。
集約された IPv4 アドレスに個々の契約ユーザをどのように振り分けるかは、実装に依存します。その手法のひとつとして、TCP や UDP のポート番号をユーザに応じて区分するというものがあります。この手法では、TCP と UDP のポート番号をユー
ザ単位で割り当てることにより、IPv4 パケットに含まれる IPv4 アドレスとトランスポート層のポート番号の組から自動的にユーザを判別します。これにより CGN での処理が効率化できるという特徴があります。
v6 プラスで採用されている MAP-E も、ポート番号を利用した IPv4 アドレスの共有手法だといえます。ただし、v6 プラスで採用されている MAP-E では、NAT を行うのはユーザ側にある CPE です。各 CPE は、各契約ユーザが利用可能な IPv4 アドレスとポート番号を把握しているので、自律分散的に CGN に類似した IPv4 アドレス共有ができます。ポート番号を契約ユーザに割り当てることによって、中央にあるルータがステートレスに運用できることから、負荷分散が可能になっているのです。このため、MAP-E は CGN と比べて運用者の負荷が低く、低コストで実現しやすい方式だといえます。
■ プロトコルに関する課題
ICMP には、TCP や UDP のようなポート番号の概念がないので、NAT による変換を行う際にフローの一意性を確保するために特別な対応が必要です。特に、MTU が小さすぎてパケットが転送できず、かつフラグメンテーションができない場合に送信される ICMP Message Too Big メッセージを CGN 機器で転送できないと、Path MTU
Discovery を利用しているアプリケーションが正しく動作せずに通信ができなくなる可能性があります。NAT における ICMP の扱いについては RFC 5508 で議論されています。なお、ICMP の扱いは NAT64 などの IPv4/IPv6 トランスレータでも課題とされています。
フラグメンテーションも CGN における課題のひとつです。IPv4 パケットがフラグメント化されるとき、TCP や UDP などのトランスポートプロトコルヘッダは、分割されたパケットのうち最初のパケットにのみ含まれます。分割されたパケットのうち2 つめ以降にはトランスポートプロトコルのヘッダが含まれないため、CGN において特別な処理が必要となります。
自宅にサーバを設置し、外部からアクセス可能にする手法のひとつとして、ダイナ
ミック DNS が利用されることがあります。ISP によって CGN が運用されるようにな
ると、ダイナミック DNS を利用した外部からのアクセスを実現するのが困難になり

79

80

第5章

IPv4 NATます。
RFC 6269 には、NAT などの IP アドレス共有技術全般における課題がまとめられています。例として CGN、DS-Lite、NAT64、A+P などが登場しますが、個々の技術についての課題というよりは、大規模に IP アドレスを共有することに伴う課題が全般的に議論されています。
RFC 7021 には、2013 年時点での CGN による通信への影響に対する調査結果がまとめられています。

第6章

v6 プラス詳解第 3 章でフレッツ網と IPv6 IPoE について、第 4 章で MAP-E について、それぞれ紹介しました。この章では、それらを利用した v6 プラスについて、さらに詳しく解説します。

6.1 通信までの一般的シーケンス
ユーザが CPE を起動してから v6 プラスが利用できるまでのシーケンスを図 6.1 に示します。
まず、MAP CE として稼働する CPE に対して、フレッツ網から IPv6 アドレスが割り当てられます。ひかり電話を利用している場合は DHCPv6-PD（DHCPv6-Preﬁx
Delegation）、利用していない場合には RA（Router Advertisement、ルータ広告）による IPv6 アドレス割り当てが行われます。
RA は、IPv6 の基本的な仕組みのひとつです。Router Advertisement の Advertisement は、「広告」という意味を持つ英単語です。Router Advertisement メッセージ

は、ルータの存在をサブネット内に広告すると同時に、ルータと通信する際に必要となる各種情報を伝える役割があります。
DHCPv6-PD は、ブロードバンドルータなどの CPE に対して IPv6 アドレスプレ

フィックスを割り当てる用途に使われます。IPv4 では ISP と契約を行っているユーザに対して 1 つの IPv4 アドレスを割り当てる方式が一般的ですが、IP アドレス空間が大きい IPv6 では単一の IPv6 アドレスではなく IPv6 プレフィックスごとユーザに割り当てる運用もあります。

82

第6章

v6 プラス詳解

インターネット

CE

フレッツ網

BR

JPIX

通信先

RAもしくは
DHCPv6-PD

RA

MAPルール
配信サーバ

MAPルール
問い合わせ
MAPルール取得

DHCP

キャッシュ
DNSサーバ

DNSクエリ
DNSクエリ
DNSレスポンス
DNSレスポンス

MAP-E
IPoE IPv6▲

図 6.1 v6 プラスでの通信開始までの一般的シーケンス

NOTE

本書では、RA および DHCPv6-PD に関する詳細は割愛します。これら IPv6 そのものに関する詳しい情報は、本書の著者の一人である小川晃通による『プロフェッショナル
IPv6』（ラムダノート、2018 年）を参照してください。

ひかり電話の有無によって、IPv6 アドレス割り当てが RA によるか、それとも
DHCPv6-PD によるかが変わるということは、ユーザが利用するネットワークの構成が変わるということでもあります。ひかり電話の有無による構成の違いについては
6.2 節で解説します。
MAP CE として稼働する CPE は、MAP BR に関する情報を MAP ルール配信サーバに問い合わせます。MAP ルール配信サーバから MAP BR の情報を得た MAP CE は、MAP
BR への IPv6 トンネルを張ります。この IPv6 トンネルを通過して、ユーザからの IPv4

6.2 ひかり電話の有無で変わる IPv6 ネットワーク構成

パケットが IPv4 インターネットへと運ばれます。

NOTE
MAP ルールの配信は、RFC 7598 では DHCPv6 による方法が規定されています。v6 プ

ラスで DHCPv6 による MAP ルールの配信が採用されていない理由としては、DHCPv6
サーバが NTT 東西によるものである一方で MAP-E が JPIX によるものであることが挙げられます。

MAP CE は、家庭内ネットワークにおいて、IPv4 の DHCP サーバとしての役割も果たします。ユーザが利用するパソコンなどの機器に対しては、MAP CE の DHCP サー
バからプライベート IPv4 アドレスがリースされます。
MAP CE は、IPv4 の DNS プロキシとしても機能します。これは、家庭内ネットワー

クの機器からの IPv4 での DNS 問い合わせを、IPv6 で JPIX のキャッシュ DNS サーバ
へと中継する機能です。この IPv6 でのキャッシュ DNS サーバの IPv6 アドレスは、フレッツ網から DHCPv6 で提供されます。

6.2 ひかり電話の有無で変わる IPv6 ネットワーク構成
フレッツ網では、ひかり電話を利用しているかどうかで、ユーザ側の IPv6 ネット
ワーク構成が変わります。

r ひかり電話を利用している場合には、ユーザに対し、フレッツ網からの DHPCv6PD によって/56 の IPv6 プレフィックスが割り当てられるr ひかり電話を利用していない場合には、ユーザに対し、/64 の IPv6 プレフィック
スが RA で送られてくる
このような違いがあることから、v6 プラスでも、ひかり電話を利用しているかどうかで IPv6 の視点でのネットワーク構成が変わります。
なお、IPv4 の視点では、ひかり電話契約の有無によらず、IPv4 ネットワークについては MAP CE をデフォルトルートとする構成になります（図 6.2）。

83

84

第6章

v6 プラス詳解

プライベートIPv4アドレス空間

JPIX

フレッツ網

IPv4インターネット

IPv6トンネル
ルータ
MAP CEJPIX
MAP BR▲

図 6.2 IPv4 視点での v6 プラス

6.2.1 ひかり電話の契約がある場合
ひかり電話の契約がある場合には、NTT 東西が提供するホームゲートウェイ、もしくは他のルータ製品により、DHCPv6-PD によって IPv6 プレフィックスの委任を受けます（図 6.3）。
ユーザ側

責任分界点

ルータ
（CPE）

フレッツ網

DHCPv6-PDで/56を委任

ルータ

/64

▲

図 6.3 ひかり電話ありの構成（IPv6 視点）

MAP-E については、NTT 東西のホームゲートウェイで行う方法と、その他のルータ製品で行う方法があります。このとき、ホームゲートウェイもしくはルータは、ユー
ザに対して IPv6 を提供するルータとなります。
この場合、プライベート IPv4 アドレスによる IPv4 ネットワークについては、このルータが MAP CE として稼働することでユーザに提供されます。
■ NTT 東西のホームゲートウェイで v6 プラスを利用する場合
ひかり電話の契約があり、NTT 東西のひかり電話ルーターまたはホームゲートウェ
イを利用する場合には、MAP-E の機能を提供する JPNE ソフトウェア†1 をホームゲー†1「JPNE ソフトウェア」に関する情報は 2023 年 1 月現在のものです。

6.2 ひかり電話の有無で変わる IPv6 ネットワーク構成

トウェイにインストールする必要があります。ホームゲートウェイを利用する形で
v6 プラスの利用を申し込むと自動的にインストールされるので、エンドユーザ側での作業は不要です。

NOTE

ひかり電話契約がなくても、ホームゲートウェイをレンタルできる場合があります。

JPNE ソフトウェアは、NTT 東西による「フレッツ・ジョイント」というサービス

によって配布されています。フレッツ・ジョイントは、事業者がホームゲートウェイ
に対してフレッツ網からソフトウェアを配信できるようにするサービスです†2 。JPIXが NTT 東西とフレッツ・ジョイントの契約を行っており、これを通じて JPNE ソフト
ウェアがユーザのホームゲートウェイにインストールできるようになっています。
ホームゲートウェイに JPNE ソフトウェアがインストールされると、自動的に MAPE が設定されます。v6 プラス開通前にホームゲートウェイで IPv4 PPPoE による IPv4

インターネット接続を利用していた場合、JPNE ソフトウェアのインストールによる
v6 プラス開通と同時に自動的に IPv4 PPPoE が無効化され、MAP-E による v6 プラスに切り替わります。
■ 他のルータで v6 プラスを利用する場合
NTT 東西のホームゲートウェイでなくても、フレッツ網からの DHCPv6-PD を処理できる IPv6 のルータで、MAP CE として動作できる機器であれば、v6 プラスを利用できます。ルータの機種によっては、ひかり電話の設定が可能なものもあります。

6.2.2 ひかり電話の契約がない場合
ひかり電話の契約がない場合には、フレッツ網から/64 の RA が送られてきます。
その RA が示すフレッツ網内のルータをデフォルトルートとして設定する必要があります。ひかり電話の契約がある場合と違って、ユーザが設定するデフォルトルートがユーザ宅内になく、フレッツ網にある形になります（図 6.4）。

†2

フレッツ・ジョイントについて詳しくは NTT 東日本による FAQ ページ（http://faq.flets.com/
category/show/759）などを参照してください。

85

86

第6章

v6 プラス詳解

ユーザ側

責任分界点

フレッツ網

ルータ

/64

▲

図 6.4 ひかり電話なしの構成（IPv6 視点）

ひかり電話の契約がない場合、フレッツ網から RA が提供される/64 のセグメントにおいて、ルータは IPv6 パススルーを行います。そのため、ユーザが利用するパソ
コンなどの機器から見ると、そのルータは L3 の構成上は透明な存在になります（図
6.5）
。

ユーザ側

責任分界点

フレッツ網

ONU
（光回線終端装置）

MAP CE（IPv6パススルー）

ルータ

/64

▲

図 6.5 ひかり電話なしの構成（一部 L1 視点）

この場合、このルータが/64 セグメントにおいて MAP CE として稼働し、MAP-E のための IPv6 トンネルを構成します。その IPv6 トンネルを IPv4 インターネット接続のアップリンクとして、プライベート IPv4 アドレスによる IPv4 ネットワークがユーザに提供されます。

6.3 「v6 プラス」固定 IP サービス

6.3 「v6 プラス」固定 IP サービス
v6 プラスには固定 IPv4 アドレスのサービスもあります。このサービスでは、JPIXで運用されている BR まで、IPv4 over IPv6 の IPIP トンネルを張ります。
この場合には、IPv4 over IPv6 トンネルとして MAP-E を利用しないので、ルール
配信サーバへの問い合わせが発生しません。また、MAP-E を利用するときのように、ポート番号に関する制限もありません。IPv4 による DNS 問い合わせが IPv6 で JPIX のキャッシュ DNS サーバへと転送される点は、MAP-E を利用する v6 プラスの場合と同様です。
固定 IPv4 アドレスサービスには、IPv4 アドレスを専有する個数に応じて、1 IP、8
IP、16 IP、32 IP、64 IP という種類のサービスがあります。IPv4 アドレスを 1 個専有する 1 IP の場合、通常の一般家庭向け IPv4 インターネット接続サービス同様に、
IPv4 NAT を利用することで家庭内で複数の機器に対してインターネット接続環境を用意できます。このとき、図 6.6 のように、IPv4 NAT ルータは IPv6 トンネルを JPIXの MAP BR に対して張ります。1 IP では、ユーザが家庭内で利用する IPv4 セグメント
はプライベート IPv4 アドレスによるものになります。

プライベートIPv4アドレス空間

JPIX

フレッツ網

IPv4インターネット

IPv6トンネル
NATルータIPIPルータ

JPIX
BR

▲

図 6.6 IPv4 視点での v6 プラス (1 IP の場合 )8 個以上のグローバル IPv4 アドレスを専有するサービスでは、ユーザはグローバル
IPv4 アドレスによるセグメントを運用できます。これらのサービスも、IPv6 トンネルを JPIX の BR に対して張る点は、IPv4 アドレスを 1 個専有するサービスと同様です。
違いは、ルータが IPv4 NAT を行わず、グローバル IPv4 アドレスによるルータとして稼働する点です（図 6.7）。

87

88

第6章

v6 プラス詳解グローバルIPv4アドレス空間

JPIX

フレッツ網

IPv4インターネット

IPv6トンネル
JPIX
BR

IPIPルータ▲

図 6.7 IPv4 視点での v6 プラス (8 IP、16 IP、32 IP、64 IP の場合 )NOTE「v6 プラス」固定 IP サービスは、通常の共用型の「v6 プラス」対応 ISP でも取り扱っていない場合があります。サービスの提供の有無に関しては、それぞれの ISP にご確認く
ださい。

6.3.1 「v6 プラス」固定 IP サービスでの通信までの一般的シーケンス
図 6.8 に固定 IPv4 アドレスの場合の v6 プラスの接続シーケンスを示します。

インターネット

CE

フレッツ網

BR

JPIX

通信先

RAもしくは
DHCPv6-PD

RA

キャッシュ
DNSサーバ

DHCP
DNSクエリ
DNSクエリ
DNSレスポンス
DNSレスポンス

IPv6トンネル
IPoE IPv6▲

図 6.8 v6 プラスでの通信開始までの一般的シーケンス（「v6 プラス」固定 IP サービス）

6.3 「v6 プラス」固定 IP サービス

マップルールサーバとの通信が不要である以外は、基本的に MAP-E による v6 プラ
スの通常サービスと同じシーケンスです。

6.3.2 v6 プラスアップデートサーバ「v6 プラス」固定 IP サービスでは、v6 プラスアップデートサーバが用意されています。フレッツ網においてユーザに割り当てられる IPv6 アドレスは、半固定という運用になっています。頻度は多くないものの、ユーザが利用中にフレッツ網から割り当
てられている IPv6 アドレスが変化してしまうことがあります。
「v6 プラス」固定 IP サービスは、IPv6 トンネルを通じて提供されているため、フレッツ網からユーザに対して割り当てられた IPv6 アドレスが変化したとき、IPv4
over IPv6 を行っているトンネルの設定も更新する必要があります。そのためには、

半固定となっている IPv6 アドレスが変化したことを IPIP トンネル設定ルータが知る必要があります。この機能を実現しているのが、v6 プラスアップデートサーバです。
「v6 プラス」固定 IP サービスに対応しているルータは、v6 プラスアップデートサー
バと定期的に通信を行い、フレッツ網からの IPv6 アドレス割り当てが変化したことを検知するとユーザ側のルータと BR の間に張られている IPIP トンネルの設定を更新
します。

89

［書籍版では空白のページです］

第7章

エンドユーザ側の必要条件と設定

この章では、v6 プラスを利用するためにエンドユーザ側で必要な契約や機器の条
件と、v6 プラスの利用を ISP と契約したエンドユーザ側での v6 プラスの設定について解説します。

7.1 v6 プラスの利用条件
v6 プラスを利用するために必要なものは、「IPv6 IPoE 方式に対応したフレッツ網の回線契約」、「v6 プラス対応機器」、「フレッツ・v6 オプション」です。

7.1.1 IPv6 IPoE 方式に対応したフレッツ網の回線契約
2021 年 2 月現在で IPv6 IPoE 方式に対応しているのはフレッツ光ネクスト、フレッ

ツ光ライト、フレッツ光ライトプラスです。NTT 東西のホームゲートウェイを利用するかどうかで、必要な回線契約の条件が少し変わります。

r ホームゲートウェイを利用する場合
フレッツ光ネクストギガスマートを除くサービスの場合には、ひかり電話契約すると提供されるひかり電話ルーターやホームゲートウェイのレンタル契約が必要です。ただし、「ひかり電話タイプ 1」および「ひかり電話オフィスタイプ」では v6
プラスは利用できません。
なお、旧 B フレッツ回線（NTT 東日本の「お客さま ID」が「COP」から始まる回線）
で、2014 年 9 月以前にひかり電話を契約している場合には、ホームゲートウェイによる v6 プラスが提供できないひかり電話のタイプ 1 である可能性もあります。現

92

第7章

エンドユーザ側の必要条件と設定

在利用しているひかり電話のタイプを確認するには、NTT 東日本もしくは光コラボ
レーション事業者への問い合わせが必要です。

r ホームゲートウェイではなくブロードバンドルータを利用する場合
IPv6 IPoE 方式対応のサービスへの契約が必要です。ひかり電話の契約は必須ではありません。

7.1.2 v6 プラス対応機器
v6 プラスの利用には、NTT 東西によるホームゲートウェイか、v6 プラスに対応したホームゲートウェイまたはブロードバンドルータが必要です。2021 年 2 月現在、
v6 プラスに対応しているホームゲートウェイ、ブロードバンドルータの一覧を表 7.1に示します。

▲

表 7.1 v6 プラス対応機器

メーカー

機種
RT-S300 シリーズ、PR-S300 シリーズ、RV-S340 シリーズ
RT-400 シリーズ、PR-400 シリーズ、RV-440 シリーズ

NTT 東西RT-500 シリーズ、PR-500 シリーズ
RS-500 シリーズ（NTT 東日本のみ）
PR-600 シリーズ、RX-600 シリーズ、XG-100 シリーズ
WRM-D2133HP、WRM-D2133HS、WRM-D2133HS/W1S
WTR-M2133HP、WTR-2133HS、WTR-2133HS/E2S
WXR-2533DHP2、WXR-2533DHP
WXR-1900DHP3（Ver.2.55 以降）
WXR-1901DHP3（Ver.2.55 以降）
WXR-1900DHP2（Ver.2.53 以降）
WXR-1900DHP（Ver.2.43 以降）

バッファロー

WXR-1750DHP（Ver.2.52 以降）
WXR-1750DHP2（Ver.2.52 以降）
WXR-1751DHP2（Ver.2.52 以降）、WXR-5700AX7S シリーズ
WXR-5959AX12 シリーズ（Ver.3.04 以降）
WSR-2533DHP2 シリーズ（Ver.1.1 以降）
WSR-2533DHPL2 シリーズ、WSR-1166DHP4 シリーズ
WSR-1166DHPL シリーズ、WSR-1166DHPL2 シリーズ
WSR-1800AX4 シリーズ、WSR-3200AX4S シリーズ
WSR-5400AX6 シリーズ

7.1 v6 プラスの利用条件

メーカー

93

機種
WN-AX1167GR（Ver.3.20 以降）

アイ・オー・データ機器

WN-AX1167GR/V6（Ver.3.20 以降）
WN-AX1167GR2、WN-AX2033GR
WN-AX2033GR2、WN-SX300FR、WN-SX300GR

NTT ドコモドコモ光ルーター 01（ファームウェアバージョン 1.2.1 以降）
Aterm WG2600HS、Aterm WG2600HS2
Aterm WG2600HP3、Aterm WG2600HP4
Aterm WG1900HP2、Aterm WG1800HP4

NEC プラットフォームズ

Aterm WG1200HS3、Aterm WG1200HS4
Aterm WG1200HP3、Aterm WG1200HP4
Aterm WX3000HP、Aterm WX6000HP
Aterm WX（AX）1800HP、Aterm GX621A1
Aterm Biz SH621A1
WRC-1750GSV、WRC-1167GST2、WRC-1750GST2
WRC-1900GST2、WRC-2533GST2、WRC-2533GS2-B

エレコム

WRC-2533GS2-W、WRC-1167GS2-B、WRC-X3000GS
WRC-X3000GSN、WMC-M1267GST2-W、WMC-DLGST2-W
WMC-2HC-W、WMC-C2533GST-W
WRC-X3200GST3-B
FutureNet NXR-G240、FutureNet NXR-G240/L

センチュリー・システムズ

FutureNet NXR-G240/L-CA、FutureNet NXR-G260
FutureNet NXR-G260/L、FutureNet NXR-530
FutureNet NXR-650

ヤマハ

RTX830、RTX1210、NVR510、NVR700W

NEC

UNIVERGE IX シリーズ

TP-Link

ArcherA10、ArcherA2600

Synology

RT2600ac（Ver.1.2.4-8081 Update 2 以降）
MR2200ac（Ver.1.2.4-8081 Update 2 以降）
AR4050S/AR3050S、AR2050V、AR1050V
AR4050S/3050S/2050V “v6 プラス ” 設定例（ひかり電話あり）

アライドテレシス

AR4050S/3050S/2050V “v6 プラス ” 設定例（ひかり電話なし）
AR1050V “v6 プラス ” 設定例（ひかり電話あり）
AR1050V “v6 プラス ” 設定例（ひかり電話なし）

古河電工

FITELnet F220/F221

エフセキュア

F-Secure SENSE （Ver.1.10.0.750 以降）

ネットギア

RAX120 （Ver.1.2.0.16 以降）

94

第7章

エンドユーザ側の必要条件と設定■ 「v6 プラス」固定 IP サービスの対応機器「v6 プラス」固定 IP サービスを利用するには IPIP に対応した機器での設定が必要です。以下 URL に機種ごとの設定例の掲載があります。

r https://www.jpne.co.jp/service/v6plus-static/（2023 年 1 月現在）
■ v6 プラス未対応のホームゲートウェイ
ホームゲートウェイには、v6 プラス対応ホームゲートウェイと、未対応ホームゲー
トウェイがあります。NTT 西日本エリアではすべてのホームゲートウェイが v6 プラ
ス対応ホームゲートウェイですが、東日本エリアでは未対応ホームゲートウェイの可能性があります。
v6 プラス対応ホームゲートウェイへの交換には、NTT 東日本の 116 窓口に申し込

むという方法があります。光コラボレーション提供事業者と回線を契約している場合には、契約している光コラボレーション事業者に変更を申し込んでください。

7.1.3 フレッツ・v6 オプション
フレッツ・v6 オプションは IPv6 IPoE 方式の提供に必要です。フレッツ・v6 オプションへの申し込みが行われていない場合には、IPv6 IPoE を契約できません。このフレッツ・v6 オプションは IPv6 IPoE 契約と同時に申し込みできます。
IPv6 IPoE 方式の契約中にフレッツ・v6 オプションを解約すると、IPv6 IPoE 方式での IPv6 インターネット接続が利用できなくなります。IPv6 IPoE が利用できなくなる
ため、IPv6 インターネット接続の IPv4 オプションである v6 プラスも利用できなくなります。

7.2 v6 プラス IPv4 設定ソフトウェア
ホームゲートウェイでの v6 プラス IPv4 設定ソフトウェアの設定方法を解説します。JPNE ソフトウェア†1 とそのインストール方法については 6.2.1 項も参照してください。

7.2.1 設定画面へのアクセス方法
JPNE ソフトウェアが配信済みのホームゲートウェイ配下のネットワークで、
http://ntt.setup:8888/t/ または http://192.168.1.1:8888/t/ にアクセ
†1

「JPNE ソフトウェア」に関する情報は 2023 年 1 月現在のものです。

7.2 v6 プラス IPv4 設定ソフトウェア

スすると、JPNE ソフトウェアによる「v6 プラス IPv4 設定ソフトウェア」を利用できます。
「配信済事業者ソフトウェア一覧」の画面には、図 7.1 のように、IPv4 設定画面へ遷移するためのアイコンが表示されます。この画面から「IPv4 設定」のアイコンを選択することで、JPNE ソフトウェアを利用できます。

▲

図 7.1 ntt.setup の画面

なお、図 7.1 に示した画面イメージには「IPv4 設定」のアイコンのみが表示されていますが、実際はエンドユーザが ISP と契約して配信済みの各種サービスのアイコンがすべて表示されます。表示されるサービスはソートされているので、実際には図7.1 と同じ位置に「IPv4 設定」のアイコンが表示されているとは限りません。

「IPv4 設定」をクリックすると、次の図 7.2 のような画面が表示されます。

▲

図 7.2 JPNE ソフトウェアトップページ

95

96

第7章

エンドユーザ側の必要条件と設定

7.2.2 トップ画面からのページ遷移「IPv4 設定」のトップ画面はフレームで構成されており、左側にメニュー、右側に設定内容が表示されます。トップページでは、割り当てられた IPv4 アドレスと利用可能なポート番号が右側に表示されています。また、IPv4 通信が有効か無効かも表示されます。
このトップページでは各種設定への遷移のみが可能であり、設定できる項目はありません。
JPNE ソフトウェアの画面遷移を図 7.3 に示します。

v6プラスIPv4設定ソフトウェア

配信済事業者
ソフトウェア
一覧の画面

IPv4設定のトップ画面

IDとパスワードが未登録
IDとパスワードの登録画面

IDとパスワードが
登録済み

認証失敗
画面

認証失敗

IPv4設定のトップ画面
認証通過

エントリ
更新・削除

IPv4パケット
フィルタ画面

静的NAPT
画面

IPv4パケット
フィルタ
編集画面

静的NAPT
編集画面

高度な設定
画面

エントリ
更新・削除

▲

図 7.3 画面遷移図

IDとパスワード
変更画面

完了画面

第

8章

FAQ とトラブルシューティング

ここまで、v6 プラスの背景となる日本のネットワークをめぐる状況と、v6 プラスを支える標準化技術について、一通り解説してきました。この章では、前章までに説明した知識を総動員し、v6 プラスに対してよくある問い合わせや、エンドユーザが遭遇する可能性が高いトラブルなどを紹介します。ユーザが遭遇しうるトラブルには、
v6 プラスとは直接関係がないにもかかわらず、v6 プラスに起因する問題だとして誤解されることが多いものも含まれます。

8.1 v6 プラスへの申し込み
JPIX は B2B の事業者であり、ユーザが直接 JPIX との契約することはできません。

どの ISP と契約して v6 プラスを開通させたいか、エンドユーザが判断する必要があります。
ISP はエンドユーザの申し込み手続きや課金などの処理を行います。どの ISP を経

由して v6 プラスに申し込んでも、IPv6 IPoE 方式の仕組み上、ユーザの IPv6 パケット
が JPIX を経由することは変わりませんが、申し込みの方法などが異なる場合があります。

8.1.1 ISP から「v6 プラスに対応していない」と言われた
フレッツ網において IPv6 IPoE 方式による IPv6 インターネット接続サービスを提供している VNE は JPIX だけではありません。VNE によっては、MAP-E や DS-Lite などの国際的に標準化されている技術を採用して、v6 プラスとは違う形で IPv4 over IPv6のサービスが提供されていることもあります。
ただし、v6 プラスは JPIX によるサービスであり、登録商標でもあるので、JPIX で

98

第8章

FAQ とトラブルシューティング

はない VNE と契約している ISP で「v6 プラス」が提供されることはありません。ISP
が v6 プラスのサービスを提供するには、その ISP が JPIX と契約をしている必要があります。

8.1.2 v6 プラスの申し込み方法が ISP によって異なる
JPIX では、v6 プラスという登録商標を、ISP が提供するサービス名として利用することを許可しています。そのため、VNE として JPIX を採用している ISP のサービスで「v6 プラス」という名称が使われることもあります。
しかし、それぞれの ISP が提供する v6 プラスのサービスへの申し込み方法は ISP ごとに異なります。たとえば、IPv6 IPoE 方式による IPv6 インターネット接続サービス
への申し込みと同時でなければ v6 プラスに申し込めない場合や、逆に別々に申し込みが必要な場合もあります。新規に光ファイバーの契約を申し込んだときに自動的に v6 プラスが付いている場合もあれば、そうでない場合もあります。ホームゲート
ウェイでの利用とその他の対応機器での申し込み方法が違う ISP もあります。そうした詳細については各 ISP への問い合わせが必要です。

8.2 v6 プラスがつながらない？
各章で説明したように、v6 プラスはさまざまな要素技術によって構成されているサービスです。何らかの問題が発生したときには、その解決のために、関連箇所の切り分けが重要になります。
ここでは、そうした問題の切り分けに役立つように、v6 プラスに関連して生じることが多い誤解や問題をまとめます。

8.2.1 実は v6 プラスに申し込んでいない
v6 プラスは JPIX が提供するサービスです。しかし、エンドユーザが JPIX と直接契約するわけではありません。エンドユーザが v6 プラスを利用するには、JPIX と契約している ISP へ申し込む必要があります。こうした事情がよく把握できていないと、「v6 プラスを利用したサービスに申し込んでいないので v6 プラスが利用できていなかった」という状況に陥ることもありえます。
たとえば、ISP が提供する「IPv6 IPoE 方式による IPv6 インターネット接続サービス」に申し込んでいても、その基本プランに IPv4 インターネット接続などの「v6 プラスのサービス」が付属していない場合があります。ISP によっては、IPv6 IPoE 方式
による IPv6 インターネット接続サービスへの申し込みとは別に、オプションで v6 プ

8.2 v6 プラスがつながらない？

ラスの申し込みが必要になることもあるので注意が必要です。
また、v6 プラスはすべての VNE 事業者が提供しているサービスではないので、IPv6
IPoE 方式による IPv6 インターネット接続を提供している ISP であっても v6 プラスは利用できない場合もあります。JPIX ではない VNE 事業者が提供する IPv6 IPoE 方式では v6 プラスを利用できません。

8.2.2 v6 プラス開通までのタイムラグ
v6 プラスは、JPIX が NTT 東西のフレッツ網の上で提供するサービスです。エンド

ユーザから v6 プラスへの申し込みを受けた ISP は、JPIX へとオーダーを出し、そのオーダーを受けた JPIX は、さらに NTT 東西へとオーダーを出します。IPv6 IPoE 方式
での IPv6 インターネット接続はもちろん、エンドユーザが v6 プラスのサービスを利用可能になるのは、NTT 東西が設定を行い、エンドユーザに対して JPIX の IPv6 アド
レスプレフィックスが割り当てられてからです。
そのため、ユーザが v6 プラスに申し込んでから実際にサービスを利用できるようになるまでは、どうしてもタイムラグがあります。「申し込んだけど使えない」という状況は、v6 プラス開通までのタイムラグである可能性もあります。

8.2.3 対応端末ではないルータだった
v6 プラスによる IPv4 インターネット接続では、ホームゲートウェイやブロードバ

ンドルータが MAP-E の CE として動作する必要があります。この機能に対応していな
いルータでは v6 プラスが利用できません。v6 プラスに対応可能なルータであることを確認したうえで利用してください（7.1.2 項を参照）。

8.2.4 IPv4 設定が無効になっている
v6 プラスは、IPv6 IPoE 方式による IPv6 インターネット接続に加えて、IPv4 イン

ターネット接続を利用するためのサービスです。しかし、IPv4 インターネットとの通信には、パソコンやスマホなどの末端の機器や CPE において IPv4 の設定が有効になっている必要があります。これらの機器で IPv4 が無効になっていたことで v6 プラ
スでの通信ができないという状況も比較的よく発生しているようです。

8.2.5 サーバ側で IPv4 アドレスがブラックリストに登録されている
v6 プラスで利用している IPv4 アドレスが Web サービスなどでブラックリストに登録されてしまい、MAP CE にその IPv4 アドレスが割り当てられたエンドユーザがその

99

100

第8章

FAQ とトラブルシューティング

Web サイトと通信できなくなる場合がありえます。その IPv4 アドレスが Web サイト

側のブラックリストで解除されない限り、その Web サイトとは通信ができません。通常、ブラックリストの解除には、何らかの方法で相手組織への連絡が必要になります。

8.2.6 IPv4 PPPoE を利用しているパソコンやスマホなどの末端の機器でデフォルトルートに設定されている CPE が、
IPv4 インターネット接続を IPv4 PPPoE で行っている場合に、v6 プラスを利用できていない状況が発生します。v6 プラスを利用するには、VNE として JPIX を選択して
IPv6 IPoE 方式による IPv6 インターネット接続を行うと同時に、IPv4 インターネットとの接続でも v6 プラスを利用する設定にする必要があります。技術的には IPv6 IPoE
方式での IPv6 インターネット接続と IPv4 PPPoE による IPv4 インターネット接続を同時に利用可能なので注意が必要です。

8.2.7 ポートが枯渇した
MAP-E における IPv4 アドレスの共有は、ユーザが利用可能なポート番号を制限することで実現しています。そのため、その制限を超えるポート番号を利用すると、ポートが枯渇してしまいます。
誤解されがちな点として、ポートの枯渇が発生するのは、「同一宛先 IPv4 アドレス
かつ同一宛先ポートに対して多数の通信を行った場合のみ」です。MAP-E においてIPv4 NAT で変換される通信セッションは、5 タプルと呼ばれる 5 つの要素（通信プ

ロトコル、宛先 IPv4 アドレス、送信元 IPv4 アドレス、宛先ポート、送信元ポート）によって識別されます。送信元ポート以外の 4 つの要素がすべて同じ状態で、送信元ポートの差異によってしか識別できない通信が極端に多くなってしまった状態が、
MAP-E における「ポートの枯渇」です。

ポートの枯渇が発生する可能性としてもっとも考えられるのは、「IPv4 インター
ネット側の単一の IPv4 アドレスを宛先 IPv4 アドレスとして、TCP もしくは UDP によるセッションが多数の同時に張られる」という状況です。たとえば、単一の Web サイトに対して同時に極端に多くの接続が発生するような場合がありえます。
また、Google Public DNS のようなパブリックの DNS を使って多数の名前解決が発生するといった状況でも、同時に多くのポート番号が消費されることが推測できます。
JPIX によると、これまで実際にポートの枯渇が発生したという観測情報は非常に少ないものの、まったく発生していないわけでもないようです（2021 年 2 月時点）。

8.3 アプリケーションの通信ができない？

8.3 アプリケーションの通信ができない？
v6 プラスでは、TCP、UDP、ICMP 以外のプロトコルを利用するアプリケーション

サービスは利用できません。たとえば、SCTP や PPTP は利用できません。さらに、ア
プリケーションの通信内容に含まれる IP アドレスなどの情報を利用する SIP や FTP では、NAT 機器において ALG が実装されている必要があります。
ユーザ側でのアプリケーションサーバの公開にも制限があります。MAP CE に割り当てられたポート番号以外でのサーバ公開は、MAP-E の仕組み上、不可能です。
MAP-E ではグローバル IPv4 アドレスを複数の契約者で共有する点にも注意が必要です。そのような環境で利用できないアプリケーションもありえます。

8.3.1 UPnP IGD による NAT 越え
MAP-E はユーザ側の機器で NAT を行うので、技術的には UPnP IGD を利用することが可能です。ただし、v6 プラスに対応したすべてのルータで UPnP IGD に対応しているわけではありません。UPnP IGD による NAT 越えが可能であるかどうかは、利用するルータの機種に依存します。
UPnP IGD では、外部に対してどのポート番号を解放するのかを、ユーザ側が指定します。そのため、MAP-E において割り当てられたポート番号が何であるかを知る必要があります。多くの v6 プラス対応ルータには、MAP-E によって割り当てられた
ポート番号を確認する機能があるので、その機能を利用すれば UPnP IGD で指定する
ポート番号がわかります。
UPnP IGD はセキュリティ上の問題を発生させることもあります。多くのルータでは初期設定で無効になっているので、利用する際には注意してください。

8.3.2 オンラインゲームと v6 プラス
インターネットを介して対戦相手との通信を行うオンラインゲームでは、P2P 的な通信が必要な場合があります。通信サービスにおいてオンラインゲームへの接続性を特に重視するユーザにとって、v6 プラスはどのようなサービスなのでしょうか。
v6 プラスで採用している MAP-E では、ユーザ側にある CPE 機器で IPv4 NAT を行います。その際、従来の NAT ルータと違って、利用できる送信元ポート番号の数が制限されます。そのため、特定の送信元ポート番号が要求されるような場合には、P2P的な通信で問題が発生する可能性もありえます。
ただし、多くのオンラインゲームは、ユーザ側に対して特定の送信元ポート番号を要求しません。実際、v6 プラスが原因で通信ができないという状況が発生している

101

102

第8章

FAQ とトラブルシューティング

オンラインゲームは多くないと考えられます。
参考までに、2018 年 11 月の Game Watch の記事†1 †2 によると、以下のゲームについては v6 プラスを利用したユーザ環境で問題なくプレイできることが検証されています。

r スプラトゥーン 2
r マリオカート 8 デラックスr マリオテニス エース
r スーパー マリオパーティ
r ファンタシースターオンライン 2 クラウドr Minecraftr フォートナイト バトルロイヤルr DARK SOULS REMASTERED

8.4 ユーザ側の機器に問題はないか
v6 プラスとは関係なく、ユーザ側の機器の問題で通信ができていなかったり、速度が低下したりしていることも考えられます。本章で挙げた要因で問題が解決しない場
合には、たとえば以下のような状況が発生していないか確認してください。

r ルータのセキュリティ設定によってゲームの通信が遮断されていた
r ルータのファームウェアに不具合があった
r 電波干渉などによる無線 LAN 環境の悪化により速度が出ていない状況だった
r UTP ケーブルの品質が低かった
r パソコンなどのネットワークインターフェースに不具合があった
r パソコンなどで MTU の値が小さく設定されていた
これらを確認するほかに、不具合が発生した場合に機器の初期化やパソコンの設定のデフォルト化などを試すという方法もあります。

†1「【特別企画】JPNE の高速回線サービス「v6 プラス」での PS4 オンラインプレイを検証」, Game Watch,2018 年 11 月 9 日 ：https://game.watch.impress.co.jp/docs/news/1151113.html†2「【特別企画】「v6 プラス」での Nintendo Switch オンラインプレイを検証」, Game Watch, 2018年 11 月 20 日 ：https://game.watch.impress.co.jp/docs/news/1152691.html

8.5 問題の切り分けと確認

103

8.5 問題の切り分けと確認問題が発生する可能性がある箇所をユーザ側から順番に見ていくと、ユーザが利用しているパソコンやスマホなどの機器、ホームゲートウェイもしくはブロードバンド
ルータ、ONU もしくは VDSL モデム、フレッツ網、IPv6 インターネット、IPv4 イン
ターネットになります（図 8.1）。

家庭内ネットワーク

フレッツ網

JPIX

JPNE
切り分けサイトONU
VDSLモデム

ホームゲートウェイ
ブロードバンドルータ

インターネット

Google
IPv6サイトフレッツ網内速度測定サイトフレッツ網外速度測定サイト▲

図 8.1 問題発生箇所の切り分け

何らかの通信障害発生が疑われる場合、これらのうちどの部分で問題が発生しているかを切り分けられるように、「JPNE 切り分けサイト」（図 8.2）が利用できます†3 。
JPNE 切り分けサイトでは、IPv4 や IPv6 の接続、あるいはフレッツ網からの接続に問題がないかをチェックできます。

r JPNE 切り分けサイト：https://kiriwake.jpne.co.jp/▲

図 8.2 JPNE 切り分けサイト†3「JPNE 切り分けサイト」に関する情報は 2023 年 1 月現在のものです。

104

第8章

FAQ とトラブルシューティング

なお、以下の状況では、JPNE 切り分けサイトによるチェックが失敗する可能性があるので注意が必要です。

r Google Chrome のライトモード（Google の Proxy 経由）が ON
r Cloudﬂare WARP などの VPN が設定されていた
上記状況では、JPNE 切り分けサイトとの接続がプロキシ経由になります。このとき、HTTP などによって JPNE 切り分けサイトと直接接続するのはプロキシです。そのため、JPNE 切り分けサイトのチェックで、v6 プラスを利用していないと判定されてしまいます。
JPNE 切 り 分 け サ イ ト 以 外 に も 、問 題 発 生 の 要 因 を 切 り 分 け る た め に 使 え る
Web サイトがいくつかあります。たとえば、Google が IPv6 でのみ提供している
ipv6.google.com は IPv4 ではアクセスできないので、ipv6.google.com が正しく表示できるかどうかで IPv6 インターネットとの通信が正しく行えているのかどうかを確認できます。

r Google の IPv6 専用ページ：https://ipv6.google.com/
また、「フレッツ速度測定サイト」により、ユーザ側のパソコン、ホームゲートウェ
イもしくはブロードバンドルータ、フレッツ網を通じた通信の正常性などの確認が可能です。

r フレッツ速度測定サイト：http://www.speed-visualizer.jp/

第9章

DS-Lite と A+P

v6 プラスにおける IPv6 over IPv4 では、第 4 章で説明した MAP-E が採用されています。IPv6 over IPv4 のための一般的な技術としては、MAP のほかに、RFC 6333 で規定されている DS-Lite という仕組みもあります。v6 プラスは MAP-E を採用しているため DS-Lite は v6 プラスの要素技術ではありませんが、DS-Lite による IPv4 over
IPv6 サービスを提供している VNE もあります。ここでは MAP との違いに焦点を当てて DS-Lite の概要を紹介します。

9.1 DS-Lite
DS-Lite という名称は ”Dual-Stack Lite” を省略したもので、「IPv6 と IPv4 のデュア

ルスタックを軽量に実現できる技術」という意図が込められています。MAP と同様に、基幹ネットワークを IPv6 のみで構築しつつ、ユーザに対しては IPv4 と IPv6 の両方が使えるデュアルスタックネットワークを提供できる仕組みです。IPv6 はそのままの状態で IPv6 インターネットとの通信できる点も MAP と同じです。
DS-Lite の概要を図 9.1 に示します。DS-Lite では、B4 および AFTR と呼ばれるルー

タの間に張られた IPv6 トンネルで、ユーザが利用するプライベート IPv4 アドレス空間からの IPv4 パケットを転送します。B4 と AFTR の間は IPv6 のみで構成できるので、ユーザに対して IPv4 インターネット接続サービスを提供しつつ、バックボーン
ネットワークは IPv6 のみで構成できます。

106

第9章

DS-Lite と A+P

IPv4インターネット

IPv6トンネル
IPv4アドレスそのまま転送
IPv6アドレスAFTR

B4

家庭内ネットワーク
ISPなどのIPv6ネットワーク

IPv6インターネット▲

図 9.1 DS-Lite の概要

NOTE
B4 は「ビフォー」と読み、AFTR は「アフター」と読みます。それぞれ ”Basic Bridging
BroadBand” および ”Address Family Transition Router” を表すとされていますが、「ユーザ側を「前方」とみなし、そこから「後方」のルータへの IPv6 トンネルをパケッ
トが通過する」という意味のほうが先にあったようです（こうした後づけの略字は IETF
での標準化ではよく見かけます）。

B4 では、IPv4 パケットを IPv6 パケットの中にカプセル化します。AFTR では、受け取った IPv6 パケットから IPv4 パケットを取り出したうえで IPv4 インターネットへとパケットを転送します。その際、AFTR では、IPv4 NAT によるアドレス変換も行います。つまり DS-Lite では、NAT 機能がユーザ側ではなく ISP 側にあります。これはMAP と DS-Lite の大きな違いのひとつです。
NAT 機能の位置は異なりますが、DS-Lite でも、MAP と同様に ISP のネットワーク

で大規模 NAT を導入することによる 2 段 NAT は避けられます。ただし、DS-Lite のAFTR には CGN 機器に類似する機能が必要になるので、DS-Lite の AFTR と MAP-E のBR とで後者のほうがシンプルな処理で済みます。
DS-Lite では、B4 が何らかの方法で AFTR の IPv6 アドレスを知る必要があります。
B4 に対して AFTR の名前を手動で設定して AFTR の IPv6 アドレスを得ることも可能

ですが、AFTR の名前を DHCPv6 で得るための仕組みもあり、RFC 6334 として標準化されています。

9.2 A+P

107

9.1.1 lw4o6
DS-Lite の名称の ”Lite” には「軽い」という意味合いがありますが、実際は AFTRの部分は「重い」仕組みです。そこで、AFTR における NAT 処理を B4 側で行うように変更した「軽量版 DS-Lite」と呼べる仕組みも考案されています。これが lw4o6（Lightweight 4over6）と呼ばれる規格で、RFC 7596 として定義されています。
lw4o6 では、RFC 7596 対応の DS-Lite における B4 と AFTR のことを、それぞれ
lwB4 および lwAFTR と呼んでいます。lw4o6 では、lwB4 が IPv4 NAT を担います。

そのため、IPv4 NAT に必要なグローバル IPv4 アドレスとポート番号のセットを lwB4が知っている必要があります。lwB4 では、この情報を Softwire46（RFC 7598）の
DHCPv6 オプションとして受け取ることになっています。

9.2 A+P
DS-Lite と同時期に、A+P（Address plus Port）と呼ばれるプロトコルも議論されていました。DS-Lite と A+P には似た部分があり、Internet Draft として議論されていたときには両者を統合するという案もありました。しかし、最終的に DS-Lite はStandard Track の RFC 6333 になり、A+P のほうは Experimental な RFC 6346 になりました。
A+P は、名前のとおり、IP アドレスとポート番号を活用した仕組みです。MAP-E

も IP アドレスとポート番号を活用する仕組みでしたが、実は A+P は MAP-E のもとになった仕組みともいえます。そのため、DS-Lite と A+P の考え方の違いを知ることは、
DS-Lite と MAP-E の考え方の違いを知るうえでも参考になります。
A+P では、IPv4 アドレスと TCP もしくは UDP のポート番号のセットを利用することで IPv4 アドレスを共有します。具体的には、複数の CPE が同じ IPv4 アドレスを利用しつつ、割り振られたポート番号のみを利用します。
CPE からの IPv4 パケットは、PRR（Port-Range Router）と呼ばれるルータまでトンネルを通って転送されます。IPv4 インターネット側からのパケットは、PRR がポー
ト番号に応じて適切な CPE とつながるトンネルへと転送します。
図 9.2 では、PRR が 192.0.2.100 というグローバル IPv4 アドレスを利用しています。CPE A と CPE B も、PRR と同じ 192.0.2.100 という IPv4 アドレスを利用しますが、CPE A が利用するポート番号が 0〜1023、CPE B が利用するポート番号が1024〜2037 という違いがあります。

各 CPE は、PRR へとパケットを送信する前に、必要に応じて NAT やポート番号を変換します。

108

第9章

DS-Lite と A+P

IPv4アドレス 192.0.2.100
ポート番号 0〜1023

CPE A

IPv4アドレス 192.0.2.100
ポート番号 0〜65535

プライベート
IPv4ネットワーク
IPv4アドレス 192.0.2.100
ポート番号 1024〜2047

IPv4インターネット

CPE B

プライベート
IPv4ネットワーク

ISPなどのIPv6ネットワーク▲

図 9.2 A+P の構成例

このとき各 CPE は、割り当てられたポート番号の範囲内であれば、NAT による変換
をせずにパケットを転送することも可能です。たとえば、192.0.2.100 という IPv4
アドレスを家庭内の PC が利用していて、送信元ポート番号を CPE に割り当てられたものの範囲内に限定できるのであれば、CPE で NAT による変換をせずに通信が可能です。

9.2.1 DS-Lite との違い
技術的には似た面もありますが、A+P と DS-Lite とでは、提案のモチベーションが大きく異なります。DS-Lite のモチベーションは、デュアルスタック運用のコスト削減でした。これに対し、A+P のモチベーションは、CGN の問題を解消することにありました。A+P の RFC では、CGN の問題として、UPnP が使えない、多くのユーザの通信ステートを CGN で保持しなければならない、単一障害点になりうるといった点が具体的に挙げられています。
DS-Lite と A+P では、提案の方針にも大きな違いがあります。DS-Lite では具体的な技術が述べられているのに対し、A+P では考え方が中心に述べられているのです。
たとえば、DS-Lite では B4 と AFTR の間のトンネルを IPv6 で構築します。一方、
A+P では、L2 延伸を含む「何らかの方法」とあるだけです。A+P で必要となるシグナ

リングプロトコルも、詳細が RFC に示されているわけではなく、可能性がある手法がいくつか列挙されているだけです。
DS-Lite と A+P では、NAT による変換が発生する場所も異なります。図 9.3 のよう9.2 A+P

109に、DS-Lite が IPv4 ネットワークの手前で NAT を行うのに対して、A+P は MAP と同様に CPE 側で NAT を行います。さらに、A+P では NAT を使わないことも可能です。
プライベート
IPv4ネットワーク

ISPなどのIPv6ネットワーク

IPv4インターネット

IPv6トンネル
IPv4アドレスここでNATをするのがA+P

ここでNATをするのがDS-Lite▲

図 9.3 DS-Lite と A+P の違い

ステートレスであることも A+P の大きな特長です。A+P では、グローバル IPv4 ア
ドレスとポート番号を NAT で利用することで、ステートを保持せずに自動的な変換が可能になっています（ただし、ICMP やフラグメントされた IP パケットについては、
通常の NAT と同様にステートフルな変換が必要です）。

［書籍版では空白のページです］

索引
記号・数字
4 つの案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 タプル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

A
A+P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
AAAA レコード . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . 18
ADF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
ADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
ADSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
AFTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
ALG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
APDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
APDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

DHCP サーバ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
DNS プロキシ . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45, 105

E
EA ビット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
EIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
EIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

F
FLET S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
FTP
NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
通信できない . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

B
B4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Basic NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
BBIX 株式会社 . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Border Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
BR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6, 40
B フレッツ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

C
CDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
CE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
CGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44, 73
A+P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
運用コスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
通信への影響 . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . 80
CPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6, 39, 81

D
DHCPv6-PD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

G
GMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

I
IID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
IPv4 NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
IPv4 over IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36, 37
DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
IPv4 PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 33
IPv4 アドレス . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
ISP からの割り当て . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
IPv4 アドレス在庫枯渇問題 . . . . . . . . . . . . . . . . . . . . . 13, 50
IPv4 インターネット接続
PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33, 36
v6 プラス . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
トラブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
IPv4 と IPv6 のどちらで接続するか . . . . . . ... . . . . . . 19

索引

112

IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2, 15
IPv6 IPoE 方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 33
IPv6 PPPoE 方式との違い . . . . . . . . . . . . ... . . . . . . . . . . . . 31
接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
必要な理由 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
IPv6 PPPoE 方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
フレッツ網内宛 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
IPv6 アドレス
IPv4 アドレスとの違い . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
IPv6 PPPoE 方式 . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . 32
Policy Based ルーティング . . . . . . . . . . . . . . . . . . . . . . . 35
v6 プラス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8, 81
IPv6 トンネルアダプタ . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . 32
IPv6 パススルー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
IPv6 閉域網 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2, 30
IPv6 マルチプレフィックス問題 . . . . . . . . . ... . . . . . . . . . 26
フレッツ網 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
IP アドレス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
IP トンネル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
ISDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
ISP
IPv4 インターネット接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
IPv6 IPoE 方式での役割 . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . 33
v6 プラス . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

J
JPIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4, 5
B2B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
JPNE 切り分けサイト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
JPNE ソフトウェア . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . 85, 95

LLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
lifetime（NAT テーブル） . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . 57
lw4o6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
lwAFTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
lwB4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

ホームゲートウェイの設定 . . . . . . . . . . . . . . . . . . . . . . . 85
MAP-T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
MAP ドメイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
MAP ルール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
配信 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

N
NAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7, 14, 47
FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
RFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
機器への要求事項 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
仕組み . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
接続例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
歴史 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
NAT binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
NAT mapping . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . 52
NAT44 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
MAP-E で無効化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
NAT444 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
NAT66 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
NAT 機器
セッション数の上限 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
NAT 越え . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61, 67
CGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
できない . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
NAT テーブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
NAT ルータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
v6 プラス . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
動作例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
NTT NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
NTT NGN IPv6 マルチプレフィックス問題. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
NTT 東西 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2, 25
NTT 法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

M
MAP BR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
MAP CE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39, 81
MAP-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6, 37
CGN との違い . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
ポート番号 . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . 100

PP2P
CGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62, 72
v6 プラス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

索引

Policy Based ルーティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Port Restricted Cone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
PRR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
PSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

R
RA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
RPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Rule IPv4 プレフィックス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Rule IPv6 プレフィックス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
接続シーケンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
全体像 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9デュアルスタック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
名前の由来 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
申し込み . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
利用しない場合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
利用条件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
v6 プラス IPv4 設定ソフトウェア . . . . . . . . ... . . . . . . . . 95
v6 プラス対応 NAT ルータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
VNE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 31, 34
VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

WS

WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
SFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
SIP
NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
通信できない . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Softwire46 . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
SOHO ルータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62, 77

アT

インターネットプロトコル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
インターネットマルチフィード株式会社 . . . . . 4
インターフェース識別子 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Traditional NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

U
UDP
NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
UNSAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62, 72
UPnP IGD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64, 101
CGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
v6 プラス . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66V
v6 プラス
IPv4 インターネット接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
IPv6 アドレス . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . 8
IPv6 インターネット接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
MAP-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
NAT 機器の要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

アクセスログ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
アドレス依存フィルタリング . . . . . . . . . . . . . . . . . . . . . . . . . 71
アドレス依存マッピング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
アドレスとポート依存フィルタリング . . . . . . . 71
アドレスとポート依存マッピング . . . . . . . . . . . . . . . . . 69

イエ
エンドポイント非依存フィルタリング . . . . . . . 70
エンドポイント非依存マッピング . . . . . . . . . . . . . . . . . 68

オ
オンラインゲーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

カ外部グローバル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
外部ローカル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
株式会社 JPIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
カプセル化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37, 106

キキャッシュ DNS サーバ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 83

ケ
ゲートウェイルータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

113

114

索引

ゲーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

コ
固定 IPv4 アドレス（v6 プラス） . . . . . . . . . . . . . 8, 87

サ

日本電信電話株式会社等に関する法律 . . . . . . . 26
日本ネットワークイネイブラー株式会社 . . . . . 4

ネネイティブ方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

サブネットプレフィックス . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . 15

ヒ

シ

ひかり電話
IPv6 ネットワーク構成の違い . . . . . . . . . . . . . . . . . 83

ジオロケーション . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . 78
商用インターネット接続サービス . . . . . . . . . . . . . . . . . 48

セ
生存時間
CGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
NAT テーブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
セキュリティ（NAT） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
接続シーケンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

ソ
速度測定サイト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

タダイアルアップ接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
大規模 NAT . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . 44, 73
タイムラグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

テデュアルスタック . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . 17

ト
トラブルシューティング . . . . . . . . . . . . . . . . . . . . . . . 97, 103
トンネル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
トンネルアダプタ . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . 32
トンネル方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

ナ
内部グローバル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
内部ローカル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
名前解決 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

ニ日本インターネットエクスチェンジ株式会社.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

フフィルタリング（NAT 機器） . . . . . . . ... . . . . . . . 67, 70
プライベート IPv4 アドレス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
歴史 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
プライベート IP アドレス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
フレッツ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
フレッツ・v6 オプション . . . . . . . . . . . . . . . . . . . . . . . . . 35, 94
フレッツ・ネクスト . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . 3
フレッツ網 . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . 2, 26
IPv4 トラフィック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
フレッツ速度測定サイト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
フレッツ網内宛通信
IPv6 IPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
IPv6 PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . 32
フロー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
ブロードバンドアクセスエクスチェンジ企画株式会社 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
ブロードバンドルータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
v6 プラス対応 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
未対応 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
プロトコル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
プロトコルスタック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
プロバイダ責任制限法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

ホ
ポート開放 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
ポート番号
CGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
lw4o6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
MAP-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
アクセスログ . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . 76
上限 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
ポートフォワーディング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

索引

ホームゲートウェイ . . . . . 33, 39, 61,84, 91, 94
未対応 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

マリ
利用条件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

ル

マッピング（NAT 機器） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
マルチホーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

ルール配信サーバ . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . 61, 82

ムレ

無線 LAN ルータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

レコード（DNS） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
レジデンシャルゲートウェイ . . . . . . . . . . . . . . . . . . . . . . . . . 39

モ
網内折り返し . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
モデム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

ロ
ローミングサービス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

115

［書籍版では空白のページです］

■ 監修者紹介

株式会社 JPIX
英文名称：Japan Internet Xing Co., Ltd.（JPIX）
日本ネットワークイネイブラー株式会社として 2010 年 8 月に設立。2023 年 1 月より日本インターネットエクスチェンジ株式会社と合併、ISP へのローミングサービス、
IX サービス、コロケーションサービス、その他付加価値サービス等の提供を主な事業とする。

■ 著者紹介小川晃通（おがわ あきみち）
慶應義塾大学にて博士（政策・メディア）取得。プログラミング、テクニカルライ
ティング、コンサルティング、DTP、セミナーや講演なども手がける。著書に『プロフェッショナル IPv6 第 2 版』
『ピアリング戦記 日本のインターネットを繋ぐ技術者たち』（ラムダノート）、『インターネットのカタチ』『マスタリング TCP/IP OpenFlow編』（オーム社）、『アカマイ 知られざるインターネットの巨人』（KADOKAWA メディ
アファクトリー）、『ポートとソケットがわかればインターネットがわかる』（技術評論社）など。
YouTube チャンネル https://www.youtube.com/user/geekpage

久保田聡（くぼた さとし）
（本書刊行当時）日本ネットワークイネイブラー株式会社技術部所属。通信キャリ
ア、ISP でバックボーン運用、セキュリティ企画・運用を経て、2011 年より KDDI 株式会社から JPNE へ出向。JPNE では v6 プラスをはじめとするサービスの技術企画、構築を担当。

技術書出版社の立ち上げに際してコンピュータとネットワーク技術の普及は情報の流通を変え、出版社の役割にも再定義が求められています。誰もが技術情報を執筆して公開できる時代、自らが技術の当事者として技術書出版を問い直したいとの思いから、株式会社時雨堂をはじめとする数多くの技術者の方々の支援をうけてラムダノート株
式会社を立ち上げました。当社の一冊一冊が、技術者の糧となれば幸いです。
鹿野桂一郎

徹底解説 v6 プラス
Printed in Japan ／ ISBN 978 4 908686 08 5
2020 年 1 月 22 日
2023 年 1 月 25 日
監

修

著

者

発行者
編

集

制

作

装

丁

印

刷

製

本

第 1 版第 1 刷 発行
第 1 版第 3 刷 発行

株式会社 JPIX
小川晃通・久保田聡
鹿野桂一郎
高尾智絵
鹿野桂一郎
轟木亜紀子（トップスタジオ）
平河工業社
平河工業社

本書の発行にあたって協力を頂いた皆様

株式会社 JPIX 様から本書の制作費を支援いただきました発行

ラムダノート株式会社
lambdanote.com
東京都荒川区西日暮里 2-22-1
連絡先 info@lambdanote.com