Network Working Group P. Savola
Request for Comments: 3956 CSC/FUNET
Updates: 3306 B. Haberman
Category: Standards Track JHU APL
November 2004
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
在IPv6多播地址中嵌入集合点（RP）地址
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（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.
此备忘录定义了一个地址分配策略，其中集合点（RP）的地址编码在IPv6多播组地址中。对于协议无关的多播稀疏模式（PIM-SM），这可以看作是组到RP映射机制的规范。这允许轻松部署可伸缩的域间多播，并简化域内多播配置。本备忘录更新了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
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
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
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
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.
正如已经注意到的[V6MISSUES]，全局域间IPv6多播存在部署问题：PIM-SM[PIM-SM]RPs无法将有关（活动）多播源的信息传送到其他多播域，因为故意没有为IPv6指定多播源发现协议（MSDP）[MSDP]。因此，整个域间任意源多播（ASM）模型变得不可用；源特定多播（SSM）[SSM]避免了这些问题，但由于以下几个原因，它不是一个完整的解决方案。
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.
此外，已经注意到SSM需要的机制的支持和部署存在一些问题[V6MISSUES]：SSM似乎不太可能在短期内可用作唯一的域间多播路由机制。
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].
本备忘录描述了多播地址分配策略，其中RP的地址编码在IPv6多播组地址中，并指定PIM-SM组到RP的映射，以使用基于编码、利用和扩展单播前缀的寻址[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.
该机制不仅为IPv6域间任意源多播提供了一个简单的解决方案，而且还可以用作具有作用域多播地址的IPv6域内ASM的简单解决方案。
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].
在以前使用引导路由器协议（BSR）[BSR]的部署场景中，它还可以用作自动RP发现机制。
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 [RFC3306]IPv6多播组地址子范围的规范，通过将标志字段的一个以前未使用的位设置为“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 映射规范，通过该映射规范，该组地址编码将与该组一起使用的RP地址，以及
o a description of operational procedures to operate ASM with PIM-SM on these IPv6 multicast groups.
o 描述在这些IPv6多播组上使用PIM-SM操作ASM的操作过程。
Addresses in the subrange will be called embedded-RP addresses.
子范围中的地址称为嵌入式RP地址。
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.
该方案消除了对MSDP的需求，并且路由器不需要包括任何多播配置，除非它们充当RP。
This memo updates the addressing format presented in RFC 3306.
本备忘录更新了RFC 3306中的寻址格式。
Some design tradeoffs are discussed in Appendix A.
附录A中讨论了一些设计权衡。
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.
128位RP地址不能嵌入到128位组地址中，其空间足以承载组标识本身。因此，通过要求嵌入式RP范围内的RPs接口ID可以指定为特定值来定义适当的编码形式。
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].
多播地址的分配不在本文件的范围内；由RP和应用程序使用一些未指定的方法来确保组地址是唯一的。然而，这些机制可能与[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.
类似地，RP故障管理方法（如Anycast RP）也不在本文件的范围内。如果没有额外的规范或部署，这些将无法工作。第6.1节简要介绍了这一点。
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.
嵌入式RP的行为就像组中的所有成员都是信息分布的域内成员一样。但是，由于它为跨多个管理域的全局IPv6多播Internet提供了解决方案，因此我们称它为域间多播的解决方案。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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
ASM任意源多播BSR引导路由器DR指定路由器IGP内部网关协议MLD多播侦听器发现MSDP多播源发现协议PIM协议独立多播PIM-SM协议独立多播-稀疏模式RIID RP接口ID（如本备忘录所述）RP集合点RPF反向路径转发SPT最短路径树SSM源特定组播
As described in [RFC3306], the multicast address format is as follows:
如[RFC3306]所述，多播地址格式如下：
| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+----+----------------+----------+
|11111111|flgs|scop|reserved|plen| network prefix | group ID |
+--------+----+----+--------+----+----------------+----------+
| 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.)
其中FLG为“0011”。（前两位尚未定义，发送为零，接收时忽略。）
This memo specifies a modification to the unicast-prefix-based address format by specifying the second high-order bit ("R-bit") as follows:
本备忘录通过指定第二高位（“R位”），指定对基于单播前缀的地址格式的修改，如下所示：
| 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|
+-+-+-+-+
| 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.
当最高阶位为0时，R=1表示将地址嵌入RP的多播地址。然后P必须设置为1，因此T必须设置为1，如[RFC3306]中所述。实际上，这意味着前缀FF70:：/12。在这种情况下，先前保留字段的最后4位被解释为嵌入RP接口ID，如本备忘录中所述。
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.
如果P或T未设置为1，则行为未指定，因为前缀将不是FF70:：/12。同样，当“flgs”中的两个高阶位被设置为11（“FFF0:：/12”）时使用的编码和协议模式有意地未指定，直到定义了最高阶位为止。如果没有进一步的IETF规范，实现不应将FFF0:：/12范围视为嵌入式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.
R=0表示一个多播地址，该地址不嵌入RP的地址，并遵循[ADDRARCH]和[RFC3306]中定义的语义。在此上下文中，“RIID”的值必须作为零发送，并且在收到时必须忽略。
The address of the RP can only be embedded in unicast-prefix-based ASM addresses.
RP的地址只能嵌入基于单播前缀的ASM地址中。
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 它必须是“flgs”设置为0111的多播地址，即前缀FF70:：/12，
o "plen" MUST NOT be 0 (i.e., not SSM), and
o “plen”不得为0（即非SSM），且
o "plen" MUST NOT be greater than 64.
o “plen”不得大于64。
The address of the RP can be obtained from a multicast address satisfying the above criteria by taking the following two steps:
RP的地址可以通过以下两个步骤从满足上述标准的多播地址获得：
1. Copy the first "plen" bits of the "network prefix" to a zeroed 128-bit address structure, and
1. 将“网络前缀”的第一个“plen”位复制到调零的128位地址结构，并
2. replace the last 4 bits with the contents of "RIID".
2. 将最后4位替换为“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|
+------------+---------------------+----+
| 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.
应注意，当[RFC3306]语句“网络前缀字段的所有非有效位均应为零”被忽略时，存在几种操作场景（参见下面的示例3）。这是为了允许多播组地址分配与单播前缀一致；多播地址仍将使用与网络前缀关联的RP。
"plen" higher than 64 MUST NOT be used, as that would overlap with the high-order bits of multicast group-id.
不得使用高于64的“plen”，因为这将与多播组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.
当处理编码以获取RP地址时，多播路由器必须对计算出的RP地址执行至少与通过其他方式（如BSR[BSR]或MSDP for IPv4）接收的RP地址相同的地址有效性检查。必须至少排除fe80:：/10、：：/16和ff00:：/8。这一点尤其重要，因为信息是从不可信的来源获得的，即任何互联网用户的输入。
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
应该注意，为“RIID”保留的4位为作用域、网络前缀和组ID的组合设置了RPs的上限——在不改变其中任何一个的情况下，可以有2^4-1=15个不同的值
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).
RPs（保留RIID=0，见第6.3节）。但是，每一个都是自己的IPv6组地址（即，每个多播地址只能有一个RP）。
Four examples of multicast address allocation and resulting group-to-RP mappings are described here to better illustrate the possibilities provided by the encoding.
这里描述了多播地址分配的四个示例以及由此产生的组到RP映射，以更好地说明编码提供的可能性。
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.
2001:DB8:：/32的网络管理员希望通过将RP放置在现有子网上，为网络和所有客户设置RP，例如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).
在这种情况下，组地址将类似于“FF7x:y40:2001:DB8:BEEF:FEED:：/96”，然后它们的RP地址将是“2001:DB8:BEEF:FEED:：y”。还有32位多播组ID要分配给客户和自己（“y”可以是1到F之间的任何值，因为不能使用0）。
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:
与示例1一样，2001:DB8:：/32的网络管理员希望设置RP，但为了使其更灵活，希望将其放置在特定路由的子网上，并希望为组分配保留更大的地址空间。也就是说，管理员选择单播前缀中最不特定的部分（plen=32），组地址将来自多播前缀：
FF7x:y20:2001:DB8::/64
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:
其中“x”是多播作用域，“y”是RP地址的接口ID，组ID或分配有64位。在这种情况下，RP的地址为：
2001:DB8::y
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.
地址2001:DB8:：y/128作为环回地址分配给路由器，并注入路由系统；如果网络管理员仅设置一个或两个RP（例如，每个子网不设置一个RP），则此方法可能比示例1中描述的方法更可取。
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.)
如例2所示，网络管理员还可以为一些客户分配多播前缀，如“FF7x:y20:2001:DB8:DEAD:：/80”。在这种情况下，RP地址仍然是“2001:DB8:：y”。（请注意，这只是示例2的一个更具体的子类，其中管理员分配多播前缀，而不仅仅是单个组ID。）
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.
请注意，派生RP地址的第二条规则：多播地址中的“plen”字段0x20=32是指获取RP地址时考虑的“网络前缀”字段的长度。在这种情况下，仅保留网络前缀字段“2001:DB8”的前32位：“plen”的值对网络中分配或使用的实际单播/多播前缀长度不采取任何立场，这里从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.
简而言之，在希望组地址与单播前缀分配一致的情况下，这种区别允许更灵活的RP地址配置。
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".
在示例1、2和3的网络中，网络管理员设置供客户使用的地址，但组织希望拥有自己的PIM-SM域。组织可以选择多播地址，例如“FF7x:y30:2001:DB8:BEEF:：/80”，然后RP地址将是“2001:DB8:BEEF:：y”。
This section describes the major operational considerations for those deploying this mechanism.
本节介绍部署此机制的人员的主要操作注意事项。
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].
在PIM-SM域中使用一种称为“Anycast RP”的技术，主要用于冗余目的，在一组RP之间共享地址和多播状态信息。通常，MSDP也用于此[AnyCastp]。还有其他方法，例如使用PIM共享此信息[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.
RP故障切换最可行的备选方案是对任意广播RP或“任意广播”（即，共享单播模型[Anycast]）使用PIM，即内部网关协议（IGP）中的RP地址，无需状态共享（尽管取决于冗余要求，这可能还不够）。但是，冗余机制不在本备忘录的范围内。
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.
由于不需要与MSDP共享域间状态，连接多播源的每个指定路由器都可以充当RP，而无需考虑设置和维护MSDP会话的可伸缩性。
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.
当人们关注RP冗余时，这可能特别有吸引力。在接近某个组的主要源的DR充当RP的情况下，可以在不使用任何RP故障切换机制的情况下获得一定数量的命运共享属性：如果DR发生故障，多播传输在任何情况下都可能不再工作。
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.
同样，将RP职责分配给多个RP也是可取的。只要不同的RP服务于不同的组，这就很简单：每个组可以映射到不同的RP（或足够多的不同RP，一个RP上的负载不成问题）。然而，一个组面临的负载共享挑战与Anycast-RP类似。
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".
通过这种机制，RP基本上可以被赋予高达/64的任何单播网络前缀。必须手动配置接口标识符以匹配“RIID”。
RIID = 0 must not be used, as using it would cause ambiguity with the Subnet-Router Anycast Address [ADDRARCH].
不能使用RIID=0，因为使用它会导致子网路由器选播地址[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.
如果管理员希望使用不符合寻址拓扑但仍然来自网络提供商单播前缀的RP地址（例如，在路由器上分配的附加环回地址，如第5.1节示例2所述），则可通过主机路由将该地址注入路由系统。
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.
对于嵌入式RP，不需要在整个PIM域中使用BSR或其他RP配置机制，因为每个组地址都指定要使用的RP。
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.
与MSDP域间ASM模型相比，谁可以使用RP以及如何使用RP的控制和管理略有变化，值得明确讨论。
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.
MSDP广告筛选通常至少包括两种功能：筛选能够创建全局会话的用户（“源筛选”）和筛选应该全局访问的组（“组筛选”）。这样做是为了防止本地组向外部发布广告，或防止未经授权的发件人创建全局组。
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.
然而，此类控制尚未阻止外部人员使用此类组，因为他们可以通过猜测/学习源和/或组地址，加入具有（源、组）或（S、G）连接的源活动广告的组。为了获得适当的保护，应该在边界路由器上设置PIM多播作用域边界。因此，默认情况下，嵌入式RP的“保护”级别大致相当于带有SA过滤的MSDP。
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.
控制方面的一个新问题是，“外域”中的节点可能注册到RP，或将PIM连接发送到RP。（在一定程度上，这些在过去也是可能的，但只能通过故意尝试或在DRs上有目的地配置RP。）这种情况下的主要威胁是，外部人员可能非法使用RP托管他/她自己的团队。这可以通过过滤RP允许的组或组范围来减轻；更具体的控制超出了本备忘录的范围。请注意，这在一开始似乎并不是一个严重的威胁，因为任何具有/64单播前缀的人都可以创建自己的RP，而不必非法从其他人那里获取。
This section specifies the group-to-RP mapping mechanism for Embedded RP.
本节指定了嵌入式RP的组到RP映射机制。
The only PIM-SM modification required is implementing this mechanism as one group-to-RP mapping method.
唯一需要的PIM-SM修改是将该机制作为一个组到RP映射方法来实现。
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.
实现必须识别地址格式，并使用第4节中的规则派生和使用RP地址。此信息至少在执行反向路径转发（RPF）查找、处理加入/删除消息或执行寄存器封装时使用。
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.
为避免循环和不一致，对于FF70:：/12范围内的地址，必须将嵌入的RP映射视为最长的匹配，并且比任何其他机制的优先级更高。
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.
值得注意的是，与可预计算的其他组到RP映射机制相比，必须为每个将映射到不同RP的新IPv6组地址重新进行嵌入式RP映射。为了提高效率，可以以特定于实现的方式缓存结果，以避免对每个嵌入式RP包进行计算。
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.
此组到RP映射机制必须由RP、与发送方相邻的DR以及从任何接收方到RP的路径上的任何路由器支持。最短路径树（SPT）形成和寄存器停止的路径不需要支持，因为它们是通过（S，G）连接完成的。
This section gives a high-level, non-normative overview of how Embedded RP operates, as specified in the previous section.
如前一节所述，本节对嵌入式RP的运行方式进行了高层次、非规范性概述。
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).
1. 接收者通过某种方式（例如SDR或网页）找到组地址。
2. The receiver issues an Multicast Listener Discovery (MLD) Report, joining the group.
2. 接收方发出多播侦听器发现（MLD）报告，加入该组。
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.
3. 接收器的DR将向多播地址中编码的RP发起PIM-SM加入过程，而不管它是在“本地”还是“远程”PIM域中。
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).
1. 发送方通过使用未指定的方法（例如，通过联系管理员进行组分配或使用多播地址分配协议）查找组地址。
2. The sender sends to the group.
2. 发件人向组发送邮件。
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).
3. 发送方的DR会将封装在PIM-SM寄存器消息中的数据包单播发送到多播地址中编码的RP地址（在DR为RP的特殊情况下，此类发送仅为概念性发送）。
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.
事实上，所有消息都按照[PIM-SM]中的规定执行；嵌入式RP只是作为一种组到RP的映射机制。该算法不是从本地配置或配置协议（例如，BSR）获取RP的地址，而是从编码的多播地址透明地派生RP的地址。
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.
连接PIM-SM域的域间MSDP模型在配置和部署方面大多是分层的，但在信息分布方面是扁平的。嵌入式RP域间模型的行为就好像每个组都形成了自己的互联网范围的PIM域，组映射到单个RP，无论接收方或发送方位于何处。因此，域间多播成为一种扁平的、以RP为中心的拓扑。下面描述了缩放问题。
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.
以前，外国来源将单播封装的数据发送到其“本地”RP；现在，他们被送往负责特定群体的“外国”RP。对于大型多播组来说，这一点尤其重要，因为其中有很多重发送方——特别是在实现无法很好地处理单播解封装的情况下。
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.
对于IPv4 ASM多播，大致有两种Internet范围的状态：MSDP（到处传播）和多播路由状态（在接收方或发送方分支上）。前者已被消除，但如果使用SPT，则主干路由器可能会在接收器（和过去的接收器，用于PIM修剪）和RP之间以及接收器和发送器之间（S，G）状态（S，G，rpt）之间结束（*，G）和（S，G，rpt）状态。但是，状态的总量较小。
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.
在域间和域内的情况下，嵌入式RP模型实际上与域内的传统PIM-SM相同。另一方面，使用MSDP在域间部署了PIM-SM（在IPv4中）；与域间模型相比，该规范通过删除外域中发送方和接收方的RP并消除MSDP信息分发，简化了树的构建（即多播路由）。
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.
由于RP的地址与多播地址绑定，RP故障管理变得更加困难，因为部署的故障切换或冗余机制（例如BSR、带有MSDP的任意广播RP）无法按原样使用。然而，使用PIM的选播RP提供了相同的冗余；第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
PIM-SM规范规定，“任何配置或读入的RP地址必须是域范围内的可访问地址”。即使没有嵌入式RP，“可达”的确切含义也不清楚。这一说法无法证明，尤其是在国外RP中，因为人们甚至无法保证RP的存在。使用此规范，使用多播的主机和用户可以间接地指定RP本身，从而降低RP可达性的预期，而不是手动配置RPs和DRs（配置不存在的RP是可能的，尽管很少）。这是一个相对重要的问题
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].
问题，但与当前的多播部署没有太大区别：例如，MLDv2（S，g）连接，无论是ASM还是SSM，都会产生相同的结果[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.
能够加入/发送到远程RPs会引起单独考虑的安全问题，但它也有一个优势：每个组都有一个“负责任的RP”，能够控制（在某种程度上）谁能够发送到该组。
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].
[PIMSEC]对域间多播路由模型（带MSDP的传统ASM、嵌入式RP、SSM）及其安全属性进行了更广泛的描述和比较。
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.
杰罗姆·杜兰德对这份备忘录的早期版本发表了评论。马歇尔·尤班克斯（Marshall Eubanks）指出了一个有关短期全票价值的问题。Tom Pusateri指出了早期SPT联接方法的问题。Rami Lehtonen指出了SA州范围内的问题，并提供了广泛的评论。Nidhi Bhaskar对该文件进行了彻底审查。Toerless Eckert、Hugh Holbrook和Dave Meyer提供了非常广泛的反馈。特别是Pavlin Radoslavov、Dino Farinaci、Nidhi Bhaskar和Jerome Durand在工作组上次电话会议期间和之后提供了良好的评论。Mark Allman、Bill Fenner、Thomas Narten和Alex Zinin在IESG评估期间提供了实质性意见。整个MboneD工作组也得到了持续的支持和评论。
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.
RPs的地址编码在多播地址中，因此在单点故障时变得更加明显。尽管这不会显著影响多播路由安全性，但可能会使RP遭受其他类型的攻击。我们鼓励运营商特别注意保护这些路由器。有关故障转移的注意事项，请参见第6.1节；有关导致某种程度命运共享属性的RPs的放置，请参见第6.2节。
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].
由于任何RP都必须接受来自任何DR的PIM-SM加入/删除/注册消息，这可能会导致潜在的拒绝服务攻击场景。但是，这是可以缓解的，因为RP可以丢弃所有不编码RP地址的多播地址的所有此类消息。基于发送方和接收方的攻击在[PIMSEC]中有更详细的描述。
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.
此外，实现还应允许手动配置允许使用的多播前缀。这可用于限制RP的使用仅限于指定群体。在某些情况下，能够限制（在RP）允许发送或加入组的单播地址是可取的。（但是，请注意，加入/删减消息仍将在网络中保留状态，并且注册消息可能被欺骗[PIMSEC]）显然，这些控制仅在RP处可用，而不在中间路由器或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.
建议支持此规范的路由器不作为RPs，除非明确配置为这样做，因为成为RP不需要任何广告（例如，通过BSR或手动）。否则，任何路由器都有可能成为RP（并被滥用）。此外，要服务的多播组或组范围可能需要在RPs处显式地配置，以保护它们不被不情愿地使用。请注意，关于允许谁使用这些组的更具体控制（例如，“内部人员必须创建”或“邀请外部人员”模型）超出了本备忘录的范围。
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.
从MSDP广告中排除仅限内部的组不会保护这些组不受外部人员的影响，但只会提供隐蔽性的安全性；嵌入式RP提供类似级别的保护。当需要真正的保护时，例如，应在边界处设置PIM范围。第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.
应该注意到嵌入式RP威胁模型实际上与SSM非常相似；这两种机制都显著降低了发送方的威胁。在接收方，这些威胁在某种程度上具有可比性，因为攻击者可以对不存在的源进行MLDv2（S，G）连接，而本地RP无法根据MSDP信息阻止该源。
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.
实现必须对嵌入式RP地址执行至少相同的地址有效性检查，就像对通过其他方式接收的RP地址一样；至少应排除fe80:：/10、：：/16和ff00:：/8。这一点尤其重要，因为信息来自不受信任的来源（即互联网上的任何用户），而不是来自本地配置。
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].
[PIMSEC]中分别对域间多播路由模型（带MSDP的传统ASM、嵌入式RP、SSM）及其安全属性进行了更广泛的描述和比较。
[ADDRARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[ADDRARCH]Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]Haberman，B.和D.Thaler，“基于单播前缀的IPv6多播地址”，RFC3306，2002年8月。
[ANYCAST] Hagino, J. and K. Ettikan, "An analysis of IPv6 anycast", Work in Progress, June 2003.
[ANYCAST]Hagino，J.和K.Ettikan，“IPv6 ANYCAST的分析”，正在进行的工作，2003年6月。
[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.
[ANYCASTRP]Kim，D.，Meyer，D.，Kilmer，H.，和D.Farinaci，“使用协议独立多播（PIM）和多播源发现协议（MSDP）的任意广播呈现点（RP）机制”，RFC 3446，2003年1月。
[ANYPIMRP] Farinacci, D. and Y. Cai, "Anycast-RP using PIM", Work in Progress, June 2004.
[ANYPIMRP]Farinaci，D.和Y.Cai，“使用PIM的Anycast RP”，正在进行的工作，2004年6月。
[BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress, July 2004.
[BSR]Fenner，B.等人，“PIM稀疏模式的引导路由器（BSR）机制”，正在进行的工作，2004年7月。
[MSDP] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[MSDP]Fenner，B.和D.Meyer，“多播源发现协议（MSDP）”，RFC 3618，2003年10月。
[PIMSEC] Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast Routing Security Issues and Enhancements", Work in Progress, October 2004.
[PIMSEC]Savola，P.，Lehtonen，R.，和D.Meyer，“PIM-SM多播路由安全问题和增强”，正在进行的工作，2004年10月。
[PIM-SM] Fenner, B. et al, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", Work in Progress, July 2004.
[PIM-SM]Fenner，B.等人，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，正在进行的工作，2004年7月。
[SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", Work in Progress, September 2004.
[SSM]Holbrook，H.等人，“IP的源特定多播”，正在进行的工作，2004年9月。
[V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", Work in Progress, September 2004.
[V6MISSUES]Savola，P.，“IPv6多播部署问题”，正在进行的工作，2004年9月。
A. Discussion about Design Tradeoffs
A.关于设计权衡的讨论
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.
本文档目前仅指定FF70:：/12；如果/当使用最高位时，必须指定FFF0:：/12如何应用于嵌入式RP。例如，与当前指定的FF70:：/12仅适用于PIM-SM不同，PIM或其他协议可能使用该范围。
Instead of using flags bits ("FF70::/12"), one could have used the leftmost reserved bits instead ("FF3x:8000::/17").
不使用标志位（“FF70:：/12”），可以使用最左边的保留位（“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.
有人认为，不允许操作员指定RIID，而是可以预先确定值（例如，“1”）。然而，这并没有被采用，因为这消除了操作员的地址分配灵活性。
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.
值64<“plen”<96将与多播组id的高位重叠；由于此限制，“plen”不得超过64位。这与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.
嵌入式RP寻址也可用于传递其他信息（RP地址除外），例如，PIM-SM的RPT阈值应该是多少。无论是否可行，这些都可以以某种方式编码在RP地址或多播组地址中。在任何情况下，此类修改都超出了本备忘录的范围。
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].
对于RPs不存在或无法访问的情况，或者在资源耗尽拒绝服务攻击中生成的状态太多而无法达到的情况，可以部署某些形式的速率限制或其他机制来减轻威胁，同时尽量不干扰合法使用。然而，由于这些威胁是通用的，它们被认为超出了范围，并在[PIMSEC]中单独讨论。
Authors' Addresses
作者地址
Pekka Savola CSC/FUNET Espoo, Finland
佩卡·萨沃拉CSC/FUNET Espoo，芬兰
EMail: psavola@funet.fi
EMail: psavola@funet.fi
Brian Haberman Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
布莱恩·哈伯曼·约翰·霍普金斯大学应用物理实验室美国马里兰州劳雷尔市约翰·霍普金斯路11100号20723-6099
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。