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ネットワークをサポートする方法

続きを読む...

DNS over HTTPSの標準化開始

DNSのメッセージをHTTPSの上に乗せようという標準化活動がIETFで開始されました。 IETFのDOH(DNS Over HTTPS)ワーキンググループです。 DOHワーキンググループは、Applications and Real-timeのエリアです。

先月開催されたIETF 100(2017年11月)にて、DOHワーキンググループの第1回ミーティングが行われました。 そこでは、ワーキンググループが対象としている範囲や、現在あるインターネットドラフトに関しての議論が行われました。

続きを読む...

ネットワークバイトオーダーの公式な参照先はエイプリルフール

インターネットは、その場しのぎの拡張を繰り返して迷路のようになってしまった古い旅館のような側面があります。

インターネットは、インターネットプロトコル(Internet Protocol/IP)を使った通信によって成り立つ世界規模のネットワークですが、そこで使われる非常に多くのプロトコルが「ネットワークバイトオーダー(network byte order)」というデータ転送の順番を採用しています。

続きを読む...

スポーツ上達をデバッグ作業として捉える

スポーツ上達はデバッグ作業に似ているのではないか、最近はそう思うようになりました。

スポーツ上達を考えるとき、普通は、スポーツに関連するスキルを上達させることを真っ先に考えます。 たとえば、サッカーであればボールを使った練習だったり、野球やソフトボールだとバッティングやピッチングという感じです。

続きを読む...

"「腹筋運動」は腰痛の原因"に興味がある人向けお勧め動画

「腹筋運動」は腰痛の原因 バスケ協会「推奨できない」 :朝日新聞デジタルという記事が話題です。その記事の中に、「カナダ・ウォータールー大のスチュアート・マックギル名誉教授の研究」という文章がありました。

子供のスポーツをサポートするためという自分への言い訳をしつつ実際には自分自身の興味の赴くままに、趣味の時間にネット上にある様々な情報を調べたりしていてMcGill教授の発信している情報を色々見ていたので、「あ!世界的に有名な名著、Low Back Disorders (和訳版:腰痛 - エビデンスに基づく予防とリハビリテーション)のStuart McGill教授だ!」と思いました。

続きを読む...

IT技術の理解について

気がつくと、IT技術を解説する文章を10年以上書き続けています。 ブログを書くときには、基本的に自分の興味があることを書くことが多いので、そのときどきによってテーマが変わることも多いです。

私は、技術理解の流れとして以下のようなものがあると感じています。

  1. 興味を持つ
  2. 少し調べて何となくわかった気になる
  3. もうちょっと調べてわかってない部分を発見する
  4. もっと調べて理解を深める
  5. 2と3と4を永遠に繰り返す

続きを読む...

オーム社電子書籍直販サービス終了に関して

オーム社が電子書籍直販サービスを終了するというお知らせがでていました。 同社では、マスタリングTCP/IP RTP編(2004年)、インターネットのカタチ(2011年)、マスタリングTCP/IP OpenFlow編(2013年)の3冊で関わらせていただいたこともあり、今回廃止される電子書籍直販サービスで拙著も販売されていました。

電子書籍直販サービスが終わるということは、ネット上で話題になっていることで知りましたが、「そのうちこうなるだろうと思っていた」ということが起きました。

続きを読む...

変わりゆくインターネットの美意識や価値観

米連邦通信委員会(FCC)が、インターネットを流れるトラフィックに差をつけずに扱うべきであるという「ネット中立性」に関する規制を撤廃する方針を発表しました。

ネット中立性の話とは直接関係はないのですが、この記事を見ていて、20年ぐらい前のIETFでの議論を思い出しました。 当時、学部生だった私は、RSVP(Resource ReSerVation Protocol)の動向を追っていましたが、IETFでの議論では、「そもそも、QoSはインターネットにそぐわない」という論点が度々登場していました。 「Classification?バカなことを言うな!インターネットはBest effortだ!」という感じのノリだったと思います。

続きを読む...

IPv6本を書きながらネットワークエンジニアではない方々向けのIPv6勉強会をやって思った、IPv4とIPv6の大きな違い

無償で読めるIPv6本を書き進めています。IPv6そのものを解説する方法をあれやこれやと試行錯誤しています。 あーでもない、こーでもない、という感じで二歩進んで一歩下がるような感じのときもあります。

その試行錯誤の一環として、ネットワークエンジニアではない方々向けのIPv6勉強会も行いました。 私は比較的、通信事業者どっぷりのコミュニティに入っていると言えますが、そこだけを見ていては、いま書くべきIPv6本は見えてこないのではないかと思って、ネットワークエンジニアではない方々向けの勉強会を主催しました。 実際はネットワークエンジニアの方々も多く参加されているようでしたが、そうではない方々も参加されていたので、IPv6勉強会に参加された方々の反応、質問、アンケート結果など、非常に参考になりました。 参考になると同時に、自分の説明方法で反省すべき点も新たに見えた部分もあります。

続きを読む...

さくらインターネットのウェブアクセラレータは凄く良い感じ

昨日の日本国内のCDNシェアという記事に対して、「個人サイトの利用ならさくらのウェブアクセラレータあたりも中々気になるんだよなあ」というhatenaのブックマークコメントがついたので、書いてみました。

気がつくと全日本剣道連盟の委員も20年目となり、それから派生して色々なスポーツ関係者からWebサイト作りや運営の相談を受けることがあるのですが、だいたいが、組織規模が小さかったり、個人だったりなので、専属でITエンジニアを雇うことができません。 そうすると、基本的にIT系のエンジニアが常に管理することが必要なサーバではなく、ホスティングサービスなど、何らかのマネージドなサービスで、かつ、値段が手頃なところとして、さくらインターネットを勧めることが多いです。

続きを読む...

日本国内のCDNシェア

JStreamによる、日本のCDNシェアに関する調査結果が公表されています。 JStreamブログは、CDNに関連する色々な調査結果をブログで公開していて面白いです。

2017年10月版国内CDNシェアの調査方法は、Webクローラーによるもので、DNSに登録されたCNAMEや、HTTPメッセージに含まれるレスポンスヘッダを解析して判定しています。 判定を行っている対象となるCDNは、Cloudflare、Akamai、CloudFront、CDNetworks、Incapsula、Limelight、Edgecast,国内CDN事業者(Accelia、IDCF、IIJ、J-Stream)です。

続きを読む...

192.168.0.1などのプライベートIPアドレスは途中で作られた

プライベートIPアドレス(プライベートIPv4アドレス)は、インターネットに直接接続しないプライベートな環境で誰でも勝手に使って良いIPv4アドレスです。 普通にインターネットで使われているIPv4アドレスはグローバルIPv4アドレスと呼ばれています。

以下の3つのIPv4アドレスブロックが「プライベートIPアドレス」として予約されています。

  • 10.0.0.0/8(10.0.0.0から10.255.255.255)
  • 172.16.0.0/12(172.16.0.0から172.31.255.255)
  • 192.168.0.0/16(192.168.0.0から192.168.255.255)

続きを読む...

APNICブログでIPv6勉強会が紹介されました

APNICブログで、ネットワークエンジニアではない方々向けのIPv6勉強会が紹介されました。

年内に開催できるかどうかはわかりませんが、もうちょっと内容を工夫しつつ、また、そのうちやりたいと思います。

続きを読む...

11月6日の「インターネットが壊れた」、Level3のleakで約90分間

米国時間の2017年11月6日(月)に、約90分間の大規模インターネット障害が発生しました。 Dyn blogによると、世界最大規模のTier 1インターネットプロバイダであるLevel 3がBGPの経路を「漏らした(leakした)」ことによって発生したとあります。 Dyn blogでは、今回の障害を紹介する記事中で、Level 3のことを「largest telecommunications network in the world(世界最大のテレコミュニケーションネットワーク」と表現しています。

Level 3がBGP leakを起こしてしまったことによって、意図しない経路に大量のトラフィックが流れて輻輳したことによって、各所で通信性能が著しく低下したようです。

続きを読む...

IPv6割り当て状況など(ARIN40での発表)

世界5つのRIR(Regional Internet Registy)によるNRO(Number Resource Organization)より、Internet Number Resource Report(2017年6月版)の発表が、ARIN 40で行われました。

続きを読む...

アカマイの新たなバックボーンネットワーク

RIPE 75のライトニングトークで、アカマイが、自社トラフィックを運ぶための専用バックボーンネットワークを構築していることを発表しました。

アカマイは、ユーザに近いところにCDN用のキャッシュサーバを置くために、世界各地に拠点を構築しています。 そういった拠点は、たとえば、ISPの中に構築されたりしています。 これまで、アカマイは拠点間の通信にはパブリックなインターネットを利用していました。 発表では、個々に孤立していたことを示すために各拠点を「島 (islands)」と表現しています(islandsという表現は、RFC等でも割と良く使われます)。

続きを読む...

ユーザの近くにある偽DNSサーバの話

RIPE 75で、DNSへの問い合わせ内容によって、DNSパケットが通過するネットワークが変わってしまうという怪しい挙動の報告がありました。

この発表では、DNSのパケットが途中ネットワークで解析され、そのDNSパケットに含まれる内容に応じて、すぐ近くにある偽のDNS応答が返ってくることがあるというものでした。 DNSパケットを解析するDPI(Deep Packet Inspection)装置+偽DNS応答機能といった感じでしょうか。

続きを読む...