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

本号では、2013年3月上旬に米国カリフォルニア州で開催された第86回IETFレ
ポートの第4弾として、IPv6に関連するWGのうち、v6ops WGの動向についてご
紹介します。

同じくIPv6に関連したWGである6man WGの動向については、vol.1080にて既に
ご報告していますので、第86回IETFの全体報告やDNS関連WG報告と同様に、下
記のURLよりバックナンバーをご覧ください。

□第86回IETF報告 特集
  ○[第1弾] 全体会議報告 (vol.1078)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2013/vol1078.html
  ○[第2弾] DNS関連WG報告 (vol.1079)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2013/vol1079.html
  ○[第3弾] IPv6関連WG報告 ～6man WGについて～ (vol.1080)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2013/vol1080.html

なお次号では、softwire WG、sunset4 WG、homenet WGの三つのIPv6関連WGに
ついて、まとめてレポートをお届けする予定です。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第86回IETF報告 [第4弾]  IPv6関連WG報告 ～v6ops WGについて～
                               ＮＥＣアクセステクニカ株式会社 川島正伸
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

米国オーランドにて開催された第86回IETFのWorking Group (WG)の中で、筆
者が会合に参加したIPv6に関連するWGの中からv6ops WGについて、議論の概
要をご紹介したいと思います。

◆ v6ops WG (IPv6 Operations WG)

v6ops WGは、IPv6運用上の問題解決のための議論を第一優先として、その他
にはIPv6普及に向けた運用上のガイドラインなども取り扱うWGです。今回は
2013年3月11日(月)と13日(水)の二つのタイムスロットで実施されましたが、
いずれのタイムスロットでも、予定していた時間よりかなり早く終了すると
いう状況でした。

以下、今回のセッションで議論が行われた、いくつかのトピックの概要につ
いてお伝えします。

1. NAT64 Deployment Considerations (NAT64使用時の考慮事項)
   draft-ietf-v6ops-nat64-experience-01

本ドキュメントは、NAT64の展開シナリオと運用上の経験について記載された
もので、Working Group Last Call (WGLC)を終えた段階にあります。今回の
プレゼンテーションは、WGLC中に寄せられたコメントとしてStateless NAT64
に関する記述を含めるかどうかと、今後の進め方について確認を求めるもの
でした。また、WGLC中のコメントなどフィードバックが少なかったため、こ
のまま標準化を進めるべきかどうか提案者としては懸念している、という発
言がありました。

会場からは、タイトルがExperienceからConsiderationsに変更された点につ
いて、ドキュメントは提案者の経験に基づき記述されており、より一般的な
情報として参照できるレベルとは言えないので、Experienceに戻すべきだと
いう指摘がありました。また、Google社がWebページの表示を高速化する目的
で開発したSPDYのような、持続性のあるセッションを扱うプロトコルの存在
が、NATデバイスに与える影響についての知見が不足しているので、
Experienceに戻すべきだとの意見もありました。今後の進め方として、タイ
トルをExperienceに戻して、かつ現在のコメントを反映した版で再度WGLCが
行われることになりました。


2. Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN
   (/64プリフィクスを3GPPモバイルインタフェースからLANへ拡張する方法)
   draft-ietf-v6ops-64share-03

本提案では、3GPPネットワークにおいて、DHCPv6-PDが利用できない環境下に
ついて取り扱っており、User Equipment (UE)の3GPPモバイルインタフェース
がモバイル網からRAで/64のプリフィクスを取得した際に、同じプリフィクス
をLANでも使用可能にするための、以下の三つのユースケースについて提案し
ているものです。

(1) UE上にグローバルアドレスを一切保持しないケース

(2) グローバルアドレスをLAN側だけに割り当てるケース

(3) 同じグローバルアドレスをエニーキャストアドレスとして3GPPモバイル
    インタフェースとLAN側の両方に割り当てるケース

なお、別の手法として既にRFC 4389として標準化されているND Proxyがあり
ますがExperimental Statusであり、またループ回避に関する制限事項がある
ことが、本提案の動機になっています。

会場からは、おのおののユースケースにおいて、ローカルアプリケーション
に与える影響についても考慮すべきとのコメントがありました。WGLCを行う
かどうかについての確認では1/4程度の賛同は得られたものの、メーリングリ
スト(ML)上での議論を継続して判断することとなりました。

その後すぐにML上で議論が開始され、IETF会期後半まで非常に多くの議論が
行われました。3GPP standardに違反しないのかとか、USBドングルやNDIS 
driverの存在により想定外の挙動になったりしないのかとか、短期/中期解と
して本方式を使うのではなく、やはりDHCPv6-PDを使うべきではないかなど多
くの提案やコメントが寄せられました。


3. Balanced Security for IPv6 CPE
   (IPv6 CPEのためのバランスの良いセキュリティ)
   draft-v6ops-vyncke-balanced-ipv6-security-00

本提案は、スイスのSwisscom社が展開しているIPv6 CPEのセキュリティ要件
を参考例として、セキュリティレベルとEnd to Endの接続性を適度にバラン
スしたポリシーを提供することを目的としたものです。実際、マーケティン
グ部門はセキュリティを重要視するのに対し、多くのエンジニアはEnd to 
Endの接続性を重要視しているので、良い落としどころを見つけて情報提供す
ることがこの提案の主旨であると言えます。

これまでの標準化の議論では、Recommended Simple Security Capabilities 
in CPE for Providing ResidentialIPv6 Internet Service (RFC 6092)がす
べてのInbound Trafficをブロックするか許容するかの2択としているのに対
して、Advanced Security for IPv6 CPE 
(draft-vyncke-advanced-ipv6-security-03)[Expire] では、IPSや
Reputation Databaseなどを必要とするなどハードルがかなり上がっているた
め、ほどよくバランスされたセキュリティポリシーを必要としているという
背景事情があります。

会場からは、新しいアプリケーションやインシデントなどの事情によりポリ
シー変更を伴う場合に、どのようにしてドキュメントを更新していくのかと
いった質問や、このセキュリティポリシーにより実際にどの程度のインシデ
ントが抑制されているのかなど、運用上のフィードバックがより必要である
との発言がありました。提案者によると、Swisscom社は2012年からIPv6 CPE
を展開しているが、今のところインシデント報告はされていないとのことで
した。

その後、本提案をWGアイテムとして採択すべきかハミングが行われましたが、
賛成／反対が半数ずつに分かれたため、ML上で継続して議論を行うことにな
りました。


4. Guidance of Using Unique Local Addresses (ULA 使用に関するガイド)
   draft-liu-v6ops-ula-usage-analysis-05

本ドキュメントでは、Unique Local IPv6 Unicast Addresses (RFC 4193)自
体のメリット／デメリットの分析とともに、ULAの使用が推奨されるユース
ケースのガイドとして記述されています。なお、推奨されるユースケースと
しては、以下が記述されています。

(1) インターネット接続から独立した、いわゆる閉域ネットワークでULAのみ
    を利用

(2) ULAとGUA(グローバルユニキャストアドレス)の両方を利用

(3) 特別なユースケースとして、B2Bのようなプライベートネットワーク間の
    接続における利用や、NAT64プリフィクスとしての利用、上位レイヤにお
    ける識別子としての利用

なお、ULA + Proxyや、ULA + NPTv6は、取り得るユースケースとしては分析
されていますが、推奨されるユースケースには含まれていません。

会場からは、ULAとGUAの両方を利用する場合、大規模ネットワークでは誰が
それを実際にやってるのか疑問だという意見があり、小規模での適用なら同
意できるとコメントされました。また、特別なユースケースは、おのおの
Pros/Consがあるはずで推奨されるユースケースではないので、ユースケース
の整理はより明確に記述すべきといったコメントがありました。その他のコ
メントとしては、ULAの境界ルータではどのように振る舞うべきかといった事
項が記述されておらず、明確な記述が必要だとするコメントもありました。

その後、本提案をWGアイテムとして採択すべきかハミングが行われましたが、
少数の賛成と、反対はほぼ無しという結果だったため結論は出さず、ML上で
継続して議論しつつ、方向性を決定していくことになりました。

※ 会期終了後から現在に至るまで、ML上で数多くの議論が行われています
   が、ULAの運用経験がまだまだ少ないことから、ドキュメントのカテゴリ
   はBCP (Best Current Practice)ではなく、Informationalとして進めよう
   という意見が大多数となっている状況ではあるものの、まだ結論は出てい
   ません。


□v6ops WG
  http://tools.ietf.org/wg/v6ops/

□第86回IETF v6ops WGのアジェンダ
  http://www.ietf.org/proceedings/86/agenda/agenda-86-v6ops


[おまけ] draft-ietf-v6ops-464xlatに関して

筆者が共著者の1人として、v6ops WGに提案していた464XLAT: Combination 
of Stateful and Stateless Translation (draft-ietf-v6ops-464xlat)です
が、IETFの会期直前にRFC Editor Process (AUTH48 status)に進むことがで
きたため、本セッションでプレゼンテーションを行うことはありませんでし
た。

なお、本提案は 2013年4月3日(水)にRFC 6877として正式に発行されました。

(参考URL) http://www.necat.co.jp/press/2013/pre_01.html

この場をお借りしまして、464XLATの提案をご支援いただきました関係者の皆
さまにお礼を申し上げたいと思います。さまざまなアドバイスやご支援をい
ただきまして、本当にありがとうございました。


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

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

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