[2] IPv6 アドレスaddressは、IPv6 において通信の当事者を識別する番地アドレスです。

仕様書

データモデル

[87] IPv6アドレスIPv6 addressは、128ビット識別子です >>86。

[88] IPv6アドレスは、8個の16ビット片16-bit pieceの順序付きの列です >>86。

IPv6 アドレスの文字列表現

[3] IPv6アドレスは ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 のように16進数を16ビットごとに「:」で区切って表記することになっています。

仕様書

構文

[24] 以下で「制約」として述べるのは RFC 5952 によって追加された規定です。 実装は引き続きそれに従わない旧来の形式のIPv6アドレスも受け付けなければなりません が、生成する時は制約に従うべきですし、人間が書くときも従うのがよいでしょうadvised

 >>22 4.。

[25] 以下の「制約」は「しなければなりません」と述べているものの、 >>24 により実質的には「するべきです」レベルの要件になってしまいます。

ABNF 定義

[50] RFC 3986 では構文を ABNF で表現しています。

  • [51] RFC 3986 Uniform Resource Identifier (URI): Generic Syntax http://tools.ietf.org/html/rfc3986
    • [52] 3.2.2. Host http://tools.ietf.org/html/rfc3986#page-21

[53] 

      IPv6address =                            6( h16 ":" ) ls32
                  /                       "::" 5( h16 ":" ) ls32
                  / [               h16 ] "::" 4( h16 ":" ) ls32
                  / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
                  / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
                  / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
                  / [ *4( h16 ":" ) h16 ] "::"              ls32
                  / [ *5( h16 ":" ) h16 ] "::"              h16
                  / [ *6( h16 ":" ) h16 ] "::"

      ls32        = ( h16 ":" h16 ) / IPv4address
                  ; least-significant 32 bits of address

      h16         = 1*4HEXDIG
                  ; 16 bits of address represented in hexadecimal

[54] この定義はかなり厳密ですが、 RFC 5952 の制約は反映されていません。 (時期的にもそうですし、 技術的にも困難そうです。)

[55] RFC 5321 にも ABNF 定義がありますが、少し簡潔な分、不完全な定義になっています。

[85] RFC 3875 にも ABNF 定義がありますが、簡潔で不正確になっています。更に、 RFC 3513 を参照しています。

  • [58] RFC 2821 Simple Mail Transfer Protocol (廃止済み)
    • [59] 4.1.3 Address Literals http://tools.ietf.org/html/rfc2821#section-4.1.3
  • [56] RFC 5321 Simple Mail Transfer Protocol
    • [57] 4.1.3. Address Literals http://tools.ietf.org/html/rfc5321#page-44
  • [84] RFC 3875 - The Common Gateway Interface (CGI) Version 1.1 ( 版) http://tools.ietf.org/html/rfc3875#page-16

[93] RFC 7239 の節点識別子は RFC 3986 の定義を参照しており、 更に RFC 5952 に従うべきとしています。

IPv4 アドレスが埋め込まれた IPv6 アドレス

[36] >>32 によれば事前の知識により IPv4アドレスが埋め込まれていると接頭辞から判断できる IPv6アドレスは混合表記を使うべきです。これに該当する接頭辞は以下のものがあります。

[39] 2008:db8:: はしばしば IPv4アドレスを埋め込まれて使われるのを見かけますが、 これは RFC 3849 で説明用に予約されているアドレス群なので、 純粋な IPv6アドレスとして使われることもあり、>>32 には該当しません。

問題点

構文解析

[96] IPv6構文解析器IPv6 parser >>89

[97] ホスト構文解析器から呼び出されます。

歴史

[5] RFC 4291 (>>4) 以前にも、RFC 3513, RFC 2373, RFC 1884 の同じく 2.2. Text Representation of Addresses でIPv6アドレスの文字列表現が定義されていました。 これらは同じ RFC の他の部分の変更に伴う改訂で、文字列表現の部分はずっと変更されていません。

[23] >>5 の定義は柔軟で場面によっては却って使いづらいことがあり、RFC 5952 でより好ましい表記方法が選択されることになりました。

[40] RFC 2373 では附属書として文字列表現の ABNF 構文が追加されました。 この定義は実は間違っていて、 × 2001:db8:::192.0.2.1 のような正しくないアドレスが生成されるものでした。 この ABNF は RFC 3513 でなぜか削除されています。

[41] RFC 3261 (SIP) は RFC 2373 の ABNF をコピペしていたために同じ間違いを抱えており >>48、 RFC 5954 で訂正されています。 RFC 5954 は RFC 3986 からコピペしています。 (同時に IPv4アドレスの構文も厳密化されています。)

RFC 3261 の前の版である RFC 2543 は IPv6 に対応していませんでした。
  • [47] RFC 3261 SIP: Session Initiation Protocol
    • [48] 25.1 Basic Rules http://tools.ietf.org/html/rfc3261#page-222
  • [49] RFC 5954 Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261 http://tools.ietf.org/html/rfc5954

[60] はじめて IPv6アドレスを URL に導入した RFC 2732 (RFC 3986 により廃止) は、IPv6address の定義を >>40 の RFC 2373 を参照しており、 同じ間違いを含有していました。RFC 3986 では独自定義 (>>53) に変更することで修正されています。

IPv6 アドレス接頭辞の文字列表現

[14] IPv6アドレスの接頭辞は「2001:0DB8:0:CD30::/60」のように IPv6アドレスの後に先頭からのビット数を併記して表すことになっています。

仕様書

構文

[17] >>15

  1. IPv6アドレスの文字列表現
  2. /
  3. 先頭から何ビット分かを表す整数

[18] IPv6アドレスは任意の文字列表現を使えるので、:: による省略も使えますが、 省略を展開してからビット長が適用されることに注意が必要です。

例えば 2001:0DB8::CD30/60 は 2001:0DB8:0000:0000:0000:0000:0000:CD30/60 と同じ意味で、接頭辞として考えると最後の「CD30」は意味がなくなります。 これは接頭辞としてはおかしな表記ですが、 >>20 の用法では意味があります。

歴史

[16] RFC 4291 (>>15) 以前にも、RFC 3513, RFC 2373 の同じく 2.2. Text Representation of Addresses でIPv6アドレスの文字列表現が定義されていました。 これらは同じ RFC の他の部分の変更に伴う改訂で、文字列表現の部分はずっと変更されていません。

RFC 2373 の前の版である RFC 1884 の時点では接頭辞の文字列表現は定義されていませんでした。

例

[19] >>15

これらはいずれも接頭辞として 20010DB80000CD3 を表します。

節点のIPv6アドレスと接頭辞の併記

[20] IPv6アドレスの接頭辞の文字列表現を使って、 節点nodeのIPv6アドレスと、その属するネットワークのIPv6アドレスの接頭辞を併記することができます。

[21] 例えば、

... は略して

... と表記できます >>15。

ポート番号との併記

[33] TCP や UDP のポート番号と IPv6アドレスを併記する場合にはいろいろな方法が採られています。 URL などでは「:」が区切りに使われてきましたが、IPv6アドレス内部でも「:」 が区切りに使われるため、曖昧性が生じます。 RFC 5952 は基本的には IPv6アドレスを「[」,「]」 で括る方法 (URL で採用されている方法) を推奨しています。

仕様書

例

[35] >>34 6.

文脈的に曖昧性がなければ3つ目以降の書式を使っても問題ないとされています。

ドメイン名や IPv4 アドレスとの併記

[42] IPv6アドレスは「:」を使っているので、 ドメイン名やIPv4アドレスとは完全に区別ができます。

URL の場合

[43] しかし、URL では >>33 のポート番号の問題があるため、 IPv6アドレスは「[」,「]」 で括られることになっており、括られないドメイン名やIPv4アドレスと区別されます。

[44] なお、 URL は将来の版の IP にも対応する構文があり、 [vn....] のように記述できます。 「vn.」の部分で IPv6アドレスと区別されます。

電子メール・アドレスの場合

[45] 電子メールのアドレスでは以前からドメイン名はそのまま、 IPv4アドレスは「[」,「]」 で括って表記、と区別がされてきました。

[46] IPv6アドレスは「[IPv6:」,「]」 となって更に区別されています。

非大域アドレスの表現

[63] 非大域アドレスの表現の方法は RFC 4007 で定義されています。

仕様書

構文

[65] 

<address>%<zone_id>
... のように、通常の IPv6アドレスの後に「%」とゾーン識別子を続けます >>64。

[66] ゾーン識別子は、 (区切子と衝突しない限り) 実装依存であり、好きに決められることになっています >>64。ゾーン識別子はネットワーク上を転送されないため、相互運用性に特に寄与しないからです。 従って厳密な構文も定められていません。ただし、実装は最低でも数値による指定には対応するべきであるとされています >>64。

[74] 純粋な IPv6アドレスとしてだけではなく、アドレス接頭辞としても用いることができます。

関連

[76] RFC 3986 は、その定義する URI の構文ではゾーン識別子は使えない、と言及していました。

[75] RFC 4007 でも URL での利用については定められていません。 URL にゾーン識別子が指定されていたら、ネットワークに転送する必要があるなら落とさないとあちらさんが混乱するかも、 % は %25 としないと URL 的にまずい、 といった注意事項を挙げ、それを根拠に有用性が十分ではないので規定しないとしています >>64。

[80] 以前は IPvFuture を使った URL の拡張が提案されていました。 SMTP にも同様の書式が提案されていました。

[79] draft-fenner-literal-zone-02 - Formats for IPv6 Scope Zone Identifiers in Literal Address Formats https://tools.ietf.org/html/draft-fenner-literal-zone-02

例

アドレスの例

  • [67] fe80::1234%1 >>64
  • [68] ff02::5678%5 >>64
  • [69] ff08::9abc%10 >>64
  • [70] fe80::1234%ne0 >>64
  • [71] ff02::5678%pvc1.3 >>64
  • [72] ff08::9abc%interface10 >>64

接頭辞の例

  • [73] fe80::%2/64 >>64

簡潔表現

[82] 1996年4月1日に出版された RFC 1924 では、 85進数によってより短く IPv6アドレスを表現する方法を規定しています。

仕様書

ipv6-literal.net

[109] IPv6 address - Wikipedia, , https://en.wikipedia.org/wiki/IPv6_address#Literal_IPv6_addresses_in_UNC_path_names

文脈

[95] IPv6アドレスとIPv4アドレスが用いられる場所や、 その両者の区別については、IPアドレスを参照。

関連

[90] URL での表記については、 authority の項を参照してください。

[108] RFC 1924 で Base85 IPv6アドレスが定義されています。

[110] RFC 8369 で UTF-128 が定義されています。

メモ

[1] IPv6 validation (and caveats) - Crisp's blog ( 版) http://crisp.tweakblogs.net/blog/2031/ipv6-validation-(and-caveats).html

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:

::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)

[61] RFC 6021 - Common YANG Data Types ( 版) http://tools.ietf.org/html/rfc6021

[62] IPv6アドレスなどのデータ型が定義されています。

[77] IPv6 address - Wikipedia, the free encyclopedia ( ( 版)) http://en.wikipedia.org/wiki/IPv6_address

[81] XMPP は JID において IPv6アドレスを記述できます。 RFC 3920 では IPv6アドレスを直接記述できましたが、 RFC 6122 では RFC 3986 を引用し、 [ と ] で括る方式に改められています。 (非互換変更....)

RFC 6122 - Extensible Messaging and Presence Protocol (XMPP): Address Format ( 版) http://tools.ietf.org/html/rfc6122#page-5

[91] RFC 6943 - Issues in Identifier Comparison for Security Purposes ( ( 版)) http://tools.ietf.org/html/rfc6943#section-3.1.2

[92] RFC 7249 - Internet Numbers Registries ( ( 版)) http://tools.ietf.org/html/rfc7249#section-2.3

[94] CSP2/CSP3: Drop support for IPv6. · b52c77b · w3c/webappsec ( 版) https://github.com/w3c/webappsec/commit/b52c77b82b14ec7b619708543f5f9507215548a7

[98] Editorial: cleanup host similarly to URL (annevk著, ) https://github.com/whatwg/url/commit/7f9c5fd9236f9a329c48615bce5d25b50f276738

[99] Disallow invalid IPv4 in IPv6 parser (rmisev著, ) https://github.com/whatwg/url/commit/a7ae1b846b91d564229faeaafdd28cb7451faa1d

[100] Make IPv6 addresses in special URLs valid (annevk著, ) https://github.com/whatwg/url/commit/aec942485630870e742d829dd9df61600796ad6e

[101] Attempt to explain valid input better (annevk著, ) https://github.com/whatwg/url/commit/50cb9ab9d8f70cc2bc72e91976bfaea0ad0fd330

[102] Clarify IPv6 serializer (annevk著, ) https://github.com/whatwg/url/commit/72865694ca2fc54b1c5fcfea9bed9f6b34e365ac

[103] RFC 8135 - Complex Addressing in IPv6 () https://tools.ietf.org/html/rfc8135

[104] Editorial: remove labels from IPv6 parser (annevk著, ) https://github.com/whatwg/url/commit/703fcd0b92053345582a36b2e4a642ab65df076e

[105] Editorial: IPv4 in IPv6 cleanup (rmisev著, ) https://github.com/whatwg/url/commit/488c459d9e4245a3f6bf087e7dcd2c7e91487ac5

[106] Editorial: refactor IPv6 in terms of lists (annevk著, ) https://github.com/whatwg/url/commit/a622235308342c9adc7fc2fd1659ff059f7d5e2a

[107] インターネット10分講座:RFC5952 -IPv6アドレスの推奨表記 - JPNIC (Japan Network Information Center著, ) https://www.nic.ad.jp/ja/newsletter/No46/0800.html