IPv6技術動向

IPv6 Technical Summit 2005

ALAXALA Networks Corporation / KAME Project
SUZUKI, Shinsuke <suz@alaxala.net>

Copyright © Hitachi,Ltd.2004 All rights reserved

Abstractn 基本仕様n 運用ノウハウn 移行技術n アドレッシング
n マルチホームn モビリティAll rights reserved, Copyright(c)2005, AlaxalA Networks Corp.

2

基本仕様
n ほぼFixした
l IETF ipv6 WGのface-to-face meetingは、2005/11が最後
uIPv6は、IPv4と同様に、全プロトコルの基本要素である
l KAME Projectの完成宣言
uhttp://www.wide.ad.jp/news/press/20051107-KAME-j.html
uhttp://www.kame.net/newsletter/20051107/l 細かい話題が若干残っている程度
uRouter Advertisementメッセージ内のM bit/O bitの定義uIPv6 DNSサーバアドレス通知方式
u仕様更新 (IPv6 over PPP, Source Address Selection, …)

n 非IP系通信媒体でのIPv6通信方法の標準化
l IETF IPv6 over Low Power WPAN WG
uセンサネットワーク
l IETF IPv6 over IEEE 802.16(e) Networks BoF
uWiMaxAll rights reserved, Copyright(c)2005, AlaxalA Networks Corp.

3

運用ノウハウn 運用ノウハウを文書化 (IETF v6ops WG)
uリナンバリング手順 (RFC4192)
uIPv6 Security概論 (draft-ietf-v6ops-security-overview-04.txt)
uICMPv6フィルタガイドライン(draft-ietf-v6ops-icmp-filtering-bcp-02.txt)
uNetwork Architecture Protection (draft-ietf-v6ops-nap-04.txt)
Ø NAT相当の機能を、NAT箱なしで実現する方法

uIPv6アドレスのDNS問い合わせに対する誤応答事例集 (RFC4074)
Ø WIDE v6fix WG http://www.v6fix.net/…

n 時には運用観点から仕様変更も提案
l On-link assumption廃止
u「端末にDefault経路がない→全ての端末は同一リンク上に存在すると思え」
u最新のIPv6基本仕様からは、この仮定が廃棄される
l Stateless DHCPv6での情報更新方法のRequirement (RFC4076)
l Stateless DHCPv6での情報更新方法 (RFC4242)
All rights reserved, Copyright(c)2005, AlaxalA Networks Corp.

4

リナンバリング手順n 大まかに3段階
l 事前準備
u事前に新アドレスを確保
Ø アドレスブロックの割当, DNS逆引き委譲

uDNSレコードのTTLを短めに設定
l 新規プレフィックスに基づくアドレス追加
u古いプレフィックスのアドレスはまだ消さない→X-dayなしのリナンバリング
l 古いプレフィックスを削除
u古いプレフィックスのDNSレコードを削除
u古いアドレス割り振りを削除

n ポイントl 思わぬところにアドレス情報は潜んでいる
uフィルタ(e.g. パケット中継、経路制御メッセージ)
uアプリケーション内部 (e.g. DHCPv6で広告するサーバアドレス)

All rights reserved, Copyright(c)2005, AlaxalA Networks Corp.

5

ICMPv6フィルタガイドライン
n 背景
l ICMPv6パケットをフィルタすると、IPv6通信自体が出来なくなることがある (e.g. path MTU discovery失敗)
l だからといって、ICMPv6パケットを無制限に通すのは怖い
廃棄不可
中継

通常は廃棄不可

Don’t
Care

管理者のポ 通常廃棄可
リシー次第

MIP6

NDP,MLD,SEND,
MR-disc.

Seamoby

NI-Query/Reply,
Router Renum.

未割当
ICMPv6エラータイプ(Type5-99,102-126)

試験割当
ICMPv6タイプ(Type100-101,200-1)
未割当ICMPv6情報タイプ(Type159-254)

共 Dst Unreach(全code)
通 Packet-Too-Big
Time-Exceed (code0) Time-Exceed. (code 1)
Param.Prob. (code1,2) Param.Prob. (code0)
Echo-Request
Echo-Reply

自 NDP,
分 MLD,
宛 SEND,

MR-discRouterRenum.,
MIP6,
SeamobyRedirect,
NIQuery/Reply

All rights reserved, Copyright(c)2005, AlaxalA Networks Corp.

6

Network Architecture Protectionn NATで提供したい機能
l Intranet-Internet間のゲートウェイ機能
l Stateful Filter Inspection
l ユーザ/アプリケーションのトラッキング
l 端末/トポロジー隠蔽l ISP非依存なアドレッシング
l グローバルアドレス枯渇対策
l マルチホームn IPv6で等価な機能を提供する方法の整理
l Privacy Address Extension
l ULA
l Prefix-Delegationl Untraceable IPv6 addressl Mobile-IPv6
l Shim6
All rights reserved, Copyright(c)2005, AlaxalA Networks Corp.

7

移行技術

n IETF v6ops WG
l IPv6導入ノウハウを文書化
uケース別のIPv6導入手順分析 (RFC4029, 4038,4057, 4213, 4215)

n IETF softwire WG
l 自動トンネリングプロトコルの標準化
l 現在は以下の2ケースに関する要求事項の整理中
uホスト〜ルータØLast one-mileのIPv6対応

uルータ〜ルータØCoreネットワーク内のIPv6対応

All rights reserved, Copyright(c)2005, AlaxalA Networks Corp.

8

アドレッシングn 不要なアドレス空間の廃止
l サイトローカルアドレス(RFC3879)
l NSAP互換アドレス (RFC4048)
l IPv4互換アドレス(draft-ietf-ipv6-addr-arch-v4-04.txt)
l IPv6実験網(6bone)の廃止 (2006年6月6日)
u3ffe::/16 (RFC3701), ip6.int (RFC4159)

n 新規アドレスの標準化
l アドレススコープの明確化 (RFC4007)
l Unique Local Address (RFC4193)
l Embedded-RP (RFC3956)

n アドレス割当ポリシー
l IETF IAB−IANA間で随時議論 (詳細は次の発表で)

All rights reserved, Copyright(c)2005, AlaxalA Networks Corp.

9

Unique Local Address (ULA)n 閉域網向けの/48アドレス空間
l Registryへの申請は不要 (FD00::/8)
uIPv4 Private Addressと同じ感覚で使える
u40bitの乱数計算が必須
Ø e.g. “時刻+EUI-64”のSHA-1ハッシュ値 の下40bit

l http://www.kame.net/~suz/gen-ula.html
1111 110 1
7 bit

Global ID (乱数)40 bitSubnet ID
16 bitInterface-ID
64 bitl IPv4 Private Addressとは違い、重複の可能性は低い
uN個のULAアドレスブロックのうちどれか2つ以上が重複する確率
1 - (1-1/240) × (1-2/240) × … × (1-N/240)
N= 1,000 →約0.00005%
N= 10,000 →約0.005%
N=150,000 →約1%l Registryで割当を管理するULA(FC00::/8)は、標準化未完了
u運用体制に関する議論が収束していないため
All rights reserved, Copyright(c)2005, AlaxalA Networks Corp.

10

Embedded-RP
n PIM-SMでのRP-Group対応付け管理はスケールしない
l Bootstrap Message
uHop-by-hopに広告
l Static RP
u全てのルータに手動設定

n Embedded-RPl グループアドレス自体に、RPアドレスを特定するための情報を埋め込む
l RPアドレスは、常に(Subnet Prefix):0:0:0:Xという形

16bit

8bit 8bit

64bit

32bit

FF7X

0X

Subnet Prefix

Group-IDYY

RP for this group = (YY bit of Subnet Prefix)::X
e.g. ff7e:0a40:2001:db8:1:2::1234 → 2001:db8:1:2::a/64

All rights reserved, Copyright(c)2005, AlaxalA Networks Corp.

11

マルチホーム(背景)n 背景l IPv4マルチホームでは“Punching Hole”が経路エントリ数増大の原因
l IPv6で同じ流儀でマルチホームすると、インターネットは破綻する

n 課題整理 (IETF multi6 WG)
l RFC4177 アーキテクチャ整理
l RFC4218 想定される脅威の分析
l RFC4219 想定される課題の分析

n 「マルチホーム」にも色々
l ここでは「サイトマルチホーム」が考察の対象
u現在“Punching Hole”の原因になっているケース
l ISP間マルチホームは考察対象外
uBGPによるポリシー制御で十分
ISP

ISP
ISP
サイトInternetInternet

ISP
ISP
All rights reserved, Copyright(c)2005, AlaxalA Networks Corp.

12

マルチホーム(プロトコル)
n Shim6=端末ベースのサイトマルチホーム技術 (IETF shim6 WG)
l 端末に振られたアドレスを2種類に分類
uIdentifierアドレス
端末の一意性を示すアドレス
uLocatorアドレス
ルーティングするための場所を示すアドレス
l IPv6層の間にShim層を導入
uShim層の上からは、Identifierアドレスで通信しているように見える
uShim層の下からは、Locatorアドレスで通信しているように見えるl 本質的には端末内NAT
uアプリケーションからNATを隠蔽し、端末外NATの抱える問題を回避
アプリケーション
TCP/UDP
IPv4

IPv6
IPv6(2)
ShimIPv6(1)物理層

IPv6(2) = IP end-point sub-layer- IPsec, Fragment, Destination Option処理
Shim- Locator/Identifier対応付け- Locator/IdentifierのIPv6アドレス付替
IPv6(1) = IP routing sub-layer- NDP, IPv6パケット送受信処理
ISP1/2の両方からアドレス取得
src/dstにより、用いられるISPが決める

All rights reserved, Copyright(c)2005, AlaxalA Networks Corp.

13

マルチホーム(プロトコルの課題) (cont.)n 一見Mobile-IPv6に似ているが…
l Identifier(Mobile-IPv6ではHome Address)への到達性がなくなる
事態も考慮
l アプリケーション単位に経路選択可能

n 到達性がなくなったら、どのような処理をすべきか
l 「到達性がなくなった」という判断基準は?
l Identifierの付替は必要?

n Locator選択アルゴリズムはどうあるべきか
l 到達性だけで評価して本当によいのか?

n Shim6がサイトマルチホーミングの課題を全て解決するか?
l 端末がマルチホームポリシーを決める設計→ネットワーク管理者は、端末に対してマルチホームポリシーを強要しにくい

All rights reserved, Copyright(c)2005, AlaxalA Networks Corp.

14

モビリティ
n 基本プロトコルの標準化は終了
n 運用を想定した議論が活発に行われている
l 特に高速ハンドオーバ
u運用階層型MIPv6 (RFC4140)
uネットワーク接続検出技術の要求事項 (RFC4135)
uMIPv6での高速ハンドオーバ (RFC4068)

All rights reserved, Copyright(c)2005, AlaxalA Networks Corp.

15

結論n 基本仕様l ほぼ完了n 運用ノウハウl ドキュメントの蓄積中l 見つかった課題は随時仕様にフィードバック

n 移行技術l Last one-mile/Backboneにおける自動トンネリングプロトコルの標準化が始まった

n アドレッシングl 不要なアドレス空間の廃止
l 有用なアドレス空間の追加 (ULA, Embedded-RP)n マルチホーム
l 端末でのサイトマルチホーム技術(shim6)の設計が急速に進む

n モビリティl 運用を想定した議論へ
All rights reserved, Copyright(c)2005, AlaxalA Networks Corp.

16

Thanks you!