どうでもいいけど、ボストンからニューヨークへの Amstrak の中からやった traceroute。

% traceroute -q1 www.kantei.go.jp
traceroute to www.kantei.go.jp (202.232.146.151), 64 hops max, 52 byte packets
 1  10.0.2.1 (10.0.2.1)  3.448 ms
 2  192.168.65.254 (192.168.65.254)  112.029 ms
 3  h-vl260-d3.acc.dca2.hopone.net (207.228.236.2)  277.486 ms
 4  gec2.core2.dca2.hopone.net (66.36.224.233)  1561.845 ms
 5  ge6-1.core1.iad1.hopone.net (66.36.224.198)  1415.138 ms
 6  abn001bb00.iij.net (206.223.115.23)  134.216 ms
 7  sjc002bb00.iij.net (216.98.96.174)  1265.895 ms
 8  tky001bf00.iij.net (216.98.96.102)  586.310 ms
 9  tky008bb01.iij.net (58.138.80.242)  2068.369 ms
10  tky008sdgw00a.iij.net (58.138.104.114)  1639.443 ms
11  *
12  210.138.70.178 (210.138.70.178)  1391.981 ms
13  202.232.146.194 (202.232.146.194)  450.740 ms
14  *
^C
% 

「.se と DNSSECと IPv6」で a.ns.se が反応し無かった理由が分かった気がする。([gj].ns.se の問題はまだ考えてない)

■ トポロジ

a.ns.se <> Internet <A> X <B> Y

• <A> の MTU は 1500 bytes
• <B> の MTU は 1445 bytes (tinc による tunnel を使用)

X と Y はホスト。

■ 問題

• あるホスト(上図 X)で実行した dig @2a01:3f0:0:301::53 se. ns +dnssec に反応がない
• ただし X のクエリをインタフェース A で観測してると、a.ns.se からフラグメントされたパケットの断片が届く (フラグメントの2片目のみ) (*)
• Y で実行すると問題ない
• a.ns.se からの返答のサイズは 2706 bytes (Y での結果より)

(*) こんなの

IP6 (hlim 56, next-header Fragment (44) payload length: 1274) 2a01:3f0:0:301::53 > 2001:xxxx:xxxx::x: frag (0x00615ecc:1448|1266)

■ MTU の観測

まず初めに、どうせ MTU の問題だろうと当たりをつけて、X から ping6 で MTU を推測してみる

> ping6 -s 1432 -m 2a01:3f0:0:301::53
PING6(1480=40+8+1432 bytes) 2001:xxxx:xxxx::xxxx --> 2a01:3f0:0:301::53
1440 bytes from 2a01:3f0:0:301::53, icmp_seq=0 hlim=56 time=105.266 ms

> ping6 -s 1433 -m 2a01:3f0:0:301::53
PING6(1481=40+8+1433 bytes) 2001:xxxx:xxxx::xxxx --> 2a01:3f0:0:301::53
^C
(注：ICMPv6 Packet Too Big も返ってこない)

このことから、

• X から a.ns.se までの Path MTU は 1480 bytes で、多分 IPv6-over-IPv4 トンネルを使っている (IPv4 ヘッダ 20 byte を足すと、ちょうど Ethernet の MTU 1500 bytes になるから)
• トンネルを終端してるルータが Packet Too Big を返さないらしい

ことが分かった。

■ DNS の観測

次に実際の DNS のクエリへの応答を、bufsize を変化させながら観測した。

>dig @2a01:3f0:0:301::53 se. ns +bufsize=1571 +dnssec

[snip]
;; Query time: 108 msec
;; SERVER: 2a01:3f0:0:301::53#53(2a01:3f0:0:301::53)
;; WHEN: Thu Apr 15 21:33:51 2010
;; MSG SIZE  rcvd: 1410

>dig @2a01:3f0:0:301::53 se. ns +bufsize=1572 +dnssec

; <<>> DiG 9.6.1-P2 <<>> @2a01:3f0:0:301::53 se. ns +bufsize=1572 +dnssec
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

>dig @2a01:3f0:0:301::53 se. ns +bufsize=1409 +dnssec

[snip]
;; Query time: 105 msec
;; SERVER: 2a01:3f0:0:301::53#53(2a01:3f0:0:301::53)  
;; WHEN: Thu Apr 15 21:35:31 2010
;; MSG SIZE  rcvd: 1248

>dig @2a01:3f0:0:301::53 se. ns +bufsize=1247 +dnssec

[snip]
;; Query time: 108 msec
;; SERVER: 2a01:3f0:0:301::53#53(2a01:3f0:0:301::53)
;; WHEN: Thu Apr 15 21:36:23 2010
;; MSG SIZE  rcvd: 1086
>

このように 1571 bytes を境に応答がなくなってる。

手始めに、メッセージサイズ(MSG SIZE)が 1410 bytes なので試しに bufsize を 1409 bytes にしてクエリを送ったところ、メッセージサイズが 1410 bytes から 1248 bytes になった。さらに bufsize を 1247 bytes にしたらメッセージサイズは 1086 bytes となった。このことから、おそらく(bufsize に余裕があれば)メッセージサイズは 162 bytes ずつ増加することが予想される。

そこで 1410 + 162 を計算すると 1572 となる。つまり、bufsize が 1572 bytes より大きいとメッセージサイズも 1572 bytes になることが予想される。(というか、Y から実行したら確かにそうなった。)

■ 仮定

上記 DNS の観測から、(応答)メッセージサイズが 1410 bytes までは問題ないが、1572 bytes になると応答がなくなることが確認できた。これは、1410 bytes まではフラグメントが必要なかったが 1572 bytes ではフラグメントが必要になるからだと推測する。ここで、

a.ns.se は MTU 1500 (Ethernet の標準の MTU)でパケットを送信しようとしている

と仮定し、これを検証してみたい。

MTU が 1500 bytes の時、IPv6ペイロードに使えるのは、IPv6ヘッダを除いて、
1500 - 40 = 1460

フラグメントする場合、8 bytes 境界で分割した上で 8 bytes のフラグメントヘッダを付加するので、実際にペイロードに使えるのは、
1460 -> 1456 - 8 = 1448

このうち 8 bytes は UDP ヘッダに使うので、DNSのクエリ応答のデータのうち、実際に1パケット目に詰め込めるのは、
1448 - 8 = 1440

応答のメッセージサイズが 2706 bytes であることは分かっているので残りは次の通り。
2706 - 1440 = 1266

1226 bytes のデータをフラグメントされた2パケット目で送ると、IPv6ペイロードのサイズ(IPv6ヘッダは除き、フラグメントヘッダは含む)はこのようになる。
1266 + 8 = 1274

これは、上記 (*) の観測結果とも一致する。つまり、a.ns.se は Path MTU を 1500 bytes と仮定してパケットを送出しているという仮定は正しいらしい。

■ 結論

仮定の中で計算したように、a.ns.se の1パケット目は 1496 bytes (= 40 + 8 + 8 + 1440) となるが、これは MTU の観測でみたように Path MTU である 1480 bytes のトンネルを通過できない。本来なら、そこで ICMPv6 の Packet Too Big が返り、a.ns.se がパケットを小さくして再送することになるのだが、恐らくその ICMPv6 メッセージが送られていないのだろう。したがって、a.ns.se は正しくパケットが配送されたとみなし、フラグメントの2片目を送り通信を終了している。

というわけで諸悪の根源は、

• Packet Too Big を返さないルータ
• トンネル技術そのもの

といったところだろうか。(しかし、この種の問題が繰り返し発生しているのを見ると、IPv6 ではルータはフラグメントしない、とした判断は果たして正しかったのだろうか？という疑問が浮かんでくる)

さて、誰か経由で、.se の人にコンタクトしてもらうべきか？(追記：と思ったけど、他のASからテストしたところ、そっちからは問題なかった。とすると、.se にあまり近くないところにトンネルがあって、そこが問題になってるっぽいな。とすると、.se の人にコンタクトしても意味ないかも。)

■ おまけ

Y も実はそのままでは通信できない。一度、+bufsize=1571 (1410 から 1571 の値)でクエリを出す必要がある。

理由：

+bufsize=1571 でクエリを送ると、a.ns.se は 40+8+1410 = 1458 bytes のパケットを送ってくる。しかし、<B> の MTU が 1445 bytes なので、X は「MTU は 1445 だよ」とした上で Packet Too Big を返送する。

IP6 (hlim 254, next-header ICMPv6 (58) payload length: 536) 2001:xxxx:xxxx::xxxx > 2a01:3f0:0:301::53: ICMP6, packet too big, length 536, mtu 1445

それにしたがい a.ns.se は、

1パケット目 40 + 8 + 8 + 1384 = 1440
2パケット目 40 + 8 + 1322 = 1370

というパケットを再送し、正常に通信が終わる。

なお、Packet Too Big が a.ns.se まで到達してることから、ICMPv6 が無闇にフィルタされてるわけではなさそうなことが分かる。また、その後、+bufsize を 1572 より大きくしても、a.ns.se は Y への Path MTU を(一定期間は)覚えているので、きちんとフラグメントされてパケットが送られてくる。

想像：

ちなみに、Packet Too Big が a.ns.se に送られてない理由の一つとして uRPF が考えられる。実は別の場所でも発生していたのだが、仕掛けはこうだ。

1. ルータは Packet Too Big を返す
2. ただし、その src address に routable でないアドレスがついてしまった
3. 途中のルータが IPv6 uRPF を動かしていて Packet Too Big を叩き落とす

ざっとこんな感じである。ルーティングを行なう上でルータのインタフェースのアドレスは必ずしも routable である必要はないので、割と見落とされやすい上に、解決に時間がかかるたぐいの問題である。