Forcing Fragmentation to Network MTU
draft-ietf-ipngwg-bsd-frag-01
| Document | Type | Expired Internet-Draft (ipngwg WG) | |
|---|---|---|---|
| Author | Mark P. Andrews | ||
| Last updated | 1998-01-27 | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats |
Expired & archived
plain text
htmlized
pdfized
bibtex
|
||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Expired | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
https://www.ietf.org/archive/id/draft-ietf-ipngwg-bsd-frag-01.txt
Abstract
There exists a class of applications which cannot accept Path MTU discovery [RFC-1981]. This is recommended to be turned on by default for IPv6 [IPV6-SPEC-V2, 4.5, 5]. This document describes an extension to the BSD API [RFC-2133] to inform the kernel when it should be fragmenting at the network MTU rather than trying to discover the path MTU. Path MTU discovery works well when there is a stream of data. However for distributed servers sending small answers larger than the network MTU to many clients the lack of fragmentation in intermediate nodes is anathema. RFC-1981 Section 5.6 recommends that a system utility be provided to: - Specify that Path MTU Discovery not be done on a given path. - Change the PMTU value associated with a given path. This documents specifies how to do the same at the application level to a individual socket.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)