group
Click on the red underlined text to get to the source
... address of the RP is encoded in the IPv6 multicast group address,
and specifies a PIM-SM group ...
... o A specification of a subrange of [RFC3306] IPv6 multicast group
addresses defined by setting one previously unused bit of the
Flags field ...
... Flags field to "1",
o a specification of the mapping by which such a group address
encodes the RP address ...
... encodes the RP address that is to be used with this group, and
o a description of operational procedures to operate ASM ...
... RP address can't be embedded into a 128-bit group address
with space left to carry the group identity ...
... 128-bit group address
with space left to carry the group identity itself. An appropriate
form of encoding ...
... multicast addresses is outside the scope of this
document; it is up to the RP and applications to ensure that group
addresses are unique by using some unspecified method. However, the
mechanisms are probably similar to those used with [RFC3306 ...
...
Embedded-RP behaves as if all the members of the group were intra-
domain to the information distribution. However, as it gives a
...
... |11111111|flgs|scop|reserved|plen| network prefix | group ID |
+--------+----+----+--------+----+----------------+----------+
...
... RIID|plen| network prefix | group ID |
+--------+----+----+----+----+----+----------------+----------+
+-+-+-+-+
...
... RIID|plen| network prefix | group ID |
+---------+----+----+----------------+----------+
|| \\ vvvvvvvvvvv
...
... network prefix field SHOULD be zero" is ignored. This is
to allow multicast group address allocations to be consistent with
unicast prefixes ...
... "plen" higher than 64 MUST NOT be used, as that would overlap with
the high-order bits of multicast group-id.
When processing an encoding ...
... bound for RPs for the combination of scope, network prefix, and group
ID -- without varying any of these, one can have 2^4-1 = 15 different
...
... RIID=0 is reserved, see section 6.3). However, each of these
is an IPv6 group address of its own (i.e., there can be only one RP
per multicast address ...
...
Four examples of multicast address allocation and resulting group-
to-RP mappings are described here to better illustrate the
...
... subnet, e.g., 2001:DB8:BEEF:FEED::/64.
In that case, the group addresses would be something like
"FF7x:y40:2001:DB8:BEEF:FEED::/96", and then their RP address ...
... address would
be "2001:DB8:BEEF:FEED::y". There are still 32 bits of multicast
group-ids to assign to customers and self ("y" could be anything from
1 to F, as 0 must not be used).
...
... subnet and wants to keep larger address space for
group allocations. That is, the administrator selects the least
specific part of the unicast prefix ...
... administrator selects the least
specific part of the unicast prefix, with plen=32, and the group
addresses will be from the multicast prefix:
...
... address, and there are 64 bits for group-ids or assignments. In this
case, the address of the RP ...
... RP address
configuration in the scenarios where it is desirable to have the
group addresses be consistent with the unicast prefix allocations.
...
... redundancy. In the case where the DR close to a major source for a
group acts as the RP, a certain amount of fate-sharing properties can
be obtained without using any RP ...
... RP
responsibilities to multiple RPs. As long as different RPs serve
different groups, this is trivial: each group could map to a
different RP ...
... responsibilities to multiple RPs. As long as different RPs serve
different groups, this is trivial: each group could map to a
different RP (or sufficiently many different RPs that the load on one
...
... RP (or sufficiently many different RPs that the load on one
RP is not a problem). However, load sharing challenges one group
faces are similar to those of Anycast-RP ...
... throughout the PIM domain is not necessary, as each group address
specifies the RP to be used.
...
... ("source filtering") and filtering which groups should be globally
accessible ("group filtering ...
... filtering which groups should be globally
accessible ("group filtering"). These are done to prevent local
groups ...
... group filtering"). These are done to prevent local
groups from being advertised to the outside or unauthorized senders
from creating global groups ...
... groups from being advertised to the outside or unauthorized senders
from creating global groups.
However, such controls do not yet block the outsiders from using such
...
...
However, such controls do not yet block the outsiders from using such
groups, as they could join the groups even without Source Active ...
... groups, as they could join the groups even without Source Active
advertisement with a (Source, Group ...
... groups even without Source Active
advertisement with a (Source, Group) or (S,G) Join by
guessing/learning the source and/or the group address ...
... Group) or (S,G) Join by
guessing/learning the source and/or the group address. For proper
protection, one should set up, for example, PIM multicast ...
... RP to host
his/hers own group(s). This can be mitigated to an extent by
filtering which groups ...
... group(s). This can be mitigated to an extent by
filtering which groups or group ranges are allowed at the RP ...
... The only PIM-SM modification required is implementing this mechanism
as one group-to-RP mapping method.
...
... priority than any other mechanism.
It is worth noting that compared to the other group-to-RP mapping
mechanisms, which can be precomputed, the embedded-RP ...
... RP mapping must be
redone for every new IPv6 group address that would map to a different
RP. For efficiency, the results may be cached in an implementation-
...
...
1. A receiver finds out a group address by some means (e.g., SDR or a
web page).
...
...
1. A sender finds out a group address by using an unspecified method
(e.g., by contacting the administrator ...
... method
(e.g., by contacting the administrator for group assignment or
using a multicast address assignment protocol).
...
... PIM-SM]; embedded-RP
just acts as a group-to-RP mapping mechanism. Instead of obtaining
the address ...
... RP; now they are sent to the "foreign" RP responsible
for the specific group. This is especially important with large
multicast groups where there are a lot of heavy senders ...
... for the specific group. This is especially important with large
multicast groups where there are a lot of heavy senders --
particularly if implementations do not handle unicast ...
... join/send to remote RPs raises security concerns that
are considered separately, but it has an advantage too: every group
has a "responsible RP" that is able to control (to some extent) who
...
... has a "responsible RP" that is able to control (to some extent) who
is able to send to the group.
A more extensive description and comparison ...
... Narten, and Alex Zinin provided substantive comments during the IESG
evaluation. The whole MboneD working group is also acknowledged for
continued support and comments.
...
... prefixes are allowed to be used.
This can be used to limit the use of the RP to designated groups
only. In some cases, being able to restrict (at the RP) which
...
... unicast addresses are allowed to send or join to a group is
desirable. (However, note that Join/Prune ...
... router could potentially become an RP (and be abused
as such). Further, multicast groups or group ranges to-be-served MAY
...
... RP (and be abused
as such). Further, multicast groups or group ranges to-be-served MAY
need to be explicitly configured at the RPs, to protect them from
...
... "insider-must-create" or "invite-outsiders" models) as to who is
allowed to use the groups are beyond the scope of this memo.
Excluding internal-only groups ...
... groups are beyond the scope of this memo.
Excluding internal-only groups from MSDP advertisements does not
protect the groups ...
... groups from MSDP advertisements does not
protect the groups from outsiders but only offers security by
obscurity; embedded-RP offers similar level of protection ...
... Values 64 < "plen" < 96 would overlap with upper bits of the
multicast group-id; due to this restriction, "plen" must not exceed
64 bits. This is in line with RFC 3306prop ...
... encoded in the RP address somehow, or in the multicast group address.
In any case, such modifications are beyond the scope of this memo.
...