IPv6対応に向かって

IPv4が枯渇すると言われて、もうずいぶん時間が経ったと思います。
2011年の10月には、IANAが管理しているIPアドレスがなくなると言われています。
いよいよ IPv4 から IPv6 への対応が必要になってきています。

IPv6化するメリットとして、利用できるアドレス空間が大幅に増えることと、
ルータの負荷軽減やセキュリティの強化が挙げられるのではないでしょうか。

もちろん、メリットばかりではなく、IPv4 前提に作られたアプリケーションなどを IPv6 対応にしていかなければなりません。
OSの設定やネットワークの設定なども変更が必要になります。
既存のIPv4のサービスをしつつ、IPv6に対応するといった必要もサービスプロバイダによってはあるかもしれません。

通信周りよりもどちらかといえば、データの扱いのほうが色々面倒なのかな、と思います。

IPv4ではuint32_t に収まっていた IP アドレスがIPv6では収まらなくなります。
/usr/include/netinet/in.h

typedef uint32_t                in_addr_t;

DBにINTで入れる設計にしてたら、この修正ってどうなっちゃうんだろう。。。
IPv6になるとIPアドレスのデータサイズが大きくなるので、少量ではありますがDBのデータ量も増えます。
大量のデータを扱わないとならないなら、データが4倍になるので、困るケースもあるかもしれません。

FreeBSDだとIPv6 のアドレスは、下記の構造体で扱われます。

/usr/include/netinet6/in6.h

/*
 * IPv6 address
 */
struct in6_addr {
	union {
		uint8_t         __u6_addr8[16];
		uint16_t        __u6_addr16[8];
		uint32_t        __u6_addr32[4];
	} __u6_addr;                    /* 128-bit IP6 address */
};

最近書いたプログラムでもドット表記(ex. 1.2.3.4)のIPアドレスを受け付けるための input validationのコードもIPv6対応にしないといけません。
いままで、uint32_tでアドレスの値を返していたプログラムは、ポインタを渡したりとか、そういうプログラムに直していくのかな。
sock addr stroage 使え、という話かもしれませんが。

Webアプリケーションで、IPv4のアドレスを入力させている場合にはIPv6の値を受け入れるためのフォームを作り直したりとか、
もう、あちこちでいろんなことがありそうです。
アクセスログの解析がIPv4前提で書いていると、それも直さないといけません。
ほんとに、スゴイ量の修正が世の中で必要になるのではないかと思うと、ほんとに大変だなぁ、と思います。

この移行作業も世の中が粛々と進めていくのだと思いますが、
2038年頃に問題になるであろう time_t が溢れる問題とか、またまたイベントがありそうで、今からドキドキしています。
OS的には、time_tのサイズを変更すればよいというレベルかもしれませんが、世の中のアプリケーションでは、それだけでは対応できず、DBのスキーマの変更とかが必要になってしまうような人達もいるのではないかと思われてなりません。

---