>>>>> On Tue, 14 Nov 2000 10:18:30 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> I'm now considering UDP applications that are sensitive to path MTU
> (toward the destinations). I recalled a discussion about a new socket
> option "IPV6_USEMTU", which allowed an application to specify an
> appropriate path MTU for packets sent from the application. I checked
> the archive of this list in April 2000, and, to my suprise, the
> discussion suddenly disappeared without any consensus.
> I think it is a good idea, and even essential for such UDP
> applications. What was wrong with the option? Or can we raise the
> option again as a clarification for rfc2292bis?
My original motiviation to support this (ancillary data item and/or
socket option) was as follows:
at one time, NetBSD and OpenBSD introduced a strict rule to validate
incoming ICMPv6 too big error messages; a too big error messages is
accepted (and the path MTU is adjusted accordingly) only when
- there exists a connected socket corresponding to the source and
destination addresses of the inner IPv6 header contained in the
error message, or
- there exists an IPsec security association corresponding to the
source and destination addresses of the inner IPv6 header
contained in the error message.
The objective of the rule is to avoid a DoS attack that tries to
make the target's memory exhausted by sending a massive number of
forged TOO BIG error messages for different paths.
The rule is okay for TCP connections. However, since some UDP
applications use unconnected sockets, such a strict rule is even
harmful for those applications; path MTU discovery does not work,
and when the applications send a large packet, the packet never
reaches the destination.
In order to overcome the situation as well as respecting the
security concerns, the only solution is to let applications perform
path MTU discovery by themselves. Thus, I thought IPV6_USEMTU was
essential.
However, as I mentioned in the ipngwg session yesterday, the latest
versions of NetBSD and OpenBSD (basically) always perform path MTU
discovery, regardless of the existence of corresponding connected
sockets or security associations. In order to avoid the DoS attack,
the latest versions introduced an upper limit of number of path MTU
cache entries (host route entries, actually), instead of the previous
strict validation.
So, for now, there's no strong reason to support the IPV6_USEMTU
ancillary data item and socket option, at least for me. Additionally,
if we can assume that every kernel accepts incoming TOO_BIG errors
(and perform path MTU discovery) regardless of the content of the
inner IPv6 headers, IPV6_USEMTU would totally be unnecessary.
However, I still think the ancillary data/socket option is not a bad
idea, because
- it is a natural generalization of IPV6_USE_MIN_MTU.
- we do not have to worry about the kernel's behavior by introducing
IPV6_USEMTU.
- if we added a knob to disable kernel-level path MTU discovery,
IPV6_USEMTU would be necessary.
- IPV6_USEMTU does not require the super user privilege, because it
only affects transmission from the corresponding socket.
- IPV6_USEMTU does not need require administrator privilege.
So, I'd like to hear others' opinions. Is it a good idea to introduce
IPV6_USEMTU (instead of IPV6_USE_MIN_MTU)?
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
