Subject: [dnsext] A6 to Historic

From: Ralph Droms <[email-masked]>
Date: Tue, 16 Aug 2011 00:44:48 -0400

There has been a discussion on the 6man mailing list about moving A6 records to Historic.  I'd like to get input from dnsext about the re-designation.

[email-masked] is bcc:ed; please reply to dnsext.

Thanks

- Ralph

---

From: Michael Graff <[email-masked]>
Date: Tue, 16 Aug 2011 00:09:35 -0700

Please move it to historic. 

--Michael (from an iPhone)

On Aug 15, 2011, at 21:44, Ralph Droms <[email-masked]> wrote:

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: bert hubert <[email-masked]>
Date: Tue, 16 Aug 2011 09:38:04 +0200

> There has been a discussion on the 6man mailing list about moving A6 records to Historic.  I'd like to get input from dnsext about the re-designation.

Please move to historic - there is still some lingering confusion out
there if A6 is for real or not, and it would be good to put that
discussion to bed.

    Bert

---

From: Peter Koch <[email-masked]>
Date: Tue, 16 Aug 2011 09:42:34 +0200

> There has been a discussion on the 6man mailing list about moving A6 records to Historic.  I'd like to get input from dnsext about the re-designation.

i have reviewed the thread starting at
<http://www.ietf.org/mail-archive/web/ipv6/current/msg14615.html>.

While i do not think A6 has any particular value, I wonder where
the alleged confusion would originate from.  RFCs 3363 and 3364
should send a clear message, even though the status of "Experimental"
was a political compromise back then.   Then again, these RFCs
might not be read by the potentially confused, but there's
reasonable doubt that that audience would interpret "Historic"
as intended.

However, A6 was defined in RFC 2874 together with "bitstring labels"
and while their use might be arguable as well, they'd either have to
share fate or be preserved in a separate document since the
status applies to a whole RFC, not just parts.

Operationally, I'd rather not see authoritative server implementations
lose the ability to recognize A6 presentation format ('cause you never
know).

-Peter

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 16 Aug 2011 07:48:19 +0000

+1

When we did 6renum current practise analysis, we found A6 record is helpful in renumbering cases. However, we then found it has many issues, which has been documented in RFC 3363 and RFC 3364. If A6 stays experimental status, it is really misleading. We should avoid this confusion by moving it to Historic.

However, some current data shows A6 is actually in use. Based on this, moving A6 to historic is much more complex than an IESG decision. We may need more investigation on how these A6 records are current used. We also need to investigate what impact may have if A6 is abolish. Another important question is whether there are A6-only client. It looks a lot investigation and analysis work, which is definitely worth a draft, before we can make the decision to moving A6 into history or start a phase out plan.

Sheng

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ralph Droms
> Sent: Tuesday, August 16, 2011 12:45 PM
> To: [email-masked]
> Subject: [dnsext] A6 to Historic
> 
> There has been a discussion on the 6man mailing list about moving A6
> records to Historic.  I'd like to get input from dnsext about the re-
> designation.
>

---

From: Roy Arends <[email-masked]>
Date: Tue, 16 Aug 2011 08:07:27 +0000

Hi Ralph, I'm all for moving A6 from experimental to historic, though I'd like to understand what the motivator behind it is (cleanup?). Additionally, A6 (RFC2874) depends on Binary Labels (or bit string labels) (RFC2673). Should that be moved to historic as well, or should that be left as is? I am not aware of any other uses for binary labels (outside of A6).

At Nominet, we still see about 2.5m queries a day for type A6 queries, though a representative sample taken of the QNAMEs in the query shows a 0% deployment of A6 records in the UK namespace. To explain: we see those queries at our authoritative servers, and we subsequently send either a delegation or an rcode3 (NXDOMAIN) back. The representative sample is taken from the delegated namespace.

If this is moved to historic, I would like to see some text on how to deal with A6 records in the future. If they are to be treated as 'unknown records' (RFC3597), it might lead to some interoperability issues, as resolvers that supported A6 in the past were required to do additional section processing for these records on the wire. Additionally, we need to understand how to deal with an A6 record in presentation format. With near zero deployment and a very large installed base that won't be changed overnight, moving something from experimental to historic for the purpose of 'cleaning up' or 'avoiding confusion' makes sense. It does come at a cost for those who have implemented it and consider their implementation as a reference implementation. 

Kind regards,

Roy Arends
Nominet UK

---

From: Shane Kerr <[email-masked]>
Date: Tue, 16 Aug 2011 10:26:23 +0200

Peter,

> reasonable doubt that that audience would interpret "Historic"

I was recently at the IANA page that lists registered RR types:

http://www.iana.org/assignments/dns-parameters

It's not clear from this list what RR types are more important, which
are less important, which may have special-case uses, and which are
basically worthless. (I love the recent trend to list the "Value and
meaning" as identical to the identifier!)

Moving A6 to historic may have the benefit of being able to change the
label from:

A6           38 A6 (Experimental)                           [RFC3226][RFC2874]

to:

A6           38 A6 (Obsolete - use AAAA)                    [RFC3226][RFC2874][RFCxxxx]

This isn't a huge help, but it is something!

--
Shane

---

From: Florian Weimer <[email-masked]>
Date: Tue, 16 Aug 2011 08:30:05 +0000

> status applies to a whole RFC, not just parts.

EDNS0bis will disallow extended label types, matching current
implementation practice.  Extended label types require a different
mechanism for discovering zone delegation in resolvers, and it appears
that this has never been implemented anywhere.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Roy Arends <[email-masked]>
Date: Tue, 16 Aug 2011 08:45:12 +0000

> that this has never been implemented anywhere.

Hi Florian,

I dispute that extended label types have never been implemented. Up until BIND-9.3.1, bit string labels (using ELT 000001) were supported. However, the text in draft-ietf-dnsext-rfc2671bis-edns0 already moves bit string labels to historic (explicitly), so that deals with at least that concern. By implication, it makes A6 useless, hence lets move that to historic as well.

Kind regards,

Roy Arends
Nominet UK

---

From: Peter Koch <[email-masked]>
Date: Tue, 16 Aug 2011 10:50:13 +0200

> This isn't a huge help, but it is something!

yes, it's a mistake.  The current list is neither complete nor consistent.
and while one might argue that the registry MAY contain comments, it is
unclear how they would be entered or maintained.  For the status of
specification (Hist, Exp, Informational or any Standards Track maturity level)
the housekeeping is traditionally done by the RFC Editor, not IANA.
"Obsolete" has unclear meaning, at least doesn't exist in RFC 2026
(other than as a loose equivalent to Historic).
What comes closest is section 3.3 of RFC 2026, but again not an IANA task.

And finally, for those specifications not opriginating from within the IETF,
there's no authoritative source for the status.

The IANA registry is a registry of code points with pointers to specification.
It should not be overloaded with additional information.  There's clearly
a need for such a 'wiki style' repository, but that definitely needs a
different approach.  In an ideal world, the IETF had a marketing/education
wing that would deal with these navigation and accessibility issues (and several
more).  In the real world, ISOC would be a good starting point for these tasks.

-Peter

---

From: Florian Weimer <[email-masked]>
Date: Tue, 16 Aug 2011 08:51:55 +0000

* Roy Arends:

> I dispute that extended label types have never been implemented. Up
> until BIND-9.3.1, bit string labels (using ELT 000001) were
> supported. However, the text in draft-ietf-dnsext-rfc2671bis-edns0
> already moves bit string labels to historic (explicitly), so that
> deals with at least that concern. By implication, it makes A6 useless,
> hence lets move that to historic as well.

The proper resolver behavior was never implemented.  BIND's resolver
assumed that the parent was upgraded to support extended label types
before they were used in a child zone.  To my knowledge, the root never
fully implemented extended label types, so this protocol extension never
took off.

The issue is that a resolver sends the full QNAME to parent servers.  If
the name includes an extended label type and the parent lacks support,
the parent will respond with an error.  An alternative implementation
would incrementally add labels until the delegation is discovered, so
that the parent never sees non-material labels.  This has other
benefits, such as not sending partial call data records around the world
if you use the public ENUM tree under e164.arpa, but I don't think it
has been implemented.

---

From: Roy Arends <[email-masked]>
Date: Tue, 16 Aug 2011 09:17:07 +0000

On Aug 16, 2011, at 9:51 AM, Florian Weimer wrote:

>>> Extended label types require a different
>> I dispute that extended label types have never been implemented.
> 
> The proper resolver behavior was never implemented.  

Hi Florian, 

My apologies, I jumped to conclusion after having misread your response. You are right of course.

Kind regards,

Roy Arends
Nominet UK

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Aug 2011 21:42:46 +1000

In message <[email-masked]>, Roy Arends wr
ites:
> I dispute that extended label types have never been implemented. Up until BIN
> D-9.3.1, bit string labels (using ELT 000001) were supported. However, the te
> xt in draft-ietf-dnsext-rfc2671bis-edns0 already moves bit string labels to h
> istoric (explicitly), so that deals with at least that concern. By implicatio
> n, it makes A6 useless, hence lets move that to historic as well.

A6 is completely independent of bit-string labels.  The case for declaring
A6 historic has to stand / fall on its own merits.

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

---

From: Ralph Droms <[email-masked]>
Date: Tue, 16 Aug 2011 10:51:15 -0400

Brian Carpenter kicked off the discussion on the 6man mailing list with:

  What do 6man people think about moving RFC 2874 (the A6 record)
  from Experimental to Historic status?

  It's pretty clear that it doesn't have any real value, and
  it can still create confusion for newcomers.

I agree with Brian and am inclined to move A6 to Historic.

- Ralph

On Aug 16, 2011, at 8:07 AM 8/16/11, [email-masked] wrote:

> 
> is the rational for moving this to historic due to the removal of A6 code from one of 
> the popular reference implementations back when it was made experimetal or is there some
> practical reason to change its status?
> 
> /bill
> 
> -leave it at experimental please-
> 
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 16 Aug 2011 07:57:17 -0700

On Aug 16, 2011, at 1:07 AM, Roy Arends wrote:

> If this is moved to historic, I would like to see some text on how to deal with A6 records in the future.

+1. Historically in the IETF, moving something to "historic" has caused confusion for developers because of lack of information (including the lack of good definition of what "historic" means). This has lead to *less* interoperability as different developers interpret "historic" in different ways.

If we are going to take this step, we should be clear what we mean, even though that takes a bit more writing work.

--Paul Hoffman

---

From: David Conrad <[email-masked]>
Date: Tue, 16 Aug 2011 06:43:42 -1000

>> If this is moved to historic, I would like to see some text on how to deal with A6 records in the future.

I'm confused.  Why should A6 be treated any differently than any other un-understood RRtype?

> If we are going to take this step, we should be clear what we mean, even though that takes a bit more writing work.

Perhaps we should move it to "Don't Waste Your Time"?

To be clear, I'm all for moving A6 to "Historic". I think spending any further time on it would fall under http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality.

Regards,
-drc

---

From: Roy Arends <[email-masked]>
Date: Tue, 16 Aug 2011 22:01:44 +0000

>I'm confused.  Why should A6 be treated any differently than any other

A6 should indeed be treated the same as any other un-understood
RRtype..... But we should say that somewhere... That's the point.

>
>> If we are going to take this step, we should be clear what we mean,
>>even though that takes a bit more writing work.
>
>
>To be clear, I'm all for moving A6 to "Historic". I think spending any
>further time on it would fall under
>http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality.

Cute.

If, in ten years time, folks want to know why we moved A6 to historic, and
what to do when encountering it, they could use a point of reference. Not
documenting doesn't help. Something very similar to RFC3425.

Roy

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 17 Aug 2011 01:17:10 +0000

I can work on this. But I need a co-author who can investigate the status of the current A6 usage. Any volunteer?

Sheng

> Behalf Of Paul Hoffman
> Sent: Tuesday, August 16, 2011 10:57 PM
> To: Roy Arends
> Cc: Ralph Droms; [email-masked]
> Subject: Re: [dnsext] A6 to Historic
> 
> +1. Historically in the IETF, moving something to "historic" has caused
> confusion for developers because of lack of information (including the
> lack of good definition of what "historic" means). This has lead to
> *less* interoperability as different developers interpret "historic" in
> different ways.
>

---

From: [email-masked]
Date: Tue, 16 Aug 2011 22:49:30 +0000

well, as others have pointed out, there is a reasonable, if small use of A6 in the
wild and just because one sector (6man) is easily confused, does not mean the rest of
us are (dnsext).   it may not have any real value to some, but it apparently does to
a statistically visiable community.  which in my mind is a reason to leave it alone.
but as an actual user of the code point, I fully expect to be overridded by folks
who don't use it and therefore see no reason to keep things around that don't fit their
view of the world.   Thanks for the heads up that you are going to depricate A6.

/bill

---

From: [email-masked]
Date: Tue, 16 Aug 2011 12:07:52 +0000

/bill

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 17 Aug 2011 06:14:09 +0000

It was RFC 3363, " Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)", moved A6 from "proposed standard" to "experimental" status. Also see RFC 3364, "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", for some issues A6 has.

Sheng

> Behalf Of [email-masked]
> Sent: Tuesday, August 16, 2011 8:08 PM
> To: Ralph Droms
> Cc: [email-masked]

---

From: Andreas Gustafsson <[email-masked]>
Date: Wed, 17 Aug 2011 10:55:20 +0300

Sheng Jiang wrote:
> However, some current data shows A6 is actually in use.

Could you please provide a reference to this data?  Does it show that
A6 records are actually published on authoritative servers, or just
that there is type A6 query traffic?

That there is A6 query traffic does not mean that A6 is actually in
use; it probably just means that there are still some recursive
servers in operation that issue internally-generated type A6 queries
when trying to look up missing name server addresses, in addition to
issuing such queries for A and AAAA.

+1 for moving A6 to Historic.
-- 
Andreas Gustafsson, [email-masked]

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 17 Aug 2011 08:19:28 +0000

> that there is type A6 query traffic?

The root servers are getting 100's of A6 q/s (~20:1 AAAA:A6 <http://k.root-servers.org/statistics/GLOBAL/daily/>).
 
> issuing such queries for A and AAAA.

That's right. That's what we need to investigate further.

Sheng

---

From: Tony Finch <[email-masked]>
Date: Wed, 17 Aug 2011 11:31:51 +0100

[email-masked] <[email-masked]> wrote:
> wild

Isn't that entirely due to obsolete software that queries for A6 instead
of AAAA? Note the A6 queries will never get a positive answer. How does
the rate of ip6.int queries compare?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber: Northwest, veering northeast 3 or 4, occasionally 5 at first. Slight.
Showers. Good.

---

From: Jim Reid <[email-masked]>
Date: Wed, 17 Aug 2011 13:29:18 +0100

> issuing such queries for A and AAAA.

Yeah.

ISTR A6 lookups found their way into some Linux/glibc implementations  
of gethostbyname() 8-10 years ago. These may well have not been  
replaced or upgraded yet.

> +1 for moving A6 to Historic.

<AOL Mode>Me too!</AOL Mode>

---

From: Edward Lewis <[email-masked]>
Date: Wed, 17 Aug 2011 09:18:08 -0400

A6, as with a handful of other lame duck types, should be marked 
historic with the meaning being "here's the definition of the syntax 
and semantics but it is not required for general purpose 
implementations and is considered to be obsolete."  Other 
dead-on-arrival types include SINK which lives on in the IANA 
registry and in harder-to-find expired drafts.

As far as A6, saying "it's in use" is a weak excuse.  Many old, old 
versions of BIND asked for it and some active name servers have not 
been upgraded for a long time.  I'm all for moving A6 to historic 
because it can be dangerous to the protocol.

When A6 was moved to experimental following the London IETF meeting 
in summer 2001, I had two negative thoughts about A6 despite 
originally thinking it was a really cool answer to renumbering 
problems.

One, no one was able to ever "white board" a scenario showing the 
concept working in front of a small crowd without making a mistake. 
That it, it did not pass a sniff test of being a simple enough to 
explain or operate mechanism.

Two, it could be a denial of service attack vector by inducing a 
resolver into a long-lived "loop" trying to find all of the fragments 
of the address needed to assemble the 128 bits.  Fragments weren't 
guaranteed to line up, so a resolver might find conflicting portions 
of the address.  Even if it seemed it was ultimately guaranteed to 
find an address, the work to get there (including the needed network 
queries) could be considerable.

The lesson learned from the A6 experiment was that the data model of 
DNS had to stick to simple records to preserve the speed feature of 
DNS.  The lesson also applied to DNSSEC, affirming[*] that 
simplifying the default authorization model (the signer domain name 
in the RRSIG ought to be the zone) was a right step.  Ever since then 
we have been trying to make sure the resolver's work is minimized.

[*] I'm not saying this led to RFC 3008, as RFC 3008 was published 
nearly a year earlier.  But it made the restriction more significant.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

I'm overly entertained.

---

From: [email-masked]
Date: Wed, 17 Aug 2011 17:34:37 +0200 (CEST)

> explain or operate mechanism.

Does DNSSEC pass this test?

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 17 Aug 2011 11:41:51 -0400

Yeah.

I'm overly entertained.

---

From: David Conrad <[email-masked]>
Date: Wed, 17 Aug 2011 12:55:06 -1000

On Aug 16, 2011, at 12:49 PM, [email-masked] wrote:
> it may not have any real value to some, but it apparently does to a statistically visiable community.  

The fact that root servers are receiving A6 queries does not necessarily imply A6 has value.

> but as an actual user of the code point,

How are you using it?

Regards,
-drc

---

From: [email-masked]
Date: Wed, 17 Aug 2011 05:19:25 +0000

actually,  Ralph has provided the rational for moving to historic.
 "Brian Carpenter was confused."

 and for those of us who use A6,  I guess we will continue to support it
 even if -in its move to historic- unless the IANA choses to revolk its code point,
 which is something I don't think they have ever done for any RR type that was
 defined.  Of course there is always a first time.

/bill

---

From: David Conrad <[email-masked]>
Date: Wed, 17 Aug 2011 19:02:45 -1000

Bill,

On Aug 17, 2011, at 5:36 PM, [email-masked] wrote:
> 	certainly not to the roots.  

Sorry, which "statistically visible community" are you talking about then?

>> How are you using it?
> 	for doing IPv6 prefix renumbering.

Which part of RFC 3364's analysis of A6's issues do you disagree with?

> I had to put the code back into BIND when
> ISC stripped it out, then had to fix DHCPv6 to work as DHCP was designed to ...
> so I have DDNS working when nodes are mobile and move between policy domains.

Other than your hacked BIND, is there any other implementation?

Regards,
-drc

---

From: Peter Koch <[email-masked]>
Date: Thu, 18 Aug 2011 10:56:10 +0200

>  defined.  Of course there is always a first time.

which part of RFC 6195 or which other document did i miss that would
put this decision in IANA's hands or would define code point revocation
in the first place?

-Peter

---

From: David Conrad <[email-masked]>
Date: Thu, 18 Aug 2011 07:21:36 -1000

Bill,

On Aug 18, 2011, at 1:25 AM, [email-masked] wrote:
> On Wed, Aug 17, 2011 at 07:02:45PM -1000, David Conrad wrote:
> 	all versions of bind are hacked to some degree or other.

I was making the distinction between what was implemented/supported/promulgated by ISC and what was done outside of ISC.

> 	and not being a DNS server librarian, I have no idea what other
> 	folks are using/doing - other than what gets seen on the wire.

I'm trying to understand if there is a valid reason to keep A6 as experimental or whether it should the experiment be declared over by moving A6 to historic.  As we figured out when the first A6 implementation was being developed, yes, A6 can be made to work but it introduces a tremendous number of potential nuclear land mines that would make the DNS far more brittle than it already is (I'll admit I still have a bit of bitterness about how all of this was handled).  

As documented in 3364, A6 has many implications. If the work that you've done contradicts those findings, that would be useful to know. If others are working on A6 in a non-trivial fashion, that would also be of interest. 

Regards,
-drc

---

From: [email-masked]
Date: Thu, 18 Aug 2011 17:37:38 +0000

> I was making the distinction between what was implemented/supported/promulgated by ISC and what was done outside of ISC.

	fair enough.  in my thinking, BIND stopped being BIND when it left
	Berkeley ... there is the ISC varient. :)

> I'm trying to understand if there is a valid reason to keep A6 as experimental or whether it should the experiment be declared over by moving A6 to historic.  As we figured out when the first A6 im…

	well, bitstrings was a kewl idea that was -very- (too) hard to wrap an operational 
	practice around - a blunt force way to "fix"  bitwise delegation in the reverse
	tree.   A6, done properly, would have been the ideal way to support renumbering.
 
> As documented in 3364, A6 has many implications. If the work that you've done contradicts those findings, that would be useful to know. If others are working on A6 in a non-trivial fashion, that wo…

	I think Ed has clarified a defenseable arguement for moving to historic...
	the latency of nested lookups (sort of like chasing validation) is reason enough
	to move to historic ...  UNLESS we can practically move to a situation where 
	there is a full IMR instead of a stub in each endsystem.  Then a cohesive arguement
	can be made to revisit the base assumptions of 3364 

/bill

---

From: [email-masked]
Date: Thu, 18 Aug 2011 11:22:29 +0000

Ed,
	This "lesson learned" is a credible reason to move the
RR to historic.  If this is the rational Ralph wants to use - then
I can back its move.  If its just "some people are confused" then 
thats not good enough for me.  Thanks for the cogent arguement.

/bill

---

From: [email-masked]
Date: Thu, 18 Aug 2011 11:25:22 +0000

all versions of bind are hacked to some degree or other.
	i just put back in the code that ISC had in there in the first place.

	its not (yet) a bespoke DNS authoritative server.

/bill

---

From: [email-masked]
Date: Thu, 18 Aug 2011 03:36:44 +0000

> The fact that root servers are receiving A6 queries does not necessarily imply A6 has value.

	certainly not to the roots.  but they have to field all kinds of stray/orphaned 
	queries.  properly considered, roots should not get A queries either.

> > but as an actual user of the code point,

	for doing IPv6 prefix renumbering.  I had to put the code back into BIND when
	ISC stripped it out, then had to fix DHCPv6 to work as DHCP was designed to ...
	so I have DDNS working when nodes are mobile and move between policy domains.

/bill