On Fri, Jun 1, 2018, 2:54 AM Mikael Abrahamsson <swm...@swm.pp.se> 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 agree with Joe. Would also note that #3 is not a problem with fragmentation itself, but with middle boxes attempting to parse transport layer information. That problem potentially exists any time a "non-standard" IP protocol number is used (ie something other than UDP it TCP). It would be best if the solution is to use generic mechanisms to provide functionality, as opposed to discouraging use of protocols or fragmentation. Using flow label for ECMP is s good example, this eliminates need for DPI and works with fragmentation or any IP protocol. I think this draft should distinguish problems inherent in IP fragmentation and those that have be created by middle boxes that can't deal with fragments Tom > -- > Mikael Abrahamsson email: swm...@swm.pp.se > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
