Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue

From: Mark Andrews <[email-masked]>
Date: Mon, 08 Mar 2004 17:58:33 +1100

[ Moderators note: Post by non-subscriber.  With the massive amount of
   spam, it is easy to miss and therefore delete relevant posts 
   by non-subsrcibers. Please fix your subscription addresses. ]

> Btw: note that IPv6 implementations aren't even required to defragment 
> a datagram which is larger than 1500 bytes once assembled.. so we're 
> in a bit murky waters here.  I'd certainly want to try to avoid packet 
> sizes >= ~1500.

	What's your issue here?

	IPv4 has reassembly buffer size limits.
	IPv6 has reassembly buffer size limits.	

	In either case you don't advertise a EDNS UDP buffer bigger
	than this limit.

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

--
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: Pekka Savola <[email-masked]>
Date: Mon, 8 Mar 2004 18:25:16 +0200 (EET)

On Mon, 8 Mar 2004, Paul Vixie wrote:
> > > ... would force tcp, which really would be worse than ip-frag.
> > 
> > Seems like a flaw in DNS spec -- too coarse granularity:
> >  1) "everything fits in one UDP datagram", or
> >  2) "just use TCP".
> > 
> > Would it make sense to add 1.5) there, "if it doesn't fit to a UDP 
> > datagram of specific size, query again, but only the missing data this 
> > time".
> 
> sense, yes, but the atomicity requirements are hard to adjust in that light.

Precisely -- but IMHO we need to figure out whether such atomicity 
requirements exist.  They very certainly exist with 512 byte limit and 
DNSSEC.  But do they exist e.g., with 1400 bytes?  I'm a bit 
doubtful.. but I'd be interested in hearing what might be a "typical 
case", a "bad case", and "worst case".  (We'll never be able to handle 
the last one, of course.)

> > Not sure if that would make sense but instead of forcing everything in 
> > one, probably fragmented message, it would seem to encourage "proper" 
> > operation with big DNS replies.
> 
> in general, if you think the response might be larger than 3*EPMTU, use tcp,
> and that will amortize the complexity nicely.  note that PMTUD hasn't been a
> raging success, and that EPMTU is probably 1500 octets most of the time, and
> that's where masataka's "4000" number comes from.

Yep, EPMTU is 1500 bytes or a bit less -- but isn't that sufficient 
for about all intents and purposes?

> yes but on such a host, the EDNS0 initiator would presumably be able to 
> discover this limitation and advertise a 1500-octet buffer.  that's what
> the EDNS0 spec says it should do, at any rate.

Should, yes :).  Does, no.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Mark Andrews <[email-masked]>
Date: Mon, 08 Mar 2004 17:58:33 +1100

What's your issue here?

	Mark

---

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Mar 2004 18:25:16 +0200 (EET)