idnits 2.17.1 draft-ietf-v6ops-addr-select-req-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 276. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 15, 2007) is 6189 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-v6ops-addr-select-ps-01 ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group A. Matsumoto 3 Internet-Draft T. Fujisaki 4 Intended status: Informational NTT 5 Expires: November 16, 2007 R. Hiromi 6 K. Kanayama 7 Intec Netcore 8 May 15, 2007 10 Requirements for address selection mechanisms 11 draft-ietf-v6ops-addr-select-req-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 16, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 In a multi-prefix environment, nodes could have multiple addresses on 45 one network interface. RFC 3484 defines source and destination 46 address-selection algorithm, which is commonly deployed in current 47 popular OSs. However, nodes could encounter some difficulties in 48 network communication when they use default address selection rules 49 defined in RFC 3484. Some mechanisms for solving address selection 50 problems are proposed including the RFC 3484 policy table 51 distribution and ICMP error-based mechanisms. This document 52 describes the requirements for these address selection mechanisms. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements of Address Selection . . . . . . . . . . . . . . . 3 58 2.1. Effectiveness . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.3. Dynamic Behavior Update . . . . . . . . . . . . . . . . . . 4 61 2.4. Node-Specific Behavior . . . . . . . . . . . . . . . . . . 4 62 2.5. Application-Specific Behavior . . . . . . . . . . . . . . . 4 63 2.6. Multiple Interface . . . . . . . . . . . . . . . . . . . . 4 64 2.7. Central Control . . . . . . . . . . . . . . . . . . . . . . 4 65 2.8. Next-hop Selection . . . . . . . . . . . . . . . . . . . . 4 66 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 68 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 5.1. Normative References . . . . . . . . . . . . . . . . . . . 5 70 5.2. Informative References . . . . . . . . . . . . . . . . . . 5 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 72 Intellectual Property and Copyright Statements . . . . . . . . . . 7 74 1. Introduction 76 One physical network can have multiple logical networks. In that 77 case, an end-host has multiple IP addresses. ( e.g. In the IPv4-IPv6 78 dual-stack environment, in a site that uses both ULA [RFC4193] and 79 global scope addresses or in a site connected to multiple upstream 80 IPv6 networks) For such a host, RFC 3484 [RFC3484] defines default 81 address-selection rules for the source and destination addresses. 83 Today, the RFC 3484 mechanism is widely implemented in major OSs. 84 However, we and others have found that in many sites the default 85 address-selection rules are not appropriate for the network 86 structure. PS [I-D.ietf-v6ops-addr-select-ps] lists problematic 87 cases that resulted from incorrect address selection. 89 Though RFC 3484 made the address-selection behavior of a host 90 configurable, typical users cannot make use of that because of the 91 complexity of the mechanism and lack of knowledge about their network 92 topologies. Therefore, an address-selection autoconfiguration 93 mechanism is necessary, especially for unmanaged hosts of typical 94 users. 96 This document contains requirements for address-selection mechanisms 97 that enable hosts to perform appropriate address selection 98 automatically. 100 2. Requirements of Address Selection 102 Address-selection mechanisms have to fulfill the following seven 103 requirements. 105 2.1. Effectiveness 107 The mechanism can modify RFC 3484 default address-selection behavior 108 at nodes. As documented in PS [I-D.ietf-v6ops-addr-select-ps], the 109 default rules defined in RFC 3484 do not work properly in some 110 environment. Therefore, the mechanism has to be able to modify 111 address-selection behavior of a host. 113 2.2. Timing 115 Nodes can obtain address selection information when necessary. If 116 nodes need to have address-selection information before performing 117 address selection, then the mechanism has to provide a way for nodes 118 to obtain necessary information beforehand. The mechanism should not 119 degrade userbility. The mechanism should not enforce long address- 120 selection processing time upon users. 122 2.3. Dynamic Behavior Update 124 Address-selection behavior of nodes can be dynamically updated. When 125 the network structure changes and address-selection behavior has to 126 be changed accordingly, a network administrator can modify the 127 address-selection behavior of nodes. 129 2.4. Node-Specific Behavior 131 The mechanism can support node-specific address-selection behavior. 132 Even when multiple nodes are on the same subnet, the mechanism should 133 be able to provide a method for the network administrator to make 134 nodes behave differently. For example, each node may have a 135 different set of assigned prefixes. In such a case, the appropriate 136 address-selection behavior may be different. 138 2.5. Application-Specific Behavior 140 The mechanism can support application-specific address-selection 141 behavior or combined use with an application-specific address- 142 selection mechanism such as address-selection APIs. 144 2.6. Multiple Interface 146 The mechanism can support those nodes equipped with multiple 147 interfaces. The mechanism has to assume that nodes have multiple 148 interfaces and makes address selection of those nodes work 149 appropriately. 151 2.7. Central Control 153 The address selection behavior of nodes can be centrally controlled. 154 A site administrator or a service provider can determine or have 155 effect on address-selection behavior at their users' hosts. 157 2.8. Next-hop Selection 159 The mechanism can control next-hop-selection behavior at hosts or 160 cooperate with other routing mechanisms, such as routing protocols 161 and RFC 4191 [RFC4191]. If the address-selection mechanism is used 162 with a routing mechanism, the two mechanisms has to be able to work 163 synchronousely. 165 3. Security Considerations 167 Incorrect address-selection can lead to serious security problems, 168 such as session hijack. However, we should note that address- 169 selection is ultimately decided by nodes and their users. There are 170 no means to enforce a specific address-selection behavior upon every 171 end-host from outside of the host. Therefore, a network 172 administrator has to take countermeasures for unexpected address 173 selection. 175 4. IANA Considerations 177 This document has no actions for IANA. 179 5. References 181 5.1. Normative References 183 [I-D.ietf-v6ops-addr-select-ps] 184 Matsumoto, A., "Problem Statement of Default Address 185 Selection in Multi-prefix Environment: Operational Issues 186 of RFC3484 Default Rules", 187 draft-ietf-v6ops-addr-select-ps-01 (work in progress), 188 April 2007. 190 [RFC3484] Draves, R., "Default Address Selection for Internet 191 Protocol version 6 (IPv6)", RFC 3484, February 2003. 193 5.2. Informative References 195 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 196 More-Specific Routes", RFC 4191, November 2005. 198 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 199 Addresses", RFC 4193, October 2005. 201 Authors' Addresses 203 Arifumi Matsumoto 204 NTT PF Lab 205 Midori-Cho 3-9-11 206 Musashino-shi, Tokyo 180-8585 207 Japan 209 Phone: +81 422 59 3334 210 Email: arifumi@nttv6.net 211 Tomohiro Fujisaki 212 NTT PF Lab 213 Midori-Cho 3-9-11 214 Musashino-shi, Tokyo 180-8585 215 Japan 217 Phone: +81 422 59 7351 218 Email: fujisaki@syce.net 220 Ruri Hiromi 221 Intec Netcore, Inc. 222 Shinsuna 1-3-3 223 Koto-ku, Tokyo 136-0075 224 Japan 226 Phone: +81 3 5665 5069 227 Email: hiromi@inetcore.com 229 Ken-ichi Kanayama 230 Intec Netcore, Inc. 231 Shinsuna 1-3-3 232 Koto-ku, Tokyo 136-0075 233 Japan 235 Phone: +81 3 5665 5069 236 Email: kanayama@inetcore.com 238 Full Copyright Statement 240 Copyright (C) The IETF Trust (2007). 242 This document is subject to the rights, licenses and restrictions 243 contained in BCP 78, and except as set forth therein, the authors 244 retain all their rights. 246 This document and the information contained herein are provided on an 247 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 248 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 249 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 250 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 251 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 252 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 254 Intellectual Property 256 The IETF takes no position regarding the validity or scope of any 257 Intellectual Property Rights or other rights that might be claimed to 258 pertain to the implementation or use of the technology described in 259 this document or the extent to which any license under such rights 260 might or might not be available; nor does it represent that it has 261 made any independent effort to identify any such rights. Information 262 on the procedures with respect to rights in RFC documents can be 263 found in BCP 78 and BCP 79. 265 Copies of IPR disclosures made to the IETF Secretariat and any 266 assurances of licenses to be made available, or the result of an 267 attempt made to obtain a general license or permission for the use of 268 such proprietary rights by implementers or users of this 269 specification can be obtained from the IETF on-line IPR repository at 270 http://www.ietf.org/ipr. 272 The IETF invites any interested party to bring to its attention any 273 copyrights, patents or patent applications, or other proprietary 274 rights that may cover technology that may be required to implement 275 this standard. Please address the information to the IETF at 276 ietf-ipr@ietf.org. 278 Acknowledgment 280 Funding for the RFC Editor function is provided by the IETF 281 Administrative Support Activity (IASA).