Internet DRAFT - draft-troan-6man-pmtu-solution-space
draft-troan-6man-pmtu-solution-space
Network Working Group O. Troan
Internet-Draft Cisco Systems
Intended status: Standards Track September 28, 2018
Expires: April 1, 2019
Path MTU discovery solution space
draft-troan-6man-pmtu-solution-space-00
Abstract
Path MTU discovery has turned out to be a thorny problem that has
haunted the Internet community for decades. Lately there has been
some work both at the transport layer and at the network layer. This
memo lists the solutions the author is aware of from the perspective
of the network layer.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 1, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Troan Expires April 1, 2019 [Page 1]
Internet-Draft September 2018
1. Introduction
Path MTU discovery has turned out to be harder than expeced. In IPv6
we set out following the same model as for IPv4. The sending host
maintains a MTU cache, that is updated based on received ICMP PMTUD
messages. That solution has a few short-comings:
o Sending of ICMP PMTUD messages is throttled in routers [RFC4443]
o It's not efficient if links along the path have decreasingly
smaller MTU, then multiple rounds of large packet, resulting ICMP
PMTUD happens.
o ICMP might be ignored by host stacks / applications
o As ICMP looks different than application traffic, it might be
blocked by routers.
o Doesn't work well in an anycast scenario (but what does).
2. Requirements / Goals
1. Avoid MTU black-holes [RFC2923].
2. Detect the Path MTU in single round trip.
3. Adapt to varying MTU over the connection life time.
4. The signalling of the MTU back to the sender must be
indistinguishable from application traffic to lessen risk of
filtering.
5. Design a mechanism that ensures that neither MTU probes nor MTU
signalling back to sender are more likely to be dropped than
other application traffic.
6. Must be deployable and anchored in transport / application areas.
Otherwise https://xkcd.com/927/
7. [Optional?] Support neighbors on the same link which support
higher MTU than link MTU see [I-D.van-beijnum-multi-mtu]
3. Network layer solutions for Path MTU discovery
o PMTUD [RFC8201]
o On-path fragmentation, IPv4 style. We know this one.
Troan Expires April 1, 2019 [Page 2]
Internet-Draft September 2018
o Packet truncation. [I-D.leddy-6man-truncate]. The source sets a
truncation elligble flag in the packet, routers on the path may
truncate f the packet is too big, and sets a truncated done flag.
Then the receiver signals the learnt forward MTU back to the
sender. Either via existing ICMP PMTUD or a transport layer
option. This is an example of a solution which does not require
the sender having to accept packets from intermediate nodes.
o MTU recording. Probe packets are sent, either as part of data
packets, if those are guaranteed not to exceed MTU. Some trigger
in the header (ECN like flags) or a HBH option is required for the
router to record the smallest MTU along the path. Application /
Transport would have to periodically include the probe trigger in
data packets to detect changes in path MTU.
3.1. Common problems
How is the router along the path "triggered" to put this packet on
the exception path? For current and the truncation scheme it's a
simple check in the forwarding path for the size of packet versus
outgoing interface MTU. For e.g. a recording MTU mechanism it would
have to be flags in the IPv6 header or an HBH option.
How should the forward path MTU be signalled back to the sender? The
signal should look like any other application traffic to avoid
filtering or is it sufficient to avoid sending from intermitent
nodes.
4. Solutions at other layers
In addition there are solutions at the transport layer, that work in
co-hort or independently of the network layer soltusions. [RFC4821]
and [I-D.ietf-tsvwg-datagram-plpmtud].
One could also imagine other solutions, e.g. to include MTU in router
advertisements in BGP, so that a BGP speaker could calculate the end
to end MTU across the set of administrative domains.
5. Conclusion
What are our options? Even if we developed a new PMTU mechanism, IP
stacks must deal with networks where the new mechanism isn't yet
deployed. Will a new mechanism be so much better that it provides
enough value for it to be deployed? Or should we at the network
layer just punt this to transport?
Troan Expires April 1, 2019 [Page 3]
Internet-Draft September 2018
6. References
[I-D.ietf-tsvwg-datagram-plpmtud]
Fairhurst, G., Jones, T., Tuexen, M., and I. Ruengeler,
"Packetization Layer Path MTU Discovery for Datagram
Transports", draft-ietf-tsvwg-datagram-plpmtud-04 (work in
progress), September 2018.
[I-D.leddy-6man-truncate]
Leddy, J. and R. Bonica, "IPv6 Packet Truncation", draft-
leddy-6man-truncate-04 (work in progress), June 2018.
[I-D.van-beijnum-multi-mtu]
Beijnum, I., "Extensions for Multi-MTU Subnets", draft-
van-beijnum-multi-mtu-05 (work in progress), March 2016.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, DOI 10.17487/RFC2923, September 2000,
<https://www.rfc-editor.org/info/rfc2923>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
Author's Address
Ole Troan
Cisco Systems
Philip Pedersens vei 1
Lysaker 1366
Norway
Email: ot@cisco.com
Troan Expires April 1, 2019 [Page 4]
