ここ数日、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

書名：ピアリング戦記 日本のインターネットを繋ぐ技術者たち 著者：小川晃通 著 発行：2022年7月13日 ISBN：978-4-908686-14-6 A5判、152ページ 紙本体2000円 電子本体1800円 インターネットを構成する「技術」は世界共通です。 その仕様であるTCP/IPは万人に対して公開されており、解説書も数多くあります。 仕様や解説書は体系的に記述されているので、一見するとインターネットは実に合理的に技術的な要請に基づいて構成された形をしているように思えるかもしれません。 しかし、インターネットは人間が作り運営しているものです。 そのため、インターネットの形には「人間の営み」が少なからず影響しています。 そもそもインターネットを物理的に構築するためにはどうしても各所でお金が必要です。 回線代、場所代、電気代、運用者の人件費など、維持にはさらにお金がかかります。 お金が

「プロフェッショナル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

「徹底解説v6プラス」という本を書きました。 「v6プラス」は、NTTフレッツ網を利用するユーザが、IPv6とともに、IPv6 IPoEを経由してIPv4インターネットと の通信ができる、日本ネットワークイネイブラー株式会社(JPNE)のサービスです。 IPv6 IPoEを経由することで、IPv4 PPPoEを経由せずにIPv4インターネットとの通信を行うため、ユーザのパケットが通る経路が変わります。 この経路の違いが通信品質に大きな影響を与える場合もあります。 「v6プラス」は、特定の企業のサービスであるため、RFCなどの文書によってその内容が明示されているものではありません。 2018年に発行した「プロフェッショナルIPv6」では、AppendixとしてNTTフレッツ網におけるIPv6に関する話題を扱っていますが、各VNEが提供しているサービスに関しては言及していません。 私がこれまで

TOP > ブログ > RFC 8501 : Reverse DNS in IPv6 for Internet Service Providers IPv4では、すべてのIPv4アドレスに対する逆引きとしてIN-ADDR.ARPAによるPTRレコードをDNSサーバに登録するといった運用が一般的に行われてきました。 しかし、各ネットワークセグメントごとに/64を割り当てるIPv6では、同様の運用を行うことは非現実的です。 ISP(Internet Service Provider)がIPv6での逆引きを扱う際のアプローチなどをまとめたInformationalなRFCとして、RFC 8501が2018年11月に発行されています。 この文章は、RFC 8501に記載されている内容を要約しています。 詳しくは、原文をご覧ください。 PTRレコードの主な用途 RFC 8501の4章で、DNSの逆引

2018年12月6日、ソフトバンクのネットワークにおいて、4時間25分にわたり約3060万回線の利用者に影響を及ぼす通信障害が発生しました。 ソフトバンクおよびワイモバイルの4G(LTE)携帯電話サービス、「おうちのでんわ」、Softbank Air、3Gサービスなどが影響を受けました。 この障害は、EricssonのMME内部にハードコーディングされた証明書が期限切れになったため、SGSN-MME(Serving GPRS Support Nodex - Mobility Management Entity)が再起動を繰り返してしまったのが原因です。 ただ、証明書が期限切れになることで、なぜ大規模な通信障害に繋がってしまうのかが良くわかりませんでした。 どのような設計をしたら、証明書が期限切れになったことで通信機器が再起動を繰り返すような状況になるのか、昨年段階では、いまいち理解できなか

fe80::/64というリンクローカルIPv6アドレス(リンクローカルユニキャストIPv6アドレス)は、同一リンク内でのみ利用可能なリンクローカルスコープのIPv6アドレスです。 リンクローカルスコープのIPv6アドレスは、同一リンク内においてのみ利用可能であるため、他のリンク内に存在しているリンクローカルIPv6アドレスに干渉しません。 そのため、たとえば、fe80::aというIPv6アドレスが、それぞれ異なるリンクに存在していてもOKです。 さらに、リンクローカルIPv6アドレスは、IPv6が有効になっている全てのネットワークインターフェースに対して設定されるため、世界中のさまざまなリンクでfe80::/64というプレフィックスが存在しています。 そのため、fe80::/64による128ビットのIPv6アドレスだけでは、通信相手を一意に指定できない場合があります。 たとえば、fe80:

2021年12月20日追記：第2版できました！ IPv6を解説した「プロフェッショナルIPv6」をラムダノート株式会社から出版しました。 初版は456ページになりました。紙版の厚さは23mmになる予定です。 現時点で、IPv6に関して世界で最もまとまっているIPv6本であると個人的に考えています。 「プロフェッショナルIPv6」は、株式会社日本レジストリサービス様、BBIX株式会社様、NTTコミュニケーションズ株式会社様、日本ネットワークイネイブラー株式会社様、クラウドファンディング(「すごい技術書を一緒に作ろう。」という企画です)でのみなさまによるサポートにより実現しました。 IPv6に関する技術情報を広く公開するという趣旨に賛同いただき、本書の執筆と制作、公開にあたって多大な協賛をいただきました。ありがとうございます！！！ 「プロフェッショナルIPv6」は、通常の書籍として5000円で

2011年から書き続けていたIPv6本がついに脱稿しました。 この本は、クラウドファンディングで書きました。 完成したIPv6本の電子版は無償配布します。 サポーターの皆様、ありがとうございます！ 全章のフィードバック受付版は、5月21日(月)にマクアケ経由のメッセージにてサポーターの皆様にお送りする予定です。 その後、7月中に完成した書籍をサポーターの皆様にお届けするとともに、一般公開および一般販売開始する予定です。 IPv6本電子版の無償配布を行いますが、紙版と電子版の販売も行います。 ご購入いただけると、私とラムダノート社が喜びます。 なお、有料版と無償配布版の間にコンテンツとしての違いはありません。 ご購入いただかなくても内容を読むことはできます。 幅広く多くの方々にIPv6に関する技術情報が伝われば幸いです。 長くツライ執筆でした IANAのIPv4アドレス中央在庫が枯渇したので

昨日の日本国内のCDNシェアという記事に対して、「個人サイトの利用ならさくらのウェブアクセラレータあたりも中々気になるんだよなあ」というhatenaのブックマークコメントがついたので、書いてみました。 気がつくと全日本剣道連盟の委員も20年目となり、それから派生して色々なスポーツ関係者からWebサイト作りや運営の相談を受けることがあるのですが、だいたいが、組織規模が小さかったり、個人だったりなので、専属でITエンジニアを雇うことができません。 そうすると、基本的にIT系のエンジニアが常に管理することが必要なサーバではなく、ホスティングサービスなど、何らかのマネージドなサービスで、かつ、値段が手頃なところとして、さくらインターネットを勧めることが多いです。 で、そういった小規模な運営主体が何らかの理由で、非常に短期的に大規模なトラフィックをさばくようなこともあります。 たとえば、年に一度開催

JStreamによる、日本のCDNシェアに関する調査結果が公表されています。 JStreamブログは、CDNに関連する色々な調査結果をブログで公開していて面白いです。 日本のCDNシェアについて調査結果＠2017年10月 JStreamブログの「市場調査」タグ 2017年10月版国内CDNシェアの調査方法は、Webクローラーによるもので、DNSに登録されたCNAMEや、HTTPメッセージに含まれるレスポンスヘッダを解析して判定しています。 判定を行っている対象となるCDNは、Cloudflare、Akamai、CloudFront、CDNetworks、Incapsula、Limelight、Edgecast，国内CDN事業者（Accelia、IDCF、IIJ、J-Stream）です。 日本語サイトのCDNシェア comなど、jpドメインではない日本語のサイトでのCDNシェアは、以下のよう

米国時間の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を起こし

RIPE 75で、DNSへの問い合わせ内容によって、DNSパケットが通過するネットワークが変わってしまうという怪しい挙動の報告がありました。 Babak Farrokhi - A Curious Case of Broken DNS Responses 発表資料(PDF) この発表では、DNSのパケットが途中ネットワークで解析され、そのDNSパケットに含まれる内容に応じて、すぐ近くにある偽のDNS応答が返ってくることがあるというものでした。 DNSパケットを解析するDPI(Deep Packet Inspection)装置＋偽DNS応答機能といった感じでしょうか。 発表者は、偽DNS応答がどこにあるのかを調べるために、DNSの問い合わせを用いたUDPによるtracerouteを実装しています。 偽DNS応答は、特定の名前に対するDNS queryに対してのみ発動するようなので、通常のtra

欧州刑事警察機構(Europol)のプレスリリースにて、ISP等で運用されるCGN(Carrier Grade NAT/大規模NAT)が犯罪捜査の妨げになっていると述べられています。 Europol: Are you sharing the same IP address as a criminal? Law enforcement call for the end of Carrier Grade NAT (CGN) to increase accountability online Europolのプレスリリースによると、欧州連合理事会(EU Council)の今期議長国であるエストニアとEuropolが共同でCGNの問題に関するワークショップを開催したとあります。 ワークショップには、EUのポリシーメーカーや法執行機関当局者35名が参加しました。 さらに、Europolの技術的なパー

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

IPv6導入が世界中に進んでいますが、日本国内では2017年中にIPv6導入が一気に加速しそうです。 NTTドコモは2017年4月頃からIPv6導入 昨日、NTTドコモ端末でのIPv6利用が2017年4月頃より開始されることがTwitterで発表されました。 2017年4月頃より、 #ドコモ 端末よりインターネットにアクセスする際に #IPv6 アドレスが付与される場合があります。自サーバへの接続でIPアドレス制限されている場合は、今のうちに設定変更を実施しましょう。詳細は→ https://t.co/cblmNM9lZ0 担当pix — NTTドコモ開発者情報 (@docomo_dev_info) 2017年2月7日 そのTweetで紹介されている「詳細」は、次のページです。 NTTドコモ：spモードサーバ情報 その「spモードサーバ情報」のページでは、一番下に以下のように記載されていま

インターネットに関連するプロトコルなどを規定する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

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

この前、4月から小学生になる知人の息子が近くで遊んでました。親が近くにいないときに、次のような会話が行われました。 少年「暇だから遊ぶものが欲しい。マインクラフトをやりたい。」 私「残念ながら、いまここにマインクラフトは無い。」 少年「iPadを持っているならマインクラフトをいますぐ買って欲しい。」 私「このiPadは仕事で使っているものだからダメ。」 少年「このボタンを押せばゲームを使えるようになるよ！（横からApp Storeをクリック）」 私「ちょっと待って。やめなさい。」 少年「ねぇ、ゲームをやらせてよーーー」 知人の子供がこのようなことを言ったうえで、ひとの持っているタブレットをいきなり操作し始めたのを見て、最初は「この子の親って。。。」という感想を持ちました。単に、その少年が信じられないぐらい図々しいだけだと思ったのです。 しかし、その後、全く別の場所でも同じようなことを主張す