On 2018-06-01 02:54, Mikael Abrahamsson wrote:

> On Thu, 31 May 2018, Joe Touch wrote:
> 
>> I disagree.
>> 
>> UDP fragmentation has its benefits and uses, but should not be required when 
>> a transport layer isn't needed - e.g., for IP tunneling.
>> 
>> Fundamentally, IP fragmentation is fragile for only a few reasons:
>> 1) the ID space is small (which shouldn't matter unless there is a very 
>> large amount of reordering)
>> 2) loss of fragments creates inefficiencies (true, but routers can 
>> fate-share fragments they drop sometimes, just as was eventually done for 
>> ATM AAL5)
>> 3) in-network devices can't find transport ports in some fragments, causing 
>> problems for NATs, policy filters and firewalls, etc.
>> 
>> Of these, my view is that #3 is the only reason actually driving a claim of 
>> fragility - and all it tells me is that "the Internet is fragile when 
>> devices don't follow the rules".
>> 
>> I do not think it is appropriate to validate that conclusion.
> 
> You're fundamentally right, unfortunately operational reality adds lots of 
> more points to your list, meaning the end outcome is that IP fragmentation 
> doesn't work well in real life.
> 
> I am as opposed to letting bad practices win as you probably are, but I also 
> don't think this is fixable. This means applications need to have a mode 
> where they do not rely on IP fragments for basic operation.

I am OK if the conclusion says: 

1) this is a bug/incorrect implementation that needs to be fixed 
2) in the meantime, users (not just apps) should consider using other
ways, esp. if their system cannot detect whether the use of IP fragments
fails 
3) #2 should not be interpreted to let implementers off the hook for #1 

I.e., IP fragmentation should not be deprecated; its avoidance should
not imply that deprecation, and vendors are responsible for the bug that
not supporting fragmentation represents. 

Joe
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to