draft-ietf-pim-igmp-mld-extension-01.txt   draft-ietf-pim-igmp-mld-extension-02.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: January 13, 2021 Z. Zhang Expires: May 6, 2021 Z. Zhang
ZTE Corporation ZTE Corporation
H. Asaeda H. Asaeda
NICT NICT
July 12, 2020 November 2, 2020
IGMPv3/MLDv2 Message Extension IGMPv3/MLDv2 Message Extension
draft-ietf-pim-igmp-mld-extension-01 draft-ietf-pim-igmp-mld-extension-02
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 January 13, 2021. This Internet-Draft will expire on May 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 2
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. Applicability and backwards compatibility . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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
skipping to change at page 9, line 4 skipping to change at page 9, line 4
IGMP and MLD implementations, host implementations in particular, IGMP and MLD implementations, host implementations in particular,
rarely change, and it expected to take a long time for them to rarely change, and it 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. defined, it may take a long time before they are supported.
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
and MLDv2 RFCs, and behave as if the extension is not present. and MLDv2 RFCs, and behave as if the extension is not present.
Implementations that support this extension MUST behave as if it is Implementations that support this extension MUST behave as if it is
not present if they support non of the extension types in an IGMP/MLD not present if they support non of the extension types in an IGMP/MLD
message. If they support at least one of the types, they will message. If they support at least one of the types, they will
process the supported types according to the type specifications, and process the supported types according to the respective type
ignore any unsupported types. specifications, and ignore any unsupported types.
It is possible that a new extension type only applies to queries, or
only reports, or there may be other specific conditions for when it
is to be used. A document defining a new type MUST specify clearly
under what conditions the new type should be used, including for
which message types. It MUST also be considered what the behavior
should be if a message is not used in the defined manner, e.g., if it
is present in a query message, when it was only expected to be used
in reports.
When defining new types, care must be taken to ensure that nodes that When defining new types, care must be taken to ensure that nodes that
support the type can co-exist with nodes that don't, on the same support the type can co-exist with nodes that don't, on the same
subnet. There could be multiple routers where only some support the subnet. There could be multiple routers where only some support the
extension, or multiple hosts where only some support the extension. extension, or multiple hosts where only some support the extension.
Or a router may support it and none of the hosts, or all hosts may Or a router may support it and none of the hosts, or all hosts may
support it, but none of the routers. support it, but none of the routers. With multiple types being used,
it must also be considered that some hosts or routers may only
support some of the types, and potentially one node might support
only one type, and another node only another type.
Documents defining new types MUST have security considerations
relevant to the new types. They MUST also in addition to defining
the behavior of host and routers supporting the new types, consider
compatibility with hosts and routers on the same subnet that do not
support the new types. Further, they MUST consider whether there are
any dependencies or restrictions on combinations between the new
types and any pre-existing types.
The extension mechanism do not support IGMPv1, IGMPv2 and MLDv1. As The extension mechanism do not support IGMPv1, IGMPv2 and MLDv1. As
nodes may send older version message, they would also not be able to nodes may send older version message, they would also not be able to
send messages using this extension. send messages using this extension.
5. Security Considerations 5. Security Considerations
This document extends MLD (resp. IGMP) message formats. As such, This document extends MLD (resp. IGMP) message formats. As such,
there is no impact on security or changes to the considerations in there is no impact on security or changes to the considerations in
[RFC3810] and [RFC3376]. The respective types defined using this [RFC3810] and [RFC3376]. The respective types defined using this
extension may impact security and must be considered as part of the extension may impact security and MUST be considered as part of the
respective specifications. respective specifications.
6. IANA Considerations 6. 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.
 End of changes. 9 change blocks. 
11 lines changed or deleted 31 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/