draft-ietf-mboned-embeddedrp-02.txt   draft-ietf-mboned-embeddedrp-03.txt 
mboned Working Group P. Savola mboned Working Group P. Savola
Internet Draft CSC/FUNET Internet Draft CSC/FUNET
Expiration Date: September 2004 Expiration Date: October 2004
B. Haberman B. Haberman
Caspian Networks Caspian Networks
March 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-02.txt draft-ietf-mboned-embeddedrp-03.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 14 skipping to change at page 2, line 14
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. Keywords ............................................... 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 ... 5 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 .............................................. 7 5.2. Example 2 .............................................. 8
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 ................................. 8
6.1. RP Redundancy .......................................... 8 6.1. RP Redundancy .......................................... 8
6.2. RP Deployment .......................................... 8 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 ............................ 9 6.4. Use as a Substitute for BSR ............................ 10
7. The Embedded-RP Group-to-RP Mapping Mechanism .............. 9 7. The Embedded-RP Group-to-RP Mapping Mechanism .............. 10
7.1. PIM-SM Group-to-RP Mapping ............................. 9 7.1. PIM-SM Group-to-RP Mapping ............................. 10
7.2. Overview of the Model .................................. 10 7.2. Overview of the Model .................................. 10
8. Scalability Analysis ....................................... 11 8. Scalability Analysis ....................................... 11
9. Acknowledgements ........................................... 12 9. Acknowledgements ........................................... 12
10. Security Considerations ................................... 12 10. Security Considerations ................................... 13
11. References ................................................ 13 11. References ................................................ 14
11.1. Normative References .................................. 13 11.1. Normative References .................................. 14
11.2. Informative References ................................ 13 11.2. Informative References ................................ 14
Authors' Addresses ............................................. 14 Authors' Addresses ............................................. 15
A. Discussion about Design Tradeoffs .......................... 14 A. Discussion about Design Tradeoffs .......................... 15
B. Changes .................................................... 15 B. Changes .................................................... 16
B.1 Changes since -01 ....................................... 15 B.1 Changes since -02 ....................................... 16
B.2 Changes since -00 ....................................... 15 B.2 Changes since -01 ....................................... 16
Intellectual Property Statement ................................ 16 B.3 Changes since -00 ....................................... 16
Full Copyright Statement ....................................... 16 Intellectual Property Statement ................................ 17
Full Copyright Statement ....................................... 17
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.
skipping to change at page 4, line 41 skipping to change at page 4, line 41
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 have been yet undefined, Where flgs are "0011". (The first two bits have been yet undefined,
sent as zero and ignored on receipt.) sent as zero and ignored on receipt.)
3. Modified Unicast-Prefix-based Address Format 3. Modified Unicast-Prefix-based Address Format
This memo specifies a modification to the unicast-prefix-based This memo specifies a modification to the unicast-prefix-based
address format: address format:
1. If the second high-order bit in "flgs" is set to 1, the address 1. If the two high-order bits in "flgs" are set to 01, 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" is set to 1, interpret 2. If the two high-order bit in "flgs" are set to 01, 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 ("RIID"), as described in this memo. RP interface ID ("RIID"), as described in this memo.
The encoding and the protocol mode used when the two high-order bit
in "flgs" are set to 11 is intentionally unspecified until such time
that the highest-order bit is defined.
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|RIID| 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 on the R = 1 indicates a multicast address that embeds the address on the
RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as
specified in [RFC3306]. specified in [RFC3306].
In the case that R = 1, the last 4 bits of the previously reserved In the case that R = 1, the last 4 bits of the previously reserved
field are interpreted as embedding the RP interface ID, as specified field are interpreted as embedding the RP interface ID, as specified
skipping to change at page 6, line 6 skipping to change at page 6, line 15
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.
That is, to identify whether an address is a multicast address as That is, to identify whether an address is a multicast address as
specified in this memo and to be processed any further, it must specified in this memo and to be processed any further, it must
satisfy all of the below: satisfy all of the 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 prefixes FF70::/12 or FFF0::/12), to 1 -- that is, be part of the prefix FF70::/12 (note that
FFF0::/12 is unspecified),
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 two steps: satisfying the above criteria by taking the two steps:
1. copy the first "plen" bits of the "network prefix" to a zeroed 1. copy the first "plen" bits of the "network prefix" to a zeroed
128-bit address structure, and 128-bit address structure, and
skipping to change at page 7, line 7 skipping to change at page 7, line 18
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 have 4 bits worth of ID -- without varying any of these, you can 2^4-1 = 15 different RPs
different RPs. However, each of these is an IPv6 group address of (as RIID=0 is reserved). However, each of these is an IPv6 group
its own (i.e., there can be only one RP per multicast address). 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- 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
skipping to change at page 7, line 34 skipping to change at page 7, line 46
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 freely assignable to anyone. In this
case, the address of the RP would be: case, 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 (and "y" could be anything from 1 to F, as 0 must not be used); the
address 2001:DB8::y/128 is added on a router as a loopback address address 2001:DB8::y/128 is assigned to a router as a loopback address
and injected to the routing system. and injected to the routing system.
5.2. Example 2 5.2. Example 2
As in Example 1, the network administrator can also allocate As in Example 1, 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
skipping to change at page 8, line 24 skipping to change at page 8, line 41
5.4. Example 4 5.4. Example 4
In the above networks, if the administrator wants to specify the RP 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 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 "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 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 Considerations 6. Operational Considerations
This desction describes the major operational considerations for This section describes the major operational considerations for those
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 RP failover cannot be used with this specification without additional
skipping to change at page 9, line 32 skipping to change at page 10, line 9
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 1 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 the RP to be used. specifies how the RP to be used.
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 works for
Embedded RP. Embedded 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
Register-encapsulation. Register-encapsulation.
To avoid loops and inconsistancies, the group-to-RP mapping specified To avoid loops and inconsistancies, the group-to-RP mapping specified
in this memo MUST be used for all embedded-RP groups (i.e., addresses in this memo MUST be used for all embedded-RP groups (i.e., addresses
with prefix FF70::/12 or FFF0::/12). with prefix FF70::/12).
It is worth noting that compared to the other group-to-RP mapping It is worth noting that compared to the other group-to-RP mapping
mechanisms, which can be precomputed, the embedded-RP mapping must be mechanisms, which can be precomputed, the embedded-RP mapping must be
redone for every new IPv6 group address which would map to a redone for every new IPv6 group address which would map to a
different RP. For efficiency, the results may be cached in an different RP. For efficiency, the results may be cached in an
implementation-specific manner, to avoid computation for every implementation-specific manner, to avoid computation for every
embedded-RP packet. embedded-RP packet.
This group-to-RP mapping mechanism must be supported by the DR This group-to-RP mapping mechanism must be supported by the RP, the
adjacent to the senders and any router on the path from any receiver DR adjacent to the senders and any router on the path from any
to the RP. Further, as the switch-over to Shortest Path Tree (SPT) receiver to the RP. Paths for Shortest Path Tree (SPT) formation and
is also possible, it must be supported on the path between the Register-Stop do not require the support, as those are accomplished
receivers and the senders as well. It also must be supported by any with an (S,G) Join.
router on the path from any sender to the RP -- in case the RP issues
a Register-Stop and Joins the sources. So, in practice, the
mechanism must be supported by all routers on any path between the
RP, receivers, and senders.
7.2. Overview of the Model 7.2. Overview of the Model
This section gives a high-level, non-normative overview of how This section gives a high-level, non-normative overview of how
Embedded RP operates, as specified in the previous section. 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).
skipping to change at page 11, line 48 skipping to change at page 12, line 23
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 failover or redundancy
mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be used as-is. mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be used as-is.
On the other hand, Anycast-RP using PIM could be used. This On the other hand, Anycast-RP using PIM could be used. This
described briefly in Section 6.1. 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 configuring RPs not even guarantee that the RP exists. Instead of manually
and DRs with a manual process (configuring a non-existent RP was configuring RPs and DRs (configuring a non-existent RP was possible
possible though rare), with this specification the hosts and users though rare), with this specification the hosts and users using
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
problem but not much different from the current multicast deployment: problem but not much different from the current multicast deployment:
e.g., MLDv2 (S,G) joins, whether ASM or SSM, yield the same result e.g., MLDv2 (S,G) joins, whether ASM or SSM, yield the same result
[PIMSEC]. [PIMSEC].
Being able to join/send to remote RPs raises security concerns that Being able to join/send to remote RPs raises security concerns that
are considered separately, but it has an advantage too: every group are considered separately, but it has an advantage too: every group
has a "responsible RP" which is able to control (to some extent) who has a "responsible RP" which is able to control (to some extent) who
are able to send to the group. are able to send to the group.
skipping to change at page 12, line 26 skipping to change at page 12, line 49
SSM) and their security properties has been described in [PIMSEC]. 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 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. The whole MboneD working group is also extensive feedback. In particular, Pavlin Radoslavov, Dino
acknowledged for the continued support and comments. Farinacci, and Nidhi Bhaskar provided good comments during and after
WG last call. The whole MboneD working group is also acknowledged
for the continued support and comments.
10. Security Considerations 10. Security Considerations
The address of the RP is encoded in the multicast address -- and thus The addresses of RPs are encoded in the multicast addresses -- and
become more visible as single points of failure. Even though this thus become more visible as single points of failure. Even though
does not significantly affect the multicast routing security, it may this does not significantly affect the multicast routing security, it
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. The implementation MAY also allow manual address of the RP. Both the sender- and receiver-based attacks are
configuration of which multicast addresses or prefixes embedding the described at more length in [PIMSEC].
RP could be used.
In a similar fashion, when a receiver joins to an RP, the DRs must Additionally the implementation MAY also allow manual configuration
accept similar PIM-SM messages back from RPs. However, this is not a of which multicast addresses or prefixes embedding the RP are allowed
considerable threat. to be used. This can be used to limit the use of the RP to
designated groups only. In some cases, it is desirable to be able to
restrict (at the RP) which unicast addresses are allowed to send or
join to a group. (However, note that Join/Prune messages would still
leave state in the network, and Register messages can be spoofed
[PIMSEC].) Obviously, these controls are only possible at the RP,
not at the intermediate routers or the DR.
It is recommended that routers supporting this specification do not
act as RPs unless explicitly configured to do so; as becoming an RP
does not require any advertisement (e.g., through BSR or manually),
otherwise any router could potentially become an RP (and be abused as
such).
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 13, line 40 skipping to change at page 14, line 26
[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
[ANYCAST] Hagino, J., Ettikan, K., "An analysis of IPv6 [ANYCAST] Hagino, J., Ettikan, K., "An analysis of IPv6
anycast", work-in-progress, anycast", work-in-progress, draft-ietf-ipngwg-ipv6-
draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt, June 2003. anycast-analysis-02.txt, June 2003.
[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-ietf-pim-anycast-rp-00.txt, work-in-progress, draft-ietf-pim-anycast-rp-00.txt,
November 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 Source [MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Source
Discovery Protocol (MSDP)", RFC 3618, October 2003. Discovery Protocol (MSDP)", RFC 3618, October 2003.
[PIMSEC] Savola, P., Lehtonen, R., Meyer, D., "PIM-SM Multicast [PIMSEC] Savola, P., Lehtonen, R., Meyer, D., "PIM-SM Multicast
Routing Security Issues and Enhancements", Routing Security Issues and Enhancements",
work-in-progress, draft-savola-mboned-mroutesec-00.txt, work-in-progress, draft-ietf-mboned-mroutesec-00.txt,
January 2004. April 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-09.txt, work-in-progress, draft-ietf-pim-sm-v2-new-09.txt,
February 2004. February 2004.
[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-04.txt, work-in-progress, draft-ietf-ssm-arch-04.txt,
October 2003. October 2003.
skipping to change at page 14, line 42 skipping to change at page 15, line 29
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 document only specifies FF70::/12 for now; if/when the upper-most
bit is used, one must specify how FFF0::/12 applies to Embedded-RP.
For example, a different mode of PIM or another protocol might use
that range, in contrast to FF70::/12, as currently specified, being
for PIM-SM only.
Instead of using flags bits ("FF70::/12"), one could have used the
left-most reserved bits instead ("FF3x:8000::/17").
It has been argued that instead of allowing the operator to specify It has been argued that instead of allowing the operator to specify
RIID, the value could be pre-determined (e.g., "1"). However, this RIID, the value could be pre-determined (e.g., "1"). However, this
has not been adopted, as this eliminates address assignment has not been adopted, as this eliminates address assignment
flexibility from the operator. flexibility from the operator.
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
skipping to change at page 15, line 15 skipping to change at page 16, line 12
encoded in the RP address somehow, or in the multicast group address. encoded in the RP address somehow, or in the multicast group address.
In any case, such modifications are beyond the scope of this memo. In any case, such modifications are beyond the scope of this memo.
For the cases where the RPs do not exist or are unreachable, or too For the cases where the RPs do not exist or are unreachable, or too
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].
The mechanism is not usable with Bidirectional PIM without protocol
extensions, as pre-computing the Designated Forwarder is not
possible.
B. Changes B. Changes
[[ RFC-Editor: please remove before publication ]] [[ RFC-Editor: please remove before publication ]]
B.1 Changes since -01 B.1 Changes since -02
o Clarified security considerations, wrt. RPs being abused by third
parties and policy controls at the RP.
o Clarified that only RPs, DRs next to sources sending to embedded-
RP groups, and routers between the receivers and the RPs need to
have support this mapping.
o Try to be clearer that FF70::/12 is meant for PIM-SM at the
moment, while FFF0::/12 is unspecified.
o Minor miscellaneous changes.
B.2 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.2 Changes since -00 B.3 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/