idnits 2.17.1 draft-ietf-pim-igmp-mld-extension-01.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 draft header indicates that this document updates RFC3810, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3376, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3376, updated by this document, for RFC5378 checks: 1998-04-07) -- 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 (July 12, 2020) is 1376 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 313 -- Looks like a reference, but probably isn't: '2' on line 319 == Missing Reference: 'N' is mentioned on line 291, but not defined == Missing Reference: 'M' is mentioned on line 329, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-bier-mld-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 6 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 Updates: 3376, 3810 (if approved) S. Venaas 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: January 13, 2021 Z. Zhang 7 ZTE Corporation 8 H. Asaeda 9 NICT 10 July 12, 2020 12 IGMPv3/MLDv2 Message Extension 13 draft-ietf-pim-igmp-mld-extension-01 15 Abstract 17 IGMP and MLD protocols are extensible, but no extensions have been 18 defined so far. This document provides a well-defined way of 19 extending IGMP and MLD, using a list of TLVs (Type, Length and 20 Value). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 13, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 2 58 3. Extension Format . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Multicast Listener Query Extension . . . . . . . . . . . 4 60 3.2. Version 2 Multicast Listener Report Extension . . . . . . 5 61 3.3. IGMP Membership Query Extension . . . . . . . . . . . . . 6 62 3.4. IGMP Version 3 Membership Report Extension . . . . . . . 7 63 4. Applicability and backwards compatibility . . . . . . . . . . 8 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 7.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 allowing a list of TLVs (Type, Length and Value) to be used 77 in the Additional Data part of IGMPv3 and MLDv2 messages. This 78 document defines a registry for such TLVs, while other documents will 79 define the specific types and their values, and their semantics. The 80 extension would only be used when at least one TLV is to be added to 81 the message. This extension also applies to the lightweight versions 82 of IGMPv3 and MLDv2 as defined in [RFC5790]. 84 The extension will be part of additional data as mentioned in 85 [RFC3810] Section 5.1.12 (resp. [RFC3376] Section 4.1.10) for query 86 messages and [RFC3810] Section 5.2.12 (resp. [RFC3376] 87 Section 4.2.11) for report messages. 89 One such TLV is being defined in [I-D.ietf-bier-mld] 91 2. Conventions used in this document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in BCP 96 14 [RFC2119] [RFC8174] when, and only when, they appear in all 97 capitals, as shown here. 99 3. Extension Format 101 A previously reserved bit in the IGMPv2 and MLDv2 headers is used to 102 indicate whether this extension is used. It is set to 1 if it is 103 used, otherwise 0. When this extension is used, the Additional Data 104 of IGMPv3 and MLDv2 messages would be formatted as follows. Note 105 that this format contains a variable number of TLVs. It MUST contain 106 at least one TLV. 108 0 1 2 3 109 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 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Reserved | Total Extension Length | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Extension Type 1 | Extension Length 1 | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Extension Value 1 | 116 . . . 117 . . . 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Extension Type 2 | Extension Length 2 | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Extension Value 2 | 122 . . . 123 . . . 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Extension Type n | Extension Length n | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Extension Value n | 128 . . . 129 . . . 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 Figure 1: Extension Format 134 Reserved: 2 octets. Reserved. MUST be set to 0. MUST be ignored 135 when received. 137 Total Extension Length: 2 octets. The remaining length of the 138 extension. This value MUST be equal to ((2 + 2) * n) + Extension 139 Length 1 + Extension Length 2 + ... Extension Length n. That is, 140 it is the sum of the lenghts of all the TLVs, including the type 141 field (2 octets), and the length field (2 octets) of each TLV. 142 The total number of octets used by the extension is the value of 143 this field plus 4 (including the 2 octets Reserved field and the 2 144 octets of this field). 146 Extension Type: 2 octets. This identifies a particular Extension 147 Type as defined in the IGMP/MLD Extension Type Registry. 149 Extension Length: 2 octets. This specifies the length in octets 150 of the following Extension Value field. 152 Extension Value: This field contains the value. The length and 153 the contents of this field is according to the specification of 154 the Extension Type as defined in the IGMP/MLD Extension Type 155 Registry. The length MUST be as specified in the Extension Length 156 field. 158 Note that there may be additional data following this extension. The 159 Total Extension Length field would indicate where this extension 160 ends, and the additional data starts. Also, there is a possibility 161 that an implementation uses the Additional Data part of IGMP/MLD 162 messages, but not according to this extension scheme. When a message 163 is received, it MUST be verified that the Total Extension Length is 164 equal to ((2 + 2) * n) + Extension Length 1 + Extension Length 2 + 165 ... Extension Length n, where n is the number of TLVs. Note that the 166 value of n is not known ahead of time. An implementation would walk 167 through the TLVs and add the 4 octet overhead and the length of each 168 TLV, until the sum is larger or equal to the Total Extension Length, 169 or until the end of the IGMP/MLD message, whichever happens first. 170 Any additional data after this MUST be ignored, except the data MUST 171 be included in checksum computations. If the sum is not equal to the 172 Total Extension Length, then it is assumed that this extension is not 173 being used, and this specification does not apply. 175 3.1. Multicast Listener Query Extension 177 The MLD query format with extension is shown below. The E-bit is set 178 to 1 to indicate that the extension is present. 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Type = 130 | Code | Checksum | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Maximum Response Code | Reserved | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | | 188 * * 189 | | 190 * Multicast Address * 191 | | 192 * * 193 | | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 |E| Resv|S| QRV | QQIC | Number of Sources (N) | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | | 198 * * 199 | | 200 * Source Address [1] * 201 | | 202 * * 203 | | 204 +- -+ 205 | | 206 * * 207 | | 208 * Source Address [2] * 209 | | 210 * * 211 | | 212 +- . -+ 213 . . . 214 . . . 215 +- -+ 216 | | 217 * * 218 | | 219 * Source Address [N] * 220 | | 221 * * 222 | | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Extension | 225 ~ ~ 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Figure 2: MLD Query Extension 230 3.2. Version 2 Multicast Listener Report Extension 232 The MLD report format with extension is shown below. The E-bit is 233 set to 1 to indicate that the extension is present. 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type = 143 | Reserved | Checksum | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 |E| Reserved |Nr of Mcast Address Records (M)| 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | 243 . . 244 . Multicast Address Record [1] . 245 . . 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | | 249 . . 250 . Multicast Address Record [2] . 251 . . 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | . | 255 . . . 256 | . | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | | 259 . . 260 . Multicast Address Record [M] . 261 . . 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Extension | 265 ~ ~ 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 3: MLD Report Extension 270 3.3. IGMP Membership Query Extension 272 The IGMP query format with the extension is shown below. The E-bit 273 is set to 1 to indicate that the extension is present. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Type = 0x11 | Max Resp Code | Checksum | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Group Address | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 |E| Resv|S| QRV | QQIC | Number of Sources (N) | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Source Address [1] | 285 +- -+ 286 | Source Address [2] | 287 +- . -+ 288 . . . 289 . . . 290 +- -+ 291 | Source Address [N] | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Extension | 294 ~ ~ 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Figure 4: IGMP Query Extension 299 3.4. IGMP Version 3 Membership Report Extension 301 The IGMP report format with the extension is shown below. The E-bit 302 is set to 1 to indicate that the extension is present. 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type = 0x22 | Reserved | Checksum | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 |E| Reserved | Number of Group Records (M) | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | | 312 . . 313 . Group Record [1] . 314 . . 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | 318 . . 319 . Group Record [2] . 320 . . 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | . | 324 . . . 325 | . | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | 328 . . 329 . Group Record [M] . 330 . . 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Extension | 334 ~ ~ 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 5: IGMP Report Extension 339 4. Applicability and backwards compatibility 341 IGMP and MLD implementations, host implementations in particular, 342 rarely change, and it expected to take a long time for them to 343 support this extension mechanism. Also as new extensions are 344 defined, it may take a long time before they are supported. 345 Implementations that do not support this extension mechanism will 346 simply ignore the extension, provided they are compliant with IGMPv3 347 and MLDv2 RFCs, and behave as if the extension is not present. 348 Implementations that support this extension MUST behave as if it is 349 not present if they support non of the extension types in an IGMP/MLD 350 message. If they support at least one of the types, they will 351 process the supported types according to the type specifications, and 352 ignore any unsupported types. 354 When defining new types, care must be taken to ensure that nodes that 355 support the type can co-exist with nodes that don't, on the same 356 subnet. There could be multiple routers where only some support the 357 extension, or multiple hosts where only some support the extension. 358 Or a router may support it and none of the hosts, or all hosts may 359 support it, but none of the routers. 361 The extension mechanism do not support IGMPv1, IGMPv2 and MLDv1. As 362 nodes may send older version message, they would also not be able to 363 send messages using this extension. 365 5. Security Considerations 367 This document extends MLD (resp. IGMP) message formats. As such, 368 there is no impact on security or changes to the considerations in 369 [RFC3810] and [RFC3376]. The respective types defined using this 370 extension may impact security and must be considered as part of the 371 respective specifications. 373 6. IANA Considerations 375 A new registry called "IGMP/MLD Extension Types" should be created 376 with registration procedure "IETF Review" as defined in [RFC8126] 377 with this document as a reference. The registry should be common for 378 IGMP and MLD and can perhaps be added to the "Internet Group 379 Management Protocol (IGMP) Type Numbers" section. The initial 380 content of the registry should be as below. 382 Type Length Name Reference 383 -------------------------------------------------------------- 385 7. References 387 7.1. Normative References 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, 391 DOI 10.17487/RFC2119, March 1997, 392 . 394 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 395 Thyagarajan, "Internet Group Management Protocol, Version 396 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 397 . 399 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 400 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 401 DOI 10.17487/RFC3810, June 2004, 402 . 404 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 405 Writing an IANA Considerations Section in RFCs", BCP 26, 406 RFC 8126, DOI 10.17487/RFC8126, June 2017, 407 . 409 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 410 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 411 May 2017, . 413 7.2. Informative References 415 [I-D.ietf-bier-mld] 416 Pfister, P., Wijnands, I., Venaas, S., Wang, C., Zhang, 417 Z., and M. Stenberg, "BIER Ingress Multicast Flow Overlay 418 using Multicast Listener Discovery Protocols", draft-ietf- 419 bier-mld-04 (work in progress), March 2020. 421 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 422 Group Management Protocol Version 3 (IGMPv3) and Multicast 423 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 424 DOI 10.17487/RFC5790, February 2010, 425 . 427 Authors' Addresses 429 Mahesh Sivakumar 430 Juniper Networks 431 64 Butler St 432 Milpitas CA 95035 433 USA 435 Email: sivakumar.mahesh@gmail.com 437 Stig Venaas 438 Cisco Systems, Inc. 439 Tasman Drive 440 San Jose CA 95134 441 USA 443 Email: stig@cisco.com 444 Zheng(Sandy) Zhang 445 ZTE Corporation 446 No. 50 Software Ave, Yuhuatai District 447 Nanjing 210000 448 China 450 Email: zhang.zheng@zte.com.cn 452 Hitoshi Asaeda 453 National Institute of Information and 454 Communications Technology 455 4-2-1 Nukui-Kitamachi 456 Koganei, Tokyo 184-8795 457 Japan 459 Email: asaeda@nict.go.jp