[dns-operations] Announcement - DNS flag day on 2019-02-01

[Mark Andrews]

> On 15 Jun 2018, at 1:57 pm, Florian Weimer <fw at deneb.enyo.de> wrote:
> 
> * Mark Andrews:
> 
>>> On 15 Jun 2018, at 1:30 pm, Florian Weimer <fw at deneb.enyo.de> wrote:
>>> 
>>> * Mark Andrews:
>>> 
>>>> No, a you just fragment at network MTU. The IETF even specified a
>>>> setsockopt in the advanced socket API to tell the kernel to do that.
>>> 
>>> As specified, IPv6 does not have a network MTU, just like IPv4.
>> 
>> Network minimum MTU (1280 RFC 2460 section 5.5) then if you want to be
>> semantically correct. See RFC 3542 for IPV6_USE_MIN_MTU for the description
>> of the setsockopt which followed from draft-ietf-ipngwg-bsd-frag.
> 
> Please read what I wrote below.  According to the specification, nodes
> still need to deal with lower MTUs than that.
> 
>>> | In response to an IPv6 packet that is sent to an IPv4 destination
>>> | (i.e., a packet that undergoes translation from IPv6 to IPv4), the
>>> | originating IPv6 node may receive an ICMP Packet Too Big message
>>> | reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
>>> | is not required to reduce the size of subsequent packets to less than
>>> | 1280, but must include a Fragment header in those packets so that the
>>> | IPv6-to-IPv4 translating router can obtain a suitable Identification
>>> | value to use in resulting IPv4 fragments.
>>> 
>>> <https://tools.ietf.org/html/rfc2460#section-5>
>>> 
>>> RFC 6946 affirms this bizarre behavior.
>>> 
>>> Therefore, if you want to avoid state, you need to send atomic
>>> fragments unconditionally, but that causes interoperability problems,
>>> so you cannot do this in practice.


There are too many religious nuts with firewalls.

We should argue that NAT64 should set DF=0 on UDP packets <= 1280.  I don’t
think this is covered by any RFC one way or another.  That would remove
any need to keep state in the server.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org