IETF102報告会
IPv6関連WG
v6man, v6ops

2018.08.31
Kaname Nishizuka@NTT Communications@__kaname__⾃⼰紹介
n 2006年 NTTコミュニケーションズ⼊社
n OCNアクセス系ネットワークの設計に従事した後、⼤規模ISP向けのトータル保守運⽤サービスを担当
n メインフィールド• トラフィック分析• DDoS対策ソリューション
• IPv4枯渇対策関連技術
n IETF提案活動• DOTS WG
n JPNIC「IPv6教育専⾨家チーム」

2

IETF102@Montreal におけるIPv6関連ホットトピック
アジェンダ
1. 6man WG
2. v6ops WG

3

3

IPv6関連 動向概要
n IPv6仕様の再整理• RFC8200 (2017/7)
n 現在の残課題• マルチホーム問題• 有線から無線へ。メディア/端末の変化への対応
ü IoTデバイスへの対応も含まれる• IPv4からの移⾏(技術⾯/運⽤⾯)
n 新技術への期待• SRv6(IPv6 Segment Routing)4IPv6関連 各WGと主な領域
n IETF IPv6関連 WGについて• v6ops WG
IPv6全般の運⽤上の課題と、プロトコルの改良• 6man WG••••

IPv4アドレスの枯渇と移⾏技術は、主に6manとv6ops
で議論される最近の傾向

6lo(6lowpan) WG
6tisch WG
lpwan WG
ipwave WG

IoTにおけるIPv6• homenet WG

マルチホームする家庭内におけるIPv65

1. 6man

66

6man WGn IPv6 Maintenance WG
n 設⽴：2007年
n チェア：Bob Hinden, Ole Troann 6man WGは、IPv6の仕様とアーキテクチャのメンテナンスと最新化を⾏う。ただし、IPv6の仕様に⼤きな変化を与えるものではない。IPv6の展開や運⽤で発⾒された制限や問題を解決する。
n IETFにおけるIPv6関連トピックの受け⽫となり、IPv6の仕様の拡張や変更に関して、責任を持つ。

7

6man Agendan ハイライト(WGドラフト)
1.SRv6のヘッダ定義

2.(新提案)IPv6-only flagin RA8

IPv6 Segment Routing (SRv6)
n Segment Routing(SR)• SID (Segment Identifier) と呼ばれる識別⼦を、ノードやリンクに付与• 指定したSIDのリスト(Segment List)を経由するようにパケットを転送
n 主なSRデータプレーン• SR-MPLS: SIDをMPLSラベルに変換• SRv6: SIDをIPv6アドレスとし、IPv6拡張ヘッダに、Segment Listを挿⼊
ü SRH (Segment Routing Header)と呼ばれる

9

IPv6 Segment Routing Header (SRH)n draft-ietf-6man-segment-routing-header• SRHの仕様を策定するWGドラフト

10

IPv6 Segment Routing Header (SRH)n 実装が先⾏している

11

IPv6 Segment Routing Header (SRH)n SRのアーキテクチャに関するRFC8402(7⽉にRFC化)を参照• このIPv6 Segment Routing Header (SRH)のRFC化を先に進めて、SRv6 Network Programmingはそれを参照する
RFC8402 Segment Routing ArchitectureIPv6 Segment Routing Header (SRH)n ドキュメントのステータス• ヘッダのフォーマットはほぼ決定• HMACとTLV関連の課題整理が残りタスク
n 「実装も進み商⽤での利⽤も⾒えてきたので、早く標準化プロセスを進めたい」という意⾒が占める• 2回⽬のWGLCになる予定

SRv6のRFC化間近？

13

IPv6 Router Advertisement IPv6-Only Flagn draft-ietf-6man-ipv6only-flag• IPv6 onlyのネットワークであることを⽰すフラグをRAに追加

14

IPv6 Router Advertisement IPv6-Only Flagn ⽬的
• ネットワークに接続したホストがIPv4を使おうとするのを抑えることn ドラフトの状況• 前回のIETFから今回までの間にWGアイテムとして採⽤

ü IPv6 Router Advertisement IPv4 Unavailable Flagから名前の変更• 賛否両論ü しかし、チェアのドラフトのためWGアイテムに

n 主な反論• このRAを受け取ったホストがIPv4の利⽤をやめる→悪意のある第三者に不意にIPv4を使えなくされてしまう
15

6man Agendan ハイライト(個⼈ドラフト)

1. zero lifetimeによる上流NWの切り替え

16

2. RA vs DHCPv6問題の解決策なるか？

Zero valid lifetimes on point-to-point links
n draft-zerorafolks-6man-ra-zero-lifetimen P2Pリンクに限ってvalid lifetimeをゼロにすることを許容し、別のリンクにすぐに寄せられるようにする提案• IPv6の仕様では、不正なRAによる攻撃を避けるためvalidlifetimeを2時間以下にすることはできない[RFC4862]5.5.3

17

Zero valid lifetimes on point-to-point links
n モバイルネットワークからのハンドオーバーや、マルチホーム環境を想定• Android機器など主にモバイル端末での利⽤のため• Google社エンジニアの提案
n デメリットはないのか？
• P2Pリンクであれば、不正なRAを出す第三者がいないため、脅威モデルは成り⽴たない• しかし、端末の⽴場から、どのようにしてそのリンクがP2Pだと知ることができるのか？
n 今後• WGアイテムとしての採⽤には⾄らず、継続議論
18

IPv6 Neighbor Discovery Extensions for Prefix Delegationn draft-templin-6man-dhcpv6-ndopt
n IPv6の⾃動アドレス設定を統⼀• RAとDHCPv6を両⽴

19

IPv6 Neighbor Discovery Extensions for Prefix Delegationn 提案• IPv6近隣探索においてDHCPv6 Optionのコードを定義する
n メカニズム(抜粋)1. クライアントはRS(ルータ要請)にDHCPv6メッセージをいれる
2. それを受けたルータは、DHCPv6サーバに転送する
3. DHCPv6サーバは、DHCPv6メッセージを⾒て、回答をルータ経由でクライアントに返す
4. その際、ルータは回答(DHCPv6 reply)をRA(ルータ広告)に載せてクライアントに返す
n 会場の反応• シンプルで、実際に動くかどうか⾮常に興味深いが、慎重な意
⾒が多い• チェアは乗り気ではない→議論不⾜として先送り
20

2. v6ops

21

21

v6ops WG
n IPv6 Operations WG
n 設⽴：2002年
n チェア：Fred Baker, Ron Bonica, Lee Howard
n v6ops WGは、IPv6を全世界に展開するにあたっての緊急の課題、特に運⽤上の課題に対処することに焦点を当てたWG
n 新しいネットワーク/既存のIPv4ネットワークにIPv6を導⼊するためのガイドラインや、IPv4/IPv6 共存ネットワークの運⽤ガイドラインを作成することも⽬的としている。

22

突然の停電でも…
n ホテル近隣⼀帯が数⼗分間
停電
n 暗い中でも議論は継続• 残念ながら、議事録(Minutes)には、停電中の議論は残っていません。

23

v6ops Agendan ハイライト「全世界IPv6利⽤状況」
APNIC ゲストスピーカ
2. 4over6 に対応するCPEへの要求事項

3. NAT64⽤prefixのディスカバリ⽅法の提案

24World IPv6 Trends
n ゲストプレゼンテーション• APNIC George Michaelson⽒• ウェブ広告を利⽤してIPv6で通信可能なユーザ割合を算出• 世界のIPv6普及状況に関して: 18%

25

World IPv6 Trends
n 国の経済規模(GDP)と、IPv6利⽤可能率の相関• 強い相関は無い

26

World IPv6 Trends
n ⽇本など、各国の対応状況を説明• 各国のエンジニアから「本当に実態を表しているのか？」という疑義あり(特にWeb広告がリーチしていないであろう国)

27

Requirements for IPv6 Customer Edge Routers to
Support IPv4 Connectivity as-a-Service

n draft-ietf-v6ops-transition-ipv4aas
n IPv4 as a Service(IPv4aaS)として、IPv4 over IPv6機能を提供するCPEについての要求事項をまとめたドラフト• 共通する機能(ディプロイメントなど)についての要求事項• 以下の技術についての個別の要求事項
ü 464XLAT, DS-Lite, MAP-E, MAP-T, Lw4o6

28

Requirements for IPv6 Customer Edge Routers to
Support IPv4 Connectivity as-a-Service

n DHCPv6でCPEにIPv4 over IPv6機能をデプロイする際に、464XLATだけがコードポイントが割り当てられていない• ドラフトでIANAに要求

現状29Requirements for IPv6 Customer Edge Routers to
Support IPv4 Connectivity as-a-Servicen どれだけ IPv4 over IPv6技術のバリエーションが増えるのか？
• IPv4 over IPv6技術が増えてしまうと、CPEメーカに対応コストが上乗せされてしまうü 「どれも似たようなコードだ」という意⾒と、
ü 「それぞれディプロイ⽅法が異なるので⼤変だ」という意⾒n WGLCには時期尚早と判断されたが、ガイドラインとして本ドラフトは有⽤• ちなみに⽇本のIPv4 over IPv6技術はVNE事業者ごとの異なる
ü プロビジョニング⽅法もそれぞれ
ü CPEベンダ泣かせ？

30

Discovering PREF64 in Router Advertisements
n draft-pref64folks-6man-ra-pref64n NAT64のアドレス(PREF64)のディスカバリとしてRAを使う⽅法の提案• DNS64/NAT64では、NAT64⽤のアドレス(PREF64)が、DNS64で返される• 例: Google Public DNS64

ü DNS64 is a DNS service that returns AAAA records withthese synthetic IPv6 addresses for IPv4-only destinations(with A but not AAAA records in the DNS). This lets IPv6only clients use NAT64 gateways without any otherconfiguration. Google Public DNS64 provides DNS64 as a
global service using the reserved NAT64 prefix 64:ff9b::/96.

n 464XLATや、NAT64配下でのIPv4アドレスリテラルでのアクセスでは、DNS64を⽤いないためDNSに依存しない形でPREF64を得る必要がある• →RAで配布しよう
31

Discovering PREF64 in Router Advertisements
n PREF64• “Well-Known Prefix” [RFC6052] 64:ff9b::/96• “Local-Use IPv4/IPv6 Translation Prefix” [RFC8215]
64:ff9b:1::/48→PREF64は環境によって異なる可能性がある
n PREF64はローカルな環境(NAT64配下)でしか使われないので、LAN内の設定は信頼できるとしてRAによって与えること意味があるというのが提案の趣旨• DNS64に依存しないことで、DNS64とDNSSECの相性問題も解決できるn 会場の反応• 好意的• DNS64をディスカバリする⽅法を決めているRFC7050に、問題があるのでは、という指摘に発展32

まとめn 6man WG• SRv6への期待の⾼まり• IPv6-Only Flagの提案(チェアが推してる…)
n v6ops WG• ゲストスピーカー枠の定着？

ü IPv6のディプロイ状況の共有• 4over6技術の受け⽫WG

ü IPv4 over IPv6技術も普及期に

33