はじめに

この記事は IPv6 Advent Calendar 2019 の 16日目の記事として投稿しています。

TL;DR

Cisco(や、何故かそれに酷似した設定体系)のIPv6ルータで、意図せず

 ipv6 nd ra suppress

と設定するケースが多いよう(Googleで検索に引っかかりやすい？)

 ipv6 nd ra suppress all

の誤りであることが多いので、設定の見直しをしてみてね、というお話。とにかく all をつけるのだ!!

この記事自体は、JANOG44 での IPv6トラブルシューティングMini の焼き直しです。

なぜ `ipv6 nd ra suppress` はだめなのか

all をつけないと何が起きる？

“all” をつけなくても、定期的なRA送出は抑制されるので、⼀⾒、RA抑制ができたように思えます。しかし、この状態でも、RS(Router Solicitation)パケットを受け取ると、RAを返してしまいます。

よくある？のは、Auto-configuration が On なノードがリンクを上げたタイミングで送出する RSパケットを受け取ってしまうケース です。

自動設定でつけられる IPv6アドレスには寿命があります。defaultの設定¹では30日後です。

で、運悪く、30日間、RA が流れないと、寿命が過ぎてアドレスが無効化します。

expire した、そのあと〜 direct connect経路の喪失〜

意図せず自動設定が On になったノードであろうとも、おそらくは手動で

IPv6アドレス設定
gatewayの設定

は行われているかと思います。たとえば、2001:db8::cafe/64 を手動でつけると

手動でつけたアドレス
- 2001:db8::cafe
それに伴う on-link prefix
- 2001:db8::/64

　が生成されます。この時、RA を受け取るとなにが起きるのか？

　前者は"an address configured by sateless autoconfiguration" (RFC4862 5.5.3 e)ではないので、RAのライフタイムの影響を受ません。後者はRFC4861のPrefix Listの要素として管理されているので、RFC4861 6.3.4 にしたがってライフタイムも更新されます。

つまり、ワーストケースで、1ヶ月後に 2001:db8::/64 の経路が喪失してしまうということになります(実際に疎通性が失われるかどうかは、実装に依存）。この結果、gatewayの設定を global unicast adderss で指定しているケースでは、gatewayへの到達性がなくなるという結果になります。

影響を受けないケース

そもそも自動設定を無効化したホスト
- まぁ固定でアドレスつけるなら、無効化しとけという話ではあります。
next-hop に IPv6 global unicast address ではなく、link-local address を利用したケース
- ただしこの場合も、同じ /64 な prefix を使った同一セグメントのサーバとの通信がNGになる。
static でつけたときの /64 の経路を消えないように対処した？実装もある模様

allなしコマンドってバグ？

いいえ、だそうです。懐かしのISATPでは、tunnel を通じて RA を流します。ルータでは tunnel を通じて multicast パケットを流すのが難しいので、RS にだけ答えるモードが求められて、実装されたそうです。今となっては、という感じでしょうか。

まとめ

細かいことはいいので

 ipv6 nd ra suppress all

って書こうぜ！！いまだに all な設定が抜けているルータを各所でみるので、いますぐ見直そう！

RFC4861: Router Configuration Variables内のAdvValidLifetimeの default値に従っている実装が多い(2592000 seconds (30 days)) ↩