Kevin Ge writes:
> Hi Garrett,
>
> Yes, IPv4 protocol has 64K limit. But how about IPv6? Does IPv6 also
> limit to 64K in Solaris?
It's roughly the same -- 65575 to be exact (because the 16-bit IPv6
payload length field, unlike IPv4, doesn't include the header length).
If you look at the ip6.c source, you'll see:
case IP6OPT_JUMBO:
if (hdr_type != IPPROTO_HOPOPTS)
goto opt_error;
goto opt_error; /* XXX Not implemented! */
... so we don't have RFC 2675 jumbograms.
I guess I'd be surprised if it's terribly useful anyway. Even if you
can arrange to have your applications somehow offer that much in one
go, you're talking about an _incredibly_ tiny reduction of overhead,
at least at the protocol level. At 65575, the overhead is about
0.09%.
Yes, I realize that jumbograms are a _system_ overhead game and not a
protocol game, but I think both have to be balanced. As the packet
size goes up, both the probability and the cost of a drop increase,
effectively wiping out the benefits. I'd expect that users need to
avoid both the per-packet overhead imposed by tiny packets at one end
of the spectrum *and* the overall cost imposed by huge ones at the
other end.
The other small problem is hardware ... Ethernet supporting frames
that long would have clock stability problems, wouldn't it? I had
thought that the situation today was that anything over 16K or so was
experimental, as in:
http://tinyurl.com/3tdav3
Obviously, Ethernet's not the only game in town, but with little
network-wide support for monsters of that sort, it'd probably be
pretty hard to deploy.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
