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

2015年11月上旬に神奈川県のパシフィコ横浜にて開催された、第94回IETFミー
ティングの様子を、vol.1360より連載にてお届けしています。

連載第5弾となる本号では、IPv6の普及に伴い新たな利用方法が生まれつつあ
るDHCPについて、検討を行っているdhc WGを中心にIETFでの議論の動向をご
紹介します。

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

  □第94回IETF報告

    ○[第1弾] 全体会議報告 (vol.1360)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1360.html
    ○[第2弾] IETF会合に初めて参加して (vol.1361)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1361.html
    ○[第3弾] セキュリティ関連報告 (vol.1362)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1362.html
    ○[第4弾] IPv6関連WG報告 (vol.1363)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1363.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第94回IETF報告 [第5弾] dhc WG関連報告
                                               Infoblox, Inc. 神明達哉
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2015年11月1日(日)～6日(金)に、横浜にて第94回IETFが開催されました。IETF
では、さまざまな技術に関する議論が行われていますが、その中の一つにDHCP
(Dynamic Host Configuration Protocol)があります。DHCPは、インターネッ
トの初期から使われている「枯れた」プロトコルですが、最近ではIPv6の普
及に応じた新しい利用法が注目されています。今回の報告でもご紹介する、
一種の移行技術としてのDHCP 4o6がその一例です。また、IPv6の広大なアド
レス空間を活かすために、末端のホストにもDHCPでプリフィクスを配布する
という利用方法も提案されています。

IETFでのDHCP関連の議論は、dhc (Dynamic Host Configuration) WGで行われ
ています。現在、dhc WGは主にIPv6用のプロトコルである、DHCPv6の拡張機
能の標準化について議論しています。具体的には、現状の基本プロトコル仕
様であるRFC3315に、ISP等から家庭やオフィスネットワークにプリフィクス
を自動配布する仕組みとして使われているprefix delegation (RFC3633)を統
合した形の改訂仕様策定、冗長化のためのフェイルオーバー機能の標準化、
セキュリティやプライバシー改善のための拡張機能の標準化などが対象となっ
ています。

本稿では、このdhc WGの議論を中心に、DHCP関連の動向をご紹介します。


◆ DHCP 4o6 Hackathon

IETF Hackathonは、IETF直前の土日を使って、策定中の最新プロトコル機能
を集中的に開発するという派生イベントで、第92回IETFから継続的に開催さ
れています。dhc WGとしては前回に続いての2回目の開催で、今回は、IPv4の
ホスト設定プロトコルとしてのDHCPv4を、DHCPv6のオプションとして定義す
ることでIPv6ネットワーク上で動作させるという、DHCP 4o6プロトコル
(RFC7341)がテーマとして選ばれました。筆者もこのイベントに参加し、
Hackathonで開発の主対象であった、Internet Systems Consortium (ISC)が
従来のISC DHCPサーバに替わる新たなDHCPサーバとして開発中の、Keaサーバ
の開発を手伝ったほか、自作のクライアント実装を用いてKeaとの相互接続性
も検証しました。短時間でしたが、最低限の相互接続性まで確認でき、また
個人的に以前から興味のあったKeaサーバの実装や設定方法などの理解が深
まったこともあり、WGとしても個人としても有意義なイベントになったと思
います。

"running code"を重んじるというのが建前だったはずのIETFも、仕様先行の
悪癖が目立って久しくなっていますが、このHackathonのようなイベントや、
ドラフト仕様への実装状況の記載を推奨する動き(RFC6982)など、IETFを「手
を動かす」エンジニアの集まりとして再構築しようとする試みは、筆者自身
も開発者なので嬉しく思います。


◆ dhc WGミーティング

次に、11月5日(木)午後に開催された、dhc WGのミーティングの概要をご紹介
します。まず、もっとも時間をかけて議論された、2件の発表について詳述し
ます。

1. Relay Initiated Release

この提案は、米Juniper社のSunil Gandhewar氏によるもので、DHCP (IPv6と
IPv4の両方)のクライアントが、アドレスその他のネットワーク資源を割り当
てられたまま移動してしまったような場合に、クライアントに代わってリレー
エージェントから、それらの資源を解放できるようにするというものです。
これにより、(特にIPv4の場合)割り当て用アドレスプールの利用効率を上げ
たり、サーバが管理する状態を減らして、負荷を下げたりすることを目的と
しています。今回のIETFに先立って、個人ドラフトからWGドラフトとしての
採択の是非が、メーリングリスト(ML)で議論されている中での発表となりま
した。

当初ML上では、おそらくすでにこの機能を独自仕様として用いている製品の
ユーザーと思われる人たちからの賛成が相次ぎ、そのまますんなりと採択さ
れるかのように見えました。しかし、資源の「リース」という、DHCPにおけ
る根本的な概念の性質(リースは有効期限で管理され、その間割り当てを受け
たクライアントはその資源を利用できると仮定できる)を覆す提案であること
から、提案への懸念を表明する声も多く上がるようになりました。

ミーティングにおける発表と質疑応答でも、相反する二つの立場がぶつかる
形となりました。提案の著者は、独自に集計した統計情報などから、サーバ
が保持するクライアントの状態数が膨大になり得ることや、自ら解放メッセー
ジを出すクライアントがほとんど存在しないことなどを理由として、提案の
必要性を訴えました。一方、この拡張の悪影響を懸念する人からは、クライ
アントが実際にリソースを保持している期間などの統計がなければ、リレー
エージェントによる解放が安全かどうかはわからないといった指摘が挙がり、
結局、明確な合意は得られませんでした。なお、会合後に現時点ではWGドラ
フトとしての採択は見送るとの結論が、WGのチェアからMLにて通知されまし
た。

2. Moving forward on Secure DHCPv6

Secure DHCPv6とは、公開鍵方式によるDHCPv6クライアント・サーバ間の認証
プロトコルです。RFC3315で規定されている、共有鍵方式のプロトコルの置き
換えとして提案、議論されてきました。なお、筆者もこのドラフトに共著者
として関わっています。Secure DHCPv6のドラフトは、すでにWGのラストコー
ルを終え、IESG (Internet Engineering Steering Group)でのレビューにか
けられる直前の状態となっていたのですが、この段階で担当のarea director
やセキュリティの専門家による事前レビューで多くの懸念が指摘され、差し
戻された形になっていました。

指摘事項は主に、このプロトコルの利用シナリオが不明確であること、厳密
な安全性を犠牲にして利便性を求める"TOFU"(Trust on First Use)モードが
安易に導入されていること、の2点でした。

一方、IETF全体でプライバシーを重視する動きが高まっているのに呼応する
形で、DHCPv6に暗号化機能を導入する提案も、独立した個人ドラフトとして
提出されていました。この提案は、Secure DHCPv6のオプションを一部利用し
ており、その意味では関連する技術となっています。

そこで、WGのミーティング前に、これらのドラフトの著者、WGチェア、セキュ
リティ技術の専門家などの関係者による小規模な非公式ミーティングを開き、
今後の方向性を話し合いました。その結果、このグループ内では以下の方針
で合意されました。

- 認証と暗号化機能を単一ドラフトに集約し、(このプロトコル内では)暗号
  化を必須とする
- TOFUモードはこの単一ドラフトの対象外とする
- 利用シナリオはプロトコルとは別なドラフトで扱う

公式のWGミーティングでは、チェアがこの経緯を説明し、暗号化ドラフトの
著者である清華大学のLishan Li氏が、統合プロトコルの概要を紹介しまし
た。参加者からは大きな反対の表明や問題点の指摘もなく、提案した方向性
はすんなりと受け入れられました。DHCPv6のプロトコルそのものとはやや独
立した話題のため、そもそもあまり興味を持たれていなかったという面もあ
りそうですが、チェアを含めて「声の大きい」人を交えて事前に意見のすり
合わせをしていたのが、奏功した例だと言えるでしょう。IETFのミーティン
グは議論に十分な時間が与えられないことも多く、また単純な誤解などから
大きく「炎上」してしまうようなことも珍しくないので、このように事前に
話を付けておくという手法はしばしば取られています。

3. その他の発表

上記2点の発表以外に、dhc WGミーティングでは以下の発表が行われました。
タイトルと概要をそれぞれご紹介します。

- YANG Data Model for DHCPv6 Configuration:
  DHCPv6の設定情報を、IETFの標準モデル言語であるYANG (Yet Another Next
  Generation)を使って記述するという提案です。現状では、基本的に進捗報
  告のみです。

- DHCPv6 Failover Update:
  DHCPv6サーバ冗長化のための、フェイルオーバープロトコルの仕様ドラフ
  トです。80ページに及ぶ大きなドキュメントで、レビューの負荷が問題に
  なりそうです。

- DHCPv6 Prefix Length hint issues:
  prefix delegationでクライアントから通知する、プリフィクス長の扱いの
  曖昧さに伴う問題を指摘して、処理の指針を提案しています。WGドラフト
  として採択されそうです。

- DHCPv6bis update & issues discussion:
  RFC3315の改訂仕様(上述)の現状報告です。改定項目はWeb上のissue管理
  ページにまとめられていて、随時MLなどでWGとして議論して改訂が進めら
  れています。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

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

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 ＠ 問い合わせ先  jpnic-news@nic.ad.jp
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
登録・削除・変更   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), 2015 Japan Network Information Center