・ 昼頃起きた。

・ ちょっと実験をしたんだよしたんだよ。

・ こないだの続き。

・ せっかくなので、PCI ROM の image を作って試してみた。AMIBCP で組み込むと‥‥おお、vendor / device ID が最初から header 内の値になっている。少なくとも BIOS は PCI ROM の image として認識してくれたらしい。

・ ドキドキしながら起動。‥‥Error はないが、その代わり常駐もしてくれない。むぅ。

・ その後も、いくつか pattern を変えて試してみた。

1. ROM header はそのままで、BIOS の module 設定で vendor / device ID を onboard NIC のものに
2. ROM header はそのままで、BIOS の module 設定で vendor / device ID を PCI NIC のものに
3. ROM header の vendor / device ID を PCI NIC のものに

ありていに言えば、惨敗であった。むむむ。

・ あと考えられるものはってーと、なんだろね。

1. ROM image が小さすぎる（ISA ROM は 512B 単位でいいらしいが、PCI ROM は 8kB が最小、とする資料もある）
2. Entry point から far ret するだけでは駄目（return 時のどれかの register の値で常駐 size を指定するとか何とか。）
3. そもそも実際に boot に使われなかった boot ROM は起動後に削除される？ （ぐはぁっ）

うーん、実際に制御が渡ってるかとかその辺りを含めて、message 出力を組み込んだりして試してみないと駄目かな、本気で。

・ これもこないだの続き。Mixi の community のほうで追加すべき設定を教えていただいたので、実験実験。

・ まずは、教えていただいた通り、/etc/ppp/ppp.conf の ocn-ipv6 entry に以下の記述を追加。

 enable echo
 accept echo
 set MTU 1390

早速実行。繋いだ状態で上述の BIOS いぢりなどして、しばらく経ってから traceroute6 をかけてみる。‥‥記述を追加する前はしばら〜く放置しておくと link が落ちていたのだが、今度はしっかりと繋がっているようだ。ありがとうございます m(__)m ＞ だいくわさん。

・ 実験機でうまくいったので、本来 tunnel を掘っている machine に設定を移す。‥‥あれ、追加した記述が error になってますな。

・ 比較してみると、実験機が 5.5-RELEASE で、tunnel 掘り machine が 4.11-RELEASE だったのが原因らしい（それぞれ標準で持っている user ppp の version が違う）。そこで、実験機から /usr/src/usr.sbin/ppp を tunnel 掘り machine に持ってきて compile。そのままだと compile が通らないので、header file をごにょごにょしながら build。さすがに default のものを上書きするのは気が引けたので、man ともども /usr/local 以下に install し、/usr/local/etc/l2tp.coonf に以下の記述を追加。

ppp-path "/usr/local/sbin/ppp"

実行して、log を確認。‥‥「accept echo」がまだ error になってるが、「enable echo」と「set MTU 1390」はちゃんと通っている。念の為に実験機の log も見てみたら、こちらもやはり「accept echo」が蹴られていた。まあ大丈夫だろうと判断して、しばらく様子を見ることに。

・ この際だから少々真面目にいじってみる。

・ まず、rtadvd(8) の .conf file を copy しなければならないというのは、単なる誤解だった。/etc/ppp/ocnipv6_linkup.sh を見てみれば分かるが、rtadvd(8) の起動時に -c を与えて file 名を指定しているので、file を copy することには何の意味もない。

・ で、誤解した原因だが、設定をいじりつつ繋いだり切ったりを繰り返していたのが原因。実は起動時にまだ ppp による link が確立していないうちに dhcp6c が起動されてしまうことがあり、その場合は retry 後にようやく address が振られる。当然それなりに delay がかかるわけだが、さらに接続を切るときにも link が落ちたあとしばらくは rtadvd(8) to dhcp6c が生き残っているため（前者は dhcp6ctl で stop がかけられたあと実際に止まるまでしばらく時間がかかる。後者はそもそもprocess を殺していない）、時間差で address が生えたりする。

・ 固定 prefix 用の tunnel では基本的に切ったり繋ぎ直したりをしないので気にしなくてもいいかもしれないが、なんとなく気持ちが悪いので、ちょっと設定を追加してみた。まず、/etc/ppp/ocnipv6_linkup.sh で dhcp6c を起動する前に数秒の sleep を入れ、link が確立するのを待ってみる。さらに /usr/local/etc/rc.d/ocnipv6.sh のほうでは ocnipv6_stopcmd() の中身をいじってみる。

ocnipv6_stopcmd()
{
    ${DHCP6CTL} stop
    kill `cat /var/run/rtadvd.pid`
    sleep 2
    ${command} exit
}

Sleep する時間は調整が必要だが、ともあれ基本方針はこんな感じで。本当なら sleep なんか使わずに wait 辺りで処理したかったのだが、PID file を吐かせるようにしたりはしたものの、肝心の wait が PID ではなく job ID を要求したりなんかしたので、面倒くさくなって投げた。（← 手抜き）

・ わざわざ切断や再接続を前提とした検討をするのは、もちろん非固定 prefix な tunnel を出先で note PC から掘るための準備を兼ねているため。

・ ところで、/etc/ppp/ppp.conf の「accept echo」な設定って、-current とか 6-stable 方面では生きてるのかしら。そのうち cvsweb あたりで見てみよう。

・ そんなこんなをしたり仕事をしたりしているうちに、いつの間にか深夜。そりゃあ腹も減るわけだ。

・ 何だか雨も止んでいたので、さくっと松屋に行ってごぼう牛飯を喰らう。

・ 26 時頃寝る。

・ 8 時半頃起きた。

・ ふにゅふにゅと支度して出発。

・ というわけで、久々に客先で会議。いやもう、皆さんにはご心配をお掛けしまして‥‥ m(__)m。

・ 廻りの人にいろいろと質問攻めにあってみたりしつつ、会議のあとは作業。‥‥え？ 休み前にもらってた以外にも仕様の追加がある？ それって大至急じゃん。‥‥それ以外に、開発環境も今週末に snapshot release？ それって危急じゃん。ぐはぁ‥‥。もうちょっと早く言ってくれれば‥‥。先週 mail で document を送ったときには何にも言われてなかったのに‥‥。しくしくしく。

・ ともあれ、今週の release に突込む分を大急ぎで組み込み。途中で昼飯喰ったり晩飯喰ったりしつつ作業を続けていると、何だか妙に人が少なくなっているのに気付く。‥‥へ？ みんな soccer 見に帰ったの？ ぬあー。

・ 何とか開発環境のほうもいじって担当者に引き渡‥‥そうかと思ったら既に帰っている。とりあえず mail で送っておいて、離脱。うーん、10 時に入って、出たのは 23 時過ぎ。飯を喰いに行っている間を以外は結局ずっと monitor を見っ放し。眼がずきずき痛いよー。うぅ。

・ 帰りの列車で、tunnel 掘りの実験。まず、起動時に自動で実行されると困るので（外に繋がってないからね）、/usr/local/etc/rc.d/ocnipv6.sh を /usr/local/bin/ocn_ipv6 と copy し、こちらをいじることにする。‥‥つーても、昨日いじっていた内容から大きな変更はなし。ocnipv6_enable の default 値を「YES」にしたくらいのものだ（← 手抜き）。もちろん、/etc/rc.conf のほうでは ocnipv6_enable を記述しないでおく。こっちを「YES」にすると起動時に /usr/local/etc/rc.d/ocnipv6.sh が動いてしまうし、「NO」にすると /usr/local/bin/ocn_ipv6 も動かなくなる。まあ、こうしておくといろいろ便利かなー‥‥と思ったのは後付けで、ほんとは script をあまりいじりたくなかっただけです。すいません。ほんの出来心なんです‥‥。

・ ともかく、ちゃんと tunnel が掘れ、自宅に access できることも確認した。あとはあれだな、firewall を整備したり。ああ、宅内 network が 3ffe なままだ。これを契機に、prefix を変更するかな‥‥。ちょっと大掛かりだが、いつまでも 3ffe な prefix を使い続けるわけにもいくまい。環境が整ったら、PPP の linkup 時に自宅向けに自動で DTCP tunnel を掘るのも止めて、OCN IPv6 に置き換えよう。

・ あとはあれだな、今の設定では note の NIC に IPv6 address が生えるようになっているが、もしも AIR-EDGE と Ether とで同時に network に繋がってしまったときに都合が悪い。Router になるわけではないんだから、dhcp6c で IPv6 address を振るのは、やっぱり tun I/F がいいんだろうな。もともと link local は生えてるわけだし。

・ 10 時頃起きた。

・ 昨夜終車時刻を気にしつつ客先を飛び出したらせっかく印刷した document を置いてきてしまったので、しょんぼりしながら印刷し直して、目を通す。‥‥うーん、cache control 廻りが厄介そうだなぁ。あと、命令が拡張されてるのはいいとして、書かれている情報だけでは振舞いがよくわからん。

・ BOF からの帰り途に斎藤さんと約束していたので、昼食がてらアルファオメガさんにお邪魔する。九段なので、キコキコと自転車で。

・ 着いたのは全国的にちょうど昼時。お茶をいただきながらしばらく時間を潰し、peak をやり過ごした頃合で裏手にあるカレー屋さんに向かう。

・ 今回はほうれん草と chicken の curry にナンと salad の set。うみゃーでよ。これで 800 円附近というのは、素晴らしい :-D===。

・ そのあとはまた会社にお邪魔して、積もりまくった話をあーでもないこーでもないと。斎藤さんは BSDCan の件でいたく心配されていた。

・ なんだかんだと夜までお邪魔してしまい、兵頭さんと 3 人で飯田橋へ向かい、コージーコーナーでお茶。うーん、通過は時々してるんだが（つい土曜日にも通過したばかりだ）、飯田橋界隈を歩くのは久し振りだな。いろいろと変わり行くなか、飯田橋駅西口の佇まいが相変わらずなのを見て、ちょっとほっとする。

・ しばらくぐったりしたあと、九段下までブラブラと。駅の入口でお二人と分かれ、一路東へ。途中で弁当など買いつつ帰宅。

・ 帰ってからはしばらく仕事。実装の検討をしてみたり。

・ なぜか 6 時頃目が覚めた。

・ よほどぐっすり寝たらしく、あまり眠くない。そのまま起きて仕事開始。

・ いつもの弁当屋ですぺさる弁当。

・ 午後もそのまま仕事。ていうか、document を読むために MS-Office が必要になってきてしまった。一部の document が PowerPoint で書かれているため。

・ しばらく前に qemu 上に W2k を入れてあったので、そこに Office2000 を突込む。さらに Adobe Reader を入れようとしたところで、W2k が無印であることに気がついた。仕方がないので SP3 を入れようと‥‥したのが運の尽き。

・ まず、SP3 を入れたら、起動しなくなった。なぜか DLL が 1 ついなくなったらしい。名前からして、graphical mode に移行して最初の splash を表示する DLL らしい。Boot 用の HDD image を FreeBSD 上から mount して、当該 DLL を探す。SP3 install 時の backup に落ちているのが無事に見つかったので、それを system32 directory に copy。ちうか、なんでこんなのが不足するんだ？

・ ともあれ、無事に boot。そのあと、念の為に update。‥‥「緊急性の高い update」なるものがぞろぞろ出てくる。しかも、それらには依存性があって、なおかつ一つづつ install しては再起動を繰り返さないと次の update を install できない。みんなよくこんなの我慢して使ってるな‥‥。

・ 仕事の裏で W2k の update 作業を続けていたが、馬鹿でっかい update を取ってくるのにやたらと時間がかかったりしているうちに自分の方が力尽きた。眼が痛い。

・ 19 時頃 down。

・ そうそう、しばらく前に qemu を入れたんだった。

・ 動機は単純。Document 読み用に W2k machine を用意してあったんだが、ただ document を読むためだけにわざわざ machine を起動するのが鬱陶しくなった。いろいろと揉めるし。で、「なかなか完成度が上がってきた」と評価が高まってきていた qemu を入れてみたというわけ。

・ 最初に入れたのは qemu 0.8.0 の頃。既に kqemu module を併用すればそこそこの速度で動くようになっていた。逆に言うと kqemu な市では余りにも重い。なので、FreeBSD では最低でも 5-stable 系列が必要。4 系列では kqemu が生きないから。

・ Build は ports の emulators/eqmu から make 一発。高速化用の optons は全部設定。HDD image はとりあえず 4GB 分用意した。で、install。なぜか FreeDOS/V の install に手間取ったりはしたものの、一旦成功するとあとはさくさく進む。

・ Install はなんとか終わったが、その先が長かった。宅内 server には Windoze machine に disk を公開するための samba server がいるが、こいつがうまく見えてくれない。もちろん、純然たる Windoze machine からは問題なく access できているので、samba 側の設定の問題とは考えにくい。情報を漁ってみるが、「なにも考えなくても qemu 内部の仮想 NAT server 経由で外部と通信が可能」という記述ばかり。むむむ。

・ tap やら vlan やらを試しているうちに「ネットワークコンピュータの検索結果」にだけは現われるようになった。つまり NMB だけは通るようになったわけだが、SMB は依然として通らず、実際に access しようとすると timeout になる。だんだん嫌になってきたので（っていうかそれにばかり時間をかけていると仕事に差し支える）、しばらくほったらかしにしていた。

・ あるとき、気分転換にいじりつつ外部で packet を監視してみると、request はちゃんと出て、その reply も返っているのに、NAT の内側へはそれが届いていないらしいことに気がついた。‥‥なんか、デジャヴが‥‥。そこで qemu の document をよく読んでみると‥‥ 10.0.2.0 の network ですか？ うわー、こいつだ‥‥。

・ 実は、宅内 network で 10. の network を使っているのだ。しかも、歴史的経緯により、subnet mask は 12-bit。どうもこいつが原因臭い。Document には「標準では 10.0.2.0 の network を使う」と書かれていたので、設定項目を探す。‥‥Network address の設定項目がありませんが‥‥。そこで、source を洗ってみる。‥‥うわ、直書きかよ‥‥ (-.-;。「標準」て、それ以外の場合は設定で逃げられるんじゃなくて source を書き換えなきゃいけないんですかそうですか。しくしく。

・ IP address が書かれているのは header 1 箇所と C source 1 箇所。しかも、C の source ではせっかく header で macro 定義しているのにそれを使わずに直接値を書いている。とりあえず netmask だけ変更して逃げようかとも思ったんだが、どうやら address class から導かれる標準の netmask をそのまま利用しているようで、netmask を明示的に設定している箇所はない。ならばと、今回は class B の private address を使用することにした。C の source で直書きしている場所は、どうせ header と値が食い違うとまともに動かないのだろうと、header を include してそこで定義されている macro を使用するように修正^*1。結局、こんな↓ patch が追加で当たるようにした。

--- qemu/slirp/ctl.h    Thu Apr 22 09:10:47 2004
+++ qemu-patched/slirp/ctl.h    Wed Apr 12 22:14:51 2006
@@ -3,5 +3,5 @@
 #define CTL_ALIAS      2
 #define CTL_DNS                3
 
-#define CTL_SPECIAL    "10.0.2.0"
-#define CTL_LOCAL      "10.0.2.15"
+#define CTL_SPECIAL    "172.16.2.0"
+#define CTL_LOCAL      "172.16.2.15"
--- qemu/vl.c   Wed Apr 12 21:51:02 2006
+++ qemu-patched/vl.c   Wed Apr 12 22:00:39 2006
@@ -62,6 +62,7 @@
 #if defined(CONFIG_SLIRP)
 #include "libslirp.h"
 #endif
+#include "slirp/ctl.h"
 
 #ifdef _WIN32
 #include 
@@ -2007,7 +2008,7 @@
     if (get_str_sep(buf, sizeof(buf), &p, ':') < 0)
         goto fail;
     if (buf[0] == '\0') {
-        pstrcpy(buf, sizeof(buf), "10.0.2.15");
+        pstrcpy(buf, sizeof(buf), CTL_LOCAL);
     }
     if (!inet_aton(buf, &guest_addr))
         goto fail;

この patch は、既に他の patch が当たったあとの file をさらにいじっている。暫定なので、patch-zza なんつー filename で files directory に転がしておく。どうせ configure 使ってるんだからその option で指定できたほうが嬉しいんだろうけど、今回はそこまでやっていない。

・ あとは普通に make install。でもって、起動してみると‥‥うむ、ちゃんと IP が変わっている。‥‥おおお、server が見えました！！ :-D

・ あー、やれやれ。ちうわけで、ようやく一件落着となったのでした。どっとはらい。

・ 余談。退院したあと、ようやく 5.5-RELEASE が出たので、qemu を動かしている machine も 5.4-RELEASE から update。ついでに portupdate -a も実行。そうしたら、qemu も 0.8.1_1 に update されていた。ますます performance が向上 :-D。作ってあった patch もそのまま当たったようだ。つるかめつるかめ。

*1: configure に --disable-slirp を与えたときに何か問題が起きるかもしれないが、どうせ ports から install するときはその option が与えられることはないので、今回は気にしていない。

・ 2 時頃起き出す。

・ 寝ている間に客先から mail が来ていたので、とりあえず返事を出す。うーん、PowerPoint の file を編集ですか‥‥。客先の公式 Wiki にかなり細かい情報まであげてあるんだが‥‥。

・ でもって、作業の続き。つーか update。

・ 9 時過ぎにいつもの弁当屋ですぺさる弁当。

・ 11 時頃、買い物に出掛ける。宅内で使っている空気清浄器に「洗浄」 sign が出たんだが、unit を浸けおき洗いするのに内径 60cm 以上のたらいかなにかが必要。

・ というわけで、いつものよーに猿江の島忠へ。‥‥たらいは外径 45cm 程度までしかないのか‥‥。店員さんにはコンテナを奨められたのだが、これがまた微妙に内寸が足りない。‥‥そういえば、そろそろ夏ですね？

・ というわけで、アウトドア関連の売り場へ。子供用のビニールプールでもないかと思ったんだが‥‥あったあった。足洗用は小さすぎ。その上となると外径 80cm か。まあまあですな。

・ その他にもいくつか買い込む。領収書をもらいに service counter へ。ついでに「車の貸し出し」の件について訊いてみると‥‥ほほう。そうですか！

・ ちょうど空いてるというし、早速借りようと思ったんだが、免許証をもってでなかったことに気付く (__;。かといって自転車で持って帰るにはちょっと微妙な荷物だし、車で運べるならちょうど欲しいものもあったので、一旦荷物を預かってもらって免許証を取りに帰る。

・ 取って返して、さらにちょっと大きめの買い物をして、車を借りる。車は軽トラ。屋根も幌もないので雨が降っているとちょっと困るが、どうせ行き帰りは自転車なので、雨が降っているとそもそも買い物に出ないだろう。

・ 早速荷物を積み込んで、出発。店からは一旦南に下るしかないので、葛西橋通りまで出て、そこから西へ。‥‥結構混んでるな。

・ 三ツ目通りを北へ。ここも結構混んでいる。蔵前橋通りへ入ってしまうと、割と空いている。結局、約 15 分で到着。

・ 荷物を降ろし、とっとと戻る。蔵前橋通りから四ツ目通りへ。この経路はいつもどおり割と空いている。約 10 分であっさり到着。店を出てから戻るまで 30 分であった。貸し出し時間は原則として 1 時間が上限なのだが、余裕ですな。それにしても、遠方がむやみに見えるようになっただけあって、眼鏡なしでも運転には全く問題がない。素晴らしい。むしろ、しばらく車を運転していなかったので、またもやペダルを強く踏み込んでしまう癖が。むむむ。

・ 車で移動中にバラバラと降ってきていたのだが、店を自転車で出る頃にはほぼ止んでいた。錦糸町へ出て、久々に宇奈ととへ行って鰻重を喰う。そのあと、途中で夕食を買い込みつつ、キコキコと帰宅。

・ 帰宅してから程なく、雨は本降りに。

・ 作業の続き。つーか、background では相変わらず update 祭り。

・ 夕方になって、ようやく一段落。ていうか、いつの間にか 4GB の HDD image をほぼ使い切ってますよ。ぐぁー‥‥。

・ 気がついたら客先から mail が来ていた。「詳しい情報は Wiki に書いてあります」と伝えておいたのだが、それを見て document を update してくれたらしい。早速 PowerPoint で確認。‥‥問題なさそうだったので、mail で連絡。

・ そのあとも source の改変作業の続き。

・ 気がついたら 23 時過ぎでやんすよ。さすがに眠い。つーか眼が痛い。

・ 明日は朝一番で診察を受けに行かねばならない。とっとと寝ることにする。ちうても 24 時近いわけですが。

・ 9 時頃起き出す。

・ 支度をして、病院へ。

・ ‥‥昨日から雨が結構降っていたせいか、割と空いている。

・ 視力や眼圧の測定。そのあと診察。

・ 手術をした左眼はまずまず順調。ところが、右眼の近視が順調に進行中らしい。既に白内障の傾向が見られることもあり、「近視というより白内障の影響かもしれない」とのこと。ただ、視野の白濁はそれほどでもなく、矯正視力も 1.2 まで出ているということなので、当面は様子見。

・ というわけで、次の診察はまた 1 ヶ月後。1 日 4 回の点眼も引き続き継続。ただし、3 種類の点眼薬の内、そろそろなくなりそうなジクロードはなくなった時点で中止し、そのあとはクラビットとリンデロン A のみになる。‥‥ところで、これらの点眼薬は朝・昼・夕・就寝前に点眼するんだが、要冷蔵なので、客先に持っていかれないんだよね。朝はいいとしても、客先に行く日は昼と夕に点眼できない。昼は諦めるしかないが、せめて当分は夜早く帰ることに努めよう。‥‥できるかな‥‥。

・ そして、手術から 1 ヶ月が経過したので、そろそろ眼鏡を作れるか訊いてみた。‥‥最低 2 ヶ月は見なければならないそうだ。日帰り手術を勧める眼科の page では大抵「1 ヶ月くらいで状態が安定するので眼鏡が作れるようになる」と書いてあるのだが、手術後の生活の注意点などの記述を見ても、同愛記念の対応との落差には驚かされることばかり。どちらが正しいというものでもないのかもしれないが、同愛記念のほうが必要以上に慎重だというわけでもないようだ。これからの医療の market の中心は自然と老人が target になるわけで、日帰り手術をはじめとしてできるだけ「気軽さ」を appeal して顧客を獲得しようとしているような気がしなくもないなぁと感じてみたり。

・ それにしても気掛かりなのは、「最低でも状態が安定するまで 2 ヶ月は見なければならないし、右眼の近眼が今後どんどん進行することも考えられるので、眼鏡を作るのはしばらく様子を見てからのほうがいい」と言われたこと。‥‥右目の状態が悪化しないことを祈ろう‥‥。ただでさえ「既に左に白内障が出たということは、右もいつ出てもおかしくない」と言われているんだし。せめて多焦点 lens の使用が一般化するまでは右眼の手術はしたくないものだ。

・ いつものように病院内の restaurant で昼食。いつもなら会計待ちの間に喰うのだが、今日はさっさと会計が終わってしまったので、のんびりと。‥‥「カニのトマトクリームパスタ」は今一つだった。いつものヒレカツ定食にしとけばよかった。

・ 帰宅して、仕事の続き。

・ ‥‥いつの間にか 24 時過ぎ。

・ 腹が減ったので、昨日買ってきてあったパンをもそもそと喰い、寝る。あんまり長時間作業をすると、眼が痛くなるんだけど、集中するとつい時間が‥‥。で、眼が痛くなって止めることになるんだが、切りが悪いところで止めるとあとが大変なんだよねぇ‥‥。

・ 9 時頃起きた。

・ もぞもぞと仕事。

・ 仕事の合間に、気分転換のため OS の update。（爆）

・ 5.x-RELEASE 系列は全て 5.5-RELEASE-p2 へ。4.x-RELEASE 系列は全て 4.11-RELEASE-p19 へ。Server の reboot は 155 日 22 時間ぶり、予備回線用の firewall に至っては実に 763 日 7 時間ぶり。

・ 並行して仕事。

・ 毎度お馴染の森の治療院へ行って鍼を打ってもらう。ちくちくちくちく。

・ らんぷ亭で飯喰って帰宅。

・ 折り返し 乗車の 件。「東京→名古屋→三河安城」と乗車する際の乗車券が 2 区間に分割されるのはいいとして、「東京都区内→名古屋市内」「大高→三河安城」となるのはなぜか、という問題。

・ 規則 86 条に定められている「特定都区市内」制度は、「ある程度の需要が見込まれる都市については運賃計算上の起終点をその代表駅に集約することによって事務上の負担を軽減するとともに旅客の自由度の向上を図る」という主旨のもとに設定されている。主に鉄道会社（＝ 国鉄）側の都合によって設定された制度であるため、その取り扱いについては特に注意が払われている。「目的地までの運賃が代表駅を採用することによって本来乗車・下車する駅で計算した場合よりも高額となる場合は、本来利用する駅を基準とした運賃を適用できる」などの扱いがそれ。

・ 特定都区市内制度が適用される場合は、原則としてその都区市内のどの駅を利用しても中心駅を利用するものとして扱う。簡単に言えば、その都区市内であれば旅客は利用する駅を任意に選択可能、ということだが、裏返せば、その都区市内にある駅は全て同一視するということになる。その考え方の一端として、「特定都区市内着の乗車券をより遠方の駅着として区間変更する場合、変更部分の運賃計算の起点をその都区市内の出口の駅とする」という定めがある（基 275 条 (1)）。合理的な範囲においてできるだけ旅客の有利になるように取り扱うという精神を明文化したものだ。

・ さらに、特定都区市内制度独特の扱いとして折り返し乗車の特例が定められている。

旅客営業取扱基準規程

（特定都区市内等における折返し乗車等の特例）
第 150 条　特定都区市内発着及び東京山手線内発着となる普通乗車券を所持する旅客が列車に乗り継ぐため、同区間内の一部が復乗となる場合は、別に旅客運賃を収受しないで、当該区間について乗車の取扱いをすることができる。

（第 2 項は省略するが、そちらは大阪市内発着の乗車券における塚本〜尼崎〜加島間の区間外乗車を定めたもの。）

似たような定めに特定の分岐区間や分岐駅通過列車に関する区間外乗車の特例（それぞれ基 149 条と基 151 条）があるが、それと較べてこの条文の特異なところは、「特定都区市内」という一定区域内について乗車列車の種別や実際の乗車経路に関して何らの制限をしていない点にある（あまり不合理な経路を取るともちろん問題になるだろうが）。これは「ある程度距離が長い乗車券の起終点となる特定都区市内はもはや全体で一つの駅」という考え方を押し進め、運賃計算上だけでなく乗車経路の面でも扱いを簡略化したものと考えることができる。東京都区内や大阪市内では特に不自然な乗車をしなくても同一区間に複数の経路が存在する場合もあるので、この取扱いは特に効果がある。

・ 今回の件で折返し区間の起点が大高となるのは、この基 150 条の定めに加えて基 275 条 (1) の主旨を準用したためだろう。名古屋市内着の乗車券では実際の着駅を当該区域内で任意に指定することができ、さらに当該特定都区市内での乗車経路は一切問われない。三河安城までの乗車券の起点を「名古屋市内駅でもっとも三河安城に近い駅」と考えれば、必然的に大高駅を採用することになる。名古屋市内での乗車経路は合理的でさえあれば全く任意なので、名古屋駅で新幹線から在来線に乗り換えて折り返しても何ら問題はない。

・ ちなみに、大高が端点となるのは単にその駅が名古屋市内の端の駅だからであって、逆向きの「三河安城→名古屋→東京方面」でも全く同じ買い方ができる。片道乗車券が「6 の字」形に環状を構成する場合に復路はその逆経路を取ることができないのとは対照的。

・ 蛇足だが、これはあくまで特定都区市内に関する制度なので、経路が同じでも名古屋駅までの営業キロが 200km 以下である場合は適用できない（名古屋駅で打ち切りとなる）。

・ 前回の続きと言えば言えなくもない。

・ 一念発起して、宅内の IPv6 address prefix を切り替えた。今までは 3ffe な prefix を使っていたのだが、これを機に 2001 な prefix へ。

・ これまでも rtadvd(8) で prefix をばらまいていたので（固定にしていたのは外に見せている firewall くらいなものだった）、prefix の切り替え自体は簡単だ。新しい prefix に対応するものは OCN IPv6 用の script 内で起動してくれるので、元々動かしていた旧 prefix 用のもの（これは歴史的経緯で現在の firewall machine とは異なる host で動いていた）を停める設定をするだけ。

・ 面倒なのは、言うまでもなく DNS の zone file の書き換え。この作業をやるたびに、どうして A6 の binary notation が標準として生き残らなかったのかとため息を吐きたくなる。宅内 network で IPv6 を使用する上で最大の障害は security と DNS の問題ではないかと思う。

・ 最も smart ではないかと思えるのは、DDNS と組み合わせて、RA を受け取って IPv6 address を振ったときに nsupdate(8) をかけるというもの。しかし、当然ながら FreeBSD の kernel にはそのような hook はない。宅内 network であればそんなに頻繁には prefix が変わることはないとは言え、NIC を差し替えたり新しい machine を追加したりなどによる MAC address の増減は当然ありうる。幸い動的に address が変わったりはしないので、nsupdate(8) を実行するのは machine の起動時のみだ。そう割りきってしまえば、「network I/F に link local でない IPv6 address が振られているか監視しておいて、振られた時点で nsupdate(8) を実行して終了する」というようなインチキ program（または script）をでっち上げてやればいいんだろうな。そのうちでっち上げるかね。

・ ところで、このところ気になっていたことがある。新しい prefix をばらまいているはずなのに、どうも IPv6 な address が生えてこないのだ。rtsol(8) を手動で実行しても駄目。 OS の update を行なっていたこともあって、いよいよその現象が顕在化してきた。

・ 最初の何台かは ifconfig(8) を使って手動で振っていたのだが、だんだん面倒になってきた。そもそも、起動しっ放しでない host は起動する度に毎回これを行なう必要がある。宅内 DNS の zone file は既に更新してしまっているので、IPv6 address が振られていない machine に接続しようとすると（FreeBSD は双方が dual stack であると IPv6 を優先的に使おうとするので）毎回 timeout 待ちになるのでいらいらする。そもそも rtadvd(8) が起動しているのにこんな現象が起こるのは納得いかない。

・ tcpdump(8) で見ていると、RA はちゃんと定期的に流れている。rtsol(8) を実行したときには、RS に対応して RA がやはり流れている。それでも RA を受け取った側には IPv6 address が生えない。

・ 以前に RA をばらまいていた machine は 4 系列の host だった。今回使っているのも 4.11-RELEASE なので、大きな違いがあるとは思えない。というか、もしも同じ使い方をしていても挙動が違うのであれば、（それが bug fix でもない限り）既に騒ぎになっているはずだ。ということは、まずは「使い方」を疑うべきだろう。

・ というわけで、状況の確認。元の host では、rtadvd(8) の起動に当たって一切 option を与えていなかった。つまり、全ての parameters が default 値であることになる。一方、OCN IPv6 用の script では configuration file を指定しており、その中では 3 つの parameters（address の有効期限に関する値）を設定している。そこで、とりあえずこの configuration file を与えないようにしてみた。‥‥うーん、さっくり生えるようになりましたよ。

・ Manual page を見る限り、3 つの parameters の間には矛盾があるようには思えない。指定していないものとの間に何らかの問題があるのかとか、そもそも 3 つのうちどれが問題なのかは、未確認。なんでしょね。ともあれ、宅内 network ではそんなに頻繁に address が変わることはないわけなので（というか、上述の通り、むしろあっては困る）、敢えて有効期限を短く設定する必要もない。ちうことで、default 値を使うことにして解決。

・ 最初に実験していた頃にはしばら〜くすると新しい address が生えてることもあったので、もしかするとこの挙動の違いは rtadvd(8) の revision にもよるのかもしれない。ちなみに、実験機は 5.5-RELEASE、本運用は 4.11-RELEASE。

・ ともあれ、一段落。念の為に access test を実施。

・ 宅内 network 内ではほとんど問題なく新しい prefix の address で通信できた（あたりまえ）。ところが、唯一例外となる host があった。よりにもよって RA をばら蒔いている当の firewall 機だ。

・ Firewall 機では、とりあえず IPv6 の firewall を off にし、IPv6 routing も有効にしていた。それにも関わらず、traceroute6(8) をかけても外へ出て行かれない。それどころか、firewall 機自身と IPv6 で通信ができない。ちなみに、firewall 機と外部の間は通信ができている。

・ そのうちに、firewall 機の /var/log/message を見ていて気がついた。外部の host に access しようとしても、firewall 機自身に access しようとしても、その時点で

/kernel: nd6_lookup: failed to lookup 2001:〜 (if = sis1)

という行が現われる。Log に現われる IPv6 address は接続元のもので、network I/F は内側向きのものだ。そこで netstat(8) で rouoting table を見てみると、宅内 network の prefix に対する routing が外側向きの I/F へ向いている。

・ 結局のところ、原因は外側向きの I/F に固定の address を振っていたことにあった。外部に公開する host は NIC の交換などによって address が変わると困るので、手動で address を振ることはそんなに特殊な例ではないだろう。現に FreeBSD ではそのための mothod が用意されており、/etc/rc.conf に記述するという標準的な手段で設定することができるし、今までもそうしてきた。

・ ところが、これまでと違う点がいくつかある。以前は /48 をもらっていたので、外部に公開する address と宅内 network に異なる SLA を振っていた。ところが、OCN IPv6 では /64 な prefix が与えられるので、このような使い方ができない。そこでとりあえず同じ prefix を持つ固定 address を /etc/rc.conf で外側の I/F に設定していた（DHCPv6 client が動的に address を振る I/F は内側にする）。本当なら server から DHCPv6 によって prefix を割り当てられたときにそれを使って生やしたかったのだが（その方が DHCPv6 で prefix を割り当てるという OCN IPv6 の方式にも馴染みやすい）、WIDE DHCPv6 client にはそういった機能がない。

・ ところで、OCN IPv6 で使用しているのは完全に動的な tunneling であり、machine が起動してから L2TP tunnel を掘り、その上で PPP を流してやる必要がある。そのためどうしても OS が起動したあとでないと tunnel が掘られないし、内側の I/F にも address が振られない。しかし、/etc/rc.conf による設定は tunnel が掘られるよりも前に実行されるので、kernel からすればまず外側の I/F に IPv6 address が振られることになる。その際、当然ながらその /64 prefix に対する routing はその I/F に向けられることになり、いざ tunnel が掘られたあともその状況は変わらない。かくして、本来内側の I/F から宅内 network に流れていくべき IPv6 な packet は外側の I/F から流れだし、受け取る者がいないその packet は行方不明にならざるを得ないというわけだ。

・ この状況を回避する方法は少なくとも 4 つある。

• まず一つは、外側 I/F に address を振るのを DHCPv6 によって prefix を取得したあとまで遅らせること。この場合は /etc/rc.conf に頼ることはできなくなる。Trigger としてはやはり「内側 I/F に address が生えた」ことが妥当で、前述の nsupdate(8) の代わりに ifconfig(8) を実行すればいいということになる。
• そしてもう一つは、prefix を受け取ったときに公開用の固定 address を割り当てること。これには WIDE 以外の DHCPv6 の実装（そういう機能があるのかどうか知らないが）を利用するか、WIDE DHCPv6 client の改造が必要になる。この方法はやや手間がかかるが、「同じ prefix を持った I/F が複数存在する」という根本的な問題を解決することもできる。
• やや姑息な手段ではあるが、「固定 address を振るのを内側の I/F にし、DHCPv6 によって動的に address を振るのは外側の I/F にする」というテもある。しかし、何だか気持ちが悪いし、なんといっても IPv6 通信に対する firewall（主に filtering）が困難になるという問題がある。IPv6 の熱心な推進論者からは「IPv6 network に firewall なんて邪道だ」と言われるかもしれないが、私は「network 上の全ての machine で host level security を維持する」なんてことを保証できるほど自分を信用していないし、この先 Windoze が標準で IPv6 を support することになればなおさらその脆弱性が問題となり得るだろう。

いずれにせよ、せっかく形の上では「prefix を DHCPv6 で配布する」ということになっている^*1のだから、固定 address を振る際にもそれに則した形にするのが望ましい。

・ で、現状はどうしているのかというと‥‥

• machine が起動したあと、外側に I/F に生えている address を一旦剥し、もう一度振り直すことで逃げている。こうすると、address を剥した時点で /64 prefix に対する routing が内側へ向き、もう一度 address を振り直してもそれは変わらない。しかし、ifconfig(8) を高々 2 回実行するだけだとはいえ、machine が起動する度に毎度これをやるのは面倒だし、なんといっても馬鹿馬鹿しい。

・ DNS の件でもそうだが、IPv6 の最大の「特長」とされている auto configuration に振り回されるというのは、実際の労力以上に精神的な疲労が大きい。なにかがいろいろと間違っている。Protocol はできあがっていても、それを運用するための技術（というか「手段」というか）がまだ成熟していないなあと感じる今日このごろ。

・ ところで、この話はもうちょびっとだけ続くんじゃな。

*1: OCN IPv6 の concept は「外出先から自宅に access する」ことを前提としているので、service を申し込むと、固定 network 用に予め prefix を 1 つ割り当てられる（固定 prefix 用 tunnel server に接続すると、user ID に応じて必ず同一の prefix が DHCPv6 で渡される）ので、固定の address を生成する場合はこの prefix を使っておけばいい。この他、非固定 prefix 用 server に接続すると動的に 1 つの prefix を利用することができる（1 つの user ID 当たり、同時には合計で 2 つの prefix が割り当てられることになる）。