It seems that the biggest obstacle to fragmentation are NAT and Firewall. They need the port numbers in order to find and enforce context. NAT might be going away with IPv6, maybe, but firewalls are not.
Have considered strategies that move the port number inside the IP header? For example, have an UDP replacement for IPv6 that does not have any port number in the new UDP header, and relies instead on unique IPv6 addresses per context? -- Christian Huitema > On Aug 26, 2018, at 10:08 AM, Tom Herbert <[email protected]> wrote: > >> On Fri, Aug 24, 2018 at 8:24 PM, Toerless Eckert <[email protected]> wrote: >>> On Fri, Aug 03, 2018 at 09:48:25AM +0200, Mikael Abrahamsson wrote: >>> I've kept saying "Networks must support ip fragmentation properly. >> >> Why ? Wheren't you also saying that you've got (like probably many >> else on this thread) all the experience that only TCP MSS gets you >> working connectivity in many case (like hotels) ? >> >> IMHO, we (network layer) should accept defeat on network layer >> fragmentation and agree that we should make it easier for the >> transport layer to resolve the problem. >> >> Aka: I would lvoe to see a new ICMPv4/ICMPv6 reply and/or PTB reply option >> indicating "Fragmented Packets Not Permitted". Any network device which >> for whatever reason does not like Fragemnts would simply drop >> fragmented packets and send this as a reply. Allows then the >> transport layer to automatically use packetization (such as TCP MSS) >> to get packets through. >> >> Of course. Will take a decade to get ubiquitously deployed, but >> neither IPv4 nor IPv6 will go away, only the problems with fragmentation >> will become worse and work if we do not have an exit strategy like this. >> > Toeless, > > I'm curious why you think the problems with fragmentation will become > worse. The draft and much of this thread has already highlighted the > problems with fragmentation that happen because of non-conformant > implementation. While there's a lot of legacy implementation that > might hard to fix completely, I don't think we've seen a good argument > that these problems are infeasible to fix in new deployments and > products. I think this draft is an opportunity not only highlight the > problems, but to suggest some practical fixes to improve the situation > as a way forward. > > Tom > >> If we don't try an exit strategy like this, we will just get what >> Joe said, the complete segmentation of the Internet with more and >> more L4 or even higher layer proxies. >> >> Btw: +1 for adopting the doc as a WG item, but primarily because everything >> before section 7 is on a way to become a good read of reality. Section >> 7 recommendations is only a faith based exercise (praying) as long as it >> tries to >> get the job done primarily by appealing to application developers. >> >> Cheers >> Toerless >> >> >> > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
