idnits 2.17.1 draft-ietf-pim-igmp-mld-extension-05.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 date (7 November 2021) is 872 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 293 -- Looks like a reference, but probably isn't: '2' on line 299 == Missing Reference: 'N' is mentioned on line 270, but not defined == Missing Reference: 'M' is mentioned on line 309, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 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: 11 May 2022 Cisco Systems, Inc. 6 Z. Zhang 7 ZTE Corporation 8 H. Asaeda 9 NICT 10 7 November 2021 12 Internet Group Management Protocol version 3 (IGMPv3) and Multicast 13 Listener Discovery version 2 (MLDv2) Message Extension 14 draft-ietf-pim-igmp-mld-extension-05 16 Abstract 18 This document specifies a generic mechanism to extend IGMPv3 and 19 MLDv2 by using a list of TLVs (Type, Length and Value). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 11 May 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions used in this document . . . . . . . . . . . . . . 3 56 3. Extension Format . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Multicast Listener Query Extension . . . . . . . . . . . 4 58 3.2. Version 2 Multicast Listener Report Extension . . . . . . 5 59 3.3. IGMP Membership Query Extension . . . . . . . . . . . . . 6 60 3.4. IGMP Version 3 Membership Report Extension . . . . . . . 7 61 4. Processing the extension . . . . . . . . . . . . . . . . . . 8 62 5. Applicability and backwards compatibility . . . . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 68 9.2. Informative References . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 This document defines a generic method to extend IGMPv3 [RFC3376] and 74 MLDv2 [RFC3810] messages to accommodate information other than what 75 is contained in the current message formats. This is done by 76 allowing a list of TLVs (Type, Length and Value) to be used in the 77 Additional Data part of IGMPv3 and MLDv2 messages. This document 78 defines a registry for such TLVs, while other documents will define 79 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 When this extension mechanism is used, it replaces the Additional 85 Data section defined in IGMPv3/MLDv2 for TLVs. 87 Additional Data is defined for Query messages in IGMPv3 [RFC3376] 88 Section 4.1.10 and MLDv2 [RFC3810] Section 5.1.12, and for Report 89 messages in IGMPv3 [RFC3376] Section 4.2.11 and MLDv2 [RFC3810] 90 Section 5.2.11. 92 2. Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 3. Extension Format 102 A previously reserved bit in the IGMPv3 and MLDv2 headers is used to 103 indicate whether this extension is used. When this extension is 104 used, the Additional Data of IGMPv3 and MLDv2 messages is formatted 105 as follows. Note that this format contains a variable number of 106 TLVs. It MUST contain 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 | Extension Type 1 | Extension Length 1 | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Extension Value 1 | 114 . . . 115 . . . 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Extension Type 2 | Extension Length 2 | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Extension Value 2 | 120 . . . 121 . . . 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Extension Type n | Extension Length n | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Extension Value n | 126 . . . 127 . . . 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 Figure 1: Figure 1: Extension Format 132 Extension Type: 2 octets. This identifies a particular Extension 133 Type as defined in the IGMP/MLD Extension Type Registry. If this 134 is not the first TLV, it will follow immediately after the end of 135 the previous one. There is no alignment or padding. 137 Extension Length: 2 octets. This specifies the length in octets 138 of the following Extension Value field. The length may be zero if 139 no value is needed. 141 Extension Value: This field contains the value. The length and 142 the contents of this field is according to the specification of 143 the Extension Type. 145 IGMPv3 and MLDv2 messages are defined so that they can fit within the 146 network MTU, in order to avoid fragmentation. When this extension 147 mechanism is used, the number of Group Records in each Report message 148 should be kept small enough that the entire message, including any 149 extension TLVs can fit within the network MTU. 151 3.1. Multicast Listener Query Extension 153 The MLDv2 Query Message format [RFC3810] with extension is shown 154 below. The E-bit MUST be set to 1 to indicate that the extension is 155 present. Otherwise, it MUST be 0. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Type = 130 | Code | Checksum | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Maximum Response Code | Reserved | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | | 165 * * 166 | | 167 * Multicast Address * 168 | | 169 * * 170 | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 |E| Resv|S| QRV | QQIC | Number of Sources (N) | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | | 175 * * 176 | | 177 * Source Address [1] * 178 | | 179 * * 180 | | 181 +- -+ 182 | | 183 * * 184 | | 185 * Source Address [2] * 186 | | 187 * * 188 | | 189 +- . -+ 190 . . . 191 . . . 192 +- -+ 193 | | 194 * * 195 | | 196 * Source Address [N] * 197 | | 198 * * 199 | | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Extension | 202 ~ ~ 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 2: Figure 2: MLD Query Extension 207 3.2. Version 2 Multicast Listener Report Extension 209 The MLDv2 Report Message format [RFC3810] with extension is shown 210 below. The E-bit MUST be set to 1 to indicate that the extension is 211 present. Otherwise, it MUST be 0. 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type = 143 | Reserved | Checksum | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 |E| Reserved |Nr of Mcast Address Records (M)| 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | | 221 . . 222 . Multicast Address Record [1] . 223 . . 224 | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 . . 228 . Multicast Address Record [2] . 229 . . 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | . | 233 . . . 234 | . | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 . . 238 . Multicast Address Record [M] . 239 . . 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Extension | 243 ~ ~ 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 3: Figure 3: MLD Report Extension 248 3.3. IGMP Membership Query Extension 250 The IGMPv3 Query Message format [RFC3376] with the extension is shown 251 below. The E-bit MUST be set to 1 to indicate that the extension is 252 present. Otherwise, it MUST be 0. 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Type = 0x11 | Max Resp Code | Checksum | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Group Address | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 |E| Resv|S| QRV | QQIC | Number of Sources (N) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Source Address [1] | 264 +- -+ 265 | Source Address [2] | 266 +- . -+ 267 . . . 268 . . . 269 +- -+ 270 | Source Address [N] | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Extension | 273 ~ ~ 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 4: Figure 4: IGMP Query Extension 278 3.4. IGMP Version 3 Membership Report Extension 280 The IGMPv3 Report Message format [RFC3376] with the extension is 281 shown below. The E-bit MUST be set to 1 to indicate that the 282 extension is present. Otherwise, it MUST be 0. 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Type = 0x22 | Reserved | Checksum | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 |E| Reserved | Number of Group Records (M) | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | | 292 . . 293 . Group Record [1] . 294 . . 295 | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 . . 299 . Group Record [2] . 300 . . 301 | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | . | 304 . . . 305 | . | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | 308 . . 309 . Group Record [M] . 310 . . 311 | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Extension | 314 ~ ~ 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 5: Figure 5: IGMP Report Extension 319 4. Processing the extension 321 The procedure specified in this document applies only when the E-bit 322 is set. 324 If the validation of the TLVs fails, the entire Additional Data field 325 MUST be ignored as specified in IGMPv3 [RFC3376] and MLDv2 [RFC3810]. 326 The following checks must pass for the validation of the TLVs not to 327 fail: 329 At least one TLV MUST be present. 331 There MUST NOT be any data in the IP payload after the last TLV. 332 To check this, one will need to walk through each of The TLVs 333 until there are less than four octets left in the IP payload. If 334 there are any octets left, validation fails. 336 The total length of the Extension MUST NOT exceed the remainder of 337 the IP payload length. For this validation, one only examines the 338 content of the Extension Length fields. 340 Future documents defining a new type MUST specify any additional 341 processing and validation. These rules, if any, will be examined 342 only after the general validation (above) succeeds. 344 Unsupported types MUST be ignored. 346 5. Applicability and backwards compatibility 348 IGMP and MLD implementations, host implementations in particular, 349 rarely change, and it is expected to take a long time for them to 350 support this extension mechanism. Also as new extensions are 351 defined, it may take a long time before they are supported. Due to 352 this, defining extensions should not be taken lightly, and it is 353 crucial to consider backwards compatibility. 355 Implementations that do not support this extension mechanism will 356 ignore it, as specified in [RFC3376] and [RFC3810]. 358 It is possible that a new extension type only applies to queries, or 359 only to reports, or there may be other specific conditions for when 360 it is to be used. A document defining a new type MUST specify under 361 what conditions the new type should be used, including for which 362 message types. It MUST also be specified what the behavior should be 363 if a message is not used in the defined manner, e.g., if it is 364 present in a query message, when it was only expected to be used in 365 reports. 367 When defining new types, care should be taken to consider the effect 368 of partial support for the new TLV, by either the hosts or routers, 369 on the same link. Further, it must be considered whether there are 370 any dependencies or restrictions on combinations between the new 371 types and any pre-existing types. 373 This document defines an extension mechanism only for IGMPv3 and 374 MLDv2. Hence this mechanism does not apply if hosts or routers send 375 older version messages. 377 6. Security Considerations 379 The Security Considerations of [RFC3376] and [RFC3810] also apply 380 here. 382 This document extends the IGMP and MLD message formats, allowing for 383 a variable number of TLVs. Implementations must take care when 384 parsing the TLVs to not exceed the packet boundary, an attacker could 385 intentionally specify a TLV with a length exceeding the boundary. 387 An implementation could add a large number of minimal TLVs in a 388 message to increase the cost of processing the message to magnify a 389 Denial of Service attack. 391 7. IANA Considerations 393 IANA is asked to create a new registry called "IGMP/MLD Extension 394 Types" in the "Internet Group Management Protocol (IGMP) Type 395 Numbers" section, with registration procedure "IETF Review" 396 [RFC8126], and with this document as a reference. The registry is 397 common for IGMP and MLD. The initial content of the registry should 398 be as below (empty). 400 Type Length Name Reference 401 -------------------------------------------------------------- 403 8. Acknowledgements 405 The authors thank Ian Duncan, Leonard Giuliano, Jake Holland, Alvaro 406 Retana and Zhaohui Zhang for reviewing the document and providing 407 valuable feedback. 409 9. References 411 9.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, 415 DOI 10.17487/RFC2119, March 1997, 416 . 418 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 419 Thyagarajan, "Internet Group Management Protocol, Version 420 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 421 . 423 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 424 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 425 DOI 10.17487/RFC3810, June 2004, 426 . 428 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 429 Writing an IANA Considerations Section in RFCs", BCP 26, 430 RFC 8126, DOI 10.17487/RFC8126, June 2017, 431 . 433 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 434 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 435 May 2017, . 437 9.2. Informative References 439 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 440 Group Management Protocol Version 3 (IGMPv3) and Multicast 441 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 442 DOI 10.17487/RFC5790, February 2010, 443 . 445 Authors' Addresses 447 Mahesh Sivakumar 448 Juniper Networks 449 64 Butler St 450 Milpitas, CA 95035 451 United States of America 453 Email: sivakumar.mahesh@gmail.com 455 Stig Venaas 456 Cisco Systems, Inc. 457 Tasman Drive 458 San Jose, CA 95134 459 United States of America 461 Email: stig@cisco.com 462 Zheng(Sandy) Zhang 463 ZTE Corporation 464 No. 50 Software Ave, Yuhuatai District 465 Nanjing 466 210000 467 China 469 Email: zhang.zheng@zte.com.cn 471 Hitoshi Asaeda 472 National Institute of Information and Communications Technology 473 4-2-1 Nukui-Kitamachi, 474 184-8795 475 Japan 477 Email: asaeda@nict.go.jp