第91話：イトは、IPv4を捨てて報告書を送れなくした｜IPv6なら必ず速い？

第90話で見つけたTV Wi-Fiのtest reportが、routerの送信trayに載っていた。

TV content missed       28 seconds
laptop avoidable stall   2 seconds
access point placement   changed

このreportをlab archiveへ送れば、次の調査で使える。

ただしtemporary traceは、三十秒後に消える。

DNS drawerには、同じ宛先名から二枚のaddress cardが出ていた。

name   trace.picoroute.test
A      192.0.2.91
AAAA   2001:db8::91

イトは長いAAAA cardを残し、短いA cardをdiscard slotへ落とした。

「IPv6は新しい。こっちだけなら速い」

IPv6 connectionは始まらない。

十二秒が過ぎた。

reportの残り時間は、十八秒。

DNSの答えは、接続成功のreceiptではない

DNSのA recordは、nameに対応するIPv4 addressを返す入口になる。

AAAA recordは、IPv6 addressを返す。

answerがあることは、そのaddress candidateを知ったという意味だ。

いまのdevice、いまのnetwork、いまのdestinationまでconnectionが成立した証明ではない。

DNS answer received      candidate known
route usable             not decided
connection established   not decided
report delivered         not decided

IPv6 pathが使えない理由は一つとは限らない。

local network、provider path、destination側、security policy、temporary failureなど、複数の境界があり得る。

反対に、IPv4 candidateが古いformatだから失敗するとも限らない。

ユイ

AAAA answerは返りました。でもconnection establishedはゼロです

マコト

A cardを捨てたから、届くかもしれない別候補まで試せない

イト

住所の新しさを、この一回の道の速さにしてた

PicoはIPv4 / IPv6のどちらも選ばない。

DNS drawerと、途中で暗くなったcurrent IPv6 railを別々に照らした。

IPv4とIPv6は、addressの広さが違う

IPv4 addressは32 bitだ。

textでは、192.0.2.91のようにdecimal numberをdotで区切って表すことが多い。

IPv6 addressは128 bitだ。

textでは、2001:db8::91のようにhexadecimalとcolonを使い、連続するzeroを::で縮める場合がある。

ここで使う二つはdocumentation用のexample rangeだ。

実在serviceのaddressではない。

IPv6は、IPv4より大きなaddress spaceを持つ。

この差は、端末やserviceが増えるinternetでaddressを扱うための大きな変更だ。

しかし、128 bitだからpacketがいつも先に到着するという式ではない。

address formatと、current end-to-end pathのlatency / loss / reachabilityを分ける。

よくある誤解：IPv6は新しいから必ず速い

ある環境でIPv6を使うと、IPv4とは異なるpathや接続方式になり、結果として体感が変わることはある。

IPv6 pathの方が速い場合もある。

IPv4 pathの方が先に使える場合もある。

片方だけが届く場合もある。

address family   route qualityではない
DNS candidate    connection successではない
newer format     universal speed guaranteeではない

今回のfixtureでは、trace destinationへのIPv6 pathが途中で止まっている。

IPv6そのものが遅いという結論にはしない。

別destination、別network、別時刻なら結果は変わり得る。

残り16秒の三択

report expiryまで、十六秒。

connectionを同時に大量発生させない。

一方が成立したら残りをcancelする。

両方失敗したらaddress文字列を作り替えず、reportをlocalへ残して送信を止める。

イトはdiscard slotからA cardを拾い、三枚のroute cardを並べた。

イト

A。IPv6-onlyを続け、新しいaddressが通るまで同じrequestを繰り返す

イト

B。長いIPv6文字列を短いIPv4風へ書き換え、同じ宛先だとみなす

イト

C。A / AAAAのidentityを保ち、短い時間差でcurrent connectionを試す

Aは、format preferenceをreachability testの代わりにしている。

Bは、別addressを文字の見た目だけで作っている。

CならIPv6を最初に試しつつ、待ち続ける前にIPv4 candidateも試せる。

fixtureの時間差と順序を、全clientの固定値にはしない。

イトがnew-only filterを閉じ、two-candidate gateを開いた

イトは左手で、new = always fastのamber filterを閉じた。

address文字列を書き換えるconversion chuteにもlockを掛ける。

右手で、A / AAAA cardを元の形のまま通すtwo-candidate gateを開いた。

Picoは止まったIPv6 railのgapだけをinspection lightで分離する。

card、gate、timer、connectionへ触れない。

closed fixtureでは、最初にIPv6 attemptを開始する。

二百五十millisecond後、まだ成立していなければIPv4 attemptを始める。

0 ms     IPv6 attempt starts
250 ms   IPv4 attempt starts
430 ms   IPv4 connection established
431 ms   remaining attempt cancelled

IPv4 connectionが先に成立した。

イトはそのconnectionへreportを一度だけ送る。

reportは届いた。IPv6 pathは直っていない

archiveからreceiptが返った。

report accepted          1
duplicate report         0
selected family          IPv4
time before expiry       14.8 seconds
IPv6 usable now          0

temporary traceは消える前に保存された。

でも、IPv6 pathは使えないままだ。

fallbackはreaderの待ち時間を減らせても、壊れたpathを修理しない。

成功したfamilyだけを記録してfailed attemptを消すと、IPv6 failureが長く隠れる場合がある。

イトはreceiptの横に、IPv6 current path unresolvedを残した。

マコト

reportは助かった。でも、IPv4が勝ったことをIPv6は遅いという結論にしない

イト

使えた道を選び、使えなかった道は未解決として残す

ユイ

fallback成功と、両方のpathがhealthyは別ですね

別の宛先では、IPv6が先に届いた

一つの結果をaddress family全体へ広げないため、別のfixture destinationも同じgateで試す。

DNSはA / AAAAを一件ずつ返した。

今度はIPv6 connectionが百四十millisecondで成立する。

IPv4 attemptを始める前に、選択は終わった。

destination             archive.picoroute.test
IPv6 established        140 ms
IPv4 attempt             not started
selected family          IPv6

最初のdestinationではIPv4。

次のdestinationではIPv6。

選択はnew / oldの人気投票ではなく、candidate order、current reachability、connection resultで変わった。

実際のclientは複数address、過去の結果、network changeなどを含む別の実装を持ち得る。

このfixtureを全deviceのalgorithmにしない。

A / AAAAを見つけた後の診断

nameが引けないなら、まずDNS answerの段で止まっている。

A / AAAAはあるが片方だけ接続できないなら、address familyごとのlocal configuration、network path、destination対応を分けて見る。

両方connection establishedなのにapplication requestが失敗するなら、TLS / HTTP / application stateなど上の段へ進む。

name resolution
  -> address candidates
  -> connection attempts
  -> established path
  -> secure / application request

address literalを当てずっぽうで書き換えない。

retry stormを起こさない。

両方失敗したらlocal dataを保ち、network change、service status、administrator / support確認へ止める。

二枚のaddress cardに、三つの名前が付いた

report receiptの下から、三枚のname cardが出てきた。

upload.picoroute.test
status.picoroute.test
support.picoroute.test

三つともpicoroute.testをparentに持つ。

しかしDNS drawerを開くと、A / AAAAの組み合わせも、向かうserviceも同じではない。

イトはuploadで得たsession ringを、statusとsupportの入口へまとめて通そうとした。

「同じ名字なら、同じ建物の同じ鍵だ」

ringはstatus gateで止まる。

同じparent nameは、same server、same path、same login scopeの証明ではない。

イトは三枚を重ねず、別々の入口へ戻した。

次回、ピコルート第92話。

イトは、同じ親を持つ三つの名前へ一つの鍵を使える？｜サブドメインの境界