＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
__
/Ｐ▲ ◆ JPNIC News & Views vol.605【臨時号】2008.12.22 ◆
_/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.605 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
本号では、vol.600、vol.601、vol.603に続いて、第73回IETFのレポート
[第4弾]として、引き続きIPv6関連WGの動向についてお届けします。
後編となる本号では、behave WGとintareaの活動をご紹介します。
その他のIEPG、6man、v6opsの各WGに関する動向については、前編をご覧
ください。
□第73回IETF報告 特集
○[第1弾] 全体会議報告 (vol.600)
http://www.nic.ad.jp/ja/mailmagazine/backnumber/2008/vol600.html
○[第2弾] DNS関連WG報告 (vol.601)
http://www.nic.ad.jp/ja/mailmagazine/backnumber/2008/vol601.html
○[第3弾] IPv6関連WG報告 [前編] (vol.603)
http://www.nic.ad.jp/ja/mailmagazine/backnumber/2008/vol603.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第73回IETF報告 [第4弾] IPv6関連WG報告 [後編]
JPNIC IPアドレス検討委員会メンバー/
NTT情報流通プラットフォーム研究所
藤崎智宏
NTT情報流通プラットフォーム研究所
松本存史
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆behave WG(Behavior Engineering for Hindrance Avoidance)
behaveという名前からはちょっと想像が難しいですが、behaveはIPv4で広く普
及しているNATの挙動を定義するワーキンググループです。標準仕様が定義さ
れないままに広く普及してしまったNATにはさまざまな実装があり、NATトラ
バーサルの処理が複雑化しEnd-to-End通信を阻害してしまうことになるため、
NATの実装をBCP(Best Current Practices)として文書化するというのが主な
目的です。
今回の第73回IETFの会期中に、behaveのセッションは3回行われました。これ
までのbehaveで扱っていたNATに関係する各種提案に加え、2008年10月にモン
トリオールで行われたIPv4-IPv6共存中間ミーティングで提案されたIPv4と
IPv6の共存技術のうち、IPv4-IPv6トランスレーションに関する方式をbehave
で扱うことになったため、三つのスロットを取って議論が行われました。ま
た、中間ミーティングで検討された技術のうち、トンネル方式をベースとした
ものはsoftwireにて議論が行われました。
behaveで行われた、IPv6とIPv4の枯渇対策に関係する議論としては以下のもの
がありました。
・IPv4-IPv6トランスレーションに関する提案
draft-baker-behave-v4v6-framework
draft-baker-behave-v4v6-translation
draft-bagnulo-behave-nat64
draft-bagnulo-behave-dns64
draft-vogt-durand-virtual-ip6-connectivity
・大規模NATに関する提案
draft-nishitani-cgn
draft-shirasaki-nat444-isp-shared-addr
・ユーザー毎に使用できるポートを制限する提案
draft-ymbk-aplusp
draft-bajko-v6ops-port-restricted-ipaddr-assign
draft-boucadair-port-range
draft-despres-sam
draft-boucadair-dhc-port-range
・IPv6 NATの提案
draft-mrw-behave-nat66
IPv4-IPv6トランスレータとしては最初に、Fred Baker氏から中間ミーティン
グでの議論の結論として、NAT64方式とIVI方式が統合されてトランスレーショ
ン方式のベースとなり、トランスレーションに関する機能毎にドキュメントを
分割して検討していくという、トランスレーション方式の検討のフレームワー
クについて説明がありました。ドキュメントとして、全体のフレームワークに
ついて記述したドラフト、パケットの変換ルールを規定したSIIT(RFC2765)の
更新について記述したドラフト、ステートフルアドレス変換方式への拡張(今
のところIPv6からIPv4への変換方式のみ)について記述したドラフト、DNS ALG
でのアドレス合成について記述したドラフト、そしてその他の要素(FTP ALG
等)について記述したドラフトという構成になっています。
アドレス変換方式に関する議論としては、対象とするトランスポートプロトコ
ルがTCPやUDPだけになっているが、SCTP、DCCPやIPSecなどの新しいプロトコ
ルは考慮しなくていいのかという質問がありましたが、SCTP、DCCPやIPSecな
どのプロトコルは変換方式についての議論が尽くされておらず、別のドラフト
として進めるという意見が大勢を占めました。
大規模NATに関してはKDDIの中川あきら氏より発表があり、4-4NATや6-4NATな
ど各種のアドレス変換をISPや企業網で利用する場合に共通して必要となる機
能を整理した提案と、4-4-4NAT即ち、IPv4 NATを2回行うモデルに関する提案
がありました。また、この4-4-4モデルを利用する際のISPの空間で利用するア
ドレスについて、本提案ではISPで共有できるアドレスブロックの新設を提案
しており、その議論はintareaのセッションにて別途行われました。
同じくIPv4アドレス在庫枯渇に関する技術として、ユーザーにIPv4グローバル
アドレスを付与するが、利用できるポート範囲を制限するというA+Pと呼ばれ
る方式がRandy Bush氏より提案されました。本方式のメリットとしては、ユー
ザーがISPのNATの配下に収容されるのではなく、利用は制限されるものの、あ
くまでグローバルIPv4アドレスがユーザーに付与されるため、End-to-Endの透
過性が保持されるというものです。しかし、ISP内でのルーティングや、ユー
ザーが使用しているルータや時には端末への変更が必要であり、実際に利用す
るにはクリアすべき障壁の多い方式になっています。
また、3回目のセッションではMargaret Wasserman氏とFred Baker氏より、
NAT66、つまりIPv6からIPv6へのNATに関する発表がありました。IPv6の設計思
想の一つとして、IPv4で現在広く使用されているNATを使わないようにする、
というものがありましたが、本提案の趣旨としては、IPv6においてもなおNAT
を必要とするケースがあることから、IPv6 NATを実装し利用する人々が出てく
ることは不可避であり、そこでIETFとしてはIPv4 NATのような標準仕様のない
混沌とした状況を生み出さないためには、IPv6 NATの標準仕様を策定する必要
がある、という論調になっています。
具体的な適用先としては、企業ネットワークなどが挙げられ、特にネットワー
ク間を接続する際にトポロジーの隠蔽が必要であり、双方向のNATが必要であ
る、などの提言がありました。NATを利用しないためにIPv6を標準化し、普及
を推進してきたIETFとしては、非常に重要なトピックであり、さまざまな議論
が交わされました。否定派の意見としては、IETFでNAT66がRFCになることで、
NAT66の普及を促進してしまうのではないか、IPv6でのセキュリティ実現方法
について記述したLNP(RFC4864)でカバーできているのではないか、といった意
見がありました。その場でのディスカッションでは、肯定否定というのではな
く慎重派が多いように見受けられましたが、結論としては本提案内容をベース
として議論を継続することになりました。
□v4v6interim
http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim
□behave WG
http://www.ietf.org/html.charters/behave-charter.html
□第73回IETF behave WGのアジェンダ
http://www.ietf.org/proceedings/08nov/agenda/behave.html
◆intarea (Internet Area Open Meeting)
先にbehaveの項でも触れましたが、ISP等でNATを行う場合にNAT配下で利用す
るアドレスとして、ISP共有アドレス(ISP Shared Address)の新設に関する提
案がKDDIの中川氏よりありました。NAT配下で利用するアドレスとしては、RFC
1918で定義されるプライベートアドレスを利用することが一般的ですが、ISP
でこのアドレス空間を使った場合に、ユーザーが設置するNAT装置配下で利用
するアドレス空間とバッティングする可能性があり、通信障害が発生するため
別のアドレスブロックが必要であること、またISP共有アドレスとしてどの程
度の大きさのアドレスブロックが必要か、などの説明がありました。この提案
に関する議論としては、現在利用されていないクラスE(240/4)の空間を利用し
てはどうか、ISPによっては際限なく大きなアドレス空間を要求するのではな
いか、ISP共有アドレスを利用している複数のISPにマルチホームしている場合
にはやはり通信障害が発生するのではないか、といったものがありました。そ
の場の結論としては、メーリングリストで継続して議論を行うということにな
りました。
また、これらのIPv4アドレス在庫枯渇、IPv6への移行といった一連のトピック
に関して、今回の第73回IETFと次回のIETFとの間に、マルタ島にて中間ミー
ティングを開催して集中議論を行うことが計画され、参加者数の調査などが行
われていたのですが、3回目のセッションにおいて、マルタ島での中間ミー
ティングはキャンセルになったことが発表されました。中止の理由としては十
分な参加者数が期待できないことが主だと思われますが、場所を移して中間
ミーティングが行われるかもしれないとのことでした。
□第73回IETF intareaのアジェンダ
http://www.ietf.org/proceedings/08nov/agenda/intarea.txt
第73回IETFミーティングの各種情報は、以下のURLより参照可能です(議事録も
今後掲載される予定です)。
□ 全体プログラム、WGアジェンダ、発表資料
https://datatracker.ietf.org/meeting/73/materials.html
□ 録音
http://videolab.uoregon.edu/events/ietf/
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
わからない用語については、【JPNIC用語集】をご参照ください。
http://www.nic.ad.jp/ja/tech/glossary.html
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■ JPNICの活動はJPNIC会員によって支えられています ■■■■■
::::: 会員リスト ::::: http://www.nic.ad.jp/ja/member/list/
:::: 会員専用サイト :::: http://www.nic.ad.jp/member/(PASSWORD有)
□┓ ━━━ N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛ お問い合わせは jpnic-news@nic.ad.jp まで ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
JPNIC News & Views vol.605 【臨時号】
＠ 発行 社団法人 日本ネットワークインフォメーションセンター
101-0047 東京都千代田区内神田2-3-4 国際興業神田ビル6F
＠ 問い合わせ先 jpnic-news@nic.ad.jp
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
本メールを転載・複製・再配布・引用される際には
http://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
登録・削除・変更 http://www.nic.ad.jp/ja/mailmagazine/
■■◆ ＠ Japan Network Information Center
■■◆ ＠ http://www.nic.ad.jp/
■■
Copyright(C), 2008 Japan Network Information Center
JPNICはインターネットの円滑な運営を支えるための組織です
- JPNIC
-
IPアドレス・AS番号
指定事業者向け各種申請手続/お知らせ
一般ユーザーの方
-
JPNIC会員
会員向け情報/各種変更手続
入会のご案内
