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

拙著「プロフェッショナル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

デバッグやテストを行っていると、プログラムが無限ループに入り込んで返ってこないような状況が発生することがあります。 そのバグが再現の難しいものであれば「gdbを使って起動しとけば良かった。。。」というような気分になる時があります。 しかし、gdbには既に起動しているプログラムの制御を横から奪い取ってデバッグするというありがたい機能があります。 ここでは、既に起動しているプログラムをgdbでいじる方法を説明したいと思います。 実際にデバッグをする方法を説明するというよりは、gdbで動いているプロセスにアタッチする例を説明します。 その後のデバッグに関しては、いつものgdbの使い方をしていただければ大丈夫です。 とりあえずアタッチしてみる 既に起動しているプロセスをgdbを解析するのは非常に簡単です。 単にgdbでプロセスにアタッチするだけです。 gdbでプロセスにアタッチする方法は2つありま

ここでは、サーバの例としてインチキHTTPサーバを作ってみたいと思います。 HTTPは日ごろ良く使っていて、馴染みも深いと思います。 手元のWebブラウザと接続できるサーバを作ると、何となくサーバを作る感覚がわかりやすいかなぁと思ったのでHTTPサーバを選んでみました。 HTTPサーバサンプル 以下にインチキHTTPサーバを示します。 #include <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> int main() { int sock0; struct sockaddr_in addr; struct sockaddr_in client; int len; int sock; int yes = 1; char buf[2048]; char inbuf[2048];

ここでは、Linuxを使ったネットワークプログラミングの説明を行いたいと思います。 ここで対象としている読者は、ネットワークプログラミング初心者（もしくは入門者）かつLinux環境でプログラミングを行いたい人です。 開発環境としては、C言語＋gccを想定しています。 説明内容は主にソケットプログラミングになります。 なお、C言語そのものが初めての方は「C言語入門」も参考にどうぞ。Windows専用には書いてませんが主にC言語で共通の部分を解説しています。 コードを書く前の準備 まず、gccを使える状態にしないといけません。 ディストリビューションにもよりますが、Linuxを普通にインストールしただけでは開発環境は入りません。 開発環境を用意するためには、gccやglibcなどのrpmを必要に応じてインストールしてください。 次に、エディタが必要になります。 mule、emacs、xemac

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

mainの最後に「return 0」と書いてあるサンプルがあります。 ここでは、それを説明しようと思います。 mainの中のreturn mainの中のreturnで返る値は、プログラムの実行が終わったときにプログラムが返す値です。 mainの中のreturnで返す値が0であれば、プログラム全体が成功、0以外であれば失敗とする慣習があります。 (UNIX系システムではこのような慣習があります) ただ、このように書いても良く解らないと思うので、以下に例を示します。 以下の例では、mainは「return 1」をしています。 int main() { return 1; } 上記例をコンパイルして出来上がったファイルを「a.exe」だとします。 (cygwinの場合です。LinuxなどのUNIX系で行った場合はa.outになると思われます。) この実行ファイルの結果を受け取って、行動を変える以

DNS Summer Days 2013の初日最後のセッションで面白い話が公表されていました。 JPCERT/CCに対して「うちのDNSが攻撃されています。助けて下さい」という問い合わせが来ることがあるらしいのですが、調べてみるとその大半がDDoSの踏み台として使われているのであって、実際は攻撃に加担してしまっているというものでした。 他者を攻撃するトラフィックを生成することで、自身の回線やサーバに負荷がかかってしまっている状態が凄くよくあるそうです。 「助けて！」と言っている人が、意図せずに誰でも使えるオープンリゾルバとして設定されており、攻撃者の踏み台にされているというものです。 キャッシュDNSサーバの設定を変更し、オープンリゾルバをやめると問題が解決することが多いとのことでした。 今年に入ってから、オープンリゾルバがDDoS攻撃の踏み台にされる話がインターネット通信業界で話題です。