idnits 2.17.1 draft-pfister-6man-sadr-ra-01.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 130: '...ed for futur use. They MUST be set to...' RFC 2119 keyword, line 135: '... MUST be ignored....' RFC 2119 keyword, line 199: '...n this flag is set, the option MUST be...' RFC 2119 keyword, line 215: '...e D hosts behavior. Type D hosts MUST...' RFC 2119 keyword, line 220: '... Hosts MUST use a Routing Table with...' (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 (June 22, 2015) is 3223 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2' on line 157 ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 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) June 22, 2015 5 Intended status: Standards Track 6 Expires: December 24, 2015 8 Source Address Dependent Route Information Option for Router 9 Advertisements 10 draft-pfister-6man-sadr-ra-01 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 December 24, 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 . . . . . . 3 56 3. Route Information Option ignore flag . . . . . . . . . . . . 4 57 4. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Selecting the next-hop router . . . . . . . . . . . . . . 6 59 4.2. Receiving Source Address Dependent Route Information 60 option . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.3. Receiving Route Information options . . . . . . . . . . . 7 62 5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 9.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 Hosts may have multiple non-link-local addresses, possibly provided 74 by different routers located on one or multiple links. In such 75 situations, hosts must make sure packets with a given source address 76 are sent to the right next-hop router. Failing in selecting the 77 right next-hop router may, at best, induce sub-optimal routing and, 78 at worst, cause the packet to be dropped ([RFC2827]). Rules 5 and 79 5.5 from the default address selection algorithm [RFC6724] make sure 80 that, once the next-hop is chosen, care is taken to pick the right 81 source address. Nevertheless, these rules may fail in some 82 situations, e.g., when the same prefix is advertised on the same link 83 by different routers. Additionally, they don't handle situations 84 where the application picks the source-address before sending the 85 packet. 87 This document defines the Source Address Dependent Route Information 88 Option for Router Advertisements [RFC4861], enabling source address 89 dependent routes to be installed in hosts by neighboring routers. It 90 also adds a new flag to the Route Information Option meaning that the 91 option may be ignored by hosts implementing this specification. 93 2. Source Address Dependent Route Information Option 95 This section defines a new Router Advertisement option called the 96 Source Address Dependent Route Information option. Its use is 97 similar to the Route Information option defined in [RFC4191] but also 98 includes additional source prefix fields, allowing source address 99 dependent routes to be installed on hosts receiving the Router 100 Advertisement. 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Type | Length | Dst Length |Resvd|Prf|Resvd| 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Route Lifetime | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | | 110 . Destination Prefix (Variable Length) . 111 . . 112 . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 . | Src Length | | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 115 | | 116 . Source Prefix (Variable Length) . 117 . . 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 Source Address Dependent Route Information Option 122 Type: To be defined by IANA. 124 Length: The length of the option (including the Type and Length 125 fields) in units of 8 octets. It ranges from 2 to 6. 127 Dst Length: The number of significant bits in the Destination Prefix 128 field. 130 Resvd (Reserved): Bits reserved for futur use. They MUST be set to 131 zero by the sender and ignored by the receiver. 133 Prf (Route Preference): The route preference as specified in 134 [RFC4191]. When the Reserved value (10) is received, the option 135 MUST be ignored. 137 Route Lifetime: Time in seconds (relative to the time the packet is 138 sent) that the prefix is valid for route determination. A value 139 of all one bits (0xffffffff) represents infinity. 141 Destination Prefix: The destination prefix significant bits padded 142 to the next 8-bits boundary. 144 Src Length: The number of significant bits in the Source Prefix 145 field. 147 Source Prefix: The source prefix significant bits padded to the next 148 64-bits boundary. 150 The following C code is given as an help for implementation: 152 #define ALIGN(bitlength, alignment) \ 153 (((bitlength != 0)?(((bitlength - 1) / alignment) + 1):0) * \ 154 (alignment / 8)) 156 unsigned char *option; 157 size_t src_len_index = 8 + ALIGN(option[2], 8); 158 size_t total_byte_length = ALIGN((src_len_index + 1) * 8 159 + option[src_len_index], 64); 161 Note: Comments have been made regarding address alignment. There is 162 no format providing at the same time good alignment and optimal TLV 163 size, while aligning both source and destination prefixes would waste 164 from 7 to 21 bytes per option. This TLV format is proposed based on 165 implementation experience and provides both TLV size efficiency, and 166 relative compatibility with the Route Information option (Linux 167 implementation of this option support is less than 100 lines of 168 code). 170 Comments and propositions are welcome regarding which format to 171 adopt. 173 3. Route Information Option ignore flag 175 This document adds the Ignore flag to the Route Information option 176 specified in [RFC4191]. It is used in order to configure type C 177 hosts with more specific routes which will be ignored by hosts 178 implementing this specification. Most of the time, such options with 179 the I bit set will be used in conjunction with Source Address 180 Dependent Route Information options including the same or a similar 181 destination prefix. 183 The option is re-defined with an additional flag. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Type | Length | Prefix Length |I|Rsv|Prf|Resvd| 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Route Lifetime | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Prefix (Variable Length) | 193 . . 194 . . 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Route Information Option 199 I flag: Ignore flag. When this flag is set, the option MUST be 200 ignored. 202 Other fields: No changes (see [RFC4191]). 204 4. Host Behavior 206 Hosts implementing this specification are referred to as type D 207 hosts, in reference to host types A, B and C defined in [RFC4191]. 208 As a reminder, type A hosts are hosts behaving as specified in 209 [RFC4191]. Type B hosts behave similarly to type A hosts with the 210 addition that they act upon the Default Router Preference values 211 present in Router Advertisement headers. Finally, type C hosts 212 behave as type B hosts with the addition that they act upon received 213 Route Information Options. 215 This section specifies type D hosts behavior. Type D hosts MUST 216 behave as type C hosts unless stated otherwise in this section. For 217 the sake of clarity, in this whole section, 'host' refers to 'type D 218 host'. 220 Hosts MUST use a Routing Table with source address dependent entries. 221 Such entries have a: 223 o Source prefix 225 o Destination prefix 227 o Preference value 229 o Interface 230 o Next-hop router address 232 o Lifetime and associated timer 234 4.1. Selecting the next-hop router 236 When sending a packet, hosts MUST select the next-hop router based on 237 the usual source address dependent routing algorithm, i.e., by 238 picking the matching entry with, by order of precedence: 240 The longest destination address match. 242 The longest source address match. 244 The greatest route preference value. 246 In case of a tie, hosts MAY either pick one entry or use load-sharing 247 techniques. 249 4.2. Receiving Source Address Dependent Route Information option 251 When receiving a Source Address Dependent Route Information option, a 252 host MUST look for an existing routing entry with: 254 1. The same source prefix. 256 2. The same destination prefix. 258 3. The next-hop router address equal to the source address of the 259 received Router Advertisement. 261 4. The outgoing interface equal to the interface the Router 262 Advertisement is received on. 264 If no routing entry is found and the Route Lifetime is not null, 265 insert a routing entry with the given source prefix, destination 266 prefix, route preference, having as next-hop the source address of 267 the received Router Advertisement, on the interface receiving the 268 packet. If the Route Lifetime is not infinity, set the routing entry 269 timer to the Route Lifetime value. 271 If a routing entry is found and the Route Lifetime is not null, 272 cancel the associated timer. If the Route Lifetime is not infinity, 273 set the timer to the Route Lifetime value. Finally, update the entry 274 preference with the Route Preference value. 276 If a routing entry is found and the Route Lifetime is null, remove 277 the routing entry. 279 If both destination and source prefixes specified by the option are 280 ::/0, the router preference and route lifetime present in the option 281 overrides the default router lifetime and default router preference 282 present in the header of the Router Advertisement. 284 4.3. Receiving Route Information options 286 When receiving a Route Information option, a host MUST behave as 287 follows: 289 If the I bit is set, ignore the option. 291 Otherwise, act as when receiving a Source Address Dependent Route 292 Information option with source prefix length set to zero. 294 5. Router Behavior 296 Routers MAY send one or multiple Source Address Dependent Route 297 Information options in their Router Advertisements. 299 Routers MUST NOT send multiple Route Information options with the 300 same Prefix (no matter what the Ignore flag value is) or multiple 301 Source Address Dependent Route Information options with the same 302 Source and Destination Prefixes. Additionally, routers MUST NOT send 303 a Route Information option with the Ignore bit not set and a Source 304 Address Dependent Route Information with the source length equal to 305 zero if the Prefix from the Route Information option is equal to the 306 Destination Prefix from the Source Address Dependent Route 307 Information option. 309 The Ignore bit is used to configure type D hosts differently from 310 hosts of types A, B or C. Different combinations will result in 311 different behaviors. For instance: 313 When injecting a source address dependent route is desired, a 314 Source Address Dependent Route Information option is sent in every 315 RA. Depending on the context, a Route Information with the same 316 prefix and the Ignore bit set MAY be sent as well in order to 317 inject a non source address dependent route into type C hosts. 318 Obviously, Source Address Dependent Route Information options can 319 be used to inject non-source dependent routes as well. This 320 technique and the use of the Ignore bit allow type C hosts and 321 type D hosts to be configured with possibly independent routes. 323 When injecting a non source address dependent route is desired, 324 the router MAY either use a Route Information option with the 325 Ignore flag not set, in which case both type C and D hosts will be 326 configured, or use a Source Address Dependent Route Information 327 option with a source prefix ::/0, in which case type C hosts will 328 not be configured. 330 When a Source Address Dependent Route Information option is removed 331 from the set of advertised options, or when the interface ceases to 332 be an advertising interface, the router SHOULD send up to 333 MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited Router Advertisements, 334 using the same rule as in [RFC2461], with the Route Lifetime set to 335 zero in all Source Address Dependent Route Information options that 336 have become invalid. 338 6. Security Considerations 340 This document allows routers to configure neighboring hosts with 341 source address dependent routing entries. Based on [RFC4191], 342 attackers can inject default routes to type A and B hosts as well as 343 destination address dependent routes to type C hosts. The Source 344 Address Dependent Route Information option adds the ability for 345 attackers to inject even more specific routes, making attacks 346 slightly harder to detect. 348 7. IANA Considerations 350 IANA is kindly asked to reserve a Router Advertisement option type to 351 be used by the Source Address Dependent Route Information option. 353 8. Acknowledgments 355 The author would appreciate reviews and comments. 357 9. References 359 9.1. Normative References 361 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 362 Discovery for IP Version 6 (IPv6)", RFC 2461, December 363 1998. 365 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 366 More-Specific Routes", RFC 4191, November 2005. 368 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 369 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 370 September 2007. 372 9.2. Informative References 374 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 375 Defeating Denial of Service Attacks which employ IP Source 376 Address Spoofing", BCP 38, RFC 2827, May 2000. 378 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 379 "Default Address Selection for Internet Protocol Version 6 380 (IPv6)", RFC 6724, September 2012. 382 Author's Address 384 Pierre Pfister 385 Cisco Systems 386 Paris 387 France 389 Email: pierre.pfister@darou.fr