idnits 2.17.1 draft-ietf-v6ops-addr-select-req-03.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 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 322. 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 (October 12, 2007) is 6041 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: April 14, 2008 R. Hiromi 6 K. Kanayama 7 Intec Netcore 8 October 12, 2007 10 Requirements for address selection mechanisms 11 draft-ietf-v6ops-addr-select-req-03.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 April 14, 2008. 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 a 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 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 3.1. List of threats introduced by new address-selection 68 mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.2. List of recommendations in which security mechanism 70 should be applied . . . . . . . . . . . . . . . . . . . . . 5 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 72 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 74 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 76 Intellectual Property and Copyright Statements . . . . . . . . . . 8 78 1. Introduction 80 One physical network can have multiple logical networks. In that 81 case, an end-host has multiple IP addresses. (e.g., in the IPv4-IPv6 82 dual-stack environment, in a site that uses both ULA [RFC4193] and 83 global scope addresses or in a site connected to multiple upstream 84 IPv6 networks) For such a host, RFC 3484 [RFC3484] defines default 85 address-selection rules for the source and destination addresses. 87 Today, the RFC 3484 mechanism is widely implemented in major OSs. 88 However, we and others have found that in many sites the default 89 address-selection rules are not appropriate for the network 90 structure. PS [I-D.ietf-v6ops-addr-select-ps] lists problematic 91 cases that resulted from incorrect address selection. 93 Though RFC 3484 made the address-selection behavior of a host 94 configurable, typical users cannot make use of that because of the 95 complexity of the mechanism and lack of knowledge about their network 96 topologies. Therefore, an address-selection autoconfiguration 97 mechanism is necessary, especially for unmanaged hosts of typical 98 users. 100 This document contains requirements for address-selection mechanisms 101 that enable hosts to perform appropriate address selection 102 automatically. 104 2. Requirements of Address Selection 106 Address-selection mechanisms have to fulfill the following seven 107 requirements. 109 2.1. Effectiveness 111 The mechanism can modify RFC 3484 default address-selection behavior 112 at nodes. As documented in PS [I-D.ietf-v6ops-addr-select-ps], the 113 default rules defined in RFC 3484 do not work properly in some 114 environments. Therefore, the mechanism has to be able to modify 115 address-selection behavior of a host. 117 2.2. Timing 119 Nodes can obtain address selection information when necessary. If 120 nodes need to have address-selection information before performing 121 address selection, then the mechanism has to provide a function for 122 nodes to obtain necessary information beforehand. The mechanism 123 should not degrade usability. The mechanism should not enforce long 124 address-selection processing time upon users. 126 2.3. Dynamic Behavior Update 128 Address-selection behavior of nodes can be dynamically updated. When 129 the network structure changes and address-selection behavior has to 130 be changed accordingly, a network administrator can modify the 131 address-selection behavior of nodes. 133 2.4. Node-Specific Behavior 135 The mechanism can support node-specific address-selection behavior. 136 Even when multiple nodes are on the same subnet, the mechanism should 137 be able to provide a method for the network administrator to make 138 nodes behave differently. For example, each node may have a 139 different set of assigned prefixes. In such a case, the appropriate 140 address-selection behavior may be different. 142 2.5. Application-Specific Behavior 144 The mechanism can support application-specific address-selection 145 behavior or combined use with an application-specific address- 146 selection mechanism such as address-selection APIs. 148 2.6. Multiple Interface 150 The mechanism can support those nodes equipped with multiple 151 interfaces. The mechanism has to assume that nodes have multiple 152 interfaces and makes address selection of those nodes work 153 appropriately. 155 2.7. Central Control 157 The address selection behavior of nodes can be centrally controlled. 158 A site administrator or a service provider could determine or could 159 have effect on address-selection behavior at their users' hosts. 161 2.8. Next-hop Selection 163 The mechanism can control next-hop-selection behavior at hosts or 164 cooperate with other routing mechanisms, such as routing protocols 165 and RFC 4191 [RFC4191]. If the address-selection mechanism is used 166 with a routing mechanism, the two mechanisms have to be able to work 167 synchronously. 169 3. Security Considerations 170 3.1. List of threats introduced by new address-selection mechanism 172 There are some security incidents when combining these requirements 173 described in Section 2 into a protocol. In particular, here are six 174 possible threats. 176 1. Hijacking or tapping from malicious nodes connecting from beyond 177 unapproved network boundaries. 178 2. Malicious changing of policy data by nonapproved nodes. 179 3. Denial of Service Attack due to higher traffic volume, and 180 blocked communication, for example, at both node and network 181 caused by sending unsafe and tampered data from unbidden 182 controller. 183 4. Attempt to stop service on node/computer resources caused by 184 unnecessary communication between the controller and nodes. 185 5. Intrusion into security boundary caused by malicious use of 186 multiprefix environment. 187 6. Leakage of network policy information from central controller. 189 3.2. List of recommendations in which security mechanism should be 190 applied 192 All the methods listed below should be well-considered for protecting 193 against security threats. There is no necessity to comply with all 194 items at same time, if one or more spec(s) could apply to other 195 security requirements. Secure network operation will also be 196 considered, and describing network operation for network security 197 will be better. Referring to and using existing technologies is also 198 preferable. 200 1. Consideration of the necessity to use digitally signed or 201 cryptographic messages. 202 2. Consideration of the necessity to maintain confidentiality of 203 source of policy data. 204 3. Consideration of the necessity of authentication and validation 205 of both entity and message integrity. 206 4. Consideration of the necessity of having a mechanism for the 207 avoidance of data conflicts if the policy data comes from 208 multiple controllers. 209 5. Consideration of the necessity of an appropriate filtering method 210 at domain boundaries. 211 6. Consideration of the necessity of data independency at every node 212 or every interface for avoidance of mixing multiple policy data. 213 7. Consideration of the necessity of having a mechanism for 214 controlling policy and all related network information on the 215 server if the server stores policy and all related neetowrk 216 information on the outside of its network domain. 218 8. Consideration of the necessity to log and collect related system 219 data. 221 4. IANA Considerations 223 This document has no actions for IANA. 225 5. References 227 5.1. Normative References 229 [I-D.ietf-v6ops-addr-select-ps] 230 Matsumoto, A., "Problem Statement of Default Address 231 Selection in Multi-prefix Environment: Operational Issues 232 of RFC3484 Default Rules", 233 draft-ietf-v6ops-addr-select-ps-01 (work in progress), 234 April 2007. 236 [RFC3484] Draves, R., "Default Address Selection for Internet 237 Protocol version 6 (IPv6)", RFC 3484, February 2003. 239 5.2. Informative References 241 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 242 More-Specific Routes", RFC 4191, November 2005. 244 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 245 Addresses", RFC 4193, October 2005. 247 Authors' Addresses 249 Arifumi Matsumoto 250 NTT PF Lab 251 Midori-Cho 3-9-11 252 Musashino-shi, Tokyo 180-8585 253 Japan 255 Phone: +81 422 59 3334 256 Email: arifumi@nttv6.net 257 Tomohiro Fujisaki 258 NTT PF Lab 259 Midori-Cho 3-9-11 260 Musashino-shi, Tokyo 180-8585 261 Japan 263 Phone: +81 422 59 7351 264 Email: fujisaki@nttv6.net 266 Ruri Hiromi 267 Intec Netcore, Inc. 268 Shinsuna 1-3-3 269 Koto-ku, Tokyo 136-0075 270 Japan 272 Phone: +81 3 5665 5069 273 Email: hiromi@inetcore.com 275 Ken-ichi Kanayama 276 Intec Netcore, Inc. 277 Shinsuna 1-3-3 278 Koto-ku, Tokyo 136-0075 279 Japan 281 Phone: +81 3 5665 5069 282 Email: kanayama@inetcore.com 284 Full Copyright Statement 286 Copyright (C) The IETF Trust (2007). 288 This document is subject to the rights, licenses and restrictions 289 contained in BCP 78, and except as set forth therein, the authors 290 retain all their rights. 292 This document and the information contained herein are provided on an 293 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 294 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 295 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 296 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 297 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 298 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 300 Intellectual Property 302 The IETF takes no position regarding the validity or scope of any 303 Intellectual Property Rights or other rights that might be claimed to 304 pertain to the implementation or use of the technology described in 305 this document or the extent to which any license under such rights 306 might or might not be available; nor does it represent that it has 307 made any independent effort to identify any such rights. Information 308 on the procedures with respect to rights in RFC documents can be 309 found in BCP 78 and BCP 79. 311 Copies of IPR disclosures made to the IETF Secretariat and any 312 assurances of licenses to be made available, or the result of an 313 attempt made to obtain a general license or permission for the use of 314 such proprietary rights by implementers or users of this 315 specification can be obtained from the IETF on-line IPR repository at 316 http://www.ietf.org/ipr. 318 The IETF invites any interested party to bring to its attention any 319 copyrights, patents or patent applications, or other proprietary 320 rights that may cover technology that may be required to implement 321 this standard. Please address the information to the IETF at 322 ietf-ipr@ietf.org. 324 Acknowledgment 326 Funding for the RFC Editor function is provided by the IETF 327 Administrative Support Activity (IASA).