IPv4には、プライベートIPアドレスとして割り当てられたアドレスブロックがあります。
1996年に発行されたRFC 1918で規定されている10.0.0.0/8、172.16.0.0/12、192.168.0.0/16の3つです。
NAT(NAPT)とともにプライベートIPアドレスは、多くの環境で利用されています。
企業LANなどでIPv4ネットワークを構築するときに、プライベートIPアドレスを一切使わずにグローバル(パブリック)IPアドレスのみで組むようことは、いまでは少ないのではないかと推測しています。
世界中で多く利用されているIPv4のプライベートIPアドレスですが、2024年現在時点において、IPv4のプライベートIPアドレスと全く同じ用途のIPv6アドレスは存在しません。
IPv6には、ULA(Unique Local Address)というアドレスがあります。
「ULAってプライベートIPアドレスのIPv6版でしょ？」という感想の人に、割と良く出会います。
ULAは、IPv4のプラベートIPアドレスであると考えられがちですが、現時点においてIETFで推奨される用途は、プライベートIPアドレスと異なります。
ULAをプライベートIPアドレスのようにNATと組み合わせて使うことは、IETFでの文書では推奨されていません。
ここで、「現時点において」と「IETFで推奨される用途」という表現を文章に含んでいる点が個人的なポイントです。
そこら辺の話は、この記事の後半に向かうにつれて紹介していきます。
IPv4のプライベートIPアドレスと全く同じものではないし、公式な用途とされている利用方法としてはNATを使うものではない、というIPv6アドレスがULAです。
その一方で、IPv4のプライベートIPアドレスと全く同じように使いたいと主張する人もいるし、実際に既に使っている人もいる、という実情もあります。
「結局、ULAはプライベートIPアドレスと同じものでしょ？」という感想を持っている方々も多そうです。
この記事では、そんな微妙な位置付けのULAについて紹介します。
なお、この記事は私の独断と偏見による個人的視点での現状観測および現状認識です。
あくまで現状を構成している要素を紹介するという考え方で書いており、IPv6がどうあるべきかを論じるものではないのでご注意ください。
この記事では、「IPv6にもプライベートIPアドレスが必要だ」とか、「IPv6でNATは避けるべきだ」とか、「IPv6でもNATを使うべきだ」とか、「ULAの用途はこうあるべきだ」とか、「ULAは事実上のプライベートIPアドレスである」とか主張するつもりはありません。
今後、世の中でどのように使われ、何がdefactoになるのかを見守っていきたいと考えています。
念のため。
以下、この記事の目次です。
私の個人的な印象としては、家庭内ネットワークや企業LAN等でのULA利用は多くなさそうですが、仮想化やクラウドといった場面でULAの利用が広がっているように思えます。
たとえば、kubernetesのkubeadmやNodeLocal DNSCacheのドキュメントにULAが登場しています。
このことからも、kubernetesでIPv6を利用する際にULAを使うことがあることがわかります。
kubernetesに関連する設定方法や事例を紹介しているブログ等でもULAを使っていることが読み取れるものがあります。
Google CloudでULAを使うことを紹介している公式ブログ記事がありますし、AWSの公式ドキュメントにもULAが記述されています。
これらの他に、たとえば、仮想化ソフトがVMに対して提供する仮想ネットワークでULAが初期設定になっている場合もあります。
仮想化やクラウドをIPv4とIPv6のデュアルスタックで扱うような場合には、IPv6のULAを目にする機会は徐々に増えているのではないでしょうか？
次は、ULAの紹介です。
ULAは、RFC 4193で定義されています。
ULAはグローバルスコープのIPアドレスです。
ULAのユニキャストIPv6アドレスの128ビットのうち、先頭7ビットがプレフィックスで、fc00::/7です。
8ビット目は、ローカルであるかどうかを示すLビットで、1の場合がローカル、0の場合は未定義となっています。
このようにRFCに記載されたプロトコルには「将来定義される」として未定義になっているフィールドが多くあるのですが、いつまでも定義されずにそのままになっていることも少なくありません。
2024年時点では、ULAとして利用されるIPv6アドレスは、事実上は、Lビットが1となるfd00::/8のみとなります。
ULAのフォーマット
ULAの非常に大きな特徴として、IPv6アドレスにおけるサブネットプレフィックスにランダムな値が含まれるという点があげられます。
この図で「グローバルID」となっている40ビットが、疑似的なランダム値となります。
このフィールドでは、既知の数値などを利用して一意性を確保することは禁止されています。
RFC 4086に基づくランダムな値を生成して利用することが求められています。
この部分がランダムであることから、ULAに関連する経路、DNSに関連する情報、あるいはパケットが外に漏れたとしても、他のアドレスとの競合が発生しにくいとRFC 4193に書かれています。
また、たとえば、複数のULAによるネットワーク同士を直接繋ぐようなときにも便利であるとされています。
たとえば、192.168.0.0/24という同じアドレス空間で運用されている異なる2つのネットワークが存在していたとします。
企業の合併等で、この2つの異なるネットワーク同士を直接イントラネット内で繋ぐような状況になったときに、そのままではアドレスがバッティングしてしまうので、何らかの対策が必要になります。
ULAであれば、全く同じアドレス空間を利用してしまう可能性が著しく低いため、同様の問題は起きにくいです。
ランダムな40ビットのグローバルIDの後ろには、16ビットのサブネットIDフィールドが続きます。
この16ビットを活用して、サブネットを構成できます。
IPv6アドレスの128ビットのうちの残りの64ビットがインターフェース識別子です。
ULAを使ったIPv6でのNATの話の前に、IPv4 NATを利用したインターネットとの通信という視点ではなく、
プライベートIPv4アドレスでのイントラネット内部での通信という視点があります。
プライベートIPv4アドレス空間でのLAN内に閉じた通信での利用という視点でみた時に、IPv6で類似することをどのようにするのかですが、IPv6ではULAを限定された範囲での通信として使えます。
では、ULAを使った環境で、イントラネット内部だけではなく、IPv6インターネットとの通信を行いたい場合はどうするのか、という話があります。
IPv6でULAを使いつつ、IPv6インターネットとの通信も行いたい場合には、どういう方法がIETFで推奨されているのかですが、IPv6イントラネットでのULAとグローバルアドレスによるマルチアドレスの活用がRFC 4193に書かれています。
ULAは、ローカルな通信だけで利用し、インターネットとの通信にはGUA(Global Unicast Address)を使え、というものです。
IPv6は、ひとつのネットワークインターフェースに複数のIPv6アドレスを設定する前提の設計になっているので、それを活用するというものです。
ULAとGUAの両方が設定され、必要に応じてそれらを使い分けるという方法です。
具体的には、こんな感じです。
LAN内にある機器で、内部のみとの通信を行う機器には、ULAのIPv6アドレスしか設定されていません。
この例では、プリンタがULAのみで運用されます。
内部にあるパソコンには、GUAとULAの両方のIPv6アドレスが設定されており、プリンタとの通信にはULAが利用され、IPv6インターネットとの通信にはGUAが使われます。
プリンタには、GUAが設定されていないので、外部から直接プリンタとの通信を行うことはできません。
内部同士での通信でULAを利用
外部との通信にはGUAを利用
さて、この環境では、GUAが設定されているので外部から直接パソコンへと攻撃が可能になってしまうじゃないか！という感想を持つ人もいると思います。
そこで登場するのがファイアウォールです。
ファイアウォールで、外部から内部への通信を制限するような設定を行うことで、そのまま直接外部から内部に対して通信を開始する難易度を上昇させることができます。
ここら辺の話は、後ほどもう少し詳しく紹介します。
さらに、IPv6とIPv4で違うのが、サブネットの大きさです。
IPv6のサブネット空間は広大なので、アドレススキャンを行う難易度がIPv4と比べて、非常に高くなります。
そこら辺の話は、以前書いた記事(IPv6アドレススキャン攻撃)をご覧ください。
IPv6のサイトローカルアドレスも、今回の話題に関連する要素です。
なぜULAのアドレスにランダムな値が入っているのかと、なぜグローバルスコープなのか？
IPv6アドレス体系におけるユニキャストのスコープがグローバルとリンクローカルの2種類のみになった理由などが、サイトローカルアドレス廃止の議論に詰まっています。
IPv6におけるプライベートIPアドレスに類するものとして、fec0::/10のサイトローカルアドレス(Site local IPv6 address)というものが、かつてありました。
サイトローカルアドレスは、2004年に発行されたRFC 3879によって廃止されました。
サイトローカルアドレスが抱える欠点を改善したものとして作られたのがULAです。
このような経緯から、ULAは、廃止されたサイトローカルアドレスとは違うものとして作られており、IPv6版のプライベートIPアドレスではないという位置付けと解釈可能です。
サイトローカルアドレスが廃止された理由として、RFC 3879では、RFC 1918で定義されているプライベートIPアドレスと同様の欠点があることや、「サイト」という概念で表される範囲が曖昧だったこと、スコープ識別子を扱う必要があったことなどがあげられています。
IPv6アドレスアーキテクチャを定義しているRFCの最新版は、2006年に発行されているRFC 4291ですが、その2.4章では、ユニキャストのIPv6アドレスの種類はリンクローカルユニキャストとグローバルユニキャストの2つだけとなっています。
RFC 4291が上書き廃止しているRFC 3513(2003年)では、ユニキャストのIPv6アドレスの種類は、サイトローカルユニキャストを含めた3種類だったものが、2種類に減っています。
| Address type | Binary prefix | IPv6 notation |
| Unspecified | 00...0 (128 bits) | ::/128 |
| Loopback | 00...1 (128 bits) | ::1/128 |
| Multicast | 11111111 | FF00::/8 |
| Link-Local unicast | 1111111010 | FE80::/10 |
| Global Unicast | (everything else) | |
RFC 4291では、Unspecified、ループバック、マルチキャスト、リンクローカルユニキャストの4種類を除く全てのIPv6アドレスをグローバルユニキャストと定義しています。
この表からも、fc00::/7は、グローバルユニキャストの一部であることがわかります。
さて、話をサイトローカルアドレスに戻しましょう。
IPv6アドレスには、IPv6アドレスのスコープとゾーンという概念があります(RFC 4007参照)。
スコープというのは、概念的な範囲を示す一方で、ゾーンは、より具体的な区分された区域を示しています。
IPv6アドレスのスコープは、その有効範囲において有効であるということは、同一スコープにおいて複数ゾーンで個別に同じIPv6アドレスが存在しても良いということです。
たとえば、世界中の複数の異なるセグメントで、fe80::1というリンクローカルアドレスが存在していても問題ありません。
リンクローカルスコープのIPv6アドレスであるリンクローカルアドレスは、個々のリンクが個別のゾーンを構成しており、別ゾーンで同じIPv6アドレスが存在しても問題がないのです。
この仕組みが、リンクローカルアドレスで、fe80::1%eth0、fe80::1%fxp0、fe80::1%1のように、IPv6アドレスとともに % を使う理由です。
他にも同じIPv6アドレスが使われる可能性があり、有効範囲を明示的に指定するために % を使っているわけです。
%とともに使われる識別子は、ゾーン識別子と定義されています。
ただ、少し厄介というか、初期実装からの歴史的経緯でややこしくなってしまった話があり、socket APIではscope_idという表現になってしまっています。
たとえば、Cでのstruct sockaddr_in6だと、sin6_scope_idです。
変数名はscope_idという名前だけど、実際はzone identifierなんです。
で、話がまた外れてしまったので、サイトローカルアドレスの話に戻すと、ゾーン識別子をどのような表現で扱うのかはホスト内での実装に依存します。
そのため、複数のゾーンが存在可能であるサイトローカルアドレスを使うためには、fec0::1%1であったり、fec0::1%2のように、ゾーン識別子を指定する必要があったわけです。
しかし、ゾーン識別子の表現方法がホスト依存するし、ゾーン識別子の表現の標準が存在しないし、ゾーン識別子はDNS等に掲載するものでもなく、そもそも、どのアドレスとどのゾーンを関連付けるのかをどうやって判別すべきなのか？
サイトローカルアドレスに関しては、そこが曖昧でした。
リンクローカルアドレスに関しては、そのスコープが単一のリンク内に必ず閉じていて、かつ、単一のノード内に閉じた話なので表現可能なのですが、ルータを超える範囲を持つことも可能であるサイトローカルアドレスの場合はゾーン識別子の扱いが曖昧になってしまいます。
そういった問題があり、サイトローカルアドレスは廃止されました。
ULAは、スコープが世界全体となり、ゾーンがひとつしか存在しないグローバルスコープのアドレスです。
そのため、GUAと同様に、というよりGUAの一部として、IPv6アドレスとともに%をつける必要がありません。
IETFでは、IPv4と同じようなやり方でIPv6 NATを利用することは「特殊な場合を除き非推奨」としています。
IETFにおけるIPv6 NATへの見解として参照されることが多いのがRFC 5902とRFC 4864の2つです。
NATが抱える問題点をまとめたものとしては、2000年に発行されたRFC 2993もあります。
NATは、内部から外部への通信に応じて動的にフィルタを追加します。
この挙動はSFI(Stateful Filter Implementation)やSPF(Stateful Packet Filtering)と呼ばれます。
SFIは外部から内部への接続を行うための難易度を上昇させるため、簡易なセキュリティとみなされることもあり、「NATが不要なIPv6ではIPv4より攻撃を受けやすくなる」と主張されることもあります。
しかし、NATのSFIはセキュリティを実現する目的で設計されているのではありません。
あくまで、IPv4アドレスの在庫枯渇問題に対する短期的解決策としてIPv4アドレスを効果的に利用するための仕組みの副作用として、外部から内部への接続性が低下しているだけという主張があります。
SFIを実現するためにNATそのものは不要であり、NATを利用せずにIPv6においても「IPv4 NATと同等のセキュリティ」を確保する方法がRFC 4864で提案されています。
適切にフィルタを設定することで、NATを使わなくてもNATと同等のセキュリティが確保できるというものです。
RFC 4864では、ファイアウォールでは内部からの攻撃に対処ができないといった点も指摘されています。
2010年に発行されたRFC 5902は、「IAB Thoughts on IPv6 Network Address Translation(参考訳：IPv6 NATに関するIABの考え)」というタイトルです。
そこでは、「NATとファイアウォールを混同すべきではない(one should not confuse NAT boxes with firewalls)」、「IPv6 NATは好ましくない(we do not consider IPv6 NATs to be desirable)」といった記述があります。
IPv6でグローバルユニキャストアドレス(GUA)での運用を行っていたとしても、適切にフィルタを設定すれば問題はないという考え方です。
その理由としてRFC 5902で書かれているのが、NATによって「end-to-end transparancy」「end-to-end reachability」が阻害されることを指摘しています。
IETFにおいて大事とされている「end-to-end principle(end-to-endの原則)」に基づく考え方です。
その一方で、RFC 5902では、マルチホーム環境やリナンバリングといった用途ではIPv6 NATの有用性を認めています。
IPv6 NATには、大きく分けて2種類あります。
IPv4 NATと同じ仕組みのものと、違う仕組みのものです。
RFC 1631にあるように、IPv4にもポート変換(IP masquerade)を行わないNATというものも過去に存在しましたが、昨今ではIPv4 NATといえばポート番号の変化を行うNAPTを含むことが大半です。
かつて、雑誌記事、ブログ、書籍等において「NAT」と書くと、「NATとNAPTは違うものだ」というツッコミを入れる人が沸いていました。
1バイトを8ビットであることを明示せずに前提とするとツッコミを入れたがる人が沸いたのと似たような感じです。
しかし、いまではIPv4 NATに関して、「（NAPT)」と断りを記述しなかったとしても、あまり文句を言われるようなことは減りました。
それぐらい、NATといえばポート変換を含むことが当たり前とも言えるようになりました。
さて、話がIPv6に戻りますが、IPv6には、IPv4 NAT(NAPT)と同様にポート変換を含むNAPTv6と、アドレス変換のみが行われるNPTv6の2種類があります。
どちらも世の中に実装があります。
ポート変換を含むNAPTv6はRFCになっていませんが、NPTv6はRFC 6296として2011年にRFC化されています。
ポート変換を含むNAPTv6は、IPv4 NATと同じようなものであると考えていただければ良いと思うので今回は紹介を割愛します。
(IPv4 NATについて知りたい方は、拙著「徹底解説v6プラス」もしくは「プロフェッショナルIPv6」のPDFが無料公開されているのでそちらをご覧ください。もちろん、有料版をご購入頂けると嬉しいです)
ということで、ここではNPTv6について紹介します。
NPTv6のRFC 6296はExperimentalという位置付けです。
RFC 6296には「IETF does not recommend the use of Network Address Translation technology for IPv6(参考訳：IETFはIPv6でNATを利用することを推奨しない)」と書かれており、ここからもIPv6におけるNATがIETFで非推奨であることがわかります。
NPTv6の特徴ですが、IPv4 NATとNAPTv6はステートフルなNATですが、NPTv6はステートレスなNATです。
IPv4 NATでは、WAN側(外側)IPアドレスが1つ(またはCGNだと複数)に対してLAN側(内側)が複数であるのに対して、NPTv6では1対1になります。
それにより、IPv4 NATのようにEnd-to-End reachabilityが毀損されません。
また、1つのWAN側IPアドレスを複数のLAN側ノードで共同利用することもないため、トランスポート層プロトコルでのポート番号を変換する必要がありません。
この変換が不要であるため、ステートレスな仕組みになっています。
チェックサムニュートラル(checksum-neutral)であることもNPTv6の特徴です。
LAN側のIPv6アドレスがWAN側IPv6アドレスに変換されるときに、IPv6ヘッダから計算されるチェックサムの値が同じになるようにIPv6アドレスの変換が行われます。
これにより、TCPやUDPなどのヘッダでのチェックサムを再計算する必要がなくなるため、IPv4 NATよりもルータにかかる負荷が軽減されます。
2024年に、ExperimentalなRFCであるNPTv6のRFC 6296をStandards Trackへと更新しようというInternet draftが提案されていました(draft-bctb-6man-rfc6296-bis)。
このdraftには業界の重鎮も含まれていましたが、2024年7月にExpireしました。
2024年時点におけるNPTv6の実装状況なども書かれており、面白い内容なので興味のある方は是非ご覧ください。
RFC 7084は「Basic Requirements for IPv6 Customer Edge Routers」というタイトルです。
日本語に訳すと「IPv6 CE(Customer Edge)ルータの要求される基本仕様」という感じです。
CEルータは、SOHOルータや家庭用ルータと読み替えても良いと思います。
RFC 7084にはULAに関する言及もあります。
RFC 7084では、ULAのアドレスを利用したトラフィックがWAN側のインターフェースから外に出ないようにすること、
ULAに含まれるランダム部分を生成したルータが再起動してもULAプレフィックスが記憶されることなど、
IPv6 CEルータがULAをどのように扱うべきなのかが紹介されています。
RFC 7084では、IPv6 CEルータがWAN側でのIPv6接続性を有せず、扱っているIPv6プレフィックスがULAのみの場合には、自分自身をdefault routerとして広告することを禁止しています。
具体的には、RAのrouter lifetimeとして、0よりも大きい値を設定することを禁止しています。
さて、ULAと家庭用IPv6ルータという話題では、IPv6 NATに関する言及が気になるところですが、
RFC 7084には、IPv6 NATであるNPTv6やNAPTv6を禁止していると読める文言がなさそうです。
たとえば、WAN側にIPv6インターネットとの接続性がある状態で、LAN側ではULAのみを広告しつつ、default routerとして自身を広告するようなことは明示的に禁止されていないと思われます。
2024年12月現在、IETFにおいてdraft-ietf-6man-rfc6724-updateの議論が行われています。
このdraftは、IPv6のためのポリシーテーブルについて規定しているRFC 6724に対する更新を目指したdraftです。
順を追って説明します。
IPv6には、アドレス選択で利用されるポリシーテーブルという仕組みがあります。
ポリシーテーブルを利用して、IPv6アドレスのプレフィックスに対して、ルーティングテーブルのようなロンゲストマッチが行われます。
ポリシーテーブルには、Precedence(優先順位)とLabel(ラベル)という要素があり、それらが宛先選択と送信元選択で利用されます。
どのような形で優先されるかの例ですが、getaddrinfo()は複数の結果がある場合には、それらがリストになって返ってきますが、ポリシーテーブルにおいて優先順位が高いものから順番にリストが並びます。
draft-ietf-6man-rfc6724-updateが着目しているのは、ULAとIPv4の優先順位です。
RFC 6724の10.6では、以下のような例を示しており、ULAの優先順位がIPv4アドレスよりも低いものとなっています。
| Prefix | Precedence | Label |
|---|
| ::1/128 | 50 | 0 |
| fd11:1111:1111::/48 | 45 | 14 |
| ::/0 | 40 | 1 |
| ::ffff:0:0/96 | 35 | 4 |
| 2002::/16 | 30 | 2 |
| 2001::/32 | 5 | 5 |
| fc00::/7 | 3 | 13 |
| ::/96 | 1 | 3 |
| fec0::/10 | 1 | 11 |
| 3ffe::/16 | 1 | 12 |
上記の例では、IPv4を意味する::ffff:0:0/96 よりも ULAのfc00::/7が低い優先順位(Precedence)になっています。
多くの実装は、RFC 6724(旧3484)に規定されたポリシーテーブルが初期値として設定されています。
このため、多くの環境において、IPv4によるプライベートIPアドレスと、IPv6によるULAで運用されている環境では、ULAよりもプライベートIPアドレスが優先されます。
これによって何が起きる可能性があるかですが、たとえば、IPv6はULAのみで、IPv4はプライベートIPアドレスのみというネットワークがあったとします。
そのネットワークでは、IPv4とIPv6の両方でNATが行われることで、インターネットとの通信を行うようになっていたとします。
そのような環境に接続したホストが、IPv6とIPv4の両方のアドレスを持つサーバとの接続を行う際に、ホストに設定されているIPv6アドレスがULAのみであるために、IPv4を利用した通信が優先される可能性が高くなってしまいます。
draft-ietf-6man-rfc6724-updateは、「IPv4よりもIPv6を優先する」という精神のもと、「Lビットを1とするfd00::/8のULAをIPv4よりも優先度を高くしよう」と提案しているわけです。
他にも2点の提案をしており、以下の3点がdraft-ietf-6man-rfc6724-updateに書かれています。
- update the default policy table (参考訳：ポリシーテーブルのデフォルト値を更新する)
- change Rule 5.5 on prefering addresses in a prefix advertised by the next-hop to a MUST(参考訳：ルール5.5にある、next-hopによって広告されたプレフィックスを優先することをMUSTに変更する)
- require that nodes MUST insert observed known-local ULA prefixes into their policy table(参考訳：ノードが観測したknown-localなULAプレフィックスをポリシーテーブルに追加することをMUSTとする)
このdraftは、2024年12月現在、まだ議論が継続している状態でRFCに至っていません。
しかし、このdraftがRFCになった場合、もしかしたら、IPv6においてNATを使いやすくなる可能性はあるかも知れないということで、一部界隈において注目されています。
なぜならば、いまはプライベートIPアドレスがULAよりも優先順位が高いため、ULAとプライベートIPアドレスで運用されているホストにおいて、IPv6が使われにくくなっているためです。
ULA+IPv6 NATという環境があったとしても、IPv4 NATを経由する通信方法の優先順位の方が高くなる可能性があります。
だたし、このdraft(ver15段階)は、以下のように書かれており、draftそのものがIPv6におけるNATであったり、ULAの用途を論じているわけではありません。
However, this document makes no comment or recommendation on how ULAs are used, or on the use of NAT in an IPv6 network.
もしかしたら、そういった意図を頭の片隅(?or中心)に持った方々がdraftを進めている可能性はありますが、このdraftは、あくまでIPv6をIPv4よりも優先するという記述になっています。
なお、draft-ietf-6man-rfc6724-updateにも書かれているように、Happy Eyeballs(RFC 6555, RFC 8305)も大きな要素です。
ここら辺の、マルチプレフィックス/マルチアドレスまわりの話は、実装依存する部分も多く、割と面倒なのです。
IPv6には、プレフィックス単位でアドレスを配るDHCPv6-PDという仕組みがあります(RFC 8415のPrefix Delegation関連項目参照)。
IPv4のように、ISP等から提供されるIPアドレスがひとつだけの場合には、そのIPアドレスの裏側に複数の機器を接続するためにNATが必要になってしまいます。
しかし、IPv6の場合は状況が異なります。
ルータからRAが降ってくるパターンの場合は、そのルータと直接接続している形になっている複数の機器が個別のIPv6アドレスを設定します。
DHCPv6-PDによってプレフィックスが提供される場合、そのプレフィックスを使ってサブネットを運用することができます。
エンタープライズネットワークや巨大Wi-Fiネットワーク等においてDHCPv6-PDを活用することに関して情報をまとめたInformationalなRFCであるRFC 9663が2024年10月に発行されています。
RFC 9663では、DHCPv6-PDを利用して個々のデバイスに対してIPv6アドレスをひとつだけ割り当てるのではなく、IPv6プレフィックスを割り当てることを提案しています。
今後、RFC 9663に書かれているような用途が増えるかどうかは現時点では不明ですが、個々のデバイスに対してIPv6アドレスひとつを割り当てるのではなくプレフィックス単位での割り当てが行われるようになれば、そのデバイス内でVMを運用するときにULAを利用しないという選択肢も出てきます。
エンドユーザに対するIPv6アドレスの割り当てをどうするのか？という視点では、DHCPv6-PDも今後の議論において重要な要素のひとつであると考えています。
最後に
「IPv6の勉強をするために簡単なネットワークを構築してみたい」という要求に対して、実験環境で利用すべきIPv6アドレスをどうすべきか？が、2024年現在は、そこまで明確ではないと私は個人的に考えています。
IPv6アドレスがISPから降ってくる環境であれば、エンドユーザとしてIPv6を試すことは可能ですが、たとえば、自分が管理権限を一切持たないような既存のマンションインターネットなどでは、色々と難しくなってしまいます。
そして、IPv6がISPから提供されている環境であったとしても、RAによって/64の割り当てが行われるだけの環境では、L3的なルーティングを伴う複数セグメントを運用することに対して多くの制約が伴います。
そこでIPv6のULAを使うという選択肢も出てくるのですが、IPv6でULA＋NATという運用はIETF等では推奨されていないということになっており、IPv4のプライベートIPアドレスと同じ感覚でULAを使うことは、推奨されないという意見もあります。
その一方で、「いやいや、同じように使いたいし」という意見も根強くあり、今も綱引きが続いています。
「じゃあ、どうすれば良いの？」という話なのですが、私は、現時点では明確に「こうすべき」という解決方法を提示できません。
どうすれば良いんですかね？
]]>
HP QFX5250-64OE-L
(D6ラック)
nexus 9164E-MS4
(D3ラック)
HP QFX5240-64OD
(D3ラック)
華為 xh9320-64EO
(D3ラック)
1Finity s9321-64E
(D3ラック)
