「プロフェッショナルIPv6 第2版」を無料配布します。2018年7月にプロフェッショナルIPv6初版を発売＆無償配布開始しました(すごいIPv6本を無料配布)。初版発売開始から3年、さらにパワーアップした「プロフェッショナルIPv6 第2版」がついに完成しました！ 本書を企画して、少しずつ文章を書き溜めはじめた2011年から10年近くかけて完成した488ページにおよぶ「プロフェッショナルIPv6 第2版」をお楽しみください。 プロフェッショナルIPv6第2版の構成 プロフェッショナルIPv6第2版は5部構成になっています。 第1部は「インターネットとIPv6の概要」というタイトルで、IPv6の視点からインターネット自体の仕組みを復習し、そのうえで、詳細の説明に入る前に把握しておくべきIPv6の概要として、次のような事項を解説しています。 従来のIPv4アドレスとは大きく異なるIPv6アド

MACアドレスは、原則として、一意に割り当てられるものです。 ネットワークインターフェースごとに、ひとつずつユニークな値をベンダーが付けるものとされています。 ただ、これは、あくまで「原則として」であって、実際は、MACアドレスが重複することもあります。 IPv6に関連するいくつかのRFCで、MACアドレスの重複への言及があります。 この記事では、MACアドレスの重複とIPv6アドレスの自動生成という、わりと限定された視点ではありますが、MACアドレスが一意とは限らない、という話を紹介します。 なお、この記事のタイトルである「MACアドレスの再利用は、みんなが思っているよりもはるかに一般的」は、RFC 7217に書かれている一文の日本語訳です。 MACアドレスの重複とIPv6アドレス生成の仕様 MACアドレスがIPv6アドレスの自動生成で使われる場合があります。 IPv6アドレス体系のRF

3.0.0.0/8がAmazonに割り当てされたIPv4アドレスに変わっています(via Hacker News)。 表面的に見えているのは、IPv4アドレスの移転ですが、恐らく、IPv4アドレス売買によってAmazonへと登録が移転されたものだと思われます。 このIPv4アドレス移転により、AmazonはIPv4アドレス空間全体の1/256を新たに使えるようになります。 3.0.0.0/8は、以前は、GE(General Electric Company)に割り当てられていました。 しかし、最近1年ほどで4回に分けてAmazonへと3.0.0.0/8が移転されています。 ARINのwhoisを見ると、3.0.0.0/8は、3.0.0.0/9と3.128.0.0/9に分けれて登録されています。 両方とも、組織は「Amazon Technologies Inc. (AT-88-Z) 」とあり

個人的には、拙著「プロフェッショナルIPv6」は、世界で最も詳しくて読みやすいIPv6解説本だと考えています。 450ページを超えるコンテンツを全部タダで読めるというのも大きな特徴です。 このような「プロフェッショナルIPv6」の企画は、ラムダノート社でしか実現できなかったと私は考えています。 いまでこそ、ラムダノート社は複数のIT技術書を出版する出版社ですが、IPv6本の企画が開始した段階では、ラムダノート社は、まだ一冊も出していない状態でした。 それでも、私はラムダノート社でIPv6本を出したかったのです。 鹿野さんが経緯を紹介している通り、クラウドファンディングでIPv6本を作ろうと考えて、鹿野さんに声をかけました。 k16's note: 技術書をクラウドファンディングで出版してみた 鹿野さんに声をかけた理由は主に2つです。 ひとつめは、クラウドファンディングで書籍を作り、電子版を

DNSのメッセージをHTTPSの上に乗せようという標準化活動がIETFで開始されました。 IETFのDOH(DNS Over HTTPS)ワーキンググループです。 DOHワーキンググループは、Applications and Real-timeのエリアです。 先月開催されたIETF 100(2017年11月)にて、DOHワーキンググループの第1回ミーティングが行われました。 そこでは、ワーキンググループが対象としている範囲や、現在あるインターネットドラフトに関しての議論が行われました。 draft-ietf-doh-dns-over-https : DNS Queries over HTTPS 現段階におけるインターネットドラフトは、以下のような内容が最初に書かれています。 DNS queries sometimes experience problems with end to end

気がつくと、IT技術を解説する文章を10年以上書き続けています。 ブログを書くときには、基本的に自分の興味があることを書くことが多いので、そのときどきによってテーマが変わることも多いです。 私は、技術理解の流れとして以下のようなものがあると感じています。 興味を持つ 少し調べて何となくわかった気になる もうちょっと調べてわかってない部分を発見する もっと調べて理解を深める 2と3と4を永遠に繰り返す 「わかってない」であったり、「知らない」という事実に気がついてからが、新しいループのスタートなのです。 何かを「理解している」と思い込みたい傲慢な自分に気がつけるタイミングが発生しないと、新しい何かを調べ始めることが難しい気もしていると同時に、油断すると傲慢になっていく怖さがあります。 このように、自分の無知に気がつく喜びと苦悩の繰り返しで、何かを学んでいくというのがパターンとして多いのではな

オーム社が電子書籍直販サービスを終了するというお知らせがでていました。 同社では、マスタリングTCP/IP RTP編(2004年)、インターネットのカタチ(2011年)、マスタリングTCP/IP OpenFlow編(2013年)の3冊で関わらせていただいたこともあり、今回廃止される電子書籍直販サービスで拙著も販売されていました。 オーム社eBook Storeサービス終了のお知らせ 電子書籍直販サービスが終わるということは、ネット上で話題になっていることで知りましたが、「そのうちこうなるだろうと思っていた」ということが起きました。 10月29日に「運営スタッフ退任のお知らせ」というお知らせが出ており、eBook Store企画運営担当の森田さんが「運営スタッフ退任」とあります。 そのお知らせからは社内異動のようにも読めますが、実際は運営スタッフ退任だけではなく、10月末で退職されたようです

ここ数年で上書きによる廃止になったIPv6関連RFCをまとめてみました。 他にもあると思いますが、IPv6本を書く過程でまとめたものを列挙しています。 RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification obsoletes RFC 2460 RFC 8201 : Path MTU Discovery for IP version 6 obsojetes RFC 1981 RFC 6434 : IPv6 Node Requirements obsoletes RFC 4294 RFC 8106 : IPv6 Router Advertisement Options for DNS Configuration obsoletes RFC 6106 RFC 8096 : The IPv6-Specific MIB Module

ICANNが、ルートゾーンに含まれる鍵(KSK/Key Signing Key)更新の予定を先送りすることを発表しました。 当初、2017年10月11日に鍵の署名が開始される予定でしたが、調査の結果、非常に多くのISPやネットワークオペレータの準備ができていないことがわかり、ロールオーバーの延期が決定したようです。 ICANN: KSK Rollover Postponed いまのところ、いつにKSKロールオーバーが開始されるのかは未定ですが、2018年第一四半期にできれば嬉しいと考えているようです。 KSKロールオーバーに関する参考リンク JPNICの解説 鈴木常彦先生の資料: DNSSECの仕組みとKSKロールオーバへの対応(PDF)

NANOG 68のDesperately Seeking Defaultという発表にて、APNICのGeoff Huston氏が、いまのインターネットはかつてエンジニア達が目指したものとは違うものになってしまったと表現しています。 この発表が行われたNANOG 68(2016年10月17日)は、ネットワークエンジニアが集まるイベントであるため、ここで言う「我々」というのは、主にネットワークエンジニアを指しています。 IETFでもそういう雰囲気があるのですが、「我々がインターネットを作っている」という自負がある人々が会場内に多いです。そういった空気感がある「場」での発表です。 発表そのものは、インターネットを運用する際に見える「経路」は組織によって異なり、インターネットでは互いに通信ができないネットワークがあるという話です。 「Default」の経路として提供されるものが異なり、インターネッ

2017年8月25日の大規模インターネット障害の続きです。 オレゴン大学がRouteViewsというサイトで、BGPフルルート情報を公開しています。 今回、Googleがリークしてしまった経路情報をRouteViewsで確認することができます。 http://archive.routeviews.org/bgpdata/2017.08/UPDATES/updates.20170825.0315.bz2 RouteViewsで公開されているデータは、MRTというフォーマット(RFC 6396参照)で保存されているので、何らかのツールで解析する必要があります。 今回は、RIPE NCCが管理しているbgpdumpというツールを使いました。 RouteViewsのデータから、Googleによる誤設定データを最初に観測できるのは、3時17分37秒(UTC)のところです。 Verizon(AS 70

「スタートアップベンチャーはスーパーエンジニアを求めるけどエンジニア界隈と起業家界隈で想像しているスーパーエンジニアの定義が違う件」という記事が話題です。 その中で、「「ひとりで何でもできるエンジニア」は存在しないと思った方が良い」」として、以下のように書かれています。 「ひとりで何でもできるエンジニア」は存在しないと思った方が良い」 起業家の方が知らない側面として 現在バリバリ活躍しているエンジニアのほとんどが得意領域を持っていて それ以外の分野については出来る人であっても「平均点以上」ぐらいの活躍しか出来ないということです。 そして優秀なエンジニアの方はそのことをよくわかっています。 たまに化け物みたいな化け物がいて物理からインフラからアプリケーションからUI/UX ネイティブアプリ開発からwebマーケティングに資産管理まで全部出来ちゃう人もいますが その人を望む事は「年収1000万の

昨日、ネットワークエンジニアではない方々向けのIPv6勉強会を行ってきました。 会場をご提供いただいた株式会社インターネットイニシアティブ様、ありがとうございました！ 発表資料をSpeaker Deckで公開しました。 当日の参加者は約150名でした。一部、私よりも詳しいネットワークエンジニアも参加していましたが、全くIPv6に関しての前提知識がないと思われる方々や、自分でIPv6 IPoEを設定してみたというかた、これから実際に手を動かしてみたいというかた、仕事でこれから必要になりそうなので調べ始めたというかたなど、様々な方々が参加されていたようです。 「ネットワークエンジニアではない方々向け」という内容ではあるものの、「どういう説明をするのか見てみたい」というネットワークエンジニアの方々もいたことや、見たことがあるTwitterアイコンなどがconnpassに表示されていたので、顔見知

今年1月に開催されたJANOG 39にて、LINE Corporationの三枝氏が「LINEサービスを運用して見えてきた課題」というタイトルで発表を行っています。 その中で、「月間平均Response Timeとの乖離」というタイトルで、以下のスライドがあります。 この図では、日本、タイ、台湾のレスポンスタイムが示されていますが、「日本は月末にResponse Timeが悪化していく傾向がある」とされています。 Twitter、Spotify、JPNAP(インターネットマルチフィード)での「ギガが減る」を昨日から紹介していますが、LINEでも同様の現象を観測しています。 やはり日本のインターネットトラフィックの最近のトレンドとして、月末に向けて通信品質が悪化するという傾向があるようです。 参考 Twitter Loves Japan Spotifyの日本インフラ 日本のインターネットも月

BBIX BGP Meeting 2017 Summerにて、TwitterのTim Hoffman氏が「Twitter loves Japan」という発表を行いました。 そこでは、Twitterの行っている独自CDNの紹介、日本におけるユーザトラフィックの特徴などが紹介などもされていました。発表そのものは、日本国内のASに対してBGPでのピアリングを呼びかけるというものです。 一部ネット界隈では「ギガが減る」という表現がホットな話題ですが、BBIX BGP meetingにおけるTwitter社とSpotify社による発表されたユーザトラフィックにおいても、そういった状況が示されているのが個人的には興味深かったです。Spotify日本進出の発表に関しては別途記事を書く予定です。 日本はTwitterを非常に多く使っている Tim Hoffman氏によると、Twitterでは、日本が最も大

www.example.comなどの「名前」に対応するIPアドレスをDNSサーバに問い合わせるとき、IPv4とIPv6に関する名前解決を単一の問い合わせで行うことはできません。そのため、DNSサーバに対して、IPv4に関する問い合わせと、IPv6に関する問い合わせを、別々に2度行う必要があります。 これは、DNSサーバに対しての問い合わせが単一のレコードに対してしか行えないためです。 Aレコード（IPv4アドレス）の問い合わせと、AAAAレコード（IPv6アドレス）の問い合わせは、それぞれ別々のレコードに対する問い合わせなので、両方を同時には行えないのです。 ただし、「IPv4とIPv6に関するDNSサーバへの問い合わせは別々に行わなければならない」というのは、事実上の話であって、「仕様上そうなっている」と言い切れるのかどうかは微妙かも知れません。 DNSに関するRFCは、悪名高いRFC

おかげさまで、ご支援いただいている金額が256万円に到達し、電子版を無償配布するIPv6本のmakuakeでのクラウドファンディングプロジェクトが「Success」になりました！ これまでに支援してくださった皆さま、本当にありがとうございます。 すごい技術書を一緒に作ろう。あきみち＋ラムダノート『プロフェッショナルIPv6』 この企画は、昨年秋ぐらいから準備をしていました。プロジェクト開始前は、3ヶ月で本当に達成できるのかが不安でしたが、予想以上のペースで支援が集まり、プロジェクト開始後10日で目標金額達成となりました。関係者一同、感謝すると同時に感激しています。 今回、makuakeでのプロジェクトとしては「Success」となっているものの、クラウドファンディングのプロジェクトは残り73日間続けます。 当初目標金額に達したことで、制作そのものに最低限必要だと見積もっていた分は、何とか用

IPv6アドレスには、128ビットの中にIPv4アドレスを含むものがあります。 IPv4アドレスを含むIPv6アドレスを表記するとき、通常のIPv6アドレス表記だけではなく、最後の32ビット部分をドット「.」で区切ったIPv4アドレス表記で記載することもできます。 先ほど公開したNAT64+DNS64記事で紹介している「64:ff9b::192.0.2.33」というのも、IPv4アドレスを含むIPv6アドレスの表記方法です。 このようなIPv4アドレスを含むIPv6アドレスをテキストで表記する方法に関しては、RFC 5952(A Recommendation for IPv6 Address Text Representation)の5章でも解説されています。 IPv4射影アドレス(IPv4-Mapped IPv6 Address) IPv6アドレスの基本仕様(RFC 4291)には、IP

IPv6の大きな特徴として、IPアドレスの自動設定機能がIPv6の根本的な仕組みとして組み込まれている点があげられます。 IPv4が誕生した当初はIPアドレスの自動設定のための手法が存在していませんでした。 IPアドレス自動設定のためのDHCP(Dynamic Host Configuration Protocol)を規定したRFC 1531が発行されたのは1993年です。 IPv4におけるIPアドレスの自動設定は、後から作られたDHCPを使うというものでしたが、IPv6では最初からIPアドレス自動設定が議論されています。 ただし、その議論の結果生み出されたものが非常にややこしくなっています。 IPv6には最初からIPアドレス自動機能が備わっているものの、IPv6用のDHCPであるDHCPv6も同時に存在しており、非常にややこしいのです。 この文章を執筆している時点では、IPv6におけるI

世界中のほとんどの人々は気にしていませんが、米国時間の2016年10月1日(土曜日)、インターネットが大きく変わりました。これまで米国政府が保持していたインターネットの重要資源に対する監督権限を手放したのです。 JPNIC: 米国政府がインターネット重要資源の監督権限を手放しました JPNIC News & Views vol.1439【臨時号】2016.10.3 NTIA: Statement of Assistant Secretary Strickling on IANA functions contract インターネットそのものは、世界中の多くの組織が分散しつつも協調することで成り立っています。 しかし、世界中のみんなが単一の「共通意識」を持って運用する必要がある、IPアドレスやポート番号などの番号資源、ドメイン名、プロトコルパラメータの3つに関しては、IANA（Internet