draft-ietf-mboned-embeddedrp-03.txt   draft-ietf-mboned-embeddedrp-04.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
mboned Working Group P. Savola mboned Working Group P. Savola
Internet Draft CSC/FUNET Internet Draft CSC/FUNET
Expiration Date: October 2004 Expiration Date: October 2004
B. Haberman B. Haberman
Caspian Networks Caspian Networks
April 2004 April 2004
Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
draft-ietf-mboned-embeddedrp-03.txt draft-ietf-mboned-embeddedrp-04.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 2, line 11 skipping to change at page 2, line 11
mechanism. This allows an easy deployment of scalable inter-domain mechanism. This allows an easy deployment of scalable inter-domain
multicast, and simplifies the intra-domain multicast configuration as multicast, and simplifies the intra-domain multicast configuration as
well. This memo updates the addressing format presented in RFC 3306. well. This memo updates the addressing format presented in RFC 3306.
Table of Contents Table of Contents
1. Introduction ............................................... 3 1. Introduction ............................................... 3
1.1. Background ............................................. 3 1.1. Background ............................................. 3
1.2. Solution ............................................... 3 1.2. Solution ............................................... 3
1.3. Assumptions and Scope .................................. 4 1.3. Assumptions and Scope .................................. 4
1.4. Keywords ............................................... 4 1.4. Terminology ............................................ 4
2. Unicast-Prefix-based Address Format ........................ 4 2. Unicast-Prefix-based Address Format ........................ 4
3. Modified Unicast-Prefix-based Address Format ............... 5 3. Modified Unicast-Prefix-based Address Format ............... 5
4. Embedding the Address of the RP in the Multicast Address ... 6 4. Embedding the Address of the RP in the Multicast Address ... 6
5. Examples ................................................... 7 5. Examples ................................................... 7
5.1. Example 1 .............................................. 7 5.1. Example 1 .............................................. 7
5.2. Example 2 .............................................. 8 5.2. Example 2 .............................................. 7
5.3. Example 3 .............................................. 8 5.3. Example 3 .............................................. 8
5.4. Example 4 .............................................. 8 5.4. Example 4 .............................................. 8
6. Operational Considerations ................................. 8 6. Operational Considerations ................................. 9
6.1. RP Redundancy .......................................... 8 6.1. RP Redundancy .......................................... 9
6.2. RP Deployment .......................................... 9 6.2. RP Deployment .......................................... 9
6.3. Guidelines for Assigning IPv6 Addresses to RPs ......... 9 6.3. Guidelines for Assigning IPv6 Addresses to RPs ......... 9
6.4. Use as a Substitute for BSR ............................ 10 6.4. Use as a Substitute for BSR ............................ 10
7. The Embedded-RP Group-to-RP Mapping Mechanism .............. 10 6.5. Controlling the Use of RPs ............................. 10
7.1. PIM-SM Group-to-RP Mapping ............................. 10 7. The Embedded-RP Group-to-RP Mapping Mechanism .............. 11
7.2. Overview of the Model .................................. 10 7.1. PIM-SM Group-to-RP Mapping ............................. 11
8. Scalability Analysis ....................................... 11 7.2. Overview of the Model .................................. 11
9. Acknowledgements ........................................... 12 8. Scalability Analysis ....................................... 12
10. Security Considerations ................................... 13 9. Acknowledgements ........................................... 13
11. References ................................................ 14 10. Security Considerations ................................... 14
11.1. Normative References .................................. 14 11. References ................................................ 15
11.2. Informative References ................................ 14 11.1. Normative References .................................. 15
Authors' Addresses ............................................. 15 11.2. Informative References ................................ 15
A. Discussion about Design Tradeoffs .......................... 15 Authors' Addresses ............................................. 16
B. Changes .................................................... 16 A. Discussion about Design Tradeoffs .......................... 16
B.1 Changes since -02 ....................................... 16 B. Changes .................................................... 17
B.2 Changes since -01 ....................................... 16 B.3 Changes since -03 ....................................... 17
B.3 Changes since -00 ....................................... 16 B.2 Changes since -02 ....................................... 17
Intellectual Property Statement ................................ 17 B.3 Changes since -01 ....................................... 18
Full Copyright Statement ....................................... 17 B.4 Changes since -00 ....................................... 18
Intellectual Property Statement ................................ 18
Full Copyright Statement ....................................... 19
1. Introduction 1. Introduction
1.1. Background 1.1. Background
As has been noticed [V6MISSUES], there exists a deployment problem As has been noticed [V6MISSUES], there exists a deployment problem
with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no
way of communicating the information about (active) multicast sources way of communicating the information about (active) multicast sources
to other multicast domains, as Multicast Source Discovery Protocol to other multicast domains, as Multicast Source Discovery Protocol
(MSDP) [MSDP] has not been, on purpose, specified for IPv6. (MSDP) [MSDP] has not been, on purpose, specified for IPv6.
Therefore the whole interdomain Any Source Multicast model is Therefore the whole interdomain Any Source Multicast model is
rendered unusable; Source-Specific Multicast (SSM) [SSM] avoids these rendered unusable; Source-Specific Multicast (SSM) [SSM] avoids these
problems but is not a complete solution for several reasons. problems but is not a complete solution for several reasons, as noted
below.
Further, it has been noted that there are some problems with the Further, it has been noted that there are some problems with the
support and deployment of mechanisms SSM would require [V6MISSUES]: support and deployment of mechanisms SSM would require [V6MISSUES]:
it seems unlikely that SSM could be usable as the only interdomain it seems unlikely that SSM could be usable as the only interdomain
multicast routing mechanism in the short term. multicast routing mechanism in the short term.
1.2. Solution 1.2. Solution
This memo describes a multicast address allocation policy in which This memo describes a multicast address allocation policy in which
the address of the RP is encoded in the IPv6 multicast group address, the address of the RP is encoded in the IPv6 multicast group address,
skipping to change at page 4, line 10 skipping to change at page 4, line 13
Addresses in the subrange will be called embedded-RP addresses. Addresses in the subrange will be called embedded-RP addresses.
This scheme obviates the need for MSDP, and the routers are not This scheme obviates the need for MSDP, and the routers are not
required to include any multicast configuration, except when they act required to include any multicast configuration, except when they act
as an RP. as an RP.
This memo updates the addressing format presented in RFC 3306. This memo updates the addressing format presented in RFC 3306.
1.3. Assumptions and Scope 1.3. Assumptions and Scope
In general, a 128-bit RP address can't be embedded into a 128-bit A 128-bit RP address can't be embedded into a 128-bit group address
group address with space left to carry the group identity itself. An with space left to carry the group identity itself. An appropriate
appropriate form of encoding is thus defined by requiring that the form of encoding is thus defined by requiring that the Interface-IDs
Interface-IDs of RPs in the embedded-RP range can be assigned to be a of RPs in the embedded-RP range can be assigned to be a specific
specific value. 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; it is up to the RP and applications to ensure that group document; it is up to the RP and applications to ensure that group
addresses are unique using some unspecified method. However, the addresses are unique using some unspecified method. However, the
mechanisms are very probably similar to ones used with [RFC3306]. mechanisms are very probably similar to ones used with [RFC3306].
Similarly, RP failure management methods, such as Anycast-RP, are out Similarly, RP failure management methods, such as Anycast-RP, are out
of scope for this document. These do not work without additional of scope for this document. These do not work without additional
specification or deployment. This is covered briefly in Section 6.1. specification or deployment. This is covered briefly in Section 6.1.
1.4. Keywords 1.4. Terminology
Embedded-RP behaves as if all the members of the group were all
intra-domain to the information distribution. However, as it gives a
solution for the global IPv6 multicast Internet, spanning multiple
administrative domains, we say it is a solution for inter-domain
multicast.
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:
skipping to change at page 6, line 47 skipping to change at page 6, line 47
|| +------------+------------------------+ || +------------+------------------------+
|| | network pre| 0000000000000000000000 | || | network pre| 0000000000000000000000 |
|| +------------+------------------------+ || +------------+------------------------+
\\ \\
``=================> copy RIID to the last 4 bits ``=================> copy RIID to the last 4 bits
+------------+---------------------+--+ +------------+---------------------+--+
| network pre| 0000000000000000000 |ID| | network pre| 0000000000000000000 |ID|
+------------+---------------------+--+ +------------+---------------------+--+
One should note that there are several operational scenarios (see One should note that there are several operational scenarios (see
Example 2 below) when [RFC3306] statement "all non-significant bits Example 3 below) when [RFC3306] statement "all non-significant bits
of the network prefix field SHOULD be zero" is ignored. This is to of the network prefix field SHOULD be zero" is ignored. This is to
allow multicast group address allocations to be consistent with allow multicast group address allocations to be consistent with
unicast prefixes, while the multicast addresses would still use the unicast prefixes, while the multicast addresses would still use the
RP associated with the network prefix. 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
high-order bits of multicast group-id. high-order bits of multicast group-id.
When processing an encoding to get the RP address, the multicast When processing an encoding to get the RP address, the multicast
routers MUST perform at least the same address validity checks to the routers MUST perform at least the same address validity checks to the
calculated RP address as to one received via other means (like BSR calculated RP address as to one received via other means (like BSR
[BSR] or MSDP for IPv4). At least fe80::/10, ::/16, and ff00::/8 [BSR] or MSDP for IPv4). At least fe80::/10, ::/16, and ff00::/8
MUST be excluded. This is particularly important as the information MUST be excluded. This is particularly important as the information
is obtained from an untrusted source, i.e., any Internet user's is obtained from an untrusted source, i.e., any Internet user's
input. input.
One should note that the 4 bits reserved for "RIID" set the upper One should note that the 4 bits reserved for "RIID" set the upper
bound for RPs for the combination of scope, network prefix, and group bound for RPs for the combination of scope, network prefix, and group
ID -- without varying any of these, you can 2^4-1 = 15 different RPs ID -- without varying any of these, you can 2^4-1 = 15 different RPs
(as RIID=0 is reserved). However, each of these is an IPv6 group (as RIID=0 is reserved, see section 6.3). However, each of these is
address of its own (i.e., there can be only one RP per multicast an IPv6 group address of its own (i.e., there can be only one RP per
address). multicast address).
5. Examples 5. Examples
Four examples of multicast address allocation and resulting group-to- Four examples of multicast address allocation and resulting group-to-
RP mappings are described here, to better illustrate the RP mappings are described here, to better illustrate the
possibilities provided by the encoding. possibilities provided by the encoding.
5.1. Example 1 5.1. Example 1
The network administrator of 2001:DB8::/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 the customers. (S)he chooses network the network and all the customers, by placing it on an existing
prefix=2001:DB8 and plen=32, and wants to use this addressing subnet, e.g., 2001:DB8:BEEF:FEED::/64.
mechanism. The multicast addresses (s)he will be able to use are of
the form: In that case, the group addresses would be something like
"FF7x:y40:2001:DB8:BEEF:FEED::/96", and then their RP address would
be "2001:DB8:BEEF:FEED::y". There are still 32 bits of multicast
group-id's to assign to customers and self ("y" could be anything
from 1 to F, as 0 must not be used).
5.2. Example 2
As in Example 1, the network administrator of 2001:DB8::/32 wants to
set up the RP, but to make it more flexible, wants to place it on a
specifically routed subnet, and wants to keep larger address space
for group allocations. That is, the administrator selects the least
specific part of the prefix, with plen=32, and the group addresses
will be of the form:
FF7x:y20:2001:DB8: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 to anyone. In this address, and "zzzz:zzzz" will be assignable to anyone. In this case,
case, the address of the RP would be: the address of the RP would be:
2001:DB8::y 2001:DB8::y
(and "y" could be anything from 1 to F, as 0 must not be used); the The address 2001:DB8::y/128 is assigned to a router as a loopback
address 2001:DB8::y/128 is assigned to a router as a loopback address address and injected to the routing system; if the network
and injected to the routing system. administrator sets up only one or a couple of RPs (and e.g., not one
RP per subnet), this approach may be preferable to the one described
in Example 1.
5.2. Example 2 5.3. Example 3
As in Example 1, the network administrator can also allocate As in Example 2, the network administrator can also allocate
multicast addresses like "FF7x:y20:2001:DB8:DEAD::/80" to some of multicast addresses like "FF7x:y20:2001:DB8:DEAD::/80" to some of
customers. In this case the RP address would still be "2001:DB8::y". customers. In this case the RP address 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, 0x20 = 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, "2001:DB8" 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 2001:DB8:DEAD::/48. here from 2001:DB8:DEAD::/48.
In short, this distinction allows more flexible RP address In short, this distinction allows more flexible RP address
configuration in the scenarios where it is desirable to have the configuration in the scenarios where it is desirable to have the
group addresses to be consistent with the unicast prefix allocations. group addresses to be consistent with the unicast prefix allocations.
5.3. Example 3 5.4. Example 4
In the network of Examples 1 and 2, the network admin sets up In the network of Examples 1, 2 and 3, the network admin sets up
addresses for use by their customers, but an organization wants to addresses for use by their customers, but an organization wants to
have their own PIM-SM domain. The organization can pick multicast have their own PIM-SM domain. The organization can pick multicast
addresses like "FF7x:y30:2001:DB8:BEEF::/80", and then their RP addresses like "FF7x:y30:2001:DB8:BEEF::/80", and then their RP
address would be "2001:DB8:BEEF::y". address would be "2001:DB8:BEEF::y".
5.4. Example 4
In the above networks, if the administrator wants to specify the RP
to be in a non-zero /64 subnet, (s)he could always use something like
"FF7x:y40:2001:DB8:BEEF:FEED::/96", and then their RP address would
be "2001:DB8:BEEF:FEED::y". There are still 32 bits of multicast
group-id's to assign to customers and self.
6. Operational Considerations 6. Operational Considerations
This section describes the major operational considerations for those This section describes the major operational considerations for those
deploying this mechanism. deploying this mechanism.
6.1. RP Redundancy 6.1. RP Redundancy
A technique called "Anycast RP" is used within a PIM-SM domain to A technique called "Anycast RP" is used within a PIM-SM domain to
share an address and multicast state information between a set of share an address and multicast state information between a set of
RP's mainly for redundancy purposes. Typically, MSDP has been used RP's mainly for redundancy purposes. Typically, MSDP has been used
for that as well [ANYCASTRP]. There are also other approaches, like for that as well [ANYCASTRP]. There are also other approaches, like
using PIM for sharing this information [ANYPIMRP]. using PIM for sharing this information [ANYPIMRP].
RP failover cannot be used with this specification without additional The most feasible candidate for RP failover is using PIM for Anycast
mechanisms or techniques such as MSDP, PIM-SM extensions, or RP or "anycasting" (i.e., the shared-unicast model [ANYCAST]) the RP
"anycasting" (i.e., the shared-unicast model [ANYCAST]) the RP
address in the IGP without state sharing (depending on the redundancy address in the IGP without state sharing (depending on the redundancy
requirements, this may or may not be enough, though). However, the requirements, this may or may not be enough, though). However, the
redundancy mechanisms are outside of the scope of this memo. redundancy mechanisms are outside of the scope of this memo.
6.2. RP Deployment 6.2. RP Deployment
As there is no need to share inter-domain state with MSDP, each DR As there is no need to share inter-domain state with MSDP, each DR
connecting multicast sources could act as an RP without scalability connecting multicast sources could act as an RP without scalability
concerns about setting up and maintaining MSDP sessions. concerns about setting up and maintaining MSDP sessions.
This might be particularly attractive when concerned about RP This might be particularly attractive when concerned about RP
redundancy. In the case where the DR close to a major source for a 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 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 be obtained without using any RP failover mechanisms: if the DR goes
down, the multicast transmission may not work anymore in any case. down, the multicast transmission may not work anymore in any case.
Along the same lines, it's may also be desirable to distribute the RP Along the same lines, it's may also be desirable to distribute the RP
responsibilities to multiple RPs. As long as different RPs serve responsibilities to multiple RPs. As long as different RPs serve
different groups, this is is trivial: each group could map to a different groups, this is trivial: each group could map to a
different RP (or sufficiently many different RPs that the load on one different RP (or sufficiently many different RPs that the load on one
RP is not a problem). However, load sharing one group faces the RP is not a problem). However, load sharing one group faces the
similar challenges as Anycast-RP. similar challenges as Anycast-RP.
6.3. Guidelines for Assigning IPv6 Addresses to RPs 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 "RIID". configured to match "RIID".
RIID = 0 must not be used as using it would cause ambiguity with the RIID = 0 must not be used as using it would cause ambiguity with the
Subnet-Router Anycast Address [ADDRARCH]. 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, as prefix (e.g., an additional loopback address assigned on a router, as
described in example 1 in Section 5.1), that address can be injected described in example 2 in Section 5.1), that address can be injected
into the routing system via a host route. into the routing system via a host route.
6.4. Use as a Substitute for BSR 6.4. Use as a Substitute for BSR
With embedded-RP, use of BSR or other RP configuration mechanisms With embedded-RP, use of BSR or other RP configuration mechanisms
throughout the PIM domain is not necessary, as each group address throughout the PIM domain is not necessary, as each group address
specifies how the RP to be used. specifies the RP to be used.
6.5. Controlling the Use of RPs
Compared to the MSDP inter-domain ASM model, the control and
management of who can use an RP and how changes slightly and deserves
explicit discussion.
MSDP advertisement filtering typically includes at least two
capabilities: being able to filter who is able to create a global
session ("source filtering"), and being able to filter which groups
should be globally accessible ("group filtering"). These are done to
prevent local groups from being advertised to the outside, or
preventing unauthorized senders from creating global groups.
However, such controls do not yet block the outsiders from using such
groups, as they could join the groups even without Source Active
advertisement with an (S,G) Join by guessing/learning the source
and/or the group address. For proper protection, one should set up,
e.g., PIM multicast scoping borders at the border routers.
Therefore, embedded-RP has by default roughtly equivalent level of
"protection" as MSDP with SA filtering.
A new issue with control comes from the fact that nodes in a "foreign
domain" may register to an RP, or send PIM Join to an RP. (These have
been possible in the past as well, to a degree, but only through
willfull attempts or purposeful RP configuration at DRs.) The main
threat in this case is that an outsider illegitimately uses the RP to
host his/hers own group(s). This can be mitigated to an extent by
filtering which groups or group ranges are allowed at the RP; more
specific controls are beyond the scope of this memo. Note that this
does not seem to be a serious threat in the first place as anyone
with a /64 prefix can create an own RP, without having to
illegitimately get it from someone else.
7. The Embedded-RP Group-to-RP Mapping Mechanism 7. The Embedded-RP Group-to-RP Mapping Mechanism
This section specifies the group-to-RP mapping mechanism works for This section specifies the group-to-RP mapping mechanism for Embedded
Embedded RP. RP.
7.1. PIM-SM Group-to-RP Mapping 7.1. PIM-SM Group-to-RP Mapping
The only PIM-SM modification required is implementing this mechanism The only PIM-SM modification required is implementing this mechanism
as one group-to-RP mapping method. as one group-to-RP mapping method.
The implementation will have to recognize the address format and The implementation will have to recognize the address format and
derive and use the RP address using the rules in Section 4. This derive and use the RP address using the rules in Section 4. This
information is used at least when performing Reverse Path Forwarding information is used at least when performing Reverse Path Forwarding
(RPF) lookups, when processing Join/Prune messages, or performing (RPF) lookups, when processing Join/Prune messages, or performing
skipping to change at page 11, line 34 skipping to change at page 12, line 27
just acts as a group-to-RP mapping mechanism; instead of obtaining just acts as a group-to-RP mapping mechanism; instead of obtaining
the address of the RP from local configuration or configuration the address of the RP from local configuration or configuration
protocols (e.g., BSR), it is derived transparently from the encoded protocols (e.g., BSR), it is derived transparently from the encoded
multicast address. multicast address.
8. Scalability Analysis 8. Scalability Analysis
Interdomain MSDP model for connecting PIM-SM domains is mostly Interdomain MSDP model for connecting PIM-SM domains is mostly
hierarchical in configuration and deployment, but flat with regard to hierarchical in configuration and deployment, but flat with regard to
information distribution. The embedded-RP inter-domain model behaves information distribution. The embedded-RP inter-domain model behaves
as if all of the Internet was a single PIM domain, with just one RP as if every group formed its own Internet-wide PIM domain, with the
per group. So, the inter-domain multicast becomes a flat, RP- group mapping to a single RP, wherever the receivers or senders are.
centered topology. The scaling issues are described below. So, the inter-domain multicast becomes a flat, RP-centered topology.
The scaling issues are described below.
Previously foreign sources sent the unicast-encapsulated data to Previously foreign sources sent the unicast-encapsulated data to
their local RP, now they do so to the foreign RP "responsible" for their "local" RP, now they do so to the "foreign" RP responsible for
the specific group (i.e., the prefix where the group address was the specific group. This is especially important with large
derived from). This is especially important with large multicast multicast groups where there are a lot of heavy senders --
groups where there are a lot of heavy senders -- particularly if particularly if implementations do not handle unicast-decapsulation
implementations do not handle unicast-decapsulation well. well.
This model increases the amount of Internet-wide multicast state With IPv4 ASM multicast, there is roughly two kinds of Internet-wide
slightly: the backbone routers might end up with (*, G) and (S, G, state: MSDP (propagated everywhere), and multicast routing state (on
rpt) state between receivers (and past receivers, for PIM Prunes) and the receiver or sender branches). The former is eliminated, but the
the RP, in addition to (S, G) states between the receivers and backbone routers might end up with (*, G) and (S, G, rpt) state
senders, if SPT is used. However, the traditional ASM model also between receivers (and past receivers, for PIM Prunes) and the RP, in
requires MSDP state to propagate everywhere in inter-domain, so the addition to (S, G) states between the receivers and senders, if SPT
total amount of state is smaller. is used. However, the total amount of state is smaller.
The embedded-RP model is practically identical in both inter-domain The embedded-RP model is practically identical in both inter-domain
and intra-domain cases to the traditional PIM-SM in intra-domain. On and intra-domain cases to the traditional PIM-SM in intra-domain. On
the other hand, PIM-SM has been deployed (in IPv4) in inter-domain the other hand, PIM-SM has been deployed (in IPv4) in inter-domain
using MSDP; compared to that inter-domain model, this specification using MSDP; compared to that inter-domain model, this specification
simplifies the multicast routing by removing the RP for senders and simplifies the tree construction (i.e., multicast routing) by
receivers in foreign domains, and eliminating the MSDP information removing the RP for senders and receivers in foreign domains, and
distribution. eliminating the MSDP information distribution.
As the address of the RP is tied to the multicast address, the RP As the address of the RP is tied to the multicast address, the RP
failure management becomes more difficult, as failover or redundancy failure management becomes more difficult, as the deployed failover
mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be used as-is. or redundancy mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be
On the other hand, Anycast-RP using PIM could be used. This used as-is. However, Anycast-RP using PIM provides equal redundancy;
described briefly in Section 6.1. 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 "reachable" learned MUST be a domain-wide reachable address". What "reachable"
precisely means is not clear, even without embedded-RP. This precisely means is not clear, even without embedded-RP. This
statement cannot be proven especially with the foreign RPs as one can statement cannot be proven especially with the foreign RPs as one can
not even guarantee that the RP exists. Instead of manually not even guarantee that the RP exists. Instead of manually
configuring RPs and DRs (configuring a non-existent RP was possible configuring RPs and DRs (configuring a non-existent RP was possible
though rare), with this specification the hosts and users using though rare), with this specification the hosts and users using
multicast indirectly specify the RP themselves, lowering the multicast indirectly specify the RP themselves, lowering the
expectancy of the RP reachability. This is a relatively significant expectancy of the RP reachability. This is a relatively significant
skipping to change at page 12, line 50 skipping to change at page 13, line 43
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 an earlier SPT-join approach. Rami Lehtonen noted problems with an earlier SPT-join approach. Rami Lehtonen
pointed out issues with the scope of SA-state and provided extensive pointed out issues with the scope of SA-state and provided extensive
commentary. Nidhi Bhaskar gave the draft a thorough review. commentary. Nidhi Bhaskar gave the draft a thorough review.
Toerless Eckert, Hugh Holbrook, and Dave Meyer provided very Toerless Eckert, Hugh Holbrook, and Dave Meyer provided very
extensive feedback. In particular, Pavlin Radoslavov, Dino extensive feedback. In particular, Pavlin Radoslavov, Dino
Farinacci, and Nidhi Bhaskar provided good comments during and after Farinacci, Nidhi Bhaskar, and Jerome Durand provided good comments
WG last call. The whole MboneD working group is also acknowledged during and after WG last call. The whole MboneD working group is
for the continued support and comments. also acknowledged for the continued support and comments.
10. Security Considerations 10. Security Considerations
The addresses of RPs are encoded in the multicast addresses -- and The addresses of RPs are encoded in the multicast addresses -- and
thus become more visible as single points of failure. Even though thus become more visible as single points of failure. Even though
this does not significantly affect the multicast routing security, it this does not significantly affect the multicast routing security, it
may expose the RP to other kinds of attacks. The operators are may expose the RP to other kinds of attacks. The operators are
encouraged to pay special attention to securing these routers. See encouraged to pay special attention to securing these routers. See
Section 6.1 on considerations regarding failover and Section 6.2 on Section 6.1 on considerations regarding failover and Section 6.2 on
placement of RPs leading to a degree of fate-sharing properties. placement of RPs leading to a degree of fate-sharing properties.
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 encode the all such messages for all multicast addresses that do not encode the
address of the RP. Both the sender- and receiver-based attacks are address of the RP. Both the sender- and receiver-based attacks are
described at more length in [PIMSEC]. described at more length in [PIMSEC].
Additionally the implementation MAY also allow manual configuration Additionally the implementation SHOULD also allow manual
of which multicast addresses or prefixes embedding the RP are allowed configuration of which multicast prefixes are allowed to be used.
to be used. This can be used to limit the use of the RP to This can be used to limit the use of the RP to designated groups
designated groups only. In some cases, it is desirable to be able to only. In some cases, it is desirable to be able to restrict (at the
restrict (at the RP) which unicast addresses are allowed to send or RP) which unicast addresses are allowed to send or join to a group.
join to a group. (However, note that Join/Prune messages would still (However, note that Join/Prune messages would still leave state in
leave state in the network, and Register messages can be spoofed the network, and Register messages can be spoofed [PIMSEC].)
[PIMSEC].) Obviously, these controls are only possible at the RP, Obviously, these controls are only possible at the RP, not at the
not at the intermediate routers or the DR. intermediate routers or the DR.
It is recommended that routers supporting this specification do not It is RECOMMENDED that routers supporting this specification do not
act as RPs unless explicitly configured to do so; as becoming an RP act as RPs unless explicitly configured to do so; as becoming an RP
does not require any advertisement (e.g., through BSR or manually), does not require any advertisement (e.g., through BSR or manually),
otherwise any router could potentially become an RP (and be abused as otherwise any router could potentially become an RP (and be abused as
such). such). Further, multicast groups or group ranges to-be-served MAY
need to be explicitly configured at the RPs, to protect from being
used unwillingly. Note that the more specific controls (e.g.,
"insider-must-create" or "invite-outsiders" models) to who is allowed
to use the groups are beyond the scope of this memo.
Excluding internal-only groups from MSDP advertisements does not
protect the groups from outsiders, only offers security by obscurity;
embedded-RP offers similar level of protection. When real protection
is desired, e.g., PIM scoping should be set up at the borders; this
is described at more length in Section 6.5.
One should observe that the embedded-RP threat model is actually One should observe that the embedded-RP threat model is actually
rather similar to SSM; both mechanisms significantly reduce the rather similar to SSM; both mechanisms significantly reduce the
threats at the sender side. On the receiver side, the threats are threats at the sender side. On the receiver side, the threats are
somewhat comparable, as an attacker could do an MLDv2 (S,G) join somewhat comparable, as an attacker could do an MLDv2 (S,G) join
towards a non-existent source, which the local RP could not block towards a non-existent source, which the local RP could not block
based on the MSDP information. based on the MSDP information.
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;
skipping to change at page 16, line 16 skipping to change at page 17, line 26
much state is being generated to reach in a resource exhaustion DoS much state is being generated to reach in a resource exhaustion DoS
attack, some forms of rate-limiting or other mechanisms could be attack, some forms of rate-limiting or other mechanisms could be
deployed to mitigate the threats while trying not to disturb the deployed to mitigate the threats while trying not to disturb the
legitimate usage. However, as the threats are generic, they are legitimate usage. However, as the threats are generic, they are
considered out of scope and discussed separately in [PIMSEC]. considered out of scope and discussed separately in [PIMSEC].
B. Changes B. Changes
[[ RFC-Editor: please remove before publication ]] [[ RFC-Editor: please remove before publication ]]
B.1 Changes since -02 B.3 Changes since -03
o Further clarifications, especially regarding Inter/intra-domain
terminology.
o Recommend more strongly that multicast groups can be configured,
and that they should be explicitly configured, to protect against
abuse.
o Note that more detailed controls on who can use a multicast
address are out of scope.
o Add discussion about controls/manageability and how that has
changed from the MSDP model.
B.2 Changes since -02
o Clarified security considerations, wrt. RPs being abused by third o Clarified security considerations, wrt. RPs being abused by third
parties and policy controls at the RP. parties and policy controls at the RP.
o Clarified that only RPs, DRs next to sources sending to embedded- o Clarified that only RPs, DRs next to sources sending to embedded-
RP groups, and routers between the receivers and the RPs need to RP groups, and routers between the receivers and the RPs need to
have support this mapping. have support this mapping.
o Try to be clearer that FF70::/12 is meant for PIM-SM at the o Try to be clearer that FF70::/12 is meant for PIM-SM at the
moment, while FFF0::/12 is unspecified. moment, while FFF0::/12 is unspecified.
o Minor miscellaneous changes. o Minor miscellaneous changes.
B.2 Changes since -01 B.3 Changes since -01
o Lots of editorial cleanups and some reorganization, without o Lots of editorial cleanups and some reorganization, without
technical changes. technical changes.
o Remove the specification that RIID=0 SHOULD NOT be accepted, but o Remove the specification that RIID=0 SHOULD NOT be accepted, but
state that they "must not" be used (implementation vs. state that they "must not" be used (implementation vs.
operational wording). operational wording).
o Specify that the RP address MUST NOT be of prefixes fe80::/10, o Specify that the RP address MUST NOT be of prefixes fe80::/10,
::/16, or ff00::/8. ::/16, or ff00::/8.
B.3 Changes since -00 B.4 Changes since -00
o Lots of editorial cleanups, or cleanups without techinical o Lots of editorial cleanups, or cleanups without techinical
changes. changes.
o Reinforce the notion of Embedded RP just being a group-to-RP o Reinforce the notion of Embedded RP just being a group-to-RP
mapping mechanism (causing substantive rewriting in section 7); mapping mechanism (causing substantive rewriting in section 7);
highlight the fact that precomputing the group-to-RP mapping is highlight the fact that precomputing the group-to-RP mapping is
not possible. not possible.
o Add (a bit) more text on RP redundancy and deployment tradeoffs o Add (a bit) more text on RP redundancy and deployment tradeoffs
wrt. RPs becoming SPoF. wrt. RPs becoming SPoF.
o Clarify the usability/scalability issues in section 8. o Clarify the usability/scalability issues in section 8.
 End of changes. 

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