「ピアリング戦記 - 日本のインターネットを繋ぐ技術者たち」を書きました！:Geekなぺーじ
書名：ピアリング戦記 日本のインターネットを繋ぐ技術者たち 著者：小川晃通 著 発行：2022年7月13日 ISBN：978-4-908686-14-6 A5判、152ページ 紙本体2000円 電子本体1800円 インターネットを構成する「技術」は世界共通です。 その仕様であるTCP/IPは万人に対して公開されており、解説書も数多くあります。 仕様や解説書は体系的に記述されているので、一見するとインターネットは実に合理的に技術的な要請に基づいて構成された形をしているように思えるかもしれません。 しかし、インターネットは人間が作り運営しているものです。 そのため、インターネットの形には「人間の営み」が少なからず影響しています。 そもそもインターネットを物理的に構築するためにはどうしても各所でお金が必要です。 回線代、場所代、電気代、運用者の人件費など、維持にはさらにお金がかかります。 お金が
6-13 SO_SNDTIMEOを利用したタイムアウト:Geekなぺーじ
#include <stdio.h> #include <unistd.h> #include <sys/socket.h> #include <sys/time.h> #include <arpa/inet.h> int main() { int sock; struct sockaddr_in server; struct timeval tv; sock = socket(AF_INET, SOCK_STREAM, 0); /* 接続先指定用構造体の準備 */ server.sin_family = AF_INET; server.sin_port = htons(12345); /* 192.168.0.0は利用されていないIPアドレス */ inet_pton(AF_INET, "192.168.0.0", &server.sin_addr.s_addr); /* タイムアウトを
Geekなぺーじ : UDPを使う
UDPとは UDPはデータが宛先に届いたかどうかをUDPは関知しないため、TCPと異なりデータの到着を保障しません。 そのため、UDPを使った通信を行うプログラムを書く場合には、パケットがネットワークの途中で消えてしまうことも想定しなくてはなりません。 このような制約がUDPにはあるため、確実にデータを届けたいアプリケーションではTCPを使うのが一般的です。 このように書くとUDPは使いにくいだけに思えますが、利点もあります。 複数の相手に同時にデータを送信できる（ブロードキャスト、マルチキャスト） TCPよりもリアルタイム性が高い まず、第一の利点として複数の相手に同時にデータ送信ができる事が挙げられます。 IPの通信形態には、ユニキャスト、ブロードキャスト、マルチキャストの３種類があります。 （ただし、IPv6にはブロードキャストはありません。） TCPでは、１対１の通信しかできないの
MACアドレスの再利用は、みんなが思っているよりもはるかに一般的:Geekなぺーじ
MACアドレスは、原則として、一意に割り当てられるものです。 ネットワークインターフェースごとに、ひとつずつユニークな値をベンダーが付けるものとされています。 ただ、これは、あくまで「原則として」であって、実際は、MACアドレスが重複することもあります。 IPv6に関連するいくつかのRFCで、MACアドレスの重複への言及があります。 この記事では、MACアドレスの重複とIPv6アドレスの自動生成という、わりと限定された視点ではありますが、MACアドレスが一意とは限らない、という話を紹介します。 なお、この記事のタイトルである「MACアドレスの再利用は、みんなが思っているよりもはるかに一般的」は、RFC 7217に書かれている一文の日本語訳です。 MACアドレスの重複とIPv6アドレス生成の仕様 MACアドレスがIPv6アドレスの自動生成で使われる場合があります。 IPv6アドレス体系のRF
IPv6がIPv4よりも速い理由:Geekなぺーじ
北米、及びカリブと北大西洋地域のRIR(Reigional Internet Registry)であるARIN(American Registry for Internet Numbers)のブログで、「Why is IPv6 faster? (なぜIPv6の方が速いのか）」という記事が公開されています。この記事に関連する内容は、NANOG 76で「Prisoner of IPv4(IPv4の囚人)」というタイトルで発表されています（動画58分ごろからがPrisoner of IPv4です）。 ARINの記事では、計測によるとIPv6を利用した方がIPv4よりもRTT(Round Trip Time)が短くなる傾向があるとしています。さらに、それによってWebサイトなどの表示速度が上昇することでSEOとしての効果も期待できるので、Googleによる検索エンジンでの順位が上がると書かれていま
インターネットプロトコルにおけるパケットサイズに関して:Geekなぺーじ
拙著「プロフェッショナルIPv6」で、IPv6がリンクにおいて1280オクテット以上のMTUを要求していることに関して「最小MTU」という表現をしており、その表現が間違っているのではないかというご指摘をいただき、その点について調べなおしました。 その過程で、そもそも関連する部分で自分が間違って理解していたことに気がつきました。 その間違いを発信していたという恥を晒す内容ですが、せっかくなのでブログの記事として共有することにしました。 IPv4におけるデータグラムのサイズに関して IPv4の仕様が規定されているRFC 791では、IPv4ヘッダのTotal Lengthに関して、以下のように書かれています。 Total Length: 16 bits Total Length is the length of the datagram, measured in octets, includi
ソフトバンク大規模通信障害の原因:Geekなぺーじ
2018年12月6日、ソフトバンクのネットワークにおいて、4時間25分にわたり約3060万回線の利用者に影響を及ぼす通信障害が発生しました。 ソフトバンクおよびワイモバイルの4G(LTE)携帯電話サービス、「おうちのでんわ」、Softbank Air、3Gサービスなどが影響を受けました。 この障害は、EricssonのMME内部にハードコーディングされた証明書が期限切れになったため、SGSN-MME(Serving GPRS Support Nodex - Mobility Management Entity)が再起動を繰り返してしまったのが原因です。 ただ、証明書が期限切れになることで、なぜ大規模な通信障害に繋がってしまうのかが良くわかりませんでした。 どのような設計をしたら、証明書が期限切れになったことで通信機器が再起動を繰り返すような状況になるのか、昨年段階では、いまいち理解できなか
[書評]「DNSがよくわかる教科書」は、すごくイイ！:Geekなぺーじ
Webエンジニアやネットワークエンジニアなど、インターネットに関わるIT系エンジニアは「DNSがよくわかる教科書」を読むことをお勧めします。 「DNSがよくわかる教科書」は、JPRSの方々が執筆しています（献本ありがとうございました）。 森下さんによると、この本は約1年半前から書き始めているようですが、DNSと日々向き合っているエンジニアの方々（DNSに人生をかけている人も）が時間をかけて書いた本だけあって、「わかりやすい」という方向性でありながら、かなりガチな内容です。 副題に「初心者エンジニア必見！やさしく、詳しい。これがDNS入門の決定版！仕組み・用語・運用をゼロから丁寧に解説」と書いてありますが、まさにその通りの内容です。 たとえば、BINDなどの特定の実装や、どこかの特定の事業者が提供しているサービスに偏った解説になっておらず、DNSそのものの概念や仕組みなどを丁寧に解説していま
DHCPv6の基本仕様が改定 - RFC 8415:Geekなぺーじ
5年間の議論の経て、DHCPv6の基本仕様を改定するRFC 8415が発行されました。 RFC 8415は、154ページあります。 RFC 8415によって、7つのRFC(3315, 3633, 3736, 4242, 7083, 7283, 7550)が上書き廃止されます。 RFC 8415では、これまでは別々のRFCとして定義されていた、DHCPv6基本仕様(RFC 3315,2003年)、DHCPv6-PD(RFC 3633,2003年)、ステートレスDHCPv6(RFC 3736, 2004年)がひとつのRFCとしてまとめられています。 DHCPv6-PD(Prefix Delegation)は、ブロードバンドルータなどのCPEに対してIPv6アドレスプレフィックスを割り当てる用途に使われます。 IPv4ではISPと契約を行っているユーザに対して1つのIPv4アドレスのみを割り当て
3.0.0.0/8がAmazonに:Geekなぺーじ
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本を無料配布！:Geekなぺーじ
2021年12月20日追記：第2版できました！ IPv6を解説した「プロフェッショナルIPv6」をラムダノート株式会社から出版しました。 初版は456ページになりました。紙版の厚さは23mmになる予定です。 現時点で、IPv6に関して世界で最もまとまっているIPv6本であると個人的に考えています。 「プロフェッショナルIPv6」は、株式会社日本レジストリサービス様、BBIX株式会社様、NTTコミュニケーションズ株式会社様、日本ネットワークイネイブラー株式会社様、クラウドファンディング(「すごい技術書を一緒に作ろう。」という企画です)でのみなさまによるサポートにより実現しました。 IPv6に関する技術情報を広く公開するという趣旨に賛同いただき、本書の執筆と制作、公開にあたって多大な協賛をいただきました。ありがとうございます！！！ 「プロフェッショナルIPv6」は、通常の書籍として5000円で
IPv6本 脱稿しました:Geekなぺーじ
2011年から書き続けていたIPv6本がついに脱稿しました。 この本は、クラウドファンディングで書きました。 完成したIPv6本の電子版は無償配布します。 サポーターの皆様、ありがとうございます！ 全章のフィードバック受付版は、5月21日(月)にマクアケ経由のメッセージにてサポーターの皆様にお送りする予定です。 その後、7月中に完成した書籍をサポーターの皆様にお届けするとともに、一般公開および一般販売開始する予定です。 IPv6本電子版の無償配布を行いますが、紙版と電子版の販売も行います。 ご購入いただけると、私とラムダノート社が喜びます。 なお、有料版と無償配布版の間にコンテンツとしての違いはありません。 ご購入いただかなくても内容を読むことはできます。 幅広く多くの方々にIPv6に関する技術情報が伝われば幸いです。 長くツライ執筆でした IANAのIPv4アドレス中央在庫が枯渇したので
ルータやスイッチは日本の法律上、通信の秘密を侵害するが違法ではない:Geekなぺーじ
パケットのヘッダに記載された情報を読み取らなければ、ルータはパケットを転送できません。 日本の法律では、ISPなどの電気通信事業者がIPヘッダに記載された情報を読み取ることは通信の秘密を侵害すると解釈されています。その一方で、インターネットにおける通信を実現するためにはルータがIPヘッダに記載された情報を読み取ることは必要であり、違法であるとは思えません。 日本におけるインターネットと法律に関する話題に触れたことがない方にとっては、非常に奇妙な話に聞こえるかも知れません。しかし、このように「法益を侵害するが違法ではない」という解釈は、日本においてインターネットがどのように運用されているのかを理解するうえで非常に重要なポイントです。 日本国憲法(第21条)と電気通信事業法(第4条)は、通信の秘密を定めています。憲法における通信の秘密と、法律における通信の秘密の違いは、憲法が政府などの公権力に
IPv6って速いの？:Geekなぺーじ
最近、たまに「IPv6って速いんですか？」という質問をされることがあります。 それに対して意図的に非常に雑な回答をする場合には、「はい。IPv6を使うと速くなる場合があります。」と答えるようにしています。 今回は、「IPv6の方が速い」となる可能性がありそうな場合をいくつか紹介します。 IPv4 PPPoEを避ける場合 「IPv6を導入するとインターネットが速くなる」と日本国内で言われている状況があります。 NTTフレッツ系のIPv4 PPPoE利用時に、NGNでの網終端での輻輳が発生している場合があり、IPv6 IPoE(参考：IPv6 IPoEの仕組み)を利用することでIPv4 PPPoEを利用せずにインターネットとの通信が可能になるために、「IPv6の方が速い」という状況が発生するというものです(IPv4 PPPoEとIPv6 PPPoEは別なので、IPv6 PPPoEを使うことでも
DNS over HTTPSの標準化開始:Geekなぺーじ
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技術の理解について:Geekなぺーじ
気がつくと、IT技術を解説する文章を10年以上書き続けています。 ブログを書くときには、基本的に自分の興味があることを書くことが多いので、そのときどきによってテーマが変わることも多いです。 私は、技術理解の流れとして以下のようなものがあると感じています。 興味を持つ 少し調べて何となくわかった気になる もうちょっと調べてわかってない部分を発見する もっと調べて理解を深める 2と3と4を永遠に繰り返す 「わかってない」であったり、「知らない」という事実に気がついてからが、新しいループのスタートなのです。 何かを「理解している」と思い込みたい傲慢な自分に気がつけるタイミングが発生しないと、新しい何かを調べ始めることが難しい気もしていると同時に、油断すると傲慢になっていく怖さがあります。 このように、自分の無知に気がつく喜びと苦悩の繰り返しで、何かを学んでいくというのがパターンとして多いのではな
日本国内のCDNシェア:Geekなぺーじ
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シェアは、以下のよう
192.168.0.1などのプライベートIPアドレスは途中で作られた:Geekなぺーじ
プライベートIPアドレス(プライベートIPv4アドレス)は、インターネットに直接接続しないプライベートな環境で誰でも勝手に使って良いIPv4アドレスです。 普通にインターネットで使われているIPv4アドレスはグローバルIPv4アドレスと呼ばれています。 以下の3つのIPv4アドレスブロックが「プライベートIPアドレス」として予約されています。 10.0.0.0/8（10.0.0.0から10.255.255.255） 172.16.0.0/12（172.16.0.0から172.31.255.255） 192.168.0.0/16（192.168.0.0から192.168.255.255） 今では、プライベートIPアドレスがさまざまなところで使われています。 身近なところでは、家庭内LANであったり、マンションで共用回線を使う場合のマンション内LAN、会社内で使うLAN、スマホ等でのテザリング
アカマイの新たなバックボーンネットワーク:Geekなぺーじ
RIPE 75のライトニングトークで、アカマイが、自社トラフィックを運ぶための専用バックボーンネットワークを構築していることを発表しました。 Christian Kaufmann - ICN Akamai 発表資料(PDF) アカマイは、ユーザに近いところにCDN用のキャッシュサーバを置くために、世界各地に拠点を構築しています。 そういった拠点は、たとえば、ISPの中に構築されたりしています。 これまで、アカマイは拠点間の通信にはパブリックなインターネットを利用していました。 発表では、個々に孤立していたことを示すために各拠点を「島 (islands)」と表現しています(islandsという表現は、RFC等でも割と良く使われます)。 世界中の様々なAS内に拠点を築き、その拠点間トラフィックもパブリックなインターネットを利用していたことは、アカマイの非常に大きな特徴であったとも言えます。 し
ユーザの近くにある偽DNSサーバの話:Geekなぺーじ
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
