Using ping6 2001:4860:4860::8888 -s <packet size>

(that's the Google public DNS server)

I see answers up to packet size 1344.

It would be very interesting to know if others see the same (ie it's a
property of the server) or different (it's a property of the link).

Unfortunately, this only tells us about the path to the server and its
fragmentation behavior, the really interesting stuff goes the other way.


On 07/05/15 10:41, Toke Høiland-Jørgensen wrote:
> Simon Kelley <> writes:
>> It's difficult to see how that would work in practise for DNS. Take
>> the Google-public-DNS example. It's clearly not sane for Google's
>> servers to do PMTU on the address of every client, just to send one
>> UDP packet, and caching PMTU for clients is going to get hard, fast.
>> If the reply-size is bigger than the PMTU what happens anyway?
>> Presumably a truncated response, to force fallback to TCP.
> Well, IPv6 also mandates a minimum PMTU of 1280 bytes. So a source host
> that doesn't do PMTU discovery should either limit itself to 1280 bytes
> packets or fragment at the source. Routers are not going to do it. See
> :)
>> I guess it could work the other way around, and the client finds the
>> PMTU to the server, and puts that in the EDNS0 max packet field. Are
>> PMTU symetric?
> I guess that would be reasonable. Or just be on the safe side and always
> set the max packet field to 1280 bytes when querying over IPv6?
>> In any case, good luck updating every stub resolver in the world to do
>> this......
> Well in theory the people updating those same stub resolvers to speak
> IPv6 should pay attention to this, I guess. I'm not holding my breath,
> though... :P
> -Toke

Dnsmasq-discuss mailing list

Reply via email to