The Internet A

Hop-by-Hop Address Assignment and
Source Address Based Routing
for IPv6 End-to-End Multihoming
京都大学大学院情報学研究科
大平健司
[email protected]
May 27, 2004
ITRC15@Fukushima
1
Agenda
はじめに
 IETF Multi6 WGでの議論
 提案
 まとめ

May 27, 2004
ITRC15@Fukushima
2
はじめに

マルチホーミング

対外接続の複数化による冗長性確保


ネットワークの高信頼化
IETF Multi6 WGで議論されている


May 27, 2004
(とりわけ) IPv6におけるサイトマルチホーム
スケーラブルな機構
ITRC15@Fukushima
3
マルチホーミングの際に考えるべき事項

どの対外接続を経由させる？


パケットにどのようなアドレスをつける？


ISP Selection / Site Exit Router Selection問題
Ingress Filtering問題
複数の対外接続を同時に
利用できないか？

The
Internet
Load Sharing問題
May 27, 2004
ITRC15@Fukushima
4
Multi6 WG

サブグループ (Design Team)



DT1 (Locator/ID separation)
DT2 (Multi-address)
現在のHot Topic

Host Identifier

Stable addressing



Transport layer survivability
especially for long-lived session
現在のタスク

6月にInterim Meeting

May 27, 2004
Architectural analysis
ITRC15@Fukushima
5
Design Teams

DT1 (Loc/ID separation)

Members










DT2 (Multi-address)

Tony Li (chair)
Erik Nordmark
Sean Doran
Pekka Savola
Mike O’Dell
Dave Katz
Brian Carpenter
Steve Bellovin
Illjitsch van Beijnum
Members









May 27, 2004
ITRC15@Fukushima
Christian Huitema
(chair)
Cedric de Launois
Marcelo Bagnulo
Dave Crocker
Lode Coene
David Kessens
Lixia Zhang
Arifumi Matsumoto
Kenji Ohira
6
経路とノード識別子

複数の経路を保持するにはいずれかが必要


単一のIPアドレス空間に対する複数の経路情報 (PI)
複数のIPアドレス空間 (PA)
→ PAがMulti6での主流
 「あるコネクションの当事者」の識別子は何か


トランスポート層アドレス (新設)
IPアドレス
May 27, 2004
ITRC15@Fukushima
→
→
DT1
DT2
7
DT1的 (Loc/ID Separation) アプローチ

主眼


提案



通信中にあるIPアドレスに対応する経路が使用できな
くなってもコネクションを継続したい
ソケットにはコネクション継続中一貫したL4IDを見せる
L4IDとIPアドレスとの対応付けプロトコル
問題点

ユーザが手動で経路を選ぶことはできない
May 27, 2004
ITRC15@Fukushima
8
DT1での提案

目的


ソケットにバインドする
名前の一意性の確保


位置識別子とノード
識別子の分離
レイヤ3とレイヤ4の
名前空間の分離
(shim layer)
提案







May 27, 2004
HIP (Host Identity Protocol, by Nikander)
NOID (No IP Identifier, by Nordmark)
SIM (Strong Identity, by Nordmark)
CB64 (64bit Crypt Based ID, by Nordmark)
CBHI (Crypt Based Host ID, by Beijnum)
WIMP (Weak Identifier, by Ylitalo)
ODT (On Demand Tunneling, by Beijnum)
ITRC15@Fukushima
9
DT2的 (Multi-Address) アプローチ

主眼


提案




複数ある経路のどちらを使用するかホストが選択でき
るようにする
経路冗長化手法
複数あるIPアドレスのうちどれがよいか教えるサーバ
(Address Selection)
1コネクションに対し複数のアドレスを対応付け可能な
トランスポート層プロトコル (Transport Survivability)
問題点

複数のアドレスを与えても結局同一の経路を通過する
恐れ
May 27, 2004
ITRC15@Fukushima
10
DT2での提案 (1/2)







経路の確保
NAT
トンネリング
提案
 経路の確保 (NAT)


ソケットにバインドするIP
アドレスの決定
経路(アドレス)の良し悪し
に関する情報共有
トランスポート層プロトコル
のマルチアドレス対応
MHTP (by Py)
経路の確保 (トンネル)

MHTB (by Bagnulo)


Host Centric (by Huitema)


ITRC15@Fukushima
出口ルータ間トンネル
アドレス選択

NAROS (by Launois)


アドレス対の到達性・最適性を
第3者(サーバ)で検証
MAST (by Crocker)

May 27, 2004
RFC3178の自動化
所有するアドレスの情報・認証
情報を通信2者間で交換
11
DT2での提案 (2/2)

経路の確保






NAT
トンネリング

経路情報の共有

ソケットにバインドするIP
アドレスの決定
経路(アドレス)の良し悪し
に関する情報共有
トランスポート層プロトコル
のマルチアドレス対応
May 27, 2004
提案
CELP (by Crocker)


当初SLAPと呼ばれていた
L4のマルチアドレス対応
ITRC15@Fukushima


TCP-MH (by Matsumoto)
SCTP for MH (by Coene)
12
両アプローチの組合せ

両DTからの提案は排他的なものではない



手動で経路を選択したいかどうかはcase by case
経路の冗長化手法についてはDT2のみが言及
組み合わせてもまだ足りないものが…


サイト内の各ノードに付けるアドレス
サイト内のルーティングプロトコル
サイトがMulti-Link Multi-Exit-Routerの
構成をとる場合に特に問題になる
May 27, 2004
ITRC15@Fukushima
13
その他
プロバイダ内地理的Aggregation
 ASN-PI (by Savola)
 AS番号共有 (by Toyama)



同一ISP組を利用するサイト同士でAS番号を共有
LIN6 (by Teraoka)


(by Beijnum)
Location Independent Networking for IPv6
MIPv6 for MH (by Bagnulo)

位置移動透過性の確保にMIPv6を利用
May 27, 2004
ITRC15@Fukushima
14
Architectural Analysis

RFC3582


Things to think about


Draft-lear-multi6-things-to-think-about-03.txt
Threats



Goals for IPv6 Site-Multihoming Architectures
Draft-nordmark-multi6-threats-00.txt
Draft-ohta-multi6-threats-00.txt
Architectures

Draft-huston-multi6-architectures-00.txt
May 27, 2004
ITRC15@Fukushima
15
For Scalability, Extensibility, …

グローバル情報・ルータでの計算項目の限定



自NWへの到達情報は本当に世界中に流さなければ
ならないのか?
ルータが｢最適」経路を計算してやる必要があるのか?
責任・権限の分界 (分割統治)




エンドホスト (レイヤー)
サイト (アクセス制限・認証)
アドレス (階層的責任委譲)
ルーティングプロトコル (影響範囲を限定的に)
May 27, 2004
ITRC15@Fukushima
16
Routing Protocol for Hierarchical Address
Assignment

要求




アドレス割当は階層的に行われていることを活用
複数の階層構造に並行して所属する場合にも対応
自動化のしやすい(単純で機械的な)構造
解決策


Subnet IDの階層化
各ルータにおいて(複数の)デフォルト経路に関し
Source Address Based Routing
May 27, 2004
ITRC15@Fukushima
17
サイト内アドレス割当
48bits
16bits
Global Routing Prefix
Subnet ID
ISPから取得



IPv6アドレスの典型例
64bits
Interface ID
NICから
自動生成
IPv6ではアドレス長は128ビット
16ビットをサイト内で管理
 マルチホーミング状態では各ノードは複数アドレスを持つ
 構成するリンク数に比例して設定変更の量が増加
 手動設定では設定ミスの可能性
経路表設定とも連動させる
→アドレス自動割当によりユーザの負担を軽く
draft-ohira-multi6-multilink-auto-prefix-assign-00.txt
May 27, 2004
ITRC15@Fukushima
18
Subnet IDの階層的分割
16bits
Destination
Subnet ID
p bits
q bits
16-p-q bits
delegated
delegating
Link ID
Next Hop Iface
2001:200:190:f02::/64 fe80::1
eth0
3ffe:150:240:2::/64
fe80::2
eth0
::
(*1)
fe80::1
eth0
::
(*2)
fe80::2
eth0
Src. Addr. が2001:… → (*1)へ
Src. Addr. が3ffe:… → (*2)へ
割当の段が深くなるほどpは増える

再帰的アドレス割当


DHCPv6 with Prefix
Delegation Option
May 27, 2004
経路表設定との連動

ITRC15@Fukushima
デフォルト経路へのSource
Address Based Routing
19
Hop-by-Hop Address Assignment
ISP
X
The
Internet
A
ISP
X
A
C
X:0000::/48
X:0000::/64
ISP
Y
C
ISP Xはサイトに
X::/48をdelegate
D
X:1000::/52
X:1000::/64
B
D
E
F
E
X:1100::/56
G
X:1100::/64
B
G
F
サイト内のリンクに出口ルータに近い所から順にアドレスが
割り当てられる
May 27, 2004
ITRC15@Fukushima
20
提案方式の特徴

Multi6 WGでの他の提案と併用可能




Loc/ID Separation
CELP / SLAP (使用経路の共有)
NAROS / MAST (位置情報の登録)
Transport Layer Survivabilityは他の提案に依存


TCP-MH
SCTP-MH
May 27, 2004
ITRC15@Fukushima
21
提案方式の課題

サイト内でアドレス数が爆発する恐れ


偽親ルータ


アドレスのspanningが必要?
MITMの可能性
Loc/ID分離との組合せを考えた時、

MappingはDNS(DDNS)で十分か


更新頻度・レコードタイプ
Mapping Serverの位置

サイトの最上位リンク?


May 27, 2004
今まで最上位だと思っていたリンクが最上位でなくなったら?
Mapping Server間の連動
ITRC15@Fukushima
22
まとめ

本発表ではサイトマルチホーミングについて、


IETF Multi6 WGにおける議論の流れ
Hop-by-Hop Address Assignmentの提案及び課題
を説明した
May 27, 2004
ITRC15@Fukushima
23

Download Report