idnits 2.17.1 draft-ietf-sipping-ipv6-torture-tests-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 715. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 721. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 12, 2007) is 6042 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3330 (Obsoleted by RFC 5735) ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2373 (Obsoleted by RFC 3513) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG V. Gurbani 3 Internet-Draft Bell Laboratories, Alcatel-Lucent 4 Intended status: Informational C. Boulton 5 Expires: April 14, 2008 Ubiquity Software Corporation 6 R. Sparks 7 Estacado Systems 8 October 12, 2007 10 Session Initiation Protocol (SIP) Torture Test Messages for Internet 11 Protocol Version 6 (IPv6) 12 draft-ietf-sipping-ipv6-torture-tests-04 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 14, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document provides examples of Session Initiation Protocol (SIP) 46 test messages designed to exercise and "torture" the code of an IPv6- 47 enabled SIP implementation. 49 This work is being discussed on the sipping@ietf.org mailing list. 51 Table of Contents 53 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Document conventions . . . . . . . . . . . . . . . . . . . . . 3 55 3. SIP and IPv6 network configuration . . . . . . . . . . . . . . 4 56 4. Parser torture tests . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Valid SIP message with an IPv6 reference . . . . . . . . . 5 58 4.2. Invalid SIP message with an IPv6 reference . . . . . . . . 5 59 4.3. Port ambiguous in a SIP URI . . . . . . . . . . . . . . . 6 60 4.4. Port unambiguous in a SIP URI . . . . . . . . . . . . . . 7 61 4.5. IPv6 reference delimiters in Via header . . . . . . . . . 7 62 4.6. SIP request with IPv6 addresses in Session Description 63 Protocol (SDP) body . . . . . . . . . . . . . . . . . . . 9 64 4.7. Multiple IP addresses in SIP headers . . . . . . . . . . . 9 65 4.8. Multiple IP addresses in SDP . . . . . . . . . . . . . . . 10 66 4.9. IPv4-mapped IPv6 addresses . . . . . . . . . . . . . . . . 11 67 4.10. IPv6 reference bug in RFC3261 ABNF . . . . . . . . . . . . 11 68 5. Security considerations . . . . . . . . . . . . . . . . . . . 12 69 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 8.1. Normative references . . . . . . . . . . . . . . . . . . . 13 73 8.2. Informative references . . . . . . . . . . . . . . . . . . 14 74 Appendix A. Bit-exact archive of each test message . . . . . . . 14 75 A.1. Encoded reference messages . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 77 Intellectual Property and Copyright Statements . . . . . . . . . . 18 79 1. Overview 81 This document is informational, and is NOT NORMATIVE on any aspect of 82 SIP. 84 This document contains test messages based on the current version 85 (2.0) of the Session Initiation Protocol as defined in [RFC3261]. 87 This document is expected to be used as a companion document to the 88 more general SIP torture test document [RFC4475], which does not 89 include specific tests for IPv6 network identifiers. 91 This document does not attempt to catalog every way to make an 92 invalid message, nor does it attempt to be comprehensive in exploring 93 unusual, but valid, messages. Instead, it tries to focus on areas 94 that may cause interoperability problems in IPv6 deployments. 96 2. Document conventions 98 This document contains many examples of SIP messages with IPv6 99 network identifiers. The appendix contains an encoded binary form 100 containing the bit-exact representation of all the messages and the 101 script needed to decode them into separate files. 103 The IPv6 addresses used in this document correspond to the 2001: 104 DB8::/32 address prefix reserved for documentation [RFC3489]. 105 Likewise, the IPv4 addresses used in this document correspond to the 106 192.0.2.0/24 address block as described in [RFC3330]. 108 Although SIP is a text-based protocol, some of these examples cannot 109 be unambiguously rendered without additional markup due to the 110 constraints placed on the formatting of RFCs. This document uses the 111 markup convention established in [RFC4475] to avoid 112 ambiguity and meet the Internet-Draft layout requirements. For the 113 sake of completeness, the text defining this markup from Section 2.1 114 of [RFC4475] is reproduced in its entirety below: 116 "Several of these examples contain unfolded lines longer than 72 117 characters. These are captured between tags. The 118 single unfolded line is reconstructed by directly concatenating all 119 lines appearing between the tags (discarding any line feeds or 120 carriage returns). There will be no whitespace at the end of lines. 121 Any whitespace appearing at a fold-point will appear at the beginning 122 of a line. 124 "The following represent the same string of bits: 126 Header-name: first value, reallylongsecondvalue, third value 128 129 Header-name: first value, 130 reallylongsecondvalue 131 , third value 132 134 135 Header-name: first value, 136 reallylong 137 second 138 value, 139 third value 140 142 "Note that this is NOT SIP header-line folding, where different 143 strings of bits have equivalent meaning." 145 3. SIP and IPv6 network configuration 147 System-level issues like deploying a dual-stack proxy server, 148 populating DNS with A and AAAA Resource Records (RRs), zero- 149 configuration discovery of outbound proxies for IPv4 and IPv6 150 networks, when should a dual-stack proxy Record-Route itself, and 151 media issues also play a major part in the transition to IPv6. This 152 document does not, however, address these issues. Instead, a 153 companion document [ID.sip-trans] provides more guidance on these 154 issues. 156 4. Parser torture tests 158 The test messages are organized into several sections. Some stress 159 only a SIP parser and others stress both the parser and the 160 application above it. Some messages are valid, and some are not. 161 Each example clearly calls out what makes any invalid messages 162 incorrect. 164 Please refer to the complete Augmented Backus-Naur Form (ABNF) in 165 [RFC3261] on representing IPv6 references in SIP messages. IPv6 166 references are delimited by a "[" and "]". When an IPv6 reference is 167 part of a SIP Uniform Resource Identifier (URI), RFC3261 mandates 168 that the "IPv6reference" production rule be used to recognize tokens 169 that comprise an IPv6 reference. More specifically, the ABNF states: 171 SIP-URI = "sip:" [ userinfo ] hostport 172 uri-parameters [ headers ] 173 hostport = host [ ":" port ] 174 host = hostname / IPv4address / IPv6reference 175 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 176 IPv6reference = "[" IPv6address "]" 177 IPv6address = hexpart [ ":" IPv4address ] 178 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 179 hexseq = hex4 *( ":" hex4) 180 hex4 = 1*4HEXDIG 182 4.1. Valid SIP message with an IPv6 reference 184 The request below is well-formatted according to the grammar in 185 [RFC3261]. An IPv6 reference appears in the Request-URI (R-URI), Via 186 header field, and Contact header field. 188 Message Details: ipv6-good 190 REGISTER sip:[2001:db8::10] SIP/2.0 191 To: sip:user@example.com 192 From: sip:user@example.com;tag=81x2 193 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 194 Call-ID: SSG9559905523997077@hlau_4100 195 Max-Forwards: 70 196 Contact: "Caller" 197 CSeq: 98176 REGISTER 198 Content-Length: 0 200 4.2. Invalid SIP message with an IPv6 reference 202 The request below is not well-formatted according to the grammar in 203 [RFC3261]. The IPv6 reference in the R-URI does not contain the 204 mandated delimiters for an IPv6 reference ("[" and "]"). 206 A SIP implementation receiving this request should respond with a 400 207 Bad Request error. 209 Message Details: ipv6-bad 210 REGISTER sip:2001:db8::10 SIP/2.0 211 To: sip:user@example.com 212 From: sip:user@example.com;tag=81x2 213 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 214 Call-ID: SSG9559905523997077@hlau_4100 215 Max-Forwards: 70 216 Contact: "Caller" 217 CSeq: 98176 REGISTER 218 Content-Length: 0 220 4.3. Port ambiguous in a SIP URI 222 IPv6 uses the colon to delimit octets. This may lead to ambiguity if 223 the port number on which to contact a SIP server is inadvertently 224 conflated with the IPv6 reference. Consider the REGISTER request 225 below. The sender of the request intended to specify a port number 226 (5070) to contact a server, but inadvertently, inserts the port 227 number inside the closing "]" of the IPv6 reference. Unfortunately, 228 since the IPv6 address in the R-URI is compressed, the intended port 229 number becomes the last octet of the reference. 231 From a parsing perspective, the request below is well-formed. 232 However, from a semantic point of view, it will not yield the desired 233 result. Implementations must ensure that when a raw IPv6 address 234 appears in a SIP URI, then a port number, if required, appears 235 outside the closing "]" delimiting the IPv6 reference. Raw IPv6 236 addresses can appear in the "sent-by" production rule of the Via 237 header field, the Contact header field, the Route and Record-Route 238 headers, among other headers. Implementers are urged to consult the 239 ABNF in [RFC3261] for a complete list of fields where a SIP URI can 240 appear. 242 Message Details: port-ambiguous 244 REGISTER sip:[2001:db8::10:5070] SIP/2.0 245 To: sip:user@example.com 246 From: sip:user@example.com;tag=81x2 247 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 248 Call-ID: SSG9559905523997077@hlau_4100 249 Contact: "Caller" 250 Max-Forwards: 70 251 CSeq: 98176 REGISTER 252 Content-Length: 0 254 4.4. Port unambiguous in a SIP URI 256 In contrast to the example in Section 4.3, the following REGISTER 257 request leaves no ambiguity whatsoever on where the IPv6 address ends 258 and the port number begins. This REGISTER request is well formatted 259 per the grammar in [RFC3261]. 261 Message Details: port-unambiguous 263 REGISTER sip:[2001:db8::10]:5070 SIP/2.0 264 To: sip:user@example.com 265 From: sip:user@example.com;tag=81x2 266 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 267 Call-ID: SSG9559905523997077@hlau_4100 268 Contact: "Caller" 269 Max-Forwards: 70 270 CSeq: 98176 REGISTER 271 Content-Length: 0 273 4.5. IPv6 reference delimiters in Via header 275 IPv6 references can also appear in Via header fields; more 276 specifically in the "sent-by" production rule and the "via-received" 277 production rule. In the "sent-by" production rule, the sequence of 278 octets comprising the IPv6 address is defined to appear as an 279 "IPv6reference" non-terminal, thereby mandating the "[" and "]" 280 delimiters. However, this is not the case for the "via-received" 281 non-terminal. The "via-received" production rule is defined thusly: 283 via-received = "received" EQUAL (IPv4address / IPv6address) 285 The "IPv6address" non-terminal is defined not to include the 286 delimiting "[" and "]". This has lead to the situation documented 287 during the 18th SIP Interoperability Event [Email-SIPit]: 289 Those testing IPv6 made different assumptions about enclosing 290 literal v6 addresses in Vias in []. By the end of the event, most 291 implementations were accepting either. Its about 50/50 on what 292 gets sent. 294 While it would be beneficial if the same non-terminal 295 ("IPv6reference") was used for both the "sent-by" and "via-received" 296 production rules, there has not been a consensus in the working group 297 to that effect. Thus, the best that can be suggested is that 298 implementations must follow the Robustness Principle [RFC1122] and be 299 liberal in accepting a "received" parameter with or without the 300 delimiting "[" and "]" tokens. When sending a request, 301 implementations must not put the delimiting "[" and "]" tokens. 303 The two test cases below are designed to stress this behavior. A SIP 304 implementation receiving either of these messages must parse them 305 successfully. 307 The request below contains an IPv6 address in the Via "received" 308 parameter. The IPv6 address is delimited by "[" and "]". Even 309 though this is not a valid request based on a strict interpretation 310 of the grammar in [RFC3261], robust implementations must nonetheless 311 be able to parse the topmost Via header field and continue processing 312 the request. 314 Message Details: via-received-param-with-delim 316 BYE sip:[2001:db8::10] SIP/2.0 317 To: sip:user@example.com;tag=bd76ya 318 From: sip:user@example.com;tag=81x2 319 320 Via: SIP/2.0/UDP [2001:db8::9:1];received=[2001:db8::9:255]; 321 branch=z9hG4bKas3-111 322 323 Call-ID: SSG9559905523997077@hlau_4100 324 Max-Forwards: 70 325 CSeq: 321 BYE 326 Content-Length: 0 328 The OPTIONS request below contains an IPv6 address in the Via 329 "received" parameter without the adorning "[" and "]". This request 330 is valid according to the grammar in [RFC3261]. 332 Message Details: via-received-param-no-delim 334 OPTIONS sip:[2001:db8::10] SIP/2.0 335 To: sip:user@example.com 336 From: sip:user@example.com;tag=81x2 337 338 Via: SIP/2.0/UDP [2001:db8::9:1];received=2001:db8::9:255; 339 branch=z9hG4bKas3 340 341 Call-ID: SSG95523997077@hlau_4100 342 Max-Forwards: 70 343 Contact: "Caller" 344 CSeq: 921 OPTIONS 345 Content-Length: 0 347 4.6. SIP request with IPv6 addresses in Session Description Protocol 348 (SDP) body 350 This request below is valid and well-formed according to the grammar 351 in [RFC3261]. Note that the IPv6 addresses in the SDP [RFC4566] body 352 do not have the delimiting "[" and "]". 354 Message Details: ipv6-in-sdp 356 INVITE sip:user@[2001:db8::10] SIP/2.0 357 To: sip:user@[2001:db8::10] 358 From: sip:user@example.com;tag=81x2 359 Via: SIP/2.0/UDP [2001:db8::20];branch=z9hG4bKas3-111 360 Call-ID: SSG9559905523997077@hlau_4100 361 Contact: "Caller" 362 CSeq: 8612 INVITE 363 Max-Forwards: 70 364 Content-Type: application/sdp 365 Content-Length: 268 367 v=0 368 o=assistant 971731711378798081 0 IN IP6 2001:db8::20 369 s=Live video feed for today's meeting 370 c=IN IP6 2001:db8::20 371 t=3338481189 3370017201 372 m=audio 6000 RTP/AVP 2 373 a=rtpmap:2 G726-32/8000 374 m=video 6024 RTP/AVP 107 375 a=rtpmap:107 H263-1998/90000 377 4.7. Multiple IP addresses in SIP headers 379 Th request below is valid and well-formed according to the grammar in 380 [RFC3261]. The Via list contains a mix of IPv4 addresses and IPv6 381 references. 383 Message Details: mult-ip-in-header 384 BYE sip:user@host.example.net SIP/2.0 385 Via: SIP/2.0/UDP [2001:db8::9:1]:6050;branch=z9hG4bKas3-111 386 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKjhja8781hjuaij65144 387 388 Via: SIP/2.0/TCP [2001:db8::9:255];branch=z9hG4bK451jj; 389 received=192.0.2.200 390 391 Call-ID: 997077@lau_4100 392 Max-Forwards: 70 393 CSeq: 89187 BYE 394 To: sip:user@example.net;tag=9817--94 395 From: sip:user@example.com;tag=81x2 396 Content-Length: 0 398 4.8. Multiple IP addresses in SDP 400 The request below is valid and well-formed according to the grammar 401 in [RFC3261]. The SDP contains multiple media lines, and each media 402 line is identified by a different network connection address. 404 Message Details: mult-ip-in-sdp 406 INVITE sip:user@[2001:db8::10] SIP/2.0 407 To: sip:user@[2001:db8::10] 408 From: sip:user@example.com;tag=81x2 409 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 410 Call-ID: SSG9559905523997077@hlau_4100 411 Contact: "Caller" 412 Max-Forwards: 70 413 CSeq: 8912 INVITE 414 Content-Type: application/sdp 415 Content-Length: 181 417 v=0 418 o=bob 280744730 28977631 IN IP4 host.example.com 419 s= 420 t=0 0 421 m=audio 22334 RTP/AVP 0 422 c=IN IP4 192.0.2.1 423 m=video 6024 RTP/AVP 107 424 c=IN IP6 2001:db8::1 425 a=rtpmap:107 H263-1998/90000 427 4.9. IPv4-mapped IPv6 addresses 429 An IPv4-mapped IPv6 address is usually represented with the last 32- 430 bits appearing as a dotted-decimal IPv4 address; e.g., ::ffff: 431 192.0.2.1. A SIP implementation receiving a message that contains 432 such a mapped address must be prepared to parse it successfully. An 433 IPv4-mapped IPv6 address may appear in signaling, or the SDP carried 434 by the signaling message, or in both. If a port number is part of 435 the URI represented by the IPv4-mapped IPv6 address, then it must 436 appear outside the delimiting "]" (cf. Section 4.4). 438 The message below is well-formed according to the grammar in 439 [RFC3261]. The Via list contains two Via headers, both of which 440 include an IPv4-mapped IPv6 address. An IPv4-mapped IPv6 address 441 also appears in the Contact header and the SDP. The topmost Via 442 header includes a port number that is appropriately delimited by "]". 444 Message Details: ipv4-mapped-ipv6 446 INVITE sip:user@example.com SIP/2.0 447 To: sip:user@example.com 448 From: sip:user@east.example.com;tag=81x2 449 Via: SIP/2.0/UDP [::ffff:192.0.2.10]:19823;branch=z9hG4bKbh19 450 Via: SIP/2.0/UDP [::ffff:192.0.2.2];branch=z9hG4bKas3-111 451 Call-ID: SSG9559905523997077@hlau_4100 452 Contact: "T. desk phone" 453 CSeq: 612 INVITE 454 Max-Forwards: 70 455 Content-Type: application/sdp 456 Content-Length: 236 458 v=0 459 o=assistant 971731711378798081 0 IN IP6 ::ffff:192.0.2.2 460 s=Call me soon, please! 461 c=IN IP6 ::ffff:192.0.2.2 462 t=3338481189 3370017201 463 m=audio 6000 RTP/AVP 2 464 a=rtpmap:2 G726-32/8000 465 m=video 6024 RTP/AVP 107 466 a=rtpmap:107 H263-1998/90000 468 4.10. IPv6 reference bug in RFC3261 ABNF 470 It is possible to follow the IPv6reference production rule of RFC3261 471 ABNF -- the relevant portion of which is reproduced at the top of 472 Section 4 -- and arrive at the following construct: 474 [2001:db8:::192.0.2.1] 475 Note the extra colon before the IPv4 address in the above construct. 476 The correct construct, of course, is: 478 [2001:db8::192.0.2.1] 480 The ABNF pertaining to IPv6 references in RFC3261 was derived from 481 RFC 2373 [RFC2373], which has been obsoleted by RFC 4291 [RFC4291]. 482 The specific behavior of inserting an extra colon was inherited from 483 RFC 2373, and has been remedied in RFC 4291. However, following the 484 Robustness Principle [RFC1122], an implementation must tolerate both 485 of the above constructs. 487 The message below includes an extra colon in the IPv6 reference. A 488 SIP implementation receiving such a message may exhibit robustness by 489 successfully parsing the IPv6 reference (it can choose to delete the 490 extra colon when parsing the IPv6 reference.) 492 Message Details: ipv6-bug-abnf-3-colons 494 OPTIONS sip:user@[2001:db8:::192.0.2.1] SIP/2.0 495 To: sip:user@[2001:db8:::192.0.2.1] 496 From: sip:user@example.com;tag=810x2 497 Via: SIP/2.0/UDP lab1.east.example.com;branch=z9hG4bKas3-111 498 Call-ID: G9559905523997077@hlau_4100 499 CSeq: 689 OPTIONS 500 Max-Forwards: 70 501 Content-Length: 0 503 The next message has the correct syntax for the IPv6 reference in the 504 R-URI. 506 Message Details: ipv6-correct-abnf-2-colons 508 OPTIONS sip:user@[2001:db8::192.0.2.1] SIP/2.0 509 To: sip:user@[2001:db8::192.0.2.1] 510 From: sip:user@example.com;tag=810x2 511 Via: SIP/2.0/UDP lab1.east.example.com;branch=z9hG4bKas3-111 512 Call-ID: G9559905523997077@hlau_4100 513 CSeq: 689 OPTIONS 514 Max-Forwards: 70 515 Content-Length: 0 517 5. Security considerations 519 This document presents examples of SIP messages with IPv6 references 520 contained in the signaling headers and SDP payload. While this 521 document may clarify the behavior of SIP elements processing a 522 message with IPv6 references, it does not normatively change the base 523 SIP [RFC3261] specification in any way. Consequently, all security 524 considerations in [RFC3261] apply. 526 Parsers must carefully consider edge conditions and malicious input 527 as part of their design. Attacks on many Internet systems use 528 crafted input to cause implementations to behave in undesirable ways. 529 Many of the messages in this draft are designed to stress a parser 530 implementation at points traditionally used for such attacks. This 531 document does not, however, attempt to be comprehensive. It contains 532 some common pitfalls that the authors have discovered while parsing 533 IPv6 identifiers in SIP implementations. 535 6. IANA considerations 537 This document does not contain any actions for IANA. 539 7. Acknowledgments 541 The authors thank Jeroen van Bemmel, Dennis Bijwaard, Gonzalo 542 Camarillo, Bob Gilligan, Alan Jeffrey, Larry Kollasch, Erik Nordmark, 543 Kumiko Ono, Pekka Pessi, Jon Peterson and other members of the SIP- 544 related working groups for input provided during the construction of 545 the document and discussion of the test cases. 547 A.B. Nataraju and A.C. Mahendran provided working group last call 548 comments. 550 Mohamed Boucadair and Brian Carpenter suggested new test cases for 551 inclusion in the document. 553 8. References 555 8.1. Normative references 557 [RFC1122] Braden, R., "Requirements for Internet Hosts - 558 Communication Layers", STD 3, RFC 1122, October 1989. 560 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 561 A., Peterson, J., Sparks, R., Handley, M., and E. 562 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 563 June 2002. 565 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 566 September 2002. 568 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 569 "STUN - Simple Traversal of User Datagram Protocol (UDP) 570 Through Network Address Translators (NATs)", RFC 3489, 571 March 2003. 573 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 574 and H. Schulzrinne, "Session Initiation Protocol (SIP) 575 Torture Test Messages", RFC 4475, May 2006. 577 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 578 Description Protocol", RFC 4566, July 2006. 580 8.2. Informative references 582 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 583 Architecture", RFC 2373, July 1998. 585 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 586 Architecture", RFC 4291, February 2006. 588 [ID.sip-trans] 589 Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 590 Transition in the Session Initiation Protocol (SIP)", 591 draft-ietf-sipping-v6-transition-07.txt (work in 592 progress), August 2007. 594 [Email-SIPit] 595 Sparks, R., "preliminary report: SIPit 18", Electronic 596 Mail archived at http://www1.ietf.org/mail-archive/web/ 597 sip/current/msg14103.html, April 2006. 599 Appendix A. Bit-exact archive of each test message 601 The following text block is an encoded, gzip compressed TAR archive 602 of files that represent each of the example messages discussed in 603 Section 4. 605 To recover the compressed archive file intact, the text of this 606 document may be passed as input to the following Perl script (the 607 output should be redirected to a file or piped to "tar -xzvf -"). 609 #!/usr/bin/perl 610 use strict; 611 my $bdata = ""; 612 use MIME::Base64; 613 while(<>) { 614 if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) { 615 if ( m/^\s*[^\s]+\s*$/) { 616 $bdata = $bdata . $_; 617 } 618 } 619 } 620 print decode_base64($bdata); 622 Alternatively, the base-64 encoded block can be edited by hand to 623 remove document structure lines and fed as input to any base-64 624 decoding utility. 626 A.1. Encoded reference messages 627 -- BEGIN MESSAGE ARCHIVE -- 628 H4sICPujD0cAA21zZy50YXIA7Vpbc6M2GPUzv0Ldl74UWzckIHUnbXY39XS760ncz 629 HQ6mY5sFBuvDRSwN+mvrwAb303c2GQ34byAjYSEpHO+i1Rv1E4OCCnkEKorRJyl1+ 630 R2dk1RQ6oE4RhxRNT/CCHGa8bpu1arTaJYhKrJ6ef+3nJ+PJDhnufzD8ku+LidPB3 631 qDTeYUn0sgkA6urpnx28DIggZpbvmHyFOF/NPWTL/FFFcg8fvyiZe+fy3Pt60Ou9A 632 5Ab2JJLhubwX42Ak6z1/DK5b7QauQ63j21sLaO9Df7z8SERxfen5WSz6TRPdY+3GF 633 fb8dY0/3rbBX7Z9p2AjS/1Tx3UEb9W9iclZNxReb9D81xpc0u5v3QGyimvj27VqIi 634 K60hDtQoxGeuutqn19aRmGZUHDwMSyOOT8fDASk7+pWpvahe/Fohfb4E2nDhwZfQb 635 BwPfkG/Bj8m2xdM43W/xJu7iW/9iAIQyyQdR+F/f6ez/8IkInsgHP3iu9WO88BNIG 636 imIjtydi1/cakRPkTz9Irx8PbIAJ07RpE2p+U0SRq9alFwOLI06UKiLCTW6Z0EQAq 637 vZAq83Aep+0qJl8MBhLEPm+9wNQ8yAi+Z3Wa+6qETcJISY1ETItQAhPGIoh0sZNMX 638 FcHzC1lsFVp934+aYNsCaaYRworbAxuOSY6QQ3TFVCFZ+6jkyKY5oXV5ReVFA/wK+ 639 YqWmxLLNhJRzRnnvtV5jpP9O7wjldGwX6DyklSv8Z5AZEmPNE/7FBWKX/JeDq3WXr 640 uvPuKlVxrEbedrqmreh6uPo/TvgXbVg2eqJubxXcTMiTN8hwpuC99Mf5Utso12/LV 641 GsSzIdhQ5Sh9rJlasb/vu+fTgCK+W8s+I9pyn9OKv+vDKzwf5kg8LZSgFegADP+u5 642 6uXNITtVEU/0GO5/zHkKX2X7m8vOJ/CViP/x4jAatlnqwCGB4tfCvgvGppTnrziHE 643 bMw+L25Y7pGK2D+5Ugix+upPSAXd+CGLfEQ/fRyqUk7Hr9RcR3ErdKnqr8ETUG+PJ 644 KNbdIDEBAymcvSL3/1Dk/6l1l+s/wjDN/xECK/0vAb/8uST+A38pgefJOJf/IifOZ 645 tCAO0R8o26e81urMBwMhclNNBhOhDtkBqJ0tXLnYq1hbBjrpoMaaDg8C2VPKlV1mn 646 mmKzETc2syMyB7nMjMRFjI5EAN0HYHWI1Pat8S91HXLfooO/jVOZcr/D+RC1jEf85 647 Zzn+MMv9PWc6K/yXgK/D/nh4FPtoBtNKwbzffc5fwMA8QmWjuAXb9LsAm5JRyAtWd 648 pRY3QZnnR8GKwCYRdNRUThwEMHfZMCZk4YTBueNHF6q5213b4iSiIh+u3gj8MNbFu 649 Ov2J/4kOsUaK8z/GLn9R4Rl9l+NYMX/ErA7/2MbkH8bSaCDcj47yP9ak0Az/k+8Ey 650 rAIfynGKX8p8So+F8C9uR/UwGo+P/S+T91hT6Pl/RAhGKse77uyJE7PlIbhfxni/1 651 fg6X7Pwzzav+nDHxqd1qfPl4/3/ZPHqqvBfabkrAuB0fdDrKWN4QwArNxefFCsJX/ 652 X9x4cEQFKOQ/Xth/I4v/GcMV/8vAPP93IPdTgncdzh7EkWWgKMH35A3ilOJEUTzJ7 653 L10ehdifv5r0tdF17vTid7zR7531CigmP/Z+W/MGUvPfSUygKvzX2Vg2f6vJ/cWp3 654 OLE4FLZYsFAW5ThJHoovrGEeIC8u8NC7LzuaaVG/OdG70L+j/3fJSNGf97fqgUOM4 655 0AB9ZAwr5j1jOf+UFpPZfSUDF/xKwj/8H0L9if4UKFSp8Y/gPJmWg1AA6AAA= 656 -- END MESSAGE ARCHIVE -- 658 Authors' Addresses 660 Vijay K. Gurbani 661 Bell Laboratories, Alcatel-Lucent 662 2701 Lucent Lane 663 Rm 9F-546 664 Lisle, IL 60532 665 USA 667 Phone: +1 630 224 0216 668 Email: vkg@alcatel-lucent.com 669 Chris Boulton 670 Ubiquity Software Corporation 671 Building 3 672 West Fawr Lane 673 St Mellons 674 Cardiff, South Wales CF3 5EA 676 Email: cboulton@ubiquitysoftware.com 678 Robert J. Sparks 679 Estacado Systems 681 Email: RjS@estacado.net 683 Full Copyright Statement 685 Copyright (C) The IETF Trust (2007). 687 This document is subject to the rights, licenses and restrictions 688 contained in BCP 78, and except as set forth therein, the authors 689 retain all their rights. 691 This document and the information contained herein are provided on an 692 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 693 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 694 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 695 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 696 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 697 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 699 Intellectual Property 701 The IETF takes no position regarding the validity or scope of any 702 Intellectual Property Rights or other rights that might be claimed to 703 pertain to the implementation or use of the technology described in 704 this document or the extent to which any license under such rights 705 might or might not be available; nor does it represent that it has 706 made any independent effort to identify any such rights. Information 707 on the procedures with respect to rights in RFC documents can be 708 found in BCP 78 and BCP 79. 710 Copies of IPR disclosures made to the IETF Secretariat and any 711 assurances of licenses to be made available, or the result of an 712 attempt made to obtain a general license or permission for the use of 713 such proprietary rights by implementers or users of this 714 specification can be obtained from the IETF on-line IPR repository at 715 http://www.ietf.org/ipr. 717 The IETF invites any interested party to bring to its attention any 718 copyrights, patents or patent applications, or other proprietary 719 rights that may cover technology that may be required to implement 720 this standard. Please address the information to the IETF at 721 ietf-ipr@ietf.org. 723 Acknowledgment 725 Funding for the RFC Editor function is provided by the IETF 726 Administrative Support Activity (IASA).