Network Working Group V. Gurbani
Request for Comments: 5118 Bell Laboratories, Alcatel-Lucent
Category: Informational C. Boultond
Ubiquity Software Corporation
R. Sparks
Estacado Systems
February 2008
Session Initiation Protocol (SIP) Torture Test Messages for
Internet Protocol Version 6 (IPv6)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the code of an IPv6-enabled SIP implementation.
この文書は、IPv6対応のSIP実装のコードを行使し、「拷問」するように設計セッション開始プロトコル（SIP）テストメッセージの例を示します。
Table of Contents
目次
1. Overview ........................................................2
2. Document conventions ............................................2
3. SIP and IPv6 Network Configuration ..............................4
4. Parser Torture Tests ............................................4
4.1. Valid SIP Message with an IPv6 Reference ...................5
4.2. Invalid SIP Message with an IPv6 Reference .................5
4.3. Port Ambiguous in a SIP URI ................................6
4.4. Port Unambiguous in a SIP URI ..............................7
4.5. IPv6 Reference Delimiters in Via Header ....................7
4.6. SIP Request with IPv6 Addresses in
Session Description Protocol (SDP) Body.....................9
4.7. Multiple IP Addresses in SIP Headers .......................9
4.8. Multiple IP Addresses in SDP ..............................10
4.9. IPv4-Mapped IPv6 Addresses ................................11
4.10. IPv6 Reference Bug in RFC 3261 ABNF ......................11
5. Security Considerations ........................................13
6. Acknowledgments ................................................13
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................14
Appendix A. Bit-Exact Archive of Each Test Message ...............15
A.1. Encoded Reference Messages ...............................16
This document is informational, and is *not normative* on any aspect of SIP.
この文書は情報提供であり、SIPのあらゆる側面に* *規範的ではありません。
This document contains test messages based on the current version (2.0) of the Session Initiation Protocol as defined in [RFC3261].
このドキュメントは[RFC3261]で定義されるようにセッション開始プロトコルの現在のバージョン（2.0）に基づいて、テストメッセージを含んでいます。
This document is expected to be used as a companion document to the more general SIP torture test document [RFC4475], which does not include specific tests for IPv6 network identifiers.
この文書は、IPv6ネットワーク識別子の特定のテストを含んでいない、より一般的なSIP拷問テスト文書[RFC4475]に仲間ドキュメントとして使用されることが期待されます。
This document does not attempt to catalog every way to make an invalid message, nor does it attempt to be comprehensive in exploring unusual, but valid, messages. Instead, it tries to focus on areas that may cause interoperability problems in IPv6 deployments.
この文書では、無効なメッセージを作るためにあらゆる方法をカタログしようとしません。また、珍しいが、有効な、メッセージを探索中に包括的であることをしようとしません。その代わりに、IPv6の展開で相互運用性の問題を引き起こす可能性の分野に注力しようとします。
This document contains many examples of SIP messages with IPv6 network identifiers. The appendix contains an encoded binary form containing the bit-exact representation of all the messages and the script needed to decode them into separate files.
この文書は、IPv6ネットワーク識別子とSIPメッセージの多くの例が含まれています。付録には、すべてのメッセージのビット正確な表現と別々のファイルにそれらをデコードするために必要なスクリプトを含むエンコードされたバイナリ形式が含まれています。
The IPv6 addresses used in this document correspond to the 2001: DB8::/32 address prefix reserved for documentation [RFC3489]. Likewise, the IPv4 addresses used in this document correspond to the 192.0.2.0/24 address block as described in [RFC3330].
文書[RFC3489]のために予約DB8 :: / 32アドレスプレフィックス：この文書で使用されるIPv6アドレス2001に対応します。 [RFC3330]に記載されているように、同様に、本書で使用されるIPv4アドレスは192.0.2.0/24アドレスブロックに対応します。
Although SIP is a text-based protocol, some of these examples cannot be unambiguously rendered without additional markup due to the constraints placed on the formatting of RFCs. This document uses the <allOneLine/> markup convention established in [RFC4475] to avoid ambiguity and meet the Internet-Draft layout requirements. For the sake of completeness, the text defining this markup from Section 2.1 of [RFC4475] is reproduced in its entirety below:
SIPは、テキストベースのプロトコルであるが、これらの例のいくつかは、明確にRFCの書式上に配置された制約に起因する追加のマークアップなしでレンダリングすることができません。この文書では、あいまいさを避けて、インターネットドラフトレイアウト要件を満たすために、[RFC4475]で設立<allOneLine />マークアップの規則を使用しています。完全を期すために、[RFC4475]のセクション2.1からこのマークアップを定義するテキストを、以下にその全体が再生されます。
Several of these examples contain unfolded lines longer than 72 characters. These are captured between <allOneLine/> tags. The single unfolded line is reconstructed by directly concatenating all lines appearing between the tags (discarding any line feeds or carriage returns). There will be no whitespace at the end of lines. Any whitespace appearing at a fold-point will appear at the beginning of a line.
これらの例のいくつかは、72文字よりも長い折り畳まれていない行が含まれています。これらは、<allOneLine />タグの間に捕捉されています。単一の折り畳まれていない行が直接タグ（任意の行を廃棄フィードやキャリッジリターン）との間に出現するすべての行を連結することによって再構成される。行の末尾に空白はありません。折り畳み点に現れる任意の空白行の先頭に表示されます。
The following represent the same string of bits:
以下は、同じビット列を表します。
Header-name: first value, reallylongsecondvalue, third value
ヘッダ名：最初の値、reallylongsecondvalue、第3の値
<allOneLine> Header-name: first value, reallylongsecondvalue , third value </allOneLine>
<allOneLine>ヘッダ名：最初の値、reallylongsecondvalue、第3の値</ allOneLine>
<allOneLine> Header-name: first value, reallylong second value, third value </allOneLine>
<allOneLine>ヘッダ名：第2の値をreallylong最初の値、第3の値</ allOneLine>
Note that this is NOT SIP header-line folding, where different strings of bits have equivalent meaning.
これは、ビットの異なるストリングは、同等の意味を有するSIPヘッダライン折り畳みではないことに留意されたいです。
System-level issues like deploying a dual-stack proxy server, populating DNS with A and AAAA Resource Records (RRs), zero-configuration discovery of outbound proxies for IPv4 and IPv6 networks, when a dual-stack proxy should Record-Route itself, and media issues also play a major part in the transition to IPv6. This document does not, however, address these issues. Instead, a companion document [sip-trans] provides more guidance on these issues.
、デュアルスタックプロキシサーバを配備AとAAAAリソースレコード（RR）、IPv4およびIPv6ネットワークのためのアウトバウンドプロキシのゼロコンフィギュレーションの発見、デュアルスタックプロキシがすべきレコードルート自体にDNSを取り込むようなシステムレベルの問題、そして、メディアの問題はまた、IPv6への移行に大きな役割を果たしています。この文書では、しかし、これらの問題に対処しません。代わりに、仲間ドキュメント[SIP-トランスは、これらの問題の詳細なガイダンスを提供します。
The test messages are organized into several sections. Some stress only the SIP parser and others stress both the parser and the application above it. Some messages are valid and some are not. Each example clearly calls out what makes any invalid messages incorrect.
テストメッセージは、いくつかのセクションに編成されています。いくつかのストレスのみSIPパーサなどがパーサとその上のアプリケーションの両方を強調します。一部のメッセージが有効であり、一部ではありません。それぞれの例では、明確に、無効なメッセージが間違って作るものを呼び出します。
Please refer to the complete Augmented Backus-Naur Form (ABNF) in [RFC3261] on representing IPv6 references in SIP messages. IPv6 references are delimited by a "[" and "]". When an IPv6 reference is part of a SIP Uniform Resource Identifier (URI), RFC 3261 mandates that the "IPv6reference" production rule be used to recognize tokens that comprise an IPv6 reference. More specifically, the ABNF states the following:
SIPメッセージ内のIPv6参照を表すには、[RFC3261]で完全増補バッカス記法（ABNF）を参照してください。 IPv6の参照は、「[」と「]」で区切られます。 IPv6の参照がSIPユニフォームリソース識別子（URI）の一部である場合、「IPv6reference」プロダクションルールは、IPv6参照を含むトークンを認識するために使用することがRFC 3261義務付け。具体的には、ABNFは、次のように述べています：
SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] hostport = host [ ":" port ] host = hostname / IPv4address / IPv6reference IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv6reference = "[" IPv6address "]" IPv6address = hexpart [ ":" IPv4address ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG
SIP-URI = "SIP：" [ユーザー情報]のHostPort URIパラメータ[ヘッダー]のHostPort =ホスト[ "：" ポート] "" ホスト=ホスト名/ IPv4Addressを/ IPv6reference IPv4Addressを= 1 * 3DIGIT 1 * 3DIGIT "" 1 * 3DIGIT "" 1 * 3DIGIT IPv6reference = "[" IPv6address "]" IPv6address = hexpart [ "：" IPv4Addressを】hexpart = hexseq / hexseq "::" [hexseq] / "::" [hexseq] hexseq = hex4 *（ "：" hex4 ）hex4 = 1 * 4HEXDIG
The request below is well-formatted according to the grammar in [RFC3261]. An IPv6 reference appears in the Request-URI (R-URI), Via header field, and Contact header field.
以下リクエストは[RFC3261]に文法に従ってウェルフォーマットです。 IPv6の参照は、ヘッダフィールドを介して、リクエストURI（R-URI）に表示され、Contactヘッダーフィールド。
Message Details: ipv6-good
メッセージの詳細：IPv6に良いです
REGISTER sip:[2001:db8::10] SIP/2.0 To: sip:user@example.com From: sip:user@example.com;tag=81x2 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 Call-ID: SSG9559905523997077@hlau_4100 Max-Forwards: 70 Contact: "Caller" <sip:caller@[2001:db8::1]> CSeq: 98176 REGISTER Content-Length: 0
SIPレジスタ：[2001：DB8 :: 10] SIP / 2.0：SIP：user@example.comから：SIP：; user@example.comビアタグ= 81x2：SIP / 2.0 / UDP [2001：DB8 :: 9 ：1];ブランチ= z9hG4bKas3-111のCall-ID：SSG9559905523997077 @ hlau_4100マックス・フォワード：70お問い合わせ： "発信者" <一口：呼び出し側2001 [@：DB8 :: 1]>のCSeq：98176 REGISTERのContent-Length：0
The request below is not well-formatted according to the grammar in [RFC3261]. The IPv6 reference in the R-URI does not contain the mandated delimiters for an IPv6 reference ("[" and "]").
以下リクエストは[RFC3261]に文法に従ってよくフォーマットされていません。 R-URIにおけるIPv6の参照は、IPv6参照（「[」と「]」）のために義務付け区切り文字が含まれていません。
A SIP implementation receiving this request should respond with a 400 Bad Request error.
この要求を受けたSIPの実装では、400不正な要求エラーで応答する必要があります。
Message Details: ipv6-bad
メッセージの詳細：IPv6に悪いです
REGISTER sip:2001:db8::10 SIP/2.0 To: sip:user@example.com From: sip:user@example.com;tag=81x2 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 Call-ID: SSG9559905523997077@hlau_4100 Max-Forwards: 70 Contact: "Caller" <sip:caller@[2001:db8::1]> CSeq: 98176 REGISTER Content-Length: 0
SIP登録：2001：DB8 :: 10 SIP / 2.0：SIP：user@example.comから：SIP：user@example.com;タグ= 81x2のVia：SIP / 2.0 / UDP [2001：DB8 :: 9：1 ];ブランチ= z9hG4bKas3-111のCall-ID：SSG9559905523997077 @ hlau_4100マックス・フォワード：70お問い合わせ： "発信者" <一口：呼び出し側@ [2001：DB8 :: 1]>のCSeq：98176 REGISTERのContent-Length：0
IPv6 uses the colon to delimit octets. This may lead to ambiguity if the port number on which to contact a SIP server is inadvertently conflated with the IPv6 reference. Consider the REGISTER request below. The sender of the request intended to specify a port number (5070) to contact a server, but inadvertently, inserted the port number inside the closing "]" of the IPv6 reference. Unfortunately, since the IPv6 address in the R-URI is compressed, the intended port number becomes the last octet of the reference.
IPv6は、オクテットを区切るためにコロンを使用しています。 SIPサーバに連絡するポート番号が誤ったIPv6参照して融合されている場合、これは曖昧さにつながる可能性があります。以下のREGISTERリクエストを考えてみましょう。ポート番号（5070）を指定することを意図するものでリクエストの送信者がサーバーに接続するが、不注意に、IPv6の基準の閉鎖「」内部ポート番号を挿入します。 R-URI内のIPv6アドレスが圧縮されているので、残念ながら、意図されたポート番号は、参照の最後のオクテットとなります。
From a parsing perspective, the request below is well-formed. However, from a semantic point of view, it will not yield the desired result. Implementations must ensure that when a raw IPv6 address appears in a SIP URI, then a port number, if required, appears outside the closing "]" delimiting the IPv6 reference. Raw IPv6 addresses can occur in many header fields, including the Contact, Route, and Record-Route header fields. They also can appear as the result of the "sent-by" production rule of the Via header field. Implementers are urged to consult the ABNF in [RFC3261] for a complete list of fields where a SIP URI can appear.
解析の観点から、以下の要求が十分に形成されています。しかし、ビューの意味論的観点から、それが所望の結果をもたらさないであろう。実装は生のIPv6アドレスがSIP URIで表示されたときに、必要な場合は、ポート番号は、「]」IPv6の参照を区切る終値外に表示されていることを確認する必要があります。生のIPv6アドレスは、連絡先、ルート、およびRecord-Routeヘッダーフィールドを含む多くのヘッダフィールド、中に発生する可能性があります。彼らはまた、「送られた - で、」Viaヘッダーフィールドの生成規則の結果として表示されます。実装者は、SIP URIが現れる可能なフィールドの完全なリストについては、[RFC3261]でABNFに相談することを促しています。
Message Details: port-ambiguous
メッセージの詳細：ポートあいまいな
REGISTER sip:[2001:db8::10:5070] SIP/2.0 To: sip:user@example.com From: sip:user@example.com;tag=81x2 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 Call-ID: SSG9559905523997077@hlau_4100 Contact: "Caller" <sip:caller@[2001:db8::1]> Max-Forwards: 70 CSeq: 98176 REGISTER Content-Length: 0
SIPレジスタ：[2001：DB8 :: 10：5070] SIP / 2.0：SIP：user@example.comから：SIP：user@example.com;タグ= 81x2のVia：SIP / 2.0 / UDP [2001：DB8： ：9：1];ブランチ= z9hG4bKas3-111のCall-ID：SSG9559905523997077 hlau_4100 @連絡先： "発信者" <一口：呼び出し側2001 [@：DB8 :: 1]>マックス・フォワード：70のCSeq：98176 REGISTERのコンテンツの長さ： 0
In contrast to the example in Section 4.3, the following REGISTER request leaves no ambiguity whatsoever on where the IPv6 address ends and the port number begins. This REGISTER request is well formatted per the grammar in [RFC3261].
4.3節の例とは対照的に、以下のREGISTERリクエストは、IPv6アドレスが終了し、ポート番号が始まる場所にまったくあいまいさを残しません。このREGISTER要求は良く[RFC3261]に文法ごとにフォーマットされています。
Message Details: port-unambiguous
メッセージの詳細：ポート明確な
REGISTER sip:[2001:db8::10]:5070 SIP/2.0 To: sip:user@example.com From: sip:user@example.com;tag=81x2 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 Call-ID: SSG9559905523997077@hlau_4100 Contact: "Caller" <sip:caller@[2001:db8::1]> Max-Forwards: 70 CSeq: 98176 REGISTER Content-Length: 0
SIPレジスタ：[2001：DB8 :: 10]：5070 SIP / 2.0：SIP：user@example.comから：SIP：; user@example.comビアタグ= 81x2：SIP / 2.0 / UDP [2001：DB8： ：9：1];ブランチ= z9hG4bKas3-111のCall-ID：SSG9559905523997077 hlau_4100 @連絡先： "発信者" <一口：呼び出し側2001 [@：DB8 :: 1]>マックス・フォワード：70のCSeq：98176 REGISTERのコンテンツの長さ： 0
IPv6 references can also appear in Via header fields; more specifically in the "sent-by" production rule and the "via-received" production rule. In the "sent-by" production rule, the sequence of octets comprising the IPv6 address is defined to appear as an "IPv6reference" non-terminal, thereby mandating the "[" and "]" delimiters. However, this is not the case for the "via-received" non-terminal. The "via-received" production rule is defined as follows:
IPv6の参照もViaヘッダーフィールドに表示することができます。より具体的には、「送信ごとの」プロダクションルールと「ビア受信した」生成規則です。 「送信-によって」生成規則では、IPv6アドレスを含むオクテットの配列は、それにより「[」と「]」区切り文字を義務付ける、「IPv6reference」非末端として表示するように定義されます。しかし、これは「ビア受信した」非末端には当てはまりません。次のように「を介して、受信した」プロダクションルールが定義されています。
via-received = "received" EQUAL (IPv4address / IPv6address)
受信されたビア= EQUAL（IPv4Addressを/ IPv6address） "受信"
The "IPv6address" non-terminal is defined not to include the delimiting "[" and "]". This has led to the situation documented during the 18th SIP Interoperability Event [Email-SIPit]:
「IPv6address」非端末が区切りを含まない定義された「[」と「]」されています。これは、18日SIPの相互運用性イベントの[メール-SIPit]中に文書化され、状況につながっています。
Those testing IPv6 made different assumptions about enclosing literal v6 addresses in Vias in []. By the end of the event, most implementations were accepting either. Its about 50/50 on what gets sent.
これらの試験IPv6は[]内のビアにリテラルV6アドレスを囲むについて異なる仮定を行いました。イベントの終わりまでに、ほとんどの実装はどちらか受諾されました。その程度50/50送られるものに。
While it would be beneficial if the same non-terminal ("IPv6reference") was used for both the "sent-by" and "via-received" production rules, there has not been a consensus in the working group to that effect. Thus, the best that can be suggested is that implementations must follow the Robustness Principle [RFC1122] and be liberal in accepting a "received" parameter with or without the delimiting "[" and "]" tokens. When sending a request, implementations must not put the delimiting "[" and "]" tokens.
それは有益であろうが、同じ非末端（「IPv6referenceが」）のために使用された場合、両方の「送信ごとの」および「ビア受信した」プロダクションルール、その旨を作業部会で合意がなされていません。したがって、提案することができる最高の実装がロバスト性の原則[RFC1122]をフォローし、区切りの有無にかかわらず、「受信」パラメータを受け入れるにリベラルでなければならないということである「[」と「]」トークン。リクエストを送信する場合、実装は区切り「[」と「]」トークンを入れてはいけません。
The two test cases below are designed to stress this behavior. A SIP implementation receiving either of these messages must parse them successfully.
下の2つのテストケースは、この動作を強調するように設計されています。これらのメッセージのいずれかを受けたSIPの実装に成功し、それらを解析する必要があります。
The request below contains an IPv6 address in the Via "received" parameter. The IPv6 address is delimited by "[" and "]". Even though this is not a valid request based on a strict interpretation of the grammar in [RFC3261], robust implementations must nonetheless be able to parse the topmost Via header field and continue processing the request.
以下のリクエストパラメータを「受信」経由でIPv6アドレスが含まれています。 IPv6アドレスは、「[」と「]」で区切られています。これは[RFC3261]での文法の厳密な解釈に基づいて、有効な要求ではない場合であっても、堅牢な実装では、それにもかかわらず、最上位のViaヘッダフィールドを解析し、要求の処理を続行することができなければなりません。
Message Details: via-received-param-with-delim
メッセージの詳細：ビア受信-のparam-と、delimを
BYE sip:[2001:db8::10] SIP/2.0 To: sip:user@example.com;tag=bd76ya From: sip:user@example.com;tag=81x2 <allOneLine> Via: SIP/2.0/UDP [2001:db8::9:1];received=[2001:db8::9:255]; branch=z9hG4bKas3-111 </allOneLine> Call-ID: SSG9559905523997077@hlau_4100 Max-Forwards: 70 CSeq: 321 BYE Content-Length: 0
BYE SIP：[2001：DB8 :: 10] SIP / 2.0：SIP：user@example.com;からタグ= bd76ya：SIP：user@example.com;タグ= 81x2 <allOneLine>のVia：SIP / 2.0 / UDP [2001：DB8 :: 9：1]; [：DB8 :: 9：255 2001]; =を受けブランチ= z9hG4bKas3-111 </ allOneLine>コールID：SSG9559905523997077 @ hlau_4100マックス・フォワード：70件のCSeq：321 BYEのコンテンツの長さ：0
The OPTIONS request below contains an IPv6 address in the Via "received" parameter without the adorning "[" and "]". This request is valid according to the grammar in [RFC3261].
OPTIONSは、下記の要求飾る「[」と「]」なし「受信」パラメータを経由でIPv6アドレスが含まれています。この要求は、[RFC3261]で文法に従って有効です。
Message Details: via-received-param-no-delim
メッセージの詳細：受信を経由して-のparam-NO-でdelim
OPTIONS sip:[2001:db8::10] SIP/2.0 To: sip:user@example.com From: sip:user@example.com;tag=81x2 <allOneLine> Via: SIP/2.0/UDP [2001:db8::9:1];received=2001:db8::9:255; branch=z9hG4bKas3 </allOneLine> Call-ID: SSG95523997077@hlau_4100 Max-Forwards: 70 Contact: "Caller" <sip:caller@[2001:db8::9:1]> CSeq: 921 OPTIONS Content-Length: 0
OPTIONSのSIP：[2001：DB8 :: 10] SIP / 2.0：SIP：user@example.comから：SIP：user@example.com;タグ= 81x2 <allOneLine>のVia：SIP / 2.0 / UDP [2001：DB8 :: 9：1]; = 2001受け取っ：DB8 :: 9：255。ブランチ= z9hG4bKas3 </ allOneLine>コールID：SSG95523997077 @ hlau_4100マックス・フォワード：70お問い合わせ： "発信者" <一口：発信者の@ [2001：DB8 :: 9：1]>のCSeq：921 OPTIONSのContent-Length：0
4.6. SIP Request with IPv6 Addresses in Session Description Protocol (SDP) Body
4.6. セッション記述プロトコル（SDP）ボディでIPv6アドレスを持つSIPリクエスト
This request below is valid and well-formed according to the grammar in [RFC3261]. Note that the IPv6 addresses in the SDP [RFC4566] body do not have the delimiting "[" and "]".
以下、この要求が有効であり、[RFC3261]に文法に従って整形します。 IPv6はSDP [RFC4566]体のアドレス区切りを持っていないことに注意してください「[」と「]」。
Message Details: ipv6-in-sdp
メッセージの詳細：IPv6対応で、SDP
INVITE sip:user@[2001:db8::10] SIP/2.0 To: sip:user@[2001:db8::10] From: sip:user@example.com;tag=81x2 Via: SIP/2.0/UDP [2001:db8::20];branch=z9hG4bKas3-111 Call-ID: SSG9559905523997077@hlau_4100 Contact: "Caller" <sip:caller@[2001:db8::20]> CSeq: 8612 INVITE Max-Forwards: 70 Content-Type: application/sdp Content-Length: 268
SIPのINVITEます。user @ [2001：DB8 :: 10] SIP / 2.0：SIP：ユーザーの@ [2001：DB8 :: 10]から：SIP：; user@example.comビアタグ= 81x2：SIP / 2.0 / UDP [2001：DB8 :: 20];ブランチ= z9hG4bKas3-111のCall-ID：SSG9559905523997077 hlau_4100 @連絡先： "発信者" <一口：呼び出し側@ [2001：DB8 :: 20]>のCSeq：8612マックス-前方にINVITE：70コンテンツを - タイプ：アプリケーション/ SDPコンテンツの長さ：268
v=0 o=assistant 971731711378798081 0 IN IP6 2001:db8::20 s=Live video feed for today's meeting c=IN IP6 2001:db8::20 t=3338481189 3370017201 m=audio 6000 RTP/AVP 2 a=rtpmap:2 G726-32/8000 m=video 6024 RTP/AVP 107 a=rtpmap:107 H263-1998/90000
V = 0 0 = IP6 2001年にアシスタント971731711378798081 0：DB8 :: 20秒=本日の会議cのライブビデオフィード= IP6 2001：DB8 :: 20トン= 3338481189 3370017201メートル=オーディオ6000 RTP / AVP 2 A = rtpmap： 107 H263-1998 / 90000：G726-32 / 8000メートル=映像6024 RTP / AVP 107 = rtpmap 2
The request below is valid and well-formed according to the grammar in [RFC3261]. The Via list contains a mix of IPv4 addresses and IPv6 references.
以下の要求が有効であり、[RFC3261]に文法に従って整形します。経由リストは、IPv4アドレスとIPv6参照のミックスが含まれています。
Message Details: mult-ip-in-header
メッセージの詳細：MULT-IP内のヘッダー
BYE sip:user@host.example.net SIP/2.0 Via: SIP/2.0/UDP [2001:db8::9:1]:6050;branch=z9hG4bKas3-111 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKjhja8781hjuaij65144 <allOneLine> Via: SIP/2.0/TCP [2001:db8::9:255];branch=z9hG4bK451jj; received=192.0.2.200 </allOneLine> Call-ID: 997077@lau_4100 Max-Forwards: 70 CSeq: 89187 BYE To: sip:user@example.net;tag=9817--94 From: sip:user@example.com;tag=81x2 Content-Length: 0
BYEをSIP：user@host.example.net SIP / 2.0経由：SIP / 2.0 / UDP [2001：DB8 :: 9：1]：6050;分岐= z9hG4bKas3-111のVia：SIP / 2.0 / UDP 192.0.2.1;分岐= z9hG4bKjhja8781hjuaij65144 <allOneLine>ビア：SIP / 2.0 / TCP [2001：DB8 :: 9：255];ブランチ= z9hG4bK451jj。受信= 192.0.2.200 </ allOneLine>は、コールIDを：lau_4100マックス - フォワード@ 997077：70のCSeq：89187へBYE：SIP：user@example.net;タグ= 9817--94から：SIP：user@example.com ;タグ= 81x2用のContent-Length：0
The request below is valid and well-formed according to the grammar in [RFC3261]. The SDP contains multiple media lines, and each media line is identified by a different network connection address.
以下の要求が有効であり、[RFC3261]に文法に従って整形します。 SDPは、複数のメディア行を含み、各メディア・ラインは、異なるネットワーク接続アドレスによって識別されます。
Message Details: mult-ip-in-sdp
メッセージの詳細：MULT-IP-で-SDP
INVITE sip:user@[2001:db8::10] SIP/2.0 To: sip:user@[2001:db8::10] From: sip:user@example.com;tag=81x2 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 Call-ID: SSG9559905523997077@hlau_4100 Contact: "Caller" <sip:caller@[2001:db8::9:1]> Max-Forwards: 70 CSeq: 8912 INVITE Content-Type: application/sdp Content-Length: 181
SIPのINVITEます。user @ [2001：DB8 :: 10] SIP / 2.0：SIP：ユーザーの@ [2001：DB8 :: 10]から：SIP：; user@example.comビアタグ= 81x2：SIP / 2.0 / UDP [2001：DB8 :: 9：1];ブランチ= z9hG4bKas3-111コールID：SSG9559905523997077 hlau_4100問い合わせ@： "発信者" <一口：発信者の@ [2001：DB8 :: 9：1]>マックス・フォワード：70件のCSeq ：8912 Content-TypeのINVITE：アプリケーション/ SDPのContent-Lengthを：181
v=0 o=bob 280744730 28977631 IN IP4 host.example.com s= t=0 0 m=audio 22334 RTP/AVP 0 c=IN IP4 192.0.2.1 m=video 6024 RTP/AVP 107 c=IN IP6 2001:db8::1 a=rtpmap:107 H263-1998/90000
V = 0 0 =ボブ280744730 28977631 IN IP4 host.example.com S = T = 0、M = IP4 192.0.2.1のmのオーディオ22334 RTP / AVP 0のC = =映像6024 IP6 2001年RTP / AVP 107個のC = DB8 :: 1、A = rtpmap：107 H263-1998 / 90000
An IPv4-mapped IPv6 address is usually represented with the last 32 bits appearing as a dotted-decimal IPv4 address; e.g., ::ffff: 192.0.2.1. A SIP implementation receiving a message that contains such a mapped address must be prepared to parse it successfully. An IPv4-mapped IPv6 address may appear in signaling, or in the SDP carried by the signaling message, or in both. If a port number is part of the URI represented by the IPv4-mapped IPv6 address, then it must appear outside the delimiting "]" (cf. Section 4.4).
IPv4マップIPv6アドレスは通常、ドット付き10進数のIPv4アドレスとして現れる最後の32ビットで表現されます。例えば、:: FFFF：192.0.2.1。このようなマッピングされたアドレスを含むメッセージを受信したSIP実装は正常に解析するために用意されなければなりません。 IPv4マップIPv6アドレスは、シグナリング、またはシグナリングメッセージによって運ばれるSDPで、または両方で表示されてもよいです。ポート番号は、IPv4射影IPv6アドレスで表されるURIの一部である場合、それは区切り「]」（参照セクション4.4）の外側に現れなければなりません。
The message below is well-formed according to the grammar in [RFC3261]. The Via list contains two Via headers, both of which include an IPv4-mapped IPv6 address. An IPv4-mapped IPv6 address also appears in the Contact header and the SDP. The topmost Via header includes a port number that is appropriately delimited by "]".
以下のメッセージは、[RFC3261]に文法に従って整形式です。ビアリストはIPv4マップIPv6アドレスを含む両方が2つのViaヘッダを含んでいます。 IPv4射影IPv6アドレスもContactヘッダーとSDPに表示されます。一番上のViaヘッダを適切に「]」で区切られたポート番号を含みます。
Message Details: ipv4-mapped-ipv6
メッセージの詳細：IPv4射影IPv6の-
INVITE sip:user@example.com SIP/2.0 To: sip:user@example.com From: sip:user@east.example.com;tag=81x2 Via: SIP/2.0/UDP [::ffff:192.0.2.10]:19823;branch=z9hG4bKbh19 Via: SIP/2.0/UDP [::ffff:192.0.2.2];branch=z9hG4bKas3-111 Call-ID: SSG9559905523997077@hlau_4100 Contact: "T. desk phone" <sip:ted@[::ffff:192.0.2.2]> CSeq: 612 INVITE Max-Forwards: 70 Content-Type: application/sdp Content-Length: 236
SIP：SIPへuser@example.com / 2.0：user@example.comから：SIP：user@east.example.com;タグ= 81x2経由：SIP INVITE SIP / 2.0 / UDPを[:: FFFF：192.0.2.10 ]：19823;ブランチ= z9hG4bKbh19経由：SIP / 2.0 / UDP [::ffff:192.0.2.2];branch=z9hG4bKas3-111のCall-ID：SSG9559905523997077 @ hlau_4100お問い合わせ： "T.デスクフォン" <一口：テッド@ [ :: FFFF：192.0.2.2]>のCSeq：612は、最大-前方にINVITE：70のContent-Type：アプリケーション/ SDPコンテンツの長さ：236
v=0 o=assistant 971731711378798081 0 IN IP6 ::ffff:192.0.2.2 s=Call me soon, please! c=IN IP6 ::ffff:192.0.2.2 t=3338481189 3370017201 m=audio 6000 RTP/AVP 2 a=rtpmap:2 G726-32/8000 m=video 6024 RTP/AVP 107 a=rtpmap:107 H263-1998/90000
IP6、V IN = 0 0 =アシスタント971731711378798081 0 :: FFFF：192.0.2.2 S =、すぐに私をしてください呼べ！ C = IP6、IN :: FFFF：192.0.2.2トン= 3338481189 3370017201メートル=オーディオ6000 RTP / AVP 2 A = rtpmap：G726-32 / 8000 2メートル=ビデオ6024 RTP / AVP 107 = rtpmap：107 H263-1998 / 90000
It is possible to follow the IPv6reference production rule of RFC 3261 ABNF -- the relevant portion of which is reproduced at the top of Section 4 -- and arrive at the following construct:
RFC 3261 ABNFのIPv6reference生成ルールに従うことが可能である - の関連部分は、セクション4の先頭に再生される - と、以下の構築物に到達します。
[2001:db8:::192.0.2.1]
[2001：DB8 ::: 192.0.2.1]
Note the extra colon before the IPv4 address in the above construct. The correct construct, of course, is:
上記構築物におけるIPv4アドレスの前に余分なコロンに注意してください。正しい構築体は、当然のことながら、次のとおりです。
[2001:db8::192.0.2.1]
[2001：DB8 :: 192.0.2.1]
The ABNF pertaining to IPv6 references in RFC 3261 was derived from RFC 2373 [RFC2373], which has been obsoleted by RFC 4291 [RFC4291]. The specific behavior of inserting an extra colon was inherited from RFC 2373, and has been remedied in RFC 4291. However, following the Robustness Principle [RFC1122], an implementation must tolerate both of the above constructs.
RFC 3261でのIPv6参照に関連ABNFは、RFC 2373、RFC 4291によって廃止された[RFC2373]、[RFC4291]に由来しました。余分なコロンを挿入する具体的な動作は、RFC 2373から継承し、ロバスト性の原則[RFC1122]以下、しかしRFC 4291.に改善された、実装は、上記の構築物の両方に耐えなければなりません。
The message below includes an extra colon in the IPv6 reference. A SIP implementation receiving such a message may exhibit robustness by successfully parsing the IPv6 reference (it can choose to ignore the extra colon when parsing the IPv6 reference. If the SIP implementation is acting in the role of a proxy, it may additionally serialize the message without the extra colon to aid the next downstream server).
以下のメッセージは、IPv6基準に余分なコロンを含みます。そのようなメッセージを受信したSIP実装は、正常のIPv6参照を解析することにより堅牢性を示すことができる（これは、IPv6の参照を解析するときに、余分なコロンを無視することを選択できる。SIP実装は、プロキシの役割で機能している場合、それはさらにメッセージをシリアル化することができます次の下流サーバーを支援するために、余分なコロンなし）。
Message Details: ipv6-bug-abnf-3-colons
メッセージの詳細：IPv6にバグABNF-3-コロン
OPTIONS sip:user@[2001:db8:::192.0.2.1] SIP/2.0 To: sip:user@[2001:db8:::192.0.2.1] From: sip:user@example.com;tag=810x2 Via: SIP/2.0/UDP lab1.east.example.com;branch=z9hG4bKas3-111 Call-ID: G9559905523997077@hlau_4100 CSeq: 689 OPTIONS Max-Forwards: 70 Content-Length: 0
OPTIONS SIP：ユーザーの@ [2001：DB8 ::: 192.0.2.1] SIP / 2.0：SIP：ユーザーの@ [2001：DB8 ::: 192.0.2.1]から：SIP：user@example.com;タグ= 810x2ビア：SIP / 2.0 / UDP lab1.east.example.com;ブランチ= z9hG4bKas3-111のCall-ID：G9559905523997077 @ hlau_4100のCSeq：689 OPTIONSマックス・フォワード：70のContent-Length：0
The next message has the correct syntax for the IPv6 reference in the R-URI.
次のメッセージは、R-URI内のIPv6参照の正しい構文を有します。
Message Details: ipv6-correct-abnf-2-colons
メッセージの詳細：IPv6に正しい-ABNF-2-コロン
OPTIONS sip:user@[2001:db8::192.0.2.1] SIP/2.0 To: sip:user@[2001:db8::192.0.2.1] From: sip:user@example.com;tag=810x2 Via: SIP/2.0/UDP lab1.east.example.com;branch=z9hG4bKas3-111 Call-ID: G9559905523997077@hlau_4100 CSeq: 689 OPTIONS Max-Forwards: 70 Content-Length: 0
OPTIONS SIP：ユーザーの@ [2001：DB8 :: 192.0.2.1] SIP / 2.0：SIP：ユーザーの@ [2001：DB8 :: 192.0.2.1]から：SIP：user@example.com;タグ= 810x2のVia：SIP /2.0/UDP lab1.east.example.com;ブランチ= z9hG4bKas3-111のCall-ID：G9559905523997077 @ hlau_4100のCSeq：689 OPTIONSマックス・フォワード：70のContent-Length：0
This document presents examples of SIP messages with IPv6 references contained in the signaling headers and SDP payload. While this document may clarify the behavior of SIP elements processing a
この文書は、シグナリングヘッダとSDPペイロードに含まれたIPv6参照してSIPメッセージの例を提示します。この文書は、処理SIP要素の挙動を明らかにするかもしれないが
message with IPv6 references, it does not normatively change the base SIP [RFC3261] specification in any way. Consequently, all security considerations in [RFC3261] apply.
IPv6の参照を持つメッセージは、それが規範的にどのような方法でベースSIP [RFC3261]の仕様を変更しません。その結果、[RFC3261]ですべてのセキュリティの考慮事項が適用されます。
Parsers must carefully consider edge conditions and malicious input as part of their design. Attacks on many Internet systems use crafted input to cause implementations to behave in undesirable ways. Many of the messages in this document are designed to stress a parser implementation at points traditionally used for such attacks. This document does not, however, attempt to be comprehensive. It contains some common pitfalls that the authors have discovered while parsing IPv6 identifiers in SIP implementations.
パーサは、慎重に設計の一部として、エッジ条件と悪質な入力を考慮しなければなりません。多くのインターネットシステムに対する攻撃は、実装が望ましくない方法で動作させるために細工された入力を使用します。この文書に記載されているメッセージの多くは、伝統的に、このような攻撃に使用されるポイントで、パーサーの実装を強調するように設計されています。この文書では、しかし、包括的であることをしようとしません。これは、SIPの実装にIPv6の識別子を解析しながら、著者が発見したことをいくつかの一般的な落とし穴が含まれています。
The authors thank Jeroen van Bemmel, Dennis Bijwaard, Gonzalo Camarillo, Bob Gilligan, Alan Jeffrey, Larry Kollasch, Erik Nordmark, Kumiko Ono, Pekka Pessi, Jon Peterson, and other members of the SIP-related working groups for input provided during the construction of the document and discussion of the test cases.
著者は、建設中に提供された入力用のJeroenバンBemmel、デニスBijwaard、ゴンサロ・カマリロ、ボブギリガン、アラン・ジェフリー、ラリーKollasch、エリックNordmarkと、久美子小野、ペッカPessi、ジョンピーターソン、およびSIP関連のワーキンググループの他のメンバーに感謝しますテストケースの文書や議論の。
This work is being discussed on the sipping@ietf.org mailing list.
この作品は、sipping@ietf.orgメーリングリストで議論されています。
A.B. Nataraju and A.C. Mahendran provided working group last call comments.
A.B. NatarajuとA.C. Mahendranは、ワーキンググループの最後の呼び出しのコメントを提供しました。
Mohamed Boucadair and Brian Carpenter suggested new test cases for inclusion in the document.
モハメドBoucadairとブライアン・カーペンターは、文書に含めるための新しいテストケースを示唆しました。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、STD 3、RFC 1122、1989年10月。
[RFC3261] 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.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330] IANA、 "特殊用途IPv4アドレス"、RFC 3330、2002年9月。
[RFC3489] 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.
[RFC3489]ローゼンバーグ、J.、ワインバーガー、J.、のHuitema、C.、およびR.マーイ、 - 2003年3月、RFC 3489 "STUNネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサルは、翻訳者（NATのを）アドレス"。
[RFC4475] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[RFC4475]スパークス、R.、編、Hawrylyshen、A.、ジョンストン、A.、ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）調教テストメッセージ"、RFC 4475、2006年5月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC2373] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[sip-trans] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", Work in Progress, August 2007.
[SIPトランス]カマリロ、G.、エルMalki、K.、およびV. Gurbani、進歩、2007年8月に仕事 "セッション開始プロトコル（SIP）におけるIPv6移行"。
[Email-SIPit] Sparks, R., "preliminary report: SIPit 18", Electronic Mail archived at http://www1.ietf.org/mail-archive/web/ sip/current/msg14103.html, April 2006.
[メール-SIPit]スパークス、R.は、 "予備報告：SIPit 18" は、電子メールは、2006年4月には、http://www1.ietf.org/mail-archive/web/でSIP /現在/ msg14103.htmlをアーカイブしました。
Appendix A. Bit-Exact Archive of Each Test Message
各テストメッセージの付録A.のビット正確なアーカイブ
The following text block is an encoded, gzip compressed TAR archive of files that represent each of the example messages discussed in Section 4.
次のテキストブロックは、セクション4で説明した例のメッセージのそれぞれを表すファイルの符号化、GZIP圧縮されたtarアーカイブです。
To recover the compressed archive file intact, the text of this document may be passed as input to the following Perl script (the output should be redirected to a file or piped to "tar -xzvf -").
そのまま圧縮されたアーカイブファイルを復元するには、この文書のテキストは（出力をファイルにリダイレクトするかを「タール-xzvf - 」パイプする必要があります）次のPerlスクリプトへの入力として渡すことができます。
#!/usr/bin/perl
use strict;
my $bdata = "";
use MIME::Base64;
while(<>) {
if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) {
if ( m/^\s*[^\s]+\s*$/) {
$bdata = $bdata . $_;
}
}
}
print decode_base64($bdata);
Alternatively, the base-64 encoded block can be edited by hand to remove document structure lines and fed as input to any base-64 decoding utility.
あるいは、ベース64符号化されたブロックは、文書構造線を除去するために手動で編集し、任意のベース64復号ユーティリティへの入力として供給することができます。
A.1. Encoded Reference Messages
A.1。エンコードされた参照メッセージ
-- BEGIN MESSAGE ARCHIVE -- H4sICPujD0cAA21zZy50YXIA7Vpbc6M2GPUzv0Ldl74UWzckIHUnbXY39XS760ncz HQ6mY5sFBuvDRSwN+mvrwAb303c2GQ34byAjYSEpHO+i1Rv1E4OCCnkEKorRJyl1+ R2dk1RQ6oE4RhxRNT/CCHGa8bpu1arTaJYhKrJ6ef+3nJ+PJDhnufzD8ku+LidPB3 qDTeYUn0sgkA6urpnx28DIggZpbvmHyFOF/NPWTL/FFFcg8fvyiZe+fy3Pt60Ou9A 5Ab2JJLhubwX42Ak6z1/DK5b7QauQ63j21sLaO9Df7z8SERxfen5WSz6TRPdY+3GF fb8dY0/3rbBX7Z9p2AjS/1Tx3UEb9W9iclZNxReb9D81xpc0u5v3QGyimvj27VqIi K60hDtQoxGeuutqn19aRmGZUHDwMSyOOT8fDASk7+pWpvahe/Fohfb4E2nDhwZfQb BwPfkG/Bj8m2xdM43W/xJu7iW/9iAIQyyQdR+F/f6ez/8IkInsgHP3iu9WO88BNIG imIjtydi1/cakRPkTz9Irx8PbIAJ07RpE2p+U0SRq9alFwOLI06UKiLCTW6Z0EQAq vZAq83Aep+0qJl8MBhLEPm+9wNQ8yAi+Z3Wa+6qETcJISY1ETItQAhPGIoh0sZNMX FcHzC1lsFVp934+aYNsCaaYRworbAxuOSY6QQ3TFVCFZ+6jkyKY5oXV5ReVFA/wK+ YqWmxLLNhJRzRnnvtV5jpP9O7wjldGwX6DyklSv8Z5AZEmPNE/7FBWKX/JeDq3WXr uvPuKlVxrEbedrqmreh6uPo/TvgXbVg2eqJubxXcTMiTN8hwpuC99Mf5Utso12/LV GsSzIdhQ5Sh9rJlasb/vu+fTgCK+W8s+I9pyn9OKv+vDKzwf5kg8LZSgFegADP+u5 6uXNITtVEU/0GO5/zHkKX2X7m8vOJ/CViP/x4jAatlnqwCGB4tfCvgvGppTnrziHE bMw+L25Y7pGK2D+5Ugix+upPSAXd+CGLfEQ/fRyqUk7Hr9RcR3ErdKnqr8ETUG+PJ KNbdIDEBAymcvSL3/1Dk/6l1l+s/wjDN/xECK/0vAb/8uST+A38pgefJOJf/IifOZ tCAO0R8o26e81urMBwMhclNNBhOhDtkBqJ0tXLnYq1hbBjrpoMaaDg8C2VPKlV1mn mmKzETc2syMyB7nMjMRFjI5EAN0HYHWI1Pat8S91HXLfooO/jVOZcr/D+RC1jEf85 Zzn+MMv9PWc6K/yXgK/D/nh4FPtoBtNKwbzffc5fwMA8QmWjuAXb9LsAm5JRyAtWd pRY3QZnnR8GKwCYRdNRUThwEMHfZMCZk4YTBueNHF6q5213b4iSiIh+u3gj8MNbFu Ov2J/4kOsUaK8z/GLn9R4Rl9l+NYMX/ErA7/2MbkH8bSaCDcj47yP9ak0Az/k+8Ey rAIfynGKX8p8So+F8C9uR/UwGo+P/S+T91hT6Pl/RAhGKse77uyJE7PlIbhfxni/1 fg6X7Pwzzav+nDHxqd1qfPl4/3/ZPHqqvBfabkrAuB0fdDrKWN4QwArNxefFCsJX/ X9x4cEQFKOQ/Xth/I4v/GcMV/8vAPP93IPdTgncdzh7EkWWgKMH35A3ilOJEUTzJ7 L10ehdifv5r0tdF17vTid7zR7531CigmP/Z+W/MGUvPfSUygKvzX2Vg2f6vJ/cWp3 OLE4FLZYsFAW5ThJHoovrGEeIC8u8NC7LzuaaVG/OdG70L+j/3fJSNGf97fqgUOM4 0AB9ZAwr5j1jOf+UFpPZfSUDF/xKwj/8H0L9if4UKFSp8Y/gPJmWg1AA6AAA= -- END MESSAGE ARCHIVE --
- メッセージアーカイブをBEGIN - H4sICPujD0cAA21zZy50YXIA7Vpbc6M2GPUzv0Ldl74UWzckIHUnbXY39XS760ncz HQ6mY5sFBuvDRSwN + mvrwAb303c2GQ34byAjYSEpHO + i1Rv1E4OCCnkEKorRJyl1 + R2dk1RQ6oE4RhxRNT / CCHGa8bpu1arTaJYhKrJ6ef + 3nJ + PJDhnufzD8ku + LidPB3 qDTeYUn0sgkA6urpnx28DIggZpbvmHyFOF / NPWTL / FFFcg8fvyiZe + fy3Pt60Ou9A 5Ab2JJLhubwX42Ak6z1 / DK5b7QauQ63j21sLaO9Df7z8SERxfen5WSz6TRPdY + 3GF fb8dY0 / 3rbBX7Z9p2AjS / 1Tx3UEb9W9iclZNxReb9D81xpc0u5v3QGyimvj27VqIi K60hDtQoxGeuutqn19aRmGZUHDwMSyOOT8fDASk7 + pWpvahe / Fohfb4E2nDhwZfQb BwPfkG / Bj8m2xdM43W / xJu7iW / 9iAIQyyQdR + F / f6ez / 8IkInsgHP3iu9WO88BNIG imIjtydi1 / cakRPkTz9Irx8PbIAJ07RpE2p + U0SRq9alFwOLI06UKiLCTW6Z0EQAq vZAq83Aep + 0qJl8MBhLEPm + 9wNQ8yAi + Z3Wa + 6qETcJISY1ETItQAhPGIoh0sZNMX FcHzC1lsFVp934 + aYNsCaaYRworbAxuOSY6QQ3TFVCFZ + 6jkyKY5oXV5ReVFA /週+ YqWmxLLNhJRzRnnvtV5jpP9O7wjldGwX6DyklSv8Z5AZEmPNE / 7FBWKX / JeDq3WXr uvPuKlVxrEbedrqmreh6uPo / TvgXbVg2eqJubxXcTMiTN8hwpuC99Mf5Utso12 / LV GsSzIdhQ5Sh9rJlasb / VU + fTgCK + W8s + I9pyn9OKv + vDKzwf5kg8LZSgFegADP + U5 6uXNITtVEU / 0GO5 / zHkKX2X7m8vOJ / CViP / x4jAatlnqwCGB 4tfCvgvGppTnrziHE BMW + L25Y7pGK2D + 5Ugix + upPSAXd + CGLfEQ / fRyqUk7Hr9RcR3ErdKnqr8ETUG + PJ KNbdIDEBAymcvSL3 / 1DK / 6l1l + S / wjDN / xECK / 0vAb / 8uST + A38pgefJOJf / IifOZ tCAO0R8o26e81urMBwMhclNNBhOhDtkBqJ0tXLnYq1hbBjrpoMaaDg8C2VPKlV1mn mmKzETc2syMyB7nMjMRFjI5EAN0HYHWI1Pat8S91HXLfooO / jVOZcr / D + RC1jEf85 Zzn + MMv9PWc6K / yXgK / D / nh4FPtoBtNKwbzffc5fwMA8QmWjuAXb9LsAm5JRyAtWd pRY3QZnnR8GKwCYRdNRUThwEMHfZMCZk4YTBueNHF6q5213b4iSiIh + u3gj8MNbFu Ov2J / 4kOsUaK8z / GLn9R4Rl9l + NYMX / ErA7 / 2MbkH8bSaCDcj47yP9ak0Az / K + 8Ey rAIfynGKX8p8So + F8C9uR / UwGo + P / S + T91hT6Pl / RAhGKse77uyJE7PlIbhfxni / 1 fg6X7Pwzzav + nDHxqd1qfPl4 / 3 / ZPHqqvBfabkrAuB0fdDrKWN4QwArNxefFCsJX / X9x4cEQFKOQ /第X / I4v / GcMV / 8vAPP93IPdTgncdzh7EkWWgKMH35A3ilOJEUTzJ7 L10ehdifv5r0tdF17vTid7zR7531CigmP / Z + W / MGUvPfSUygKvzX2Vg2f6vJ / cWp3 OLE4FLZYsFAW5ThJHoovrGEeIC8u8NC7LzuaaVG / OdG70L + J / 3fJSNGf97fqgUOM4 0AB9ZAwr5j1jOf + UFpPZfSUDF / xKwj / 8H0L9if4UKFSp8Y / gPJmWg1AA6AAA = - ENDのメッセージアーカイブ -
Authors' Addresses
著者のアドレス
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane Rm 9F-546 Lisle, IL 60532 USA
ビジェイK. Gurbaniベル研究所、アルカテル・ルーセント2701ルーセントレーンRmの9F-546ライル、IL 60532 USA
Phone: +1 630 224 0216 EMail: vkg@alcatel-lucent.com
電話：+1 630 224 0216 Eメール：vkg@alcatel-lucent.com
Chris Boulton Ubiquity Software Corporation Building 3 West Fawr Lane St Mellons Cardiff, South Wales CF3 5EA
クリスボールトンのUbiquity Software Corporationのビル3西Fawrレーンセントメロンズカーディフ、サウスウェールズCF3 5EA
EMail: cboulton@ubiquitysoftware.com
メールアドレス：cboulton@ubiquitysoftware.com
Robert J. Sparks Estacado Systems
ロバート・J・スパークスシステムズEstacado
EMail: RjS@estacado.net
メールアドレス：RjS@estacado.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。