Thus spake "Mark Smith" <[EMAIL PROTECTED]>
On Fri, 22 Jul 2005 13:20:40 -0500
"Stephen Sprunk" <[EMAIL PROTECTED]> wrote:
The hole is that there may be an L2 device in the middle which has
a lower MTU than the end hosts. The neighbor MTU is an upper
bound, but it's not guaranteed to work -- you need to probe to see
what really works.
I agree that probing would be nice to have, however I don't think not
having it is a "black" hole.
When a larger than standard MTU is used (e.g., 9K jumbos over
GigE verses the 802.3 standard of 1500), the operator has made a
conscious decision to increase the MTU, and therefore needs to
take responsibility for ensuring that intermediary layer 2 devices
support the increased MTU. People who want use jumbo frames
on GigE interfaces know usually that they have to also have
jumbo frame capable switches..
Except we nearly have this situation today -- jumbos only work if the admin
goes through a lot of painstaking effort to make sure they do. You're
proposing we eliminate the per-host effort but not the network-side effort;
to me that's a half-solution (as you granted in a section I snipped). I
want jumbos to work out of the box without the admin (which might be my
grandmother at home) even knowing what jumbos are.
If we make the assumption that the intermediary link layer devices
support the largest node MTU/MRU on the segment, I think the
problem becomes a lot simpler, and then the issues to solve are :
(a) how to ensure large MTU/MRU capable end nodes use them
when communicating between each other.
(b) how to ensure end-nodes with smaller MTU/MRUs are not sent
too large frames by the large MTU/MRU capable end-nodes.
I think either of these issues could be solved by using a ND NS/NA
MRU type option, and, because RAs can carry a link-layer address,
negating the need for a node to perform a ND NS/NA transaction
with the router, at least initially, have an RA also possibly carry
an MRU indication.
The RA's MRU would make a good upper bound, but you still need to probe to
make sure a host you're talking to isn't sitting behind some $30 hub that
silently drops jumbos (er, giants). And you have to keep probing in case
the host moves or the L1/L2 path changes, unless you've recently received
from that host a jumbo or ACK for your own jumbo.
The reason I think this is necessary is that it allows hosts supporting
jumbos to have them on by default and gracefully fall back to non-jumbo
sizes in the presence of non-jumbo-aware hosts or network devices. You can
only have them on by default if you're sure you can handle the most perverse
case (which I think I presented).
For multicast, the link standard MTU or the link RA announced MTU
would be used.
I'm not sure using an MTU above 1500 for multicast should be legal; there
may be hosts on the subnet which we don't know are neighbors and thus we
don't know the lowest MRU out there. Also, aren't there cases where we'll
know of a neighbor but wouldn't have had to do ND and thus wouldn't have
learned their MRU?
For nodes that don't implement this "MRU" option, they'll use the link
standard MTU to communicate with their neighbours and vice-versa,
as per IPv6 operation today.
Of course.
And, since I know this is the IPv6 WG list, which WG would be appropriate to
discuss back-porting this feature into IPv4 after we solve it for IPv6?
S
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
