10。
遠隔練習gateが、赤い数字を浮かべた。
第19話で、一つのmedia segmentを運んだ47個のpacket。
役目を終えたIPv6 headerは、受信台の上へ残っている。
どのheaderにも、二つの欄があった。
source address。
destination address。
遠隔gateから、新しい指示が届く。
受領票を一枚返せ。十秒以内に届けば、次のsegmentを開く。
これは、このlabだけの練習用packetだ。
HTTPやTCPの標準的な返事を再現しているわけではない。
イトは、空の返信packetへ受領票を入れた。
そして、届いたheaderの destination を、新しいpacketのdestination欄へ写そうとする。
イト
destinationは宛先でしょ。返信も、ここへ送ればいい
ユイ
でも、その印は今いるlabを指しています
ピコ
そのdestinationは、いつの、どちら向きの宛先だろう
残り九秒。
イトの指が止まった。
「destination」は、永遠の宛先ではない
受信台の床に、一本の光跡が戻った。
遠隔gateから、labへ。
いま見ているheaderは、届いてきたpacketのものだ。
IPv6の仕様であるRFC 8200では、IPv6 headerに次の二つのfieldがある。
- source address: packetを作ったoriginatorのaddress
- destination address: packetが意図するrecipientのaddress
この受信packetでは、originatorは遠隔側。
intended recipientはlab側だ。
だから受信headerのdestinationは、正しくlabを指している。
だが、これから作るのは逆向きの新しいpacketだ。
同じ位置へ返すための印ではない。
sourceとdestinationは、そのpacketの向きに対する役割なのだ。
マコト
届いた封筒の『宛先』は、受け取った自分の住所か
イト
それを返信用封筒の宛先へ写したら、自分へ返すことになる
残り七秒。
三枚の返信card
受信台が、三枚の処理cardを開いた。
- 届いたheaderを丸ごと複製し、sourceもdestinationも変えない
- destinationはいつも宛先だと考え、受信destinationを新しいdestinationへ写す
- 新しい向きに合わせ、受信sourceを新しいdestinationへ置き、lab側の有効なaddressを新しいsourceとして選ぶ
一つ目なら、もっとも速い。
copy leverを一回倒すだけでいい。
だが、元のheaderは遠隔側からlab側への向きだ。
複製しても、向きは変わらない。
二つ目なら、「destination」というfield名に忠実に見える。
けれどその値は、届いたpacketでのrecipient、つまりlab側だ。
新しいpacketもlabへ向かう。
影の実験laneで、受領票がくるりと曲がった。
遠隔gateへ出ず、イトのいる受信台へ戻ってくる。
三つ目は、headerを新しく組み立てなければならない。
受信sourceだった遠隔側を、新しいdestinationへ置く。
そしてlab側から、新しいsourceとして使うaddressを選ぶ。
残り五秒。
ピコ
field名を写す？ それとも、新しいpacketの役割を決める？
イト
届いたheaderは、届いた向きの記録として残す
イトは、copy leverのcoverを閉じた。
受信headerを、書き換えない
イトは、47枚の受信headerを台から捨てなかった。
sourceもdestinationも、書き換えない。
それらは「遠隔側からlabへ届いた」という証拠だからだ。
代わりに、空の返信packetを一枚、組立台へ置く。
受信headerのsourceから、遠隔側を示す光のtokenを読む。
それを、新しい destination address 欄へ入れた。
次に、lab側のaddress候補を開く。
一つではなかった。
IPv6 Addressing ArchitectureのRFC 4291では、IPv6 addressはnodeそのものではなくinterfaceへ割り当てられ、一つのinterfaceが複数のaddressを持てる。
そのため、「この機械の住所を一つ写す」だけでは決まらない場合がある。
このlabの組立台には、いま使える候補が二つ光った。
イトは、受信時にlab側で使われたaddressと候補の状態を確かめ、今回の返信に使えるものを一つ選ぶ。
それを、新しい source address 欄へ入れた。
残り二秒。
ユイ
受信packetを裏返したのではなく、新しいpacketを作ったんですね
イト
うん。向きが変わるから、役割を選び直した
イトが送信leverを押す。
返信packetは、labを出た
空だった外向きlaneに、一本の光が走った。
返信packetは、受信台へ戻らない。
labの出口を通り、最初のrouterへ向かう。
routerの向こうで、遠隔練習gateが受領票を受け取った。
赤い数字が、1で止まる。
その横に、青い受領印が点いた。
gateが開く。
閉じていた次のsegmentが、青いlaneへ送り出された。
screenのbufferには、次の一箱を待つ空きがある。
イトが選んだ返信先によって、次の練習を続けられるようになった。
network台には、二つの記録が残った。
- 受信packet: 遠隔側がsource、lab側がdestination
- 返信packet: lab側がsource、遠隔側がdestination
二つの向きは反対に見える。
では、返信では必ずsourceとdestinationを交換すればよいのだろうか。
「いつもswap」ではない
多くの単純な返信では、受信packetのsourceを返信先にできる。
受信packetのdestinationとして使われたaddressを、返信側のsourceにできる場合も多い。
Default Address Selection for IPv6のRFC 6724も、多くの場合、responderは受信packetのsourceをresponse destinationに、受信packetのdestinationをresponse sourceに使えると説明している。
だが、「二欄を無条件にswapすれば完成」という万能規則ではない。
受信destinationがmulticast addressだった場合など、そのままresponse sourceにはできない場面がある。
interfaceが複数のaddressを持つときは、どのsource addressを使うか選ぶ必要もある。
applicationや上位層が明示的に選ぶ場合もあれば、実装のaddress selectionへ任せる場合もある。
だからイトが覚えたのは、交換の手順ではない。
まず新しいpacketのoriginatorとintended recipientを考える。
その結果として、単純な一対一の返信では二つの役割が反転して見える。
マコト
sourceはいつも遠隔service、destinationはいつも自分、ではないんだね
イト
packetが逆向きになれば、誰が送る側かも変わる
ピコ
名前ではなく、そのpacketでの役割を読めたね
最終宛先はわかっても、道順はない
受領票を運ぶ返信packetが、最初のrouterの前で止まった。
headerのdestinationは、遠隔gateを指している。
迷子ではない。
けれど、packetの外側をいくら見ても、通る門の一覧は書かれていなかった。
左のlane。
中央のlane。
右のlane。
routerは三つの出口を開いている。
destinationは、最終的に誰へ届けたいかを示す。
それだけで、ここからどの出口へ進めばよいかを一行ずつ命令しているわけではない。
イトは、受信headerと返信headerを透明台へ並べた。
受信packetの光跡は、遠隔側からlabへ。
返信packetの光跡は、labから遠隔側へ。
二つのheaderは、別の向きを記録した別物のまま残る。
その先で、routerの三つの出口だけが消えなかった。
イト
誰に届けるかは決めた。でも、次にどのlaneへ出すの？
ピコ
それを決めるのが、次の案内役だ
次回：routerは、最終宛先を見て最初の一歩をどう選ぶ？
source addressとdestination addressは、機械に永久に貼られた「送る側」「受ける側」の名札ではない。
そのpacketで誰がoriginatorか、誰がintended recipientかを示すfieldだ。
イトは届いたdestinationを返信先へ写さず、新しい向きに合わせてheaderを組み立てた。
受領票はlabへ戻らず、遠隔gateへ届いた。
ただし、単純な返信で二つの役割が反転して見えても、常に無条件でswapするわけではない。
最後に残ったのは、遠隔側をdestinationに持つ一枚の返信packet。
その前には、三つのrouter出口。
次回、ピコルート第21話。
routerは、どの道を選ぶ？
画面のむこう側をもっと知る
IP addressの基本、private/public、IPv4/IPv6を図で整理するなら、IPアドレスとはで確かめられます。