Dear Mr Vixie and Mr Fujiwara,
I’m a relative noob to DNS and the IETF, and I’m often confused in
how the term MTU is used when discussing DNS. Essentially it is a
layer-2 term, and outside of layer-2 it can be difficult to understand
what is meant by it. It’s a term that’s become overloaded.
For example this sentence, “In practice, the smallest MTU witnessed in
the operational DNS community is 1500 octets, the Ethernet maximum
payload size.” Does this imply an Ethernet overhead of 18 bytes
(6+6+2+4) (DA+SA+ET+FCS)? And what precisely is meant by Ethernet here?
Contemporary layer-2 technologies that we call ethernet do not have this
1500 byte limit. The problem is that as a reader it’s not clear to me
how many bytes are left over for layer-3 and above.
Perhaps it’s too late in the game to limit the use of ‘MTU’ to
layer-2 discussions. But it would be a lot clearer to me if we used a
term like ‘packet size’ when discussing layer-3 and above, and kept
the MTU term for use only when discussing layer-2 segment maximum
datagram sizes.
Also, it seems odd to not mention NAT in the second sentence, “Path
MTU discovery remains widely undeployed due to security issues”. NAT
breaks PMTUD when ICMP is used as the discovery mechanism. This should
get mentioned in the document somewhere. There are likely many
technologies deployed that break PMTUD that I’m not even aware of,
it’s not just ‘security issues’.
—Andrew
On 30 Jun 2020, at 12:36, [email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Domain Name System Operations WG of
the IETF.
Title : Fragmentation Avoidance in DNS
Authors : Kazunori Fujiwara
Paul Vixie
Filename : draft-ietf-dnsop-avoid-fragmentation-00.txt
Pages : 10
Date : 2020-06-30
Abstract:
Path MTU discovery remains widely undeployed due to security
issues,
and IP fragmentation has exposed weaknesses in application
protocols.
Currently, DNS is known to be the largest user of IP fragmentation.
It is possible to avoid IP fragmentation in DNS by limiting
response
size where possible, and signaling the need to upgrade from UDP to
TCP transport where necessary. This document proposes to avoid IP
fragmentation in DNS.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-avoid-fragmentation-00
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-00
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
