Network Working Group A. Matsumoto
Request for Comments: 5221 T. Fujisaki
Category: Informational NTT
R. Hiromi
Intec NetCore
K. Kanayama
INTEC Systems
July 2008
Network Working Group A. Matsumoto
Request for Comments: 5221 T. Fujisaki
Category: Informational NTT
R. Hiromi
Intec NetCore
K. Kanayama
INTEC Systems
July 2008
Requirements for Address Selection Mechanisms
对地址选择机制的要求
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
There are some problematic cases when using the default address selection mechanism that RFC 3484 defines. This document describes additional requirements that operate with RFC 3484 to solve the problems.
在使用RFC 3484定义的默认地址选择机制时，存在一些问题。本文件描述了使用RFC 3484解决问题的附加要求。
Table of Contents
目录
1. Introduction ....................................................2
2. Requirements of Address Selection ...............................2
2.1. Effectiveness ..............................................2
2.2. Timing .....................................................2
2.3. Dynamic Behavior Update ....................................3
2.4. Node-Specific Behavior .....................................3
2.5. Application-Specific Behavior ..............................3
2.6. Multiple Interface .........................................3
2.7. Central Control ............................................3
2.8. Next-Hop Selection .........................................3
2.9. Compatibility with RFC 3493 ................................4
2.10. Compatibility and Interoperability with RFC 3484 ..........4
2.11. Security ..................................................4
3. Security Considerations .........................................4
3.1. List of Threats Introduced by New Address-Selection
Mechanism ..................................................4
3.2. List of Recommendations in Which Security Mechanism
Should Be Applied ..........................................5
4. Normative References ............................................5
1. Introduction ....................................................2
2. Requirements of Address Selection ...............................2
2.1. Effectiveness ..............................................2
2.2. Timing .....................................................2
2.3. Dynamic Behavior Update ....................................3
2.4. Node-Specific Behavior .....................................3
2.5. Application-Specific Behavior ..............................3
2.6. Multiple Interface .........................................3
2.7. Central Control ............................................3
2.8. Next-Hop Selection .........................................3
2.9. Compatibility with RFC 3493 ................................4
2.10. Compatibility and Interoperability with RFC 3484 ..........4
2.11. Security ..................................................4
3. Security Considerations .........................................4
3.1. List of Threats Introduced by New Address-Selection
Mechanism ..................................................4
3.2. List of Recommendations in Which Security Mechanism
Should Be Applied ..........................................5
4. Normative References ............................................5
Today, the RFC 3484 [RFC3484] mechanism is widely implemented in major OSs. However, in many sites, the default address-selection rules are not appropriate, and cause a communication failure. The problem statement (PS) document [RFC5220] lists problematic cases that resulted from incorrect address selection.
如今，RFC 3484[RFC3484]机制在主要的开放源码软件中得到了广泛的应用。但是，在许多站点中，默认地址选择规则不合适，会导致通信失败。问题陈述（PS）文档[RFC5220]列出了由于地址选择错误而导致的问题案例。
Though RFC 3484 made the address-selection behavior of a host configurable, typical users cannot make use of that because of the complexity of the mechanism and lack of knowledge about their network topologies. Therefore, an address-selection autoconfiguration mechanism is necessary, especially for unmanaged hosts of typical users.
尽管RFC 3484使主机的地址选择行为可配置，但由于机制的复杂性和缺乏对其网络拓扑的了解，典型用户无法使用该行为。因此，地址选择自动配置机制是必要的，特别是对于典型用户的非托管主机。
This document contains requirements for address-selection mechanisms that enable hosts to perform appropriate address selection automatically.
本文档包含地址选择机制的要求，这些机制使主机能够自动执行适当的地址选择。
Address-selection mechanisms have to fulfill the following eleven requirements.
地址选择机制必须满足以下11个要求。
The mechanism can modify RFC 3484 default address-selection behavior at nodes. As documented in the PS [RFC5220], the default rules defined in RFC 3484 do not work properly in some environments. Therefore, the mechanism has to be able to modify the address-selection behavior of a host and to solve the problematic cases described in the PS document.
该机制可以修改节点上的RFC 3484默认地址选择行为。如PS[RFC5220]中所述，RFC 3484中定义的默认规则在某些环境中无法正常工作。因此，该机制必须能够修改主机的地址选择行为，并解决PS文档中描述的问题情况。
Nodes can perform appropriate address selection when they select addresses.
节点在选择地址时可以执行适当的地址选择。
If nodes need to have address-selection information to perform appropriate address selection, then the mechanism has to provide a function for nodes to obtain the necessary information beforehand.
如果节点需要有地址选择信息来执行适当的地址选择，那么该机制必须为节点提供一个功能，以便事先获得必要的信息。
The mechanism should not degrade usability. The mechanism should not enforce long address-selection processing time upon users. Therefore, forcing every consumer user to manipulate the address-selection policy table is usually not an acceptable solution. So, in this case, some kind of autoconfiguration mechanism is desirable.
该机制不应降低可用性。该机制不应对用户强制执行较长的地址选择处理时间。因此，强制每个使用者用户操作地址选择策略表通常不是一个可接受的解决方案。因此，在这种情况下，需要某种自动配置机制。
The address-selection behavior of nodes can be dynamically updated. When the network structure changes and the address-selection behavior has to be changed accordingly, a network administrator can modify the address-selection behavior of nodes.
节点的地址选择行为可以动态更新。当网络结构改变并且地址选择行为必须相应改变时，网络管理员可以修改节点的地址选择行为。
The mechanism can support node-specific address-selection behavior. Even when multiple nodes are on the same subnet, the mechanism should be able to provide a method for the network administrator to make nodes behave differently. For example, each node may have a different set of assigned prefixes. In such a case, the appropriate address-selection behavior may be different.
该机制可以支持特定于节点的地址选择行为。即使多个节点位于同一子网上，该机制也应该能够为网络管理员提供一种方法，使节点的行为有所不同。例如，每个节点可能有一组不同的指定前缀。在这种情况下，适当的地址选择行为可能不同。
The mechanism can support application-specific address-selection behavior or combined use with an application-specific address-selection mechanism such as address-selection APIs.
该机制可以支持特定于应用程序的地址选择行为，也可以与特定于应用程序的地址选择机制（如地址选择API）结合使用。
The mechanism can support those nodes equipped with multiple interfaces. The mechanism has to assume that nodes have multiple interfaces and makes address selection of those nodes work appropriately.
该机制可以支持具有多个接口的节点。该机制必须假设节点具有多个接口，并使这些节点的地址选择工作正常。
The address-selection behavior of nodes can be centrally controlled. A site administrator or a service provider could determine or could have an effect on the address-selection behavior at their users' hosts.
节点的地址选择行为可以集中控制。站点管理员或服务提供商可以确定或影响其用户主机上的地址选择行为。
The mechanism can control next-hop-selection behavior at hosts or cooperate with other routing mechanisms, such as routing protocols and RFC 4191 [RFC4191]. If the address-selection mechanism is used with a routing mechanism, the two mechanisms have to be able to work synchronously.
该机制可以控制主机上的下一跳选择行为，或者与其他路由机制（如路由协议和RFC 4191[RFC4191]）协作。如果地址选择机制与路由机制一起使用，则这两种机制必须能够同步工作。
The mechanism can allow an application that uses the basic socket interface defined in RFC 3493 [RFC3493] to work correctly. That is, with the basic socket interface the application can select appropriate source and destination addresses and can communicate with the destination host. This requirement does not necessarily mean that OS protocol stack and socket libraries should not be changed.
该机制允许使用RFC 3493[RFC3493]中定义的基本套接字接口的应用程序正常工作。也就是说，通过基本套接字接口，应用程序可以选择适当的源地址和目标地址，并可以与目标主机通信。此要求并不一定意味着不应更改操作系统协议栈和套接字库。
The mechanism is compatible with RFC 3484. Now that RFC 3484 is widely implemented, it is preferable that a new address selection mechanism does not conflict with the address selection mechanisms defined in RFC 3484.
该机构与RFC 3484兼容。既然RFC 3484已被广泛实施，则优选新的地址选择机制不与RFC 3484中定义的地址选择机制冲突。
If the solution mechanism changes or replaces the address-selection mechanism defined in RFC 3484, interoperability has to be retained. That is, a host with the new solution mechanism and a host with the mechanism of RFC 3484 have to be interoperable.
如果解决方案机制更改或替换RFC 3484中定义的地址选择机制，则必须保留互操作性。也就是说，具有新解决方案机制的主机和具有RFC 3484机制的主机必须是可互操作的。
The mechanism works without any security problems. Possible security threats are described in the Security Considerations section of this document.
该机制工作时没有任何安全问题。本文档的安全注意事项部分描述了可能的安全威胁。
There will be some security incidents when combining the requirements described in Section 2 into a protocol. In particular, there are 3 types of threats: leakage, hijacking, and denial of service.
将第2节中描述的要求合并到协议中时，会发生一些安全事件。具体来说，有三种类型的威胁：泄漏、劫持和拒绝服务。
1. Leakage: Malicious nodes may tap to collect the network policy information and leak it to unauthorized parties.
1. 泄漏：恶意节点可能会点击以收集网络策略信息并将其泄漏给未经授权的方。
2. Hijacking: Nodes may be hijacked by malicious injection of illegitimate policy information. RFC 3484 defines both a source and destination selection algorithm. An attacker able to inject malicious policy information could redirect packets sent by a victim node to an intentionally chosen server that would scan the victim node activities to find vulnerable code. Once vulnerable code is found, the attacker can take control of the victim node.
2. 劫持：恶意注入非法策略信息可能会劫持节点。RFC 3484定义了源和目标选择算法。能够注入恶意策略信息的攻击者可以将受害者节点发送的数据包重定向到故意选择的服务器，该服务器将扫描受害者节点活动以查找易受攻击的代码。一旦发现有漏洞的代码，攻击者就可以控制受害者节点。
3. Denial of Service: This is an attack on the ability of nodes to communicate in the absence of the address-selection policy. An attacker could launch a flooding attack on the controller to prevent it from delivering the address selection policy information to nodes, thus preventing those nodes from appropriately communicating.
3. 拒绝服务：这是在没有地址选择策略的情况下对节点通信能力的攻击。攻击者可以对控制器发起泛洪攻击，以阻止其将地址选择策略信息传递给节点，从而阻止这些节点进行适当通信。
3.2. List of Recommendations in Which Security Mechanism Should Be Applied
3.2. 应适用安全机制的建议清单
The address selection mechanism should be afforded security services listed below. It is preferable that these security services are afforded via use of existing protocols (e.g., IPsec).
地址选择机制应提供下列安全服务。最好通过使用现有协议（例如，IPsec）提供这些安全服务。
1. Integrity of the network policy information itself and the messages exchanged in the protocol. This is a countermeasure against leakage, hijacking, and denial of service.
1. 网络策略信息本身和协议中交换的消息的完整性。这是针对泄漏、劫持和拒绝服务的对策。
2. Authentication and authorization of parties involved in the protocol. This is a countermeasure against Leakage and Hijacking.
2. 协议各方的认证和授权。这是防止泄漏和劫持的对策。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.，和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，2003年2月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月。
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules", RFC 5220, July 2008.
[RFC5220]Matsumoto，A.，Fujisaki，T.，Hiromi，R.，和K.Kanayama，“多前缀环境中默认地址选择的问题陈述：RFC 3484默认规则的操作问题”，RFC 52202008年7月。
Authors' Addresses
作者地址
Arifumi Matsumoto NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan
松本明文NTT PF实验室Midori Cho 3-9-11武藏野市，日本东京180-8585
Phone: +81 422 59 3334
EMail: arifumi@nttv6.net
Phone: +81 422 59 3334
EMail: arifumi@nttv6.net
Tomohiro Fujisaki NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan
藤崎智宏NTT PF实验室Midori Cho 3-9-11武藏野市，东京180-8585日本
Phone: +81 422 59 7351
EMail: fujisaki@nttv6.net
Phone: +81 422 59 7351
EMail: fujisaki@nttv6.net
Ruri Hiromi Intec Netcore, Inc. Shinsuna 1-3-3 Koto-ku, Tokyo 136-0075 Japan
日本东京新宿1-3-3 Koto-ku，Ruri Hiromi Intec Netcore，Inc.日本东京136-0075
Phone: +81 3 5665 5069
EMail: hiromi@inetcore.com
Phone: +81 3 5665 5069
EMail: hiromi@inetcore.com
Ken-ichi Kanayama INTEC Systems Institute, Inc. Shimoshin-machi 5-33 Toyama-shi, Toyama 930-0804 Japan
Ken ichi Kanayama INTEC Systems Institute，Inc.Shimoshin machi 5-33富山市，富山930-0804日本
Phone: +81 76 444 8088
EMail: kanayama_kenichi@intec-si.co.jp
Phone: +81 76 444 8088
EMail: kanayama_kenichi@intec-si.co.jp
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见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.