Time Attack: bgpsimple vs exabgp 2nd Heat
After @exabgp thankfully gave me an advice on my previous post, I carried out performance tests of bgpsimple and exabgp again.
@codeout Great blog entry: http://t.co/FHKPp9DXN6 . It would be great if you could check how much faster our API is to send the routes out.
— ExaBGP (@exabgp) May 15, 2015Right, API might be faster than massive config loading.
Full Route Advertisement
Service providers are struggling with the growing IPv4 full route and recently some people abandon default-free zone due to TCAM space problem. But they still sometimes need full route for analysis and forensic purpose. So, I'm curious, in such a case, is there good toolbox to inject full route into their network?
I think that simple BGP daemons are good options,
- bgpsimple
- exabgp with mrtparse
can read a full-table bgpdump archive and advertise to neighbor routers. Then, how fast are they?
Test Equipments
- MacBook Pro (Retina, Mid 2012) + VMWare
- Guest
Firefly was configured as a dumb BGP neighbor rejecting any route so that it couldn't affect route injector's performance.
Benchmark
| bgpsimple | exabgp with config file | exabgp with API | |
|---|---|---|---|
| Until BGP turnup | 0'00" | 2'58" | 0'02" |
| To complete advertising since BGP turnup | 2'38" | 1'13" | 4'13" |
| To complete advertising since "clear bgp neighbor" | 2'43" | 2'09" | 2'31" |
Version tested: *1
It took bgpsimple 2'38" to advertise full route, while exabgp required 4'11" ~ 4'15" in total.
exabgp shows different behavior depending on its configuration. exabgp with config file in the table above means "a bunch of static routes configured in .conf converted by mrtparse", exabgp with API means "configured to run an external script for route injection". The script looks like:
import sys import time messages = [ 'announce route 1.0.0.0/24 origin IGP as-path [2497 15169 ] next-hop 192.168.0.78', ... ] while messages: message = messages.pop(0) sys.stdout.write( message + '\n') sys.stdout.flush() while True: time.sleep(1)
See exabgp's wiki for more details.
Conclusion
bgpsimple is handier and faster way to inject full route from bgpdump archive. It simply assumes that the route information is given as a file in bgpdump -m format, read it with no signal handling and process routes in a simple loop with generating a minimal set of objects.
*1:Different version of exabgp from the previous post
ruby で pcap を読む
tcpdump やtshark などでキャプチャーしたパケットを，ruby で読むためのライブラリがあります．
The Ruby Toolbox などで検索すると山のように出てきますが，いくつか良さそうなのを紹介します．
PacketFu
例: IP パケットのsource address だけを抽出したい場合:
require 'packetfu' packets = PacketFu::PcapPackets.new.read(File.read('sample.pcap')) packets.each do |p| packet = PacketFu::Packet.parse(p.data) puts packet.respond_to?(:ip_saddr) && packet.ip_saddr end
PacketFu::Packet#inspectがちゃんとあってprint デバッグしやすい
[1] pry(main)> p packet --EthHeader------------------------------------------------- eth_dst fe:ff:20:00:01:00 PacketFu::EthMac eth_src 00:00:01:00:00:00 PacketFu::EthMac eth_proto 0x0800 StructFu::Int16 --IPHeader-------------------------------------------------- ip_v 4 Fixnum ip_hl 5 Fixnum ip_tos 0 StructFu::Int8 ip_len 48 StructFu::Int16 ip_id 0x0f41 StructFu::Int16 ip_frag 16384 StructFu::Int16 ip_ttl 128 StructFu::Int8 ip_proto 6 StructFu::Int8 ip_sum 0x91eb StructFu::Int16 ip_src 145.254.160.237 PacketFu::Octets ip_dst 65.208.228.223 PacketFu::Octets --TCPHeader------------------------------------------------- tcp_src 3372 StructFu::Int16 tcp_dst 80 StructFu::Int16 tcp_seq 0x38affe13 StructFu::Int32 tcp_ack 0x00000000 StructFu::Int32 tcp_hlen 7 PacketFu::TcpHlen tcp_reserved 0 PacketFu::TcpReserved tcp_ecn 0 PacketFu::TcpEcn tcp_flags ....S. PacketFu::TcpFlags tcp_win 8760 StructFu::Int16 tcp_sum 0xc30c StructFu::Int16 tcp_urg 0 StructFu::Int16 tcp_opts MSS:1460,NOP,NOP,SACKOK PacketFu::TcpOptions
- C拡張ではないため 遅い
pcap / ruby-pcap
例: IP パケットのsource address だけを抽出したい場合:
require 'pcap' packets = Pcap::Capture.open_offline('sample.pcap') packets.each do |packet| puts packet.ip? && packet.ip_src end
このgem はruby 2.2 に対応してません．(2015-07-27 追記: 対応されました)
本体に取り込まれるまでは
gem install specific_install gem specific_install https://github.com/codeout/ruby-pcap
or
git clone https://github.com/codeout/ruby-pcap cd ruby-pcap gem build pcap.gemspec gem install --local pcap-0.7.7.gem
でインストールできます．
ほか
いろいろありますが，各種プロトコルヘッダーにアクセスするAPI が少なくて使いやすいとは言えません．
ベンチマーク: PacketFu vs. pcap
10,000 パケットの処理時間:
user system total real PacketFu 3.760000 0.040000 3.800000 ( 3.857046) pcap 0.010000 0.000000 0.010000 ( 0.012067)
やはり差が出ます．パフォーマンスが要求される場合は pcap オススメ．
ベンチマーク用コード:
require 'packetfu' require 'pcap' require 'benchmark' Benchmark.bm do |x| packets = PacketFu::PcapPackets.new.read(File.read('sample.pcap')) x.report('PacketFu') do packets.each do |p| packet = PacketFu::Packet.parse(p.data) packet.respond_to?(:ip_saddr) && packet.ip_saddr end end packets = Pcap::Capture.open_offline('sample.pcap') x.report('pcap') do packets.each do |packet| packet.ip? && packet.ip_src end end end
別途PacketFu をプロファイリングしてみても，パケットのparse が遅そうです．
% cumulative self self total time seconds seconds calls ms/call ms/call name 6.44 10.16 10.16 297491 0.03 0.05 StructFu::Int#read 4.46 17.20 7.04 171613 0.04 0.06 PacketFu::EthPacket.can_parse? 3.33 22.45 5.25 70757 0.07 0.15 PacketFu::IPPacket.can_parse? 3.02 27.22 4.77 296710 0.02 0.02 PacketFu.force_binary 3.00 31.96 4.74 44296 0.11 0.18 PacketFu::EthOui#read 2.45 35.83 3.87 12958 0.30 4.20 PacketFu::IPHeader#read 2.30 39.46 3.63 8866 0.41 2.22 PacketFu::TCPPacket#tcp_calc_sum 2.17 42.89 3.43 1149060 0.00 0.00 String#[] 2.09 46.19 3.30 17732 0.19 1.64 PacketFu::TcpOptions#read 2.09 49.49 3.30 27390 0.12 0.30 PacketFu::TcpOption#read 2.08 52.77 3.28 79465 0.04 0.06 PacketFu::Packet.layer 1.93 55.81 3.04 155600 0.02 0.03 StructFu::Int#to_i 1.84 58.72 2.91 966615 0.00 0.00 Struct#[] 1.83 61.61 2.89 159701 0.02 1.18 PacketFu::Packet.parse 1.80 64.45 2.84 8866 0.32 4.71 PacketFu::TCPHeader#read 1.79 67.28 2.83 278978 0.01 0.03 Struct#force_binary
Time Attack: bgpsimple vs exabgp
お手軽フルルート環境に興味が出て，どの程度お手軽にできるのか試しました．
(参考: Other OSS BGP implementations · Exa-Networks/exabgp Wiki · GitHub)
をざっと見て
ので選ぶと，bgpsimple / exabgp が候補になります．
bgpsimple，Google Code にしかないっぽいんだけど 大丈夫か...
フルルート広告の所要時間が気になる
bgpsimple はbgpdump でMRT table dump をテキスト化すれば入力できるし，exabgp はmrtparser で設定ファイルを出力できます．両方お手軽なんですが，経路広告の所要時間が気になるので計測してみました．
環境
- MacBook Pro (Retina, Mid 2012) + VMWare
- Guest
- 4x Intel(R) Core(TM) i7-3820QM CPU @ 2.70GH
- 2GB RAM
経路受信側は別Hypervisor のfirefly．ボトルネックにならないよう，経路はすべてreject する設定．
結果
| bgpsimple | exabgp | |
|---|---|---|
| ピアが上がるまで | 数秒 | 3'59" |
| フルルート広告し終わるまで | 2'39" | 1'15" |
| clear bgp 後，フルルート広告し終わるまで | 2'34" | 2'57" |
bgpsimple のほうがトータル速そう．exabgp は設定ファイルをload → parse するのに4分もかかるため，全体として2倍遅いです．
注意
bgpsimple を使うときはholdtimer を長く
bgpsimple は経路を広告し終わるまでKEEPALIVE メッセージを送らないため，経路広告が終わるまえにHold Timer Expire する可能性が高い．
exabgp は適宜KEEPALIVE してくれます．
bgpsimple は，経路リストの全エントリーについて広告
bgpdump -m によってMRTをテキスト変換してbgpsimple に入力しますが，もとのMRT には複数neighbor 分の経路が保存されています．そのため，テキスト変換された経路リストには同じprefix の経路が複数含まれている場合があります．これを順次UPDATE メッセージとして送信すると，対向のfirefly では後に受け取ったpath だけがAdj-RIBs-In に残ります．
ムダですね．
exabgp はMRT ファイル上で先に現れた経路のみ広告
mrtparser の仕様により，prefix が同じであれば先に読まれたpath のみUPDATE メッセージとして送信します．ムダはありませんが，bgpsimple で経路広告した場合と比べて 対向のAdj-RIBs-In の中身が変わってくることに注意です．
HipChat ゲストアクセス時も履歴を保存したい
HipChat は無料プランでもゲストを招待できて便利だけど，招待された側は履歴をたどれなくて不便．
- 自分がオフラインだった期間の履歴は読めない
- 前回ゲストとして発言した自分の履歴も読めない
- タブを閉じたり，リロードしても消える
毎回まっさらな状態から始まって「前回ログインしたA さん」と「今回ログインしたA さん」を別人として扱うのは，サービスとしてまっとうな実装に見える．
Chrome Extension でなんとかした
でも不便なので，Chrome Extension 作った．
自分がオンラインだった期間の履歴を，Chrome が自動保存して 次回ログイン時に復元する．
私の環境だとうまく動いているけど，beforeunload をフックしていて，場合によっては自動保存の前にログアウトが走ってしまって動かないかもしれない．その場合はご連絡ください．
Guest access to HipChat
HipChat is a cool chat service which enables "guest mode" even in a free plan, but its security policy is sometimes annoying.
- Chat history never show up, if it was done while a guest was offline.
- History is always gone after logging in again, even the guest's words.
- Closing or reloading HipChat tab mistakenly causes a history blackout.
This behavior looks secure enough as it's complicated for the service to identify a guest every time and display only visible chat history with no security risk.
Auto-save and restore in browser side
HipChat Pin is a Chrome extension which automatically saves chat history in guest mode and restores when logging in next time.
Note that it has a potential timing issue of beforeunload callback. Please contact me if it doesn't work in your Chrome. I have some ideas to fix it.
古いメールを全文検索できるよう保存する
昔からのメールが溜まってて，検索できる状態で置いときたい．
どんな検索エンジンを使うのがいいかを検討した．
ざっくり言うと
Xapian をバックエンドとするmu でインデックスして，サーバーサイドでmu4e をつかって検索するのがよさそう．
やりたいこと
- 古いメールは，普段目に触れないようにしたい
- 検索したい
- 検索するのはまれなので，常駐プロセスを増やしたくない
候補
- クライアント側で検索
- Mail.app
- Thunderbird
- サーバー側で検索
- Lucene バックエンドなもの (Solr，Elasticsearch など)
- Xapian バックエンドなもの (mu など)
比較
古いメールの一部を使って試す．
- 930MB
- 2.5万通
クライアント側で検索
(MacBook Pro - Retina, Mid 2012)
慣れたメールアプリで検索できるが，インデックスするのにダウンロードが発生する．筋が悪い方法だけど いちおう試してみる．古いメールはIMAP で取ってくる．
| インデックス時間 | ダウンロード後のフォーマット | ダウンロード後のサイズ | インデックスサイズ | |
|---|---|---|---|---|
| Mail.app | 1時間 | .emlx | 1.3GB | 22MB |
| Thunderbird | 10分 | mbox | 890MB | 55MB |
Mail.app
-
- インデックス時間も保存メールサイズも現実的
サーバー側で検索
(4 core 3.3GHz + 4GB RAM)
- Lucene ベースのSolr，Elasticsearch はdaemon を常駐させないといけないので，今回の用途には合わない
- Java 書いて直接Lucene 叩けばいけそう (やってない)
- dovecot-lucene はアリかも (libc6 ごとアップグレードする必要があって試してない)
- IMAP SEARCH にも対応できる
- メモリを浪費する可能性ある
- いっぽうXapian は常駐しないタイプのフロントエンドが充実
- 今回はmu を試した
| インデックス時間 | ダウンロード後のフォーマット | ダウンロード後のサイズ | インデックスサイズ | |
|---|---|---|---|---|
| mu | 1分 | - | - | 110MB |
インデックスするには
$ mu index -m ~/Maildir
検索するには，CLI から
$ mu find ipv6
$ mu find from:\*gmail subject:ipv6
のようにするか，mu4e をつかう．
$ emacs -f mu4e
気軽でいい感じ．
インデックス時のスワップに注意
メモリをじゃぶじゃぶ使うタイプのソフトウェアっぽくて，
$ mu index --xbatchsize 1000 -m ~/Maildir
のようにしてメモリ使用量を抑える必要があった．
インデックスの最適化
mv .mu/xapian .mu/xapian.old xapian-compact .mu/xapian.old .mu/xapian rm -rf .mu/xapian.old
インデックスサイズが3.4G → 2.2G まで小さくなった．
まとめ
下のどちらかがいいと思う．
- Thunderbird に食わせて，サーバーからメールを消す
- サーバー側に置いといて，mu か mu4e で検索する
JANOG35 に行ってきた (Day3)
JANOG35 に行ってきた (Day2) に引き続き，JANOG35 レポート．
ほぼ毎回行ってるイベントで，インターネットに関するネットワーク寄りの知見を得られる．参加者はネットワークエンジニア中心．
気になったセッションをいくつか紹介しようと思う．
ところで，この日は駅からこんなバスで送迎してもらった．
ロンドンバス！なぜ！ pic.twitter.com/sjKtfxyhuF
— K (@ponytail_68) January 16, 2015すごい目立ってました．．．ご通行のかたも「なぜ！」ってなるわ． イベントのホストさん曰く「いや，たまたまバス会社が持ってたんです」なぜこんなの持ってる．．．
JANOG35会場ネットワークに関して
JANOG35 では，ホストさんとconbu プロジェクトに会場ネットワークを提供していただきました．すごく快適でした！ありがとうございました．
このセッションでは，会場ネットワークを設計 / 構築するにあたり conbu が何を目指して，どうネットワークを作ったかが紹介されている． 知見が溜まっているようで，興味があるひとは結構いそう．
やりたいこと
- 会場側にすでにあるルーターは家庭用のものが多いが，トラブルの原因になりがち
- NAT テーブルが小さい
- 設定を変えられない
- 会場に持ち込むハードウェアを少なくしたい
どうやったか
- 会場からのtraffic を全部VPN でくるむ
- 1つの大きな通信に見えるから，会場ルーターにやさしい
- 他方のVPN 終端はクラウド環境 (物理かも？) にあって，そこからInternet に抜ける
- サーバー類はすべてクラウド環境側に置く
こうすることで「会場が変わっても，現地セットを持っていくだけで簡単に会場ネットワークが構築できるし，事前のテストも半日程度になる」とのこと．
conbu の背景
イベントが多い首都圏などでは，会場ネットワーク運営のニーズはかなりありそう． 「conbu ってなに？」という方には，JPA Thanks CONBU トークセッション のときのスライドをどうぞ．
BGP Flowspec(RFC5575)
タイトルから想像しづらいが，Arbor Networks が出しているDDoS トレンドレポート(ATLAS Q3 2014 DDoS Attack Trends みたいなやつ) を解説付きで説明してくれているので参考になる．
このセッションの主旨は「DDoS を止めるためにBGP Flowspec を使えるかも．なのであらためて紹介します」
感想
- RFC5575 自体はけっこう古くて，2009 年にpublish されたもの
- 私の印象ではあまり注目されてなかったのだが，なぜ今Flowspec を取り上げたのか気になった (が，聞くの忘れた)
セッション中では「Intra-AS ルーティングで使う想定」と言っていたが，RFC を読むとInter-AS もスコープ内に見える
Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.経路のoriginator がFlowspec spec のoriginator である必要がありそう
A flow specification NLRI must be validated such that it is considered feasible if and only if: a) The originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification.https://tools.ietf.org/html/rfc5575#page-14
便利につかうために議論したいことはたくさんあって，たとえば
- Transit AS がFlowspec を追加 / 変更したい
- Flowspec NLRI を消す = 広報しないことはできそう
- 逆に，出したFlowspec をTransit AS に操作されたくない
- Flowspec を受け取った側が，ポリシーに応じてFlowspec をpermit / deny したい
のような要望がある気がする．(関連I-D 読んでなくて，現状どうなってるのか分かってません)
- Transit AS がFlowspec を追加 / 変更したい
当世MVNO事情
MVNO 事業者 3社のサービス開発の裏側，ネットワークの紹介，トラブル事例，悩みごとの紹介．いわゆる「格安SIM」の裏側の話．
- OCN Mobile One
- IIJmio
- mineo
ネットワーク構成
- MNO とL2 接続することが多い
- 帯域制御など，付加価値をつけやすい
- 他には回線卸，L3 接続がある
- MVNO 事業者は，P-GW / GGSN / PCRF / PCEF を自社で運用
- IIJ ではRCRF(DCCA) を内製
サービス全般
- IIJmio だと，LTE でIPv6 を使える端末がある
- IPv6 利用率: 1.97%
- MNO のtraffic ピークは夜だが，IIJmio のピークはランチタイム
- MNO との棲み分けが今後のキモ
- MVNO 同士の競争は終焉に向かっているように思える
- 端末検証たいへん
- iOS8 にしたら使えなくなった！ とか
- 降ってくるキャリアプロファイルの中身が事前に分からない
- サービスのbackend を作るのが大変．あと交換機高い
- MVNO 全体で，シェア1% とか
- 欧米では10% ほど
感想
RPKIやってみませんか?
GREE のラボ環境でOrigin Validation をやってみた結果と課題の紹介．是非RPKI やってみよう！ というメッセージ．
- Validation を集中的に Route Reflector でやろうとしたが，できなかった
- iBGP peer では動作しない
- INVALID になってもログに残す機能がない
- ルーターのリブート時の動作が気に入らない
- ゴールはBGPSEC = Origin Validation + Path Validation
- ルーターはROA の正当性を確認できないので，信頼できるROA キャッシュとセキュアなトランスポートを使うべき
- Origin Validation だけでは対処できない問題も起こっている
- bitcoin を不正に増やすためにroute hijack が使われた が，どうやら配下にAS を作ってhijack したっぽい
- Path Validation が必要なケース
- public ROA cache もあります
- ROA キャッシュの位置について
- IX にpublic なものがある．でも最終的には自社ネットワーク内に置くことが望ましい
- ROA キャッシュの位置について
- JPNIC でROA 作成ツール作り込んでます！
感想
- 簡単な設定で動くので，対応ルーターがあれば試してみると面白いと思う
- ルーティングを変えずに VALID / INVALID / UNKNOWN をマークするだけ，とか
- 中央集権的にvalidate できればいいけど，BGP でできるんだろうか…
- validate するだけなら，もちろんできる
- ルーティングに適用しようとすると，AS border では「INVALID な経路をreject しない」ってことだから そいつが使われる可能性あるんでは
- ルーティングに適用しようと思うとハードルが上がる
- AS border ルーターへの投資
- 第三者 (prefix オーナーやRIR / LIR など) の過失によるトラブル増 -> カスタマーサポートコスト
- DNSSEC と同じ構図
Path Validation で検証できるのは「その経路が AS_PATH どおりに伝搬してきたこと」だと理解してるんだけど，bitcoin のケースを検知するには「Path Validation できない経路をINVALID 判定」しないといけなくて，それはBGPSEC 普及率がかなり高くないとダメなのでは
- 最近の議論を追ってないので，間違えているかもしれません．その際にはご指摘いただけるとうれしいです
JANOG35 に行ってきた (Day2)
先日，JANOG35 というネットワーク系イベントに行ってきた．Day1 は参加してない．
ほぼ毎回行ってるイベントで，インターネットに関するネットワーク寄りの知見を得られる．参加者はネットワークエンジニア中心．
気になったセッションをいくつか紹介しようと思う．
運用から見た研究、研究から見た運用
趣旨は
stateman: A network-state management service
- SIGCOMM2014
- Microsoft
ネットワーク運用の自動化サービス
- OS アップグレード，設定変更，TE
- タスクを渡すと自動で
- タスク間の依存関係を解決
- スケジューリング
- 実行
- 確認
をやってくれる
Azure 内で稼働中
Revisiting Routing Control Platforms with the eyes and muscles of Software-Defined Networking
- SIGCOMM2012
- SDN controller にeBGP を実装し，inter-AS ルーティングを実現しようという話
Google B4: Experience with a Globally Deployed Software Defined WAN
- SIGCOMM 2013
- "before" のように発音するらしい
SDN をつかってWAN 回線の有効利用を実現しました，という話
Google 内で稼働中
- 30~40% だった平均回線利用率が，多くの回線で100% 近くまで使えて平均でも70% になった
SDX: A software Defined Internet Exchange
- SIGCOMM2014
- SDN をIX に適用しようという話
- ポリシー記述言語を作り，OpenFlow に適用する
- multi-latral peering のようなアーキテクチャ
- 利用例
- アプリケーション単位でpeering
- inbound traffic 制御
- LB
- anycast で吸いこんで，dst IP address を書き換える
- firewall，ddos mitigation
感想
ネットワークに話題を限定するので「まあまあ枯れているこの技術，なんで普及しないの？ 問題はなんだろう？」「困っていることがあるんだけど，どうしたらいいと思う？」といった運用面での問題解決が中心になる．
事業者間で協調しないとネットワーク全体として動かないので 運用についてガッツリ話すのはいいことなんだけれど，ステークホルダーが多すぎて長期的に取り組むことになる = その場で解決しなかったり，ヒントすらなくてモヤモヤ感が残る．
一方で，技術的に「スゲェ」と思う新しいネタはワクワクできるし，わかりやすい． キーワードを拾うだけでもためになるので，こういうセッションはありがたい．
なぜ、IPv6 対応したくないのか
10年以上同じ話題について議論しているが，主体がコンテンツ事業者に移ってきた．
からみたIPv6 の話．シンプルに言うと
- IPv6 を導入するメリットがない
- サービスに付加価値をつけられる，という類のものじゃない
- ユーザーからの要望がない
- デメリットはある
- 投資，開発コスト，ユーザーサポートコストが増える
最後の登壇者，さくらインターネットは 全サービスでIPv6 ready だそう．すごい．
IPv6 後押し意見 (参加者から)
- IP 放送，VoD でIPv6 を使っている
- 余裕のあるaddressing ができるから
- IPv4 = CGN に頼るという構図になるが，NAT の制約のせいで使えないサービスがあるかも
- WebRTC とか大丈夫？
- 発展途上国ではIPv6 しか選択肢がない
- IoT を考えると，IPv6 スタックしかないデバイスが出るかもしれない
- 個別にアドレスがつくと，TLS のための証明書を発行しやすい
- 試行錯誤が必要なので，ユーザーが少ないうちから始めて知見を溜めたい
- IPv6 アドレスは取得しやすい
感想
長いことIPv6 の議論をしているが，主体が徐々に変わっている．
- IPv4 アドレス枯渇が遠い未来だったころは，Transit ISP の問題だった (~2008)
- どうdual stack を設計/運用する？ とか
- IPv4 アドレス枯渇が目前になって，Access provider ISP の問題になった (2008~2012)
- ISP でIPv6 の目途がたったら，サーバーインフラ事業者，モバイルキャリアの問題になった (2012~)
日本ではこんなかんじの経緯だと思う．
私は10年ほどISP + IX でネットワークエンジニアをやっていたが，「無理にIPv6 推進しなくていいのに」というスタンス．「どっちでもいいなら，IPv6 やろうよ」とか「知らないのはヤバいから情報収集しとこう」レベルのことは言うが，基本 「必要になったらやればいい」と思っている．
なので，最後に残ったコンテンツ事業者は「次，おまえの番ね」と言われるかもしれんが，まあ継続的に検討してタイミングがきたら着手すればいいんじゃないかな．CGN やIPv6/IPv4 トランスレーターを運用している事業者にとっては，移行期が長くなると辛いかもしれないが．
ただ，IPv6 でサービスしていないのに「ユーザーがIPv4 ばっかり」というのはおかしいので，ときどきIPv4/IPv6 ともにアクセスできるダミーURL を踏ませるとかして，IPv6 潜在ユーザー数を計測しておくといいかもしれない．
GnukトークンでSSH
SSH 用の鍵をUSB トークンに保存しておいて, two-factor auth できるよ！という話
オープンなライセンス
- hardware design: Creative Commons 3.0
- firmware: GPLv3
面白そうだったのに，見せてもらうの忘れた！
DNSの可用性と完全性について考える。
DNSSEC を導入するpros / cons と，運用して取れた統計データの紹介．
- ccTLD，gTLD の70% 以上は署名している
- cache DNS のうち，4.76% "も" DNSSEC validate している*1
QTNet がcache DNS でDNSSEC validation を運用した経験では
- validation fail するquery は0.05%
- ユーザーからの問い合わせは，ほとんどない
会場サーベイでは「DNSSEC 導入することで可用性が下がる」のを気にするひとが多数派 (2/3 程度)
- DNSSEC validation 環境下でも，NS にcache poisoning されたら乗っ取られる
- cache poisoning を100% 検知できるわけではない
懇親会
かなりいい会場でマグロ解体のような出し物もあり，日本酒バーとか富士通レタスも堪能しました． ホストの特定非営利活動法人ふじのくに情報ネットワーク機構さんありがとうございました！
懇親会なう。 #janog pic.twitter.com/IIF62lSXJJ
— 池田武 (@zeldaudon) January 15, 2015マグロの解体ショー！ #JANOG pic.twitter.com/kFm1hSa1fz
— Yamaha SoundNetwork (@yamaha_sn) January 15, 2015昨晩の #janog 35 Meeting懇親会でいただいた、富士通製！レタス。朝ごはんに美味しくいただきました。そのまま食べてもかなりいける。 pic.twitter.com/dFVaceMpys
— kinoSi / きのし (@i7kinosi) January 16, 2015