Subject: Re: Advancing AAAA to Full standard ?

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

In your previous mail you wrote:

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

   What is needed for advancement is a report from Working Group that this
   is a fully mature specification and is in use.
   
=> TAHI has a test suite for DNS, IMHO they can give a list of
certified (i.e., successfully tested) implementations.

Thanks

[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: 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
  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.
>	Olafur & Olaf

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

---

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: [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: 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: Paul Vixie <[email-masked]>
Date: Tue, 15 Nov 2005 19:37:49 +0000

# EDNS0 isn't full standard grade yet.

suggestions welcomed?

---

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 16 Nov 2005 16:20:17 +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. ]

>>>>> 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
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]