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
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)
Internet协议版本6（IPv6）的会话启动协议（SIP）测试消息
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.
本文档提供了会话启动协议（SIP）测试消息的示例，这些消息旨在练习和“折磨”支持IPv6的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
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.
本文件预计将作为更通用的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部署中可能导致互操作性问题的领域。
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地址对应于为文档[RFC3489]保留的2001:DB8:：/32地址前缀。同样，本文档中使用的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
标题名称：第一个值、reallylongsecondvalue、第三个值
<allOneLine> Header-name: first value, reallylongsecondvalue , third value </allOneLine>
<allOneLine>标题名称：第一个值、reallylongsecondvalue、第三个值
<allOneLine> Header-name: first value, reallylong second value, third value </allOneLine>
<allOneLine>标题名称：第一个值、reallylong第二个值、第三个值
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资源记录（RRs）填充DNS、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:
请参阅[RFC3261]中关于在SIP消息中表示IPv6引用的完整扩充的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
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）、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 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引用的强制分隔符（“[”和“]”）。
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
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引用的结束“]”之外。原始IPv6地址可以出现在许多头字段中，包括联系人、路由和记录路由头字段。它们也可以作为Via标题字段的“发送人”生产规则的结果出现。敦促实施者参考[RFC3261]中的ABNF，以获得可以显示SIP URI的字段的完整列表。
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 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
消息详细信息：端口无歧义
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 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引用也可以出现在Via标头字段中；更具体地说，在“发送人”生产规则和“通过接收”生产规则中。在“发送人”生成规则中，包含IPv6地址的八位字节序列被定义为显示为“IPv6reference”非终端，从而强制使用“[”和“]”分隔符。然而，“通过接收”非终端并非如此。“通过接收”生成规则定义如下：
via-received = "received" EQUAL (IPv4address / IPv6address)
via received=“received”等于（IPv4address/IPV6地址）
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地址做出了不同的假设。到活动结束时，大多数实现都接受了这两种情况。发送的内容大约各占一半。
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”）将是有益的，但工作组尚未就此达成共识。因此，最好的建议是实现必须遵循健壮性原则[RFC1122]，并且在接受带有或不带有
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.
下面的两个测试用例旨在强调这种行为。接收这些消息的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“received”参数中包含IPv6地址。IPv6地址由“[”和“]”分隔。尽管基于[RFC3261]中严格的语法解释，这不是一个有效的请求，但健壮的实现必须能够通过头字段解析最顶层并继续处理请求。
Message Details: via-received-param-with-delim
消息详细信息：通过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
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].
下面的选项请求在Via“received”参数中包含一个IPv6地址，但没有修饰“[”和“]”。根据[RFC3261]中的语法，此请求有效。
Message Details: via-received-param-no-delim
消息详细信息：通过收到的参数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
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
消息详细信息：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 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
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
消息详细信息：头中的多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
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
消息详细信息：sdp中的多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 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
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映射的IPv6地址通常用最后32位表示为点十进制IPv4地址；e、 g.：：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]中的语法，下面的消息格式正确。Via列表包含两个Via标头，这两个标头都包含IPv4映射的IPv6地址。IPv4映射的IPv6地址也会出现在联系人标头和SDP中。最顶端的Via标头包括一个端口号，该端口号由“]”适当分隔。
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
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
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的IPV6参考生成规则（第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[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引用中包含一个额外的冒号。通过成功解析IPv6引用，接收此类消息的SIP实现可能会表现出健壮性（在解析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
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
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.
解析器必须仔细考虑边缘条件和恶意输入作为其设计的一部分。对许多Internet系统的攻击使用精心编制的输入，导致实现以不希望的方式运行。本文档中的许多消息旨在强调传统上用于此类攻击的解析器实现。然而，本文件并不试图全面。它包含一些作者在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：会话启动协议”，RFC 3261，2002年6月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330]IANA，“特殊用途IPv4地址”，RFC33302002年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，“STUN-通过网络地址转换器（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.，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：会话描述协议”，RFC4566，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 23731998年7月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年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.
[电子邮件SIPit]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.
下面的文本块是一个编码的、gzip压缩的TAR归档文件，表示第4节中讨论的每个示例消息。
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);
#!/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.
或者，可以手动编辑base-64编码块以移除文档结构行，并将其作为输入馈送到任何base-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 --
-- 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实验室，阿尔卡特朗讯2701朗讯巷，美国伊利诺伊州利斯勒9F-546室，邮编：60532
Phone: +1 630 224 0216
EMail: vkg@alcatel-lucent.com
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
Chris Boulton Ubiquity软件公司大楼3 West Fawr Lane St Mellons Cardiff，南威尔士CF3 5EA
EMail: cboulton@ubiquitysoftware.com
EMail: cboulton@ubiquitysoftware.com
Robert J. Sparks Estacado Systems
Robert J.Sparks Estacado系统公司
EMail: RjS@estacado.net
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.