Subject: [DNSOP] DNS, fragmentation, and IPv6 extension headers

From: Fernando Gont <[email-masked]>
Date: Mon, 28 Jul 2014 08:24:59 -0400

Folks,

(Apologies if this has been debated to death already).

At the last IEPG meeting we presented some results regarding the
filtering of packets that employ IPv6 extension headers (please see:
<http://www.iepg.org/2014-07-20-ietf90/iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0.pdf>).
The packet drop rates range from 10% to over 50%, depending on the
dataset (FWIW, these packets drops have nothing to do with DNS-specific
packet-drops caused by sloppy firewalls or the like).

This essentially raises the question of "What's the plan for
transporting DNS queries/responses in IPv6?"

At different venues (including the IETF), I've received/listened_to
different opinions. Quite a few folks usually argue "oh, that's simple:
we'll use TCP", while others tend to argue that "one should be careful
when thinking about relying on TCP for DNS queries/responses" (e.g. see
<http://www.iepg.org/2013-11-ietf88/2013-11-Time-Value-DNS.pdf>).

While this issue/question may be currently masqueraded by the fact that
we still have IPv4, I wonder what's "the plan" for the IPv6 case (at
some point, we'll have to rely on whatever such plan is).

If the answer is "fall-back to TCP if UDP doesn't work", my next
question would be "does popular DNS server software implement
mitigations for TCP-based attacks?" (zero-windows, FIN-WAIT-X flooding,
etc.)

Thoughts?

Thanks!
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 28 Jul 2014 14:42:40 +0200

On Mon, Jul 28, 2014 at 08:24:59AM -0400,
 Fernando Gont <[email-masked]> wrote 
 a message of 43 lines which said:

> dataset 

Annoying.

> transporting DNS queries/responses in IPv6?"

Why do we need a plan? We serve DNS over IPv6 for now ten years and it
works (not "I think it works" but "it is monitored so I'm certain it
works"). The problem with extension headers is annoying but, today,
they are not used (of course, it's partially a chicken and egg
problem, similar to the problm of IPv4 options: they are not
transported reliably so people don't use them, so there is no
motivation to make them reliable, etc).

> Quite a few folks usually argue "oh, that's simple: we'll use TCP",

There are many good reasons to use TCP but, in that case, I do not see
why we need it. First, IPv6 users typically don't use extension
headers and, second, if the problem is in IP, why would changing from
UDP to TCP work?

> does popular DNS server software implement mitigations for TCP-based
> attacks?" (zero-windows, FIN-WAIT-X flooding, etc.)

Is it something that should be done in every application, and not in
TCP itself?

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 28 Jul 2014 08:48:55 -0400

> headers and, second, if the problem is in IP, why would changing from

Because the big issue is fragments:  The IPv4 net decreed “Fragment’s don’t really work”.  The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”.

The solution is to detect and fallback on EDNS0 MTU to retry at 1400B first (rather than directly down to 512b), and properly handle truncation.  But you do that, and things do work.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 28 Jul 2014 08:52:06 -0400

Hi, Stephane,

Thanks so much for your prompt response. Comments in-line...

On 07/28/2014 08:42 AM, Stephane Bortzmeyer wrote:
> works"). 

Just curious: How do you check that the UDP-based DNS replies actually
get to the node that sent the query?

> The problem with extension headers is annoying but, today,

Agreed.

> headers and,

How do you send responses larger than , say, ~1500 bytes without
fragmentation?

> second, if the problem is in IP, why would changing from
> UDP to TCP work?

Because TCP can avoid fragmentation.

> Is it something that should be done in every application, and not in

There are some mitigations that can be implemented in the kernel, while
others make more sense to implement at the app (yes, it'd be ugly to
duplicate code in multiple apps, but....)

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 28 Jul 2014 09:17:07 -0400

On 07/28/2014 08:48 AM, Nicholas Weaver wrote:
>> 
>> There are many good reasons to use TCP but, in that case, I do not
>> see why we need it. First, IPv6 users typically don't use
>> extension headers and, second, if the problem is in IP, why would
>> changing from UDP to TCP work?
> 
> Because the big issue is fragments:  The IPv4 net decreed “Fragment’s
> don’t really work”.  The IPv6 net has decreed “No, really, FRAGMENTS
> DO NOT WORK”.
> 
> The solution is to detect and fallback on EDNS0 MTU to retry at 1400B
> first (rather than directly down to 512b), and properly handle
> truncation.  But you do that, and things do work.

Is this standard behavior, or rather an implementation thing? (ie.., t
what extent may one expect this mechanism to be widely implemented?)

Thanks,

---

From: David Conrad <[email-masked]>
Date: Mon, 28 Jul 2014 07:05:50 -0700

Hi,

On Jul 28, 2014, at 5:48 AM, Nicholas Weaver <[email-masked]> wrote:
> The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”.

This could be a bit of an issue when the DNSSEC root key is rolled. Could someone point me to a writeup and/or data as to how we know the above decree? (I'm not disagreeing, I just haven't really been following this for a while).

> The solution is to detect and fallback on EDNS0 MTU to retry at 1400B first (rather than directly down to 512b), and properly handle truncation.  

How many shipping resolvers actually do this?

Regards,
-drc

---

From: Tony Finch <[email-masked]>
Date: Mon, 28 Jul 2014 15:25:23 +0100

David Conrad <[email-masked]> wrote:
> > truncation.

I don't know what Unbound does.

BIND 9.9 and earlier have three states in the default configuration: EDNS
4096, EDNS 512, and no-EDNS. It would start at the top and work down in
response to failures. There is a knob to adjust the starting buffer size.

BIND 9.10 changes the first state to do variable-size probing: it will try
512, 1232, 1432, and 4096, starting at the bottom and working up and down
depending on what works. The middle numbers come from the minimum IPv6 MTU
minus space for headers, and the ethernet MTU minus v4 and v6 headers to
allow for tunneling. The (fixed) EDNS 512 and no-EDNS states remain.

Unfortunately starting with a UDP size of 512 provokes masses of horrible
truncation bugs in authority servers which causes more breakage (in my
experience) than fragmentation does. It is particularly unfortunate when
BIND decides to send no-EDNS queries for DNSSEC zones :-( I've hacked my
BIND to drop the fixed EDNS 512 state and to start the variable-size
probing at 1232 which seems to work a lot better.

http://dnssec-deployment.org/pipermail/dnssec-deployment/2014-July/007080.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Cyclonic 4 or 5, becoming northerly 5 to 7 in north. Slight or
moderate, becoming moderate or rough in north. Fog patches at first in east.
Moderate or good, occasionally very poor at first in east.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 28 Jul 2014 17:32:38 +0200

On Mon, Jul 28, 2014 at 08:52:06AM -0400,
 Fernando Gont <[email-masked]> wrote 
 a message of 60 lines which said:

> Just curious: How do you check that the UDP-based DNS replies
> actually get to the node that sent the query?

1) Because, otherwise, we would see retransmissions by the client.

2) Because we tested from various places (see a trace attached).

3) Because nobody complained (the weakest argument...)

> How do you send responses larger than , say, ~1500 bytes without

I really did not understand your point at all: when you said
"extension headers", I did not think of fragmentation but of
Destination Options, things like that. I thought that your point was
that "extension headers do not work".  So, your point is actually that
"fragmentation does not work"? 

If so, there are other solutions such as decreasing the buffer size
of the server, under the MTU (.com name servers do it). This also
helps against amplification attacks.

% dig -6 @d.ext.nic.fr ANY fr

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -6 @d.ext.nic.fr ANY fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48851
;; flags: qr aa rd; QUERY: 1, ANSWER: 20, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;fr.			IN ANY

;; ANSWER SECTION:
fr.			172800 IN SOA nsmaster.nic.fr. hostmaster.nic.fr. (
				2222549502 ; serial
				3600       ; refresh (1 hour)
				1800       ; retry (30 minutes)
				3600000    ; expire (5 weeks 6 days 16 hours)
				5400       ; minimum (1 hour 30 minutes)
				)
fr.			0 IN RRSIG NSEC3PARAM 8 1 0 20140914071832 (
				20140716071832 47116 fr.
				frc2CPwNg8uhi79qD7HRRuLHHc9tBIUebEOOHxRqnq0H
				v5hYZCxahoZ2ZyO4oIf4uqjAIrB3IF8YUdebujJkhYiZ
				v0vcS5eHrnZRbWhn0tZEdxBYPaD51zGNrKENrQhdApbR
				iWUVL9ZjkfOPKAHvtgvSlQlCUhDamxpvOkmeAFM= )
fr.			0 IN NSEC3PARAM	1 0 1 33629585
fr.			172800 IN RRSIG	DNSKEY 8 1 172800 20140914071832 (
				20140716071832 20122 fr.
				V47KfKfpCkwh0oC13es9Tr/dqNrG63SRLyhWYdwDWTXH
				+wRMQNrIXLDVWRk7ZqwFadYABP2ler5PTMQ7bM0sjMAa
				NmPou3Pj+xOr7mT9MAvIXzVNKehETh4dN9MtlTzLLAmO
				wCv9yBxby0197w+wDZYjkTTBMzVgXuUkj5ymWwENQmIU
				F9fs6RuTRY9ZNweczjWMQmQDwL9FBgLOHtO3o7fmYMOR
				3oSUlFpXvg1U4ou8z28euz7+hoX4N4rKClSzwzdkQSWj
				es2nI+DB/QqhXAnkL0UxH3sYd953ejbzxAv8MtZG1up7
				nNZb117VRmnL+eMe6AG0fuE/OSFaUBv6xw== )
fr.			172800 IN RRSIG	DNSKEY 8 1 172800 20140914071832 (
				20140716071832 47116 fr.
				e1Yka0xOaumQgPgyvwhjlYxVTre+m1b9KmM1jvCyT0HV
				g80llLLzZVq8Ndj/iR+UXH7Ba2VxMZ47WhzdnQ67s/QR
				cVcXDNILHdurIurPiIpqZuixI3s+nylWYRhUpzaznIKH
				BznIXCgqIOVFnVowFaBMUvnMiSW2/yvv2jiPtxg= )
fr.			172800 IN DNSKEY 257 3 8 (
				AwEAAa2sILZ4XD/QqobSU6NKFRzXwBV3OpHn21LWcGgz
				84+g9emlizfjWv51lwsERFSgK+AqmKpYegptTY/PQJrg
				rCAvOEoQBZi3WvnjZFmMvqnZpeFlymIAiRgfAsHdF+Nx
				o/5eItUoJv3YjquFXcSQXpZJz5w6S/I2n+7W44GuWv3A
				iNuVJNG6qsy7sEZRc2SpOgM8RPtAQpwcA+YHPuMdIdba
				O7BEzlnmUN6bOSguVRz1SQR6+5xcLciZ264+whSTKtOy
				fjLvrrbTyZtXu8s++5xJkDQ8U/yUpBbtNaUVtlKeLFTe
				Ad8K6xd3ggAR2qLvUMp2XZYBBKF7Lfwn6fcEq6E=
				) ; key id = 20122
fr.			172800 IN DNSKEY 256 3 8 (
				AwEAAbSTCfGdqPiLkqwzc1MTj0lpXSTS0yKfhgeRXeaO
				VmDCzSJ2Xo4pWb0ByV6OA9qefTriLiwvXCiPnh3l9rEd
				T6qBo5AqnMaFhM723DebNr1BVLSZcZP5hadMLTMFexLH
				+ysquEbPgszN5ZqXTLtcuA9B0wmuX8a/66qq6xUIDq51
				) ; key id = 63211
fr.			172800 IN DNSKEY 256 3 8 (
				AwEAAaxxBitg7Axk/Ra7HliE/AFvaGqZ49qMpQDPB/lo
				Ba2/VuswG3IrDqnWzkV/Gdex6MoIFEf9ty6yfdPhwdOh
				T9sr8auuN/BxMhB0pd7ZkZYYaVzDxN9Zl0k/90BmCNuh
				9+YyoHpWT49Qz+xInQXKIvkgFAeEDTlqcMf75MgSLJBf
				) ; key id = 11353
fr.			172800 IN DNSKEY 256 3 8 (
				AwEAAZoFNhNbJMFFKT757RrCsiJWRSDTnhD+F0rsMdWq
				kSpWxKdCtfxdA8zy2fzKTLYQThN++PLSjYVJx7SazJAM
				xIvU9N+IfvWokYmJC7amKrVPQfcZkdCbiN4b//aMmokU
				PV3iNAyzJR0tpoDIve7rTu0OTGtRhveJPuQg5zkG9VFh
				) ; key id = 47116
fr.			172800 IN RRSIG	NAPTR 8 1 172800 20140914071832 (
				20140716071832 47116 fr.
				KUR7+TrvP0Lpx9yec9qHyJt2BSuKwe9TrTn2yNxqJodu
				0UQzXJlVZ461kVWudqxmIsjnuz1oHx/rAb3GSJJfa1dL
				07GduJBJu840+FPeQNDkirTnHX18qzXLi/Vq41cprHX/
				2Ze5pnUfeYX9zRv+2mGXKZ8MZne14H+72x7iqQ8= )
fr.			172800 IN NAPTR	100 10 "s" "DCHK1:iris.lwz" "" _iris-lwz._udp.fr.
fr.			172800 IN RRSIG	TXT 8 1 172800 20140926152016 (
				20140728142016 47116 fr.
				G+VOyC/P62WeBZ6gx2RstYNfsaPgF73tR3gOWPX/PAlS
				NjUvxe+ZKH7W58l00+m3LuHrijp0THw4TXddm6IFOFs8
				iabNXxqcgnHCgRD3+NoPWX86C7L/DOvAefZFNhc7aL5k
				OTrkaXx9gJhXroq/+UHVsICZase+0twH9JncT/I= )
fr.			172800 IN TXT "89 RRs processed [28/07/2014 17H20:13]"
fr.			172800 IN RRSIG	NS 8 1 172800 20140914071832 (
				20140716071832 47116 fr.
				CY/u5gHzviK94mKIt5dx+qIFjjt4jWzPfVo2ldTFchZI
				BaSBniwsqInCI5DQBfEinI1QkNGTfxyad8aOkvbFgDWv
				UT8hFJ3UuM3846xXl7CH5ssjivUQklb7h9U8KYAixuNM
				+cy9PBLm4Wr997oqx68FeaBUNOTEVtyZfySDuLI= )
fr.			172800 IN NS d.ext.nic.fr.
fr.			172800 IN NS f.ext.nic.fr.
fr.			172800 IN NS g.ext.nic.fr.
fr.			172800 IN NS e.ext.nic.fr.
fr.			172800 IN NS d.nic.fr.
fr.			172800 IN RRSIG	SOA 8 1 172800 20140926152016 (
				20140728142016 47116 fr.
				WIYAH+TZ+WRBp3g/wuNCvPME46Zc3j9Sv55pYTflHUbu
				p/MDgdtVn3ps4C8w9WIj6fTwwi/SqQBGBNJMgHZ8BVqg
				n0SZPdxicRPiit7fOYZ+tP640TyNygM8ejRhNReBY0ip
				+xKllb0zN8XxQU3P3T6PjhtraxorpgpzI1nKFh4= )

;; ADDITIONAL SECTION:
_iris-lwz._udp.fr.	172800 IN RRSIG	SRV 8 3 172800 20140914071832 (
				20140716071832 47116 fr.
				K+3NGWDs9ucdp6K/cXJY3CNDGJJ5MdIvIGccj7rrWdbY
				lTU2CBaQ0vj2FUsmQrHagDPg1LdfSuE5gi5dYP8fG1YO
				MFG8KjujJ5Pbata0p1q2Hpbsakr/I4JKQKrAwND/ceOG
				VK8987LCN7RQvdAxiFegXf/oxK+XqUAy6AlhQW4= )
_iris-lwz._udp.fr.	172800 IN SRV 0 0 715 dchk.nic.fr.

;; Query time: 72 msec
;; SERVER: 2001:500:2e::2#53(2001:500:2e::2)
;; WHEN: Mon Jul 28 17:30:27 2014
;; MSG SIZE  rcvd: 2475

---

From: Casey Deccio <[email-masked]>
Date: Mon, 28 Jul 2014 12:35:20 -0400

On Mon, Jul 28, 2014 at 10:05 AM, David Conrad <[email-masked]> wrote:

> This could be a bit of an issue when the DNSSEC root key is rolled. Could
> someone point me to a writeup and/or data as to how we know the above
> decree? (I'm not disagreeing, I just haven't really been following this for
> a while).
>
>
As one data point, the current top DNSKEY response sizes for TLDs (all
using UDP) are:

xn--fiq228c5hs. 1669
xn--6frz82g. 1657
xn--3ds443g. 1657
rich. 1629
post. 1629
pink. 1629
info. 1629
blue. 1629
asia. 1629
red. 1625
org. 1625
onl. 1625
kim. 1625
sc. 1621
pr. 1621
mn. 1621
me. 1621
lc. 1621
in. 1621
gi. 1621
bz. 1621
ag. 1621
bg. 1567
xn--fiqz9s. 1505
xn--fiqs8s. 1505
am. 1479
cn. 1473
dk. 1459

All of the above result in IPv6 fragmentation, and nearly all also result
in IPv4 fragmentation---both assuming a 1500-byte PMTU and a resolver using
an EDNS UDP payload value sufficient to hold the entire payload.  This list
has changed over time, through key rollovers and such.

Has there been empirical or anecdotal evidence to suggest that DNSSEC
validation has been broken for these TLDs for some population?

I'm not suggesting that fragmentation is pretty, and I'm quite aware of
path problems with fragmentation (some of them having been worked around by
resolver implementations and configurations, as Tony indicated).

Casey

---

From: David Conrad <[email-masked]>
Date: Mon, 28 Jul 2014 15:41:31 -0700

Oops. Mailer problems and obviously  misdirected... (intended to be sent to someone with whom I worked on the name collision stuff :))

Sincere apologies.

Regards,
-drc

On Jul 28, 2014, at 3:34 PM, Casey Deccio <[email-masked]> wrote:
> I have to admit I have struggled to not respond to Casey (who works for VRSN) with:
> 
> "Well, there wasn't much empirical evidence that name collisions could cause problems, yet..."
> 
> :)
> 
> Regards,
> -drc
> 
> As one data point, the current top DNSKEY response sizes for TLDs (all using UDP) are:
> 
> xn--fiq228c5hs. 1669
> xn--6frz82g. 1657
> xn--3ds443g. 1657
> rich. 1629
> post. 1629
> pink. 1629
> info. 1629
> blue. 1629
> asia. 1629
> red. 1625
> org. 1625
> onl. 1625
> kim. 1625
> sc. 1621
> pr. 1621
> mn. 1621
> me. 1621
> lc. 1621
> in. 1621
> gi. 1621
> bz. 1621
> ag. 1621
> bg. 1567
> xn--fiqz9s. 1505
> xn--fiqs8s. 1505
> am. 1479
> cn. 1473
> dk. 1459
> 
> All of the above result in IPv6 fragmentation, and nearly all also result in IPv4 fragmentation---both assuming a 1500-byte PMTU and a resolver using an EDNS UDP payload value sufficient to hold the entire payload.  This list has changed over time, through key rollovers and such.
> 
> Has there been empirical or anecdotal evidence to suggest that DNSSEC validation has been broken for these TLDs for some population?
> 
> I'm not suggesting that fragmentation is pretty, and I'm quite aware of path problems with fragmentation (some of them having been worked around by resolver implementations and configurations, as Tony indicated).
> 
> Casey

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Jul 2014 14:45:14 +0900

Tony Finch wrote:

> BIND 9.10 changes the first state to do variable-size probing: it
> will try 512, 1232, 1432, and 4096, starting at the bottom and
> working up and down depending on what works. The middle numbers come
> from the minimum IPv6 MTU minus space for headers, and the ethernet
> MTU minus v4 and v6 headers to allow for tunneling.

Your assumption is that there is no extension headers exist.

But, the problem of current IPv6 specification allows for very
long extension headers (more than 60KB is allowed), some of
which are automatically inserted not under transport/application
layer control.

So, as Fernando Gont wrote:

> While this issue/question may be currently masqueraded by the fact
> that we still have IPv4, I wonder what's "the plan" for the IPv6 case
> (at some point, we'll have to rely on whatever such plan is).

The first thing to do is to obsolete extension headers and
related gotcha in IPv6 specification.

Even a fragmentation header has annoying requirement.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Jul 2014 15:08:27 +0900

David Conrad wrote:

> This could be a bit of an issue when the DNSSEC root key is rolled.

It is not, if separate RR types are used for different set of
authentication algorithms and, during roll over, separate RR
types are used for the current most and the second (and third
or more, if necessary) current information, as I mentioned
decades ago.

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Jul 2014 16:20:34 +1000

> which are automatically inserted not under transport/application

So?  Fragmented packets *do* get through the network.  Where they
don't it slows up DNS resolution and the firewall usually gets fixed
to allow fragments.

The break points above only come into play when there are firewalls
that block fragmented traffic.  One can always add more break points
in the future.

As for 60K headers, I'll worry about them when they start happening.

-- 
Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 29 Jul 2014 10:59:46 +0200

Hi David,

On 07/28/2014 04:05 PM, David Conrad wrote:
> Could someone point me to a writeup and/or data as to how we know
> the above decree? (I'm not disagreeing, I just haven't really been
> following this for a while).
> 
>> The solution is to detect and fallback on EDNS0 MTU to retry at
>> 1400B first (rather than directly down to 512b), and properly
>> handle truncation.
> 

Unbound implements this.  Since version 1.4.19 (dec 2012) at sizes
1472 and 1232.  Earlier it also did this in version 1.4.14 (dec 2011)
at sizes of 1480 and 1260 (but those are slightly wrong and that could
cause issues if the 1480-response has a size 1472..1480).

The logic in these versions is: if there is a timeout on EDNS0-4096
then retry with the 1400 version.  Handle truncation with TCP.  Like
Nicholas suggests above.  There is more logic that eventually falls
back to non-EDNS (and the non-EDNS-ness is cached) but that is not
pertinent to your question.

Best regards,
   Wouter

---

From: Tony Finch <[email-masked]>
Date: Tue, 29 Jul 2014 10:45:25 +0100

W.C.A. Wijngaards <[email-masked]> wrote:
> 1472 and 1232.

Does anyone have useful data on the amount that sub-ethernet MTUs cause
problems? I am thinking particularly that tunnels are likely to break
fragmentation and a stack like UDP/IPv6/crypto/UDP/IPv6 is likely to have
128 bytes of header. I suppose the fallback to the IPv6 minimum MTU will
catch most of them.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber: Variable 4 but northerly 4 or 5 for a time in east, becoming
northwesterly 4 or 5 later. Slight or moderate. Showers then fair. Good.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 30 Jul 2014 08:04:37 +0900

> don't it slows up DNS resolution and the firewall usually gets fixed

Yes, hopefully within a decade or two, some firewall maybe
fixed. So?

> As for 60K headers, I'll worry about them when they start happening.

I know most of you have been short sighted to expect too
much in the future.

But, even today, how much, in your opinion, is the assured-to-be-
safe DNS message size over IPv6 with 1280B of MTU?

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Jul 2014 09:26:46 +1000

> Yes, hopefully within a decade or two, some firewall maybe

Actually the firewalls get fixed pretty quickly in most cases.

> safe DNS message size over IPv6 with 1280B of MTU?

Well we have space for around 700 bytes of additional header space
before EDNS@512 will fail due to fragments being dropped.  Now I'm
sure one could artificially consume those 700 bytes but for the
moment I'm not worried.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 31 Jul 2014 14:49:17 +0900

Mark Andrews wrote:

>>> So?  Fragmented packets *do* get through the network.  Where
>>> they don't it slows up DNS resolution and the firewall usually
>>> gets fixed to allow fragments.
>> 
>> Yes, hopefully within a decade or two, some firewall maybe fixed.
>> So?
> 

If you are thinking of ideal world with relatively new firewalls,
maybe.

The problem is that, in the real world, there are a lot of
firewalls with maintenance period expired.

> sure one could artificially consume those 700 bytes but for the 

You haven't answered my question.

How much, in your opinion, is the assured-to-be-safe DNS message
size over IPv6 with 1280B of MTU?

> MTU minus v4 and v6 headers to allow for tunneling.

can not be made.

						Masataka Ohta

PS

It should be noted that my modest proposal to have some
(e.g. 256B) reasonable limit on the extension header
length with an explanation that applications such as DNS
need some limit was formally rejected by IPv6 WG (in
Danvers meeting in 1995, IIRC) that you should expect
more.

IPv6 is produced by collective stupidity.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Jul 2014 22:58:46 -0700

i think there's a necessary and healthy tension between the installed
base and new technology. i would not like to see every new application
designed to run inside TCP/80, even though that's the only universal
wide area protocol. and we won't see any new application that requires a
forklift upgrade of the whole internet before it can be used -- no market.

in this case i think mark's approach is right, because it works better
for people who fix their firewalls, but it finds a way to work, no
matter what. this puts a little bit of pressure on middlebox makers who
mindlessly constrain future protocols.

sardonically, the reason i chose fragmentation for EDNS rather than a
new MD (More Data) bit in the flags and a new "fragment number N of M"
option in the OPT RR, is that i imagined getting EDNS deployed in less
than five years. now that it's been almost fifteen years and we're still
fiddling with it, i can see that i made the wrong choice in RFC 2671.

vixie

---

From: Mark Andrews <[email-masked]>
Date: Thu, 31 Jul 2014 16:13:18 +1000

> firewalls with maintenance period expired.

Well most of the one with DNS/UDP size limits have configuration
options to turn the check off.  For those that don't DNS and DNSSEC
will still operate through them

> size over IPv6 with 1280B of MTU?

If you have idiotic software adding idiotic amounts of headers it
will break both TCP and UDP and someone will then fix the problem.

> > MTU minus v4 and v6 headers to allow for tunneling.

The sizes were chosen to allow v4-in-v6 and v6-in-v4 to pass.  If
other headers become common we can add more break points.  The lower
bound will remain 512 bytes.

> Danvers meeting in 1995, IIRC) that you should expect

And 256B is better than 257B how?  People will still only add headers
if the resulting packet get through or they will come up with a
different solution. You don't need a fixed limit. You just need to
depend upon self interest prevailing.

> IPv6 is produced by collective stupidity.  -- Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871
4742                 INTERNET: [email-masked]