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

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

色々な説明を省略して非常に雑な表現ではありますが、「IPv6を導入するとインターネットが速くなる」と日本国内で言われている状況があります。NTTフレッツ系のIPv4 PPPoE利用時に、NGNでの網終端での輻輳が発生している場合があり、IPv6 IPoEなどを利用することでIPv4 PPPoEを利用せずにインターネットとの通信が可能になるために、「IPv6の方が速い」という状況が発生するというものです。 IPv4 PPPoEを避けるために、DS-Liteなどを活用するといった話も一部界隈では盛り上がっています。 IPv4 PPPoEに関しては、総務省の研究会で議論が続けられてきましたが、10月27日に行われた「接続料の算定に関する研究会（第8回）」にて、「IPv4 PPPoEを使うと遅い」という状況が改善されるかも知れないと思える新しい動きがありました。 2017年10月27日(金)の10

ネットワーク技術者ではない方々向けIPv6セミナー2の発表資料です。 会場をご提供いただいた株式会社インターネットイニシアティブ様、ご発表いただいた中川さん、堂前さん、ご参加いただいた皆様、ありがとうございました！ 今回、アンケートを行ったのですが、ご意見として「質疑応答で出た質問の内容が難しすぎる」というものが数件ありました。 今回の企画を行うために3人で色々話しながら発表内容に関しては、気にしながら進めていましたが、質疑応答でいただく質問およびそれに対する回答がマニアックになり過ぎることに関しては、事前に気付けていませんでした。 もしかしたら、そのためにライトな質問をしにくい雰囲気ができてしまったのかも知れません。 以後、類似する企画をする場合には、もっと気軽にライトな質問をしやすい雰囲気作りを目指したいと思います。 IPv6最新動向 ～世界共通語で最適化が進むインターネット～ 日本イ

「ネットはゴミだらけ」ということが話題になることが増えてきました。 今も昔も、ネット上にあるコンテンツが玉石混淆であることは変わりません。 ある程度探したいものが明確であり、かつ、キーワードもわかっていれば、今も昔も変わらずにネット検索は可能です。 しかし、何かは確実に変わっているように思えます。 そうやって考えていると、そもそも、Webの世界で実現される夢として語られていた「群衆の叡智」というのは、あの当時の熱狂を背景として専門家がダンピング的に専門知識をネット上に掲載していたから実現したことであって、それが永遠に続くわけではないのかも知れないと思い始めました。 叡智を目指したはずが、営利へと主軸が変化していくなかで、2000年代の熱狂と夢から覚めつつある人々が「ネットはゴミだらけ」という感想を発している場合もありそうです。 さらに、「ゴミだらけ」になった背景であったり、「ゴミだらけ」だ

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

先週の金曜日、Googleが誤った経路をインターネットに流したことによって、大規模な通信障害が発生しました。 大きな影響を受けたのが日本のOCNとKDDIだったとされていますが、様々な事業者が影響を受けたようです。 ネットワーク障害 グーグルが設定誤りで謝罪 グーグルが謝罪　大規模ネット障害、装置の誤操作が原因 ニュース解説 - 米グーグルの設定ミス、なぜ日本の大規模ネット障害を引き起こしたのか？：ITpro BGP leak causing Internet outages in Japan and beyond 8月25日に発生した大規模通信障害をまとめてみた 今回の障害は、世界中の組織とBGP(Border Gateway Protocol)で繋がっている巨大なネットワークを持つ「Googleだからこそ」の事例と言えそうです。 ここでは、その理由を紹介します。 ネットワークのネットワ

インターネットそのものが「新しいもの」であったころは、インターネットそのものとともにITエンジニアが成長できました。未踏な領域に踏み込む冒険心をくすぐられるミッションが、そこら中に転がっていました。「できなくてツラい」と苦しみつつも、マゾ的に心を踊らせチャレンジする環境がありました。 インターネットを利用することが珍しいことではなくなり、インターネットを活用したビジネスを実現するためのエンジニアリングの分業化も進みました。それに伴い、IT系エンジニアに求められる技能が細分化しており、「必要に応じて全部やる」ことが求められない環境も非常に多くなっています。 そういった環境の変化もあり、「昔と違って何でもできる人は育ちにくくなっている」という感想を持っている人も結構多い印象です。私の周りで「ひとりで何でもできるんじゃないかと思えるほど守備範囲が広いエンジニア」と私が思う凄い人々は、インターネッ

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

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

Uberの技術ブログ「Uber Engineering」で、IPv6対応状況を公表しました。 Uberの内部ネットワークは急激に成長しており、このままでは2017年後半頃に10.0.0.0/8のプライベートIPv4アドレスが足りなくなってしまうこともあり、内部ネットワークで積極的にIPv6を活用することを目指していることが述べられています。 Uber Engineering Updates: Adopting the Next-Gen Internet Protocol: Deploying IPv6 for Uber Engineering 2017年4月の時点で、Uberの内部ネットワークでは10.0.0.0/8の50%以上を既に使ってしまっています。 買収した会社で利用されているIPv4アドレスが、既に運用されている機器に設定されているIPv4アドレスと重複するといった問題もありまし

さくらインターネットが、VPSの標準OSイメージでIPv6設定デフォルト無効化を発表しました。 さくらのVPS、標準OSイメージの仕様変更のご連絡 (IPv6設定デフォルト無効化) 発表では、以下のようにあります。 初期状態のおけるセキュリティ向上のため、以下のOSについてIPv6のデフォルト無効化を実施いたします。 有効化手順につきましては、ヘルプページをご用意しておりますのでそちらをご確認ください。 個人的には、IPv6が普及しつつある現状に対する一歩先を行く対応だと思いました。 流石だなぁと。 気づかずに放置されるIPv6セキュリティ 現段階では、IPv6環境でのセキュリティが放置されがちです。 IPv4環境とIPv6環境のセキュリティの差に関して述べられている発表が昨年ありました。 ITU/APNIC/MICT IPv6 Security Workshop : Securing t

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

先日、RFCの正規文書がplain-text ASCIIからXMLに変更された記事を書きましたが、plain-text ASCIIのデータが存在しないRFCも存在しているという無駄知識を先ほど獲得しました。 plain-text ASCIIのフォーマットが存在しないのは、1969年に発行された RFC 8 と RFC 9 です。 それぞれ、スキャンされた手書きデータがPDF化されたものだけが公開されています。 RFC 8 : ARPA Network Functional Specifications, May 1969 RFC 9 : Host Software, May 1969 このことに気がついたのは、この文章を書く30分ぐらい前です。 最近は、あまり時間を取ってRFCを読んだりしていなかったので、年末年始に時間を取ってゆっくりと色々なRFCでも読もうかと思って、RFCのデータをr

パケットのヘッダに記載された情報を読み取らなければ、ルータはパケットを転送できません。 日本の法律では、ISPなどの電気通信事業者がIPヘッダに記載された情報を読み取ることは通信の秘密を侵害すると解釈されています。その一方で、インターネットにおける通信を実現するためにはルータがIPヘッダに記載された情報を読み取ることは必要であり、違法であるとは思えません。 日本におけるインターネットと法律に関する話題に触れたことがない方にとっては、非常に奇妙な話に聞こえるかも知れません。しかし、このように「法益を侵害するが違法ではない」という解釈は、日本においてインターネットがどのように運用されているのかを理解するうえで非常に重要なポイントです。 日本国憲法(第21条)と電気通信事業法(第4条)は、通信の秘密を定めています。憲法における通信の秘密と、法律における通信の秘密の違いは、憲法が政府などの公権力に

インターネットで使われる各種仕様の多くは、RFCと呼ばれる文書として発行されています。 RFCは、「意見募集」や「意見を求む」といった意味を持つRequest For Commentsの略ですが、インターネットに関連する通信仕様の標準を示す文書の名称が、なぜ意見を募集するとなっているのでしょうか？ それには、初期のRFCが発行された時代背景があるのです。 RFCの文書番号は新しい文書とともに増加していくので、基本的に文書番号が小さいほど昔のものになります。 最初のRFCである、RFC 1は、1969年4月7日に発行されています。 多少余談になりますが、RFC 1は、「インターネット」という単語が生まれる前に発行されています。 「インターネット（internet）」という単語が初めて登場するRFCは、1974年に発行されたRFC 675です。 1973年に発行されたRFC 604とRFC 6

インターネットに関連するプロトコルなどを規定するRFC(Request For Comments)の正規文書のフォーマットが、これまでのplain-text ASCIIからXMLへと変わります。そのためのRFCが、RFC 7990 - RFC 7998として策定されました。 RFC 7990 RFC Format Framework RFC 7991 The "xml2rfc" Version 3 Vocabulary RFC 7992 HTML Format for RFCs RFC 7993 Cascading Style Sheets (CSS) Requirements for RFCs RFC 7994 Requirements for Plain-Text RFCs RFC 7995 PDF Format for RFCs RFC 7996 SVG Drawings for R

日経ビジネスオンラインの「DeNA転落の起点　買収と譲渡、2つの過ち」という記事に、以下のような文章がありました。 そもそも、ウェブは「コピペ」や「パクリ」で汚れていた。 ライターやブロガーが汗水を垂らして記事を書き、ネットに公開しても、そこから得られる収入は薄利。無報酬のブロガーも多い。キュレーション勢は、そうした記事を寄せ集め、検索エンジン最適化（SEO）という技法を用いて巨大なアクセスを生み、一次情報の発信者を尻目に収益化していった。ライターやブロガーが権利を訴えたところで、著作権法が定める「引用」の印籠をかざされるだけだ。 引用の範疇を超えた明らかな著作権法違反だとしても、キュレーション勢には「プロバイダ責任制限法」という第2の印籠がある。責任は記事の投稿者にあり、掲載したサイトは指摘があってから削除すれば責任を免れるといった法律だ。だが実際には削除申請の手続きが煩雑で、泣き寝入り

「特定電気通信役務提供者の損害賠償責任の制限及び発信者情報の開示に関する法律」(プロバイダ責任制限法)は、第一条にあるように、「特定電気通信による情報の流通によって権利の侵害があった場合について、特定電気通信役務提供者の損害賠償責任の制限」するものです。 しかし、すべての状況においてプロバイダの賠償責任が制限されるわけではありません。第三条には、以下のようにあります。 （損害賠償責任の制限） 第三条 　特定電気通信による情報の流通により他人の権利が侵害されたときは、当該特定電気通信の用に供される特定電気通信設備を用いる特定電気通信役務提供者（以下この項において「関係役務提供者」という。）は、これによって生じた損害については、権利を侵害した情報の不特定の者に対する送信を防止する措置を講ずることが技術的に可能な場合であって、次の各号のいずれかに該当するときでなければ、賠償の責めに任じない。ただ

IPv6の利用が世界中で増えつつあり、IETFなどのコミュニティではIPv4を廃止しようという動きが以前よりも活発化しています(参考)。 いまのところは、TCP/IPを解説するような文章を書くのであればIPv4を前提とした文章を書きつつ、IPv6の存在も紹介するという方法になりがちですが、今後の状況によっては、IPv4の紹介は「昔はそういうプロトコルがありました」と記述しつつ、IPv6を前提とした技術解説文を書く可能性も考えられます。 IPv6利用者数がIPv4利用者数を大きく超えるような状況になるのかならないのか、なるのであればそれがいつなのかに関しては、現時点では良くわかりません。ただ、「IPv6への移行」を目指して活動するネットワーク関係者の勢いは以前よりも強くなっている印象です。 例示用IPv6アドレスがわかりにくい 「IPv6への移行」を目指す動きが活発化しているものの、TCP/