| < 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/ | ||||