IETF93報告会
IPv6関連WG

v6man, v6ops+sunset4
2015.08.27
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アドレスの枯渇と技術

今回は v6ops と sunset4 で合同ミーティング
3

IETF93@Prague におけるIPv6関連WG ホットトピック

44

6man

55

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

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

6

AgendaWGドラフトは今回はなし

ドラフトなしの厱2件

新規の個人ドラフト(時間卲れで発表なし)

7

IPv6ホストのソースアドレス依存ルーティングの分析(1/2)

 Source Address Dependent Routing for IPv6 hosts analysis
 BCP38(uRPF)のフィルタによって、• 適卲なルーティング (Scenario 1)• 適卲なアドレス選択 (Scenario 2)がされないと、通信が勘能になる問題

8

IPv6ホストのソースアドレス依存ルーティングの分析(2/2)

 なぜ、問題にするのか？
• multi6, mif, homenet, v6ops などのWGで既に 厱されている話題• 特にRFC7157: IPv6 Multihoming without Network
Address Translation
 筆者が主張する解決策• RFC6724:Default Address Selection for IPv6 の Rule5.5の適用• Prefix Information Option(PIO)を必須とする• エッジネットワークにおけるルータにおいて、ソースアドレスベースのルーティングを推奨する
 会場の反応• WGドラフトとすることには強い同意• 解決策については同意は千られ 、今後9

IPv6関連RFCのカテゴリーについて(1/3)
 IPv6 specifications to Internet Standard
 IPv6関連のRFCのカテゴリーをInternet Standardに！
RFC6410
Internet Standard
国際標準とすべき仕様の最上位

Internet Standard

Draft Standard
さらに広範囲で利用されているもの

Proposed Standard

Proposed Standard
複数組織での独立した実装と相互接続
何もしないと2 後にProposed Standardに(6manのminutesより)

10

IPv6関連RFCのカテゴリーについて(2/3)
 Draft StandardとなっているIPv6関連RFC

11

IPv6関連RFCのカテゴリーについて(3/3)
 しかし、Internet Standardとなる基準は高い• Errataが存在しないこと• 使われていない複雑な仕様がないこと、、など
 RFC2460• 9つのUpdate RFC• 2つのErrata
 RFC2460bis に改訂して、Internet Standardにする。
• Update RFCも一緒に？
現状を反映した改訂にし、場から ても仕様を明確に。

※RFC2460の後に、RFC4291(addressing architecture)に手をつける。
12

v6ops+sunset4

13

13

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

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

sunset4 WG
 Sunsetting IPv4 WG
 設2012
 Chairs: Marc Blanchet (Viagenie)
Wesley George (Time Warner Cable)

 IPv6への 全なに向けて、アプリケーション・ホスト・ネットワークがIPv4への依存無しに機能することを目指す。
 他のWGに対しても、プロトコルの策定に際してIPv4を使わないよう きかけを う。

15

sunset4 WG Agenda 今までRFC化されたドラフトは無し
 MLの及 は少ない
 今回発表枠のあったドラフト• IPv4を止める際のGap Analysis• NAT64におけるポート割当手法について
 その他のActiveなdraft• IPv4を持たないルータにおける32bit IDについて• DHCPv6オプションまたはRAを用いたIPv4匏用の勧について 卹動が卹発でないことと、取り うが一部匤複しているため、対象ののために、v6opsと合同ミーティングに。
16

v6ops WG Agenda(1) v6ops WGの Charterについて(2) AppleとIPv6について(3) ギリシャのISPのIPv6対応状況について(IPv4 as a service Projectの一環)(4)ホストアドレスに複数アドレスを匏用することの推奨について(※)

WGLCを受けて、最終校正中WGLC予定
次回からWGドラフトに※ め卲り け匸みドラフトが匭い、とチェアから
17

言…

(1) v6ops WGの Charter

新について v6opsの Charter が改訂されます。
<Old><New>(Proposed)

1. IPv4/IPv6という表現が曖昧なので、どちらが対象なのかを明確に書く
2. IPv6オンリーあるいは、IPv6/IPv4デュアルスタックの課題解決策を考えることはスコープ内だが、IPv4だけのトピックはスコー
プ外
3. IPv6オンリーへののガイドラインは、sunset4のと匤複する。「sunset4を休眠状態にする/v6opsで吸収する」ではなく、sunset4を して今後も合同ミーティングを続ける 匸み18

(2) AppleとIPv6について(1/5)
 すべてのiOSのアプリケーションは、IPv6ネイティブサポートとNAT64ネットワークで動作しなければならない

19

(2) AppleとIPv6について(2/5)
厩• Verizon社、AT&T社、T-Mobile社などのキャリアでIPv6対応が進んだ• CGN越しにIPv4通信をするよりもIPv6で通信をするインセンティブがある• iOS 9とOS X 10.11 (El Capitan)から、99%がIPv6通信になる新しいHappyEyeballを実装(β版)20

(2) AppleとIPv6について(3/5)
 なぜNAT64を選択したのか

・464XLAT：IPv4のみのクライアントはIPv4サーバとしか通信ができない
・NAT64/DNS64：IPv6のみのクライアントはIPv6/IPv4サーバ両方と通信できる

 会場の意••「DNSSECのvalidationの点でDNS64を用いない464XLATの方が い」「IPv4リテラルへの対応はどうするのか」「464XLATでもクライアントはIPv6を持っていることが仮定されているので変わらないのでは」
しかし、Apple社の方向性が、開発者にIPv6でのアプリ開発を促すものになるので、支持する意 が匭数21

(2) AppleとIPv6について(4/5)
 NAT64環境のテスト方法• OS X 10.11 (El Capitan)• インターネット接続の共有 Create NAT64 NetworkをチェックするだけでOK App開発者がIPv6対応するには• Use the networking frameworks (for example,“NSURLSession”)• Avoid use of IPv4-specific APIs
• Avoid hard-coded IP addresses
http://www.internetsociety.org/deploy360/blog/2015/06/applewill-require-ipv6-support-for-all-ios-9-apps/
22

(2) AppleとIPv6について(5/5)
 HappyEyeballsの挙動について• V6ops WGのMLに7/10に投稿• iOS 9とOS X 10.11 (El Capitan)
1. DNSリゾルバにAクエリとAAAAクエリを出します- もしDNSレコードがキャッシュに無い場合、リクエストはワイヤ上で連続して送信されます(AAAAが先)
2-1. もし最初の応答がAAAAだった場合、IPv6のSYNを直ちに送ります
2-2. もし最初の応答がAだった場合、AAAAを期待して、25msのタイマーを開始します- もしタイマーが卲れたら、IPv4のSYNを送ります- もし25ms以内にAAAAを受け取ったら、アドレス選択に進みます
3. IPアドレスのリストがある場合(DNSキャッシュからの場合か、IPv4とIPv6を近接して受け取った場合)、それらのソートのために、アドレス選択アルゴリズムを実施します。このアルゴリズムは、過去のRTT値のデータを用いて遅延の少ないアドレスを優先しますが、25msのゆとりを持ちます。もし、過去のRTT値の差が25ms以内だった場合、RFC3484を使ってベストなアドレスを選択します
4. リストがソートされたら、リストの1番目のアドレスにSYNを送ります。また同時に、過去のTCPのRTT値の平均と分散をベースとしたタイマーを開始します。大雑把に言えば、1番目のSYNの再送信と同じくらいの時間に2番目のアドレスのSYNを送ります
5. 1番目のアドレスのSYN-ACK応答が競争に勝ったら、他のTCP接続の試みをキャンセルします• β版なのでは変 される可能性はあるが、将来のApple製品のIPv6トラフィックを飛躍的に増加さ る 匸み23

(3) ギリシャのISPのIPv6対応状況について(1/3)
 IPv4 as a Serviceプロジェクトの一環として、ギリシャのISP(OTE)のIPv6対応状況が発表された

24

(3) ギリシャのISPのIPv6対応状況について(2/3)
 IPv6対応状況• 90%のCPEがデュアルスタック対応済

25

(3) ギリシャのISPのIPv6対応状況について(3/3)
 IPv4アドレスはほとんど枯渇
 IPv4 over IPv6の選択• 当初はMAPを選択

 必要な新しい設備が少ない
 Statelessな変換である
 事前テストで問題がほとんどなかった

BR: (virtual) Cisco ASR1k and ASR9k
CPE: latest OpenWRT image• 最終的にLightweight 4 over 6を選択

 上記に加え、プロヴィジョニングがシンプルなため ドイツテレコムが関与していることがkey factor

26

(4)ホストアドレスに複数アドレスを匏用することの推奨について(1/4)

 draft-colitti-v6ops-host-addr-availability• Google： Lorenzo Colitti, Vint Cerf
• Apple ：Stuart Cheshire 趣旨• IPv6とIPv4の大きな違いはホストで複数のアドレスを持てることだが、そのメリットが 解されていない• 複数のアドレスを持つことのメリット

27

(4)ホストアドレスに複数アドレスを匏用することの推奨について(2/4)

 アンチNAT66• NAT越えの問題、NAT keepaliveの問題

28

(4)ホストアドレスに複数アドレスを匏用することの推奨について(3/4)

 どのくらいアドレスが必要になるのか？

29

(4)ホストアドレスに複数アドレスを匏用することの推奨について(4/4)

 卖出以来、 厱を き こしている• 内容をサポートする意 が匭い• しかし、ドラフトはまだ問題を明確に記述することができていない ネットワーク・プレフィックスの話なのか、ホスト部の話なのか

 WGドラフトとなる公算が高い• 今後も注目すべきドラフト30

まとめ3131

 IPv6に関連するWGでの最新動向を順に紹介しました。
 注目• AppleのIPv6対応のインパクト• 複数ホストアドレス推奨の動向• IPv4 as a Service プロジェクト32