Subject: Large EDNS0 buffer sizes and IPv6

From: Florian Weimer <[email-masked]>
Date: Mon, 04 Aug 2008 19:45:18 +0200

How do you make large EDNS0 buffer sizes work with IPv6?  I couldn't
find anything about that in the RFC or in the draft.

Unlike IPv4, IPv6 doesn't fragment in the core.  This means that the
source must perform path MTU discovery and fragment on its own.  This,
in turn, requires client-specific state, which is generally considered
a bad thing.

What am I missing?

Apparently, this was raised by Itojun at IETF48 back in 2000, but I
don't see how it was resolved.  Implementations with buffer sizes
greater than 1400 bytes seem to fragment according to the link MTU
they are connected to, and do not care about the path MTU.  (I haven't
got native IPv6, so it's hard for me to tell what's going on.)

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

--
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 04 Aug 2008 15:09:39 -0700

At Mon, 04 Aug 2008 15:07:48 -0700,
JINMEI Tatuya <[email-masked]> wrote:

> My understanding is that the name server is expected to set the
> IPV6_USE_MIN_MTU socket option (when available) for its AF_INET6 UDP
> sockets.  See RFC3542 for this option.  BIND9 does that; unbound also
> seems to do so according to a quick naive grep.

In this context I should have rather focused on authoritative
servers...for that matter, NSD also seems to do so according to a
quick naive grep.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 04 Aug 2008 15:07:48 -0700

At Mon, 04 Aug 2008 19:45:18 +0200,

---
JINMEI, Tatuya

---

From: Florian Weimer <[email-masked]>
Date: Tue, 05 Aug 2008 10:49:29 +0200

> seems to do so according to a quick naive grep.

Ah, thanks.  This socket option was introduced in Linux 2.6.14
(released in October 2005), so it's probably not universally
available.  (I'm not saying that the Linux kernel is the univeral
measure, but if it's not there, several other vendors probably lack
it, too.)

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 05 Aug 2008 11:26:49 -0700

At Tue, 05 Aug 2008 10:49:29 +0200,

> measure, but if it's not there, several other vendors probably lack

I have no doubt that some vendors lack it (e.g., Microsoft doesn't
implement it as far as I know), but referring to Linux in this context
could actually be misleading; the Linux IPv6 protocol stack (including
socket API extensions) had been a cretaceous relic largely behind many
other OSes, until the USAGI project incorporated their effort to the
mainline kernel.

---
JINMEI, Tatuya

---

From: Florian Weimer <[email-masked]>
Date: Wed, 06 Aug 2008 09:50:30 +0200

> other OSes, until the USAGI project incorporated their effort to the

Okay.  If my stack lacks it, what should I cap the EDNS0 buffer size
to?  1232 (1280 minues 40 minus 8)? 1200?

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 06 Aug 2008 16:02:53 +0200

JINMEI Tatuya / 神明達哉 wrote:
| At Mon, 04 Aug 2008 15:07:48 -0700,
| JINMEI Tatuya <[email-masked]> wrote:
|
|>> Apparently, this was raised by Itojun at IETF48 back in 2000, but I
|>> don't see how it was resolved.  Implementations with buffer sizes
|>> greater than 1400 bytes seem to fragment according to the link MTU
|>> they are connected to, and do not care about the path MTU.  (I haven't
|>> got native IPv6, so it's hard for me to tell what's going on.)
|> My understanding is that the name server is expected to set the
|> IPV6_USE_MIN_MTU socket option (when available) for its AF_INET6 UDP
|> sockets.  See RFC3542 for this option.  BIND9 does that; unbound also
|> seems to do so according to a quick naive grep.
|
| In this context I should have rather focused on authoritative
| servers...for that matter, NSD also seems to do so according to a
| quick naive grep.

Yes, NSD does this:
If MIN_MTU option exists - sets that option.
Else set the edns bufsize to the IPV6_MIN_MTU

Best regards,
~   Wouter

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 06 Aug 2008 10:48:11 -0700

At Wed, 06 Aug 2008 09:50:30 +0200,

> to?  1232 (1280 minues 40 minus 8)? 1200?

I don't think the EDNS0 buffer size matters in this context: it's the
receiver's (=client's) buffer size, while it's the sender that needs
(or has to deal with the case with missing) IPV6_USE_MIN_MTU.  Or are
you talking about something like BIND9's specific feature
"max-udp-size"?  If so, I'd say it should be not larger than 1232 (if
there's any possibility that some extension headers can be inserted to
DNS responses, it should be smaller accordingly).

---
JINMEI, Tatuya