URIに含まれるIPv6ゾーンID - RFC 6874

fe80::/64というリンクローカルIPv6アドレス(リンクローカルユニキャストIPv6アドレス)は、同一リンク内でのみ利用可能なリンクローカルスコープのIPv6アドレスです。 リンクローカルスコープのIPv6アドレスは、同一リンク内においてのみ利用可能であるため、他のリンク内に存在しているリンクローカルIPv6アドレスに干渉しません。 そのため、たとえば、fe80::aというIPv6アドレスが、それぞれ異なるリンクに存在していてもOKです。

さらに、リンクローカルIPv6アドレスは、IPv6が有効になっている全てのネットワークインターフェースに対して設定されるため、世界中のさまざまなリンクでfe80::/64というプレフィックスが存在しています。 そのため、fe80::/64による128ビットのIPv6アドレスだけでは、通信相手を一意に指定できない場合があります。

続きを読む...

ラムダノート社で「プロフェッショナルIPv6」を執筆した理由

個人的には、拙著「プロフェッショナルIPv6」は、世界で最も詳しくて読みやすいIPv6解説本だと考えています。 450ページを超えるコンテンツを全部タダで読めるというのも大きな特徴です。

このような「プロフェッショナルIPv6」の企画は、ラムダノート社でしか実現できなかったと私は考えています。 いまでこそ、ラムダノート社は複数のIT技術書を出版する出版社ですが、IPv6本の企画が開始した段階では、ラムダノート社は、まだ一冊も出していない状態でした。 それでも、私はラムダノート社でIPv6本を出したかったのです。

続きを読む...

特集「リハ専門医が知っておくべき骨関節の3次元動態」が面白い

The Japanese Journal of Rehabilitation Medicineの2016年53巻10号に掲載されている特集「リハ専門医が知っておくべき骨関節の3次元動態」が無料公開されています。 リハビリ専門家に向けた論文誌ですが、解説記事なので、私のようなスポーツをする子供を持つ一般保護者が読んでも面白く、非常にためにな内容です。

以下、特集に含まれる記事とPDFダウンロードURL一覧です。

クラウドファンディングIT技術書「プロフェッショナルIPv6」無償配布から1ヶ月

クラウドファンディングで作ったIPv6本である「プロフェッショナルIPv6」の電子版を無償配布してから1ヶ月が経ちました。サポーターの方々に紙版のIPv6本をお届けし、クラウドファンディングのプロジェクトを無事に終えることができました(「あきみちを呼ぶ権利」がいくつか残っています)。 完成した「プロフェッショナルIPv6」の紙版および電子版の一般販売も開始されました。

Twitterなどで、「プロフェッショナルIPv6」や「IPv6本」といったキーワードでエゴサーチをしていると、書籍の写真を掲載されている方々を発見できます。 それらを見ると、本当に多くの方々に喜んでいただけているのがよくわかります。 今回、クラウドファンディングという形で書籍を作りましたが、それによって多くのサポーターの方々と、ある種の一体感を感じることができています。

続きを読む...

すごいIPv6本を無料配布!

IPv6を解説した「プロフェッショナルIPv6」をラムダノート株式会社から出版しました。 初版は456ページになりました。紙版の厚さは23mmになる予定です。 現時点で、IPv6に関して世界で最もまとまっているIPv6本であると個人的に考えています。

「プロフェッショナルIPv6」は、株式会社日本レジストリサービス様、BBIX株式会社様、NTTコミュニケーションズ株式会社様、日本ネットワークイネイブラー株式会社様、クラウドファンディング(「すごい技術書を一緒に作ろう。」という企画です)でのみなさまによるサポートにより実現しました。 IPv6に関する技術情報を広く公開するという趣旨に賛同いただき、本書の執筆と制作、公開にあたって多大な協賛をいただきました。ありがとうございます!!!

続きを読む...

セネガル戦のハーフタイムと終了直後にインターネットトラフィック急増

ワールドカップでの日本代表戦テレビ中継のハーフタイムと終了直前に水道使用量が急増するそうです。 NHKの記事では、「トイレなどで水を一気に使ったのが理由ではないか」と理由を推測しています。

サッカーワールドカップ、ロシア大会の日本とセネガルの試合でも、コロンビア戦と同じように東京23区の水道の使用量が試合のハーフタイムの間と試合の終了直後に急激に増えました。

ワールドカップは、水道だけではなくインターネットにも影響を与えている可能性があります。 ISPなどが相互に接続し、インターネットの交差点のような存在となっているIX(Internet eXchange)であるJPIXJPNAPでトラフィック情報が公開されています。 それらの公開情報を見ると、水道だけではなく、インターネットの使用量もハーフタイムと終了直後に増えていました。 そして、試合中はトラフィックが急激に減っています。

続きを読む...

Z-WaveのIoTゲートウェイ@Interop Tokyo 2018

400G SR8 OSFP

プログラマブルな電話通知サービス@Interop Tokyo 2018

プログラマブルな電話通知クラウドサービス、「Symphony Call」が出展されていました。

Symphony Callは、アラートメールをトリガとした「メール連携」によって通知を実行したり、Web API経由での電話通知、Web画面からの電話通知、あらかじめ設定した時間での電話通知など、様々なトリガーから電話通知ができます。

続きを読む...

ShowNet 2018の来場者用無線LAN

ShowNetでの無線LANサービス提供のチャレンジは年々進化してますが、ここ数年のShowNetでは、会場内での来場者向け無線LANの安定した提供ができるようになっています。(参考までに、2013年に書いた記事「ShowNetの「汚れた無線LAN、クリーンアップ大作戦」」)

今年の新しい試みとしては「5GHzベース、5Gbpsベース」があります。 802.11ac Wave2の新製品が色々出てきているので、それらを活用しています。 今回は、8割が802.11ac Wave2のアクセスポイントです。 802.11ac Wave2で新たに加えられた技術であるMU-MIMOによって、複数人に対して電波を同時に送られています。

続きを読む...

ShowNet 2018モニタリング

ShowNetのトポロジ図に掲載されたすべての機器を監視対象としたモニタリングが行われています。 監視機器数 900弱、監視ターゲットの総数が10万監視ポイント、受信トラップ数が1日約19万弱、1日に1億から2億行のシスログ/xFlow/snmptrapを転送しているという環境を、NOCメンバー2名が管理しているのです。

統合監視

続きを読む...

100G LAG@Interop Tokyo 2018

Interop Tokyo 2018 ShowNetで、100Gリンクアグリゲーションのデモが行われています。

100G LAGは、NTTコミュニケーションズのグローバルIPネットワークサービス(GIN)の100Gx2回線を、幕張メッセと大手町を結んでいます。

続きを読む...

ShowNet Self Walking Tour

ShowNet 2018では、IoT関連のデモとして、LTE網に接続されたQRコードリーダーにラズベリーパイによるスタンプラリー企画「ShowNet Self Walking Tour」が行われています。 毎年、ShowNetの解説を聞きながらまわるShowNetツアーが行われていますが、ShowNet Self Walking Tourは、場内9箇所をスタンプラリー的に自分でまわるというものです。 9箇所全部をまわると、最後に景品がもらえます。


図:スタンプラリー設置箇所

ShowNet Self Walking Tourの集計サーバは、ShowNetのNOCラックで稼働しています。 場内9箇所にあるラズベリーパイ端末は、LTE網を経由して集計サーバと通信しています。 9箇所のうち、3箇所は総務省で「高度化方式」と呼ばれているLTE方式を使った地域BWA(阪神ケーブルエンジニアリングと華為技術日本)、残りの6箇所はShowNetがMVNOを構築したLTE網(さくらインターネットとLTE-X)と接続しています。

続きを読む...

TCAMと同等以上の性能をソフトウェアで実現したBGPルータ@Interop Tokyo 2018

Interop Tokyo 2018のShowNetバックボーンにて、NTTコミュニケーションズが開発したBGPルータ「Kamuee」が展示されています。 Kamueeは、TCAMと同等以上の性能をソフトウェアで実現できるという特徴があるとのことでした。

Kamueeの特徴は、非常に多くの経路情報が登録された状態で、高性能なパケット転送処理ができるというものです。 これまでも、経路情報が多数登録されていない状態であれば、DPDKの活用のみでソフトウェアによる高速なパケット転送に対する取り組みは過去に既に存在してました。 Kamueeが面白いのは、フルルート(Full route。IPv4が約70万プレフィックス、IPv6が約6万プレフィックス)を扱いながらも、高速なパケット転送が行える点です。 インターネット全体を示す地図ともいえるフルルートを扱うデータを圧縮することによって、CPUキャッシュに全部収めてしまったことがKamueeであるとも言えそうです。


写真:Kamueeの説明をする小原氏

続きを読む...

Interop Tokyo 2018 ShowNet展示

Interop Tokyo取材も、今年で10年目です。ShowNet取材をしていて、ふと、「あれ?ShowNet展示の一覧があると便利じゃないか?」と思ったのですが、なぜ今まで思いつかなかったのでしょうか。。。

個別の項目をどこまで取材できるのかは、まだ不明ですが、Interop Tokyo 2018記事の第1弾として、まずは、ShowNet 2018の見どころ集です!

続きを読む...

IPv6本の進捗

IPv6本の完成が徐々に近づいています。 5月21日に、IPv6本サポーターの皆様宛に、製作中のIPv6本PDF最新版をお送りしています。 今回のフィードバックが出版前の最終チェック用になります。 フィードバックの締め切りは、6月11日を予定しています。 まだご覧になっていないサポーターの皆様は、マクアケのメッセージをご覧ください。

今回のPDFから、マクアケでのクラウドファンディング等によるサポーターの皆様の名前が掲載されています。 掲載されるお名前がご希望通りであるかのご確認もお願い致します。

続きを読む...

IPv6本 脱稿しました

2011年から書き続けていたIPv6本がついに脱稿しました。 この本は、クラウドファンディングで書きました。 完成したIPv6本の電子版は無償配布します。 サポーターの皆様、ありがとうございます! 全章のフィードバック受付版は、5月21日(月)にマクアケ経由のメッセージにてサポーターの皆様にお送りする予定です。 その後、7月中に完成した書籍をサポーターの皆様にお届けするとともに、一般公開および一般販売開始する予定です。

IPv6本電子版の無償配布を行いますが、紙版と電子版の販売も行います。 ご購入いただけると、私とラムダノート社が喜びます。

続きを読む...

2017年の記事ベスト10(PV順)

本日で2017年も終わりです。 2017年に書いた記事で、PVが多かったベスト10です。

  1. 「ひとりで何でもできるエンジニア」は勝手に育つ
  2. 2017年8月25日の大規模インターネット障害
  3. オーム社電子書籍直販サービス終了に関して
  4. インターネットは当初目指したものではなくなってしまった
  5. 無償で読めるIPv6本を作ります
  6. フリーランスになって10年
  7. IPv6って速いの?
  8. ややこしいIPv6アドレス自動設定の話
  9. 「すごいエンジニア」は凄いエンジニアになることを目指してないかも
  10. 「女性は生まれつきエンジニアに向かない」と元Google社員は主張していたのか?

2018年もよろしくお願い致します!

IPv6って速いの?

最近、たまに「IPv6って速いんですか?」という質問をされることがあります。 それに対して意図的に非常に雑な回答をする場合には、「はい。IPv6を使うと速くなる場合があります。」と答えるようにしています。

今回は、「IPv6の方が速い」となる可能性がありそうな場合をいくつか紹介します。

続きを読む...

Happy Eyeballs Version 2 (RFC 8305)

Happy Eyeballs Version 2のRFC 8305が発行されました。 RFC 8305は、Happy Eyeballs (Version 1)を定義していたRFC 6555を上書き廃止するので、旧Happy Eyeballsが廃止されたうえで、Version 2の利用が推奨されることになります。

RFC 8305のAppendix AにRFC 6555との違いがまとめらています。RFC 8305とRFC 6555の違いは以下のようなものです。

  • how to perform DNS queries to obtain these addresses
  • how to handle multiple addresses from each address family
  • how to handle DNS updates while connections are being raced
  • how to leverage historical information
  • how to support IPv6-only networks with NAT64 and DNS64

(意訳等)
  • IPアドレスを得るためのDNSキュエリーを行う方法
  • 各アドレスファミリ毎に複数のIPアドレスがある場合の処理
  • DNSに関連するアップデートがコネクション確立試行中に発生した場合の処理(IETFで議論中のDNSプッシュ(draft-ietf-dnssd-push-13)やTTL切れに関して書かれています)
  • 過去の通信履歴を利用する方法(過去の通信時のRTT等を使うなど)
  • NAT64とDNS64によるIPv6-onlyネットワークをサポートする方法

続きを読む...