[要約] RFC 5118は、IPv6に対するSIP Torture Test Messagesの仕様を定めたものです。このRFCの目的は、IPv6環境でのSIPプロトコルのテストと評価を可能にすることです。
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)
セッション開始プロトコル（SIP）インターネットプロトコルの拷問テストメッセージバージョン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].
このドキュメントで使用されているIPv6アドレスは、2001年に対応しています。DB8::/32ドキュメントのために予約されているアドレス[RFC3489]。同様に、このドキュメントで使用されるIPv4アドレスは、[RFC3330]で説明されているように、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
Header-Name：First Value、ReallongSecondValue、3番目の値
<allOneLine> Header-name: first value, reallylongsecondvalue , third value </allOneLine>
<Alloneline> Header-Name：最初の値、reallongsecondValue、3番目の値</alloneline>
<allOneLine> Header-name: first value, reallylong second value, third value </allOneLine>
<Alloneline> Header-Name：最初の値、本当にロング2番目の値、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.
デュアルスタックプロキシサーバーの展開、DNSのAおよびAAAAリソースレコード（RRS）の住宅、IPv4およびIPv6ネットワークのアウトバウンドプロキシのゼロ構成発見などのシステムレベルの問題。デュアルスタックプロキシ自体が記録される場合、また、メディアの問題は、IPv6への移行にも大きな役割を果たします。ただし、このドキュメントでは、これらの問題に対処していません。代わりに、コンパニオンドキュメント[SIP-Trans]は、これらの問題に関するより多くのガイダンスを提供します。
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]の完全な増強されたBackus-Naurフォーム（ABNF）を参照してください。IPv6参照は、「["と「]」によって区切られています。IPv6リファレンスがSIPユニフォームリソース識別子（URI）の一部である場合、RFC 3261は、「IPv6reference」生産ルールを使用して、IPv6参照を含むトークンを認識することを義務付けています。より具体的には、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
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）、ヘッダーフィールド、および接触ヘッダーフィールドに表示されます。
Message Details: ipv6-good
メッセージの詳細：IPv6-Good
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
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リファレンス（ "[" and "]"）の義務付けられたデリミターが含まれていません。
A SIP implementation receiving this request should respond with a 400 Bad Request error.
このリクエストを受信するSIP実装では、400の悪い要求エラーで応答するはずです。
Message Details: ipv6-bad
メッセージの詳細：IPv6-Bad
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
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リファレンスと不注意に混同される場合、曖昧さにつながる可能性があります。以下の登録リクエストを検討してください。リクエストの送信者は、サーバーに連絡するためにポート番号（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アドレスは、接触、ルート、レコードルートのヘッダーフィールドなど、多くのヘッダーフィールドで発生する可能性があります。また、Via Headerフィールドの「セントバイ」制作ルールの結果として表示される可能性があります。実装者は、SIP URIが表示されるフィールドの完全なリストについては、[RFC3261]のABNFに相談することをお勧めします。
Message Details: port-ambiguous
メッセージの詳細：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
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の例とは対照的に、次のレジスタリクエストには、IPv6アドレスが終了してポート番号が始まる場所についてはあいまいさがありません。このレジスタリクエストは、[RFC3261]の文法ごとに適切にフォーマットされています。
Message Details: port-unambiguous
メッセージの詳細：port-unbiguous
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
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参照は、ヘッダーフィールドを介して表示することもできます。より具体的には、「セントバイ」の制作ルールと「経歴による」生産ルールにおいて。「セントバイ」の制作ルールでは、IPv6アドレスを含むオクテットのシーケンスは、「IPv6reference」非ターミナルとして表示されるように定義され、それによって「["および「]」デリミターを義務付けます。ただし、これは「経歴を経て」非ターミナルの場合ではありません。「経由で認識された」制作ルールは、次のように定義されています。
via-received = "received" EQUAL (IPv4address / IPv6address)
via-received = "受信"等しい（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をテストしている人は、[]のVIASでリテラル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」）が「Sent-by」と「via-Receeved」制作ルールの両方に使用された場合、それは有益ですが、その効果についてワーキンググループにはコンセンサスはありませんでした。したがって、提案できる最善の点は、実装が堅牢性の原則[RFC1122]に従い[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.
以下のリクエストには、VIA「受信」パラメーターのIPv6アドレスが含まれています。IPv6アドレスは、「["と「]」によって区切られています。これは[RFC3261]の文法の厳密な解釈に基づく有効な要求ではありませんが、それでも堅牢な実装はヘッダーフィールドを介して最上部を解析し、リクエストの処理を続けることができなければなりません。
Message Details: via-received-param-with-delim
メッセージの詳細：Via-Received-Param-With-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
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].
以下のオプションリクエストには、「["" ""および ""が装飾されていない「受信」パラメーターのIPv6アドレスが含まれています。この要求は、[RFC3261]の文法に従って有効です。
Message Details: via-received-param-no-delim
メッセージの詳細：Via-Received-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
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]の文法に従って有効であり、よく形成されています。SDP [RFC4566]ボディのIPv6アドレスには、「["と「]」の区切りがないことに注意してください。
Message Details: ipv6-in-sdp
メッセージの詳細：IPv6-in-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
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
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]の文法に従って適切に形成されています。VIAリストには、IPv4アドレスとIPv6参照の組み合わせが含まれています。
Message Details: mult-ip-in-header
メッセージの詳細：Mult-IP-in-Header
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
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-in-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
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
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-Mapped IPv6アドレスは、通常、最後の32ビットが点線程度のIPv4アドレスとして表示されることで表されます。例：:: FFFF：192.0.2.1。このようなマッピングされたアドレスを含むメッセージを受信するSIP実装は、それを正常に解析するために準備する必要があります。IPv4-Mapped IPv6アドレスは、シグナリング、または信号メッセージによって運ばれるSDP、または両方に表示される場合があります。ポート番号がIPv4-Mapped IPv6アドレスで表されるURIの一部である場合、削除の外側に表示される必要があります。
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]の文法に従ってよく形成されています。VIAリストには、2つのHeaderが含まれており、どちらもIPv4マップIPv6アドレスが含まれています。IPv4-Mapped IPv6アドレスもコンタクトヘッダーとSDPに表示されます。最上部のヘッダーには、「]で適切に区切られたポート番号が含まれています。
Message Details: ipv4-mapped-ipv6
メッセージの詳細：IPv4-Mapped-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
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
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] Note the extra colon before the IPv4 address in the above construct. The correct construct, of course, is:
[2001：DB8 ::: 192.0.2.1]上記のコンストラクトのIPv4アドレスの前の余分なコロンに注意してください。もちろん、正しい構造は次のとおりです。
[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 [RFC2373]に由来し、RFC 4291 [RFC4291]によって廃止されました。余分なコロンを挿入する特定の挙動はRFC 2373から継承され、RFC 4291で改善されました。ただし、堅牢性の原則[RFC1122]に従って、実装は上記の構成要素の両方を許容する必要があります。
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-Bug-ABNF-3-Colons
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
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-Correct-Abnf-2-Colons
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
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 Van Bemmel、Dennis Bijwaard、Gonzalo Camarillo、Bob Gilligan、Alan Jeffrey、Larry Kollasch、Erik Nordmark、Kumiko Ono、Pekka Pessi、Jon Peterson、および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.
Mohamed BoucadairとBrian Carpenterは、文書に含めるための新しいテストケースを提案しました。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、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] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「スタン - ネットワークアドレス翻訳者（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバーサル」、RFC 3489、2003年3月。
[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] Sparks、R.、Ed。、Ed。、Hawrylyshen、A.、Johnston、A.、Rosenberg、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] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC2373] Hinden、R。およびS. Deering、「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. Deering、「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-TRANS] Camarillo、G.、El Malki、K。、およびV. Gurbani、「セッション開始プロトコル（SIP）のIPv6遷移」、2007年8月の作業。
[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.
[電子メールシピット] Sparks、R。、「予備報告書：Sipit 18」、電子メールはhttp://www1.ietf.org/mail-archive/web/ sip/current/msg14103.html、2006年4月にアーカイブされています。
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圧縮タールアーカイブです。
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 -").
圧縮されたアーカイブファイルを無傷の回復するには、このドキュメントのテキストを次のPerlスクリプトに入力すると渡される場合があります（出力はファイルにリダイレクトするか、「tar -xzvf」にパイプされている必要があります）。
#!/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デコードユーティリティへの入力として供給することができます。
-- 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 --
Authors' Addresses
著者のアドレス
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane Rm 9F-546 Lisle, IL 60532 USA
Vijay K. Gurbani Bell Laboratories、Alcatel-Lucent 2701 Lucent Lane RM 9F-546 Lisle、IL 60532 USA
Phone: +1 630 224 0216
EMail: vkg@alcatel-lucent.com
Chris Boulton Ubiquity Software Corporation Building 3 West Fawr Lane St Mellons Cardiff, South Wales CF3 5EA
クリス・ボールトンユビキティソフトウェアコーポレーションビル3ウェストファーレーンセントメロンカーディフ、サウスウェールズCF3 5EA
EMail: cboulton@ubiquitysoftware.com
Robert J. Sparks Estacado Systems
ロバート・J・スパークス・エスタカド・システム
EMail: RjS@estacado.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。