Subject: Re: edns0-bis submitted

From: Kenji Rikitake <[email-masked]>
Date: Mon, 3 Mar 2008 12:13:37 +0900

In the message <[email-masked]>
dated Thu, Feb 28, 2008 at 10:21:22AM +1100,
Mark Andrews <[email-masked]> writes:
> 	The only transitions allowed for packet loss should be.
> 
> 		EDNS -> EDNS @512 (for broken firewalls)
> 
> 	If a firewall is not going to allow EDNS though then it should be
> 	responding to the query with FORMERR.

Just curious: Mark, what do you think about the following case?

* a resolver send a UDP request to a server for a large RR with EDNS

* the server responds with the answer in a large UDP datagram which
fragments into two or more pieces of IP packets

* unfortunately the resolver is behind a middlebox (firewall, router,
whatever) and could not get the answer due to the blockage of the
DF-bit-set IP packets

In this case, I think falling back to EDNS @IP-MTU-aware-value
(presumably 1500 for IPv4, 1200 or so for IPv6) is worth trying, though
the state management will get more complicated because it's adding
another state between EDNS and "EDNS @512".

I'd like to see the pros and cons.

I also feel, however, to accept the conservative approach of

> 	I'm tempted to say don't do any fallbacks on packet loss and
> 	just treat "packet loss" as "packet loss".

because assuming the reason of a packet loss without a proof often
backfires (e.g., a "real" packet loss may change the
maximum-length-limit state of EDNS).

Kenji Rikitake

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Mark Andrews <[email-masked]>
Date: Mon, 03 Mar 2008 14:45:14 +1100

> whatever) and could not get the answer due to the blockage of the

	Any nameserver that sets DF for IPv4 UDP resonses is broken.
	For IPv6 network MTU fragmentation should be being performed.
 
> I'd like to see the pros and cons.

	It's not worth trying to detect.

	I actually sit behind a NAT which can't handle out of order
	fragments.  I just configure the nameserver to advertise a
	EDNS UDP size of 1460.

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

---

From: Kenji Rikitake <[email-masked]>
Date: Thu, 6 Mar 2008 11:24:07 +0900

In the message <[email-masked]>
dated Mon, Mar 03, 2008 at 02:44:51PM +1100,
> 	Any nameserver that sets DF for IPv4 UDP resonses is broken.

Does this sentence implicate that for a large-size answer (such as that
for DNSSEC) exceeding the IPv4 MTU should (or even must) be sent by TCP?

> 	For IPv6 network MTU fragmentation should be being performed.

I understand that IPv6 has its own end-to-end fragmentation header and
routers do not fragment IPv6 packets, so that this is a negotiable issue
between the hosts.   Correct me if I'm wrong.

> [Rikitake writes:]

OK, I understand your idea.

> 	fragments.  I just configure the nameserver to advertise a

Is it by the "maxudp" option on BIND 9.4 and later?

Kenji Rikitake

---

From: Mark Andrews <[email-masked]>
Date: Thu, 06 Mar 2008 13:58:23 +1100

> Is it by the "maxudp" option on BIND 9.4 and later?

	edns-udp-size as it's a problem with the inbound path.

---

From: Joe Abley <[email-masked]>
Date: Thu, 6 Mar 2008 12:48:34 -0500

> for DNSSEC) exceeding the IPv4 MTU should (or even must) be sent by  

I read it as saying that large-size answers sent over UDP should be  
sent with DF=0 (i.e. such that fragmentation is possible).

Joe

---

From: Mark Andrews <[email-masked]>
Date: Fri, 07 Mar 2008 10:23:22 +1100

> sent with DF=0 (i.e. such that fragmentation is possible).

	Correct.

	DF works reasonably well with TCP.  DF does not work well
	with many UDP applications which includes DNS.

	IPv6 a setsockopt() to force network MTU to be used.  A DNS
	server should be setting it.

                if (pf == AF_INET6) {
                        (void)setsockopt(sock->fd, IPPROTO_IPV6,
                                         IPV6_USE_MIN_MTU,
                                         (void *)&on, sizeof(on));
                }

	Network MTU does not make sense for IPv4.

	Mark

---

From: Kenji Rikitake <[email-masked]>
Date: Sat, 8 Mar 2008 08:24:19 +0900

I 100% agree with Joe and Mark's answers on setting DF when sending TCP
(and NOT in UDP).  My wording of DF might have caused misunderstanding.
My thanks to Joe and Mark.

Let me rephrase.

I am thinking about dealing with a middie box dropping IP fragments
(i.e., the second or later parts of fragmented IP datagrams), and
consequently blocking UDP with multiple IP fragments.   If this
middlebox is set on the resolver's side, the resolver's query will reach
to the server without problem, but the server's answer will be blocked
by the middlebox, so the transaction will fail until the client decides
to fall back on TCP.

I understand that Mark wrote the above case is not worth to detect.
Should the resolver just wait and see?

Kenji Rikitake

---

From: Mark Andrews <[email-masked]>
Date: Sat, 08 Mar 2008 11:10:44 +1100

> consequently blocking UDP with multiple IP fragments.

	It the packet is fragmented it will almost certainly be
	bigger than 512 octets originally.  This is indistingishable
	from a firewall which drops unfragmented UDP responses
	bigger than 512 octets.  Falling back to 512 octet EDNS
	packets handles both cases.

	Trying to find the largest packet size that works is not
	worth the effort.

	Mark