idnits 2.17.1 draft-ietf-mmusic-sdp-srcfilter-10.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 536. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 637 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 34 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 10 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 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 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 (September 22, 2005) is 6790 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) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'RTCP-SSM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDP' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Bob Quinn 2 INTERNET-DRAFT Celox Networks 3 Category: Standards Track Ross Finlayson 4 Expires: March 2006 Live Networks, Inc. 5 September 22, 2005 7 Session Description Protocol (SDP) Source Filters 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of 16 BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document describes how to adapt the Session Description Protocol 37 (SDP) to express one or more source addresses as a source filter for 38 one or more destination "connection" addresses. It defines the 39 syntax and semantics for an SDP "source-filter" attribute that may 40 reference either IPv4 or IPv6 address(es) as either an inclusive or 41 exclusive source list for either multicast or unicast destinations. 42 In particular, an inclusive source-filter can be used to specify a 43 Source-Specific Multicast (SSM) session. 45 1. Terminology 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [REQMNT]. 51 2. Introduction 53 The Session Description Protocol [SDP] provides a general-purpose 54 format for describing multimedia sessions in announcements or 55 invitations. SDP uses an entirely textual data format (the US-ASCII 56 subset of [UTF-8]) to maximize portability among transports. 57 SDP does not define a protocol, but only the syntax to describe a 58 multimedia session with sufficient information to discover and 59 participate in that session. Session descriptions may be sent using 60 any number of existing application protocols for transport 61 (e.g., SAP, SIP, RTSP, email, HTTP, etc.). 63 Typically, session descriptions reference an IP multicast address for 64 the "connection-address" (destination), though unicast addresses or 65 fully qualified domain names (FQDNs) MAY also be used. The "source- 66 filter" attribute defined in this document qualifies the session 67 traffic by identifying the address (or FQDN) of legitimate source(s) 68 (senders). The intent is for receivers to use the source and 69 destination address pair(s) to filter traffic, so that applications 70 receive only legitimate session traffic. 72 Receiver applications are expected to use the SDP source-filter 73 information to identify traffic from legitimate senders, and discard 74 traffic from illegitimate senders. Applications and hosts may also 75 share the source-filter information with network elements (e.g., with 76 routers using [IGMPv3]) so they can potentially perform the traffic 77 filtering operation further "upstream," closer to the source(s). 79 The "source-filter" attribute can appear at the session level 80 and/or the media level. 82 2.1. Motivation 84 The purpose of a source-filter is to help protect receivers from 85 traffic sent from illegitimate source addresses. Filtering traffic 86 can help to preserve content integrity and protect against denial of 87 service (DoS) attacks. 89 For multicast destination addresses, receiver applications MAY apply 90 source-filters using the Multicast Source Filter APIs [MSF API]. 91 Hosts are likely to implement these APIs using protocol mechanisms to 92 convey the source filters to local multicast routers. Other 93 "upstream" multicast routers MAY apply the filters and thereby 94 provide more explicit multicast group management and efficient 95 utilization of network resources. The protocol mechanisms to enable 96 these operations are beyond the scope of this document, but their 97 potential provided motivation for SDP source-filters. 99 3. The "source-filter" Attribute 101 The SDP source-filter attribute does not change any existing SDP 102 syntax or semantics, but defines a format for additional session 103 description information. Specifically, source-filter syntax can 104 prescribe one or more unicast addresses as either legitimate or 105 illegitimate sources for any (or all) SDP session description 106 "connection-address" field values. 108 Note that the unicast source addresses specified by this attribute 109 are those that are seen by a receiver. Therefore, if source 110 addresses undergo translation en route from the original sender to 111 the receiver - e.g., due to NAT (Network Address Translation) or some 112 tunneling mechanism - then the SDP "source-filter" attribute - as 113 presented to the receiver, will not be accurate, unless the source 114 addresses therein are also translated accordingly. 116 The source-filter attribute has the following syntax: 118 a=source-filter: 120 The is either "incl" or "excl" (for inclusion or 121 exclusion, respectively). The has four sub-components: 123 125 A of "incl" means that an incoming packet is accepted 126 only if its source address is in the set specified by . 127 A of "excl" means that an incoming packet is rejected 128 if its source address is in the set specified by . 130 The first sub-field indicates the network type, since SDP 131 is protocol independent. This document is most relevant to the value 132 "IN", which designates the Internet Protocol. 134 The second sub-field identifies the address family, 135 and for the purpose of this document may be either value 136 "IP4" or "IP6". Alternately, when is an FQDN 137 (fully-qualified domain name), the value MAY be "*" to apply to both 138 address types, since either address type can be returned from a DNS 139 lookup. 141 The third sub-field is the destination address, which 142 MUST correspond to one or more of the session's "connection-address" 143 field values. It may be either a unicast or multicast address, 144 a FQDN, or the "*" wildcard to match any/all of the session's 145 "connection-address" values. 147 The fourth sub-field is the list of source 148 hosts/interfaces in the source-filter, and consists of one or more 149 unicast addresses or FQDNs, separated by space characters. 151 The format and content of these semantic elements are derived from 152 and compatible with those defined in [SDP]. For more detail, see 153 Appendix A of this document. 155 3.1. Processing Rules 157 There are a number of details to consider when parsing the SDP 158 source-filter syntax. 160 The value in a "source-filter" attribute MUST 161 correspond to an existing value in the session 162 description. The only exception to this is when a "*" wildcard is 163 used to indicate that the source-filter applies to all 164 values. 166 When the value is a multicast address, the field value 167 MUST NOT include the sub-fields and from 168 the value. If the 169 specifies more than one multicast address (in the 170 field), then a source filter, if any, for each 171 such address must be stated explicitly, using a separate 172 "a=source-filter" line for each address (unless a "*" wildcard is 173 used for ). See section 3.2.4 for an example. 175 When the value is the "*" wildcard, the 176 MUST be either a FQDN or "*" (i.e., it MUST NOT be an IPv4 or IPv6 177 address). See section 3.2.6 for an example. 179 As has always been the case, the default behavior when a 180 source-filter attribute is not provided in a session description is 181 that all traffic sent to the specified value 182 should be accepted (i.e., from any source address). The 183 source-filter grammar does not include syntax to express either 184 "exclude none" or "include all." 186 Like the standard described in [SDP], the location 187 of the "source-filter" attribute determines whether it applies to the 188 entire session or only to a specific medium (i.e., "session-level" or 189 "media-level"). A media-level source-filter will always completely 190 override a session-level source-filter. 192 A "source-filter" need not be located at the same hierarchy level as 193 its corresponding . So, a media-level can reference a session-level value, and a 195 session-level "source-filter" can be applied to all matching media- 196 level values. See section 3.2.3 for an example. 198 An SDP description MUST NOT contain more than one session-level 199 "source-filter" attribute that covers the same destination address, 200 nor more than one media-level "source-filter" attribute that covers 201 the same destination address. 203 There is no specified limit to the number of entries allowed in the 204 , however there are practical limits that should be 205 considered. For example, depending on the transport to be used for 206 the session description, there may be a limit to the total size of 207 the session description (e.g., as determined by the maximum payload 208 in a single datagram). Also, when the source-filter is applied to 209 control protocols, there may be a limit to the number of source 210 addresses that can be sent. These limits are outside the scope of 211 this document, but should be considered when defining source-filter 212 values for SDP. 214 3.2. Examples 216 Here are a number of examples that illustrate how to use the source- 217 filter attribute in some common scenarios. We use the following 218 session description components as the starting point for the examples 219 to follow. For each example, we show the source filter with 220 additional relevant information, and provide a brief explanation. 222 = 223 v=0 224 o=The King 225 s=Elvis Impersonation 226 i=All Elvis, all the time 227 u=http://www.example.com/ElvisLive/ 228 t=0 0 229 a=recvonly 231 = 232 m=audio 54320 RTP/AVP 0 234 = 235 m=video 54322 RTP/AVP 34 237 3.2.1. Source-Specific Multicast Example 239 Multicast addresses in the Source-Specific Multicast [SSM] range 240 require a single unicast sender address for each multicast 241 destination, so the source-filter specification provides a natural 242 fit. In this example, a session member should receive only traffic 243 sent from 192.0.2.10 to the multicast session address 232.3.4.5. 245 247 c=IN IP4 232.3.4.5/127 248 a=source-filter: incl IN IP4 232.3.4.5 192.0.2.10 250 252 This source filter example uses an inclusion list with a single 253 multicast "connection-address" as the destination and single unicast 254 address as the source. Note that the value of the connection-address 255 matches the value specified in the connection-field. 257 Also note that since the connection-field is located in the session- 258 description section, the source-filter applies to all media. 260 Furthermore, if the SDP description specifies a RTP session 261 (e.g., its "m=" line(s) specify "RTP/AVP" as the transport protocol), 262 then the "incl" specification will apply not only to RTP packets, 263 but also to any RTCP packets that are sent to the specified multicast 264 address. This means that, as a side effect of the "incl" 265 specification, the only possible multicast RTCP packets will be 266 "Sender Report" (SR) packets sent from the specified source address. 268 Because of this, an SDP description for a Source-Specific Multicast 269 (SSM) RTP session SHOULD also include a 270 a=rtcp: unicast ... 271 attribute, as described in [RTCP-SSM] (section 10.1). This specifies 272 that RTCP "Reception Report" (RR) packets are to be sent back via 273 unicast. 275 3.2.2. Unicast Exclusion Example 277 Typically, an SDP session value is a multicast 278 address, although it is also possible to use either a unicast 279 address or FQDN. This example illustrates a scenario whereby a 280 session description indicates the unicast source address 192.0.2.10 281 in an exclusion filter. In effect, this sample source-filter says, 282 "destination 192.0.2.11 should accept traffic from any sender 283 *except* 192.0.2.10." 285 287 c=IN IP4 192.0.2.11 288 a=source-filter: excl IN IP4 192.0.2.11 192.0.2.10 290 292 3.2.3. Multiple Session Address Example 294 This source-filter example uses the wildcard "*" value for 295 to correspond to any/all values. 296 Hence, the only legitimate source for traffic sent to either 297 232.2.2.2 or 232.4.4.4 multicast addresses is 192.0.2.10. 298 Traffic sent from any other unicast source address should be 299 discarded by the receiver. 301 303 a=source-filter: incl IN IP4 * 192.0.2.10 305 307 c=IN IP4 232.2.2.2/127 309 311 c=IN IP4 232.4.4.4/63 313 3.2.4. Multiple Multicast Address Example 315 In this example, the specifies three multicast 316 addresses: 224.2.1.1, 224.2.1.2, and 224.2.1.3. The first and third 317 of these addresses are given source filters. However, in this 318 example the second address - 224.2.1.2 - is *not* given a 319 source filter. 321 323 c=IN IP4 224.2.1.1/127/3 324 a=source-filter: incl IN IP4 224.2.1.1 192.0.2.10 325 a=source-filter: incl IN IP4 224.2.1.3 192.0.2.42 327 329 3.2.5. IPv6 Multicast Source-Filter Example 331 This simple example defines a single session-level source-filter that 332 references a single IPv6 multicast destination and source pair. The 333 IP multicast traffic sent to FFOE::11A is valid only from the unicast 334 source address 2001:DB8:1:2:240:96FF:FE25:8EC9 336 338 c=IN IP6 FF0E::11A/127 339 a=source-filter incl IN IP6 FF0E::11A 2001:DB8:1:2:240:96FF:FE25:8EC9 341 343 3.2.6. IPv4 and IPv6 FQDN Example 345 This example illustrates use of the "*" wildcard, along 346 with multicast and source FQDNs that may resolve to either an IPv6 347 or IPv4 address, or both. Although typically both the multicast and 348 source addresses will be the same (either both IPv4 or IPv6), using 349 the wildcard for addrtype in the source filter allows asymmetry 350 between the two addresses (so an IPv4 source address may be used 351 with an IPv6 multicast address). 353 355 c=IN IP4 channel-1.example.com/127 356 c=IN IP6 channel-1.example.com/127 357 a=source-filter: incl IN * channel-1.example.com src-1.example.com 359 361 3.3 Offer-Answer Model Considerations 363 The "source-filter" attribute is not intended to be used as an 364 'offer' in a SDP offer-answer exchange [OFFER], because sets of 365 source addresses do not represent 'capabilities' or 'limitations' 366 of the offerer, and because the offerer does not, in general, have 367 'a priori' knowledge of which IP source address(es) will be included 368 in an answer. While an answerer may include the "source-filter" 369 attribute in his answer (e.g., to designate a SSM session), he SHOULD 370 ignore any "source-filter" attribute that was present in the original 371 offer. 373 4. Interoperability Issues 375 Defining a list of legitimate sources for a multicast destination 376 address represents a departure from the Any-Source Multicast 377 (ASM) model, as originally described in [IGMPv1]. The ASM model 378 supports anonymous senders, and all types of multicast applications 379 (e.g., many-to-many). Use of a source-filter excludes some (unknown 380 or undesirable) senders, which lends itself more to one-to-many or 381 few-to-few type multicast applications. 383 Although these two models have contrasting operational 384 characteristics and requirements, they can coexist on the same 385 network using the same protocols. Use of source-filters do not 386 corrupt the ASM semantics but provide more control for receivers, 387 at their discretion. 389 5. Security Considerations 391 See [SDP] for security considerations specific to the Session 392 Description Protocol in general. The central issue relevant to 393 using source address filters is the question of address 394 authenticity. 396 Using the source IP address for authentication is weak, since 397 addresses are often dynamically assigned and it is possible for a 398 sender to "spoof" its source address (i.e., use one other than its 399 own) in datagrams that it sends. Proper router configuration, 400 however, can reduce the likelihood of "spoofed" source addresses 401 being sent to or from a network. Specifically, border routers are 402 encouraged to filter traffic so that datagrams with invalid source 403 addresses are not forwarded (e.g., routers drop datagrams if the 404 source address is non-local) [FILTERING]. This, however, does not 405 prevent IP source addresses from being spoofed on a LAN. 407 Also, as noted in section 3 above, tunneling or NAT mechanisms 408 may require corresponding translation of the addresses specified in 409 the SDP "source-filter" attribute, and furthermore, may cause a set 410 of original source addresses to be translated to a smaller set of 411 source addresses as seen by the receiver. 413 Use of FQDNs for either or values provides 414 a layer of indirection that provides great flexibility. However, it 415 also exposes the source-filter to any security inadequacies that the 416 DNS system may have. If unsecured, it is conceivable that the DNS 417 server could return illegitimate addresses. 419 In addition, if source-filtering is implemented by sharing the 420 source-filter information with network elements, then the security of 421 the protocol(s) that are used for this (e.g., [IGMPv3]) becomes 422 important, to ensure that legitimate traffic (and only legitimate 423 traffic) is received. 425 For these reasons, receivers SHOULD NOT treat the SDP "source-filter" 426 attribute as being its sole mechanism for protecting the integrity 427 of received content. 429 6. IANA Considerations 431 As recommended by [SDP] (Appendix B), the new attribute name 432 "source-filter" should be registered with IANA, as follows: 434 The following contact information shall be used for all 435 registrations included here: 437 Contact: Ross Finlayson 438 email: finlayson (at) live555.com 439 phone: +1-650-254-1184 441 SDP Attribute ("att-field"): 442 Attribute name: source-filter 443 Long form: Source Filter 444 Type of name: att-field 445 Type of attribute: Session level or media level 446 Subject to charset: No 447 Purpose: See this document 448 Reference: This document 449 Values: See this document, and registrations below 451 7. Acknowledgements 453 The authors would like to thank Dave Thaler and Mark Handley, whose 454 input provided much of the substance of this document. Magnus 455 Westerlund also provided valuable feedback during editing. 457 8. Normative References 459 [ABNF] Crocker, D., P. Overell, "Augmented BNF for Syntax 460 Specifications: ABNF," RFC 2234, November 1997. 462 [REQMNT] Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels," BCP 14, RFC 2119, March 1997. 465 [RTCP-SSM] Chesterfield, J., E. Schooler, J. Ott, 466 "RTCP Extensions for Single-Source Multicast Sessions 467 with Unicast Feedback," Work in progress, October 2004. 469 [SDP] Handley, M., V. Jacobson, C. Perkins, 470 "SDP: Session Description Protocol," 471 Work in Progress, February 2005. 473 [UTF-8] Yergeau, F., "UTF-8, a transformation format of 474 ISO 10646," RFC 3629, October 1996. 476 9. Informative References 478 [FILTERING] Ferguson, P., D. Senie, "Network Ingress Filtering: 479 Defeating Denial of Service Attacks which employ IP 480 Source Address Spoofing," BCP 38, RFC 2827, May 2000. 482 [IGMPv1] Deering, S., "Host Extensions for IP Multicasting," 483 RFC 1112 (STD 5), August 1989. 485 [IGMPv3] Cain, B. et al. "Internet Group Management Protocol, 486 Version 3,", RFC 3376, October 2002. 488 [MSF API] Thaler, D., B. Fenner, B. Quinn, "Socket Interface 489 Extensions for Multicast Source Filters," 490 RFC 3678, January 2004. 492 [OFFER] Rosenberg, J., H. Schulzrinne, "An Offer/Answer Model 493 with the Session Description Protocol (SDP)", 494 RFC 3264, June 2002. 496 [SSM] Bhattacharyya, S. et al., "An Overview of Source-Specific 497 Multicast (SSM)," RFC 3569, July 2003. 499 10. Authors' Addresses 501 Bob Quinn 502 Celox Networks 503 2 Park Central Drive 504 Southborough, MA 01772 505 phone: 508-305-7000 506 email: bquinn (at) celoxnetworks.com 508 Ross Finlayson 509 Live Networks, Inc. 510 650 Castro St., suite 120-196 511 Mountain View, CA 94041 512 email: finlayson (at) live555.com 514 11. IPR Notice 516 The IETF takes no position regarding the validity or scope of any 517 Intellectual Property Rights or other rights that might be claimed 518 to pertain to the implementation or use of the technology 519 described in this document or the extent to which any license 520 under such rights might or might not be available; nor does it 521 represent that it has made any independent effort to identify any 522 such rights. Information on the procedures with respect to rights 523 in RFC documents can be found in BCP 78 and BCP 79. 525 Copies of IPR disclosures made to the IETF Secretariat and any 526 assurances of licenses to be made available, or the result of an 527 attempt made to obtain a general license or permission for the use 528 of such proprietary rights by implementers or users of this 529 specification can be obtained from the IETF on-line IPR repository 530 at http://www.ietf.org/ipr. 532 The IETF invites any interested party to bring to its attention 533 any copyrights, patents or patent applications, or other 534 proprietary rights that may cover technology that may be required 535 to implement this standard. Please address the information to the 536 IETF at ietf-ipr@ietf.org. 538 12. Copyright Notice 540 Copyright (C) The Internet Society (2005). 542 This document is subject to the rights, licenses and restrictions 543 contained in BCP 78, and except as set forth therein, the authors 544 retain all their rights. 546 This document and the information contained herein are provided on an 547 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 548 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 549 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 550 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 551 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 552 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 554 Appendix A. Source-Filter Attribute Syntax 556 This appendix provides an Augmented BNF [ABNF] grammar for expressing 557 an exclusion or inclusion list of one or more (IPv4 or IPv6) unicast 558 source addresses. It is intended as an extension to the grammar for 559 the Session Description Protocol, as defined in [SDP]. Specifically, 560 it describes the syntax for the new "source-filter" attribute field, 561 which MAY be either a session-level or media-level attribute. 563 The "dest-address" value in each source filter field MUST match 564 an existing connection-field value, unless the wildcard connection- 565 address value "*" is specified. 567 source-filter = "source-filter" ":" SP filter-mode SP filter-spec 568 ; SP is the ASCII 'space' character 569 ; (0x20, defined in [ABNF]). 571 filter-mode = "excl" / "incl" 572 ; either exclusion or inclusion mode 574 filter-spec = nettype SP address-types SP dest-address SP src-list 575 ; nettype is as defined in [SDP]. 577 address-types = "*" / addrtype 578 ; "*" for all address types (both IP4 and IP6), 579 ; but only when and 580 ; reference FQDNs. 581 ; addrtype is as defined in [SDP]. 583 dest-address = "*" / basic-multicast-address / unicast-address 584 ; "*" applies to all connection-address values. 585 ; unicast-address is as defined in [SDP]. 587 src-list = *(unicast-address SP) unicast-address 588 ; one or more unicast source addresses (in 589 ; standard IPv4 or IPv6 ASCII-notation form) 590 ; or FQDNs. 591 ; unicast-address is as defined in [SDP]. 593 basic-multicast-address = basic-IP4-multicast / basic-IP6-multicast 594 / FQDN / extn-addr 595 ; i.e., the same as multicast-address 596 ; defined in [SDP], except that the 597 ; / and / 598 ; fields are not included. 599 ; FQDN and extn-addr are as defined 600 ; in [SDP]. 602 basic-IP4-multicast = m1 3( "." decimal-uchar ) 603 ; m1 and decimal-uchar are as defined 604 ; in [SDP]. 606 basic-IP6-multicast = hexpart 607 ; hexpart is as defined in [SDP]. 609 Expires: March 2006 September 22, 2005