[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 5118

SIPPING WG                                               V. Gurbani, Ed.
Internet-Draft                         Bell Laboratories, Alcatel-Lucent
Intended status: Informational                                C. Boulton
Expires: November 5, 2007                  Ubiquity Software Corporation
                                                               R. Sparks
                                                        Estacado Systems
                                                             May 4, 2007


  Session Initiation Protocol (SIP) Torture Test Messages for Internet
                       Protocol Version 6 (IPv6)
                draft-ietf-sipping-ipv6-torture-tests-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 5, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This informational document provides examples of Session Initiation
   Protocol (SIP) test messages designed to exercise and "torture" the
   code of a SIP implementation that parses IPv6 addresses.




Gurbani, et al.         Expires November 5, 2007                [Page 1]

Internet-Draft           SIP IPv6 Torture Tests                 May 2007


   This work is being discussed on the sipping@ietf.org mailing list.


Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Document conventions . . . . . . . . . . . . . . . . . . . . .  3
   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 URI  . . . . . . . . . . . . . . . . .  6
     4.4.  Port unambiguous in a URI  . . . . . . . . . . . . . . . .  6
     4.5.  IPv6 reference delimiters in Via header addresses  . . . .  7
     4.6.  SIP request with IPv6 addresses in Session Description
           Protocol (SDP) body  . . . . . . . . . . . . . . . . . . .  8
     4.7.  Multiple IP addresses in SIP headers . . . . . . . . . . .  9
     4.8.  Multiple IP addresses in SDP . . . . . . . . . . . . . . . 10
   5.  Security considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative references . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative references . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Bit-exact archive of each test message  . . . . . . . 12
     A.1.  Encoded reference messages . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 15























Gurbani, et al.         Expires November 5, 2007                [Page 2]

Internet-Draft           SIP IPv6 Torture Tests                 May 2007


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 example SIP messages.  The appendix
   contains an encoded binary form containing the bit-exact
   representation of the messages and the algorithm needed to decode
   them into separate files.

   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:




Gurbani, et al.         Expires November 5, 2007                [Page 3]

Internet-Draft           SIP IPv6 Torture Tests                 May 2007


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


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 should a dual-stack proxy 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 [ID.sip-trans] provides more guidance on these
   issues.


4.  Parser torture tests

   The test messages are organized into several sections.  Some stress
   only a 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.  IPv6 references
   are delimited by a "[" and "]".  When an IPv6 reference is part of a
   SIP Uniform Resource Identifier (URI), RFC3261 mandates that the
   "IPv6reference" production rule be used to recognize tokens that
   comprise an IPv6 reference.  More specifically, the ABNF states:




Gurbani, et al.         Expires November 5, 2007                [Page 4]

Internet-Draft           SIP IPv6 Torture Tests                 May 2007


     SIP-URI        =  "sip:" [ userinfo ] hostport
                       uri-parameters [ headers ]
     hostport       =  host [ ":" port ]
     host           =  hostname / IPv4address / IPv6reference
     IPv6reference  =  "[" IPv6address "]"
     IPv6address    =  hexpart [ ":" IPv4address ]
     hexpart        =  hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
     hexseq         =  hex4 *( ":" hex4)
     hex4           =  1*4HEXDIG

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

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



Gurbani, et al.         Expires November 5, 2007                [Page 5]

Internet-Draft           SIP IPv6 Torture Tests                 May 2007


      Content-Length: 0


4.3.  Port ambiguous in a 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, inserts 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 appear in the "sent-by" production rule of the Via
   header field, the Contact header field, the Route and Record-Route
   headers, among other headers.  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


4.4.  Port unambiguous in a 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





Gurbani, et al.         Expires November 5, 2007                [Page 6]

Internet-Draft           SIP IPv6 Torture Tests                 May 2007


      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 addresses

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

      via-received = "received" EQUAL (IPv4address / IPv6address)

   The "IPv6address" non-terminal is defined not to include the
   delimiting "[" and "]".  This has lead 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
   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.  An
   element 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



Gurbani, et al.         Expires November 5, 2007                [Page 7]

Internet-Draft           SIP IPv6 Torture Tests                 May 2007


   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


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




Gurbani, et al.         Expires November 5, 2007                [Page 8]

Internet-Draft           SIP IPv6 Torture Tests                 May 2007


     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

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

   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









Gurbani, et al.         Expires November 5, 2007                [Page 9]

Internet-Draft           SIP IPv6 Torture Tests                 May 2007


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


5.  Security considerations

   This document presents NON-NORMATIVE examples of SIP session
   establishment.  The 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 draft 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.  IANA considerations

   This document does not contain any actions for IANA.



Gurbani, et al.         Expires November 5, 2007               [Page 10]

Internet-Draft           SIP IPv6 Torture Tests                 May 2007


7.  Acknowledgments

   The authors thank Jeroen van Bemmel, Dennis Bijwaard, Gonzalo
   Camarillo, Bob Gilligan, Alan Jeffrey, Larry Kollasch, Erik Nordmark,
   Kumiko Ono, Pekka Pessi, and other members of the SIP-related working
   groups for input provided during the construction of the document and
   discussion of the test cases.

   A.B. Nataraju and A.C. Mahendran provided working group last call
   comments.


8.  References

8.1.  Normative references

   [RFC1122]  Braden, R., "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.

   [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., 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.

8.2.  Informative references

   [ID.sip-trans]
              Camarillo, G., El Malki, K., and V. Gurbani, "IPv6
              Transition in the Session Initiation Protocol (SIP)",
              draft-ietf-sipping-v6-transition-04.txt (work in
              progress), September 2006.

   [Email-SIPit]



Gurbani, et al.         Expires November 5, 2007               [Page 11]

Internet-Draft           SIP IPv6 Torture Tests                 May 2007


              Sparks, R., "preliminary report: SIPit 18", Electronic
              Mail archived at http://www1.ietf.org/mail-archive/web/
              sip/current/msg14103.html, April 2006.


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.

A.1.  Encoded reference messages

















Gurbani, et al.         Expires November 5, 2007               [Page 12]

Internet-Draft           SIP IPv6 Torture Tests                 May 2007


     -- BEGIN MESSAGE ARCHIVE --
     H4sICN2EHkYAA2FyY2hpdmUudGFyAO1ZXXPiNhTNs3+FZl/65KAry5Ll1J202WzKd
     LvLBJqZTifTEdiLTfFHbcMm++tXNjEQAjhpgN0mPi8YJPnaQufco6sgmTK9L92jPQ
     IDxozSI4wxcIaLz+Ly7hNjSo0jwAxzEwPhXP0OhAI5wvt8qAqTLJepCjn9Z7i1X5z
     7XrqlffYm1cvx3T7k/nB5ftHu9s4vURYkNlEzb7t9y7YBo2670yLHWOvFdtk4ybz0
     1LuRYTL2jgdxqL1L43B900kuh44FN0S7CqRd3an1x9sO+msRQ9hwfdJPZTTwnS/Cv
     6D932Rm6ACgncnxWG+/VUO7F8I0hcCmSQwhOOb81B/Lyd9UrSntd3mjv4vTzzJ1Mx
     txrJ3FUS4HuY3eFHfw0jfox+L5BuWX06XYcP2Tdtb1/rWRsNSaRNU0lHfwolx/70X
     D3LcR1rRv/RftFUHB/2Ec71MA6vlvLvhPaMl/hlnD/wPgHv+XCYKvGwV4BQpQ8j+I
     9MxN9hajhv+AOan4TzAr87+BTaPh/wHQ/nDV7p0vOPwYCbjf59kqQPAzReDRnFeRK
     tJbDAiavfx6ESkkoHebeDaSSTIOBjIP4qilaPJAIAizNG3qYC12ZJYFaj1FORIcuA
     EcwOAWFxa2AGEVD7U7DC0/kJY574Oph6aB68Xok+e56FOcojx25e0PGQo9Lw+ioTZ
     w1o3NHcMwLGoBWAIZBi/4RTBooSMnbhAjplYiuux1Wj9fdRDRpJPmSSiVz0MXnDDd
     IC1L9VDdZ9EZJnTeXbFyMUB9Qb8Spv4VIayWKFb4SxbFV4RwMs71IClSgO9Jd6vE/
     VfU+T+17ub6D6RoB0owbfT/APjlzyXx9+MsP670O/LyufzXmTibYRNvEPEHY0Goq2
     NyDCsDRv5IWtwCfzSRwYiZQOn9wb2zlcDENFdTBzVhNDpJvYGnVNV1qlikSBNVNrl
     LIFtM5CxFCLA4UhO03gCr+SnzW2EfdV3QR+XB785cLvF/bxawjv+cszn/Ccz8n8nM
     hv8HwHfg/56/C3y0ARTltm8z3+eW8GkOECyoHGA/7iNiYU4pN7C6EmpxGzBzfhTdE
     9hiB505ysRhhOeWjRDDWJgwXBk/ulDNzXZtjUmEOg+XxGmuy7AfDCfxJNvPGqut/5
     jz/A9G2a5cs4kb/h8Am+s/ton5/6MI9KSazwbyv9YiUMn/SbRXBXgK/ymB0v8bAA3
     /D4At9d9SABr+v2z+TwOpV7slPZGpDPUo1l1vHIQ7i1HLf7Y4/zVZef7DgDbnP4fA
     x06v/fFD99sd/8y36isb+4eSsCoHOz0OEssHQgTQ3by8eCFYw//PQe7vVAFq+U8W+
     d+c7f8Z5Q3/D4Gq/vdE7pcE77uc3cody0Bdge/ZB8QlxQ1F8aKy99Lp3aBBgwYb8R
     U5DHG1ACoAAA==
     -- END MESSAGE ARCHIVE --


Authors' Addresses

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

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













Gurbani, et al.         Expires November 5, 2007               [Page 13]

Internet-Draft           SIP IPv6 Torture Tests                 May 2007


   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.         Expires November 5, 2007               [Page 14]

Internet-Draft           SIP IPv6 Torture Tests                 May 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Gurbani, et al.         Expires November 5, 2007               [Page 15]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/