Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Message Extension
Extracted elements (17)
IGMP and MLD implementations rarely change, so adoption of this extension mechanism is expected to be slow. Defining new extension TLVs should not be taken lightly; partial support by hosts or routers on the same link and dependencies between Extension Types must be carefully considered.
Implementations that do not support the extension mechanism will ignore it as specified in RFC 3376 and RFC 3810. This extension mechanism applies only to IGMPv3 and MLDv2; it does not apply when hosts or routers send older version messages.
Future documents defining a new Extension Type MUST specify the conditions under which it should be used (including which message types) and what behavior should occur if used outside its defined context.
The extension format MUST contain at least one TLV when the extension mechanism is used.
TLV validation requires: at least one TLV present, no data in the IP payload after the last TLV, and the total Extension length MUST NOT exceed the remainder of the IP payload length. If validation fails, the entire Additional Data field MUST be ignored.
TLVs with unsupported Extension Types MUST be ignored. Type-specific validation rules are only examined after the general validation succeeds.
When this extension is used, the number of records in each Report message SHOULD be kept small enough so that the entire message, including any extension TLVs, can fit within the network MTU.
The E-bit is a previously reserved bit in IGMPv3 and MLDv2 message headers that indicates the presence of the extension. It MUST be set to 1 when the extension is present, and MUST be 0 otherwise.
The No-op TLV (Extension Type=0) is a No-Operation TLV that MUST be ignored during processing. It may be used to verify correct implementation of the extension mechanism. No alignment requirement exists, so No-op is not needed for padding.
IANA created the 'IGMP/MLD Extension Types' registry under 'Internet Group Management Protocol (IGMP) Type Numbers', with registration procedure 'IETF Review'. Type 0 is No-op, types 1-65533 are Unassigned, and types 65534-65535 are Reserved for Experimental Use.
Implementations must take care not to exceed the packet boundary when parsing TLVs, because an attacker could intentionally specify a TLV with a length exceeding the boundary. Additionally, an attacker could add a large number of minimal TLVs to increase processing cost and magnify a denial-of-service attack.
The Extension Format consists of a variable list of TLVs appended to the Additional Data section of IGMPv3/MLDv2 messages. Each TLV has a 2-octet Extension Type, 2-octet Extension Length, and variable-length Extension Value field. There is no alignment or padding between TLVs.
The IGMPv3 Query message (Type=0x11) uses the E-bit in the octet shared with Resv, S, and QRV fields to signal extension presence. The Extension field follows after all Source Addresses.
The IGMPv3 Report message (Type=0x22) uses the E-bit in the second word (shared with Reserved and Number of Group Records) to signal extension presence. The Extension field follows after all Group Records.
The MLDv2 Query message (Type=130) uses the E-bit in the octet shared with Resv, S, and QRV fields to signal extension presence. The Extension field follows after all Source Addresses.
The MLDv2 Report message (Type=143) uses the E-bit in the second word (shared with Reserved and Nr of Mcast Address Records) to signal extension presence. The Extension field follows after all Multicast Address Records.
The No-op TLV has a 2-octet No-op Type field (value 0), a 2-octet Extension Length field, and a variable-length Value field. The number of octets in the Value field MUST match the specified length.