Network Working Group J. Rosenberg Request for Comments: 3581 dynamicsoft Category: Standards Track H. Schulzrinne Columbia University August 2003 対称応答ルーティングのためのセッション開始プロトコル(SIP)拡張 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するも のである。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文 書の配布は無制限である。 著作権表記 Copyright (C) The Internet Society (2003).All Rights Reserved. 概要 セッション開始プロトコル(SIP)は、UDP、TCP上などで動作する。UDPで使用 される場合、リクエストに対する応答は、リクエストの送信元のソースアド レス、および、リクエストの先頭のViaヘッダーフィールド値に書かれてい るポートへ返される。多くの場合、特に、クライアントがNetwork Address Translator(NAT)の内側にいる場合は、この動作は妥当ではない。この拡張 は、Viaヘッダーフィールド用の新規のパラメータ「rport」を定義する。こ れによって、クライアントは、リクエストが生成されたソースIPアドレスお よびポートへ、応答を返すように、サーバへ要求することができるように なる。 Rosenberg & Schulzrinne Standards Track [Page 1] RFC 3581 Symmetric Response Routing August 2003 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 述語規則 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. クライアントの動作 . . . . . . . . . . . . . . . . . . . . . 3 4. サーバーの動作 . . . . . . . . . . . . . . . . . . . . . . . . 4 5. 構文 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. セキュリティの考慮 . . . . . . . . . . . . . . . . . . . . . . 6 8. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. 問題定義 . . . . . . . . . . . . . . . . . . . . . . . . 8 9.2. 出口戦略 . . . . . . . . . . . . . . . . . . . . . . . . 8 9.3. 本仕様がもたらす脆弱性 . . . . . . . . . . . . . . . . . 9 9.4. 長期的解決のための要件 . . . . . . . . . . . . . . . . . 10 9.5. 既存のNAPTボックスに関する問題 . . . . . . . . . . . . . 10 10. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . 11 11.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . 11 12. 知的所有権表記および著作権表記 . . . . . . . . . . . . . . . . 11 13. 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . 12 14. 完全な著作権表記 . . . . . . . . . . . . . . . . . . . . . . . 13 1. はじめに セッション開始プロトコル(SIP)(参考文献[1])は、UDP、TCP上などで動作す る。UDPで使用される場合、リクエストに対する応答は、リクエストの送信元 のソースアドレス、および、リクエストの先頭のViaヘッダーフィールド値に 書かれているポートへ返される。結果として、「組み合わせた」方法で応答 の送信先を算出することになる。情報の半分(具体的にはIPアドレス)はIPパ ケットヘッダーから取得され、また、もう半分(具体的にはポート)はSIPの メッセージヘッダーから取得される。SIPは、サーバーがすべてのメッセージ をリッスンできるように、1個のIPアドレスとポート上で、この方法でリクエ ストと応答を操作する。これは、スケーラビリティの改善に役立つ。だが、 多くの場合、特に、クライアントがNATの内側にいる場合は、この動作は妥当 ではない。この場合、リクエストで確立されたバインディングとマッチしな いために、応答は適切にNATを越えられない。 さらに、現在のところ、クライアントが応答を確認して、サーバーが応答に 対応するリクエストで確認したソースポートを、クライアントが特定する方 法はない。現在、SIPは、サーバーがリクエストで確認したソースIPアドレス をクライアントに提示しているが、ポートはそうではない。ソースIPアドレ スは、応答の先頭にあるViaヘッダーフィールド値の「received」パラメータ で伝達される。この情報は、基本的なNAT越え、デバッグの用途、マルチホー Rosenberg & Schulzrinne Standards Track [Page 2] RFC 3581 Symmetric Response Routing August 2003 ムホストのサポートに有用なことがわかっている。だが、ポート情報がなけ れば不完全である。 この拡張は、Viaヘッダーフィールド用の新規のパラメータ「rport」を定義 する。これによって、クライアントは、リクエストが生成されたソースIPア ドレスおよびポートへ、応答を返すように、サーバへ要求することができる ようになる。「rport」パラメータは、IPアドレスではなくポート番号を含む 点を除くと、「received」パラメータに類似している。 2. 述語規則 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC2119のBCP 14(参考文献[5]) に記載されるとおりに解釈されるべきであり、CPL準拠の実装のための実装レ ベルを示すものである。 3. クライアントの動作 ここで規定されているクライアントの動作は、SIP(RFC3261/参考文献[1])の セクション18.1で定義されているトランスポート処理に影響を与える。 本仕様に準拠するクライアント(UACとプロキシを含む)は、生成するリクエス トにある先頭のViaヘッダーフィールド値に「rport」パラメータを含めても よい[MAY]。このパラメータには値を設定してはならない[MUST]。このパラ メータは、この拡張をサポートしていることと、トランザクションに要求す ることを、サーバーに示すためのフラグとして機能する。 クライアントがリクエストを送信するとき、リクエストがUDPを使用して送信 される場合には、クライアントは、リクエストのソースIPアドレスとソース ポートと同じIPアドレスとポート上で、応答を受信できるように備えなけれ ばならない[MUST]。また、下位互換性のために、クライアントはSIP(参考文 献[1])のセクション18.1.1で規定されているように、先頭のViaヘッダー フィールド値のsent-byフィールドで示されているポートについても、応答を 受信できるように備えなければならない[MUST]。 クライアントとサーバーの間にNATがある場合、リクエストはNAT内のバイン ディングを生成(または更新)する。このバインディングは、クライアントが 応答を受信できるように、トランザクションの継続期間中は存在し続けなけ ればならない。多くのUDP NATバインディングは、約1分のタイムアウトを 持っていると思われる。これは非INVITEトランザクションの継続期間を上 回る。したがって、非INVITEリクエストへの応答は、バインディングが存在 している間であれば、受信される。INVITEトランザクションが完了する時 間は、任意の長さである。結果として、バインディングは、最終応答を受信 する前に期限切れになる可能性がある。バインディングの状態を保つため に、クライアントは20秒くらいの間隔でINVITEを再送信すべきである [SHOULD]。こうした再送信は、暫定応答の受信後でも、実行する必要がある。 Rosenberg & Schulzrinne Standards Track [Page 3] RFC 3581 Symmetric Response Routing August 2003 UAは、NATにおける実際のバインディングのライフタイムを特定するために、 RFC3489(参考文献[4])のセクション10.2にある、バインディングのライフタ イム検出アルゴリズムを実行してもよい[MAY]。それが1分以上になる場合、 クライアントは、検出されたライフタイムの半分まで、リクエスト再送信の 間隔を増やすべきである[SHOULD]。それが1分に満たない場合、クライアン トは、検出されたライフタイムの半分まで、リクエスト再送信の間隔を減ら すべきである[SHOULD]。バインディングのライフタイムの検出は信頼できな い可能性がある、ということに注意。RFC3489(参考文献[4])のセクション14.3 を参照のこと。 4. サーバーの動作 ここで規定されているサーバの動作は、SIP(参考文献[1])のセクション18.2 で定義されているトランスポート処理に影響を与える。 本仕様に準拠するサーバー(プロキシまたはUASであり得る)がリクエストを受 信すると、先頭のViaヘッダーフィールド値を検査する。このViaヘッダーフ ィールド値に値のない「rport」パラメータが含まれる場合、リクエストの ソースポートへ、このパラメータの値を設定しなければならない[MUST]。こ れは、サーバーが先頭のViaヘッダーフィールド値へ「received」パラメータ を挿入する方法と類似している。実際に、サーバーは、リクエストの送信元 であるソースIPアドレスを含む「received」パラメータを、たとえそれが 「sent-by」コンポーネントの値と同じであっても、挿入しなければならない [MUST]。この処理はトランスポートプロトコルと無関係に行われることに注 意すること。 サーバーが応答送信を試みるとき、その応答の先頭にあるViaヘッダーフィー ルド値を検査する。「sent-protocol」コンポーネントが、UDPのように信頼 できないユニキャスト送信プロトコルを示し、さらに、「maddr」パラメータ はないが、「received」パラメータと「rport」パラメータの両方がある場 合、「received」パラメータに列挙されるIPアドレス、かつ、「rport」パ ラメータにあるポートへ、応答を送信しなければならない[MUST]。この応答 は、対応するリクエストを受信したのと同じアドレスとポートから送信しな ければならない[MUST]。これによって、事実上、SIP(参考文献[1])のセク ション18.2.2の手順2と3の間に新しい手順を追加することになる。 対称型(symmetric)NATを越えるために、応答は、リクエストを受信したのと 同じアドレスとポートから送信しなければならない。サーバーは、複数の ポートまたはインターフェース上でリクエストをリッスンしている場合、リ クエストをどこで受信したのかを記憶しておく必要がある。ステートフルプ ロキシの場合、トランザクションの継続期間、この情報を保存しているため、 問題ではない。だが、ステートレスプロキシは、リクエストとその応答間で ステートを保持しないため、リクエストを受信したアドレスをポートを記憶 できない。本仕様を正しく実装するために、ステートレスプロキシは、リク エストの送信先アドレスとポートを、挿入するViaヘッダーフィールド値にエ ンコードすることができる。応答が届くと、この情報を展開して使用し、応 答を転送(forward)することができる。 Rosenberg & Schulzrinne Standards Track [Page 4] RFC 3581 Symmetric Response Routing August 2003 5. 構文 「rport」パラメータの構文は以下のとおりである。 response-port = "rport" [EQUAL 1*DIGIT] これはViaヘッダーフィールドパラメータの既存の定義を拡張するため、BNF は以下のようになる。 via-params = via-ttl / via-maddr / via-received / via-branch / response-port / via-extension 6. 例 クライアントは、一部が以下のようなINVITEをプロキシサーバーへ送信する。 INVITE sip:user@example.com SIP/2.0 Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff このINVITEは、ソースポート4540、ソースIPアドレス10.1.1.1で送信される。 プロキシは192.0.2.2(proxy.example.com)にあり、ポート5060と5070の両方 をリッスンしている。クライアントはリクエストをポート5060へ送信する。 リクエストはプロキシへ到達する途中でNATを通過するため、ソースIPアドレ スは192.0.2.1、またソースポートは9988のように見える。プロキシはリクエ ストを転送するが、その前に、以下のようにプロキシされるリクエストの 「rport」パラメータに値を追加する。 INVITE sip:user@example.com SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77 Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff このリクエストは、以下のようにプロキシに到達する応答を生成する。 SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77 Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff プロキシは先頭のViaヘッダーフィールド値を取り除き、その次の値を検査 する。この値には、「received」パラメータと「rport」パラメータの両方が 含まれている。サーバーはセクション4で規定される規則に従って、以下のよ うに、応答をIPアドレス192.0.2.1、ポート9988へ送信し、かつ、192.0.2.2 上のポート5060から送信する。 Rosenberg & Schulzrinne Standards Track [Page 5] RFC 3581 Symmetric Response Routing August 2003 SIP/2.0 200 OK Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988 ;branch=z9hG4bKkjshdyff このパケットは最初のリクエストで生成されたバインディングと一致する。 そのため、NATはこのパケットの送信先アドレスを元の10.1.1.1へ書き替え、 また、送信先ポートを元の4540へ書き替える。NATは、そのアドレスとポート 上で応答をリッスンしているクライアントへ、この応答を転送する。このク ライアントは適切に応答を受信する。 7. セキュリティの考慮 サーバーが本仕様を使用する場合、送信する応答は、リクエストの送信元で あるソースポートを含むようになった。場合によっては、リクエストのソー スアドレスとポートは機密情報である。機密情報である場合、TLS上のSIP(参 考文献[1])を使用して、リクエストを保護すべきである[SHOULD]。このよう な場合、本仕様は(TCPでのみ機能するため)、いかなる応答ルーティング機能 も提示しない。クライアントには、単に、サーバーが確認する通りのソース ポートに関する情報を提示するだけである。 攻撃者が、man-in-the-middle(仲介者)として振る舞い、クライアントが送信 したリクエストにあるViaヘッダーの「rport」パラメータを修正することで、 クライアントに対するサービスを混乱させようとする可能性はある。このパラ メータを削除すると、NATの内側にいるクライアントは、サービスを受け取れな くなる。このパラメータを追加することは、通常は何も影響はない。当然な がら、攻撃者がman-in-the-middle攻撃を実行できる場合、例えばリクエストを ただ破棄するだけなど、他にもサービスを妨害する方法が多くある。そのた め、この攻撃は重大ではないと思われる。 8. IANA条項 本仕様に関連付けられるIANA条項はない。 9. IAB条項 IABは、Unilateral Self Address Fixing (UNSAF)プロトコル(参考文献[5]) と呼ばれるプロトコル群のクラスを研究してきた。これらのプロトコルによっ て、NATの内側にいるクライアントは、この情報をアプリケーション層プロト コルで使用する用途で、NATが特定のリクエストに割り当てるIPアドレスと ポートを知ることができる。UNSAFプロトコルの一例として、「Simple Traversal of UDP Through NATs (STUN)」(参考文献[4])が挙げられる。 Rosenberg & Schulzrinne Standards Track [Page 6] RFC 3581 Symmetric Response Routing August 2003 クライアントに対して、NAT越しに送信されたパケットのソースIPアドレスと ポートを明かすようなプロトコルはすべて、UNSAFプロトコルである。本仕様 はこの目的で設計されたのではないが、UNSAFプロトコルとして使用すること ができる。応答の先頭にあるViaヘッダーフィールド値の「rport」パラメー タ(本仕様で定義)と「received」パラメータ(RFC3261(参考文献[1])で定義) を使用すると、リクエストを送信するクライアントは、応答を送信するサー バーが確認するのと同じアドレスを知ることができる。 この情報の用法は2つある。1つ目は、登録についてである。NATの別サイドに あるプロキシ/レジストラで登録しようとしている、NATの内側のクライアン トについて考慮する。クライアントは、自身の登録時に、プロキシから送信 されるSIPリクエストをどのアドレスで受信するかを提示しなければならな い。だが、クライアントはNATの内側にいるため、どのインターフェース上の アドレスへも、プロキシは到達できない。クライアントがプロキシが到達可 能なアドレスをプロキシに提示できれば、クライアントは送信されるリクエ ストを受け取れる。本仕様を使用すると、NATの内側にいるクライアントは、 REGISTERリクエストを受信するプロキシが確認するのと同じアドレスとポー トを知ることができる。さらに、クライアントは、Contactヘッダーフィール ドにあるこのアドレスを使用して、新規の登録を実行することができる。これ によって、クライアントは、送信した登録のソースIPアドレスとポートと同じ IPアドレスとポートで、送信されるリクエスト(例えばINVITE)を受信できるよ うになる。この手法が機能するのは、サーバーがREGISTER自体を受信したのと 同じアドレスとポートから、UAにリクエストを送信する場合のみである。 多くの場合、登録が送信されるサーバーはレジストラではなく、プロキシで あり、プロキシは受信後にリクエストをレジストラに送信する。このような 場合、クライアントに対して送信されるすべてのリクエストは、登録が直接 送信されるプロキシを越えなければならない。SIPのPathヘッダー拡張(参考 文献[3])を使用すると、プロキシは、こうしたリクエストのパス上に存在す る必要があることを示すことができるようになる。 2つ目の用法は、レコードルートについてであり、2つのプロキシ間について、 上記と同様の問題を提示する。サーバーへリクエストを転送する、NATの内側 にあるプロキシは、例えば、サーバーが確認するのと同じアドレスを知るた めに、OPTIONSを使用できる。このアドレスは、そのサーバーへ送信されるリ クエストのRecord-Routeヘッダーフィールドへ設定することができる。これ によって、プロキシは、OPTIONSリクエストのソースIPアドレスとポートと同 じIPアドレスとポート上で、そのサーバーからのリクエストを受信できるよ うになる。 こうした考えうる用途から、本文書は参考文献[5]で挙がっている問題を考慮 しなければならない。 Rosenberg & Schulzrinne Standards Track [Page 7] RFC 3581 Symmetric Response Routing August 2003 9.1. 問題定義 参考文献[5]によると、すべてのUNSAF提案は以下について提示しなければな らない。 UNSAF提案で解決できる、固有の、限定された範囲の問題に関する詳細な 定義。短期的な解決は、他の問題を解決するために一般化されるべきでは ない。これが「通常、短期的解決はない」という理由である。 本仕様は主に、リクエストがNAT越しに送信されたときに、SIP応答を受信で きるようにすることを目標としている。この主な用途では、本仕様はUNSAF提 案ではない。だが、この機能の副産物として、本仕様をUNSAFプロトコルとし て使用することができる。この用法では、以下の2つの問題に取り組む。 o クライアントがNATの内側にいる場合、REGISTERリクエストのContact ヘッダーで使用する可能性のあるアドレスを持つクライアントを提示。 o プロキシがNATの内側にある場合、リクエスト中のRecord-Routeヘッダー で使用する可能性のあるアドレスを持つプロキシを提示。 9.2. 出口戦略 参考文献[5]によると、すべてのUNSAF提案は以下について提示しなければな らない。 出口戦略/遷移計画の説明。適切な技術が展開されるにつれて、短期的解 決の多くは、自然と使用されなくなるものである。 SIPワーキンググループは、NAT越しの登録とレコードルートに対応するため に本仕様を使用することは適切ではない、と認識している。後述のように既 知の問題が数多くある。アドレス確定(address fixing)のために本仕様を使 用する可能性を取り除く方法は、アドレス確定のために本仕様を使用する理 由となる可能性がある問題に対して、適切な解決方法を提示することである。 特に、NATが存在する場合の、登録とレコードルートに対する適切な解決方法 を開発する必要がある。この解決方法は、アドレス確定に依存しない。 このような解決方法のための要件は、すでに開発中である(参考文献[6])。 本仕様の実装については、NAT越しの登録とレコードルートに対する、よりよ い解決のために、この研究に従うことが推奨される。 Rosenberg & Schulzrinne Standards Track [Page 8] RFC 3581 Symmetric Response Routing August 2003 9.3. 本仕様がもたらす脆弱性 参考文献[5]によると、すべてのUNSAF提案は以下について提示しなければな らない。 システムを組み込むことで、より「脆弱」になる可能性がある、固有の問 題についての議論。例えば、複数のネットワーク層にあるデータ使用を伴 う手法は、より依存関係が多くなるため、デバッグの試行が増え、遷移が より複雑になる。 本仕様は、アドレス確定のために使用される場合、SIPシステムに対して、以 下のように、何点かの脆弱性を持ち込む。 o UDPの登録に使用される場合、クライアントは、NATのバインディング状態 を保つために、ひんぱんに再登録する必要がある。多くの場合、こうした 登録は、登録の通常の更新間隔よりも多く、100回近く実行される。これ によってシステムの負荷が増大し、スケーラビリティの障害となる。 o クライアントは、登録(またはレコードルート)が越えたNATについて、バ インディングのライフタイムを正確に特定することができない。そのた め、バインディングが期限切れの時間と、次の登録またはOPTIONSの更新 が送信されるまでの間に、到達不可能な期間が存在する可能性がある。こ のため、呼やメッセージ、その他の情報を逃す結果になる可能性がある。 o NATが対称型の系統(参考文献[4])である場合、クライアントが使用できる のは、リクエストの送信先サーバーからリクエストを受信するアドレスの みである。そのサーバーがクラスタ内の複数サーバーの1つである場合、 クライアントはクラスタの他のサーバーからリクエストを受信できない可 能性がある。このため、呼やメッセージ、その他の情報を逃す結果になる 可能性がある。 o NATが対称型の系統(参考文献[4])で、サーバーがクライアントに登録を受 信したのと同じアドレスとポートからリクエストを送信する場合、クライ アントが使用できるのは、リクエストを受信するアドレスのみである。こ のサーバーの動作はRFC3261(参考文献[1])で必須ではないが、実用では一 般的なようである。 o レジストラと、クライアントのREGISTERリクエスト送信先であるサーバー とが同じではない場合、この手法は、サーバーがPathヘッダーフィールド (参考文献[3])を使用するときのみ、機能する。サーバーがPathヘッダー を登録に使用すべきであると決定できる、容易で信頼のおける方法はな い。先頭のViaヘッダーフィールドにあるアドレスがプライベートアドレ スのときにPathを使用すると、通常は機能するが、実際に必要ではないと きでもPathを使用する結果になるかもしれない。 Rosenberg & Schulzrinne Standards Track [Page 9] RFC 3581 Symmetric Response Routing August 2003 9.4. 長期的解決のための要件 参考文献[5]によると、すべてのUNSAF提案は以下について提示しなければな らない。 適切な長期的解決を発見する処理に貢献する、長期的で適切な技術的解決 方法のための要件を特定すること。 セクション9.3に記載されている脆弱性によって、長期的解決のために以下の 要件が導かれる。 クライアントは自身のアドレスを指定する必要はない。登録とレコードルー トは、クライアントに対して、どのアドレスでリクエストを受信するのかを 指定するよう、要求する。適切な技術的解決によって、クライアントは、外 に出るリクエストの送信による接続上で、送られてくるリクエストを受信し たいということを明示的に示すことができるはずである。このように、クラ イアントは自身のアドレスを示す必要はない。 解決方法は複数サーバーの複数クラスタを扱わなければならない。商業上で 配置されたSIPシステムの多くは、サーバーが複数あり、それぞれ、異なるア ドレスとポートにあり、クライアントに対して送られてくるリクエストを操 作する。この場合についての解決方法を具体的に考慮しなければならない。 解決方法は、ネットワーク負荷の増大を伴ってはならない。適切な技術的解 決には、不利益があってはならない。 9.5. 既存のNAPTボックスに関する問題 参考文献[5]によると、すべてのUNSAF提案は以下について提示しなければな らない。 既存の配置されているNAT/NAPTに関する実用上の顕著な問題の影響につい ての議論、および、経験の報告。 執筆の時点でわかっていることは、アドレス確定のために本仕様を使用する ことは、非常に限られているということである。そのため、特に実用上の問 題は起こっていない。 10. 謝辞 この作業へのコメントと貢献に対してRohan MahyとAllison Mankinに謝意を 表したい。 Rosenberg & Schulzrinne Standards Track [Page 10] RFC 3581 Symmetric Response Routing August 2003 11. 参考文献 11.1. 規範となる参考文献 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002. [4] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. 11.2. 有益な参考文献 [5] Daigle, L., Ed., and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [6] Mahy, R., "Requirements for Connection Reuse in the Session Initiation Protocol (SIP)", Work in Progress. 12. 知的所有権表記 IETFは、知的所有権、あるいは本文書に記載される技術の実装または仕様に 関して主張される可能性のある他のいかなる権利についても、有効期間また は範囲に関して、あるいはこのような権利下でどのようなライセンスの範囲 までが利用可能か否かに関して、何ら見解を持たない。また、このような権 利を特定しようともしていない。標準化過程および標準化に関連する文書化 に関するIETFの手順に関する情報は、BCP-11に記載されている。こうした所 有権について、本仕様の実装者あるいはユーザーが公開のために利用可能と された権利請求の複写、および、利用可能とされたライセンスの保証、ある いは、一般的なライセンスまたは許可を取得しようと試みた結果は、IETF事 務局から入手できる。 Rosenberg & Schulzrinne Standards Track [Page 11] RFC 3581 Symmetric Response Routing August 2003 IETFは、この規格を実行するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。これ らの情報については、IETFの事務局長への連絡を請う。 13. 著者の連絡先 Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs Rosenberg & Schulzrinne Standards Track [Page 12] RFC 3581 Symmetric Response Routing August 2003 14. 完全な著作権表示 Copyright (C) The Internet Society (2003).All Rights Reserved. 本記述とその翻訳は複写し他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布す ることができる。しかし、この文書自体にはいかなる方法にせよ、著作権表 示やインターネットソサエティもしくは他のインターネット関連団体への参 照を取り除くなどの変更を加えてはならない。インターネット標準を開発す るために必要な場合は例外とされるが、その場合はインターネット標準化過 程で定義されている著作権のための手続きに従わなければならない。またRFC を英語以外の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネットソサエティも しくはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないとい う保証、商用利用および特定目的への適合性への保証を含め、また、これら だけに限らずすべての保証について、明示的もしくは暗黙的の保証は行われ ない。 謝辞 RFC編集者の職務のための資金は、現在、インターネットソサエティによって 提供されている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Rosenberg & Schulzrinne Standards Track [Page 13]