idnits 2.17.1 draft-templin-6man-rio-redirect-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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 30, 2017) is 2642 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) == Unused Reference: 'RFC0791' is defined on line 253, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Updates: rfc4191, rfc4861 (if approved) J. Woodyatt 5 Intended status: Standards Track Google 6 Expires: August 3, 2017 January 30, 2017 8 Route Information Options in Redirect Messages 9 draft-templin-6man-rio-redirect-01.txt 11 Abstract 13 The IPv6 Neighbor Discovery protocol provides a Redirect function 14 allowing routers to inform recipients of a better next hop on the 15 link toward the destination. This document specifies a backward- 16 compatible extension to the Redirect function to allow routers to 17 include routing information that the recipient can associate with the 18 next hop. 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 3, 2017. 37 Copyright Notice 39 Copyright (c) 2017 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Route Information Options in Redirect Messages . . . . . . . 3 57 3.1. Validation of Redirect Messages . . . . . . . . . . . . . 3 58 3.2. Router Specification . . . . . . . . . . . . . . . . . . 3 59 3.3. Host Specification . . . . . . . . . . . . . . . . . . . 4 60 3.3.1. Type "D" Hosts with Delegated Prefixes . . . . . . . 4 61 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 8.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Appendix A. Link-layer Address Changes . . . . . . . . . . . . . 7 69 Appendix B. Interfaces with Multiple Link-Layer Addresses . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861][RFC2460] 75 provides a Redirect function allowing routers to inform recipients of 76 a better next hop on the link toward the destination. Further 77 guidance for processing Redirect messages is given in "First-Hop 78 Router Selection by Hosts in a Multi-Prefix Network" [RFC8028]. 80 "Default Router Preferences and More-Specific Routes" [RFC4191] 81 specifies a Route Information Option (RIO) that routers can include 82 in Router Advertisement (RA) messages to inform recipients of more- 83 specific routes. This document specifies a backward-compatible 84 extension to allow routers to include RIOs in Redirect messages. 86 2. Terminology 88 The terminology in the normative references applies. 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. Lower case 93 uses of these words are not to be interpreted as carrying RFC2119 94 significance. 96 3. Route Information Options in Redirect Messages 98 The RIO is specified for inclusion in RA messages in Section 2.3 of 99 [RFC4191]. The Redirect function is specified in Section 8 of 100 [RFC4861]. This specification permits routers to include RIOs in 101 Redirect messages so that recipients can direct future packets to a 102 better next hop for a destination *prefix* instead of just a specific 103 destination. This specification therefore updates [RFC4191] and 104 [RFC4861], as discussed in the following sections. 106 3.1. Validation of Redirect Messages 108 The validation of Redirect messages follows Section 8.1 of [RFC4861], 109 which contains the following passage: 111 "The contents of any defined options that are not specified to be 112 used with Redirect messages MUST be ignored and the packet 113 processed as normal. The only defined options that may appear are 114 the Target Link-Layer Address option and the Redirected Header 115 option." 117 This specification updates the above statement by adding RIOs to the 118 list of defined options that may appear. 120 3.2. Router Specification 122 The Router Specification follows Section 8.2 of [RFC4861], which 123 provides a list of options that may appear in a Redirect message. 124 This specification updates the list by including RIOs as permissible 125 options. Routers therefore MAY send Redirect messages containing 126 RIOs with values determined by a means outside the scope of this 127 specification. 129 After the initial router sends Redirect messages containing RIOs that 130 are processed by the recipient, the redirection Target MAY send its 131 own Redirect messages containing RIOs. These Redirect messages may 132 be either "solicited" (i.e., an ordinary Redirect) or "unsolicited" 133 (i.e., a Redirect generated without waiting for a packet to arrive). 135 An unsolicited Redirect message includes a Destination Address and 136 Redirected Header option that are either fabricated or derived from a 137 remembered packet that was processed at an earlier time. 138 Alternatively, the message could omit the Redirected Header option 139 and/or set the Destination Address field to "::" (the IPv6 140 unspecified address). Such a message would still satisfy the message 141 validation checks in Section 8.1 of [RFC4861]. 143 Any router may send RA messages with RIOs at any time, but these may 144 be dropped along some paths over layer-2 switch fabrics that 145 implement RA filtering. 147 3.3. Host Specification 149 The Host Specification follows Section 8.3 of [RFC4861], Section 3 of 150 [RFC4191], and Section 3 of [RFC8028]. According to [RFC4861], a 151 host that receives a valid Redirect message updates its destination 152 cache per the Destination Address and its neighbor cache per the 153 Target Address. According to [RFC4191], hosts can be classified as 154 Type "A", "B" or "C" based on how they process valid RA messages, 155 where a Type "C" host updates its routing table per any RIO elements 156 included in the message. Finally, according to [RFC8028], a Type "C" 157 host operating on a Multi-Prefix Network with multiple default routes 158 can make source address selection decisions based on information in 159 its routing table decorated with information derived from the source 160 of the RIO element. 162 In light of these considerations, this document introduces a new Type 163 "D" behavior for hosts with the same behavior as a Type "C" host, but 164 which also process RIO elements in Redirect messages. Type "D" hosts 165 process Redirect messages with RIO elements by updating 1) their 166 neighbor cache per the Target Address, 2) their destination cache per 167 the Destination Address, and 3) their routing tables per any RIO 168 elements present. The host can then make source address selection 169 decisions per [RFC8028] the same as described above. 171 When a Type "D" host processes a Redirect message, it SHOULD first 172 test the path to the Target using Neighbor Unreachability Detection 173 (NUD) while continuing to send packets via the router that issued the 174 Redirect until the NUD procedure converges. Thereafter, if a Route 175 Lifetime expires (or if an RIO with Route Lifetime 0 arrives) the 176 host removes the corresponding Prefix from its routing table and 177 allows future packets to follow a different route. 179 The behaviors of Type "A", "B" and "C" hosts defined in [RFC4191] are 180 not changed by this specification. This specification updates 181 Section 3 of [RFC4191] by introducing a new host Type "D", and 182 updates Section 8.3 of [RFC4861] by permitting RIOs to appear in 183 Redirect messages. 185 3.3.1. Type "D" Hosts with Delegated Prefixes 187 Type "D" hosts may be holders of entire IPv6 prefix delegations 188 instead of just a singleton address. For example, the host may 189 connect an entourage of "Internet of Things" devices that derive 190 their addresses from a delegated prefix. In that case, the host may 191 itself serve as a redirection target in a manner consistent with the 192 Router Specification above. Such Type "D" hosts act like a host in 193 terms of processing received Redirects and act like a router in terms 194 of sending Redirects. 196 4. Implementation Status 198 The Redirect function and RIOs are widely deployed in IPv6 199 implementations. 201 5. IANA Considerations 203 This document introduces no IANA considerations. 205 6. Security Considerations 207 The Redirect message validation rules in Section 8.1 of [RFC4861] 208 require recipients to verify that the IP source address of the 209 Redirect is the same as the current first-hop router for the 210 specified ICMP Destination Address. Recipients therefore naturally 211 reject any Redirect message with an incorrect source address. 213 Other security considerations for Redirect messages that include RIOs 214 are the same as for any IPv6 ND messages as specified in Section 11 215 of [RFC4861]. Namely, the protocol must take measures to secure IPv6 216 ND messages on links where spoofing attacks are possible. 218 A spoofed Redirect message containing no RIOs could cause corruption 219 in the host's destination cache while a spoofed Redirect message 220 containing RIOs could corrupt the host's routing tables. While the 221 latter would seem to be a more onerous result, the possibility for 222 corruption is unacceptable in either case. 224 "IPv6 ND Trust Models and Threats" [RFC3756] discusses spoofing 225 attacks, and states that: "This attack is not a concern if access to 226 the link is restricted to trusted nodes". "SEcure Neighbor Discovery 227 (SEND)" [RFC3971] provides one possible mitigation for other cases. 229 "IPv6 Router Advertisement Guard" [RFC6105] ("RA Guard") describes a 230 layer-2 filtering technique intended for network operators to use in 231 protecting hosts from receiving RA messages sent by nodes that are 232 not among the set of default routers regarded as legitimate by the 233 network operator. However, the RA Guard function defined in 234 [RFC6105] does not filter ND Redirect messages. On networks with 235 such RA Guard functions, routers that are blocked from sending RAs 236 can use ND Redirect messages to inform hosts of routes for specific 237 destination addresses. This draft introduces a new method by which 238 such routers can inform Type D hosts of routes for more specific 239 destination prefixes as well as addresses. 241 7. Acknowledgements 243 Joe Touch suggested a standalone draft to document this approach in 244 discussions on the intarea list. The work was subsequently 245 transferred to the 6man list, where the following individuals 246 provided valuable feedback: Mikael Abrahamsson, Zied Bouziri, Brian 247 Carpenter, Steinar Haug, Christian Huitema, Tomoyuki Sahara. 249 8. References 251 8.1. Normative References 253 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 254 DOI 10.17487/RFC0791, September 1981, 255 . 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, 259 DOI 10.17487/RFC2119, March 1997, 260 . 262 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 263 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 264 December 1998, . 266 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 267 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 268 November 2005, . 270 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 271 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 272 DOI 10.17487/RFC4861, September 2007, 273 . 275 8.2. Informative References 277 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 278 Neighbor Discovery (ND) Trust Models and Threats", 279 RFC 3756, DOI 10.17487/RFC3756, May 2004, 280 . 282 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 283 "SEcure Neighbor Discovery (SEND)", RFC 3971, 284 DOI 10.17487/RFC3971, March 2005, 285 . 287 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 288 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 289 DOI 10.17487/RFC6105, February 2011, 290 . 292 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 293 Hosts in a Multi-Prefix Network", RFC 8028, 294 DOI 10.17487/RFC8028, November 2016, 295 . 297 Appendix A. Link-layer Address Changes 299 Type "D" hosts send unsolicited Neighbor Advertisements (NAs) to 300 announce link-layer address changes per standard neighbor discovery 301 [RFC4861]. Link-layer address changes may be due to localized 302 factors such as hot-swap of an interface card, but could also occur 303 during movement to a new point of attachment on the same link. 305 Appendix B. Interfaces with Multiple Link-Layer Addresses 307 Type "D" host interfaces may have multiple connections to the link; 308 each with its own link-layer address. Type "D" nodes can therefore 309 include multiple link-layer address options in Redirects and other 310 IPv6 ND messages. Neighbors that receive these messages can cache 311 and select link-layer addresses in a manner outside the scope of this 312 specification. 314 Authors' Addresses 316 Fred L. Templin (editor) 317 Boeing Research & Technology 318 P.O. Box 3707 319 Seattle, WA 98124 320 USA 322 Email: fltemplin@acm.org 324 James Woodyatt 325 Google 326 3400 Hillview Ave 327 Palo Alto, CA 94304 328 USA 330 Email: jhw@google.com