idnits 2.17.1 draft-troan-6man-pmtu-solution-space-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 Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 28, 2018) is 2035 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) == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-datagram-plpmtud-04 == Outdated reference: A later version (-05) exists of draft-leddy-6man-truncate-04 ** Downref: Normative reference to an Experimental draft: draft-van-beijnum-multi-mtu (ref. 'I-D.van-beijnum-multi-mtu') ** Downref: Normative reference to an Informational RFC: RFC 2923 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Troan 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track September 28, 2018 5 Expires: April 1, 2019 7 Path MTU discovery solution space 8 draft-troan-6man-pmtu-solution-space-00 10 Abstract 12 Path MTU discovery has turned out to be a thorny problem that has 13 haunted the Internet community for decades. Lately there has been 14 some work both at the transport layer and at the network layer. This 15 memo lists the solutions the author is aware of from the perspective 16 of the network layer. 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 https://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 April 1, 2019. 35 Copyright Notice 37 Copyright (c) 2018 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 (https://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 Path MTU discovery has turned out to be harder than expeced. In IPv6 53 we set out following the same model as for IPv4. The sending host 54 maintains a MTU cache, that is updated based on received ICMP PMTUD 55 messages. That solution has a few short-comings: 57 o Sending of ICMP PMTUD messages is throttled in routers [RFC4443] 59 o It's not efficient if links along the path have decreasingly 60 smaller MTU, then multiple rounds of large packet, resulting ICMP 61 PMTUD happens. 63 o ICMP might be ignored by host stacks / applications 65 o As ICMP looks different than application traffic, it might be 66 blocked by routers. 68 o Doesn't work well in an anycast scenario (but what does). 70 2. Requirements / Goals 72 1. Avoid MTU black-holes [RFC2923]. 74 2. Detect the Path MTU in single round trip. 76 3. Adapt to varying MTU over the connection life time. 78 4. The signalling of the MTU back to the sender must be 79 indistinguishable from application traffic to lessen risk of 80 filtering. 82 5. Design a mechanism that ensures that neither MTU probes nor MTU 83 signalling back to sender are more likely to be dropped than 84 other application traffic. 86 6. Must be deployable and anchored in transport / application areas. 87 Otherwise https://xkcd.com/927/ 89 7. [Optional?] Support neighbors on the same link which support 90 higher MTU than link MTU see [I-D.van-beijnum-multi-mtu] 92 3. Network layer solutions for Path MTU discovery 94 o PMTUD [RFC8201] 96 o On-path fragmentation, IPv4 style. We know this one. 98 o Packet truncation. [I-D.leddy-6man-truncate]. The source sets a 99 truncation elligble flag in the packet, routers on the path may 100 truncate f the packet is too big, and sets a truncated done flag. 101 Then the receiver signals the learnt forward MTU back to the 102 sender. Either via existing ICMP PMTUD or a transport layer 103 option. This is an example of a solution which does not require 104 the sender having to accept packets from intermediate nodes. 106 o MTU recording. Probe packets are sent, either as part of data 107 packets, if those are guaranteed not to exceed MTU. Some trigger 108 in the header (ECN like flags) or a HBH option is required for the 109 router to record the smallest MTU along the path. Application / 110 Transport would have to periodically include the probe trigger in 111 data packets to detect changes in path MTU. 113 3.1. Common problems 115 How is the router along the path "triggered" to put this packet on 116 the exception path? For current and the truncation scheme it's a 117 simple check in the forwarding path for the size of packet versus 118 outgoing interface MTU. For e.g. a recording MTU mechanism it would 119 have to be flags in the IPv6 header or an HBH option. 121 How should the forward path MTU be signalled back to the sender? The 122 signal should look like any other application traffic to avoid 123 filtering or is it sufficient to avoid sending from intermitent 124 nodes. 126 4. Solutions at other layers 128 In addition there are solutions at the transport layer, that work in 129 co-hort or independently of the network layer soltusions. [RFC4821] 130 and [I-D.ietf-tsvwg-datagram-plpmtud]. 132 One could also imagine other solutions, e.g. to include MTU in router 133 advertisements in BGP, so that a BGP speaker could calculate the end 134 to end MTU across the set of administrative domains. 136 5. Conclusion 138 What are our options? Even if we developed a new PMTU mechanism, IP 139 stacks must deal with networks where the new mechanism isn't yet 140 deployed. Will a new mechanism be so much better that it provides 141 enough value for it to be deployed? Or should we at the network 142 layer just punt this to transport? 144 6. References 146 [I-D.ietf-tsvwg-datagram-plpmtud] 147 Fairhurst, G., Jones, T., Tuexen, M., and I. Ruengeler, 148 "Packetization Layer Path MTU Discovery for Datagram 149 Transports", draft-ietf-tsvwg-datagram-plpmtud-04 (work in 150 progress), September 2018. 152 [I-D.leddy-6man-truncate] 153 Leddy, J. and R. Bonica, "IPv6 Packet Truncation", draft- 154 leddy-6man-truncate-04 (work in progress), June 2018. 156 [I-D.van-beijnum-multi-mtu] 157 Beijnum, I., "Extensions for Multi-MTU Subnets", draft- 158 van-beijnum-multi-mtu-05 (work in progress), March 2016. 160 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 161 RFC 2923, DOI 10.17487/RFC2923, September 2000, 162 . 164 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 165 Control Message Protocol (ICMPv6) for the Internet 166 Protocol Version 6 (IPv6) Specification", STD 89, 167 RFC 4443, DOI 10.17487/RFC4443, March 2006, 168 . 170 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 171 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 172 . 174 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 175 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 176 DOI 10.17487/RFC8201, July 2017, 177 . 179 Author's Address 181 Ole Troan 182 Cisco Systems 183 Philip Pedersens vei 1 184 Lysaker 1366 185 Norway 187 Email: ot@cisco.com