IETF92報告会
IPv6関連WG
v6ops, v6man

2015.04.23
Kaname Nishizuka@NTT Communications自己紹介 2006 NTTコミュニケーションズ入社。
 OCNアクセス系ネットワークの設計に従事した後、大規模ISP向けのトータル保守運用サービスを担当。
 現在、DDoS対策ソリューションの開発および、CGN関連技術のIETF提案活動に従事
 ISOC-JP プログラムチェア【社外活動】
 JANOG28
卑 JANOG30 会場運営卑 JANOG32 「HTTP 2.0のインパクト」登壇
 HTML5 Conference 2013 NWチーム
 Interop2014「IPv6ホットトピックス」登壇
2

IPv6関連 各WGと主な IETF IPv6関連 WGについて• v6ops WG
IPv6全般の運用上の課題と、プロトコルの匳• 6man WG• 6lo/6lowpan WG
センサーネットワーク• 6tisch WG
におけるIPv6• homenet WG• softwire WG
家庭内におけるIPv6• sunset4 WG• behave WG(厖 )IPv4アドレスの枯渇と技術

3

IETF92@Dallas におけるIPv6関連WG ホットトピック

44

v6ops55

v6ops WG
 IPv6 Operations WG
 設2002
 Chairs: Fred Baker(Cisco)
Lee Howard(Time Warner Cable)

 v6ops WGは、IPv6を全世界に展開するにあたっての緊急の課題、特に運用上の課題に対処することに焦点を当てたWG
 新しいネットワーク/既存のIPv4ネットワークにIPv6を導入するためのガイドラインや、IPv4/IPv6 共存ネットワークの運用ガイドラインを作成することも目的としている。

6

Agenda(2)WGLC(1)IPv4 as a Service(3)データセンタ内でのIPv4 over IPv6技術匏用

7

IPv4 as a Service(1/2)
 v6ops WGで扱う新しいプロジェクトとしてチェアが提案
 IPv6のネットワーク上において、IPv4を必要なサービスとして提供する(ただし、徐々に減らしていく)というシナリオを前提として、IPv4 over IPv6 技術の展開における運用ガイダンスを書くプロジェクト

8

IPv4 as a Service(2/2)
 プロジェクトのスコープを、以下のgoogle docsで共同編集中
 https://docs.google.com/document/d/1ifDEkoypW43lgZJq
h2paUDcMAwoUWdz6psyEb456c3A/edit
 各地のNOG(Network Operators Group)と連携しながら執筆を進めていくとチェアが表明

これらの技術の匏用が匪 している日本からの午報入9が卻JPNE MAP-E deployment(1/5)
 発表者：中川あきら氏
日本ネットワークイネイブラー株式会社(JPNE) APRICOT+APAN 2015カンファレンス@福岡における、「IPv6 Deployment Status in Japan」がきっかけ
 チェアのFred Baker氏から”v6ops で30分間話してもらいたい”との打診が急遽あった
 発表骨子• 日本におけるIPv6の普及状況• JPNEがMAP-Eを選択した 厩• 実 結果・匏用結果と半10

JPNE MAP-E deployment(2/5)
 JPNEがMAP-Eを選択した 厩• ステートレスであるためログ収集が勘要あること• カスタマサポートが卣 なこと• エンド-エンドで通信が可能であること

11

JPNE MAP-E deployment(3/5)
 実 結果・匏用結果と半• IPv6通信とIPv4通信の定結果が同であること• ポート匏用状況の 匧データからユーザに厝分な数のポートが割り当てられていること• 接続匯定 ージが提供されておりトラブルシュートが卣 になっていること

12

JPNE MAP-E deployment(4/5)

13

JPNE MAP-E deployment(5/5)
 会場の反応• 発表の 中でも
問・

厱が卹発に卦わされた卧• 顧客からの勘匊は無かったのか？
 無かった• コンシューマユーザ向けか、ビジネスユーザ向けか？
 両方だが、主にコンシューマユーザ• 日本のプロバイダはIPv6をもっていない。プロバイダに働きかけをしないのか？(by Google) したいと思っている14

IPv6 deployment in India, with MAP-T Trials
 インドにおけるMAP-Tトライアルの報告
 MAP-Tを選択した 厩• QoS/SLAなど顧客 匱のポリシー 合が卣
• DPI装置の匏用が卣 であること

15であることMAP-T and MAP-E deployment in CERNET and China Telecom 中国におけるMAP-TとMAP-Eの自動卲換• キャンパスネットワークがメインのためユーザは多くない• MAP-TがデフォルトでMAP-Eに卲り えているのは1%以下

16

MAP-T and MAP-E deployment in CERNET and China Telecom

 MAPの厾(ユーザあたりのポート数)について• 127port, 255port = safe
• 63port 以下 = ユーザ影響あり

17

Working Group Last Call(2件) Some Design Choices for IPv6 Networks
draft-ietf-v6ops-design-choices• IPv6ネットワークをデザインするにあたり、ルーティングに関してどのような選択肢があり、それぞれにどのようなメリット・デメリットがあるのかを的に調査したドラフト• WGLCとすることに会場賛成多数
 Close encounters of the ICMP type 2 kind (near misseswith ICMPv6 PTB)
draft-ietf-v6ops-pmtud-ecmp-problem• ロードバランサ環境下でICMPv6 type 2 “Packet Too Big”(PTB)メッセージ応答が元のサーバに返らない問題を記述したドラフト• WGLCとすることに会場賛成多数
18

データセンタ内でのIPv4 over IPv6技術匏用(1/4)
 SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data
Centre Environments
 IPv6で構成されたデータセンタ内ネットワークにおいて、IPv4インターネットからの接続性を提供する方法をまとめた一連のドラフト• draft-anderson-v6ops-siit-eam ステートレスなIPv4/IPv6変換[RFC6145]のアドレスマッピングルールを緩和する提案• draft-ietf-v6ops-siit-dc

 データセンタ側にステートレスなIPv4/IPv6変換[RFC6145]をうトランスレータを設置し、IPv4NWからIPv6サーバに接続する方法の提案• draft-ietf-v6ops-siit-dc-2xlat

 さらに、 IPv6からIPv4に変換するトランスレータを設置し、4→6→4の2段変換によって、IPv4サーバに接続する方法の提案
19

データセンタ内でのIPv4 over IPv6技術匏用(2/4)
 draft-anderson-v6ops-siit-eam• ステートレスなIPv4/IPv6変換[RFC6145]のアドレスマッピ
ングルールを緩和する提案• 今回の提案でWG draftとして採用された
 RFC6052アルゴリズムを必須とする制約を緩和する

 Androidの464XLAT実装では、すでに使われていない。
20

データセンタ内でのIPv4 over IPv6技術匏用(3/4)
 draft-ietf-v6ops-siit-dc• データセンタ側にステートレスなIPv4/IPv6変換[RFC6145]
を うトランスレータを設置し、IPv4NWからIPv6サーバに接続する方法の提案• 前回(IETF91)の提案でWG draftとして採用された• マッピングアルゴリズムに関する 分は卲り し21

データセンタ内でのIPv4 over IPv6技術匏用(4/4)
 draft-ietf-v6ops-siit-dc-2xlat• さらに、 IPv6からIPv4に変換するトランスレータを設置し、4→6→4の2段変換によって、IPv4サーバに接続する方法の提案• 前回(IETF91)の提案でWG draftとして採用された• が、前のドラフトとマージすることが決定

22

6man

23

23

6man WG
 IPv6 Maintenance WG
 設2007
 Chairs: Bob Hinden(Check Point)
Ole Troan (Cisco)

 v6man WGは、IPv6の仕様とアーキテクチャのメンテナンスと最新化を う。ただし、IPv6の仕様に大きな変化を与えるものではない。IPv6の展開や運用で発 された制 や問題を卆決する。
 IETFにおけるIPv6関連トピックの受け皿となり、IPv6の仕様のや変 に関して、 厃を匛つ。

24

Agenda(1)RFC発の報告(2)NDオプションの正当性評価

25

RFC発の報告

 RFC7421 - Analysis of the 64-bit Boundary in IPv6
Addressing• https://tools.ietf.org/rfc/rfc7421.txt
 IPv6ユ キャストアドレスのインターフェース 厌子(IID)が64-bit で 定されていることの匏点およ 可変にしたときの影響について調査結果をまとめた Informational RFC

26

ND(近)オプションの正当性評価(1/2)

 Validation of IPv6 Neighbor Discovery Options
draft-ietf-6man-nd-opt-validation
 Source link-layer address(SLLA)オプション• 近 要請(NS)、ルータ要請(RS)、ルータ広告(RA)メッセー
ジの送信者のリンク層アドレス

 Target Link-Layer Address (TLLA)オプション• 近 広告(NA)、リダイレクトメッセージにおける目標のリンク層アドレス27

ND(近)オプションの正当性評価(2/2)

 前述のオプションにおけるリンクレイヤアドレスが、ブロードキャストアドレス・マルチキャストアドレス・受信ノードのアドレスになっている場合は、このオプションを無視しなければならない。
 IPv6の近スプーフィングによるサービス勘能• 転送におけるループを引き起こしてしまうの一 それ以外のオプションについての記述は、既存の文章[RFC4861], [RFC2464]と大きな変 が無いので、この华つのオプションの記述の に る きかどうかが 厱されている

28

まとめ2929

 IPv6に関連するWGでの最新動向を順に紹介しました。
 注目• v6ops: IPv4 as a Service Project• v6ops: SIIT-DC30