<div dir="ltr"><br><div>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. <br>
<br>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.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 15, 2014 at 11:11 AM, Hannes Frederic Sowa <span dir="ltr"><<a href="mailto:hannes@stressinduktion.org" target="_blank">hannes@stressinduktion.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Jan 15, 2014 at 10:42:21AM -0800, Colm MacCárthaigh wrote:<br>
> On Wed, Jan 15, 2014 at 5:06 AM, Hannes Frederic Sowa <<br>
> <a href="mailto:hannes@stressinduktion.org">hannes@stressinduktion.org</a>> wrote:<br>
> ><br>
> > Would it be of interest to get the state of fragmentation on incoming<br>
> > datagrams by e.g. ancillary data on recvmsg so resolvers could check if<br>
> > the incoming packet was fragmented then drop and retry if it was below<br>
> > a certain size?<br>
> ><br>
><br>
> Yes, I'd appreciate that capability at least. It would also be nice to be<br>
> able to reject re-assembled datagrams whose fragments had different IP TTL<br>
> values.<br>
<br>
</div></div>IIRC this was already under discussion and at that time was not considered<br>
beneficial (I don't remember where).<br>
<br>
For inclusion to the core stack we would need some hard facts that<br>
different TTLs on fragments are very unlikely on the internet (which<br>
I doubt).<br>
<br>
A netfilter match should be doable nonetheless.<br>
<br>
Thanks,<br>
<br>
  Hannes<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Colm
</div>