＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲         ◆ JPNIC News & Views vol.571【臨時号】2008.9.3 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
---------- PR --------------------------------------------------------
■■■    進化し続ける専用ホスティングサービス『ＭＤＥＯ』    ■■■
MDEOとは、システム開発会社様向けのレンタル開発環境です。
システム保守・瑕疵担保期間中の開発環境の維持を安価に行う事が可能で、
開発環境からシームレスに本番運用に移行する事ができます。
━━  株式会社ディーネット 詳細はこちら ⇒ http://www.mdeo.jp/  ━━
----------------------------------------------------------------------
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.571 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2008年7月27日から8月1日の6日間にわたり、アイルランドのダブリンで開催さ
れた第72回IETFのレポートを、本号より連載でお届けします。

まず[第1弾]として、本号では全体会議の報告をお送りします。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第72回IETF報告 [第1弾]  全体会議報告
                               株式会社インテック・ネットコア 廣海緑里
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆ 概要

年に3回開催されるIETFでは、1回以上を北米以外で実施することになっていま
す。今回は、その"北米以外"にあたっており、アイルランドで開催されました。
アイルランドといえば、子供の頃に聞いた丸山薫作詞の「汽車に乗って」の一
節、「日が照りながら雨のふる/あいるらんどのやうな田舎へ行かう」を思い
出しますが、そのような天候ではなく、朝方雨が降っても昼間は太陽が輝き、
隣接するゴルフ場の芝生を美しく照らす素敵なところでした。緯度が高いため、
日が暮れるのも20時半過ぎで、朝から晩まで続く会議で1日がやたらと長く感
じるIETFですが、最後のセッションを聞いた後もまだ日が出ているため、
ちょっといつもとは違う感覚を味わうことができました。

会場は、ダブリン市内からバスで30分ほどの田園地帯にあり、普段はゴルフの
ための宿泊客が多いようで、ヘリコプターで来るゲストのためにヘリポートが
備わっており、会期中も頻繁にヘリコプターが行き来していました。隔離され
た環境に、世界中から研究者や技術者が集まって、議論に没頭する1週間とな
りました。

  ・会期：2008年7月27日～8月1日
  ・会場：CityWest Hotel(Dublin, Ireland)
  ・参加費：635USD(early registrationの場合)
  ・セッション数：118(tutorial、training、plenary sessionを除くWGやBoF
                  セッション数)
  ・ホスト：Alcatel Lucent社(通信機器ベンダー)
  ・参加登録者数：1,183(前回比50人増、1,000人強で常態化しているようです)
  ・参加国数：48(国別の分類などもUS、JP、DEなど変わらず。参加国数も常
                 態化)

今回の会場は、ゴルフ場の中にあり、宿泊施設とメイン会議場の他にも数棟の
建物内の会議場がありました。鮮やかなグリーンやよく手入れのされた草花を
見ながらの移動は気分転換にもなり、また、途中のテラスやバルコニーにもイ
スやテーブルがあり、そこかしこで議論をしている人でにぎわっていました。

会期の始まる直前に、ComputerWorld(*1)のWebサイトに、IETFチェアのRuss
Housley氏による「IETFでは、現在VoIP、MPLS、P2PとならんでIPv4/IPv6プロ
トコル変換機がホットトピックである」というインタビュー記事が公開されま
した。しかし、IETFではプレナリをはじめ、この話に触れる発言もなく、特に
どのプロトコルに力を入れているということもなく、どの標準化作業について
もタフな議論がされていたように思います。

(*1)http://www.computerworld.jp/topics/nb/116249.html

◆ IETF Technical Plenary

今回は、Technical Plenaryが4日目(2008年7月30日、17:00～19:30)にあり、
Operations and Administration Plenaryが5日に行われました。

Welcomeスピーチの後、ホストのAlcatel-Lucent社(アイルランド支社のKevin
O'Callaghan氏)のホスト・プレゼンテーション、IRTFとIABからのレポートに
続き、「IPv6 Deployment Forum」のタイトルでテクニカルセッション、オー
プンマイクという流れでした。

ホスト・プレゼンテーションでは、通信機器ベンダーらしく、通信環境の変遷
についてどのようなことを課題として取り組んできたか、最近のトレンドは何
か、という発表がありました。エコロジー(エネルギー問題)についての取り組
みの紹介では、いくつか実例紹介があり、その中でも、富士通社がspamを低減
することで消費エネルギー(電力)を削減したというエピソードは、海外で聞く
日本の評判という点からも興味深いものがありました。

「IRTF Report」では、IRTFチェアのAaron Falk氏から、dtnrg(*2)で開発した
参照コード"DTN2"がSource Forge(*3)にも掲載され取得できるようになったこ
との報告がありました。最近の各リサーチグループの動きの中では、
iccrg(*4)内に、リサーチペーパー作成のためのデザイン&ドラフティングチー
ムが形成されていることの紹介がありました。また、SIPのアプリケーション
やIPv6についてのリサーチについてもトピックとしてあがっているとのことで
した。

(*2)dtnrg: Delay Tolerant Networking Research Group
(*3)https://sourceforge.net/project/showfiles.php?group_id=101657
(*4)iccrg:Internet Congestion Control Research Group

続くOlaf Kolkman氏による「IAB update」では、通常のドキュメント更新状況
や多組織との協調活動報告のほかに、「RFC Editor Model」というタイトル
で、RFCの執筆から発行までの整理と提言がされました。この提案では、RFCの
生産工程における担当者とその役割が提示されるとともに、具体的には、
"stream producers"、"stream approvers"、"production house"、
"publisher"、という大きな枠組みがあり、その中における"RFC Editor"の
"production house"と"publisher"に対する関与の仕方を整理しています。
詳細は、IABのWebページ(*5)で閲覧可能で、コメントも受付中です。

(*5)http://www.iab.org/documents/resources/RFC-Editor-Model.html

また、IABとして現在まとめている文書のうち、前回紹介された、「よいプロ
トコルの条件」
(What makes For successful protocol?,draft-iab-protocol-success-02.txt)
は、RFC5218として発行されたという報告がありました。

これにより、現在進行中のIAB文書は、「ヘッダと常用文」が追加されて、以
下の三つになります。

  -「Internet上の端末設定の原則」(Principles of Internet Host
    Configuration, draft-iab-ip-config-04.txt)
  -「DNS拡張を行う際のデザインの選択性について」(Design choices when
    expanding DNS, draft-iab-dns-choices-06.txt)
  -「ヘッダと常用文」(Headers and Boilerplates,
    draft-iab-streams-headers-boilerplates-00.txt)

IAB主導で進められているアーキテクチャに関する活動としては、2008年4月25～
26日にストックホルムで開催した会合があり、この結果は、「IPモデルの進化
(The evolution of the IP model,draft-thaler-ip-model-evolution-01.txt)、
「ピアツーピアのアーキテクチャ(Peer to Peer Architecture,
draft-camarillo-iab-p2p-archs-00.txt)としてまとめられたほか、今回のテ
クニカルプレナリの企画につながったそうです。

前回報告のあった、ITU-TとIETFによるMPLSの拡張に関するジョイント・ワー
キング・チームについては、draft-bryant-mpls-tp-jwt-report-00.txtとして
成果がまとめられたそうです。そのほかにも、OECDとも、世界経済における
インターネットのもたらす経済と将来性についての議論がはじまったそうです。

Olaf氏からは最後に、IABのロゴマークが紹介されました。ロゴデザインは、
Dow Street氏によるものだそうです。

パネルディスカッション形式で行われた、「IPv6 Deployment Forum」では、
開催に先立って、このディスカッションのモデレーターであるIABのGregory
Lebovitz氏から参加者に、概要や参考情報などが提示されました。(*6)

(*6)http://www.ietf.org/mail-archive/web/ietf/current/msg52686.html

IPv6の普及については、"ニワトリと卵の問題"と揶揄される状況も見受けられ
ますが、そのような状況でもIPv6によるサービスを開始している事業者も出始
めています。こうした先例を知ることによって、IPv4の在庫枯渇問題(RIRから
の新規割り当てアドレス売り切れ)やIPv6を取り入れていくことにどう立ち向
かうのかヒントを得るとともに、IETFがどのようにサポートしていくべきであ
るのかを見極めたいというのが、今回のパネルディスカッションの狙いでした。

セッションは、Lebovitz氏から、あらためて主旨説明がされた後、IETFが手掛
けたIPvt6の移行作業の一つとして、NAT-PT(Network Address Translation-
Protocol Translation)の話がありました。NAT-PTは、2000年の2月に、
RFC2766として発行されましたが、2007年7月にRFC4966により"Historic
Status"となっています。しかし、1年たって状況をみてみると、NAT-PTであげ
られている利用例は現存しており、NAT-PTの必要性は残っているという説明が
ありました。実際に、IETF72でも、三つのWGと二つのエリアミーティング、一
つのBoFで取り上げられていたそうです。

ということで、「現場の苦労を語る」ために選ばれた、5人のパネリストの紹
介がありました。

  ・ARINのMark Kosters氏
  ・Comcast社のAlain Durand氏。
  ・NTTコミュニケーションズのShin Miyakawa氏
  ・Google社のLorenzo Colitti氏
  ・Apple社のStuart Cheshire氏です。

ARINのKosters氏からは、IPv4とIPv6のアドレススペースの動向について、わ
かりやすい統計資料を用いた説明がありました。IPv4の5大RIRへの割り振りで
は、ARIN/RIPE/APNICでそれぞれ30%ずつを分け合っており、これはLIRやISPへ
の割り当てとほぼ合致するため、実際の利用状況もそのようになっていると言
えます。一方で、IPv6の割り振りは、各RIR に/12ずつ均等に分配されている
ため、その/12内のLIRやISPへの割り当て状況が報告されていました。RIR内の
割り当て件数で推移をみると、およそ50%がRIPEで、APNICが30%、ARINが18%、
LACNICとAfriNICが2%といった状況であるという報告がされました。また、ポ
リシー提案状況について、IPv4では枯渇や割り振りサイズであるのに対して、
IPv6では、プロモーションをはじめとして割り当てと割り振りそのものについ
てとなっていて、プロトコルバージョンの普及度合いによって議論の内容に違
いがあるという興味深い報告もされていました。

続いて、Comcast社のAlain Durand氏からは、全米一の巨大CATV網における
IPv6の導入について話がありました。Comcast社では、インフラ(CATVバック
ボーン)のIPv6対応、その次に家庭への接続計画とラボテストという2段階のア
プローチで取り組んできたそうです。CATV業界では、DOCSISというケーブルモ
デムの仕様があり、これのバージョン3.0で、IPv6対応となっているという事
情もあるようですが、それでもベンダーから対応ソフトがなかなか入手できな
いなどの苦労があったそうです。また、数100万世帯分のIPv4アドレスを苦労
して調達・管理し続けるするより、IPv6の大きなスペースをまとめて入手し、
それを使ったケーブルモデムの管理ネットワークを設計構築してしまう方が安
上がりという考えも当初あったようです。

ところが、現実の問題として、ケーブルモデムから先の家庭内の事情として、
家庭内の機器はやはりIPv4ベースのものが多く、また、その家庭内の機器の通
信先であるコンテンツサーバもIPv4ベースであるという事情から、CATVバック
ボーンがIPv6に対応しても、IPv4パケットを受け取り、IPv6対応バックボーン
を通過して、IPv4網に流す仕組みは必要である、という結論に達したそうです。
さらに、IANAからRIRへのIPv4グローバルアドレスの新規割り振りができなく
なった際には、これまでのISPからホームゲートウェイにIPv4グローバルアド
レスを割り当てられることもなくなります。そのため、現在、同社ではこれま
での、「やがてくるIPv6対応のためのネットワーク計画」に、「IPv4だけの機
能しか持たない機器」の救命策の導入を行っているそうです。Durand氏からは、
三つのプランが提示されました。

  プランA：デュアルスタック対応のホームゲートウェイを提供するが、
           IPv4のみの接続性は提供しないという案
  プランB：IPv4プライベートアドレス対応のホームゲートウェイを提供し、
           ISPのIPv4プライベート網に接続するダブルNAT案
  プランC：デュアルスタック対応のホームゲートウェイを提供し、IPv4のみ
           の機器にはIPv4overIPv6トンネルを提供してIPv4の接続性をもた
           せるデュアルスタック・ライト案
  (全てのプランは、新規加入者が対象です。既存顧客にはこれまでと同じ環
   境が提供されます)

それぞれのプランのメリット・デメリットを踏まえ、プランCが既存顧客に
とっても、デュアルスタックの環境を持つユーザー、将来増えると目される
IPv6顧客のいずれににとってもよいと結論づけていました。そして、プランC
を遂行するには、ISPのバックボーン内にIPv4ネットワークをつなぐための
キャリアグレードNAT(Network Address, protocol translator)の導入する必
要性を訴えていました。

一方、Google社のIPv6対応はとてもシンプルな要求によるものです。それは、
「IPv6だけの環境を持つユーザーが出てきた時にコンテンツを提供できるよう
になっていること」だそうです。そして、もしもIPv6でコンテンツを提供する
ことが、もっとよいユーザーサービスにつながるのであれば、推進していくと
いうゴモットモな動機が表明されていました。Google社がIPv6を用いることで
検証したいのは、具体的には、

  ・IPv6によって、遅延やパケットロスが低減するかどうか
  ・NATレスによるAjaxアプリケーションの挙動の向上(多数コネクション接続
    時のNAPTによるポート消費解消)
  ・NATトラバーサル対応からの解放(開発時間をもっと別のことに使えるよ
    うにしたい)

といったあたりです。また、IPv4の在庫枯渇問題に対するGoogle社の答えも非
常にシンプルで、RIRのアドレスプールがなくなった時の根本的な解決策は
IPv6を使うということであり、アドレスプールは2011年末になくなることがわ
かっているのだから、「なぜIPv6なのか」と言ってる場合ではなくて、「いつ
やるべきか」ということが問題であり、

  ・やるなら早いうちに対応しておく方が良い(サービス品質が求められる前に)
  ・すぐやる方が後からせっぱつまって対策するより、コスト削減につながる
  ・IPv6対応は、高等理論いっぱいの難しいことではないが、時間はかかりそ
    うだという考えの着地点が、「今」だった

という説明がありました。とはいえ、Google社におけるIPv6対応も、いわゆる
「20%プロジェクト」として開始され、試験環境を整え、社内会合のネットワー
クで試し、ネットワークが立ち上がることによってアプリケーション側の対応
がはじまり、という具合に進んできたそうです。その後、規模を大きくし、精
度を高める、というステップを踏んできたそうです。そうした体験から、
「IPv6はIPv4ほどすんなりとは進まないから、オペレーターは注意深く、ゆっ
くり、確実に取り組んだ方がいい」という助言がありました。ただし、「高等
な理論は必要なく、時間がかかるだけ」というフォローもありました。

ここまでのところ、Google社はIPv6にすごく好意的であるという印象を受けま
すが、機器・相互運用性についての現状評価は厳しく、期待に反して、実装さ
れていない機能や信頼性がない事象の紹介がされるとともに、「インターネッ
ト(相互に接続し合って成り立つネットワーク網)ではない」という嘆きも表明
されていました。しかし、解決策の見えている問題ばかりとして捕らえている
ようであり、その上で、Google品質を保つにはどうすべきか?という課題解決
に向けて取り組んでいるようです。また、キャリアグレードNATについての考
えは、できるだけクライアントはIPv6に移行すべきと考えているようで、そう
した中でもIPv4コンテンツにアクセスすることができるように、「IPv6-Only
Networks with NAT-PT」を提案していました。ここでも、IPv4 NATより、こ
ちらの構成の方がまだまし、というアンチNATの発言が強調されていたように
思います。最後に、IETFへの要望として、以下の4点が伝えられました。

  ・IPv6-onlyのネットワークへの最低限のNAT-PT機能(RFC2766の部分的復活) 
  ・point-to-pointリンクへの/127接続(RFC4291の該当部分の改訂)
  ・IPv6のVRRPの策定
  ・/48を使ったマルチホーム

最後のパネリストである、Apple社のCheshire氏からは、OS、Apple TVといっ
た機器、iTunesなどのアプリケーション、.MacのようなxSP機能の提供者とい
うあらゆる側面から話がありました。前述のように、Apple社が世に出す製品
は沢山あるのですが、どれもIPネットワークを利用するものばかりで、IPv6を
サポートした際にも、TCP/IPの基本的な挙動上でのIPv4とIPv6双方の共存面に
苦労したようです。Apple社では、そうした困難に遭遇した際には、純粋にOS
として、またアプリケーションとして、それを扱うISPというそれぞれの立場
に立って、「これはイケル」と思えるものとそうではないものに整理して対処
にあたってきたそうです。

その結果、TCP確立時のIPv6-IPv4フォールバック問題(接続に時間がかかった
り、タイムアウトしたりする問題)には、getaddrinfo()関数をカスタマイズし
て、IPv6の接続性を確認した上でIPv6のコネクションを張るように改良をした
り、"connect-by-name"と呼ばれるAPIを使って、TCPの名前解決をせずにアプ
リケーションをオープンするような仕組みを取り入れるといった工夫を随所に
施した上での製品提供となっている、という説明がありました。Cheshire氏自
身は言及していませんでしたが、説明にあったようなIPv4とIPv6を同時に動か
した上で共存状況での挙動について、早くから取り組んできたことによって得
た知見が活かされ、対処できているよい例だと思われました。

パネリストの発表が一通り終わった後に、モデレーターと会場からのQ&Aがあ
りましたが、
  ・DHCPv6を使った設定やDHCPv6 Proxyなどの利用はうまくいくか。問題点は
    ないか
  ・キャリアグレードNATなどの議論はなぜBEHAVE WGで行われているのか
  ・softwireはどうなのか
  ・proxy(Application Level Gateway)はどうなのか
  ・Googleでv6クライアントのダイレクト・コネクションについて気にするの
    はなぜなのか
  ・キャリアグレードNATなどのような中間機器を新しく開発するのは本当に
    必要なのか
  ・v4だけでしか通信できない機器は本当にそんなにあるのか。どういう想定
    なのか。どれ位見越す必要があるのか
といった幅広い領域に対する質問が飛び交っていました。キャリアグレード
NATなどについては、BEHAVE-WGを中心に議論が継続中です。

◆ IETF Operations and Administration Plenary

Operations and Administration Plenaryでは、今回はホスト・プレゼンテー
ションも前日のテクニカル・プレナリで行われ、淡々とIETFの運営(NOC、IETF 
チェア、IETF trustチェア、IAOCチェア、IAD、NomCom、EDUチーム)に関する
報告がされました。

標準化作業について、前回のミーティング後からのRFC発行数(88)、I-D投稿数
(107)、そのうちIANAに依頼したレビュー数などの報告がありました。

今後のミーティング予定の発表では、次回IETF73のミネアポリスから、IETF76
まで来年1年分の発表がありました。以下、2009年の開催予定です。
  ・IETF74　2009年3月22日～27日 サンフランシスコ(アメリカ)
            ホストはJuniper Networks社
  ・IETF75　2009年7月26日～31日 ストックホルム(スウェーデン)
            ホストは.SE
  ・IETF76　2009年11月8日～13日 広島(日本)
            ホストはWIDEプロジェクト

その後のIAOC Q&Aの時間に、IAOCから、2010年の開催予定地であるアナハイム
とアトランタ(いずれもUSA)に関心のある人は、ホストを探していますのでぜ
ひともよろしく、というアナウンスがありました。

IESG Q&Aでは、IESGの標準化プロセスへの介入方法や、権限について苦情に近
い質問が出ていました。これに対して、かなり長時間、IESG内でどういうプロ
セスを持っているか、議論はどの程度行われているか、著者へのコンタクトや
ADへの協力体制はどうなっているか、といった説明が丁寧になされていました。
途中、ダブリンの醸造所で誕生したギネスビールがIESGに振る舞われるという
場面がありましたが、その後も継続して、この質問については、trackerとい
うツールにより著者以外にも全ての人に対してどのようなコメントがされ著者
の反応はどうか、といった状況は公開されていること、絶えずADやWGに対して
満足されるような支援であるか考えながら進めているといった回答がされてい
ました。

IAB Q&Aは、前もって、Olaf氏よりメーリングリストで事前に質問事項を送っ
て、時間短縮をしようという提案がされていましたが、結局ポストされたのは
1件で、内容も、「プレナリの時間は延長可能ですか」というものだったとい
う哀しい発表がされていました。実際の会場からの質問は、nomcom processに
関するもの、NATやトンネルプロトコルと協調動作する新しいインターネット
プロトコルを作成すべきなのではないかというもの、NATやトンネルプロトコ
ルに関係してUDPのカプセル化についての議論、Unicodeの普及に関しての援助
依頼、といった事項があがっていました。いずれも継続した議論となりそうで
す。

◆ 余談

テクニカル・プレナリの「IPv6普及パネル」で、Google社発表の決め台詞とし
て、「IPv6 is Not Rocket Science」という言葉が使われていてましたが、発
表スライドには、右肩に「TM」とありました。本当に、商標登録しているのか
気になるところです。(この言葉、初出典は、DNSの設定について述べたBill
Manningさんのようです)

IETF71に引き続き、無線のアクセスポイントとロケーション情報を使った、
GEOPRIVとECRIT wgの実験がされていましたが、呼びかけがattendee listで行
われる程度で、プレナリでの報告も特段されないのが残念でしたが、今回の実
験については、Webサイト(*7)が開設されていました。実験結果は、それぞれ
のWGでの活動として実を結んでいるようです。

(*7)http://geopriv.googlepages.com/

次回のIETF73は、2008年11月16日から11月21日まで、北米に戻って、ミネアポ
リスにて、Google社のメインホストで開催されます。すでに、会議の参加登録、
ホテルの受け付けなどがスタートしたというアナウンスがありました。

     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【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.571 【臨時号】

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