Subject: Advancing AAAA to Full standard ?

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Mon, 14 Nov 2005 09:33:12 -0500

About 2 years ago RFC3596 was published as Draft Standard.
The chairs have received a question if it can be elevated to Full Standard.

On the face of it RFC3596 meets all the criteria for advancement,
it is implemented, deployed and used.

If you have any reason to object that this document be advanced please
state so on the mailing list before December 1'st 2005.
In addition the chairs need at least 5 people to state support
for this action.

What is needed for advancement is a report from Working Group that this
is a fully mature specification and is in use.

	Olafur & Olaf 

--
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: Francis Dupont <[email-masked]>
Date: Mon, 14 Nov 2005 15:40:16 +0100

In your previous mail you wrote:

=> I support!

=> TAHI has a test suite for DNS, IMHO they can give a list of
certified (i.e., successfully tested) implementations.

Thanks

[email-masked]

---

From: Mohsen Souissi <[email-masked]>
Date: Mon, 14 Nov 2005 15:52:19 +0100

As asked below,

I believe RFC3596 is widely implemented and many implementations have
 been fully inter-operating for many years now in this matter and
 especially since it was published as DS.

I fully support the action of the chairs which consists in moving
forward RFC3596 to Full Standard.

Mohsen.

 On 14 Nov, lafur Gumundsson /DNSEXT co-chair wrote:
 | 
 | About 2 years ago RFC3596 was published as Draft Standard.
 | The chairs have received a question if it can be elevated to Full Standard.
 | 
 | On the face of it RFC3596 meets all the criteria for advancement,
 | it is implemented, deployed and used.
 | 
 | If you have any reason to object that this document be advanced please
 | state so on the mailing list before December 1'st 2005.
 | In addition the chairs need at least 5 people to state support
 | for this action.
 | 
 | What is needed for advancement is a report from Working Group that this
 | is a fully mature specification and is in use.
 | 
 | 	Olafur & Olaf

---

From: Simon Leinen <[email-masked]>
Date: Mon, 14 Nov 2005 16:12:18 +0100

I support the RFC 3596's advancement to Full Standard.

I have been using multiple RFC 3596 implementations every day for
several years; in fact I think I use every aspect of it.  My employer
considers it an integral part of our network's DNS infrastructure, and
our tools support it for the generation of forward and inverse zones,
as well as for glue in the ccTLD registries that we operate.

Regards,
-- 
Simon Leinen.
SWITCH

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Nov 2005 10:34:15 -0500

Shouldn't RFC 3596 require EDNS0?

Looking at RFC 3226, A6 was stated to require 
EDNS0 in section 2.2.  This has always been in 
the back of my mind.

It's possible that the rationale in RFC 3226 is 
wrong, that larger message sizes aren't 
necessary.  On the other hand, I wonder if 
requiring it might make it possible to sneak 
AAAA's into the root zone.

Other than that, it seems to be mature, implemented and in some use.

At 9:33 -0500 11/14/05, Ólafur Guðmundsson /DNSEXT

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

True story:
Only a routing "expert" would fly London->Minneapolis->Dallas->Minneapolis
to get home from a conference.  (Cities changed to protect his identity.)

---

From: Pekka Savola <[email-masked]>
Date: Mon, 14 Nov 2005 17:39:22 +0200 (EET)

> it is implemented, deployed and used.

I support this action, HOWEVER, the spec has IPv6 addressing 
architecture as a normative reference; it cannot go to FS withou 
addrarch going to full standard or applying for variance.

So, basically this could be advanced when the v6 protocol bundle gets 
advanced.

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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Nov 2005 17:25:41 +0000

i was considering making a process objection to the advancement of AAAA, but
even though the process has been flawed, the results we'll get by advancing
AAAA aren't worse than the ones we'd get by backtracking and then following
the process.

i refer specifically to the abandonment of A6.  the decision to abandon A6 was
made in a smoke filled room and then presented to the community as the new
default unless sufficient cause was shown to reinstate the previous default
(A6).  lacking such sufficient cause, A6 was abandoned.

the results have been catastrophic, and will only get worse as IPv6 is further
deployed.  we had one shining chance to use DNS as an identity and IPv6
addresses as locators, and that's been lost.  most enterprise IPv6 deployment
will be behind NAT, for the resulting economic reasons.  the routing table will
be every bit as pressured in an IPv6 world as it has been in an IPv4 world, or
likely, far more pressured.

but, even though our reasons for going to war were either outright lies or
based on faulty intelligence or "sexed up" by interested politicians or even
"not voted down" by folks who were afraid to be seen as "outside of the
consensus position", the fact remains that we are at war, and we should win
rather than lose or draw.

AAAA will be a black mark on this working group's historical record.  advance
it please.

---

From: David Conrad <[email-masked]>
Date: Mon, 14 Nov 2005 10:22:51 -0800

Paul,

> (A6).  lacking such sufficient cause, A6 was abandoned.

Yes, the way A6 was abandoned was unfortunate.  The fact that it was  
abandoned wasn't.

I don't see the relationship to AAAA however.

> addresses as locators, and that's been lost.

A6 was inherently flawed in a variety of ways (this isn't intended as  
criticism of the A6 authors, rather just an observation of what was  
discovered during implementation), the worst of which was that it  
would have introduced non-determinism in the lookup algorithm.  Ick.

However, there is absolutely nothing that stops using the DNS as the  
identifier and an IPv6 address as a locator and, in fact, there is  
much to argue for it (provider independence, site-wide transparent  
renumbering, site multi-homing, amenable to non-network topological  
and/or geo-political assignment, etc).  The DNS could be used for the  
mapping between IPv6 identifier and locator _today_ (albeit a  
deployable DNSSEC would help), you don't need the weird half-step  
that was A6.

"It's dead, Jim."  Let it be.

Rgds,
-drc

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Nov 2005 13:37:22 -0500

>I don't see the relationship to AAAA however.

<aol> Me too. <\aol>

>discovered during implementation), the worst of which was that it would have
>introduced non-determinism in the lookup algorithm.  Ick.
>
>identifier and an IPv6 address as a locator and, in fact, there is much to
>argue for it (provider independence, site-wide transparent renumbering, site
>multi-homing, amenable to non-network topological and/or geo-political
>assignment, etc).  The DNS could be used for the mapping between IPv6
>identifier and locator _today_ (albeit a deployable DNSSEC would help), you
>don't need the weird half-step that was A6.
>

Sometimes I think that it would be good to publish RFC's detailing 
things like this for the historical record and as lessons to the next 
generation.

I was once disappointed in the loss of A6.  It was neat, it appealed 
to the engineer/protocol geek in me.  Kind of like flying cars.  But 
it is against the basic tenet of a core infrastructural element, it 
is complex.

My metric for the bit label was that I never once saw anyone ever, 
ever, stand up in front of more than 5 people and successfully work 
out an example by hand.  If a human expert can't follow the 
algorithm, even for just a one-shot with no time limit, I can't 
expect two or more expert implementers to independently get the code 
right.

Ok, maybe the bit label isn't A6, but they went hand-in-hand because 
of the arbitrary bit delegation boundry ideal.

3 months to the next trip.  I guess it's finally time to settle down and
find a grocery store.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Nov 2005 13:40:13 -0500

At 17:39 +0200 11/14/05, Pekka Savola wrote:
>I support this action, HOWEVER, the spec has IPv6 addressing architecture as a
>normative reference; it cannot go to FS withou addrarch going to full standard
>or applying for variance.
>
>So, basically this could be advanced when the v6 
>protocol bundle gets advanced.

At that rate...

...or can we rewrite the document to remove the 
reference.  Make the AAAA record definition stand 
on it's own, regardless of IPv6.  I.e., it's a 
128 bit address, not an IPv6 address.  That's all 
nomenclature, just trying to avoid IETF process 
gridlock.

Still - I would like to hear about whether we 
ought to require EDNS0, recommending a minimum 
acceptable response size.

---

From: John Levine <[email-masked]>
Date: 14 Nov 2005 20:24:03 -0000

> It's possible that the rationale in RFC 3226 is wrong, that larger
> message sizes aren't necessary.  On the other hand, I wonder if
> requiring [EDNS0] might make it possible to sneak AAAA's into the
> root zone.

Could you clarify "sneak" ?

$ dig @e.root-servers.net fr. soa

; <<>> DiG 8.3 <<>> @e.root-servers.net fr. soa 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 12
;; QUERY SECTION:
;;      fr, type = SOA, class = IN

;; AUTHORITY SECTION:
fr.                     2D IN NS        A.EXT.NIC.fr.
fr.                     2D IN NS        A.NIC.fr.
fr.                     2D IN NS        B.EXT.NIC.fr.
fr.                     2D IN NS        B.NIC.fr.
fr.                     2D IN NS        C.EXT.NIC.fr.
fr.                     2D IN NS        C.NIC.fr.
fr.                     2D IN NS        D.EXT.NIC.fr.
fr.                     2D IN NS        E.EXT.NIC.fr.
fr.                     2D IN NS        E.NIC.fr.

;; ADDITIONAL SECTION:
A.EXT.NIC.fr.           2D IN A         193.51.208.14
A.NIC.fr.               2D IN A         192.93.0.1
B.EXT.NIC.fr.           2D IN A         192.228.90.21
B.NIC.fr.               2D IN A         192.93.0.4
B.NIC.fr.               2D IN AAAA      2001:660:3005:1::1:2
C.EXT.NIC.fr.           2D IN A         128.112.129.15
C.NIC.fr.               2D IN A         192.134.0.49
C.NIC.fr.               2D IN AAAA      2001:660:3006:1::1:1
D.EXT.NIC.fr.           2D IN A         204.152.184.85
D.EXT.NIC.fr.           2D IN AAAA      2001:4f8:0:2::8
E.EXT.NIC.fr.           2D IN A         193.176.144.6
E.NIC.fr.               2D IN A         194.57.253.1

;; Total query time: 94 msec
;; FROM: xuxa.iecc.com to SERVER: e.root-servers.net  192.203.230.10
;; WHEN: Mon Nov 14 15:20:23 2005
;; MSG SIZE  sent: 20  rcvd: 400

$ dig @e.root-servers.net coop. soa

; <<>> DiG 8.3 <<>> @e.root-servers.net coop. soa 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 8
;; QUERY SECTION:
;;      coop, type = SOA, class = IN

;; AUTHORITY SECTION:
coop.                   2D IN NS        NS2.NIC.coop.
coop.                   2D IN NS        NS3.NIC.coop.
coop.                   2D IN NS        NS4.NIC.coop.
coop.                   2D IN NS        NS5.NIC.coop.
coop.                   2D IN NS        NS6.NIC.coop.
coop.                   2D IN NS        NS1.NIC.coop.

;; ADDITIONAL SECTION:
NS1.NIC.coop.           2D IN A         204.74.112.106
NS1.NIC.coop.           2D IN AAAA      2001:502:d399::106
NS2.NIC.coop.           2D IN A         204.74.113.106
NS3.NIC.coop.           2D IN A         199.7.66.106
NS4.NIC.coop.           2D IN A         199.7.67.106
NS4.NIC.coop.           2D IN AAAA      2001:502:100e::106
NS5.NIC.coop.           2D IN A         192.100.59.106
NS6.NIC.coop.           2D IN A         198.133.199.106

;; Total query time: 98 msec
;; FROM: xuxa.iecc.com to SERVER: e.root-servers.net  192.203.230.10
;; WHEN: Mon Nov 14 15:23:07 2005
;; MSG SIZE  sent: 22  rcvd: 286

---

From: David Blacka <[email-masked]>
Date: Mon, 14 Nov 2005 16:09:29 -0500

> Could you clarify "sneak" ?

I presumed that Ed was referring to using AAAA records for the root  
servers themselves, where sizing is an issue, e.g., a AAAA record for  
b.root-servers.net.

However, I must not have eaten my Wheaties(tm) this morning because I  
am failing to understand how mandating EDNS0 for AAAA records would  
even work at this late date.  Would servers give back different  
answers if queried without EDNS?

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: "John R Levine" <[email-masked]>
Date: 14 Nov 2005 16:30:21 -0500

> servers themselves, where sizing is an issue, e.g., a AAAA record for

Since resolvers typically have the addresses of the roots configured in a
hints file, why is that an issue?  I realize they should query and get an
updated set of addresses, but so what?

> answers if queried without EDNS?

I suppose they might leave out some of the additional records to keep the
response under 512 bytes, thereby adding a trickle of additional traffic.
The response for the root with authority and additional records is
currently 493 bytes, so it'd take additional queries to find AAAA records
for them.  Considering how what a tiny fraction of root traffic is this
sort of root refresh query, do we care?

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Nov 2005 08:39:16 +1100

I worried about advancing AAAA as it alone does not reflect
	the status of addresses assigned to a IPv6 node.

	IPv6 has both active and deprecated addresses and we don't
	have a way of reflecting these states in the DNS.

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

---

From: Tony Finch <[email-masked]>
Date: Mon, 14 Nov 2005 22:33:36 +0000

> 	have a way of reflecting these states in the DNS.

What's wrong with deleting the deprecated address RRs?

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Nov 2005 10:00:16 +1100

> What's wrong with deleting the deprecated address RRs?

	Well you can still send packets to and from these addresses.
	They are deprecated not gone.  Being deprecated you don't
	want to use these for new sessions, if you can avoid doing
	so, but you still need to maintain the association between
	the name and the address.

	Mark

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Nov 2005 20:12:43 -0500

At 16:30 -0500 11/14/05, John R Levine wrote:
>Quoting David

Yeah, David is right.  Yeah, there are AAAA's for delegations from 
the root.  I've just been waiting for the root servers to start 
having AAAA's (and DNSSEC).

So what? - Configured data goes stale.  It's better to have them 
listed in the zone.

>sort of root refresh query, do we care?

One of the first commandments of the DNS protocol is to put the 
entire response for the root SOA, authority and additional in one 
packet.  It's my understanding that the problem of getting AAAA's for 
the root servers is doing so while obeying that commandment.

What would happen if we dropped that commandment?  Would things still 
work?  Would that get AAAA's into, okay, root-servers.net?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Nov 2005 12:53:48 +1100

> the root servers is doing so while obeying that commandment.

	Actually the DNS protocol does not require this.  Older
	versions of 'named' required this which is not the same
	thing.  A resolver should be able to get any missing address
	records using the SBELT information.
	
> work?  Would that get AAAA's into, okay, root-servers.net?

	Yes they would still work given that the servers can
	preferentually treat A additional records over AAAA additional
	records to help the broken systems.  Note that the A 
	records are all present but the AAAA records are not.
	[The local caching server has AAAA/A records for a number
	of the root servers pre-loaded.]

; <<>> DiG 8.3 <<>> ns . 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62036
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15
;; QUERY SECTION:
;;	., type = NS, class = IN

;; ANSWER SECTION:
.			4d14m25s IN NS	A.ROOT-SERVERS.NET.
.			4d14m25s IN NS	B.ROOT-SERVERS.NET.
.			4d14m25s IN NS	C.ROOT-SERVERS.NET.
.			4d14m25s IN NS	D.ROOT-SERVERS.NET.
.			4d14m25s IN NS	E.ROOT-SERVERS.NET.
.			4d14m25s IN NS	F.ROOT-SERVERS.NET.
.			4d14m25s IN NS	G.ROOT-SERVERS.NET.
.			4d14m25s IN NS	H.ROOT-SERVERS.NET.
.			4d14m25s IN NS	I.ROOT-SERVERS.NET.
.			4d14m25s IN NS	J.ROOT-SERVERS.NET.
.			4d14m25s IN NS	K.ROOT-SERVERS.NET.
.			4d14m25s IN NS	L.ROOT-SERVERS.NET.
.			4d14m25s IN NS	M.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET.	1d23h55m11s IN A  198.41.0.4
B.ROOT-SERVERS.NET.	1H IN A		192.228.79.201
C.ROOT-SERVERS.NET.	1d23h55m7s IN A  192.33.4.12
D.ROOT-SERVERS.NET.	1d23h55m4s IN A  128.8.10.90
E.ROOT-SERVERS.NET.	1d23h55m1s IN A  192.203.230.10
F.ROOT-SERVERS.NET.	1H IN A		192.5.5.241
G.ROOT-SERVERS.NET.	1d23h54m55s IN A  192.112.36.4
H.ROOT-SERVERS.NET.	1H IN A		128.63.2.53
I.ROOT-SERVERS.NET.	1d23h54m52s IN A  192.36.148.17
J.ROOT-SERVERS.NET.	1d23h54m47s IN A  192.58.128.30
K.ROOT-SERVERS.NET.	1H IN A		193.0.14.129
L.ROOT-SERVERS.NET.	1d23h54m44s IN A  198.32.64.12
M.ROOT-SERVERS.NET.	1H IN A		202.12.27.33
B.ROOT-SERVERS.NET.	1H IN AAAA	2001:478:65::53
F.ROOT-SERVERS.NET.	1H IN AAAA	2001:500::1035

;; Total query time: 1 msec
;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1
;; WHEN: Tue Nov 15 12:40:05 2005
;; MSG SIZE  sent: 17  rcvd: 492

	Adding AAAA records for the roots while definitely causing
	the answer to exceed 512 bytes should not trigger fragmentation.

; <<>> DiG 8.3 <<>> ns . +dnssec 
;; res options: init recurs defnam dnsrch dnssec
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63291
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 19
;; QUERY SECTION:
;;	., type = NS, class = IN

;; ANSWER SECTION:
.			4d10m59s IN NS	A.ROOT-SERVERS.NET.
.			4d10m59s IN NS	B.ROOT-SERVERS.NET.
.			4d10m59s IN NS	C.ROOT-SERVERS.NET.
.			4d10m59s IN NS	D.ROOT-SERVERS.NET.
.			4d10m59s IN NS	E.ROOT-SERVERS.NET.
.			4d10m59s IN NS	F.ROOT-SERVERS.NET.
.			4d10m59s IN NS	G.ROOT-SERVERS.NET.
.			4d10m59s IN NS	H.ROOT-SERVERS.NET.
.			4d10m59s IN NS	I.ROOT-SERVERS.NET.
.			4d10m59s IN NS	J.ROOT-SERVERS.NET.
.			4d10m59s IN NS	K.ROOT-SERVERS.NET.
.			4d10m59s IN NS	L.ROOT-SERVERS.NET.
.			4d10m59s IN NS	M.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET.	1d23h51m45s IN A  198.41.0.4
B.ROOT-SERVERS.NET.	1H IN A		192.228.79.201
C.ROOT-SERVERS.NET.	1d23h51m41s IN A  192.33.4.12
D.ROOT-SERVERS.NET.	1d23h51m38s IN A  128.8.10.90
E.ROOT-SERVERS.NET.	1d23h51m35s IN A  192.203.230.10
F.ROOT-SERVERS.NET.	1H IN A		192.5.5.241
G.ROOT-SERVERS.NET.	1d23h51m29s IN A  192.112.36.4
H.ROOT-SERVERS.NET.	1H IN A		128.63.2.53
I.ROOT-SERVERS.NET.	1d23h51m26s IN A  192.36.148.17
J.ROOT-SERVERS.NET.	1d23h51m21s IN A  192.58.128.30
K.ROOT-SERVERS.NET.	1H IN A		193.0.14.129
L.ROOT-SERVERS.NET.	1d23h51m18s IN A  198.32.64.12
M.ROOT-SERVERS.NET.	1H IN A		202.12.27.33
B.ROOT-SERVERS.NET.	1H IN AAAA	2001:478:65::53
F.ROOT-SERVERS.NET.	1H IN AAAA	2001:500::1035
H.ROOT-SERVERS.NET.	1H IN AAAA	2001:500:1::803f:235
K.ROOT-SERVERS.NET.	1H IN AAAA	2001:7fd::1
M.ROOT-SERVERS.NET.	1H IN AAAA	2001:dc3::35
; EDNS: version: 0, udp=1460, flags=8000

;; Total query time: 1 msec
;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1
;; WHEN: Tue Nov 15 12:43:31 2005
;; MSG SIZE  sent: 28  rcvd: 587

	A referral to the COM/NET servers already exceeds 512 bytes.

---

From: [email-masked]
Date: Tue, 15 Nov 2005 02:53:33 +0000

> it is against the basic tenet of a core infrastructural element, it 

	i -still- am pissed off that support for A6 is gone.

> expect two or more expert implementers to independently get the code 

	Ha!  i've seen it done on several occasions.
	get one of the swedes four or five shots down a fine
	single malt and they can do it... :)  (ok, only slightly
	less complex than sendmail rulesets... :)

> of the arbitrary bit delegation boundry ideal.

	critical, core technology required to support variable length
	addresses.  hanging in suspended animation until the world is
	ready for true advances. of course YMMV.

> Edward Lewis                                                +1-571-434-5468

--bill

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Nov 2005 00:26:13 -0500

>	of the root servers pre-loaded.]

So, why don't we see AAAA's for the root servers?  I lulled myself 
into believing it was the size constraint.

Doesn't ($implementation=) BIND treat AAAA's as preferential?  I ask 
because I am not sure what you mean by preferential treatment.  Do 
you mean prefer to include A's over AAAA's?  (As opposed to trying 
the AAAA before the A for the server.)

>	the answer to exceed 512 bytes should not trigger fragmentation.
...
>;; ADDITIONAL SECTION:
...
>; EDNS: version: 0, udp=1460, flags=8000

I don't see these records when querying...

sh-2.05b$ for i in a b c d e f g h i j k l m; \
           do dig $i.root-servers.net aaaa +short; \
           done
sh-2.05b$

It's late here, maybe I have a typo in my dig, but I can't find 
AAAA's for the roots.

If there's no problem with AAAA's and message size, then I can see 
that EDNS0 is not an issue for AAAA's.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Nov 2005 16:56:13 +1100

> the AAAA before the A for the server.)

	I mean prefer adding A records to the additional section
	over AAAA records.  Most nameservers that make/accept queries
	over IPv6 also support EDNS.

	Note preferential treatment is a implementation specific
	behaviour.

> It's late here, maybe I have a typo in my dig, but I can't find 

	http://www.root-servers.org/ will give you the IPv6 addresses
	of the root servers.  It's easy enough to create zones for
	each of the root servers that has a IPv6 address to test
	IPv6 support.

zone "f.root-servers.net" {
        type master;
        file "master/f.root-servers.net";
        notify no;
        allow-query { localhost; };
};

master/f.root-servers.net:
@ 3600 IN SOA drugs.dv.isc.org. marka.isc.org. 1 3600 1200 604800 3600
@ 3600 IN NS drugs.dv.isc.org.
@ 3600 IN A 192.5.5.241
@ 3600 IN AAAA 2001:500::1035

---

From: Pekka Savola <[email-masked]>
Date: Tue, 15 Nov 2005 15:52:52 +0200 (EET)

On Mon, 14 Nov 2005, Edward Lewis wrote:
> Still - I would like to hear about whether we ought to require EDNS0, 
> recommending a minimum acceptable response size.

We can't require it without a normative reference, and EDNS0 isn't 
full standard grade yet.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Nov 2005 09:04:29 -0500

...

I appreciate the work around and the engineering coolness associated 
with it but when it comes to an operational environment configured 
data is to be avoided.  Why, if message size isn't the issue, are 
there no AAAA resource records for the roots in DNS?  I thought the 
issue was message size.

---

From: [email-masked]
Date: Tue, 15 Nov 2005 14:50:17 +0000

> there no AAAA resource records for the roots in DNS?  I thought the 

	message size is only one consideration. given the number of
	"legacy" IMRs running a variety of older software, consideration
	should be made for code that fails to comprend unknown RR types.
	or, we can just declare that such code is broken and we don't care
	if they stop working. (try that on for size ICANN!!!)

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Nov 2005 10:51:04 -0500

>	if they stop working. (try that on for size ICANN!!!)

What's an IMR?  I learned of IMP's in my History of the Internet 
course, but not IMR. ;)

What is the problem if the AAAA is not understood?  Is the 
implication that this software just stops working?  The old software 
will likely also be unable to make use of an IPv6 address even if it 
recognized it.

As someone said in the hallway last month, some bad ideas will cause 
"broken things to stop working."

---

From: [email-masked]
Date: Tue, 15 Nov 2005 16:35:01 +0000

> What's an IMR?  I learned of IMP's in my History of the Internet 

	read the list archives... :)
	Iterative Mode Resolver ... or in depricated parlance, caching server

> will likely also be unable to make use of an IPv6 address even if it 

	perhaps the best examples are documented in an upcoming SAINT paper.
	the failures range from failure to continue processing to returning
	A data instead of the AAAA data.

> "broken things to stop working."

	yup, but there is something to be said for stability.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Nov 2005 19:37:49 +0000

# EDNS0 isn't full standard grade yet.

suggestions welcomed?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Nov 2005 07:38:51 +1100

> 	if they stop working. (try that on for size ICANN!!!)
	
	You mean all those nameservers which will break when they recieve
	AAAA record in response to a ./NS query but also do not break when
	handed a referral to the COM/NET/SE/FR servers and whatever other TLD
	with nameservers answering on IPv6.

	AAAA has been it the wild for many years now.  The only place
	in the DNS heirachy that it is not returned is with non-delegation
	answers from the root.

; <<>> DiG 8.3 <<>> soa com @a.root-servers.net 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15018
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 15
;; QUERY SECTION:
;;	com, type = SOA, class = IN

;; AUTHORITY SECTION:
com.			2D IN NS	A.GTLD-SERVERS.NET.
com.			2D IN NS	G.GTLD-SERVERS.NET.
com.			2D IN NS	H.GTLD-SERVERS.NET.
com.			2D IN NS	C.GTLD-SERVERS.NET.
com.			2D IN NS	I.GTLD-SERVERS.NET.
com.			2D IN NS	B.GTLD-SERVERS.NET.
com.			2D IN NS	D.GTLD-SERVERS.NET.
com.			2D IN NS	L.GTLD-SERVERS.NET.
com.			2D IN NS	F.GTLD-SERVERS.NET.
com.			2D IN NS	J.GTLD-SERVERS.NET.
com.			2D IN NS	K.GTLD-SERVERS.NET.
com.			2D IN NS	E.GTLD-SERVERS.NET.
com.			2D IN NS	M.GTLD-SERVERS.NET.

;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET.	2D IN AAAA	2001:503:a83e::2:30
A.GTLD-SERVERS.NET.	2D IN A		192.5.6.30
G.GTLD-SERVERS.NET.	2D IN A		192.42.93.30
H.GTLD-SERVERS.NET.	2D IN A		192.54.112.30
C.GTLD-SERVERS.NET.	2D IN A		192.26.92.30
I.GTLD-SERVERS.NET.	2D IN A		192.43.172.30
B.GTLD-SERVERS.NET.	2D IN AAAA	2001:503:231d::2:30
B.GTLD-SERVERS.NET.	2D IN A		192.33.14.30
D.GTLD-SERVERS.NET.	2D IN A		192.31.80.30
L.GTLD-SERVERS.NET.	2D IN A		192.41.162.30
F.GTLD-SERVERS.NET.	2D IN A		192.35.51.30
J.GTLD-SERVERS.NET.	2D IN A		192.48.79.30
K.GTLD-SERVERS.NET.	2D IN A		192.52.178.30
E.GTLD-SERVERS.NET.	2D IN A		192.12.94.30
M.GTLD-SERVERS.NET.	2D IN A		192.55.83.30

;; Total query time: 232 msec
;; FROM: drugs.dv.isc.org to SERVER: 198.41.0.4
;; WHEN: Wed Nov 16 07:26:04 2005
;; MSG SIZE  sent: 21  rcvd: 509

---

From: David Conrad <[email-masked]>
Date: Tue, 15 Nov 2005 10:13:21 -0800

Bill,

> 	yup, but there is something to be said for stability.

Seems to me there is a fairly binary choice:

0) Add <new technology> to the root zone and risk breaking things.
1) Don't add <new technology> to the root zone and get stuck in the  
eighties.

I didn't particularly like the 80's myself, but I'm sure that's just me.

It is too bad that the politics of the DNS world don't allow the  
existence of multiple DNS infrastructures implementing the same DNS  
content (e.g., a different set of root hints that reflected servers  
that supported <new technology>, leaving the "classic" root hints  
pointing to servers that don't support <new technology>).  Ah well,  
I'm sure the ISPs around the world will be happy when their customers  
call them asking why DNS answers are ... different.

Rgds,
-drc

---

From: [email-masked]
Date: Tue, 15 Nov 2005 23:55:22 +0000

> I didn't particularly like the 80's myself, but I'm sure that's just me.

	had to give up polyester and chest hair... the mores the pity.

> call them asking why DNS answers are ... different.

	change invites disaster, to some anyway. the concerns, as i
	understand them are:  how much damage and can any of it be 
	pre-empted by education and upgrades?  so the question becomes
	not so much binary by analog...  yes, we add new technology, but
	at what cost?

> -drc

-- bill (who recommends you get a hair cut and a real job)

---

From: John Levine <[email-masked]>
Date: 16 Nov 2005 00:19:22 -0000

># EDNS0 isn't full standard grade yet.

I've seen plausible complaints saying that EDNS0 still causes
operational problems because of the funky things that non-EDNS0
servers do when presented with a EDNS0 request.  If you're lucky,
they'll reject it, but some return odd responses, and some just ignore
it, leading to a lot of potential extra traffic due to retries before
falling back.

I haven't tried it myself, so I'd be interested to hear what people's
actual EDNS0 experience is.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Nov 2005 12:08:06 +1100

> actual EDNS0 experience is.

	EDNS is basically a non-issue these days.  +70% of the
	worlds nameservers talk EDNS.  Of the others the majority
	are RFC 1034 / RFC 1035 compliant and send a error code.

	There really is only a handful of servers that get this
	wrong these days though one major vendor decided to implement
	a 60 second holddown on sending error responses.

	The problem is with middleware that drops packets they can't
	completely decode.  Note: most middleware now handles EDNS
	though some boxes block EDNS w/ DO set.

	Mark

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Nov 2005 08:34:26 +0200 (EET)

> # EDNS0 isn't full standard grade yet.

Get it enabled by default on stub resolvers so we get some actual 
operational experience, and get it to Draft Standard first.

If stub resolvers {can't,won't} turn it on by default, that's a pretty 
strong indication that something might not work as well as hoped.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Nov 2005 09:23:58 +0200 (EET)

On Wed, 16 Nov 2005, JINMEI Tatuya / ¿ÀÌÀÃ£ºÈ wrote:
> I don't think we need to force stub resolvers to turn on EDNS0 by
> default in order to advance the EDNS0 spec to Draft Standard.  Today
> many of recursive resolvers turn it on by default (there are at least
> two different implementations), and I personally believe operational
> experiences with these recursive resolvers should provide enough
> information to decide whether it's matured for DS.

Agreed, I was not clear enough: on stubs is not (IMHO) a strict 
requirement for DS, but it's IMHO a requirement for Full Standard.

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 16 Nov 2005 09:57:30 -0500

>	are RFC 1034 / RFC 1035 compliant and send a error code.

With almost 1 out of 3 not talking EDNS0, I'd say it's an issue. ;) 
(Funny how you can twist statistics - IOW "if your two neighbors are 
speaking EDNS0, you are probably not.")

But perhaps not an issue in the way you mean.

>	though some boxes block EDNS w/ DO set.

Well, moving EDNS0 (or rather the RFC that documents it) from 
Proposed to Draft (and then Full) won't wreck the world of code. 
Moving along the standards track on one hand is just an IETF 
procedural matter, and on the other hand is just an IETF procedural 
matter.

Being a procedural matter, it doesn't change reality.  It's good for 
the WG to begin to exercise this process, to give some weight to the 
work that has been done over the past decade.  This is all about 
formally documenting what we've done, something a mature organization 
does.

On the other hand, being a procedural matter, it's only as important 
as the weight given to the procedures.  A lot of the IETF standards 
consuming world confuses RFC with standard (the IETF editor not 
highlighting the STD track on their home page isn't helping in this 
regard).  Moreover, the difference between Proposed, Draft, and Full 
are not clear.  Yes, they matter to the believers of the IETF, but 
the IETF apparently hasn't sold the consumers on the importance of 
the process.  At least not well enough.

One other thing I'll add.  The thread started out on AAAA advancement 
to Full.  Now we've spread to EDNS0.  At some point the chairs ought 
to step back in and scope and time the work before we become a 
classroom full of unruly students wanting to reinvent everything all 
at once.

So, let's focus on advancing one thing and publicizing the importance 
of the process, the reason for expending more resources to redocument 
what's already been done in both an RFC and in code.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 16 Nov 2005 16:37:47 +0900

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

(I could not find the original message from the chair in my mail box,
so I'm responding to this message)

>>>>> On Mon, 14 Nov 2005 15:40:16 +0100, 
>>>>> Francis Dupont <[email-masked]> said:

>    is a fully mature specification and is in use.
   
I generally agree that the specification and implementations of AAAA
are pretty mature.  However, I believe we should note that there are
also non-negligible numbers of implementations that do not process
AAAA RRs correctly and cause troubles in the actual operation.

RFC4074 describes some of such (authoritative server) implementations.
We've also found some recursive servers/DNS proxies deployed in hotel
Internet connectivity services do not handle AAAA correctly.

I'm not sure whether the existence of these bad implementations can be
a showstopper of this action, though.  Perhaps advancing the spec to
full standard can be a strong incentive for vendors to conform to the
spec.  But I'd like the community (= us) to be aware of the problems
and then to decide the action.

So my response to the proposed action is currently "support with a
reservation".

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 16 Nov 2005 16:20:17 +0900

>>>>> On Wed, 16 Nov 2005 08:34:26 +0200 (EET), 
>>>>> Pekka Savola <[email-masked]> said:

> strong indication that something might not work as well as hoped.

In my understanding, stub resolvers simply don't have to turn it on by
default, since they generally only get small responses (much smaller
than 512 bytes).

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 16 Nov 2005 16:37:47 +0900

JINMEI, Tatuya

---

From: Edward Lewis <[email-masked]>
Date: Wed, 16 Nov 2005 11:16:47 -0500

At 16:37 +0900 11/16/05, JINMEI Tatuya / 

>AAAA RRs correctly and cause troubles in the actual operation.

The rules are set forth in RFC 2026 for standards elevation.  In short:

(4.1.2)
    A specification from which at least two independent and interoperable
    implementations from different code bases have been developed, and
    for which sufficient successful operational experience has been
    obtained, may be elevated to the "Draft Standard" level.  For the

and

(4.1.3)
    A specification for which significant implementation and successful
    operational experience has been obtained may be elevated to the
    Internet Standard level.  An Internet Standard (which may simply be

Neither says anything about "non-negligible numbers of 
implementations that do not process X correctly."  This is rooted in 
the non-enforcement of IETF standards.

I would say that AAAA's meet the Draft Standard criteria, excepting 
for the formal documentation of such.  Not knowing first hand, I 
would say that the same  holds true for Internet Standard.  (Meaning, 
I don't do surveys of implementations.)

I know that non-compliant implementations cause headaches.  But the 
IETF only has purview over documents.  Perhaps making the documents 
more worthwhile will drive the non-compliant implementations to be 
corrected, that needs an outreach effort from the IETF I think.