Subject: Re: [v6ops] RFC 2464 - MTU >1500

From: RJ Atkinson <[email-masked]>
Date: Fri, 11 Feb 2011 17:04:47 -0500

Because of issues with file transfer throughput, originally 
arising in the high-performance computing world which was 
moving from ATM to GigE in the late 1990s, nearly all 
1 Gig Ethernet products have supported an IP MTU of 9180 bytes 
for at least a decade now.  

The computing issues addressed by GigE jumbograms and the 
reason for the 9180 byte IP MTU size are amply documented 
in an old ATM-related document, RFC-1626.  For migration
reasons and to avoid fragmentation, Ethernet jumbograms 
needed to be at least as big as the ATM jumbogram size.

The combination of CSMA/CD at the link-layer (e.g. big
yellow Ethernet cables) and jumbograms can create real 
technical issues.  This reportedly has caused IEEE to decline 
to formally standardise jumbograms for Ethernet.  Despite
that, support for Ethernet jumbograms is a marketplace
requirement and is (AFAICT) universally available in
deployed 1/10 GigE products today.

Earlier, Fred Baker wrote:
> </chair>
> 
> I think the right thing to do is (C), an update to 2464 and the various RFCs
> that refer to a magic numbers 1500 or 1280, indicating that IPv6 MTU
> *in*all*cases* follows the same rules as IPv4, which is to say that it uses
> defaults appropriate to the characteristics of the link layer and
> is subject to local configuration, DHCP configuration, TCP MSS negotiation,
> and Path MTU.
> 
> The number "1280" is important in a world where IPv6 is primarily carried
> in tunnels, and 1500 is important to Ethernets below 1 Gig.  But we are
> in the process of making IPv6 native, and have link layer MTUs as small
> as 128 without a means to link fragments of higher layer protocols together
> (so the rule trying to impose that on link layer protocols is broken)
> and as high as 18,000 (Token thing).

I agree with Fred on the above.  

I objected to setting the magic 1280 byte number low back ~15 years 
ago (IETF IPng WG minutes, December 1994).  At the time, I was 
thinking about certain SATCOM link layers (some of that link technology 
is still deployed, btw).  Since then, I know of other link layers 
that have this issue.  At the same IETF IPng WG meeting, an equivalent 
issue was identified with AppleTalk.  Fred has now pointed out that 
802.15.4 and other link layers have this issue.  

Tunneling isn't the answer here.  It consumes precious bandwidth,
requires more CPU, and requires more memory.  All of these are
scarce.  For example, the SATCOM definition of "high bandwidth" is 
several orders of magnitude smaller than the 10 Gbps links that
ISPs would call "high bandwidth".

If IPv6 is going to really replace IPv4, then Fred's suggestions
above really ought to be made to the standards.  My guess is that
if IPv6 does not make those changes, then folks will only run
IPv4 over those constrained link types (which is what seems 
to have happened in the past ~15 years, AFAICT).  That is not an
outcome that helps IPv6 be widely deployed natively.

Yours,

Ran Atkinson