diff options
Diffstat (limited to 'doc/rfc/rfc4091.txt')
| -rw-r--r-- | doc/rfc/rfc4091.txt | 395 |
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc4091.txt b/doc/rfc/rfc4091.txt new file mode 100644 index 0000000..e4da351 --- /dev/null +++ b/doc/rfc/rfc4091.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group G. Camarillo +Request for Comments: 4091 Ericsson +Category: Standards Track J. Rosenberg + Cisco Systems + June 2005 + + + The Alternative Network Address Types (ANAT) Semantics + for the Session Description Protocol (SDP) Grouping Framework + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document defines the Alternative Network Address Types (ANAT) + semantics for the Session Description Protocol (SDP) grouping + framework. The ANAT semantics allow alternative types of network + addresses to establish a particular media stream. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Scope and Relation with Interactive Connectivity + Establishment. . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. ANAT Semantics . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Preference . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 5. Offer/Answer and ANAT . . . . . . . . . . . . . . . . . . . . 3 + 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 + 9.2. Informational References . . . . . . . . . . . . . . . . 5 + + + + + + + +Camarillo & Rosenberg Standards Track [Page 1] + +RFC 4091 ANAT Semantics June 2005 + + +1. Introduction + + A Session Description Protocol (SDP) [2] session description contains + the media parameters to be used in establishing a number of media + streams. For a particular media stream, an SDP session description + contains, among other parameters, the network addresses and the codec + to be used in transferring media. SDP allows for a set of codecs per + media stream, but only one network address. + + The ability to offer a set of network addresses to establish a media + stream is useful in environments with both IPv4-only hosts and + IPv6-only hosts, for instance. + + This document defines the Alternative Network Address Types (ANAT) + semantics for the SDP grouping framework [4]. The ANAT semantics + allow for the expression of alternative network addresses (e.g., + different IP versions) for a particular media stream. + +1.1. Scope and Relation with Interactive Connectivity Establishment + + The ANAT semantics are intended to address scenarios that involve + different network address types (e.g., different IP versions). They + are not intended to provide alternative transport addresses with the + same network type. Systems that need to provide different transport + addresses with the same network type should use the SDP format + defined in ICE (Interactive Connectivity Establishment) [6] instead. + + ICE is used by systems that cannot determine their own transport + address as seen from the remote end, but that can provide several + possible alternatives. ICE encodes the address that is most likely + to be valid in an 'm' line, and the rest of addresses as a= lines + after that 'm' line. This way, systems that do not support ICE + simply ignore the a= lines and only use the address in the 'm' line. + This achieves good backward compatibility. + + We have chosen to group 'm' lines with different IP versions at the + 'm' level (ANAT semantics) rather than at the a= level (ICE format) + in order to keep the IPv6 syntax free from ICE parameters used for + legacy (IPv4) NATs (Network Address Translators). This yields a + syntax much closer to vanilla SDP, where IPv6 addresses are defined + in their own 'm' line, rather than in parameters belonging to a + different 'm' line. + + Additionally, ICE only allows us to provide a single primary address + when the peer does not support ICE. The ANAT semantics avoid + relegating certain types of addresses (e.g., IPv6 addresses) to only + be a secondary alternate to another address type (e.g., IPv4 + addresses). + + + +Camarillo & Rosenberg Standards Track [Page 2] + +RFC 4091 ANAT Semantics June 2005 + + + Furthermore, the separation between ANAT and ICE helps systems that + support IPv4 and IPv6 but that do not need to support ICE (e.g., a + multicast server). + +2. Terminology + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT + RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as + described in BCP 14, RFC 2119 [1] and indicate requirement levels for + compliant implementations. + +3. ANAT Semantics + + We define a new "semantics" attribute within the SDP grouping + framework [4]: ANAT (Alternative Network Address Types). + + Media lines grouped using ANAT semantics provide alternative network + addresses of different types for a single logical media stream. The + entity creating a session description with an ANAT group MUST be + ready to receive (or send) media over any of the grouped 'm' lines. + The ANAT semantics MUST NOT be used to group media streams whose + network addresses are of the same type. + +4. Preference + + The entity generating a session description may have an order of + preference for the alternative network address types offered. The + identifiers of the media streams MUST be listed in order of + preference in the group line. For example, in the session + description in Section 6, the 'm' line with mid=1 has a higher + preference than the 'm' line with mid=2. + +5. Offer/Answer and ANAT + + An offerer using SIP [3] to send its offer SHOULD place the sdp-anat + option-tag [5] in a Require header field. + + An answerer receiving a session description that uses the ANAT + semantics SHOULD use the address with the highest priority it + understands and set the ports of the rest of the 'm' lines of the + group to zero. + + + + + + + + + +Camarillo & Rosenberg Standards Track [Page 3] + +RFC 4091 ANAT Semantics June 2005 + + +6. Example + + The session description below contains an IPv4 address and an IPv6 + address grouped using ANAT. The format corresponding to the mapping + of ICE into SDP [6] can be used in both 'm' lines to provide + additional addresses. + + v=0 + o=bob 280744730 28977631 IN IP4 host.example.com + s= + t=0 0 + a=group:ANAT 1 2 + m=audio 25000 RTP/AVP 0 + c=IN IP6 2001:DB8::1 + a= <ICE-encoded additional IPv6 addresses (and ports)> + a=mid:1 + m=audio 22334 RTP/AVP 0 + c=IN IP4 192.0.2.1 + a= <ICE-encoded additional IPv4 addresses (and ports)> + a=mid:2 + +7. Security Considerations + + An attacker adding group lines, using the ANAT semantics, to an SDP + session description could make an end-point use only one out of all + the streams offered by the remote end, when the intention of the + remote-end might have been to establish all the streams. + + An attacker removing group lines using ANAT semantics could make an + end-point establish a higher number of media streams. If the + end-point sends media over all of them, the session bandwidth may + increase dramatically. + + It is thus strongly RECOMMENDED that integrity protection be applied + to the SDP session descriptions. For session descriptions carried in + SIP [3], S/MIME is the natural choice to provide such end-to-end + integrity protection, as described in RFC 3261 [3]. Other + applications MAY use a different form of integrity protection. + + + + + + + + + + + + + +Camarillo & Rosenberg Standards Track [Page 4] + +RFC 4091 ANAT Semantics June 2005 + + +8. IANA Considerations + + The IANA has registered the following new 'semantics' attribute for + the SDP grouping framework [4]: + + Semantics Token Reference + --------------------------------- ----- --------- + Alternative Network Address Types ANAT [RFC4091] + + ANAT has been registered in the SDP parameters registry under + Semantics for the "group" SDP Attribute. + +9. References + +9.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Handley, M. and V. Jacobson, "SDP: Session Description + Protocol", RFC 2327, April 1998. + + [3] 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. + + [4] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, + "Grouping of Media Lines in the Session Description Protocol + (SDP)", RFC 3388, December 2002. + + [5] Camarillo, G. and J. Rosenberg, "Usage of the Session + Description Protocol (SDP) Alternative Network Address Types + (ANAT) Semantics in the Session Initiation Protocol (SIP)", RFC + 4092, June 2005. + +9.2. Informative References + + [6] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A + Methodology for Network Address Translator (NAT) Traversal for + Multimedia Session Establishment Protocols", Work in Progress, + February 2005. + + + + + + + + + + +Camarillo & Rosenberg Standards Track [Page 5] + +RFC 4091 ANAT Semantics June 2005 + + +Authors' Addresses + + Gonzalo Camarillo + Ericsson + Hirsalantie 11 + Jorvas 02420 + Finland + + EMail: Gonzalo.Camarillo@ericsson.com + + + Jonathan Rosenberg + Cisco Systems + 600 Lanidex Plaza + Parsippany, NJ 07054 + US + + EMail: jdrosen@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Camarillo & Rosenberg Standards Track [Page 6] + +RFC 4091 ANAT Semantics June 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + 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 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Camarillo & Rosenberg Standards Track [Page 7] + |