RedhatがNTT Comとクラウドで協業を拡大
2011年4月14日，RedhatはNTTコミュニケーションズとのクラウドにおける協業を拡大したと発表した．
2010年4月の協業開始でNTTコミュニケーションズは「Red Hat Premier Certified Cloud Partner」となったが，今回の協業拡大では「Biz ホスティング ベーシック」の基盤としてKVMベースの「Red Hat Enterprise Virtualization」と「Red Hat Enterprise Linux」 の採用を拡大するとのこと．
NTT Comがクラウド型家計簿「OCN家計簿」の提供を開始
2011年4月18日，NTTコミュニケーションズはクラウド型家計簿「OCN家計簿」の提供を開始したと発表した．
このサービスでは銀行口座やクレジットカード，ネット通販などの明細を自動的に取り込むことで家計簿や資産管理簿を自動作成することができる．
取り込みができるのは銀行口座，クレジットカード，ネット通販，公共料金（電話，ガス，水道，電力）マイレージ，ポイントなどで，137社のコンテンツパートナーから．自動取り込みのためにはIDとパスワードを預ける必要があるとのこと．
MicrosoftがNortelからIPv4アドレス666,624個を$7.5Mで購入？
ベトナムのIPv6移行
ベトナムは2020年までのIPv6への移行を国家プロジェクトとしており，現在第一段階を進めている．教育カリキュラムにIPv6のテーマを盛り込むなどの促進政策も行っているようだ．IPv6実験網には多くのISPが参加しているがまだ２つの巨大ISPが参加していない．IPv6国家タスクフォースの会合は４月末に召集される予定である．
ベトナムがIPv6に移行するのには４，５年要するだろう
VietNamNet Bridge - 情報通信省の管轄であるベトナム インターネット ネットワークインフォメーションセンターは，もしISPが必要な変更を実施するチームへの参加に尽力してくれない限りは，ベトナムがIPv6技術に完全に切り替わるのに４〜５年を要する必要があるだろうと信じている．
情報通信大臣のLe Doan Hopは2011年の３月末に第433号決定にサインし，2020年までにベトナムのインターネットのネットワークとサービスをIPv6テクノロジーへ移行することを予定するIPv6の国家アクションプランを公開した．
Hopは，ISPの運用と，徐々にベトナムのインターネット利用者にIPv6でサービスを提供するためにネットワークを切り替える実験を実施するという国家計画に適した，IPv6アクションプランの確立と公表を早急に行うようにISPに求めた．
Hopはまた，タスクフォースのメンバーに教育訓練省の下でIPv6の利用を促進し，電子工学，電気通信学，情報技術の学生のカリキュラムにIPv6のテーマを入れてベトナムの全労働者がIPv6への切り替えに準備できるようにするように求た．
IPv6への切り替えのプロセスは３つの段階からなる予定だ．最初の段階は2011年から2012年の準備期間，第二の段階は2013年から2015年でキックオフの期間になるだろう．公式な切り替えは第三の段階である2016年から2019年に実行されるつもりである．
VNNICの副所長であるTran Minh Tanは，IPv4アドレスがほとんど枯渇するという重大な時期に決定は行われたとコメントを述べた．決定はインターネットを維持し発展させるというベトナムの強い決断力を示していると述べた．決定はIPv4からIPv6への切り替えにおける国際統合に対するベトナムの強い決断力も示している．
ISPは具体的な計画を立て社会に提供されるべきIPv6のサービス設計するように指示されてきた．IPv6国家タスクフォースの会合は４月末に召集される予定であり，具体的な計画が設定され，具体的なタスクがISPに割り当てられるだろう．
Tanによれば，計画の2011年から2012年の第一段階における最も重要な目標は，国家的なIPv6実験ネットワークを構築し．I実験ネットワークにISPが接続可能なように準備しておくことだという．
これまでにNetnamやViettel, VTC, EVN, SPTは国家IPv6ネットワークに接続完了したが，２つの巨大なISPであるVDCとFPTはまだ接続を行っていない．
加えて，アクションプランを実行する第一段階において，共産党機関に供している特定のネットワークや，国の行政機関もIPv6対応を行う必要がある．この情報技術プロジェクトは国家予算から資金提供されているためにIPv6利用の先駆者にならなくてはいけないのだ．
ここで，もしベトナムにとって2020年までにIPv6利用に移行するのが既に遅かった場合はどうするのかという疑問が生じる．世界がその時までに完全にIPv6へ移行しているのに対し．ベトナムがもし計画の第一段階の後で多くのことを果たすことができるのなら，ベトナムはただちにIPv6に切り替えなくてはならないだろう，とTanは答えた．しかし彼は．．．
TanはIPv6利用へ切り替えることは必要であると強調した．なぜならIPv4のアドレスはほとんど枯渇しているからだ．加えて彼によれば，ISPがIPv6でどんなサービスを提供したとしても，サービス提供の競争は切り替えプロセスに対してさらに大きな効果があるという．言い換えれば，もしISPが依然としてサービスを提供できなかったのなら，IPv6への切り替えが成功するのは難しいだろう．
サービスを提供するためにすぐにISPは外国のパートナーと共にチームに参加するだろうとTanは考えている．人は一度サービスに慣れ親しんだら提供者は付いていくべき良いビジネス分野を見つけるだろう．
東日本大震災によって被害を受けた海底ケーブル
米国へのNTT経由の経路が大阪周りになっていたので海底ケーブルが切れたかなぁとつぶやいていたのだけど，本当に切れていたみたいです．公にされている情報から分かったのは３つ．
- PC-1 West (Ajigaura - Habor Point)
- PC-1 North (Ajigaura - Shima)
- Japan-US (Kita-Ibaragi - Manchester)
APNICのIPv4アドレスが枯渇
2011年04月日，APNICはIPv4アドレスが枯渇したと発表した．ただし2011年2月3日にIANAの在庫が枯渇したときとは少し事情が違い，APNICの場合は/8ブロックが残り１つになった時点で枯渇としている．
APNICが枯渇したということでJPNICも同時に枯渇したということになる．JPNICによればこの最後の/8ブロックの割り振りは特別なポリシーで割り振られることになる．
- 新規の事業者およびIPv6への移行のために利用される場合認められる
- 初回割り振りまたは追加割り振り基準を満たしていれば1組織につき1回まで/22の割り振りが認められる
DNSがもっと良かったらという思考実験
概要
IPv4 アドレスが枯渇しヴァーチャルドメインが普及する現代では，DNSとWell Known Portで構成されるアプリケーションの通信にTLS証明書問題などの不都合が生じることが稀に良くある．DNSとportmapを組み合わせたような賢いサービスディスカバリーシステムを導入していたらスマートなインターネットができたのではないのか，という考察を思考整理を兼ねて行ってみる．
DNS
ドメイン名とIPアドレスを対応付ける仕組み．10.0.0.1 だとわかりにくいから www.yuyarin.net という名前を付ける．名前を「解決」するとIPアドレスが得られ，アプリケーションは解決で得られたIPアドレスを使って通信を行う．
ドメイン名からIPアドレスを解決することを正引き，IPアドレスからドメイン名を解決することを逆引きという．正引きは違うドメインが同一のIPアドレスを指すことができるのでn対1のマッピングである．
Well Known Port
よく知られた通信を行うためのポートは基本的に固定されている．例えばHTTPはTCP80，メールはTCP25など．TCP/UDP のポート1~1024はこれに該当する．Well Known PortはIANAによって管理されている．Well Known Portに当てはまるプロトコルとポート番号のマッピングは/etc/services に記述されており，getservbyname でプロトコル名からポート番号を得られるのだが，大体の場合ポート番号は数値でハードコーディングされる．
struct sockaddr_in s; struct servent *service; // まちがい s.sin_port = htons(80); // せいかい service = getservbyname("http", "tcp"); s.sin_port = service->s_port;
IPv4
過去のインターネットプロトコルであるが何故か現在も大量に利用されている．アドレス空間が狭く，１人１つグローバルアドレスが持てれば御の字である．
想定する状況
ドメインを複数持っているが，グローバルIPv4アドレスを１つしか持ってない時に，Well Known なサービスを提供する状況を考える．
DNSとWell Known Portで困ったこと
httpdを複数立てたい
例えば，このドメインではApache httpd，このドメインではLight httpdを動かしたいという場合や，ドメインごとにApache自体を分けて使いたい場合．TCP80でコンフリクトしてしまう．
場当たり的な解決としては，片方をTCP8080のように別のポートで動かし，www.yuyarin.net:8080 のようにアクセスする．どうしても同じポートを使いたい場合はトランスパレントプロキシを噛ませる．前者はカッコ悪いし後者は面倒である．バッドノウハウ．
postfixのバーチャルドメインとTLS
１つのサーバで複数のドメインのメールを使う場合．postfixのバーチャルドメインで複数のドメインのメールを扱えるのであるが，複数のドメインに対してTLSを提供することができない．これはTLSで暗号化された後にドメイン名の交換が行われるから，ヴァーチャルドメインの証明書を正しく取得できないからである．ちなみにHTTPでは一部のブラウザと一部のhttpdが協調することで，この問題を解決している．このTLS問題はどのプロトコルでも生じる問題である．
解決方法としては，postfixのインスタンスを分けて，それぞれ別のポート番号をアサインし，MUAでのSMTPサーバの設定を変更する．例えばsmtp.yuyarin.net のSMTPは TCP25, smtp.yuyar.in のSMTPはTCP2525 などと．
ただし，他のMTAの設定を変更することはできないので，この場合，smtp.yuyar.in に対して外から飛んでくるメールはどうしようもないのだが，現状はMTA間のTLSなんてほぼ動いていないので TCP25 を使えばよく，問題になってないだけである．
何が悪かったのか
結論から言うと
の２つが原因だと思う．
学校では「ドメイン名はホストを区別してポート番号はプロセスを区別する」と習う．１つのホストに注目した場合これは真であるが，Well Known Portに関して言えば，彼らが区別するのはプロセスではなくプロトコルである．HTTPやFTPは柔軟に別のポート番号が指定できるが，DNSやSMTPはそれができない．
ポート番号が変えられないという状況で，先に述べた問題をスマートに解決するためには新しいIPv4アドレスが必要になる．恐らくDNSができた当時はCIDRが提案される10年も前の話でIPv4アドレスはたくさんあったし，バーチャルドメインなんてものも存在しなかった．だからその解決策が使うことができた，というかそもそも問題が起きなかったのだろう．
ただ，こうした歴史はデプロイを考えた当時のエンジニアリング的には最適な解決策だったことには間違いはない．
どうすれば良かったのか
もし今からインターネットを作り直すとしたらどうするのがいいのだろうか．ドメイン名からアドレスを解決するだけではなく，サービスとドメイン名からアドレスとポート番号を解決できる，もっと賢いサービスディスカバリシステムがあればスマートになるのではないのかと思う．
従来
www.yuyarin.net => 10.0.0.1 www.yuyar.in => 10.0.0.1 http => tcp80 (決め打ち)
http://www.yuyarin.net と http://www.yuyar.in がコンフリクトする．
提案
http://www.yuyarin.net => 10.0.0.1:80 http://www.yuyar.in => 10.0.0.1:8080
http://www.yuyarin.net と http://www.yuyar.in がコンフリクトしない．
Winnyの話
P2Pネットワークは似たような仕組みを実現している．Winnyの初期ノードリストはIPv4アドレスとポート番号の情報が含まれている．実はこの初期ノードリストを検索するという行為は winny というプロトコルを話す（サービスを提供している）ホストを探すという行為である．そこを人間が自分の手でやっていることになる（なんかズレてる例かも）．
portmapの話
サービスからポート番号を知ることができるのがportmapである．サービス名を渡すとアプリケーションレイヤプロトコルのバージョン，セッションレイヤのプロトコルとポート番号がわかる．
提案で書いたような DNS+portmap みたいな仕組みが初めからあればスマートだったのかなと思う．
SRVレコード
DNSにはSRVレコードってのがあって，ドメインの提供するサービスの情報が引けるのだけど，対応してないライブラリが多かったり，実際にSRVレコードを参照するアプリケーションがほとんどないと思う（ActiveDirectoryぐらい？）．ここで話してきたことは「初めっからSRVレコードがメインだったら良かったのに」ということになる．
ついでに言うとMXレコードの存在は気持ちが悪すぎる．
結局は救えないもの
portmap でも portmap 用のポートが固定されているように，こういうサービスディスカバリのシステムがあったとして，そのポート番号は固定になってしまう．なので３つめのDNSの複数インスタンス問題のようなものはどっちみち救えない．うまくやる方法はないのかな．
LSN
LSNが運用され始めるとポート番号のコンフリクトはより深刻になるだろうと思うが，多分LSNに収められるのはそういうことをしない人なので問題ないのか．
