> From: Petr Špaček <pspa...@isc.org>
>> Then, do you agree the following requirements ? (as DNS software
>> developpers)
>> 1. SHOULD set DF bit on outgoing UDP packets on IPv4,
>> and SHOULD not use FRAGMENT header on IPv6.
>
> Theoretically yes, but it might not be achievable depending on OS
> API. We tried many iterations in BIND, and discovered that APIs (at
> least in Linux) are horrible and there are traps everywhere.
Thanks. "Path MTU Disovery" API and setting IP_DF API are complex and
they often don't work as expected.
However, it may be easy to avoid using the Fragment Header on IPv6.
(limit IPv6 response packet smaller than interaface MTU.)
(Or, is it not easy ?)
Then, do you agree "SHOULD not use FRAGMENT header on IPv6" ?
On IPv4, I would like to write it in such a way that "setting the DF
bit" is an goal, and that OS implementors and DNS server
software developpers will do their best.
(For example, UDP responders RECOMMENDED to set DF bit on IPv4.)
However, from RFC 2119 keyword definitions, SHOULD==RECOMMENDED,
and there may exist valid reasons to ignore a particular item.
(When the OS does not have a function to set DF bit,
it is a alid reason not to set DF bit.)
| 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
| may exist valid reasons in particular circumstances to ignore a
| particular item, but the full implications must be understood and
| carefully weighed before choosing a different course.a
>> 2. limit DNS payload size 1232 without path MTU discovery.
>> (After DNSFlagDay2020, many implementations use 1232)
>
> As Paul wrote down thread, it is random number - and so far it works
> for us.
OK, Then,
Then, to allow larger than 1232/1400 and smaller than interface MTU
response packets, recommendations for UDP requestors are changed as:
UDP responders can send reponses fit in both
the result of path MTU discovery (if available),
interface MTU and UDP requestor's payload size.
Recommendations for UDP requestors are changed as
- remove "Don't Fragment" way.
- UDP requestors SHOULD limit the requestor's payload size as 1400.
[ UDP requestors MAY limit the requestor's payload size as 1232.
1232 is the IPv6 minimal MTU size
minus IPv6 header size minus UDP header size. ]
>> 3. If path MTU discovery works, UDP responders can send larger (>1232)
>> responses fit in the path MTU.
>
> Possibly, but I think it is kind of moot advice without knowing how it
> can be done. Right now there is no such thing as RFC 8899-equivalent
> for DNS, so we don't even know if it would work for DNS as we know
> it. Quick glance at RFC 8899 section 3 is not encouraging in that
> regard, e.g. point 3, as a single example, shows that 8899 does not
> match the current state of DNS (because auth does not get answer from
> a resolver if the large response got through or not).
Then, I would like to change as
UDP requestors MAY perform "Path MTU discovery" per destination
to use requestor's UDP payload size larger than 1400.
Then, calculate their maximum DNS/UDP payload size as
the reported path MTU
minus IPv4/IPv6 header size (20 or 40) minus UDP header size (8).
>> 4. TCP implementations SHOULD set DF bit / not use FRAGMENT header.
>> (many TCP implementations already set DF bit)
>
> I doubt we have control over this from the application. Is there even
> API to control that on TCP sockets?
I agree. I leave it unwritten.
>> # If there is a link whose MTU is smaller than 1260 (on IPv4),
>> # the link may be a blackhole.
>
> Definitely. If the default is "too wrong" the whole thing falls apart.
>
>
> I'm sorry for not being more informative. The only I know for certain
> is that we had multiple iterations in BIND, are not happy with any of
> them, and and it is order of magnitude more complex than we thought.
At least, I would like to disable IPv6 fragmentation.
and I would like to make "avoid IPv4 fragmetion" our goal.
--
Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
