「IPv6アドレス」の版間の差分

IPアドレスは、[[ホスト (ネットワーク)|ホスト]]の個々のネットワークインターフェースを特定し、ホスト間でIP[[パケット]]の[[ルーティング]]を行うために使用される。IPアドレスはパケットのヘッダに記載され、そのパケットの送信元と送信先を示している。

IPv6アドレスは、以下の3種類に分類される<ref name="rfc4291">RFC{{IETF RFC|4291}}, ''IP Version 6 Addressing Architecture'', R. Hinden, S. Deering （2006年2月）</ref>。

*[[ユニキャスト]]アドレス - 単一のインターフェースのための識別子。インターネットプロトコルは、ユニキャストアドレスに送られたパケットを、そのアドレスによって識別されるインターフェースに配送する。

*[[エニーキャスト]]アドレス - インターフェース集合（通常は異なるノードに属する）のための識別子。エニーキャストアドレスに送られたパケットは、そのアドレスで識別されるインターフェースの内で、ルーティングプロトコルの距離の定義に従って「最も近く」(nearest)にあるただ1つのインターフェースに配送される。エニーキャストアドレスはユニキャストアドレスと同じフォーマットのため、表記上は区別がつかない。ただ、同じアドレスが複数のインターフェースに設定されるかどうかの違いしかない。

*[[マルチキャスト]]アドレス - エニーキャストと同様にインターフェース集合のための識別子であるが、マルチキャストアドレスに送られたパケットは、そのアドレスを持つすべてのインターフェースに配送される。

IPv6には[[ブロードキャスト]]アドレス]]は存在せず、その機能はマルチキャストアドレスが果たす。

[[ユニキャスト]]アドレスと[[エニーキャスト]]アドレスは、通常2つの部分に分けられる。前半の64ビット（サブネットプリフィックス）は[[ルーティング]]に使用され、後半の64ビット（インターフェース識別子）はサブネット内での個別のインターフェースを指し示す。

|style="text-align: center;"| ''インターフェース識別子''

ネットワークプリフィックス（「ルーティングプリフィックス」と「サブネットID」）は、アドレスの中の上位64ビットである。ルーティングプリフィックスのサイズは可変である。プリフィックスのサイズが大きくなると、その分だけサブネットIDのサイズが小さくなる。サブネットIDのビットのフィールドは、ネットワーク管理者が与えられたネットワーク内でサブネットを定義するのに使用することができる。64ビットの「インターフェース識別子」は、インターフェースの[[MACアドレス]]から[[#Modified EUI-64|modified EUI-64]]{{Refnest|group="注釈"|name=EUI64|Modified EUI-64の使用はセキュリティの観点からは非推奨とされるが、RFCで公式に非推奨(deprecated)とはなっていない。モバイル・IoT機器では依然として多数採用されている<ref>[https://www.nic.ad.jp/ja/materials/iw/2016/proceedings/t02/t2-kitaguchi-2.pdf ''www.nic.ad.jp'']</ref>。}}）を使用して自動的に決定されるか、[[DHCPv6]]サーバから取得するか、ランダムに決定されるか、手動で設定するかのいずれかで決められる。

[[リンクローカルアドレス]]もまたインターフェース識別子に基づいているが、ネットワークプリフィックスとは異なるフォーマットになっている。

|style="text-align: center;"| ''インターフェース識別子''

{{details|[[:en:Multicast address#IPv6]]}}

|R (Rendezvous)<ref name="rfc3956">RFC{{IETF RFC|3956}}, ''Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address'' P. Savola, B. Haberman (November 2004)</ref>

|P (Prefix)<ref name="rfc3306">RFC{{IETF RFC|3306}}, ''Unicast-Prefix-based IPv6 Multicast Addresses'', B. Haberman, D. Thaler (August 2002)</ref>

リンク範囲(link-scoped)マルチキャストアドレスは、互換性のあるフォーマットを使用する<ref name="rfc4489">RFC{{IETF RFC|4489}}, ''A Method for Generating Link-Scoped IPv6 Multicast Addresses'', J-S. Park, M-K. Shin; H-J. Kim (April 2006)</ref>。

IETFは、この問題を軽減するために、IPv6アドレスをテキストで表現する際の規範的なフォーマットの規定を RFC{{IETF RFC|5952}} として提案した。この規定は以下の通りである。

インターフェースアドレスのルーティングプリフィックスは、直接にアドレスとCIDR記法で表すことができる。例えば、2001:db8:a::/64 のサブネットに接続されているアドレス 2001:db8:a::123 のインターフェースの設定は、 2001:db8:a::123/64 のように書くことができる。

IPv6アドレスの[[コロン (記号)|コロン]](:)は、[[Uniform Resource Identifier|URI]]や[[Uniform Resource Locator|URL]]のような資源識別子の確立した文法と競合する。コロンは伝統的にホストパスと[[ポート番号]]の区切りに使用されてきた<ref name="rfc3986">RFC{{IETF RFC|3986}}, ''Uniform Resource Identifier (URI): Generic Syntax'', [[ティム・バーナーズ＝リー|T. Berners-Lee]], {{仮リンク|ロイ・フィールディング|en|Roy Fielding|label=R. Fielding}}, L. Masinter (January 2005)</ref>。この競合を軽減するため、資源識別子の中ではIPv6アドレス を[[角括弧]]（[]）で囲む。例えば、以下のようにする。

:<nowiki>httphttps://[2001:db8:85a3:8d3:1319:8a2e:370:7348]/</nowiki>

[[Microsoft Windows]][[オペレーティングシステム]] (OS) では、IPv4アドレスは{{仮リンク|[[Uniform Naming Convention|en|Uniform]] Naming Convention}}(UNC) のパス名に含めることができる。しかし、UNCパス名ではコロンは文法的に意味を持っているため、IPv6アドレスはそのままではUNCパス名に使用できない。このため、[[マイクロソフト]]はUNCパスに使用できるドメイン名にIPv6アドレスを含められるような変換アルゴリズムを実装している。このために、マイクロソフトは[[セカンドレベルドメイン]]''ipv6-literal.net''をインターネット上で登録し、保持している<ref>{{cite web|title=ipv6-literal.net Domain History|url=http://www.who.is/domain-history/ipv6-literal.net|publisher=who.is|accessdate=2016-02-24}}</ref>。IPv6アドレスは、以下のように、この名前空間のホスト名やサブドメイン名に変換される。

未指定アドレス(::)以外の全てのIPv6アドレスは「スコープ」(scope)を持っている<ref name="rfc4007">RFC{{IETF RFC|4007}}, ''IPv6 Scoped Address Architecture'', [[スティーブ・ディアリング|S.Deering]], B. Haberman, T. Jinmei, E. Nordmark, B. Zill (March 2005)</ref>。スコープは、そのアドレスが有効である範囲を特定するのに使用する。

[[ユニークローカルアドレス]]は世界的にルーティング可能ではなく、そのアドレスはそれが使われているネットワークの範囲内でのみ有効である。ユニークローカルアドレスは、[[ルーティング・テーブル]]が特にそれを許可するように構成されたルータや[[トンネリング|トンネル]]によってのにルーティングされる。

| <tt>0x1</tt> || interface-local || interface-localスコープは、ノードの1つのインターフェースのみで有効である。これは、マルチキャストのループバック転送にのみ使用される。

IPv6アドレスの割り当てプロセスの管理は、[[インターネットアーキテクチャ委員会]]と[[Internet Engineering Steering Group]]から[[Internet Assigned Numbers Authority]] (IANA)に委任されている<ref name="rfc1881">RFC{{IETF RFC|1881}}, ''IPv6 Address Allocation Management'', [[インターネットアーキテクチャ委員会|Internet Architecture Board]] (December 1995)</ref>。主な機能は、大きなアドレスブロックを[[地域インターネットレジストリ]](RIR)に割り当てることである。RIRは、世界の地域ごとに、ネットワーク・サービス・プロバイダや他のローカルインターネットレジストリへのアドレスの割り当てを委任されている。IANAは、IPv6アドレス空間の公式の割り当てリストの管理を1995年12月から行っている<ref>[http://www.iana.org/assignments/ipv6-address-space IPv6 address space at IANA]. Iana.org (2010-10-29). Retrieved on 2011-09-28.</ref>。

効果的な[[経路集約]](route aggregation)を提供し、それによってインターネット・ルーティング・テーブルのサイズを減らすために、全体のアドレス空間の8分の1(2000::/3)だけが[[インターネット]]で使用するために割り当てられている。IPv6アドレス空間の残りは、将来の利用と特別な目的のために予約されている。アドレス空間は/23から/12という大きなブロック単位でRIRに割り当てられている<ref>httphttps://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml IPv6 Global Unicast Address Assignments], IANA</ref>。

RIRは[[ローカルインターネットレジストリ]](LIR)に小さなブロックを割り当てる。そのサイズは一般的に/19から/32の範囲である<ref>[http://www.db.ripe.net/whois?form_type=simple&full_query_string=&searchtext=DE-TELEKOM-20050113&do_search=Search DE-TELEKOM-20050113]. Db.ripe.net. Retrieved on 2011-09-28.</ref><ref>{{cite web |url=https://www.arin.net/policy/nrpm.html#four22 |title=ARIN Number Resource Policy Manual: Initial allocation to ISPs|accessdate=2016-02-25}}</ref><ref>{{cite web |url=http://www.ripe.net/ripe/docs/ripe-481#minimum_allocation |title=RIPE NCC IPv6 Address Allocation and Assignment Policy: Minimum allocation|accessdate=2016-02-25}}</ref>。アドレスは一般的に/48から/56の単位でエンドユーザに分配される<ref name="rfc6177">RFC{{IETF RFC|6177}}, ''IPv6 Address Assignment to End Sites'', T. Narten, G. Houston, L. Roberts, [[IETF]] Trust,(March 2011).</ref>。

グローバルユニキャストの割り当ての記録は、それぞれのRIRのサイトなどで閲覧できる<ref>[httphttps://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml for example]. Iana.org. Retrieved on 2011-09-28.</ref>。

それぞれのRIRは1つの/23ブロックを512個の/32のブロックに分割することができ、一般的には1つのISPに対して1つの/32ブロックを割り当てる。ISPは割り当てられた/32ブロックを{{gaps|65|536}}個の/48ブロックに分割することができ、一般的には1人の顧客に対して1つの/48ブロックを割り当てる<ref>{{cite web | title = IPv6 Addressing Plans | publisher = ARIN IPv6 Wiki | url = http://www.getipv6.info/index.php?title=IPv6_Addressing_Plans&oldid=2998 | quote = 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. | accessdate = 2010-08-18 }}

それぞれのサブネットプリフィックスの最も低いアドレス（インターフェース識別子を全て0に設定したもの）は、「サブネット・ルータ・エニーキャストアドレス」として予約されている<ref name="rfc4291" />。アプリケーションはこのアドレスを利用可能な1つのルータとの通信に利用できる。このアドレス宛にのパケットはただ1つだけのルータに届く。

/64のサブネットプリフィックスの最上位の128個のアドレスは、エニーキャストアドレスとして予約されている<ref name="rfc2526">RFC{{IETF RFC|2526}},''Reserved IPv6 Subnet Anycast Addresses'', D. Johnson, [[スティーブ・ディアリング|S.Deering]] (March 1999)</ref>。これらのアドレスは、インターフェース識別子の最初の57ビットが1で、残りの7ビットがエニーキャストIDである。この場合、そのアドレスが世界的に唯一ではないことを示すために、[[#Modified EUI-64|universal/localビット]]は0にしなければならない。エニキャスト識別子0x7eは[[mobile IP|mobile IPv6]]ホームエージェント・エニーキャストアドレスとして定義されている。エニキャスト識別子0x00から0x7dまでと0x7fは予約されており、何にも使用されていない。

{{see also|:en:Reserved IP addresses#IPv6}}

IPv6において特別な意味を持つアドレスがある<ref name="rfc5156">RFC{{IETF RFC|5156}}, ''Special-Use IPv6 Addresses'', M. Blanchett (April 2008)</ref>。それを以下に挙げる。

* ::/128 — 全ビットが0のアドレスは未指定アドレス(unspecified address)と呼ばれる。IPv4における「0.0.0.0/32」に相当する。<br/>このアドレスは、いかなるインターフェースにも割り当ててはならない。このアドレスは、初期化中のホストの自分自身のIPアドレスを知る前にIPv6パケットを送る場合の送信元アドレスとして使用される。ルータは未指定アドレスを持つパケットを転送してはならない。

* ::1/128 — [[ループバック]]アドレスはユニキャスト[[localhost]]アドレスである。ホストのアプリケーションがこのアドレス宛にパケットを送信したときは、IPv6スタックはそのパケットを同じ仮想インターフェースにループバックする。IPv4における「[[localhost|127.0.0.1/8]]」に相当する。

* fe80::/10 — リンクローカルプリフィックスのアドレスは、単一の接続の中でのみ有効であり唯一である。このプリフィックスにおいては1つのサブネットのみが割り当てられ（残り54ビットは0）、効果的なフォーマットは fe80::/64 と与えられる。下位64ビットはインターフェースのハードウェアアドレスから[[#Modified EUI-64|modified EUI-64]]によって決められるのが一般的である。[[リンクローカルアドレス]]は、あらゆるIPv6対応インターフェースで必要とされる。IPv6ルーティングがないときは、アプリケーションはリンクローカルアドレスの存在に頼るかもしれない。これらのアドレスは、IPv4における自動設定アドレス 169.254.0.0/16 に相当する。

* fc00::/7 — [[ユニークローカルアドレス]] (ULA) はローカルな通信のために使われる。それらは、設定されたサイトの中でだけルーティングできる<ref name="rfc1918">RFC{{IETF RFC|1918}}, ''Address Allocation for Private Internets'', Y. Rekhter, B. Moskowitz, D. Karrenberg, G.J. De Groot, E. Lear (February 1996)</ref>。このブロックは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)に相当する。

* 64:ff9b::/96 — "Well-Known Prefix"。このプリフィックスのアドレスは、自動IPv4/IPv6トランスレーション(NAT64)に使用する<ref name="rfc6052">RFC{{IETF RFC|6052}}, "IPv6 Addressing of IPv4/IPv6 Translators", C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li, (October 2010)</ref>。

* 2002::/16 — このプリフィックスは、[[6to4]]のために使用される。（6to4はHistoricalとなった {{IETF RFC|7526}})

{{Main|:en:Teredo tunnelingトンネリング}}

:IANAは'Sub-TLA ID'と呼ばれるアドレスブロックを特別な用途のために予約している<ref name="rfc4773">RFC{{IETF RFC|4773}}, ''Administration of the IANA Special Purpose IPv6 Address Block'', G. Huston (December 2006)</ref><ref name="rfc2928">RFC{{IETF RFC|2928}}, ''Initial IPv6 Sub-TLA ID Assignments'', R. Hinden, [[スティーブ・ディアリング|S.Deering]], R. Fink, T. Hain (September 2000) The [[インターネット協会ソサエティ|Internet Society]]</ref>。それは、 2001:0000::/29 から 2001:01f8::/29 までの範囲の64のネットワークプリフィックスである。その内の3つは以下のものである。

* 2001:2::/48 — Benchmarking Methodology Working Group (BMWG)に割り当てられており<ref name="rfc5180">RFC{{IETF RFC|5180}}, ''IPv6 Benchmarking Methodology for Network Interconnect Devices'', C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin (May 2008)</ref>、IPv6の[[ベンチマーク]]に使用されている。IPv4でベンチマークに使用されている 198.18.0.0/15 に相当する。プリフィックス 2001:0200::/48 は RFC{{IETF RFC|4773}} ではなく RFC{{IETF RFC|5180}} で定義されている<ref name="rfc5180-errata">RFC{{IETF RFC|5180}} Errata, ''RFC Editor'', M. Cotton, R. Bonica, (April 2009)</ref>。

* 2001:20::/28 — ORCHIDv2 (Overlay Routable Cryptographic Hash Identifiers)<ref name="rfc7343">RFC{{IETF RFC|7343}} – ''An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)''</ref>に割り当てられている。これらはCryptographic Hash Identifiersに使うルーティングされないIPv6アドレスである。

* 2001:db8::/32 — このプリフィックスは、文書記述用に使用される<ref name="rfc3849">RFC{{IETF RFC|3849}}, ''IPv6 Address Prefix Reserved for Documentation'', G. Huston, A. Lord, P. Smith (July 2004)</ref>。このアドレスは、マニュアルや設定サンプル等に例示としてIPv6アドレスを使用する場合に使用される。このアドレスは実際の通信には使用してはならない。IPv4では 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 がこの目的で使用されていた<ref name="rfc5737">RFC{{IETF RFC|5737}}, ''IPv4 Address Blocks Reserved for Documentation'', J. Arkko, M. Cotton, L. Vegoda (January 2010), {{ISSN|2070-1721}}</ref>。

* 0100::/64 — このプリフィックスは、破棄するトラフィックに使用される<ref name="rfc6666">RFC{{IETF RFC|6666}}, ''A Discard Prefix for IPv6'', N. Hilliard, D. Freedman (August 2012)</ref>。

{{further2|[[#非推奨とされ廃止されたアドレス_2|非推奨とされ廃止されたアドレス]]}}

| 1 (インターフェースローカル), 2 (リンクローカル):

* <tt>ff01::1</tt> → All nodes in the インターフェースローカル

| 1 (インターフェースローカル), 2 (リンクローカル), 5 (サイトローカル):

* <tt>ff01::2</tt> → インターフェースローカルの全てのルータ

{{仮リンク|要請ノードマルチキャストアドレス|en|Solicited-node multicast address}}のグループIDの下位24ビットは、インターフェースのユニキャストアドレスまたはエニーキャストアドレスの下位24ビットである。このアドレスは、ローカル・ネットワーク上の全てのノードを妨げずに、[[近隣探索プロトコル]](NDP)による[[リンク層]]アドレス解決をすることができる。ホストは、設定されたユニキャストアドレスまたはエニーキャストアドレスの要請ノードマルチキャストグループに参加しなければならない。

システムの起動時、ノードは、それぞれのIPv6が利用可能なインターフェースについて[[リンクローカルアドレス]]を自動的に生成する。グローバルにルーティングできるアドレスが、手動で設定されるか、後述する「設定プロトコル」から得られる場合でも同様である。

それは、[[近隣探索プロトコル]]の機能を使用したステートレスアドレス自動設定(SLAAC)<ref name="rfc4862">RFC{{IETF RFC|4862}}, ''IPv6 Stateless Address Autoconfiguration'', S. Thomson, T. Narten, T. Jinmei (September 2007)</ref>によって、独立して、そして、事前設定なしで動作する。このアドレスはプリフィックス fe80::/64 の中から選択される。

IPv4に「設定プロトコル」はDHCPやPPPを含む。[[DHCPv6]]もあるが、IPv6のホストはグローバルにルーティング可能なユニキャストアドレスを作るのに[[近隣探索プロトコル]]を用いる。ホストはルータ要請(RS: router solicitation)を送信し、IPv6[[ルーター]]は割り当てられたプリフィックスとともに応答を返す<ref name="rfc4861">RFC{{IETF RFC|4861}}, ''Neighbor Discovery for IP version 6 (IPv6)'', T. Narten, E. Nordmark, W. Simpson, H. Holiman (September 2007)</ref>。

アドレスの下位64ビットは、64ビットの[[#Modified EUI-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:<u>FF:FE</u>:0C:47:D5 に変換される。このEUI-64をIPv6アドレスの中で使うとき、次のように変形される<ref name="rfc4291"/>。 ''Universal/Local''ビット（EUI-64の最上位ビットを第1ビットとしたときの第7ビット）を反転する。ネットワークプリフィックス 2001:db8:1:2::/64 と上記のMACアドレスを用いてIPv6アドレスを生成すると、 2001:db8:1:2:0<u>2</u>0c:29ff:fe0c:47d5 となる。ここで、下線部は''Universal/Local''ビットが1に反転された箇所である。1は''Universal''、0は''Local''を意味する。

インターフェースに[[ユニキャスト]]IPv6アドレスを割り当てた後、''Neighbor Solicitation''（近隣要請）と''Neighbor Advertisement''（近隣広告）（[[ICMPv6]]のtype 135と136）メッセージを使ってそのアドレスが唯一のものであるかの確認を行う。確認を行っている間、そのアドレスは「仮」(''tentative'')の状態にある。

ノードが自身の仮アドレスを宛先とする''Neighbor Solicitation''を受信した場合、そのアドレスはユニークではない。ノードが、仮アドレスを送信元とする''Neighbor Advertisement''を受信した場合も同様である。アドレスがユニークであると確認できた時だけ、そのアドレスが割り当てられ、インターフェースによって使用される。

インターフェースに割り当てられたIPv6アドレスは固定された有効期限(lifetime)を持つ。より短い期間に設定されない限り、有効期限は無制限である。アドレスには、''preferred lifetime''と''valid lifetime''の2つの有効期限がある<ref>

{{Cite news| journal=The Internet Protocol Journal| year=2006| volume=9| issue=3| pages=16–29| title=IPv6 Internals| author=Iljitsch van Beijnum |url=http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-3/ipv6_internals.html}}</ref>。有効期限は、ルーターで設定されて自動設定によって値が提供されるか、インターフェースに手動で設定する。

アドレスがインターフェースに割り当てられたとき、そのアドレスは"preferred"の状態にあり、preferred-lifetimeの間それが継続する。preferred-lifetimeが経過すると"deprecated"の状態になり、そのアドレスを使って新しい接続はできなくなる。valid-lifetimeが経過すると"invalid"の状態になり、そのアドレスはインターフェースから除かれ、インターネットから新しいアドレスの割り当てを受ける。

ステートレスアドレス自動設定でインターフェース識別子を生成するのに、グローバルにユニークな固定のMACアドレスを使用している。そのため、時間がたってIPv6ネットワークプリフィックスが変わったとしても、MACアドレスによってネットワーク機器を、そしてユーザを追跡することができる<ref>[http://portal.acm.org/citation.cfm?id=1852723&dl=GUIDE&coll=GUIDE&CFID=103687796&CFTOKEN=17254293 The privacy implications of stateless IPv6 addressing]. Portal.acm.org (2010-04-21). Retrieved on 2011-09-28.</ref>。IPv6アドレスの一部とユーザが永久に結びつく危険性を減らすため、ノードは「一時アドレス」(temporary address)を作ることができる。一時アドレスは、時間によりランダムに変化するビット列に基づいたインターフェース識別子<ref name="rfc4941">RFC{{IETF RFC|4941}}, ''Privacy Extensions for Stateless Address Autoconfiguration in IPv6'', T. Narten, R. Draves, S. Krishnan (September 2007)</ref>を使用し、有効期限を比較的短く（数時間から数日）することで短い時間で新しいアドレスに置き替えられる。

[[Mac OS X Lion]]以降の[[macOS]]、[[Microsoft Windows Vista|Windows Vista]]・[[Microsoft Windows 2008 Server 2008|Windows 2008 Server 2008]]以降の[[マイクロソフト]]のOSでは、IPv6のネットワークインターフェースの設定で、デフォルトで一時アドレスを使用する設定になっている。

優先選択アルゴリズム<ref name="rfc6724">RFC{{IETF 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)</ref>は、特定の宛先（[[デュアルスタック]]実装におけるIPv4射影IPv6アドレスを含む）の中で通信において最も適切なアドレスを選択するアルゴリズムであり、各々のルーティングプリフィックスを優先順位レベルと結びつけるカスタマイズ可能な選択テーブルに基づいている。デフォルトのテーブルは以下の通りである<ref name="rfc6724"/>。

| | 6to4 (Historical {{IETF RFC|7526}})

ホストの全てのリンクローカルアドレスは共通のプリフィックスを持つので、リンクローカルの宛先にパケットを送信するとき、出て行くインターフェースを選ぶのに通常のルーティング手順を用いることができない。そこで、ゾーンインデックス(''zone index'')と呼ばれる特別な識別子<ref name="rfc4007"/>を用いて付加的なルーティングの情報を提供する。

* [[Microsoft Windows]]は、数値のゾーンインデックスを使用する（例 fe80::3%1）。インデックスは、インターフェース番号で決定される。

* 多くの[[Unix系]]OS（[[Berkeley Software Distribution|BSD]], [[Linux]], [[macOS]]など）は、インターフェース名をゾーンインデックスに使用する（例 fe80::3%eth0）。

ゾーンインデックスの表記は、[[Uniform Resource Identifier]](URI)の中で使用する時に文法的に競合するため、パーセント記号"%"を[[パーセントエンコーディング]]によって回避しなければならない<ref>[httphttps://toolsdatatracker.ietf.org/doc/html/rfc6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers]. Tools.ietf.org. Retrieved on 2013-07-09.</ref>。例 http://[fe80::3'''%25'''eth0]

[[Domain Name System]](DNS)では、''AAAA''リソースレコード（クアッドAレコード）によって[[ホスト名]]をIPv6アドレスに対応づけしている。[[逆引き#逆引き (DNS)|DNS逆引き]]のために、IETFはドメイン名[[.arpa|ip6.arpa]]を維持しており、その名前空間は、後述するようにIPv6アドレスを4ビット（[[ニブル]]）単位で1桁ずつの[[十六進数]]に分けた物になっている。この仕組みは RFC{{IETF RFC|3596}} で定義されている。

2009年現在、多くの家庭内ネットワークのNAT装置やルータのDNSリゾルバは、未だにAAAAレコードを不適切に取り扱う<ref>RFC{{IETF RFC|4074}} ''Common Misbehavior Against DNS Queries for IPv6 Addresses'', Y. Morishita, T. Jinmei. May 2005.</ref>。これらのいくつかは、適切な否定のDNS応答をきちんと返さずに、単にそのようなレコードのDNS要求を破棄する。要求が破棄されるので、要求を送信しているホストはタイムアウトを待たなければならない。クライアント・ソフトウェアがIPv6接続が失敗するのを待ってからIPv4接続を行うため、デュアルスタックIPv6/IPv4ホストに接続しようとするときに、しばしば減速を引き起こす。

* サイトローカルプリフィックス fec0::/10 は、組織内のサイトネットワーク内でのみ有効であると特定されたアドレスである。これは、1995年12月に定められた最初のアドレス体系の一部であった<ref name="rfc1884">RFC{{IETF RFC|1884}}, ''IP Version 6 Addressing Architecture'', R. Hinden, [[スティーブ・ディアリング|S.Deering]] ({{date|dec 1995}})</ref>が、2004年9月に廃止された<ref name="rfc3879">RFC{{IETF RFC|3879}}, ''Deprecating Site Local Addresses'', C. Huitema, B. Carpenter ({{date|sep 2004}})</ref>。これは、「サイト」という用語の定義が曖昧だったことにより、ルーティングのルールに混乱を生じていたためである。新しいネットワークはサイトローカルアドレスに対応してはならない。2005年10月、新しい仕様<ref name="rfc4193">RFC{{IETF RFC|4193}}, ''Unique Local IPv6 Unicast Addresses'', R. Hinden, B. Haberman ({{date|oct 2005}})</ref>により、サイトローカルアドレスは[[ユニークローカルアドレス]]に置き替えられた。

* アドレスブロック 0200::/7 は、1996年8月にOSI NSAP-mapped プリフィックスとして定義された<ref name="rfc4147">RFC{{IETF RFC|4147}}, ''Proposed Changes to the Format of the IANA IPv6 Registry'', G. Houston ({{date|aug 2005}})</ref><ref name="rfc1888">RFC{{IETF RFC|1888}}, ''OSI NSAPs and IPv6'', J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd ({{date|aug 1996}})</ref>が、2004年12月に廃止された<ref name="rfc4048">RFC{{IETF RFC|4048}}, ''<nowiki>RFC 1888</nowiki> Is Obsolete'', B. Carpenter ({{date|apr 2005}})</ref>。

* アドレスブロック 3ffe::/16 は、1998年12月に{{仮リンク|6bone|en|6bone}}ネットワークの試験目的に割り当てられた<ref name="rfc2471">RFC{{IETF RFC|2471}}, ''IPv6 Testing Address Allocation'', R. Hinden, R. Fink, [[ジョン・ポステル|J. Postel]] ({{date|dec 1998}})</ref>。それ以前には、アドレスブロック 5F00::/8 がこの目的のために使用されていた。両方のアドレスブロックは2006年6月にアドレスプールに返還された<ref name="rfc3701">RFC{{IETF RFC|3701}}, ''6bone (IPv6 Testing Address Allocation) Phaseout'', R. Fink, R. Hinden ({{date|mar 2004}})</ref>。

* IPv6アドレスの[[Domain Name System]](DNS)の[[逆引き#逆引き (DNS)|逆引き]]用のレコードは、[[.int|int]]トップレベルドメインの下のip6ゾーンに登録されていた。2000年、[[インターネットアーキテクチャ委員会]](IAB)は[[.arpa|arpa]]トップレベルドメインを廃止する意向を示したが、2001年にarpaトップレベルドメインがその本来の機能を維持しなければならないと決めた。ip6.intドメインはip6.arpaに移された<ref name="rfc3152">RFC{{IETF RFC|3152}}, ''Delegation of IP6.ARPA'', R. Bush ({{date|aug 2001}})</ref>。ip6.intゾーンは正式に2006年6月6日に除去された。

* 2011年3月、[[IETF]]は、エンドサイトへのアドレスブロックの配分の推奨を変更した<ref name="rfc6177" />。/48, /64, /128を割り当てる（これは2001年の[[インターネットアーキテクチャ委員会|IAB]]と[[IESG]]の見解に従ったものである）<ref name="rfc3177">RFC{{IETF RFC|3177}}, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", [[インターネットアーキテクチャ委員会|IAB]], [[IESG]], (September 2001).</ref>代わりに、インターネット・サービス・プロバイダは、より小さなブロック（例えば/56）をエンドユーザに割り当てることを考えなければならない。地域レジストリ[[ARIN]], [[RIPE]], [[APNIC]]の方針は、必要に応じて/56の割り当てを促す<ref name="rfc6177"/>。

== 脚注 ==

==外部リンク 参考文献 ==