Change Status of RFC 2675 to Historic
draft-jones-6man-historic-rfc2675-00

Abstract

This document changes the status of RFC2675, IPv6 Jumbograms, from Proposed Standard to Historic.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 9, 2019.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Conventions and Definitions
• 3. Rationale
• 4. RFCs Referencing Jumbograms
• 5. Security Considerations
• 6. IANA Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Acknowledgments
• Appendix A
• Appendix B
• Authors' Addresses

1. Introduction

[RFC2675] defines the IPv6 Jumbo Payload Option, which enables Jumbograms, IPv6 datagrams that carry a payload greater than 65,535 octets. Jumbograms have seen little deployment in the open Internet and there are currently no known active Internet deployments.

Note: “Jumboframe” is a commonly term that is used to describe frames that exceed 1500 bytes in length, and is different to an IPv6 Jumbo Payload Option, or Jumbogram.

When published, this document changes the status of RFC2675 to historic.

2. Conventions and Definitions

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Rationale

Jumbograms have seen little deployment, A Roadmap for Transmission Control Protocol (TCP) Specification Documents ([RFC7414]) explains some of the protocol reasons behind this:

"This document states that jumbograms are to only be used when it can be
 guaranteed that all receiving nodes, including each router in the
 end-to-end path, will support jumbograms.  If even a single node that does
 not support jumbograms is attached to a local network, then no host on
 that network may use jumbograms.  This explains why jumbogram use has been
 rare, and why this document is considered a performance optimization and
 not part of TCP over IPv6's basic functionality."

Over time, the IPv6 Node Requirements document series has reported on the deployment of Jumbograms, as follows:

• RFC4294: “IPv6 Jumbograms [RFC-2675] MAY be supported.”
• RFC6434: “To date, few implementations exist, and there is essentially no reported experience from usage.”
• RFC8504: “Removed Jumbograms (RFC 2675) as they aren’t deployed.”

This document removes support for Jumbograms, and therefore paves the way for the removal of their support from operating system stacks. This also removes the need for testing Jumbogram support, which otherwise require links with a MTU greater than 65,535 bytes, making testing of implementations impractical without significant effort.

4. RFCs Referencing Jumbograms

This section summarises document in the RFC series that mention support for IPv6 Jumbograms.

The Jumbo option is mentioned in a set of documents:

• Protocols that consider the larger possible sized enabled by Jumbograms, for encryption ciphers (AES [RFC3686] and [RFC4309]).
• Protocols that are unable to support Jumbograms, due to their increased length (SRTP [RFC3711] and ROHC [RFC5225]).
• Protocols that consider the jumbogram option field as a possible length format (IPFIX [RFC5102], IPv6 transition [RFC8468]).

TCP specifications have also refered to Jumbograms. Adding support for TCP jumbograms required modification to the Maximum Segment Size and Urgent Pointer fields to interpret a value of 65,535 as infinite. These modifications resulted in references to [RFC2675] in several TCP Documents ([RFC4614], [RFC6691], [RFC7323], [RFC7414]) and the TCP Roadmap [RFC7414], which describes the fundamental changes to TCP required to support Jumbograms.

UDP Usage Guidlines [RFC8085] refers to Jumbogram support for large unfragmentable datagrams:

"IPv6 allows the option of transmitting large packets ("jumbograms")
without fragmentation when all link layers along the path support this
[RFC2675]."

References also appear in documents that acknowledge the existence of the jumbo option, but do not define new mechanisms. Jumbograms are mentioned in IPv6 node requirements [RFC4294], UDP Guidelines [RFC5405] (histroric), IPv6 Avian Carriers [RFC6214], IPv6 node requirements [RFC6434], DTN convergence [RFC7122].

If published, this document changes the status of RFC2675 to historic. Use of Jumbograms will no longer be specified as an IETF mechanism for use with these IETF-specified protocols.

5. Security Considerations

XXX security considerations XXX

The security considerations for in RFC2675 state: “The Jumbo Payload option and TCP/UDP jumbograms do not introduce any known new security concerns”.

6. IANA Considerations

This document has no IANA actions.

7. References

7.1. Normative References

7.2. Informative References

Acknowledgments

Tom Jones and Godred Fairhurst are supported by the University of Aberdeen.

Appendix A

RFC editor: please remove this section before publication.

This appendix provides an annotated list of text where support is mentioned within the RFC series.

Appendix B

RFC editor please remove this section before publishing

Relevant quotes from PS and BCP documents that reference [RFC2675].

Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP) ([RFC3686]):

"This construction can produce enough key stream for each packet
sufficient to handle any IPv6 jumbogram [JUMBO]."

"Note that ESP with 32- bit Sequence Numbers will not exceed 2^64
blocks even if all of the packets are maximum-length IPv6 jumbograms
[JUMBO]."

"A 28-bit block counter value is sufficient for the generation of a key
stream to encrypt the largest possible IPv6 jumbogram [JUMBO]; however,
a 32-bit field is used.  This size is convenient for both hardware and
software implementations."

The Secure Real-time Transport Protocol (SRTP) ([RFC3711]):

"The AES has a block size of 128 bits, so 2^16 output blocks are
sufficient to generate the 2^23 bits of keystream needed to encrypt the
largest possible RTP packet (except for IPv6 "jumbograms" `[RFC2675]`,
which are not likely to be used for RTP-based multimedia traffic)."

Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP) ([RFC4309]):

"L  L indicates the size of the length field in octets.  CCM defines
    values of L between 2 octets and 8 octets.  This specification only
    supports L = 4.  Implementations MUST support an L value of 4
    octets, which accommodates a full Jumbogram [JUMBO]; however, the
    length includes all of the encrypted data, which also includes the
    ESP Padding, Pad Length, and Next Header fields."

"payload
    The payload of the ESP packet.  The payload MUST NOT be longer than
    4,294,967,295 octets, which is the maximum size of a Jumbogram
    [JUMBO]; however, the ESP Padding, Pad Length, and Next Header
    fields are also part of the payload."

"This construction provides more key stream for each packet than is
needed to handle any IPv6 Jumbogram [JUMBO]."

Information Model for IP Flow Information Export ([RFC5102], Obsolete):

"5.4.30.  payloadLengthIPv6

   Description:
     This Information Element reports the value of the Payload
     Length field in the IPv6 header.  Note that IPv6 extension
     headers belong to the payload.  Also note that in case of a
     jumbo payload option the value of the Payload Length field in
     the IPv6 header is zero and so will be the value reported by
     this Information Element."

"5.7.1.  ipPayloadLength

   Description:
     The effective length of the IP payload.  For IPv4 packets, the
     value of this Information Element is the difference between
     the total length of the IPv4 packet (as reported by
     Information Element totalLengthIPv4) and the length of the
     IPv4 header (as reported by Information Element
     headerLengthIPv4).  For IPv6, the value of the Payload Length
     field in the IPv6 header is reported except in the case that
     the value of this field is zero and that there is a valid
     jumbo payload option.  In this case, the value of the Jumbo
     Payload Length field in the jumbo payload option is reported."

RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite ([RFC5225]):

"IPv6 headers using the jumbo payload option of RFC 2675 `[RFC2675]` will
not be compressible with this encoding method since the value of the
payload length field does not match the length of the packet.

UDP Usage Guidelines ([RFC5405], Obsolete):

"IPv6 allows the option of transmitting large packets ("jumbograms")
without fragmentation when all link layers along the path support this
`[RFC2675]`."

TCP Extensions for High Performance ([RFC7323]):

"Expanding the TCP window beyond 64 KiB for IPv6 allows Jumbograms
`[RFC2675]` to be used when the local network supports packets larger
than 64 KiB.  When larger TCP segments are used, the TCP checksum
becomes weaker."

"The same technique applies to IP version 6, except in the case of IPv6
Jumbograms.  When IPv6 Jumbograms are supported, [RFC2675] requires
additional steps for dealing with the Urgent Pointer; these steps are
described in Section 5.2 of `[RFC2675]`."

UDP Usage Guidelines [RFC8085]:

"IPv6 allows the option of transmitting large packets ("jumbograms")
without fragmentation when all link layers along the path support this
`[RFC2675]`."

IPv6 Node Requirements ([RFC8504]):

"Removed Jumbograms (RFC 2675) as they aren't deployed."

Authors' Addresses