draft-ietf-mboned-embeddedrp-05.txt   draft-ietf-mboned-embeddedrp-06.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: December 2004 Expiration Date: December 2004
B. Haberman B. Haberman
Caspian Networks Caspian Networks
June 2004 June 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-05.txt draft-ietf-mboned-embeddedrp-06.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 7 skipping to change at page 2, line 7
This memo defines an address allocation policy in which the address This memo defines an address allocation policy in which the address
of the Rendezvous Point (RP) is encoded in an IPv6 multicast group of the Rendezvous Point (RP) is encoded in an IPv6 multicast group
address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), address. For Protocol Independent Multicast - Sparse Mode (PIM-SM),
this can be seen as a specification of a group-to-RP mapping this can be seen as a specification of a group-to-RP mapping
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 ............................................... 2
1.1. Background ............................................. 3 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 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 .............................................. 7 5.2. Example 2 .............................................. 7
5.3. Example 3 .............................................. 8 5.3. Example 3 .............................................. 8
skipping to change at page 2, line 37 skipping to change at page 2, line 37
7.1. PIM-SM Group-to-RP Mapping ............................. 11 7.1. PIM-SM Group-to-RP Mapping ............................. 11
7.2. Overview of the Model .................................. 11 7.2. Overview of the Model .................................. 11
8. Scalability Analysis ....................................... 12 8. Scalability Analysis ....................................... 12
9. Acknowledgements ........................................... 13 9. Acknowledgements ........................................... 13
10. Security Considerations ................................... 14 10. Security Considerations ................................... 14
11. References ................................................ 15 11. References ................................................ 15
11.1. Normative References .................................. 15 11.1. Normative References .................................. 15
11.2. Informative References ................................ 15 11.2. Informative References ................................ 15
Authors' Addresses ............................................. 16 Authors' Addresses ............................................. 16
A. Discussion about Design Tradeoffs .......................... 16 A. Discussion about Design Tradeoffs .......................... 16
B. Changes .................................................... 17
B.4 Changes since -04 ....................................... 17
B.3 Changes since -03 ....................................... 17
B.2 Changes since -02 ....................................... 17
B.3 Changes since -01 ....................................... 18
B.4 Changes since -00 ....................................... 18
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 5, line 42 skipping to change at page 5, line 34
| 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]. If R = 1, but P is set to 0, the packet MUST
be discarded. The behaviour if T is set to 0 when P is set to 1 is
derived from [RFC3306] and is unspecified in this memo.
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 7, line 47 skipping to change at page 7, line 47
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 ("y" could be anything group-id's to assign to customers and self ("y" could be anything
from 1 to F, as 0 must not be used). from 1 to F, as 0 must not be used).
5.2. Example 2 5.2. Example 2
As in Example 1, the network administrator of 2001:DB8::/32 wants to 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 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 specifically routed subnet, and wants to keep larger address space
for group allocations. That is, the administrator selects the least for group allocations. That is, the administrator selects the least
specific part of the prefix, with plen=32, and the group addresses specific part of the unicast prefix, with plen=32, and the group
will be of the form: addresses will be from the multicast prefix:
FF7x:y20:2001:DB8:zzzz:zzzz:<group-id> FF7x:y20:2001:DB8::/64
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 assignable to anyone. In this case, address, and there are 64 bits for group-id's or assignments. In
the address of the RP would be: this case, the address of the RP would be:
2001:DB8::y 2001:DB8::y
The address 2001:DB8::y/128 is assigned to a router as a loopback The address 2001:DB8::y/128 is assigned to a router as a loopback
address and injected to the routing system; if the network address and injected to the routing system; if the network
administrator sets up only one or a couple of RPs (and e.g., not one 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 RP per subnet), this approach may be preferable to the one described
in Example 1. in Example 1.
5.3. Example 3 5.3. Example 3
As in Example 2, the network administrator can also allocate As in Example 2, the network administrator can also assign multicast
multicast addresses like "FF7x:y20:2001:DB8:DEAD::/80" to some of prefixes like "FF7x:y20:2001:DB8:DEAD::/80" to some of customers. In
customers. In this case the RP address would still be "2001:DB8::y". this case the RP address would still be "2001:DB8::y". (Note that
this is just a more specific subcase of Example 2, where the
administrator assigns a multicast prefix, not just invidial group-
id's.)
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
skipping to change at page 9, line 45 skipping to change at page 9, line 45
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
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 unicast
up to /64. The interface identifier will have to be manually network prefix up to /64. The interface identifier will have to be
configured to match "RIID". manually 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 unicast prefix (e.g., an additional loopback address assigned on a
described in example 2 in Section 5.1), that address can be injected router, as described in example 2 in Section 5.1), that address can
into the routing system via a host route. be injected 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 the RP to be used.
6.5. Controlling the Use of RPs 6.5. Controlling the Use of RPs
Compared to the MSDP inter-domain ASM model, the control and Compared to the MSDP inter-domain ASM model, the control and
skipping to change at page 10, line 47 skipping to change at page 10, line 47
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
with a /64 prefix can create an own RP, without having to with a /64 unicast prefix can create an own RP, without having to
illegitimately get it from someone else. 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 for Embedded This section specifies the group-to-RP mapping mechanism for 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
Register-encapsulation. Register-encapsulation.
To avoid loops and inconsistancies, the group-to-RP mapping specified To avoid loops and inconsistancies, for addresses in the range
in this memo MUST be used for all embedded-RP groups (i.e., addresses FF70::/12, the Embedded-RP mapping MUST be considered to be the
with prefix FF70::/12). longest possible match and higher priority than any other mechanism.
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 RP, the This group-to-RP mapping mechanism must be supported by the RP, the
DR adjacent to the senders and any router on the path from any DR adjacent to the senders and any router on the path from any
skipping to change at page 17, line 21 skipping to change at page 17, line 21
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 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
[[ RFC-Editor: please remove before publication ]]
B.4 Changes since -04
o Only update the boilerplates.
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
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.3 Changes since -01
o Lots of editorial cleanups and some reorganization, without
technical changes.
o Remove the specification that RIID=0 SHOULD NOT be accepted, but
state that they "must not" be used (implementation vs.
operational wording).
o Specify that the RP address MUST NOT be of prefixes fe80::/10,
::/16, or ff00::/8.
B.4 Changes since -00
o Lots of editorial cleanups, or cleanups without techinical
changes.
o Reinforce the notion of Embedded RP just being a group-to-RP
mapping mechanism (causing substantive rewriting in section 7);
highlight the fact that precomputing the group-to-RP mapping is
not possible.
o Add (a bit) more text on RP redundancy and deployment tradeoffs
wrt. RPs becoming SPoF.
o Clarify the usability/scalability issues in section 8.
o Clarify the security issues in Sections 8, Security
Considerations and Appendix A, mainly by referring to a separate
document.
o Add a MUST that embedded-RP mappings must be honored by
implementations.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property 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. 

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