Forcing Fragmentation to Network MTU
draft-ietf-ipngwg-bsd-frag-01
Document | Type |
Expired Internet-Draft
(ipngwg WG)
Expired & archived
|
|
---|---|---|---|
Author | Mark P. Andrews | ||
Last updated | 1998-01-27 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | (None) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
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) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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.)