IPv4/IPv6 移行・共存技術の動向

インターネットマルチフィード株式会社
技術部
川上
雄也

IPv4枯渇時代に向けて

2013/05/20

2
2013 (c) INTERNET MULTIFEED CO.
JANOG31会場ネットワーク

3
⽬目次

  IPv4アドレス枯渇の状況
  IPv4/IPv6 移⾏行行・共存技術
  IPv4/IPv6 移⾏行行・共存技術各論論
  ステートフルIPv4/IPv6トランスレーション技術

  ステートフルIPv4 over IPv6カプセル化技術

  ステートレスIPv4/IPv6トランスレーション技術

  ステートレスIPv4 over IPv6カプセル化技術

  その他

  IPv4/IPv6 移⾏行行・共存技術の⽐比較
  IPv4/IPv6 移⾏行行・共存時代の注意点
  付録

2013 (c) INTERNET MULTIFEED CO. 4

5
IPv4アドレスプールの枯渇

  2011/02/03 INAIAのアドレスプールが枯渇
  2011/04/19 APNICのアドレスプールが枯渇
  /8 のプールが残り１つになり通常の割り振りを終了了
  2012/09/14 RIPE(欧州)のアドレスプールが枯渇
ANA Unallocated Address Pool Exhaustion:
　　 03-Feb-2011  
Projected RIR Address Pool Exhaustion Dates:
RIRProjected Exhaustion Date Remaining Addresses in RIR Pool (/8s)
APNIC: 19-Apr-2011 (actual) 0.8667
RIPE NCC: 14-Sep-2012 (actual) 0.9022
ARIN: 12-Apr-2014 2.3224
LACNIC: 04-Sep-2014 2.5227
AFRINIC: 09-Aug-2020 3.7283

http://www.potaroo.net/tools/ipv4/

6
IPv4の売買と値段

  2011/03/24 MicrosoftがNortelから666,624個のIPv4アドレスを$7.5Mで購⼊入
  IPv4アドレス１つあたり$11.25という値段の相場ができた
http://www.networkworld.com/community/blog/microsoft-pays-nortel-75-million-ipv4-address

7
IPv4アドレスの移転

  2011/08/01 JPNIC内のIPv4アドレス移転制度度開始
  72件の移転が実施された(2013/05/09時点)
  2012/07 RIR(地域レジストリ)間の移転が可能に
  2013/06/03 JPNIC内外でのアドレス移転が可能になる予定
https://www.nic.ad.jp/ja/ip/ipv4transfer-log.html

8
IPv4グローバルアドレスの利利⽤用料料

  2013/05/07 UQ WiMAXがWiMAX接続のIPv4アドレスをプライベートアドレ
スに移⾏行行することを発表。同時にで⽉月額100円グローバルアドレスを利利⽤用する
ことができるオプションを発表
  グローバルIPv4アドレス１つの⽉月額サービス料料の⽬目安

http://www.uqwimax.jp/service/price/option07.html

9
IPv6の普及状況(Cisco)

  Ciscoによる⽇日本の統計では
  プレフィックス： 46.50%
  トランジットAS： 78.95%
  コンテンツプロバイダ： 27.52%（※トラフィック量量でTop500 Webサイト）
  ユーザ： 2.32%
  ⽇日本ではユーザの対応のほうが遅れている

http://6lab.cisco.com/stats/

10
IPv6の普及状況(Google)

  Googleによる統計では
  世界的に1.25％が対応
  ⽇日本は2.08％が対応
  ただし⽇日本は「ユーザーが
IPv6 対応のウェブサイトに接続したときに信頼性
や遅延に関する重⼤大な問題が発⽣生している地域」に分類されている

https://www.google.com/intl/ja/ipv6/statistics.html

11
IXでのIPv6の通信量量

https://www.ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic

http://www.de-cix.net/about/statistics/

6.8 Gbps / 1936 Gbps = 0.35％
11.5 Gbps / 2775 Gbps = 0.41%
1.0 Gbps / 300 Gbps = 0.33％
ただし⼟土⽇日は半分！

13
IPv4/IPv6 移⾏行行・共存技術

  IPv4/IPv6移⾏行行・共存技術の分類
  利利⽤用場所での分類
  アクセス回線でユーザのトラフィックを運ぶための技術（下の表）
  ISPのバックボーン内でトラフィックを運ぶための技術
  アドレスファミリーでの分類
  Dual Stack
  IPv4 over IPv6
  IPv6 over IPv4
  IPv4 from/to IPv6
Client
ISP
Server
Solution

v4
v4
v4
CGN

v4
v6
v4
MAP, DS-Lite, 464XLAT

v6
v4
v6
6rd

v6
*
v4
NAT64

IPv4のアドレス枯渇に備えて、次世代IPのIPv6に移⾏行行するにあたって、
移⾏行行期間中のIPv4/IPv6の共存を実現するための技術

14
今⽇日のお話：IPv4延命技術

  IPv4/IPv6移⾏行行・共存技術の中でも
  アクセス回線でユーザのトラフィックを運ぶ技術
  IPv6通信が⼀一般になった時代に、残るIPv4通信を救う技術
  そのためにIPv4のアドレス枯渇対策も⾏行行うことができる技術
利用率率率

時間

IPv4
IPv6

IPv6
IPv4
IPv4

この時代のお話
IPv4通信をIPv6の上で⾏行行う

エンド
ユーザ
ISP
インターネット

IPv4 over IPv6技術 IPv4のアドレス共有技術(NAPT)

15
IPv4延命はそんなに先の話ではない

  こんなケースはありませんか？
ユーザにはグローバルIPv4アドレスを提供しなきゃいけないから、
バックボーンに使うアドレスを節約してユーザに回したい（DC事業者）
ユーザにグローバルIPv4アドレスは提供しなくてもいいけど、
何かしらIPv4の接続性は提供しておかなくちゃいけない（ISP）

16
IPv4/IPv6 移⾏行行・共存技術の進化

SAM 4rd
MAP-E
4rd-(H,U)NAT-PT
NAT64
IVI dIVI dIVI-pd MAP-T
XLAT464
NAT464 DS-lite
Public 4over6
Lightweight 4over6
Stateless DS-lite
MAP
MAP-DHCP
MAP-DEPLOYMENT
A+P
RFC1933
Conﬁgured tunnels
Automatic tunnels
6to4 (RFC3056) 6rd (RFC5969)
6over4 ISATAP
Teredo
Tunnel brokers
Softwire mesh
BGP tunnels
6PE 6VPE
http://www.swinog.ch/meetings/swinog24/p/04_townsley-map-swinog-may-2012-distribution.pdf

17
今覚えておきたい４つの技術

  特徴
 １つのグローバルIPv4アドレスを複数のCPEで共有(NAPT)
 IPv6バックボーンを超えてIPv4の接続性を提供
  分類⽅方法
 NATのセッション(ステート)管理理を⾏行行う場所 (CPE or ISP)
 IPv6バックボーンの越え⽅方 (カプセル化 or トランスレーション)

カプセル化
(Encupslation)

トランスレーション
(Translation)

プロバイダ側Stateful
DS-Lite
464XLAT

プロバイダ側Stateless
MAP-E
MAP-T

18
４つの技術の適⽤用範囲

  ISPのIPv6アクセス網を経由して複数のご家庭間で1つのIPv4アドレスを共有

IPv4

エンドユーザ
（プライベート
　アドレス）

ISPのIPv6
アクセス網
IPv4

IPv4

IPv4

CPE(家庭⽤用ブロードバンドルータ)

プロバイダ側機器

カプセル化 or トランスレーション

19
カプセル化とトランスレーション

  カプセル化
  IPv4パケットをIPv6パケットで包み込んで運ぶ、通称トンネル
  IPv6分だけヘッダが増える
  トランスレーション
  IPv4パケットをIPv6パケットに変換して運ぶ
  IPv4ヘッダの情報が⽋欠落落する
  ヘッダは差分だけ増える

Payload

IPv4

IPv6

Payload

IPv4

Payload

IPv4

Payload

IPv6

Payload

IPv4

Payload

IPv4

20
ステートフルとステートレス

  ステートとは
  通信のセッションの「状態」
  ステートレス (Stateless)
  ユーザの通信について状態を管理理しなくて良良い状態
  ステートフル(Stateful)
  ユーザの通信について状態を管理理しなくてはならない状態
  ステートがおかしくなると正しく通信できない
  今回出てくるステートの例例
  NAPTのセッションテーブル
Protocol
DstAddr
DstPort
SrcAddr
SrcPort

TCP
192.0.2.13
179
192.168.3.2
48329

UDP
10.56.2.1
53
192.168.11.5
9136

22
ステートフルIPv4/IPv6トランスレーション技術

SAM 4rd
MAP-E
4rd-(H,U)NAT-PT
NAT64
XLAT464
NAT464 DS-lite
Public 4over6
Lightweight 4over6
Stateless DS-lite
MAP
MAP-DHCP
MAP-DEPLOYMENT
A+P
RFC1933
Conﬁgured tunnels
Automatic tunnels
6to4 (RFC3056) 6rd (RFC5969)
6over4 ISATAP
Teredo
Tunnel brokers
Softwire mesh
BGP tunnels
6PE 6VPE

23
NAT-PT (NAT Protocol Translation)

  概要
  IPv4とIPv6の相互変換を⽬目的とした技術[RFC2766]
  NAPT機能を⼊入れたNAPT-PTも定義されている
  既にRFCがHistoricにされているため⾮非推奨[RFC4966]
  動作
  96-bitのIPv6プレフィックスを設定することで、32-bitのIPv4アドレスと128-bitの　
IPv6アドレスの相互変換を⾏行行う
  NAT-PTルータがApplication Level Gateway (ALG) 機能を⽤用いてDNS[RFC2694]や
ICMP[RFC2765]、FTPなどのアプリケーションの通信のプロトコル変換も⾏行行う
  この技術の問題点
  ⽣生IPを使うアプリケーションの通信に対応できない
  対応しているALGはDNSとFTPぐらい
  SIPなどはまだ対応していない
  ALGがNAT-PTルータの機能として提供されるため
  DNS-SECに対応できない
  別のDNSを使われるとALGが機能しない
IPvX

IPvY

NAT-PT

DNS

通信先

DNSクエリ変換

パケット変換

24
NAT64

  概要
  IPv6からIPv4へ変換するステートフルなNAT[RFC6146]
  変換⽅方法はIP/ICMP変換の新標準[RFC6145]に従う
  NAPT-PTのDNS ALGをパケットのパスから分離離してDNS64[RFC6147]に
  通信の発信元をv6側に限定しv6v4変換のみを定義
  TCP/UDP/ICMPに対するNATの要求仕様を満たし、NAT Traversalにも対応
  動作
  96-bitのIPv6プレフィックスを設定することで32-bitのIPv4アドレスと128-bitのIPv6
アドレスの相互変換を⾏行行う
  DNSについてはDNS64に対応したDNSサーバに問い合わせを⾏行行う
  この技術の問題点
  ALG問題：⽣生IPv4アドレスを使うアプリは救えない
  MSN Messenger (2009年年)
  2.38％のWebサイトがIPv4アドレス直書き
IPv6

IPv4

NAT64

DNS64

通信先
DNSクエリ変換

パケット変換

[v4literals]

25
464XLAT

  概要
  IPv4/IPv6変換[RFC6145]とNAT64[RFC6146]を組み合わせたv4/v6/v4変換技術
  ⽇日本⼈人によって提案されRFC6877として発⾏行行された[RFC6877]
  NAT64の要素技術である既存の標準技術の組み合わせなので開発が容易易
  IPv4-IPv4の通信なのでDNS等のALGは必要ない
  動作
  CLATでIPv4からIPv6へのステートレスな変換を⾏行行う(1:1)
  PLATでNAT64によるIPv6からIPv4へのステートフルな変換を⾏行行う(n:1)

IPv6
IPv4

PLAT

ステートフル64変換
(RFC6146(NAT64))

IPv4

CLAT

ステートレス46変換
(RFC6145)

エンドユーザ
ISP

26
464XLAT

  PLAT: Provider side translator(XLAT)
  ISP側に設置される集約装置
  RFC6146(NAT-64)に基づくステートフルなトランスレータ
  グローバルIPv6アドレスからグローバルIPv4アドレスへの
1:n の変換を⾏行行う
  CLAT: Customer side translator(XLAT)
  エンドユーザのゲートウェイとして設置される装置
  RFC6145に基づくステートレスなトランスレータ
  プライベートIPv4アドレスからグローバルIPv6アドレスへの
1:1 の変換を⾏行行う
  アドレスフォーマット
  96-bit IPv6プレフィックス付加と32-bit IPv4アドレス埋め込み
  シンプルなアドレスフォーマット
96-bit

32-bit

32-bit

IPv4

IPv6

27
464XLATの実装

  PLAT
  Cisco ASR 1000Series (IOS-XE3.4.0S~)
  Juniper SRX Series (JUNOS10.4~)
  A10 Networks AX Series (ACOS 2.6.4~)
  F5 Networks BIG-IP Series (11.1~)
  Ecdysis NAT64
  linux nat64
  OpenBSD PF
  CLAT
  NEC AccessTechnica CL-AT1000P
  Linux Prototype
  Nokia n900
  android-clat
  LG myTouch
  Samsung Nexus

28
ステートフルIPv4 over IPv6カプセル化技術

SAM 4rd
MAP-E
4rd-(H,U)NAT-PT
NAT64
XLAT464
NAT464 DS-lite
Public 4over6
Lightweight 4over6
Stateless DS-lite
MAP
MAP-DHCP
MAP-DEPLOYMENT
A+P
RFC1933
Conﬁgured tunnels
Automatic tunnels
6to4 (RFC3056) 6rd (RFC5969)
6over4 ISATAP
Teredo
Tunnel brokers
Softwire mesh
BGP tunnels
6PE 6VPE

29
DS-Lite

  概要
  IPv4 over IPv6カプセル化とCGNを組み合わせた技術[RFC6333]
  Dual StackよりライトにDual Stackが実現できるからDual Stack Lite
  CPE機器をB4 (Basic Bridging BroadBand)と呼ぶ
  プロバイダ側機器を AFTR (Address Family Transition Router)
  動作
  B4でIPv4 over IPv6のカプセル化を⾏行行い、設定されたAFTRに転送する
  AFTRではカプセル化を解除し、NAPT44を⾏行行う
  NAPTではトンネルのB4側のIPv6アドレスで加⼊入者を区別する
  トンネルのIPv4アドレスにはAFTR: 192.0.0.1/29, B4: 192.0.0.2/29を使う
IPv4 over IPv6
IPv4

AFTR

IPv4 over IPv6カプセル化
＋ステートフル44変換(CGN)

IPv4

B4

エンドユーザ

ISP

30
DS-Liteの実装

  AFTR
  Cisco CRS Series (IOS XR-4.2.1~)
  Juniper MX/M/T Series (JUNOS 10.4~)
  A10 Networks AX Series (ACOS 2.6.1~)
  ISC aftr
  B4
  だいたいのIPv4 over IPv6トンネルが可能な機器
  Cisco IOS
  IIJ SEIL/X1
  …

31
ステートレスIPv4/IPv6トランスレーション技術

SAM 4rd
MAP-E
4rd-(H,U)NAT-PT
NAT64
XLAT464
NAT464 DS-lite
Public 4over6
Lightweight 4over6
Stateless DS-lite
MAP
MAP-DHCP
MAP-DEPLOYMENT
A+P
RFC1933
Conﬁgured tunnels
Automatic tunnels
6to4 (RFC3056) 6rd (RFC5969)
6over4 ISATAP
Teredo
Tunnel brokers
Softwire mesh
BGP tunnels
6PE 6VPE

32
IVI (1:N)

  IVI (1:N)概要
  ステートレスなNAT64 [RFC6219]
  ただしIPv6クライアントはアドレスによって使える送信元ポート番号が決まっている
  DNSの変換はDNS64(RFC6147)、ICMPの変換はRFC6145を使う。
  名前の由来はローマ数字の４(IV)と６(VI)をくっつけてIVI
  1:NではNクライアントで1つのIPv4アドレスを共有する
  プレフィックスは/32のみ
  動作
  ポート番号Pは P = j*N + K (j=0..N-1, K=0..N-1) で決まる（IVI独⾃自のルール）
  クライアントが送信元ポートを⾃自発的に制限する（OSに変更更を加える）
  アドレスのPort Coding (PC)部にNを4-bit, Kを12-bitで埋め込んでいる
  アドレスフォーマット
  IPv4アドレスとポートの範囲が埋め込まれている
  標準化されたフォーマットはRFC6052で定義されている
LIR
PC
IPv6
FF
IPv4
0

32
40
0
72
84
128

33
dIVI (1:N)

  概要
  ステートフルv4/v6変換(1:1 IVI) + ステートレスv6/v4変換(1:N IVI)技術
  IVIを２回実⾏行行するのでdouble IVI
  クライアント側は1:1 IVI
  クライアントで送信元ポートを制限すればステートレス
  IVI機器(ホームゲートウェイ)でNAPT後の送信元ポートを制限すればステートフル
  プロバイダ側はステートレスな1:N IVI
  送信元ポート番号の使い⽅方は相変わらず独⾃自
  dIVI-pd
  prefix-delegationができるようにしたもの
IPv6
IPv4

1:N IVI


IPv4

1:1 IVI

ステートフル46変換
エンドユーザ
ISP

34
MAP: Mapping Address and Port

  A+P (Address plus Port) の考え⽅方
  IPv4アドレス32-bitとポート番号(16-bit)を併せて識識別⼦子として使えば48-bitのアドレス
空間を使うことができる！[RFC6346]
  1つのIPv4アドレスを複数のユーザで使える
  ただし使えるポート番号が限られる
  SAM (Stateless Address Mapping)の考え⽅方
  6rdみたいにIPv6アドレスを⾒見見ればIPv4アドレスが分かるようになったら。セッション
ごとのアドレス変換表を持たなくていいのでステートレスにプロトコル変換できる！
  でもIPv6アドレスへのIPv4アドレスの埋め込みはbitが⾜足りなくて難しい
  ネットワーク部は省省略略して、ホスト部だけ埋め込もう！（プレフィックスの変換表を持つ）
  空いたbitにポート番号の情報を⼊入れよう！[sam]
  MAPの考え⽅方
  パケットの運び⽅方はさておき、IPv6アドレスに対するIPv4アドレスとポート番号情報の
埋め込み⽅方（FMR = forwarding mapping rule）と、アドレスから送信元ポートを決める
port mapping algorithmを統⼀一しよう！

35
MAP-T (Mapping of Address and Port using Translation)

  概要
  MAPに準拠したv4/v6/v4変換技術[map-t]
  CPEでNAPTするため、プロバイダ側はステートレス
  CPE側の機器をCE(Customer Edge)、プロバイダ側の機器をBR(Border Relay)と呼ぶ
  動作
  CEにてステートフルなNAPT44が実⾏行行される
  プライベートアドレスが外部グローバルアドレスに変換される
  MAPのport mapping algorithmに従って送信元ポートが決定される
  CEにてMAPのFMRに従ってv4/v6変換される
  BRにてステートレスにv6/v4変換される
IPv6
IPv4

BR


IPv4

CE

MAPによるステートフル
NAPT44＋46変換
エンドユーザ
ISP

36
ステートレスIPv4 over IPv6カプセル化技術

SAM 4rd
MAP-E
4rd-(H,U)NAT-PT
NAT64
XLAT464
NAT464 DS-lite
Public 4over6
Lightweight 4over6
Stateless DS-lite
MAP
MAP-DHCP
MAP-DEPLOYMENT
A+P
RFC1933
Conﬁgured tunnels
Automatic tunnels
6to4 (RFC3056) 6rd (RFC5969)
6over4 ISATAP
Teredo
Tunnel brokers
Softwire mesh
BGP tunnels
6PE 6VPE

37
4rd (IPv4 Residual Deployment)

  概要
  NAPT44 + IPv4 over IPv6カプセル化技術[4rd]
  独⾃自のポートマッピングアルゴリズム
  現在の4rd[4rd-u]とは別物なので注意(despres版とか旧4rdとかで区別)
  動作
  IPv4プレフィックスとIPv6プレフィックスのマッピングのルールは予め共有される
  CEでステートフルなNAPTが⾏行行われてカプセル化されてIPv6バックボーンを超える
  BRではIPv4アドレスからステートレスにIPv6アドレスを求めてカプセル化しCEに転送
する

IPv4 over IPv6
IPv4

BR
IPv4

CE

独⾃自のステートフルNAPT44
＋IPv4 over IPv6カプセル化
エンドユーザ

ISP

ステートレスな

38
MAP-E (Mapping of Address and Port with Encapsulation)

  概要
  MAPに準拠したNAPT44 + IPv4 over IPv6カプセル化技術[map-e]
  アドレスフォーマットとポートマッピングがMAPに準拠
  動作
  IPv4プレフィックスとIPv6プレフィックスのマッピングのルールは予め共有される
  CEでステートフルなNAPTが⾏行行われる（送信元ポート範囲はIPv6アドレスから計算される）
  CEでカプセル化されてIPv6バックボーンを超える
  BRではIPv4アドレスからステートレスにIPv6アドレスを求めてカプセル化しCEに転送する

IPv4 over IPv6
IPv4

BR
IPv4

CE

MAPによるステートフルNAPT44
＋IPv4 over IPv6カプセル化
エンドユーザ

ISP

ステートレスな

39
MAP-Eの実装

  BR
  FNSC FX Series
  IP Infusion (Linux/NetBSD)
  ASAMAP
  IIJ SEIL/X1
  Cisco ASR9000(IOS-XR)
  CE
  BRの機器
  FNSC F Series
  YAMAHA RTX1200
  CERNET OpenWRT

40
相互接続試験＠JANOG31

Tech
Role
Day1
Day2

MAP-E

BR
IPI
IPI
FNSC

CE1
SEIL
FNSC
ASAMAP
YAMAHA

CE2
FNSC
FNSC

DS-Lite

AFTR
A10
A10

B4
NECAT
SEIL

464XLAT

PLAT
A10
A10

CLAT
NECAT
NECAT

41
BR切切り替え実験@JANOG31

  MAP-EのBRはステートレスなのでBRが切切り替わってもセッションは切切れない

42
まとめると

IPv4 over IPv6

IPv4

BR
IPv4

CE

ステートフルNAPT44
＋ステートレス4o6 ステートレス4o6
IPv4 over IPv6

IPv4

AFTR
IPv4

B4

ステートレス4o6
ステートフル
NAPT＋4o6
IPv6

IPv4

PLAT
IPv4

CLAT

ステートレスNAT46 ステートフルNAT64
IPv6

IPv4

BR
IPv4

CE

ステートフルNAT46 ステートレスNAT64
MAP-E

DS-Lite
464XLAT

MAP-T

43
その他

SAM 4rd
MAP-E
4rd-(H,U)NAT-PT
NAT64
XLAT464
NAT464 DS-lite
Public 4over6
Lightweight 4over6
Stateless DS-lite
MAP
MAP-DHCP
MAP-DEPLOYMENT
A+P
RFC1933
Conﬁgured tunnels
Automatic tunnels
6to4 (RFC3056) 6rd (RFC5969)
6over4 ISATAP
Teredo
Tunnel brokers
Softwire mesh
BGP tunnels
6PE 6VPE

44
4rd-U (-Unified)

  概要
  MAP-EもMAP-TもIPv4パケットの運び⽅方が違うだけだから、そこの差異異を吸収して新し
いフォーマットに統⼀一してしまおう[4rd-u]
  ヘッダ情報のマッピングを持たせればいい

Lightweight 4 over 6 (LW4o6)[LW4o6]

Payload

IPv4

IPv6

MAP-E

Payload

IPv4⽋欠落落

IPv6

MAP-T

Payload

マッピング

IPv6

4rd-U

  概要
  DS-LiteのCPEごとにアドレスとポートレンジを設定してあげればステートレスになるよ
  ↑それMAP−Eと何が違うの？

45
乱⽴立立してはまとめられる規格

IPv4
ネイティブ

カプセル化

トランス
レーション

新しい
フォーマット

CPE

MAP-E
(元4rd)

MAP-T
(元dIVI)

4rd
(元4rd-U)

ISP

NAT44
CGN
DS-Lite

464XLAT

CPE＆
ISP

NAT444

IPv4パケットの運び⽅方

NATの
場所
LW4o6

まとめられそう！

Softwire Unified CPE[unified-cpe]

47
各技術の⽐比較表

DS-Lite
464XLAT
MAP-E
MAP-T
4rd-u
LW4o6

Encap/
Trans

Encap
Trans
Encap
Trans
Hybrid
Encap

Stateless
/Stateful

Stateful
Stateful
Stateless
Stateless
Stateless
Stateless

Mesh
ready

No
No
Yes
Yes
Yes
No

Address
Mapping

割り当て
なし
⾃自動計算
⾃自動計算
⾃自動計算
割り当て

http://www.slideshare.net/m-asama/map-14353679

48
すべての技術に共通する問題

  MTU問題
  カプセル化にしろトランスレーションにしろヘッダのサイズが変わる
  カプセル化：+ 40 byte
  トランスレーション: +20 byte
  IPのペイロードのサイズがギリギリだとフラグメントされてしまう
  特にフラグメントの概念念がないIPv6へのトランスレーションの場合どうする？
  TCPの場合MSS ClampingでMSSを調整する
  ステートフル技術ではプロバイダ側機器でやるが、MAP-Tは？
  UDPは救えない
  NAPT問題
  すべての技術はIPv4アドレス共有のためにNAPTを⾏行行なっているので、ポート
番号を持っていないIPの上位プロトコルは個別対応が必要というNAPTの問題
を抱えている
  ICMP: だいたい対応
  L2TP, PPTP: 対応してない場合が多い
  IPsec: NAPTの場合UDPでwrapする仕様だが、対応していないクライアントも

49
カプセル化
vs トランスレーション

  カプセル化のいいところ
  元のパケットをそのまま運ぶのでIPv4のヘッダ情報が⽋欠落落しない
  チェックサムの再計算をしなくていい
  トランスレーションのいいところ
  プロバイダのIPv6ネットワークでペイロードを⽣生で扱える
  ACLやQoSのためにDPIしなくていい
  カプセル化よりもMTUが⼤大きい

IPv4 over IPv6

IPv4
IPv4

IPv6

IPv4
IPv4

50
ステートレス
vs ステートフル

  ステートレスのいいところ
  Anycastなどの既存技術を⽤用いた冗⻑⾧長化が可能
  悪意のあるユーザにポート番号を専有されない
  ポートアサインのログを保管しなくて良良い
  多数収容するプロバイダ側でステートを持たないのでスケールする
  セッションベースではなく、トラフィックベースでの設備投資が可能
  ステートフルのいいところ
  ポート数がユーザごとに固定されていないのでより少ないIPv4アドレスでサ
ービスが提供可能(dynamic allocationの場合)
  CPE機器の実装が簡易易、安価に

IPv4
IPv4

IPv6

IPv4
IPv4

IPv6

51
結局どれを使えばいいの？

  今回はv4 over v6の技術を紹介しましたが、v6 over v4やCGNもある…
  フローチャートはありませんか？
  あります[46chart]

結局やりたいサービスと⾃自社ネットワークの状況からの判断
それでも決まらなければ世間の波に乗る

53
NAPTの実装関する注意

  NAPTの実装によって期待する通信ができない、特にオンラインゲームユーザに
対して⼤大きな影響があるので注意
  ヘアピン通信
  NAT超え
  要件：マッピングとフィルタリングの挙動で分類
  マッピング：エンドポイント⾮非依存マッピング
  フィルタリング：エンドポイント⾮非依存フィルタリング
  コナミの佐藤さんの資料料[napt-stun]がわかりやすい
IPv4

エンドユーザ

ISP

IPv4

外部アドレスが
同じ！！！

54
サーバでのロギングに関する注意

  同じIPv4アドレスから別のユーザがアクセスしてくる
  IPv4アドレスだけをロギングしているだけでは不不⼗十分
  RFC6302でログ内容の推奨を⾏行行なっている
  送信元IPアドレス
  送信元ポート番号
  タイムスタンプ(UTC)
  追跡可能な時刻源で１秒以下の精度度
  トランスポート層プロトコル(TCP/UDP)と宛先ポート番号

56
MAPのアドレスフォーマット

  IPv6アドレスにIPv4アドレスの情報を埋め込む
  ただし32-bit全部は⼊入らないのでホスト部分(Suffix)だけ
  ネットワーク部分の情報はマッピング規則としてBRとCEで共有する
  IPv6アドレスにポート番号の情報を埋め込む
  余った部分に利利⽤用可能なポート番号の範囲の情報(PSID: Port Set ID)を埋め込む
IPv6 Prefix
subnet ID

IPv4 Prefix
IPv4 Suffix

Interface ID
⾃自由に使える

IPv4

IPv6

IPv6 Prefix
subnet ID

IPv4 Prefix
IPv4 Suffix

Interface ID

IPv4

IPv6

PSID

EA bits

57
MAPのアドレスフォーマット

  Port Set IDは16-bitポート番号の中に埋め込まれたk-bitの識識別⼦子
  これで送信元ポート番号を制限できる
  Aはオフセット。存在するときAは0以上の値にする(システムポートの利利⽤用を避ける)
  IPv6アドレスとIPv4アドレスを紐紐付けるルール(Basic Mapping Rule, BMR)
  {IPv6プレフィックス、IPv4プレフィックス、EA bits⻑⾧長}の組をBRとCEの間で共有する
  IPv4: IPv4 Prefixに合致したら、残りのSuffixと設定されたPSIDでEA bitsを構築する
  IPv6: IPv6 Prefixに合致したら、続くEA bits⻑⾧長のうち、32-prefix⻑⾧長を切切り出してIPv4 Suffixを
埋めて、残りはPSIDだと解釈する
A
PSID
M
ポート番号(16-bit)

IPv6 Prefix
subnet ID

IPv4 Prefix
IPv4 Suffix

Interface ID

IPv4

IPv6

PSID

EA bits

59
参考⽂文献 (1/6)

  IPv4枯渇
  [ipv4-report] IPv4 Address Report
  http://www.potaroo.net/tools/ipv4/
  IPv6統計
  [cisco6] Cisco IPv6 Lab: IPv6 Deployment
  http://6lab.cisco.com/stats/
  [google6] IPv6 – Google
  https://www.google.com/intl/ja/ipv6/statistics.html
  [amsix6] AMS-IX IPv6 Traffic
  https://www.ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic
  [decix6] DE-CIX Native IPv6 Traffic
  http://www.de-cix.net/about/statistics/
  IPv4/IPv6 移⾏行行・共存技術
  [loadmap] Mapping Address + Port
  http://www.swinog.ch/meetings/swinog24/p/04_townsley-map-swinog-may-2012-
distribution.pdf

60
参考⽂文献 (2/6)

  NAT-PT
  [RFC2766] Network Address Translation - Protocol Translation (NAT-PT)
  http://tools.ietf.org/html/rfc2766
  [RFC2765] Stateless IP/ICMP Translation Algorithm (SIIT)
  [RFC2694] DNS extensions to Network Address Translators (DNS_ALG)
  [RFC4966] Reasons to Move the Network Address Translator - Protocol Translator
(NAT-PT) to Historic Status
  NAT64
  [RFC6146] Stateful NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers
  [RFC6147] DNS64: DNS Extensions for Network Address Translation from IPv6
Clients to IPv4 Servers
  [RFC6145] IP/ICMP Translation Algorithm

61
参考⽂文献 (3/6)

  [v4literals] Coping with IP Address Literals in HTTP URIs with IPv6/IPv4 Translators
  http://tools.ietf.org/html/draft-wing-behave-http-ip-address-literals-02
  464XLAT
  [RFC6877] 464XLAT: Combination of Stateful and Stateless Translation
  [464xlat-products] 「IPv6時代のIPv4を考える」〜～第⼆二章〜～【464XLAT事前公開資料料】
  http://www.janog.gr.jp/meeting/janog30/doc/janog30-v64-pre-kawashimam-01.pdf
  IVI
  [RFC6219] The China Education and Research Network (CERNET) IVI Translation
Design and Deployment for the IPv4/IPv6 Coexistence and Transition
  [RFC6052] IPv6 Addressing of IPv4/IPv6 Translators
  dIVI
  [divi] Address-sharing stateless double IVI
  http://tools.ietf.org/html/draft-xli-behave-divi-01
  [divi-pd] dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix Delegation
  http://tools.ietf.org/html/draft-xli-behave-divi-pd-01

62
参考⽂文献 (4/6)

  DS-Lite
  [RFC6333] Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
  A+P
  [RFC6346] The Address plus Port (A+P) Approach to the IPv4 Address Shortage
  SAM
  [sam] SAM: Stateless Address Mapping 〜～
IPv6 時代の
IPv4 を考える
〜～
  http://www.janog.gr.jp/meeting/janog26/doc/post-dslite-matsushima.pdf
  MAP-T
  [map-t] Mapping of Address and Port using Translation (MAP-T)
  http://tools.ietf.org/id/draft-ietf-softwire-map-t-01.txt
  4rd
  [4rd]
  http://tools.ietf.org/html/draft-despres-softwire-4rd-00
  MAP-E
  [map-e] Mapping of Address and Port with Encapsulation (MAP)
  http://tools.ietf.org/id/draft-ietf-softwire-map-06.txt

63
参考⽂文献 (5/6)

  4rd-U
  [4rd-u] IPv4 Rapid Deployment on IPv6 Infrastructures (4rd)
  http://tools.ietf.org/html/draft-vautrin-softwire-4rd-00
  [many4rd]これでいいのか4rd - 標準化と、実装と、運⽤用と、のはざまの奮闘記
  http://www.janog.gr.jp/meeting/janog30/doc/janog30-map-after-matsushima-01.pdf
  LW4o6
  [LW4o6] Lightweight 4over6: An Extension to the DS-Lite Architecture
  http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-11
  [unified-cpe] Unified IPv4-in-IPv6 Softwire CPE
  http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-02
  各技術の⽐比較
  [compare] MAP実装してみた
  http://www.slideshare.net/m-asama/map-14353679
  [46chart] IPV4/V6移⾏行行・共存技術について
  https://www.nic.ad.jp/ja/materials/iw/2011/proceedings/t1/t1-01.pdf
  [config] JANOG Meeting本会議場ネットワークの作り⽅方
| JANOG31 Meeting
  http://www.janog.gr.jp/meeting/janog31/LA.html

64
参考⽂文献 (6/6)

  移⾏行行・共存技術の注意点

  [napt-stun] 「IPv6時代の
IPv4を考える」〜～第⼆二章〜～共存
/ 移⾏行行技術とP2P 対
戦
ゲー

ム
の相性
  http://www.janog.gr.jp/meeting/janog30/doc/janog30-v64-pre-stun-ryosato-02.pdf
  [RFC6302] Logging Recommendations for Internet-Facing Servers

IPv4/IPv6 移行・共存技術の動向

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (8)

Similaire à IPv4/IPv6 移行・共存技術の動向

Similaire à IPv4/IPv6 移行・共存技術の動向 (20)

Dernier

Dernier (9)

IPv4/IPv6 移行・共存技術の動向