Path MTU discovery remains widely undeployed due to
security issues, and IP fragmentation has exposed weaknesses in
application protocols.
PMTUD doesn’t work through NAT and that’s probably the main reason
why it doesn’t work on the Internet. I think that’s less of a
security issue than just a general issue with PMTUD not working on the
modern Internet.
Currently, DNS is known to be the largest
user of IP fragmentation.
Compared to what? I would just drop this sentence because it doesn’t
add anything to the document and it’s trying to make a point that
doesn’t need to be made.
Most of the Internet and especially the inner core has an MTU of
at least 1500 octets. Maximum DNS/UDP payload size for IPv6 on
MTU 1500 ethernet is 1452 (1500 minus 40 (IPv6 header size) minus
8 (UDP header size)). To allow for possible IP options and
distant tunnel overhead, authors' recommendation of default
maximum DNS/UDP payload size is 1400.
Before I was interested in the DNS I worked for an ethernet switch
vendor for 8 years, and I often find the way MTU gets talked about in
IETF documents simply weird. MTU is a measurement of maximum frame size
for a network segment starting at Layer 2. Yet there’s no discussion
of layer 2 here. The discussion starts at layer 3 and because of that
the math doesn’t make any sense to me.
Is there just an assumption that layer 2 will consume 18 bytes?
(6+6+2+4) (DA+SA+ET+FCS) Can we state this assumption in the document?
As I read it now it’s not clear how many bytes are assumed to be
consumed by layer 2 headers.
I said many of these same things in a mail to this list on August 12,
2020 but never received a response.
Thanks,
Andrew
On 26 Jul 2022, at 23:13, Suzanne Woolf wrote:
Dear colleagues,
This message starts the Working Group Last Call for
draft-ietf-dnsop-avoid-fragmentation
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/).
The requested status is BCP.
Since we're starting the Last Call during the IETF week, and many
folks are on holidays in the next few weeks, the WGLC will end in
three weeks (instead of the usual two), on August 16.
Substantive comments to the list, please. It’s fine for minor edits
to go direct to the authors. We need to hear positive support to
advance it, or your comments on what still needs to be done.
Thanks,
Suzanne
For the chairs
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
