mboned Working Group                                           P. Savola
Internet Draft                                                 CSC/FUNET
Expiration Date: April August 2004
                                                             B. Haberman
                                                        Caspian Networks

                                                            October 2003

                                                           February 2004

Embedding the Rendezvous Point (RP) Address of RP in an IPv6 Multicast Address

                  draft-ietf-mboned-embeddedrp-00.txt

                  draft-ietf-mboned-embeddedrp-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

Abstract

   There exists a huge

   A very difficult deployment problem with global, interdomain IPv6
   multicast:
   multicast using Protocol Independent Multicast - Sparse Mode (PIM-SM)
   Rendezvous Points (RPs) have no way of communicating the information
   about multicast sources to other multicast domains, as there is no
   Multicast Source Discovery Protocol (MSDP), and the whole interdomain
   Any Source Multicast (ASM) model is rendered unusable; Source
   Specific Multicast (SSM) avoids these problems but is not considered
   readily deployable at the moment.
   has been identified.  This memo defines a PIM-SM group-
   to-RP mapping an address allocation policy
   in which encodes the address of the RP Rendezvous Point (RP) is encoded in the
   IPv6 multicast group address. In consequence, there would  For PIM-SM, this can be no need for
   interdomain MSDP, seen as a
   specification of a group-to-RP mapping mechanism.  This allows an
   easy deployment of scalable inter-domain multicast, and even simplifies
   the intra-domain RP multicast configuration could be
   simplified. as well.  This memo updates
   the addressing format presented in RFC 3306.

Table of Contents

   1.  Introduction  ...............................................   2
   2.  Unicast-Prefix-based Address Format  ........................   4
   3.  Modified Unicast-Prefix-based Address Format  ...............   4
   4.  Embedding the Address of the RP in the Multicast Address  ...   5
   5.  Examples  ...................................................   6
     5.1.  Example 1  ..............................................   6
     5.2.  Example 2  ..............................................   6   7
     5.3.  Example 3  ..............................................   6   7
     5.4.  Example 4  ..............................................   7
   6.  Operational Requirements  ................................... Considerations  .................................   7
     6.1.  Anycast-RP  .............................................  RP Redundancy  ..........................................   7
     6.2.  RP Deployment  ..........................................   8
     6.3.  Guidelines for Assigning IPv6 Addresses to RPs  .........   7   8
   7.  Required  PIM-SM Protocol Modifications  ..............................   7   8
     7.1.  PIM-SM Group-to-RP Mapping  .............................   9
     7.2.  Overview of the Model  ..................................   9
   8.  Scalability/Usability Analysis  .............................   9  10
   9.  Acknowledgements  ...........................................  11
   10.  Security Considerations  ...................................  11
   11.  References  ................................................  12  13
     11.1.  Normative References  ..................................  12  13
     11.2.  Informative References  ................................  12  13
   Authors' Addresses  .............................................  13  14
   A.  Discussion about Design Tradeoffs  ..........................  13  14
   B.  Changes since -00  ..........................................  15
   Intellectual Property Statement  ................................  14  15
   Full Copyright Statement  .......................................  15  16

1. Introduction

   As has been noticed [V6MISSUES], there exists a huge deployment problem
   with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no
   way of communicating the information about multicast sources to other
   multicast domains, as there is no MSDP [MSDP], and Multicast Source Discovery Protocol
   (MSDP) [MSDP] (at least yet). Therefore the whole interdomain Any
   Source Multicast model is rendered unusable; SSM Source-Specific
   Multicast (SSM) [SSM] avoids these problems.

   It problems but is not a complete
   solution for several reasons.

   Further, it has been noted that there are some problems with SSM deployment the
   support and support: deployment of mechanisms SSM would require: it seems
   unlikely that SSM could be usable as the only interdomain multicast
   routing mechanism in the short term.

   This memo
   proposes describes a fix to interdomain multicast routing, and provides an
   additional method for the RP discovery with the intra-domain case.

   This document proposes a solution to the group-to-RP mapping problem address allocation policy in which leverages and extends [RFC3306] by encoding
   the RP address of the RP is encoded in the IPv6 multicast group into address,
   and specifies a PIM-SM group-to-RP mapping to use the group address itself. encoding,
   leveraging and extending the unicast-prefix -based addressing
   [RFC3306].

   This mechanism not only provides a simple solution for IPv6
   interdomain ASM Any Source Multicast (ASM) but can be used as a simple
   solution for IPv6 intradomain ASM on scoped addresses, addresses as well. The use as a substitute
   for Bootstrap Router protocol (BSR) [BSR] is  It
   can also possible. be used in those deployment scenarios which would have
   previously used the Bootstrap Router protocol (BSR) [BSR].

   The solution consists of two elements applicable to three elements:

     o A specification of a subrange of [RFC3306] IPv6 multicast group
       addresses which are defined by setting one previously unused bit of the
       Flags field to "1": "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 specification of optional and mandatory procedures to operate
       ASM with PIM-SM on these IPv6 multicast groups.

   Addresses in this the subrange will be called embedded-RP embedded RP addresses.  If
   used in  This
   scheme obviates the interdomain, a mechanism similar to MSDP is not required need for these addresses inter-domain MSDP, and RP configuration for these addresses can be
   as simple as zero configuration for the routers supporting this
   specification.

   It is self-evident that are
   not required to include any multicast configuration, except when they
   act as an RP.

   In general, a 128 bit 128-bit RP address can in general not can't be embedded into a 128-bit
   group address with space left to carry a the group identity itself. An
   appropriate form of encoding is thus defined, and it is assumed that
   the Interface-ID of RPs in the
   embedded-RP embedded RP range can be assigned to
   be a specific values. value.

   If these assumptions can't be followed, either operational procedures
   and configuration must be slightly changed or this mechanism can not
   be used.

   The assignment of multicast addresses is outside the scope of this
   document; however, it is up to the RP and applications to ensure that group
   addresses are unique using some unspecified method.  However, the
   mechanisms are very probably similar to ones 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.

   This memo updates the addressing format presented in RFC 3306.

   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].

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 yet undefined undefined, sent
   as zero and
   thus zero.) ignored on receipt.)

3. Modified Unicast-Prefix-based Address Format

   This memo proposes specifies a modification to the unicast-prefix-based
   address format:

      1. If the second high-order bit in "flgs" is set to 1, the address
         of the RP is embedded in the multicast address, as described in
         this memo.

      2. If the second high-order bit in "flgs" was is set to 1, interpret
         the last low-order 4 bits of "reserved" field as signifying the
         RP interface ID, as described in this memo.

   In consequence, the address format becomes:

        |   8    |  4 |  4 |  4 |  4 |    8   |       64       |    32    |
        +--------+----+----+----+----+--------+----------------+----------+
        |11111111|flgs|scop|rsvd|RPad|
        |11111111|flgs|scop|rsvd|RIID|  plen  | network prefix | group ID |
        +--------+----+----+----+----+--------+----------------+----------+
                                        +-+-+-+-+
        flgs is a set of 4 flags:       |0|R|P|T|
                                        +-+-+-+-+

   R = 1 indicates a multicast address that embeds the address of on the
   PIM-SM
   RP.  Then P MUST BE set to 1, and consequently T MUST be set to 1, as
   specified in [RFC3306].

   In the case that R = 1, the last 4 bits of the previously reserved
   field
   ("RPad") are interpreted as embedding the RP interface ID of the RP, ("RIID"), as
   specified in this memo.

   R = 0 indicates a multicast address that does not embed the address
   of the PIM-SM RP and follows the semantics defined in [ADDRARCH] and
   [RFC3306].  In this context, the value of "RPad" has no meaning. "RIID" MUST be 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.

   To identify whether an address is a multicast address as specified in
   this memo and to be processed any further, it must satisfy all of the
   below:

     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 FF7::/12 prefixes FF70::/12 or FFF::/12), FFF0::/12),

     o "plen" MUST NOT be 0 (ie. not SSM), and

     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. take copy the last 96 first "plen" bits of the multicast "network prefix" to a zeroed
         128-bit address add 32 zero bits
         at the end,

      2. zero the last 128-"plen" bits, structure, and

      3.
      2. replace the last 4 bits with the contents of "RPad". "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 |ID|
                             +------------+---------------------+--+
   One should note that there are several operational scenarios (see
   Example 2 below) when [RFC3306] statement "all non-significant bits
   of the network prefix field SHOULD be zero" is ignored -- and why the second step, above,
   is necessary. ignored.  This is to
   allow multicast address assignments to third parties which still use your RP; see example 2 below.
   the RP associated with the network prefix.

   "plen" higher than 64 MUST NOT be used as that would overlap with the
   upper bits of multicast group-id.

   The implementation

   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), to avoid e.g. e.g., the address being "::" "::",
   "::1", or "::1". a link-local address.

   One should note that the 4 bits reserved for "RPad" "RIID" set the upper
   bound for RPs per multicast group address; not for the number combination of RPs in a
   subnet, PIM-SM domain or large-scale network. scope, network prefix, and group
   ID -- without varying any of these, you can have 4 bits worth of
   different RPs.  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 3FFE:FFFF::/32 2001:DB8::/32 wants to set up an RP for
   the network and all of his customers.  He  (S)he chooses network
   prefix=3FFE:FFFF
   prefix=2001:DB8 and plen=32, and wants to use this addressing
   mechanism.  The multicast addresses he (s)he will be able to use are of
   the form:

        FF7x:y20:3FFE:FFFF:zzzz:zzzz:<group-id>

        FF7x:y20:2001:DB8:zzzz:zzzz:<group-id>

   Where "x" is the multicast scope, "y" the interface ID of the RP
   address, and "zzzz:zzzz" will be freely assignable within the PIM-SM
   domain. In this case, the address of the PIM-SM RP would be:

        3FFE:FFFF::y

        2001:DB8::y

   (and "y" could be anything from 0 to F); the address 3FFE:FFFF::y/128 2001:DB8::y/128
   is added as a Loopback address and injected to the routing system.

5.2. Example 2

   As above, in Example 1, the network administrator can also allocate
   multicast addresses like "FF7x:y20:3FFE:FFFF:DEAD::/80" "FF7x:y20:2001:DB8:DEAD::/80" to some of his
   customers within the PIM-SM domain.  In this case the RP address
   would still be "3FFE:FFFF::y". "2001:DB8::y".

   Note the second rule of deriving the RP address: the "plen" field in
   the multicast address, (hex)20 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, "3FFE:FFFF" "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 3FFE:FFFF:DEAD::/48. 2001:DB8:DEAD::/48.

5.3. Example 3

   In the above network, network of Examples 1 and 2, the network admin sets up
   addresses as above, for use by their customers, but an organization wants to
   have their own PIM-SM domain; that's reasonable.  The organization
   can pick multicast addresses like
   "FF7x:y30:3FFE:FFFF:BEEF::/80", "FF7x:y30:2001:DB8:BEEF::/80", and
   then their RP address would be
   "3FFE:FFFF:BEEF::y". "2001:DB8:BEEF::y".

5.4. Example 4

   In the above networks, if the admin wants to specify the RP to be in
   a non-zero /64 subnet, he (s)he could always use something like
   "FF7x:y40:3FFE:FFFF:BEEF:FEED::/96",
   "FF7x:y40:2001:DB8:BEEF:FEED::/96", and then their RP address would
   be "3FFE:FFFF:BEEF:FEED::y". "2001:DB8:BEEF:FEED::y".  There are still 32 bits of multicast
   group-id's to assign to customers and self.

6. Operational Requirements Considerations

   This desction describes the major operational considerations for
   those deploying this mechanism.

6.1. Anycast-RP

   One should note that MSDP RP Redundancy

   A technique called "Anycast RP" is also used, in addition used within a PIM-SM domain to interdomain
   connections between RPs, in anycast-RP [ANYCASTRP] -technique, for
   sharing the
   share an address and multicast state information between different RPs in one PIM-SM
   domain.  However, there a set of
   RP's mainly for redundancy purposes.  Typically, MSDP has been used
   for that as well [ANYCASTRP].  There are also other propositions, approaches, like [ANYPIMRP].

   Anycast-RP mechanism is incompatible with this addressing method
   unless MSDP is specified and implemented.  Alternatively, another
   method
   using PIM for sharing state this information could be used.

   Anycast-RP and other possible [ANYPIMRP].

   RP failover cannot be used with this specification without additional
   mechanisms or techniques such as MSDP, PIM-SM extensions, or
   anycasting the RP address in the IGP without state sharing (depending
   on the redundancy requirements, this may or may not be enough,
   though).  However, the redundancy mechanisms are outside of the scope
   of this memo.

6.2. Guidelines for Assigning IPv6 Addresses RP Deployment

   As there is no need to RPs

   With this mechanism, the share inter-domain state with MSDP, each DR
   connecting multicast sources could act as an RP without scalability
   concerns about MSDP sessions.

   This might be particularly attractive when 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 given basically obtained without using any network RP failover mechanisms: if the DR goes
   down, the multicast transmission may not be all that interesting
   anymore in any case.

   Along the same lines, it's may also be desirable to distribute the RP
   responsibilities to multiple RPs.  As long as different RPs serve
   different groups, this is is trivial: each group should map to a
   different RP (or enough many different RPs that the load on one RP is
   not a problem).  However, load sharing one group faces the similar
   challenges as Anycast-RP.

6.3. Guidelines for Assigning IPv6 Addresses to RPs

   With this mechanism, the RP can be given basically any network prefix
   up to /64. The interface identifier will have to be manually
   configured to match "RPad".

   RPad "RIID".

   RIID = 0 SHOULD 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
   prefix (e.g. (e.g., an additional loopback address assigned on a router),
   that address can be injected into the routing system via a host
   route.

7. Required PIM-SM Protocol Modifications

   The use of multicast addresses with embedded RP addresses requires
   additional

   This section describes how PIM-SM processing.  Namely, a is modified, i.e., how the group-
   to-RP mapping mechanism works for Embedded RP.

7.1. PIM-SM router Group-to-RP Mapping

   The only PIM-SM modification required is implementing this mechanism
   as one group-to-RP mapping method.

   The implementation will need to
   be able have to recognize the encoding address format and
   derive and use the RP address from the
   address using the rules in section 4 Section 4.  This
   information is used at least when performing RPF lookups and to be able to use when
   processing Join/Prune messages, or performing Register-encapsulation.

   To avoid loops and inconsistancies, the
   embedded RP, instead of its own for multicast addresses group-to-RP mapping specified
   in this
   specified range.

   The three key places where these modifications are memo MUST be used are the
   Designated Routers (DRs) on for all embedded RP groups (i.e., with
   prefix FF70::/12 or FFF0::/12).

   It is worth noting that compared to the receiver/sender networks, other group-to-RP mappings,
   which can be precomputed, the
   backbone networks, and embedded RP mapping must be redone for
   every new IPv6 group address which would map to a different RP.  For
   efficiency, the RPs results may be cached in an implementation-specific
   manner.

   This group-to-RP mapping mechanism must be supported by the domain where DR
   adjacent to senders and any router on the embdedded
   address has been derived path from (see figure below).

   For any receiver to
   the foreign DRs (rtrR1, rtrR23, and rtrR4), this means sending
   PIM-SM Join/Prune/Register messages towards the foreign RP (rtrRP_S).
   Naturally, PIM-SM Register-Stop and other messages must RP.  It also must be
   allowed from the foreign RP.  DRs in the local PIM-SM domain (rtrS)
   do the same.

   For the RP (rtrRP_S), this means being able to recognize and validate
   PIM-SM messages which use RP-embedded addressing originated from supported by any
   DR at all.

   For the other routers on the path (rtrBB), this means recognizing and
   validating that the Join/Prune PIM-SM messages using the embedded RP
   addressing are router on the right path towards the RP they think is in
   charge of the particular address.

        nodeS - rtrS - rtrRP_S - rtrBB -----+--- rtrR1 - node1
                         |         |        |
        node2_S ---------+         |        +-- rtrR23 - node2
                                   |               |
                                   |               +---- node3
                                   |
                                   +------------ rtrR4 - node4

   In addition, the administration of the PIM-SM domains MAY have an
   option to manually override the RP selection for the embedded RP
   multicast addresses: the default policy SHOULD be to use the embedded
   RP.

   The extraction of the RP information from any
   sender to the multicast address
   should be done during forwarding state creation.  That is, if no
   state exists for the multicast address, PIM-SM must take the embedded RP information into account when creating forwarding state.  Unless
   otherwise dictated by the administrative policy, this would result -- in
   a receiver's DR initiating a PIM-SM Join towards case the foreign RP or issues a
   source's DR sending PIM-SM Register messages towards Register-Stop and Joins
   the foreign RP. sources.

   It should be noted that this approach removes the need to run inter-
   domain MSDP.  Multicast distribution trees in foreign networks can be
   joined by issuing a PIM-SM Join/Prune/Register to the RP address
   encoded in the multicast address.

   Also, the addressing model described here could be used to replace or
   augment the intra-domain Bootstrap Router mechanism (BSR), as the RP-
   mappings can be communicated by derived from the application of multicast address assignment.

7.1.
   assignmen policies.

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:

      1. A receiver finds out a group address from some means (e.g. (e.g., SDR
         or a web page).

      2. The receiver issues an MLD Report, joining the group.
      3. The receiver's DR will initiate the PIM-SM Join process towards
         the RP embedded in the multicast address.

   The steps when a sender wishes to send to a group are:

      1. A sender finds out a group address from some means, whether in
         an existing group (e.g. (e.g., SDR, web page) or in a new group (e.g.
         (e.g., a call to the administrator for group assignment, use of
         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 both cases, fact, all the messages then go on as specified in [PIM-SM] and
   other specifications (e.g.  Register-Stop and/or SPT Join); there is
   no difference in them except for -- embedded RP
   just acts as a group-to-RP mapping mechanism; instead of obtaining
   the fact that address of the RP address from local configuration or configuration
   protocols (e.g., BSR), it is derived transparently from the encoded
   multicast address.

   Sometimes, some information, using conventional mechanisms, about
   another RP exists in the PIM-SM domain.  The embedded RP SHOULD be
   used by default, but there MAY be an option to switch the preference.
   This is because especially when performing PIM-SM forwarding in the
   transit networks, the routers must have the same notion of the RP, or
   else the messages may be dropped.

8. Scalability/Usability Analysis

   Interdomain MSDP model for connecting

8. Scalability/Usability Analysis

   Interdomain MSDP model for connecting PIM-SM domains is mostly
   hierarchical.
   hierarchical in configuration and deployment, but flat with regard to
   information distribution.  The "embedded embedded RP address" changes this to a mostly
   flat, sender-centered, full-mesh virtual topology.

   This may or may not cause some effects; it may or may not be
   desirable.  At the very least, it makes many things much more robust inter-domain model behaves
   as the number of third parties is minimized.  A good scalability
   analysis is needed.

   In some cases (especially if e.g. every home user is employing site-
   local multicast), some degree all of hierarchy would be highly desirable,
   for scalability (e.g. to take the advantage of shared multicast
   state) and administrative point-of-view.

   Being able to join/send to remote RPs has security considerations
   that are considered below, but it has an advantage too: every group
   has Internet was a "home RP" which is able to control (to some extent) who are
   able to send to the single PIM domain, with just one RP
   per group.

   One should note that the model presented here simplifies  So, the PIM-SM inter-domain multicast routing model slightly by removing the RP for senders and
   receivers in foreign domains.  One scalability consideration should becomes a flat, RP-
   centered topology.  The scaling issues are be noted: previously described below.

   Previously foreign sources sent the unicast-encapsulated data to
   their local RP, now they do so 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.

   This model increases the amount of Internet-wide multicast state
   slightly: 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.  Certainly, the amount of inter-
   domain inter-domain multicast traffic
   between sources and the embedded-RP embedded RP will increase compared to the ASM
   model with MSDP; however, the domain
   responsible for the MSDP.

   The embedded RP model is expected practically identical in both inter-domain
   and intra-domain cases to be able 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 handle this. that inter-domain model, this specification
   simplifies the multicast routing by removing the RP for senders and
   receivers in foreign domains.

   As the address of the RP is tied to the multicast address, in the
   case of RP
   failure PIM-SM BSR management becomes more difficult, as failover or redundancy
   mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot pick a new RP; the
   failover mechanisms, if used, for backup RPs are different, and
   typically would depend on sharing one address.  The failover
   techniques are outside of the scope of this memo. be used as-is.
   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 this "reachable"
   precisely means is not clear, even without embedded-RP.  However, typically this embedded RP.  This
   statement cannot be proven especially with the foreign RPs (typically
   one (one can
   not even guarantee that the RP exists!).  The bottom line is
   that while traditionally the configuration  Instead of configuring RPs
   and DRs was
   typically with a manual process, and e.g. configuring process (configuring a non-existant non-existent RP was possible, but here
   possible though rare), with this specification the hosts and users which use
   using multicast indirectly specify the RP. RP themselves, lowering the
   expectancy of the RP reachability.

   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 "home RP" which is able to control (to some extent) who are
   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 draft of this memo.  Marshall
   Eubanks noted an issue regarding short plen values.  Tom Pusateri
   noted problems with earlier SPT-join approach.  Rami Lehtonen pointed
   out issues with the scope of SA-state and provided extensive
   commentary.  Nidhi Bhaskar gave the draft a thorough review.
   Toerless Eckert, Hugh Holbrook, and Dave Meyer provided very
   extensive feedback.  The whole MboneD working group is also
   acknowledged for the continued support and comments.

10. Security Considerations

   The address of the PIM-SM RP is embedded encoded in the multicast address.  RPs may
   be a good target for Denial of Service attacks -- as they are a
   single point of failure (excluding failover techniques) for a group.
   In this way, the target would be clearly visible.  However, it could
   be argued that if interdomain multicast was to be made to work
   e.g. e.g.,
   with MSDP, the address would have to be visible anyway (through via
   other channels, which may be more easily securable). channels).

   As any RP will have to accept PIM-SM Join/Prune/Register messages
   from any DR, this might cause a potential DoS attack scenario.
   However, this can be mitigated by the fact that the RP can discard
   all such messages for all multicast addresses that do not embed encode the
   address of the RP, and if deemed important, the implementation could
   also allow manual configuration of which multicast addresses or
   prefixes embedding the RP could be used, so that only the pre-agreed
   sources could use the RP.

   In a similar fashion, when a receiver joins to an RP, the DRs must
   accept similar PIM-SM messages back from RPs.

   One consequence of the embedded RP usage model is that it allows
   Internet-wide multicast state creation (from receiver(s) in another
   domain to the RP in another domain) compared to the domain wide state
   creation in the MSDP traditional ASM model.  However, the traditional ASM
   model also requires MSDP state to propagate everywhere in inter-
   domain, so the total amount of state is smaller.

   One should observe that the embedded RP threat model is actually
   pretty similar to SSM; both mechanisms significantly reduce the
   threats at the sender side, but have new ones in the receiver side,
   as any receiver can try to join any non-existant non-existent group or channel,
   and the local DR or RP cannot readily reject such joins (based (e.g., based on MSDP information).
   information) such joins.

   RPs may become a bit more single points of failure as anycast-RP mechanism is not
   (at least immediately) available.  This can be
   partially mitigated by the fact that  However, some other forms of
   failover are still possible, possible (see Section 6.1) and there should be less need to store state as one can obtain some
   forms of fate-sharing properties with
   MSDP. a proper placement of RPs (see
   Section 6.2).

   The implementation MUST perform at least the same address validity
   checks to the embedded RP address as to one received via other means
   (like BSR or MSDP), to avoid the address being e.g. "::" e.g., "::", "::1", or "::1".
   a link-local address.

   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].

11. References

11.1. Normative References

   [ADDRARCH]  Hinden, R., Deering, S., "IP Version 6 Addressing
               Architecture", RFC3513, April 2003.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3306]   Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6
               Multicast Addresses", RFC3306, August 2002.

11.2. Informative References

   [ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and
               MSDP", RFC 3446, January 2003.

   [ANYPIMRP]  Farinacci, D., Cai, Y., "Anycast-RP using PIM",
               work-in-progress, draft-farinacci-pim-anycast-rp-00.txt,
               January draft-ietf-pim-anycast-rp-00.txt,
               November 2003.

   [BSR]       Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for
               PIM Sparse Mode", work-in-progress, draft-ietf-pim-sm-
               bsr-03.txt, February 2003.

   [MSDP]      Meyer, D., Fenner, B, (Eds.), "Multicast Sourc Source
               Discovery Protocol (MSDP)", work-in-progress,
               draft-ietf-msdp-spec-20.txt, May RFC 3618, October 2003.

   [PIMSEC]    Savola, P., Lehtonen, R., Meyer, D., "PIM-SM Multicast
               Routing Security Issues and Enhancements",
               work-in-progress, draft-savola-mboned-mroutesec-00.txt,
               January 2004.

   [PIM-SM]    Fenner, B. et al, "Protocol Independent Multicast -
               Sparse Mode (PIM-SM): Protocol Specification (Revised),
               work-in-progress, draft-ietf-pim-sm-v2-new-08.txt,
               October 2003.

   [SSM]       Holbrook, H. et al, "Source-Specific Multicast for IP",
               work-in-progress, draft-ietf-ssm-arch-03.txt,
               May draft-ietf-ssm-arch-04.txt,
               October 2003.

   [V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues",
               work-in-progress, draft-savola-v6ops-multicast-
               issues-02.txt, October 2003.

Authors' Addresses

   Pekka Savola
   CSC/FUNET
   Espoo, Finland
   EMail: psavola@funet.fi

   Brian Haberman
   Caspian Networks
   One Park Drive, Suite 300
   Research Triangle Park, NC  27709
   EMail: brian@innovationslab.net
   Phone: +1-919-949-4828

A. Discussion about Design Tradeoffs

   The initial thought was to use only SPT join from local RP/DR to
   foreign RP, rather than a full PIM Join to foreign RP.  However, this
   turned out to be problematic, as this kind of SPT joins where
   disregarded because the path had not been set up before sending them.
   A full join to foreign PIM domain is a much clearer approach.

   One could argue that there should be more RPs than the 4-bit "RPad" "RIID"
   allows for, especially if anycast-RP cannot be used.  In that light,
   extending "RPad" "RIID" to take full advantage of whole 8 bits would seem
   reasonable.  However, this would use up all of the reserved bits, and
   leave no room for future flexibility.  In case of large number of
   RPs, an operational workaround could be to split the PIM domain: for
   example, using two /33's instead of one /32 would gain another 16 (or
   15, if zero is not used) RP addresses.  Note that the limit of 4 bits
   worth of RPs just depends on the prefix the RP address is derived
   from; one can use multiple prefixes in a domain, and the limit of 16
   (or 15) RPs should never really be a problem.

   Some hierarchy (e.g. two-level, "ISP/customer") for RPs could
   possibly be added if necessary, but that would be torturing one 128
   bits even more.

   One particular case, whether in the backbone or in the sender's
   domain, is where the regular PIM-SM RP would be X, and the embedded
   RP address would be Y.  This could e.g. be a result of a default all-
   multicast-to-one-RP group mapping, or a local policy decision.  The
   embedded RP SHOULD be used by default, but there MAY be an option to
   change this preference.

   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 encoded in the RP address
   somehow, or in the multicast group address.  However,  Whether this is a good
   idea is another thing.  In any case, such modifications are beyond
   the scope of this memo.

   Some kind

   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
   attack, some forms of rate-limiting functions, ICMP message responses, or
   similar other mechanisms could be defined for the case of when the RP embedded in
   deployed to mitigate the
   address is threats while trying not willing to serve for disturb the specific group (or doesn't
   even exist).  Typically this would result
   legitimate usage.  This has been described at more length in the datagrams getting
   blackholed or rejected
   [PIMSEC].

   The mechanism is not usable with ICMP.  In particular, a case for
   "rejection" or "source quench" -like messages would be in Bidirectional PIM without protocol
   extensions, as pre-computing the case
   that a source keeps transmitting a huge amount of data, which is sent
   to a foreign RP using Register message but Designated Forwarder is discarded if not
   possible.

B. Changes since -00

   [[ RFC-Editor: please remove before publication ]]

     o Lots of editorial cleanups, or cleanups without techinical
       changes.
     o Reinforce the notion of Embedded RP
   doesn't allow just being a group-to-RP
       mapping mechanism (causing substantive rewriting in section 7);
       highlight the source host to transmit: fact that precomputing the group-to-RP mapping is
       not possible.
     o Add (a bit) more text on RP should be able to
   indicate to redundancy and deployment tradeoffs
       wrt. RPs becoming SPoF.
     o Clarify the DR, "please limit usability/scalability issues in section 8.
     o Clarify the amount of Register messages",
   or "this source sending to my group is bogus".  Note that such "kiss-
   of-death" packets have an authentication problem; spoofing them could
   result security issues in an entirely different kind of Denial of Service, for
   legitimate sources.  One possibility here would be to specify some
   form of "return routability" check for DRs Sections 8, Security
       Considerations and RPs; for example, if Appendix A, mainly by referring to a
   DR receives packets from separate
       document.
     o Add a host to group G G (resulting in MUST that embedded RP address
   R), the DR would send only a limited amount of packets to R until it
   has heard back from R (a "positive acknowledgement").  It is not
   clear whether this needs to mappings must be considered or specified in more
   detail.

   Could this model work with bidir-PIM?  Is it feasible?  Not sure, not
   familiar enough with bidir-PIM. honored by
       implementations.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.