狠狠撸

For The Guaranteed Network
? ALAXALA Networks Corp. 2009. All rights reserved.
滨笔惫6标準化の最新动向
アラクサラネットワークス(株) 営業本部
鈴木伸介 <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対策の検討
? オペミス回避策を整理中

狠狠撸

滨笔惫6标準化の最新动向

Recommended

More Related Content

What's hot (20)

Similar to 滨笔惫6标準化の最新动向 (20)

More from Shinsuke SUZUKI (7)

滨笔惫6标準化の最新动向