IPv6アドレスの:で区切られた部分を何て呼べばいいの?

IPv6アドレスにおいて:(コロン)で区切られる2バイトの部分を何て呼べばいいのだろうか?IPv4アドレスではオクテット(octet)と呼ばれていて、会話の中で「第4オクテットが〜」みたいな使い方をするのだけど、IPv6アドレスで「第3***が〜」みたいな表現をしたい時に何て呼べばいいのだろうか?調べてみた。

紹介するインターネットドラフトではhextetという単語が提案されていて、NANOGでの一定の支持もあり、個人的にも良さげだったのでこれからはhextetって呼んでいこうと思う。

draft-denog-v6ops-addresspartnaming-04

draft-denog-v6ops-addresspartnaming-04で提案されている呼び方は2種類ある。ただしこのドラフトは2011年にExpireしており、RFCにもなっていない。NANOGのML投票なども行われて、このドラフトで最終的に候補に上がったのは以下の2つ。

hextet

IPv4のoctetは8-bitの意味なので、それをを真似して、16-bitということでhexadectet。でも発音が難しいのでhextet。読み方は多分「ヘクステット」か「へクテット」。hextetはすべての技術仕様文書で使う必要がある用語(MUST)とされている。

quibble

4-bitを表すnibbleの4倍だからquad nibbleでquibble。読み方は多分「クイブル」。quibbleは意思疎通のための補助的な用語(MAY)とされている。

RFC4291

IPv6アドレスの構造を規定しているRFC4291では、特に呼び名を設けていないが、テキスト表現を規定する文章中では一部 field という単語が使われている。

      Note that it is not necessary to write the leading zeros in an
      individual field, but there must be at least one numeral in every
      field (except for the case described in 2.).

"one or more groups of 16 bits of zeros"というような表現も見られる通り、fieldと呼んでいるものに対して特別に意味を持たせてはおらず、アドレス構造のRFCなのであくまでbit単位で語る文章が多い。

RFC5952

RFC4291のSection2.2のIPv6アドレスのテキスト表現について、推奨表現の更新を行なっているRFC5952では、こちらも特に呼び名を設けていないが、文章中では field (16-bit field) という単語が使われている。

draft-denog-v6ops-addresspartnaming-02

冒頭で紹介したドラフトの初期バージョンで提案されている呼び方を紹介しておこう。

  1. Chazwazza
  1. Chunk
  2. Column
  3. Colonade, Colonnade
    • コロンで区切られた、的な意味
  4. Doctet
    • double octetの略語
  5. Field
  6. Hexadectet
  7. Hit
    • hex-bitの略語
  8. Orone
  9. Part
  10. Provider number, customer number, network number
  11. Quad nibble, qibble, quibble
  12. Segment
  13. Tuple
  14. Word
    • コンピュータでは16-bitの単位をwordと呼ぶので

mod_spdyをMac OS Xのapache(macports)に導入する

http://www.yuyarin.net/screenshot/20120422185338.png

Googleがmod_spdyをリリースしたというニュースが出たので早速うちのapacheにも導入してみようかと思います.

LinuxだとDebian系用のdebCentOS系用のrpmは用意されているので多分楽に使えるのですが,残念ながらうちのサーバはMac OS XFreeBSDしかないので,頑張ってソースからインストールしてみようと思います.

環境

Lion(10.7)だとXcodeSDKの変化に対応するための書き換えが必要になるみたい.

準備

Google Code Archive - Long-term storage for Google Code Project Hosting.

基本的にこのページを見れば準備はできます.

3. 4. に関して,Max OS XapacheSSLの導入の仕方は上記ページの解説とは違いますが本題から逸れるのでググってくだしあ.

ビルドのための調整

5. Build mod_spdyから大きく変わります.

まず,makeコマンドを打てと言っていますが,Makefileなんか無いです.

どうするのかというとxcodeでビルドします.

src/build/all.xcodeprojを開きます.

x86_64への対応

まずhttpdMach-Oフォーマットを調べます.variantsで+universalしているかどうかで変わります.

x86_64ネイティブの場合

% file /opt/local/apache2/bin/httpd
/opt/local/apache2/bin/httpd: Mach-O 64-bit executable x86_64

Universal Binaryの場合

% file /opt/local/apache2/bin/httpd
/opt/local/apache2/bin/httpd: Mach-O universal binary with 2 architectures
/opt/local/apache2/bin/httpd (for architecture x86_64):     Mach-O 64-bit executable x86_64
/opt/local/apache2/bin/httpd (for architecture i386):     Mach-O executable i386

※次の手順で他の部分も書き換えるので,作業する前にひとまず全て読んでください.

all.xcodeproj内に含まれる全てのプロジェクトを開いて,Project -> Edit Project SettingsのArchitecturesを.x86_64ネイティブの場合は64-bit Intelに,universalの場合はStandard (32/64-bit Universal)に変更します.

http://www.yuyarin.net/screenshot/20120422190421.png

no-common

all.xcodeproj内に含まれる全てのプロジェクトを開いて,Project -> Edit Project SettingsのOther C-Flagsに -fno-commonを入れます.

mod_spdy

mod_spdy.xcodeprojのターゲットをmod_spdyにしてProject -> Edit Active Target "mod_spdy"を開き,

  • Mach-O Type : Bundle
  • Other Linker Flags : -dynamic -undefined dynamic_lookup -Wl,-search_paths_first
  • Exported Symbols File :
    • 適当なファイルに _spdy_module と記述
    • そのファイルパスを指定する

とする.

コードの書き換え

プリプロセスが適切に動作しているかどうかわからないので,apacheから呼び出されるsymbolを確実にexportするように書き換え(もしかしたら必要ないかもしれない)

899a900
< #if defined(__linux)
900a902
< #endif
904,905c906
>  struct module_struct __attribute__((visibility("default")))  spdy_module = {
---
<   module AP_MODULE_DECLARE_DATA spdy_module = {
925a927
< #if defined(__linux)
926a929
< #endif

ビルド

src/buildへcdしでビルド

% xcodebuild -project all.xcodeproj -configuration Release -target All

テスト系はビルドに失敗するかもしれない.

確認

src/xcodebuild/Release/mod_spdy.soが存在することを確認

symbol spdy_moduleがexportedになっているか確認.大文字のDで表示されていればOK.

% nm mod_spdy.so | grep _spdy_module
0000000000037e40 D _spdy_module

導入

コンフィグ

SSLの設定は入れてください

httpd.conf

LoadModule spdy_module modules/mod_spdy.so

Virtual Host

<VirtualHost *:443>
        ServerName www.yuyarin.net
        ...
        SSLEngine on
        SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
        SSLCertificateFile www.yuyarin.net.cert.pem
        SSLCertificateKeyFile www.yuyarin.net.privkey.pem
        ...
        SpdyEnabled on
        ...
ロード
% sudo cp mod_spdy.so /opt/local/apache2/modules
% sudo port unload apache2; sudo port load apache2

SPDYが有効になっているか確認

Google ChromeのExtensionのSPDY Indicatorをインストールして,httpsでアクセス.

http://www.yuyarin.net/screenshot/20120422185338.png

右上の稲妻が緑色に光れば導入成功!

パフォーマンス

うちのサイトはパフォーマンスの差はそれほど出ないだろうけど測定してみる.

測定に当たってはキャッシュの類を全て消します.

SPDY (https)

http://www.yuyarin.net/screenshot/20120422193440.png

ロードまでに331ms

HTTP

http://www.yuyarin.net/screenshot/20120422193601.png

ロードまでに419ms,何度かやったが差がでる.

違いはどこだろう.大きく見てDomCompleteまでに80ms多く時間がかかっているが,domainLookUpEndやConnectEndのネットワーク部分の時間もSPDYに比べて8ms余計にかかっている.

正直この程度のサイトじゃ効果はよくわからないように感じる.

解析

Wiresharkで通信の様子を眺めてみようかと思ったけどSSLで暗号化されているので諦めた

http://www.yuyarin.net/screenshot/20120422194347.png

これまでに出会ったエラー

httpd: Syntax error on line 119 of /opt/local/apache2/conf/httpd.conf: Cannot load /opt/local/apache2/modules/mod_spdy.so into server: dlopen(/opt/local/apache2/modules/mod_spdy.so, 10): no suitable image found.  Did find:\n\t/opt/local/apache2/modules/mod_spdy.so: mach-o, but wrong architecture

httpdアーキテクチャと合致していない(設定を変えないとi386コンパイルされる)

httpd: Syntax error on line 119 of /opt/local/apache2/conf/httpd.conf: Cannot load /opt/local/apache2/modules/mod_spdy.so into server: dlopen(/opt/local/apache2/modules/mod_spdy.so, 10): no suitable image found.  Did find:\n\t/opt/local/apache2/modules/mod_spdy.so: no matching architecture in universal wrapper

Universal BinaryコンパイルしたけどhttpdUniversal Binaryじゃなかった

httpd: Syntax error on line 119 of /opt/local/apache2/conf/httpd.conf: Can't locate API module structure `spdy_module' in file /opt/local/apache2/modules/mod_spdy.so: dlsym(0x1004061b0, spdy_module): symbol not found

そもそもsymbol _spdy_moduleがない(symbolをexportしないと)

ld: warning: cannot export hidden symbol _spdy_module from mod_spdy.so

_spdy_moduleがexportedになっていない(nmでmod_spdy.oを見るとDになっているのにmod_spdy.soではdに)

Cloudnをつかってみた

2012年3月30日からサービス開始されたNTTコミュニケーションズのCloudn(クラウド・エヌ),通称「くらうどん」をさっそく使ってみました.結構躓いたので,くらうどん1/4玉のインスタンスを作ってSSHの設定をするところまでを説明してみます.

くらうどんは従量課金制かつ月額上限付きのセルフサービスなクラウドで,面倒な紙の申し込みが不要で,オンラインで登録したらすぐに使える便利なサービスです.

AWS互換のAPIも備えていて管理も自分たちで好きなようにできます.NTTグループのサービスにしては非常にオープンで好感が持てますね.現在は米国のDCで,6月から日本のDCでも使えるようです.

プランは0.25CPU, RAM 0.5GB,ディスク15GB(Linux)で上限945円のvQプランから.VPS的な使い方しかしない場合はかなり高価ですね.そのかわり,ネットワークの設定やファイヤウォールやロードバランサが無料で使えるのが魅力.

http://www.yuyarin.net/screenshot/20120331161805.png

ミドルウェアはCitrix CloudStackっぽいです.

申し込み

くらうどんのページの右上の「お申し込み」から申し込み.必要な情報を入力してメールの認証を済ませてクレジットカードの登録をして,いざ本登録と思ったら...

「現在お申し込み出来ません。しばらく待って再度実行してください」

うーん,残念.申込受付開始のすぐ後だったので混雑してたんでしょう.

インスタンスの作成

無事,登録ができたのでコントロールパネルへアクセスしてみる.
http://www.yuyarin.net/screenshot/20120330113539.png

左と上に同じメニューがあるのは気にしないとして,とりあえずサーバを立ててみようと思う.

上のメニューにしか無い「クラウドコンソール」からインスタンスの作成ができるみたいなので開いてみる.

http://www.yuyarin.net/screenshot/20120331160443.png

InstancesのところにAdd Instanceといのがあったのでそれを押してみる.

OSの選択.Ubuntuにしてみる.CentOSの方が仮想化に相性が良いから作りこんであろうというのがわかっていての敢えての選択.

自分でテンプレートを作ったりISOを置いてBootしたりできるみたいだけど,そのためのディスクの利用に従量課金があるみたい.

http://www.yuyarin.net/screenshot/20120331160633.png

プランはうどん1/4玉で

http://www.yuyarin.net/screenshot/20120331160650.png

ディスクは並盛

http://www.yuyarin.net/screenshot/20120331160704.png

トッピングはなし

http://www.yuyarin.net/screenshot/20120331160716.png

名前はudon

http://www.yuyarin.net/screenshot/20120331160744.png

クラウドコンソールのInstancesで画面っぽい黒い部分をクリックするとVNCが立ち上がる

まじかよ,デスクトップ版かよ...

ログインパスワードは先の画面に書かれている(コピペ出来ない).Ubuntuの場合はuserというユーザが表示されているが,rootでログインする必要がある

http://www.yuyarin.net/screenshot/20120330114757.png

VNCはDivのマトリックスでそれぞれajaxでデスクトップの描画結果を取得しているみたい.
これが非常にもっさりで,インタラクションが困難.RTTが180ms程度なので仕方が無いか.日本のDCに移せるまで待とう.

shiftキーの処理がうまくいっていないようで,なかなか"|"や":"が入力できない(パイプやvimのコマンド入力ができない).改善を期待したい.

http://www.yuyarin.net/screenshot/20120330121343.png

useraddやadduserをしようとすると強制ログアウトされる.なぜ...

SSHの設定

そんなわけでSSHの設定をしましょう.といってもRTTが180+msぐらいなので,それでもあまり快適ではないですが.

デフォルトでsshdapacheやmysqldが動いているみたいで,rootでパスワードログイン可能なので,VNCは使わずにSSHから設定することをお勧めします.そのためにはport forwardingとfirewallの設定を変える必要があります.

Networkのメニューから

http://www.yuyarin.net/screenshot/20120331160838.png

Firewallのタブで,tcp22のアクセス許可を設定.ソースアドレスの制限はとりあえずなし全IPv4アドレス(怖い場合は自分の現在のグローバルアドレスを/32で設定してね).

http://www.yuyarin.net/screenshot/20120331160912.png

次にPort Forwardingのタブでtcp22を先ほど作ったインスタンスへforwardingするように設定

http://www.yuyarin.net/screenshot/20120331160932.png

多分これでSSHでアクセスできるはず.あとはユーザを作って,鍵を置いて,パスワード認証とrootでのログインを無効化して,といういつもの作業.

パフォーマンス

メモリがカツカツ.やっぱり1/4玉は軽いインスタンスがたくさん欲しい時用だなぁ.

top - 01:51:26 up 1 day,  5:11,  3 users,  load average: 0.08, 0.06, 0.06
Tasks: 143 total,   1 running, 142 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    504112k total,   456248k used,    47864k free,    77920k buffers
Swap:   521212k total,   237108k used,   284104k free,   221072k cached

tracerouteした感じだと200msぐらいあるので米国だとしたら東海岸のデータセンターっぽいですね.

round-trip min/avg/max = 178.0/189.3/202.3 ms

まとめ

SSHでログインするところまでを説明してみました.これから面白い遊び方を試してみたいなーと思います.

ところでIPv6ないんだけど?

2ch.netの接続障害とへ経路の揺れ

2012年01月21日の14時頃から2ちゃんねるのuni鯖など一部のサーバの板が閲覧不能に.0時前に回復するも断続的に接続不能になり,午前5時に再度接続不能状態が続いて現在に至る.

Megauploadに対する米当局の逮捕・閉鎖に抗議したanonymouseによる,政府系サイトやFBI,レコード会社系サイトへのDoS攻撃が行われているが(MailOnline, ITProPortal),これらのWebサイトがPIE(PacificInternetExchange)のデータセンターにあるため,同じデータセンターにある2ちゃんねるも攻撃の影響を受けている模様である.

同じく20日の19時頃から拙宅からwww.2ch.netに対する経路が大きく揺れている.具体的にはこれまでFreeBit,OCNからKDDI経由だったものがntt.net,gblx経由になっている.これが頻繁に切り替わっているようで,ASパスが変わったという自前アラートが鳴り止まない...

BGPのbest pathがAS32335の次でちょくちょく変わっているので,そのへんでなんか起きているんだろうなぁという感じ.下の2通りの間で時々切り替わっている.

4713 2516 4459 32335
2914 3549 23342 32335

↓自前アラート

www.2ch.net 206.223.154.230 from FreeBit 2012/01/22 04:06
 1   10013 FreeBit Co.,Ltd. CIDR                    219.99.81.171   tokyo2-9.ntt-poi.FreeBit.NET                        6.0 ms
 2   10013 FreeBit Co.,Ltd. CIDR                    219.99.81.162   219.99.81.162                                       6.0 ms
 3   10013 FreeBit Co.,Ltd. CIDR                    122.152.1.177   te3-1.SR8.B9A.FreeBit.NET                           9.0 ms
 4   10013 FreeBit Co.,Ltd. CIDR                    219.99.124.202  ae0.26.TR2.B9A.FreeBit.NET                         18.0 ms
 5 +  2914 NTT Communications Global IP Network     61.213.161.9    xe-5-0-3.a20.tokyjp01.jp.ra.gin.ntt.net            12.0 ms
   -  4713 OCN (AS4713) CIDR BLOCK 32               61.126.89.173   61.126.89.173                                             
 6 +  2914 NTT Communications Global IP Network     61.213.162.161  ae-6.r24.tokyjp01.jp.bb.gin.ntt.net                24.0 ms
   +  2914 NTT Communications Global IP Network     61.213.162.169  ae-6.r25.tokyjp01.jp.bb.gin.ntt.net                       
   -  4713 OCN (AS4713) CIDR BLOCK 86               118.23.146.201  118.23.146.201                                            
 7 + 20123 Dummy                                    129.250.2.20    ae-1.r20.tokyjp01.jp.bb.gin.ntt.net                11.0 ms
   + 20123 Dummy                                    129.250.2.72    ae-0.r21.tokyjp01.jp.bb.gin.ntt.net                       
   + 20123 Dummy                                    129.250.2.92    ae-9.r20.tokyjp01.jp.bb.gin.ntt.net                       
   + 20123 Dummy                                    129.250.3.222   ae-3.r23.osakjp01.jp.bb.gin.ntt.net                       
   -  4713 OCN (AS4713) CIDR BLOCK 86               118.23.168.69   118.23.168.69                                             
 8 + 20123 Dummy                                    129.250.2.2     ae-2.r20.osakjp01.jp.bb.gin.ntt.net               100.0 ms
   + 20123 Dummy                                    129.250.2.48    ae-7.r20.osakjp01.jp.bb.gin.ntt.net                       
   + 20123 Dummy                                    129.250.3.145   as-0.r21.lsanca03.us.bb.gin.ntt.net                       
   + 20123 Dummy                                    129.250.3.22    as-3.r20.lsanca03.us.bb.gin.ntt.net                       
   + 20123 Dummy                                    129.250.4.189   as-1.r20.sttlwa01.us.bb.gin.ntt.net                       
   + 20123 Dummy                                    129.250.4.44    as-2.r21.snjsca04.us.bb.gin.ntt.net                       
   -  4713 OCN (AS4713) CIDR BLOCK 19               210.254.187.198 210.254.187.198                                           
 9 + 20123 Dummy                                    129.250.2.164   as-2.r20.snjsca04.us.bb.gin.ntt.net               120.0 ms
   + 20123 Dummy                                    129.250.2.230   ae-1.r05.lsanca03.us.bb.gin.ntt.net                       
   + 20123 Dummy                                    129.250.3.197   as-1.r21.snjsca04.us.bb.gin.ntt.net                       
   + 20123 Dummy                                    129.250.5.47    ae-1.r05.sttlwa01.us.bb.gin.ntt.net                       
   + 20123 Dummy                                    129.250.5.55    ae-2.r06.snjsca04.us.bb.gin.ntt.net                       
   + 20123 Dummy                                    129.250.5.86    ae-2.r05.lsanca03.us.bb.gin.ntt.net                       
   -  4713 OCN (AS4713) CIDR BLOCK 9                210.163.230.98  210.163.230.98                                            
10 + 20123 Dummy                                    129.250.5.13    ae-1.r06.snjsca04.us.bb.gin.ntt.net               120.0 ms
   +  1221 REACH (Customer Route)                   64.208.110.222  verio-1.ar5.SEA1.gblx.net                                 
   +  1221 REACH (Customer Route)                   64.212.107.1    te6-4-10G.ar4.LAX1.gblx.net                               
   -  2516 KDDI                                     118.155.197.129 otejbb203.kddnet.ad.jp                                    
11 + 20123 Dummy                                    204.245.39.34   204.245.39.34                                     127.0 ms
   +  1221 REACH (Customer Route)                   208.178.58.201  te2-3-10G.ar3.SJC2.gblx.net                               
   +  1221 REACH (Customer Route)                   64.212.107.1    te6-4-10G.ar4.LAX1.gblx.net                               
   + 22566 Proxy-registered route object            67.17.157.86    UNITED-LAYER.GigabitEthernet9-3.ar5.LAX1.gblx.net         
   -  2516 KDDI                                     203.181.100.138 pajbb001.kddnet.ad.jp                                     
12 + 20123 Dummy                                    204.245.39.34   204.245.39.34                                     134.0 ms
   + 23342 United Layer, Inc.                       209.237.224.137 Vlan802.br2.sf7.unitedlayer.com                           
   + 23342 United Layer, Inc.                       209.237.229.94  200p.maido3.net                                           
   -  2516 KDDI                                     124.211.34.126  ix-pa8.kddnet.ad.jp                                       
13   32335 Pacific Internet Exchange - Proxy Object 206.223.154.230 206.223.154.230                                   139.0 ms
   + 23342 United Layer, Inc.                       209.237.224.137 Vlan802.br2.sf7.unitedlayer.com                           
   + 23342 United Layer, Inc.                       209.237.229.94  200p.maido3.net                                           
   -  2516 KDDI                                     124.215.192.106 124.215.192.106                                           
14   32335 Pacific Internet Exchange - Proxy Object 206.223.154.230 206.223.154.230                                   128.0 ms
   -  4459 For Streamworks in LA                    209.137.145.90  p2002090.kdd.net                                          
15   32335 Pacific Internet Exchange - Proxy Object 206.223.154.230 206.223.154.230                                   136.0 ms
16   32335 Pacific Internet Exchange - Proxy Object 206.223.154.230 206.223.154.230                                   116.0 ms

rrdtool fetchをフォーマットするzsh関数

ネットワークの監視のためにトラフィックのデータをmrtgcactiでとっていると,生データを見たくなる時が時々あるのだけれども,rrdtool fetchのデフォルトの表示では分かり辛いのでフォーマットするzshの関数を書いてみた.

ひとまず1カラム目のUNIX timeをフォーマットする関数.

rrd-fetch () { rrdtool fetch $@ | gawk -F : '{ s = $1; if (match($1, /^[0-9]+/)>0) { cmd = "date -r "$1" +\"%Y/%m/%d %H:%M:%S\""; cmd | getline s; close(cmd);} print s, $2}' }

こっちはLinux用(dateコマンドの仕様が違うので)

rrd-fetch () { rrdtool fetch $@ | gawk -F : '{ s = $1; if (match($1, /^[0-9]+/)>0) { cmd = "date -d @"$1" +\"%Y/%m/%d %H:%M:%S\""; cmd | getline s; close(cmd);} print s, $2}' }

更にトラフィックデータ用にMbpsで表示する関数.

rrd-fetch-mb () { rrd-fetch $@ | gawk '{ s = $1" "$2; i=2; while (++i <= NF){ if (match($i, /nan/)==0) {s = s" "sprintf("% 7.1f",strtonum($i)*8/1024/1024) } else { s = s"     nan" } } print s }' }

実行するとこんな感じ.

$ rrd-fetch-mb hoge.rrd AVERAGE
2012/01/06 23:35:00   249.2   428.3
2012/01/06 23:40:00   272.3   426.5
2012/01/06 23:45:00   241.5   445.9
2012/01/06 23:50:00     nan     nan
2012/01/06 23:55:00     nan     nan

トラフィックデータの場合大体CFはAVERAGEなのでそこまで関数にハードコートしてもいいかも.