IPv6アドレス

IPv6アドレス（アイピーブイシックスアドレス、英: IPv6 address）とは、IPv6コンピュータネットワークにおいてコンピュータ等のノードのネットワークインタフェースを判別するための番号（IPアドレス）である。 IPアドレスは、ホストの個々のネットワークインタフェースを特定し、ホスト間でIPパケットのルーティングを行うために使用される。IPアドレスはパケットのヘッダに記載され、そのパケットの送信元と送信先を示している。 IPv6は、インターネットにおいて最初に使用されたIPv4を継承している。IPv4が32ビットのIPアドレスを使用するのに対し、IPv6は128ビットのIPアドレスを使用する。このため、IPv6はIPv4と比べて非常に大きなIPアドレス空間を持っている。 IPv6アドレスは、以下の3種類に分類される。 ユニキャストアドレス - 単一のインタフェースのための識別子。インターネットプロトコルは、ユニキャストアドレスに送られたパケットを、そのアドレスによって識別されるインタフェースに配送する。 エニーキャストアドレス - インタフェース集合（通常は異なるノードに属する）のための識別子。エニーキャストアドレスに送られたパケットは、そのアドレスで識別されるインタフェースの内で、ルーティングプロトコルの距離の定義に従って「最も近く」(nearest)にあるただ1つのインタフェースに配送される。エニーキャストアドレスはユニキャストアドレスと同じフォーマットのため、表記上は区別がつかない。ただ、同じアドレスが複数のインタフェースに設定されるかどうかの違いしかない。 マルチキャストアドレス - エニーキャストと同様にインタフェース集合のための識別子であるが、マルチキャストアドレスに送られたパケットは、そのアドレスを持つすべてのインタフェースに配送される。 IPv6にはブロードキャストアドレスは存在せず、その機能はマルチキャストアドレスが果たす。 IPv6アドレスは128ビットのアドレス幅を持っている。アドレスは、アドレス指定とルーティングの方法により、ユニキャストアドレス、マルチキャストアドレス、エニーキャストアドレスに分類される。これらのそれぞれに、論理的に128のアドレス・ビットをビット・グループに分け、これらのビット・グループの値を特別なアドレス指定機能と結びつけることによって、様々なアドレス・フォーマットが存在する ユニキャストアドレスとエニーキャストアドレスは、通常2つの部分に分けられる。前半の64ビット（サブネットプリフィックス）はルーティングに使用され、後半の64ビット（インタフェース識別子）はサブネット内での個別のインタフェースを指し示す。 ネットワークプリフィックス（「ルーティングプリフィックス」と「サブネットID」）は、アドレスの中の上位64ビットである。ルーティングプリフィックスのサイズは可変である。プリフィックスのサイズが大きくなると、その分だけサブネットIDのサイズが小さくなる。サブネットIDのビットのフィールドは、ネットワーク管理者が与えられたネットワーク内でサブネットを定義するのに使用することができる。64ビットの「インタフェース識別子」は、ランダムに決定されるか、DHCPv6サーバから取得するか、インタフェースのMACアドレスからmodified EUI-64を使用して自動的に決定されるか、手動で設定するかのいずれかで決められる。 リンクローカルアドレスもまたインタフェース識別子に基づいているが、ネットワークプリフィックスとは異なるフォーマットになっている。 prefix（プリフィックス）フィールドは二進数の値 1111111010 であり、54個のゼロがその後に続く。全てのリンクローカルアドレスのネットワークプリフィックスは同じ（fe80::/64 : リンクローカルアドレスプリフィックス）になり、それがルーティング不可であることを示す。 マルチキャストアドレスは、いくつかの特別なルールに従ってフォーマットされている。 全てのマルチキャストアドレスで、prefix（プリフィックス）は二進数の値 11111111 である。 flg（フラグ）フィールドの4つのビットのうち3つは値の意味が定義されているが、最上位ビットは将来のために予約されている。 4ビットのスコープフィールド (sc) は、アドレスが有効でユニークとなる有効範囲を示すのに使われる。 要請ノード(solicited-node)には特別なマルチキャストアドレスが与えられる。 sc（スコープ）フィールドは二進数値 0010 （リンクローカル）である。要請ノードマルチキャストアドレスは、ユニキャストアドレスやエニーキャストアドレスの最後の24ビットをマルチキャストアドレスの最後の24ビットに写して作られる。 リンク範囲(link-scoped)マルチキャストアドレスは、互換性のあるフォーマットを使用する。 IPv6アドレスは、128ビットを16ビットずつの8つのグループに区切ってそれぞれのグループを4桁の十六進数で表記し、グループとグループの間をコロンで仕切る。例えば以下のように表現される。 2001:0db8:85a3:0000:0000:8a2e:0370:7334 十六進数は大文字・小文字を区別しないが、IETFでは小文字を使用するよう推奨している。この表記は、以下に示す方法で短く表現することができる。 0の連続 各区切りの先頭の連続する0は省略できる。このルールを適用すると、上記に例示したアドレスは以下のように表記できる。 2001:db8:85a3:0:0:8a2e:370:7334 0だけのグループ 1つ以上の0だけのグループは、"::"で表すことができる。このルールを適用すると、上記に例示したアドレスは以下のように表記できる。 2001:db8:85a3::8a2e:370:7334 localhost（ループバック）アドレス 0:0:0:0:0:0:0:1 は ::1 と、IPv6未指定アドレス 0:0:0:0:0:0:0:0 は :: と表現できる。1つのアドレス内では :: は1回しか使用できない。これは、:: を2回以上使用すると、それぞれの省略した箇所のビット長がわからなくなるためである。 IPv4アドレスが埋め込まれている場合 IPv4とIPv6が混在している環境で、IPv4をIPv6に変換して使用する場合、下位32ビットにIPv4アドレスを含んだIPv4変換IPv6アドレスやIPv4射影IPv6アドレスを使用する。この場合、IPv4アドレスの部分を、通常IPv4アドレスを表記するときに使用する、十進数と"."による記法で表現することができる。例えば、IPv4射影IPv6アドレスの ::ffff:c000:0280 は ::ffff:192.0.2.128 と表現することができる。 IPv6アドレスを単純化しようとしたとき、標準の規定ではIPアドレスの表現に柔軟性がある。しかし、そのために同一のIPアドレスについて複数の表現が許されることになり、特定のIPアドレスをテキストファイルやトラフィックの中から探したり、2つのアドレスが同一であるかを調べたりするのが困難になる。 IETFは、この問題を軽減するために、IPv6アドレスをテキストで表現する際の規範的なフォーマットの規定を RFC 5952 として提案した。この規定は以下の通りである。 それぞれの16ビットフィールドの先頭の0は省略する。例えば、2001:0db8::0001 は 2001:db8::1 とする。ただし、全てが 0 である16ビットフィールドは 0 とする。 0のみのフィールドが連続する場合は"::"で短くする。例えば 2001:db8:0:0:0:0:2:1 は 2001:db8::2:1 とする。0のみのフィールドがひとつだけの場合は"::"を使わない。例えば 2001:db8:0000:1:1:1:1:1 は 2001:db8:0:1:1:1:1:1 とする。 表現は、できる限り短くする。全て0のフィールドの連続で最も長い物を"::"に置き替える。同じ長さの全て0のフィールドの連続が複数ある場合は、最も左の物を"::"にする。例えば、 2001:db8:0:0:1:0:0:1 は 2001:db8:0:0:1::1 ではなく 2001:db8::1:0:0:1 とする。 十六進数の英文字は常に小文字で書く。例えば、2001:DB8::1 ではなく 2001:db8::1 とする。 IPv6ネットワークは、2の累乗個のサイズの一定のIPv6アドレスのグループである「アドレスブロック」を使用する。アドレスの先頭のビットは、与えられたネットワーク内の全てのホストで同一であり、ネットワークアドレスまたはルーティングプリフィックスと呼ばれる。 ネットワークアドレスの範囲はCIDR表記で表される。ネットワーク表現は、ブロックの最初のアドレス（最後のビットが全て0になる）の後にスラッシュ（/）および、プリフィックスのビット長を十進数で書く。例えば、2001:db8:1234::/48 と表現されるネットワークは、2001:db8:1234:0000:0000:0000:0000:0000 に始まり 2001:db8:1234:ffff:ffff:ffff:ffff:ffff で終わる。 インタフェースアドレスのルーティングプリフィックスは、直接にアドレスとCIDR記法で表すことができる。例えば、2001:db8:a::/64 のサブネットに接続されているアドレス 2001:db8:a::123 のインタフェースの設定は、 2001:db8:a::123/64 のように書くことができる。 スラッシュに続く十進数の数値が表すのは、そのアドレスブロックに含まれるアドレスの数ではなく、ネットワークプリフィックスのビット数である。例えば、48ビットのプリフィックスのアドレスブロックは"/48"と表される。そのようなアドレスブロックは、 2128 − 48 = 280 個のアドレスを含んでいる。ネットワークプレフィックスの値がより少ないほど、ブロックは大きくなる。/21のブロックは/24のブロックの8倍の大きさがある。 IPv6アドレスのコロン(:)は、URIやURLのような資源識別子の確立した文法と競合する。コロンは伝統的にホストパスとポート番号の区切りに使用されてきた。この競合を軽減するため、資源識別子の中ではIPv6アドレス を角括弧（[]）で囲む。例えば、以下のようにする。 https://[2001:db8:85a3:8d3:1319:8a2e:370:7348]/ URLがポート番号を含む場合は以下のようにする。 https://[2001:db8:85a3:8d3:1319:8a2e:370:7348]:443/ Microsoft Windowsオペレーティングシステム (OS) では、IPv4アドレスはUniform Naming Convention (UNC) のパス名に含めることができる。しかし、UNCパス名ではコロンは文法的に意味を持っているため、IPv6アドレスはそのままではUNCパス名に使用できない。このため、マイクロソフトはUNCパスに使用できるドメイン名にIPv6アドレスを含められるような変換アルゴリズムを実装している。このために、マイクロソフトはセカンドレベルドメインipv6-literal.netをインターネット上で登録し、保持している。IPv6アドレスは、以下のように、この名前空間のホスト名やサブドメイン名に変換される。 2001:db8:85a3:8d3:1319:8a2e:370:7348 は以下のように変換される。 2001-db8-85a3-8d3-1319-8a2e-370-7348.ipv6-literal.net この表記は、マイクロソフトのソフトウェアによってDNSサーバを介さずに自動的に名前解決される。IPv6アドレスがゾーンインデックスを含む場合、それは文字"s"に続けてアドレス部に追加される。 fe80--1s4.ipv6-literal.net 未指定アドレス(::)以外の全てのIPv6アドレスは「スコープ」(scope)を持っている。スコープは、そのアドレスが有効である範囲を特定するのに使用する。 ユニキャストアドレスでは、リンクローカルアドレスとループバックアドレスはlink-localのスコープを持っている。link-localスコープは、そのアドレスが直接接続(link)されているネットワークでのみ使用されることを意味する。 ユニークローカルアドレスを除くそれ以外のアドレスは、global（またはuniversal）のスコープを持つ。globalスコープは、そのアドレスが世界的にルーティング可能であり、全ての箇所においてglobalスコープのアドレスと、直接接続のネットワークにおいてlink-localスコープのアドレスと接続可能であることを意味する。 ユニークローカルアドレスは世界的にルーティング可能ではなく、そのアドレスはそれが使われているネットワークの範囲内でのみ有効である。ユニークローカルアドレスは、ルーティング・テーブルが特にそれを許可するように構成されたルータやトンネルによってルーティングされる。 エニーキャストアドレスのスコープは、ユニキャストアドレスのスコープと同様に定義される。 マルチキャストのために、マルチキャストアドレスの2つ目のオクテットの最下位から4番目のビット(ff0s::)がアドレスのスコープ(scope)、すなわち、マルチキャスト・アドレスが伝達される範囲を示す。現在定義されているスコープは以下の通りである。 IPv6アドレスの割り当てプロセスの管理は、インターネットアーキテクチャ委員会とInternet Engineering Steering GroupからInternet Assigned Numbers Authority (IANA)に委任されている。主な機能は、大きなアドレスブロックを地域インターネットレジストリ(RIR)に割り当てることである。RIRは、世界の地域ごとに、ネットワーク・サービス・プロバイダや他のローカルインターネットレジストリへのアドレスの割り当てを委任されている。IANAは、IPv6アドレス空間の公式の割り当てリストの管理を1995年12月から行っている。 効果的な経路集約(route aggregation)を提供し、それによってインターネット・ルーティング・テーブルのサイズを減らすために、全体のアドレス空間の8分の1(2000::/3)だけがインターネットで使用するために割り当てられている。IPv6アドレス空間の残りは、将来の利用と特別な目的のために予約されている。アドレス空間は/23から/12という大きなブロック単位でRIRに割り当てられている。 RIRはローカルインターネットレジストリ(LIR)に小さなブロックを割り当てる。そのサイズは一般的に/19から/32の範囲である。アドレスは一般的に/48から/56の単位でエンドユーザに分配される。 グローバルユニキャストの割り当ての記録は、それぞれのRIRのサイトなどで閲覧できる。 IPv6アドレスは、IPv4アドレスと比較して大きなブロックで各組織に割り当てられる。推奨された割り当ての大きさである/48は280個のアドレスを含んでおり、これはIPv4アドレスの全アドレス空間（32ビット）の248倍（約2.8×1014倍）である。IPv6アドレスの全アドレス空間は2128個（340,282,366,920,938,463,463,374,607,431,768,211,456個、約3.4×1038個、340澗個、340兆の1兆倍の1兆倍）もあるため、予見できる将来に対して十分である。 それぞれのRIRは1つの/23ブロックを512個の/32のブロックに分割することができ、一般的には1つのISPに対して1つの/32ブロックを割り当てる。ISPは割り当てられた/32ブロックを65536個の/48ブロックに分割することができ、一般的には1人の顧客に対して1つの/48ブロックを割り当てる。顧客は割り当てられた/48ブロックから65536個の/64のネットワークを作ることができる。/64のネットワークには264個（18,446,744,073,709,551,616個、約1.8×1019個、1845京個）のアドレスが収容できる。これでもIPv4の全アドレス空間（232個、4,294,967,296個、約4.3×109個）の232倍の個数である。 計画的に、アドレス空間の非常に少ない部分だけが、実際には使われる。大きなアドレス空間はアドレスがたいてい利用できることを確実にする。そして、それはアドレス維持のためにネットワークアドレス変換(NAT)を使用することを完全に不必要にする。NATはIPv4ネットワークにおいてIPアドレス枯渇問題を軽減するために今後も使われる。 それぞれのサブネットプリフィックスの最も低いアドレス（インタフェース識別子を全て0に設定したもの）は、「サブネット・ルータ・エニーキャストアドレス」として予約されている。アプリケーションはこのアドレスを利用可能な1つのルータとの通信に利用できる。このアドレス宛のパケットはただ1つだけのルータに届く。 /64のサブネットプリフィックスの最上位の128個のアドレスは、エニーキャストアドレスとして予約されている。これらのアドレスは、インタフェース識別子の最初の57ビットが1で、残りの7ビットがエニーキャストIDである。この場合、そのアドレスが世界的に唯一ではないことを示すために、universal/localビットは0にしなければならない。エニキャスト識別子0x7eはmobile IPv6ホームエージェント・エニーキャストアドレスとして定義されている。エニキャスト識別子0x00から0x7dまでと0x7fは予約されており、何にも使用されていない。 IPv6において特別な意味を持つアドレスがある。それを以下に挙げる。 ::/128 — 全ビットが0のアドレスは未指定アドレス(unspecified address)と呼ばれる。IPv4における「0.0.0.0/32」に相当する。 このアドレスは、いかなるインタフェースも割り当ててはならない。このアドレスは、初期化中のホストの自分自身のIPアドレスを知る前にIPv6パケットを送る場合の送信元アドレスとして使用される。ルータは未指定アドレスを持つパケットを転送してはならない。 ::/0 — デフォルトルートを表すアドレスである。IPv4における「0.0.0.0/0」に相当する。 ::1/128 — ループバックアドレスはユニキャストlocalhostアドレスである。ホストのアプリケーションがこのアドレス宛にパケットを送信したときは、IPv6スタックはそのパケットを同じ仮想インタフェースにループバックする。IPv4における「127.0.0.1/8」に相当する。 fe80::/10 — リンクローカルプリフィックスのアドレスは、単一の接続の中でのみ有効であり唯一である。このプリフィックスにおいては1つのサブネットのみが割り当てられ（残り54ビットは0）、効果的なフォーマットは fe80::/64 と与えられる。下位64ビットはインタフェースのハードウェアアドレスからmodified EUI-64によって決められるのが一般的である。リンクローカルアドレスは、あらゆるIPv6対応インタフェースで必要とされる。IPv6ルーティングがないときは、アプリケーションはリンクローカルアドレスの存在に頼るかもしれない。これらのアドレスは、IPv4における自動設定アドレス 169.254.0.0/16 に相当する。 fc00::/7 — ユニークローカルアドレス (ULA) はローカルな通信のために使われる。それらは、設定されたサイトの中でだけルーティングできる。このブロックは2つの部分に分割される。後半半分(fd00::/8)は「確率論的にユニークな(probabilistically unique)」アドレスとして使用され、40ビットの擬似乱数を用いて/48の割り当てを得る。これは、結合または互いと通信しようとする2つのサイト間で競合するアドレスができてしまう可能性が僅かにあるということを意味するが、どの程度僅かなのかは不詳である。前半半分(fc00::/8)は割り当てない方式のために定義されている。これらのアドレスは、IPv4のプライベートアドレス(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)に相当する。 ::ffff:0:0/96 — このプリフィックスは「IPv4射影IPv6アドレス」(IPv4-mapped IPv6 address)に割り当てられている。この種類のアドレスを使用することで、IPv4のトランスポート層プロトコルをIPv6ネットワークアプリケーションプログラミングインタフェース(API)を透過して使用することができる。サーバアプリケーションは、1つのソケットを待ち受けるだけで、IPv6とIPv4の両方のクライアントからの要求を受け付けることができる。IPv4クライアントは、IPv4射影IPv6アドレスによって、サーバからはIPv6クライアントのように見える。伝送においても同様に取り扱われる。IPv4またはIPv6のデータグラムを伝送するのに、IPv6アドレスとIPv4射影IPv6アドレスにバインドされた確立したソケットを使用することができる。（IPv6#IPv4との相互運用を参照） ::ffff:0:0:0/96 — 「IPv4変換IPv6アドレス」(IPv4-translated address)に割り当てられており、ステートレスIP/ICMP変換(SIIT)プロトコルに使用する。 64:ff9b::/96 — "Well-Known Prefix"。このプリフィックスのアドレスは、自動IPv4/IPv6トランスレーション(NAT64)に使用する。 2002::/16 — このプリフィックスは、6to4のために使用される。（6to4はHistoricalとなった RFC 7526) IANAは'Sub-TLA ID'と呼ばれるアドレスブロックを特別な用途のために予約している。それは、 2001:0000::/29 から 2001:01f8::/29 までの範囲の64のネットワークプリフィックスである。その内の3つは以下のものである。 2001::/32 — teredoに用いられる。 2001:2::/48 — Benchmarking Methodology Working Group (BMWG)に割り当てられており、IPv6のベンチマークに使用されている。IPv4でベンチマークに使用されている 198.18.0.0/15 に相当する。プリフィックス 2001:0200::/48 は RFC 4773 ではなく RFC 5180 で定義されている。 2001:20::/28 — ORCHIDv2 (Overlay Routable Cryptographic Hash Identifiers)に割り当てられている。これらはCryptographic Hash Identifiersに使うルーティングされないIPv6アドレスである。 2001:db8::/32, 3fff::/20 — これらのプリフィックスは、文書記述用に使用される。このアドレスは、マニュアルや設定サンプル等に例示としてIPv6アドレスを使用する場合に使用される。このアドレスは実際の通信には使用してはならない。IPv4では 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 がこの目的で使用されている。 0100::/64 — このプリフィックスは、破棄するトラフィックに使用される。 マルチキャストアドレス ff0X::（Xは十六進数の値）は予約されており、いかなるマルチキャストグループにも割り当ててはならない。Internet Assigned Numbers Authority(IANA)がアドレスの予約を管理している。 ff0X::のIPv6マルチキャストアドレスは、以下の物に割り当てられている。 要請ノードマルチキャストアドレス（英語版）のグループIDの下位24ビットは、インタフェースのユニキャストアドレスまたはエニーキャストアドレスの下位24ビットである。このアドレスは、ローカル・ネットワーク上の全てのノードを妨げずに、近隣探索プロトコル(NDP)によるリンク層アドレス解決をすることができる。ホストは、設定されたユニキャストアドレスまたはエニーキャストアドレスの要請ノードマルチキャストグループに参加しなければならない。 システムの起動時、ノードは、それぞれのIPv6が利用可能なインタフェースについてリンクローカルアドレスを自動的に生成する。グローバルにルーティングできるアドレスが、手動で設定されるか、後述する「設定プロトコル」から得られる場合でも同様である。 それは、近隣探索プロトコルの機能を使用したステートレスアドレス自動設定(SLAAC)によって、独立して、そして、事前設定なしで動作する。このアドレスはプリフィックス fe80::/64 の中から選択される。 IPv4に「設定プロトコル」はDHCPやPPPを含む。DHCPv6もあるが、IPv6のホストはグローバルにルーティング可能なユニキャストアドレスを作るのに近隣探索プロトコルを用いる。ホストはルータ要請(RS: router solicitation)を送信し、IPv6ルーターは割り当てられたプリフィックスとともに応答を返す。 アドレスの下位64ビットは、64ビットのmodified EUI-64フォーマットによるインタフェース識別子である。この識別子は、通常そのインタフェースの全ての自動的に構成されたアドレスによって共有される。その利点は、1つのマルチキャスト・グループだけが近隣探索のために参加する必要があることである。このためには、ネットワークプリフィックス ff02::1:ff00:0/104 とアドレスの下位24ビットからなるマルチキャストアドレスが用いられる。 64ビットのインタフェース識別子は、48ビットのMACアドレスから生成するのが最も一般的である。MACアドレス 00:0C:29:0C:47:D5 は、真ん中に FF:FE を入れることで64ビットのEUI-64 00:0C:29:FF:FE:0C:47:D5 に変換される。このEUI-64をIPv6アドレスの中で使うとき、次のように変形される。 Universal/Localビット（EUI-64の最上位ビットを第1ビットとしたときの第7ビット）を反転する。ネットワークプリフィックス 2001:db8:1:2::/64 と上記のMACアドレスを用いてIPv6アドレスを生成すると、 2001:db8:1:2:020c:29ff:fe0c:47d5 となる。ここで、下線部はUniversal/Localビットが1に反転された箇所である。1はUniversal、0はLocalを意味する。 グローバルユニキャストアドレスのインタフェースIDには、MACアドレス等から生成されるModified EUI-64フォーマットが使用されることが多いが、プライバシー上の懸念があるため、一意性およびプライバシーの双方を満たす仕様（一時アドレス）への変更が推奨されている（RFC 7217、RFC 7721、RFC 8064）。 インタフェースにユニキャストIPv6アドレスを割り当てた後、Neighbor Solicitation（近隣要請）とNeighbor Advertisement（近隣広告）（ICMPv6のtype 135と136）メッセージを使ってそのアドレスが唯一のものであるかの確認を行う。確認を行っている間、そのアドレスは「仮」(tentative)の状態にある。 ノードは仮のアドレスの要請ノードマルチキャストグループに参加し（まだ参加していない場合）、仮アドレスを宛先、未指定アドレス(::/128)を送信元としてNeighbor Solicitationメッセージを送信する。ノードは、Neighbor Advertisementが受信できるようにするために全ホストマルチキャストアドレス ff02::1 にも参加する。 ノードが自身の仮アドレスを宛先とするNeighbor Solicitationを受信した場合、そのアドレスはユニークではない。ノードが、仮アドレスを送信元とするNeighbor Advertisementを受信した場合も同様である。アドレスがユニークであると確認できた時だけ、そのアドレスが割り当てられ、インタフェースによって使用される。 この仕組みを重複アドレス検出(DAD: Duplicate address detection)という。 インタフェースに割り当てられたIPv6アドレスは固定された有効期限(lifetime)を持つ。より短い期間に設定されない限り、有効期限は無制限である。アドレスには、preferred lifetimeとvalid lifetimeの2つの有効期限がある。有効期限は、ルーターで設定されて自動設定によって値が提供されるか、インタフェースに手動で設定する。 アドレスがインタフェースに割り当てられたとき、そのアドレスは"preferred"の状態にあり、preferred-lifetimeの間それが継続する。preferred-lifetimeが経過すると"deprecated"の状態になり、そのアドレスを使って新しい接続はできなくなる。valid-lifetimeが経過すると"invalid"の状態になり、そのアドレスはインタフェースから除かれ、インターネットから新しいアドレスの割り当てを受ける。 注意: ほとんどの場合、新しいRouter Advertisement(RA)を受信することで有効期限のタイマーが元に戻るので、有効期限は期限切れになることはない。しかし、RAが受信できない場合、preferred-lifetimeが経過してアドレスは"deprecated"状態になる。 ステートレスアドレス自動設定でインタフェース識別子を生成するのに、グローバルにユニークな固定のMACアドレスを使用している。そのため、時間がたってIPv6ネットワークプリフィックスが変わったとしても、MACアドレスによってネットワーク機器を、そしてユーザを追跡することができる。IPv6アドレスの一部とユーザが永久に結びつく危険性を減らすため、ノードは「一時アドレス」(temporary address)を作ることができる。一時アドレスは、時間によりランダムに変化するビット列に基づいたインタフェース識別子を使用し、有効期限を比較的短く（数時間から数日）することで短い時間で新しいアドレスに置き替えられる。 外部ホストがDNS問い合わせのできるパブリックアドレスを使っている場合、接続を始めるための送信元アドレスとして、一時的なアドレスを使用することができる。 Mac OS X Lion以降のmacOS、Windows Vista・Windows Server 2008以降のマイクロソフトのOSでは、IPv6のネットワークインタフェースの設定で、デフォルトで一時アドレスを使用する設定になっている。 実際には、ISPから配布されるプレフィックスが契約ごとに固定されている運用が多く、プレフィックスと他の情報を組み合わせて使用してユーザを追跡することができるため、プライバシー保護の観点からは、限定的な効果しかない。 IPv6利用可能なネットワークインタフェースは、通常2つ以上のIPv6アドレスを持っている。例えばリンクローカルとグローバルアドレス、恒久アドレスと一時アドレスなどである。 IPv6はアドレススコープと選択優先性(selection preference)の概念を導入している。選択優先性は、他のホストと接続するときに送信元と宛先のアドレスを選択するために複数の選択を与える。 優先選択アルゴリズムは、特定の宛先（デュアルスタック実装におけるIPv4射影IPv6アドレスを含む）の中で通信において最も適切なアドレスを選択するアルゴリズムであり、各々のルーティングプリフィックスを優先順位レベルと結びつけるカスタマイズ可能な選択テーブルに基づいている。デフォルトのテーブルは以下の通りである。 デフォルト設定は、IPv4よりもIPv6を優先し、できるだけ小さなスコープの宛先を優先する。そのため、他の条件が同じならば、グローバルにルーティングされた経路よりもリンクローカルの通信の方が優先される。プリフィックスポリシーテーブルはルーティングテーブルに似ている。すなわち、優先順位の値がルーティングテーブルにおける接続コストの役割として働き、より高い優先度はより大きい値として表される。 送信元アドレスは宛先アドレスと同じラベルの値により評価される。アドレスはビット列の最上位からの最長一致によってプリフィックスと比較される。候補の送信元アドレスはオペレーティングシステムから取得し、候補の宛先アドレスはDNS問合せによって取得する。 ホストの全てのリンクローカルアドレスは共通のプリフィックスを持つので、リンクローカルの宛先にパケットを送信するとき、出て行くインタフェースを選ぶのに通常のルーティング手順を用いることができない。そこで、ゾーンインデックス(zone index)と呼ばれる特別な識別子を用いて付加的なルーティングの情報を提供する。 アドレスが文字で書かれているとき、ゾーンインデックスはアドレスの後にパーセント記号(%)で区切って付加する。ゾーンインデックスの実際の構文は、OSに依存する。 Microsoft Windowsは、数値のゾーンインデックスを使用する（例 fe80::3%1）。インデックスは、インタフェース番号で決定される。 多くのUnix系OS（BSD, Linux, macOSなど）は、インタフェース名をゾーンインデックスに使用する（例 fe80::3%eth0）。 BSD系のOS（macOSを含む）では、数値のゾーンインデックスを2番目の16ビットフィールドに入れることでも表現できる（例 fe80:1::3）。 ゾーンインデックスの表記は、Uniform Resource Identifier(URI)の中で使用する時に文法的に競合するため、パーセント記号"%"をパーセントエンコーディングによって回避しなければならない。例 http://[fe80::3%25eth0] Domain Name System(DNS)では、AAAAリソースレコード（クアッドAレコード）によってホスト名をIPv6アドレスに対応づけしている。DNS逆引きのために、IETFはドメイン名ip6.arpaを維持しており、その名前空間は、後述するようにIPv6アドレスを4ビット（ニブル）単位で1桁ずつの十六進数に分けた物になっている。この仕組みは RFC 3596 で定義されている。 IPv4と同様、DNSではそれぞれのホストは2つのDNSレコード、アドレスレコードと逆引きポインターレコードによって表現される。例えば、derrickという名前のホストコンピュータがexample.comドメインにあり、ユニークローカルアドレス fdda:5cc1:23:4::1f を持っているとする。そのAAAAアドレスレコードは derrick.example.com. IN AAAA fdda:5cc1:23:4::1f となり、IPv6逆引きポインターレコードは f.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.3.2.0.0.1.c.c.5.a.d.d.f.ip6.arpa. IN PTR derrick.example.com. となる。 このポインターレコードは、d.f.ip6.arpaゾーンの権限の委任のチェーンに従って、いくつかのゾーンで定義される。 DNSプロトコルはトランスポート層プロトコルから独立している。要求されるデータのアドレスファミリに関係なく、DNSの問合せと応答はIPv6とIPv4のどちらによってでも送信される。 2009年現在、多くの家庭内ネットワークのNAT装置やルータのDNSリゾルバは、未だにAAAAレコードを不適切に取り扱う。これらのいくつかは、適切な否定のDNS応答をきちんと返さずに、単にそのようなレコードのDNS要求を破棄する。要求が破棄されるので、要求を送信しているホストはタイムアウトを待たなければならない。クライアント・ソフトウェアがIPv6接続が失敗するのを待ってからIPv4接続を行うため、デュアルスタックIPv6/IPv4ホストに接続しようとするときに、しばしば減速を引き起こす。 クライアント・ソフトウェアがHappy Eyeballs（英語版）アルゴリズム（Fast Fallbackアルゴリズムとも言う）を使用することで、この問題は軽減される。このアルゴリズムは、IPv6とIPv4の接続を同時に開始し、先に接続が完了した方を使用するという物である。 サイトローカルプリフィックス fec0::/10 は、組織内のサイトネットワーク内でのみ有効であると特定されたアドレスである。これは、1995年12月に定められた最初のアドレス体系の一部であったが、2004年9月に廃止された。これは、「サイト」という用語の定義が曖昧だったことにより、ルーティングのルールに混乱を生じていたためである。新しいネットワークはサイトローカルアドレスに対応してはならない。2005年10月、新しい仕様により、サイトローカルアドレスはユニークローカルアドレスに置き替えられた。 アドレスブロック 0200::/7 は、1996年8月にOSI NSAP-mapped プリフィックスとして定義されたが、2004年12月に廃止された。 96ビットの0のプリフィックス ::/96は「IPv4互換アドレス」(IPv4-compatible address)として知られ、1995年に初めて言及され、1998年に初めて記述された。IPv4互換アドレスは、IPv6移行技術の中でIPv4アドレスを表現するのに使用された。IPv4互換アドレスは、最初の（最上位の）96ビットを0とし、残りの32ビットでIPv4アドレスを表現する。2006年2月、Internet Engineering Task Force(IETF)はIPv4互換アドレスの使用を非推奨とし廃止された。IPv6アドレスを格納することのできる固定長のメンバーを持つテーブルやデータベースで、IPv4互換アドレスはIPv4アドレスを意味することになっている。 アドレスブロック 3ffe::/16 は、1998年12月に6bone（英語版）ネットワークの試験目的に割り当てられた。それ以前には、アドレスブロック 5f00::/8 がこの目的のために使用されていた。両方のアドレスブロックは2006年6月にアドレスプールに返還された。 IPv6アドレスのDomain Name System(DNS)の逆引き用のレコードは、intトップレベルドメインの下のip6ゾーンに登録されていた。2000年、インターネットアーキテクチャ委員会(IAB)はarpaトップレベルドメインを廃止する意向を示したが、2001年にarpaトップレベルドメインがその本来の機能を維持しなければならないと決めた。ip6.intドメインはip6.arpaに移された。ip6.intゾーンは正式に2006年6月6日に除去された。 2011年3月、IETFは、エンドサイトへのアドレスブロックの配分の推奨を変更した。/48, /64, /128を割り当てる（これは2001年のIABとIESGの見解に従ったものである）代わりに、インターネット・サービス・プロバイダは、より小さなブロック（例えば/56）をエンドユーザに割り当てることを考えなければならない。地域レジストリARIN, RIPE, APNICの方針は、必要に応じて/56の割り当てを促す。 ^ a b Modified EUI-64の使用はセキュリティの観点からは非推奨とされる。 ^ a b c d e f g h i j k RFC 4291, IP Version 6 Addressing Architecture, R. Hinden, S. Deering （2006年2月） ^ Silvia Hagen (May 2006). IPv6 Essentials (Second ed.). O'Reilly. ISBN 978-0-596-10058-2  ^ a b RFC 3956, Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address P. Savola, B. Haberman (November 2004) ^ a b RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses, B. Haberman, D. Thaler (August 2002) ^ RFC 4489, A Method for Generating Link-Scoped IPv6 Multicast Addresses, J-S. Park, M-K. Shin; H-J. Kim (April 2006) ^ RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding（英語版）, L. Masinter (January 2005) ^ “ipv6-literal.net Domain History”. who.is. 2016年2月24日閲覧。 ^ a b RFC 4007, IPv6 Scoped Address Architecture, S.Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill (March 2005) ^ RFC 1881, IPv6 Address Allocation Management, Internet Architecture Board (December 1995) ^ IPv6 address space at IANA. Iana.org (2010-10-29). Retrieved on 2011-09-28. ^ https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml IPv6 Global Unicast Address Assignments], IANA ^ DE-TELEKOM-20050113. Db.ripe.net. Retrieved on 2011-09-28. ^ “ARIN Number Resource Policy Manual: Initial allocation to ISPs”. 2016年2月25日閲覧。 ^ “RIPE NCC IPv6 Address Allocation and Assignment Policy: Minimum allocation”. 2016年2月25日閲覧。 ^ a b c RFC 6177, IPv6 Address Assignment to End Sites, T. Narten, G. Houston, L. Roberts, IETF Trust,(March 2011). ^ for example. Iana.org. Retrieved on 2011-09-28. ^ “IPv6 Addressing Plans”. ARIN IPv6 Wiki. 2010年8月18日閲覧。 “All customers get one /48 unless they can show that they need more than 65k subnets. [...] If you have lots of consumer customers you may want to assign /56s to private residence sites.” ^ RFC 2526,Reserved IPv6 Subnet Anycast Addresses, D. Johnson, S.Deering (March 1999) ^ RFC 5156, Special-Use IPv6 Addresses, M. Blanchett (April 2008) ^ RFC 1918, Address Allocation for Private Internets, Y. Rekhter, B. Moskowitz, D. Karrenberg, G.J. De Groot, E. Lear (February 1996) ^ RFC 6052, "IPv6 Addressing of IPv4/IPv6 Translators", C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li, (October 2010) ^ RFC 4773, Administration of the IANA Special Purpose IPv6 Address Block, G. Huston (December 2006) ^ RFC 2928, Initial IPv6 Sub-TLA ID Assignments, R. Hinden, S.Deering, R. Fink, T. Hain (September 2000) The Internet Society ^ RFC 5180, IPv6 Benchmarking Methodology for Network Interconnect Devices, C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin (May 2008) ^ RFC 5180 Errata, RFC Editor, M. Cotton, R. Bonica, (April 2009) ^ RFC 7343 – An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) ^ RFC 3849, IPv6 Address Prefix Reserved for Documentation, G. Huston, A. Lord, P. Smith (July 2004) ^ RFC 9637, Expanding the IPv6 Documentation Space, G. Huston, N. Buraglio (August 2024) ^ RFC 5737, IPv4 Address Blocks Reserved for Documentation, J. Arkko, M. Cotton, L. Vegoda (January 2010), ISSN 2070-1721 ^ RFC 6666, A Discard Prefix for IPv6, N. Hilliard, D. Freedman (August 2012) ^ IANA Internet Protocol Version 6 Multicast Addresses. ^ RFC 4862, IPv6 Stateless Address Autoconfiguration, S. Thomson, T. Narten, T. Jinmei (September 2007) ^ RFC 4861, Neighbor Discovery for IP version 6 (IPv6), T. Narten, E. Nordmark, W. Simpson, H. Holiman (September 2007) ^ Iljitsch van Beijnum (2006年). “IPv6 Internals”. The Internet Protocol Journal 9 (3): pp. 16–29. http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-3/ipv6_internals.html  ^ The privacy implications of stateless IPv6 addressing. Portal.acm.org (2010-04-21). Retrieved on 2011-09-28. ^ RFC 4941, Privacy Extensions for Stateless Address Autoconfiguration in IPv6, T. Narten, R. Draves, S. Krishnan (September 2007) ^ a b RFC 6724, Default Address Selection for Internet Protocol Version 6 (IPv6), D. Thaler, Ed., R. Draves, A. Matsumoto, T. Chown, The Internet Society (September 2012) ^ Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers. Tools.ietf.org. Retrieved on 2013-07-09. ^ RFC 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses, Y. Morishita, T. Jinmei. May 2005. ^ a b RFC 1884, IP Version 6 Addressing Architecture, R. Hinden, S.Deering (1995-12) ^ RFC 3879, Deprecating Site Local Addresses, C. Huitema, B. Carpenter (2004-09) ^ RFC 4193, Unique Local IPv6 Unicast Addresses, R. Hinden, B. Haberman (2005-10) ^ RFC 4147, Proposed Changes to the Format of the IANA IPv6 Registry, G. Houston (2005-08) ^ RFC 1888, OSI NSAPs and IPv6, J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd (1996-08) ^ RFC 4048, RFC 1888 Is Obsolete, B. Carpenter (2005-04) ^ a b RFC 2471, IPv6 Testing Address Allocation, R. Hinden, R. Fink, J. Postel (1998-12) ^ RFC 3701, 6bone (IPv6 Testing Address Allocation) Phaseout, R. Fink, R. Hinden (2004-03) ^ RFC 3152, Delegation of IP6.ARPA, R. Bush (2001-08) ^ RFC 3177, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", IAB, IESG, (September 2001). Beijnum, van, Iljitsch (2005). Running IPv6. ISBN 1-59059-527-0  IPアドレス枯渇問題 IPv6 IPアドレス IP Version 6 multicast addresses