IPv6 Configuration in IKEv2

[draft-eronen-ipsec-ikev2-ipv6-config-04]

VPNのときIKEv2のConfiguration Payloadを使うけど現状IPv4はOKだけど
IPv6のある種の特徴を使うことが難しい。
この文書では、IPv6での現状のIKEv2 configuration payloadの限界と
すべての特徴を備えた仮想的なIPv6インターフェースをセットアップ可能にする解決方法
を考えていく。

現状の問題

IKEv2のリモートアクセスにおけるconfiguration payloadの使用方法は
デカイアドレスのIPv4としてしかあつかわれていない。
eg. 仮想的なIPv6インタフェースにはlink-local addressがない(RFC4291違反)。
これはlink-local addressの存在を前提としているプロトコルの使用を複雑にしている。
リンクローカルがないと、MLDv2やDHCPv6が動かん。。。
複数のprefix
クライアントは複数のINTERNAL_IP6_ADDRESSをリクエストに含めることができるが、
GWはクライアントがリクエストした以上のアドレスをアサインできない。
- 複数prefix : リナンバリング、ホストベースサイトマルチホーミング(SHIM6)、
 unique local ipv6 address(rfc4193)で有益
　すべてのケースで、GWはいくつの異なるアドレス(prefix)を
 クライアントにアサインすべきかの情報をもっている。


たとえMLDが動いたとしてもマルチキャストトラフィックをSでネゴできない。

GWはクライアントによって使用されるインタフェースIDを選択する(fig2)。
これはクライアントがインタフェースIDをリクエストしてGWがprefix部分を
選択することも可能になる。

これはCGAで問題になる。
CGAではインタフェースIDはprefixを知る前に計算することができないから。
クライアントはまずnon-CGAアドレスによってprefixを得、
そして分離されたCFG_REQUESTによって同じprefixのCGAアドレスをえる。
この方法ではIKEv2実装がCGAを管理するコンポーネントへのインターフェースを
提供することになって、実装の依存性が深くなってします。
同じようなことが、HBAやprivacyアドレスなどのどのインタフェースIDを
使用するかクライアントが主導権を握るものでも起こりうる。

いくつかのVPNクライアントでは他のデバイス(携帯ーラップトップなど)と
VPNコネクションを共有する。
この場合、デバイスごとに適用するポリシーは異なるだろうし
stateless address auto configurationとの連携も複雑になる。
そのためprefixをもらって、それをローカルリンクに流すほうがよい。

オリジナル３GPPでは各携帯にひとつのIPv6アドレスを付与する(IKEv2)。
3GPPは各携帯にユニークな/64 prefixを与えなくてはならなくなる。
もしVPNクライアントが他のVPNクライアントとシェアするprefix(es)から
アドレスをアサインされる場合、マルチリンクサブネットの一種となってしまう。。。

デザインゴール:
与えられたprefixにより複数のアドレスを得ることができる。
インタフェースIDはクライアントによって選択され、prefixに依存。
VPNクライアントはひとつのVPNとのリンクで複数のprefixをアサインされえる。
クライアントはいくつのprefixが必要か事前に知る必要はない。
...
DADはなし。
マルチキャストも動く。
VPNアクセスをローカルエリアネットワークでシェアできる。
最認証も動く。IKE SAの再生成の場合でも同じ仮想リンク(同じアドレス…)をしようできる。
バーチャルリンクでDHCP PDできるようにするかは議論する。

AUTOCONFやDHCPv6の仕組みはできるだけ使用。IKEv2すぺしふぃっくは避けるべき。
同じようなものをいくつも提案しない。。。

実装においてはクリーンな依存性に徹する。
コアIPv6スタックや、IKEv2のIPv6部分に影響をあたえない。

ノンゴール
MIPv6はすでにIPsec/IKEv2のinterctionを定義しているからこの文書でも変更しない。


解決方法の議論

"virtual link" (gw-client)
linkはikev2メッセージによって作成され、IKE SAが使用されなくなったら破壊される。
linkはIPsec SAでない。
このリンクでのIPsec SAがカバーするトラフィックは0以上にありうる。
linkはひとつのIKE SAでない。
再認証をサポートするために、他のIKE SAで同じリンクを識別可能にすること。
TBD：複数のvirtual linkをサポートするために
single IKE SAが必要かどうか
(おそらくいらない、複数のvirtual linksは必要、multiple IKESAは使用される）

ピア間のすべてのIPsecトラフィックはvirtula linkに関連する必要はない。
(だけれども一番シンプルなVPN client-GWシナリオはあり)

どのlink/subnetモデルを使うか？
GWからprefixの情報を伝播させるか？
各クライアントでユニークなIPv6アドレスをどうやって保障するか？
L3アクセスコントロール


link model
p2p link : shareしない
multi access link : GWが転送
router aggregation link model: multi-linkの一形態
複数のクライアントがprefixをシェアするがlink-local multicastは
他のクライアントは受信しない。

mcat linkモデルはmcastパケットいっぱい。。。

o ikev2(CP)
o RA over ipsec tunnel
o DHCPv6


multi access, router aggregationモデルでは複数のクライアントが
prefixを共有するのでアドエスがかさならないようにするひつようあり。
o client recevie IKEv3 (CP)、クライアントのアドレスをトラックする必要
o DHCPv6 : GW nees relay agent機能
o AUTOCONF: DAD


p2pではGWが単にクライアントが使用しているprefixを知っていればいい。

L3 AC
ingress filterのおかれている場所に依存
SAD/SPD
outside ipsec

そのた
いくつかの候補ではGWに沢山のステートが必要。
virtual linkの際認証でのユニークにvirtual linkを
識別するにはIKE_SAが作成されたときにリクエスト。それ以外ならIKE SPI。。。。。

prefix lifetime == ike sa lifetime ?

CHILD_SAができたとき、ピアはvirutal interfaceにもCHILD_SAを適用するか、
リアルインターフェースのIKEv2メッセージを送信するか？
CREATE_CHILD_SAリクエストにペイロードを付加する
もしくは、CHIL_SAをにlinkを識別するプロポーズするTSをしよう


＊＊＊ IPsec ipv6 over ipv4 tunnelのケースは？


解決方法は
上記の組み合わせか･･･

initial exchanges

INTERNAL_IP6_LINK 導入

...


ND,RD,PD,Prameter discovery, AUTOCONFは使わず、IKEv2レイヤーで必要なものは実装。

address Rsolution, Next-hop Determinatio, Redirectはつかわない、
virtual linkはlinnk-local addressを持たないし、p2plinkなので。

既存のINTERNAL_IP6_ADDRESSは使わないが、クライアントが投げてきたときに
GWはそれを使うか決定。
その他は依然有効(INTERNAL_ADDREsS_EXPIRYとINTERNAL_IP6_ADDRESS以外)。
INTERNAL_IP6_SUBNETもconfusingだが有効。