ネットワークバイトオーダーの公式な参照先はエイプリルフール:Geekなぺーじ
インターネットは、その場しのぎの拡張を繰り返して迷路のようになってしまった古い旅館のような側面があります。 インターネットは、インターネットプロトコル(Internet Protocol/IP)を使った通信によって成り立つ世界規模のネットワークですが、そこで使われる非常に多くのプロトコルが「ネットワークバイトオーダー(network byte order)」というデータ転送の順番を採用しています。 ネットワークバイトオーダーはビッグエンディアンという大きな桁を表すビットを含むバイトから最初に並べる方式を示す用語で、TCP/IPに関連する非常に多く(もしくは大半)のプロトコルが、ネットワークバイトオーダーを採用しています。 しかし、ネットワークバイトオーダーがTCP/IPの標準であることを示したRFCは存在しません。 そもそも、ネットワークバイトオーダーを明確に定義したRFCも存在しません。
11月6日の「インターネットが壊れた」、Level3のleakで約90分間:Geekなぺーじ
米国時間の2017年11月6日(月)に、約90分間の大規模インターネット障害が発生しました。 Dyn blogによると、世界最大規模のTier 1インターネットプロバイダであるLevel 3がBGPの経路を「漏らした(leakした)」ことによって発生したとあります。 Dyn blogでは、今回の障害を紹介する記事中で、Level 3のことを「largest telecommunications network in the world(世界最大のテレコミュニケーションネットワーク」と表現しています。 DYN blog: Widespread impact caused by Level 3 BGP route leak WIRED: How a Tiny Error Shut Off the Internet for Parts of the US Level 3がBGP leakを起こし
アカマイの新たなバックボーンネットワーク:Geekなぺーじ
RIPE 75のライトニングトークで、アカマイが、自社トラフィックを運ぶための専用バックボーンネットワークを構築していることを発表しました。 Christian Kaufmann - ICN Akamai 発表資料(PDF) アカマイは、ユーザに近いところにCDN用のキャッシュサーバを置くために、世界各地に拠点を構築しています。 そういった拠点は、たとえば、ISPの中に構築されたりしています。 これまで、アカマイは拠点間の通信にはパブリックなインターネットを利用していました。 発表では、個々に孤立していたことを示すために各拠点を「島 (islands)」と表現しています(islandsという表現は、RFC等でも割と良く使われます)。 世界中の様々なAS内に拠点を築き、その拠点間トラフィックもパブリックなインターネットを利用していたことは、アカマイの非常に大きな特徴であったとも言えます。 し
「ネットはゴミだらけ」を考える:Geekなぺーじ
「ネットはゴミだらけ」ということが話題になることが増えてきました。 今も昔も、ネット上にあるコンテンツが玉石混淆であることは変わりません。 ある程度探したいものが明確であり、かつ、キーワードもわかっていれば、今も昔も変わらずにネット検索は可能です。 しかし、何かは確実に変わっているように思えます。 そうやって考えていると、そもそも、Webの世界で実現される夢として語られていた「群衆の叡智」というのは、あの当時の熱狂を背景として専門家がダンピング的に専門知識をネット上に掲載していたから実現したことであって、それが永遠に続くわけではないのかも知れないと思い始めました。 叡智を目指したはずが、営利へと主軸が変化していくなかで、2000年代の熱狂と夢から覚めつつある人々が「ネットはゴミだらけ」という感想を発している場合もありそうです。 さらに、「ゴミだらけ」になった背景であったり、「ゴミだらけ」だ
Geekなぺーじ : 2009年2月17日 世界的インターネット経路障害解説
2009年2月17日に発生した世界的なインターネット経路障害に関しての解説、及びその後調べたことです。（参考：インターネットが壊れました）。 BGPとは何かに関しての解説も書いたので、インターネット通信技術そのものに関して知りたい方はそちらもご覧下さい。 何が発生していたのか？ チェコのプロバイダが非常に長いAS pathを流してしまい、その長いAS pathを受け取ったルータがBGP peerを切れたり上げたりを繰り返しました。 BGPのpeerが切れた次の瞬間に、また接続し直してpeerが復活し、そしてまた問題のAS path情報を受け取って切れるという状況を繰り返してしまったようです。 BGP peerが切れるのは、パケットがISP間で転送されなくなるという事なので、世界中で「到達出来ない場所」が発生しました。 この障害は約1時間弱続きました。 問題をトリガーしたチェコのプロバイダと
Twitter Loves Japan:Geekなぺーじ
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では、日本が最も大
なぜIPv6とIPv4の名前解決は別々に行なわれるのか？:Geekなぺーじ
www.example.comなどの「名前」に対応するIPアドレスをDNSサーバに問い合わせるとき、IPv4とIPv6に関する名前解決を単一の問い合わせで行うことはできません。そのため、DNSサーバに対して、IPv4に関する問い合わせと、IPv6に関する問い合わせを、別々に2度行う必要があります。 これは、DNSサーバに対しての問い合わせが単一のレコードに対してしか行えないためです。 Aレコード（IPv4アドレス）の問い合わせと、AAAAレコード（IPv6アドレス）の問い合わせは、それぞれ別々のレコードに対する問い合わせなので、両方を同時には行えないのです。 ただし、「IPv4とIPv6に関するDNSサーバへの問い合わせは別々に行わなければならない」というのは、事実上の話であって、「仕様上そうなっている」と言い切れるのかどうかは微妙かも知れません。 DNSに関するRFCは、悪名高いRFC
ざっくり詳解 - NAT64とDNS64:Geekなぺーじ
2016年6月から、iOSアプリの審査基準としてIPv4に依存するコードの禁止が追加され、IPv6対応がiOSアプリの義務なったことからも、IPv6に関する知識が必須となったエンジニアも多いのではないかと思います(Appleの発表)。 Appleのサイトでは、IPv4アドレス在庫枯渇の発生とともに、ユーザに対してIPv6のみによるインターネット接続性を提供するNAT64(「なっとろくよん」です。ろくじゅうよんではないです。)とDNS64という技術が、エンタープライズ網や携帯電話網で採用されることが増えているとあります。 Apple Developer: Supporting IPv6 DNS64/NAT64 Networks iOSアプリ開発者は、このNAT64とDNS64環境でもアプリが正しく動作することを求められています。 Appleのサイトでは、NAT64とDNS64はOS X 10
RFCの正規文書がXMLに:Geekなぺーじ
インターネットに関連するプロトコルなどを規定する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
BGPルータの512K問題について:Geekなぺーじ
インターネットでの通信障害を発生させた「BGPルータの512K問題」が一部界隈で話題です。今回は、それがどういった問題で、それが発生する背景がどのようなものであるかを紹介します。 インターネットの仕組みとBGP インターネットは、AS(Autonomous System/自律システム)という単位で運営されていますが、AS同士はBGPという経路をやり取りするプロトコルを利用して互いに接続することで成り立っています。BGPは、伝言ゲームのように「私の隣に○○というASの××というネットワークがある」という情報を伝えて行くものです。世界中のASが伝言ゲームに参加することによって、世界中のASへの到達方法を共有しているのがインターネットなのです。 BGPによって集められた、世界中のASに含まれるネットワークへの経路を全て(もしくは全てと推測される規模の)経路情報は「フルルート(Full Route
DNSキャッシュポイズニングの基本と重要な対策:Geekなぺーじ
2014年4月15日に公開されたJPRSの緊急注意喚起に続き、中京大学の鈴木常彦教授によるDNSキャッシュポイズニングに関する技術情報が公開されました。 今回公開された技術情報に書かれている内容には、DNSの本質につながるさまざまな要素が関係しており一回で書ききれるものではなく、また、書いている側（私）も、それぞれの要素技術について勉強しながら理解しつつ進めていかないと混乱してしまうということが良くわかったため、これから数回に分けて徐々に書いて行くことにしました。 ということで、今回はまず、そもそもDNSキャッシュポイズニングとは何かということと、JPRSの注意喚起に書かれているUDPソースポート番号のランダム化（ソースポートランダマイゼーション）の概要、そしてなぜそれが重要なのかという点について解説します。 DNSキャッシュポイズニングとは インターネットで通信を行うとき、各機器同士は通
強烈なDNSキャッシュポイズニング手法が公開される:Geekなぺーじ
本日、JPRSが緊急の注意喚起を公表しました。 緊急）キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について（2014年4月15日公開）- 問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨 それに対して、2月中旬に脆弱性を発見してJPRSへと報告していた鈴木氏(脆弱性は前野氏との共同発見)が、JPRSの注意喚起では「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」として、以下の情報を公開しています。 開いたパンドラの箱 - 長年放置されてきたDNSの恐るべき欠陥が明らかに キャッシュポイズニングの開いたパンドラの箱 キャッシュポイズニングの開いたパンドラの箱 - 2 - 本来であれば、より上位からの正規の回答が優先されなければならないはずなのに、下位側が優先される仕様になっているので、偽装されたデータが優先されてしまう
スノーデン事件の裏で起きていたSSL秘密鍵を巡る戦い:Geekなぺーじ
今月7日から9日にアリゾナ州で開催されたNANOG 59で、Ladar Levison氏がFBIにサービス全体のSSL秘密鍵を要求された話が公開されていました。 Ladar Levison氏が運営していた、Lavabitという電子メールサービスはスノーデン事件に関連して突如8月8日に閉鎖されています。 閉鎖時には詳細が書かれておらず、様々な憶測が語られていましたが、世界中から多数のネットワークエンジニアが集まるNANOGで、その一部始終が語られました。 この発表は、NANOG 59が開始される前の週に、裁判所が調査対象の氏名以外を機密解除したことによって実現しています。 インターネット上で提供されているサービス事業者にSSL秘密鍵を提出させ、かつ、その事実の公表が違法行為となるようにされてしまっている一方で、こういった内容を公的に語れるように裁判所で戦って、実際にそれを勝ち取るというのは凄
国際規則でインターネットを規制する試み - WCIT/ITRs:Geekなぺーじ
国際規則によってインターネットを規制しようという動きがあります。 最近いきなり湧いて来た話ではありませんし、議論の過程の一部などの様々な情報も公開されています。 また、議論に参加している各国間での調整によって大枠だけの内容になる可能性も高いのではないかと一部で言われているので、陰謀論的に解釈すべき話ではないと思います。 とはいえ、これまでとは違い、インターネットそのものに関する国際的な合意文書化策定が試みられています。 追記 WCIT-12の結果については以下のインタビュー記事をご覧下さい。 WCIT-12 総務省インタビュー (2013年1月) WCITでITRsが変更される話 International Telecommunication Regulations(ITRs/国際電気通信規則)は、国際的な電話網における規制を規定した通信の国際規則です。 ITRsは、1988年にITU(I
自炊って結構バランスいいかも(少なくとも現時点では):Geekなぺーじ
電子出版や自炊や紙に関して話題になっていますが、私個人としては「現時点の日本では自炊以外の選択肢が事実上ないんじゃないか？」という感想を持っていますし、「自炊は面倒だけど実は結構バランスがいい」とも考えています。 私は自分の本の電子書籍版を出していますし、ブログを英語化してAmazon Kindle Direct Publishingで出版してみたり、日本で発売された剣道雑誌の記事を英語に翻訳したうえで出版社と共同で電子書籍化して世界に向けて販売する実験を行ったりしています。 電子書籍は検索が行えたり場所を取らなかったりと便利です。 日本に居ながらにして世界中の電子書籍を欲しいと思った瞬間に入手可能であり、専門書を購入するために特定の書店にいかなくても済むという便利さもあります。 販売側から見ると、紙の書籍では実現し得ない販路(海外展開など)を実現できます。 著者から見ると、出版社を通さず
なぜ「DNSの浸透」は問題視されるのか:Geekなぺーじ
「DNSの浸透」という表現が結構よく使われています。 DNSに設定された情報を更新したけれど、その結果がなかなか反映されずに誰かに相談すると「DNSの浸透には時間がかかります」と説明されて納得してしまうという事例が多いようです。 しかし、うまく準備を行えば、実際の切り替え処理は、いつ完了するのかが不明な「DNSの浸透」を待つのではなく、事前に計画した時間通りに完了させることが可能です。 さらに、本来であればDNS情報の設定者(ゾーン情報の設定者)は、いつまでに世界中のキャッシュが更新されるかを知ることができる環境にあり、それ以降も更新がされていなければ「何かがおかしい」とわかるはずです。 DNSにおける設定内容(DNSのリソースレコード)には、その情報をキャッシュとして保持し続けても良い期間であるTTL(Time To Live)という要素がありますが、TTLはDNS情報設定者が自分で設定
Geekなぺーじ : Amazon Kindle Storeで電子出版してみた
Amazon Kindle Storeで英語文章の電子出版をしてみました。 内容としては、日本語で書いた「人生の全てはTCP/IPに学んだ」というブログ記事を英訳したものであり、非常に短いものです。 All I Really Need to Know I Learned from TCP/IP [Kindle Edition] 価格は99セント、1ドル82円だと思うと約82円です(日本から買う場合は+2ドルの価格になります)。 本当は無料でもよかったのですがAmazon DTPを使う場合、0.99ドルが最安値でした。 ブログ記事単体に対して、この価格が高いと思うか安いと思うかは賛否両論がありそうです。 よっちゃんいかが何個買えるかとか、チロルチョコだといくつかとか、いやいやスタバのコーヒーの何分の一だよとか、何と比較するかで感想も変わるでしょう。 電子出版の作業自体は非常に簡単でした。 A
livedoor Readerパーフェクトガイドが生み出した格差:Geekなぺーじ
7月23日に「livedoor Readerパーフェクトガイド」が公開されました。 非常に読みやすく、良く解説されているドキュメントです。 このドキュメントが公開されてから非常に興味深い現象が発生しました。 登録数ランキング300位に入っているサイトと入っていないサイトでブログ格差が発生しています。 原因はlivedoor Readerパーフェクトガイド中に書いてある以下の文章だと思われます。 II. 登録数ランキングの上位を一括登録 「livedoor Reader」に登録されているフィードのうち、登録数の上位300件をまとめているOPMLを“全部”登録しましょう。Webディレクターであればどれも押さえておくべきフィードばかりですので、躊躇せずに“全部”登録してください（不要なフィードはあとから削除できます）。 この文章に従った人が多かったと思われるため登録数ランキングに入っているフィー
Geekなぺーじ：選択肢を減らすことの重要性
Google TechTalksでBarry Schwartz博士による講演が公開されていました。 「The Paradox of Choice - Why More Is Less」というタイトルでした。 最初は、UNIXコマンドのmoreがlessよりも劣っている理由の事だと思って見始めましたが、そうではありませんでした。 何でも選べてベストじゃないと満足しないというのは、アメリカ人っぽい気もしましたが、かなり面白かったです。 ユーザビリティと機能の問題は良くある問題ですが、お店で展示されている商品の種類を減らした方が売り上げが上昇する話などが新鮮でした。 以下に要約してみました。 ここでは書いていない部分も多いので、詳細はビデオをご覧下さい。 字幕も入っていますし、ゆっくりと話してくれる人なので非常に見やすいと思います。 ただ、スライド(PPT?)が見られないので、何故観客が笑ってい
オープンソースコミュニティ運営方法:Geekなぺーじ
Google Videoに「 How Open Source Projects Survive Poisonous People (And You Can Too)」という54分のビデオがありました。 Subversionの開発者達が、オープンソースプロジェクトを運営上の注意点を解説していました。 面白かったです。 ボランティア開発者の集合体によって実現しているオープンソースプロジェクトを運営する方法を解説するという題目ですが、 最後のオチでは、「これはオープンソースに限らない」と言っていました。 確かに、一般的な開発でも参考になる部分は多いと思いました。 また、掲示板やブログのコメント欄でも一部は適用できそうなノウハウであると思いました。 要約してみましたが、結構いい加減で間違いなどがあると思うので詳細はビデオをご覧下さい。 「Poisonous People」は「有害な人」と訳してみま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
