Re: Meta-issues: On the deprecation of the fragmentation function

[RJ Atkinson <[e-mail]>]

On July 9th, Carsten Bormann wrote, in part:
>>> But for one problem: adaptation layer fragmentation is
>>> *transparent*, so there is no way for an application
>>> to do the equivalent of PMTUD to avoid/minimize adaptation
>>> layer fragmentation.

>> On 10/07/2013 05:28, RJ Atkinson wrote:
>> Good point.

On 09  Jul 2013, at 16:50 , Brian E Carpenter wrote:
> And you can't get round it. The decision to raise the minimum link
> MTU from 576 to 1280 was not a change in principle;

For IPv6, the specification of any minimum MTU might well 
have been the fundamental mistake here.

Specifying a minimum MTU above 576 definitely was a mistake 
in practical terms of IPv6 deployability -- and some of us 
objected to the change at the time (giving examples of 
links that would be broken -- which have come true since).


As you know already, IPv4 simply does not have any
Minimum Link MTU.  So it was probably over-specification 
for IPv6 to specify any minimum link MTU.


For IPv4, RFC-791 says 576 actually was the size of buffer space
that hosts had to have available for fragment reassembly.  

RFC-1122 agrees with RFC-791 and gives it the name EMTU_R 
  ("Effective MTU to receive").  

RFC-1122 further defines EMTU_S ("Effective MTU to send")
and says: 
  "... the IP layer SHOULD use EMTU_S <= 576 whenever
  the destination address is not a a connected network,
  and otherwise use the connected network's MTU."

A bit later on, RFC-1122 also says:
   "Since nearly all networks in the Internet currently
   support an MTU of 576 or greater, we strongly recommend
   the use of 576 for datagrams sent to non-local networks."

Again, this doesn't make 576 a minimum link MTU for IPv4.


> The big change in principle was the abolition of on-path fragmentation.

Well, at the moment, on-path fragmentation is not actually prohibited,
as near as several implementers (including me) can tell, although it 
absolutely is never required to be supported by routers.  

Everyone agrees that on-path fragmentation by routers is generally 
undesirable.  

Everyone also agrees that a router, for example a backbone high-speed router, 
must not be forced to fragment anything -- for practical performance reasons 
that are widely understood.  

However, the IPv6 specs don't prohibit a router from choosing to fragment 
a packet in the way described in my earlier note in those circumstances.  
Such fragmentation is generally undetectable at present, except to the 
router that performs the fragmentation in order to transmit the IPv6 packet 
over a link having a smaller MTU.  

This difference between "not required" and "prohibited" is critical 
for IPv6 deployment over low-rate links having a smaller MTU size, 
as I outlined in my previous note within this thread.

If a goal of this WG is to encourage deployment of IPv6 and transition
from IPv4 to IPv6, then it would be best not to change the current status
of fragmentation in IPv6 -- and it would be helpful to change the minimum
Link MTU to a value lower than 1280 (or deprecate the Minimum Link MTU
specification entirely, although that seems quite unlikely here now).

I'd really like to see IPv6 get universally deployed.  These particular
changes are significant barriers to that happening and create perverse
incentives either to stay with IPv6 forever or to build & deploy
IPv6::IPv4 translational gateways (ugh).

Cheers,

Ran