三つとも、一致。
routerの照合台が、三枚のroute cardを青く光らせた。
/0。
/32。
/64。
どれも、第20話でイトが送った受領票packetのdestinationに合っている。
遠隔練習gateまで届いた光跡を、labが最初のrouter直前へ巻き戻したのだ。
三枚のcardは、それぞれ別の出口につながっている。
左は、広い外向きlane。
中央は、遠隔gateへ近そうに見える短いlane。
右は、暗い壁の向こうへ曲がる細いlane。
このlabのdispatch windowは、八秒。
時間内に正しいentryを選ばなければ、次のsegment laneは接続されない。
イトは、見た目がいちばん短い中央laneへ手を伸ばした。
イト
三つとも宛先に合うなら、近そうな出口でいいよね
ユイ
でもrouterは、道の見た目を見られるんでしょうか
ピコ
手元にあるのはdestinationと、三枚のentryだよ
残り七秒。
destinationに、道順は書かれていない
packetのIPv6 headerには、遠隔gateを指すdestination addressがある。
だが、左、中央、右という出口名はない。
「次は二番目の門へ」といったpath一覧も入っていない。
routerは、packetをfinal recipientへ一気に飛ばす装置ではない。
いまいる地点から、次の一歩を決める。
そのための照合台が、FIBだ。
FIBは Forwarding Information Base の略で、packetをforwardするときに調べるentryを持つ。
各entryには、destinationの範囲を表すprefixと、そのentryを選んだときのnext hopやoutgoing interfaceが結び付いている。
next hopは、いまのrouterから次に渡す相手。
outgoing interfaceは、その相手へ出すために使う出口だ。
マコト
最終目的地と、次に渡す相手は同じとは限らないんだね
イト
destinationは最後まで遠隔gate。でも、このrouterは一歩だけ選ぶ
残り六秒。
/0も一致する
照合台が、destination addressを一本の長いbit ribbonにした。
route cardのprefixは、その先頭と比べるpatternだ。
/32なら、先頭32 bitぶん。
/64なら、先頭64 bitぶん。
今回のdestinationは、二枚のpatternとそれぞれの長さまで一致した。
では、/0はなぜ光ったのか。
/0は、比べる先頭bitが0個だ。
何も違わないことを求めるため、どんなdestinationにも一致する。
default routeとして使われる形だ。
つまり、三枚が光ったのは故障ではない。
一つのdestinationに、広い範囲と狭い範囲のentryが同時に一致し得る。
問題は、どれを勝たせるかだ。
三つの選び方
照合台が、三枚のdecision cardを出した。
- 最初に並ぶ
/0を選ぶ。どんなdestinationにも一致するから - 物理的に短く見える中央laneを選ぶ。遠隔gateへ近そうだから
- 一致したprefixの中から、prefix lengthが最も長い
/64を選ぶ
一つ目なら、一枚目でlookupを止められる。
first-match leverを倒すだけだ。
だが、それでは後ろにあるspecificなentryを見ない。
二つ目なら、labの立体地図では納得しやすい。
けれど、現実のrouterはlaneの絵を眺めて、地理的に近そうな道を選ぶわけではない。
画面上の線が短くても、network上の条件とは一致しない。
三つ目なら、三枚すべてを比較する必要がある。
先頭32 bitまで合うentryより、先頭64 bitまで合うentryの方が、destinationを狭い範囲まで特定している。
IPv6 forwardingのprefix lengthを扱うRFC 7608は、異なる長さの複数prefixがdestination addressに一致するとき、より長いprefixを使う longest-match-first を説明している。
ただし、overrideするpolicyが設定されている場合は、そのpolicyが関わる。
ここではoverride policyのないlabに絞る。
残り三秒。
ピコ
全部matchした。どこまで長く合った？
イト
道の短さじゃない。prefixの一致がいちばん長いものを見る
イトは、first-match leverへ透明coverを下ろした。
三枚を重ね、最長の一枚を残す
イトは、destinationのbit ribbonを三枚のprefix cardへ重ねた。
/0。
比較するbitはない。match trayへ入る。
/32。
先頭32 bitが合う。これもmatch trayへ入る。
/64。
先頭64 bitまで合う。三枚目もmatch trayへ入る。
イトは、「一致した」というlampだけでは決めなかった。
三枚のprefix lengthを比べる。
もっとも長い/64 cardを、forwarding slotへ差し込んだ。
残り一秒。
cardに結び付いたnext-hop tokenを取る。
右のoutgoing interfaceへ置く。
イトがsend leverを押した。
近そうに見えなかったlaneが開いた
中央の短いlaneは、暗いままだった。
最初に並んだdefault laneも、開かない。
右の壁へ曲がっていた細いlaneだけが、cyanに光った。
packetがrouterを出る。
壁の向こうに隠れていたnext-hop nodeで、受信lampが点いた。
照合台のdestination addressは、変わっていない。
遠隔gateを指したままだ。
routerはfinal destinationを、自分のnext hopへ書き換えたのではない。
FIB entryから次の渡し先と出口を選び、packetを一hopだけ進めた。
遠回りに見えたcyan laneは、壁の裏でnext-hop nodeへ最短に接続されていた。
だが、それは結果として見えたこのlabの形だ。
longest prefix matchが「物理的な最短距離」を保証するわけではない。
勝った理由は、あくまでFIBでdestinationと最も長く一致したentryだったことだ。
一歩進むたび、Hop Limitを一つ使う
packetのheaderで、もう一つの小さな欄が光った。
Hop Limit。
このtraining packetでは、routerへ入る前に9だった。
next hopへ出た後は、8になっている。
IPv6の仕様であるRFC 8200では、packetをforwardするnodeがHop Limitを1減らす。
受信時に0だった場合、または減らして0になった場合、forwardingではpacketをdiscardする。
道順が壊れてpacketがrouter間を回り続けても、無限に残さないための上限になる。
今回のpacketは、9から8。
まだ先へ進める。
だが、一hopを無料で通ったわけではない。
routerはpacketごとにdestinationをFIBへ照合し、winning entryを選ぶ。
forwardするたび、Hop Limitも一つ引き受ける。
ユイ
destinationは同じまま、next hopだけが一歩ずつ変わるんですね
イト
そして一歩ごとに、Hop Limitは減る
マコト
最終地図を持つ荷物と、今の案内をするrouterを分けて考えられるね
default routeは、負けたから不要ではない
三枚のroute cardが、再び照合台へ戻った。
今回は/64が勝った。
だからといって、/0が間違ったentryという意味ではない。
もっとspecificな一致がないdestinationでは、default routeが出口になる場合がある。
広いfallbackがあり、その上に狭いspecific entryが重なる。
specificな行き先が増えても、すべてのdestinationを一件ずつ書く必要はない。
一方、matching entryがなく、default routeもなければ、このrouterはpacketを先へforwardできない。
今回の問いは、routeがFIBへどう入ったかではない。
その作り方や更新、routing protocol、metric、管理policyは、第27話側で扱う。
第21話では、すでにある複数entryから、packet一枚の次の一歩をどう選ぶかだけを見る。
routerへ届く前の空白
labの巨大routerが、家庭用の小さなboxへ戻った。
隣に、tabletが置かれる。
tabletはvideoの次のsegmentを待っている。
packetを外へ送るなら、まずtabletからrouterへ渡さなければならない。
だが二台の間に、cableはない。
さきほどまで床を走っていたcyan laneも消えた。
イトがtabletを持ち上げる。
routerは少し離れた棚の上だ。
空中に、薄い波だけが広がった。
イト
routerが道を選ぶ前に、packetはどうやってここまで届いたの？
ピコ
その最初のlinkには、見えるcableがないね
照合台には、三枚のprefix card。
そのうち最も長く一致した一枚だけが、forwarding slotへ残っている。
packetのdestinationは変わらず、Hop Limitの光だけが一つ減った。
奥では、tabletとrouterの間の何もない空間が青く揺れていた。
次回：cableなしで、packetはrouterへ届く？
routerはdestination addressとFIB entryを比べ、override policyがないこのlabでは最も長く一致するprefixを選んだ。
winning entryが示すnext hopとoutgoing interfaceへ、packetを一歩forwardした。
見た目の近さでも、最初に並んだdefault routeでもない。
その一歩でHop Limitは9から8へ減り、destinationは遠隔gateのまま残った。
次に確かめるのは、routerがlookupするより前のlink。
tabletとrouterの間には、cableがない。
次回、ピコルート第22話。
Wi-Fiはどう空中を通る？
画面のむこう側をもっと知る
家庭用routerの役割、WAN/LAN、packetを外へ送る流れを図で整理するなら、ルーターの仕組みで確かめられます。