draft-ietf-mboned-embeddedrp-00.txt   draft-ietf-mboned-embeddedrp-01.txt 
mboned Working Group P. Savola mboned Working Group P. Savola
Internet Draft CSC/FUNET Internet Draft CSC/FUNET
Expiration Date: April 2004 Expiration Date: August 2004
B. Haberman B. Haberman
Caspian Networks Caspian Networks
October 2003 February 2004
Embedding the Address of RP in IPv6 Multicast Address Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
draft-ietf-mboned-embeddedrp-00.txt draft-ietf-mboned-embeddedrp-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
There exists a huge deployment problem with global, interdomain IPv6 A very difficult deployment problem with global, interdomain IPv6
multicast: Protocol Independent Multicast - Sparse Mode (PIM-SM) multicast using Protocol Independent Multicast - Sparse Mode (PIM-SM)
Rendezvous Points (RPs) have no way of communicating the information has been identified. This memo defines an address allocation policy
about multicast sources to other multicast domains, as there is no in which the address of the Rendezvous Point (RP) is encoded in the
Multicast Source Discovery Protocol (MSDP), and the whole interdomain IPv6 multicast group address. For PIM-SM, this can be seen as a
Any Source Multicast (ASM) model is rendered unusable; Source specification of a group-to-RP mapping mechanism. This allows an
Specific Multicast (SSM) avoids these problems but is not considered easy deployment of scalable inter-domain multicast, and simplifies
readily deployable at the moment. This memo defines a PIM-SM group- the intra-domain multicast configuration as well. This memo updates
to-RP mapping which encodes the address of the RP in the IPv6 the addressing format presented in RFC 3306.
multicast address. In consequence, there would be no need for
interdomain MSDP, and even intra-domain RP configuration could be
simplified. This memo updates RFC 3306.
Table of Contents Table of Contents
1. Introduction ............................................... 2 1. Introduction ............................................... 2
2. Unicast-Prefix-based Address Format ........................ 4 2. Unicast-Prefix-based Address Format ........................ 4
3. Modified Unicast-Prefix-based Address Format ............... 4 3. Modified Unicast-Prefix-based Address Format ............... 4
4. Embedding the Address of the RP in the Multicast Address ... 5 4. Embedding the Address of the RP in the Multicast Address ... 5
5. Examples ................................................... 6 5. Examples ................................................... 6
5.1. Example 1 .............................................. 6 5.1. Example 1 .............................................. 6
5.2. Example 2 .............................................. 6 5.2. Example 2 .............................................. 7
5.3. Example 3 .............................................. 6 5.3. Example 3 .............................................. 7
5.4. Example 4 .............................................. 7 5.4. Example 4 .............................................. 7
6. Operational Requirements ................................... 7 6. Operational Considerations ................................. 7
6.1. Anycast-RP ............................................. 7 6.1. RP Redundancy .......................................... 7
6.2. Guidelines for Assigning IPv6 Addresses to RPs ......... 7 6.2. RP Deployment .......................................... 8
7. Required PIM-SM Modifications .............................. 7 6.3. Guidelines for Assigning IPv6 Addresses to RPs ......... 8
7.1. Overview of the Model .................................. 9 7. PIM-SM Protocol Modifications .............................. 8
8. Scalability/Usability Analysis ............................. 9 7.1. PIM-SM Group-to-RP Mapping ............................. 9
7.2. Overview of the Model .................................. 9
8. Scalability/Usability Analysis ............................. 10
9. Acknowledgements ........................................... 11 9. Acknowledgements ........................................... 11
10. Security Considerations ................................... 11 10. Security Considerations ................................... 11
11. References ................................................ 12 11. References ................................................ 13
11.1. Normative References .................................. 12 11.1. Normative References .................................. 13
11.2. Informative References ................................ 12 11.2. Informative References ................................ 13
Authors' Addresses ............................................. 13 Authors' Addresses ............................................. 14
A. Discussion about Design Tradeoffs .......................... 13 A. Discussion about Design Tradeoffs .......................... 14
Intellectual Property Statement ................................ 14 B. Changes since -00 .......................................... 15
Full Copyright Statement ....................................... 15 Intellectual Property Statement ................................ 15
Full Copyright Statement ....................................... 16
1. Introduction 1. Introduction
As has been noticed [V6MISSUES], there exists a huge deployment As has been noticed [V6MISSUES], there exists a deployment problem
problem with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no
have no way of communicating the information about multicast sources way of communicating the information about multicast sources to other
to other multicast domains, as there is no MSDP [MSDP], and the whole multicast domains, as there is no Multicast Source Discovery Protocol
interdomain Any Source Multicast model is rendered unusable; SSM (MSDP) [MSDP] (at least yet). Therefore the whole interdomain Any
[SSM] avoids these problems. Source Multicast model is rendered unusable; Source-Specific
Multicast (SSM) [SSM] avoids these problems but is not a complete
solution for several reasons.
It has been noted that there are some problems with SSM deployment Further, it has been noted that there are some problems with the
and support: it seems unlikely that SSM could be usable as the only support and deployment of mechanisms SSM would require: it seems
interdomain multicast routing mechanism in the short term. This memo unlikely that SSM could be usable as the only interdomain multicast
proposes a fix to interdomain multicast routing, and provides an routing mechanism in the short term.
additional method for the RP discovery with the intra-domain case.
This document proposes a solution to the group-to-RP mapping problem This memo describes a multicast address allocation policy in which
which leverages and extends [RFC3306] by encoding the RP address of the address of the RP is encoded in the IPv6 multicast group address,
the IPv6 multicast group into the group address itself. and specifies a PIM-SM group-to-RP mapping to use the encoding,
leveraging and extending the unicast-prefix -based addressing
[RFC3306].
This mechanism not only provides a simple solution for IPv6 This mechanism not only provides a simple solution for IPv6
interdomain ASM but can be used as a simple solution for IPv6 interdomain Any Source Multicast (ASM) but can be used as a simple
intradomain ASM on scoped addresses, as well. The use as a substitute solution for IPv6 intradomain ASM on scoped addresses as well. It
for Bootstrap Router protocol (BSR) [BSR] is also possible. can also be used in those deployment scenarios which would have
previously used the Bootstrap Router protocol (BSR) [BSR].
The solution consists of two elements applicable to a subrange of The solution consists of three elements:
[RFC3306] IPv6 multicast group addresses which are defined by setting
one previously unused bit of the Flags field to "1": o A specification of a subrange of [RFC3306] IPv6 multicast group
addresses defined by setting one previously unused bit of the
Flags field to "1",
o A specification of the mapping by which such a group address o A specification of the mapping by which such a group address
encodes the RP address that is to be used with this group, and encodes the RP address that is to be used with this group, and
o A specification of optional and mandatory procedures to operate o A specification of optional and mandatory procedures to operate
ASM with PIM-SM on these IPv6 multicast groups. ASM with PIM-SM on these IPv6 multicast groups.
Addresses in this subrange will be called embedded-RP addresses. If Addresses in the subrange will be called embedded RP addresses. This
used in the interdomain, a mechanism similar to MSDP is not required scheme obviates the need for inter-domain MSDP, and the routers are
for these addresses and RP configuration for these addresses can be not required to include any multicast configuration, except when they
as simple as zero configuration for routers supporting this act as an RP.
specification.
It is self-evident that a 128 bit RP address can in general not be In general, a 128-bit RP address can't be embedded into a 128-bit
embedded into a 128-bit group address with space left to carry a group address with space left to carry the group identity itself. An
group identity itself. An appropriate form of encoding is thus appropriate form of encoding is thus defined, and it is assumed that
defined, and it is assumed that the Interface-ID of RPs in the the Interface-ID of RPs in the embedded RP range can be assigned to
embedded-RP range can be assigned to be specific values. be a specific value.
If these assumptions can't be followed, either operational procedures If these assumptions can't be followed, either operational procedures
and configuration must be slightly changed or this mechanism can not and configuration must be slightly changed or this mechanism can not
be used. be used.
The assignment of multicast addresses is outside the scope of this The assignment of multicast addresses is outside the scope of this
document; however, the mechanisms are very probably similar to ones document; it is up to the RP and applications to ensure that group
used with [RFC3306]. addresses are unique using some unspecified method. However, the
mechanisms are very probably similar to ones used with [RFC3306].
Similarly, RP failure management methods, such as Anycast-RP, are out
of scope for this document. These do not work without additional
specification or deployment. This is covered briefly in Section 6.1.
This memo updates the addressing format presented in RFC 3306. This memo updates the addressing format presented in RFC 3306.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Unicast-Prefix-based Address Format 2. Unicast-Prefix-based Address Format
As described in [RFC3306], the multicast address format is as As described in [RFC3306], the multicast address format is as
follows: follows:
| 8 | 4 | 4 | 8 | 8 | 64 | 32 | | 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+--------+----------------+----------+ +--------+----+----+--------+--------+----------------+----------+
|11111111|flgs|scop|reserved| plen | network prefix | group ID | |11111111|flgs|scop|reserved| plen | network prefix | group ID |
+--------+----+----+--------+--------+----------------+----------+ +--------+----+----+--------+--------+----------------+----------+
Where flgs are "0011". (The first two bits are yet undefined and Where flgs are "0011". (The first two bits are yet undefined, sent
thus zero.) as zero and ignored on receipt.)
3. Modified Unicast-Prefix-based Address Format 3. Modified Unicast-Prefix-based Address Format
This memo proposes a modification to the unicast-prefix-based address This memo specifies a modification to the unicast-prefix-based
format: address format:
1. If the second high-order bit in "flgs" is set to 1, the address 1. If the second high-order bit in "flgs" is set to 1, the address
of the RP is embedded in the multicast address, as described in of the RP is embedded in the multicast address, as described in
this memo. this memo.
2. If the second high-order bit in "flgs" was set to 1, interpret 2. If the second high-order bit in "flgs" is set to 1, interpret
the last low-order 4 bits of "reserved" field as signifying the the last low-order 4 bits of "reserved" field as signifying the
RP interface ID, as described in this memo. RP interface ID, as described in this memo.
In consequence, the address format becomes: In consequence, the address format becomes:
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+--------+----------------+----------+ +--------+----+----+----+----+--------+----------------+----------+
|11111111|flgs|scop|rsvd|RPad| plen | network prefix | group ID | |11111111|flgs|scop|rsvd|RIID| plen | network prefix | group ID |
+--------+----+----+----+----+--------+----------------+----------+ +--------+----+----+----+----+--------+----------------+----------+
+-+-+-+-+ +-+-+-+-+
flgs is a set of 4 flags: |0|R|P|T| flgs is a set of 4 flags: |0|R|P|T|
+-+-+-+-+ +-+-+-+-+
R = 1 indicates a multicast address that embeds the address of the R = 1 indicates a multicast address that embeds the address on the
PIM-SM RP. Then P MUST BE set to 1, and consequently T MUST be set RP. Then P MUST BE set to 1, and consequently T MUST be set to 1, as
to 1, as specified in [RFC3306]. specified in [RFC3306].
In the case that R = 1, the last 4 bits of previously reserved field In the case that R = 1, the last 4 bits of the previously reserved
("RPad") are interpreted as embedding the interface ID of the RP, as field are interpreted as embedding the RP interface ID ("RIID"), as
specified in this memo. specified in this memo.
R = 0 indicates a multicast address that does not embed the address R = 0 indicates a multicast address that does not embed the address
of the PIM-SM RP and follows the semantics defined in [ADDRARCH] and of the RP and follows the semantics defined in [ADDRARCH] and
[RFC3306]. In this context, the value of "RPad" has no meaning. [RFC3306]. In this context, the value of "RIID" MUST be as zero and
MUST be ignored on receipt.
4. Embedding the Address of the RP in the Multicast Address 4. Embedding the Address of the RP in the Multicast Address
The address of the RP can only be embedded in unicast-prefix -based The address of the RP can only be embedded in unicast-prefix -based
ASM addresses. ASM addresses.
To identify whether an address is a multicast address as specified in To identify whether an address is a multicast address as specified in
this memo and to be processed any further, it must satisfy all of the this memo and to be processed any further, it must satisfy all of the
below: below:
o it MUST be a multicast address and have R, P, and T flag bits set o it MUST be a multicast address and have R, P, and T flag bits set
to 1 (that is, be part of the prefix FF7::/12 or FFF::/12), to 1 (that is, be part of the prefixes FF70::/12 or FFF0::/12),
o "plen" MUST NOT be 0 (ie. not SSM), and o "plen" MUST NOT be 0 (ie. not SSM), and
o "plen" MUST NOT be greater than 64. o "plen" MUST NOT be greater than 64.
The address of the RP can be obtained from a multicast address The address of the RP can be obtained from a multicast address
satisfying the above criteria by taking the following steps: satisfying the above criteria by taking the two steps:
1. take the last 96 bits of the multicast address add 32 zero bits
at the end,
2. zero the last 128-"plen" bits, and 1. copy the first "plen" bits of the "network prefix" to a zeroed
128-bit address structure, and
2. replace the last 4 bits with the contents of "RIID".
3. replace the last 4 bits with the contents of "RPad". These two steps could be illustrated as follows:
One should note that there are several operational scenarios when | 20 bits | 4 | 8 | 64 | 32 |
[RFC3306] statement "all non-significant bits of the network prefix +---------+----+----+----------------+----------+
field SHOULD be zero" is ignored -- and why the second step, above, |xtra bits|RIID|plen| network prefix | group ID |
is necessary. This is to allow multicast address assignments to +---------+----+----+----------------+----------+
third parties which still use your RP; see example 2 below. || \\ vvvvvvvvvvv
|| ``====> copy plen bits of "network prefix"
|| +------------+------------------------+
|| | network pre| 0000000000000000000000 |
|| +------------+------------------------+
\\
``=================> copy RIID to the last 4 bits
+------------+---------------------+--+
| network pre| 0000000000000000000 |ID|
+------------+---------------------+--+
One should note that there are several operational scenarios (see
Example 2 below) when [RFC3306] statement "all non-significant bits
of the network prefix field SHOULD be zero" is ignored. This is to
allow multicast address assignments to third parties which still use
the RP associated with the network prefix.
"plen" higher than 64 MUST NOT be used as that would overlap with the "plen" higher than 64 MUST NOT be used as that would overlap with the
upper bits of multicast group-id. upper bits of multicast group-id.
The implementation MUST perform at least the same address validity When processing an encoding to get the RP address, the multicast
checks to the calculated RP address as to one received via other routers MUST perform at least the same address validity checks to the
means (like BSR [BSR] or MSDP for IPv4), to avoid e.g. the address calculated RP address as to one received via other means (like BSR
being "::" or "::1". [BSR] or MSDP for IPv4), to avoid e.g., the address being "::",
"::1", or a link-local address.
One should note that the 4 bits reserved for "RPad" set the upper One should note that the 4 bits reserved for "RIID" set the upper
bound for RPs per multicast group address; not the number of RPs in a bound for RPs for the combination of scope, network prefix, and group
subnet, PIM-SM domain or large-scale network. ID -- without varying any of these, you can have 4 bits worth of
different RPs. However, each of these is an IPv6 group address of
its own (i.e., there can be only one RP per multicast address).
5. Examples 5. Examples
Four examples of multicast address allocation and resulting group-to-
RP mappings are described here, to better illustrate the
possibilities provided by the encoding.
5.1. Example 1 5.1. Example 1
The network administrator of 3FFE:FFFF::/32 wants to set up an RP for The network administrator of 2001:DB8::/32 wants to set up an RP for
the network and all of his customers. He chooses network the network and all of his customers. (S)he chooses network
prefix=3FFE:FFFF and plen=32, and wants to use this addressing prefix=2001:DB8 and plen=32, and wants to use this addressing
mechanism. The multicast addresses he will be able to use are of the mechanism. The multicast addresses (s)he will be able to use are of
form: the form:
FF7x:y20:3FFE:FFFF:zzzz:zzzz:<group-id> FF7x:y20:2001:DB8:zzzz:zzzz:<group-id>
Where "x" is the multicast scope, "y" the interface ID of the RP Where "x" is the multicast scope, "y" the interface ID of the RP
address, and "zzzz:zzzz" will be freely assignable within the PIM-SM address, and "zzzz:zzzz" will be freely assignable within the PIM-SM
domain. In this case, the address of the PIM-SM RP would be: domain. In this case, the address of the PIM-SM RP would be:
3FFE:FFFF::y 2001:DB8::y
(and "y" could be anything from 0 to F); the address 3FFE:FFFF::y/128 (and "y" could be anything from 0 to F); the address 2001:DB8::y/128
is added as a Loopback address and injected to the routing system. is added as a Loopback address and injected to the routing system.
5.2. Example 2 5.2. Example 2
As above, the network administrator can also allocate multicast As in Example 1, the network administrator can also allocate
addresses like "FF7x:y20:3FFE:FFFF:DEAD::/80" to some of his multicast addresses like "FF7x:y20:2001:DB8:DEAD::/80" to some of his
customers within the PIM-SM domain. In this case the RP address customers within the PIM-SM domain. In this case the RP address
would still be "3FFE:FFFF::y". would still be "2001:DB8::y".
Note the second rule of deriving the RP address: the "plen" field in Note the second rule of deriving the RP address: the "plen" field in
the multicast address, (hex)20 = 32, refers to the length of "network the multicast address, 0x20 = 32, refers to the length of "network
prefix" field considered when obtaining the RP address. In this prefix" field considered when obtaining the RP address. In this
case, only the first 32 bits of the network prefix field, "3FFE:FFFF" case, only the first 32 bits of the network prefix field, "2001:DB8"
are preserved: the value of "plen" takes no stance on actual are preserved: the value of "plen" takes no stance on actual
unicast/multicast prefix lengths allocated or used in the networks, unicast/multicast prefix lengths allocated or used in the networks,
here from 3FFE:FFFF:DEAD::/48. here from 2001:DB8:DEAD::/48.
5.3. Example 3 5.3. Example 3
In the above network, the network admin sets up addresses as above, In the network of Examples 1 and 2, the network admin sets up
but an organization wants to have their own PIM-SM domain; that's addresses for use by their customers, but an organization wants to
reasonable. The organization can pick multicast addresses like have their own PIM-SM domain; that's reasonable. The organization
"FF7x:y30:3FFE:FFFF:BEEF::/80", and then their RP address would be can pick multicast addresses like "FF7x:y30:2001:DB8:BEEF::/80", and
"3FFE:FFFF:BEEF::y". then their RP address would be "2001:DB8:BEEF::y".
5.4. Example 4 5.4. Example 4
In the above networks, if the admin wants to specify the RP to be in In the above networks, if the admin wants to specify the RP to be in
a non-zero /64 subnet, he could always use something like a non-zero /64 subnet, (s)he could always use something like
"FF7x:y40:3FFE:FFFF:BEEF:FEED::/96", and then their RP address would "FF7x:y40:2001:DB8:BEEF:FEED::/96", and then their RP address would
be "3FFE:FFFF:BEEF:FEED::y". There are still 32 bits of multicast be "2001:DB8:BEEF:FEED::y". There are still 32 bits of multicast
group-id's to assign to customers and self. group-id's to assign to customers and self.
6. Operational Requirements 6. Operational Considerations
6.1. Anycast-RP This desction describes the major operational considerations for
those deploying this mechanism.
One should note that MSDP is also used, in addition to interdomain 6.1. RP Redundancy
connections between RPs, in anycast-RP [ANYCASTRP] -technique, for
sharing the state information between different RPs in one PIM-SM
domain. However, there are other propositions, like [ANYPIMRP].
Anycast-RP mechanism is incompatible with this addressing method A technique called "Anycast RP" is used within a PIM-SM domain to
unless MSDP is specified and implemented. Alternatively, another share an address and multicast state information between a set of
method for sharing state information could be used. RP's mainly for redundancy purposes. Typically, MSDP has been used
for that as well [ANYCASTRP]. There are also other approaches, like
using PIM for sharing this information [ANYPIMRP].
Anycast-RP and other possible RP failover mechanisms are outside of RP failover cannot be used with this specification without additional
the scope of this memo. mechanisms or techniques such as MSDP, PIM-SM extensions, or
anycasting the RP address in the IGP without state sharing (depending
on the redundancy requirements, this may or may not be enough,
though). However, the redundancy mechanisms are outside of the scope
of this memo.
6.2. Guidelines for Assigning IPv6 Addresses to RPs 6.2. RP Deployment
As there is no need to share inter-domain state with MSDP, each DR
connecting multicast sources could act as an RP without scalability
concerns about MSDP sessions.
This might be particularly attractive when concerned about RP
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 failover mechanisms: if the DR goes
down, the multicast transmission may not be all that interesting
anymore in any case.
Along the same lines, it's may also be desirable to distribute the RP
responsibilities to multiple RPs. As long as different RPs serve
different groups, this is is trivial: each group should map to a
different RP (or enough many different RPs that the load on one RP is
not a problem). However, load sharing one group faces the similar
challenges as Anycast-RP.
6.3. Guidelines for Assigning IPv6 Addresses to RPs
With this mechanism, the RP can be given basically any network prefix With this mechanism, the RP can be given basically any network prefix
up to /64. The interface identifier will have to be manually up to /64. The interface identifier will have to be manually
configured to match "RPad". configured to match "RIID".
RPad = 0 SHOULD NOT be used as using it would cause ambiguity with RIID = 0 SHOULD NOT be used as using it would cause ambiguity with
the Subnet-Router Anycast Address [ADDRARCH]. the Subnet-Router Anycast Address [ADDRARCH].
If an administrator wishes to use an RP address that does not conform If an administrator wishes to use an RP address that does not conform
to the addressing topology but is still from the network provider's to the addressing topology but is still from the network provider's
prefix (e.g. an additional loopback address assigned on a router), prefix (e.g., an additional loopback address assigned on a router),
that address can be injected into the routing system via a host that address can be injected into the routing system via a host
route. route.
7. Required PIM-SM Modifications 7. PIM-SM Protocol Modifications
The use of multicast addresses with embedded RP addresses requires
additional PIM-SM processing. Namely, a PIM-SM router will need to
be able to recognize the encoding and derive the RP address from the
address using the rules in section 4 and to be able to use the
embedded RP, instead of its own for multicast addresses in this
specified range.
The three key places where these modifications are used are the This section describes how PIM-SM is modified, i.e., how the group-
Designated Routers (DRs) on the receiver/sender networks, the to-RP mapping mechanism works for Embedded RP.
backbone networks, and the RPs in the domain where the embdedded
address has been derived from (see figure below).
For the foreign DRs (rtrR1, rtrR23, and rtrR4), this means sending 7.1. PIM-SM Group-to-RP Mapping
PIM-SM Join/Prune/Register messages towards the foreign RP (rtrRP_S).
Naturally, PIM-SM Register-Stop and other messages must also be
allowed from the foreign RP. DRs in the local PIM-SM domain (rtrS)
do the same.
For the RP (rtrRP_S), this means being able to recognize and validate The only PIM-SM modification required is implementing this mechanism
PIM-SM messages which use RP-embedded addressing originated from any as one group-to-RP mapping method.
DR at all.
For the other routers on the path (rtrBB), this means recognizing and The implementation will have to recognize the address format and
validating that the Join/Prune PIM-SM messages using the embedded RP derive and use the RP address using the rules in Section 4. This
addressing are on the right path towards the RP they think is in information is used at least when performing RPF lookups and when
charge of the particular address. processing Join/Prune messages, or performing Register-encapsulation.
nodeS - rtrS - rtrRP_S - rtrBB -----+--- rtrR1 - node1 To avoid loops and inconsistancies, the group-to-RP mapping specified
| | | in this memo MUST be used for all embedded RP groups (i.e., with
node2_S ---------+ | +-- rtrR23 - node2 prefix FF70::/12 or FFF0::/12).
| |
| +---- node3
|
+------------ rtrR4 - node4
In addition, the administration of the PIM-SM domains MAY have an It is worth noting that compared to the other group-to-RP mappings,
option to manually override the RP selection for the embedded RP which can be precomputed, the embedded RP mapping must be redone for
multicast addresses: the default policy SHOULD be to use the embedded every new IPv6 group address which would map to a different RP. For
RP. efficiency, the results may be cached in an implementation-specific
manner.
The extraction of the RP information from the multicast address This group-to-RP mapping mechanism must be supported by the DR
should be done during forwarding state creation. That is, if no adjacent to senders and any router on the path from any receiver to
state exists for the multicast address, PIM-SM must take the embedded the RP. It also must be supported by any router on the path from any
RP information into account when creating forwarding state. Unless sender to the RP -- in case the RP issues a Register-Stop and Joins
otherwise dictated by the administrative policy, this would result in the sources.
a receiver's DR initiating a PIM-SM Join towards the foreign RP or a
source's DR sending PIM-SM Register messages towards the foreign RP.
It should be noted that this approach removes the need to run inter- It should be noted that this approach removes the need to run inter-
domain MSDP. Multicast distribution trees in foreign networks can be domain MSDP. Multicast distribution trees in foreign networks can be
joined by issuing a PIM-SM Join/Prune/Register to the RP address joined by issuing a PIM-SM Join/Prune/Register to the RP address
encoded in the multicast address. encoded in the multicast address.
Also, the addressing model described here could be used to replace or Also, the addressing model described here could be used to replace or
augment the intra-domain Bootstrap Router mechanism (BSR), as the RP- augment the intra-domain Bootstrap Router mechanism (BSR), as the RP-
mappings can be communicated by the multicast address assignment. mappings can be derived from the application of multicast address
assignmen policies.
7.1. Overview of the Model 7.2. Overview of the Model
This section gives a high level, non-normative overview of how
Embedded RP operates, as specified in the previous section.
The steps when a receiver wishes to join a group are: The steps when a receiver wishes to join a group are:
1. A receiver finds out a group address from some means (e.g. SDR 1. A receiver finds out a group address from some means (e.g., SDR
or a web page). or a web page).
2. The receiver issues an MLD Report, joining the group. 2. The receiver issues an MLD Report, joining the group.
3. The receiver's DR will initiate the PIM-SM Join process towards 3. The receiver's DR will initiate the PIM-SM Join process towards
the RP embedded in the multicast address. the RP embedded in the multicast address.
The steps when a sender wishes to send to a group are: The steps when a sender wishes to send to a group are:
1. A sender finds out a group address from some means, whether in 1. A sender finds out a group address from some means, whether in
an existing group (e.g. SDR, web page) or in a new group (e.g. an existing group (e.g., SDR, web page) or in a new group
a call to the administrator for group assignment, use of a (e.g., a call to the administrator for group assignment, use of
multicast address assignment protocol). a multicast address assignment protocol).
2. The sender sends to the group. 2. The sender sends to the group.
3. The sender's DR will send the packets unicast-encapsulated in 3. The sender's DR will send the packets unicast-encapsulated in
PIM-SM Register-messages to the RP address encoded in the PIM-SM Register-messages to the RP address encoded in the
multicast address (in the special case that DR is the RP, such multicast address (in the special case that DR is the RP, such
sending is only conceptual). sending is only conceptual).
In both cases, the messages then go on as specified in [PIM-SM] and In fact, all the messages go as specified in [PIM-SM] -- embedded RP
other specifications (e.g. Register-Stop and/or SPT Join); there is just acts as a group-to-RP mapping mechanism; instead of obtaining
no difference in them except for the fact that the RP address is the address of the RP from local configuration or configuration
derived from the multicast address. protocols (e.g., BSR), it is derived transparently from the encoded
multicast address.
Sometimes, some information, using conventional mechanisms, about
another RP exists in the PIM-SM domain. The embedded RP SHOULD be
used by default, but there MAY be an option to switch the preference.
This is because especially when performing PIM-SM forwarding in the
transit networks, the routers must have the same notion of the RP, or
else the messages may be dropped.
8. Scalability/Usability Analysis 8. Scalability/Usability Analysis
Interdomain MSDP model for connecting PIM-SM domains is mostly Interdomain MSDP model for connecting PIM-SM domains is mostly
hierarchical. The "embedded RP address" changes this to a mostly hierarchical in configuration and deployment, but flat with regard to
flat, sender-centered, full-mesh virtual topology. information distribution. The embedded RP inter-domain model behaves
as if all of the Internet was a single PIM domain, with just one RP
This may or may not cause some effects; it may or may not be per group. So, the inter-domain multicast becomes a flat, RP-
desirable. At the very least, it makes many things much more robust centered topology. The scaling issues are be described below.
as the number of third parties is minimized. A good scalability
analysis is needed.
In some cases (especially if e.g. every home user is employing site-
local multicast), some degree of hierarchy would be highly desirable,
for scalability (e.g. to take the advantage of shared multicast
state) and administrative point-of-view.
Being able to join/send to remote RPs has security considerations
that are considered below, but it has an advantage too: every group
has a "home RP" which is able to control (to some extent) who are
able to send to the group.
One should note that the model presented here simplifies the PIM-SM Previously foreign sources sent the unicast-encapsulated data to
multicast routing model slightly by removing the RP for senders and their local RP, now they do so to the foreign RP responsible for the
receivers in foreign domains. One scalability consideration should specific group. This is especially important with large multicast
be noted: previously foreign sources sent the unicast-encapsulated groups where there are a lot of heavy senders -- particularly if
data to their local RP, now they do so to the foreign RP responsible implementations do not handle unicast-decapsulation well.
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-decapsulation
well.
This model increases the amount of Internet-wide multicast state This model increases the amount of Internet-wide multicast state
slightly: the backbone routers might end up with (*, G) and (S, G, slightly: the backbone routers might end up with (*, G) and (S, G,
rpt) state between receivers and the RP, in addition to (S, G) states rpt) state between receivers (and past receivers, for PIM Prunes) and
between the receivers and senders. Certainly, the amount of inter- the RP, in addition to (S, G) states between the receivers and
domain multicast traffic between sources and the embedded-RP will senders. Certainly, the amount of inter-domain multicast traffic
increase compared to the ASM model with MSDP; however, the domain between sources and the embedded RP will increase compared to the ASM
responsible for the RP is expected to be able to handle this. model with MSDP.
As the address of the RP is tied to the multicast address, in the The embedded RP model is practically identical in both inter-domain
case of RP failure PIM-SM BSR mechanisms cannot pick a new RP; the and intra-domain cases to the traditional PIM-SM in intra-domain. On
failover mechanisms, if used, for backup RPs are different, and the other hand, PIM-SM has been deployed (in IPv4) in inter-domain
typically would depend on sharing one address. The failover using MSDP; compared to that inter-domain model, this specification
techniques are outside of the scope of this memo. simplifies the multicast routing by removing the RP for senders and
receivers in foreign domains.
As the address of the RP is tied to the multicast address, the RP
failure management becomes more difficult, as failover or redundancy
mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be used as-is.
This described briefly in Section 6.1.
The PIM-SM specification states, "Any RP address configured or The PIM-SM specification states, "Any RP address configured or
learned MUST be a domain-wide reachable address". What this means is learned MUST be a domain-wide reachable address". What "reachable"
not clear, even without embedded-RP. However, typically this precisely means is not clear, even without embedded RP. This
statement cannot be proven especially with the foreign RPs (typically statement cannot be proven especially with the foreign RPs (one can
one can not even guarantee that the RP exists!). The bottom line is not even guarantee that the RP exists!). Instead of configuring RPs
that while traditionally the configuration of RPs and DRs was and DRs with a manual process (configuring a non-existent RP was
typically a manual process, and e.g. configuring a non-existant RP possible though rare), with this specification the hosts and users
was possible, but here the hosts and users which use multicast using multicast indirectly specify the RP themselves, lowering the
indirectly specify the RP. expectancy of the RP reachability.
Being able to join/send to remote RPs raises security concerns that
are considered separately, but it has an advantage too: every group
has a "home RP" which is able to control (to some extent) who are
able to send to the group.
A more extensive description and comparison of the inter-domain
multicast routing models (traditional ASM with MSDP, embedded RP,
SSM) and their security properties has been described in [PIMSEC].
9. Acknowledgements 9. Acknowledgements
Jerome Durand commented on an early draft of this memo. Marshall Jerome Durand commented on an early draft of this memo. Marshall
Eubanks noted an issue regarding short plen values. Tom Pusateri Eubanks noted an issue regarding short plen values. Tom Pusateri
noted problems with earlier SPT-join approach. Rami Lehtonen pointed noted problems with earlier SPT-join approach. Rami Lehtonen pointed
out issues with the scope of SA-state and provided extensive out issues with the scope of SA-state and provided extensive
commentary. Nidhi Bhaskar gave the draft a thorough review. The commentary. Nidhi Bhaskar gave the draft a thorough review.
whole MboneD working group is also acknowledged for the continued Toerless Eckert, Hugh Holbrook, and Dave Meyer provided very
support and comments. extensive feedback. The whole MboneD working group is also
acknowledged for the continued support and comments.
10. Security Considerations 10. Security Considerations
The address of the PIM-SM RP is embedded in the multicast address. The address of the RP is encoded in the multicast address. RPs may
RPs may be a good target for Denial of Service attacks -- as they are be a good target for Denial of Service attacks -- as they are a
a single point of failure (excluding failover techniques) for a single point of failure (excluding failover techniques) for a group.
group. In this way, the target would be clearly visible. However, it In this way, the target would be clearly visible. However, it could
could be argued that if interdomain multicast was to be made work be argued that if interdomain multicast was to be made to work e.g.,
e.g. with MSDP, the address would have to be visible anyway (through with MSDP, the address would have to be visible anyway (through via
via other channels, which may be more easily securable). other channels).
As any RP will have to accept PIM-SM Join/Prune/Register messages As any RP will have to accept PIM-SM Join/Prune/Register messages
from any DR, this might cause a potential DoS attack scenario. from any DR, this might cause a potential DoS attack scenario.
However, this can be mitigated by the fact that the RP can discard However, this can be mitigated by the fact that the RP can discard
all such messages for all multicast addresses that do not embed the all such messages for all multicast addresses that do not encode the
address of the RP, and if deemed important, the implementation could address of the RP, and if deemed important, the implementation could
also allow manual configuration of which multicast addresses or also allow manual configuration of which multicast addresses or
prefixes embedding the RP could be used, so that only the pre-agreed prefixes embedding the RP could be used, so that only the pre-agreed
sources could use the RP. sources could use the RP.
In a similar fashion, when a receiver joins to an RP, the DRs must In a similar fashion, when a receiver joins to an RP, the DRs must
accept similar PIM-SM messages back RPs. accept similar PIM-SM messages back from RPs.
One consequence of the usage model is that it allows Internet-wide One consequence of the embedded RP usage model is that it allows
multicast state creation (from receiver(s) in another domain to the Internet-wide multicast state creation (from receiver(s) in another
RP in another domain) compared to the domain wide state creation in domain to the RP in another domain) compared to the domain wide state
the MSDP model. creation in the traditional ASM model. However, the traditional ASM
model also requires MSDP state to propagate everywhere in inter-
domain, so the total amount of state is smaller.
One should observe that the embedded RP threat model is actually One should observe that the embedded RP threat model is actually
pretty similar to SSM; both mechanisms significantly reduce the pretty similar to SSM; both mechanisms significantly reduce the
threats at the sender side, but have new ones in the receiver side, threats at the sender side, but have new ones in the receiver side,
as any receiver can try to join any non-existant group or channel, as any receiver can try to join any non-existent group or channel,
and the local DR or RP cannot readily reject such joins (based on and the local DR or RP cannot readily reject (e.g., based on MSDP
MSDP information). information) such joins.
RPs may become a bit more single points of failure as anycast-RP RPs become single points of failure as anycast-RP mechanism is not
mechanism is not (at least immediately) available. This can be (at least immediately) available. However, some other forms of
partially mitigated by the fact that some other forms of failover are failover are still possible (see Section 6.1) and one can obtain some
still possible, and there should be less need to store state as with forms of fate-sharing properties with a proper placement of RPs (see
MSDP. Section 6.2).
The implementation MUST perform at least the same address validity The implementation MUST perform at least the same address validity
checks to the embedded RP address as to one received via other means checks to the embedded RP address as to one received via other means
(like BSR or MSDP), to avoid the address being e.g. "::" or "::1". (like BSR or MSDP), to avoid the address being e.g., "::", "::1", or
a link-local address.
A more extensive description and comparison of the inter-domain
multicast routing models (traditional ASM with MSDP, embedded RP,
SSM) and their security properties has been described in [PIMSEC].
11. References 11. References
11.1. Normative References 11.1. Normative References
[ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing [ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC3513, April 2003. Architecture", RFC3513, April 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3306] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 [RFC3306] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6
Multicast Addresses", RFC3306, August 2002. Multicast Addresses", RFC3306, August 2002.
11.2. Informative References 11.2. Informative References
[ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and [ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and
MSDP", RFC 3446, January 2003. MSDP", RFC 3446, January 2003.
[ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM", [ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM",
work-in-progress, draft-farinacci-pim-anycast-rp-00.txt, work-in-progress, draft-ietf-pim-anycast-rp-00.txt,
January 2003. November 2003.
[BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for [BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for
PIM Sparse Mode", work-in-progress, draft-ietf-pim-sm- PIM Sparse Mode", work-in-progress, draft-ietf-pim-sm-
bsr-03.txt, February 2003. bsr-03.txt, February 2003.
[MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Sourc [MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Source
Discovery Protocol (MSDP)", work-in-progress, Discovery Protocol (MSDP)", RFC 3618, October 2003.
draft-ietf-msdp-spec-20.txt, May 2003.
[PIMSEC] Savola, P., Lehtonen, R., Meyer, D., "PIM-SM Multicast
Routing Security Issues and Enhancements",
work-in-progress, draft-savola-mboned-mroutesec-00.txt,
January 2004.
[PIM-SM] Fenner, B. et al, "Protocol Independent Multicast - [PIM-SM] Fenner, B. et al, "Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol Specification (Revised), Sparse Mode (PIM-SM): Protocol Specification (Revised),
work-in-progress, draft-ietf-pim-sm-v2-new-08.txt, work-in-progress, draft-ietf-pim-sm-v2-new-08.txt,
October 2003. October 2003.
[SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP",
work-in-progress, draft-ietf-ssm-arch-03.txt, work-in-progress, draft-ietf-ssm-arch-04.txt,
May 2003. October 2003.
[V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", [V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues",
work-in-progress, draft-savola-v6ops-multicast- work-in-progress, draft-savola-v6ops-multicast-
issues-02.txt, October 2003. issues-02.txt, October 2003.
Authors' Addresses Authors' Addresses
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo, Finland Espoo, Finland
skipping to change at page 13, line 21 skipping to change at page 14, line 21
Brian Haberman Brian Haberman
Caspian Networks Caspian Networks
One Park Drive, Suite 300 One Park Drive, Suite 300
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
EMail: brian@innovationslab.net EMail: brian@innovationslab.net
Phone: +1-919-949-4828 Phone: +1-919-949-4828
A. Discussion about Design Tradeoffs A. Discussion about Design Tradeoffs
The initial thought was to use only SPT join from local RP/DR to One could argue that there should be more RPs than the 4-bit "RIID"
foreign RP, rather than a full PIM Join to foreign RP. However, this
turned out to be problematic, as this kind of SPT joins where
disregarded because the path had not been set up before sending them.
A full join to foreign PIM domain is a much clearer approach.
One could argue that there should be more RPs than the 4-bit "RPad"
allows for, especially if anycast-RP cannot be used. In that light, allows for, especially if anycast-RP cannot be used. In that light,
extending "RPad" to take full advantage of whole 8 bits would seem extending "RIID" to take full advantage of whole 8 bits would seem
reasonable. However, this would use up all of the reserved bits, and reasonable. However, this would use up all of the reserved bits, and
leave no room for future flexibility. In case of large number of leave no room for future flexibility. In case of large number of
RPs, an operational workaround could be to split the PIM domain: for RPs, an operational workaround could be to split the PIM domain: for
example, using two /33's instead of one /32 would gain another 16 (or example, using two /33's instead of one /32 would gain another 16 (or
15, if zero is not used) RP addresses. Note that the limit of 4 bits 15, if zero is not used) RP addresses. Note that the limit of 4 bits
worth of RPs just depends on the prefix the RP address is derived worth of RPs just depends on the prefix the RP address is derived
from; one can use multiple prefixes in a domain, and the limit of 16 from; one can use multiple prefixes in a domain, and the limit of 16
(or 15) RPs should never really be a problem. (or 15) RPs should never really be a problem.
Some hierarchy (e.g. two-level, "ISP/customer") for RPs could
possibly be added if necessary, but that would be torturing one 128
bits even more.
One particular case, whether in the backbone or in the sender's
domain, is where the regular PIM-SM RP would be X, and the embedded
RP address would be Y. This could e.g. be a result of a default all-
multicast-to-one-RP group mapping, or a local policy decision. The
embedded RP SHOULD be used by default, but there MAY be an option to
change this preference.
Values 64 < "plen" < 96 would overlap with upper bits of the Values 64 < "plen" < 96 would overlap with upper bits of the
multicast group-id; due to this restriction, "plen" must not exceed multicast group-id; due to this restriction, "plen" must not exceed
64 bits. This is in line with RFC 3306. 64 bits. This is in line with RFC 3306.
The embedded RP addressing could be used to convey other information The embedded RP addressing could be used to convey other information
(other than RP address) as well, for example, what should be the RPT (other than RP address) as well, for example, what should be the RPT
threshold for PIM-SM. These could be encoded in the RP address threshold for PIM-SM. These could be encoded in the RP address
somehow, or in the multicast group address. However, such somehow, or in the multicast group address. Whether this is a good
modifications are beyond the scope of this memo. idea is another thing. In any case, such modifications are beyond
the scope of this memo.
Some kind of rate-limiting functions, ICMP message responses, or For the cases where the RPs do not exist or are unreachable, or too
similar could be defined for the case of when the RP embedded in the much state is being generated to reach in a resource exhaustion DoS
address is not willing to serve for the specific group (or doesn't attack, some forms of rate-limiting or other mechanisms could be
even exist). Typically this would result in the datagrams getting deployed to mitigate the threats while trying not to disturb the
blackholed or rejected with ICMP. In particular, a case for legitimate usage. This has been described at more length in
"rejection" or "source quench" -like messages would be in the case [PIMSEC].
that a source keeps transmitting a huge amount of data, which is sent
to a foreign RP using Register message but is discarded if the RP
doesn't allow the source host to transmit: the RP should be able to
indicate to the DR, "please limit the amount of Register messages",
or "this source sending to my group is bogus". Note that such "kiss-
of-death" packets have an authentication problem; spoofing them could
result in an entirely different kind of Denial of Service, for
legitimate sources. One possibility here would be to specify some
form of "return routability" check for DRs and RPs; for example, if a
DR receives packets from a host to group G G (resulting in RP address
R), the DR would send only a limited amount of packets to R until it
has heard back from R (a "positive acknowledgement"). It is not
clear whether this needs to be considered or specified in more
detail.
Could this model work with bidir-PIM? Is it feasible? Not sure, not The mechanism is not usable with Bidirectional PIM without protocol
familiar enough with bidir-PIM. extensions, as pre-computing the Designated Forwarder is not
possible.
B. Changes since -00
[[ RFC-Editor: please remove before publication ]]
o Lots of editorial cleanups, or cleanups without techinical
changes.
o Reinforce the notion of Embedded RP just being a group-to-RP
mapping mechanism (causing substantive rewriting in section 7);
highlight the fact that precomputing the group-to-RP mapping is
not possible.
o Add (a bit) more text on RP redundancy and deployment tradeoffs
wrt. RPs becoming SPoF.
o Clarify the usability/scalability issues in section 8.
o Clarify the security issues in Sections 8, Security
Considerations and Appendix A, mainly by referring to a separate
document.
o Add a MUST that embedded RP mappings must be honored by
implementations.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/