IPv4アドレス枯渇と高くついたIPv6 (メモ)

[2021-12] だいぶ昔のメモ。若干最近の状況を加え、別ページに分離。

2021年12月現在, まだ ISPによっては IPv6 化されていない (例えば BBIQ は未了.) が、クライアント側の IPv6 化がかなり進んできた。IPv6 提案当時の幻想「NAT廃止」の逆、NAT64 / DNS64 で、ようやく前に進むようになった。

あと数年で、サーバ側が IPv6 アドレス only にし始める景色になってくるだろう。ここまで25年掛かっている。ずっと昔から書いているが、社会への展開を軽視した技術バカの大失敗として, 歴史に残るのではないか。

IPv6 - Google IPv6 を使って Google にアクセスしているユーザーの割合. これがほぼほぼ100% にならなければ、IPv4アドレスを捨てられない。

枯渇するのは 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と互換性を持たせるようにしなかったんだろう。

IPng 歴史

1991年には, 将来の IPv4 アドレスの枯渇が予想されるようになっていた。

さまざまなプロトコルが提案された。

  • Simple Internet Protocol (SIP) Specification The original Internet-Draft was November 10, 1992. 64-bit addresses.
  • RFC 1347 TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing (1992年6月). IPヴァージョン9. NSAP 可変長アドレス.
  • P. Internet Protocol (pip) 1994年 RFC 1621, RFC 1622. IPヴァージョン8.
  • RFC 1707 CATNIP: Common Architecture for the Internet. アドレスは OSI method of specifying Network Service Access Points (NSAPs). 最大 20 オクテット (160 bits) 可変長. 完全な仕様ではなかったため脱落。
  • RFC 1710 Simple Internet Protocol Plus White Paper. -- SIP と PIP をマージ。アドレスは 64 bits 固定長. 128-bits, 192-bits or even larger も可能?

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は緩やかに普及し、」とある。「なぜ」普及すると思った? 懐疑論者は最初からずっと、そのようなコースを通ることはありえない、と指摘しているのに。

IPsec と NAT敵視

昔の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 に格下げした。

IPv4 を終わらせる

IETF Sunset4 WG は, IPv4 の退場を目指す作業部会だったようだ。2016年3月に, メモ IPv4 Declared Historic が提出された。IPv4 [RFC 791] を歴史的ステイタスに変更する提案。いやいやいやいや、それはアカンやろ。この提案は流れたが、こういう提案が出てくること自体、現実と乖離していた証左ではないか。

クライアントのIPv6 only化

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