RFC 9166: A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping
- H. Zhao,
- X. Liu,
- Y. Liu,
- A. Peter,
- M. Sivakumar
Abstract
This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping devices. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA).¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
This document defines a YANG [RFC7950] data model for the management of IGMP and MLD snooping [RFC4541] devices.¶
The YANG module in this document conforms to the NMDA defined in [RFC8342]. The NMDA adds the ability to inspect the current operational values for configuration, allowing clients to use identical paths for retrieving the configured values and the operational values.¶
1.1. Terminology
The terminology for describing YANG data models is found in [RFC6020] and [RFC7950], including:¶
The following terminologies are used in this document:¶
- mrouter:
- multicast router, which is a router that has multicast routing enabled [RFC4286].¶
- mrouter interfaces:
- snooping switch ports where multicast routers are attached [RFC4541].¶
The following abbreviations are used in this document and defined model:¶
1.2. Tree Diagrams
Tree diagrams used in this document follow the notation defined in [RFC8340].¶
1.3. Prefixes in Data Node Names
In this document, names of data nodes, actions, and other data model objects are often used without a prefix, as long as it is clear from the context in which YANG module each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1.¶
2. Design of Data Model
An IGMP/MLD snooping switch [RFC4541] analyzes IGMP/MLD packets and sets up forwarding tables for multicast traffic. If a switch does not run IGMP/MLD snooping, multicast traffic will be flooded in the broadcast domain. If a switch runs IGMP/MLD snooping, multicast traffic will be forwarded based on the forwarding tables to avoid wasting bandwidth. The IGMP/MLD snooping switch does not need to run any of the IGMP/MLD protocols. Because the IGMP/MLD snooping is independent of the IGMP/MLD protocols, the data model defined in this document does not augment, or even require, the IGMP/MLD data model defined in [RFC8652]. The model covers considerations for IGMP and MLD snooping switches [RFC4541].¶
IGMP and MLD snooping switches do not adhere to the conceptual model that provides the strict separation of functionality between different communications layers in the ISO model and instead utilize information in the upper-level protocol headers as factors to be considered in processing at the lower levels [RFC4541].¶
IGMP snooping switches utilize IGMP and could support IGMPv1 [RFC1112], IGMPv2 [RFC2236], and IGMPv3 [RFC3376]. MLD snooping switches utilize MLD and could support MLDv1 [RFC2710] and MLDv2 [RFC3810]. The goal of this document is to define a data model that provides a common user interface to IGMP and MLD snooping.¶
2.1. Overview
The YANG module on IGMP and MLD snooping defined in this document has all the common building blocks for the IGMP and MLD snooping switches.¶
The YANG module includes an IGMP and MLD snooping instance definition that uses the instance in the L2 service type of bridge [dot1Qcp]. It also includes actions for clearing IGMP and MLD snooping group tables.¶
The YANG module doesn't cover L2VPN, which will be specified in a separate document.¶
2.2. Optional Capabilities
This model is designed to represent the basic capability subsets of IGMP and MLD snooping. The main design goals of this document are that the basic capabilities described in the model are supported by any major now-existing implementation and that the configuration of all implementations meeting the specifications is easy to express through some combination of the optional features in the model and simple vendor augmentations.¶
There is also value in widely supported features being standardized to provide a standardized way to access these features, to save work for individual vendors, and to ensure that mapping between different vendors' configuration is not needlessly complicated. Therefore, this model declares a number of features representing capabilities that not all deployed devices support.¶
The extensive use of feature declarations should also substantially
simplify the capability negotiation process for a vendor's IGMP and MLD
snooping implementations
On the other hand, operational state parameters are not so widely designated as features, as there are many cases where the defaulting of an operational state parameter would not cause any harm to the system, and it is much more likely that an implementation without intrinsic support for a piece of operational state would be able to derive a suitable value for a state variable that is not intrinsically supported.¶
2.3. Position of Address Family in Hierarchy
IGMP snooping only supports IPv4, while MLD snooping only supports IPv6. The data model defined in this document can be used for both IPv4 and IPv6 address families.¶
This document defines IGMP snooping and MLD snooping as separate schema branches in the structure. The benefits are:¶
3. Module Structure
This model augments the core routing data model specified in [RFC8349].¶
The "igmp
The YANG data model defined in this document conforms to the NMDA [RFC8342]. The operational state data is combined with the associated configuration data in the same hierarchy [RFC8407].¶
3.1. IGMP Snooping Instances
The YANG module ietf
All the IGMP snooping
One igmp
Currently, the value of l2-service-type in igmp
The values of bridge
The attributes under the interfaces show the statistics of IGMP snooping
3.2. MLD Snooping Instances
The YANG module ietf
All the MLD snooping
The mld
Currently, the value of l2-service-type in mld
The value of bridge
The attributes under the interfaces show the statistics of MLD snooping
3.3. Using IGMP and MLD Snooping Instances
The igmp
For the bridge service, this model augments
It also augments
The mld
3.4. IGMP and MLD Snooping Actions
IGMP and MLD snooping actions clear the specified IGMP and MLD snooping group tables. If both source X and group Y are specified, only source X from group Y in that specific instance will be cleared.¶
4. IGMP and MLD Snooping YANG Module
This module references [RFC1112], [RFC2236], [RFC2710], [RFC3376], [RFC3810], [RFC4541], [RFC5790], [RFC6636], [RFC6991], [RFC7761], [RFC8343], and [dot1Qcp].¶
5. Security Considerations
The YANG module specified in this document defines a schema for data that
is designed to be accessed via network management protocols such as NETCONF
[RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure
transport layer, and the mandatory
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
There are a number of data nodes defined in this YANG module that are
writable
Under
The subtrees under
The subtrees under
Unauthorized access to any data node of these subtrees can adversely affect the IGMP and MLD snooping subsystem of both the local device and the network. This may lead to network malfunctions, delivery of packets to inappropriate destinations, and other problems.¶
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus important
to control read access (e.g., via get, get-config, or notification) to
these data nodes. These are the subtrees and data nodes and their
sensitivity
Under
Unauthorized access to any data node of these subtrees can disclose the
operational state information of IGMP and MLD snooping on this device. The
group
Under
Some of the actions in this YANG module may be considered sensitive or
vulnerable in some network environments. The IGMP and MLD snooping YANG
module supports the "clear
6. IANA Considerations
6.1. XML Registry
This document registers the following namespace URI in the "IETF XML Registry" [RFC3688]:¶
7. References
7.1. Normative References
- [dot1Qcp]
-
IEEE, "Standard for Local and metropolitan area networks
--Bridges and Bridged Networks , IEEE Std 802.1Qcp-2018, DOI 10--Amendment 30: YANG Data Model" .1109 , , <https:///IEEESTD .2018 .8467507 ieeexplore >..ieee .org /servlet /opac ?punumber =8467505 - [RFC1112]
-
Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10
.17487 , , <https:///RFC1112 www >..rfc -editor .org /info /rfc1112 - [RFC2236]
-
Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, DOI 10
.17487 , , <https:///RFC2236 www >..rfc -editor .org /info /rfc2236 - [RFC2710]
-
Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10
.17487 , , <https:///RFC2710 www >..rfc -editor .org /info /rfc2710 - [RFC3376]
-
Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10
.17487 , , <https:///RFC3376 www >..rfc -editor .org /info /rfc3376 - [RFC3688]
-
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10
.17487 , , <https:///RFC3688 www >..rfc -editor .org /info /rfc3688 - [RFC3810]
-
Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10
.17487 , , <https:///RFC3810 www >..rfc -editor .org /info /rfc3810 - [RFC4286]
-
Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, DOI 10
.17487 , , <https:///RFC4286 www >..rfc -editor .org /info /rfc4286 - [RFC4541]
-
Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10
.17487 , , <https:///RFC4541 www >..rfc -editor .org /info /rfc4541 - [RFC5790]
-
Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, DOI 10
.17487 , , <https:///RFC5790 www >..rfc -editor .org /info /rfc5790 - [RFC6020]
-
Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10
.17487 , , <https:///RFC6020 www >..rfc -editor .org /info /rfc6020 - [RFC6241]
-
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10
.17487 , , <https:///RFC6241 www >..rfc -editor .org /info /rfc6241 - [RFC6242]
-
Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10
.17487 , , <https:///RFC6242 www >..rfc -editor .org /info /rfc6242 - [RFC6636]
-
Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks", RFC 6636, DOI 10
.17487 , , <https:///RFC6636 www >..rfc -editor .org /info /rfc6636 - [RFC6991]
-
Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10
.17487 , , <https:///RFC6991 www >..rfc -editor .org /info /rfc6991 - [RFC7761]
-
Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10
.17487 , , <https:///RFC7761 www >..rfc -editor .org /info /rfc7761 - [RFC7950]
-
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10
.17487 , , <https:///RFC7950 www >..rfc -editor .org /info /rfc7950 - [RFC8040]
-
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10
.17487 , , <https:///RFC8040 www >..rfc -editor .org /info /rfc8040 - [RFC8294]
-
Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10
.17487 , , <https:///RFC8294 www >..rfc -editor .org /info /rfc8294 - [RFC8340]
-
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10
.17487 , , <https:///RFC8340 www >..rfc -editor .org /info /rfc8340 - [RFC8341]
-
Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10
.17487 , , <https:///RFC8341 www >..rfc -editor .org /info /rfc8341 - [RFC8342]
-
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10
.17487 , , <https:///RFC8342 www >..rfc -editor .org /info /rfc8342 - [RFC8343]
-
Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10
.17487 , , <https:///RFC8343 www >..rfc -editor .org /info /rfc8343 - [RFC8349]
-
Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10
.17487 , , <https:///RFC8349 www >..rfc -editor .org /info /rfc8349 - [RFC8446]
-
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10
.17487 , , <https:///RFC8446 www >..rfc -editor .org /info /rfc8446
7.2. Informative References
- [RFC7951]
-
Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10
.17487 , , <https:///RFC7951 www >..rfc -editor .org /info /rfc7951 - [RFC8407]
-
Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10
.17487 , , <https:///RFC8407 www >..rfc -editor .org /info /rfc8407 - [RFC8652]
-
Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A. Peter, "A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD)", RFC 8652, DOI 10
.17487 , , <https:///RFC8652 www >..rfc -editor .org /info /rfc8652
Appendix A. Data Tree Example
This section contains an example of bridge service in the JSON encoding [RFC7951], containing both configuration and state data.¶
The configuration data for R1 in the above figure could be as follows:¶
The corresponding operational state data for R1 could be as follows:¶
The following action is to clear all the entries whose group address is
225.1.1.1 for igmp