doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc5118.txt b/doc/rfc/rfc5118.txt
new file mode 100644
index 0000000..731bacb
--- /dev/null
+++ b/doc/rfc/rfc5118.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                         V. Gurbani
+Request for Comments: 5118             Bell Laboratories, Alcatel-Lucent
+Category: Informational                                      C. Boultond
+                                           Ubiquity Software Corporation
+                                                               R. Sparks
+                                                        Estacado Systems
+                                                           February 2008
+
+
+      Session Initiation Protocol (SIP) Torture Test Messages for
+                   Internet Protocol Version 6 (IPv6)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Abstract
+
+   This document provides examples of Session Initiation Protocol (SIP)
+   test messages designed to exercise and "torture" the code of an
+   IPv6-enabled SIP implementation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al.              Informational                      [Page 1]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+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
+
+   This document is informational, and is *not normative* on any aspect
+   of SIP.
+
+   This document contains test messages based on the current version
+   (2.0) of the Session Initiation Protocol as defined in [RFC3261].
+
+   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.
+
+   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.
+
+2.  Document Conventions
+
+   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.
+
+
+
+Gurbani, et al.              Informational                      [Page 2]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+   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].
+
+   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:
+
+      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.
+
+      The following represent the same string of bits:
+
+      Header-name: first value, reallylongsecondvalue, third value
+
+         <allOneLine>
+         Header-name: first value,
+          reallylongsecondvalue
+         , third value
+         </allOneLine>
+
+         <allOneLine>
+         Header-name: first value,
+          reallylong
+         second
+         value,
+          third value
+         </allOneLine>
+
+      Note that this is NOT SIP header-line folding, where different
+      strings of bits have equivalent meaning.
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al.              Informational                      [Page 3]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+3.  SIP and IPv6 Network Configuration
+
+   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.
+
+4.  Parser Torture Tests
+
+   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.
+
+   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-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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al.              Informational                      [Page 4]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+4.1.  Valid SIP Message with an IPv6 Reference
+
+   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.
+
+   Message Details: 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
+
+4.2.  Invalid SIP Message with an IPv6 Reference
+
+   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 "]").
+
+   A SIP implementation receiving this request should respond with a 400
+   Bad Request error.
+
+   Message Details: 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al.              Informational                      [Page 5]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+4.3.  Port Ambiguous in a SIP 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.
+
+   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.
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al.              Informational                      [Page 6]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+4.4.  Port Unambiguous in a SIP 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].
+
+   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
+
+4.5.  IPv6 Reference Delimiters in Via Header
+
+   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:
+
+      via-received = "received" 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]:
+
+      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.
+
+   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
+
+
+
+
+Gurbani, et al.              Informational                      [Page 7]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+   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.
+
+   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.
+
+   Message Details: 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].
+
+   Message Details: 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
+
+
+
+
+
+Gurbani, et al.              Informational                      [Page 8]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+4.6.  SIP Request with IPv6 Addresses in Session Description Protocol
+      (SDP) Body
+
+   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 "]".
+
+   Message Details: 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
+
+4.7.  Multiple IP Addresses in SIP Headers
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al.              Informational                      [Page 9]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+   Message Details: 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
+
+4.8.  Multiple IP Addresses in SDP
+
+   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.
+
+   Message Details: 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
+
+
+
+
+
+
+
+Gurbani, et al.              Informational                     [Page 10]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+4.9.  IPv4-Mapped IPv6 Addresses
+
+   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).
+
+   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 "]".
+
+   Message Details: 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
+
+4.10.  IPv6 Reference Bug in RFC 3261 ABNF
+
+   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:
+
+   [2001:db8:::192.0.2.1]
+
+
+
+Gurbani, et al.              Informational                     [Page 11]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+   Note the extra colon before the IPv4 address in the above construct.
+   The correct construct, of course, is:
+
+   [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.
+
+   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).
+
+   Message Details: 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.
+
+   Message Details: 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
+
+
+
+
+
+
+
+Gurbani, et al.              Informational                     [Page 12]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+5.  Security Considerations
+
+   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
+
+   message with IPv6 references, it does not normatively change the base
+   SIP [RFC3261] specification in any way.  Consequently, all security
+   considerations in [RFC3261] apply.
+
+   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.
+
+6.  Acknowledgments
+
+   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.
+
+   This work is being discussed on the sipping@ietf.org mailing list.
+
+   A.B. Nataraju and A.C. Mahendran provided working group last call
+   comments.
+
+   Mohamed Boucadair and Brian Carpenter suggested new test cases for
+   inclusion in the document.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC1122]     Braden, R., Ed., "Requirements for Internet Hosts -
+                 Communication Layers", STD 3, RFC 1122, October 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.
+
+
+
+
+
+Gurbani, et al.              Informational                     [Page 13]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+   [RFC3330]     IANA, "Special-Use IPv4 Addresses", RFC 3330, September
+                 2002.
+
+   [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.
+
+   [RFC4475]     Sparks, R., Ed., Hawrylyshen, A., Johnston, A.,
+                 Rosenberg, J., and H. Schulzrinne, "Session Initiation
+                 Protocol (SIP) Torture Test Messages", RFC 4475, May
+                 2006.
+
+   [RFC4566]     Handley, M., Jacobson, V., and C. Perkins, "SDP:
+                 Session Description Protocol", RFC 4566, July 2006.
+
+7.2.  Informative References
+
+   [RFC2373]     Hinden, R. and S. Deering, "IP Version 6 Addressing
+                 Architecture", RFC 2373, July 1998.
+
+   [RFC4291]     Hinden, R. and S. Deering, "IP Version 6 Addressing
+                 Architecture", RFC 4291, February 2006.
+
+   [sip-trans]   Camarillo, G., El Malki, K., and V. Gurbani, "IPv6
+                 Transition in the Session Initiation Protocol (SIP)",
+                 Work in Progress, August 2007.
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al.              Informational                     [Page 14]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+Appendix A.  Bit-Exact Archive of Each Test Message
+
+   The following text block is an encoded, gzip compressed TAR archive
+   of files that represent each of the example messages discussed in
+   Section 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 -").
+
+   #!/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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al.              Informational                     [Page 15]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+A.1.  Encoded Reference Messages
+
+   -- 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 --
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al.              Informational                     [Page 16]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+Authors' Addresses
+
+   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
+
+   EMail: cboulton@ubiquitysoftware.com
+
+
+   Robert J. Sparks
+   Estacado Systems
+
+   EMail: RjS@estacado.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al.              Informational                     [Page 17]
+
+RFC 5118                 SIP IPv6 Torture Tests            February 2008
+
+
+Full Copyright Statement
+
+   Copyright (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.
+
+   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.
+
+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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani, et al.              Informational                     [Page 18]
+