[Dnsmasq-discuss] seeing www.ietf.org fail dnssec with dnsmasq rc7

[Kevin Darbyshire-Bryant]

On 07/05/2015 13:54, Simon Kelley wrote:
> On 07/05/15 10:41, Toke Høiland-Jørgensen wrote:
>> Simon Kelley <simon at thekelleys.org.uk> 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
>> https://tools.ietf.org/html/rfc2460#section-5 :)
> But if they fragment, what size should they fragment to? I guess inthe
> absence of any information to the contrary, 1280 bytes. I wonder if the
> Google public DNS is failing to do that, or if it is, and the path to me
> is dropping fragments?
>
> Simon.

For me, a variable but persistent problem reported by the ICSI Netalyzer is one of "the
path between you and us doesn't handle fragmented IPv6 traffic properly".  Another symptom
of this is, I know not if this is cause or effect, is that the ipv6 traceroute they run also doesn't
complete.

The behaviour between working or not can change for months at a time, which suggests
a core routing difference rather than any ipv4/v6 tunnel config change (I use Hurricane
Electric's free tunnelbroker service for IPv6 & have tried changing tunnel MTU)

Certainly my initial understanding of IPv6 was that 'it didn't do fragmentation', which isn't
quite true.  When I get some time at home alone with my router (!) I shall do a bit more
digging.  But mishandling of IPv6 fragments is going to cause hell for edns.

Kevin



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4791 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150507/21f55e05/attachment.bin>