idnits 2.17.1 draft-ietf-magma-mrdssm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 65: '...SSM Range option SHOULD be included in...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (21 February 2002) is 8097 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2461 (ref. '4') (Obsoleted by RFC 4861) Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force MAGMA WG 2 INTERNET-DRAFT Isidor Kouvelas/Cisco 3 draft-ietf-magma-mrdssm-00.txt 21 February 2002 4 Expires: August 2002 6 Multicast Router Discovery SSM Range Option 8 Status of this Document 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This document is a product of the IETF IDMR WG. Comments should be 29 addressed to the authors, or the WG's mailing list at 30 pim@catarina.usc.edu. 32 Abstract 34 This document defines the Multicast Router Discovery option 35 for advertising the configured Source Specific Multicast 36 destination address range. 38 1. Introduction 40 With current multicast deployment in the Internet, different 41 multicast routing protocols coexist and operate under separate parts of 42 the multicast address space [1]. Multicast routers are consistently 43 configured with information that maps specific multicast destination 44 address ranges to multicast routing protocols. Part of this 45 configuration describes the subset of the address space that is used by 46 source-specific multicast (SSM) [2]. 48 There are currently two requirements for a router to advertise its 49 configured SSM range on its attached links: 51 o On links with multiple multicast routers, advertisement of the 52 configured SSM range by each router can be used to discover miss- 53 configurations. 55 o IP systems with multicast sources or receivers can use the 56 advertisements to learn the SSM group range with which the network is 57 configured. 59 This document defines an optional extension for the Multicast 60 Router Discovery protocol [3] which can be used to advertise the SSM 61 range. 63 2. SSM Range Option 65 The SSM Range option SHOULD be included in all Multicast Router 66 Advertisement messages for IPv4 [3] and all Neighbour Discovery Protocol 67 Router Advertisement messages for IPv6 [4]. It contains the list of 68 multicast destination address ranges that are configured to operate 69 under Source Specific Multicast on this router. The format of the 70 option is as follows: 72 0 1 2 3 73 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 74 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 75 | Type=Y | Length=var | Mask-Len-1 | Prefix-1 ... 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 | Mask-Len-2 | Prefix-2 ... 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 79 | ... | 80 Type The type value of the SSM Range option is TBD-X when present in 81 IPv4 Multicast Router Advertisement messages and TBD-Z when present 82 in IPv6 Neighbour Discovery Protocol Advertisement messages. 84 Length 85 The length of the SSM Range Discovery option is variable and 86 depends on the number of destination ranges present in the option 87 as well as the sizes of the ranges. 89 Mask-Len-n 90 The mask length for the nth address range. 92 Prefix-n 93 The multicast destination address prefix of the nth range present 94 in this option. The size of the prefix field is variable and 95 depends on the number of significant bits in the prefix (specified 96 in the corresponding Mask-Len field). The field is padded by enough 97 trailing bits to make the end of the field fall on an octet 98 boundary. Note that the value of the trailing bits is irrelevant. 100 A router receiving a Multicast Router Advertisement message or a 101 Neighbour Discovery Protocol Router Advertisement message with an SSM 102 Range Discovery Option must compare the contents of the option with the 103 multicast address ranges in the local SSM configuration and signal any 104 differences to the administrator in a rate-limited manner. 106 3. Acknowledgements 108 The author would like to thank Bill Fenner and Dave Thaler for their 109 contribution to this document. 111 4. Authors' Addresses 113 Isidor Kouvelas 114 Cisco Systems 115 170 W. Tasman Drive 116 San Jose, CA 95134 117 kouvelas@cisco.com 119 5. References 121 [1] Z. Albanna, K. Almeroth, D. Meyer, "IANA Guidelines for IPv4 122 Multicast Address Allocation", Best Current Practices, , 2001. 125 [2] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", work in 126 progress, , 21 November 2001. 128 [3] S. Biswas, B. Haberman, "IGMP Multicast Router Discovery", Work In 129 Progress, , 2002. 131 [4] T. Narten, E. Nordmark, W. Simpson, "Neighbour Discovery for IP 132 Version 6 (IPv6)", Standards Track RFC2461, December 1998.