IGMPv3/MLDv2 Message Extension
Juniper Networks64 Butler StMilpitasCA 95035USAsivakumar.mahesh@gmail.comCisco Systems, Inc.Tasman DriveSan JoseCA 95134USAstig@cisco.comZTE CorporationNo. 50 Software Ave, Yuhuatai DistrictNanjing210000Chinazhang.zheng@zte.com.cnNational Institute of Information and
Communications Technology4-2-1 Nukui-KitamachiKoganei, Tokyo184-8795Japanasaeda@nict.go.jp
Routing
MulticastIGMP and MLD protocols are extensible, but no extensions
have been defined so far. This document provides a
well-defined way of extending IGMP and MLD, using a list of
TLVs (Type, Length and Value).
In this document, we describe a generic method to extend
IGMPv3 and MLDv2
messages to accommodate information 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 in the
Additional Data part of IGMPv3 and MLDv2 messages. This document defines
a registry for such TLVs, while other documents will 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 the message. This extension
also applies to the lightweight versions of IGMPv3 and MLDv2 as defined
in .
When this extension mechanism is used, it will make use of the entire Additional Data
section defined in IGMPv3/MLDv2 for TLVs. The TLV scheme is flexible enough to provide
for any future extensions.
Additional Data is defined for query messages in IGMPv3 Section 4.1.10
and MLDv2 Section 5.1.12, and for report messages in IGMPv3
Section 4.2.11 and MLDv2 Section 5.2.11.
One such TLV is being defined for use in BIER IGMP/MLD overlays .
This TLV provides BIER specific information that only will be processed by BIER routers.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and only when,
they appear in all capitals, as shown here.
A previously reserved bit in the IGMPv3 and MLDv2 headers is used to
indicate whether this extension is used. When this extension is used,
the Additional Data of IGMPv3 and MLDv2 messages would be formatted as
follows. Note that this format contains a variable number of TLVs.
It MUST contain at least one TLV.
Extension Type: 2 octets. This identifies a particular Extension
Type as defined in the IGMP/MLD Extension Type Registry.
Extension Length: 2 octets. This specifies the length in octets of
the following Extension Value field. Note that this value may be zero,
in which case there is no Extension Value field present. The next type
field, if any, will come immediately after this length field.
Extension Value: This field contains the value. The length and the
contents of this field is according to the specification of the
Extension Type as defined in the IGMP/MLD Extension Type Registry.
The length MUST be as specified in the Extension Length 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 network MTU, in order
to avoid fragmentation. When this extension mechanism is used, the number of Group Records
in each Report message should be kept small enough that the entire message, including any
extension TLVs can fit within the network MTU.
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
MUST be 0.
The MLD report format with extension is shown below. The E-bit
MUST be set to 1 to indicate that the extension is present. Otherwise it
MUST be 0.
The IGMP query format with the extension is shown below. The E-bit
MUST be set to 1 to indicate that the extension is present. Otherwise it
MUST be 0.
The IGMP report format with the extension is shown below. The E-bit
MUST be set to 1 to indicate that the extension is present. Otherwise it
MUST be 0.
IGMP and MLD implementations, host implementations in particular,
rarely change, and it is expected to take a long time for them to support
this extension mechanism. Also as new extensions are defined, it may
take a long time before they are supported. Due to this, defining
extensions should not be taken lightly, and it is crucial to consider
backwards compatibility.Implementations that do not
support this extension mechanism will simply ignore the extension,
provided they are compliant with IGMPv3 and MLDv2 RFCs, which specify
that additional data must be ignored, and behave as
if the extension is not present. Implementations that support this
extension MUST behave as if it is not present if they support none of the
extension types in an IGMP/MLD message. If they support at least one of
the types, they will process the supported types according to the
respective type specifications, and ignore any unsupported types.
It is possible that a new extension type only applies to queries, or
only to 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
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 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 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 hosts 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.
This document defines an extension mechanism only for IGMPv3 and MLDv2. Hence this mechanism
would not apply if hosts or routers send older version message.This document extends IGMP and MLD message formats, allowing for a
variable number of TLVs. Implementations must take care when parsing
the TLVs to not exceed the packet boundary, an attacker could
intentionally specify a TLV with a length exceeding the boundary.
An implementation could add a large number of minimal TLVs in a
message to increase the cost of processing the message to magnify
a Denial of Service attack.
The respective types defined using this extension may impact security
and this MUST be considered as part of the respective specifications.
A new registry called "IGMP/MLD Extension Types" should be created
with registration procedure "IETF Review" as defined in
with this document as a reference.
The registry should be common for IGMP and MLD and can perhaps be added
to the "Internet Group Management Protocol (IGMP) Type Numbers" section.
The initial content of the registry should be as below.