RGMP
Click on the red underlined text to get to the source
... multicast traffic.
The RGMP protocol described in this document restricts multicast
traffic to router ports ...
... with a protocol number of 2, the same as that of IGMP. All RGMP
messages are sent with TTL 1, to destination address ...
... 4] is an example of such a protocol.
The RGMP protocol specifies operations only for IP version 4
multicast routing ...
... IP version 6 is not considered.
To keep RGMP simple, efficient and easy to implement, it is designed
for switches to expect RGMP ...
... RGMP simple, efficient and easy to implement, it is designed
for switches to expect RGMP messages from only one source per port.
For this reason, RGMP ...
... RGMP messages from only one source per port.
For this reason, RGMP only supports a single RGMP enabled router to
...
... port.
For this reason, RGMP only supports a single RGMP enabled router to
be connected directly to a port ...
... 3228 are
assigned to protocol testing and experimentation. This is not an
operational issue for RGMP itself because only RGMP packets use the
IPv4 ...
... assigned to protocol testing and experimentation. This is not an
operational issue for RGMP itself because only RGMP packets use the
IPv4 destination address ...
... routers to switches. The source IPv4
address of an RGMP packet is the sending interface IPv4 address of
...
... router. The destination IPv4 address of an RGMP
packet is 224.0.0.25. Switches supporting RGMP ...
... RGMP
packet is 224.0.0.25. Switches supporting RGMP need to listen to
packets to this group.
...
... RGMP Protocol Description ...
... RGMP Router side Protocol Description ...
... of their ports. Multicast routers use RGMP to pass such information
to the switches. Only routers ...
... RGMP on an interface periodically [Hello
Interval] sends an RGMP Hello message to the attached network to
...
... Hello message to the attached network to
indicate that it is RGMP enabled. When RGMP is disabled on a routers
...
... routers
interface, it will send out an RGMP Bye message on that interface,
indicating that it again wishes to receive IPv4 ...
... interface is RGMP enabled, a router sends an RGMP Join
message out through this interface to each group ...
... traffic for a particular
group, it sends an RGMP Leave message for the group. For robustness,
the router ...
... group to the switch. These messages are called data-triggered
RGMP Leave messages and the router SHOULD rate-limit them. The
router ...
... router SHOULD rate-limit them. The
router MAY suppress sending a data triggered RGMP Leave message if it
has a desired group that has the same MAC destination address ...
... 6] for MAC ambiguity.) Such
suppression of data triggered RGMP Leave messages SHOULD be
configurable if supported.
...
... switch enabled for RGMP on a network consumes RGMP messages
received from ports of the network ...
... ports of the network and processes them as described
below. If enabled for RGMP, the switch must NOT forward/flood
...
... timer [5 * Hello Interval] is started. This timer is restarted by
each RGMP Hello message arriving on the port. If this timer ...
... timer expires
or if it is removed by the arrival of an RGMP Bye message, then the
port reverts to its prior state ...
... IPv4 originator address of the
RGMP Hello and Bye messages it receives on that port. In the event
it receives multiple IPv4 ...
... administrator. The switch MAY also have a configuration option that
will allow for the operator to disable RGMP and have the switch fall
back to flooding ...
... potentially dangerous option.
By default, connecting two or more RGMP enabled routers to a switch
...
... multicast traffic
towards these routers. Black holing occurs when a RGMP Leave is
received from one router while the other router ...
... traffic constraining benefits
of RGMP are not realized. This suggests that congestion happens at a
much later time than the misconfiguration and can then not easily be
...
... Because routers supporting RGMP are not required to send RGMP Join or
Leave messages for groups ...
... Leave messages for groups 224.0.0.x (x=0...255), 224.0.1.39 and
224.0.1.40, RGMP enabled ports always need to receive traffic for
...
... RGMP Join and Leave messages are accepted if they arrive on an RGMP
enabled port, otherwise they will be discarded. Upon acceptance of
...
... enabled port, otherwise they will be discarded. Upon acceptance of
an RGMP Join message, the switch MUST start ...
... the group to the port. Upon acceptance of an RGMP Leave message, the
switch SHOULD stop forwarding traffic ...
... To stop forwarding of traffic to a group in the event of lost RGMP
Leave message(s), a switch MAY time out RGMP ...
... IPv4 multicast traffic restriction may also be
used on RGMP enabled ports. In this case, forwarding for a group on
...
... potential layer 2 network topology changes, RGMP does not specify how
to restrict multicast traffic on links ...
... links connecting switches amongst
each other. With just RGMP being used, multicast traffic will thus
be flooded on inter-switch ...
... switch will not flood/forward
received RGMP messages out to the inter-switch link and thus the
switch ...
... RGMP messages on ports to make
it look like an RGMP enabled router to a potential switch at the
...
... ingress ports, the traffic restriction is applied there only.
RGMP-incapable routers will receive multicast traffic for all
...
... RGMP and multicast routing protocols ...
...
One result of the simplicity of RGMP are its restrictions in
supporting specific routing protocols. The following paragraphs list
...
... traffic
for a multicast group unless it explicitly requests it via RGMP Join
messages (besides those group ranges ...
... router elected to be the DF must not be enabled for
RGMP on the network, because it unconditionally needs to forward
traffic ...
... network can not be
supported if the elected DR is running RGMP, because this DR needs to
unconditionally receive traffic ...
... traffic into
the switched network need to send RGMP Joins for the group in support
of the PIM ...
... ensure that such ports are dedicatedly connected to one system which
acts as an RGMP capable router. This is also the recommended
configuration to best leverage the benefits of the RGMP ...
... RGMP capable router. This is also the recommended
configuration to best leverage the benefits of the RGMP protocol
(e.g., avoiding unwanted third-party IPv4 ...
... RGMP specific DoS attacks arise from forged RGMP messages. If more
than one system is connected to a port of the RGMP ...
... RGMP messages. If more
than one system is connected to a port of the RGMP switch, then one
system may forge RGMP ...
... RGMP switch, then one
system may forge RGMP messages and affect the operations of the other
system(s) on the same port. This is a potential security risk ...
... physical security ensures that only one system is connected to a
RGMP capable port on a switch, then forged messages ...
... Hello message can restrict multicast data towards a
non-RGMP enabled router on the same port. This effectively
...
... port. The effect is a possible
blackholing DoS attack similar to an RGMP Hello Message except
that it does not affect all IPv4 ...
... forged messages. It will also only
affect a port if there officially is only one RGMP enabled router
connected to it (i.e., if the port ...
... RGMP Bye message can turn the port into being
RGMP-disabled. This could, indirectly, cause a DoS attack based
on the port ...
... network bandwidth of the port was provisioned with the expectation
that RGMP will suppress unwanted IPv4 multicast messages.
...
... DoS attack simply re-establishes a port behavior as
if RGMP was not configured and invalidates the benefit of RGMP.
This, however, does not introduce an issue that would not have
...
... port behavior as
if RGMP was not configured and invalidates the benefit of RGMP.
This, however, does not introduce an issue that would not have
been there without RGMP ...
... RGMP.
This, however, does not introduce an issue that would not have
been there without RGMP in the first place.
Join Message ...
... Join Message:
A forged RGMP Join message could attract undesired multicast
packets to the port ...
... multicast
packets to the port where it is received from. The effect is
similar to an RGMP Bye Message except that it does not affect all
IPv4 multicast traffic ...
... forged
messages. The message will affect a port only if there officially
is only one RGMP enabled router connected to it (i.e., if the port
...
...
This appendix is not part of the RGMP specification but is provided
for information only.
...
... bridged
ethernet networks. As such it is also a possible alternative to RGMP
for the purpose of constraining multicast traffic towards router ...
... GMRP messages. In RGMP, routers only need to send RGMP
messages and switches only need to listen to them. This protocol
...
...
o The same switch running RGMP in a backbone network will likely see
more states then running on the edge ...
... group processing
and memory requirements in RGMP more in bounds than possible in
IGMP Snooping ...
... ethernet
group address, in RGMP timer maintenance is completely optional
and there are only two states per group ...
... as layer2 switches. Extensions to support further entities are
likely easier to come by through extensions to RGMP than to
GARP/GMRP ...
... group. In addition, due to the state
simplicity of RGMP it is easy to integrate IGMP Snooping and RGMP ...
... switch
port which is one reason for its complexity. In RGMP, this
configuration is explicitly not supported: More than one router
...
... multicast traffic between
switches, another reason for its complexity. RGMP does not
explicitly support this as part of the protocol because of the
following reasons:
...
...
o It is not necessary to include this function as part of the
RGMP protocol description because switch implementations can
transparently decide to support this function (see 4.1 about
...
... switch implementations can
transparently decide to support this function (see 4.1 about
this "RGMP Spoofing").
...
... layer 3 routed network is often the
best solution, supporting RGMP-Spoofing (see section 4.1) is
another one.
...
...
This appendix is not part of the RGMP specification but is provided
for information only.
...
...
This appendix presents a discussion of possible extensions to RGMP.
Included are points on why the extensions are not included and in
addition a motivation for RGMP ...
... RGMP.
Included are points on why the extensions are not included and in
addition a motivation for RGMP in comparison to (PIM) snooping ...
... channels by
joining to G. Extending RGMP to include (S,G) Join/Leaves is
feasible. However, currently the majority of switches ...
... RGMP could easily be extended to support IPv6 by mapping the RGMP
packet format into the MLD ...
...
As discussed in Appendix B. This is probably one extension that
should be avoided. Multiple RGMP router per port are
...
... DF routers,
additional RGMP messages may be added to allow routers to indicate
that certain group ...
... routers.
As previously mentioned, RGMP was designed to be easy to implement
and to support simple layer2 switches. Implementations could also be
...
... switches beyond layer 2. If all the above possible future
extensions were to be supported by an evolution of RGMP, it would be
questionable whether such a protocol could be any less complex than
actually snooping ...
... From the perspective of protocol architecture it is certainly more
appropriate to have a separate protocol like RGMP or GARP/GMRP for
...
...
In summary, with PIM still evolving, the approach taken by RGMP is
the safest one for the immediate problems at hand, and extensions
like those listed should be considered in time for actual demand.
...