idnits 2.17.1 draft-ramki-igmp-ssm-ranges-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2019) is 1753 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) == Unused Reference: 'RFC3376' is defined on line 177, but no explicit reference was found in the text == Unused Reference: 'RFC4604' is defined on line 182, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 188, but no explicit reference was found in the text == Unused Reference: 'RFC3973' is defined on line 194, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Chokkanathapuram Sundaram 3 Internet-Draft S. Venaas 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: January 9, 2020 July 8, 2019 7 Source specific multicast range distribution for L2 multicast networks 8 draft-ramki-igmp-ssm-ranges-00 10 Abstract 12 In an IGMP snooping multicast network with version 3 (v3) enabled on 13 the routers, when a v2 join/leave is received for a multicast group 14 the router operates on V2 compatible mode. For SSM ranges a (*,G)v2 15 or v3 report should be ignored by the router/switch. The IGMP 16 snooping switches may not have knowledge about the user configured 17 SSM range in the network to correctly discard/ignore the v2 join/ 18 leave. Accepting (*,G) v2 or v3 will cause SSM operations to fail. 19 This draft discusses distribution of SSM ranges in the L2 multicast 20 network so that L2 snooping switches can learn about the configured 21 SSM ranges and discard any (*,G) v2/v3 reports for the said ranges. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 9, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. L2 network with a PIM router . . . . . . . . . . . . . . . . 3 61 3. L2 multicast network with no PIM router . . . . . . . . . . . 3 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 66 6.2. Informative References . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 IGMP v2 join and leaves and IGMP v3 (*,G) group records should be 72 discarded for Source specific multicast group ranges. The default 73 SSM range is 232/8 but changing the range is possible. In a L2 74 multicast network the Snooping switches are unaware of the user 75 configured SSM ranges in the network. Methods are needed to 76 distribute user configured SSM ranges so that all snooping switches 77 in the L2 domain knows about the same. Thus the snooping switches 78 can discard the Version 2 joins/leaves falling in the SSM range. If 79 the v2 joins/leaves for the SSM ranges are not discarded then the 80 router/ querier start operating in v2 mode. This will result in 81 outages. The same problem is applicable for MLD as well. 83 1.1. Conventions Used in This Document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 1.2. Terminology 91 DR: Designated Router 93 SSM: Source Specific Multicast 95 2. L2 network with a PIM router 97 In a LAN if a PIM router is detected the LAN segment should use the 98 PIM SSM range configured on the PIM router which is the DR on the 99 LAN. Snooping switches typically process PIM Hello packets already 100 to detect routers. A new PIM Hello Option will carry the current 101 (default or configured) SSM group ranges. The PIM Hello Option can 102 be used by the snooping switches to learn the SSM ranges used in the 103 network. Thus an IGMP message for a group in the SSM range in a v3 104 enabled network can correctly be discarded/ignored. Preventing hosts 105 (whether by accident or a DoS attack) from disrupting the SSM 106 service. Routers could be statically configured with the SSM group 107 range. In case there are multiple routers on the LAN it is possible 108 that routers are configured with different ranges. In that case, 109 switches should use the range announced by the DR. The option allows 110 for detecting configuration mistakes. A PIM router can log a message 111 if it sees a neighbor announcing a different SSM range. Also, 112 switches can log a message if they are statically configured with 113 ranges that differ from what what is announced by the DR. There is 114 no hold time for the config. The config is removed if the router 115 sends a hello without the option, or the DR expires. If a new DR is 116 elected, the config will be replaced by what the new DR is 117 announcing. 119 Figure 1: PIM SSM range hello option. 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Type = TBD | Length = Variable. | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Group Address 1 (Encoded-Group format) | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Group Address N (Encoded-Group format) | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 3. L2 multicast network with no PIM router 134 In a pure L2 only network a new IGMP message is sent from querier to 135 learn the SSM ranges. The SSM range used should be configured on the 136 querier and the querier will distribute it with a new message type so 137 that all L2 switches can learn about the SSM range. 139 Figure 2: IGMP SSM range message. 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Type = TBD | Reserved | Checksum | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Reserved | Num SSM ranges | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | SSM range 1 | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | .... | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | SSM range N | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 SSM range is an IP address plus a length octet. 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | SSM Prefix address | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Prefix length | 159 +-+-+-+-+-+-+-+-+ 161 4. IANA Considerations 163 This document requires the assignment of a PIM hello option and an 164 IGMP message type. 166 5. Acknowledgments 168 6. References 170 6.1. Normative References 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, 174 DOI 10.17487/RFC2119, March 1997, 175 . 177 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 178 Thyagarajan, "Internet Group Management Protocol, Version 179 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 180 . 182 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 183 Group Management Protocol Version 3 (IGMPv3) and Multicast 184 Listener Discovery Protocol Version 2 (MLDv2) for Source- 185 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 186 August 2006, . 188 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 189 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 190 . 192 6.2. Informative References 194 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 195 Independent Multicast - Dense Mode (PIM-DM): Protocol 196 Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, 197 January 2005, . 199 Authors' Addresses 201 Ramakrishnan Chokkanathapuram Sundaram 202 Cisco Systems, Inc. 203 Tasman Drive 204 San Jose CA 95134 205 USA 207 Email: ramaksun@cisco.com 209 Stig Venaas 210 Cisco Systems, Inc. 211 Tasman Drive 212 San Jose CA 95134 213 USA 215 Email: stig@cisco.com