doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc3956.txt b/doc/rfc/rfc3956.txt
new file mode 100644
index 0000000..08e88f1
--- /dev/null
+++ b/doc/rfc/rfc3956.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                          P. Savola
+Request for Comments: 3956                                     CSC/FUNET
+Updates: 3306                                                B. Haberman
+Category: Standards Track                                        JHU APL
+                                                           November 2004
+
+
+              Embedding the Rendezvous Point (RP) Address
+                      in an IPv6 Multicast Address
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This memo defines an address allocation policy in which the address
+   of the Rendezvous Point (RP) is encoded in an IPv6 multicast group
+   address.  For Protocol Independent Multicast - Sparse Mode (PIM-SM),
+   this can be seen as a specification of a group-to-RP mapping
+   mechanism.  This allows an easy deployment of scalable inter-domain
+   multicast and simplifies the intra-domain multicast configuration as
+   well.  This memo updates the addressing format presented in RFC 3306.
+
+Table of Contents
+
+   1.  Introduction  ...............................................   2
+       1.1.  Background ............................................   2
+       1.2.  Solution  .............................................   2
+       1.3.  Assumptions and Scope .................................   3
+       1.4.  Terminology  ..........................................   4
+       1.5.  Abbreviations  ........................................   4
+   2.  Unicast-Prefix-based Address Format  ........................   4
+   3.  Modified Unicast-Prefix-based Address Format  ...............   5
+   4.  Embedding the Address of the RP in the Multicast Address  ...   5
+   5.  Examples  ...................................................   7
+       5.1.  Example 1  ............................................   7
+       5.2.  Example 2  ............................................   7
+       5.3.  Example 3  ............................................   8
+       5.4.  Example 4  ............................................   8
+
+
+
+Savola & Haberman           Standards Track                     [Page 1]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+   6.  Operational Considerations  .................................   8
+       6.1.  RP Redundancy .........................................   8
+       6.2.  RP Deployment  ........................................   9
+       6.3.  Guidelines for Assigning IPv6 Addresses to RPs ........   9
+       6.4.  Use as a Substitute for BSR ...........................   9
+       6.5.  Controlling the Use of RPs ............................   9
+   7.  The Embedded-RP Group-to-RP Mapping Mechanism  ..............  10
+       7.1.  PIM-SM Group-to-RP Mapping ............................  10
+       7.2.  Overview of the Model .................................  11
+   8.  Scalability Analysis  .......................................  12
+   9.  Acknowledgements  ...........................................  13
+   10. Security Considerations .....................................  13
+   11. References ..................................................  15
+       11.1. Normative References ..................................  15
+       11.2. Informative References ................................  15
+   A.  Discussion about Design Tradeoffs ...........................  16
+   Authors' Addresses ..............................................  17
+   Full Copyright Statement ......................................... 18
+
+1.  Introduction
+
+1.1.  Background
+
+   As has been noticed [V6MISSUES], there exists a deployment problem
+   with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no
+   way of communicating the information about (active) multicast sources
+   to other multicast domains, as Multicast Source Discovery Protocol
+   (MSDP) [MSDP] has deliberately not been specified for IPv6.
+   Therefore the whole interdomain Any Source Multicast (ASM) model is
+   rendered unusable; Source-Specific Multicast (SSM) [SSM] avoids these
+   problems but is not a complete solution for several reasons, as noted
+   below.
+
+   Further, it has been noted that there are some problems with the
+   support and deployment of mechanisms SSM would require [V6MISSUES]:
+   it seems unlikely that SSM could be usable as the only interdomain
+   multicast routing mechanism in the short term.
+
+1.2.  Solution
+
+   This memo describes a multicast address allocation policy in which
+   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,
+   leveraging, and extending unicast-prefix-based addressing [RFC3306].
+
+   This mechanism not only provides a simple solution for IPv6
+   interdomain Any Source Multicast but can be used as a simple solution
+   for IPv6 intra-domain ASM with scoped multicast addresses as well.
+
+
+
+Savola & Haberman           Standards Track                     [Page 2]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+   It can also be used as an automatic RP discovery mechanism in those
+   deployment scenarios that would have previously used the Bootstrap
+   Router protocol (BSR) [BSR].
+
+   The solution consists of three elements:
+
+   o  A specification of a subrange of [RFC3306] IPv6 multicast group
+      addresses defined by setting one previously unused bit of the
+      Flags field to "1",
+
+   o  a specification of the mapping by which such a group address
+      encodes the RP address that is to be used with this group, and
+
+   o  a description of operational procedures to operate ASM with PIM-SM
+      on these IPv6 multicast groups.
+
+   Addresses in the subrange will be called embedded-RP addresses.
+
+   This scheme obviates the need for MSDP, and the routers are not
+   required to include any multicast configuration, except when they act
+   as an RP.
+
+   This memo updates the addressing format presented in RFC 3306.
+
+   Some design tradeoffs are discussed in Appendix A.
+
+1.3.  Assumptions and Scope
+
+   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
+   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
+   value.
+
+   If these assumptions can't be followed, operational procedures and
+   configuration must be slightly changed, or this mechanism can't be
+   used.
+
+   The assignment of multicast addresses is outside the scope of this
+   document; it is up to the RP and applications to ensure that group
+   addresses are unique by using some unspecified method.  However, the
+   mechanisms are probably similar to those used with [RFC3306].
+
+   Similarly, RP failure management methods, such as Anycast-RP, are out
+   of scope for this document.  These do not work without additional
+   specification or deployment.  This is covered briefly in Section 6.1.
+
+
+
+
+
+Savola & Haberman           Standards Track                     [Page 3]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+1.4.  Terminology
+
+   Embedded-RP behaves as if all the members of the group were intra-
+   domain to the information distribution. However, as it gives a
+   solution for the global IPv6 multicast Internet, spanning multiple
+   administrative domains, we say it is a solution for inter-domain
+   multicast.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   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
+
+   As described in [RFC3306], the multicast address format is as
+   follows:
+
+      |   8    |  4 |  4 |   8    | 8  |       64       |    32    |
+      +--------+----+----+--------+----+----------------+----------+
+      |11111111|flgs|scop|reserved|plen| network prefix | group ID |
+      +--------+----+----+--------+----+----------------+----------+
+
+   Where flgs are "0011".  (The first two bits are as yet undefined,
+   sent as zero and ignored on receipt.)
+
+
+
+
+
+
+
+
+
+
+
+Savola & Haberman           Standards Track                     [Page 4]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+3.  Modified Unicast-Prefix-based Address Format
+
+   This memo specifies a modification to the unicast-prefix-based
+   address format by specifying the second high-order bit ("R-bit") as
+   follows:
+
+      |   8    |  4 |  4 |  4 |  4 | 8  |       64       |    32    |
+      +--------+----+----+----+----+----+----------------+----------+
+      |11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID |
+      +--------+----+----+----+----+----+----------------+----------+
+                                      +-+-+-+-+
+      flgs is a set of four flags:    |0|R|P|T|
+                                      +-+-+-+-+
+
+   When the highest-order bit is 0, 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 specified in [RFC3306].  In
+   effect, this implies the prefix FF70::/12.  In this case, the last 4
+   bits of the previously reserved field are interpreted as embedding
+   the RP interface ID, as specified 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, the encoding and the
+   protocol mode used when the two high-order bits in "flgs" are set to
+   11 ("FFF0::/12") is intentionally unspecified until such time that
+   the highest-order bit is defined.  Without further IETF
+   specification, implementations SHOULD NOT treat the FFF0::/12 range
+   as Embedded-RP.
+
+   R = 0 indicates a multicast address that does not embed the address
+   of the RP and follows the semantics defined in [ADDRARCH] and
+   [RFC3306].  In this context, the value of "RIID" MUST be sent as zero
+   and MUST be ignored on receipt.
+
+4.  Embedding the Address of the RP in the Multicast Address
+
+   The address of the RP can only be embedded in unicast-prefix-based
+   ASM addresses.
+
+   That is, to identify whether it is a multicast address as specified
+   in this memo and to be processed any further, an address must satisfy
+   all of the following:
+
+   o It MUST be a multicast address with "flgs" set to 0111, that is, to
+      be of the prefix FF70::/12,
+
+   o  "plen" MUST NOT be 0 (i.e., not SSM), and
+
+
+
+
+Savola & Haberman           Standards Track                     [Page 5]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+   o  "plen" MUST NOT be greater than 64.
+
+   The address of the RP can be obtained from a multicast address
+   satisfying the above criteria by taking the following two steps:
+
+   1. Copy the first "plen" bits of the "network prefix" to a zeroed
+      128-bit address structure, and
+
+   2. replace the last 4 bits with the contents of "RIID".
+
+   These two steps could be illustrated as follows:
+
+      | 20 bits | 4  | 8  |       64       |    32    |
+      +---------+----+----+----------------+----------+
+      |xtra bits|RIID|plen| network prefix | group ID |
+      +---------+----+----+----------------+----------+
+                  ||    \\  vvvvvvvvvvv
+                  ||     ``====> copy plen bits of "network prefix"
+                  ||       +------------+--------------------------+
+                  ||       | network pre| 0000000000000000000000   |
+                  ||       +------------+--------------------------+
+                   \\
+                    ``=================> copy RIID to the last 4 bits
+                           +------------+---------------------+----+
+                           | network pre| 0000000000000000000 |RIID|
+                           +------------+---------------------+----+
+
+   One should note that there are several operational scenarios (see
+   Example 3 below) when the [RFC3306] statement "all non-significant
+   bits of the network prefix field SHOULD be zero" is ignored.  This is
+   to allow multicast group address allocations to be consistent with
+   unicast prefixes; the multicast addresses would still use the RP
+   associated with the network prefix.
+
+   "plen" higher than 64 MUST NOT be used, as that would overlap with
+   the high-order bits of multicast group-id.
+
+   When processing an encoding to get the RP address, the multicast
+   routers MUST perform at least the same address validity checks to the
+   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
+   MUST be excluded.  This is particularly important, as the information
+   is obtained from an untrusted source, i.e., any Internet user's
+   input.
+
+   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
+   ID -- without varying any of these, one can have 2^4-1 = 15 different
+
+
+
+Savola & Haberman           Standards Track                     [Page 6]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+   RPs (as RIID=0 is reserved, see section 6.3).  However, each of these
+   is an IPv6 group address of its own (i.e., there can be only one RP
+   per multicast address).
+
+5.  Examples
+
+   Four examples of multicast address allocation and resulting group-
+   to-RP mappings are described here to better illustrate the
+   possibilities provided by the encoding.
+
+5.1.  Example 1
+
+   The network administrator of 2001:DB8::/32 wants to set up an RP for
+   the network and all the customers, by placing it on an existing
+   subnet, e.g., 2001:DB8:BEEF:FEED::/64.
+
+   In that case, the group addresses would be something like
+   "FF7x:y40:2001:DB8:BEEF:FEED::/96", and then their RP address would
+   be "2001:DB8:BEEF:FEED::y".  There are still 32 bits of multicast
+   group-ids to assign to customers and self ("y" could be anything from
+   1 to F, as 0 must not be used).
+
+5.2.  Example 2
+
+   As in Example 1, the network administrator of 2001:DB8::/32 wants to
+   set up the RP but, to make it more flexible, wants to place it on a
+   specifically routed subnet and wants to keep larger address space for
+   group allocations.  That is, the administrator selects the least
+   specific part of the unicast prefix, with plen=32, and the group
+   addresses will be from the multicast prefix:
+
+      FF7x:y20:2001:DB8::/64
+
+   where "x" is the multicast scope, "y" is the interface ID of the RP
+   address, and there are 64 bits for group-ids or assignments.  In this
+   case, the address of the RP would be:
+
+      2001:DB8::y
+
+   The address 2001:DB8::y/128 is assigned to a router as a loopback
+   address and is injected into the routing system; if the network
+   administrator sets up only one or two RPs (and, e.g., not one RP per
+   subnet), this approach may be preferable to the one described in
+   Example 1.
+
+
+
+
+
+
+
+Savola & Haberman           Standards Track                     [Page 7]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+5.3.  Example 3
+
+   As in Example 2, the network administrator can also assign multicast
+   prefixes such as "FF7x:y20:2001:DB8:DEAD::/80" to some of customers.
+   In 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 individual group-
+   ids.)
+
+   Note the second rule of deriving the RP address: the "plen" field in
+   the multicast address, 0x20 = 32, refers to the length of "network
+   prefix" field considered when obtaining the RP address.  In this
+   case, only the first 32 bits of the network prefix field, "2001:DB8",
+   are preserved: the value of "plen" takes no stance on actual
+   unicast/multicast prefix lengths allocated or used in the networks,
+   here from 2001:DB8:DEAD::/48.
+
+   In short, this distinction allows more flexible RP address
+   configuration in the scenarios where it is desirable to have the
+   group addresses be consistent with the unicast prefix allocations.
+
+5.4.  Example 4
+
+   In the network of Examples 1, 2, and 3, the network admin sets up
+   addresses for use by customers, but an organization wants to have its
+   own PIM-SM domain.  The organization can pick multicast addresses
+   such as "FF7x:y30:2001:DB8:BEEF::/80", and then the RP address would
+   be "2001:DB8:BEEF::y".
+
+6.  Operational Considerations
+
+   This section describes the major operational considerations for those
+   deploying this mechanism.
+
+6.1.  RP Redundancy
+
+   A technique called "Anycast RP" is used within a PIM-SM domain to
+   share an address and multicast state information between a set of RPs
+   mainly for redundancy purposes.  Typically, MSDP has been used for
+   this as well [ANYCASTRP].  There are also other approaches, such as
+   using PIM for sharing this information [ANYPIMRP].
+
+   The most feasible candidate for RP failover is using PIM for Anycast
+   RP or "anycasting" (i.e., the shared-unicast model [ANYCAST]) the RP
+   address in the Interior Gateway Protocol (IGP) without state sharing
+   (although depending on the redundancy requirements, this may or may
+   not be enough).  However, the redundancy mechanisms are outside of
+   the scope of this memo.
+
+
+
+Savola & Haberman           Standards Track                     [Page 8]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+6.2.  RP Deployment
+
+   As there is no need to share inter-domain state with MSDP, each
+   Designated Router connecting multicast sources could act as an RP
+   without scalability concerns about setting up and maintaining MSDP
+   sessions.
+
+   This might be particularly attractive when one is concerned about RP
+   redundancy.  In the case where the DR close to a major source for a
+   group acts as the RP, a certain amount of fate-sharing properties can
+   be obtained without using any RP failover mechanisms: if the DR goes
+   down, the multicast transmission may not work anymore in any case.
+
+   Along the same lines, its may also be desirable to distribute the RP
+   responsibilities to multiple RPs.  As long as different RPs serve
+   different groups, this is trivial: each group could map to a
+   different RP (or sufficiently many different RPs that the load on one
+   RP is not a problem).  However, load sharing challenges one group
+   faces are similar to those of Anycast-RP.
+
+6.3.  Guidelines for Assigning IPv6 Addresses to RPs
+
+   With this mechanism, the RP can be given basically any unicast
+   network prefix up to /64. The interface identifier will have to be
+   manually configured to match "RIID".
+
+   RIID = 0 must not be used, as using it would cause ambiguity with the
+   Subnet-Router Anycast Address [ADDRARCH].
+
+   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
+   unicast prefix (e.g., an additional loopback address assigned on a
+   router, as described in Example 2 in Section 5.1), that address can
+   be injected into the routing system via a host route.
+
+6.4.  Use as a Substitute for BSR
+
+   With embedded-RP, use of BSR or other RP configuration mechanisms
+   throughout the PIM domain is not necessary, as each group address
+   specifies the RP to be used.
+
+6.5.  Controlling the Use of RPs
+
+   Compared to the MSDP inter-domain ASM model, the control and
+   management of who can use an RP, and how, changes slightly and
+   deserves explicit discussion.
+
+
+
+
+
+Savola & Haberman           Standards Track                     [Page 9]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+   MSDP advertisement filtering typically includes at least two
+   capabilities: filtering who is able to create a global session
+   ("source filtering") and filtering which groups should be globally
+   accessible ("group filtering").  These are done to prevent local
+   groups from being advertised to the outside or unauthorized senders
+   from creating global groups.
+
+   However, such controls do not yet block the outsiders from using such
+   groups, as they could join the groups even without Source Active
+   advertisement with a (Source, Group) or (S,G) Join by
+   guessing/learning the source and/or the group address.  For proper
+   protection, one should set up, for example, PIM multicast scoping
+   borders at the border routers.  Therefore, embedded-RP has by default
+   a roughly equivalent level of "protection" as MSDP with SA filtering.
+
+   A new issue with control is that nodes in a "foreign domain" may
+   register to an RP, or send PIM Join to an RP.  (These have been
+   possible in the past as well, to a degree, but only through willful
+   attempts or purposeful RP configuration at DRs.)  The main threat in
+   this case is that an outsider may illegitimately use the RP to host
+   his/hers own group(s).  This can be mitigated to an extent by
+   filtering which groups or group ranges are allowed at the RP; more
+   specific controls are beyond the scope of this memo.  Note that this
+   does not seem to be a serious threat in the first place, as anyone
+   with a /64 unicast prefix can create their own RP without having to
+   illegitimately get it from someone else.
+
+7.  The Embedded-RP Group-to-RP Mapping Mechanism
+
+   This section specifies the group-to-RP mapping mechanism for Embedded
+   RP.
+
+7.1.  PIM-SM Group-to-RP Mapping
+
+   The only PIM-SM modification required is implementing this mechanism
+   as one group-to-RP mapping method.
+
+   The implementation will have to recognize the address format and
+   derive and use the RP address by using the rules in Section 4.  This
+   information is used at least when performing Reverse Path Forwarding
+   (RPF) lookups, when processing Join/Prune messages, or performing
+   Register-encapsulation.
+
+   To avoid loops and inconsistencies, for addresses in the range
+   FF70::/12, the Embedded-RP mapping MUST be considered the longest
+   possible match and higher priority than any other mechanism.
+
+
+
+
+
+Savola & Haberman           Standards Track                    [Page 10]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+   It is worth noting that compared to the other group-to-RP mapping
+   mechanisms, which can be precomputed, the embedded-RP mapping must be
+   redone for every new IPv6 group address that would map to a different
+   RP.  For efficiency, the results may be cached in an implementation-
+   specific manner, to avoid computation for every embedded-RP packet.
+
+   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
+   receiver to the RP.  Paths for Shortest Path Tree (SPT) formation and
+   Register-Stop do not require the support, as those are accomplished
+   with an (S,G) Join.
+
+7.2.  Overview of the Model
+
+   This section gives a high-level, non-normative overview of how
+   Embedded RP operates, as specified in the previous section.
+
+   The steps when a receiver wishes to join a group are as follows:
+
+   1. A receiver finds out a group address by some means (e.g., SDR or a
+      web page).
+
+   2. The receiver issues an Multicast Listener Discovery (MLD) Report,
+      joining the group.
+
+   3. The receiver's DR will initiate the PIM-SM Join process towards
+      the RP encoded in the multicast address, irrespective of whether
+      it is in the "local" or "remote" PIM domain.
+
+   The steps when a sender wishes to send to a group are as follows:
+
+   1. A sender finds out a group address by using an unspecified method
+      (e.g., by contacting the administrator for group assignment or
+      using a multicast address assignment protocol).
+
+   2. The sender sends to the group.
+
+   3. The sender's DR will send the packets unicast-encapsulated in
+      PIM-SM Register-messages to the RP address encoded in the
+      multicast address (in the special case that DR is the RP, such
+      sending is only conceptual).
+
+   In fact, all the messages go as specified in [PIM-SM]; embedded-RP
+   just acts as a group-to-RP mapping mechanism.  Instead of obtaining
+   the address of the RP from local configuration or configuration
+   protocols (e.g., BSR), the algorithm derives it transparently from
+   the encoded multicast address.
+
+
+
+
+Savola & Haberman           Standards Track                    [Page 11]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+8.  Scalability Analysis
+
+   Interdomain MSDP model for connecting PIM-SM domains is mostly
+   hierarchical in configuration and deployment, but flat with regard to
+   information distribution.  The embedded-RP inter-domain model behaves
+   as if every group formed its own Internet-wide PIM domain, with the
+   group mapping to a single RP, wherever the receivers or senders are
+   located.  Hence, the inter-domain multicast becomes a flat, RP-
+   centered topology.  The scaling issues are described below.
+
+   Previously, foreign sources sent the unicast-encapsulated data to
+   their "local" RP; now they are sent to the "foreign" RP responsible
+   for the specific group.  This is especially important with large
+   multicast groups where there are a lot of heavy senders --
+   particularly if implementations do not handle unicast-decapsulation
+   well.
+
+   With IPv4 ASM multicast, there are roughly two kinds of Internet-wide
+   state: MSDP (propagated everywhere), and multicast routing state (on
+   the receiver or sender branches).  The former is eliminated, but the
+   backbone routers might end up with (*, G) and (S, G, rpt) state
+   between receivers (and past receivers, for PIM Prunes) and the RP, in
+   addition to (S, G) states between the receivers and senders, if SPT
+   is used.  However, the total amount of state is smaller.
+
+   In both inter-domain and intra-domain cases, the embedded-RP model is
+   practically identical to the traditional PIM-SM in intra-domain.  On
+   the other hand, PIM-SM has been deployed (in IPv4) in inter-domain
+   using MSDP; compared to that inter-domain model, this specification
+   simplifies the tree construction (i.e., multicast routing) by
+   removing the RP for senders and receivers in foreign domains and
+   eliminating the MSDP information distribution.
+
+   As the address of the RP is tied to the multicast address, the RP
+   failure management becomes more difficult, as the deployed failover
+   or redundancy mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be
+   used as-is.  However, Anycast-RP using PIM provides equal redundancy;
+   this described briefly in Section 6.1.
+
+   The PIM-SM specification states, "Any RP address configured or
+   learned MUST be a domain-wide reachable address".  What "reachable"
+   precisely means is not clear, even without embedded-RP.  This
+   statement cannot be proven, especially with the foreign RPs, as one
+   cannot even guarantee that the RP exists.  Instead of manually
+   configuring RPs and DRs (configuring a non-existent RP was possible,
+   though rare), with this specification the hosts and users using
+   multicast indirectly specify the RP themselves, lowering the
+   expectancy of the RP reachability.  This is a relatively significant
+
+
+
+Savola & Haberman           Standards Track                    [Page 12]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+   problem but not much different from the current multicast deployment:
+   e.g., MLDv2 (S,G) joins, whether ASM or SSM, yield the same result
+   [PIMSEC].
+
+   Being able to join/send to remote RPs raises security concerns that
+   are considered separately, but it has an advantage too: every group
+   has a "responsible RP" that is able to control (to some extent) who
+   is able to send to the group.
+
+   A more extensive description and comparison of the inter-domain
+   multicast routing models (traditional ASM with MSDP, embedded-RP,
+   SSM) and their security properties has been described in [PIMSEC].
+
+9.  Acknowledgements
+
+   Jerome Durand commented on an early version of this memo.  Marshall
+   Eubanks noted an issue regarding short plen values.  Tom Pusateri
+   noted problems with an earlier SPT-join approach.  Rami Lehtonen
+   pointed out issues with the scope of SA-state and provided extensive
+   commentary.  Nidhi Bhaskar gave the document a thorough review.
+   Toerless Eckert, Hugh Holbrook, and Dave Meyer provided very
+   extensive feedback.  In particular, Pavlin Radoslavov, Dino
+   Farinacci, Nidhi Bhaskar, and Jerome Durand provided good comments
+   during and after WG last call.  Mark Allman, Bill Fenner, Thomas
+   Narten, and Alex Zinin provided substantive comments during the IESG
+   evaluation.  The whole MboneD working group is also acknowledged for
+   continued support and comments.
+
+10.  Security Considerations
+
+   The addresses of RPs are encoded in the multicast addresses, thus
+   becoming more visible as single points of failure.  Even though this
+   does not significantly affect the multicast routing security, it may
+   expose the RP to other kinds of attacks.  The operators are
+   encouraged to pay special attention to securing these routers.  See
+   Section 6.1 for considerations regarding failover and Section 6.2 for
+   placement of RPs leading to a degree of fate-sharing properties.
+
+   As any RP will have to accept PIM-SM Join/Prune/Register messages
+   from any DR, this might cause a potential Denial of Service attack
+   scenario.  However, this can be mitigated, as the RP can discard all
+   such messages for all multicast addresses that do not encode the
+   address of the RP.  Both the sender- and receiver-based attacks are
+   described at greater length in [PIMSEC].
+
+
+
+
+
+
+
+Savola & Haberman           Standards Track                    [Page 13]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+   Additionally, the implementation SHOULD also allow manual
+   configuration of which multicast prefixes are allowed to be used.
+   This can be used to limit the use of the RP to designated groups
+   only.  In some cases, being able to restrict (at the RP) which
+   unicast addresses are allowed to send or join to a group is
+   desirable.  (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).  Further, multicast groups or group ranges to-be-served MAY
+   need to be explicitly configured at the RPs, to protect them from
+   being used unwillingly.  Note that the more specific controls (e.g.,
+   "insider-must-create" or "invite-outsiders" models) as to who is
+   allowed to use the groups are beyond the scope of this memo.
+
+   Excluding internal-only groups from MSDP advertisements does not
+   protect the groups from outsiders but only offers security by
+   obscurity; embedded-RP offers similar level of protection.  When real
+   protection is desired, PIM scoping for example, should be set up at
+   the borders. This is described at more length in Section 6.5.
+
+   One should observe that the embedded-RP threat model is actually
+   rather similar to SSM; both mechanisms significantly reduce the
+   threats at the sender side.  On the receiver side, the threats are
+   somewhat comparable, as an attacker could do an MLDv2 (S,G) join
+   towards a non-existent source, which the local RP could not block
+   based on the MSDP information.
+
+   The implementation MUST perform at least the same address validity
+   checks to the embedded-RP address as it would to one received via
+   other means; at least fe80::/10, ::/16, and ff00::/8 should be
+   excluded.  This is particularly important, as the information is
+   derived from the untrusted source (i.e., any user in the Internet),
+   not from the local configuration.
+
+   A more extensive description and comparison of the inter-domain
+   multicast routing models (traditional ASM with MSDP, embedded-RP,
+   SSM) and their security properties has been done separately in
+   [PIMSEC].
+
+
+
+
+
+
+
+Savola & Haberman           Standards Track                    [Page 14]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+11.  References
+
+11.1.  Normative References
+
+   [ADDRARCH]  Hinden, R. and S. Deering, "Internet Protocol Version 6
+               (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3306]   Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
+               Multicast Addresses", RFC 3306, August 2002.
+
+11.2.  Informative References
+
+   [ANYCAST]   Hagino, J. and K. Ettikan, "An analysis of IPv6 anycast",
+               Work in Progress, June 2003.
+
+   [ANYCASTRP] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci,
+               "Anycast Rendevous Point (RP) mechanism using Protocol
+               Independent Multicast (PIM) and Multicast Source
+               Discovery Protocol (MSDP)", RFC 3446, January 2003.
+
+   [ANYPIMRP]  Farinacci, D. and Y. Cai, "Anycast-RP using PIM", Work in
+               Progress, June 2004.
+
+   [BSR]       Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for
+               PIM Sparse Mode", Work in Progress, July 2004.
+
+   [MSDP]      Fenner, B. and D. Meyer, "Multicast Source Discovery
+               Protocol (MSDP)", RFC 3618, October 2003.
+
+   [PIMSEC]    Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast
+               Routing Security Issues and Enhancements", Work in
+               Progress, October 2004.
+
+   [PIM-SM]    Fenner, B. et al, "Protocol Independent Multicast -
+               Sparse Mode (PIM-SM): Protocol Specification (Revised)",
+               Work in Progress, July 2004.
+
+   [SSM]       Holbrook, H. et al, "Source-Specific Multicast for IP",
+               Work in Progress, September 2004.
+
+   [V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", Work in
+               Progress, September 2004.
+
+
+
+
+
+
+Savola & Haberman           Standards Track                    [Page 15]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+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
+   leftmost reserved bits instead ("FF3x:8000::/17").
+
+   It has been argued that instead of allowing the operator to specify
+   RIID, the value could be pre-determined (e.g., "1").  However, this
+   has not been adopted, as this eliminates address assignment
+   flexibility from the operator.
+
+   Values 64 < "plen" < 96 would overlap with upper bits of the
+   multicast group-id; due to this restriction, "plen" must not exceed
+   64 bits.  This is in line with RFC 3306.
+
+   The embedded-RP addressing could be used to convey other information
+   (other than RP address) as well, for example, what should be the RPT
+   threshold for PIM-SM.  These could be, whether feasible or not,
+   encoded in the RP address somehow, or in the multicast group address.
+   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
+   much state is being generated to reach in a resource exhaustion
+   Denial of Service attack, some forms of rate-limiting or other
+   mechanisms could be deployed to mitigate the threats while trying not
+   to disturb the legitimate usage.  However, as the threats are
+   generic, they are considered out of scope and discussed separately in
+   [PIMSEC].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savola & Haberman           Standards Track                    [Page 16]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+Authors' Addresses
+
+   Pekka Savola
+   CSC/FUNET
+   Espoo, Finland
+
+   EMail: psavola@funet.fi
+
+
+   Brian Haberman
+   Johns Hopkins University Applied Physics Lab
+   11100 Johns Hopkins Road
+   Laurel, MD  20723-6099
+   US
+
+   Phone: +1 443 778 1319
+   EMail: brian@innovationslab.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savola & Haberman           Standards Track                    [Page 17]
+
+RFC 3956        The RP Address in IPv6 Multicast Address   November 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   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
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Savola & Haberman           Standards Track                    [Page 18]
+