トップ 最新の日記 ユーザー登録 ログイン ヘルプ

osdev-jの日記 RSSフィード

2008-08-03

IPv6-in-IPv4のTracerouteが一方通行になる 08:11  IPv6-in-IPv4のTracerouteが一方通行になる - osdev-jの日記 を含むブックマーク

Linuxのsitトンネルは特に何も設定しなければ、IPv6パケットのHop Limit(要するにTTL)をカプセル化後のIPv4パケットに引き継ぐので、明示的にTTLを指定する。

要するに、IPv6でなくIPv4のICMP time exceededが届くので、traceroute的に届いていないように見える。

もっとも、feel6のようなトンネルにたどり着けばそれ以降のパケットはIPv6的に到達するので最終目的地付近では正常になる。

わかりやすいデュアルスタックを作るには

移行の過渡期にはどうしてもこういう弊害は付きもの*1だが、このような問題を解決することは求められている。

そこで、「統合ピアキャッシュ」を提案する。

従来のネットワークプロトコルスタックはインターフェースによる抽象化で上位のプロトコルスタックからエラーを隠蔽してきた。

統合ピアキャッシュは、ネットワークサービスをツリー構造と見なす。

ファイルシステムのような*2APIと見なせる。つまり、個々のネットワーク接続は常に親を持ち、接続を行うということは適切なディレクトリでmkdirすることに相当する。UNIXアプリケーションをこの枠に当てはめても恩恵は無いが、この概念そのものはトラブルシューティングを行う人間の助けにはなる。たとえばWiresharkのようなパケットスニファの分析の一つとしてFUSEファイルシステムの実装をすることもできるだろう。

機械が解決できない問題を人間に解決させるためには良い情報提示が必要だと考える。もちろんパケットの直接観察と条件フィルタリングは手法の一つだが、通常の人間には難しい。

v6v4デュアルスタックにこれを適用した場合、リゾルバによって取得された同名のAとAAAAは仮想ルート(root)の子として並列に作成されることになる。もちろんルート(route)や提供しているサービス実態が異なる*3こともあるので、このような対応が正しいのかは議論の必要があるかもしれない。

しかし、現状のデュアルスタック環境では、既存OSの「同名異プロトコルホストは常に別物と見なす」よりも正しいと思える。ダンスやモザイクの有無以外の顕著な差があるケースは殆ど無い。

なぜFPGAなのか 08:11 なぜFPGAなのか - osdev-jの日記 を含むブックマーク

http://www.alles.or.jp/~thisida/mycputop.html (via 陰気な男でいいですか?

専用のライターソフトを使って、あそこをこう、ここをこう、と記述して、結果として8080やZ80と同じ動作をするものを作り上げたとしたとしても、それって、バーチャルとどこが違います?

どこまで降りるかというのは難しい問題で、自分の中でも相当に迷いがある。

俺アーキ本でFPGAを選択している理由は「現実のデバイスと繋がる」と「安い」の2点。

もっとも、世間的にはTTL派が多数派だと思う*4し、あくまで、方向性の違いでしかない。

現実と繋がるために

現実のデバイスと繋がるという点では別に汎用ロジックICで出来なくはなくて、http://www.mycpu.eu/ では実際にVGAとかIDEも繋がってるし、TCP/IPも有る。

しかし、USBを繋ぎたいとなると(専用のホストコントローラを使わない限りは)かなり難しくて*5FPGAを使わざるを得ない。

USBデバイスと接続することにどれくらいの価値を見出すかは人それぞれかも知れないが、個人的にはこれが最大の動機となっている。

TTLFPGAの位置づけ

CPUの創り方』でも、FPGAは後段階と位置づけていたけれど、これは現状を考えると絶妙な問題で、個人的にはFPGAから論理回路に入っても良いんじゃないかと思っている。

  • FPGAボードは有るけどTTLボードはない

電源を入れてすぐ使える。

もちろんTTLをブレッドボードに挿しても良いのだけれど、カウンタ以上のものをアレで作るのはなかなか難しい。

  • FPGAにも動作限界はある

FPGAだって、書いたとおりに動くクリーンな世界では無い。

50MHzを越えた辺りからは適切に問題を分割するセンスが必要になるし、論理回路に落とせるように問題を変形する必要は常にある。

確かに、FPGATTLに比べて大容量過ぎるし、論理の圧縮などは論理合成ソフトウェア任せになってしまうのでその辺の理解が難しいかも知れない。しかし、個人的にはこれらの単元は(未だに滅んでいない)手続き型言語でのプログラミングに移しても良いんじゃないかと考えている。

論理合成とその最適化の仕組みは関数型言語のようなパラダイムを勉強すれば自然に理解出来る。要するにアレはパターンの照合と還元で出来ている。

  • 費用対効果

これは本当に難しい問題で、個人的にはFPGAの方が絶対的に費用対効果は良いと信じているけれど、重み付け次第で簡単に結論は変わる。

TTLの世界から出るためにはFPGAに投資するしかない。じゃぁ最初からFPGAで良いよねとなったときに、次の比較的単純な対立を考える。

  1. 料理教室でハンティングから教えることは希である
  2. 普段は鉛筆やシャーペンだけど毛筆のテクニックは必要

TTLはハンティングなのか毛筆なのか、はたまた、目的は習字教室なのか料理教室なのか。と。

FPGAの非現実感はどこから来るのか

むしろTTLの現実感をFPGAで手に入れるにはどうすれば良いのかという問題だけれど、たしかにFPGAでカウンタを作るよりも、ブレッドボードにTTLを並べてカウンタを作った方が現実感が有る。

個人的には、FPGAVGAUSBが繋がったのは8進カウンタをTTLで作るのと同じくらい感動できるけれども。。

興味深いのはTTLの方が現代的にはずっと非現実で、FPGAの方が見た目が「普通」というところか。つまり、その辺にありふれているモノは動いて当たり前という意識が働くために感動が薄いのではないだろうか。

TTLを外見上動かない状態に持って行くのは容易で、配線さえしなければそれで良い。しかしFPGAボードに取り付けられたFPGAは、その時点でいまにも動き出しそうだ。

*1:本来的にはIPv6のHop LimitがIPv4の世界に問題を起こしてはいけないはずで、どちらかしか無い世界ではこういう問題は発生しない。

*2:しかし、ファイルシステムとは決定的に異なる点が一つだけある。ファイルシステムには過去が有るがネットワークが過去に戻ることは無い。

*3http://www.kame.net, http://ipv6.2ch.net

*4:教育用デバイスとしては

*5:12MHzで動くロジックをTTLで組むのは通常のヒューマンには難しい

トラックバック - http://osdevj.g.hatena.ne.jp/osdevj/20080803