RFC5118 日本語訳

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

Gurbaniがコメントのために要求するワーキンググループV.をネットワークでつないでください: 5118年のベル研究所、アルカテル透明なカテゴリ: 情報のC.Boultond偏在ソフトウェア社R.はエスタカードシステム2008年2月にスパークします。

      Session Initiation Protocol (SIP) Torture Test Messages for
                   Internet Protocol Version 6 (IPv6)

インターネットプロトコルバージョン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.

このドキュメントはメッセージが運動するように設計したテストと「拷問」というSession Initiationプロトコル(SIP)に関する例にIPv6によって可能にされたSIP実装のコードを提供します。

Gurbani, et al.              Informational                      [Page 1]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[1ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

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

1. 概要…2 2. コンベンションを記録してください…2 3. 一口とIPv6は構成をネットワークでつなぎます…4 4. パーサ拷問はテストされます…4 4.1. IPv6参照がある有効な一口メッセージ…5 4.2. IPv6参照がある無効の一口メッセージ…5 4.3. 一口URIであいまいなポート…6 4.4. 一口URIで明白なポート…7 4.5. IPv6はヘッダーを通して中でデリミタに参照をつけます…7 4.6. IPv6との一口要求は、セッション記述でプロトコル(SDP)がボディーであると扱います…9 4.7. 複数のIPが一口でヘッダーに演説します…9 4.8. SDPの複数のIPアドレス…10 4.9. IPv4によって写像されたIPv6アドレス…11 4.10. RFC3261ABNFのIPv6参照欠陥…11 5. セキュリティ問題…13 6. 承認…13 7. 参照…13 7.1. 標準の参照…13 7.2. 有益な参照…それぞれのテストメッセージの14の付録のA.のビット正確なアーカイブ…15 A.1。 参照メッセージをコード化します…16

1.  Overview

1. 概要

   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]で定義されるようにSession Initiationプロトコルの最新版(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.

仲間ドキュメントとしてこのドキュメントによって、より一般的なSIP耐久テストドキュメント[RFC4475]に使用されると予想されます。(ドキュメントはIPv6ネットワーク識別子のための特異的な試験を含んでいません)。

   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展開における相互運用性問題を引き起こすかもしれない領域に焦点を合わせようとします。

2.  Document Conventions

2. ドキュメントコンベンション

   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メッセージに関する多くの例を含んでいます。 付録はすべてのメッセージのビット正確な表現と別々のファイルの中にそれらを解読するのに必要であるスクリプトを含むコード化された二部形式を含んでいます。

Gurbani, et al.              Informational                      [Page 2]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[2ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

   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アドレスは.2.0/24アドレスが[RFC3330]で説明されるように妨げる192.0に一致しています。

   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はテキストベースのプロトコルですが、RFCsの形式に置かれた規制のため追加マーク付けなしでこれらの例のいくつかを明白に表すことができません。 このドキュメントはあいまいさを避けて、インターネット草稿レイアウト必要条件を満たすために[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>ヘッダー名: まず最初に、値、reallylongの2番目の値は3番目に</allOneLine>を評価します。

      Note that this is NOT SIP header-line folding, where different
      strings of bits have equivalent meaning.

ビットの異なったストリングには同等な意味があるところでこれがNOT SIPヘッダー系列の折り重なりであることに注意してください。

Gurbani, et al.              Informational                      [Page 3]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[3ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

3.  SIP and IPv6 Network Configuration

3. 一口とIPv6ネットワーク・コンフィギュレーション

   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.

また、デュアルスタックプロキシがそれ自体、およびメディア問題をRecord発送するべきであるとき、IPv4の外国行きのプロキシとIPv6ネットワークのAとAAAA Resource Records(RRs)、無構成発見でDNSに居住して、デュアルスタックプロキシサーバを配布するようなシステムレベル問題はIPv6への変遷における大半をプレーします。 しかしながら、このドキュメントはこれらの問題を扱いません。 代わりに仲間ドキュメント、[一口、-、移-、]、これらの問題で、より多くの指導を提供します。

4.  Parser Torture Tests

4. パーサ耐久テスト

   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]の完全なAugmented BN記法(ABNF)を参照してください。 そして、IPv6参照がaによって区切られる、「[「」、]、」 IPv6参照がSIP Uniform Resource Identifier(URI)の一部であるときに、RFC3261は、"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

一口URI=は「以下をちびちび飲みます」。 「[userinfo]hostport uri-パラメタ[ヘッダー]hostportはホスト[「:」 ポート]ホスト=ホスト名/ IPv4address / IPv6reference IPv4address=1*3DIGITと等しい」、」 「1*3DIGIT」、」 「1*3DIGIT」、」 「「[「IPv6address」]」という1*3DIGIT IPv6reference=IPv6address=hexpart[「:」 IPv4address]hexpartはhexseq / hexseqと等しい」:、:、」 「[hexseq]/」:、:、」 [hexseq]hexseq=hex4*(「:」 hex4)hex4は1*4HEXDIGと等しいです。

Gurbani, et al.              Informational                      [Page 4]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[4ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

4.1.  Valid SIP Message with an IPv6 Reference

4.1. IPv6参照がある有効な一口メッセージ

   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参照はRequest-URI(R-URI)、Viaヘッダーフィールド、および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

REGISTER一口: [2001: db8: : 10]SIP/2.0To: 一口: user@example.com From: 一口: user@example.com;tag は81×2Viaと等しいです: 一口/2.0/UDP[2001: db8: : 9:1]; ブランチはz9hG4bKas3-111呼び出しIDと等しいです: 前方へ SSG9559905523997077@hlau_4100 マックス: 70 接触: 「訪問者」<一口: 訪問者@[2001: db8: : 1]>CSeq: 98176 コンテンツの長さを示してください: 0

4.2.  Invalid SIP Message with an IPv6 Reference

4.2. IPv6参照がある無効の一口メッセージ

   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実装は400Bad Request誤りで応じるべきです。

   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

REGISTER一口:2001:db8:、:10 一口/2.0To: 一口: user@example.com From: 一口: user@example.com;tag は81×2Viaと等しいです: 一口/2.0/UDP[2001: db8: : 9:1]; ブランチはz9hG4bKas3-111呼び出しIDと等しいです: 前方へ SSG9559905523997077@hlau_4100 マックス: 70 接触: 「訪問者」<一口: 訪問者@[2001: db8: : 1]>CSeq: 98176 コンテンツの長さを示してください: 0

Gurbani, et al.              Informational                      [Page 5]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[5ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

4.3.  Port Ambiguous in a SIP URI

4.3. 一口URIであいまいなポート

   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アドレスはContact、Route、およびRecord-ルートヘッダーフィールドを含む多くのヘッダーフィールドで起こることができます。 また、彼らは「送って」Viaヘッダーフィールドのプロダクションルールの結果として現れることができます。 Implementersが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

REGISTER一口: [2001: db8: : 10:5070]SIP/2.0To: 一口: user@example.com From: 一口: user@example.com;tag は81×2Viaと等しいです: 一口/2.0/UDP[2001: db8: : 9:1]; ブランチはz9hG4bKas3-111呼び出しIDと等しいです: SSG9559905523997077@hlau_4100 接触: 「訪問者」<一口: 前方へ訪問者@[2001: db8: : 1]>マックス: 70CSeq: 98176 コンテンツの長さを示してください: 0

Gurbani, et al.              Informational                      [Page 6]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[6ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

4.4.  Port Unambiguous in a SIP URI

4.4. 一口URIで明白なポート

   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

REGISTER一口: : [2001: db8: : 10]5070SIP/2.0To: 一口: user@example.com From: 一口: user@example.com;tag は81×2Viaと等しいです: 一口/2.0/UDP[2001: db8: : 9:1]; ブランチはz9hG4bKas3-111呼び出しIDと等しいです: SSG9559905523997077@hlau_4100 接触: 「訪問者」<一口: 前方へ訪問者@[2001: db8: : 1]>マックス: 70CSeq: 98176 コンテンツの長さを示してください: 0

4.5.  IPv6 Reference Delimiters in Via Header

4.5. ヘッダーを通した中のIPv6参照デリミタ

   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」非端末が区切りを含まないように定義される、「[「」、]、」 これは第18SIP Interoperability Event[メール-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を同封することに関する異なった仮定を[]のViasのアドレスにしました。 イベントの終わりまでには、ほとんどの実装が受け入れていました。 送られるものに関するそのおよそ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

を通してそして、同じ非端末("IPv6reference")が両方に使用されるなら有益である、「発信する」、「-、受け取られている、」 プロダクションルール、ワーキンググループにはコンセンサスがその趣旨でありませんでした。 またはしたがって、示すことができるベストが実装がRobustness Principle[RFC1122]に続いて、aがパラメタを「受けた」受諾で寛容であるに違いないということである。

Gurbani, et al.              Informational                      [Page 7]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[7ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

   delimiting "[" and "]" tokens.  When sending a request,
   implementations must not put the delimiting "[" and "]" tokens.

そして、区切り、「[「」、]、」 トークン。 そして、要求を送るとき、実装が区切りを置いてはいけない、「[「」、]、」 トークン。

   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]の文法の厳しい解釈に基づく、有効な要求ではありませんが、強健な実装は、最上のViaヘッダーフィールドを分析して、それにもかかわらず、要求を処理し続けることができなければなりません。

   Message Details: via-received-param-with-delim

メッセージの詳細: 受け取られていることを通して、delimで、paramしています。

      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一口: [2001: db8: : 10]SIP/2.0To: 一口: user@example.com;tag はbd76ya From:と等しいです。 一口: user@example.com;tag は81×2<allOneLine>Viaと等しいです: 一口/2.0/UDP[2001: db8: : 9:1]; 容認された=[2001: db8: : 9:255]。 ブランチ=z9hG4bKas3-111allOneLine>呼び出し</ID: 前方へ SSG9559905523997077@hlau_4100 マックス: 70CSeq: 321 さようならコンテンツの長さ: 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要求がViaの「受け取られていている」パラメタのデコレーションのないIPv6アドレスを含んでいる、「[「」、]、」 [RFC3261]の文法によると、この要求は有効です。

   Message Details: via-received-param-no-delim

メッセージの詳細: 容認されたparamを通した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一口: [2001: db8: : 10]SIP/2.0To: 一口: user@example.com From: 一口: user@example.com;tag は81×2<allOneLine>Viaと等しいです: 一口/2.0/UDP[2001: db8: : 9:1]; 容認された=2001: db8:、:9:255; ブランチ=z9hG4bKas3allOneLine>呼び出し</ID: 前方へ SSG95523997077@hlau_4100 マックス: 70 接触: 「訪問者」<一口: 訪問者@[2001: db8: : 9:1]>CSeq: 921オプションコンテンツの長さ: 0

Gurbani, et al.              Informational                      [Page 8]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[8ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

4.6.  SIP Request with IPv6 Addresses in Session Description Protocol
      (SDP) Body

4.6. IPv6との一口要求は、セッション記述でプロトコル(SDP)がボディーであると扱います。

   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

メッセージの詳細: sdpのipv6

      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

INVITE一口: ユーザ@[2001: db8: : 10]SIP/2.0To: 一口: ユーザ@[2001: db8: : 10]From: 一口: user@example.com;tag は81×2Viaと等しいです: 一口/2.0/UDP[2001: db8: : 20]; ブランチはz9hG4bKas3-111呼び出しIDと等しいです: SSG9559905523997077@hlau_4100 接触: 「訪問者」<一口: 訪問者@[2001: db8: : 20]>CSeq: 8612は前方へマックスを招待します: 70コンテントタイプ: sdp Contentアプリケーション/長さ: 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=0oはアシスタント971731711378798081 0IN IP6 2001: db8と等しいです:、:= 20秒間、生中継ビデオは今日のミーティングc=IN IP6 2001: db8に以下を食べます:20 tは3338481189 3370017201m=オーディオの6000RTP/AVP2a=rtpmapと等しいです: 2G726-32/8000mはビデオ6024RTP/AVP107a=rtpmap: 107H263-1998/90000と等しいです。

4.7.  Multiple IP Addresses in SIP Headers

4.7. 複数のIPが一口でヘッダーに演説します。

   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参照のミックスを含んでいます。

Gurbani, et al.              Informational                      [Page 9]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[9ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

   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一口: user@host.example.net SIP/2.0Via: 一口/2.0/UDP[2001: db8: : 9:1]:6050; ブランチは以下を通ってz9hG4bKas3-111と等しいです。 一口/2.0/UDP192.0.2.1; ブランチは以下を通ってz9hG4bKjhja8781hjuaij65144<allOneLine>と等しいです。 一口/2.0/TCP[2001: db8: : 9:255]; ブランチはz9hG4bK451jjと等しいです。 容認された=192.0.2.200</allOneLine>Call-ID: 前方へ 997077@lau_4100 マックス: 70CSeq: 89187不戦勝To: 一口: user@example.net;tag は9817--94From:と等しいです。 一口: user@example.com;tag は81×2のContent-長さと等しいです: 0

4.8.  Multiple IP Addresses in SDP

4.8. SDPの複数のIPアドレス

   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

メッセージの詳細: sdpのmult-ip

      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

INVITE一口: ユーザ@[2001: db8: : 10]SIP/2.0To: 一口: ユーザ@[2001: db8: : 10]From: 一口: user@example.com;tag は81×2Viaと等しいです: 一口/2.0/UDP[2001: db8: : 9:1]; ブランチはz9hG4bKas3-111呼び出しIDと等しいです: SSG9559905523997077@hlau_4100 接触: 「訪問者」<一口: 前方へ訪問者@[2001: db8: : 9:1]>マックス: 70CSeq: 8912はコンテントタイプを招待します: sdp Contentアプリケーション/長さ: 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

0 0ボブの280744730 28977631IN v=0o=IP4 host.example.com s=t=mがオーディオの22334RTP/AVPと等しい、0、c、=IN IP4、192.0、.2、.1m、=ビデオ6024RTP/AVP、107、c、IN IP6 2001: =db8:、:1a=rtpmap: 107H263-1998/90000

Gurbani, et al.              Informational                     [Page 10]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[10ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

4.9.  IPv4-Mapped IPv6 Addresses

4.9. IPv4によって写像されたIPv6アドレス

   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).

通常、最後の32ビットがドット付き10進法IPv4アドレスとして現れていて、IPv4によって写像されたIPv6アドレスは表されます。 例えば:、:ffff: 192.0.2.1. 首尾よくそれを分析するようにそのような写像しているアドレスを含むメッセージを受け取るSIP実装を準備しなければなりません。 IPv4によって写像されたIPv6アドレスはシグナリング、シグナリングメッセージによって運ばれたSDP、または両方に現れるかもしれません。 「ポートナンバーがIPv4によって写像されたIPv6アドレスによって表されたURIの一部であるなら、区切りの外に現れなければならない」]、」(Cf。 セクション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]の文法によると、以下のメッセージは整形式です。 Viaリストは2個のViaヘッダーを入れてあます。その両方がIPv4によって写像されたIPv6アドレスを含んでいます。 また、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

INVITE一口: user@example.com SIP/2.0To: 一口: user@example.com From: 一口: user@east.example.com;tag は81×2Viaと等しいです: 一口/2.0/UDP、[: : ffff: 192.0 .2 .10]: 19823; ブランチは以下を通ってz9hG4bKbh19と等しいです。 一口/2.0/UDP、[: : ffff: 192.0 .2 .2]; ブランチはz9hG4bKas3-111呼び出しIDと等しいです: SSG9559905523997077@hlau_4100 接触: 「T.卓上電話」<一口: ted@、[: : ffff: 192.0 .2 .2] >CSeq: 612 前方へマックスを招待してください: 70コンテントタイプ: sdp Contentアプリケーション/長さ: 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

v=0oはアシスタント971731711378798081 0IN IP6と等しいです:、:192.0.2.2 s=は、すぐ、私に電話をしてください!ffff: cはIN IP6と等しいです:、:ffff: 192.0 .2 .2 tは3338481189 3370017201m=オーディオの6000RTP/AVP2a=rtpmapと等しいです: 2G726-32/8000mはビデオ6024RTP/AVP107a=rtpmapと等しいです:、107H263-1998/90000

4.10.  IPv6 Reference Bug in RFC 3261 ABNF

4.10. RFC3261ABNFのIPv6参照欠陥

   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:

それの関連部分がセクション4の先端で再生するRFC3261ABNFのIPv6referenceプロダクションルールに従って、以下の構造物に到着するのは可能です:

   [2001:db8:::192.0.2.1]

[2001、: db8: : : 192.0、.2、.1]

Gurbani, et al.              Informational                     [Page 11]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[11ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

   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.

RFC2373[RFC2373]からRFC3261でのIPv6参照に関係するABNFを得ました。(RFCはRFC4291[RFC4291]によって時代遅れにされました)。 付加的なコロンを挿入する特異的行動は、RFC2373から引き継がれて、RFC4291で改善されました。 しかしながら、Robustness Principle[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バグabnf3コロン

      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一口: ユーザ@、[2001、: db8: : : 192.0.2.1]SIP/2.0To: 一口: ユーザ@、[2001、: db8: : : 192.0、.2.1]From: 一口: user@example.com;tag は810×2Viaと等しいです: 一口/2.0/UDP lab1.east.example.com; ブランチはz9hG4bKas3-111呼び出しIDと等しいです: G9559905523997077@hlau_4100 CSeq: 689のオプションマックス-フォワード: 70 コンテンツの長さ: 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の正しいabnf2コロン

      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一口: ユーザ@、[2001、: db8: : 192.0.2.1]SIP/2.0To: 一口: ユーザ@、[2001、: db8: : 192.0、.2.1]From: 一口: user@example.com;tag は810×2Viaと等しいです: 一口/2.0/UDP lab1.east.example.com; ブランチはz9hG4bKas3-111呼び出しIDと等しいです: G9559905523997077@hlau_4100 CSeq: 689のオプションマックス-フォワード: 70 コンテンツの長さ: 0

Gurbani, et al.              Informational                     [Page 12]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[12ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

5.  Security Considerations

5. セキュリティ問題

   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

IPv6参照がシグナリングヘッダーとSDPペイロードに含まれている状態で、このドキュメントはSIPメッセージに関する例を提示します。 このドキュメントはaを処理する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識別子を分析している間に発見しているいくつかの一般的な落とし穴を含んでいます。

6.  Acknowledgments

6. 承認

   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.

作者はジョロエンバン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とワーキンググループに提供された西暦Mahendranは、最後にコメントと呼びます。

   Mohamed Boucadair and Brian Carpenter suggested new test cases for
   inclusion in the document.

モハメドBoucadairとブライアンCarpenterはドキュメントでの包含のために新しいテストケースを勧めました。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [RFC1122]     Braden, R., Ed., "Requirements for Internet Hosts -
                 Communication Layers", STD 3, RFC 1122, October 1989.

[RFC1122] ブレーデン、R.、エド、「インターネットホストのための要件--コミュニケーションは層にする」、STD3、RFC1122、10月1989日

   [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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

Gurbani, et al.              Informational                     [Page 13]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[13ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

   [RFC3330]     IANA, "Special-Use IPv4 Addresses", RFC 3330, September
                 2002.

[RFC3330]IANA、「特別な使用IPv4アドレス」、RFC3330、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.マーイ、「気絶させてください--ネットワークアドレス変換機構(NATs)を通したユーザー・データグラム・プロトコル(UDP)の簡単な縦断」、RFC3489、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]スパーク、R.Hawrylyshen、A.、ジョンストン、A.、ローゼンバーグ、J.、およびH.Schulzrinne(エド)、「セッション開始プロトコル(一口)耐久テストメッセージ」(RFC4475)は2006がそうするかもしれません。

   [RFC4566]     Handley, M., Jacobson, V., and C. Perkins, "SDP:
                 Session Description Protocol", RFC 4566, July 2006.

[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。

7.2.  Informative References

7.2. 有益な参照

   [RFC2373]     Hinden, R. and S. Deering, "IP Version 6 Addressing
                 Architecture", RFC 2373, July 1998.

[RFC2373] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。

   [RFC4291]     Hinden, R. and S. Deering, "IP Version 6 Addressing
                 Architecture", RFC 4291, February 2006.

[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、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.

[一口、-、移-、]、キャマリロ、G.、「セッション開始プロトコル(一口)におけるIPv6変遷」という高架鉄道Malki、K.、およびV.Gurbaniは進行中(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.

[メール-SIPit] スパーク、R.、「準備段階は以下を報告します」。 SIPit、何18インチも、Electronicメールは http://www1.ietf.org/mail-archive/web/ に一口/電流/msg14103.html、2006年4月を格納しました。

Gurbani, et al.              Informational                     [Page 14]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[14ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

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 -").

完全な状態で圧縮されたアーカイブファイルを回収するために、このドキュメントの原本は以下のPerlスクリプトに入力されるように通過されるかもしれません(出力は「-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);

#/usr/bin/perl使用厳しい。 私の$bdataが等しい、「「;」 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コード化されたブロックをドキュメント構造線を取り外すために手で編集して、与えることができます。

Gurbani, et al.              Informational                     [Page 15]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[15ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

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 --

-- メッセージアーカイブを始めてください; 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/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; MGUvPfSUygKvzX2Vg2f6vJ/cWp3 OLE4FLZYsFAW5ThJHoovrGEeIC8u8NC7LzuaaVG/OdG70L+j/3fJSNGf97fqgUOM4 0AB9ZAwr5j1jOf+UFpPZfSUDF/xKwj/8H0L9if4UKFSp8Y/gPJmWg1AA6AAA=があるrAIfynGKX8p8So+F8C9uR/UwGo+P/S+T91hT6Pl/RAhGKse77uyJE7PlIbhfxni/1fg6X7Pwzzav+nDHxqd1qfPl4/3/ZPHqqvBfabkrAuB0fdDrKWN4QwArNxefFCsJX/X9x4cEQFKOQ/Xth/I4v/GcMV/8vAPP93IPdTgncdzh7EkWWgKMH35A3ilOJEUTzJ7L10ehdifv5r0tdF17vTid7zR7531CigmP/Z+; メッセージアーカイブを終わらせてください--

Gurbani, et al.              Informational                     [Page 16]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[16ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

Authors' Addresses

作者のアドレス

   Vijay K. Gurbani
   Bell Laboratories, Alcatel-Lucent
   2701 Lucent Lane
   Rm 9F-546
   Lisle, IL  60532
   USA

ビジェイK.Gurbaniベル研究所、アルカテル透明な2701年の透明なレーンRm9F546ライル糸、IL60532米国

   Phone: +1 630 224 0216
   EMail: vkg@alcatel-lucent.com

以下に電話をしてください。 +1 0216年の630 224メール: vkg@alcatel-lucent.com

   Chris Boulton
   Ubiquity Software Corporation
   Building 3
   West Fawr Lane
   St Mellons
   Cardiff, South Wales  CF3 5EA

クリスボールトン偏在ソフトウェア社のBuilding3西洋Fawrレーン通りメロン・カーディフ、南ウェールズCF3 5EA

   EMail: cboulton@ubiquitysoftware.com

メール: cboulton@ubiquitysoftware.com

   Robert J. Sparks
   Estacado Systems

ロバートJ.はエスタカードシステムをかきたてます。

   EMail: RjS@estacado.net

メール: RjS@estacado.net

Gurbani, et al.              Informational                     [Page 17]

RFC 5118                 SIP IPv6 Torture Tests            February 2008

Gurbani、他 情報[17ページ]のRFC5118はIPv6耐久テスト2008年2月にちびちび飲みます。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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に情報を記述してください。

Gurbani, et al.              Informational                     [Page 18]

Gurbani、他 情報[18ページ]