idnits 2.17.1 draft-ietf-magma-mrdssm-01.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 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 66: '...SSM Range option SHOULD be included in...' RFC 2119 keyword, line 101: '...t Router Advertisement messages SHOULD...' RFC 2119 keyword, line 105: '...options MUST only use the prefixes fro...' RFC 2119 keyword, line 109: '...Discovery Option MUST compare the cont...' 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 (3 November 2002) is 7837 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 3171 (ref. '1') (Obsoleted by RFC 5771) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 4 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-01.txt 3 November 2002 4 Expires: May 2003 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 MAGMA WG. Comments should be 29 addressed to the authors, or the WG's mailing list at magma@ietf.org. 31 Abstract 33 This document defines the Multicast Router Discovery option 34 for advertising the configured IPv4 Source Specific Multicast 35 destination address range. 37 1. Introduction 39 With current multicast deployment in the Internet, different 40 multicast routing protocols coexist and operate under separate parts of 41 the multicast address space [1]. Multicast routers are consistently 42 configured with information that maps specific multicast destination 43 address ranges to multicast routing protocols. Part of this 44 configuration describes the subset of the address space that is used by 45 source-specific multicast (SSM) [2]. 47 There are currently two requirements for a router to advertise its 48 configured SSM range on its attached links: 50 o On links with multiple multicast routers, advertisement of the 51 configured SSM range by each router can be used to discover miss- 52 configurations. 54 o IP systems with multicast sources or receivers can use the 55 advertisements to learn the SSM group range with which the network is 56 configured. 58 This document defines an optional extension for the IPv4 Multicast 59 Router Discovery protocol [3] which can be used to advertise the SSM 60 range. Note that the SSM range for IPv6 is well defined and a mechanism 61 to allow additional ranges to operate in SSM mode on a per-link bases is 62 not required. 64 2. SSM Range Option Format 66 The SSM Range option SHOULD be included in all Multicast Router 67 Advertisement messages [3]. It contains the list of multicast 68 destination address ranges that are configured to operate under Source 69 Specific Multicast on this router. The format of the option is as 70 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=X | Length=var | Mask-Len-1 | Prefix-1 ... 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 | Mask-Len-2 | Prefix-2 ... 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 79 | ... | 80 Type The type value of the Multicast Router Advertisement SSM Range 81 option is X (TBD by IANA). 83 Length 84 The length of the SSM Range Discovery option is variable and 85 depends on the number of destination ranges present in the option 86 as well as the sizes of the ranges. 88 Mask-Len-n 89 The mask length for the nth address range. 91 Prefix-n 92 The multicast destination address prefix for the nth range present 93 in this option. The size of the prefix field is variable and 94 depends on the number of significant bits in the prefix (specified 95 in the corresponding Mask-Len field). The field is padded by enough 96 trailing bits to make the end of the field fall on an octet 97 boundary. Note that the value of the trailing bits is irrelevant. 99 3. Notes on Option Processing 101 Routers originating Multicast Router Advertisement messages SHOULD 102 NOT include more than one SSM Range Discovery option in each message. 103 Systems with a multicast capable IP host stack that receive a Multicast 104 Router Advertisement message with more than one SSM Range Discovery 105 options MUST only use the prefixes from the last SSM Range Discovery 106 option in the message as the active SSM range. 108 A router receiving a Multicast Router Advertisement message with an 109 SSM Range Discovery Option MUST compare the contents of the option with 110 the multicast address ranges in the local SSM configuration and signal 111 any differences to the administrator in a rate-limited manner. 113 4. Security Considerations 115 Multicast Router Advertisement messages are IGMP messages sent to 116 the All-Systems multicast group (224.0.0.1) which is not forwarded by 117 routers. Only rogue systems on a connected link can masquerade as 118 multicast routers. Such rogue systems can include the SSM Range 119 Discovery option in their messages and cause the SSM range mapping to be 120 incorrectly set by hosts on the link. The next Multicast Router 121 Advertisement from a real valid router on the link will restore the 122 correct mapping. This spec mandates that routers log the reception of 123 inconsistent range advertisements which makes it easier to detect rogue 124 systems. 126 5. IANA Considerations 128 This document introduces the new SSM Range Option for the Multicast 129 Router Discovery protocol. This option requires a new MRD type value to 130 be assigned by IANA. 132 6. Acknowledgments 134 The author would like to thank Bill Fenner and Dave Thaler for their 135 contribution to this document. 137 7. Authors' Addresses 139 Isidor Kouvelas 140 Cisco Systems 141 170 W. Tasman Drive 142 San Jose, CA 95134 143 kouvelas@cisco.com 145 8. References 147 [1] Z. Albanna, K. Almeroth, D. Meyer, M. Schipper, "IANA Guidelines for 148 IPv4 Multicast Address Assignments", RFC 3171 (BCP 51), August 149 2001. 151 [2] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", work in 152 progress, , 21 November 2001. 154 [3] S. Biswas, B. Haberman, "IGMP Multicast Router Discovery", Work In 155 Progress, , 2002.