━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.1590【臨時号】2018.5.11 ◆
  _/ＮＩＣ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1590 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2018年3月下旬に、イギリス・ロンドンで開催されたIETFミーティングのレ
ポートを、vol.1587より連載にてお届けしています。

連載の最後となる本号では、IPv6関連WG報告として、v6ops WGおよび6man WG
の議論をご紹介します。

これまでに発行した第101回IETF報告は、下記のURLからバックナンバーをご
覧ください。

  □第101回IETF報告

    ○[第1弾] 全体会議報告 (vol.1587)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1587.html

    ○[第2弾] DDoS対策(DOTS WG)関連報告 (vol.1588)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1588.html

    ○[第3弾] 5G関連技術の動向報告 (vol.1589)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1589.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第101回IETF報告 [第4弾]  IPv6関連WG報告 ～v6ops/6man WG ～
                                NTTコミュニケーションズ株式会社 西塚要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2018年3月17日(土)～23日(金)にイギリスのロンドンにて、第101回IETFミー
ティングが開催されました。筆者が会合に参加したIPv6に関連するWorking
Group (WG)の中からv6ops WG、6man WGについて、主な議論の概要を報告いた
します。


■ v6ops WG (IPv6 Operations, Ops Area)

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

ミーティングは3月19日(月)の9:30からと最初の時間帯での開催でしたが、参
加者が多く活況でした。


○ゲストプレゼンテーション

ドラフトに紐づくものではないですが、ゲストとして「Mythic Beasts: an
IPv6-Preferred Data Center」と題して、IPv6のみで構成したデータセンター
をサービス提供したホスティング企業での、経験を共有するプレゼンテーショ
ンがありました。ホスティングサービスとして提供している機能のうち、ど
れがIPv6対応しているか、対応していない場合どのように対応させてきたか
など、有用な情報が多く含まれていました。例えば、IPv6対応できていない
プラットフォームとして、hadoopが挙げられています。

IPv6-onlyホストのIPv4でのコネクティビティに関して、出ていく方向はNAT64
で実現し、入ってくる方向はproxy経由にするなど、ユニークな構成でした
が、IPv4の利用要望に対しては追加価格を求めるサービスにしたところ、半
数のユーザーがIPv6-onlyのまま利用するなど、非常に興味深い知見がありま
した。

Raspberry Piのような小型コンピュータよりも、IPv4アドレス1個の値段の方
が高いという発言もあり、笑いをとっていました。Raspberry Pi 3を並べた
ホスティングサービスなど、ユニークな発想でのトライアルを行っているの
で、興味がある方はぜひ[発表資料]
(https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-ipv6-only-hosting-00)
を見ていただければと思います。

会場の反応は好評で、IPv4を使い続けることによるコスト高騰というリスク
が現実のものになっている、という評価を受けていました。

○WGドラフト

WGドラフトとして、二つの発表がありました。

一つ目は、IPv6対応ルータへの要求事項をまとめた、Requirements for IPv6
Routers <draft-ietf-v6ops-ipv6rtr-reqs>です。発表者が本会合に参加でき
なかったため、チェアが発表を代行して行われました。IPv6対応ルータへの
要求事項が非常にうまくまとめられたドラフトとなっておりますが、すべて
のケースを網羅してはいないことが指摘されており、どのようなルータを対
象とするかを明確にすべき、という方向性が示されました。

二つ目は、企業のネットワークが上流に複数ISPと接続している際の、マルチ
ホーム問題の解決を試みる、Using Conditional Router Advertisements for
Enterprise Multihoming<draft-ietf-v6ops-conditional-ras>です。

解決したい問題設定として、

 ・送信元アドレスに応じた正しいISPの出口を、ネットワークが選択できる
   こと
 ・対象のISPに応じた正しい送信元アドレスを、ホストが選択できること

の2点があります。なお、IPv4のようにNATを使った解決策は対象外です。

マルチホーム問題の解決策として、ietf-rtgwg-enterprise-pa-multihoming
というドラフトがすでに存在しています。しかし、この解決策は、RFC6724に
記載された、Rule 5.5による送信元アドレス選択に、すべてのホストが対応
していることが前提となっています。現在、Rule 5.5に対応しているOSは限
られているため、現実的な解決策とはなっていません。

提案手法は、Rule 5.5に依存せずとも、限られた条件においてはルータ側の
機能によってマルチホームが実現できる、としています。ホストの直近の
ファーストホップルータで、上流の状況に応じて、RA (Router
Advertisement)のlifetimeを変えるというだけの内容です。

すべてのシナリオを解決できるわけではありませんが、現実的な落とし所と
しておおむね好評でした。早々に、WGラストコール(WGLC)へと向かうことが
確認されました。

IPv4 with NATとほぼ同等の解決策ではないか、という意見も見られました。
同じマルチホーム問題の解決策としては、RFC7157 (IPv6 Multihoming
without Network Address Translation)が提案されておりますが、RAを使っ
た解決策が好まれているような背景があるのかもしれません。

○個人ドラフト

個人ドラフトとして6件の発表があり、v6opsのWGアイテムとなりそうな提案
はありませんでしたが、IP Fragmentation Considered Fragileというドラフ
トの発表にて、フラグメント問題に対する解決策が必要だという意見があり
ました。

このドラフトは、IPv6のフラグメントは壊れやすい(Fragile)ので、フラグメ
ントの仕組みについて解説した上で、アプリケーション開発者にはフラグメ
ントに依存しないように、ネットワーク運用者にはICMPv6 Packet Too Big
Messageをフィルタしないように啓発する内容となっています。その中で、
DNSSECのメッセージサイズが1500byteを超える問題があらためて提起されま
した。DNSプロトコル側でDNS over TCPに向かっていくのか、IPv6として解決
をしていくのか、どのような解決法となるかは注目すべきと考えます。


■ 6man WG (IPv6 Maintenance, Int Area)

6man WGは、IPv6の仕様とアーキテクチャのメンテナンスと最新化を行うWGで
す。IETFにおけるIPv6関連トピックの受け皿となり、IPv6の仕様の拡張や変
更に関して、責任を持っています。

○WGドラフト

WGドラフトとして、二つの発表がありました。

一つ目は、IPv6対応ノードへの要求事項をまとめたRFC6343を改訂する、IPv6
Node Requirements <draft-ietf-6man-rfc6434-bis>です。v6opsで発表のあっ
たIPv6対応ルータへの要求事項のドラフトがルータ側なことに対して、こち
らは端末側という整理になります。大きな違いは、ルータ側はDHCPv6をMUST
でサポートしなければならないこと対し、端末側はSHOULDでサポートすべき、
という点です。この違いは、些細なようでとても大きいです。この落とし所
は現実的なところでしょう。改訂の内容に満足している参加者が多く、チェ
アはこのドラフトをIESGのプロセスに進めることを決めました。

二つ目は、SRv6を実現する拡張ヘッダを定義するIPv6 Segment Routing
Header (SRH) <draft-ietf-6man-segment-routing-header>です。Cisco社も
含め、すでに実装が出てきていることが強調されておりました。また、内容
についても大きなアップデートがなく成熟していると評価されています。し
かし、SRv6 Network Programming
<draft-filsfils-spring-srv6-network-programming>という、SRv6 network
において、どのようにプログラミングするかというドラフトがspring WGに提
出されており、そのドラフトと足並みを揃えるべきという指摘がありました。
実装状況やリファレンスについて内容を精査した上で、WGLCに進むことが決
まりました。

○個人ドラフト

個人ドラフトとして、6件の発表がありましたが、3件をここでは取り上げて
報告いたします。

一つ目は、ルータの処理上限でパケットを捨てたというICMPv6のエラーコー
ドを追加する、ICMPv6 errors for discarding packets due to processing
limits <draft-herbert-6man-icmp-limits>という提案です。インターネット
経路上のルータやFire Wallなどのミドルボックスは、IPv6拡張ヘッダが一定
数以上チェインしているとパケットを破棄することが観測されています。そ
のような理由によってパケットが破棄されたときに、ICMPv6エラーを返した
いというのが提案の骨子ですが、そのエラーメッセージを受け取ったホスト
がどうようなアクションを取れるのか、という疑問が呈されました。拡張ヘッ
ダは途中で挿入され得るので、送信元ではなく挿入した機器がエラーを受け
取れないと意味がありません。しかし、ハミングによるコンセンサス確認を
行ったところ、WGドラフトとして採用することが決まりました。

二つ目は、IPv4が利用できないことを示すフラグをRAに追加する、IPv6
Router Advertisement IPv4 Unavailable Flag <draft-hinden-ipv4flag>と
いう提案です。IPv6 onlyのファーストホップルータが、デュアルスタックの
ホストに対して、IPv4では通信できないこと(I'm not the default gateway
for IPv4)を示します。デフォルト(flag=0)では、IPv4が使えることを示すの
で、フラグを理解しないルータ/端末でも問題を起こすことはないと主張しま
す。家庭内LANだけでなく、企業ネットワークのIPv6 only化においても有用
ではないか、などの意見が出ました。WGとしてsunset4 WGが適切ではないか
という意見もありましたが、参加者はsunset4 WGにあまり良いイメージを持っ
ておらず、6manでWGドラフトとして採用するかのハミングが行われました。
採用すべしというハムの声の方が大きかったですが、内容に対する反対意見
もあり、MLで継続議論が起きています。

三つ目は、パフォーマンス計測のためにIPv6のヘッダ内にマーキングのため
のフィールドをつけようという、IPv6 Performance Measurement with
Alternate Marking Method <draft-fioccola-v6ops-ipv6-alt-mark>です。こ
のドラフトの発表はv6ops WGでも行われましたが、6manが適切ではないかと
いうことで、再度6man WGで発表されました。パケットロスや遅延、ジッター
を計測するために、パケットにマーキングをする手法がRFC8321
(Alternate-Marking Method for Passive and Hybrid Performance
Monitoring)で、提案されています。QUICプロトコルで提案のあった、spin
bitも同様の発想です。問題はどのフィールドがIPv6の場合に使えるかです
が、拡張ヘッダ、IPv6アドレス、Flow Labelが挙げられました。v6opsでは興
味があると表明した事業者がいましたが、6manにおいては、IPレイヤ以外で
実現すべきだ、などの反対意見が相次ぎました。


■ まとめ

RFC8200において、IPv6の基本仕様が整理されアップデートされましたが、現
在はIPv6対応に関する要求事項など、実装に関する整理が進んでいる状況で
す。マルチホーム問題や、IPv6/IPv4共存時のフォールバック問題など、利用
者目線での課題解決が進んでいくことに期待しています。また、SRv6の仕様
がWGLCに進むなど、SRv6がキャズムを超えてきている様子が見られます。パ
フォーマンスを測定したいという要望が上がってきているのは、SDNの普及と
関連している事象であるように思います。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
          まわりの方にもぜひNews & Viewsをオススメください！
      転送にあたっての注意や新規登録については文末をご覧ください。
                  ◇              ◇              ◇
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃  http://feedback.nic.ad.jp/1590/5ccbaa7640ad994e0487e2516d870143 ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃  http://feedback.nic.ad.jp/1590/08e8c6310f48ed1158aa255e4584f88c ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  ::::: https://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト :::: https://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 JPNIC News & Views vol.1590 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 ＠ 問い合わせ先  jpnic-news@nic.ad.jp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
   ◇ JPNIC Webにも掲載していますので、情報共有にご活用ください ◇
登録・削除・変更   https://www.nic.ad.jp/ja/mailmagazine/
バックナンバー     https://www.nic.ad.jp/ja/mailmagazine/backnumber/
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■     News & ViewsはRSS経由でも配信しています！    ■■■■■
::::: https://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

■■◆                          ＠ Japan Network Information Center
■■◆                                     ＠  https://www.nic.ad.jp/
■■

Copyright(C), 2018 Japan Network Information Center