無印吉澤(※新エントリはhatenablogに掲載中)

吉澤です。このサイトではIPv6やP2Pなどの通信技術から、SNSやナレッジマネジメントなどの理論まで、広い意味での「ネットワーク」に関する話題を扱っていたのですが、はてなブログに引っ越しました
最新の記事は http://muziyoshiz.hatenablog.com/ でご覧ください。
RSSフィードは http://muziyoshiz.hatenablog.com/feed に手動で変更するか、
Feedly or Live Dwango Reader を使っている方は以下のボタンで変更ください。
follow us in feedly Subscribe with Live Dwango Reader
«前の日記(2004/12/20) 最新 次の日記(2004/12/29)» 編集

2004/12/25

[NAT][P2P]UDP hole punchingとSkype

[skype]skypeの分析論文(Tomo’s HotLine)
http://toremoro.tea-nifty.com/tomos_hotline/2004/12/skypeskype_1.html

最近、Tomo's HotLineにて紹介されたSkypeの分析論文"An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol"とそれに対する反応を読んでいて、どうも「UDP hole punching」という用語の定義が曖昧なまま使われているように感じましたので、一度ここで整理してみます。

UDP hole punchingという単語がIETF(Internet Engineering Task Force)の文章に登場したのは、僕の知る限りではdraft-ford-natp2p-00(期限切れ)です。このインターネットドラフトの最新稿"Peer-to-Peer(P2P) communication across Network Address Translators(NATs)"(draft-ford-midcom-p2p-03)(12月26日現在)の3.3節"UDP hole punching"では、UDP hole punchingについて以下のように書かれています。

The "UDP hole punching" technique is the most popular and effective
of all the techniques described thus far. UDP hole punching
relies on the properties of common firewalls and cone NATs to allow
appropriately designed peer-to-peer applications to "punch holes"
through the NAT device and establish direct connectivity with each
other, even when both communicating hosts lie behind NAT devices.
This technique was mentioned briefly in section 5.1 of RFC 3027 [NAT-
PROT], described in [KEGEL], and used in some recent protocols
[TEREDO, ICE].

この定義の前半を読んだだけでは、UDP hole punchingという用語の定義が以下の2者のどちらであるのかが明確ではありません。

  • NATの背後にいるピアが内側からUDPパケットを送信して、NATに穴を開ける(=NATが応答のUDPパケットを転送できるようにする)こと
  • NATの背後にいるピアが内側からUDPパケットを送信してNATに穴を開け、NATの中にいるピア同士が第三者を介さずにUDPで通信できるようにすること

しかし、このインターネットドラフトでは、その後で

  • Peers behind different NATs(3.3.1節)
  • Peers behind the same NAT(3.3.2節)
  • Peers separated by multiple NATs(3.3.3節)

と、両側のピアがNATの背後にいる例を挙げています。また、このインターネットドラフトから参照されているRFC3027[NAT-PROT]NAT and Peer-to-peer networking[KEGEL]でも同様の例を取り上げているため、僕はUDP hole punchingの定義は後者であると思っていました。Skypeの分析論文に対する反応を見ていると、以下のサイトの方も同様に考えていたようです。

steps to phantasien t(2004-12-19)
http://www.dodgson.org/omo/t/?date=20041219#p01

一方、前述のTomoさんのエントリでは、UDP hole punchingの定義として前者を選択しています。上記の例では「片側のピアだけがNATの背後にいる」というパターンが触れられていませんが、この場合も、まずNATの背後にいるピアが先にUDPパケットを送信するという特殊な動作が必要になるため、これをUDP hole punchingと呼ぶ事も理に適っていると思います。元々の定義が曖昧なので、どちらが正しいとも言い切れないところです。

----

ただ、今回はUDP hole punchingという単語の定義が曖昧なために、同じSkypeの分析論文を読んでも「SkypeはUDP hole punchingをしている」と解釈する人と、「SkypeはUDP hole punchingをしていない」と解釈する人に別れてしまったのが問題です。そこで、誤解を防ぐために、Skypeの分析論文に書かれていることを「UDP hole punching」という単語を使わずに書き直すと、以下のようになります(4.4節"Call Establishment and Teardown"のFigure 10)。

  • 呼び出す側のピアがport-restricted NATの背後にいて、呼び出される側のピアがグローバルIPアドレスを持っている場合、

    • ピア間の音声通信は、メディアプロクシとして動作するピア(図中のN5)によってリレーされる
    • 呼び出し側のピアは、N5に向かってUDPパケットを送信して、呼び出し側にあるNATに穴を開ける(UDP hole punchingの前者の定義)

つまり、この実験結果を信じるなら「少なくとも一方のピアがNATの背後に居る場合は、第三者によるリレーが発生する」ということなので、全セッションの中で音声通信がリレーされる割合はかなり高そうな気がします。Skypeが動作しているピア(日本/世界)の何割くらいがNATの背後にいるかについてはデータがないので、実際の所はよくわかりませんけどね。

しかし、これだけSkypeがリレーに頼っていそうだとなると、動画をサポートしたときにSkypeネットワークが保つのかどうかがやや不安です。

参考サイト:P2Pとファイアウォール
http://homepage3.nifty.com/toremoro/p2p/firewall.html

----

(2004-12-27追記)
draft-ford-midcom-p2p-03の3.3.4節を見ると「UDP hole punchingはCone NATのようなP2P-friendly NATでしか動作しない」という記述があるので、やっぱり「UDP hole punching」という単語を使う時は後者の定義で使わないと混乱しそうです。

[]

2004|06|07|09|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|09|10|11|
2009|01|02|03|04|05|07|08|10|
2010|01|03|
2015|03|
スパム対策のため、60日以上前の日記へのコメント及びトラックバックは管理者が確認後に表示します。
また、この日記に無関係と判断したコメント及びトラックバックは削除する可能性があります。ご了承ください。