< draft-templin-6man-fragrep-06.txt   draft-templin-6man-fragrep-07.txt >
Network Working Group F. L. Templin, Ed. Network Working Group F. L. Templin, Ed.
Internet-Draft Boeing Research & Technology Internet-Draft Boeing Research & Technology
Updates: RFC8200, RFC8201, RFC4443, RFC1191 (if 9 February 2022 Updates: RFC8200, RFC8201, RFC4443, RFC1191 (if 29 March 2022
approved) approved)
Intended status: Standards Track Intended status: Standards Track
Expires: 13 August 2022 Expires: 30 September 2022
IPv6 Fragment Retransmission and Path MTU Discovery Soft Errors IPv6 Fragment Retransmission and Path MTU Discovery Soft Errors
draft-templin-6man-fragrep-06 draft-templin-6man-fragrep-07
Abstract Abstract
Internet Protocol version 6 (IPv6) provides a fragmentation and Internet Protocol version 6 (IPv6) provides a fragmentation and
reassembly service for end systems allowing for the transmission of reassembly service for end systems allowing for the transmission of
packets that exceed the path MTU. However, loss of individual packets that exceed the path MTU. However, loss of individual
fragments requires retransmission of original packets in their fragments requires retransmission of original packets in their
entirety leading to cascading reassembly failures. This document entirety leading to cascading reassembly failures. This document
specifies an IPv6 fragment retransmission scheme that matches the specifies an IPv6 fragment retransmission scheme that matches the
loss unit to the retransmission unit. The document further specifies loss unit to the retransmission unit. The document further specifies
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 13 August 2022. This Internet-Draft will expire on 30 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
skipping to change at page 2, line 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Common Use Cases . . . . . . . . . . . . . . . . . . . . . . 4 3. Common Use Cases . . . . . . . . . . . . . . . . . . . . . . 4
4. IPv6 Fragmentation . . . . . . . . . . . . . . . . . . . . . 4 4. IPv6 Fragmentation . . . . . . . . . . . . . . . . . . . . . 4
5. IPv6 Fragment Retransmission . . . . . . . . . . . . . . . . 5 5. IPv6 Fragment Retransmission . . . . . . . . . . . . . . . . 5
6. Packet Too Big (PTB) Soft Errors . . . . . . . . . . . . . . 8 6. Packet Too Big (PTB) Soft Errors . . . . . . . . . . . . . . 8
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Internet Protocol version 6 (IPv6) [RFC8200] provides a fragmentation Internet Protocol version 6 (IPv6) [RFC8200] provides a fragmentation
and reassembly service similar to that found in IPv4 [RFC0791], with and reassembly service similar to that found in IPv4 [RFC0791], with
the exception that only the source host (i.e., and not routers on the the exception that only the source host (i.e., and not routers on the
path) may perform fragmentation. When an IPv6 packet is fragmented, path) may perform fragmentation. When an IPv6 packet is fragmented,
the loss unit (i.e., a single IPv6 fragment) becomes smaller than the the loss unit (i.e., a single IPv6 fragment) becomes smaller than the
retransmission unit (i.e., the entire packet) which even under retransmission unit (i.e., the entire packet) which even under
skipping to change at page 4, line 12 skipping to change at page 4, line 12
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.
3. Common Use Cases 3. Common Use Cases
A common use case of interest is to improve the state of affairs for A common use case of interest is to improve the state of affairs for
IPv6 encapsulation (i.e., "tunneling") [RFC2473] when the original IPv6 encapsulation (i.e., "tunneling") [RFC2473] when the original
source may be many IP hops away from the tunnel ingress, and the source may be many IP hops away from the tunnel ingress, and the
tunnel packet may be fragmented following encapsulation. The tunnel tunnel packet may be fragmented following encapsulation. The tunnel
is seen as a "link" on the path from the original source to the final is seen as a "link" on the path from the original source to the final
destination, and the goal is to increase the reliability of that link destination, and the goal is to increase link reliability in order to
in order to minimize wasteful end-to-end retransmissions. minimize wasteful end-to-end retransmissions.
When the original source and IPv6 fragmentation source are co-located When the original source and IPv6 fragmentation source are co-located
on the same platform (physical or virtual) the window of opportunity on the same platform (physical or virtual) the window of opportunity
for successful retransmission of individual fragments may be narrow for successful retransmission of individual fragments may be narrow
unless the link persistence timeframe is carefully coordinated with unless the link persistence timeframe is carefully coordinated with
upper layer retransmission timers. (In an uncoordinated case, upper upper layer retransmission timers. (In an uncoordinated case, upper
layers may retransmit the entire packet before or at roughly the same layers may retransmit the entire packet before or at roughly the same
time the IPv6 fragmentation source retransmits individual fragments, time the IPv6 fragmentation source retransmits individual fragments,
leading to increased congestion and wasted retransmissions.) leading to increased congestion and wasted retransmissions.)
However, the same retransmission facility can be applied to both the However, the same retransmission facility can be applied to both the
skipping to change at page 5, line 30 skipping to change at page 5, line 30
considered as the standard method which adheres to the details of considered as the standard method which adheres to the details of
that RFC. This document presents an enhanced method that allows for that RFC. This document presents an enhanced method that allows for
retransmissions of individual fragments. retransmissions of individual fragments.
5. IPv6 Fragment Retransmission 5. IPv6 Fragment Retransmission
Fragmentation implementations that follow this specification reuse Fragmentation implementations that follow this specification reuse
the (formerly) Reserved field of the IPv6 Fragment Header. For first the (formerly) Reserved field of the IPv6 Fragment Header. For first
fragments (i.e., those with zero Fragment Offset) the 8-bit Reserved fragments (i.e., those with zero Fragment Offset) the 8-bit Reserved
field is replaced with a 7-bit Parcel ID followed by a 1-bit A(RQ) field is replaced with a 7-bit Parcel ID followed by a 1-bit A(RQ)
flag, and the 2-bit Res field is replaced with a single P(arcel) bit flag, and the 2-bit Res field is replaced with a 1-bit P(arcel) flag
followed by a 1-bit S(ub-parcels) flag as shown below: followed by a 1-bit S(ub-parcels) flag as shown below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Parcel ID |A| Fragment Offset |P|S|M| | Next Header | Parcel ID |A| Fragment Offset |P|S|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification | | Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For non-first fragments (i.e., those with non-zero Fragment Offset), For non-first fragments (i.e., those with non-zero Fragment Offset),
the Reserved field is replaced with a 7-bit "Ordinal" field followed the Reserved field is replaced with a 7-bit "Ordinal" field followed
skipping to change at page 6, line 8 skipping to change at page 6, line 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Ordinal |A| Fragment Offset |Res|M| | Next Header | Ordinal |A| Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification | | Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a source that follows this specification fragments an IPv6 When a source that follows this specification fragments an IPv6
packet it sets the first fragment A flag to 1, then for IP parcels packet it sets the first fragment A flag to 1, then for IP parcels
sets Parcel ID, P and S according to the processing and transmission sets Parcel ID, P and S according to the processing and transmission
procedures found in [I-D.templin-6man-omni]. For non-parcels, the procedures found in [I-D.templin-intarea-parcels] and
source instead sets Parcel ID, P and S to 0. [I-D.templin-6man-omni]. For non-parcels, the source instead sets
Parcel ID, P and S to 0.
The source then sets the Ordinal value for each successive non-first The source then sets the Ordinal value for each successive non-first
fragment to a monotonically-increasing value beginning with 1, i.e., fragment to a monotonically-increasing value beginning with 1, i.e.,
it sets Ordinal to '1' for the first non-first fragment, '2' for the it sets Ordinal to '1' for the first non-first fragment, '2' for the
second non-first fragment, '3' for the third non-first fragment, etc. second non-first fragment, '3' for the third non-first fragment, etc.
up to either Ordinal '127' or the final fragment (whichever comes up to either Ordinal '127' or the final fragment (whichever comes
first) while also setting the A flag to 1. (If there are additional first) while also setting the A flag to 1. (If there are additional
non-first fragments beyond Ordinal '127', the source instead sets non-first fragments beyond Ordinal '127', the source instead sets
their Ordinals to '0' to indicate that the fragment is not eligible their Ordinals to '0' to indicate that the fragment is not eligible
for retransmission.) for retransmission.)
When a destination that follows this specification receives IPv6 When a destination that follows this specification receives IPv6
fragments with the A flag set to 1, it infers that the source fragments with the A flag set, it infers that the source participates
participates in the protocol and maintains a checklist of all Ordinal in the protocol and maintains a checklist of all Ordinal fragments
fragments received for a specific Identification number. (Note that received for a specific Identification number. (Note that receipt of
receipt of any IPv6 fragments with the A flag set provides an any IPv6 fragments with the A flag set provides an implicit assertion
implicit assertion that all lost Ordinal IPv6 fragments are also that any lost Ordinals of the same packet are also eligible for
eligible for retransmission.) retransmission.)
If the destination notices one or more Ordinals missing after most If the destination notices one or more Ordinals missing after most
other Ordinals for the same Identification have arrived, it can other Ordinals for the same Identification have arrived, it can
prepare an ICMPv6 Fragmentation Report (FRAGREP) message [RFC4443] to prepare an ICMPv6 Fragmentation Report (FRAGREP) message [RFC4443] to
send back to the source. The message is formatted as follows: send back to the source. The message is formatted as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
skipping to change at page 7, line 11 skipping to change at page 7, line 15
In this format, the destination prepares the FRAGREP message as a In this format, the destination prepares the FRAGREP message as a
list of 20-octet (Identification(i), Bitmap(i)) pairs. The first 4 list of 20-octet (Identification(i), Bitmap(i)) pairs. The first 4
octets in each pair encode the Identification value for the IPv6 octets in each pair encode the Identification value for the IPv6
packet that is subject of the report, while the remaining 16 octets packet that is subject of the report, while the remaining 16 octets
encode a 128-bit Bitmap of Ordinal fragments received for this encode a 128-bit Bitmap of Ordinal fragments received for this
Identification. For example, if the destination receives the first Identification. For example, if the destination receives the first
fragment (i.e., Ordinal number 0) plus non-first fragment Ordinals 1, fragment (i.e., Ordinal number 0) plus non-first fragment Ordinals 1,
3, 4, 6, and 8 it sets Bitmap bits 0, 1, 3, 4, 6 and 8 to '1' and 3, 4, 6, and 8 it sets Bitmap bits 0, 1, 3, 4, 6 and 8 to '1' and
sets all other bits to '0'. The destination may include as many sets all other bits to '0'. The destination may include as many
(Identification, Bitmap) pairs as necessary without causing the (Identification, Bitmap) pairs as necessary without causing the
entire message to exceed the minimum IPv6 MTU of 1280 octets. (If entire message to exceed the minimum IPv6 MTU (i.e., 1280 octets); if
additional pairs are necessary, the destination may prepare and send additional pairs are necessary, the destination may prepare and send
multiple messages.) multiple messages.
The destination next transmits the FRAGREP message to the IPv6 The destination next transmits the FRAGREP message to the IPv6
fragment source. When the source receives the message, it examines fragment source. When the source receives the message, it examines
each entry to determine the per-Identification Ordinal fragments that each entry to determine the per-Identification Ordinal fragments that
require retransmission. For example, if the source receives a Bitmap require retransmission. For example, if the source receives a Bitmap
for Identification 0x12345678 with bits 0, 1, 3, 4, 6 and 8 set to for Identification 0x12345678 with bits 0, 1, 3, 4, 6 and 8 set to
'1', it would retransmit Ordinal fragments (0x12345678, 2), '1', it would retransmit Ordinal fragments (0x12345678, 2),
(0x12345678, 5) and (0x12345678, 7). (0x12345678, 5) and (0x12345678, 7).
This implies that the source should retain a cache of recently This implies that the source should retain a cache of recently
transmitted fragments for a time that determines "link persistence" transmitted fragments for a time that determines "link persistence"
[RFC3366]. The link persistence should be at least as long as the [RFC3366]. The link persistence should be at least as long as the
round-trip time from the fragmentation source to the reassembly round-trip time from the fragmentation source to the reassembly
destination, plus an additional small delay to allow for processing destination, plus an additional small delay to allow for processing
overhead and/or delay variance. Then, if the source receives a overhead and/or delay variance. Then, if the source receives a
FRAGREP message requesting retransmission of one or more Ordinals, it FRAGREP message requesting retransmission of one or more Ordinals, it
can retransmit if it still holds the Ordinals in its cache. can retransmit any still in its cache. Otherwise, the Ordinal will
Otherwise, the Ordinal will incur a cache miss and the original incur a cache miss and the original source will eventually retransmit
source will eventually retransmit the original packet in its the original packet in its entirety. After processing all entries in
entirety. After processing all entries in the FRAGREP, the source the FRAGREP, the source discards the message.
discards the message.
The maximum-sized IPv6 packet that a source can submit for The maximum-sized IPv6 packet that a source can submit for
fragmentation is 65535 octets, and the minimum IPv6 path MTU is 1280 fragmentation is 65535 octets, and the minimum IPv6 path MTU is 1280
octets. Assuming the minimum IPv6 path MTU as the nominal size for octets. Assuming the minimum IPv6 path MTU as the nominal size for
non-final fragments, the number of Ordinals for each IPv6 packet non-final fragments, the number of Ordinals for each IPv6 packet
should therefore easily fit within the available Bitmap bits when the should therefore easily fit within the available Bitmap bits when the
fragments are transmitted over IPv6-only network paths. However, fragments are transmitted over IPv6-only network paths. However,
when the path may traverse one or more IPv4 networks (e.g., via when the path may traverse one or more IPv4 networks (e.g., via
tunneling) the path MTU may be significantly smaller. In that case, tunneling) the path MTU may be significantly smaller. In that case,
the number of IPv6 fragments needed may exceed the maximum number of the number of IPv6 fragments needed may exceed the maximum number of
Ordinal retransmission candidates. Ordinal retransmission candidates.
When the number of IPv6 fragments exceeds 128, the source assigns an When the number of IPv6 fragments exceeds 128, the source assigns an
Ordinal value in the first 127 non-first fragments, but sets Ordinal Ordinal value in the first 127 non-first fragments, but sets Ordinal
to 0 in any remaining non-first fragments then transmits all to 0 in any remaining non-first fragments then transmits all
fragments. When the destination receives the fragments, it may fragments. When the destination receives the fragments, it may
return a FRAGREP to request retransmission of the first fragment and/ return a FRAGREP to request retransmission of the first fragment and/
or any missing Ordinal non-first fragments, but may not request or any missing Ordinal non-first fragments, but may not request
retransmission of non-first fragments with zero Ordinals for which retransmission of non-first fragments with zero Ordinals for which
the best-effort delivery default behavior applies. However, all the default behavior of best-effort delivery applies. However, all
fragments are presented equally to the reassembly cache regardless of fragments are presented equally to the reassembly cache regardless of
the (formerly) Reserved field settings, where the Reserved values are the (formerly) Reserved field settings, where the Reserved values are
ignored and successful reassembly is likely. ignored and successful reassembly is likely.
Finally, transmission of IPv6 fragments over IPv6-only paths can be Finally, transmission of IPv6 fragments over IPv6-only paths can be
safely conducted without a fragmentation-layer integrity check since safely conducted without a fragmentation-layer integrity check since
IPv6 includes reassembly safeguards and a 32-bit Identification IPv6 includes reassembly safeguards and a 32-bit Identification
value. Conversely, transmission of IPv6 fragments over IPv4-only or value. Conversely, transmission of IPv6 fragments over IPv4-only or
mixed IPv6/IPv4 paths requires a fragmentation-layer integrity check mixed IPv6/IPv4 paths requires a fragmentation-layer integrity check
inserted by the source before fragmentation and verified by the inserted by the source before fragmentation and verified by the
skipping to change at page 9, line 28 skipping to change at page 9, line 33
for hard errors as described above and may therefore miss performance for hard errors as described above and may therefore miss performance
improvement opportunities. improvement opportunities.
7. Implementation Status 7. Implementation Status
TBD. TBD.
8. IANA Considerations 8. IANA Considerations
A new ICMPv6 Message Type code for "Fragmentation Report (FRAGREP)" A new ICMPv6 Message Type code for "Fragmentation Report (FRAGREP)"
is requested. is requested. The registration procedure is "IETF Review" and the
reference is this document [RFCXXXX].
The IANA is instructed to create new registries for "ICMPv6 Packet The IANA is instructed to create new registries for "ICMPv6 Packet
Too Big Code field" and "ICMPv4 Fragmentation Needed unused field" Too Big Code field" and "ICMPv4 Fragmentation Needed unused field"
values. Both registries should have the following initial values: values. Both registries should have the following initial values:
Value Sub-Type name Reference Value Sub-Type name Reference
----- ------------- ---------- ----- ------------- ----------
0 PTB hard error [RFCXXXX] 0 PTB hard error [RFCXXXX]
1 PTB soft error (loss) [RFCXXXX] 1 PTB soft error (loss) [RFCXXXX]
2 PTB soft error (no loss) [RFCXXXX] 2 PTB soft error (no loss) [RFCXXXX]
skipping to change at page 11, line 8 skipping to change at page 11, line 10
[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, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
11.2. Informative References 11.2. Informative References
[I-D.templin-6man-aero] [I-D.templin-6man-aero]
Templin, F. L., "Automatic Extended Route Optimization Templin, F. L., "Automatic Extended Route Optimization
(AERO)", Work in Progress, Internet-Draft, draft-templin- (AERO)", Work in Progress, Internet-Draft, draft-templin-
6man-aero-38, 31 December 2021, 6man-aero-40, 7 March 2022,
<https://www.ietf.org/archive/id/draft-templin-6man-aero- <https://www.ietf.org/archive/id/draft-templin-6man-aero-
38.txt>. 40.txt>.
[I-D.templin-6man-omni] [I-D.templin-6man-omni]
Templin, F. L. and T. Whyman, "Transmission of IP Packets Templin, F. L., "Transmission of IP Packets over Overlay
over Overlay Multilink Network (OMNI) Interfaces", Work in Multilink Network (OMNI) Interfaces", Work in Progress,
Progress, Internet-Draft, draft-templin-6man-omni-52, 31 Internet-Draft, draft-templin-6man-omni-55, 7 March 2022,
December 2021, <https://www.ietf.org/archive/id/draft- <https://www.ietf.org/archive/id/draft-templin-6man-omni-
templin-6man-omni-52.txt>. 55.txt>.
[I-D.templin-intarea-parcels] [I-D.templin-intarea-parcels]
Templin, F. L., "IP Parcels", Work in Progress, Internet- Templin, F. L., "IP Parcels", Work in Progress, Internet-
Draft, draft-templin-intarea-parcels-06, 22 December 2021, Draft, draft-templin-intarea-parcels-09, 10 February 2022,
<https://www.ietf.org/archive/id/draft-templin-intarea- <https://www.ietf.org/archive/id/draft-templin-intarea-
parcels-06.txt>. parcels-09.txt>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>. December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on [RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on
link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366,
DOI 10.17487/RFC3366, August 2002, DOI 10.17487/RFC3366, August 2002,
<https://www.rfc-editor.org/info/rfc3366>. <https://www.rfc-editor.org/info/rfc3366>.
 End of changes. 20 change blocks. 
35 lines changed or deleted 36 lines changed or added

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