V6prog OSC2013Hokkaido

1
Socket を使用し
た IPv6 プログラ
ミングの基礎
IPv6 普及・高度化推進協議会
IPv6/IPv4 共存 WG
アプリ IPv6 化検討 SWG メンバ
ー
株式会社リコー
研究開発本部
基盤技術開発センター
大平浩貴（おおひらこうき）

2
IPv6 とその必要性
1990 年代よりインターネットが流行した
– IP が多数使われるようになった
– IP を使う端末が増えた
IP アドレスの枯渇
– インターネットで通信する端末の識別番号（端末
の住所： IP アドレス）が不足するようになった
新しい IP アドレスを持つ IP にしよう
– IPv4 （従来型）から IPv6 （次世代型）へ
– IPv6 は IPv4 を参考にしているが相互運用性はない

3
IPv6 の対応状況
 iDC/ ホスティング→続々対応中
 ISP→ 続々対応中
 端末 OS→PC は対応済み（随時機能向上中）
 … じゃぁ、アプリケーションソフトウェアは？
– Apache や BIND など、公共性の高いものは対応済み
 … じゃぁ、私たちが作るアプリは？
– 私たち自身がこれからがんばらないと！
 アプリケーションソフトウェアが IPv6 対応するには
どうしたらいいか

4
IPv6 プログラミングの情報につ
いて
 今回の解説で参考にしている書籍
– IPv6 ネットワークプログラミング ASCII 社刊
•http://ascii.asciimw.jp/books/books/detail/4-7561-4236-2.shtml
– 著者は萩野純一郎（ itojun ）氏
– 今回参考にしたプログラムもこの本に掲載されているもの
•itojun 氏が製作し、パブリックドメインで公開
 IW2012 の T7 「 IPv6 実践講座～トラブルシューテ
ィング、セキュリティ、アプリ構築まで～」セッシ
ョン
– https://www.nic.ad.jp/ja/materials/iw/2012/proceedings/t7/

5
IPv6 普及・高度化推進協議会での活動
 IPv6/IPv4 共存 WG アプリケーション IPv6 化検討
SWG
– http://www.v6pc.jp/jp/wg/coexistenceWG/v6app-
swg.phtml
 Socket アプリケーションの IPv6 化
•http://www.v6pc.jp/jp/entry/wg/2012/12/ipv610.phtml
– 手法本文 / サンプルプログラム / ソリューションサ
ンプル
•http://www.v6pc.jp/jp/upload/pdf/socket-20121203.pdf
•http://www.v6pc.jp/jp/upload/pdf/socket-sample-
20121203.pdf
•http://www.v6pc.jp/jp/upload/pdf/about_asterisk_ipv6v5-9.pdf
 Web アプリの IPv6 化
– 現在調査・検討中

6
IPv6 Summit も北海道で開催
 IPv6 Summit 2014 in Hokkaido
– IPv6 に関する最新事情の講演会
– 1 月ないしは 2 月に実施
 社団法人日本インターネット協会（ IAjapan ）が主催
– http://www.iajapan.org/
– IPv6 ディプロイメント委員会による
– http://www.iajapan.org/ipv6/
 みなさまお誘い合わせの上、ご参加をよろしくお願いい
たします

7
今回の説明の概要
 BSD Socket API を使用したアプリケーションソフト
ウェアの IPv6 化を説明
 クライアントプログラムの IPv6 対応
– 具体的な手順
 サーバプログラムの IPv6 対応
– 手法の分類
– 具体的な手順は割愛（すみません）
 名前解決の問題と解決案
 組み込みの話

8
BSD Socket による
クライアントアプリケーションの IPv6
化

9
IPv6 対応・デュアルスタック対応とは
 IPv6 だけでなく従来の IPv4 にも対応しなければならない
 従来：シングルスタック
– ひとつのプロトコル（ IPv4 ）に対応していた
 今後：デュアルスタック（ IPv6/IPv4 両対応プログラム）
– クライアントは複数のプロトコル・複数アドレスの中のどれで送信を
行うか選ばなければならない
– サーバは複数のプロトコル・アドレスで同時に受信しなければならな
い
ただ単に関数を変更するだけではだめ
選択機構や、並列受信機構などが新たに必要となる

10
従来のクライアントプログラミン
グ
IPv4 対応シングルスタックによるクライアン
トアプリの大まかな流れ
– ホスト名解決
– サービス名解決
– Socket 生成（ファイルデスクリプタ生成）
– Connect 実行（通信相手指定・接続を確立）
– デスクリプタによる入出力
– クローズ

11
ホスト名・サービス名解決
 IPv4
– ホスト名： gethostbyname() で hostent 構造体を得る
– サービス： getservbyname() で servent 構造体を得る
 デュアルスタック
– getaddrinfo() を呼ぶと addrinfo 構造体のリストが得られる
•リストの開放は freeaddrinfo() 関数に引数でそのリストを与える
 注意
– gethostbyname2() は IPv6 を扱えるが使うべきではない

12
addrinfo 構造体と sockaddr 構
造体 addrinfo 構造体
– 1 インスタンスで 1 アドレス情報を持ち、リストを構築している
– 内部でアドレスを保持する sockaddr 構造体へのリンクを持つ
 sockaddr 構造体
– IPv4 や IPv6 など各種アドレス情報を汎化した構造体
– 実体は sockaddr_in6 （ v6 ）や sockaddr_in （ v4 ）
– どのアドレスが入るかわからない場合は sockaddr_storage で定義

13
逆引き
 IPv4
– アドレス： gethostbyaddr() で hostent 型構造体を得る
– サービス： getservbyport() で servent 構造体を得る
 デュアルスタック
– getnameinfo() に sockaddr 構造体を与えるとホスト名やサー
ビス名の文字列を取得できる
•文字列領域は呼び出し元が引数で与える
– いろいろなオプションが指定可能
•NI_NOFQDN …FQDN ではなくホスト名だけ
•NI_DGRAM …UDP のポート情報を得る
•NI_NUMERICHOST… 逆引きせずアドレスの文字列表現を返す
•etc...

14
ソケット生成・コネクト
 デュアルスタックの場合 addrinfo 構造体を参照する
– 例： addrinfo ai ；
– プロトコルファミリ： ai->ai_family
– ソケットタイプ： ai->ai_socktype
– プロトコル： ai->ai_protocol
– アドレス： ai->ai_addr
– アドレス長： ai->ai_addrlen
 実例
s=socket （ ai->ai_family, ai->ai_socktype, ai->ai_protocol ） ;
connect(s, ai->ai_addr, ai->ai_addrlen);

15
クライアントのコード概要
struct addrinfo hints, *res, *resall;
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
getaddrinfo(“www.v6pc.jp”,”http”, &hints, &resall);
for (res = resall; res; res = res->ai_next) {
s=socket （ res->ai_family, res->ai_socktype, res->ai_protocol ） ;
if (s<0) continue;
if (connect(s, res->ai_addr, res->ai_addrlen) < 0){
close(s);
continue;
}
/* 読み書き */
close(s);
break;
}

16
デュアルスタッククライアントのまと
め
getaddrinfo() で接続先 IP アドレスのリストを
得る
– addrinfo 構造体のリスト
リストの順にソケット生成・接続を行い、成
功したら通信して終了する
サンプルプログラム
20121203.pdf

17
BSD Socket による
サーバアプリケーションの IPv6
対応

18
サーバのデュアルスタック化
いくつか手法がある
– inetd を使用する
– 自身のプロトコル・アドレスの数だけ socket() を
生成して、全ての FD に対して応答処理をする
– シングルスタック仕様のプログラムを複数プロセ
ス走行させる
– IPv4 マップドアドレス（ IPv4 Mapped IPv6
address ）を使用して、 v6 ソケットで通信する

19
サーバアプリ実現手法の分類
手法利点欠点
【手法１】
inetd を使用する
通信部分を inetd が代行す
るため、通信の IPv6 化を
意識しなくてよい
inetd を必要とする
【手法 2 】
複数の socket を生成する
ひとつのプロセスでマル
チプロトコルに対応でき
る
複数ソケットを生成し、
それらを同時に待つため
、プログラムが複雑にな
る
【手法 3 】
シングルスタックプログ
ラムを複数プロセス走行
させる
プログラム構成の変更な
しに IPv6 に対応できる
共有リソースを扱う場合
、プロセス間で排他制御
する必要がある
【手法 4 】
IPv4 マップドアドレスを
使用する
ひとつのソケットで
IPv4/IPv6 両方を処理でき
、プログラム構成の変更
が必要ない
IPv4 と IPv6 の処理が混在
する。アドレスを扱う際
には IPv4 マップドアドレ
スかどうかの判定が必要

20
inetd によるデュアルスタック
サーバ
 通信部分は変わらない
 通信相手アドレスを取得する部分で注意が必要
– getpeername() 　 FD と sockaddr 構造体を引数で渡すと
sockaddr 構造体に相手ピアアドレスを書く
– 引数は sockaddr 構造体ではなく、 sockaddr_storage 構造
体を使用する
•sockaddr_storage 構造体はどんなプロトコルのアドレスでも記憶で
きる領域を持つ
– あとは getnameinfo() で文字列化
sockaddr_storage from;
getpeername(0,(sockaddr*)&from,sizeof(from)) ；
手法
１

21
複数 socket で待ち受けるサ
ーバ
もっとも典型的で理想的な対応
プログラム構成が変化する
– 複数のデスクリプタを同時待ち受けする機構
完全な新規で設計する通信プログラムはこの
構成が望ましい
手法
２

22
複数ソケットを処理するサーバの
流れ
 getaddrinfo() で自身のプロトコル・アドレスを addrinfo 構造
体のリストで得る
– hints パラメータで AI_PASSIVE を指定すると IN_ADDR_ANY と
IN6ADDR_ANY_INIT が得られる
 リストで得られたプロトコル・アドレス個別に下記を実施
– socket() 、 bind() 、 listen()
 得られた複数の FD を fd_set 構造体に保存
 以降はループ
– fd_set 構造体を引数に select() で接続の待機
– select() を抜けてきた fd に対して accept()
– 読み書き処理
– クローズ

23
複数プロセスで待ち受けるサーバ
 シングルスタックアプリを複数走行させる
– getaddrinfo() で AF_INET と AF_INET6 のどちらかを設
定する
 fork でひとつのプログラムが v4/v6 に分離するよう
にすればリソースの節約も可能
– Copy on Write 機能による
手法
３

24
自分自身の IP アドレスを得るに
は？
環境依存
– UNIX ライク OS なら ioctl 関数を利用するのが一
般的
オープンソース OS の場合は ifconfig のソース
を参照するとよい
– FreeBSD の場合、 /usr/src/sbin/ifconfig/*
– ubuntu の場合、 net-tools パッケージ

25
デュアルスタックサーバのまとめ
いくつか手法があるので、メリットとコスト
・リスクを比較して適切な選択をしましょう
サンプルプログラム
20121203.pdf

26
名前解決の問題と最近のテクニッ
ク

27
getaddrinfo の並びは？
getaddrinfo() は名前解決
– 出力される addrinfo 構造体のリストはどういう順
序になるのか？
長らく RFC3484 で定義されていた
RFC6724 が RFC3484 を Obsolete した
– デフォルトポリシーテーブルの修正
– アドレス選択ルールの修正
– フォールバック問題の記述
– etc...

28
フォールバック問題
 フォールバックとは
– クライアントが接続先 IP アドレスのリストを得る
– リストの先頭にある IP アドレスに接続しようとして、失
敗すると次のリスト要素の IP アドレスを試す
 原因
– サーバがそのプロトコル・ IP アドレスでアプリサービス
をしていない
– ネットワークの接続性が失われている
 問題
– タイムアウトを繰り返すので、接続まで時間がかかる
– 環境によっては数十秒かかる場合もありうる

29
フォールバックの回避
 サーバがサービスしていない IP アドレスは DNS に
登録しない
 IP の接続性を健全に保つ
 ポリシーテーブルを変更する
– ポリシーテーブルの参照法は下記のとおり
•Windows: netsh interface ipv6 show prefixpolicies
•Linux: ip addrlavel show
•FreeSBD: ip6addrctl show
 サーバサイドだけでの対応では完全には解決できな
い

30
Happy Eyeballs
 RFC6555 、 RFC6556 で定義
 従来は TCP Syn の接続失敗を
受けて次の TCP Syn を送って
いた
 Happy Eyeballs は IPv6 / IPv4
アドレスに両方に対して一気に
TCP Syn を送る
– Syn/Ack 応答が帰ってきた IP に
TCP Ack を送って接続
 詳細の動きが不明瞭で実装依存
性が高い
– 複数 I/F の場合や IPv6 アドレスが
複数ある場合は？
– IPv6 Syn/Ack が遅れて届いたら？
– 今後の展開や運用を注視すべき

31
組み込み用途での IPv6 対応

32
組み込み機器へのアドレス埋め込
み
組み込みでは Socket を使うことが多い
組み込み機器はいろいろ大変
– お客様の環境で DNS が使えない
– 名前解決処理に必要なリソースが不足している
組み込み機器で IP アドレスをハードコーディ
ングしたいこともある
– しかしやめたほうがいい
– RFC4085 でこの問題が記述されている

33
アドレスハードコーディングの問
題
 そもそも IP アドレスは借り物
– リナンバリングのリスクが伴う
 ホスト名は名前指定して、名前解決には
getaddrinfo() を使うべき
– RFC6724 や RFC3484 に従った適切な処理が約束されて
いる
– これを自作するということは RFC に従うコストやそれか
ら外れるリスクを自己負担するということ
 これらのリスク・コスト・インターネットの道義的
責任がハードコーディングしないリスク・コストを
上回ったとき
– 十分な注意・サポートとともにやむをえずハードコーディ
ングすることは考えられる

34
最後に
 IPv6 はどんどん浸透してきている
– アプリで IPv6 を先取りして、時代もお客様も先取りしよう
 何かありましたらいつでもこちらまで
– IPv6 普及・高度化推進協議会の連絡先
•https://www.v6pc.jp/jp/info/inquiry_web.phtml
– 大平の連絡先
•ohhira@src.ricoh.co.jp
•kohki@lemegeton.org
•Twitter ： @torawarenoaya
•facebook ： http://www.facebook.com/kohki.ohhira
•LinkedIn ： http://jp.linkedin.com/pub/kohki-ohhira/10/7ba/6a2

V6prog OSC2013Hokkaido

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to V6prog OSC2013Hokkaido (20)

V6prog OSC2013Hokkaido