Subject: Re: IPV6_USEMTU socket option

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 16 Dec 2000 23:20:50 +0900

>>>>> On Tue, 14 Nov 2000 10:18:30 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> 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-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sun, 17 Dec 2000 00:00:10 +0900

>IPV6_USEMTU (instead of IPV6_USE_MIN_MTU)?

	I tried to come up with three scenarios, with different availability
	of standards.  hope it is correct.

	discussion points would be:
	- can we assume that the kernel will always fragment outgoing
	  datagrams?  i believe there's no clear wording in spec so far.
	  i do remember there was some discussion in the past, about
	  if path MTU discovery works for UDP or not.
	- IPV6_USE_MTU changes situation very little, while it require
	  certain amount of user code to take advantage of it.  is it really
	  worthwhile?
	- do we need to inform of new path MTU value, with IPV6_RECVPATHMTU?
	  (depends on the 2nd bullet)

itojun

in the world with IPV6_USE_MIN_MTU only:
- to avoid path MTU discovery, user application will use MTU of 1280, by
  IPV6_USE_MIN_MTU.
- otherwise, kernel will automatically fragment the packet (it is assumed).
- for L4 without retransmit (UDP), user application needs to resend the packet.
  however, there's no notification even when we need a retransmission.

in the world with IPV6_USE_MIN_MTU + IPV6_RECVPATHMTU:
- to avoid path MTU discovery, user application will use MTU of 1280, by
  IPV6_USE_MIN_MTU.
- otherwise, kernel will automatically fragment the packet (it is assumed).
- for L4 without retransmit (UDP), user application needs to resend the packet.
  with IPV6_RECVPATHMTU, user application can know when it needs to resend.
- do we need to include current path MTU information to IPV6_RECVPATHMTU?
  it depends on application.  (1) can use the information, (2) cannot.
  (1) if the application can use arbitrary packet size, it can adapt to the
      current path MTU, and try to use path MTU > 1280 effectively.
  (2) if the applicaiton cannot use arbitrary packet size (like NFS/DNS), it
      will need to rely upon kernel fragmentation, or need to fragment to 1280.

in the world with IPV6_USE_MIN_MTU + IPV6_RECVPATHMTU + IPV6_USE_MTU:
- to avoid path MTU discovery, user application will use MTU of 1280, by
  IPV6_USE_MIN_MTU.
- otherwise, kernel will automatically fragment the packet.  even if
  the kernel does not fragment it, we can fragment it by IPV6_USE_MTU.
- for L4 without retransmit (UDP), user application needs to resend the packet.
  with IPV6_RECVPATHMTU, user application can know when it needs to resend.
- do we need to include current path MTU information to IPV6_RECVPATHMTU?
  it depends on application.  (1) and (2c) can take advantage of it, others
  cannot.
  (1) if the application can use arbitrary packet size, it can adapt to the
      current path MTU, and try to use path MTU > 1280 effectively.
  (2) if the applicaiton cannot use arbitrary packet size (like NFS/DNS), it
      has three options:
    (2a) rely upon kernel fragmentation,
    (2b) fragment to 1280, or
    (2c) specify fragmentation size with IPV6_USE_MTU.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Jason R Thorpe <[email-masked]>
Date: Sat, 16 Dec 2000 09:30:30 -0800

> IPV6_USEMTU (instead of IPV6_USE_MIN_MTU)?

Note that for IPv4, NetBSD has a way to fetch path MTU information for raw
IP sockets.  If an application gets an EMSGSIZE, it can do a getsockopt()
on the IP_ERRORMTU option to fetch the MTU that it should have used.

-- 
        -- Jason R. Thorpe <[email-masked]>