RFC 5118 SIP IPv6 Torture Tests February 2008
Table of Contents
1. Overview ........................................................22. Document conventions ............................................23. SIP and IPv6 Network Configuration ..............................44. Parser Torture Tests ............................................44.1. Valid SIP Message with an IPv6 Reference ...................54.2. Invalid SIP Message with an IPv6 Reference .................54.3. Port Ambiguous in a SIP URI ................................64.4. Port Unambiguous in a SIP URI ..............................74.5. IPv6 Reference Delimiters in Via Header ....................7
4.6. SIP Request with IPv6 Addresses in
Session Description Protocol (SDP) Body.....................94.7. Multiple IP Addresses in SIP Headers .......................94.8. Multiple IP Addresses in SDP ..............................104.9. IPv4-Mapped IPv6 Addresses ................................114.10. IPv6 Reference Bug in RFC 3261 ABNF ......................115. Security Considerations ........................................136. Acknowledgments ................................................137. References .....................................................137.1. Normative References ......................................137.2. Informative References ....................................14Appendix A. Bit-Exact Archive of Each Test Message ...............15A.1. Encoded Reference Messages ...............................161. 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 20084.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 20084.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 20084.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 RFC3261 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 20085. 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. References7.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
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]