2019 IPv6 アドベントカレンダー

1. IPv6 マルチプレフィックスの話
SFC Murai Lab. M2 yas-nyan
Notice:2019年1月に研究室でLTに利用した内容の焼き直しです．情報が古い可能性があります．

2. IPv6 マルチプレフィックスについて
● IPv6環境では同一NICに複数のユニキャストアドレスを付与することを想定してい
る[1]。リンクローカルは勿論のことグローバルユニキャストアドレスも複数付与可能
である。
● 特に異なるプレフィックスのアドレスを名乗ることをマルチプレフィックスと言う。(日
本以外ではあんまり言わない?)
● 両方のアドレスからインターネットに疎通性がある状況をマルチホームと言う。
[1] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.

3. IPv6 マルチプレフィックスの実例
複数のプレフィックス &IPv6グローバルユニキャストアドレス
複数のデフォルトゲートウェイ
複数のルーター(RA)

4. 日本におけるIPv6 マルチプレフィックス問題
● 東西フレッツ閉域網(通称NGN)ではGUAが使用
されている。
● インターネットへの接続性を持つISPアドレスと
NGN用のアドレス間でのマルチプレフィックス問
題が広く議論された。[2](RFC 7157)
● 結局、NGNではIPoE方式・PPPoE方式のいず
れかによってクライアントに複数のプレフィックス
を与えない方法で決着した。[3]
[2] Troan, Ole, et al. Ipv6 multihoming without network address translation. No. RFC 7157. 2014.
[3] NGNのISP接続（PPPoEとIPoE）に関する 当面の方向性 - 総務省 http://www.soumu.go.jp/main_content/000532520.pdf
https://tech.nikkeibp.co.jp/it/article/COLUMN/20080908/314339/

5. IPv6 マルチホーム環境、何が問題か
● 送信元アドレス選択問題
● デフォルトゲートウェイ選択問題
● 送信元アドレス + デフォルトゲートウェイ不一致
問題
● (DNSサーバー選択問題)
[4]小川晃通.プロフェッショナル IPv6.ラムダノート , 72018

6. 送信元アドレス選択問題
概要：
アプリケーションは、IPv4/IPv6デュアルスタック時と同様に、どのアドレスを送信元ア
ドレスとして利用するかを選択する必要がある。RFC 6724[5]では8のルールが定め
られている。
アドレス種別による優先度をポリシーテーブルに記述することでアドレス選択に利用し
ている。
問題：
ポリシーテーブルがデフォルト値の場合、グローバルv6アドレスのうちどのアドレスが選択されるかは適当っぽい
(最終的には宛先アドレスとの一致度などランダムな要素に影響されてしまう。)
同一アプリケーションでも宛先アドレスごとに送信元アドレスが入れ替わる可能性
[5]Thaler, D., et al. Default address selection for internet protocol version 6 (IPv6). No. RFC 6724. 2012.
6

7. デフォルトゲートウェイ選択問題
概要：
マルチプレフィックス環境ではネクストホップとなりうるルーターのアドレスは複数候補
存在しうるので、クライアントが適切に選択する必要がある．
問題：
RAでの「preference値」設定をデフォルトに設定した場合、どちらのルーターが選択
されるかは実装依存
● RFC 8028 (PROPOSED STANDARD)[7]：(送信元IPアドレスを決定した上で)RA送信元のルーターに送信
○ Linux未実装?
● NEW RFC 8475 (Informational)[7] ：デフォルトゲートウェイのルーターがポリシーベースでルーティングすることでマ
ルチホーム環境を実現
[6]Baker, Fred, and Brian Carpenter. First-Hop Router Selection by Hosts in a Multi-Prefix Network. No. RFC 8028. 2016.
[7]Linkova, Jen, and M. Stucchi. Using Conditional Router Advertisements for Enterprise Multihoming. No. RFC 8475. 2018. 7

8. アドレス・デフォゲ不一致問題
● 通常、ISPではDDoS攻撃などの送信元となる
ことを防ぐために、送信元アドレスの整合性を
確認するオペレーションを行っている。
○ BCP 38(RFC 2827[8])
○
● 誤ったルーターをGWにするとパケッ
トが届かない。
○ 仮に送信出来たとしても、 Statefull
packet inspection環境では落とされる。
[8] Ferguson, P., and D. Senie. "RFC2827 (BCP38): Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. IETF, May
2000."
prefix A prefix B
Addr AAddr B
Router A Router B

9. IPv6マルチホーム環境①
概要：同一リンク上のルーター２台がそれ
ぞれ別のISPに接続されている
想定される問題：
● 送信元アドレス選択問題
● デフォルトゲートウェイ選択問題
● 送信元アドレス + デフォゲ不一致問
題.
[4]小川晃通.プロフェッショナル IPv6.ラムダノート , 72018

10. IPv6マルチホーム環境②
概要：ルーター1台が複数のISPに接続さ
れている
想定される問題：
● 送信元アドレス選択問題
環境によって顕在化する問題：
● デフォルトゲートウェイ選択問題
● 送信元アドレス + デフォゲ不一致問
題[4]小川晃通.プロフェッショナル IPv6.ラムダノート , 72018

11. IPv6マルチホーム環境③
概要：端末の複数のNICからそれぞれ別に
ネットワークに接続される
想定される問題：
● 送信元アドレス選択問題
● デフォゲ選択問題
[4]小川晃通.プロフェッショナル IPv6.ラムダノート , 72018

12. 検証
実験環境：GNS3
ルーター：vyos 1.1.8 x2
ルーター間はEBGPで経路交換
クライアント：
Alpine Linux(Kernel 4.4.0)
- RA+SLAACでアドレスを取得
- mtrで送信元アドレスと経路を確
認
実験で確かめたいこと：
マルチプレフィックス下の Linuxの
振る舞いが知りたい！
● source addressの選択
● next hopの選択
送信元ホスト 宛先ホストprefix A
prefix B
Addr A
Addr B
Dest. prefix
p2p prefix
prefix A: 2001:1::/64
prefix B: 2001:2::/64
Dest. :
2001:1000::100/64
Rtr A
Rtr B

13. 結果
1. preference値をどちらも同じ値(middle/low/high)にした場合
Addr A Rtr B Rtr A Dest. Addr
⇢送信元アドレスにAが選択されたのにも関わらず RtrBがネク
ストホップに選択された。
2. Rtr Aのpreference値をHighに,Bをmiddleにした場合
Addr A Rtr A Dest. Addr
Addr A Dest. Addr
3. 2でRtr Aを落としてみた．
Rtr B Rtr A
⇢送信元アドレスにAが選択されたのにも関わらず RtrBがネク
ストホップに選択された。

14. まとめ
● ルーター側でRAでPreference値を設定[9]することで、優先されるデフォルトゲート
ウェイを任意に変更することは一応可能。
● が、送信元アドレスとネクストホップ選択に関連性はない。
○ RFC 8028は実験環境では未実装らしい
● マルチプレフィックスは現状かなりしんどい．
○ 当面マルチホームは IPv4と同じようにNATで対応する形が良さそう．
[9]Draves, Richard, and Dave Thaler. Default router preferences and more-specific routes. No. RFC 4191. 2005.