2006年03月

このエントリーを含むブックマーク 2006年03月31日

昨日に引き続き、これも tech ML で流した IPv6 ネタですが...

KLab のイントラのサーバである kamiya で、

ping6 -I eth0 ff02::1

を実行してみると、20台程度のマシンが反応します。うち、半分くらいは、 私が IPv6 をインストールしたマシンだったりします。 Linux や WindowsXP は標準で IPv6 をサポートしてますし、 Windows2000 も IPv6 Technology Preview を使えば IPv6 が使えます。興味がある人は試してみては? 今まで鳴かず飛ばずだった IPv6 ですが、なんとなく いろいろ使えそうな予感がします。 いろいろな仕掛けを IPv6 へ移行中...

# ついでに言うと stone も、IPv6 をサポートしています

六本木LAN の kamiya からフツーに IP で、私の自宅サーバ asao.gcd.org へ ping を打って、

kamiya:/home/sengoku % ping -t 64 asao.gcd.org
PING asao.gcd.org (60.32.85.216) from 10.10.0.2 : 56(84) bytes of data.
64 bytes from gcd.org (60.32.85.216): icmp_seq=1 ttl=50 time=6.55 ms

asao.gcd.org 側で見ると、

asao.gcd.org:/root # tcpdump -v -i ppp0 icmp
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
09:34:55.115600 IP (tos 0x0, ttl  50, id 0, offset 0, flags [DF], length: 84) 161.90.128.210.bf.2iij.net > asaogw.gcd.org: icmp 64: echo request seq 256

64 に設定した ttl が 50 まで減っています。つまり 14 hop あるということ ですね。ping パケットは

六本木LAN → PPPoE (IPv6網) → IIJ (6 hop) ─┐
                                             ↓
                                           MFEED
                                             │
  自宅LAN ← PPPoE (IPv6網) ← OCN (7 hop) ←┘

と延々と旅をしてますし、しかも IPv6網は PPPoE でトンネリングして しまっているので、IPv6網での物理的な hop 数はカウントされていません。 実質的には合計で 20 〜 22 hop 程度はあると考えるべきでしょう。

一方 IPv6 で asao.gcd.org へ ping を打つと、

asao.gcd.org:/root # tcpdump -v -i br0 icmp6
tcpdump: WARNING: br0: no IPv4 address assigned
tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
09:37:10.664278 kamiya.v6.klab.org > asao.v6.gcd.org: icmp6: echo request seq 256 (len 64, hlim 60)

hlim が 60 までしか減ってません。つまりわずか 4 hop ですね。

六本木LAN → IPv6網 → 自宅LAN

しかも途中に PPPoE のような邪魔なものは入っていないので、 mtu は 1500 のままです。


このエントリーを含むブックマーク 2006年03月30日

一年以上前に tech ML で取り上げたネタなのですが、現在よく使われている Linux ディストリビューションでも glibc 2.3.2 あたりが使われることもある ようなので紹介します。


KLab のイントラのサーバには、IPv6 なアドレスも割り当ててあります。 例えば、

% host kamiya.v6.klab.org
kamiya.v6.klab.org has IPv6 address 2001:c90:c1c:100e:2e0:81ff:feab:cdef

% host 2001:c90:c1c:100e:2e0:81ff:feab:cdef
f.e.d.c.b.a.e.f.f.f.1.8.0.e.2.0.e.0.0.1.c.1.c.0.0.9.c.0.1.0.0.2.ip6.arpa domain name pointer kamiya.v6.klab.org.

のような感じ。kamiya というホスト名は KLab が六本木ヒルズへ移転してくる 前は、神谷町にオフィスがあったことにちなんでいます。イントラのサーバ群に は地名がつけられているマシンが多く、もちろん roppongi というホスト名の マシンもあります。

で、当時は Linux サーバの多くは glibc 2.2 を使っていたのですが、一部の マシンは glibc 2.3 にバージョンアップしていました。ところが、glibc 2.3 な マシンから ping6 を打ってみると異様に遅い...

% time ping6 -c 3 kamiya.v6.klab.org
PING kamiya.v6.klab.org(kamiya.v6.klab.org) 56 data bytes
64 bytes from kamiya.v6.klab.org: icmp_seq=1 ttl=64 time=1.10 ms
64 bytes from kamiya.v6.klab.org: icmp_seq=2 ttl=64 time=0.563 ms
64 bytes from kamiya.v6.klab.org: icmp_seq=3 ttl=64 time=0.363 ms

--- kamiya.v6.klab.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 20022ms
rtt min/avg/max/mdev = 0.338/0.475/0.569/0.102 ms
0.006u 0.004s 0:40.04 0.0%      0+0k 0+0io 0pf+0w

3 発 ping を打つだけなのに 40 秒もかかっています。-n オプションを 指定して、逆引きを抑制すると、

% time ping6 -nc 3 kamiya.v6.klab.org
PING kamiya.v6.klab.org(2001:c90:c1c:100e:2e0:81ff:feab:cdef) 56 data bytes
64 bytes from 2001:c90:c1c:100e:2e0:81ff:feab:cdef: icmp_seq=1 ttl=64 time=0.981 ms
64 bytes from 2001:c90:c1c:100e:2e0:81ff:feab:cdef: icmp_seq=2 ttl=64 time=0.354 ms
64 bytes from 2001:c90:c1c:100e:2e0:81ff:feab:cdef: icmp_seq=3 ttl=64 time=0.273 ms

--- kamiya.v6.klab.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.273/0.536/0.981/0.316 ms
0.003u 0.004s 0:02.02 0.0%      0+0k 0+0io 0pf+0w

などとフツーに 2 秒程度で終わるので、DNS の逆引きに問題があることが 分かります。一回の逆引きに 10 秒ほどかかっているようです。 てっきりネームサーバの設定の問題かと思ったのですが、host コマンドや dnsqr コマンドを使う限り、このような遅れは生じません。ping6 をはじめ、 glibc の getnameinfo(3) を使う場合だけ遅延が発生します。

後で気づいたのですが、この問題が起きるのは glibc 2.3 だけで glibc 2.2 では起きません (つまり kamiya とかでは正常に ping6 できる)。また、 当然ながら glibc 2.3 でも IP の逆引きは正常で、問題なのは IPv6 の逆引き だけです。

# 後述するように問題があるのは glibc 2.3.3 までで 2.3.4 は問題ありません こーいうときは tcpdump が基本だよね、つーことでパケットダンプしてみると、 getnameinfo(3) の場合は、

\[x20010c900c1c100e02e081fffeabcdef/128].ip6.arpa.

というクエリがまず飛び、10 秒ほどたってタイムアウトした後に

f.e.d.c.b.a.e.f.f.f.1.8.0.e.2.0.e.0.0.1.c.1.c.0.0.9.c.0.1.0.0.2.ip6.arpa.

というクエリが飛ぶことが分かりました。前者は見慣れない形式だったのですが、 「Binary Label」ないし「Bit-String」などと呼ばれる形式のようです (ちなみ に後者は nibble 形式)。「Binary Label」は、ドメイン名の一形式として RFC1035 で規定され、DNS での使い方が RFC2673 で決められたにもかかわらず、 ネームサーバでサポートされなかったために、RFC3363 で IPv6 の逆引きの方法 としては、使うのを断念されてしまった不幸な形式のようです。

とはいえ、「DNS で、どーして上位バイトが先にくるんだ〜 実装のこと何も 考えてないな〜」と脊髄反射的に拒否したくなる、頭悪い (brain damaged) 形式なので、断念されて幸い、ということもできますね。

2002年8月に RFC3363 で正式に断念された形式なら、そのまま人々の記憶から 忘れ去られて欲しかったのですが、何を血迷ったか、glibc 2.3 は IPv6 の 逆引きで、まず「Bit-String」クエリを試し、タイムアウトしたら「nibble」 クエリを送信するという実装になっています (glibc の resolv は BIND 由来 だから?)。

少なくとも 2004年8月3日に公開された glibc 2.3.3 では Bit-String が デフォルトのままですね。一刻も早く Bit-String が使われなくなることを 願ってやみません。

願ってるだけではアレ (^^;) なので、ソースを見てみると、 glibc-2.3.3/resolv/nss_dns/dns-host.c (2003年10月26日) では

case AF_INET6:
  /* XXX Maybe we need an option to select whether to use the nibble
     or the bitfield form.  The RFC requires the bitfield form so
     we use it.  */

って書いてありますね (Maybe って書くくらいならオプション指定できるように しろよ...)。これが glibc-2.3.4/resolv/nss_dns/dns-host.c (2004年10月25日) だと

case AF_INET6:
  /* Only lookup with the byte string format if the user wants it.  */
  if (__builtin_expect (_res.options & RES_USEBSTRING, 0))
    {
      qp = stpcpy (qbuf, "\\[x");
      ...

に修正されています! つまりデフォルトでは nibble 形式に変更されたんです ね。めでたしめでたし。さっさと glibc 2.3.4 (2005年1月26日) に上げよっと。

...と書いてる間に自宅マシンで 2.3.4 を make して install してみました。 無事、getnameinfo(3) が遅延なく IPv6 の逆引きができるようになりました。 メール書いているうちに自己完結してしまったわけですが、まあ何かの参考に なるかも知れないし、IPv6 に興味を持ってくれる人が増えるといいな、 ということで tech に投げておきます。

#12237                                                          仙石 浩明
http://www.gcd.org/sengoku/             Hiroaki Sengoku <sengoku@gcd.org>


「分からない」と言えることが重要だと私が感じるようになったのは、実は中学・
高校時代に遡ります。中学の時も、高校の時も、それぞれ同級生に、とても優秀
な友人がいました。そしてどちらに対しても、とても敵わないと思ったものでし
た。

例えば、何かの説明を彼にしようとして、頭の中で説明の筋道を考えた上で彼に
話しはじめると、まだ 10 のうち 1 ほども説明していないのに、「分かった」
と言われてしまったことがしばしばでした。まだ説明は序の口にも到達していな
いような状況だったので、話はこれから面白くなるのにと思いつつ、佳境の部分
を端折って説明しようとしたら、先回りして「要するに○○ということだろう!」
と要点だけ言われてしまいました。

異常に早く「分かった」と言う彼でしたが、「分からない」も連発していました。
当時の私には、彼ほど優秀な人がなぜ「分からない」と言うのかとても謎でした。
私にとっては、「なるほどなるほど」と相槌を打ちたくなるような話 (別の友人
が話した話題だったり、数学の証明だったり、コンピュータの仕組みの説明だっ
たり、SF の設定だったりしましたが) に対しても、彼は「分からない」と言う
のです。

なにぶん 20年以上も前のことなので詳細は覚えていないのですが、どこが分か
らないのか問い詰めていったら、実は私も分かっていなかったことが判明して、
「なるほど!」と腑に落ちたことだけは覚えています。

いかに簡単に、分かったつもりになってしまうか痛感した瞬間でした。

分かったつもりになっているだけなのか、ちゃんと分かっているのか、なかなか
判別できるようにはなれなかったのですが、彼と同じ内容について見聞きした後、
彼が分からない、というかどうか聞くのが楽しみになりました。

自分は分かったと思っても、彼が分からない、と言った時は、慌てて自己の思考
過程を振り返り、どこに論理の飛躍があるのか一生懸命考えたものです。どう考
えても自明なことのように思われるのに、彼が「分からない」と言った時は、そ
れはそれは彼が立派に見えたものです。

そんなわけで私は、「分からない」と言える人を尊敬してしまうようになったの
で、「『分からない』と言うことが恥ずかしい」と思っている人に対して違和感
を覚えるのです。



tech ML に、「分からない時は、『分からない』と言おう」キャンペーン を
書いたら、E コマース案件を担当している T さんが書き込んできました。

> あえて「分からない」が言えないシーン、心理状態を想像してみると、
> 直接コミュニケーションをとっている中で、「ちょっと調べれば
> 分かりそうなことを聞いてしまうことが恥ずかしい、(話の腰を
> 折るのが悪い)」というような心理的なブレーキが作用している
> ような気がします。
> でも分かってないまま話を続けさせるのって相手に失礼ですよね (^^;

まあ、そういう心理なのでしょうね。「自分で調べてから」というのは正しい態
度のようにも思われますが、多くの場合は調べる前に忘れちゃったりするわけで、
あまりよろしくありません。

> そういう意味では「分からない」を言いやすい環境作り、「分からない」と
> 言われやすいキャラ作りも一考の価値あるかな、とも思いました。

さすが T さん、「分からない」と言えない人のことだけでなく、その相手のこ
とまで考えています。何事もいろいろな角度から見ることが必要ですからね。

だけど、私が言いたいのは「分からない」ことをどうやって意識させるか、なの
で相手のことを考えてしまうと主題が発散してしまいます。困ったな (^^;)。

つまり、
「分からない」を言いやすい環境でないと「分からない」と言えない
では、ダメなんです。「分からない」と言うのが一番ためらわれる状況でも、
「恥ずかしい」という気持ちを押え込んで声を出す訓練を積み上げていって欲し
いと思っています。

例えば、講演会等で、質疑応答の時間になった時、誰も質問しなくって、大きな
会場が静まり返る、という状況はよくありますよね? その静寂を打ち破って質
問できるでしょうか? ほとんどの人は、たとえ質問したいことがあっても、な
かなか声を出せないんじゃないでしょうか?

私が個人的に尊敬している人って、ほとんど例外なくそういう場でも臆すること
なく質問できる人なんですよね。「分からない」と言える勇気を持つことと、ス
キルアップできること、との間には強い相関があるように思えてなりません。

大人数が参加する講演会場とかで質問するのは、まあ後々の課題として、せめて
社内の勉強会や tech ML とかでは、どんどん「分からない」と言えるようになっ
てもらいたいです。


「分からない時は、『分からない』と言おう」キャンペーン中、という メールを社内ML に出してみました。

この社内ML というのは tech ML という名前なのですが、KLab の技術者だけでなく、KLab と一緒に開発を行なっていただいている協力会社の方も全員参加していて、少しでも技術に関係ありそうなネタなら何でも自由に書いてね、という ML です。もちろん私も、いろんなことを書いています。

たとえばこんな感じで:

日経ベンチャーの Web ページに、「ピックアップBOOKS」という書評のコーナーがあって、いつも参考にさせていただいているのですが、そこで「ソフトウェア開発で伸びる人、伸びない人」という本の紹介を見つけたので、反射神経的に tech ML にメールを流しました。

----- tech ML に投げたメールここから -----
仙石です。

「分からない時は、『分からない』と言おう」キャンペーン中。

ソフトウェア開発で伸びる人、伸びない人 荒井玲子著
技術評論社 技評SE新書 002 2006/2 208pp 882円
http://nv-club.nikkeibp.co.jp/free/RASHINBAN/20060216/106694/

| プライドには、良いプライドと悪いプライドがある。間違ったプライドを持っ
| ている人かどうかは、次の質問をすればすぐにわかる。
|
| (1) 「わかりません」と言えますか?
| (2) 「難しい」と言って放棄していませんか?
| (3) 説明する機会を避けていませんか?
|
| 「わかりません」と言えない人、「そんなことはわかっています」という反応
| には要注意である。プライドの高い人は、尋ねるということ自体を苦手とする
| 傾向がある。

「分からない」と言えない人って、プライドが原因なんですかね?
「分からない」と言う方がカッコイイってことに、どーして気づかないんだろ?

| ひとつの専門性を持ったら、自分の適正に応じて専門領域を広げていくことは
| できる。一芸に秀でることは、他の分野の専門性を理解することに役立つ。そ
| のためには、ひとつの専門領域を極めることが重要である。

これも、その通りですね。


#13265                                                          仙石 浩明
http://www.gcd.org/sengoku/             Hiroaki Sengoku <sengoku@gcd.org>
----- tech ML に投げたメールここまで -----

優秀な技術者とそうでない技術者との境界線って、「分からない」ことが分かるか否か、だけじゃないかなぁと常日頃から思っているので、手を替え品を替え「分からない」と言えることの重要性を説いているわけです。

# 4/20追記: わからないことをわからないということの重要性を
# 書いているページを見つけました。


プロフィール
2000年、KLab株式会社取締役CTOに就任。1995年以来、TCP/IPパケットリピータ「stone」や、Palm上の時刻表ツール「Time Table Viewer」などを開発・発表する。また、堅牢で安定したサイトgcd.org を運営し、会員にサービスを提供。そこで得たサーバー構築ノウハウを日経Linuxで2000年4月から2年間連載
Categories
Blog内検索
人気記事
Archives
Ranking
KLabについて
KLab株式会社は、携帯電話の基盤技術から各種ソリューション、コンテンツ企画など多くのサービスを提供している会社です。
最新記事
最新コメント
最新トラックバック
blogranking.net
QRコード
QRコード