Hosting Casual Talks #4 Osaka 2017年9月30日
Hosting Casual Talks #4 Osaka 2017年9月30日
今回は、株式会社サイバーエージェントの篠原雅和氏と高橋哲平氏に、IPv6への取り組みや、SDN（Software Designed Networking）の検討状況などを伺いました。 取材時点においてAAAAレコードを外部サービス用にDNSに登録していないものの、内部ネットワークでは基本的にIPv6アドレスのみでの運用を実現されているのが印象的でした。 「技術で押していく会社がIPv6で引いてどうする」 ──御社でのIPv6への取り組みを教えてください。 新データセンターの内側はIPv6での運用になっています。ただし、外側はまだIPv4のみです。 内側はNAT64などを利用しつつ、IPv6とデュアルスタックで運用しています。一部、マネジメントポートがIPv4にしか対応していないなどの理由によってIPv4のみで運用されている部分もありますが、基本的にIPv6です。 ──なぜ内側を全てIP
IPv6アドレスにおいて:(コロン)で区切られる2バイトの部分を何て呼べばいいのだろうか？IPv4アドレスではオクテット(octet)と呼ばれていて、会話の中で「第4オクテットが〜」みたいな使い方をするのだけど、IPv6アドレスで「第3***が〜」みたいな表現をしたい時に何て呼べばいいのだろうか？調べてみた。 紹介するインターネットドラフトではhextetという単語が提案されていて、NANOGでの一定の支持もあり、個人的にも良さげだったのでこれからはhextetって呼んでいこうと思う。 draft-denog-v6ops-addresspartnaming-04 draft-denog-v6ops-addresspartnaming-04で提案されている呼び方は２種類ある。ただしこのドラフトは2011年にExpireしており、RFCにもなっていない。NANOGのMLで投票なども行われて、こ
USAGI(UniverSAl playGround for Ipv6) Project works to deliver the production quality IPv6 and IPsec(for both IPv4 and IPv6) protocol stack for the Linux system, tightly collaborating with WIDE Project, KAME Project and TAHI Project. USAGI Project is run by volunteers from various organizations. At this moment, the volunteers are from Japan, however, we are glad to work with volunteers in any count
(2006.8.5 ページを独立。) C/C++でのIPv6ソケットプログラミングについて。 ソケットについてはすでに掃いて捨てるほど解説サイトがあるが、IPv6に対応した、しかもポータブルな書き方を紹介しているところは見当たらなかった。 目次: サーバを作る クライアントを作る IPv6, IPv4を区別するサーバ @ サーバを作る まず、ソケットでIPv4あるいはIPv6クライアントからの接続を受け付けるプログラムを作ってみる。Fedora Core 5 Linuxで試した。 IPv4 onlyのときの典型的なコードは、次のようになる。※現代ではこのように書いてはいけません。 /** * TCP で listen する. IPv4 only. 実コードで使用不可! * * @param node bind() するホスト名. NULL の場合 INADDR_ANY. * @param
2. MAP とは？ • 現在 IETF Softwire WG で標準化が進められている IPv6 Network 上で IPv4 Service を展開するための Protocol のひとつ ☞ http://tools.ietf.org/html/draft-ietf-softwire-map • IPv4 Packet を IPv6 Header で Capsule 化する MAP-E （Encapsulation）と IPv4 Packet の IPv4 Header を IPv6 Header に書き換える MAP-T （Translation）の 2 種類 が存在 • Provider Network 側に変換 Table を持つ Address and Port 変換装置を持たない（Stateless） • ひとつの IPv4 Address を複数の顧客で共有可能 3.
図2 IPv6ヘッダ構成図。IPv4のヘッダに比べ、発信元／送信先アドレスが長くなっているが、全体としてはそれほどサイズが大きくなっておらず、よりシンプルになっていることが分かる 同じIPプロトコルでありながら、図2に示されたIPv6のヘッダは、図1のIPv4ヘッダに比べてかなりシンプルになっている。その大きな理由は、付加的な情報の多くを別個の「拡張ヘッダ」に再配置したことにある。図2に示されているのはIPv6の「基本ヘッダ」と呼ばれる部分であり、必要に応じて、このヘッダの後に「拡張ヘッダを追加する」ことによって、シンプルさと機能性の両立を可能にしている。基本ヘッダ内のフィールドの数が大きく減少したことにより、IPv6パケットの伝送における中継ルータの負荷が軽減されている。 基本ヘッダと拡張ヘッダの分離には、さまざまな効果がある。図1をご覧いただければ分かるが、IPv4のヘッダにはOpti
Network Working Group Request for Comments: 2553 Obsoletes: 2133 Category: Informational R. Gilligan FreeGate S. Thomson Bellcore J. Bound Compaq W. Stevens Consultant March 1999 Status of This Memo このメモは、インターネット社会のための情報を提供する。それは、如何なる種類のインターネット標準も規定しない。このメモの配布は制限されない。 Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract TCP/IP アプリケーションのデファクト標準のアプリケーションプログラムインター
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
