Re: [dns-operations] UDP fragmentation while not needed/wanted DS www.veilingzaalmelase.be

2021-03-26 Thread Joao Luis Silva Damas 


> On 25 Mar 2021, at 23:36, Paul Vixie  wrote:
> 
> On Wed, Mar 24, 2021 at 11:25:48PM +0100, Florian Weimer wrote:
>>> ...
>> 
>> Proactive fragmentation irrespective of path MTU is required for
>> stateless IPv6 UDP services.  Unlike IPv4, the network does not
>> fragment packets.  So a UDP service has to conservatively fragment
>> around 1200 or so bytes (to account for tunnel overhead).  ...
> 
> 1280 subtracts several hundred bytes from 1500 to allow for tunnel
> overhead.

Actually it doesn’t. The IETF arrived at this number from the other side (small 
values for MTU). See mail at bottom to see just what assumptions went into the 
parameters (1280=1025+256 because IPv4 was 512+64 and IPv6 needed to reduce the 
header overhead below that of IPv4. please…, 9600bps...)

> 1232 subtracts dozens more to allow for IP and UDP headers
> and options.

That is does, unnecessarily. There is, and has been for a while, data out there 
showing bigger numbers are OK (for instance, Google published how they got to 
the size they use on QUIC packets based on traffic they observed arriving at 
their network, a fairly decent piece of data).

> 
> please, nobody, subtract even more. if everyone subtracts a fudge
> factor, forever, we'll eventually run out of payload space, or worse,
> go negative.

:)

> 
> -- 
> Paul Vixie
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations


From owner-i...@sunroof.eng.sun.com   
Thu Nov 13 16:41:01 1997
Received: (from majordomo@localhost)
by sunroof.eng.sun.com  
(8.8.8+Sun.Beta.0/8.8.8) id QAA14339
for ipng-dist; Thu, 13 Nov 1997 16:38:00 -0800 (PST)
Received: from Eng.Sun.COM  (engmail1 [129.146.1.13])
by sunroof.eng.sun.com  
(8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA14332
for ; Thu, 13 Nov 1997 16:37:51 -0800 (PST)
Received: from saturn.sun.com  (saturn.EBay.Sun.COM 
 [129.150.69.2])
by Eng.Sun.COM  (SMI-8.6/SMI-5.3) with SMTP id 
QAA28654
for mailto:i...@sunroof.eng.sun.com>>; Thu, 
13 Nov 1997 16:37:48 -0800
Received: from postoffice.cisco.com  
(postoffice.cisco.com  [171.69.200.88])
by saturn.sun.com  (8.8.8/8.8.8) with ESMTP id 
QAA28706
for mailto:i...@sunroof.eng.sun.com>>; Thu, 
13 Nov 1997 16:37:49 -0800 (PST)
Received: from [171.69.199.124] (deering-mac.cisco.com 
 [171.69.199.124]) by postoffice.cisco.com 
 (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA20862; 
Thu, 13 Nov 1997 16:37:48 -0800 (PST)
X-Sender: deer...@postoffice.cisco.com 
Message-Id: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Nov 1997 16:37:00 -0800
To: IPng Working Group mailto:i...@sunroof.eng.sun.com>>
From: Steve Deering mailto:deer...@cisco.com>>
Subject: (IPng 4802) increasing the IPv6 minimum MTU
Cc: hin...@ipsilon.com 
Sender: owner-i...@eng.sun.com 
Precedence: bulk

In the ipngwg meeting in Munich, I proposed increasing the IPv6 minimum MTU
from 576 bytes to something closer to the Ethernet MTU of 1500 bytes, (i.e.,
1500 minus room for a couple layers of encapsulating headers, so that min-
MTU-size packets that are tunneled across 1500-byte-MTU paths won't be
subject to fragmentation/reassembly on ingress/egress from the tunnels,
in most cases).

After the short discussion in the Munich meeting, I called for a show of
hands, and of those who raised their hands (about half the attendees, if
I recall correctly), the vast majority were in favor of this change --
there were only two or three people opposed.  However, we recognized that
a fundamental change of this nature requires thoughtful discussion and
analysis on the mailing list, to allow those who were not at the meeting
and those who were there but who have since had second thoughts, to express
their opinions.  A couple of people have already, in private conversation,
raised some concerns that were not identified in the discussion at the
meeting, which I report below.  We would like to get this issue settled as
soon as possible, since this is the only thing holding up the publication
of the updated Proposed Standard IPv6 spec (the version we expect to advance
to Draft Standard), so let's see if we can come to a decision before the ID
deadline at the end of next week (hoping there isn't any conflict between
"thoughtful analysis" and "let's decide quickly" :-).

The reason I would like to increase the minimum MTU is that there are some
applications for which Path MTU Discovery just won't work very well,

Re: [dns-operations] UDP fragmentation while not needed/wanted DS www.veilingzaalmelase.be

2021-03-25 Thread Paul Vixie 
On Wed, Mar 24, 2021 at 11:25:48PM +0100, Florian Weimer wrote:
> > ...
> 
> Proactive fragmentation irrespective of path MTU is required for
> stateless IPv6 UDP services.  Unlike IPv4, the network does not
> fragment packets.  So a UDP service has to conservatively fragment
> around 1200 or so bytes (to account for tunnel overhead).  ...

1280 subtracts several hundred bytes from 1500 to allow for tunnel
overhead. 1232 subtracts dozens more to allow for IP and UDP headers
and options.

please, nobody, subtract even more. if everyone subtracts a fudge
factor, forever, we'll eventually run out of payload space, or worse,
go negative.

-- 
Paul Vixie
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] UDP fragmentation while not needed/wanted DS www.veilingzaalmelase.be

2021-03-24 Thread Thor Spruyt 


- On Mar 24, 2021, at 8:12 PM, Viktor Dukhovni ietf-d...@dukhovni.org wrote:

> No.  The server *did* respond with 1 UDP packet, which got fragmented at
> the *IP* layer, into two IPv6 packets, presumably because the IPv6 MTU
> was set to somewhere around 1280.
> 
>> It is also strange that the first fragment has a size of 1232 ...
> 
> Well, that shows 1232 bytes of IP payload, including the 8 byte UDP
> header.  Thus a total of 1298 bytes.  It would perhaps be interesting to
> know how an actual 1232 byte UDP response would be handled from the same
> server.  Would it still be fragmented, or would it generate a single,
> slightly larger first packet.

Ok, that makes sense.
Fragmented response starts from requests with buffer size 1290 apparently.

Shouldn't this server use an edns buffer size of 1289 to avoid fragmentation ?

--
Thor
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] UDP fragmentation while not needed/wanted DS www.veilingzaalmelase.be

2021-03-24 Thread Florian Weimer 
* Thor Spruyt:

> Packets:
>
> $ sudo tcpdump -nn -p host 2a02:348:a1:bd32::1
> 19:33:04.426128 IP6 2a02::::1.60034 > 2a02:348:a1:bd32::1.53: 10024 
> [1au] DS? www.veilingzaalmelase.be. (53)
> 19:33:04.434834 IP6 2a02:348:a1:bd32::1 > 2a02::::1: frag (0|1232) 53 
> > 60034: 10024*- 0/4/1 (1224)
> 19:33:04.434846 IP6 2a02:348:a1:bd32::1 > 2a02::::1: frag (1232|66)
>
> So the server responds with 2 fragments, while there should be no
> reason for this.

Proactive fragmentation irrespective of path MTU is required for
stateless IPv6 UDP services.  Unlike IPv4, the network does not
fragment packets.  So a UDP service has to conservatively fragment
around 1200 or so bytes (to account for tunnel overhead).  Or perhaps
send a TC response instead, and avoid fragmentation altogether.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] UDP fragmentation while not needed/wanted DS www.veilingzaalmelase.be

2021-03-24 Thread Viktor Dukhovni 
On Wed, Mar 24, 2021 at 07:51:53PM +0100, Thor Spruyt wrote:

> DNS server @2a02:348:a1:bd32::1 seems to behave strangly.

[ Looks normal to me... ]

> $ dig -t DS www.veilingzaalmelase.be @2a02:348:a1:bd32::1 +edns=0 
> +bufsize=1452 +norecurse +dnssec
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> [...]
> ;; SERVER: 2a02:348:a1:bd32::1#53(2a02:348:a1:bd32::1)
> ;; MSG SIZE  rcvd: 1290
> 
> Packets:
> 
> $ sudo tcpdump -nn -p host 2a02:348:a1:bd32::1
> 19:33:04.426128 IP6 2a02::::1.60034 > 2a02:348:a1:bd32::1.53: 10024 
> [1au] DS? www.veilingzaalmelase.be. (53)
> 19:33:04.434834 IP6 2a02:348:a1:bd32::1 > 2a02::::1: frag (0|1232) 53 
> > 60034: 10024*- 0/4/1 (1224)
> 19:33:04.434846 IP6 2a02:348:a1:bd32::1 > 2a02::::1: frag (1232|66)
> 
> So the server responds with 2 fragments, while there should be no reason for 
> this.
> It advertises a buffer size of 4096 in the response, so the response fits in 
> 1 udp packet.
> Is my conclusion correct ?

No.  The server *did* respond with 1 UDP packet, which got fragmented at
the *IP* layer, into two IPv6 packets, presumably because the IPv6 MTU
was set to somewhere around 1280.

> It is also strange that the first fragment has a size of 1232 ...

Well, that shows 1232 bytes of IP payload, including the 8 byte UDP
header.  Thus a total of 1298 bytes.  It would perhaps be interesting to
know how an actual 1232 byte UDP response would be handled from the same
server.  Would it still be fragmented, or would it generate a single,
slightly larger first packet.

-- 
VIktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] UDP fragmentation while not needed/wanted DS www.veilingzaalmelase.be

2021-03-24 Thread Thor Spruyt 
Hi,

DNS server @2a02:348:a1:bd32::1 seems to behave strangly.

$ dig -t DS www.veilingzaalmelase.be @2a02:348:a1:bd32::1 +edns=0 +bufsize=1452 
+norecurse +dnssec

; <<>> DiG 9.11.4 <<>> -t DS www.veilingzaalmelase.be @2a02:348:a1:bd32::1 
+edns=0 +bufsize=1452 +norecurse +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10024
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.veilingzaalmelase.be.  IN  DS

;; AUTHORITY SECTION:
veilingzaalmelase.be.   7200IN  SOA ns1.mijndnsserver.nl. 
hostmaster.veilingzaalmelase.be. 2021031001 28800 7200 2419200 86400
veilingzaalmelase.be.   7200IN  RRSIG   SOA 8 2 7200 20210409093004 
20210310093004 35055 veilingzaalmelase.be. 
Lxfkk00qbjQhrXql1xBf7D/0lR3O8NfWIf599kKstRSmVX0OT3L+JJeb 
Z4pcOuVCZbU7E938/p6krnQ1k68yPxMk+mGBV5y1fAF5aSX3cAXLQX 
z1nTwMS0jXNk0JEtak1CyGbIeyP3x0HDciewftW140khPjIh3rSA4tk+ 
X+GPCwg+G7zPagZOisLnTt+LFMTpfCDr0wlCPA+b8Ae778r7ry4KpPSx 
WbS1xz8NESasYt+H2qwq+MYVLjTA0jtIxztbAZ0WU1SrkEBU3CQtQ4 
MndVpXNovbAqRy4XNUrw2yZ8j56mb1Lm6twc3mO4jz+LWMr2X6NDVfoM 
dknn5k0CJHFhXGoO1TlATAs15IPBjsZXMRaIxZCopjEphpE40VP31sea 
v8miQDhvbM+Kr49ZaHCo61qDbcaznHHVYQeTVGnkVnhYs6QJfjwFo7+I 
8R1JHKF8v+qjcGLHKx3z0k6NPNqNoZaE3+nitKBltEj+L9wQ4HzHvF 
TTDiGv4oUITo8pVi3eceZIG9jYcx91obQgH02pNNiz0I+jnyQ27CLm1h 
2Ei3lcIhK3xfjB6NVVnkKhHt0eHUC0QiQLEGXWfFZRV5glkpxaIikEIp 
26ldVD8sr6z2JOoHfmaMG2x3QPel8Gc8YJpeoTCX7yw7uBPN2Rnq1y vLXVSGHLrN0=
www.veilingzaalmelase.be. 86400 IN  NSECveilingzaalmelase.be. A RRSIG 
NSEC
www.veilingzaalmelase.be. 86400 IN  RRSIG   NSEC 8 3 86400 20210409093004 
20210310093004 35055 veilingzaalmelase.be. 
EIZCmD06nt9u2S6VHA+6J6o9IkSFNJRypDJ4SgEauyNRw/7ButbLqZrH 
3nYJlqkt95NxCjifg36k60oCK0dI5Zp56wQVQU50au5FrlMBIfidOO 
DYt5u++iQ18QdiW9N8Lc0i0y3PWQKVGcEZLGrroOlc7nw1TX3oE9VOme 
WziFpdjVFYn+qEXNp8vHNyuKMwtIFDREHobU2wffClp//B0olWLrDUzi 
JClgxV+XZH8LawO2QCBsV9Ze2iJOkKPeUzcNXumQ3E3Tr0xMB6fAat 
xgAOzNN3dOOA+g4gYqzUfLtk8n4wHgP8IAAxqYn1e2blAlssgT8rMltR 
8ZPQDcXLgexPj0aCe8rvUQhcHXQ7CyE/RuFt6uVOfrCLBv2USBmIn/OU 
RLMdoLLx+at8O+oKMjoq5lqh5SBdx0hygHehsVY7hXl+xSPitz6AUg9s 
tdTdGfF1FKekIk12Bg4DE+o69/7AewUCKCGQLz2+4aA7HjmszdteF8 
GhE1QwgrD4MRAtMmz559q76UJ3WNp/FV8gU7KpXU9vJUuo3eCo9BFahi 
eyc39mBwwbIJSp02MizwnOfpGAUBzFe2NutuOYYrY8YozNvRJpWQkP1P 
Lm421cfgdhhSToZu966HmOaW/Wlg2lEofavdmT2V4CMMzFMGzyZOEe Zico4VaMVOM=

;; Query time: 8 msec
;; SERVER: 2a02:348:a1:bd32::1#53(2a02:348:a1:bd32::1)
;; WHEN: Wed Mar 24 19:33:04 CET 2021
;; MSG SIZE  rcvd: 1290

Packets:

$ sudo tcpdump -nn -p host 2a02:348:a1:bd32::1
19:33:04.426128 IP6 2a02::::1.60034 > 2a02:348:a1:bd32::1.53: 10024 
[1au] DS? www.veilingzaalmelase.be. (53)
19:33:04.434834 IP6 2a02:348:a1:bd32::1 > 2a02::::1: frag (0|1232) 53 > 
60034: 10024*- 0/4/1 (1224)
19:33:04.434846 IP6 2a02:348:a1:bd32::1 > 2a02::::1: frag (1232|66)

So the server responds with 2 fragments, while there should be no reason for 
this.
It advertises a buffer size of 4096 in the response, so the response fits in 1 
udp packet.
Is my conclusion correct ?

It is also strange that the first fragment has a size of 1232 ...

Thanks for any feedback,
Thor
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations