In message <pine.lnx.4.64.1308261732510.29...@shell4.bayarea.net>, "C. M. Heard " writes: > On Tue, 27 Aug 2013, Mark Andrews wrote: > > In message <pine.lnx.4.64.1308260755110.19...@shell4.bayarea.net>, > > "C. M. Heard" writes: > > > Here are some other suggestions: > > > > > > - Make this a destination option that appears before the > > > fragmentation header, not a hop-by-hop option, as discussed in a > > > previous e-mail in this thread. > > > > It is quite possible to develop asics which understand this option > > the same way as there are asics which process tcp and udp headers. > > could be developed != exists in current core routers > > Existing core routers are likely to punt hop-by-hop options to a > slow path. But they aren't the cause of the fragment dropping > problems. So we should seek a solution that does not require > updating them.
Some punt them to the slow path but fragmented IP is also a small percentage of traffic. Others just don't process hop-by-hop. Others just drop. > I don't see why a destination option (apearing BEFORE the fragment > header) would not work just as well as a hop-by-hop option while > being immune from this particular problem. > > > > - This option MUST NOT appear in an initial fragment (or in an > > > unfragmented fatagram). That avoids the possibiity that a > > > middlebox will interpret a datagram differently from an end system > > > (or another middlebox). > > > > This is a non starter. Whatever change we make needs to be visible in > > all fragment. Firewalls need to be able to identify if the packet is > > following old fragmentation rules or new fragmentation rules so it can > > decide if it is applying old policy or new policy. > > I don't see that. Lots of firewalls discard all fragments as it is pointless sending the initial fragment if you are discarding non-initial fragments. As for mis-matches they are expected if you have NATs in the path. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
