MACアドレスは、原則として、一意に割り当てられるものです。 ネットワークインターフェースごとに、ひとつずつユニークな値をベンダーが付けるものとされています。 ただ、これは、あくまで「原則として」であって、実際は、MACアドレスが重複することもあります。 IPv6に関連するいくつかのRFCで、MACアドレスの重複への言及があります。 この記事では、MACアドレスの重複とIPv6アドレスの自動生成という、わりと限定された視点ではありますが、MACアドレスが一意とは限らない、という話を紹介します。 なお、この記事のタイトルである「MACアドレスの再利用は、みんなが思っているよりもはるかに一般的」は、RFC 7217に書かれている一文の日本語訳です。 MACアドレスの重複とIPv6アドレス生成の仕様 MACアドレスがIPv6アドレスの自動生成で使われる場合があります。 IPv6アドレス体系のRF

北米、及びカリブと北大西洋地域の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による検索エンジンでの順位が上がると書かれていま

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

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

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

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

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

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

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

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

昨日、ネットワークエンジニアではない方々向けのIPv6勉強会を行ってきました。 会場をご提供いただいた株式会社インターネットイニシアティブ様、ありがとうございました！ 発表資料をSpeaker Deckで公開しました。 当日の参加者は約150名でした。一部、私よりも詳しいネットワークエンジニアも参加していましたが、全くIPv6に関しての前提知識がないと思われる方々や、自分でIPv6 IPoEを設定してみたというかた、これから実際に手を動かしてみたいというかた、仕事でこれから必要になりそうなので調べ始めたというかたなど、様々な方々が参加されていたようです。 「ネットワークエンジニアではない方々向け」という内容ではあるものの、「どういう説明をするのか見てみたい」というネットワークエンジニアの方々もいたことや、見たことがあるTwitterアイコンなどがconnpassに表示されていたので、顔見知

BBIX BGP Meetingにて、SpotifyのPeter Carlsten氏がSpotifyの日本進出について発表しました。 おそらく偶然だとは思いますが、同じイベントの別セッションで発表されたTwitterと同様に巷で話題の「ギガが減る」という状況を示すユーザトラフィックが公表されつつ、日本の通信事業者に対するピアリングの呼びかけが行われました。 日本ユーザの通信品質 Spotifyは、音楽のストリーミングサービスです。ユーザは、音楽を再生するためにSpotifyから音楽データをダウンロードしますが、Spotifyとユーザの間での通信品質が低いと、ユーザ側で行われている音楽の再生が途中でストップしてしまい、バッファリングが行われます。 SpotifyのPeter Carlsten氏は、バッファリングが開始されて音楽再生が引っかかってしまう状況を「stutter(どもり)」と表現し

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そのものは、決して新しいものではありません。 IPv6の最初の基本仕様であるRFC 1883は1995年に発行されており、そのRFCに関連する議論は、それよりももっと前から開始されています。 IPv4アドレスの在庫が枯渇することは、かなり昔から予想されていて、その対策としてIPv6が作られたのですが、IPv4とIPv6には互換性がないこともあり、IPv6が普及せずにIPv4のみが利用され続ける状況が長く続いたのです。 しかし、2011年にIPv4アドレスの中央在庫が枯渇したことによってIPv6が注目されるようになり、IPv6によるインターネットも急激に拡大していきました。 2011年当時の段階では、世界中のインターネットユーザが利用しているインターネットプロトコルはIPv4でしたが、2017年の段階ではIPv6普及率が50％を超える地域も登場しています。 Apple社が、2016年

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

これまで何度か、IPv6が今も変化し続けている発展途上なプロトコルであるという話を書いてきましたが、その変化をどのように追えるのかに関しては、紹介していませんでした。 今回は、IPv6がどのように変化しているのかに関するイメージを持っていただくために、IPv6に関連するRFCの廃止や更新を紹介します。 IPv6に関する最初の仕様が決まったのが1995年ですが、そのときに発行されたIPv6関連の主要なRFCが、RFC 1883 から RFC 1886の4つです(1809と1881もありますが、それらは今回は割愛)。 それらのRFCは、IPv6に関する根本的な仕組みを示したものでした。 IPv6の根本的な仕様を示すRFCとして、1996年に発行されたRFC 1970もあります。IPv6のNeighbor DiscoveryのRFCです。 1995年に発行されたIPv6に関する4つのRFCと、1

IAB(Internet Architecture Board)は、7日にIPv4を前提とした標準の開発を行わないことを求める声明を発表しました。 IAB Statement on IPv6 声明によると、IPv4アドレス在庫は既に枯渇し、IPv4とIPv6によるデュアルスタック環境やIPv6のみによるネットワーク構築が急速に増つつあり、その傾向は今後も続くとあります。 そのため、今後、IETFではIPv6を前提とした標準化を進め、新しいプロトコルなどでIPv4との後方互換を求めない方針を声明で伝えています。 今後、IETFで標準化されるプロトコルは、IPv4に依存せずにIPv6のみで運用可能であることが求められます。さらに、RFCなどの文書で示される例も、IPv4ではなくIPv6で記述することを求めています。 IPv4とIPv6のデュアルスタックや、移行技術(共存技術)などによって、IP

TCPとは インターネットでの通信の90%以上はTCPによるものだと言われています。 通信を行うプログラムを書く場合、ほとんどがTCPによるものになると思います。 インターネットは信頼性のない通信路です。 信頼性がないインターネットでは、通信中にパケットロス、ビットエラー、順番の入れ替えなどが発生する可能性があります。 TCPは、そのような通信路上の障害を隠蔽してくれます。 具体的には、パケットロスが発生したら再送を行ったり、順番が入れ替わると正しい順番に直したりしています。 TCPによる通信はサーバとクライアントの2者間で行われます。 サーバは通信要求が来るまで待ち続けます。 TCPによる通信は、クライアントがサーバに対して接続要求を出すことから始まります。 サーバが接続要求を受け付けるとクライアントとサーバの間に仮想的な接続（バーチャルサーキット）が出来上がります。 プログラムを書く場

世界中のほとんどの人々は気にしていませんが、米国時間の2016年10月1日(土曜日)、インターネットが大きく変わりました。これまで米国政府が保持していたインターネットの重要資源に対する監督権限を手放したのです。 JPNIC: 米国政府がインターネット重要資源の監督権限を手放しました JPNIC News & Views vol.1439【臨時号】2016.10.3 NTIA: Statement of Assistant Secretary Strickling on IANA functions contract インターネットそのものは、世界中の多くの組織が分散しつつも協調することで成り立っています。 しかし、世界中のみんなが単一の「共通意識」を持って運用する必要がある、IPアドレスやポート番号などの番号資源、ドメイン名、プロトコルパラメータの3つに関しては、IANA（Internet

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