IPv4アドレスを含むIPv6アドレス表記:Geekなぺーじ
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
ソフトバンク大規模通信障害の原因:Geekなぺーじ
2018年12月6日、ソフトバンクのネットワークにおいて、4時間25分にわたり約3060万回線の利用者に影響を及ぼす通信障害が発生しました。 ソフトバンクおよびワイモバイルの4G(LTE)携帯電話サービス、「おうちのでんわ」、Softbank Air、3Gサービスなどが影響を受けました。 この障害は、EricssonのMME内部にハードコーディングされた証明書が期限切れになったため、SGSN-MME(Serving GPRS Support Nodex - Mobility Management Entity)が再起動を繰り返してしまったのが原因です。 ただ、証明書が期限切れになることで、なぜ大規模な通信障害に繋がってしまうのかが良くわかりませんでした。 どのような設計をしたら、証明書が期限切れになったことで通信機器が再起動を繰り返すような状況になるのか、昨年段階では、いまいち理解できなか
ネットワークバイトオーダーの公式な参照先はエイプリルフール:Geekなぺーじ
インターネットは、その場しのぎの拡張を繰り返して迷路のようになってしまった古い旅館のような側面があります。 インターネットは、インターネットプロトコル(Internet Protocol/IP)を使った通信によって成り立つ世界規模のネットワークですが、そこで使われる非常に多くのプロトコルが「ネットワークバイトオーダー(network byte order)」というデータ転送の順番を採用しています。 ネットワークバイトオーダーはビッグエンディアンという大きな桁を表すビットを含むバイトから最初に並べる方式を示す用語で、TCP/IPに関連する非常に多く(もしくは大半)のプロトコルが、ネットワークバイトオーダーを採用しています。 しかし、ネットワークバイトオーダーがTCP/IPの標準であることを示したRFCは存在しません。 そもそも、ネットワークバイトオーダーを明確に定義したRFCも存在しません。
オーム社電子書籍直販サービス終了に関して:Geekなぺーじ
オーム社が電子書籍直販サービスを終了するというお知らせがでていました。 同社では、マスタリングTCP/IP RTP編(2004年)、インターネットのカタチ(2011年)、マスタリングTCP/IP OpenFlow編(2013年)の3冊で関わらせていただいたこともあり、今回廃止される電子書籍直販サービスで拙著も販売されていました。 オーム社eBook Storeサービス終了のお知らせ 電子書籍直販サービスが終わるということは、ネット上で話題になっていることで知りましたが、「そのうちこうなるだろうと思っていた」ということが起きました。 10月29日に「運営スタッフ退任のお知らせ」というお知らせが出ており、eBook Store企画運営担当の森田さんが「運営スタッフ退任」とあります。 そのお知らせからは社内異動のようにも読めますが、実際は運営スタッフ退任だけではなく、10月末で退職されたようです
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を起こし
RFCは、なぜ「意見募集」という名前だったのか？:Geekなぺーじ
インターネットで使われる各種仕様の多くは、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の正規文書が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
ルータやスイッチは日本の法律上、通信の秘密を侵害するが違法ではない:Geekなぺーじ
パケットのヘッダに記載された情報を読み取らなければ、ルータはパケットを転送できません。 日本の法律では、ISPなどの電気通信事業者がIPヘッダに記載された情報を読み取ることは通信の秘密を侵害すると解釈されています。その一方で、インターネットにおける通信を実現するためにはルータがIPヘッダに記載された情報を読み取ることは必要であり、違法であるとは思えません。 日本におけるインターネットと法律に関する話題に触れたことがない方にとっては、非常に奇妙な話に聞こえるかも知れません。しかし、このように「法益を侵害するが違法ではない」という解釈は、日本においてインターネットがどのように運用されているのかを理解するうえで非常に重要なポイントです。 日本国憲法(第21条)と電気通信事業法(第4条)は、通信の秘密を定めています。憲法における通信の秘密と、法律における通信の秘密の違いは、憲法が政府などの公権力に
金と力のインターネット:Geekなぺーじ
「ユーザがインターネットサービスプロバイダにお金を払う」という部分をイメージできる方々は多いと思いますが、インターネットサービスプロバイダは、どこにお金を払ってインターネットとつながっているのでしょうか？ 普段インターネットを利用していると、忘れがちですがインターネットそのものも誰かが運用しています。そして、その運用にはお金がかかりますが、誰がどのように経費負担をするのかに関しては「金と力」が影響します。金と力のバランスによって、インターネットは日々形を変えているのです。 「ネットワークのネットワーク」であるインターネット インターネットの前身であるARPANETが運用開始されたのは1969年でした。その後、ARPA（高等研究計画局）のロバート・カーン氏と、スタンフォード大学のヴィント・サーフ氏らによって現在のインターネットの基礎となる研究が開始されたのが1973年です。RFC 675は、
世界的なインターネット障害が発生:Geekなぺーじ
6月20日に世界的な通信障害が発生しました。先日、このブログの「金と力のインターネット」という記事で「超巨大バックボーンネットワークを持つ組織同士(ティアワン)」を紹介しましたが、世界第2位の規模(参考)を持つティアワンであるスウェーデンのTeliaが通信障害を起こしたのです。 TheRegisterの記事によると、Teliaの通信障害の原因をエンジニアによるミスであるようだと記載しています。ヨーロッパ中のトラフィックが香港に向けて流れるように基幹ルータの設定を変更してしまったとあります(BGPの設定ミス？)。 この通信障害によって、Facebook、Amazon、CloudFlare、その他非常に多くの事業者が影響を受けたようです。数多くのWebサイトの再配信を手がけているCDN事業者であるCloudFlareが影響を受けたことで、同社サービスを利用しているWebサイトにも影響が出ました
BGPルータの512K問題について:Geekなぺーじ
インターネットでの通信障害を発生させた「BGPルータの512K問題」が一部界隈で話題です。今回は、それがどういった問題で、それが発生する背景がどのようなものであるかを紹介します。 インターネットの仕組みとBGP インターネットは、AS(Autonomous System/自律システム)という単位で運営されていますが、AS同士はBGPという経路をやり取りするプロトコルを利用して互いに接続することで成り立っています。BGPは、伝言ゲームのように「私の隣に○○というASの××というネットワークがある」という情報を伝えて行くものです。世界中のASが伝言ゲームに参加することによって、世界中のASへの到達方法を共有しているのがインターネットなのです。 BGPによって集められた、世界中のASに含まれるネットワークへの経路を全て(もしくは全てと推測される規模の)経路情報は「フルルート(Full Route
「著作権侵害サイト遮断 政府が導入検討、海外経由に対応」に関して:Geekなぺーじ
日本経済新聞に、以下のような記事が掲載されています。 著作権侵害サイト遮断 政府が導入検討、海外経由に対応 政府はインターネット上に氾濫する著作権侵害サイトへの接続を強制的に遮断できる仕組みを検討する。内閣官房の知的財産戦略本部（本部長・安倍晋三首相）に今夏にも有識者会議を新設。通信事業者や大学の専門家と連携して2016年３月にも決める。取り締まりが難しい海外サーバーを使った侵害サイトに対応できるようにする。 2010年頃の議論を振り返る 「取り締まりが難しい海外サーバーを使った侵害サイトに対応できるようにする」とありますが、恐らく、DNSブロッキングに関する議論も含まれていると推測しています。 日本では、児童ポルノを対象としたDNSブロッキングが2011年から開始しています（参考）。民間の通信事業者が各自の自主的な判断でDNSブロッキングを行っているという体裁であるため、ここで議題となる
BGPフルルートは必要か？GREEの事例:Geekなぺーじ
「インターネットに接続された全てのネットワークへの経路」であるBGPのフルルート(Full Route)を「ネットワークエンジニアの夢」と表現するネットワークエンジニアもいます。INTEROP Tokyo 2014のShowNetでも、あえてフルルートを受け取らないAS運用がテーマのひとつでした。 さて、そんなフルルートですが、「それって本当に必要なの？夢とかロマンとか感情的な話じゃなくて、現実問題として必要なの？」といった方向性の議論がコンテンツ事業者などの間で増えつつあります。 今回は、2年前にフルルート運用から脱却したグリー株式会社インフラストラクチャ本部の黒河内倫氏に、何故フルルートの運用をやめたのかや、それによって何が変わったのかを伺いました。 フルルートを捨てる決断を促した障害 GREEがフルルートを捨てる決断をしたのは、2年前、2012年の夏に発生した障害が原因でした。当時G
SFP型タップ/EtherOAMデバイス:Geekなぺーじ
ルータやスイッチからは通常のSFP(Small Form-Factor Pluggable)として認識されつつも、タッピングやEtherOAMが出来る製品が展示されていました。 SAMURAIのONMITSU INTEROP Tokyo 2014のShowNetで行われているデモのひとつとして、NTTコミュニケーションズの運用管理ツールであるSAMURAIがShowNetのモニタリングを行っています。 SAMURAIは、ShowNetのNOCメンバーも利用しており、ShowNetの構築や運用に活用されています。 これまで、SAMURAIはxFlowを利用しサンプリングによってネットワーク全体のトラフィックモニタリングを行ってきましたが、さらに具体的にパケット解析を行うためのDPI(Deep Packet Inspection)を行えるONMITSU(ベータ版/参考出品)という新機能が搭載さ
DNSキャッシュポイズニングの基本と重要な対策:Geekなぺーじ
2014年4月15日に公開されたJPRSの緊急注意喚起に続き、中京大学の鈴木常彦教授によるDNSキャッシュポイズニングに関する技術情報が公開されました。 今回公開された技術情報に書かれている内容には、DNSの本質につながるさまざまな要素が関係しており一回で書ききれるものではなく、また、書いている側（私）も、それぞれの要素技術について勉強しながら理解しつつ進めていかないと混乱してしまうということが良くわかったため、これから数回に分けて徐々に書いて行くことにしました。 ということで、今回はまず、そもそもDNSキャッシュポイズニングとは何かということと、JPRSの注意喚起に書かれているUDPソースポート番号のランダム化（ソースポートランダマイゼーション）の概要、そしてなぜそれが重要なのかという点について解説します。 DNSキャッシュポイズニングとは インターネットで通信を行うとき、各機器同士は通
なぜ、違法ダウンロードによる逮捕者が出ないのか？:Geekなぺーじ
NHKによる「刑事罰適用１年 売り上げ回復せず」というニュースが話題です。 その中で、「警察が摘発した例はまだありませんが」とある点が気になったので調べていたら、2012年に松田政行先生が書かれた「違法ダウンロードに対する刑事罰の導入に関する著作権法の視点」の存在を知りました。 この文書は、違法ダウンロード刑事罰化が施行される前に発表されたものですが、違法ダウンロードに対する罰則規定追加に対して、著作権法の視点での反対意見が述べられています。 その中で幇助者に対する刑事事案に関して、同文書5ページに以下のような記述があります。 ア 民事的請求から刑事罰への立法事実 民事的請求を許容する2009 年改正において、肯定された権利行使は、この3年間一切なかった。違法ダウンロードは無数に存在したのであるが、これを幇助する、そして権利行使可能性が肯定される事案は1件もなかったということが証明されたの
なぜ「DNSの浸透」は問題視されるのか:Geekなぺーじ
「DNSの浸透」という表現が結構よく使われています。 DNSに設定された情報を更新したけれど、その結果がなかなか反映されずに誰かに相談すると「DNSの浸透には時間がかかります」と説明されて納得してしまうという事例が多いようです。 しかし、うまく準備を行えば、実際の切り替え処理は、いつ完了するのかが不明な「DNSの浸透」を待つのではなく、事前に計画した時間通りに完了させることが可能です。 さらに、本来であればDNS情報の設定者(ゾーン情報の設定者)は、いつまでに世界中のキャッシュが更新されるかを知ることができる環境にあり、それ以降も更新がされていなければ「何かがおかしい」とわかるはずです。 DNSにおける設定内容(DNSのリソースレコード)には、その情報をキャッシュとして保持し続けても良い期間であるTTL(Time To Live)という要素がありますが、TTLはDNS情報設定者が自分で設定
.inドメイン名停止とwhois公開代行:Geekなぺーじ
今日(4月30日頃)、一部の人々の間で「うちのWebサイトで使ってる.inの名前解決が出来なくなった！」という悲鳴が聞こえています。 数年前、インドのccTLD(country code Top Level Domain)である「.in」を日本国内のWebサービスで使うのが流行しました。 「.in」は「イン」と読めるため語呂が良く、個人が気軽にWebサイトを作ったときに、ドメイン名も同時に登録するというのが流行ったわけですが、そのときにwhoisで世界に向けて連絡先(個人であれば氏名住所電話番号の場合もあり)を公開されるのは嫌だということで、whois情報公開代行サービス(もしくはプライバシー保護サービス)を使うというのが割と一般的に行われていました。 しかし、その.inのレジストリであるINRegistryが、whois情報公開代行サービスを利用しているドメイン名を次々と停止しているよう
Geekなぺーじ:MessagePackがIETF標準化に巻き込まれてる件について
ここ数日、MessagePackがIETFにおける標準化に巻き込まれてザワザワしています。 何が起きているかというと、MessagePackプロジェクトとは関係が無い第三者がIETFで派生物の標準化を進めようとしています(binarypack、Informational RFCとして)。 binarypackは、自らをMessagePackの派生であるとしながらも、MessagePackとの後方互換性が無いものです。 MessagePack is in danger! binarypackのInternet-Draftを提出しているのは、coreと6lowpanのchairです。 Chairであるかどうかが議論そのものに与える影響はそこまで大きくないとも言えますが、少なくともIETFでの話の進め方に精通した人物であることは確かです。 ただ、今回のInternet-Draftは、その人物がC
昨年末のgmail乗っ取りの原因ってこれ？:Geekなぺーじ
昨年末に発生したgmail大量乗っ取り事件と、この事件→「Googleドメイン向けの不正証明書、主要ブラウザメーカーが失効措置」って関係あるんですかね？(記事最後に追記あり。注意。) Googleセキュリティブログの記事はコレ→「Enhancing digital certificate security」ですね。 時期といい、この手法だったら防ぐの難しいよなぁというのと、凄くピッタリなんですけど。。。 この攻撃手法に関してはGoogleに落ち度がなく、逆にGoogleが気がついて遮断しているわけで、今回の発表を見ると凄いなぁと思えます。 2011年に発生したイランでの事件発覚もChromeによるものみたいですが、今回もChromeが検知して遮断という流れですね(参考：イランからGoogleへのSSL通信が傍受されていた疑い。CAから発行された偽証明書が原因)。 逆に言うと、この手の攻撃に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
