Hi,

>From: Bob Hinden <[EMAIL PROTECTED]>
>Date: Fri, 22 Jul 2005 13:18:24 -0700

> In my personal view, having devices on shared media with different MTU's is 
> just a bad idea.

I think so, but in a real world, such bad ideas are often accepted.

In the IPv4 environment, MTU problem is more simple because DHCP has
no MTU option.  The mechanisms to adjust packet size are PMTUD and TCP
MSS negotiation.  For TCP applications to the Internet, these
mechanisms will work fine.  For UDP or ICMP applications to the
Internet, almost applications restrict a packet size less than 1500.
Of course, NFS uses large packet size, but almost people will not use
NFS over the Internet.  So, people can use the Internet fine, and
enjoy Jumbo Frames in LAN.

To make a same situation for IPv6, we must not include MTU option in
RA.  An interoperability will be down slightly, but we can use Jumbo
Frames.  If RA includes MTU option, we will get a perfect
interoperability about MTU, but cannot use Jumbo Frame.

Now, people are accumulating the knowledge about Jumbo Frames.  They
will learn the trick to use Jumbo Frames for IPv4, and will say, "IPv6
is slower than IPv4, because it disables Jumbo Frames...".

I think there are three ways for us.

1) Do nothing.  Jumbo Frames is an illegal specification for IEEE
   802.3, and there is no de facto frame size also.  Wait until IEEE
   will move, or a de facto standard will be made.

2) Make a new protocol for MTU/MRU discovery/negotiation.  Thanks for
   Mark, Iljitsch or others.

3) Make a memorandum for Jumbo Frames with current implementations.
   Fix the implicit maximum value of RFC2464, how to enable Jumbo
   Frames for IPv6, the estimated problems, the implimentation
   restrictions, and so on.


Ryota Hirose
Yamaha Corporation


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to