Network Working Group P. Savola
Request for Comments: 3627 CSC/FUNET
Category: Informational September 2003
Network Working Group P. Savola
Request for Comments: 3627 CSC/FUNET
Category: Informational September 2003
Use of /127 Prefix Length Between Routers Considered Harmful
路由器之间使用/127前缀长度被认为是有害的
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.
在某些情况下，操作决策可能是使用IPv6/127前缀长度，特别是在路由器之间的点到点链路上。在某些情况下，由于正在实施子网路由器选播，这可能导致一个路由器要求两个地址。本文件讨论了该问题，并针对该问题提供了两种解决方案；然而，应避免在两个路由器之间使用/127。
[ADDRARCH] defines Subnet-router anycast address: in a subnet prefix of n bits, the last 128-n bits are all zero. It is meant to be in use of any one router in the subnet.
[ADDRARCH]定义子网路由器选播地址：在n位的子网前缀中，最后128-n位均为零。它意味着使用子网中的任何一个路由器。
Even though having prefix length longer than /64 is forbidden by [ADDRARCH] section 2.4 for non-000/3 unicast prefixes, using /127 prefix length has gained a lot of operational popularity; it seems like that these prefix lengths are being used heavily in point-to-point links. The operational practise has often been to use the least amount of address space especially in the presence of a large number of point-to-point links; it may be unlikely that all of these links would start to use /64's. Using /127 has also other operational benefits: you always know which address the other end uses, and there is no "ping-pong" [PINGPONG] problem with older ICMP implementations (fixed now in [ICMPv3]).
尽管[ADDRARCH]第2.4节禁止前缀长度大于/64的非000/3单播前缀，但使用/127前缀长度已经获得了大量的操作普及；这些前缀长度似乎在点到点链接中被大量使用。操作实践通常是使用最少的地址空间，尤其是在存在大量点对点链接的情况下；所有这些链接不太可能都开始使用/64。使用/127还有其他操作好处：您总是知道其他终端使用的地址，并且旧的ICMP实现（现在已在[ICMPv3]中修复）没有“乒乓”问题。
This memo does not advocate the use of long prefixes, but brings up problems for those that do want to use them, for one reason or another.
这份备忘录并不提倡使用长前缀，但出于这样或那样的原因，给那些确实想使用它们的人带来了问题。
Detailed discussion on what is the "right" solution is out of the scope; it is not the goal of this memo to try to find the "best" addressing solution for everyone.
关于什么是“正确”解决方案的详细讨论超出了范围；本备忘录的目的不是试图为每个人找到“最佳”解决方案。
Note that this problem does not exist between a router and a host, assuming the PREFIX::0/127 address is assigned to the router.
请注意，如果将前缀：：0/127地址分配给路由器，则路由器和主机之间不存在此问题。
Using /127 can be especially harmful on a point-to-point link when Subnet-router anycast address is implemented. Consider the following sequence of events:
当实现子网路由器选播地址时，在点到点链路上使用/127可能特别有害。考虑下面的事件顺序：
1. Router A and Router B are connected by a point-to-point link.
1. 路由器A和路由器B通过点对点链路连接。
2. Neither has anything configured or set up on this link.
2. 此链接上没有任何配置或设置。
3. 3ffe:ffff::1/127 address is added to Router A; now it performs Duplicate Address Detection (DAD) [NDISC] for 3ffe:ffff::1. Router A also adds the Subnet-router anycast address 3ffe:ffff::0/127. (DAD is not performed for anycast addresses.)
3. 3ffe:ffff:：1/127地址添加到路由器A；现在，它对3ffe:ffff:：1执行重复地址检测（DAD）[NDISC]。路由器A还添加了子网路由器选播地址3ffe:ffff:：0/127。（选播地址不执行DAD。）
4. Now Router B has been planned and configured to use 3ffe:ffff::0/127 as its unicast IPv6 address, but adding it will fail DAD, and Router B does not have any address.
4. 现在，路由器B已经计划并配置为使用3ffe:ffff:：0/127作为其单播IPv6地址，但添加它将失败，并且路由器B没有任何地址。
Similar scenarios also happen during router reboots, crashes and such.
在路由器重新启动、崩溃等过程中也会发生类似的情况。
The usability of subnet-router anycast address between two routers on a point-to-point link is very questionable, but it is still a mandated feature of [ADDRARCH]. Workarounds for this are presented in the next section.
在点到点链路上的两个路由器之间的子网路由器选播地址的可用性是非常值得怀疑的，但它仍然是[ADDRARCH]的强制功能。下一节将介绍解决方法。
As of yet, this kind of unexpected behavior hasn't been seen at large perhaps because the Subnet-router anycast address hasn't been implemented or too widely used.
到目前为止，这种意外的行为还没有被普遍发现，可能是因为子网路由器选播地址尚未实现或使用得太广泛。
1. One could use /64 for subnets, including point-to-point links.
1. 可以将/64用于子网，包括点到点链路。
2. One could use only link-local addresses, but that may make network maintenance and debugging impractical at least in bigger networks; for example, "traceroute" can only return a list of nodes on the path, not the links which would have been used.
2. 可以只使用链路本地地址，但这可能使网络维护和调试变得不切实际，至少在更大的网络中是如此；例如，“traceroute”只能返回路径上的节点列表，而不能返回本应使用的链接。
3. Failing that, /126 does not have this problem, and it can be used safely on a point-to-point link (e.g., using the 2nd and the 3rd address for unicast). This is analogous to using /30 for IPv4. Using two /128 addresses is also one, though often cumbersome, approach. Naturally, not much would be lost if even a shorter prefix was used, e.g., /112 or /120.
3. 否则，/126就没有这个问题，它可以安全地在点到点链路上使用（例如，使用第2和第3个地址进行单播）。这类似于将/30用于IPv4。使用两个/128地址也是一种虽然通常很麻烦的方法。当然，如果使用更短的前缀，例如/112或/120，也不会损失太多。
The author feels that if /64 cannot be used, /112, reserving the last 16 bits for node identifiers, has probably the least amount of drawbacks (also see section 3).
作者认为，如果不能使用/64，/112保留最后16位作为节点标识符，那么它的缺点可能最少（另请参见第3节）。
4. [ADDRARCH] could be revised to state that Subnet-router anycast address should not be used if the prefix length of the link is not /64 (or even longer than /120). This does not seem like a good approach, as we should avoid making assumptions about prefix lengths in the specifications, to maintain future flexibility. Also, in some cases, it might be usable to have a Subnet-router anycast address in some networks with a longer prefix length.
4. [ADDRARCH]可以修改为，如果链路的前缀长度不为/64（甚至大于/120），则不应使用子网路由器选播地址。这似乎不是一个好方法，因为我们应该避免在规范中假设前缀长度，以保持未来的灵活性。此外，在某些情况下，在某些前缀长度较长的网络中，可以使用子网路由器选播地址。
A more conservative (implementation) approach would be not using Subnet-router anycast addresses in subnets with a prefix length of /127 if there are only two routers on the link: this can be noticed with [NDISC] 'Router' bit in Neighbor Advertisement messages. However, this seems to overload the functionality of 'R' bit, so it does not look like a good approach in the long run.
如果链路上只有两个路由器，则更保守的（实现）方法是在前缀长度为/127的子网中不使用子网路由器选播地址：这可以通过邻居播发消息中的[NDISC]“路由器”位发现。然而，这似乎会使“R”位的功能过载，因此从长远来看，这不是一个好方法。
5. It's also possible to improve implementations: if /127 is used on a point-to-point link, never claim two addresses. This has the drawback that even if the router using the combined unicast and anycast address is down, the packets to subnet-router anycast address will be lost as the other cannot claim the address. This approach might lead to unpredictability which would be hard to trace when debugging problems. However, this would normally be an issue only when the Subnet-router anycast address is used from outside of the link; usually, this cannot be done reliably as the prefix length or EUI64 u/g bits cannot be known for certain. There are other problems with an address being anycast and unicast
5. 还可以改进实现：如果在点到点链接上使用/127，则永远不要声明两个地址。这有一个缺点，即即使使用组合单播和选播地址的路由器关闭，到子网路由器选播地址的数据包也将丢失，因为另一个路由器无法声明该地址。这种方法可能会导致不可预测性，这在调试问题时很难跟踪。然而，这通常只有在从链路外部使用子网路由器选播地址时才会出现问题；通常，这无法可靠地完成，因为前缀长度或EUI64 u/g位无法确定。地址被选播和单播还有其他问题
too: use of it as a source address, whether to use unicast or anycast semantics in [NDISC], and others: allowing this behavior would seem to only add a lot of complexity to the implementations.
太：将其用作源地址，在[NDISC]中使用单播还是选播语义，以及其他：允许这种行为似乎只会增加实现的复杂性。
1) is definitely the best solution, wherever it is possible. 2) may be usable in some scenarios, but in larger networks (where the most often the desire would be to use longer prefix length) it may be deemed very impractical. There are some situations where one of these may not be an option; then an operational work-around for this operational problem, that is 3), appears to be the best course of action. This is because it may be very difficult to know whether all implementations implement some checks, like ones described in 4) or 5).
1) 在可能的情况下，这绝对是最好的解决方案。2） 在某些情况下可能是可用的，但在更大的网络中（通常希望使用更长的前缀长度），这可能被认为是非常不切实际的。在某些情况下，其中一种可能不是一种选择；然后，针对该操作问题的操作解决方案（即3）似乎是最佳的行动方案。这是因为可能很难知道是否所有实现都实现了一些检查，如4）或5）中所述。
These issues are not specific to /127.
这些问题并非特定于/127。
One should note that [ADDRARCH] specifies universal/local bits (u/g), which are the 70th and 71st bits in any address from non-000/3 range. When assigning prefixes longer than 64 bits, these should be taken into consideration; in almost every case, u should be 0, as the last 64 bits of a long prefix is very rarely unique. 'G' is still unspecified, but defaults to zero. Thus, all prefixes with u or g=1 should be avoided.
应该注意的是，[ADDRARCH]指定了通用/本地位（u/g），它是非000/3范围内任何地址中的第70位和第71位。分配长度超过64位的前缀时，应考虑这些前缀；几乎在所有情况下，u都应该是0，因为长前缀的最后64位很少是唯一的G'仍然未指定，但默认为零。因此，应避免使用u或g=1的所有前缀。
[MIPV6] specifies "Mobile IPv6 Home-Agents" anycast address which is used for Home Agent Discovery. In consequence, 7 last bits of have been reserved in [ANYCAST] of every non-000/3 non-multicast address, similar to [ADDRARCH]. Thus, at least /120 would seem to make sense. However, as the sender must know the destination's prefix length, this "reserved anycast addresses" mechanism is only applicable when the sender knows about the link and expects that there is a service it needs there. In the case of e.g., /126 between routers, the only to node to be found on this link would be the other router, so the mechanism does not seem useful. At least, Mobile IPv6 Home Agent Discovery should not be performed if the prefix length is longer than /120.
[MIPV6]指定用于归属代理发现的“移动IPv6归属代理”选播地址。因此，在每个非000/3非多播地址的[ANYCAST]中保留了的最后7位，类似于[ADDRARCH]。因此，至少/120似乎是有意义的。但是，由于发送方必须知道目的地的前缀长度，因此这种“保留选播地址”机制仅在发送方知道该链接并希望在该链接上有它需要的服务时才适用。例如，在路由器之间的/126情况下，在该链路上找到的唯一to节点将是另一个路由器，因此该机制似乎没有用处。至少，如果前缀长度大于/120，则不应执行移动IPv6归属代理发现。
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[ADDRARCH]Hinden，R.和S.Deering，“IP版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[ANYCAST] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[ANYCAST]Johnson，D.和S.Deering，“保留的IPv6子网选播地址”，RFC 25261999年3月。
[NDISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[NDISC]Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC 2461，1998年12月。
[MIPV6] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", Work in Progress.
[MIPV6]Johnson，D.，Perkins，C.，Arkko，J.，“IPv6中的移动支持”，正在进行中。
[ICMPv3] Conta, A., Deering, S., "Internet Control Message Protocol (ICMPv6)", Work in Progress.
[ICMPv3]Conta，A.，Deering，S.，“互联网控制消息协议（ICMPv6）”，正在进行中。
[PINGPONG] Hagino, J., Jinmei, T., Zill, B., "Avoiding ping-pong packets on point-to-point links", Work in Progress.
[乒乓球]Hagino，J.，Jinmei，T.，Zill，B.，“避免点对点链接上的乒乓球数据包”，正在进行的工作。
Beyond those already existing in other specifications, solution 4) might lead to denial of service in the case that one router is down: the packet to subnet-router anycast address would be lost.
除了其他规范中已有的解决方案外，解决方案4）可能会在一个路由器停机的情况下导致拒绝服务：包到子网路由器的选播地址将丢失。
Thanks to Robert Elz and many others on the IPv6 Working Group for discussion, and Alain Durand for pointing out [ADDRARCH] requirements for prefix lengths. Charles Perkins pointed out MIPv6 HA requirements. Randy Bush and Ole Troan commented on the document extensively, and Erik Nordmark pointed out issues with u-bit.
感谢Robert Elz和IPv6工作组的许多其他成员的讨论，以及Alain Durand指出的[ADDRARCH]前缀长度要求。Charles Perkins指出了MIPv6 HA要求。兰迪·布什（Randy Bush）和奥勒·特罗安（Ole Troan）对该文件进行了广泛评论，埃里克·诺德马克（Erik Nordmark）指出了u-bit的问题。
Pekka Savola CSC/FUNET Espoo, Finland
佩卡·萨沃拉CSC/FUNET Espoo，芬兰
EMail: psavola@funet.fi
EMail: psavola@funet.fi
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。