idnits 2.17.1 draft-pfister-6man-sadr-ra-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 135: '...ed for futur use. They MUST be set to...' RFC 2119 keyword, line 140: '... MUST be ignored....' RFC 2119 keyword, line 180: '...n this flag is set, the option MUST be...' RFC 2119 keyword, line 187: '...is specification MUST behave similarly...' RFC 2119 keyword, line 191: '...is specification MUST use a Routing Ta...' (10 more instances...) -- The draft header indicates that this document updates RFC4191, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4191, updated by this document, for RFC5378 checks: 2005-11-15) -- 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 (February 27, 2015) is 3338 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Pfister 3 Internet-Draft Cisco Systems 4 Updates: 4191 (if approved) February 27, 2015 5 Intended status: Standards Track 6 Expires: August 31, 2015 8 Source Address Dependent Route Information Option for Router 9 Advertisements 10 draft-pfister-6man-sadr-ra-00 12 Abstract 14 This document defines the Source Address Dependent Route Information 15 option for Router Advertisements, enabling source address dependent 16 routes to be installed in hosts by neighboring routers. It also adds 17 a new flag to the existing Route Information option for backward 18 compatibility purposes. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 31, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Source Address Dependent Route Information Option . . . . . . 2 56 3. Route Information Option ignore flag . . . . . . . . . . . . 4 57 4. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Receiving Source Address Dependent Route Information 59 option . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. Receiving Route Information option . . . . . . . . . . . 6 61 5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 9.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 Hosts may have multiple non-link-local addresses, possibly provided 73 by different routers located on one or multiple links. In such 74 situations, hosts must make sure packets with a given source address 75 are sent to the right next-hop router. Failing in selecting the 76 right next-hop router may, at best, induce sub-optimal routing and, 77 at worst, cause the packet to be dropped ([RFC2827]). Rules 5 and 78 5.5 from the default address selection algorithm [RFC6724] make sure 79 that, once the next-hop is chosen, care is taken to pick the right 80 source address. Nevertheless, these rules may fail in some 81 situations, e.g., when the same prefix is advertised on the same link 82 by different routers. Additionally, they don't handle situations 83 where the application picks the source-address before sending the 84 packet. 86 This document defines the Source Address Dependent Route Information 87 Option for Router Advertisements [RFC4861], enabling source address 88 dependent routes to be installed in hosts by neighboring routers. It 89 also adds a new flag to the Route Information Option meaning that the 90 option may be ignored by hosts implementing this specification. 92 2. Source Address Dependent Route Information Option 94 This section defines a new Router Advertisement option called the 95 Source Address Dependent Route Information option. Its use is 96 similar to the Route Information option defined in [RFC4191] but also 97 includes additional source prefix fields, allowing source address 98 dependent routes to be installed on hosts receiving the Router 99 Advertisement. 101 0 1 2 3 102 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Type | Length | Src Length | Dst Length | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Route Lifetime | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 |Resvd|Prf|Resvd| Source Prefix (Variable Length) | 109 +-+-+-+-+-+-+-+-+ + 110 . . 111 . . 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Destination Prefix (Variable Length) | 114 . . 115 . . 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Source Address Dependent Route Information Option 120 Type: To be defined by IANA. 122 Length: The length of the option (including the Type and Length 123 fields) in units of 8 octets. It ranges from 2 to 6. 125 Src Length: The number of significant bits in the Source Prefix 126 field. 128 Dst Length: The number of significant bits in the Destination Prefix 129 field. 131 Route Lifetime: Time in seconds (relative to the time the packet is 132 sent) that the prefix is valid for route determination. A value 133 of all one bits (0xffffffff) represents infinity. 135 Resvd (Reserved): Bits reserved for futur use. They MUST be set to 136 zero by the sender and ignored by the receiver. 138 Prf (Route Preference): The route preference as specified in 139 [RFC4191]. When the Reserved value (10) is received, the option 140 MUST be ignored. 142 Source Prefix: The source prefix significant bits padded to the next 143 8-bits boundary. 145 Destination Prefix: The destination prefix significant bits padded 146 to the next 64-bits boundary. 148 Note: The alignment is a bit awkward. I am not sure reserving 24 149 bits for the purpose of aligning the source prefix would be helpful. 150 The destination prefix cannot be aligned neither due to the variable 151 length of the source prefix, unless we add unused bytes in between. 152 Propositions are welcome concerning the best format for this option. 154 3. Route Information Option ignore flag 156 This document adds the Ignore flag to the Route Information option 157 specified in [RFC4191]. It is used in order to configure type C 158 hosts with more specific routes which will be ignored by hosts 159 implementing this specification. Most of the time, such options with 160 the I bit set will be used in conjunction with Source Address 161 Dependent Route Information options including the same or a similar 162 destination prefix. 164 The option is re-defined with an additional flag. 166 0 1 2 3 167 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Type | Length | Prefix Length |I|Rsv|Prf|Resvd| 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Route Lifetime | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Prefix (Variable Length) | 174 . . 175 . . 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Route Information Option 180 I flag: Ignore flag. When this flag is set, the option MUST be 181 ignored. 183 Other fields: No changes (see [RFC4191]). 185 4. Host Behavior 187 Hosts implementing this specification MUST behave similarly to type C 188 hosts as specified in [RFC4191], unless stated otherwise in this 189 section. 191 Hosts implementing this specification MUST use a Routing Table with 192 source address dependent entries. Such entries have a source prefix, 193 a destination prefix, a preference value, a lifetime, an interface 194 and a next-hop router address. 196 When sending a packet, hosts MUST select the next-hop router based on 197 the usual source address dependent routing algorithm, i.e., by 198 picking the matching entry with, by order of precedence: 200 The longest destination address match. 202 The longest source address match. 204 The highest route preference value. 206 In case of a tie, hosts MAY either pick one entry or use load-sharing 207 techniques. 209 4.1. Receiving Source Address Dependent Route Information option 211 When receiving a Source Address Dependent Route Information option, a 212 host MUST look for an existing routing entry with: 214 1. The same source prefix. 216 2. The same destination prefix. 218 3. The next-hop router address equal to the source address of the 219 received Router Advertisement. 221 4. The outgoing interface equal to the interface the Router 222 Advertisement is received on. 224 If no routing entry is found and the Route Lifetime is not null, 225 insert a routing entry with the given source prefix, destination 226 prefix, route preference, having as next-hop the source address of 227 the received Router Advertisement, on the interface receiving the 228 packet. If the Route Lifetime is not infinity, set the routing entry 229 timer to the Route Lifetime value. 231 If a routing entry is found and the Route Lifetime is not null, 232 cancel the associated timer. If the Route Lifetime is not infinity, 233 set it to the Route Lifetime value. Finally, update the entry 234 preference with the Route Preference value. 236 If a routing entry is found and the Route Lifetime is null, remove 237 the routing entry. 239 If both destination and source prefixes specified by the option are 240 ::/0, the router preference and route lifetime present in the option 241 override the default router lifetime and default router preference 242 present in the header of the Router Advertisement. 244 4.2. Receiving Route Information option 246 When receiving a Route Information option, a host MUST behave as 247 follows: 249 If the I bit is set, ignore the option. 251 Otherwise, act as when receiving a Source Address Dependent Route 252 Information option with source prefix length set to zero. 254 5. Router Behavior 256 Routers MAY send one or multiple Source Address Dependent Route 257 Information options in their Router Advertisements. 259 Routers MUST NOT send multiple Route Information options with the 260 same Prefix (no matter what the Ignore flag value is) or multiple 261 Source Address Dependent Route Information options with the same 262 Source and Destination Prefixes. Additionally, routers MUST NOT send 263 a Route Information option with the Ignore bit not set and a Source 264 Address Dependent Route Information with the source length equal to 265 zero if the Prefix from the Route Information option is equal to the 266 Destination Prefix from the Source Address Dependent Route 267 Information option. 269 The Ignore bit is used to configure hosts implementing this 270 specification differently from other types of hosts (A, B or C). 271 Different combinations will result in different behaviors. For 272 instance: 274 When injecting a source address dependent route is desired, a 275 Source Address Dependent Route Information option is sent in every 276 RA. Depending on the context, a Route Information with the same 277 prefix and the Ignore bit set MAY be sent as well in order to 278 inject non source address dependent route into type C hosts. 279 Obviously, Source Address Dependent Route Information options can 280 be used to inject non-source dependent routes as well. This 281 technique and the use of the Ignore bit allow type C hosts and 282 hosts implementing this specification to be configured with 283 independent routes. 285 When injecting a non source address dependent route is desired, 286 the router MAY either use a Route Information option with the 287 Ignore flag not set, in which case type C hosts as well as hosts 288 implementing this specification will be configured, or use a 289 Source Address Dependent Route Information option with a source 290 prefix ::/0, in which case type C hosts will not be configured. 292 When a Source Address Dependent Route Information option is removed 293 from the set of advertised options, the router SHOULD send multiple 294 unsolicited Router Advertisements with the Route Lifetime set to 295 zero. 297 6. Security Considerations 299 This document allows routers to configure neighboring hosts with 300 source address dependent routing entries. Based on [RFC4191], 301 attackers can inject default routes to type A and B hosts as well as 302 destination address dependent routes to type C hosts. The Source 303 Address Dependent Route Information option adds the ability for 304 attackers to inject even more specific routes, making attacks 305 slightly harder to detect. 307 7. IANA Considerations 309 IANA is kindly asked to reserve a Router Advertisement option type to 310 be used by the Source Address Dependent Route Information option. 312 8. Acknowledgments 314 The author would appreciate reviews and comments. 316 9. References 318 9.1. Normative References 320 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 321 More-Specific Routes", RFC 4191, November 2005. 323 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 324 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 325 September 2007. 327 9.2. Informative References 329 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 330 Defeating Denial of Service Attacks which employ IP Source 331 Address Spoofing", BCP 38, RFC 2827, May 2000. 333 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 334 "Default Address Selection for Internet Protocol Version 6 335 (IPv6)", RFC 6724, September 2012. 337 Author's Address 339 Pierre Pfister 340 Cisco Systems 341 Paris 342 France 344 Email: pierre.pfister@darou.fr