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

2018年7月中旬にカナダ・モントリオールで開催された第102回IETFミーティ
ングの連載レポートも、後半に入りました。

IPv6関連の報告は前後編の2号に分け、連載第4弾の本号では、IETF内でIPv6
の仕様とアーキテクチャのメンテナンスおよび最新化を行う6man WGの標準化
動向をお伝えします。

連載最終号となる次号では、IPv6関連WG報告の後半として、v6ops WGの活動
をご紹介する予定です。これまでに発行した第102回IETFの報告は、下記のURL
からバックナンバーをご覧ください。

  □第102回IETF報告

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

    ○[第2弾] セキュリティエリア関連報告 ～TRANS WGにおけるCTに関する
              議論について～ (vol.1615)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1615.html

    ○[第3弾] IoT関連報告 (vol.1617)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1617.html

また、本会合のオンサイトでの報告会を、今週8月31日(金)に東京・青山学院
大学にて開催いたします。参加登録は、明日8月30日(木)17:00までです。

  IETF報告会(102ndモントリオール)開催のご案内
  https://www.nic.ad.jp/ja/topics/2018/20180803-01.html

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

2018年7月14日(土)～20日(金)にカナダのモントリオールにて、第102回IETF
ミーティングが開催されました。前回(*1)に引き続き、筆者が会合に参加し
たIPv6に関連するWorking Group (WG)の中から6man WG、v6ops WGについて
主な議論の概要を報告いたします。この前半では6man WGについて報告しま
す。

次号の後半ではv6ops WGについて報告するとともに、筆者が提案活動を行っ
ているdots WGについても簡単に報告する予定です。

  (*1)第101回IETF報告 [第4弾]  IPv6関連WG報告 ～v6ops/6man WG ～
      https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1590.html


■6man WG (IPv6 Maintenance, Int Area)

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

 (1)ドラフトの最新ステータス

    最初にチェアから、WGで扱っているドラフトの最新状況のアップデート
    がありました。まずは、以下のドラフトがRFC Editorの編集待ちリスト
    に入っていることが報告されました。

  (1)-1. IANA Considerations for IPv6 Neighbor Discovery

    このドラフトは、本会議後の2018年7月末にRFC8425
    <https://tools.ietf.org/html/rfc8425>としてRFC化されています。
    IPv6 近隣探索プロトコルで定義されているPrefix Information
    Option (PIO)に関して、PIO Flags (8bit)をIANA (Internet Assigned
    Numbers Authority)の管理におくという内容です。

    過去、RFC6275 (Mobility Support in IPv6)において、IANAレジストリ
    への登録や既存RFCを更新せずに該当のフィールドを用いてしまったとい
    う経緯がありました。

    同様のことを繰り返さないためにIANAレジストリを作成し、IPv6の近隣
    探索プロトコルを定義しているRFC4861 (Neighbor Discovery for IP
    version 6)を更新する形で、Standards TrackのカテゴリでRFC化されて
    います。

    次に、以下のドラフトがIESGプロセスに進んでいることが報告されまし
    た。

  (1)-2. IPv6 Node Requirements <draft-ietf-6man-rfc6434-bis>

    こちらは、IPv6アドレスを持つノードへの要求事項をまとめたRFC6434
    (IPv6 Node Requirements)の内容を更新するものです。前回議論のあっ
    たDHCPv6のサポートに関しては、SHOULDのままになっています。前回の
    経緯については、上述の第101回IETF報告[第4弾]のURLをご覧ください。


 (2)WGドラフト

  (2)-1. IPv6 Segment Routing Header (SRH)
         <draft-ietf-6man-segment-routing-header>

    こちらは、IPv6におけるセグメントルーティング(SRv6)の仕様を策定す
    るものです。40分という長い時間が割り当てられ議論されました。

    最初に、ドラフトの構成と、他ドラフトとの関連について筆者から説明
    がありました。14版以前のドラフトの導入部分には、セグメントルーティ
    ング(SR)についての説明がありましたが、すでにSRのアーキテクチャに
    関するRFC8402<https://tools.ietf.org/html/rfc8402> (Segment
    Routing Architecture)があるので、それへの参照だけを残して、大幅に
    説明が削られました。削除された説明に興味がある方は、古いバージョ
    ンのドラフトを参照されるとよいかと思います。

    また、spring WGには、SRv6 Network Programming
    <draft-filsfils-spring-srv6-network-programming>というSRv6のネッ
    トワークプログラミングのコンセプトと、基本的な関数(function)を定
    義したドラフトがありますが、このIPv6 Segment Routing Header
    (SRH)のRFC化を先に進めて、SRv6 Network Programmingはそれを参照す
    る形で進めていくと報告されました。

    前回からのアップデートとして、34個のイシューがクローズされ、残り
    は13個となっています。

    ヘッダのフォーマットは、以前から変わっていないですが、フラグの使
    い方に変更が加わり、TLV (Type-Length-Value)の定義も追加で変更と
    なっています。そのため、残りのイシューは、HMAC (Keyed-Hashing for
    Message Authentication)とTLV関連のものが主なものになっています。
    特に、TLVがどのように使われるのかがきちんと定められていないことに
    ついて議論が盛り上がりました。

    議論はされつつも、実装も進み商用での利用も見えてきたので、早く標
    準化プロセスを進めたいという意見も目立ちました。他のWGが新しいビッ
    トを定義しようとしたときにどのようにコーディネートするのか、を明
    確にした上で、文書がアップデートされたら、2回目のWGLCになる予定で
    す。

  (2)-2. IPv6 Router Advertisement IPv6-Only Flag
         <draft-ietf-6man-ipv6only-flag>

    IPv6 onlyのネットワークであることを示すフラグをRAに追加する提案
    で、前回のIETFから今回までの間にWGアイテムとして採用されました
    (IPv6 Router Advertisement IPv4 Unavailable Flagから名前が変更さ
    れています)。

    ネットワークに接続したホストがIPv4を使おうとするのを抑えることを
    目的としていますが、前回に引き続き、賛否両論となっています。

    反対している主な理由は、セキュリティ上の問題です。このRAを受け取っ
    たホストがIPv4の利用をやめる挙動をすると、悪意のあるRAに不意に
    IPv4を使えなくされてしまう恐れがあります。

    その他、このフラグを定義することで、さまざまな脅威モデルを考える
    ことができるため、反対意見は根強かったです。個人的にも、IPv4が使
    えるか使えないかは、IPv4の世界(DHCPv4)で完結しているべきであり、
    他のプロトコルであるIPv6のRAで通知することには問題があると考えま
    す。

  (2)-3. Privacy Extensions for Stateless Address Autoconfiguration
         in IPv6 <draft-ietf-6man-rfc4941bis>

    IPv6の仕様を再整理する際に、議論に時間がかかることが想定されたた
    めに後回しにされた、RFC4941<https://tools.ietf.org/html/rfc4941>
    (Privacy Extensions for Stateless Address Autoconfiguration in
    IPv6)の改定ドラフトです。

    RFC4941には、インタフェースIDを異なるネットワークで使い回すため、
    第三者が端末をネットワークを超えて識別できてしまうという問題があ
    ります。

    このドラフトは、RFC7217<https://tools.ietf.org/html/rfc7217> (A
    Method for Generating Semantically Opaque Interface Identifiers
    with IPv6 SLAAC)で定義されている、ネットワークIDや時間要素をイン
    タフェースIDの生成アルゴリズムに入れる方法や、完全にランダムにす
    る方法を提案しています。

    しかし、RFC7217による方法には問題があるといった指摘や、一時アドレ
    スをデフォルトにすべきかなどの議論が尽きず、MLで継続議論となって
    います。


 (3)個人ドラフト

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

  (3)-1. Zero valid lifetimes on point-to-point links
         <draft-zerorafolks-6man-ra-zero-lifetime>

    現在のIPv6の仕様では、不正なRAによる攻撃を避けるためprefix情報の
    lifetimeを2時間以下にすることはできません。それに対し、P2Pリンク
    に限ってlifetimeをゼロにすることを許容し、別のリンクにすぐに寄せ
    られるようにするGoogle社のエンジニアからの提案です。

    モバイルネットワークからのハンドオーバーや、マルチホーム環境を想
    定しており、Android機器など主にモバイル端末での利用のためと推測さ
    れます。P2Pリンクであれば、上記の不正なRAを出す第三者がいないた
    め、脅威モデルが成り立たないというのが提案者の主張です。しかし、
    端末の立場から、どのようにしてそのリンクがP2Pだと知ることができる
    のか、という疑問も出されました。

    WGアイテムとしての採用には至らず、継続議論となっています。

  (3)-2. IPv6 Neighbor Discovery Extensions for Prefix Delegation
         <draft-templin-6man-dhcpv6-ndopt>

    6man WGで常に話題になる、アドレス設定方法におけるRAとDHCPv6の対立
    ですが、それらを統一するunified stateless/stateful
    autoconfiguration serviceの提案です。

    IPv6の近隣探索においてDHCPv6 Optionのコードを定義し、RSにDHCPv6
    メッセージを入れます。それを受けたルータは、DHCPv6サーバに転送し
    ます。そして、DHCPv6サーバからの回答がルータを経由してRAに載せて
    端末に返される、という動作です。

    統一方法としては非常に興味深いですが、慎重な意見が多かったです。
    特にチェアはあまり乗り気ではなく、もっと議論すべしという指示がさ
    れました。


■6man WG まとめ

今回の6man WGでは、SRv6への期待の高まりを強く感じました。IPv6対応に関
する要求事項など、実装に関する整理は順調に進んでいますが、今後もより
精査が必要となると思われます。IPv6-Only Flagの提案は問題を多く含んで
おりますが、チェアが一推しで進めているため、今後の進展に注目が必要で
す。


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

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃  http://feedback.nic.ad.jp/1618/9b17dd7e6a78b5af2f609309afe38b8d ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃  http://feedback.nic.ad.jp/1618/ed166194fcb0ee1241005e6b19d3826c ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  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.1618 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          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