世界初への挑戦！インターネットを快適にするNAT64/DNS64とは？ - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
はじめまして。BIGLOBEのN澤です。 最近は気軽に外出しづらい世の中ですので、休日はステイホームで動画サイトを楽しむことが増えてきました。お気に入りの動画は、かつて一世を風靡した某冬ソングの女王が最近の流行りの曲をピアノで引き語りながら暴走 (暴奏?) する動画です。 ということで、今はインターネットで誰もが手軽にさまざまなコンテンツを楽しむことができる時代です。特に光ファイバーのような定額の固定回線では、「ギガが減る」ことを気にする必要がないため、動画のような大容量のコンテンツを楽しんでいる方も多いのではないでしょうか。そのような背景もあり、インターネットのトラフィックは毎年、指数関数的に増加する傾向にあります。 増え続けるトラフィック、どうする？ IPv4？IPv6？ IPv4 over IPv6とは？ NAT64/DNS64とは なぜNAT64/DNS64に取り組むのか NAT6
技術書をクラウドファンディングで出版してみた
あきみちさんから、「IPv6本を出すということで、クラウドファンディングで協賛を呼びかけよう」（原文ママ）というアイデアを聞いたのは、TwitterのDMのやり取りを読み返すと2016年11月23日のことだったらしい。 DMには時刻が表示されないので正確な時間はわからないけど、その後のやり取りがいつの間にか11月24日になっているので、たぶんそういう時間帯だ。 それに対するぼくの最初の返答は、「それは既存の出版社だと面倒そうだ」（原文ママ）だ。 言外に「うち（ラムダノート）ならできるよ」が含意されていることは、起業前からいろいろ相談にのってくれていたあきみちさんには間違いなく伝わる。 とはいえ、そのころはまだ『プロフェッショナルSSL/TLS』も制作中だったし、直販ストアもなかったし、ラムダノートは胸を張って「出版社」と言える状態ではなかった。 そもそも、あきみちさんやぼくは技術自体という
なぜIPv6とIPv4の名前解決は別々に行なわれるのか？:Geekなぺーじ
www.example.comなどの「名前」に対応するIPアドレスをDNSサーバに問い合わせるとき、IPv4とIPv6に関する名前解決を単一の問い合わせで行うことはできません。そのため、DNSサーバに対して、IPv4に関する問い合わせと、IPv6に関する問い合わせを、別々に2度行う必要があります。 これは、DNSサーバに対しての問い合わせが単一のレコードに対してしか行えないためです。 Aレコード（IPv4アドレス）の問い合わせと、AAAAレコード（IPv6アドレス）の問い合わせは、それぞれ別々のレコードに対する問い合わせなので、両方を同時には行えないのです。 ただし、「IPv4とIPv6に関するDNSサーバへの問い合わせは別々に行わなければならない」というのは、事実上の話であって、「仕様上そうなっている」と言い切れるのかどうかは微妙かも知れません。 DNSに関するRFCは、悪名高いRFC
ざっくり詳解 - NAT64とDNS64:Geekなぺーじ
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
RHEL6/CentOS6では、single-request-reopen を必須にしたい…
2012-11-02 結論から言えば、とりあえず RHLE6/CentOS6 な人は /etc/resolv.conf に options single-request-reopen を書いておこうという話です(全部小文字ですよ、念のため） なぜか？ RHEL5/CentOS5/Ubuntu 10.04なLinuxとかでは、FQDN の解決をするときに DNSキャッシュサーバに AAAA RR の Queryを投げる AAAA RR の Reply を受ける DNSキャッシュサーバに A RR の Queryを投げる A RR の Reply を受ける という挙動でしたが、RHEL6/CentOS6 では DNSキャッシュサーバに A RR の Queryを投げる DNSキャッシュサーバに AAAA RR の Queryを投げる A RR の Reply を受ける AAAA RR の Re
［速報］今日、日本を含むアジア太平洋地域のIPv4アドレスが枯渇しました
日本ネットワークインフォメーションセンター（JPNIC）は今日付け（2011年4月15日）で、アジア太平洋地域のIPv4アドレスを管理しているAPNIC（Asia Pacific Network Information Centre）のIPv4アドレスの在庫が枯渇したと発表しました。 2011年4月15日をもって、 APNICにおけるIPv4アドレスの在庫は枯渇いたしました。 本件に関し、APNICからもアナウンスが出されています。 IPv4アドレスは今年2月に、最後のIPv4のアドレスブロックを世界に5つある地域インターネットレジストリ（RIR：Regional Internet Registry）に分配し、IPv4の配布を終了するというセレモニーを開催していました。アジア太平洋地域は世界で最も早くIPv4アドレスが枯渇した地域となります。 今後のIPv4アドレスの分配は？ JPNICで
WIDE : Press Release : 「itojun基金」募金協力のお願い
2007年10月29日、"itojun"のアカウント名で知られる萩野純一郎君が、37歳の若さで、多くの仲間に惜しまれながら永眠されました。 itojunは、KAMEプロジェクトを通じたIPv6参照ソフトウェアの研究開発やIETFにおける標準化活動など、次世代インターネット技術の確立と普及に向けて、献身的な貢献をされました。 itojunのIPv6に関連する幅の広い、そして情熱的な貢献と偉大な業績なしには、今日のIPv6技術は存在することがなかったでしょう。 この度、彼の活躍を讃え、その遺志を継ぐために、ご家族からの寄付を基にしてIPv6並びに次世代インターネット技術のための基金をIETFの母体であるISOC（Internet Society）に作ることとなりました。 この基金は、"Itojun Service Award"として、IPv6関連で献身的な活躍をした個人または団体を表彰し支援す
itojun氏インタビューYouTubeで伝えたい、IPv6のあんなことこんなこと
萩野純一郎氏が10月29日に亡くなった。本名よりも「itojun」の愛称で知る人の方がはるかに多いこともあり、ここでは敬意を込めて「itojun」氏と呼ばせていただくことにする。 itojun氏は、よく知られているように、KAME projectでIPv6プロトコルスタックの開発および公開に尽力した主要メンバーの1人で、IPv6普及に多大な貢献をした技術者だ。訃報が流れて以後、インターネット上には萩野氏を悼む声が溢れている。 itojun氏は、最近ではYouTubeで「ipv6 100の質問」をシリーズで公開し、技術者だけでなく、広く一般のユーザーにもIPv6について知ってもらおうと試みていた。本誌では、10月中旬にitojun氏にYouTubeのコンテンツについて取材しており、残念ながらitojun氏に見ていただくことはできなくなってしまったが、itojun氏がIPv6普及のために何をし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
