要約

  • RFC 1234 は 1991 年に IPX-over-UDP を定め、実装が IP internet を単一の IPX network と見なすことを可能にした。既知の host については、IPX host number の後ろ四 octet が node の IP address となり、unicast の対応が直接になる。
  • broadcast はそのまま広がらない。server と router は手作業で作る peer list を保ち、要求された broadcast ごとに各 peer へ一つずつ unicast を送る。RFC は、broadcast が server peer group 全体へ届く傾向がなければ、resource は end system から見えても到達不能になり得ると述べる。

一つの network という表現が扱った範囲

RFC 1234 の問題設定は明快である。IP だけを運ぶ internet の上で、IPX をどう運ぶか。UDP encapsulation がその経路をつくる。さらに IPX host number の最初の二 octet を zero にし、最後の四 octet を node の IP address にすることで、既知の宛先への unicast は読み替え可能になる。

だが、この仕組みは IP internet を物理的に同じ LAN にするものでも、一つの運用主体や security domain にするものでもない。RFC が許しているのは implementation の見方である。誰が service discovery の問いを受け取るべきか、そして実際に受け取ったかは、別の条件として残る。

IPX では、同じ network を共有する NetWare server と IPX router が互いを見つけるために broadcast facility が必要だった。既知の address への packet delivery と、関係する全員へ「どこに router があるか」と尋ねる delivery は別の作業である。後者には、宛先集合を決め、それぞれへ送る仕組みがいる。

broadcast は媒体の性質ではなく peer list の仕事になった

RFC 1234 は internet-wide IP broadcast を appropriate でも available でもないとする。代わりに、各 server と router は manually constructed な IP peer list を維持する。IPX が broadcast を求めると、encapsulation implementation は list の各 peer に separate unicast packet を送る。

ここで broadcast の範囲は共有媒体から自動的に生まれない。list に誰が載っているか、コピーが各 peer に届くかによって決まる。RFC は、list が手で作られるため、同じ IP internet を share しながら互いを知らない複数の peer group が存在し得るとも説明する。一つの group に属する list は、その group のすべての peer を含むべきである。

したがって、二つの site 間に IP path があることも、tunnel が両者を一つの logical IPX network として扱えることも、同じ discovery request が完全に届いた証拠ではない。underlay の共有と、問いの到達範囲の完全性は同じ事実ではない。

client にも全体へ尋ねる役目があった

この責任は server 側だけにない。IPX network の client は、望む destination に届く router を発見するため broadcast を送る必要がある。RFC 1234 は client implementation にも、peer group のすべての server と router の IP addresses を持つ configured list を求め、その各 address へ packet copy を送らせる。

発見の成否は、server/router が持つ list の完全性と、client がすべての relevant server peer groups に問い合わせることの両方に依存する。既知の unicast を正しく運べる tunnel でも、list から漏れた peer、古くなった address、group の一部に継続して届かない copy を自動では直せない。

RFC の警告は条件付きである。そうした packets が server peer group 全体へ届く傾向がなければ、IPX internet の resources は end system から visible でありながら、その system には unreachable になり得る。これは特定の outage、operator、topology を報告しているのではない。route を見つける discovery が全 group を覆わないとき、見えることと使える経路を得ることが分かれ得る、という protocol condition を示している。

known host の address は group membership を決めない

設計には非対称性がある。known host の location は header の IPX host number から読める。broadcast は「誰がこの問いを聞く必要があるか」を問う。その答えは packet の中にはなく、変更可能な list と、それを保守する判断にある。RFC 1234 は IP topology をその問いの自動回答にはしなかった。

RFC は IP multicast が将来使えるかもしれないとしつつ、当時は広く available ではなく、well-known address も implementation もなかったと記す。これは単なる古い制約ではない。list を multicast や registry へ替えても、member を定義し、delivery の欠落を示し、同じ transport を share する groups の境界を保つ仕事は残る。

default IPX MTU は 576 bytes、encapsulation 後の IP total は 604 bytes で、参加する IP systems はその大きさを受け入れなければならない。UDP checksum は optional だが、IPX が通常 checksum を用いないため strongly recommended である。これらは tunnel を成立させる条件であって、peer list を完全にする条件ではない。

情報源と証拠の限界

本稿の閉じた source set は RFC 1234, Tunneling IPX Traffic through IP Networks のみである。日付、UDP encapsulation、host-number convention、peer list、client discovery、visible だが unreachable になり得る条件、MTU、checksum、security considerations を裏付ける。特定の deployment、実際の failure、組織の topology、今日の利用状況、UDP port 213 の現在の状態は裏付けない。