< draft-ietf-ipngwg-bsd-frag-00.txt   draft-ietf-ipngwg-bsd-frag-01.txt >
INTERNET-DRAFT Mark Andrews (CSIRO) INTERNET-DRAFT Mark Andrews (CSIRO)
<draft-ietf-ipngwg-bsd-frag-00.txt> January 1998 <draft-ietf-ipngwg-bsd-frag-01.txt> January 1998
Forcing Fragmentation to Network MTU Forcing Fragmentation to Network MTU
Status of This Memo Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
skipping to change at page 1, line 30 skipping to change at page 1, line 30
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet- the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa), Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
There exists a class of applications which cannot accept Path There exists a class of applications which cannot accept Path
MTU discovery [RFC-1191]. This is recommended to be turned on MTU discovery [RFC-1981]. This is recommended to be turned on
by default for IPv6 [RFC-1883, 4.5, 5]. This document describes by default for IPv6 [IPV6-SPEC-V2, 4.5, 5]. This document
an extension to the BSD API [RFC-2133] to inform the kernel when describes an extension to the BSD API [RFC-2133] to inform the
it should be fragmenting at the network MTU rather than trying kernel when it should be fragmenting at the network MTU rather
to discover the path MTU. than trying to discover the path MTU.
Path MTU discovery works well when there is a stream of data. Path MTU discovery works well when there is a stream of data.
However for distributed servers sending small answers larger However for distributed servers sending small answers larger
than the network MTU to many clients the lack of fragmentation than the network MTU to many clients the lack of fragmentation
in intermediate nodes is anathema. 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.
1 - No Path MTU Discovery 1 - No Path MTU Discovery
Disabling path MTU. This would be a binary option, on a per socket Disabling path MTU. This would be a binary option, on a per socket
basis. If set the kernel would fragment all IP packets generated by basis. If set the kernel would fragment all IP packets generated by
this socket at the network MTU (576) [RFC-1883, 5] unless it has a this socket at the network MTU (1280) [IPV6-SPEC-V2, 5] unless it has a
priori knowledge of the path MTU which it could then use. priori knowledge of the path MTU which it could then use.
int discover = 0; int discover = 0;
if (setsockopt(s, IPPROTO_IPV6, IPV6_MTU_DISCOVER, if (setsockopt(s, IPPROTO_IPV6, IPV6_MTU_DISCOVER,
(char*) &discover, sizeof(discover)) == -1) (char*) &discover, sizeof(discover)) == -1)
perror("setsockopt IPV6_MTU_DISCOVER"); perror("setsockopt IPV6_MTU_DISCOVER");
2 - Setting IP Fragmentation Size 2 - Setting IP Fragmentation Size
A socket option to explicitly set the maximum IP fragment size for A socket option to explicitly set the maximum IP fragment size for
messages derived from this socket. This should be used when it is known messages derived from this socket. This should be used when it is known
that the path MTU is greater than the network MTU. that the path MTU is greater than the network MTU.
When combined with disabling path MTU discovery the resultant behaviour When combined with disabling path MTU discovery the resultant behaviour
should be the same as if the network MTU was set to this value. should be the same as if the network MTU was set to this value.
size_t mtu = 576; size_t mtu = 1280;
if (setsockopt(s, IPPROTO_IPV6, IPV6_MTU, if (setsockopt(s, IPPROTO_IPV6, IPV6_MTU,
(char*) &mtu, sizeof(mtu)) == -1) (char*) &mtu, sizeof(mtu)) == -1)
perror("setsockopt IPV6_MTU"); perror("setsockopt IPV6_MTU");
3 - Security Considerations 3 - Usage Consideration
Applications sending IPv6 datagrams larger than the network MTU should
ensure that the reviever has buffer space large enough to receive them.
How this is done is left upto the application.
4 - Security Considerations
This document is believed to introduce no security problems. This document is believed to introduce no security problems.
References Existing security problems with using IPv6 datagrams larger than the
network MTU include:
[RFC-1191] - Fragment overlay attacks.
Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[RFC-1883] - Reassembly buffer exhaustion.
Deering, S., and Hinden, R., "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995. References
[RFC-1981]
McCann, J., Deering, S., and Mogul, J. "Path MTU Discovery for
IP version 6", RFC 1981, August 1996.
[RFC-2133] [RFC-2133]
Gilligan, R. E., Thomson, S., and Bound, J., "Basic Socket Gilligan, R. E., Thomson, S., and Bound, J., "Basic Socket
Interface Extensions for IPv6", RFC 2133, April 1996. Interface Extensions for IPv6", RFC 2133, April 1996.
[IPV6-SPEC-V2] work in progress
Deering, S., and Hinden, R., "Internet Protocol, Version 6
(IPv6) Specification", draft-ietf-ipngwg-ipv6-spec-v2-01.txt,
November 1997.
Author' Address Author' Address
Mark Andrews Mark Andrews
CSIRO Mathematical and Information Sciences CSIRO Mathematical and Information Sciences
Locked Bag 17 Locked Bag 17
North Ryde NSW 2113 North Ryde NSW 2113
AUSTRALIA AUSTRALIA
+61 2 9325 3148 +61 2 9325 3148
<Mark.Andrews@cmis.csiro.au> <Mark.Andrews@cmis.csiro.au>
 End of changes. 10 change blocks. 
16 lines changed or deleted 40 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/