idnits 2.17.1 draft-baker-6man-multiprefix-default-route-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 248. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 261. 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 (November 5, 2007) is 6018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2740 (Obsoleted by RFC 5340) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintanence (6man) F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Informational November 5, 2007 5 Expires: May 8, 2008 7 Multiprefix IPv6 Routing for Ingress Filters 8 draft-baker-6man-multiprefix-default-route-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 8, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This note addresses routing in a network that supports multiple 42 prefixes and has different DMZs, in the context of BCPs 38 and 84 43 (ingress filtering). It proposes a change to the way IPv6 forwarding 44 occurs, and so should be considered carefully by the Internet 45 community. 47 Requirements Language 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in [RFC2119]. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Host selection of an address . . . . . . . . . . . . . . . 3 58 2.2. Host selection of a router . . . . . . . . . . . . . . . . 4 59 2.3. Selection of a multipath route by a router . . . . . . . . 4 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 Intellectual Property and Copyright Statements . . . . . . . . . . 7 69 1. Introduction 71 BCP 38 [RFC2827] recommends that routing systems protect themselves 72 against spoofed source addresses by the application of ingress 73 filtering. In short, this means discarding datagrams that 74 purportedly come from addresses that the routing system does not 75 believe are reachable from the direction whence they have arrived. 76 BCP 84 [RFC3704] discusses the problems this raises in a multihomed 77 network that uses multiple prefixes internally. In short, it 78 recommends that a routing system route in such a way that datagrams 79 are only presented to an upstream routing system if and only if that 80 upstream routing system will not discard them in accordance with BCP 81 38. 83 In IPv6 [RFC2460] networks, this poses several problems. The IPv6 84 Addressing Architecture [RFC4291] leads one to assume that on any 85 interface, a system is likely to have at least two addresses - its 86 link local address and its address in the relevant prefix. If 87 Privacy addresses [RFC4941] are in use, it might have many addresses 88 in the same prefix. In a routing system with multiple prefixes 89 overlaid, an interface might have numerous addresses even if it has 90 only one per prefix. 92 It is this last situation that causes the present concern. Is there 93 a way that we can ensure that routing to the egress router is optimal 94 while ensuring that traffic sent upstream uses the right upstreams 95 without forcing the host to be involved in datagram routing? 97 2. Proposal 99 In short, the author suggests that datagrams should be sent in a 100 direction that will avoid ingress filtering, starting from the 101 originating host. This section discusses the ramifications of that 102 policy. 104 2.1. Host selection of an address 106 [RFC3484] describes an architecture by which a network administrator 107 can define which source address prefixes should be used on datagrams 108 sent to various destination prefixes. This proposal assumes that if 109 remote non-default prefixes are propagated within a network, this 110 technology governs the choice of address. As such, traffic headed to 111 destinations for which there is routing other than the default route 112 will never be sent to an upstream that will discard them. 114 2.2. Host selection of a router 116 Having selected a source address, the host must now determine what 117 router to send its datagram to. 119 If Neighbor Discovery [RFC4861] or SEcure Neighbor Discovery 120 [RFC3971] are in use, the prefix that the host is using will have 121 been advertised to it in a Router Advertisement. In either case, the 122 host SHOULD send the datagram to the router from which it learned the 123 prefix. 125 if DHCP [RFC3315] is in use, it may be possible to rely on the Router 126 Advertisements bring broadcast periodically. This case requires 127 further thought. 129 2.3. Selection of a multipath route by a router 131 Once a datagram has been handed to a router, the router has two 132 possible options: either it has a single route to that prefix, or it 133 has a multipath route. If it has a single route or an internal 134 route, it SHOULD of course use it. 136 If the chosen route is a multipath route to an external network, the 137 router SHOULD use the path that was advertised into the network by 138 the DMZ that injected the prefix used in the datagram's source 139 address. This can be determined, for example, by observing the OSPF 140 [RFC2740] inter-area-router-LSA, which will contain at least one 141 interface using the prefix of the relevant upstream and will have a 142 companion AS-external-LSA indicating a default route. This would 143 generally apply t default routes, but may also apply to more specific 144 aggregated routes advertised into the network via multiple DMZs. 146 3. IANA Considerations 148 This memo adds no new IANA considerations. The presence of this 149 template text indicates that the author/editor has not actually 150 reviewed IANA considerations. 152 Note to RFC Editor: This section will have served its purpose if it 153 correctly tells IANA that no new assignments or registries are 154 required, or if those assignments or registries are created during 155 the RFC publication process. From the author"s perspective, it may 156 therefore be removed upon publication as an RFC at the RFC Editor"s 157 discretion. 159 4. Security Considerations 161 One could argue that hist note addresses a security concern raised in 162 BCP 84, that the communications between two systems may be inhibited 163 or obstructed by a poor choice of source address in a poorly thought 164 through routing system. At this writing, the security issues have 165 not been fully thought through, so this section needs to be updated. 167 5. Acknowledgements 169 6. References 171 6.1. Normative References 173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14, RFC 2119, March 1997. 176 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 177 (IPv6) Specification", RFC 2460, December 1998. 179 6.2. Informative References 181 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 182 RFC 2740, December 1999. 184 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 185 Defeating Denial of Service Attacks which employ IP Source 186 Address Spoofing", BCP 38, RFC 2827, May 2000. 188 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 189 and M. Carney, "Dynamic Host Configuration Protocol for 190 IPv6 (DHCPv6)", RFC 3315, July 2003. 192 [RFC3484] Draves, R., "Default Address Selection for Internet 193 Protocol version 6 (IPv6)", RFC 3484, February 2003. 195 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 196 Networks", BCP 84, RFC 3704, March 2004. 198 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 199 Neighbor Discovery (SEND)", RFC 3971, March 2005. 201 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 202 Architecture", RFC 4291, February 2006. 204 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 205 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 206 September 2007. 208 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 209 Extensions for Stateless Address Autoconfiguration in 210 IPv6", RFC 4941, September 2007. 212 Author's Address 214 Fred Baker 215 Cisco Systems 216 Santa Barbara, California 93117 217 USA 219 Phone: +1-408-526-4257 220 Fax: +1-413-473-2403 221 Email: fred@cisco.com 223 Full Copyright Statement 225 Copyright (C) The IETF Trust (2007). 227 This document is subject to the rights, licenses and restrictions 228 contained in BCP 78, and except as set forth therein, the authors 229 retain all their rights. 231 This document and the information contained herein are provided on an 232 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 233 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 234 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 235 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 236 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 237 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 239 Intellectual Property 241 The IETF takes no position regarding the validity or scope of any 242 Intellectual Property Rights or other rights that might be claimed to 243 pertain to the implementation or use of the technology described in 244 this document or the extent to which any license under such rights 245 might or might not be available; nor does it represent that it has 246 made any independent effort to identify any such rights. Information 247 on the procedures with respect to rights in RFC documents can be 248 found in BCP 78 and BCP 79. 250 Copies of IPR disclosures made to the IETF Secretariat and any 251 assurances of licenses to be made available, or the result of an 252 attempt made to obtain a general license or permission for the use of 253 such proprietary rights by implementers or users of this 254 specification can be obtained from the IETF on-line IPR repository at 255 http://www.ietf.org/ipr. 257 The IETF invites any interested party to bring to its attention any 258 copyrights, patents or patent applications, or other proprietary 259 rights that may cover technology that may be required to implement 260 this standard. Please address the information to the IETF at 261 ietf-ipr@ietf.org. 263 Acknowledgment 265 Funding for the RFC Editor function is provided by the IETF 266 Administrative Support Activity (IASA).