iDC サービスの IPv6 対応ガイドライン
2010 年 9 月 22 日 第 0.1 版
2011 年 1 月 11 日

第 0.2 版

IPv4 アドレス枯渇対応タスクフォース
サービスロゴ WG
技術検討 SWG〔注〕
本ガイドラインは、昨年 9 月末に技術検討 SWG で作成したガイドラインに一部表現等の変更を加えたものです。さらなる推敲を要する箇所も有るかもしれませんが、IPv4 アドレス枯渇を目前に控えて、iDC のガイドラインを早く公開した方が良いと考え、第 0.2 版として公開することとしました。
技術検討 SWG【問合せ先】サービスロゴ WG

v4exh-logo@mri.co.jp

1
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

目次
1. はじめに __________________________________ 3
1.1.

目的 ................................................................................ 31.2.

想定 iDC 環境 ................................................................. 41.3.

記述用語 ......................................................................... 4

2. 必要条件 __________________________________ 62.1.

iDC の到達性 .................................................................. 82.2.

iDC 網内部の機能......................................................... 102.3.

提供サービス .................................................................112.4.

2.3.1.

iDC 共通基盤 .................................................................................112.3.2.

ホスティング................................................................................ 142.3.3.

レンタルサーバ ............................................................................ 142.3.4.

ハウジング ................................................................................... 15

エンドユーザへの提供機能 .......................................... 152.4.1.

基本提供機能................................................................................ 152.4.2.

オプション提供機能 ..................................................................... 172.4.3.

ユーザサポートの提供 ................................................................. 18

3. 終わりに _________________________________20
3.1.

まとめ........................................................................... 203.2.

今後の課題 ................................................................... 203.3.

参考資料 ....................................................................... 21

4. 付録 _____________________________________22
4.1.

著者一覧 ....................................................................... 22

2
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

1. はじめに1.1. 目的
我が国の社会経済活動の基盤となっているインターネットについては、近年の急速な普及により、IPv4 アドレスの在庫が 2011 年にも枯渇する見込みとされている。したがって、インターネットの持続的な発展を維持するためには、現在利用されている IPv4 の後継規格である IPv6に対応することが急務となっている。ネットワーク機器に関する IPv6 対応基準については、国際的に IPv6 の推進に取り組んでいる IPv6 フォーラム（本部：ルクセンブルク）により運用されている IPv6 Ready Logo Program において明確に定義されている。
一方、インターネット上の様々なサービスを利用している個人ユーザ、法人ユーザ等にとって、今後サービスを選択する際には、当該サービスが IPv6 に対応しているかどうかが選択の基準の一つとなることが想定される。しかし、現在は「サービスが IPv6 に対応していること」を利用者が確認するための目安がなく、利用者がどのようなサービスを選択すればよいか判断することが困難である。また、サービス提供業者にとっても、利用者への訴求力を高めるため、自らの提供するサービスが IPv6 に対応していることを効果的にアピールしたいという要望は大きい。さ
らに、現在 IPv6 フォーラムにおいてもインターネットサービスプロバイダー（ISP）等が提供するインターネットサービスの IPv6 対応に関する基準の策定について検討が行われており、このようなサービス提供者の要望は世界的にも大きいと考えられる。
この様な状況を踏まえ、以下のような点に資することを目的として、総務省では「インターネットサービス等の IPv6 対応に係る基本指針」(以下、「基本指針」とする)を策定し、現在 IPv4で提供されているインターネットサービス等が IPv6 でも提供できるようにするために最低限満たすべき基準についての基本的な考え方を定めた。
（１）サービスの IPv6 対応の目安の提供（２）利用者の円滑な IPv6 対応の促進（３）国内サービスの海外展開の促進
なお、基本指針は、現在 IPv4 で提供されているインターネット接続サービス等について、IPv6でも提供できるようにするために最低限満たすべき基準について基本的な考え方を定めたものであり、コンテンツ配信サービスやオンラインショッピング等の個別サービスについての詳細な要求条件や、複数のサービスを組み合わせた際の相互接続性を確保するための要求条件については規定していない。
本書は、iDC が最低限満たすべき要求条件について整理するだけでなく、さらに検討を深め、iDC の運用条件等も加味した、各 iDC に共通する要求条件を整理した拡張仕様となっている。
これにより、個人および法人ユーザが iDC によるサービスの IPv6 対応状況の詳細を把握できること、また、サービスを提供する iDC が IPv6 対応状況の細部を共通な尺度でアピールできることを期待している。
3Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

また、本書は、国内サービスの海外展開の促進に資するべく、今後、IPv6 フォーラムへ認定ロゴの仕様となるよう提案する事も考慮して、まとめたものである。

1.2. 想定 iDC 環境
今後、インターネット上に IPv6 ネイティブ環境のユーザが登場する可能性がある。そこで本書では、そのようなユーザとの通信環境を想定し、個人ユーザ、法人ユーザ等向けホスティング・レンタルサーバ・ハウジング等の iDC サービスを提供する事業者を対象としている。

1.3. 記述用語
本書にて使用されている用語は、IAJapan（財団法人日本インターネット協会）においてまとめ て い る 、「 IPv6 関 連 用 語 集
第 一 版 」 ( IPv6 関 連 用 語 集 （ IAJapan ）：http://www.iajapan.org/ipv6/v6term/glossary_01.html) に従っている。各用語に関する解説は用語集を参照して頂きたい。また、上記に記述されていない用語で、本書内で用いている用語について以下に示す。

¾ マルチホーミング
インターネット回線を複数の経路を利用して接続すること。

¾ ピアリング（peering）
2 社のインターネット接続事業者（プロバイダ）等が，相互に対等の条件で接続し、互いにトラフィックを交換し合うこと。

¾ RTT
Round Trip Time の略。往復遅延時間。

¾ ルートサーバドメインと IP アドレスのマッピングを管理する DNS の階層構造で最上位に位置するサーバ。
インターネット上のドメイン検索を行う場合、ルートサーバへの到達性は必要不可欠。

¾ IRR
Internet Routing Registry の略。Autonomous System が管理プレフィックス、AS-PATH などの経路情報を蓄積するデータベース。

¾ MTU
Maximum Transmission Unit の略。通信時に 1 回で送信できるデータ量の最大値。
4Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

¾ MX
ドメインのメールサーバを記述する DNS レコード。sample@example.jp にメールを送信する
場合、送信元メールサーバは example.jp の MX レコードを送信先 DNS サーバに問い合わせ、応答を得た IP アドレス宛にメールを送信する。

¾ トランスポート（IPv6 でのトランスポート）
OSI 参照モデルのレイヤー4 のこと。IPv6 で通信をする場合に、レイヤー4 も含めてセッションが確立することを、「IPv6 でのトランスポート」と呼ぶ場合が多い。

¾ キャッシュ（DNS）
DNS 再帰問い合わせを行い、その結果を内部にキャッシュ（蓄積）する機能を持った DNS サーバ。クライアントからの問い合わせが合った場合、内部にキャッシュされていれば、キャッシュのデータを返答する。

¾ NTP
Network Time Protocol の略。ネットワークに接続される機器において、機器が持つ時計を正しい時刻へ調整するための通信プロトコル¾ ホスティング・サービス
インターネットを利用する法人や個人に、サーバーの容量の一部を間貸しするサービス。

¾ レンタルサーバ・サービス
サーバや回線を自前で用意できない顧客から公開したい情報内容(コンテンツ)を預かり、インターネットに接続された自社サーバで公開するサービス。

¾ ハウジング・サービス
顧客が自分で通信機器やサーバを用意し、それを回線や電源設備の整った事業者の施設に設置するサービス。
「コロケーション(collocation)」サービスとも言う。

¾ ローミング（roaming）
契約している通信事業者のサービスを、その事業者のサービス範囲外でも、提携している他の事業者の設備を利用して、元の事業者と同等のサービスを受けられるようにすること。

¾ インシデント（incident）
情報管理やシステム運用に関して保安上の脅威となる現象や事案(セキュリティインシデント)のこと。

5
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

2. 必要条件
本章では、iDC が商用サービスレベルの IPv6 接続性提供を行うために満たすべき条件について記載する。ここでの商用サービスレベルとは、RFC5211 Section2.2 で記載されているTransition Phase 相当を想定している。特徴として、IPv4 と同等の接続サービスを IPv6 で提供、ユーザ向けサービス（たとえばメールなど）の提供、内部ネットワークでの IPv6 対応が挙げられる。
ここで挙げている条件は一般的に多くの iDC にあてはまる項目であり、iDC の提供サービス内容によってはこれ以上の対応が必要となる場合がある。本章記載の仕様は総務省発行の「インターネットサービス等の IPv6 対応に係る基本指針」 に準拠している。
条件は 5 つのテーマ、合計 38 の項目に分類される。サービス提供形態により分類（必須 or推奨）が分かれる 1 項目含め、全 38 項目のうち必須条件、すなわち認定機関がチェックするべき項目は 14 項目、必須ではないものの、iDC として対応することが推奨される項目は 27 項目である。IPv6 に対応する iDC は、必須条件には最低限対応すべきであり、可能な範囲で推奨条件にも対応することが望ましい。表１に項目の一覧を示す。詳細な説明は 2.1 章より解説する。
各項目の詳細説明部分では、必須を 2 段階の CRITICAL と MUST,推奨を 2 段階の SHOULDと RECOMMEND に分別する。CRITICAL、SHOULD の方が推奨度合いは強い。
また、参考として既に運用開始されている「IPv6 Enabled ISP Logo Program, BASIC Level」に要求される条件を表２に示す。
表１

必要条件一覧

テーマ

項目

推奨

IX への到達性○

外部との接続の冗長性○

iDC の到達性

到達時間(RTT)○(Reachability)

ルートサーバへの到達性○

フィルタ回避○MTU 問題対応(Performance)

スループット

提供サービスiDC 共通基盤○

経路情報の開示ISP 網内部の機能(Service)

必須

メールのトランスポート

○

※
○

○

メール／ユーザの送受信方式○

メール／ユーザの代替手段○【法人】メール／MX リレー○

メール／セキュリティ対策○

DNS／キャッシュ

○DNS／セカンダリ○

6Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

【法人】DNS／逆引き○

DNS／レコード登録

○

NTP

○

ユーザ専用ページ

ホスティング○

提供 OS の表示○

ユーザ専用ページ

レンタルサーバ○

対応サービスの表示

ハウジング

○

回線種別

基本提供機能○アドレス付与／内容○

アドレス付与／方法○

IPv6 提供方法○

エンドユーザへトランスレータ○の提供形態

経路情報○（Access &IPv6 監視○Specification)

IPv6 監視のトランスポート○

オプション提供機能

セキュリティ

○

コマンド

○

ログ

○

保守運用

※

○

インシデント対応○

顧客対応窓口

ユーザサポートの提供（Support)○

IPv6 マイグレーション○

IPv4/v6 障害切り分け○※マネージドサービス等を提供している場合は必須
表２ IPv6 Enabled ISP Logo Program, Basic Level 必要条件一覧【参考】
テーマ項目

必須

割り振り IPv6 アドレス情報○インターネットへの接続性

割り当て IPv6 アドレス情報○(Reachability)

IPv6 経路広報 AS 番号情報

○

経路広報

○

WEB（動作確認コンテンツ）○

提供サービス(Service)メール○

DNS／キャッシュ

○回線種別
エンドユーザへの提供形態（Access & Specification)

推奨○

アドレス割当／内容○

アドレス割当／方法○

IPv6 ネイティブ接続方法○

WEB（動作確認コンテンツ）への接続

○

保守運用

○

サポートの提供

インシデント対応○（Support）

会員専用ページ○

ユーザサポート○

申請方法など、詳しくは、http://ipv6.jate.jp/enabled/ を参照ください。
7
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

2.1. iDC の到達性
¾ IX への到達性
認定条件
推奨(RECOMMEND)要件
IX に接続し他の ISP と経路を交換して相互にトラフィックを流通可能であること
理由
IX に接続することは相互の経路を最適化しレイテンシを小さくするのに効果的であるため
備考
IX に接続しなくてもインターネット接続性を得ることは可能であるため、必須とはしない¾ 外部との接続の冗長性/upstream・マルチホーミング
認定条件
推奨(RECOMMEND)
要件
常に複数の upstream ISP と接続し、ひとつの upstream ISP が断になっても到達性を維持すること
単一の upstream ISP と接続する場合は、接続回線を複数設けること
理由
サービスとして接続性を提供する以上、単一回線の障害で全断してはならないため¾ 外部との接続の冗長性/peering
認定条件
推奨(RECOMMEND)
要件
他の ISP や iDC と peering して相互接続可能なこと
理由
接続経路を最適化し、品質を向上させることができるため
備考
他 ISP や iDC との peering をアピールする際には正しい表記が求められる

8Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

¾ 到達時間（RTT）
認定条件
推奨(RECOMMEND)要件
iDC 網から特定の拠点に対する RTT を提示できること
理由
RTT は品質を示す基本的な情報であり、常時計測可能であることが重要であるため
備考
外部拠点への RTT を表記する際には条件を正しく提示する¾ ルートサーバへの到達性
認定条件
必須(MUST)
要件
iDC 網からクリティカルインフラであるルートサーバへの到達性を提示できること
理由
インターネットの商用利用において、ルートサーバへ到達できること、すなわち DNS を利用した名前解決ができることは必須であるため。(2.3 章参照)

¾ 経路情報の開示
認定条件
推奨(SHOULD)要件
iDC へのルーティングに関する情報が外部から参照可能なデータベース(IRR)に正しく登録されていること
理由
経路情報の正常性を確認するのに必要であるため¾ フィルタ回避
認定条件
推奨(RECOMMEND)
要件
常に正しい経路情報を広告していること

9
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

理由
iDC 網への到達性を正しく保たないと接続性を維持できないため
備考
世界のサイトと通信が行えるように経路広告を正しく行う

2.2. iDC 網内部の機能¾ MTU 問題対応
 MTU 問題対応/pMTUD
認定条件
必須(CRITICAL)要件
iDC 網を構成する全てのルータが packet too big を転送できる状態にあること
理由
フラグメントされない IPv6 では path MTU discovery が機能しないと通信不能に陥り、データセンターのサーバが、一部サービス不能などの欠陥が発生してしまうため
備考
RFC4890(Recommendations for Filtering ICMPv6 Messages in Firewalls)
too big を返し ICMPv6 を filter out しない MTU 問題対応/上限開示
認定条件
推奨(RECOMMEND)要件
iDC が提供する回線に MTU の上限がある場合はそれを開示すること
理由
ユーザがあらかじめ MTU を設定することができ、packet too big の発生を抑制できるため
備考
PPPoE 等の認証ヘッダによる MTU 上限がある場合は表記することが望ましい¾ スループット
認定条件
10Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

推奨(RECOMMEND)
要件提供する回線の最低利用可能な帯域を表記すること
理由
IPv6 で利用できる帯域が IPv4 と比べて劣る場合適切に表示することが必要であるため
備考
帯域に制限がある場合は表記することが望ましい

2.3. 提供サービス
2.3.1.

iDC 共通基盤¾ メールのトランスポート
認定条件
必須（CRITICAL）
要件
外部のメールサーバー間で IPv6 トランスポートが可能であること
また、MX レコードに IPv6 に対応したサーバが指定してあり、かつ、IPv6 での到達性があること
理由
メールサービス、メールサポートにおいて IPv6 でのトランスポート提供が必要であるため¾ メール／ユーザの送受信方式
認定条件
推奨（RECOMMEND）
要件
一般的な方式が使用できること。また、その方式を提示すること
理由
方式が提示されていることが望ましいため
備考
上記記載の方式とは、POP、IMAP4、SMTP、POPS、IMAP4S、SMTPS 等

11
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

¾ メール／ユーザの代替手段
認定条件
推奨（RECOMMEND）
要件
一般的なメールサービスが提供されない場合、代替手段として web メールなどを提供する場
合は IPv6 環境でも提供すること
理由
IPv4 インターネット同様に環境整備することが望ましいため¾ 【法人】メール／MX リレー
認定条件
推奨（RECOMMEND）
要件
法人ユーザ自身で用意したサーバと IPv6 で MX 通信できる MX リレーサービスを提供すること
理由
法人サービスに対しては、IPv6 でのトランスポート環境の提供が必要であるため¾ メール／セキュリティ対策
認定条件
推奨（RECOMMEND）
要件
IPv6 でアクセスできるメールボックスに対して、ウイルスチェックサービス、SPAM 対策等、セキュリティサービスを提供すること
理由
IPv4 と同等のセキュリティ対策を提供することが望ましいため¾ DNS／キャッシュ
認定条件
必須（CRITICAL）
要件
DNS キャッシュ機能を提供する場合は、IPv6 トランスポートでも提供すること
理由
提供するサーバ間で IPv6 トランスポートを持つことが必須であるため

12
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

¾ DNS／セカンダリ
認定条件
必須（CRITICAL）
要件
セカンダリ DNS サービスが IPv6 トランスポートで配送できること
理由
プライマリ DNS と同等のトランスポートを持つことが必須であるため¾ 【法人】DNS／逆引き
認定条件
推奨（RECOMMEND）
要件
法人顧客に割り当てたアドレスの全てまたは一部が逆引き登録されていること

理由
ユーザの使用環境により DNS の逆引きが必要なことがあるため¾ DNS／レコード登録
認定条件
必須（CRITICAL）
要件
AAAA レコードを登録できること
理由
ドメイン名からサーバにアクセスするのに必須であるため

¾ NTP
認定条件
推奨（RECOMMEND）
要件
網内、外部の NTP サーバに IPv6 トランスポートが可能であること
理由
NTP サーバと IPv6 でのトランスポートができることが望ましいため

13
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

2.3.2.

ホスティング¾ ユーザ専用ページ
認定条件
推奨（SHOULD）
要件
ユーザ専用ページを提供している場合は IPv6 環境でも提供すること
理由
IPv4 インターネット同様に環境整備することが望ましいため¾ 提供 OS の表示
認定条件
必須（MUST）
要件
IPv6 対応として提供できる OS を表示すること
理由
IPv6 対応として提供できる OS とできない OS の区分を明確にするため
備考
対応 OS が一部のみの場合はユーザに誤解なく提示することを推奨する

2.3.3.

レンタルサーバ¾ ユーザ専用ページ
認定条件
推奨（SHOULD）
要件
ユーザ専用ページを提供している場合は IPv6 環境でも提供すること
理由
IPv4 インターネット同様に環境整備することが望ましいため¾ 対応サービスの表示
認定条件
必須（MUST）
14
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

要件
ユーザに提供するサービス(Web,Mail,FTP,SSH 等)が IPv6 で提供されていること
理由
IPv6 でのトランスポート提供が必須であるため

2.3.4.

ハウジング¾ 回線種別認定条件
推奨（RECOMMEND）
要件
エンドユーザに提供する回線種別を明記すること（例：ADSL,フレッツ,CATV,携帯網等）
理由
エンドユーザへ提供する回線種別を明確にすることが望ましいため

2.4. エンドユーザへの提供機能
2.4.1.

基本提供機能¾ アドレス付与／内容
認定条件
必須（MUST）
要件
アドレス割当ての提供内容について正しく表記すること（例：固定／非固定、prefix 長、prefix割当個数等）
理由
アドレス割当ての提供内容をエンドユーザに誤解なく提示することが望ましいため¾ アドレス付与／方法
認定条件
必須（MUST)

15
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

要件
アドレスの付与方法を正しく表記すること（例：DHCPv6,手動設定等）
理由
アドレスの付与方法をエンドユーザに誤解なく提示することが望ましいため¾ IPv6 提供方法
認定条件
必須（MUST)
要件
IPv6 通信の提供方法について正しく表記すること（ネイティブ／トンネル、PPPoE／IPv6
over IPv4 等）
理由
IPv6 通信の提供方法はいくつも考えられるので、正しく表記することが望ましいため¾ トランスレータ
認定条件
推奨（RECOMMEND）
要件
IPv4⇒IPv6/IPv6⇒IPv4 トランスレータを提供する場合、提供方法を提示すること理由
IP アドレスによりコンテンツを参照しているケースがある場合、問題になるケースがあるため¾ 経路情報
認定条件
推奨（RECOMMEND）
要件
IPv6 経路提供方法を正しく表記すること（RIPng／スタティック等）
理由
IPv6 を提供する場合、IPv6 経路提供方法を正しく表記することが望ましいため16
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

2.4.2.

オプション提供機能¾ IPv6 監視認定条件
必須（MUST)
要件
iDC 網の IPv6 ノードに対して、データセンター側から IPv6 サービスの監視を実施できる事（ICMP／Port／Service）
理由
監視ツールが IPv6 に対応していることをエンドユーザに提示することが望ましいため¾ IPv6 監視のトランスポート
認定条件
必須（MUST)
要件
iDC 網の IPv6 ノードへの監視が IPv6 トランスポートで行われていること
理由
IPv4 併用の監視も考えられるので、正しく表記することが望ましいため¾ セキュリティ
認定条件
推奨（SHOULD)要件
iDC のセキュリティポリシーを表示すること理由
iDC のセキュリティポリシーをエンドユーザに誤解なく提示することが望ましいため¾ コマンド認定条件
推奨（SHOULD）
要件
ping、traceroute 等の基本コマンドが IPv6 で提供されていること

17
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

理由
運用環境が IPｖ６に対応していることをエンドユーザに提示することが望ましいため

¾ ログ
認定条件
推奨（SHOULD)
要件
iDC 網の IPv6 ノード間でシスログ転送ができる
理由
シスログ転送が IPv6 に対応していることをエンドユーザに提示することが望ましいため

2.4.3.

ユーザサポートの提供¾ 保守運用認定条件
推奨（SHOULD) ※マネージドサービス等を提供している場合は必須（MUST）
要件
顧客が容易に確認できる方法で運用体制の有無を表示すること
理由
商用サービスとして提供するために体制作りと告知が必須であるため
備考
ローミングによるサービス提供のように、保守運用サービスがない場合でも表示すること¾ インシデント対応
認定条件
推奨（RECOMMEND）
要件
顧客が容易に確認できる方法で受付窓口の有無を表示すること
理由
IPv4 インターネット同様に窓口を設置することが望ましいため¾ 顧客対応窓口
認定条件
18
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

必須（MUST）
要件
顧客が容易に確認できる方法で受付窓口の有無を表示すること
理由
IPv4 インターネット同様に環境整備することが望ましいため¾ IPv6 マイグレーション（ユーザーサポート）
認定条件
推奨（RECOMMEND）
要件
IPv6 マイグレーションサポートができれば表示する
理由
今後顧客の IPv4 から IPv6 への移行が増えると考えられるので、iDC でサポートできる体制を整備することが望ましいため¾ IPv4/v6 障害切り分け（ユーザーサポート）
認定条件
推奨（RECOMMEND）
要件
IPv4/v6 障害切り分けができれば表示する
理由
IPv6 への過渡期で IPv4/v6 が混在する環境が今後も残ると考えられるので、iDC で障害切り分けができる体制を整備することが望ましいため19
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

3. 終わりに

3.1. まとめiDC が IPv6 に対応するためには、事業者毎に様々な手法や事情があるが、本書では対応のために最低限満たしておかなければならないと思われる要素を取り上げている。最低限の要素をまとめると以下の通り。
1 ルートサーバへの到達性
2 Path MTU Discovery への応答
3 IPv6 トランスポートでのメール配送(MX)4 DNS 権威サーバの IPv6 対応
5 DNS キャッシュサーバの IPv6 対応
6 IPv6 に関連する DNS レコードの登録
7 [hosting の場合]提供 OS の明記
8 [レンタルサーバの場合]IPv6 対応サービスの明記
9 アドレス付与内容の明記
10 アドレス付与方法の明記
11 IPv6 提供方法の明記
12 IPv6 サービスの監視
13 死活監視の IPv6 での実施
14 顧客窓口対応
ただし、IPv6 Enabled Logo ISP Basic 相当の条件である、IPv6 アドレスの取得、インターネットへの経路到達、IPv6 での通信確認可能なサーバの用意は満たしているものとする。

3.2. 今後の課題
国際的に共通な基準を設ける事で、IPv6 対応内容のバラツキが抑えられ、結果としてインターネット全体の品質劣化を防止する効果が期待できる。日本国内だけにとどまらず、国際的な団体で採用される基準とする事が課題の一つである。一方、IPv4 アドレスが枯渇し、IPv6 のインターネットが普及するにつれて、アプリケーションが両方のプロトコルで通信する状態が想定される。このとき、一方の品質劣化がアプリケーション全体の品質を左右してしまう状況が発生しうる。IPv4 アドレスの枯渇および IPv6 移行の進捗具合により、iDC に対してはさらに異なる要件が出てくる事も想定されるため、本書で定める用件を永久のものとはせず、時間とともに改版を重ねる事も検討しなければならない。

20
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

3.3. 参考資料
[1] 総務省．インターネットサービス等の IPv6 対応に係る基本指針・ネットワーク技術者に求められる IPv6 関連技術習得に係る基本指針（2009/05）[2] 総務省．
「IPv6 によるインターネットの利用高度化に関する研究会」とりまとめ（2010/03）[3] J.Curran. RFC5211 An Internet Transition Plan(2008/06)
http://tools.ietf.org/rfc/rfc5211.txt[4] IPv6 Forum. IPv6 Enabled Program ISP Basic Logo
http://www.ipv6forum.com/ipv6_enabled/ipv6_enable.php[5] S.Kawamura. A Basic Guideline for Listing ISPs that Run IPv6(2010/06)
http://tools.ietf.org/id/draft-kawamura-ipv6-isp-listings-00.txt

21
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.

4. 付録4.1.

著者一覧

貞田 洋明 エヌ・ティ・ティ・コミュニケーションズ株式会社
山中 仁志 イッツ・コミュニケーションズ株式会社
野崎 健太郎 関西マルチメディアサービス株式会社
北村 充靖 富士通エフ・アイ・ピー株式会社
永井 祐弥 株式会社ライブドア
宮田 宏 横河電機株式会社
津国 剛 株式会社三菱総合研究所
平井 則輔 ソフトバンク BB 株式会社
向井 将 KDDI 株式会社
寺田 昭彦 財団法人電気通信端末機器審査協会
菅沼 真 株式会社電算
渡邊 恭央 株式会社テクノロジーネットワークス
伊田 吉宏 パナソニックシステムネットワークス株式会社
西 和人 ソフトバンク BB 株式会社
川村 聖一 NEC ビッグローブ株式会社
市川 剛 株式会社ライブドア
芦田 宏之 イッツ・コミュニケーションズ株式会社
丹羽 暁子 株式会社三菱総合研究所
大西 毅 財団法人電気通信端末機器審査協会
鵜飼 拓男 総務省
武馬 慎 総務省

22
Copyright (C) 2010-2011 Task Force on IPv4 Address Exhaustion, Japan. All Rights Reserved.