------------------------------------------------------------------------------- IPv6ops meeting - ユーザサイトonlyミーティング- date: 2001/08/02 18:30- @ pana.net 参加者 ふじもと＠NEC いしばし＠NEC 近藤＠IIJ 橘＠aniani.com 村上＠pana 細江＠pana 白橋＠NetOne 熊谷＠国際情報システム 猪俣＠富士通 島田＠pana 荒野＠gblx むかい＠OMP (敬称略) ------------------------------------------------------------------------------- まず、自己紹介 ------------------------------------------------------------------------------- ☆全体のsurvey サイトの種類 - 企業系 - イントラネット, include non-PC close net, iDC(借りる側の話) - コンシューマ系 - 家庭... 検討する分野 - ネットワーク系 - addressing, 構成, 経路制御 - IPv4 - DNS - アプリケーション - 提供モデル - セキュリティ - Firewall? tranparent NAT? - transition - 管理・運用 - 監視 - インターネット - renumberng - upstream変更 - ISP mergeなどなどで発生する - multihoming - アウトソーシング - VPN - intranet over the internet これらを企業系、コンシューマ系それぞれに格子状にみていく。 どのようなケースがあるかを考える。 検討するのは企業系の方が多いだろう 家電製品にアドレス振ったときの通信方法? 共通するL2的なものが問題になる。 とりあえず、企業系の話題をメインにやったほうがよいかもしれない。 コンシューマ系の話は、メンバを変えたほうがよい? 企業にアドレスを固定で配る。 コンシューマにはprefixで配る方がよい。 - これは別な議論を生むよねぇ - コンシューマはアドレスの議論なんてしないだろう。 - セキュリティの方が優先されるのかもしれない。 今日のゴール - 検討分野に対して、小項目を洗い出す。 - 次のアイディアにむけてのマイルストーン ------------------------------------------------------------------------------- 現状 セキュリティに対する項目はふえそう デュアルスタックでのセキュリティモデル IPSecでよい? - 企業の管理ポリシーとセキュリティポリシーは違うがある。 企業にとってなにがメリットがあるのかどうかがわからないといけない IPv6オンリーでサービスを提供するモデルが見えると なにが必要かどうかが見えてくる IPv4を使っているところにIPv6をいれようとすると、 新規の機器購入になってしまう。 検討をする対象にIPv6がはいっているのが現状 iDCをつくるときにはIPv6対応は必須になろうとしている。 追加のコストをできるだけ減らしておきたい リースもきれていないのに入れ換えるというのは難しい。 企業にIPv6をいれるのは前提 - IPv6のtransitionをやると、こうなるというのを検討できればよい - お金がどれだけ必要になるのかというベースを考えられればよいかな ------------------------------------------------------------------------------- 検討モデルの洗い出し - イントラネットをIPv6化 - upstreamをIPv6化する ------------------------------------------------------------------------------- ☆既存のイントラネットをIPv6にする場合 課題の洗い出し - どの範囲をIPv6化するか?どのタイミング? - DNS - 機器 - ルータ - L3SW - stack (single or dual) -> dualになるのはないか? - address (global or site local) - globalが使われるだろう - prefix - segmentでつかわれるprefix /64 - linkとして使われるpreifix /64 /127 link-local neighbor - link-localをつかって監視をする?しない? - loopbackは/128? /64? - EUI-64 - segment - router - server - 共用機器(printer) - EUI-64 vs DHCP6 - DNS discovery → これからの議論:( - plug and playは本当によいのか。 - 管理された機器だけをつなげさせたい - 認証と承認はちがうぜっ! by ino - セキュリティ IPv4の海の中をIPv6の島をtunnelでつなぐモデルがある。 ユーザのセグメントはデュアルスタックでいく - クローズネットワーク - クローズならグローバルアドレスはいらない? - サイトローカルアドレスならぶつかっちゃわない? - グローバルにつなぐときにこまるかなぁ ローソンとかはO(10^5)ぐらいの数を考えないといけない /48は使い果たす。 /48がO(10^5)ぐらいでてくる 銀行のATMはイントラネットで、数も半端じゃない SOHOがWANにつなぐ時の問題 企業の中でEUI-64をつかうのか? - アドレスをみて、ホストを特定できるとよい - ホストのリタンダントにつかうVRRPの時ってどうなのだろう - router renumberingしたときにさくっとかわれるとよい - default routerとかはRAをつかってしまう - trouble shootするときにどこのrouterを通るのかを特定するには決め打ちがよい - サーバは、DDNSつかってEUI-64をつかうのか? - plug and play問題 - RAを聞いてしまうとつなげられてしまう - RA extentionとか出来て管理をすることは可能になるのか routing - 企業によってはRIPngで十分 - OSPFをつかっている企業もある。 - 拠点数も重要 ------------------------------------------------------------------------------- ☆企業のセキュリティ問題 課題 - FireWall packet filterだけというのは(嘘)だー L7までみるやつ - end to end(IPSec) - IPSecをpermit or not? - 管理側はコントロールしたい - one of policy issues - contents filterをしたい管理者にとってはIPSecはイヤなもの - 802.11b問題 - なにもしないともれまくり - NAT - イントラ - インターネット - 部門間セキュリティ - application gateway - EUI-64 - プライバシー - セキュリティ 議論 IPv4だとプライベートアドレスがあるから守られているけど、 IPv6だとグローバル。どこに差があるだろう - その差が見えたほうがよい 社内でつかうアプリケーションが使うモノのほうがthe Internetでつかうモノより多い denyするよりpermitionをする機構の問題がある 移動をした際に、適切なリソースに対してアクセスが可能になるようなもの。 EUI-64がそのままthe Internetにでていくことの問題 - 個人の特定ができることの問題 エンタープライズでIPSecを許す、許さない、会社のポリシーとの問題 - policy的問題もある。 - policy問題をtechnicalで解決できる? IPSec - tranport , tunnel mode両方ある。 - IPv4で最近追加された機能はIPv6版ではまだ実装されていない 中央のポリシー、特別なポリシー、両方を充たすモノが必要 baseはIPsec、通信相手は固定にするというポリシーもある。 ------------------------------------------------------------------------------- ☆DNS 課題 - registration - ホスト情報のregist - ホスト情報の管理は必要。 - 逆引き問題 - EUI-64 議論 WINSサーバの検索のためにhostsをくばる例もある。 会社であたえたPCしかつなげないようにするとかもある。 - mac address filter peer to peer通信をするには、DNSは必須 - アドレスの直接入力は、IPv6では厳しいものがある 意外とDNSにregistする必要はないかもしれない。 - 一部のホストの情報は登録されるべき 逆引き問題もある ------------------------------------------------------------------------------- ☆v4 - v6通信をどうするのか(transition含む) - case by case 課題 - translator - dual stack 議論 業務系システムは移行できないかも IPv4 only dual stack - という端末ができるだろう。 IPv6だけというのはない。 アドレスをresolvして、v4/v6を選択して通信してしまえばよい 企業がつかっているアプリって、別にIPv6にする必要はない - web とmail gatewayだけIPv6対応すれば困らない IPv6のメリットを考えないといけないかもしれない タイミングをみながら考えた方がよい。 - いつ移行するのか。その時の機器のそろい具合とか。 業務系にはIPv4が残るかもしれない。 他はIPv6になる可能性とかIPv4は全くなくならないのかもしれない。 ------------------------------------------------------------------------------- ☆アプリケーション 課題->メリット(有利なもの) - Oracle(DB系) - 対応すればおしまい 必要となるもの - VoIP - multicastをつかってのデータの同期というのもあり。 議論 企業で必要となるアプリケーション IPv6を広めるために必要なアプリケーションをたくさんつくる? VoIPがIPv6になると何がよいのか メリット proposeモデルをつくるという感じ call manegerがsignalingだけの問題 - PBX的なもの。 - 内線の管理 - 外線もかけるから、その管理をどのようにするか? NATがないから通信できているかもしれない もっとメリットが必要 アドレスは変わるけど、電話番号は変わらない - call manegerが管理できていればよい。 - 個人の特定が重要 - 電話機の台数的には、IPv6のメリットがある。 - anycastでcall manegerをさがせる IP電話は便利になる。 - 設定が楽になる。 ユーザはどのようなアプリがほしいんだろう? 会社の業務を家にもっていったときに、どのようなアプリがあればよいのだろう? ------------------------------------------------------------------------------- ISPのサービスとしてどのような提供モデルがあればよいか? エンタープライズとして、SOHOとしてISPはどんな提供モデルを用意すればよいのか? という議論もある。 ------------------------------------------------------------------------------- ☆管理・運用・監視 大規模ネットワークのモデルを転用出来る。 - ISPのオペレーションスキルと、エンタープライズのスキルは違う - 人の数。 お手軽に、人をかけずにやるということが重要である。 - 基本は、ISPのオペレーション ------------------------------------------------------------------------------- ☆ゴール モデルをつくる? IPv6のモデルをつくる 案 articleをかく。 発表をする。 - IPv6 summitでセッションをもつ 発表の場として - IPv6 summit(年末) - 議論モード - チュートリアル(IW2001) - 一般向けモード -> 技術開発促進をできる。(ソフトウェア開発など) SIビジネスに直結してるけど、大丈夫? - 実現可能なSI屋はすくない。 これで本をだす! -> 情報は公開する。 - 11月には中間のまとめ - pick upした項目をまとめる - まずはセキュリティを中心に話す。 - 企業ネットワークを中心 ホームのIPv6の問題は、意識の高い人をよばないと無理。 時期をおくらせて、12月ぐらいからやる。 8月、9月、10月に議論 ipv6-opsの中に分科会的雰囲気でユーザサイトの話題をする chairは別にする。 小人数でやる。 議論を行うメーリングリスト - ipv6-biz@bugest.net ------------------------------------------------------------------------------- 8/16 18:30〜 pana.net ＠ 京橋 9/10 18:30〜 pana.net ＠ 京橋