idnits 2.17.1 draft-kline-6man-pmo-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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1753 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Kline 3 Internet-Draft Loon LLC 4 Intended status: Standards Track July 8, 2019 5 Expires: January 9, 2020 7 IPv6 Path MTU Option 8 draft-kline-6man-pmo-00 10 Abstract 12 This document describes an IPv6 Neighbor Discovery (ND) Path MTU 13 Option (PMO) for inclusion in Router Advertisements (RAs). This 14 allows some environments greater flexibility to support, for example, 15 a higher MTU for on-link or intra-administrative-domain 16 communications than for broader Internet communications. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 9, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 This document describes an IPv6 Neighbor Discovery (ND) Path MTU 53 Option (PMO) for inclusion in Router Advertisements (RAs). This 54 allows some environments greater flexibility to support, for example, 55 a higher MTU for on-link or intra-administrative-domain 56 communications than for broader Internet communications. 58 TBD: Explain why extending RFC4191 RIOs didn't look easy. 60 TBD: more discussion 62 2. Terminology 64 2.1. Requirements Language 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 68 "OPTIONAL" in this document are to be interpreted as described in BCP 69 14 [RFC2119] [RFC8174] when, and only when, they appear in all 70 capitals, as shown here. 72 2.2. Summary of key terms 74 For the purposes of this document the following terms are used as 75 described here. 77 2.2.1. Link MTU 79 The MTU of the link ([RFC4861]); alternatively, the MTU as it would 80 be determined were no Path MTU Option (Section 2.2.5) present. This 81 may be: 83 the value specified in an MTU Option (Section 2.2.4), 85 a value specified in a separate document that covers operating IP 86 over a particular link type (e.g., [RFC2464]), or 88 a value derived by other means (e.g. administrative or a hint from 89 a sub-IP layer mechanism). 91 The Link MTU MUST be the initial Path MTU used when transmitting to 92 any link-local destination. 94 2.2.2. Path MTU 96 TBD: Path MTU 98 2.2.3. Path MTU Discovery 100 TBD: Path MTU Discovery (cite [RFC8201]) 102 2.2.4. MTU Option 104 The MTU Option is defined in [RFC4861] section 4.6.4. In this 105 documented it may also be referred to as the Link MTU Option, in 106 order to disambiguate it from this the Path MTU Option 107 (Section 2.2.5). 109 2.2.5. Path MTU Option 111 The IPv6 ND Path MTU Option is described in this document. It 112 provides more explicit signaling of the best initial Path MTU value 113 for a given set of destinations when sending via the advertising 114 router. 116 3. Path MTU Option Format 118 0 1 2 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Type | Length | MTU #1 (upper 16 bits) | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | MTU #1 (lower 16 bits) | num prefixes | prefix len #1 | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | prefix #1 ... | 126 . . 127 . . 128 . . 129 | ... | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Fields: 133 Type TBD 135 Length The length of the option in units of 8 octets. 137 When not set, the receiving node MUST NOT make any 138 assumptions of exclusive use of the specified Prefix, i.e. 139 processing is unchanged from previous standards behavior. 141 Option The contents of the option as described below. 142 contents 144 The Path MTU Option contents are encoded as a repeated sequence of: 146 4-octet MTU value 148 1-octet number of prefixes 150 sequence of prefixes to which this MTU applies 152 where each prefix is encoded as: 154 1-octet prefix length 156 variable length leading bits of prefix or IP address 158 Each sequence of octets representing a prefix uses only as many 159 octets as required to by the prefix length (e.g. for a prefix length 160 of 0: 0 octets are required, for prefix lengths 1 through 8: 1 octet 161 is required, and so on). 163 The option is padded with zero-valued octets to the 8 octet boundary 164 as given by the option length. 166 4. Option Processing Rules 168 Nodes compliant with this specification do not change their 169 processing of RAs that contain no Path MTU Options. Additionally, 170 for all Path MTU determination, an effective Path MTU learned via a 171 Path MTU Discovery mechanism ([RFC8201]) MUST take precedence. 173 Any IPv6 link-local prefixes listed within a Path MTU Option MUST be 174 ignored by the receiver and SHOULD be logged for review by an 175 administrator. 177 Any MTU value lower than the IPv6 minimum MTU (i.e. 1280, [RFC8200] 178 section 5), SHOULD be logged for administrator review as a 179 configuration error and MUST be treated by the receiver as though the 180 IPv6 minimum MTU had been the encoded value. 182 The Link MTU MUST also be used for all on-link destinations, to 183 maintain compatibility with existing behavior and expectations. For 184 the same reason, the Link MTU SHOULD be used for destinations within 185 any PIO prefix in the RA, even if the L bit is not set. As noted in 186 [RFC5942], a destination may at some time be learned to be on-link, 187 and this information may expire or be changed. 189 For all other destinations considered reachable via the option's 190 advertising router, an initial Path MTU SHOULD be determined by first 191 looking for a prefix that includes the destination in a Path MTU 192 Option and using the corresponding MTU value. If no such prefix 193 exists, the Link MTU SHOULD be assumed to be the default. 195 Note that as a matter of convenience a Path MTU Option may contain an 196 entry for ::/0 even when the router lifetime is zero. This in no way 197 indicates that the router will function as a default gateway. 198 Rather, it may be used, for example, to apply a Path MTU to all 199 prefixes listed in a set of RIOs. 201 5. Examples 203 TBD 205 6. Security Considerations 207 TBD 209 7. References 211 7.1. Normative References 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, 215 DOI 10.17487/RFC2119, March 1997, . 218 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 219 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 220 DOI 10.17487/RFC4861, September 2007, . 223 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 224 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 225 May 2017, . 227 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 228 (IPv6) Specification", STD 86, RFC 8200, 229 DOI 10.17487/RFC8200, July 2017, . 232 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 233 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 234 DOI 10.17487/RFC8201, July 2017, . 237 7.2. Informative References 239 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 240 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 241 . 243 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 244 Model: The Relationship between Links and Subnet 245 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 246 . 248 Author's Address 250 Erik Kline 251 Loon LLC 252 1600 Amphitheatre Parkway 253 Mountain View, California 94043 254 US 256 Email: ek@loon.com