[2021-12] だいぶ昔のメモ。若干最近の状況を加え、別ページに分離。
2021年12月現在, まだ ISPによっては IPv6 化されていない (例えば BBIQ は未了.) が、クライアント側の IPv6 化がかなり進んできた。IPv6 提案当時の幻想「NAT廃止」の逆、NAT64 / DNS64 で、ようやく前に進むようになった。
あと数年で、サーバ側が IPv6 アドレス only にし始める景色になってくるだろう。ここまで25年掛かっている。ずっと昔から書いているが、社会への展開を軽視した技術バカの大失敗として, 歴史に残るのではないか。
IPv6 - Google IPv6 を使って Google にアクセスしているユーザーの割合. これがほぼほぼ100% にならなければ、IPv4アドレスを捨てられない。
技術的には、IPv6しか喋れないソフトウェア (クライアント) は、IPv4のサービス (サーバ) を利用できない。IPv6/IPv4 両対応にしたとしても, IPv4 only のときより利用できるサービスが増えるわけではない。モチベイションが乏しい。
他方, IPv6のサーバは IPv4しか喋れないクライアントからの接続を受けることができる (IPv4-mapped address). しかし, IPv4クライアントのために, IPv4 アドレスを維持する必要がある。ここが重要な点。
まず (a.) 社会全体のサーバがIPv6に対応し、次に (b.) すべてのクライアントがIPv6に移行し、その間も, 各サーバは IPv4 onlyクライアントが廃れるまでIPv4アドレスも持つ必要がある。(c.)「すべての」クライアントがIPv6に対応して初めて、IPv4アドレスを捨てることができる。
結局,「すべての」ソフトウェアが IPv6 に対応するまでIPv4アドレスの需要が減らない。かなり無駄、不効率、不経済。本当になんでIPv6をIPv4と互換性を持たせるようにしなかったんだろう。
1991年には, 将来の IPv4 アドレスの枯渇が予想されるようになっていた。
さまざまなプロトコルが提案された。
RFC 1726 (1994年12月) で, IPng 選定のための技術的な評価基準が記述された。20年間使われることを要求。普及する前に20年経ってしまったがね。
CATNIP, SIPP (RFC 1710) および TUBA の3提案にもとづき, RFC 1752 (The Recommendation for the IP Next Generation Protocol; 1995年1月) にて評価結果が整理され、技術的骨子が決まった。SIPP ベースで 128 bits 固定長に。
IPv6 仕様の初版は RFC 1883 (1995年12月). その後, IPv6 基本仕様は RFC 2460 (1998年12月), RFC 8200 (2017年7月) に更新されている。20歳を超えたIPv6の現状、修正版RFCで廃止/アップデートされる仕様も【IETFトピックス2016-17】 - INTERNET Watch IPsec は SHOULD に格下げ。
See Internet Week 2004 チュートリアル T28, IPv6 Advanced Features
IPv6 のウソ・ホント 2008年.
IPv6のはなし|Wireless・のおと|サイレックス・テクノロジー株式会社
IPv6 Transition and Co-existent with IPv4 (IPv6/IPv4共存技術解説) 2015年11月。このp.5に, IPv6推進者の誤解が集約されている。「IPv6は緩やかに普及し、」とある。「なぜ」普及すると思った? 懐疑論者は最初からずっと、そのようなコースを通ることはありえない、と指摘しているのに。
昔のIPv6 仕様では IPsec が必須となっていた。あくまで仕様では、であって、実際にすべての場面で利用されたわけではない。
IPsec により end-to-end で暗号化するためには、IPアドレスを共用化するNATが邪魔だった。当時の IPv6 技術者は、NAT は暫定的なソリューションであり、IPv6 によってすべての端末にグローバルIPを配布することで NATを廃止できる、と本気で考えていたようだ。例えば, IPv6の拡張機能:IPv6ネットワークへの招待(最終回) 2001年.
RFC 4294 IPv6 Node Requirements (2006年4月) 8.1 で, RFC 4301 IPsec はサポートされなければならない (MUST) としていた。更新された RFC 6434 (2011年12月) 11.1 は, "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be supported by all IPv6 nodes.
として, SHOULD に格下げした。
IETF Sunset4 WG は, IPv4 の退場を目指す作業部会だったようだ。2016年3月に, メモ IPv4 Declared Historic が提出された。IPv4 [RFC 791] を歴史的ステイタスに変更する提案。いやいやいやいや、それはアカンやろ。この提案は流れたが、こういう提案が出てくること自体、現実と乖離していた証左ではないか。
2011年4月15日をもって, APNIC および JPNIC におけるIPv4アドレスの在庫は枯渇した。
クライアントのIPv6 only 化が、社会全体のキモ.
IPv6 only クライアントから IPv4 サービスに到達する技術として, NAT64 / DNS64 が実用化されている。IPv6 onlyクライアントからのDNS問い合わせ、通信相手のアドレスを変換することで, クライアントに対して IPv6 サービスに接続しているように見せかける。RFC 6146: Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (April 2011).
左側が内部、右側が外部。DNS64 は、インターネット上の DNSとのやり取りを変換する。
NAT64 は, IPv6通信とIPv4通信を変換する。
出典 https://www.nic.ad.jp/ja/newsletter/No64/0800.html
これで、上記 (a.) すべてのサービス (サーバ) のIPv6対応、を待たなくても、ISP事業者や携帯電話会社は, 端末を IPv6 only にできる。
もともとは NAT-PT という技術が提案されていたが, 問題が多く, 廃れた。代わりが NAT64 / DNS64.
2016年6月1日より, App Store に提出されたすべてのアプリは, IPv6 only ネットワークをサポートしなければならない (MUST) こととなった。Supporting IPv6-only Networks - Support - Apple Developer