< draft-ietf-mboned-embeddedrp-06.txt   draft-ietf-mboned-embeddedrp-07.txt >
mboned Working Group P. Savola mboned Working Group P. Savola
Internet Draft CSC/FUNET Internet Draft CSC/FUNET
Expiration Date: December 2004 Expiration Date: January 2005
B. Haberman B. Haberman
Caspian Networks Caspian Networks
June 2004 July 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-06.txt draft-ietf-mboned-embeddedrp-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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 other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 ............................................... 2 1. Introduction ............................................... 2
1.1. Background ............................................. 2 1.1. Background ............................................. 2
1.2. Solution ............................................... 3 1.2. Solution ............................................... 3
1.3. Assumptions and Scope .................................. 4 1.3. Assumptions and Scope .................................. 4
1.4. Terminology ............................................ 4 1.4. Terminology ............................................ 4
2. Unicast-Prefix-based Address Format ........................ 4 1.5. Abbreviations .......................................... 4
2. Unicast-Prefix-based Address Format ........................ 5
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 .............................................. 7 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 ................................. 9 6. Operational Considerations ................................. 9
6.1. RP Redundancy .......................................... 9 6.1. RP Redundancy .......................................... 9
6.2. RP Deployment .......................................... 9 6.2. RP Deployment .......................................... 9
skipping to change at page 2, line 47 skipping to change at page 2, line 48
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 (ASM) 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, as noted problems but is not a complete solution for several reasons, as noted
below. 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,
and specifies a PIM-SM group-to-RP mapping to use the encoding, and specifies a PIM-SM group-to-RP mapping to use the encoding,
leveraging and extending unicast-prefix -based addressing [RFC3306]. leveraging and extending 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 Any Source Multicast (ASM) but can be used as a simple interdomain Any Source Multicast but can be used as a simple solution
solution for IPv6 intradomain ASM with scoped multicast addresses as for IPv6 intradomain ASM with scoped multicast addresses as well. It
well. It can also be used as an automatic RP discovery mechanism in can also be used as an automatic RP discovery mechanism in those
those deployment scenarios which would have previously used the deployment scenarios which would have previously used the Bootstrap
Bootstrap Router protocol (BSR) [BSR]. Router protocol (BSR) [BSR].
The solution consists of three elements: The solution consists of three elements:
o A specification of a subrange of [RFC3306] IPv6 multicast group o A specification of a subrange of [RFC3306] IPv6 multicast group
addresses defined by setting one previously unused bit of the addresses defined by setting one previously unused bit of the
Flags field to "1", 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
skipping to change at page 4, line 5 skipping to change at page 3, line 46
SM on these IPv6 multicast groups. SM on these IPv6 multicast groups.
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.
Some design tradeoffs are discussed in Appendix A.
1.3. Assumptions and Scope 1.3. Assumptions and Scope
A 128-bit RP address can't be embedded into a 128-bit group address A 128-bit RP address can't be embedded into a 128-bit group address
with space left to carry the group identity itself. An appropriate with space left to carry the group identity itself. An appropriate
form of encoding is thus defined by requiring that the Interface-IDs form of encoding is thus defined by requiring that the Interface-IDs
of RPs in the embedded-RP range can be assigned to be a specific of RPs in the embedded-RP range can be assigned to be a 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
skipping to change at page 4, line 38 skipping to change at page 4, line 38
Embedded-RP behaves as if all the members of the group were all Embedded-RP behaves as if all the members of the group were all
intra-domain to the information distribution. However, as it gives a intra-domain to the information distribution. However, as it gives a
solution for the global IPv6 multicast Internet, spanning multiple solution for the global IPv6 multicast Internet, spanning multiple
administrative domains, we say it is a solution for inter-domain administrative domains, we say it is a solution for inter-domain
multicast. 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].
1.5. Abbreviations
ASM Any Source Multicast
BSR Bootstrap Router
DR Designated Router
IGP Interior Gateway Protocol
MLD Multicast Listener Discovery
MSDP Multicast Source Discovery Protocol
PIM Protocol Independent Multicast
PIM-SM Protocol Independent Multicast - Sparse Mode
RIID RP Interface ID (as specified in this memo)
RP Rendezvous Point
RPF Reverse Path Forwarding
SPT Shortest Path Tree
SSM Source-specific Multicast
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 by specifying the second high-order bit ("R-bit") as
follows:
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
this memo.
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
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:
| 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]. If R = 1, but P is set to 0, the packet MUST specified in [RFC3306]. In effect, this implies the prefix
be discarded. The behaviour if T is set to 0 when P is set to 1 is FF70::/12.
derived from [RFC3306] and is unspecified in this memo.
The behavior is unspecified if P or T is not set to 1, as then the
prefix would not be FF70::/12. Likewise, encoding and the protocol
mode used when the two high-order bit in "flgs" are set to 11
("FFF0::/12") is intentionally unspecified until such time that the
highest-order bit is defined.
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
in this memo. 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 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 "RIID" MUST be sent as zero [RFC3306]. In this context, the value of "RIID" MUST be sent as zero
and MUST be ignored on receipt. and MUST be ignored on receipt.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
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 prefix FF70::/12 (note that to 1 -- that is, be part of the prefix FF70::/12 (note that
FFF0::/12 is unspecified), FFF0::/12 is yet 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
2. replace the last 4 bits with the contents of "RIID". 2. replace the last 4 bits with the contents of "RIID".
These two steps could be illustrated as follows: These two steps could be illustrated as follows:
| 20 bits | 4 | 8 | 64 | 32 | | 20 bits | 4 | 8 | 64 | 32 |
+---------+----+----+----------------+----------+ +---------+----+----+----------------+----------+
|xtra bits|RIID|plen| network prefix | group ID | |xtra bits|RIID|plen| network prefix | group ID |
+---------+----+----+----------------+----------+ +---------+----+----+----------------+----------+
|| \\ vvvvvvvvvvv || \\ vvvvvvvvvvv
|| ``====> copy plen bits of "network prefix" || ``====> copy plen bits of "network prefix"
|| +------------+------------------------+ || +------------+--------------------------+
|| | 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 |RIID|
+------------+---------------------+--+ +------------+---------------------+----+
One should note that there are several operational scenarios (see One should note that there are several operational scenarios (see
Example 3 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.
skipping to change at page 9, line 20 skipping to change at page 9, line 20
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].
The most feasible candidate for RP failover is using PIM for Anycast The most feasible candidate for RP failover is using PIM for Anycast
RP or "anycasting" (i.e., the shared-unicast model [ANYCAST]) the RP RP or "anycasting" (i.e., the shared-unicast model [ANYCAST]) the RP
address in the IGP without state sharing (depending on the redundancy address in the Interior Gateway Protocol (IGP) without state sharing
requirements, this may or may not be enough, though). However, the (depending on the redundancy requirements, this may or may not be
redundancy mechanisms are outside of the scope of this memo. enough, though). However, the 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
connecting multicast sources could act as an RP without scalability Designated Router connecting multicast sources could act as an RP
concerns about setting up and maintaining MSDP sessions. without scalability 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 trivial: each group could map to a different groups, this is trivial: each group could map to a
skipping to change at page 10, line 32 skipping to change at page 10, line 32
MSDP advertisement filtering typically includes at least two MSDP advertisement filtering typically includes at least two
capabilities: being able to filter who is able to create a global capabilities: being able to filter who is able to create a global
session ("source filtering"), and being able to filter which groups session ("source filtering"), and being able to filter which groups
should be globally accessible ("group filtering"). These are done to should be globally accessible ("group filtering"). These are done to
prevent local groups from being advertised to the outside, or prevent local groups from being advertised to the outside, or
preventing unauthorized senders from creating global groups. preventing unauthorized senders from creating global groups.
However, such controls do not yet block the outsiders from using such However, such controls do not yet block the outsiders from using such
groups, as they could join the groups even without Source Active groups, as they could join the groups even without Source Active
advertisement with an (S,G) Join by guessing/learning the source advertisement with a (Source, Group) or (S,G) Join by
and/or the group address. For proper protection, one should set up, guessing/learning the source and/or the group address. For proper
e.g., PIM multicast scoping borders at the border routers. protection, one should set up, e.g., PIM multicast scoping borders at
Therefore, embedded-RP has by default roughtly equivalent level of the border routers. Therefore, embedded-RP has by default roughtly
"protection" as MSDP with SA filtering. equivalent level of "protection" as MSDP with SA filtering.
A new issue with control comes from the fact that nodes in a "foreign 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 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 been possible in the past as well, to a degree, but only through
willfull attempts or purposeful RP configuration at DRs.) The main willfull attempts or purposeful RP configuration at DRs.) The main
threat in this case is that an outsider illegitimately uses the RP to 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 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 filtering which groups or group ranges are allowed at the RP; more
specific controls are beyond the scope of this memo. Note that this 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 does not seem to be a serious threat in the first place as anyone
skipping to change at page 11, line 47 skipping to change at page 11, line 47
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).
2. The receiver issues an MLD Report, joining the group. 2. The receiver issues an Mulicast Listener Discovery (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 encoded in the multicast address, irrespective of the RP encoded in the multicast address, irrespective of
whether it is in the "local" or "remote" PIM domain. whether it is in the "local" or "remote" PIM domain.
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 using an unspecified method 1. A sender finds out a group address using an unspecified method
(e.g, by contacting the administrator for group assignment or (e.g, by contacting the administrator for group assignment or
using a multicast address assignment protocol). using a multicast address assignment protocol).
2. The sender sends to the group. 2. The sender sends to the group.
skipping to change at page 13, line 44 skipping to change at page 13, line 44
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, Nidhi Bhaskar, and Jerome Durand provided good comments Farinacci, Nidhi Bhaskar, and Jerome Durand provided good comments
during and after WG last call. The whole MboneD working group is during and after WG last call. Mark Allman, Bill Fenner, Thomas
also acknowledged for the continued support and comments. Narten, and Alex Zinin provided substantive comments during the IESG
evaluation. The whole MboneD working group is 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 Denial of Service attack
However, this can be mitigated by the fact that the RP can discard scenario. However, this can be mitigated by the fact that the RP can
all such messages for all multicast addresses that do not encode the discard all such messages for all multicast addresses that do not
address of the RP. Both the sender- and receiver-based attacks are encode the address of the RP. Both the sender- and receiver-based
described at more length in [PIMSEC]. attacks are described at more length in [PIMSEC].
Additionally the implementation SHOULD also allow manual Additionally the implementation SHOULD also allow manual
configuration of which multicast prefixes are allowed to be used. configuration of which multicast prefixes are allowed to be used.
This can be used to limit the use of the RP to designated groups 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 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. RP) which unicast addresses are allowed to send or join to a group.
(However, note that Join/Prune messages would still leave state in (However, note that Join/Prune messages would still leave state in
the network, and Register messages can be spoofed [PIMSEC].) the network, and Register messages can be spoofed [PIMSEC].)
Obviously, these controls are only possible at the RP, not at the Obviously, these controls are only possible at the RP, not at the
intermediate routers or the DR. intermediate routers or the DR.
skipping to change at page 15, line 41 skipping to change at page 15, line 41
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, draft-ietf-ipngwg-ipv6- anycast", work-in-progress, 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-02.txt,
November 2003. June 2004.
[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-ietf-mboned-mroutesec-00.txt, work-in-progress, draft-ietf-mboned-mroutesec-02.txt,
April 2004. June 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 17, line 16 skipping to change at page 17, line 16
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, whether feasible or not, threshold for PIM-SM. These could be, whether feasible or not,
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
attack, some forms of rate-limiting or other mechanisms could be Denial of Service attack, some forms of rate-limiting or other
deployed to mitigate the threats while trying not to disturb the mechanisms could be deployed to mitigate the threats while trying not
legitimate usage. However, as the threats are generic, they are to disturb the legitimate usage. However, as the threats are
considered out of scope and discussed separately in [PIMSEC]. generic, they are considered out of scope and discussed separately in
[PIMSEC].
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 Rights or other rights that might be claimed to Intellectual Property Rights 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; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can on the IETF's procedures with respect to rights in IETF Documents can
 End of changes. 22 change blocks. 
63 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/