idnits 2.17.1 draft-zerorafolks-6man-ra-zero-lifetime-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 draft header indicates that this document updates RFC4862, 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (Using the creation date from RFC4862, updated by this document, for RFC5378 checks: 2004-02-10) -- 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 30, 2018) is 2127 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: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance L. Colitti 3 Internet-Draft E. Kline 4 Updates: 4862 (if approved) Google 5 Intended status: Standards Track June 30, 2018 6 Expires: January 1, 2019 8 Zero valid lifetimes on point-to-point links 9 draft-zerorafolks-6man-ra-zero-lifetime-00 11 Abstract 13 This document allows implementations to accept low or zero valid 14 lifetimes in Router Advertisement Prefix Information Options in cases 15 where it is known that there can only be one router on the link. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 1, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. Cases when it is useful to reduce Valid Lifetime to zero . . 2 54 3. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . . . 2 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 6.1. Normative References . . . . . . . . . . . . . . . . . . 3 59 6.2. Informative References . . . . . . . . . . . . . . . . . 3 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 3 62 1. Introduction 64 Currently, Prefix Information Options in Router Advertisements cannot 65 reduce the Valid Lifetime of an IPv6 address below 2 hours. This is 66 due to an explicit restriction in Section 5.5.3 of [RFC4862]. The 67 reason is to avoid a denial-of-service attack whereby a malicious 68 attacker can cause a node's addresses to expire prematurely by 69 sending a Router Advertisement with a low Valid Lifetime. 71 1.1. Requirements Language 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [RFC2119]. 77 2. Cases when it is useful to reduce Valid Lifetime to zero 79 In some cases, it is useful for the network to inform the host that a 80 given prefix is no longer valid or will shortly no longer be valid. 81 One example is if the host has moved beyond the mobility scope of the 82 prefix and the network will no longer deliver packets for that prefix 83 to the host. The host can thus terminate any upper-layer connections 84 using that prefix and notify applications that continued 85 communication will require using a new source address. 87 In order to ensure uninterrupted communications and no dispution to 88 applications, this should be done only if the host already has other 89 IPv6 addresses of equivalent scope and sufficient Valid Lifetime. 91 3. Changes to RFC 4862 93 The following clause is added between points 1 and 2 of clause e, 94 Section 5.5.3 of [RFC4862]: 96 2. If the link-layer guarantees that there is only one node on the 97 link from which the host can receive Router Advertiesements (e.g., 98 if the link is a point-to-point link, such as a PPP link or a 3GPP 99 link as defined in [RFC6459]), and the link has another prefix of 100 the same scope with sufficient Valid Lifetime, set the valid 101 lifetime of the corresponding address to the advertised Valid 102 Lifetime. 104 4. IANA Considerations 106 This memo includes no request to IANA. 108 5. Security Considerations 110 The denial-of-service attack that motivated this restriction cannot 111 be mounted on a link where no other devices can send Router 112 Advertisements to the host. 114 6. References 116 6.1. Normative References 118 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 119 Requirement Levels", BCP 14, RFC 2119, 120 DOI 10.17487/RFC2119, March 1997, 121 . 123 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 124 Address Autoconfiguration", RFC 4862, 125 DOI 10.17487/RFC4862, September 2007, 126 . 128 6.2. Informative References 130 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 131 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 132 Partnership Project (3GPP) Evolved Packet System (EPS)", 133 RFC 6459, DOI 10.17487/RFC6459, January 2012, 134 . 136 Authors' Addresses 137 Lorenzo Colitti 138 Google 139 Roppongi 6-10-1 140 Minato, Tokyo 106-6126 141 JP 143 Email: lorenzo@google.com 145 Erik Kline 146 Google 147 Roppongi 6-10-1 148 Minato, Tokyo 106-6126 149 JP 151 Email: ek@google.com