Cisco / CCNA 200-301 v2.0

試験項目 1.4 · CCNA-020

IPv6 Prefix Sizing

Prefix Length / Prefix Boundary / /48・/56・/60・/64 / Subnet Bit / Child Prefix数 / Same Prefix / SLAACと/64

このページのゴール

IPv6 Prefix Lengthを解釈し、Network Prefix・Subnet部分・Interface Identifierの関係と親Prefixから得られるChild Prefix数を計算し、提示されたPrefix Sizeが用途と整合するか判断できるようにする。

このページで学ぶこと

  • IPv6 Prefix Length
  • Prefix Boundary
  • /64 Interface Identifier Boundary
  • Parent / Child Prefix
  • Subnet Bit Count
  • Child Prefix Count
  • Same Prefix Membership
  • SLAAC /64 要件

ページ019では、IPv6アドレスの表記・展開・正規化を確認しました。

ページ020では、その128ビットアドレスに、

/48
/56
/60
/64

のようなプレフィックス長が付いたとき、

どこまでがプレフィックスなのか

親プレフィックスから
いくつの子プレフィックスを作れるのか

2つのアドレスが
同じ数値プレフィックスに属するのか

そのプレフィックスサイズが
設計要件と整合しているのか

を判断します。

例えば、

2001:db8:abcd:1200::1/56

では、4番目ヘクステットすべてがプレフィックスとして固定されるわけではありません。

/56なので、

先頭48ビット
+
4番目ヘクステットの上位8ビット

までがプレフィックスです。

一方、

2001:db8:abcd:1200::1/64

なら、先頭4ヘクステットすべて、つまり64ビットがプレフィックスです。

ページ020では、

プレフィックス長
↓
プレフィックス境界
↓
親/ 子
↓
サブネットビット
↓
子プレフィックス数
↓
プレフィックス所属
↓
SLAAC用途との整合
↓
プレフィックスサイズの確認結果

の順に判断できるようにします。

1. プレフィックス長は左端から何ビットがプレフィックスかを示す

IPv6プレフィックスは、

ipv6-address/prefix-length

の形で表します。

例えば、

2001:db8:1:20::10/64

の、

/64

は、

左端から64ビット

がプレフィックスであることを示します。

IPv6アドレス全体は128ビットなので、

プレフィックス
64ビット

残り
64ビット

です。

重要なのは、

/64
=
64個のアドレス

ではないことです。

64は、

プレフィックスとして扱うビット数

です。

2. プレフィックス長が長いほど固定ビットが増える

例えば、

/48

と、

/64

を比較します。

/48は、

先頭48ビット

をプレフィックスとして扱います。

/64は、

先頭64ビット

をプレフィックスとして扱います。

したがって、

/48
↓
/64

ではプレフィックスとして固定するビットが、

16ビット増加

します。

逆に、

/64
↓
/60

なら、プレフィックスとして固定するビットは4ビット減ります。

3. 16進数1桁は4ビット

ページ019で確認したとおり、16進数1桁は、

4ビット

です。

そのため、

/48
/52
/56
/60
/64

のように4の倍数になっているプレフィックス長は、16進数1桁の境界で読みやすくなります。

/48
=
16進数12桁
/56
=
16進数14桁
/60
=
16進数15桁
/64
=
16進数16桁

です。

4. ヘクステット境界

1ヘクステットは16ビットです。

したがって、

/16
/32
/48
/64

はヘクステット境界と一致します。

例えば、

2001:db8:abcd:1234::/64

なら、

2001
db8
abcd
1234

の先頭4ヘクステットがプレフィックスです。

| 2001 | 0db8 | abcd | 1234 | xxxx | xxxx | xxxx | xxxx |
|--------------- 64ビットプレフィックス ----------------|

となります。

5. /48・/56・/60・/64の境界

/48

2001:db8:abcd::/48

なら、

2001:db8:abcd

の先頭3ヘクステットが固定です。

/56

2001:db8:abcd:1200::/56

なら、

2001:db8:abcd:12

までが固定です。

4番目ヘクステットでは、

12xx

の上位2桁の16進数がプレフィックスです。

/60

2001:db8:abcd:1230::/60

なら、

2001:db8:abcd:123

までが固定です。

4番目ヘクステットの最後1桁は、/60より右側です。

/64

2001:db8:abcd:1234::/64

なら、

2001:db8:abcd:1234

の先頭4ヘクステットすべてが固定です。

6. /56の親範囲

次の親プレフィックス:

2001:db8:abcd:1200::/56

では、

2001:db8:abcd:12

までが固定です。

したがって、4番目ヘクステットは、

1200
~
12ff

の範囲を含みます。

例えば、

2001:db8:abcd:1200::/64

も、

2001:db8:abcd:12a5::/64

も、

2001:db8:abcd:12ff::/64

も、この/56 親内です。

一方、

2001:db8:abcd:1300::/64

は、

12
→
13

と固定部分が変わるため、この親外です。

7. /60の親範囲

次の親プレフィックス:

2001:db8:abcd:1230::/60

では、

2001:db8:abcd:123

までが固定です。

4番目ヘクステットの最後1桁を、

0
~
f

へ変化させられるため、/64 子としては、

2001:db8:abcd:1230::/64
2001:db8:abcd:1231::/64
...
2001:db8:abcd:123f::/64

を含みます。

8. 親プレフィックスと子プレフィックス

より短いプレフィックス長を持つプレフィックスを、

親プレフィックス

とし、それをより長いプレフィックスへ分割して得るプレフィックスを、

子プレフィックス

として考えます。

例えば、

親
2001:db8:abcd::/48

子
2001:db8:abcd:0001::/64

です。

この場合、

/48
↓
/64

へプレフィックス長を16ビット増やしています。

その追加16ビットによって、複数の/64 子プレフィックスを識別できます。

9. サブネットビット数は子 - 親

親プレフィックスを子プレフィックスへ分割するとき、追加で使用するビット数は、

子プレフィックス長
-
親プレフィックス長

です。

例えば、

/48
→
/64

なら、

64 - 48
=
16ビット

です。

/56
→
/64

なら、

64 - 56
=
8ビット

です。

/60
→
/64

なら、

64 - 60
=
4ビット

です。

10. 子プレフィックス数は2^(追加ビット数)

追加したビット数を、

n

とすると、作成できる等長子プレフィックス数は、

2^n

です。

したがって、

子プレフィックス数
=
2^(子プレフィックス長 - 親プレフィックス長)

です。

11. /48・/56・/60から/64を作る

/48 → /64

64 - 48
=
16ビット

なので、

2^16
=
65,536

個の/64 子プレフィックスを作れます。

/56 → /64

64 - 56
=
8ビット

なので、

2^8
=
256

個です。

/60 → /64

64 - 60
=
4ビット

なので、

2^4
=
16

個です。

12. /48 → /64の例

親:

2001:db8:abcd::/48

では、4番目ヘクステット全体16ビットを/64 子プレフィックス識別へ使用できます。

したがって、

2001:db8:abcd:0000::/64
2001:db8:abcd:0001::/64
...
2001:db8:abcd:ffff::/64

まで、

65,536

個の/64があります。

13. /56 → /64の例

親:

2001:db8:abcd:1200::/56

では、

12

まで固定です。

残る下位8ビット、つまり16進数2桁を利用して、

1200
1201
1202
...
12ff

までの/64 子プレフィックスを作れます。

合計:

256

個です。

14. 子数から親を逆算する場合

子プレフィックス数から親プレフィックス長を考えることもできます。

ただし、

必要子数
=
親プレフィックスが必ず一意に決まる

わけではありません。

例えば、

連続した16個の/64 子プレフィックスを
ちょうど1つの整列済み親で包含する

とします。

16
=
2^4

なので、

4ビット

分の子識別空間が必要です。

したがって、

64 - 4
=
/60

です。

つまり、

16個の連続した/64を
ちょうど含む親
→ /60

です。

同様に、

256
=
2^8

なので、

256個の連続した/64を
ちょうど含む親
→ /56

です。

ただし、

16個の/64を収容できるか

だけなら、/56のようなより大きな親でも収容できます。

15. プレフィックス長はアドレス長を変えない

例えば、

/64

を、

/68

へ変更しても、IPv6アドレスが132ビットになるわけではありません。

IPv6アドレスは常に、

128ビット

です。

変化するのは、

128ビットのうち
左から何ビットをプレフィックスとして扱うか

です。

/64
→
/68

なら、プレフィックスとして固定するビットが4ビット増えます。

16. 同一プレフィックスは先頭プレフィックス長分のビットで判断する

2つのIPv6アドレスが同じ数値プレフィックスに属するかは、

先頭プレフィックス長分のビット

を比較して判断します。

例えば、

2001:db8:1:20::10/64

と、

2001:db8:1:20::abcd/64

なら、先頭64ビット:

2001:db8:1:20

が一致します。

したがって、

同じ/64 プレフィックス

です。

この「同じプレフィックス」という数値比較と、

ホストが宛先を
オンリンクとして扱うか

というIPv6近隣探索上の判断は別の概念です。

ページ020では、プレフィックス所属の数値比較を扱います。

オンリンク判定の詳細はここでは扱いません。

17. /64のプレフィックス所属

次の3アドレス:

A
2001:db8:1:20::10/64

B
2001:db8:1:20::ffff/64

C
2001:db8:1:21::1/64

を考えます。

AとBは、

2001:db8:1:20

まで一致するため、同じ/64です。

Cは4番目ヘクステットが、

20
→
21

なので別の/64です。

18. /56では4番目ヘクステット全体を比較しない

次のアドレス:

A
2001:db8:abcd:1201::1/56

B
2001:db8:abcd:12fe::1/56

C
2001:db8:abcd:1300::1/56

/56では4番目ヘクステットの上位8ビット、

12

までがプレフィックスです。

したがって、

A
12 01

B
12 fe

は同じ/56です。

一方、

C
13 00

はプレフィックス側が異なるため、別の/56です。

19. プレフィックス長の不一致では数値所属が変わる

次の2アドレスを考えます。

ホスト-A
2001:db8:1:20::10/60

ホスト-B
2001:db8:1:2f::20/64

4番目ヘクステットを4桁で考えると、

0020
002f

です。

/60では4番目ヘクステットの上位12ビット、

002

までがプレフィックスです。

したがって、

2001:db8:1:20::10

と、

2001:db8:1:2f::20

は、数値上は同じ/60 プレフィックスに属します。

一方、/64で比較すると、

0020
≠
002f

なので別の/64です。

したがって、

/60で比較
→ 同一プレフィックス

/64で比較
→ 異なるプレフィックス

となります。

設計上両端が同じ/64を使用するはずなら、

ホスト-A
実際値 /60

期待値 /64

というプレフィックス長の確認結果があります。

ここから、

ホスト-Aがホスト-Bを
オンリンクと判断する

とまでは、このプレフィックス長だけでは断定しません。

20. プレフィックス長をアドレスとセットで確認する

例えば、

2001:db8:10:20::1/64

と、

2001:db8:10:20::2/60

は、アドレス文字列の先頭部分が似ています。

しかし、

/64

と、

/60

ではプレフィックス境界が異なります。

トラブルシューティングでは、

アドレス値
+
プレフィックス長

をセットで確認します。

21. /64の境界

一般的な/64 IPv6サブネットでは、

先頭64ビット
プレフィックス

残り64ビット
インターフェース識別子側

として扱います。

例えば、

2001:db8:1:2::10/64

なら、

プレフィックス
2001:db8:1:2

です。

残る下位64ビットがインターフェース識別子側です。

22. /64とModified EUI-64は別

ページ020で確認するのは、

/64
=
プレフィックス64ビット
+
残り64ビット

という境界です。

その64ビットのインターフェース識別子を、

MACアドレスから
どのように生成するか

というModified EUI-64の処理はページ023で扱います。

したがって、

/64
=
必ずModified EUI-64

ではありません。

23. SLAAC用途では/64が重要

自律アドレス設定では、

プレフィックス長
+
インターフェース識別子長
=
128

である必要があります。

CCNAで扱う一般的な64ビットのインターフェース識別子を使用するLANでは、

プレフィックス
64ビット

インターフェース識別子
64ビット

となります。

したがって、SLAAC用途では、

/64

との整合が重要です。

24. 「IPv6は全部/64」ではない

SLAAC用LANで/64が重要でも、

IPv6プレフィックスは全部 /64

という意味ではありません。

例えば、

/48
/56
/60

の親プレフィックスも正常に存在します。

それらを複数の、

/64 子プレフィックス

へ分割して各LANへ割り当てる設計もできます。

したがって、

SLAAC用LAN
→ /64との整合を確認

と、

IPv6プレフィックス
→ 常に/64

を混同しません。

25. SLAAC用途のプレフィックスサイズの確認結果

次の要件:

LAN-A

アドレス割り当て
SLAAC

ルーター広告で通知されるプレフィックスが、

2001:db8:10:20::/60

だったとします。

CCNAで扱う一般的な64ビットのインターフェース識別子のLANで自律アドレス設定を行う前提なら、

期待値
/64

実際値
/60

というプレフィックスサイズ不整合があります。

ここで、

/60というIPv6プレフィックス自体が無効

とは判断しません。

問題なのは、

SLAAC用途との整合

です。

26. SLAACの処理そのものはページ024

ページ020では、

SLAAC用途に対し
プレフィックスサイズが整合するか

までを扱います。

一方、

ルーター要請

ルーター広告の詳細

Aフラグ

アドレス生成処理

SLAACとDHCPv6の役割分担

などはページ024で扱います。

27. 必要な子プレフィックス数と親プレフィックスの収容数を比較する

例えば、

/64 LANを
200個必要

だとします。

/60 親から作れる/64は、

16個

なので不足します。

一方、/56 親なら、

256個

の/64 子プレフィックスを作れます。

したがって、

必要
200

/60 収容数
16
→ 不足

/56 収容数
256
→ 収容可能

です。

ページ020では、最適なアドレス計画を新規設計するのではなく、

提示された親プレフィックスが
要求子数を収容できるか

を判断します。

28. 必要以上に大きい親を自動的に誤りにしない

例えば、

必要
10個の/64

に対して、

/56 親

が割り当てられているとします。

/56なら256個の/64を作れるため、

10個を収容できない

という問題はありません。

もし設計上、

期待する親プレフィックス
/60

と指定されているなら、

期待値 /60
実際値   /56

という設計/ 設定不一致です。

単に、

余裕が多い

という理由だけでは誤設定と断定しません。

29. 親/ 子プレフィックスのトラブルシューティング

要件:

親
2001:db8:abcd:1200::/56

子プレフィックスサイズ
/64

実際の子プレフィックス:

2001:db8:abcd:12a0::/64

は親内です。

固定される上位8ビットが、

12

で一致するためです。

一方、

2001:db8:abcd:13a0::/64

なら、

期待する親プレフィックス
12xx

実際の子プレフィックス
13a0

なので親外です。

30. 同一プレフィックスのトラブルシューティング

期待値:

ホスト-Aとホスト-B
同じ/64 プレフィックス

実際値:

ホスト-A
2001:db8:10:20::10/64

ホスト-B
2001:db8:10:21::20/64

なら、

ホスト-A
2001:db8:10:20::/64

ホスト-B
2001:db8:10:21::/64

です。

したがって、

期待値
同一/64

実際値
異なる/64

というプレフィックス所属の確認結果です。

31. プレフィックス長不一致のトラブルシューティング

期待値:

ホスト-A
2001:db8:10:20::10/64

ホスト-B
2001:db8:10:20::20/64

実際値:

ホスト-A
2001:db8:10:20::10/60

ホスト-B
2001:db8:10:20::20/64

アドレス値は期待値と一致しています。

しかし、

ホスト-A

期待するプレフィックス長
/64

実際のプレフィックス長
/60

です。

したがって、

アドレス値
一致

プレフィックス長
不一致

と分離できます。

この場合の誤った値はホスト-Aのプレフィックス長です。

32. よくある誤判断

誤り1:/64は64個のアドレスを意味する

64はプレフィックスとして扱うビット数です。

誤り2:プレフィックス長が長いほど固定ビットが減る

逆です。

長くなるほどプレフィックスとして固定するビットが増えます。

誤り3:/56なら4番目ヘクステット全体が固定

/56では4番目ヘクステットの上位8ビットまでです。

誤り4:/60 → /64は64個作れる

追加ビットは4なので、

2^4
=
16個

です。

誤り5:16個の/64が必要なら親は必ず/60

16個の連続した/64をちょうど含む整列済み親は/60です。

より大きい/56などでも16個を収容できます。

誤り6:同一プレフィックスならホストは必ずオンリンク扱いする

ページ020の同一プレフィックスは数値上のプレフィックス所属判定です。

IPv6のオンリンク判断とは別です。

誤り7:IPv6ではすべて/64

親プレフィックスなどでは別プレフィックス長も正常です。

誤り8:/64なら必ずModified EUI-64

/64はプレフィックスサイズです。

インターフェース識別子生成方式とは別です。

誤り9:SLAACで/60ならIPv6プレフィックスとして無効

/60自体が無効なのではなく、一般的な64ビットのインターフェース識別子を使用するSLAAC用途との不整合です。

誤り10:アドレスが一致すればプレフィックス長は確認不要

アドレス値が正しくてもプレフィックス長だけ不一致の場合があります。

33. IPv6プレフィックスサイズの基本手順

1. プレフィックス長を確認

        ↓

2. プレフィックス境界を特定

        ↓

3. 親/ 子関係を確認

        ↓

4. 子 - 親で
   追加ビット数を求める

        ↓

5. 2^(追加ビット数)で
   子プレフィックス数を求める

        ↓

6. 先頭プレフィックス長分のビットを比較し
   プレフィックス所属を判断

        ↓

7. 期待するプレフィックス長と比較

        ↓

8. SLAAC用途なら
   /64との整合を確認

        ↓

9. 必要な子プレフィックス数と
   親プレフィックスの収容数を比較

        ↓

10. プレフィックスサイズ上の
    確認結果を特定

すべての問題で全手順を実行する必要はありません。

問題文で要求される、

境界

親/ 子

子プレフィックス数

所属

SLAAC

収容数

のどこを確認すべきか判断します。

34. 最終的に判断できるようにすること

ページ020では最終的に、

プレフィックス長は
左から何ビットがプレフィックスかを示す

/48は先頭3ヘクステット

/56は4番目ヘクステットの上位8ビットまで

/60は4番目ヘクステットの上位12ビットまで

/64は先頭4ヘクステット

サブネットビット数
=
子 - 親

子プレフィックス数
=
2^(子 - 親)

/48 → /64
65,536個

/56 → /64
256個

/60 → /64
16個

プレフィックス所属は
先頭プレフィックス長分のビットで判断する

数値プレフィックス所属と
IPv6オンリンク判断を混同しない

プレフィックス長の不一致を識別する

SLAAC用途では
一般的な64ビットのインターフェース識別子と/64の整合を確認する

ただしIPv6すべてを/64にしない

子数から親を逆算するときは
「ちょうど含む親」と
「収容できる親」を区別する

必要があります。

まとめ

IPv6プレフィックス長は、

左端から何ビットを
プレフィックスとして扱うか

を示します。

IPv6アドレスそのものは常に、

128ビット

です。

例えば、

/48

なら先頭48ビット、

/56

なら先頭56ビット、

/60

なら先頭60ビット、

/64

なら先頭64ビットがプレフィックスです。

16進数1桁は4ビットなので、

/48
/56
/60
/64

は16進数1桁の境界で判断しやすいプレフィックス長です。

親プレフィックスから子プレフィックスへ分割するときの追加ビット数は、

子プレフィックス長
-
親プレフィックス長

です。

作成できる等長子プレフィックス数は、

2^(子 - 親)

です。

したがって、

/48 → /64
16ビット追加
65,536個
/56 → /64
8ビット追加
256個
/60 → /64
4ビット追加
16個

です。

子プレフィックス数から逆算する場合、

16個の連続した/64を
ちょうど含む親
→ /60

ですが、

16個を収容できる親

であれば/56など、より大きい親も成立します。

プレフィックス所属は、

アドレス文字列全体

ではなく、

先頭プレフィックス長分のビット

を比較して判断します。

ただし、

数値上同じプレフィックス

であることと、

IPv6ホストが宛先を
オンリンクとして扱う

ことは同じ意味ではありません。

ページ020ではプレフィックス所属の数値比較までを扱います。

また、

アドレス値

が期待値と一致していても、

プレフィックス長

だけが誤っている場合があります。

トラブルシューティングでは両方を確認します。

SLAACについては、CCNAで扱う一般的な64ビットのインターフェース識別子のLANでは、

/64 プレフィックス
+
64ビットのインターフェース識別子
=
128ビット

となるため、SLAAC用途では/64との整合が重要です。

しかし、

IPv6の全プレフィックス
=
/64

ではありません。

/48、/56、/60などの親プレフィックスも正常に使用できます。

ページ020での最終流れは、

プレフィックス長
↓
境界
↓
親/ 子
↓
サブネットビット数
↓
子プレフィックス数
↓
プレフィックス所属
↓
期待値との比較
↓
SLAACと/64の整合
↓
親プレフィックスの収容数
↓
プレフィックスサイズの確認結果

です。

次のページ021では、プレフィックスサイズではなく、グローバルユニキャスト/ ユニークローカル/ リンクローカル/ 未指定/ ループバックなどのIPv6ユニキャストアドレス種別と範囲を扱います。

理解確認

このページの内容を14問で確認します。

理解確認14問へ →