連載 / lPv6 の実装ー① 図 7 要請マルチキャスト・アドレスの計算例 2 0 01 : 0 2 0 0 : 0 0 0 0 : 0 0 0 0 : fedc : ba9 8 : 7 6 5 4 : 3 210 リンクローカル・マルチキャスト 96 ~ 104 ビットはすべて 1 ↓下位 24 ビットをコピー 図 8 要請マルチキャスト・アドレスへの変換 526 527 528 529 530 531 532 533 534 535 536 dst—sa. sin6—addr. s6—addr16[O] dst—sa. sin6-addr. s6-addr16[1] dst—sa. sin6—addr. s6—addr32 [ 1 ] dst—sa. sin6—addr. s6—addr32 [ 2 ] dst—sa. sin6—addr. s6—addr32 [ 3 ] dst—sa. sin6—addr. s6-addr8[12] IPV6_ADDR_INT16_MLL ; IPV6_ADDR_INT32_ONE; taddr6—>sin6—addr. s6—addr32 [ 3 ] ; Oxf f ; if (in6—addr2zoneid(ifp , &dst—sa. sin6—addr, &dst—sa. sin6—scope—id)) { goto bad ; in6—embedscope (&dst-sa. sin6-addr , &dst—sa) ; / * XXX * / 簡単な変換で求めることかできます。変換の手順を石忍し ておきましよう。 1. 要請マルチキャスト・アドレスの舸立 24 ビットは、も 2.96 ~ 104 ヒ、ツトはすべて 1 との IP アドレスと同し そして、 538 行目で IP バケットのヘッダに終点アドレ ます。 図 8 の 526 ~ 531 行目では、上記の変換を実行してい スを言 1 算すると、図 7 のようになります。 10 という IP アドレスから要請マルチキャスト・アドレ たとえば、 2001 : 0200 : 0000 : 0000 : fedc : ba98 : 7654 : 32 スト・アドレス 3.1 、 2 を満たすリンクローカル・スコープのマノレチキャ 538 ip6->ip6-dst 537 } スを言聢します。 539 ~ 610 行目では、始点アドレスの尺処理をおこな dst_sa. sin6_addr ・ UNIX MAGAZINE 2002.6 要請バケットの始点アドレスは、次の規則て決まります。 まず、重複アドレス検出ではない場合の処理てす。近隣 539 if ( !dad) { 合に分けられます。 います。これは、重複アドレス検出の場合とそれ以外の場 送イ蔀寺ちの状態の IP バケットがあれは、そのバケット の始点アドレスを利用する。 ・そうでなけれは、近隣要請バケットの終点アドレスに もっとも適したアドレスを利用する。 フヾ 558 559 562 563 564 560 、な処理は以下のとおりです。 if ( 1 Ⅱ & & 1 Ⅱー > ln ー hold ) { hip6 = mt0d ( ln ー > 1 Ⅱー hold , struct ip6—hdr * ) ; if (ip6-getpktaddrs (ln—>ln—hold , &hsrc , NULL) ) if (hsrc & & in6ifa-ifpwithaddr(ifp, &hsrc—>sin6-addr) ) *hsrc ; src_sa 1 Ⅱは、の呼出し時に引数として渡さ れた近隣キャッシュの情報です。近隣キャッシュには、送 信待ちになっている IPzs ケットの情報かオ褓内されている ことがあります。このような IP バケットがあれば、その 始点アドレスを近隣要請バケットの始点アドレスとして利 用します。 送信待ちになっている IP バケットの始点アドレスが 利用できないときは、 in6-seIectsrc() で始点アドレスを 決定します ( 図 9 ) 。 in6seIectsrc() は、引数で渡された sockaddrän6 構造体のアドレスを終点アドレスとした場 71

連載 / IPv6 の実装ー① icmp6. h 254 struct nd_neighbor_solicit 255 256 struct icmp6—bdr struct in6_addr —target ; 言周査」・象 - nd ns_hdr ; nd_ns 近隣要請バケットは、 ICMP ヘッダの後ろに 495 if (daddr6 = = NULL Ⅱ ドレス宛に近隣要請バケットを送イ言する必要があります。 スカ喇明していない場合、最初は要請マルチキャスト・ア される場合の処理です。通イ目手のデータリンク層アドレ 495 ~ 500 行目は、近隣要請バケットがマルチキャスト す。 MGETHDR() で送イヤヾケット用の mbuf を石呆しま 455 MGETHDR (m , M_DONTWA I T , MT_DATA ) ; のビット操作で大きさを 8 の倍数に揃えています。 オクテット境界のアラインメントが必要なので、 445 行目 せています。近ド蝌架索バケットのオプションは、すべて 8 layer Address) オプションを追加するための余裕をもた 通知するため、送信元リンク層アドレス (Source Link- ンク層アドレスを、近隣要請バケットを受信したノードに 行目では、近隣要請バケットを送信したノードのデータリ さらに、必要に応じてオプションが追加されます。 445 ifp—>if—addrlen + 7 ) & ~ 7 ; 445 maxlen + = (sizeof (struct nd—opt—hdr) 十 の IP アドレスをオ褓内する領域か読きます ( 256 行目 ) 。 IN6_IS_ADDR_MULTICAST (&daddr6—> ルータを j 面過する際に 1 すっ減らされるので、受信したと きに 255 以外のホップリミットが設定されていれば、他 のリンクから不正に送られてきた近謝架索バケットである と判断できるわけです。 502 icmp61en = sizeof(*nd—ns) ; 503 m—>m-pkthdr. len = m—>m—len sizeof(*ip6) + icmp61en; icmp61en には、名前のとおり ICMP バケットのサイ ズが入ります。 502 行目で近隣要請バケットに最 f 邸具必要 な長さを設定し、オプションに応して長さをしていき ます。 507 行目から近ド蝌架索バケットの構築か始まります。 507 508 509 510 512 513 mtod(m , struct ip6—hdr * ) ; ip6—>ip6—fIow = 0 ; ip6->ip6—vfc & = -IPV6—VERSION_MASK ; ip6->ip6—vfc ー = IPV6—VERSION ; ip6—>ip6—nxt = IPPROTO—ICMPV6 ; ip6—>ip6-h1im = 255 ; ip6 507 ~ 513 行目で、基本的な IP ヘッダのフィールドを 埋めています。近隣要請がユニキャストされるときも、マ ルチキャストされる場合と同様にホップリミットを 255 に設定する必要があります。 496 497 498 499 500 } sin6-addr) ) { m—>m—flags ー = M—MCAST ; im60. im60—muIticast—ifp im60. im60_mu1ticast_h1im = 255 ; im60. im60_mu1ticast—100p = 0 ; ifp; 515 516 517 518 519 520 bzero(&src—sa, sizeof (src—sa) ) ; bzero(&dst—sa, sizeof (dst—sa) ) ; src—sa. sin6—fami1y =dst—sa. sin6—fami1y AF_INET6 ; src_sa. sin6_Ien =dst_sa. sin6_Ien sizeof (struct sockaddr—in6) ; if (daddr6) dst_sa = *daddr6 ; 496 行目で、 mbuf がマルチキャスト・バケットを含む ことを示すフラグを設定します。 497 ~ 499 行目はマルチ キャスト・オプションの設定です。前回説明したとおり、 このオプションは ip6-output() の呼出し時に引数て渡さ れます。 498 行目のホップリミットの設定は重要です。近窮架索 はリンク内て元結するプロトコルです。他のリンクから近 ド架索を装ったバケットか送信されることを防ぐため、す べての近ド架索バケットは 255 のホップリミットをもた なけれはならないことになっています。ホップリミットは 70 nd6-ns-output() の呼出し側で IP バケットの終点ア ドレスを指定していれば、 daddr6 に値か設定されていま す。この場合には、指定されたアドレスを終点アドレスと して設定します。 525 else { そうでなければ、データリンク層アドレスの検索対象 となっているアドレス (taddr6) から要請マルチキャス ト・アドレスを引算し、それを終点アドレスとして設定し ます。 2001 年 11 月号で解説したとおり、 IP アドレスが分 かっていれば、対応する要請マルチキャスト・アドレスは UNIX MAGAZINE 2002.6

USENIX 2001 AnnuaI TechnicaI Conference かぎらない。そのため、制限されたタグの変イ t) 杉の覧を 作ると、実行されてしまう可能生がある。 最終的な解決策は、アプリケーションの境界を越えて OS レベルてイすることである。ューザーの生産生を高 めるためには、もっとも低い 4 雀のみを付与しなけれはな らない。よりレベルの高い牛讚雀を得るには、 sudo などの アプリケーションを使う。 プロトコルの言十における定説、過失、信仰 Radia PerIman (Sun Microsystems 研プむ万 ) ( 報告 : Kenneth G. Yocum) Dr. PerIman は、神聖不可侵な存在に批判の矢を放 っと宣言した。これを聴いた会場は不安げにざわめいた。 Perlman はいくつかのガイドラインについて述べた。失 敗から学び、同し過ちを繰り返さす、失敗を恐れないこと である。 Perlman は現在の状況にいたる道のりを説明し ようとし、「プリッジ、ルータ、スイッチ」と言って驚き を表した。人びとはそれらの違いを知っていると思いこん でいるが、じつは知らないことが多く、 こうした用語を混 同して使っているからだ。 続いて、 ISO OSI 参照モテルを簡単に説明した。レイ ヤ 1 は物理層、レイヤ 2 は ( 隣どうしを結ふ、 ) リンク、 レイヤ 3 は複数のホップにまたがる通信、レイヤ 4 は TCP 、レイヤ 5 以 E はもううんざり。会場は笑いに包ま れた。続いて、 Perlman はプリッジとルータの混同に焦点 を当てた。ホップカウントをそのままにする lnfiniband には泣かされる。 Ethernet がすべてをごちゃませにする うえ、最終的な送信先のほかに、次のホッフ。アドレスが必 要になるとは。したがって、レイヤ 2 の送信先 / 送信元は ホップごとに変化するが、レイヤ 3 は変わらない。その ため、ルーティング・アルゴリズムを考えなおさなけ川ま ならない。 Perlman は、プリッジはルータよりも前に考えだされ たという定説をくつがえした。レイヤ 3 は Ethernet に 取って代わられたと考え、レイヤ 3 を無視してその上に プロトコルを作った人びとがいた。 Perlman の上司は 2 つの Ethernet のあいだにマジックポックスが必要だと いうが、 PerIman は必要なのはルータだとして譲らない。 両者の話し合いはまとまらす、レイヤ 3 なしですまそう とした結果、プリッジが生まれたのである。プリッジは、 146 すべてを聞きとり、反対側に転送する箱である。これによ り、 Ethernet を物理的に拡大することが可能になったが、 ルーフ。のないトボロジーが必要である。ホップカウントが ないと、トボロジーのループは悪夢と化す。幾何級数的な 増加という悪夢に。ルータなら、 1 つのバケットは 1 つの ままだ。プリッジのせいで、バケットは複数のリンクに複 製さ不協和音を奏でる。鮹夬策 ? 一部のリンクをオフ にするのか賢いカ 1 去である。 Perlman は賢明にも、スパ ニングッリー・アルゴリズムを開発した。 Perlman はそ れを詩に詠んだ。とても架く、かっ溺稽で、会場からは 笑いか起こった。 Perlman はルータの話を締めくくり、 IP マルチキャ ストの話題に移った。なぜこれほど複雑でなければならな かったのかと自間し、そこまで複雑にする必要はなかった のだと自答した。 ATM は point-to-multipoint の VC (Virtual Circuit) をもつ。 VC には送信先を追加するこ とができる。 IP 業界の関係者は、ルート (root) ではなく メンバーから結合を開始させたいと考えている。それもい いだろう。ルートにメッセージを送ろう。 IP マルチキャスト API の設言原理は Ethernet の ようなもので、レイヤ 3 の上のマルチキャストは、レイ ヤ 2 (Ethernet) 上にあるマルチキャストのように見え なければならない。だが、それを効率よくおこなう方法 はない。アドレスの割当ては悪夢である。 Perlman は、 DVMRP 、 PIM-Dense モード、 MOSPF 、 MSDP 、コ アベースのツリー (CBT) など、さまざまな技術を挙げ、 何か尚題なのかを説明した。そして、 8 バイトのアドレス を提案した。ツリーのルートは本質的な部分であり、ルー ト刎甫はない。ルートを選択し、ルートにアドレスを問 い合わせる (root, G)O そうすれば、アドレスの管理はと るに足らない間題である。ルータはルートを簡単に突き止 められるし、アドレスは豊富にある。「ソフトウェアの設 計には 2 通りのガ去がある。 1 つは欠陥がないようにシン プルにすることで、もう 1 つは欠陥がすぐに分からないよ うに複雑にすることだ」という Hoare の言葉が引用され た。この引用はしつに適切なものだった。 Perlman は次 に IPv6 に話題を移した。 Perlman は CLNP の消滅を不思議に思っている。 CLNP は IP と似ていたが、ともかくアドレスの数が多 かった。 IETF がいうには、 IP を ISO と置き換えるこ UNIX MAGAZINE 2002.6

連載 / 旧 v6 の実装ー① データリンク層バケットの出力 カルーチンに至るまでの処理の流れは、以下のようになり IP バケットの出力ルーチンから各データリンク層の出 じて個別に実装しています。 タリンク層アドレスの解決処理もデータリンクの不頁に応 を共通化することが可能になりました。 IPv4 では、デー リンク層アドレスの解決方法か統一されたため、この部分 層の出力ルーチンを呼び出すのですが、 IPv6 ではデータ 最糸勺には、近謝架索の出力ルーチンも各データリンク れた出力ルーチンを個別に呼び出す実装となっています。 れに対し、 IPv4 では、データリンクの不頁ごとに用意さ ーチンである nd6-output() を経由して送信されます。 ではすべての IP'S ケットが、近架索スタックの出力ル ク層アドレスの発見です。前回解説したとおり、 KAME 近ド架索の目的は、 IP アドレスに対応するデータリン 1. 次ノードの石忍 ます。 近隣探索スタックの出力ルーチンは nd6-output() で 次ノードの確認 3. データリンク層出力ルーチンの呼出し 2. 近隣キャッシュの伏軋寉認・更新 す。この関数は 5 つの引数をもちます。 m() は出力される IP バケットです。 dst には、次の中点となるノードのアドレスが入りま す。経路制徊ヘッダカ甘旨定されてい川ま、 dst は経路缶衂 ヘッダで指定された次ノードのアドレスに、指定されてい ない場合は単純に IP バケットの終点アドレスになります。 rt0 は dst , 、、の経路報です。 近謝架索プロトコルは ICMP を利用して実現されてい ます。近ド架索は、 IP で涌信するためには必頭です。し かし、 ICMP は IP の上位プロトコルとして : 見されてい ます。どちらが先かという鶏と卵の問題のようですが、 の連鎖を断ち切るのが 2 , 082 行目の処理てす。 2 , 082 行目 では、宛先アドレスがマルチキャストの場合に、近ド蝌架索 の手順を飛ひ越えてバケットを出力します。 2082 if (IN6-IS-ADDR MULTICAST(&dst—> 2083 sin6—addr) ) goto sendpkt ; 2062 2063 2064 2065 2066 2067 2068 2069 int nd6—output (ifp , struct struct struct struct st ruct origifp, mO, dst, て tO ) ifnet *ifp; ifnet *origifp; mbuf *mO ; sockaddr_in6 *dst ; rtentry *rtO; 2001 年 11 月号で解説したとおり、通イ目手のデータ リンク層アドレスを得るには、まず近隣要請を送信しなけ れはなりません。近隣要請は、通信したい相手ノードのア ドレスに対応する要請マルチキャスト・アドレスに対して 送信されます。 IP スタックからみれは、要請マルチキャ スト・アドレスはたんなるマルチキャスト・アドレスで すから、 2 , 082 行目の条件に従って即座にデータリンクに 出力されます。近隣要請を受信したノードは、近隣要請を 送ってきたノードに近隣通知を返信して、自分のデータリ ンク層アドレスを通知します。 近隣要請の送信と近隣通知の受信処理についてはあとで 角見することにして、こではバケットの出力処理の続き をみていきましよう。 2085 if (nd6—need—cache(ifp) = 0 ) 2086 goto sendpkt ; ifp と origifp は、出力先のアドレスに対応するインタ ーフェイスへのポインタです。この 2 つの違いは、自分自 身にループバックするときに意味をもちます。たとえは、 自分自身の Ethernet インターフェイスに出力する場合、 論理的な出力インターフェイスは Ethernet インターフェ イスですが、実際にはルーフ。バック・インターフェイスに 出力することになります。その際に、 ifp がループバック・ インターフェイスを指し、 origifp が Ethernet インター フェイスを指します。 64 nd6-need-cache() は、引数で指定されたネットワー ク・インターフェイスで近架索が必要かどうかを判断し ます。たとえは、ループバック・インターフェイスなど はそもそもデータリンク層アドレスをもたないため、近隣 探索をする必要がありません。そのような場合は、即座に バケットの出力を開始します。 if (rt) { 2091 2092 if ( (rt->rt—flags & RTF UP) UNIX MAGAZINE 2002.6

連載 / IPv6 の実装ー① 図 5 nd6-ns-output() の定義 385 void 386 nd6—ns—output (ifp , daddrO , taddr0, 1 Ⅱ , dad) 387 388 389 390 391 { struct ifnet *ifp; const struct sockaddr_in6 *daddr0 , *taddrO ; struct 11info—nd6 *1n; / * for source address determination * / int dad; / * duplicated address detection * / 図 6 ゾーンリ砌言聢 419 420 421 422 423 424 426 427 428 429 430 431 433 434 daddr6 = &daddr6_storage ; taddr6 = &taddr6-storage ; if (daddr の { * daddr6 = * daddrO ; if (in6—addr2zoneid(ifp , &daddr6—>sin6—addr , &daddr6—>sin6—scope—id) ) { return ・ } else daddr6 = NULL ; *taddr6 = *taddrO ; if (in6—addr2zoneid(ifp , &taddr6—>sin6_addr, 近隣要請バケットの構築 UNIX MAGAZINE 2002.6 指定します。 Detection) を実行するための近隣要請を送信する場合に 最後の dad は、重複アドレス検出 (Duplicate Address ln は、 taddrO に対応する近隣キャッシュを指します。 ます。 カま走わしい場合は近隣要請バケットを送信することがあり ため、データリンク層アドレスカ喇明していても、到達性 層アドレスの解決以外にノードの到達不能十鎹ロもおこなう のかと思うかもしれません。近ド蝌架索では、データリンク レスカ明しているのに、近隣要請を送信する必要がある をマルチキャストする場合などです。データリンク層アド リンク層アドレスがキャッシュされていたり、近隣要請 できません。たとえば、すでに近隣キャッシュにデータ するデータリンク層アドレスか判明しているときしカ甘旨定 daddrO は、この引数て指定される IP アドレスに対応 レス、 taddrO は角夬したい IP アドレスです。 イスを指します。 daddr0 は近隣要請バケットの終点アド ifp は近隣要請を出力するネットワーク・インターフェ nd6-ns-output() は 5 つの引数をもちます ( 図 5 ) 。 &taddr6—>sin6—scope—id) ) { ます、 sockaddr-in6 構造体で指定された daddr0 と taddr0 のゾーン識別子を設定します。もとのアドレス 情報を破壊しないように、それぞれ daddr6-storage と taddr6-storage という auto 変数を用意し、そこに孑日疋 されたデータをコピーしています ( 図 6 ) 。 if (IN6_IS_ADDR_MULTICAST (&taddr6-> 440 441 sin6-addr) ) return; マルチキャスト・アドレスに対応するデータリンク層ア ドレスを調べるために近隣要請する必要はありません。 IP アドレスを変換するだけで、簡単にデータリンク層アドレ スを引算することができます。 444 ~ 465 行目では、近ド蝌架索バケットのための mbuf を用意します。 444 maxlen = sizeof ( * 土 p6 ) + sizeof(*nd—ns) ; maxlen には近隣要請バケットの全体長を設定します。 近隣探索バケットは、基本的に IP ヘッダと近隣探索パ ケットのヘッダ (ICMP ヘッダと近隣要請のヘッ夘か ら構成されます。近隣探索 , 、、ツダは、 icmp6. h で以下の ように定義されています。 69

図 10 734 735 736 737 649 650 651 652 658 連載 / IPv6 の実装ー① フラグ情報の抽出 1S_override ( (flags & ND—NA—FLAG_OVERRIDE) ! = 0 ) ; is—solicited = ( (flags & ND—NA—FLAG—SOLICITED) ! = 0 ) ; 1S_router ( (flags & ND—NA-FLAG_ROUTER) ! = 0 ) ; flags = nd—na—>nd—na—flags—reserved; ip6—>ip6—p1en = htons ( (u—short) icmp61en) ; nd—ns—>nd_ns_cksum = 0 ; nd_ns—>nd_ns_cksum in6—cksum(), IPPROTO—ICMPV6 , sizeof(*ip6) , icmp61en) ; ip6—output (m , NULL, &ro , dad ? IPV6_UNSPECSRC &im60 , NULL) ; icmp61en には ICMP バケットの長さかオ褓内されていま ます、ホップリミットをチェックします。 711 if (ip6—>ip6-h1im ! = 255 ) { す。 712 713 714 } goto bad; 近隣要請を送信すると、応答として近隣通知が医され てきます。近隣通知バケットには近隣通知を送信してきた ノードのデータリンク層アドレスが含まれているので、こ の情報を調べれは IP アドレスとデータリンク層アドレス を関連つ、けることができます。近隣通矢ロの受信処理は、以 651 ~ 652 行目で ICMP のチェックサムを計算し、 658 行目で送信します。重複アドレス検出の場合は、第 4 引数 で IPV6-UNSPECSRC を指定しています。このフラグ を指定しないと、 ip6-output() は始点アドレスが未定義 であるバケットをエラーとみなします。 近知の鄧言里 近虧甬知バケットの正当性チェック 4. 送イ寺ち IP?S ケットの送信 3. 近隣キャッシュの状態遷移 2. オプション処理 1. 近隣通知バケットの正当性チェック 下のような流れになります。 687 nd6—na—input (), off , icmp61en) 686 void put() を経由して呼び出されます。 icmp6 -in- おこなう nd6-na-input() は、 ip6-input() 、 近隣通知は ICMP の一種です。近隣通知の受信処理を 255 以外の値をもつバケットを破棄することで、他の リンクから近ド爾臻を装って送信されたバケットを除外し ます。 734 ~ 737 行目 ( 図 10 ) では近隣通知バケットからフラ ク 1 辭にを取り出しています。 is-router は、近隣通知を送っ てきたノードがルータであることを意味します。 is-solic- ited は、この近隣通知が近隣要請への応答として送信さ れたものであることを示します。近隣通知は、近隣要請ハ ケットを受信したとき以外にも、リンク上のすべてのノー ドに自分の存在を知らせる目的てマルチキャストされるこ とがあります。 is-override は、近隣キャッシュの情報を 明カ勺に上書きしたい場合に指定されます。 754 if (is—solicited & & IN6—IS—ADDR—MULTICAST 757 (&ip6->ip6-dst) ) { goto bad; 688 689 struct mbuf *m; int off , icmp61en; m には受信しオ丘隣通知バケットが、。仕には IP ヘッ ダの先頭から一 ICMP ヘッダの知頁までのオフセットが、 UNIX MAGAZINE 2002.6 近隣要請を受けて近隣通知する場合 (is-solicited が設 定されている場は、マルチキャストしてはいけません。 オプション里 近隣通知バケット構造体は icmp6. h で定義されていま す ( 図 11 ) 。 nd-na-target には、近隣要請て指定された IP アドレ スかオ絲勺されます。この構造体の後ろには、データリンク 層アドレスかオ勺されたオプションか読きます。近隣通知 では、近隣要請で要求された IP アドレスに対するデー タリンク層を示すターゲットリンク層アドレス (Target Link-layer Address) オプションと、近隣通知を送信し たノード自身のデータリンク層アドレスを示す送信元リン 758 } 73

NEWS ・ Cisco 処理能力を強化した Cata ⅳ st 4000 シスコシステムズは、マルチレイヤ・ス スト ) などを備える。ルーティング・プロ イッチ「 Cisco Catalyst 4006 Supervi- トコルは、 BGP4 、 OSPF 、 EIGRP など。 sor Engine III 」の販売を開始した。 バックプレーン性能は 64Gbps 、フォワー タ些里工ンジン・モジューノレ Supervisor ディング性能 ( レイヤ 2 / 3 / 4 ) はいすれも Engine III を用いた、、 Catalyst 4000 クフ ファミリー用のすべての I / F モジュール 48Mpps 、ノレーティング・テープルのエン ァミリーの新モデル。他の Catalyst ファ をサポート。 トリ数は 131 , 072 。 ミリーと操作を共通化した Supervisor 外形 - 覗去 (H XWXD) は 40 X 43.7X30 I/F は、 Supervisor Engine III モジュ IOS 、コアルータ Cisco 12016 GSR でも ールがアップリンク (GBIC)x20 同時発 cm 、重量は最大 24kgo 使われているフォワーディング機能 CEF 価格は 365 万 5 , 000 円 ( 6 スロットの 表の「 WS ー X4448 ー GB ー RJ45 」 ( 10 / 100 / (Cisco Express Forwarding) 、ハ 1000Base T ( オート・ネゴシェーショ Catalyst 4006 シャーシ、 Supervisor En- ウェア化されたインテリジェント・サービ gine III モジュール、 AC 電源 x2 ) から。 ン ) X48 ) 、「同 GB—LX 」 (1000Base LX ス機能 ( セキュリティ、 QoS 、マルチキャ (SFP) x 48 ) のはか、既存の Catalyst 4000 http://www.cisco.com/jp/o セスを高速化する。 DAFS プロトコル (IETF で標準化作業中 ) は、 OS として NetApp ONTAP 6.2 を使用するファイ ラー、、 NetApp F800 シリーズ〃てサポー トされる。 1 ・ Network AppIiance DAFS 対応ストレージ 米 Network AppIiance は、 DAFS した。 Gigabit Ethernet と NetApp ファイ (Direct Access Fi le System) 対応のス ラーを使用し、 DAFS と仮想ネットワー トレージ・システム「 NetApp DAFS Database AcceIerator 」の販売を開始 ク I / F を用いてデータベースへのアク •AgiIent TechnoIogies ケーフルテスター兼用ネットワーク・アナライサ 接続性 ( IP アドレス、 MAC アドレス、サ アジレント・テクノロジー (Tel 0120 ー プネットマスクなど ) とネットワーク性能 421345 ) は、企業ネットワーク用のネッ (MAC ループバック、各種サーバーから トワークノヾフォーマンス・アナライザ のファイルのダウンロード時間、回線使用 はか、カテゴリー 6 / ISO クラス E のケー 「 AgiIent N2610A フレームスコープ プルに対応 ( オプションでマルチモード / 率、プロードキャスト、マルチキャスト、 350 」の販売を開始した。 シングルモード光ファイバーにも対応 ) 。 工ラーなど ) を監視する機能を追加。対応 「 Agi lent ワ 既存のケープルテスター ネットワーク・プロトコルは、 IP 、 IPX 、 価格は 118 万 6 , 000 円。 イヤスコープ 350 」の機能に、サーバーや NetBIOS0 10Base T/100Base TX の ルータなどのネットワーク・デバイスの •Sun ミッドレンジのストレージ サン・マイクロシステムズ (TeI 03 ー 始した。 36GB または 73GB のデュアルポート ミッドレンジ・クラスの 5717 ー 5033 ) は、 ストーレジ製品•sun StorEdge 3900 ク FC—AL HD ( 10 , 000rpm ) を 190.5 X60.7 ーー。 = ジサズ = = 第同一 6900 の一 - シーリズの販売を開 x 94cm (H x W x D) のキャピネットに 21 UNIX MAGAZINE 2002.6

TAKAOKA ダウンロ - ド製 Windows サ - パ・クライアントシステム VirtuaI mage ロ istributor シンクライアントの TAKAOKA から Windows@/Linux 対応叫 テムが登場 ! に ロ isk 厄 ss クライアントシ ロ「 ネ、、トワク 5 第 M50 物 0 0 宿に ) びしし 専用クライアント MiNTPC ridott02 管理が容易で無駄な費用、手間のかからない システム構築、運用が可能 ・クライアントの OS 、環境設定、アプリケーションなどはローカルディス クに持ちません。 ・サーバ上のイメージを更新するだけなので、アプリケーションのインス トール、アンインストール、バージョンアップが簡単です。 テュアルプート可能 ・ Windows@2000 と Linux のネットプートが可能です。 ローカルハードティスクを持たない 専用クライアント「 MiNTPC 「 idott02 」 ・ローカルにハードディスクを持たないため、極めて低い障害発生率を実 現しました。 ・オプションの HDD を追加し管理用マスタ PC として使用できます。 VID に関するお問い合わせは下記まで。 容易で柔軟な管理 ・ソフトウェアの一元管理・優れた拡張性とセキュリティ ・自由度の高いシステム構築 ネットワークプート ・ Intel@"Preboot eXecution Environment(PXE)" 技術による ネットワークプート ・ Wakeup On LAN ( WOL ) とマルチキャスト配信 ・スーバー・エンハンス・ライトフィルタ Ⅵ D システム構成 アプリケーションサーバ / DHCP サーバ ・サーバ MiNTPC 「 idott02 十オプション HDD ・管理用マスター PC ・ソフトウェア . agile VID ・専用クライアント .. MiNTPC ridott02 ※会社名・製品名などの固有名言司は、一般に該当する会社もしくは組織の登録商標または商標です。 〒 101 -0064 東京都千代田区猿楽町 2-1 -11 東燃神田ヒル TEL. 03-3292-6543 代 / FAX. 03-3292-6588 http://www.takaoka. CO. jp/system/ e-mail :system@sp.takaoka. CO. jp ・中部支社 : TEL. 052-582-9571 代 / FAX. 052-583-8418 ・関西支社 : TEL. 06-6344-5331 代 / FAX. 06-6341-0958 ・九州支社 : TEL. 092-781-3468 代 / FAX. 092-731-3040 システム・ソリューションカンニ 株式会社高岳製作所

日 FC ダイジェストー RFC3275 は、 XML 署名の生成およひ表現に関する処 ミドルポックス " の分類と関連する言侖の整理をおこな 理規則と去を定義している。 RFC3075 からの変点を っている。、、広報 " として 2002 年 2 月に公開された。 以下に示す。 ミドルポックスとは、一イ殳のオ剽純勺な IP ルータ以外で インターネットのデータ糸響各一トに配置されるエンティティ ・ DSA 鍵表現の変更 ( 下位互換性なし ) のことである。定義から分かるように、 ミドルポックスは ・ X509Data の KeyInfo 構造体で複数の CRL をもて きわめて広範囲の要素を指づ念であり、 IETF などで共 るように変皿これにより、署名と他の X509 情報を 通した言墟侖をおこなうためにはなんらかの分類が必要であ まとめて扱えるようになった る。そこで RFC3234 では、一ヨ殳にミドルポックスと考 ・ PGPKeyID 型を文字列型から Base64Binary 型に変 えられる要素を分類したうえで、言侖における論点を提示 更 ( 下位換性なし ) している。 警告を追加 嬲里する IETF のう斗会としては以下のものがある。 WebDAV 関連 ・ MIDCOM RFC3253 Versioning Extensions to WebDAV (Web ・ WEBI Distributed Authoring and Versioning) ・ OPES WebDAV 用パージョニング拡張 ・ CDI PS. 、 G. Clemm 他 ・ RSERPOOL HTTP/I.1 を才長した WebDAV (Distributed Au- RFC3234 でとりあげられたミドルポックスを以下に thoring and Versioning) におけるノヾージョン管理機能 用のメソッド、ヘッ久リソース型のイ兼を定義している。 現在の状態は、、標準化への提唱 " である。 2002 年 3 月に 公開された。 従来、 Web コンテンツの作成や管理には FTP や CVS などのプロトコルや技術が用いられ、 Web 環境の管理は 複雑化する傾向にあった。一方、 HTTP は当初はコンテ ンツの取得を目的としたプロトコルであったが、 Web 環 境の世界的かっ爆発的な成長にともないさまざまな機能が 追加されてきた。 RFC2291 および RFC2518 で提案されている Web- DAV は、 HTTP による遠隔からのコンテンツ作成と管 理を可能にするための拡張である。 WebDAV を利用する ことで、 HTTP を用いた糸舌的な Web コンテンツ作成 や管理が可能になる。 RFC3253 では、 WebDAV でコンテンツのノヾージョン を管理するためのメソッド、ヘッダ、リソース型の負嶽を 定義している。 ・ NAT ・ NAT-PT ・ SOCKS ゲートウェイ ・ IP トンネル端点 ・バケットの分類器 / マーカ / スケジュ ーフ ・トランスポート層リレー ・ TCP 性能矼 E フ。ロキシー ・ロードバランサー ( バケット /URL) ・ IP ファイアウォール アプリケーション・ファイアウォール アプリケーションレベル・ゲートウェイ ゲートキーパー / セッション制御装置 アプリケーション層変換器 (Transcoder) プロキシー キャッシュ ・ DNS サーノヾー ( 機育去張型 ) ・コンテンツ / アプリケーション配布欟冓 アプリケーション・レベルの横取り (interceptor) アプリケーション・レベルのマルチキャスト 反身勺バケット・リダイレクション . アノニマイサー (Anonymiscr そ也 RFC3234 Middleboxes: Taxonomy and lssues ミドルポックス分類法と論点 旧 fo. 、一一 B, Carpenter 他 157 UNIX MAGAZINE 2002.6

ワークステーションのおと一 O 写真 4 レガシーポートはまったくない 写真 2 マルチボート ルも使えるようになるそうです。 2 のマルチベイも Evo Notebook と共通で、これに対 応する DVD-ROM ドライプやハードディスクを取り付 けることかできます。マルチベイは、 IBM の ThinkPad シリーズで使われているウルトラベイ 2000 とはは伺し機 構です。残念ながら、両者のあいだに互換性はありません。 メーカーの垣根を越えて、長のための共通の規格を採用 表 1 に記したように、高さと奧行きはそれぞオ勺 30cm してくれれば嬉しいのですが・・ ()4 判用紙の長辺とはは 1 司じ ) です。幅は約 7cm で、ち 3 の USB 対器の接続のために、 USB ポートカ嘴 ようど UNIX MAGAZINE を 7 ~ 8 冊重ねた場合の厚 面に 4 つ、前面に 1 つ用意されています。標準の状態で みと同しです。たいへんコンパクトにまとまっていて、付 は、お馴染みの PS/2 やシリアルポート、パラレルポート 属従置き台を使え ( に魔にもなりません。シリーズ名に などの、いわゆるレガシーな拡張ポートはまったくありま US (UItra SIim) と付けただけのことはあります。 せん ( 写真 4 ) 。さすがに、これでは不便かもしれないと考 ただし、小さくしたぶん刻長生か生になっていて、ハ えたのか、オプションの、、レガシー・モジュール " を取り ードディスクなどの記應装置や PCI カードは増やせませ 付けると、 PS/2 ( x2 ) 、シリアルポート ( xl ) 、パラレル ん。できるのは、次のようなことだけです。 ポート ( xl ) カ俐用できるようになります。 1. マルチボート ( 写真 2 ) への対器の取付け 2. マルチベイに入っている CD-ROM ドライプ ( 写真 3 ) の CD-RW ドライプなどとの交換 分解といっても、通常の保守竹業程度であれは、とくに 3. USB 対饑器の接続 工具を使うことはありません。必要になるのは、ハードデ イスクを交換するときくらいでしよう。その場合も、付属 1 の、、マルチボート " というのは、 Compaq のノート の小さなトルックス・ドライバーで用が足りるかもしれま PC のシリーズである Evo Notebook にもあるイ目みで、 せん。ただし、これはあまり使いやすくないので、 Com- ノート PC と共通のモジュールが使えるようになってい paq のデスクトップ PC やサーバーをたくさん利用して ます。いまのところは B ⅲ et 。。 th のモジュールしかあり いる人は、 T15 タイプのトルックス・ドライバーを購入 ませんが、・今彳変、無糸泉 LAN ( IEEE802.11b ) モジュー 写真 3 いざ分解 122 UNIX MAGAZIN E 2002.6