idnits 2.17.1 draft-venaas-pim-igmp-mld-extension-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 : ---------------------------------------------------------------------------- No issues found here. 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 (November 4, 2019) is 1627 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: '1' on line 283 -- Looks like a reference, but probably isn't: '2' on line 289 == Missing Reference: 'N' is mentioned on line 263, but not defined == Missing Reference: 'M' is mentioned on line 299, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-bier-mld-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Sivakumar 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track S. Venaas 5 Expires: May 7, 2020 Cisco Systems, Inc. 6 Z. Zhang 7 ZTE Corporation 8 November 4, 2019 10 IGMPv3/MLDv2 Message Extension 11 draft-venaas-pim-igmp-mld-extension-00 13 Abstract 15 IGMP and MLD protocols are extensible, but no extensions have been 16 defined so far. This document provides a well-defined way of 17 extending IGMP and MLD, including a new extension type to distinguish 18 between different extensions. This document also defines an 19 extension for use with IGMP and MLD over BIER, that allows for 20 identifying the sender. This will in turn enable MLD (resp. IGMP) 21 to be used in the BIER multicast flow overlay. 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 May 7, 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 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 3. Proposed MLD/IGMP Extension . . . . . . . . . . . . . . . . . 3 60 3.1. Multicast Listener Query Extension . . . . . . . . . . . 4 61 3.2. Version 2 Multicast Listener Report Extension . . . . . . 5 62 3.3. IGMP Membership Query Extension . . . . . . . . . . . . . 6 63 3.4. IGMP Version 3 Membership Report Extension . . . . . . . 7 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 6.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 In this document, we describe a generic method to extend IGMPv3 74 [RFC3376] and MLDv2 [RFC3810] messages to accommodate information 75 other than what is contained in the current message formats. This is 76 done by introducing an extension-type field in the message formats to 77 indicate the application for which the extension is done. This will 78 be followed by the actual value of the extension. 80 Bit Index Explicit Replication (BIER [RFC8279]) defines a new 81 architecture for optimal forwarding of multicast packets through a 82 multicast domain without requiring a protocol for explicitly bulding 83 multicast distribution trees while obviating the need for 84 intermediate nodes to maintain any per-flow state. Forwarding in the 85 BIER network is accomplished by having ingress routers construct a 86 bit mask indicating the set of egress routers in the BIER domain 87 interested in receiving the packet. 89 New technologies (such as BIER) can use MLD (resp. IGMP) as an 90 overlay protocol, in order to collect the ingress and egress nodes 91 for multicast flows in a multicast domain (such as a BIER domain) 92 [I-D.ietf-bier-mld]. That draft makes use of an extension to IGMP/ 93 MLD, defined in this document, to have additional info identifying 94 the BIER sender of the message. This allows the IGMP/MLD overlay to 95 know exactly who is interested in receiving flows. It can 96 potentially also be used for other purposes such as logging to 97 capture information regarding the sender of the message. The 98 extension will be part of additional data as mentioned in [RFC3810] 99 Section 5.1.12 (resp. [RFC3376] Section 4.1.10) for query messages 100 and [RFC3810] Section 5.2.12 (resp. [RFC3376] Section 4.2.11) for 101 report messages. 103 2. Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 3. Proposed MLD/IGMP Extension 113 The proposed MLD (resp. IGMP) extension for BIER will contain the 114 same information as the PTA tunnel identifier in [RFC8556] and is 115 shown in Figure 1. Note that, as defined in the MLD (resp. IGMP), 116 existing implementations are supposed to ignore this additional data. 118 0 1 2 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 |Extension Type | Sub-domain ID | BFR-ID | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | BFR-Prefix | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 ~ ~ 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | BFR-Prefix | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 Figure 1: MLD/IGMP Extension Data for BIER 132 o Extension Type: The first octet will introduce an IGMP/MLD 133 extension type for BIER. This would mean that if we need to 134 extend MLD (resp. IGMP) messages for other purposes, the type can 135 tell us what the extension represents. What follows is the 136 information needed for BIER overlay. For BIER the value here will 137 be as assigned by IANA. 139 o Sub-domain-id: The second field is a single octet, containing a 140 BIER sub-domain-id (see [[RFC8279]]). This indicates the BIER 141 sub-domain of the router originating the message. 143 o BFR-id: The next field is a two-octet field containing the BFR-id, 144 in the specified sub-domain, of the router originating the 145 message. 147 o BFR-prefix: The last field is the BFR-prefix (see [[RFC8279]]) of 148 the router that is originating the message. The BFR-prefix will 149 either be a /32 IPv4 address or a /128 IPv6 address. 151 3.1. Multicast Listener Query Extension 153 The MLD query format with the proposed extension is shown below 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Type = 130 | Code | Checksum | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Maximum Response Code | Reserved | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | 163 * * 164 | | 165 * Multicast Address * 166 | | 167 * * 168 | | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Resv |S| QRV | QQIC | Number of Sources (N) | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | | 173 * * 174 | | 175 * Source Address [1] * 176 | | 177 * * 178 | | 179 +- -+ 180 | | 181 * * 182 | | 183 * Source Address [2] * 184 | | 185 * * 186 | | 187 +- . -+ 188 . . . 189 . . . 191 +- -+ 192 | | 193 * * 194 | | 195 * Source Address [N] * 196 | | 197 * * 198 | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 |Extension Type | Extension Value | 201 ~ ~ 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Figure 2: MLD Query Extension 206 3.2. Version 2 Multicast Listener Report Extension 208 The MLD report format with the proposed extension is shown below 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Type = 143 | Reserved | Checksum | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Reserved |Nr of Mcast Address Records (M)| 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | | 217 . . 218 . Multicast Address Record [1] . 219 . . 220 | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | | 223 . . 224 . Multicast Address Record [2] . 225 . . 226 | | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | . | 229 . . . 230 | . | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | | 233 . . 234 . Multicast Address Record [M] . 235 . . 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 |Extension Type | Extension Value | 239 ~ ~ 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 3: MLD Report Extension 244 3.3. IGMP Membership Query Extension 246 The IGMP query format with the proposed extension is shown below 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type = 0x11 | Max Resp Code | Checksum | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Group Address | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Resv |S| QRV | QQIC | Number of Sources (N) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Source Address [1] | 257 +- -+ 258 | Source Address [2] | 259 +- . -+ 260 . . . 261 . . . 262 +- -+ 263 | Source Address [N] | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 |Extension Type | Extension Value | 266 ~ ~ 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 4: IGMP Query Extension 271 3.4. IGMP Version 3 Membership Report Extension 273 The IGMP report format with the proposed extension is shown below 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Type = 0x22 | Reserved | Checksum | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Reserved | Number of Group Records (M) | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | 282 . . 283 . Group Record [1] . 284 . . 285 | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | | 288 . . 289 . Group Record [2] . 290 . . 291 | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | . | 294 . . . 295 | . | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 . . 299 . Group Record [M] . 300 . . 301 | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |Extension Type | Extension Value | 304 ~ ~ 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 5: IGMP Report Extension 309 4. Security Considerations 311 This document extends MLD (resp. IGMP) message formats for a BIER 312 overlay. As such, there is no impact on security or changes to the 313 considerations in [RFC3810] and [RFC3376]. 315 5. IANA Considerations 317 This document requests that IANA assign a new registry entry for the 318 MLD (resp. IGMP) extension-types. 320 6. References 322 6.1. Normative References 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, 326 DOI 10.17487/RFC2119, March 1997, 327 . 329 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 330 Thyagarajan, "Internet Group Management Protocol, Version 331 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 332 . 334 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 335 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 336 DOI 10.17487/RFC3810, June 2004, 337 . 339 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 340 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 341 May 2017, . 343 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 344 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 345 Explicit Replication (BIER)", RFC 8279, 346 DOI 10.17487/RFC8279, November 2017, 347 . 349 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 350 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 351 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 352 2019, . 354 6.2. Informative References 356 [I-D.ietf-bier-mld] 357 Pfister, P., Wijnands, I., Venaas, S., Wang, C., Zhang, 358 Z., and M. Stenberg, "BIER Ingress Multicast Flow Overlay 359 using Multicast Listener Discovery Protocols", draft-ietf- 360 bier-mld-02 (work in progress), July 2019. 362 Authors' Addresses 363 Mahesh Sivakumar 364 Juniper Networks 365 64 Butler St 366 Milpitas CA 95035 367 USA 369 Email: sivakumar.mahesh@gmail.com 371 Stig Venaas 372 Cisco Systems, Inc. 373 Tasman Drive 374 San Jose CA 95134 375 USA 377 Email: stig@cisco.com 379 Zheng(Sandy) Zhang 380 ZTE Corporation 381 No. 50 Software Ave, Yuhuatai Distinct 382 Nanjing 210000 383 China 385 Email: zhang.zheng@zte.com.cn