< draft-hinden-6man-mtu-option-01.txt   draft-hinden-6man-mtu-option-02.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: September 12, 2019 University of Aberdeen Expires: January 6, 2020 University of Aberdeen
March 11, 2019 July 5, 2019
IPv6 Minimum Path MTU Hop-by-Hop Option IPv6 Minimum Path MTU Hop-by-Hop Option
draft-hinden-6man-mtu-option-01 draft-hinden-6man-mtu-option-02
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 to a destination host. This collects a minimum recorded MTU along
the path to the destination. The value can then be communicated back the path to the destination. The value can then be communicated back
to the source host by an ICMPv6 Packet Too Big message. 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 to IETF in full conformance with the This Internet-Draft is submitted to IETF 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 September 12, 2019. This Internet-Draft will expire on January 6, 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 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivation and Problem Solved . . . . . . . . . . . . . . . . 4 2. Motivation and Problem Solved . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
4. Applicability Statements . . . . . . . . . . . . . . . . . . 5 4. Applicability Statements . . . . . . . . . . . . . . . . . . 5
5. IPv6 Minimum Path MTU Hop-by-Hop Option . . . . . . . . . . . 5 5. IPv6 Minimum Path MTU Hop-by-Hop Option . . . . . . . . . . . 5
6. Router, Host, and Transport Behaviors . . . . . . . . . . . . 6 6. Router, Host, and Transport Behaviors . . . . . . . . . . . . 6
6.1. Router Behaviour . . . . . . . . . . . . . . . . . . . . 6 6.1. Router Behaviour . . . . . . . . . . . . . . . . . . . . 6
6.2. Host Behavior . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Host Behavior . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Transport Behavior . . . . . . . . . . . . . . . . . . . 8 6.3. Transport Behavior . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 10 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Planned Experiments . . . . . . . . . . . . . . . . 12 Appendix A. Planned Experiments . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 nodes. The source node 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 node, the Destination node can send the minimum reported
PMTU value back to the Source Node. This can be done by creating an PMTU value back to the Source Node using the Return PMTU field in the
ICMPv6 Packet Too Big message. 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 Sender and Destination
nodes comprises three links, the sender has a link MTU of size MTU-S, nodes 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 8 KBytes, 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 +----+ 8 KB +----+ MTU-D +-------+ +--------+ MTU-S +----+ 9000B +----+ MTU-D +-------+
The scenarios are described: The scenarios are described:
Scenario 1, considers all links to have an 8 KByte MTU and the method Scenario 1, considers all links to have an 9000 Byte MTU and the
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 destination link to have an MTU of 1500
Byte. This is the smallest MTU, router R2 resets the reported PMTU Byte. This is the smallest MTU, router R2 resets the reported PMTU
to 1500 Byte and this is detected by the method. Had there been to 1500 Byte and this is detected by the method. Had there been
another smaller MTU at a link further along the path that supports another smaller MTU at a link further along the path that supports
the method, the lower PMTU would also have been detected. 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. This scenario would also arise if the PTB message was
not delivered to the sender. not delivered to the sender.
+-+-----+-----+----+----+----------+-----------------------+ +-+-----+-----+----+----+----------+-----------------------+
| |MTU-S|MTU-D| R1 | R2 | Rec PMTU | Note | | |MTU-S|MTU-D| R1 | R2 | Rec PMTU | Note |
+-+-----+-----+----+----+----------+-----------------------+ +-+-----+-----+----+----+----------+-----------------------+
|1| 8KB | 8KB | H | H | 8 KB | Endpoints attempt to | |1|9000B|9000B| H | H | 9000 B | Endpoints attempt to |
| | | | | | use an 8 KB PMTU. | | | | | | | use an 9000 B PMTU. |
+-+-----+-----+----+----+----------+-----------------------+ +-+-----+-----+----+----+----------+-----------------------+
|2| 8KB |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. |
+-+-----+-----+----+----+----------+-----------------------+ +-+-----+-----+----+----+----------+-----------------------+
|3| 8KB |1500B| H | - | 8 KB | Endpoints attempt to | |3|9000B|1500B| H | - | 9000 B | Endpoints attempt to |
| | | | | | | use an 8 KB PMTU, but | | | | | | | | use an 9000 B PMTU, |
| | | | | | | need to implement a | | | | | | | | but need to implement |
| | | | | | | method to fall back | | | | | | | | a method to fall back |
| | | | | | | use a 1500 B PMTU. | | | | | | | | use a 1500 B PMTU. |
+-+-----+-----+----+----+----------+-----------------------+ +-+-----+-----+----+----+----------+-----------------------+
IPv6 as specified in [RFC8200] allows nodes to optionally process IPv6 as specified in [RFC8200] allows nodes to optionally process
Hop-by-Hop headers. Specifically from Section 4: Hop-by-Hop headers. Specifically from Section 4:
o The Hop-by-Hop Options header is not inserted or deleted, but may o The Hop-by-Hop Options header is not inserted or deleted, but may
be examined or processed by any node along a packet's delivery be examined or processed by any node along a packet's delivery
path, until the packet reaches the node (or each of the set of path, until the packet reaches the node (or each of the set of
nodes, in the case of multicast) identified in the Destination nodes, in the case of multicast) identified in the Destination
skipping to change at page 6, line 5 skipping to change at page 6, line 5
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.
5. IPv6 Minimum Path MTU Hop-by-Hop Option 5. IPv6 Minimum Path MTU Hop-by-Hop Option
The Minimum Path MTU Hop-by-Hop Option has the following format: The Minimum Path MTU Hop-by-Hop Option has the following format:
Option Option Option Option Option Option
Type Data Len Data Type Data Len Data
+--------+--------+--------+--------+ +--------+--------+--------+--------+---------+-------+-+
|BBCTTTTT|00000010| 2 octet value | |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.
TTTT 11110 Expermental Option Type from [IANA-HBH]. TTTT 11110 Experimental Option Type from [IANA-HBH].
Length: 2 Note 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.
Value: n The Reported PMTU in octets, reflecting the smallest Min-PMTU: n 16-bits. The minimum PMTU in octets, reflecting the
link MTU that the packet experienced across the path. smallest link MTU that the packet experienced across
the path. This is called the Reported PMTU. A value
less than the IPv6 minimum link MTU [RFC8200]
should be ignored.
Rtn-PMTU: n 15-bits. The returned mimimum PMTU, carrying the 15
most significant bits of the latest received Min-PMTU
field. The value zero means that no Reported MTU is
being returned.
R n 1-bit. R-Flag. Set by the source to signal that
the destination should include the received
Reported PMTU in Rtn-PMTU field.
NOTE: The encoding of the final two octets (Rtn-PMTU and R-Flag)
could be implemented by a mask of the latest received Min-MTU value
with 0xFFFE, discarding the right-most bit and then performing a
logical 'OR' with the R-Flag value of the sender.
6. Router, Host, and Transport Behaviors 6. Router, Host, and Transport Behaviors
6.1. Router Behaviour 6.1. Router Behaviour
Routers that do not support Hop-by-Hop options SHOULD ignore this Routers that do not support Hop-by-Hop options SHOULD ignore this
option and SHOULD forward the packet. option and SHOULD forward the packet.
Routers that support Hop-by-Hop Options, but do not recognize this Routers that support Hop-by-Hop Options, but do not recognize this
option SHOULD ignore the option and SHOULD forward the packet. option SHOULD ignore the option and SHOULD forward the packet.
Routers that recognize this option SHOULD compare the Reported PMTU Routers that recognize this option SHOULD compare the Reported PMTU
in the Option Value field and the MTU configured for the outgoing in the Min-PMTU field and the MTU configured for the outgoing link.
link. If the MTU of the outgoing link is less than the Reported If the MTU of the outgoing link is less than the Reported PMTU, the
PMTU, the router rewrites the Reported PMTU in the Option to use the router rewrites the Reported PMTU in the Option to use the smaller
smaller value. value.
The router MUST ignore and not change the Rtn-PMTU field and R-Flag
in the option.
Discussion: Discussion:
o The design of this Hop-by-Hop Option makes it feasible to be o The design of this Hop-by-Hop Option makes it feasible to be
implemented within the fast path of a router, because the required implemented within the fast path of a router, because the required
processing is simple. processing is simple.
6.2. Host Behavior 6.2. Host Behavior
The source host that supports this option SHOULD create a packet with The source host that supports this option SHOULD create a packet with
this Hop-by-Hop Option and fill the Reported PMTU field of the option this Hop-by-Hop Option and fill the Min-PMTU field of the option with
with the MTU of configured for the link over which it will send the the MTU of configured for the link over which it will send the packet
packet on the next hop towards the destination. on the next hop towards the destination.
The source host may request that the destination host return the
received minimum MTU value by setting the R-Flag in the option. This
will cause the destination host to include a PMTU option in an
outgoing packet.
Discussion: Discussion:
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.
skipping to change at page 7, line 40 skipping to change at page 8, line 11
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 nodes [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 optimised 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.
A Destination Host MUST NOT respond to each packet received with this The Source Host can request the destination host to send a packet
option, when the option also carries the same received value. This carrying the PMTU Option using the R-Flag.
requires the implementation to cache the last received value of the
option. This is necessary to avoid generating excessive feedback
traffic. When sending an ICMPv6 Packet Too Big message the node MUST
follow the procedures in [RFC4443] and [RFC8201] to avoid sending too
many ICMPv6 Packet Too Big Messages to the source.
When a Destination Host, that supports this option, receives a packet A Destination Host SHOULD respond to each packet received with the
with this option, it SHOULD first compare the Reported PMTU value R-Flag set, by setting the PMTU Option in the next packet that it
with a value received earlier from this source. If this is the first sends to the Source Host by the same upper layer protocol instance.
value, or if the received value is lower, it SHOULD record the value
as the Received PMTU for the Source of the Packet, and it SHOULD send
the new value back to the Source of the packet. This can be done by
creating an ICMPv6 Packet Too Big message.
NOTE: The Received PMTU could also be reset by a timer to allow The upper layer protocol MAY generate a packet when any of these
periodic refresh of the state. This would also allow a sender to conditions is met when the R Flag is set in the PMTU Option and
discover cases where the Path MTU has increased (e.g., due to a either:
change in the forwarding path).
o It is the first Reported PMTU value it has received from the
Source.
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
carry the feedback of a Reported PMTU.
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
the Rtn-PMTU field. If these values are not present the field MUST
be set to zero.
For a connection-oriented upper layer protocol, this could be
implemented by saving the value of the last received option within
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
carry the IPv6 Minimum Path MTU Hop-by-Hop Option.
A connection-less protocol, e.g., based on UDP, requires the
application to be updated to cache the Received PMTU value, and to
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.
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
the SPI in IPsec, etc), not the protocol itself, because network
devices can make forwarding decisions that impact the PMTU based on
the presence and values of these upper layer fields, and therefore
these fields need to correspond to those of the packets for the flow
received by the Destination Host set to ensure feedback is provided
to the corresponding Source Host.
NOTE: An upper layer protocol that send packets from the Destination
Host towards the Source Host less frequently than the Destination
Host receives packets from the Source Host, provides less frequent
feedback of the received Min-PMTU value. However, it will always
needs to send the most recent value.
Discussion: Discussion:
o A simple mechanism could only send an ICMPv6 Packet Too Big o A simple mechanism could only send an MTU Option with the Rtn-PMTU
message 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
Path MTU if the ICMPv6 Packet Too Big Message fails to reach the PMTU Option fails to reach the sender, or the sender looses state.
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 A transport endpoint using this option needs to use a method to
verify the information provided by this option. verify the information provided by this option.
skipping to change at page 9, line 37 skipping to change at page 10, line 37
Since the method can delay notification of an increase in the actual Since the method can delay notification of an increase in the actual
PMTU, a sender with a link MTU larger than the current PMTU SHOULD PMTU, a sender with a link MTU larger than the current PMTU SHOULD
periodically probe for a PMTU value that is larger than the Received periodically probe for a PMTU value that is larger than the Received
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). Specifically, whether a Received
PMTU value should be maintained by the method for each transport PMTU value should be maintained by the method for each transport
endpoint, or for each network address, and how these are best used by endpoint, or for each network address, and how these are best used by
methods such as PLPMTUD or DPLPMTUD. methods such as PLPMTUD or DPLPMTUD.
7. IANA Considerations 7. IANA Considerations
No IANA assignments are requested. Document uses experimental option No IANA assignments are requested. Document uses experimental option
skipping to change at page 10, line 36 skipping to change at page 11, line 36
validate that the message is in response to a packet that was validate that the message is in response to a packet that was
originated by the sender. This is intended to provide protection originated by the sender. This is intended to provide protection
against off-path insertion of ICMP PTB messages by an attacker trying against off-path insertion of ICMP PTB messages by an attacker trying
to disrupt the service. Messages that fail this check MAY be logged, to disrupt the service. Messages that fail this check MAY be logged,
but the information they contain MUST be discarded. but the information they contain MUST be discarded.
TBD TBD
9. Acknowledgments 9. Acknowledgments
Helpful comments were received from [your name here] and other A somewhat similar mechanism was proposed for IPv4 in 1988 in
members of the 6MAN working group. [RFC1063] by Jeff Mogul, C. Kent, Craig Partridge, and Keith
McCloghire. It was later obsoleted in 1990 by [RFC1191] the current
deployed approach to Path MTU Discovery.
Helpful comments were received from Tom Herbert, Tom Jones, Fred
Templin, Ole Troan, [Your name here], and other members of the 6MAN
working group.
10. Change log [RFC Editor: Please remove] 10. Change log [RFC Editor: Please remove]
draft-hinden-6man-mtu-option-02, 2019-July-5
o Changed option format to also include the Returned MTU value and
Return flag and made related text changes in Section 6.2 to
describe this behaviour.
o ICMP Packet Too Big messages are no longer used for feedback to
the Source host.
o Added to Acknowledgements Section that a similar mechanism was
proposed for IPv4 in 1988 in [RFC1063].
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
describe what the purpose of this document is. describe what the purpose of this document is.
o Added Appendix A describing planned experiments and how the o Added Appendix A describing planned experiments and how the
results will be measured. results will be measured.
o Editorial changes. o Editorial changes.
skipping to change at page 11, line 20 skipping to change at page 12, line 40
[IANA-HBH] [IANA-HBH]
"Destination Options and Hop-by-Hop Options", "Destination Options and Hop-by-Hop Options",
<https://www.iana.org/assignments/ipv6-parameters/ <https://www.iana.org/assignments/ipv6-parameters/
ipv6-parameters.xhtml#ipv6-parameters-2>. ipv6-parameters.xhtml#ipv6-parameters-2>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, <https://www.rfc-editor.org/info/ RFC2119, March 1997, <https://www.rfc-editor.org/info/
rfc2119>. rfc2119>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/ (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/
RFC8200, July 2017, <https://www.rfc-editor.org/info/ RFC8200, July 2017, <https://www.rfc-editor.org/info/
rfc8200>. rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, <https://www.rfc- DOI 10.17487/RFC8201, July 2017, <https://www.rfc-
editor.org/info/rfc8201>. editor.org/info/rfc8201>.
11.2. Informative References 11.2. Informative References
[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP
MTU discovery options", RFC 1063, DOI 10.17487/RFC1063,
July 1988, <https://www.rfc-editor.org/info/rfc1063>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, <https://www.rfc-
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>.
[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
 End of changes. 28 change blocks. 
75 lines changed or deleted 148 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/