RFC 3266

Support for IPv6 in Session Description Protocol (SDP)

📅 published July 2002, from ietf

RFC 3266: Support for IPv6 in Session Description Protocol (SDP) 🎀

okay bestie, so this one is by Sean Olson (Microsoft), Gonzalo Camarillo (Ericsson), and Adam Roach (dynamicsoft) 👯. It's a Standards Track doc from June 2002, and it updates RFC 2327 (that's the SDP spec itself) ✨. The header doesn't say it obsoletes anything, so nothing's getting replaced here, just upgraded 💅.

Status of This Memo 📋

This is an Internet standards track protocol for the Internet community, and they're literally asking for discussion and suggestions for improvements 💬. For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 🔍. Distribution of this memo is unlimited, so share away 🦋.

Copyright Notice 🌈

Abstract 🌸

This doc is all about using Internet Protocol Version 6 (IPv6) addresses together with the Session Description Protocol (SDP) 🧚. Basically, it clears up what SDP already says about the syntax of IPv6 addresses, which is so needed 🙌.

1. Introduction ✨

okay so SDP is for describing multimedia sessions, like when you announce one, invite people to one, or start one in other ways 🎬. It's a text format that spills all the tea about a session: who started it, a URL related to it, the connection address for the media, and optional attributes for the media 📝. Every one of those pieces can involve one or more IPv6 addresses, and that's the main event here 🔥. The ABNF for IP addresses in SDP currently leaves IPv6 syntax undefined, which is giving incomplete energy 💀. This doc finishes the ABNF so it includes IPv6 addresses, iykyk 🫶.

So the address type "IP6", which means an IPv6 address, should be allowed in the connection field, "c=", of SDP 💜. The ABNF already reflects this 🙈. The problem is that the "Connection Data" text under section 6 of RFC 2328 only defines the "IP4" address type, so that text is lagging behind 😭.

2. Terminology 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5] 📚. These words are the rules of the game, so read them carefully 👑.

3. Syntax 🧩

RFC 2373 [1] gives an ABNF for the text representation of IPv6 addresses in Appendix B 🦋. RFC 2732 [3] covers the text representation of IPv6 addresses when they're used within a URL 🌐. Using the ABNF described in these documents, the following updated ABNF for SDP is proposed 💖.

   uri =                 ; defined in RFC1630 and RFC2732

   multicast-address =   IP4-multicast / IP6-multicast

   IP4-multicast =       m1 3*( "." decimal-uchar )
                         "/" ttl [ "/" integer ]
                         ; IPv4 multicast addresses may be in the
                         ; range 224.0.0.0 to 239.255.255.255

   m1 =                  ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
                         ("23" DIGIT ))

   IP6-multicast =       hexpart
                         ; IPv6 address starting with FF

   addr =                FQDN / unicast-address

   FQDN =                4*(alpha-numeric/"-"/".")
                         ; fully qualified domain name as specified
                         ; in RFC1035
   unicast-address =     IP4-address / IP6-address

   IP4-address =         b1 3*("." decimal-uchar) / "0.0.0.0"

   b1 =                  decimal-uchar
                         ; less than "224"; not "0" or "127"

   ; The following is from RFC2373 Appendix B. It is a direct copy.
   IP6-address =         hexpart [ ":" IP4-address ]

   hexpart =             hexseq / hexseq "::" [ hexseq ] /
                         "::" [ hexseq ]

   hexseq  =             hex4 *( ":" hex4)

   hex4    =             1*4HEXDIG

4. Example SDP description with IPv6 addresses 🍓

Here's an example SDP description using the ABNF above for IPv6 addresses 🛰️. The main stars are the origin and connection fields, since both of them hold IPv6 addresses 🌟.

   v=0
   o=nasa1 971731711378798081 0 IN IP6 2201:056D::112E:144A:1E24
   s=(Almost) live video feed from Mars-II satellite
   p=+1 713 555 1234
   c=IN IP6 FF1E:03AD::7F2E:172A:1E24
   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

5. Note for implementors ⚠️

okay this part is important, so pay attention 🙈

An implementation may receive an SDP session description with an IPv6 address whose format [1] is internally that of an IPv4 mapped address 🫣. Such an address is actually the address of an IPv4-only node, so implementors are warned to interpret IPv4 mapped addresses as equivalent to IP4 🚨.

6. IANA Considerations 📑

This document updates the definition of the IP6 addrtype parameter found in RFC 2327 🔄.

7. Security Considerations 🔐

No additional considerations above what is stated in section 7 of RFC 2327 🛡️. So the security story is the same as SDP's, and that's the whole plot 💀.

8. References 📚

   [1]   Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 2373, July 1998.

   [2]   Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

   [3]   Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal
         IPv6 Addresses in URL's", RFC 2732, December 1999.

   [4]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.

   [5]   Bradner, S., "Key words for Use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

9. Authors' Addresses 🧚‍♀️

   Sean Olson
   Microsoft
   One Microsoft Way
   Redmond, WA 98052
   USA

   EMail: seanol@microsoft.com


   Gonzalo Camarillo
   Ericsson
   Advanced Signalling Research Lab.
   FIN-02420 Jorvas
   Finland

   Phone: +358 9 299 3371
   Fax: +358 9 299 3118
   EMail: Gonzalo.Camarillo@ericsson.com


   Adam Roach
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX 75024
   USA

   EMail: adam@dynamicsoft.com
   Voice: <sip:adam@dynamicsoft.com>

10. Full Copyright Statement 🔒

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Acknowledgement 💜

Funding for the RFC Editor function is currently provided by the Internet Society 🫶✨

📦 where this page comes from

ietf: rfc3266 2002-07
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms