IPv6 Packet Identification
draft-templin-6man-jumbofrag-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Fred Templin | ||
| Last updated | 2022-05-22 (Latest revision 2021-11-18) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Unlike Internet Protocol, version 4 (IPv4), Internet Protocol, version 6 (IPv6) does not include an Identification field in the basic packet header. Instead, IPv6 includes a 32-bit Identification field in a Fragment Header extension since the architecture assumed that the sole purpose for the Identification is to support the fragmentation and reassembly process. This document asserts that per-packet Identifications may be useful for other purposes, e.g., to allow recipients to detect spurious packets that may have been injected into the network by an attacker. But, rather than defining a new extension header, this document recommends employing the existing Fragment Header for per-packet identification even if the packet itself appears as an "atomic fragment".
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)