SIPPING WGNetwork Working Group V. GurbaniInternet-DraftRequest for Comments: 5118 Bell Laboratories, Alcatel-LucentIntended status:Category: Informational C. BoultonExpires: April 14, 2008Ubiquity Software Corporation R. Sparks Estacado SystemsOctober 12, 2007January 2008 Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)draft-ietf-sipping-ipv6-torture-tests-04Status ofthisThis MemoBy 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 ofThis memo provides information for the InternetEngineering 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.community. Itis inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The listdoes not specify an Internet standard ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listany kind. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2007).this memo is unlimited. Abstract This document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the code of anIPv6- enabledIPv6-enabled SIP implementation.This work is being discussed on the sipping@ietf.org mailing list.Table of Contents 1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 3........................................................2 2. Document conventions. . . . . . . . . . . . . . . . . . . . . 3............................................2 3. SIP and IPv6network configuration . . . . . . . . . . . . . . 4Network Configuration ..............................4 4. Parsertorture tests . . . . . . . . . . . . . . . . . . . . . 4Torture Tests ............................................4 4.1. Valid SIPmessageMessage with an IPv6reference . . . . . . . . . 5Reference ...................5 4.2. Invalid SIPmessageMessage with an IPv6reference . . . . . . . . 5Reference .................5 4.3. PortambiguousAmbiguous in a SIP URI. . . . . . . . . . . . . . . 6................................6 4.4. PortunambiguousUnambiguous in a SIP URI. . . . . . . . . . . . . . 7..............................7 4.5. IPv6reference delimitersReference Delimiters in Viaheader . . . . . . . . . 7Header ....................7 4.6. SIPrequestRequest with IPv6addressesAddresses in Session Description Protocol (SDP)body . . . . . . . . . . . . . . . . . . . 9Body.....................9 4.7. Multiple IPaddressesAddresses in SIPheaders . . . . . . . . . . . 9Headers .......................9 4.8. Multiple IPaddressesAddresses in SDP. . . . . . . . . . . . . . . 10..............................10 4.9.IPv4-mappedIPv4-Mapped IPv6addresses . . . . . . . . . . . . . . . . 11Addresses ................................11 4.10. IPv6reference bugReference Bug inRFC3261RFC 3261 ABNF. . . . . . . . . . . . 11......................11 5. Securityconsiderations . . . . . . . . . . . . . . . . . . . 12Considerations ........................................13 6.IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1.Acknowledgments ................................................13 7. References .....................................................13 7.1. Normativereferences . . . . . . . . . . . . . . . . . . . 13 8.2.References ......................................13 7.2. Informativereferences . . . . . . . . . . . . . . . . . . 14References ....................................14 Appendix A.Bit-exact archiveBit-Exact Archive ofeach test message . . . . . . . 14Each Test Message ...............15 A.1. Encodedreference messages . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 18Reference Messages ...............................16 1. Overview This document is informational, and isNOT NORMATIVE*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. DocumentconventionsConventions 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. 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:"SeveralSeveral 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."TheThe 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>"NoteNote that this is NOT SIP header-line folding, where different strings of bits have equivalentmeaning."meaning. 3. SIP and IPv6network configurationNetwork 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, whenshoulda 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[ID.sip-trans][sip-trans] provides more guidance on these issues. 4. Parsertorture testsTorture Tests The test messages are organized into several sections. Some stress onlyathe SIP parser and others stress both the parser and the application above it. Some messages arevalid,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),RFC3261RFC 3261 mandates that the "IPv6reference" production rule be used to recognize tokens that comprise an IPv6 reference. More specifically, the ABNFstates: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 4.1. Valid SIPmessageMessage with an IPv6referenceReference 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 SIPmessageMessage with an IPv6referenceReference 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 4.3. PortambiguousAmbiguous 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,insertsinserted 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 canappearoccur 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 headerfield, the Contact header field, the Route and Record-Route headers, among other headers.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 4.4. PortunambiguousUnambiguous 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. IPv6reference delimitersReference Delimiters in ViaheaderHeader 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 definedthusly:as follows: via-received = "received" EQUAL (IPv4address / IPv6address) The "IPv6address" non-terminal is defined not to include the delimiting "[" and "]". This hasleadled 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. 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 4.6. SIPrequestRequest with IPv6addressesAddresses in Session Description Protocol (SDP)bodyBody 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 IPaddressesAddresses in SIPheaders ThHeaders 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. 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 IPaddressesAddresses 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 4.9.IPv4-mappedIPv4-Mapped IPv6addressesAddresses An IPv4-mapped IPv6 address is usually represented with the last32-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. IPv6reference bugReference Bug inRFC3261RFC 3261 ABNF It is possible to follow the IPv6reference production rule ofRFC3261RFC 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] 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 inRFC3261RFC 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 todeleteignore the extra colon when parsing the IPv6reference.)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 5. SecurityconsiderationsConsiderations 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 thisdraftdocument 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. 7.Acknowledgments The authors thank Jeroen van Bemmel, Dennis Bijwaard, Gonzalo Camarillo, Bob Gilligan, Alan Jeffrey, Larry Kollasch, Erik Nordmark, Kumiko Ono, Pekka Pessi, JonPetersonPeterson, 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.8.7. References8.1.7.1. NormativereferencesReferences [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. [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.8.2.7.2. InformativereferencesReferences [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.[ID.sip-trans][sip-trans] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)",draft-ietf-sipping-v6-transition-07.txt (workWork inprogress),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. Appendix A.Bit-exact archiveBit-Exact Archive ofeach test messageEach 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. Encodedreference messagesReference 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 -- Authors' Addresses Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane Rm 9F-546 Lisle, IL 60532 USA Phone: +1 630 224 0216Email:EMail: vkg@alcatel-lucent.com Chris Boulton Ubiquity Software Corporation Building 3 West Fawr Lane St Mellons Cardiff, South Wales CF3 5EAEmail:EMail: cboulton@ubiquitysoftware.com Robert J. Sparks Estacado SystemsEmail:EMail: RjS@estacado.net Full Copyright Statement Copyright (C) The IETF Trust(2007).(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.Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).