[2] [DFN[IPv6 [RUBYB[アドレス]@en[address]]]]は、[[IPv6]] において通信の当事者を[[識別]]する[RUBY[[[番地]]]@en[[[アドレス]]]]です。 * IPv6 アドレスの文字列表現 [3] [[IPv6アドレス]]は [CODE@en[ABCD:EF01:2345:6789:ABCD:EF01:2345:6789]] のように16進数を16ビットごとに「[CODE(char)[[[:]]]]」で区切って表記することになっています。 ** 仕様書 - [4] [[RFC 4291]] -- [CSECTION@en[2.2. Text Representation of Addresses]] ** 構文 - [6] [RUBYB[好ましい形]@en[preferred form]]は、16進数を16ビット分ずつ8回繰り返す表記です。 [SRC[>>4 2.2. 1.]] -- 例: [CODE[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]] - [7] ただし[[先導0]]は省略できます。 [SRC[>>4 2.2. 1.]] -- 例: [CODE[1080:0:0:0:8:800:200C:417A]] - [8] 0ばかりが続くところは1回だけ「[CODE[[[::]]]]」により省略できます。 [SRC[>>4 2.2. 2.]] -- 例: [CODE[FF01::43]] = [CODE[FF01:0:0:0:0:0:0:43]] -- 例: [CODE[::]] = [CODE[0:0:0:0:0:0:0:0]] - [9] 最後の32ビットを[[IPv4アドレス]]形式で表記できます。 [SRC[>>4 2.2. 3.]] -- 例: [CODE[0:0:0:0:0:FFFF:129.144.52.38]] -- 例: [CODE[::FFFF:129.144.52.38]] ** 問題点 - [10] 16進数表記の1部分の最大桁数が明確に定義されていません。「16ビット分」なので常識的には4桁ですが、先頭に「0」を付ければ同じ意味でいくらでも長くできます。 - [11] 16進数アルファベットが明確に定義されていません。例示はすべて[[大文字]]になっていますが、[[小文字]]でもよいのかは不明確です。 - [12] [[IPv4アドレス]]の表記法が明確に定義されていません。常識扱いされているようです。 - [13] >>8 と >>9 により文字列表記が一意に確定しないので、比較など場面によっては困りそうです。 ** 歴史 [5] [[RFC 4291]] (>>4) 以前にも、[[RFC 3513]], [[RFC 2373]], [[RFC 1884]] の同じく [CSECTION@en[2.2. Text Representation of Addresses]] で[[IPv6アドレス]]の文字列表現が定義されていました。 これらは同じ [[RFC]] の他の部分の変更に伴う改訂で、文字列表現の部分はずっと変更されていません。 * IPv6 アドレス接頭辞の文字列表現 [14] [[IPv6アドレス]]の[[接頭辞]]は「[CODE[2001:0DB8:0:CD30::/60]]」のように [[IPv6アドレス]]の後に先頭からのビット数を併記して表すことになっています。 ** 仕様書 - [15] [[RFC 4291]] -- [CSECTION@en[2.3. Text Representation of Address Prefixes]] ** 歴史 [16] [[RFC 4291]] (>>15) 以前にも、[[RFC 3513]], [[RFC 2373]] の同じく [CSECTION@en[2.2. Text Representation of Addresses]] で[[IPv6アドレス]]の文字列表現が定義されていました。 これらは同じ [[RFC]] の他の部分の変更に伴う改訂で、文字列表現の部分はずっと変更されていません。 ;; [[RFC 2373]] の前の版である [[RFC 1884]] の時点では[[接頭辞]]の文字列表現は定義されていませんでした。 * メモ [1] [CITE@en[IPv6 validation (and caveats) - Crisp's blog]] ([TIME[2009-07-05 12:39:37 +09:00]] 版) >I started out with the RFC mentioned in the title of the request, which was RFC-2732 which referred to RFC-2373 for the ABNF syntax of IPv6 >however, I quickly noticed that this expression (and thus the ABNF in the RFC) couldn't be correct because it doesn't limit the number of hex4 groups and is totally wrong in the way it checks for an IPv4 formatted part. > Luckily this has been fixed in RFC-3986 which mentions the following ABNF >Now that's something else... Also note how this strictly defines the format of an IPv4 address. This either called for a monstrous regular expression or a tokenizing approach. I started out with the latter but quickly abandoned it because it became rather chaotic and didn't perform very well. >These are 3 examples of invalid addresses which pass using PHP's filter_var: [PRE[ ::01.02.03.04 (leading zero's not allowed in IPv4 part digits) 0:0:0:255.255.255.255 (not enough parts and no compression) 1fff::a88:85a3::172.31.128.1 (only one part may be compressed) ]PRE]