idnits 2.17.1 draft-ietf-mmusic-anat-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 283. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2004) is 7120 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFCxxxx' on line 208 ** Obsolete normative reference: RFC 2327 (ref. '2') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 3388 (ref. '4') (Obsoleted by RFC 5888) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-02 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC Working Group G. Camarillo 2 Internet-Draft Ericsson 3 Expires: April 25, 2005 J. Rosenberg 4 dynamicsoft 5 October 25, 2004 7 The Alternative Network Address Types Semantics (ANAT) for the 8 Session Description Protocol (SDP) Grouping Framework 9 draft-ietf-mmusic-anat-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 25, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This document defines the Alternative Network Address Types (ANAT) 45 semantics for the SDP grouping framework. The ANAT semantics allow 46 offering alternative types of network addresses to establish a 47 particular media stream. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Scope and Relation with Interactive Connectivity 53 Establishment . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. ANAT Semantics . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Preference . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Offer/Answer and ANAT . . . . . . . . . . . . . . . . . . . . 4 58 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 6 63 9.2 Informational References . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 65 Intellectual Property and Copyright Statements . . . . . . . . 8 67 1. Introduction 69 An SDP [2] session description contains the media parameters to be 70 used to establish a number of media streams. For a particular media 71 stream, an SDP session description contains, among other parameters, 72 the network addresses and the codec to be used to transfer media. 73 SDP allows providing a set of codecs per media stream, but only one 74 network address. 76 Being able to offer a set of network addresses to establish a media 77 stream is useful in environments with both IPv4-only hosts and 78 IPv6-only hosts, for instance. 80 This document defines the Alternative Network Address Types (ANAT) 81 semantics for the SDP grouping framework [4]. The ANAT semantics 82 allow expressing alternative network addresses (e.g., different IP 83 versions) for a particular media stream. 85 1.1 Scope and Relation with Interactive Connectivity Establishment 87 The ANAT semantics are intended to address scenarios that involve 88 different network address types (e.g., different IP versions). They 89 are not intended to provide alternative transport addresses with the 90 same network type. Systems that need to provide different transport 91 addresses with the same network type should use the SDP format 92 defined in ICE (Interactive Connectivity Establishment) [6] instead. 94 ICE is used by systems that cannot determine their own transport 95 address as seen from the remote end but that can provide several 96 possible alternatives. ICE encodes the address that is most likely 97 to be valid in an 'm' line and the rest of addresses as a= lines 98 after that 'm' line. This way, systems that do not support ICE 99 simply ignore the a= lines and only use the address in the 'm' line. 100 This achieves good backwards compatibility. 102 We have chosen to group 'm' lines with different IP versions at the 103 'm' level (ANAT semantics) rather than at the a= level (ICE format) 104 in order to keep the IPv6 syntax free from ICE parameters used for 105 legacy (IPv4) NATs (Network Address Translators). This yields a 106 syntax much closer to vanilla SDP, where IPv6 addresses are defined 107 in their own 'm' line, rather than in parameters belonging to a 108 different 'm' line. 110 Additionally, ICE only allows us to provide a single primary address 111 when the peer does not support ICE. The ANAT semantics avoids 112 relegating addresses of a certain type (e.g., IPv6 addresses) to just 113 be a secondary alternate to another address type (e.g., IPv4 114 addresses). 116 Furthermore, the separation between ANAT and ICE helps systems that 117 support IPv4 and IPv6 but that do not need to support ICE (e.g., a 118 multicast server). 120 2. Terminology 122 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 123 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 124 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 125 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 126 compliant implementations. 128 3. ANAT Semantics 130 We define a new ``semantics'' attribute within the SDP grouping 131 framework [4]: ANAT (Alternative Network Address Types). 133 Media lines grouped using ANAT semantics provide alternative network 134 addresses of different types for a single logical media stream. The 135 entity creating a session description with an ANAT group MUST be 136 ready to receive (or send) media over any of the grouped 'm' lines. 137 The ANAT semantics MUST NOT be used to group media streams whose 138 network addresses are of the same type. 140 4. Preference 142 The entity generating a session description may have an order of 143 preference for the alternative network address types offered. The 144 identifiers of the media streams MUST be listed in order of 145 preference in the group line. For an example where the 'm- line with 146 mid=1 has a higher preference than the 'm' line with mid=2, see 147 Section 6. 149 5. Offer/Answer and ANAT 151 An offerer using SIP [3] to send its offer SHOULD place the sdp-anat 152 option-tag [5] in a Require header field. 154 An answerer receiving a session description that uses the ANAT 155 semantics SHOULD use the address with highest priority it understands 156 and set the ports of the rest of the 'm' lines of the group to zero. 158 6. Example 160 The session description below contains an IPv4 address and an IPv6 161 address grouped using ANAT. The format correspoding to the mapping 162 of ICE into SDP [6] is used in both 'm' lines to provide extra 163 addresses. 165 v=0 166 o=bob 280744730 28977631 IN IP4 host.example.com 167 s= 168 t=0 0 169 a=group:ANAT 1 2 170 m=audio 25000 RTP/AVP 0 171 c=IN IP6 2001:DB8::1 172 a=alt:1 1.0 : user1 9kksj== 2001:DB8::1 25000 173 a=alt:2 0.8 : user2 9kksk== 2001:DB8::2 20000 174 a=alt:3 0.4 : user3 9kksl== 2001:DB8::3 30000 175 a=mid:1 176 m=audio 22334 RTP/AVP 0 177 c=IN IP4 192.0.2.1 178 a=alt:1 1.0 : user4 9kksm== 10.0.1.1 1010 179 a=alt:2 0.8 : user5 9kksn== 192.0.2.2 20000 180 a=alt:3 0.4 : user6 9kkso== 192.0.2.1 22334 181 a=mid:2 183 7. Security Considerations 185 An attacker adding group lines using the ANAT semantics to an SDP 186 session description could make an end-point use only one out of all 187 the streams offered by the remote end, when the intention of the 188 remote-end might have been to establish all the streams. 190 An attacker removing group lines using ANAT semantics could make and 191 end-point establish a higher number of media streams. If the 192 end-point sends media over all of them, the session bandwidth may 193 increase dramatically. 195 It is thus STRONGLY RECOMMENDED that integrity protection be applied 196 to the SDP session descriptions. For session descriptions carried in 197 SIP [3], S/MIME is the natural choice to provide such end-to-end 198 integrity protection, as described in RFC 3261. Other applications 199 MAY use a different form of integrity protection. 201 8. IANA Considerations 203 IANA needs to register the following new 'semantics' attribute for 204 the SDP grouping framework [4]: 206 Semantics Token Reference 207 --------------------------------- ----- --------- 208 Alternative Network Address Types ANAT [RFCxxxx] 210 It should be registered in the SDP parameters registry 211 (http://www.iana.org/assignments/sdp-parameters) under Semantics for 212 the "group" SDP Attribute. 214 9. References 216 9.1 Normative References 218 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 219 Levels", BCP 14, RFC 2119, March 1997. 221 [2] Handley, M. and V. Jacobson, "SDP: Session Description 222 Protocol", RFC 2327, April 1998. 224 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 225 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 226 Session Initiation Protocol", RFC 3261, June 2002. 228 [4] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne, 229 "Grouping of Media Lines in the Session Description Protocol 230 (SDP)", RFC 3388, December 2002. 232 [5] Camarillo, G. and J. Rosenberg, "The sdp-anat Session Initiation 233 Protocol (SIP) Option-Tag", 234 draft-camarillo-sip-anat-option-tag-00.txt (work in progress), 235 April 2004. 237 9.2 Informational References 239 [6] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 240 Methodology for Network Address Translator (NAT) Traversal for 241 Multimedia Session Establishment Protocols", 242 draft-ietf-mmusic-ice-02 (work in progress), July 2004. 244 Authors' Addresses 246 Gonzalo Camarillo 247 Ericsson 248 Hirsalantie 11 249 Jorvas 02420 250 Finland 252 EMail: Gonzalo.Camarillo@ericsson.com 253 Jonathan Rosenberg 254 dynamicsoft 255 600 Lanidex Plaza 256 Parsippany, NJ 07054 257 US 259 EMail: jdrosen@dynamicsoft.com 261 Intellectual Property Statement 263 The IETF takes no position regarding the validity or scope of any 264 Intellectual Property Rights or other rights that might be claimed to 265 pertain to the implementation or use of the technology described in 266 this document or the extent to which any license under such rights 267 might or might not be available; nor does it represent that it has 268 made any independent effort to identify any such rights. Information 269 on the procedures with respect to rights in RFC documents can be 270 found in BCP 78 and BCP 79. 272 Copies of IPR disclosures made to the IETF Secretariat and any 273 assurances of licenses to be made available, or the result of an 274 attempt made to obtain a general license or permission for the use of 275 such proprietary rights by implementers or users of this 276 specification can be obtained from the IETF on-line IPR repository at 277 http://www.ietf.org/ipr. 279 The IETF invites any interested party to bring to its attention any 280 copyrights, patents or patent applications, or other proprietary 281 rights that may cover technology that may be required to implement 282 this standard. Please address the information to the IETF at 283 ietf-ipr@ietf.org. 285 Disclaimer of Validity 287 This document and the information contained herein are provided on an 288 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 289 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 290 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 291 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 292 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 293 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 295 Copyright Statement 297 Copyright (C) The Internet Society (2004). This document is subject 298 to the rights, licenses and restrictions contained in BCP 78, and 299 except as set forth therein, the authors retain all their rights. 301 Acknowledgment 303 Funding for the RFC Editor function is currently provided by the 304 Internet Society.