Subject: RE: FW: Evaluation of: draft-ietf-ipv6-node-requirements-07.txt

From: [email-masked]
Date: Sun, 28 Dec 2003 13:37:40 +0200

Mans & Pekka,

> > <snip>  I guess the question is about whether we want to
> > encourage adding that support, or documenting existing, well-known
> > practice for new implementations.  If we put EDNS0 as a SHOULD, we'd
> > probably be doing the former .. which is OK by me as long as we're
> > doing a conscious decision on that (but my personal take is that we
> > should stick to "known good, implemented, works" -mantra in 
> a document
> > like this).
> 
> We know that EDNS0 works. Mark did a good description of the present
> state. I see nothing to the contrary. It is A Good Thing to endorse
> EDNS0 in a document like this, because it could speed up deployment. 

I am not an expert with EDNS0, but reviewing this thread, it seems
that the client support for EDNS0 is what is lacking, most servers
support it already.  What I think this means is that a SHOULD in
the requirements shouldn't cause operational difficulties.  If I
am correct, then, what would be the problem with listing EDNS0
as a SHOULD?  If we do this, we may get more clients to support
EDNS0.

John

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mans Nilsson <[email-masked]>
Date: Sun, 28 Dec 2003 14:40:26 +0100

Subject: RE: FW: Evaluation of: draft-ietf-ipv6-node-requirements-07.txt Date: Sun, Dec 28, 2003 at 01:37:40PM +0200 Quoting [email-masked] ([email-masked]):

> If I
> as a SHOULD?  

None significant I can think of, though I'd like to hear other opinions. 

-- 
Måns Nilsson         Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

YOW!!  What should the entire human race DO??  Consume a fifth of
CHIVAS REGAL, ski NUDE down MT. EVEREST, and have a wild SEX WEEKEND!

---

From: Pekka Savola <[email-masked]>
Date: Tue, 30 Dec 2003 15:59:55 +0200 (EET)

> as a SHOULD?  If we do this, we may get more clients to support

As practically zero stub resolvers enable EDNS0 by default (I don't
know of any) and only a few implement it at all, I think it is
premature to say that we know it "just plain works" (without any
adverse effects etc.).

I don't think we have much real deployment experience, from the node 
perspective, yet.

-- 
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: Thomas Narten <[email-masked]>
Date: Tue, 30 Dec 2003 12:42:32 -0500

> > as a SHOULD? =20

> None significant I can think of, though I'd like to hear other opinions.=20

Perhaps the question to ask is whether support of EDNS0 is needed to
make IPv6 work well enough. The thing that EDNS0 fixes that is of
relevance here is the small packet size problem. In DNS, packets are
restricted (by default) to be 512 bytes. With IPv6's bigger addresses,
packet overflows are more likely to happen. If we expect this is going
to be a problem, then the right thing to do is recommend use of EDNS0,
even if it isn't widely deployed yet (and for ipv4, the packet size is
less of an issue, hence less motivation/need for it there).

Thomas

---

From: Fred Templin <[email-masked]>
Date: Tue, 30 Dec 2003 10:01:14 -0800

Hello Thomas,

I'm just returning from vacation and catching up, but it seems
to me that the packet size issue could become important if we
expect that the DNS will return many AAAA, A, etc. records
for some FQDNs. Are there any limits on the number of RRs
per FQDN that may be stored in the DNS? And, is EDNS0
essential to support query responses when the size would
exceed 512 bytes?

Thanks - Fred
[email-masked]

---

From: [email-masked]
Date: Wed, 31 Dec 2003 08:41:07 +1100

> per FQDN that may be stored in the DNS?

	No.  Theoretically you can fall all the way back to using
	a zone transfer to get the data you want if it is too big
	for a single DNS/TCP message.

	There have been a number of proposals to allow a multi-message
	DNS/TCP response regardless of query type.  AXFR/IXFR should
	not have been a special cases.

> And, is EDNS0

	Essential. No.  Highly desirable. Yes.  EDNS's larger UDP
	size is to try to reduce the number of times a client will
	have to fall back to TCP.

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