On Sun, Aug 26, 2018 at 10:31 AM, Christian Huitema <huit...@huitema.net> wrote: > 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, That's sort of along the lines for what Firewall and Service Tickets (FAST) does. But instead of just putting a port number in the IP header, FAST employs a generic ticket containing the state information needed by the firewall. Tickets are encoded in Hop-by-Hop options, so the firewall only needs to inspect the Hop-by-Hop options to do its work eliminating the need for DPI at the middlebox (protocol compliant with RFC8200). This works on any packet regardless of whether it's a fragment (no reassembly at firewall is ever necessary), any combination of extension headers, and any transport protocol even those that don't have a concept of ports. Tom > > -- Christian Huitema > >> On Aug 26, 2018, at 10:08 AM, Tom Herbert <t...@herbertland.com> wrote: >> >>> On Fri, Aug 24, 2018 at 8:24 PM, Toerless Eckert <t...@cs.fau.de> 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 >> 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
