doc: Add RFC documents

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]
+