Unfortunately I can't share data, but I have looked at a lot of it. In general, I've seen TTLs to be very stable. Most ECMP is flow-hashed these days and so as long as the path is stable, the TTLs should be identical. If there's some kind of transition mid-datagram, the the TTLs may legitimately mismatch, but those events seem to be very rare.
netfilter would be fine, but it'd be nice to not incur any state cost beyond what the UDP re-assembly engine is keeping already. On Wed, Jan 15, 2014 at 11:11 AM, Hannes Frederic Sowa < [email protected]> wrote: > On Wed, Jan 15, 2014 at 10:42:21AM -0800, Colm MacCárthaigh wrote: > > On Wed, Jan 15, 2014 at 5:06 AM, Hannes Frederic Sowa < > > [email protected]> wrote: > > > > > > Would it be of interest to get the state of fragmentation on incoming > > > datagrams by e.g. ancillary data on recvmsg so resolvers could check if > > > the incoming packet was fragmented then drop and retry if it was below > > > a certain size? > > > > > > > Yes, I'd appreciate that capability at least. It would also be nice to be > > able to reject re-assembled datagrams whose fragments had different IP > TTL > > values. > > IIRC this was already under discussion and at that time was not considered > beneficial (I don't remember where). > > For inclusion to the core stack we would need some hard facts that > different TTLs on fragments are very unlikely on the internet (which > I doubt). > > A netfilter match should be doable nonetheless. > > Thanks, > > Hannes > > -- Colm
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
