IPv6 Minimum Path MTU Hop-by-Hop
OptionCheck Point Software959 Skyway RoadSan CarlosCA94070USAbob.hinden@gmail.comUniversity of AberdeenSchool of EngineeringFraser Noble BuildingAberdeenAB24 3UEUKgorry@erg.abdn.ac.ukThis 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 host
to a destination host.
The value can then be communicated back to
the source using the return Path MTU field in the option.This draft proposes a new IPv6 Hop-by-Hop Option to record
the minimum of the Maximum Transmission Unit (MTU) along the forward
path between a source and destination host. The source host creates a
packet with this option and fills the Min-PMTU field with the value of
the MTU for the outbound link that will be used to forward the packet
towards the destination host.At each subsequent hop where the option is processed, the router
compares the value of the Min-PMTU Field in the option and the MTU of
its outgoing link. If the MTU of the link is less than the Min-PMTU, it
rewrites the value in the option data with the smaller value. When the
packet arrives at the destination host, the host can send the value of
the minimum reported MTU for the path back to the source host using the
Rtn-PMTU field in the option. The source host can then use this value as
input to the method that sets the Path MTU (PMTU) used by upper layer
protocols.This method has the potential to complete discovery of the
correct value in a single round trip time, even over paths that
have successive links each configured with a lower MTU.The figure below illustrates the operation of the method. In this
case, the path between the source host and the destination host 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 9000 bytes, and the final link to
the destination has an MTU of size MTU-D.Three scenarios are described:
Scenario 1, considers all links to have an 9000 byte MTU and
the method is supported by both routers. The initial Min-PMTU is
not modified along the path, and therefore the PMTU is 9000
bytes.
Scenario 2, considers the link to the destination host (MTU-D)
to have an MTU of 1500 bytes. This is the smallest MTU, router R2
updates the Min-PMTU to 1500 bytes and the method correctly
updates the PMTU to 1500 bytes. Had there been another smaller MTU
at a link further along the path that also supports the method,
the lower MTU would also have been detected.
Scenario 3, considers the case where the router preceding the
smallest link (R2) does not support the method, and the link to
the destination host (MTU-D) has an MTU of 1500 bytes. Therefore,
router R2 does not update the Min-PMTU to 1500 bytes. The method
then fails to detect the actual PMTU.
In Scenarios 2 and 3, a lower PMTU would also fail to be detected
in the case where PMTUD had been used and an ICMPv6 Packet Too Big
(PTB) message had not been delivered to the sender .These scenarios are summarized in the table below. "H" in R1 and/or
R2 columns means the router understands the Minimum Path MTU
Hop-by-Hop option.IPv6 as specified in
allows nodes to optionally process Hop-by-Hop headers. Specifically
from Section 4:
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
path, until the packet reaches the node (or each of the set of
nodes, in the case of multicast) identified in the Destination
Address field of the IPv6 header. The Hop-by-Hop Options header,
when present, must immediately follow the IPv6 header. Its
presence is indicated by the value zero in the Next Header field
of the IPv6 header.
NOTE: While required
that all nodes must examine and process the Hop-by-Hop Options
header, it is now expected that nodes along a packet's delivery
path only examine and process the Hop-by-Hop Options header if
explicitly configured to do so.
The Hop-by-Hop Option defined in this document is designed to take
advantage of this property of how Hop-by-Hop options are processed.
Nodes that do not support this Option SHOULD ignore them. This can
mean that the Min-PMTU value does not account for all links along a
path.The current state of Path MTU Discovery on the Internet is
problematic. The mechanisms defined in are known to not work well in all environments. This
fails to work in various cases, including when nodes in the middle of
the network do not send ICMP PTB messages, or rate-limited ICMP
messages, or do not have a return path to the source host.This results in many transport connections being configured to use
smaller packets (e.g., 1280 bytes) by default and makes it difficult to
take advantage of paths with a larger PMTU where they do exist.
Applications
that send
large packets are forced
to use IPv6 Fragmentation ,
which can reduce the reliability of Internet communication .Encapsulations and network-layer tunnels further reduce the
payload size available for a transport to use. Also, some use-cases
increase packet overhead, for example, Network Virtualization Using
Generic Routing Encapsulation (NVGRE) encapsulates L2 packets in an outer IP header and
does not allow IP Fragmentation.Sending larger packets can improve host performance, e.g.,
avoiding limits to packet processing by the packet rate.
The potential of multi-gigabit
Ethernet will only be realized if the packet size is increased above 1280
bytes, to avoid exceeding a packet per second sending rate that
most hosts can process.
For example, the packet per second rate required to reach
wire speed on a 10G Ethernet link with 1280 byte packets is about 977K
packets per second (pps), vs. 139K pps for 9000 byte packets. A
significant difference.The purpose of the this draft is to improve the situation by defining
a mechanism that does not rely on reception of ICMPv6 Packet Too Big
messages from nodes in the middle of the network. Instead, this provides
information to the destination host about the minimum Path MTU, and
sends this information back to the source host. This is expected to work
better than the current RFC8201-based mechanisms.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and only when, they appear in all capitals, as
shown here.The Path MTU option is designed for environments where there is
control over the hosts and nodes that connect them, and where there
is more than one MTU size in use. For example in Data Centers and
on paths between Data Centers, to allow a hosts
to better take advantage of a path that is able to support a large
PMTU.The design of the option is sufficiently simple that it can be
executed on a router's fast path. A strong pull from router vendors
customers will be required to create critical mass for this to happen.
This could initially be the case for connections within and between Data
Centers.The method could also be useful in other environments, including the
general Internet, and offers advantage when this Hop-by-Hop Option is
supported on these paths. The method is more robust when used to probe
the path using packets that do not carry application data and when also
paired with a method such as Packetization Layer PMTUD or Datagram PLPMTUD .The Minimum Path MTU Hop-by-Hop Option has the following format:NOTE: The encoding of the final two octets (Rtn-PMTU and R-Flag)
could be implemented by a mask of the latest received Min-PMTU value
with 0xFFFE, discarding the right-most bit and then performing a logical
'OR' with the R-Flag value of the sender. This encoding fits
in the minimum-sized HBH Option header.
Routers that are not configured to support Hop-by-Hop Options
SHOULD ignore this option and SHOULD forward the packet .Routers that support Hop-by-Hop Options, but that are not
configured to support this option SHOULD ignore the option and SHOULD
forward the packet.Routers that support this option SHOULD compare the value of the
Min-PMTU field with the MTU configured for the outgoing link. If the
MTU of the outgoing link is less than the Min-PMTU, the router
rewrites the Min-PMTU in the Option to use the smaller value. (The
router processing is performed without checking the valid range of the
Min-PMTU or the Rtn-PMTU fields.)A router MUST ignore and MUST NOT change the Rtn-PMTU field or the
R-Flag in the option. Discussion:
The design of this option makes it feasible to be implemented
within the fast path of a router, because the processing
requirements are minimal.
The PMTU entry associated with the destination in the IP
layer cache can be updated using PMTUD after detecting a change
using the IPv6 Minimum Path MTU Hop-by-Hop Option. This cached
value can be used by other flows that share the IP cache.The value in the host IP layer cache could, for instance, be
used by PLPMTUD to select an initial PMTU for each flow before
a flow determines a PMTU for the specific path it is using
(e.g., using the IPv6 Minimum Path MTU Hop-by-Hop Option and
DPLPMTUD). The cached PMTU is only increased by PLPMTUD when
the PL determines the path actually supports a larger PMTU
.
When requested to send an IPv6 packet with the Minimum Path MTU
option, the source host includes the option in an outgoing packet.
The source host MUST fill the Min-PMTU field with the MTU configured
for the link over which it will send the packet on the next hop
towards the destination host.It sets the R Flag if it wishes the remote host to return
the discovered PMTU value.When a host includes the option in a packet it sends, the host
SHOULD set the Rtn-PMTU field to the previously cached value of the
received Minimum Path MTU for the flow in the Rtn-PMTU field (see
). If this value is not set (for
example, because there is no cached reported Min-PMTU value), the
Rtn-PMTU field value MUST be set to zero.The source host MAY request the destination host to return the
reported Min-PMTU value by setting the R-Flag in the option of an
outgoing packet. The R-Flag SHOULD NOT be set when the Minimum Path
MTU Option was sent solely to provide requested feedback on the
return Path MTU to avoid each response generating another
response.The normal sequence of operation of the R-Flag using the terminology from
the diagram in Figure 1 is:
Sender sends probe to Dest. Sender MUST set the R-Flag
Dest responds by sending a probe including the
received Min-PMTU as the Rtn-PMTU. Dest sets R-Flag only if response is
desired
Sender sends response probe back to Dest, MUST NOT set
R-Flag.
This Hop-by-Hop option is intended to be used with a path MTU
discovery method.Section 4.1 of
describes different types of PMTU Probe, depending on whether the
probe packets carry application data. When the path is expected to
support use of the option, the PMTU Probe can be sent on packets
that include application data, but needs to be robust to potential
loss of the packet with the possibility that retransmission might be
needed. Using a PMTU Probe on packets that do not carry application
data will avoid the need for loss recovery if a router on the path
later drops packets that set this option.
This avoids the transport needing to retransmit a lost packet
that includes this option. The upper layer protocol can request the Minimum Path MTU
option to be included in an outgoing IPv6 packet. A transport
protocol (or upper layer protocol) can include this option only on
specific packets used to test the path. This option does not need
to be included in all packets belonging to a flow.NOTE: Including this option in a large packet (e.g., one larger
than the present PMTU) is not likely to be useful, since the large
packet would itself be dropped by any link along the path with a
smaller MTU, preventing the Min-PMTU information from reaching the
destination host.Discussion:
In the case of TCP, the option could be included in a
packet that carries a TCP segment sent after the connection is
established. A segment without data could be used, to avoid
the need to retransmit this data if the probe packet is lost.
The discovered value can be used to inform PLPMTUD
.NOTE: A TCP SYN can also negotiate the Maximum Segment Size
(MSS), which acts as an upper limit to the packet size that
can be sent by a TCP sender. If this option were to be
included in a TCP SYN, it could increase the probability that
the SYN segment is lost when routers on the path drop packets
with this option (see ), which
could have an unwanted impact on the result of racing options
or feature negotiation.
The use with datagram transport protocols (e.g., UDP) is
harder to characterize because applications using datagram
transports range from very short-lived (low data-volume
applications) exchanges, to longer (bulk) exchanges of packets
between the source and destination hosts .
Simple-exchange protocols (i.e., low data-volume
applications that
only send one or a few packets per transaction), might assume
that the PMTU is symmetrical. That is, the PMTU is the same in
both directions, or at least not smaller for the return path.
This optimization does not hold when the paths are not
symmetric.
A datagram transport can utilise DPLPMTUD . For example, QUIC (see
section 14.3 of ),
can use DPLPMTUD to determine whether the path to a
destination will support a desired maximum datagram size. When
using the IPv6 MinPMTU HBH option, the option could be added
to an additional QUIC PMTU Probe that is of minimal size (or
one no larger than the currently supported PMTU size). Once
the return Path MTU value in the Min PMTU HBH option has been
learned, DPLPMTUD can be triggered to test for a larger PLPMTU
using an appropriately sized PLPMTU Probe Packet (see section
5.3.1 of ).
The use of this option with DNS and DNSSEC over UDP ought
to work for paths where the PMTU is symmetric. The DNS server
will learn the PMTU from the DNS query messages. If the
Rtn-PMTU value is smaller, then a large DNSSEC response might
be dropped and the known problems with PMTUD will then occur.
DNS and DNSSEC over transport protocols that can carry the
PMTU ought to work.
This method also can be used with Anycast to discover
the PMTU of the path, but the use needs to be aware that the
Anycast binding might change.
An upper layer protocol (e.g., transport endpoint) using this
option needs to provide protection from data injection attacks by
off-path devices . This
requires a method to assure that the information in the Option
Data is provided by a node on the path. This validates that the
packet forms a part of an existing flow, using context available
at the upper layer. For example, a TCP connection or UDP
application that maintains the related state and uses a
randomized ephemeral port would provide this basic validation
to protect from off-path data injection, see Section 5.1 of
.
IPsec and TLS provide greater assurance.The upper layer discards any received packet when the packet
validation fails. When packet validation fails, the upper layer
MUST also discard the associated Option Data from the minimum Path
MTU option without further processing.For a connection-oriented upper layer protocol, caching of the
received Min-PMTU could be implemented by saving the value in the
connection context at the transport layer. A connection-less upper
layer (e.g., one using UDP), requires the upper layer protocol to
cache the value for each flow it uses.A destination host that receives a Minimum Path MTU Option with
the R-Flag SHOULD include the Minimum Path MTU option in the next
outgoing IPv6 packet for the corresponding flow.A simple mechanism could only include this option (with the
Rtn-PMTU field set) the first time this option is received or when
it notifies a change in the Minimum Path MTU. This limits the
number of packets including the option packets that are sent.
However, this does not provide robustness to packet loss or
recovery after a sender loses state.Discussion:
Some upper layer protocols send packets less frequently
than the rate at which the host receives packets. This
provides less frequent feedback of the received Rtn-PMTU
value. However, a host always sends the most recent Rtn-PMTU
value.
The Rtn-PMTU field provides an indication of the PMTU from
on-path routers. It does not necessarily reflect the actual PMTU
between the sender and destination. Care therefore needs to be
exercised in using the Rtn-PMTU value. Specifically:
The actual PMTU can be lower than the Rtn-PMTU value because
Min-PMTU field was not updated by a router on the path that did
not process the option.
The actual PMTU may be lower than the Rtn-PMTU value because
the there is a layer 2 device with a lower MTU.
The actual PMTU may be larger than the Rtn-PMTU value
because of a corrupted, delayed or mis-ordered response. A
source host SHOULD ignore a Rtn-PMTU value larger than the MTU
configured for the outgoing link.
IPv6 requires that every link in the Internet have an MTU of
1280 octets or greater. A node MUST ignore a Rtn-PMTU value less
than 1280 octets .To avoid unintentional dropping of packets that exceed the
actual PMTU (e.g., Scenario 3 in ), the
source host can delay increasing the PMTU until a probe packet
with the size of the Rtn-PMTU value has been successfully
acknowledged by the upper layer, confirming that the path supports
the larger PMTU. This probing increases robustness, but adds one
additional path round trip time before the PMTU is updated. This
use resembles that of PTB messages in section 4.6 of DPLPMTUD
(with the important
difference that a PTB message can only seek to lower the PMTU,
whereas this option could trigger a probe packet to seek to
increase the PMTU.)Section 5.2 of
provides guidance on the caching of PMTU information and also the
relation to IPv6 flow labels. Implementations should consider the
impact of Equal Cost Multipath (ECMP) . Specifically, whether a PMTU ought be
maintained for each transport endpoint, or for each network
address.Path characteristics can change and the actual PMTU could
increase or decrease over time. For instance, following a path
change when packets are forwarded over a link with a
different MTU than that previously used. To bound the delay in
discovering an increase in the actual PMTU, a host with a link MTU
larger than the current PMTU SHOULD periodically send the Minimum
Path MTU Option with the R-bit set. DPLPMTUD provides
recommendations concerning how this could be implemented (see
Section 5.3 of ). Since
the option consumes less capacity than a full-sized probe packet,
there can be advantage in using this to detect a change in the
path characteristics.There is evidence that some middleboxes drop packets that
include Hop-by-Hop options. For example, a firewall might drop a
packet that carries an unknown extension header or option. This
practice is expected to decrease as an option becomes more widely
used. It could result in generation of an ICMPv6 message
indicating the problem. This could be used to (temporarily)
suspend use of this option.A middlebox that silently discards a packet with this option
results in dropping of any packet using the option. This dropping
can be avoided by appropriate configuration in a controlled
environment, such as within a data centre, but needs to be
considered for Internet usage. recommends
that this option is not used on packets where loss might adversely
impact performance.IANA has assigned and registered an IPv6 Hop-by-Hop Option type with
Temporary status from the "Destination Options and Hop-by-Hop Options"
registry . This assignment is
shown in .IANA is requested to update this registry to point to this document
and remove the Temporary status.This section discusses the security considerations.
It first reviews router option processing. It then reviews
host processing when receiving this option at the network layer. It then
considers two ways in which the Option Data can be processed, followed
by two approaches for using the Option Data. Finally, it discusses
middlebox implications related to use in the general Internet.This option shares the characteristics of all other IPv6 Hop by
Hop Options, in that if not supported at line rate it could be used
to degrade the performance of a router. This option, while simple, is no
different to other uses of IPv6 Hop-by-Hop options.A malicious attacker can forge a packet directed at a host that
carries the minimum Path MTU option. By design, the fields of this IP
option can be modified by the network.Reception of this packet will require processing as the
network stack parses the packet before the packet is delivered to the
upper layer protocol. This network layer option processing is normally
completed before any upper layer protocol delivery checks are
performed.The network layer does not normally have sufficient information to
validate that the packet carrying an option originated from the
destination (or an on-path node). It also does not typically have
sufficient context to demultiplex the packet to identify the related
transport flow. This can mean that any changes resulting from
reception of the option apply to all flows between a pair of
endpoints.These considerations are no different to other uses of Hop-by-Hop
options, and this is the use case for PMTUD. The following section
describes a mitigation for this attack.Transport protocols should be designed to provide protection from
data injection attacks by off-path devices and mechanisms should be
described in the Security Considerations for each transport
specification (see Section 5.1 of the UDP Guidelines ). For example, a TCP or UDP
application that maintains the related state and uses a randomized
ephemeral port would provide basic protection. TLS or IPsec provide cryptographic authentication. An upper
layer protocol that validates each received packet discards any packet
when this validation fails. In this case, the host MUST also discard
the associated Option Data from the minimum Path MTU option without
further processing ().A network node on the path has visibility of all packets it
forwards. By observing the network packet payload, the node might be
able to construct a packet that might be validated by the destination
host. Such a node would also be able to drop or limit the flow in
other ways that could be potentially more disruptive. Authenticating
the packet, for example, using IPsec or TLS
mitigates this attack.The simplest way to utilize the Rtn-PMTU value is to directly use
this to update the PMTU. This approach results in a set of security
issues when the option carries malicious data:
A direct update of the PMTU using the Rtn-PMTU value could
result in an attacker inflating or reducing the size of the host
PMTU for the destination. Forcing a reduction in the PMTU can
decrease the efficiency of network use, might increase the number
of packets/fragments required to send the same volume of payload
data, and prevents sending an unfragmented datagram larger than
the PMTU. Increasing the PMTU can result in black-holing (see
Section 1.1 of ) when
the source sends packets larger than the actual PMTU. This
persists until the PMTU is next updated.
The method can be used to solicit a response from the
destination host. A malicious attacker could forge a packet that
cause the sender to add the option to a packet sent to the source.
A forged value of Rtn-PMTU in the Option Data might also impact
the remote endpoint, as described in the previous bullet. This
persists until a valid minimum Path MTU option is received. This
attack could be mitigated by limiting the sending of the minimum
Path MTU option in reply to incoming packets that carry the
option.
Another way to utilize the Rtn-PMTU value is to indirectly trigger
a probe to determine if the path supports a PMTU of size Rtn-PMTU.
This approach needs context for the flow, and hence assumes an upper
layer protocol that validates the packet that carries the option (see
). This is the case when used in
combination with DPLPMTUD .
A set of security considerations result when an option carries
malicious data:
If the forged packet carries a validated option with a non-zero
Rtn-PMTU field, the upper layer protocol could utilize the
information in the Rtn-PMTU field. A Rtn-PMTU larger than the
current PMTU can trigger a probe for a new size.
If the forged packet carries a non-zero Min-PMTU field, the
upper layer protocol would change the cached information about the
path from the source. The cached information at the destination host
will be overwritten when the host receives another packet that
includes a minimum Path MTU option corresponding to the flow.
Processing of the option could cause a destination host to add
the minimum Path MTU option to a packet sent to the source host.
This option will carry a Rtn-PMTU value that could have been updated
by the forged packet. The impact of the source host receiving this
resembles that discussed previously.
There is evidence that some middleboxes drop packets that include
Hop-by-Hop options. For example, a firewall might drop a packet that
carries an unknown extension header or option. This practice is
expected to decrease as the option becomes more widely used. Methods
to address this are discussed in .When a forged packet cause a packet to be sent including the
minimum Path MTU option, and the return path does not forward packets
with this option, the packet will be dropped . This attack is mitigated by validating the
option data before use and by limiting the rate of responses
generated. An upper layer could further mitigate the impact by
responding to a R-Flag by including the option in a packet that does
not carry application data.This section describes the experimental goals of this
specification.A successful deployment of the method depends upon several components
being implemented and deployed:
Support in the sending node (see ). This also requires corresponding support in
upper layer protocols (see ).
Router support in nodes (see ). The IETF continues to provide recommendations on
the use of IPv6 Hop-by-Hop options, for example . This document does not update the
way router implementations configure support for HBH options.
Support in the receiving node (see ).
Experience from deployment is an expected input to any decision to
progress this specification from Experimental to IETF Standards Track.
Appropriate inputs might include:
Reports of implementation experience;
Measurements of the number paths where the method can be
used;
Measurements showing the benefit realized or the implications of
using specific methods over specific paths.
At the time this document was published there are two known
implementations of the Path MTU Hop-by-Hop option. These are:
Wireshark dissector. This is shipping in production in Wireshark
version 3.2 .
A prototype in the open source version of the FD.io Vector Packet
Processing (VPP) technology .
The the time this document was published, the source code can be found
.
A similar mechanism was proposed for IPv4 in 1988 in by Jeff Mogul, C. Kent, Craig
Partridge, and Keith McCloghire. It was later obsoleted in 1990 by the current deployed approach to
Path MTU Discovery.Helpful comments were received from Tom Herbert, Tom Jones, Fred
Templin, Ole Troan, Tianran Zhou, Jen Linkova, Brian Carpenter, Peng
Shuping, Mark Smith, Fernando Gont, and other members of the 6MAN
working group.draft-ietf-6man-mtu-option-08, 2021-September-7
Clarifications and editorial changes based on chair review by
Ole Troan.
Correction and clarifications based on review by Fernando Gont.
draft-ietf-6man-mtu-option-07, 2021-August-31
Added Experiment Goals section.
Added Implementation Status section.
Updated the IANA Considerations section to point to this document
and remove Temporary status.
Clarifications and editorial changes based on review by Mark Smith.
draft-ietf-6man-mtu-option-06, 2021-August-7
Transport usage of the mechanism clarified in response to feedback
and suggestions from Jen Linkova.
Restructured to
improve readability.
Editorial changes.
draft-ietf-6man-mtu-option-05, 2021-April-28
Editorial changes.
draft-ietf-6man-mtu-option-04, 2020-Oct-23
Fixes for typos.
draft-ietf-6man-mtu-option-03, 2020-Sept-14
Rewrite to make text and terminology more consistent.
Added the notion of validating the packet before use of the HBH
option data.
Method aligned with the way common APIs send/receive HBH option
data.
Added reference to DPLPMTUD and clarified upper layer usage.
Completed security considerations section.
draft-ietf-6man-mtu-option-02, 2020-March-9
Editorial changes to make text and terminology more
consistent.
Added reference to DPLPMTUD.
draft-ietf-6man-mtu-option-01, 2019-September-13
Changes to show IANA assigned code point.
Editorial changes to make text and terminology more
consistent.
Added a reference to RFC8200 in and a reference to RFC6438 in .
draft-ietf-6man-mtu-option-00, 2019-August-9
First 6man w.g. draft version.
Changes to request IANA allocation of code point.
Editorial changes.
draft-hinden-6man-mtu-option-02, 2019-July-5
Changed option format to also include the Returned PMTU value and
Return flag and made related text changes in to describe this behavior.
ICMP Packet Too Big messages are no longer used for feedback to
the source host.
Added to Acknowledgements Section that a similar mechanism was
proposed for IPv4 in 1988 in .
Editorial changes.
draft-hinden-6man-mtu-option-01, 2019-March-05
Changed requested status from Standards Track to Experimental to
allow use of experimental option type (11110) to allow for
experimentation. Removed request for IANA Option assignment.
Added "Motivation
and Problem Solved" section to better describe what the purpose of
this document is.
Added appendix describing planned experiments and how the results
will be measured.
Editorial changes.
draft-hinden-6man-mtu-option-00, 2018-Oct-16
Initial draft.
ReferencesNormative ReferencesDestination Options and Hop-by-Hop OptionsInformative ReferencesVPP/What is VPP?VPP SourceWireshark Network Protocol Analyzer