IPv6標準化の最新動向

For The Guaranteed Network
© ALAXALA Networks Corp. 2009. All rights reserved.
IPv6標準化の最新動向
アラクサラネットワークス(株) 営業本部
鈴木伸介 <suz@alaxala.net>
Interop2009【NC-02】
「標準化、運用、アドレス管理におけるIPv6最新動向」

2
最近のIETFでのIPv6標準化概況
IPv4アドレス枯渇対策の議論がホット
– Large-Scale-NAT (Carrier-Grade-NAT, Dual-Stack-Lite, …)
– IPv4-IPv6変換
– …
並行して、実運用を見据えた検討も増えてきた
– DHCPv6の仕様変更の検討
– IPv6-NATの検討
– ソースアドレス選択の仕様変更の検討
– 不正RA対策の検討
– … 本セッションでの報告対象

3
1. DHCPv6の仕様変更の検討
(1) 背景
(2) 提案内容
(3) 検討状況

4
1(1) DHCPv6の仕様変更の背景
DHCPv6ではデフォルトゲートウェイとプレフィックス長を配布不可
（RAで学習すれば十分、という設計思想）
Host
DHCPv6-server
アドレス=2001:db8:1:2:1234:5678:abcd:ef00/64
デフォルトゲートウェイ= fe80::1%eth0
Router (DHCPv6-relay)
DHCPv6=2001:db8:1:2:1234:5678:abcd:ef00を配布
RA=2001:db8:1:2::/64 (Autonomous-bit OFF)をfe80::1から配布

5
1(2) DHCPv6の仕様変更案
デフォルトゲートウェイやプレフィックス長をDHCPで一律管理
できないと困る (少なくともIPv4では)
=> DHCPv6でも、デフォルトゲートウェイやプレフィックス長を
配布できるようにしよう
Host
DHCPv6-server
アドレス=2001:db8:1:2:1234:5678:abcd:ef00/64
デフォルトゲートウェイ= fe80::1%eth0
Router (DHCPv6-relay)
DHCPv6=2001:db8:1:2:1234:5678:abcd:ef00/64を配布
デフォルトゲートウェイはfe80::1

6
1(3) DHCPv6の仕様変更の検討状況
DHCPで配布すべき情報を精査中
a) プロトコル観点
• デフォルトゲートウェイやプレフィックス長以外にも「RA
で配れるが、DHCPv6で配れない情報」が多数ある。
これらはDHCPv6配布不要か?
b) 運用観点
• 「デフォルトゲートウェイやプレフィックス長をDHCPv6
で一律管理できないと困る」事例集め

7
1(3) a. プロトコル観点での整理
現状、DHCPv6で配布できない情報は多数ある
– 黄色= DHCPv4/RAでは配れるが、DHCPv6では配れない情報
– 青色= RAでは配れるが、DHCPv6では配れない情報
=> どこまでDHCPv6で対応すべき?
RA DHCP
v6
DHCP
v4
アドレ
ス関連
インタフェースのプレフィックス情報 (Prefix , Prefix長) ○ × ○
インタフェースのプレフィックス情報 (有効期間, Onlink情報) ○ × ×
インタフェースのアドレス情報(アドレス, 有効期間) × ○ ○
Prefix DelegationのPrefix情報 (Prefix, Prefix長, 有効期間) × ○ ×
経路
関連
デフォルトルータ情報 (IPアドレス, 有効期間) ○ × ○
デフォルトルータ情報 (MACアドレス,優先度) ○ × ×
デフォルトルート以外の経路情報 ○ × ×
その他 NDP情報 (キャッシュ有効期間, NDP再送時間) ○ × ×
TTL ○ × ×
MTU ○ × ×
DNSサーバ情報 ○ ○ ○
その他サーバ情報(NTP, SIP, …) × ○ ○

8
1(3) b.デフォルトゲートウェイをDHCP配布できないと困る例
無線LANでのIEEE802.1x認証VLAN
– RAは無線上でブロードキャストされる
IEEE802.1x認証結果に関係なく、RAでデフォルトゲートウェイを学習
※DHCPv4/v6は実質unicastなので、このような問題がない
– いくつか運用回避案はある
• LAN1/LAN2ルータのリンクローカルアドレスを同じ値に設定
• RAをユニキャストで送受信させる (e.g. ISATAP)
– DHCPv6でデフォルトゲートウェイを配布できた方が素直か?
無線基地局
Host1 Host2
LAN2に所属LAN1に所属
LAN1 Router LAN2 Router
LAN1のRA広告 LAN2のRA広告
無線LAN上ではどちらのマルチキャストも端末
へ流れる
（LAN1もLAN2も同じ電波に乗っているため)

9
2. IPv6-NATの検討
(1) 背景
(2) 提案
(3) 状況

10
2(1) IPv6-NATの背景
IPv6にて末端拠点がマルチホームする方式は、現状下記2種類
ISP1
Prefix-1
ISP2
Prefix-2
Site
Prefix-3
Internet
ISP1
Prefix-1
ISP2
Prefix-2
Site
Prefix-1
Prefix-2
Internet
①Provider-Independentアドレス
②Provider-Aggregatableアドレスを
複数取得し、端末で適宜使い分ける
ISP1
Prefix-1
ISP2
Prefix-2
Site
ULA
Internet IPv6
NAT
初期コスト、ランニングコストが高い「端末側での使い分け」が困難
ISP変更時のリナンバリングが大変
→簡便版マルチホームソリューションとして、IPv6-NATを検討
IETFで検討しないとしても、誰かがIPv6 NATを作る
=> IETFで先に「IPv6 NATのあるべき姿」を検討しておこう

11
2(2) IPv6-NATの提案 (NAT66)
「狭義のNAT」
– 以下のアドレスを使用
• 内部= ULA(RFC4193) FDxx:xxxx:xxxx::/48 (xx部は乱数)
• 外部= グローバルアドレス (/48が前提)
– アドレス変換方法
• 基本的には上位48bitを入れ替えるだけ
• グローバルアドレスの49-64bit目にチェックサム補正フィールドを設ける
→TCP/UDPポート情報をそのまま保持可能
特徴
– ステートレスな1対1変換が可能→実装コスト低
– 外部→内部通信も可能
• 別途Stateful Inspectionを導入すれば、IPv4 NAT相当に
– その他のNATの制約はそのまま残っている
• e.g. アプリケーション層でのIPアドレス埋込・IPsecとの相性
NAT66
Box
内部
fd01:0203:0405::/48
fd01:0203:0405:0001::1234→Dst-A
Port 12345→80
チェックサム補正
2001:db8:1:d550::1234→Dst-A
Port 12345→80
外部1
2001:0db8:0001::/48
外部1
2001:0db8:0001::/48
外部2
2001:0db8:aaaa::/48
上位48bit入替

12
2(3) IPv6-NATの検討状況
議論継続中
– そもそもNATで実装する必然性があるのか?
ALGでも十分では?
– エンドユーザに/48のグローバルアドレスを配布する前提
→本当に普及可能?
→マルチホームを必要とするユーザなら/48を要求する?
– 本当にNAT66実装の方が実装コストが低いか?
• IPv4 NAPTの実装をそのままIPv6移植した方が楽?
(ただしIPv4と同じNAPTの制約が残り、IPv6導入メリットが薄いが)

13
3. ソースアドレス選択の仕様変更の検討
(1) 背景
(2) 検討状況

14
端末がソースアドレスが複数有する場合に、どれを用いて通信すべきかは、
RFC3484に規定されている
しかしRFC3484の規定だけでは不十分なことも多い (RFC5220, RFC5221)
・IPv4アドレスとIPv6アドレスのどちらを優先すべきか?
・IPv6アドレスが複数あるとき、どちらを優先すべきか?
・複数インタフェースがあるとき、どれを優先すべきか?
…
※ソースアドレス選択を誤ると、通信が成立しないこともある
3(1) ソースアドレス選択の仕様変更の背景
ISP1
Prefix-1
ISP2
Prefix-2
Site
Prefix-1
Prefix-2
Inter-
net
Source=Prefix-2を選択
ingress filteringにより、
Prefix-2をソースとする
パケットを廃棄
閉域網
Prefix-1
ISP2
Prefix-2
Site
Prefix-1
Prefix-2
Inter-
net
Source=Prefix-1を選択
Prefix-1宛に返事をしても、
Prefix-1への経路がない

15
以下の2つを検討中
– ソースアドレス選択ポリシーの動的変更方式の検討
– RFC3484で規定されている、デフォルトのソースアドレス選択
ポリシー」の修正
想定される用途を洗いながら、最適解を模索中
– 何を契機に変更される?
– どの位の頻度で変更される?
…
3(2) ソースアドレス選択の仕様変更の検討状況

16
4. 不正RA対策の検討
(1) 背景
(2) 検討状況

17
本当のルータ以外の装置からRAを流されることにより、
IPv6通信断に至る事故が多数発生
• ルータの設定ミス
• 端末側の誤動作
…
→「不正なRA」を防止する運用技術が必要
※本質的には、不正DHCPv4サーバの防止対策と同じ
4(1) 不正RA対策の背景
Router
Host1 Host2
RA
不正RA
不正RAを信じて、Host2をデフォ
ルトゲートウェイと思い込む

18
・様々な運用対策案を整理 (現在WG最終レビュー中)
・「悪意を持った攻撃の対策」よりも、「オペミス防御策」を重視
– L2層での予防
• 端末間の直接通信防止
– Private-VLAN, 無線LANのPrivacy-Separation
• 端末直収スイッチで意図せぬRAをフィルタリング
– L3層での予防
• ルータで、Router Preferenceを「高」に設定
• Secure Neighbor Discovery
• DHCPv6でデフォルトルートを配布
• RAをユニキャストで送付
– L3層での治療
• 意図せぬソースからのRAを見つけたら、
同じソースでRouter Lifetime=0のRAを投げる
(KAME rafixd)
4(2) 不正RA対策の検討状況
太字: ほとんどの実装で使用可能
斜体: 標準化作業要
Router
Host Host
Router
Host Host
RA(高優先) RA(低優先)
RA(高優先)を優先して使用
Router
Host Host
不正RA
監視サーバ
不正RAをRouter
Lifetime=0で再広告
不正RA学習をリセット
端末間で直接RA
を流せなくする
RA

19
まとめ
実運用を見据えた検討が進んでいる
– DHCPv6の仕様変更の検討
• どこまでIPv6固有な情報を配布できるようにすべきか
を整理中
– IPv6-NATの検討
• 妥当な落としどころを模索中
– ソースアドレス選択の仕様変更の検討
• 動的変更方式やデフォルト値の改訂を検討中
– 不正RA対策の検討
• オペミス回避策を整理中

IPv6標準化の最新動向

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to IPv6標準化の最新動向

Similar to IPv6標準化の最新動向 (20)

More from Shinsuke SUZUKI

More from Shinsuke SUZUKI (7)

Recently uploaded

Recently uploaded (6)

IPv6標準化の最新動向