draft-ietf-pim-igmp-mld-extension-03.txt   draft-ietf-pim-igmp-mld-extension-04.txt 
Network Working Group M. Sivakumar Network Working Group M. Sivakumar
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Updates: 3376, 3810 (if approved) S. Venaas Updates: 3376, 3810 (if approved) S. Venaas
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: July 19, 2021 Z. Zhang Expires: July 25, 2021 Z. Zhang
ZTE Corporation ZTE Corporation
H. Asaeda H. Asaeda
NICT NICT
January 15, 2021 January 21, 2021
IGMPv3/MLDv2 Message Extension IGMPv3/MLDv2 Message Extension
draft-ietf-pim-igmp-mld-extension-03 draft-ietf-pim-igmp-mld-extension-04
Abstract Abstract
IGMP and MLD protocols are extensible, but no extensions have been IGMP and MLD protocols are extensible, but no extensions have been
defined so far. This document provides a well-defined way of defined so far. This document provides a well-defined way of
extending IGMP and MLD, using a list of TLVs (Type, Length and extending IGMP and MLD, using a list of TLVs (Type, Length and
Value). Value).
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 19, 2021. This Internet-Draft will expire on July 25, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Extension Format . . . . . . . . . . . . . . . . . . . . . . 3 3. Extension Format . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Multicast Listener Query Extension . . . . . . . . . . . 4 3.1. Multicast Listener Query Extension . . . . . . . . . . . 4
3.2. Version 2 Multicast Listener Report Extension . . . . . . 5 3.2. Version 2 Multicast Listener Report Extension . . . . . . 5
3.3. IGMP Membership Query Extension . . . . . . . . . . . . . 6 3.3. IGMP Membership Query Extension . . . . . . . . . . . . . 6
3.4. IGMP Version 3 Membership Report Extension . . . . . . . 7 3.4. IGMP Version 3 Membership Report Extension . . . . . . . 7
4. Applicability and backwards compatibility . . . . . . . . . . 8 4. Processing the extension . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Applicability and backwards compatibility . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
In this document, we describe a generic method to extend IGMPv3 In this document, we describe a generic method to extend IGMPv3
[RFC3376] and MLDv2 [RFC3810] messages to accommodate information [RFC3376] and MLDv2 [RFC3810] messages to accommodate information
other than what is contained in the current message formats. This is other than what is contained in the current message formats. This is
done by allowing a list of TLVs (Type, Length and Value) to be used done by allowing a list of TLVs (Type, Length and Value) to be used
in the Additional Data part of IGMPv3 and MLDv2 messages. This in the Additional Data part of IGMPv3 and MLDv2 messages. This
document defines a registry for such TLVs, while other documents will document defines a registry for such TLVs, while other documents will
define the specific types and their values, and their semantics. The define the specific types and their values, and their semantics. The
extension would only be used when at least one TLV is to be added to extension would only be used when at least one TLV is to be added to
the message. This extension also applies to the lightweight versions the message. This extension also applies to the lightweight versions
of IGMPv3 and MLDv2 as defined in [RFC5790]. of IGMPv3 and MLDv2 as defined in [RFC5790].
When this extension mechanism is used, it will make use of the entire When this extension mechanism is used, it replaces the Additional
Additional Data section defined in IGMPv3/MLDv2 for TLVs. The TLV Data section defined in IGMPv3/MLDv2 for TLVs.
scheme is flexible enough to provide for any future extensions.
Additional Data is defined for query messages in IGMPv3 [RFC3376] Additional Data is defined for query messages in IGMPv3 [RFC3376]
Section 4.1.10 and MLDv2 [RFC3810] Section 5.1.12, and for report Section 4.1.10 and MLDv2 [RFC3810] Section 5.1.12, and for report
messages in IGMPv3 [RFC3376] Section 4.2.11 and MLDv2 [RFC3810] messages in IGMPv3 [RFC3376] Section 4.2.11 and MLDv2 [RFC3810]
Section 5.2.11. Section 5.2.11.
One such TLV is being defined for use in BIER IGMP/MLD overlays One such TLV is being defined for use in BIER IGMP/MLD overlays
[I-D.ietf-bier-mld]. This TLV provides BIER specific information [I-D.ietf-bier-mld]. This TLV provides BIER specific information
that only will be processed by BIER routers. that only will be processed by BIER routers.
skipping to change at page 3, line 46 skipping to change at page 3, line 46
| Extension Type n | Extension Length n | | Extension Type n | Extension Length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Value n | | Extension Value n |
. . . . . .
. . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Extension Format Figure 1: Extension Format
Extension Type: 2 octets. This identifies a particular Extension Extension Type: 2 octets. This identifies a particular Extension
Type as defined in the IGMP/MLD Extension Type Registry. Type as defined in the IGMP/MLD Extension Type Registry. If this
is not the first TLV, it will follow immediately after the end of
the previous Extension Value field, or immediately after the
previous Extension Length field if the previous Extension Length
was zero. There is no alignment or padding.
Extension Length: 2 octets. This specifies the length in octets Extension Length: 2 octets. This specifies the length in octets
of the following Extension Value field. Note that this value may of the following Extension Value field. The length may be zero if
be zero, in which case there is no Extension Value field present. no value is needed.
The next type field, if any, will come immediately after this
length field.
Extension Value: This field contains the value. The length and Extension Value: This field contains the value. The length and
the contents of this field is according to the specification of the contents of this field is according to the specification of
the Extension Type as defined in the IGMP/MLD Extension Type the Extension Type as defined in the IGMP/MLD Extension Type
Registry. The length MUST be as specified in the Extension Length Registry. The length MUST be as specified in the Extension Length
field. field.
There MUST be no data in the message after the last TLV. The TLVs
are processed until the end of the message is reached. When
processing the TLVs an implementation MUST keep track of how many
octets are remaining in the message and stop TLV processing when
there is no room for any further TLVs. That is, TLV processing stops
if there are less than 4 octets remaining in the message after a TLV
is processed since there is not enough room for an additional minimal
TLV. Also if a TLV has a length exceeding the remainder of the
message, that TLV is ignored, and further TLV processing stops.
IGMPv3 and MLDv2 messages are defined so that they can fit within the IGMPv3 and MLDv2 messages are defined so that they can fit within the
network MTU, in order to avoid fragmentation. When this extension network MTU, in order to avoid fragmentation. When this extension
mechanism is used, the number of Group Records in each Report message mechanism is used, the number of Group Records in each Report message
should be kept small enough that the entire message, including any should be kept small enough that the entire message, including any
extension TLVs can fit within the network MTU. extension TLVs can fit within the network MTU.
3.1. Multicast Listener Query Extension 3.1. Multicast Listener Query Extension
The MLD query format with extension is shown below. The E-bit MUST The MLD query format with extension is shown below. The E-bit MUST
be set to 1 to indicate that the extension is present. Otherwise it be set to 1 to indicate that the extension is present. Otherwise it
skipping to change at page 8, line 40 skipping to change at page 8, line 40
. Group Record [M] . . Group Record [M] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension | | Extension |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IGMP Report Extension Figure 5: IGMP Report Extension
4. Applicability and backwards compatibility 4. Processing the extension
How to validate and process a specific type will be defined in the
respective type specifications, but prior to validating and
processing each of the types, the following general validation MUST
be done.
First one MUST check that the E-bit is set, otherwise this
specification does not apply. There MUST be no data in the IP
payload after the last TLV. To check this, one will need to walk
through each of The TLVs until there are less than four octets left
in the IP payload. If there are any octets left, validation failed.
The walk also stops and validation fails if a TLV has a length
exceeding the remainder of the IP payload. For this validation, one
only examines the content of the Extension Length fields.
If the validation failed, the entire Additional Data field MUST be
ignored as specified in IGMPv3 [RFC3376] and MLDv2 [RFC3810].
If the validation succeeded, one will proceed examining each of the
specified types and perform validation and processing of the
respective types. Unsupported types MUST be ignored; type validation
and processing proceeds as if they were not present.
5. Applicability and backwards compatibility
IGMP and MLD implementations, host implementations in particular, IGMP and MLD implementations, host implementations in particular,
rarely change, and it is expected to take a long time for them to rarely change, and it is expected to take a long time for them to
support this extension mechanism. Also as new extensions are support this extension mechanism. Also as new extensions are
defined, it may take a long time before they are supported. Due to defined, it may take a long time before they are supported. Due to
this, defining extensions should not be taken lightly, and it is this, defining extensions should not be taken lightly, and it is
crucial to consider backwards compatibility. crucial to consider backwards compatibility.
Implementations that do not support this extension mechanism will Implementations that do not support this extension mechanism will
simply ignore the extension, provided they are compliant with IGMPv3 simply ignore the extension, provided they are compliant with IGMPv3
skipping to change at page 9, line 42 skipping to change at page 10, line 19
the behavior of hosts and routers supporting the new types, consider the behavior of hosts and routers supporting the new types, consider
compatibility with hosts and routers on the same subnet that do not compatibility with hosts and routers on the same subnet that do not
support the new types. Further, they MUST consider whether there are support the new types. Further, they MUST consider whether there are
any dependencies or restrictions on combinations between the new any dependencies or restrictions on combinations between the new
types and any pre-existing types. types and any pre-existing types.
This document defines an extension mechanism only for IGMPv3 and This document defines an extension mechanism only for IGMPv3 and
MLDv2. Hence this mechanism would not apply if hosts or routers send MLDv2. Hence this mechanism would not apply if hosts or routers send
older version message. older version message.
5. Security Considerations 6. Security Considerations
This document extends IGMP and MLD message formats, allowing for a This document extends IGMP and MLD message formats, allowing for a
variable number of TLVs. Implementations must take care when parsing variable number of TLVs. Implementations must take care when parsing
the TLVs to not exceed the packet boundary, an attacker could the TLVs to not exceed the packet boundary, an attacker could
intentionally specify a TLV with a length exceeding the boundary. intentionally specify a TLV with a length exceeding the boundary.
An implementation could add a large number of minimal TLVs in a An implementation could add a large number of minimal TLVs in a
message to increase the cost of processing the message to magnify a message to increase the cost of processing the message to magnify a
Denial of Service attack. Denial of Service attack.
The respective types defined using this extension may impact security The respective types defined using this extension may impact security
and this MUST be considered as part of the respective specifications. and this MUST be considered as part of the respective specifications.
6. IANA Considerations 7. IANA Considerations
A new registry called "IGMP/MLD Extension Types" should be created A new registry called "IGMP/MLD Extension Types" should be created
with registration procedure "IETF Review" as defined in [RFC8126] with registration procedure "IETF Review" as defined in [RFC8126]
with this document as a reference. The registry should be common for with this document as a reference. The registry should be common for
IGMP and MLD and can perhaps be added to the "Internet Group IGMP and MLD and can perhaps be added to the "Internet Group
Management Protocol (IGMP) Type Numbers" section. The initial Management Protocol (IGMP) Type Numbers" section. The initial
content of the registry should be as below. content of the registry should be as below.
Type Length Name Reference Type Length Name Reference
-------------------------------------------------------------- --------------------------------------------------------------
7. References 8. Acknowledgements
7.1. Normative References The authors thank Ian Duncan, Leonard Giuliano, Jake Holland and
Zhaohui Zhang for reviewing the document and providing valuable
feedback.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>. <https://www.rfc-editor.org/info/rfc3376>.
skipping to change at page 10, line 48 skipping to change at page 11, line 33
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 9.2. Informative References
[I-D.ietf-bier-mld] [I-D.ietf-bier-mld]
Pfister, P., Wijnands, I., Venaas, S., Wang, C., Zhang, Pfister, P., Wijnands, I., Venaas, S., Wang, C., Zhang,
Z., and M. Stenberg, "BIER Ingress Multicast Flow Overlay Z., and M. Stenberg, "BIER Ingress Multicast Flow Overlay
using Multicast Listener Discovery Protocols", draft-ietf- using Multicast Listener Discovery Protocols", draft-ietf-
bier-mld-04 (work in progress), March 2020. bier-mld-04 (work in progress), March 2020.
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
 End of changes. 15 change blocks. 
35 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/