DS-Liteは、基幹ネットワークをIPv6で構築し、ユーザのローカルネットワークとIPv4インターネットをつなぐことができる技術です。 基幹ネットワークをIPv6だけで構築しつつ、ユーザに対してはIPv4サービスも提供できます。 DS-Liteという名前は、Dual-Stack Liteの略です。 名前の意図としては、IPv6とIPv4のデュアルスタックを軽量に実現できる技術である、というものです。 この軽量は、ISP側によるIPv4でのCGN(Carrier Grade NAT)と比べて軽量という意図があります。 CGNによるNATでは、ユーザによるプライベートIPv4アドレスでのネットワーク、ISPでのCGN配下のIPv4ネットワーク、IPv4インターネットという3種類のIPv4ネットワークによる通信になるため、NAT444と呼ばれることもあります。 CGNによるNAT444では、ユ

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

最近、たまに「IPv6って速いんですか？」という質問をされることがあります。 それに対して意図的に非常に雑な回答をする場合には、「はい。IPv6を使うと速くなる場合があります。」と答えるようにしています。 今回は、「IPv6の方が速い」となる可能性がありそうな場合をいくつか紹介します。 IPv4 PPPoEを避ける場合 「IPv6を導入するとインターネットが速くなる」と日本国内で言われている状況があります。 NTTフレッツ系のIPv4 PPPoE利用時に、NGNでの網終端での輻輳が発生している場合があり、IPv6 IPoE(参考：IPv6 IPoEの仕組み)を利用することでIPv4 PPPoEを利用せずにインターネットとの通信が可能になるために、「IPv6の方が速い」という状況が発生するというものです(IPv4 PPPoEとIPv6 PPPoEは別なので、IPv6 PPPoEを使うことでも

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を起こし

色々な説明を省略して非常に雑な表現ではありますが、「IPv6を導入するとインターネットが速くなる」と日本国内で言われている状況があります。NTTフレッツ系のIPv4 PPPoE利用時に、NGNでの網終端での輻輳が発生している場合があり、IPv6 IPoEなどを利用することでIPv4 PPPoEを利用せずにインターネットとの通信が可能になるために、「IPv6の方が速い」という状況が発生するというものです。 IPv4 PPPoEを避けるために、DS-Liteなどを活用するといった話も一部界隈では盛り上がっています。 IPv4 PPPoEに関しては、総務省の研究会で議論が続けられてきましたが、10月27日に行われた「接続料の算定に関する研究会（第8回）」にて、「IPv4 PPPoEを使うと遅い」という状況が改善されるかも知れないと思える新しい動きがありました。 2017年10月27日(金)の10

「ネットはゴミだらけ」ということが話題になることが増えてきました。 今も昔も、ネット上にあるコンテンツが玉石混淆であることは変わりません。 ある程度探したいものが明確であり、かつ、キーワードもわかっていれば、今も昔も変わらずにネット検索は可能です。 しかし、何かは確実に変わっているように思えます。 そうやって考えていると、そもそも、Webの世界で実現される夢として語られていた「群衆の叡智」というのは、あの当時の熱狂を背景として専門家がダンピング的に専門知識をネット上に掲載していたから実現したことであって、それが永遠に続くわけではないのかも知れないと思い始めました。 叡智を目指したはずが、営利へと主軸が変化していくなかで、2000年代の熱狂と夢から覚めつつある人々が「ネットはゴミだらけ」という感想を発している場合もありそうです。 さらに、「ゴミだらけ」になった背景であったり、「ゴミだらけ」だ

「壊れやすくて粘り強い」というのは、私がインターネットに対して持っているイメージです。 絶対に壊れないことを目指すのではなく、ある程度は部分的に壊れることを前提にしてある、また、ゆるさやいい加減さが逆に全体としての壊れにくさを実現しており、全体としては粘り強くなっている、という意味合いです。 絶対に壊れないシステムを目指して、細かい部分的な障害や不具合を許容しないシステムを設計してしまうと、部分的には壊れなくても、障害のレベルがある一定の閾値を超えた時点で全体として動作不能になる可能性があります。 「部分的に壊れることを許さないもの」を目指してしまうと、できるだけ耐えるけど、耐えきれなくなったら全部一気に崩壊するというモデルになってしまいがちなのです。 今の日本では、インターネットは非常に安く、高速で、いつでも使える社会基盤となりました。 その社会基盤が「壊れる」ことなんて想像できないとい

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

Google社員が「女性は生まれつきエンジニアに向かない」という社内文書を作成したというニュースが話題になっています。 ITMedia: Google、中の人の「女性は生まれつきエンジニアに向かない」文書回覧で社内騒然 そこには、以下のように書かれています。 ダイバーシティ重視を打ち出しているのにエンジニアの女性比率がなかなか上がらないGoogleさん。男性エンジニアが「だって女性はエンジニアに向いてないんだよ」という社内文書を公開して大騒ぎ。 この騒動は世界的なニュースとなり、社内文書を作成したGoogle社員は解雇されました。 BBC: グーグル、「男女は生来能力が違う」と書いた従業員を解雇 BBCの記事には、以下のように書かれています。 ピチャイ氏は、グーグル社内で表現の自由を守る重要性について行数を割き、「文書に書かれた内容の多くは、議論に値するものだった。グーグル人の大半が賛成す

一部界隈で「ギガが減る」という表現が話題です(参考:若者はみんな使っている？謎のワード「ギガが減る」とは)。 「ギガがない」「ギガが回復した」「ギガが限界」「ギガがやばい」といった表現をTwitterなどで発見することもできます。データの単位を示すギガバイトのうちの「ギガ」という部分が何故か物のように表現されており、なかなか破壊力が大きい衝撃的なパワーワードです。 最近話題になっているのは「ITに詳しくない人々が使う変な表現」という面白ワードとしてですが、そういった表現が、実は日本のインターネットトラフィックの傾向を示すものになりつつあると言えてしまうのかも知れません。 IX事業者が見る「ギガが減る」 インターネットマルチフィード株式会社の吉田氏が2016年のIP Meetingで発表した「2015年インターネット運用動向」(PDF)の中で、次のように月初めから月末にかけてトラフィックが落

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では、日本が最も大

www.example.comなどの「名前」に対応するIPアドレスをDNSサーバに問い合わせるとき、IPv4とIPv6に関する名前解決を単一の問い合わせで行うことはできません。そのため、DNSサーバに対して、IPv4に関する問い合わせと、IPv6に関する問い合わせを、別々に2度行う必要があります。 これは、DNSサーバに対しての問い合わせが単一のレコードに対してしか行えないためです。 Aレコード（IPv4アドレス）の問い合わせと、AAAAレコード（IPv6アドレス）の問い合わせは、それぞれ別々のレコードに対する問い合わせなので、両方を同時には行えないのです。 ただし、「IPv4とIPv6に関するDNSサーバへの問い合わせは別々に行わなければならない」というのは、事実上の話であって、「仕様上そうなっている」と言い切れるのかどうかは微妙かも知れません。 DNSに関するRFCは、悪名高いRFC

さくらインターネットが、VPSの標準OSイメージでIPv6設定デフォルト無効化を発表しました。 さくらのVPS、標準OSイメージの仕様変更のご連絡 (IPv6設定デフォルト無効化) 発表では、以下のようにあります。 初期状態のおけるセキュリティ向上のため、以下のOSについてIPv6のデフォルト無効化を実施いたします。 有効化手順につきましては、ヘルプページをご用意しておりますのでそちらをご確認ください。 個人的には、IPv6が普及しつつある現状に対する一歩先を行く対応だと思いました。 流石だなぁと。 気づかずに放置されるIPv6セキュリティ 現段階では、IPv6環境でのセキュリティが放置されがちです。 IPv4環境とIPv6環境のセキュリティの差に関して述べられている発表が昨年ありました。 ITU/APNIC/MICT IPv6 Security Workshop : Securing t

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

IPv6の大きな特徴として、IPアドレスの自動設定機能がIPv6の根本的な仕組みとして組み込まれている点があげられます。 IPv4が誕生した当初はIPアドレスの自動設定のための手法が存在していませんでした。 IPアドレス自動設定のためのDHCP(Dynamic Host Configuration Protocol)を規定したRFC 1531が発行されたのは1993年です。 IPv4におけるIPアドレスの自動設定は、後から作られたDHCPを使うというものでしたが、IPv6では最初からIPアドレス自動設定が議論されています。 ただし、その議論の結果生み出されたものが非常にややこしくなっています。 IPv6には最初からIPアドレス自動機能が備わっているものの、IPv6用のDHCPであるDHCPv6も同時に存在しており、非常にややこしいのです。 この文章を執筆している時点では、IPv6におけるI

インターネットで使われる各種仕様の多くは、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(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