Re: [v6ops] PMTUD issue discussion

In message <2134F8430051B64F815C691A62D9831832D13130@XCH-BLV-504.nw.nos.boeing.com>, "Templin, Fred L" writes:
> Hi Mikael,
> 
> > -----Original Message-----
> > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]
> > Sent: Tuesday, September 09, 2014 8:08 AM
> > To: Templin, Fred L
> > Cc: Tom Perrine; v6ops@ietf.org
> > Subject: RE: [v6ops] PMTUD issue discussion
> > 
> > On Tue, 9 Sep 2014, Templin, Fred L wrote:
> > 
> > > This could be problematic when PMTUD is not functioning correctly. As a
> > > result, IMHO any end system that wants to try for packet sizes larger
> > > than 1500 really should be using RFC4821 (maybe even MUST?).
> > 
> > Well, even that might not solve it as there might be devices along the
> > path that re-assemble the packets (if they're fragmented) and then
> > fragment them again, which will break things anyway.
> 
> I think RFC4821 only applies to whole packets with DF=1 (i.e., where
> all IPv6 packets implicitly have DF=1), but I get your point. 
> 
> > But yes, supporting 4821 or PMTUD blackhole detection should definitely be
> > a requirement.
> 
> OK.
>  
> > One problem is that a lot of people don't even know that sending a 16k UDP
> > packet fragmented into a bunch of smaller fragments, is a perfectly valid
> > use of IP. They're so used to TCP and its MSS that this is all they've
> > seen.
> 
> Yes, isolated large UDP packets with DF=0 must be dealt with.

Actually there is plenty of fragmented UDP traffic.  Pick just about
any IPv6 DNSSEC aware recursive nameserver and you will almost
certainly see fragmented IPv6 UDP responses.  This traffic is only
increasing as more zones become signed pushing response size well
over 1500.

Below is from BIND 9.10 which tracks UDP response sizes.  Find a
busy resolver and you will find a lot more.  The EDNS field shows
timeouts at various EDNS UDP buffer sizes.  A timeout at a small
size is counted against larger sizes as well as named tries to
workout the DNS/UDP mtu which can be as low as 512 as some firewalls
"know" that DNS/UDP payloads "never" exceeded 512 bytes.

This nameserver is behind a HE tunnel so it also has to deal with
authorative nameservers that block PTB to them.  Named also forces
fragmentation at 1280 on all sockets if it can.  The savings for a
nameserver in sending bigger packets just aren't there.

[edns success/4096 timeout/1432 timeout/1232 timeout/512 timeout]

[rock:~/ports] marka% grep srtt /var/named/named_dump.db | grep udpsize | grep -v "udpsize 512" | grep :
;	2001:500:31::63 [srtt 119657] [flags 00806000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 965] [ttl 1230]
;	2001:500:2c::254 [srtt 214672] [flags 00806000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 1676] [ttl 1222]
;	2001:13c7:7002:3000::11 [srtt 242467] [flags 00806000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 513] [ttl 1229]
;	2001:500:60::30 [srtt 229183] [flags 00806000] [edns 4/0/0/0/0] [plain 0/0] [udpsize 1816] [ttl 1221]
;	2001:4f8:0:2::19 [srtt 82726] [flags 00806000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 1626] [ttl 1221]
;	2001:500:13::108 [srtt 115528] [flags 00806000] [edns 2/0/0/0/0] [plain 0/0] [udpsize 1991] [ttl 1229]
[rock:~/ports] marka% 

> Thanks - Fred
> fred.l.templin@boeing.com
>  
> > --
> > Mikael Abrahamsson    email: swmike@swm.pp.se
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org