LGTM

Looks Good To Me

JANOG35 に行ってきた (Day2)

networking

先日，JANOG35 というネットワーク系イベントに行ってきた．Day1 は参加してない．

ほぼ毎回行ってるイベントで，インターネットに関するネットワーク寄りの知見を得られる．参加者はネットワークエンジニア中心．

気になったセッションをいくつか紹介しようと思う．

運用から見た研究、研究から見た運用

趣旨は

  • google，facebook がやってるような，研究 <-> 開発 <-> 運用 のいい具合のサイクルをコミュニティ内で回したい
  • 今回は研究分野から，SIGCOMM で見つけた新しいネタの紹介

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 の特殊な環境が前提になっている
      • app は自分でrate limit できる
      • app の優先度 + 必要帯域があらかじめ分かる
      • POP 数が少ない
    • コントロールプレーンはquagga + OpenFlow Controller (OFC)
      • app クラスターごとにAS を割り当て，quagga とBGP を張る
      • POP 間でもquagga がBGP を張る
      • OFC 上のTE Agent が，app ごとのtraffic をlink 上に予約する
      • OFC は，OpenFlow スイッチとOpenFlow プロトコルを話す
    • Paxos による冗長化
    • スイッチは自社開発

  • 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~)
    • hosting，クラウド事業者
    • このころ，既にISP はIPv6 ready になっていた
    • ユーザー側にIPv6 が振られ始めても，コンテンツ側がIPv4 のためtraffic は小さい
    • コンテンツ事業者では，問題にもなってない

日本ではこんなかんじの経緯だと思う．

私は10年ほどISP + IX でネットワークエンジニアをやっていたが，「無理にIPv6 推進しなくていいのに」というスタンス．「どっちでもいいなら，IPv6 やろうよ」とか「知らないのはヤバいから情報収集しとこう」レベルのことは言うが，基本 「必要になったらやればいい」と思っている．

なので，最後に残ったコンテンツ事業者は「次，おまえの番ね」と言われるかもしれんが，まあ継続的に検討してタイミングがきたら着手すればいいんじゃないかな．CGN やIPv6/IPv4 トランスレーターを運用している事業者にとっては，移行期が長くなると辛いかもしれないが．

ただ，IPv6 でサービスしていないのに「ユーザーがIPv4 ばっかり」というのはおかしいので，ときどきIPv4/IPv6 ともにアクセスできるダミーURL を踏ませるとかして，IPv6 潜在ユーザー数を計測しておくといいかもしれない．

GnukトークンでSSH

SSH 用の鍵をUSB トークンに保存しておいて, two-factor auth できるよ！という話

面白そうだったのに，見せてもらうの忘れた！

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% 検知できるわけではない

懇親会

かなりいい会場でマグロ解体のような出し物もあり，日本酒バーとか富士通レタスも堪能しました． ホストの特定非営利活動法人ふじのくに情報ネットワーク機構さんありがとうございました！

*1:http://validator-search.verisignlabs.com/