draft-ietf-6man-mtu-option-00.txt   draft-ietf-6man-mtu-option-01.txt 
Network Working Group R. Hinden Network Working Group R. Hinden
Internet-Draft Check Point Software Internet-Draft Check Point Software
Intended status: Experimental G. Fairhurst Intended status: Experimental G. Fairhurst
Expires: February 10, 2020 University of Aberdeen Expires: March 16, 2020 University of Aberdeen
August 9, 2019 September 13, 2019
IPv6 Minimum Path MTU Hop-by-Hop Option IPv6 Minimum Path MTU Hop-by-Hop Option
draft-ietf-6man-mtu-option-00 draft-ietf-6man-mtu-option-01
Abstract Abstract
This document specifies a new Hop-by-Hop IPv6 option that is used to This document specifies a new Hop-by-Hop IPv6 option that is used to
record the minimum Path MTU along the forward path between a source record the minimum Path MTU along the forward path between a source
to a destination host. This collects a minimum recorded MTU along host to a destination host. This collects a minimum recorded MTU
the path to the destination. The value can then be communicated back along the path to the destination. The value can then be
to the source using the return Path MTU field in the option. communicated back to the source using the return Path MTU field in
the option.
This Hop-by-Hop option is intended to be used in environments like This Hop-by-Hop option is intended to be used in environments like
Data Centers and on paths between Data Centers, to allow them to Data Centers and on paths between Data Centers, to allow them to
better take advantage of paths able to support a large Path MTU. better take advantage of paths able to support a large Path MTU.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 10, 2020. This Internet-Draft will expire on March 16, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 36
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Planned Experiments . . . . . . . . . . . . . . . . 13 Appendix A. Planned Experiments . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This draft proposes a new Hop-by-Hop Option to be used to record the This draft proposes a new Hop-by-Hop Option to be used to record the
minimum MTU along the forward path between the source and destination minimum MTU along the forward path between the source and destination
nodes. The source node creates a packet with this Hop-by-Hop Option hosts. The source host creates a packet with this Hop-by-Hop Option
and fills the Reported PMTU Field in the option with the value of the and fills the Reported PMTU Field in the option with the value of the
MTU for the outbound link that will be used to forward the packet MTU for the outbound link that will be used to forward the packet
towards the destination. towards the destination.
At each subsequent hop where the option is processed, the router At each subsequent hop where the option is processed, the router
compares the value of the Reported PMTU in the option and the MTU of compares the value of the Reported PMTU in the option and the MTU of
its outgoing link. If the MTU of the outgoing link is less than the its outgoing link. If the MTU of the outgoing link is less than the
Reported PMTU specified in the option, it rewrites the value in the Reported PMTU specified in the option, it rewrites the value in the
Option Data with the smaller value. When the packet arrives at the Option Data with the smaller value. When the packet arrives at the
Destination node, the Destination node can send the minimum reported destination host, the destination host can send the minimum reported
PMTU value back to the Source Node using the Return PMTU field in the PMTU value back to the source host using the Return PMTU field in the
option. option.
The figure below can be used to illustrate the operation of the The figure below can be used to illustrate the operation of the
method. In this case, the path between the Sender and Destination method. In this case, the path between the source and destination
nodes comprises three links, the sender has a link MTU of size MTU-S, hosts comprises three links, the sender has a link MTU of size MTU-S,
the link between routers R1 and R2 has an MTU of size 8 KBytes, and the link between routers R1 and R2 has an MTU of size 9000 bytes, and
the final link to the destination has an MTU of size MTU-D. the final link to the destination has an MTU of size MTU-D.
+--------+ +----+ +----+ +-------+ +--------+ +----+ +----+ +-------+
| | | | | | | | | | | | | | | |
| Sender +---------+ R1 +--------+ R2 +-------- + Dest. | | Sender +---------+ R1 +--------+ R2 +-------- + Dest. |
| | | | | | | | | | | | | | | |
+--------+ MTU-S +----+ 9000B +----+ MTU-D +-------+ +--------+ MTU-S +----+ 9000B +----+ MTU-D +-------+
The scenarios are described: The scenarios are described:
Scenario 1, considers all links to have an 9000 Byte MTU and the Scenario 1, considers all links to have an 9000 byte MTU and the
method is supported by both routers. method is supported by both routers.
Scenario 2, considers the destination link to have an MTU of 1500 Scenario 2, considers the link to the destination host (MTU-D) to
Byte. This is the smallest MTU, router R2 resets the reported PMTU have an MTU of 1500 bytes. This is the smallest MTU, router R2
to 1500 Byte and this is detected by the method. Had there been resets the reported PMTU to 1500 bytes and this is detected by the
another smaller MTU at a link further along the path that supports method. Had there been another smaller MTU at a link further along
the method, the lower PMTU would also have been detected. the path that supports the method, the lower PMTU would also have
been detected.
Scenario 3, considers the case where the router preceding the Scenario 3, considers the case where the router preceding the
smallest link does not support the method, and the method then fails smallest link does not support the method, and the method then fails
to detect the actual PMTU. These scenarios are summarized in the to detect the actual PMTU. These scenarios are summarized in the
table below. This scenario would also arise if the PTB message was table below. In this scenario, the lower PMTU would also fail to be
not delivered to the sender. detected had PMTUD been used and an ICMPv6 PTB message had not been
delivered to the sender.
+-+-----+-----+----+----+----------+-----------------------+ +-+-----+-----+----+----+----------+-----------------------+
| |MTU-S|MTU-D| R1 | R2 | Rec PMTU | Note | | |MTU-S|MTU-D| R1 | R2 | Rec PMTU | Note |
+-+-----+-----+----+----+----------+-----------------------+ +-+-----+-----+----+----+----------+-----------------------+
|1|9000B|9000B| H | H | 9000 B | Endpoints attempt to | |1|9000B|9000B| H | H | 9000 B | Endpoints attempt to |
| | | | | | use an 9000 B PMTU. | | | | | | | use an 9000 B PMTU. |
+-+-----+-----+----+----+----------+-----------------------+ +-+-----+-----+----+----+----------+-----------------------+
|2|9000B|1500B| H | H | 1500 B | Endpoints attempt to | |2|9000B|1500B| H | H | 1500 B | Endpoints attempt to |
| | | | | | | use a 1500 B PMTU. | | | | | | | | use a 1500 B PMTU. |
+-+-----+-----+----+----+----------+-----------------------+ +-+-----+-----+----+----+----------+-----------------------+
skipping to change at page 4, line 33 skipping to change at page 4, line 36
for all links along a path. for all links along a path.
2. Motivation and Problem Solved 2. Motivation and Problem Solved
The current state of Path MTU Discovery on the Internet is The current state of Path MTU Discovery on the Internet is
problematic. The problems with the mechanisms defined in [RFC8201] problematic. The problems with the mechanisms defined in [RFC8201]
are known to not work well in all environments. Nodes in the middle are known to not work well in all environments. Nodes in the middle
of the network may not send ICMP Packet Too Big messages or they are of the network may not send ICMP Packet Too Big messages or they are
rate limited to the point of not making them a useful mechanism. rate limited to the point of not making them a useful mechanism.
This results in many connection defaulting to 1280 octets and makes This results in many transport connections defaulting to 1280 bytes
it very difficult to take advantage of links with larger MTU where and makes it very difficult to take advantage of links with a larger
they exist. Applications that need to send large packets over UDP MTU where they exist. Applications that need to send large packets
are forced to use IPv6 Fragmentation. (e.g., using UDP) are forced to use IPv6 Fragmentation [RFC8200].
Transport encapsulations and network-layer tunnels reduce the PMTU Transport encapsulations and network-layer tunnels reduce the PMTU
available for a transport to use. For example, Network available for a transport to use. For example, Network
Virtualization Using Generic Routing Encapsulation (NVGRE) [RFC7637] Virtualization Using Generic Routing Encapsulation (NVGRE) [RFC7637]
encapsulates L2 packets in an outer IP header and does not allow IP encapsulates L2 packets in an outer IP header and does not allow IP
Fragmentation. Fragmentation.
The use of 10G Ethernet will not achieve it's potential because the The use of 10G Ethernet will not achieve it's potential because the
packet per second rate will exceed what most nodes can send to packet per second rate will exceed what most nodes can send to
achieve multi-gigabit rates if the packet size limited to 1280 achieve multi-gigabit rates if the packet size limited to 1280 bytes.
octets. For example, the packet per second rate required to reach For example, the packet per second rate required to reach wire speed
wire speed on a 10G Ethernet link with 1280 octet packets is about on a 10G Ethernet link with 1280 byte packets is about 977K packets
977K packets per second (pps), vs. 139K pps for 9,000 octet packets. per second (pps), vs. 139K pps for 9000 byte packets. A significant
A significant difference. difference.
The purpose of the this draft is to improve the situation by defining The purpose of the this draft is to improve the situation by defining
a mechanism that does not rely on nodes in the middle of the network a mechanism that does not rely on nodes in the middle of the network
to send ICMPv6 Packet Too Big messages, instead it provides the to send ICMPv6 Packet Too Big messages, instead it provides the
destination host information on the minimum Path MTU and it can send destination host information on the minimum Path MTU and it can send
this information back to the source host. This is expected to work this information back to the source host. This is expected to work
better than the current RFC8201 based mechanisms. better than the current RFC8201 based mechanisms.
3. Requirements Language 3. Requirements Language
skipping to change at page 5, line 26 skipping to change at page 5, line 28
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
4. Applicability Statements 4. Applicability Statements
This Hop-by-Hop Option header is intended to be used in environments This Hop-by-Hop Option header is intended to be used in environments
such as Data Centers and on paths between Data Centers, to allow them such as Data Centers and on paths between Data Centers, to allow them
to better take advantage of a path that is able to support a large to better take advantage of a path that is able to support a large
PMTU. For example, it helps inform a sender that the path includes PMTU. For example, it helps inform a sender that the path includes
links that have a MTU of 9,000 Bytes. This has many performance links that have a MTU of 9000 bytes. This has many performance
advantages compared to the current practice of limiting packets to advantages compared to the current practice of limiting packets to
1280 Bytes. 1280 bytes.
The design of the option is sufficiently simple that it could be The design of the option is sufficiently simple that it could be
executed on a router's fast path. To create critical mass for this executed on a router's fast path. To create critical mass for this
to happen will have to be a strong pull from router vendors to happen will have to be a strong pull from router vendors
customers. This could be the case for connections within and between customers. This could be the case for connections within and between
Data Centers. Data Centers.
The method could also be useful in other environments, including the The method could also be useful in other environments, including the
general Internet. general Internet.
skipping to change at page 6, line 18 skipping to change at page 6, line 18
|BBCTTTTT|00000100| Min-PMTU | Rtn-PMTU |R| |BBCTTTTT|00000100| Min-PMTU | Rtn-PMTU |R|
+--------+--------+--------+--------+---------+-------+-+ +--------+--------+--------+--------+---------+-------+-+
Option Type: Option Type:
BB 00 Skip over this option and continue processing. BB 00 Skip over this option and continue processing.
C 1 Option data can change en route to the packet's final C 1 Option data can change en route to the packet's final
destination. destination.
TTTTT nnnnn Option Type assigned from IANA. TTTTT 10000 Option Type assigned from IANA [IANA-HBH].
Length: 4 The size of the each value field in Option Data Length: 4 The size of the each value field in Option Data
field supports Path MTU values from 0 to 65,535 octets. field supports Path MTU values from 0 to 65,535 octets.
Min-PMTU: n 16-bits. The minimum PMTU in octets, reflecting the Min-PMTU: n 16-bits. The minimum PMTU in octets, reflecting the
smallest link MTU that the packet experienced across smallest link MTU that the packet experienced across
the path. This is called the Reported PMTU. A value the path. This is called the Reported PMTU. A value
less than the IPv6 minimum link MTU [RFC8200] less than the IPv6 minimum link MTU [RFC8200]
should be ignored. should be ignored.
skipping to change at page 7, line 43 skipping to change at page 7, line 43
o This option does not need to be sent in all packets belonging to a o This option does not need to be sent in all packets belonging to a
flow. A transport protocol (or packetization layer) can set this flow. A transport protocol (or packetization layer) can set this
option only on specific packets used to test the path. option only on specific packets used to test the path.
o In the case of TCP, the option could be included in packets o In the case of TCP, the option could be included in packets
carrying a SYN segment as part of the connection set up, or can carrying a SYN segment as part of the connection set up, or can
periodically be sent in packets carrying other segments. periodically be sent in packets carrying other segments.
Including this packet in a SYN could increase the probability that Including this packet in a SYN could increase the probability that
SYN segment is lost, when routers on the path drop packets with SYN segment is lost, when routers on the path drop packets with
this option. Including this option in a large packet is not this option. Including this option in a large packet (e.g.,
likely to be useful, since the large packet might itself also be greater than the present PMTU) is not likely to be useful, since
dropped by a link along the path with a smaller MTU, preventing the large packet might itself also be dropped by a link along the
the Reported PMTU information from reaching the Destination node. path with a smaller MTU, preventing the Reported PMTU information
from reaching the destination host.
o The use with datagram transport protocols (e.g. UDP) is harder to o The use with datagram transport protocols (e.g., UDP) is harder to
characterize because applications using datagram transports range characterize because applications using datagram transports range
from very short-lived (low data-volume applications) exchanges, to from very short-lived (low data-volume applications) exchanges, to
longer (bulk) exchanges of packets between the Source and longer (bulk) exchanges of packets between the source and
Destination nodes [RFC8085]. destination hosts [RFC8085].
o For applications that use Anycast, this option should be included o For applications that use Anycast, this option should be included
in all packets as the actual destination will vary due to the in all packets as the actual destination will vary due to the
nature of Anycast. nature of Anycast.
o Simple-exchange protocols (i.e low data-volume applications o Simple-exchange protocols (i.e low data-volume applications
[RFC8085] that only send one or a few packets per transaction, [RFC8085] that only send one or a few packets per transaction,
could be optimized by assuming that the Path MTU is symmetrical, could be optimized by assuming that the Path MTU is symmetrical,
that is where the Path MTU is the same in both directions, or at that is where the Path MTU is the same in both directions, or at
least not smaller in the return path. This optimisation does not least not smaller in the return path. This optimisation does not
hold when the paths are not symmetric. hold when the paths are not symmetric.
o The use of this option with DNS and DNSSEC over UDP ought to work o The use of this option with DNS and DNSSEC over UDP ought to work
as long as the paths are symmetric. The DNS server will learn the as long as the paths are symmetric. The DNS server will learn the
Path MTU from the DNS query messages. If the return Path MTU is Path MTU from the DNS query messages. If the return Path MTU is
smaller, then the large DNSSEC response may be dropped and the smaller, then the large DNSSEC response may be dropped and the
known problems with PMTUD will occur. DNS and DNSSEC over known problems with PMTUD will occur. DNS and DNSSEC over
transport protocols that can carry the Path MTU should work. transport protocols that can carry the Path MTU should work.
The Source Host can request the destination host to send a packet The source host can request the destination host to send a packet
carrying the PMTU Option using the R-Flag. carrying the PMTU Option using the R-Flag.
A Destination Host SHOULD respond to each packet received with the A destination host SHOULD respond to each packet received with the
R-Flag set, by setting the PMTU Option in the next packet that it R-Flag set, by setting the PMTU Option in the next packet that it
sends to the Source Host by the same upper layer protocol instance. sends to the source host by the same upper layer protocol instance.
The upper layer protocol MAY generate a packet when any of these The upper layer protocol MAY generate a packet when any of these
conditions is met when the R Flag is set in the PMTU Option and conditions is met when the R Flag is set in the PMTU Option and
either: either:
o It is the first Reported PMTU value it has received from the o It is the first Reported PMTU value it has received from the
Source. source.
o The Reported PMTU value is lower than previously received. o The Reported PMTU value is lower than previously received.
The R-Flag SHOULD NOT be set when the PMTU Option was sent solely to The R-Flag SHOULD NOT be set when the PMTU Option was sent solely to
carry the feedback of a Reported PMTU. carry the feedback of a Reported PMTU.
The PMTU Option sent back to the source SHOULD contain the outgoing The PMTU Option sent back to the source SHOULD contain the outgoing
link MTU in Min-PMTU field and SHOULD set the last Received PMTU in link MTU in Min-PMTU field and SHOULD set the last Received PMTU in
the Rtn-PMTU field. If these values are not present the field MUST the Rtn-PMTU field. If these values are not present the field MUST
be set to zero. be set to zero.
For a connection-oriented upper layer protocol, this could be For a connection-oriented upper layer protocol, this could be
implemented by saving the value of the last received option within implemented by saving the value of the last received option within
the connection context. This last received value is then used to set the connection context. This last received value is then used to set
the return Path MTU field for all packets belonging to this flow that the return Path MTU field for all packets belonging to this flow that
carry the IPv6 Minimum Path MTU Hop-by-Hop Option. carry the IPv6 Minimum Path MTU Hop-by-Hop Option.
A connection-less protocol, e.g., based on UDP, requires the A connection-less protocol (e.g., based on UDP), requires the
application to be updated to cache the Received PMTU value, and to application to be updated to cache the Received PMTU value, and to
ensure that this corresponding value is used to set the last Received ensure that this corresponding value is used to set the last Received
PMTU in the Rtn-PMTU field of any PMTU Option that it sends. PMTU in the Rtn-PMTU field of any PMTU Option that it sends.
NOTE: The Rtn-PMTU value is specific to the instance of the upper NOTE: The Rtn-PMTU value is specific to the instance of the upper
layer protocol (i.e. matching the IPv6 flow ID, port-fields in UDP or layer protocol (i.e., matching the IPv6 flow ID, port-fields in UDP
the SPI in IPsec, etc), not the protocol itself, because network or the SPI in IPsec, etc), not the protocol itself, because network
devices can make forwarding decisions that impact the PMTU based on devices can make forwarding decisions that impact the PMTU based on
the presence and values of these upper layer fields, and therefore the presence and values of these upper layer fields, and therefore
these fields need to correspond to those of the packets for the flow these fields need to correspond to those of the packets for the flow
received by the Destination Host set to ensure feedback is provided received by the destination host set to ensure feedback is provided
to the corresponding Source Host. to the corresponding source host.
NOTE: An upper layer protocol that send packets from the Destination NOTE: An upper layer protocol that send packets from the destination
Host towards the Source Host less frequently than the Destination host towards the source host less frequently than the destination
Host receives packets from the Source Host, provides less frequent host receives packets from the source host, provides less frequent
feedback of the received Min-PMTU value. However, it will always feedback of the received Min-PMTU value. However, it will always
needs to send the most recent value. needs to send the most recent value.
Discussion: Discussion:
o A simple mechanism could only send an MTU Option with the Rtn-PMTU o A simple mechanism could only send an MTU Option with the Rtn-PMTU
field filled in the first time this option is received or when the field filled in the first time this option is received or when the
Received PMTU is reduced. This is good because it limits the Received PMTU is reduced. This is good because it limits the
number sent, but there is no provision for retransmission of the number sent, but there is no provision for retransmission of the
PMTU Option fails to reach the sender, or the sender looses state. PMTU Option fails to reach the sender, or the sender looses state.
o The Reported PMTU value could increase or decrease over time. For o The Reported PMTU value could increase or decrease over time. For
instance, it would increase when the path changes and the packets instance, it would increase when the path changes and the packets
become then forwarded over a link with a MTU larger than the link become then forwarded over a link with a MTU larger than the link
previously used. previously used.
6.3. Transport Behavior 6.3. Transport Behavior
A transport endpoint using this option needs to use a method to An upper layer protocol (e.g., transport endpoint) using this option
verify the information provided by this option. needs to use a method to verify the information provided by this
option.
The Received PMTU does not necessarily reflect the actual PMTU The Received PMTU does not necessarily reflect the actual PMTU
between the sender and destination. Care therefore needs to be between the sender and destination. Care therefore needs to be
exercised in using this value at the sender. Specifically: exercised in using this value at the sender. Specifically:
o If the Received PMTU value returned by the Destination is the same o If the Received PMTU value returned by the destination is the same
as the initial Reported PMTU value, there could still be a router as the initial Reported PMTU value, there could still be a router
or layer 2 device on the path that does not support this PMTU. or layer 2 device on the path that does not support this PMTU.
The usable PMTU therefore needs to be confirmed. The usable PMTU therefore needs to be confirmed.
o If the Received PMTU value returned by the Destination is smaller o If the Received PMTU value returned by the destination is smaller
than the initial Reported PMTU value, this is an indication that than the initial Reported PMTU value, this is an indication that
there is at least one router in the path with a smaller MTU. there is at least one router in the path with a smaller MTU.
There could still be another router or layer 2 device on the path There could still be another router or layer 2 device on the path
that does not support this MTU. that does not support this MTU.
o If the Received PMTU value returned by the Destination is larger o If the Received PMTU value returned by the destination is larger
than the initial Reported PMTU value, this may be a corrupted, than the initial Reported PMTU value, this may be a corrupted,
delayed or mis-ordered response, and SHOULD be ignored. delayed or mis-ordered response, and SHOULD be ignored.
A sender needs to discriminate between the Received PMTU value in a A sender needs to discriminate between the Received PMTU value in a
PTB message generated in response to a Hop-by-Hop option requesting PTB message generated in response to a Hop-by-Hop option requesting
this, and a PTB message received from a router on the path. this, and a PTB message received from a router on the path.
A PMTUD or PLPMTUD method could use the Received PMTU value as an A PMTUD or PLPMTUD method could use the Received PMTU value as an
initial target size to probe the path. This can significantly initial target size to probe the path. This can significantly
decrease the number of probe attempts (and hence time taken) to decrease the number of probe attempts (and hence time taken) to
skipping to change at page 10, line 40 skipping to change at page 10, line 42
PMTU value. This specification does not define an interval for the PMTU value. This specification does not define an interval for the
time between probes. time between probes.
Since the option consumes less capacity than an a full probe packet, Since the option consumes less capacity than an a full probe packet,
there may be advantage in using this to detect a change in the path there may be advantage in using this to detect a change in the path
characteristics. characteristics.
NOTE: Further details to be included in next version. NOTE: Further details to be included in next version.
NOTE: A future version of the document will consider more the impact NOTE: A future version of the document will consider more the impact
of Equal Cost Multipath (ECMP). Specifically, whether a Received of Equal Cost Multipath (ECMP) [RFC6438]. Specifically, whether a
PMTU value should be maintained by the method for each transport Received PMTU value should be maintained by the method for each
endpoint, or for each network address, and how these are best used by transport endpoint, or for each network address, and how these are
methods such as PLPMTUD or DPLPMTUD. best used by methods such as PLPMTUD or DPLPMTUD.
7. IANA Considerations 7. IANA Considerations
IANA is requested to assign and register a new IPv6 Hop-by-Hop Option No IANA actions are requested in this document.
Earlier IANA assigned and registered a new IPv6 Hop-by-Hop Option
type from the "Destination Options and Hop-by-Hop Options" registry type from the "Destination Options and Hop-by-Hop Options" registry
[IANA-HBH] as shown in Section 5. This assignment should have the [IANA-HBH]. This assignment is shown in Section 5.
"act" and "chg" bits set to 00 and 1.
8. Security Considerations 8. Security Considerations
The method has no way to protect the destination from off-path attack The method has no way to protect the destination from off-path attack
using this option in packets that do not originate from the source. using this option in packets that do not originate from the source.
This attack could be used to inflate or reduce the size of the This attack could be used to inflate or reduce the size of the
reported PMTU. Mechanisms to provide this protection can be provided reported PMTU. Mechanisms to provide this protection can be provided
at a higher layer (e.g., the transport packetization layer using at a higher layer (e.g., the transport packetization layer using
PLPMTUD or DPLPMTUD), where more information is available about the PLPMTUD or DPLPMTUD), where more information is available about the
size of packet that has successfully traversed a path. size of packet that has successfully traversed a path.
The method solicits a response from the destination, which should be The method solicits a response from the destination, which should be
used to generate a response to the IPv6 node originating the option used to generate a response to the IPv6 host originating the option
packet. A malicious attacker could generate a packet to the packet. A malicious attacker could generate a packet to the
destination for a previously inactive flow or one that advertises a destination for a previously inactive flow or one that advertises a
change in the size of the MTU for an active flow. This would create change in the size of the MTU for an active flow. This would create
additional work at the destination, and could induce creation of additional work at the destination, and could induce creation of
state when a new flow is created. It could potentially result in state when a new flow is created. It could potentially result in
additional traffic on the return path to the sender, which could be additional traffic on the return path to the sender, which could be
mitigated by limiting the rate at which responses are generated. mitigated by limiting the rate at which responses are generated.
A sender MUST check the quoted packet within the PTB message to
validate that the message is in response to a packet that was
originated by the sender. This is intended to provide protection
against off-path insertion of ICMP PTB messages by an attacker trying
to disrupt the service. Messages that fail this check MAY be logged,
but the information they contain MUST be discarded.
TBD TBD
9. Acknowledgments 9. Acknowledgments
A somewhat similar mechanism was proposed for IPv4 in 1988 in A somewhat similar mechanism was proposed for IPv4 in 1988 in
[RFC1063] by Jeff Mogul, C. Kent, Craig Partridge, and Keith [RFC1063] by Jeff Mogul, C. Kent, Craig Partridge, and Keith
McCloghire. It was later obsoleted in 1990 by [RFC1191] the current McCloghire. It was later obsoleted in 1990 by [RFC1191] the current
deployed approach to Path MTU Discovery. deployed approach to Path MTU Discovery.
Helpful comments were received from Tom Herbert, Tom Jones, Fred Helpful comments were received from Tom Herbert, Tom Jones, Fred
Templin, Ole Troan, [Your name here], and other members of the 6MAN Templin, Ole Troan, [Your name here], and other members of the 6MAN
working group. working group.
10. Change log [RFC Editor: Please remove] 10. Change log [RFC Editor: Please remove]
draft-ietf-6man-mtu-option-00, 2019-August-9 draft-ietf-6man-mtu-option-01, 2019-September-13
o Changes to show IANA assigned code point.
o Editorial changes to make text and terminology more consistent.
o Added a reference to RFC8200 in Section 2 and a reference to
RFC6438 in Section 6.3.
draft-ietf-6man-mtu-option-00, 2019-August-9
o First 6man w.g. draft version. o First 6man w.g. draft version.
o Changes to request IANA allocation of code point. o Changes to request IANA allocation of code point.
o Editorial changes. o Editorial changes.
draft-hinden-6man-mtu-option-02, 2019-July-5 draft-hinden-6man-mtu-option-02, 2019-July-5
o Changed option format to also include the Returned MTU value and o Changed option format to also include the Returned MTU value and
Return flag and made related text changes in Section 6.2 to Return flag and made related text changes in Section 6.2 to
describe this behaviour. describe this behaviour.
o ICMP Packet Too Big messages are no longer used for feedback to o ICMP Packet Too Big messages are no longer used for feedback to
the Source host. the source host.
o Added to Acknowledgements Section that a similar mechanism was o Added to Acknowledgements Section that a similar mechanism was
proposed for IPv4 in 1988 in [RFC1063]. proposed for IPv4 in 1988 in [RFC1063].
o Editorial changes. o Editorial changes.
draft-hinden-6man-mtu-option-01, 2019-March-05 draft-hinden-6man-mtu-option-01, 2019-March-05
o Changed requested status from Standards Track to Experimental to o Changed requested status from Standards Track to Experimental to
allow use of experimental option type (11110) to allow for allow use of experimental option type (11110) to allow for
experimentation. Removed request for IANA Option assignment. experimentation. Removed request for IANA Option assignment.
o Added Section 2 "Motivation and Problem Solved" section to better o Added Section 2 "Motivation and Problem Solved" section to better
skipping to change at page 13, line 24 skipping to change at page 13, line 29
July 1988, <https://www.rfc-editor.org/info/rfc1063>. July 1988, <https://www.rfc-editor.org/info/rfc1063>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, <https://www.rfc- DOI 10.17487/RFC1191, November 1990, <https://www.rfc-
editor.org/info/rfc1191>. editor.org/info/rfc1191>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation", RFC Virtualization Using Generic Routing Encapsulation", RFC
7637, DOI 10.17487/RFC7637, September 2015, 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>. <https://www.rfc-editor.org/info/rfc7637>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
Appendix A. Planned Experiments Appendix A. Planned Experiments
 End of changes. 39 change blocks. 
74 lines changed or deleted 84 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/