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: "Durand, Alain" <[email-masked]>
Date: Mon, 14 Nov 2005 10:34:06 -0500

> In addition the chairs need at least 5 people to state 
> support for this action.

I support this action.

   - Alain.

---

From: Allison Mankin <[email-masked]>
Date: Mon, 14 Nov 2005 11:00:32 -0800

Ed,

> ..or can we rewrite the document to remove the
> reference. 

Or there can be a downref by using RFC 3967 procedure in
the Last Call - it just asks the community to agree
that AAAA going to Full Standard doesn't require the IPv6
architecture RFC to go beyond DS.  IMO, the downref
is technically reasonable.  Asking the question
in the Last Call is easy boilerplate.

Allison

---

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

On Tue, 15 Nov 2005, Mark Andrews wrote:
>
> 	IPv6 has both active and deprecated addresses and we don't
> 	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: "Durand, Alain" <[email-masked]>
Date: Mon, 14 Nov 2005 17:46:31 -0500

Pekka,

This is a good point, still the requests to the IESG to advance all those specs can happen simultaneously.

    - Alain.

-----Original Message-----
From: [email-masked]
To: Ólafur Guðmundsson /DNSEXT  co-chair
CC: [email-masked]
Sent: Mon Nov 14 10:39:22 2005
Subject: Re: Advancing AAAA to Full standard ? 

> 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
h�{.n�+���zwZ��,j��v�y�覗������-��"z��"�a{
+v�칻�&ފv��x%zX�y�-�鞲Ơzױ��ɪ܆+ކ�i��)�'�~���X����jg���iz�?

---

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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

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

> At 16:30 -0500 11/14/05, John R Levine wrote:
> >Quoting David
> >>  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.
> >
> >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?
> 
> 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.
> 
> >>  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?
> >
> >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?
> 
> 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.

	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.
	
> What would happen if we dropped that commandment?  Would things still 
> 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.

> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                +1-571-434-5468
> NeuStar
> 
> 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: 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: Mark Andrews <[email-masked]>
Date: Wed, 16 Nov 2005 12:08:06 +1100

> ># EDNS0 isn't full standard grade yet.
> >
> >suggestions welcomed?
> 
> 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

	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: 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:

> => I support!

>    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: 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.