RFC 5118
Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)
RFC 5118 🌈
Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6) 🎀
Network Working Group 🧚 Authors: V. Gurbani (Bell Laboratories, Alcatel-Lucent), C. Boultond (Ubiquity Software Corporation), and R. Sparks (Estacado Systems) Category: Informational 💜 Date: February 2008 📅 Obsoletes / Updates: The title block doesn't list any RFCs that this one obsoletes or updates. 🙈
Status of This Memo ✨
This memo gives information to the Internet community. It is not an Internet standard of any kind. Distribution of this memo is unlimited. 💅
Abstract 🦋
This document gives you examples of Session Initiation Protocol (SIP) test messages designed to really stress out and "torture" the code of an IPv6-enabled SIP implementation. 😈
Table of Contents 🍓
1. Overview ........................................................2
2. Document conventions ............................................2
3. SIP and IPv6 Network Configuration ..............................4
4. Parser Torture Tests ............................................4
4.1. Valid SIP Message with an IPv6 Reference ...................5
4.2. Invalid SIP Message with an IPv6 Reference .................5
4.3. Port Ambiguous in a SIP URI ................................6
4.4. Port Unambiguous in a SIP URI ..............................7
4.5. IPv6 Reference Delimiters in Via Header ....................7
4.6. SIP Request with IPv6 Addresses in
Session Description Protocol (SDP) Body.....................9
4.7. Multiple IP Addresses in SIP Headers .......................9
4.8. Multiple IP Addresses in SDP ..............................10
4.9. IPv4-Mapped IPv6 Addresses ................................11
4.10. IPv6 Reference Bug in RFC 3261 ABNF ......................11
5. Security Considerations ........................................13
6. Acknowledgments ................................................13
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................14
Appendix A. Bit-Exact Archive of Each Test Message ...............15
A.1. Encoded Reference Messages ...............................161. Overview ✨
This document is informational, and it is not normative on any aspect of SIP. 🙅♀️
This document has test messages based on the current version (2.0) of the Session Initiation Protocol, as defined in [RFC3261]. 💖
This document is meant to be a companion to the more general SIP torture test document, [RFC4475]. That one doesn't include specific tests for IPv6 network identifiers. 🎀
This document doesn't try to list every possible way to make an invalid message, and it isn't trying to be comprehensive about unusual but valid messages either. Instead, it focuses on the areas that may cause interoperability problems in IPv6 deployments. 👑
2. Document Conventions 🌸
This document has lots of examples of SIP messages with IPv6 network identifiers. The appendix has an encoded binary form with the bit-exact representation of all the messages, plus the script you need to decode them into separate files. 🧚
The IPv6 addresses in this document correspond to the 2001: DB8::/32 address prefix, which is reserved for documentation [RFC3489]. In the same way, the IPv4 addresses here correspond to the 192.0.2.0/24 address block, as described in [RFC3330]. 🦋
SIP is a text-based protocol, but some of these examples can't be unambiguously rendered without extra markup, because of the rules RFCs have for formatting. So this document uses the <allOneLine/> markup convention established in [RFC4475]. That keeps things unambiguous and meets the Internet-Draft layout requirements. For 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.3. SIP and IPv6 Network Configuration 🌈
Okay, so there are a bunch of system-level things that matter a lot for the move to IPv6. Think deploying a dual-stack proxy server, filling DNS with A and AAAA Resource Records (RRs), zero-configuration discovery of outbound proxies for IPv4 and IPv6 networks, when a dual-stack proxy should Record-Route itself, and media issues. 💅 This document doesn't cover any of those, though. A companion document, [sip-trans], gives more guidance on them. 🦋
4. Parser Torture Tests 💀
The test messages are organized into several sections. Some only stress the SIP parser, and others stress both the parser and the application above it. Some messages are valid and some aren't. Each example clearly calls out what makes an invalid message incorrect. 🔥
Please refer to the complete Augmented Backus-Naur Form (ABNF) in [RFC3261] for how to represent IPv6 references in SIP messages. IPv6 references are delimited by a "[" and "]". When an IPv6 reference is part of a SIP Uniform Resource Identifier (URI), RFC 3261 mandates that the "IPv6reference" production rule be used to recognize the tokens that make up an IPv6 reference. Here's what the ABNF says: 🧚
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*4HEXDIG4.1. Valid SIP Message with an IPv6 Reference 💖
This request is well-formatted according to the grammar in [RFC3261]. An IPv6 reference shows up in the Request-URI (R-URI), the Via header field, and the 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: 04.2. Invalid SIP Message with an IPv6 Reference 🙈
This request is not well-formatted according to the grammar in [RFC3261]. The IPv6 reference in the R-URI doesn't have the mandated "[" and "]" delimiters. Oof. 💀
A SIP implementation that receives 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: 04.3. Port Ambiguous in a SIP URI 👀
Okay, so IPv6 uses the colon to delimit octets. That can get messy if the port number a SIP server is supposed to be contacted on gets accidentally mixed up with the IPv6 reference. 😭 Look at the REGISTER request below. The sender meant to specify port 5070 to contact a server, but they accidentally put the port number inside the closing "]" of the IPv6 reference. And since the IPv6 address in the R-URI is compressed, the intended port number ends up as the last octet of the reference. Yikes. 🙃
From a parsing perspective, this request is well-formed. But from a semantic point of view, it won't give the result you wanted. Implementations must ensure that when a raw IPv6 address appears in a SIP URI, any port number, if one is required, appears outside the closing "]" that delimits the IPv6 reference. Raw IPv6 addresses can show up in many header fields, including the Contact, Route, and Record-Route header fields. They can also appear as the result of the "sent-by" production rule of the Via header field. Implementers are urged to check the ABNF in [RFC3261] for a complete list of the 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: 04.4. Port Unambiguous in a SIP URI 🦋
Compare that with the example in Section 4.3. This REGISTER request leaves zero ambiguity about where the IPv6 address ends and the port number begins. It's giving clarity. ✨ It's well formatted per the grammar in [RFC3261], too. 👑
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: 04.5. IPv6 Reference Delimiters in Via Header 🦋
okay so IPv6 references can also pop up in Via headers, specifically in the "sent-by" production rule and the "via-received" production rule 💅. In "sent-by", the IPv6 address is defined to show up as an "IPv6reference" non-terminal, which means the "[" and "]" delimiters are required. The "via-received" one is different, though 👀:
via-received = "received" EQUAL (IPv4address / IPv6address)The "IPv6address" non-terminal is defined to NOT include the delimiting "[" and "]". This caused a whole moment at 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.
It would be iconic if the same non-terminal ("IPv6reference") was used for both "sent-by" and "via-received", but the working group never reached a consensus on that 🥲. So the best advice 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. Pinky promise 🤙.
The two test cases below are built to stress this behavior. A SIP implementation receiving either of these messages MUST parse them successfully ✨.
The first request has an IPv6 address in the Via "received" parameter, wrapped in "[" and "]". Not valid under a strict reading of the grammar in [RFC3261], but robust implementations MUST nonetheless be able to parse the topmost Via header field and keep 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: 0The OPTIONS request below has an IPv6 address in the Via "received" parameter WITHOUT the "[" and "]". This one 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: 04.6. SIP Request with IPv6 Addresses in Session Description Protocol (SDP) Body 🌸
This request is valid and well-formed according to the grammar in [RFC3261] 💖. Notice that the IPv6 addresses in the SDP [RFC4566] body do NOT have the "[" and "]" delimiters. Very intentional.
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/900004.7. Multiple IP Addresses in SIP Headers 🧁
This request is valid and well-formed according to the grammar in [RFC3261] ✅. The Via list is a mix of IPv4 addresses and IPv6 references, so it's giving variety 🌈.
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: 04.8. Multiple IP Addresses in SDP 🦢
This request is valid and well-formed according to the grammar in [RFC3261] 🫶. The SDP has multiple media lines, and each one is identified by a different network connection address. Main character energy 👑.
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/900004.9. IPv4-Mapped IPv6 Addresses 🍓
An IPv4-mapped IPv6 address is usually written with its last 32 bits as a dotted-decimal IPv4 address, e.g., ::ffff: 192.0.2.1. A SIP implementation receiving a message with one of these MUST be prepared to parse it successfully 💅. The mapped address can show up in signaling, in the SDP carried by the signaling message, or in both 🌙. If the URI represented by the IPv4-mapped IPv6 address includes a port number, that port number MUST appear outside the delimiting "]" (cf. Section 4.4) ✨.
The message below is well-formed according to the grammar in [RFC3261]. The Via list has two Via headers, and both include an IPv4-mapped IPv6 address. There's one in the Contact header and one in the SDP too. The topmost Via header has a port number that's delimited by "]" properly 🎀.
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/900004.10. IPv6 Reference Bug in RFC 3261 ABNF 🐛
Okay, this one is a bit of a plot twist 🙈. It's possible to follow the IPv6reference production rule of RFC 3261 ABNF (the relevant bit is reproduced at the top of Section 4) and end up with this construct:
[2001:db8:::192.0.2.1]See that extra colon before the IPv4 address? The correct construct, of course, is:
[2001:db8::192.0.2.1]The ABNF for IPv6 references in RFC 3261 was derived from RFC 2373 [RFC2373], which has been obsoleted by RFC 4291 [RFC4291]. The extra-colon behavior was inherited from RFC 2373, and RFC 4291 fixed it. Still, following the Robustness Principle [RFC1122], an implementation MUST tolerate both of the above constructs 🫶.
The message below has the extra colon in the IPv6 reference. A SIP implementation receiving it MAY show robustness by successfully parsing the IPv6 reference (it can choose to ignore the extra colon when parsing). If the SIP implementation is acting as a proxy, it MAY also serialize the message without the extra colon to help 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: 0The 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: 05. Security Considerations 🔐
Real talk, this section is serious, bestie 😤.
This document shows examples of SIP messages with IPv6 references in the signaling headers and SDP payload. It may clarify how SIP elements behave when processing a message with IPv6 references, but it does NOT normatively change the base SIP [RFC3261] specification in any way. So all 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 make implementations behave in undesirable ways 💀. Lots of the messages in this document are designed to stress a parser at the spots traditionally used for those attacks. This document is NOT comprehensive, though. It just covers some common pitfalls the authors found 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 the other members of the SIP-related working groups for their input during the construction of the document and the discussion of the test cases 💖.
This work is being discussed on the sipping@ietf.org mailing list 📬.
A.B. Nataraju and A.C. Mahendran provided working group last call comments 🌟.
Mohamed Boucadair and Brian Carpenter suggested new test cases for inclusion in the document 🧠.
7. References ✨
7.1. Normative References 📚
- [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. 🧱
- [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 📞✨
- [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. 🗺️
- [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. 🔀
- [RFC4475] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006. 😈🧪
- [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 🎶
7.2. Informative References 🌸
- [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. 🏡
- [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 🏠 The newer version of the one above, bestie 💅
- [sip-trans] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", Work in Progress, August 2007. 🚧
- [Email-SIPit] Sparks, R., "preliminary report: SIPit 18", Electronic Mail archived at http://www1.ietf.org/mail-archive/web/sip/current/msg14103.html, April 2006. 📧
Appendix A. Bit-Exact Archive of Each Test Message 🎁
Okay so this is the gift basket 🎁💖. It's an encoded, gzip compressed TAR archive holding files for each of the example messages we talked about in Section 4. Every single one, bestie!
To get the archive back out intact, you can feed the text of this document into the Perl script below. Redirect the output to a file, or pipe it into 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);Not a Perl person? No stress 🙈. You can also hand-edit the base-64 block to strip out the document structure lines, then feed it into any base-64 decoding utility you like.
A.1. Encoded Reference Messages 🧁
-- BEGIN MESSAGE ARCHIVE --
H4sICPujD0cAA21zZy50YXIA7Vpbc6M2GPUzv0Ldl74UWzckIHUnbXY39XS760ncz
HQ6mY5sFBuvDRSwN+mvrwAb303c2GQ34byAjYSEpHO+i1Rv1E4OCCnkEKorRJyl1+
R2dk1RQ6oE4RhxRNT/CCHGa8bpu1arTaJYhKrJ6ef+3nJ+PJDhnufzD8ku+LidPB3
qDTeYUn0sgkA6urpnx28DIggZpbvmHyFOF/NPWTL/FFFcg8fvyiZe+fy3Pt60Ou9A
5Ab2JJLhubwX42Ak6z1/DK5b7QauQ63j21sLaO9Df7z8SERxfen5WSz6TRPdY+3GF
fb8dY0/3rbBX7Z9p2AjS/1Tx3UEb9W9iclZNxReb9D81xpc0u5v3QGyimvj27VqIi
K60hDtQoxGeuutqn19aRmGZUHDwMSyOOT8fDASk7+pWpvahe/Fohfb4E2nDhwZfQb
BwPfkG/Bj8m2xdM43W/xJu7iW/9iAIQyyQdR+F/f6ez/8IkInsgHP3iu9WO88BNIG
imIjtydi1/cakRPkTz9Irx8PbIAJ07RpE2p+U0SRq9alFwOLI06UKiLCTW6Z0EQAq
vZAq83Aep+0qJl8MBhLEPm+9wNQ8yAi+Z3Wa+6qETcJISY1ETItQAhPGIoh0sZNMX
FcHzC1lsFVp934+aYNsCaaYRworbAxuOSY6QQ3TFVCFZ+6jkyKY5oXV5ReVFA/wK+
YqWmxLLNhJRzRnnvtV5jpP9O7wjldGwX6DyklSv8Z5AZEmPNE/7FBWKX/JeDq3WXr
uvPuKlVxrEbedrqmreh6uPo/TvgXbVg2eqJubxXcTMiTN8hwpuC99Mf5Utso12/LV
GsSzIdhQ5Sh9rJlasb/vu+fTgCK+W8s+I9pyn9OKv+vDKzwf5kg8LZSgFegADP+u5
6uXNITtVEU/0GO5/zHkKX2X7m8vOJ/CViP/x4jAatlnqwCGB4tfCvgvGppTnrziHE
bMw+L25Y7pGK2D+5Ugix+upPSAXd+CGLfEQ/fRyqUk7Hr9RcR3ErdKnqr8ETUG+PJ
KNbdIDEBAymcvSL3/1Dk/6l1l+s/wjDN/xECK/0vAb/8uST+A38pgefJOJf/IifOZ
tCAO0R8o26e81urMBwMhclNNBhOhDtkBqJ0tXLnYq1hbBjrpoMaaDg8C2VPKlV1mn
mmKzETc2syMyB7nMjMRFjI5EAN0HYHWI1Pat8S91HXLfooO/jVOZcr/D+RC1jEf85
Zzn+MMv9PWc6K/yXgK/D/nh4FPtoBtNKwbzffc5fwMA8QmWjuAXb9LsAm5JRyAtWd
pRY3QZnnR8GKwCYRdNRUThwEMHfZMCZk4YTBueNHF6q5213b4iSiIh+u3gj8MNbFu
Ov2J/4kOsUaK8z/GLn9R4Rl9l+NYMX/ErA7/2MbkH8bSaCDcj47yP9ak0Az/k+8Ey
rAIfynGKX8p8So+F8C9uR/UwGo+P/S+T91hT6Pl/RAhGKse77uyJE7PlIbhfxni/1
fg6X7Pwzzav+nDHxqd1qfPl4/3/ZPHqqvBfabkrAuB0fdDrKWN4QwArNxefFCsJX/
X9x4cEQFKOQ/Xth/I4v/GcMV/8vAPP93IPdTgncdzh7EkWWgKMH35A3ilOJEUTzJ7
L10ehdifv5r0tdF17vTid7zR7531CigmP/Z+W/MGUvPfSUygKvzX2Vg2f6vJ/cWp3
OLE4FLZYsFAW5ThJHoovrGEeIC8u8NC7LzuaaVG/OdG70L+j/3fJSNGf97fqgUOM4
0AB9ZAwr5j1jOf+UFpPZfSUDF/xKwj/8H0L9if4UKFSp8Y/gPJmWg1AA6AAA=
-- END MESSAGE ARCHIVE --Authors' Addresses 💌
Here's who wrote this beauty 🫶
Vijay K. Gurbani
Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane
Rm 9F-546
Lisle, IL 60532
USA
Phone: +1 630 224 0216
EMail: vkg@alcatel-lucent.com
Chris Boulton
Ubiquity Software Corporation
Building 3
West Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
EMail: cboulton@ubiquitysoftware.com
Robert J. Sparks
Estacado Systems
EMail: RjS@estacado.netFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2008). 🔒
This doc is governed by the rights, licenses, and restrictions in BCP 78. Outside of what's set out there, the authors keep all of their rights.
This document and the information in it 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 doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim about implementing or using the technology in this document are valid or how far they reach. It also doesn't say whether a license under those rights would or wouldn't be available. And it doesn't claim to have independently tried to find any such rights. If you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79. 📖
Copies of IPR disclosures sent to the IETF Secretariat, along with any assurances of licenses to be made available, or the results of an attempt to get a general license or permission to use those proprietary rights by implementers or users of this specification, can be found in the IETF's online 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 needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 💜
📦 where this page comes from
- ietf: rfc5118 2008-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms