Subject: RE: AAAA/A6 thing

From: "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" <[email-masked]>
Date: Mon, 30 Apr 2001 17:08:40 -0700

hi,

	Is there any alternate solution to A6 record
      being looked at ? Something which lies somewhere
      in between AAAA and A6. 

-ebi

> -----Original Message-----
> From: David Terrell [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 9:25 AM
> To: Masataka Ohta
> Cc: D. J. Bernstein; [email-masked]; 
> [email-masked]
> Subject: Re: AAAA/A6 thing
> 
> 
> On Mon, Apr 30, 2001 at 06:16:21PM +0859, Masataka Ohta wrote:
> > Dan;
> > 
> > It's your problem.
> > 
> > > Paul A Vixie writes:
> > > > i have not, yet, heard anything new against A6 in this 
> round of the debate.
> > > 
> > > http://cr.yp.to/djbdns/killa6.html
> > 
> > How about:
> > 
> > 	aol.com.	NS	ns0.aol.net.
> > 	aol.com.	NS	ns1.aol.net.
> > 
> > 	aol.net.	NS	ns0.aol.com.
> > 	aol.net.	NS	ns1.aol.com.
> > 
> > ?
> 
> In this case, ns[01].aol.{net,com} will be in the {net,com} zones as 
> glue.
> 
> I think the question that I have yet to see answered that Dan is
> not articulating well is "how the hell is DNS glue supposed to work
> sanely with A6?"  I can't find an answer to that myself.  Everybody's
> talking about no full IP addresses written anywhere, and DNS
> delegation is one place where that just doesn't work.  You need the
> full 128 bit address in there, and glue registry is the one place
> that these addresses can't change frequently, because of the bulk
> of TLD zones and complicated, time consuming procedures registrars
> use to update those records... 
> 
> -- 
> David Terrell            | "I went into Barnes and Noble to 
> look for a 
> Prime Minister, Nebcorp  | book on A.D.D., but I got bored and left." 
> [email-masked]             | - Benjy Feen
> http://wwn.nebcorp.com/  |
> 
> 
> to unsubscribe send a message to 
> [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> 

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 1 May 2001 09:32:15 +0859 ()

Ebi;

>       being looked at ? Something which lies somewhere

A6 is as good as NS.

All you need is an alternative implementation.

Dan's one is broken. Paul's one was and may still be broken.

						Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Tue, 01 May 2001 16:09:47 +0700

Date:        Mon, 30 Apr 2001 17:08:40 -0700
    From:        "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	Is there any alternate solution to A6 record
  |       being looked at ? Something which lies somewhere
  |       in between AAAA and A6. 

The obvious thing there would simply be to add some restrictions to the
use of A6.   One currently proposed is to only use A6 0,xxx (which makes
it isomorphic to AAAA - but at least using the new record format, so
upgrading to something a bit more complex later would not be impossible).

Another would be to require all of the domains listed to be in the same
zone as the A6 record (so the whole chain can always be returned in one
DNS reply), and/or perhaps limiting the length of the chain (partly for the
same reason).

I doubt very much that it makes sense to invent something new - we already
have the simplest of all possible results (AAAA) and the most general we
can think of at the minute anyway (A6).  Something neither simple, nor general
doesn't seem likely to be a useful aim.

kre

---

From: [email-masked]
Date: Tue, 01 May 2001 18:22:09 +0900

>upgrading to something a bit more complex later would not be impossible).

	this part i don't really understand.  if we advocate "A6 0 <128bit>"
	there will be resolver implementation that does not chase A6 chains
	at all (like for cellphones or whatever).  if there's no need,
	there'll be no code.  then, there will be no possibility for "A6
	<non-zero> <less-than-128bit> <chain>".  so I don't really see benefit
	of "A6 0 <128bit>" than "AAAA".

itojun

---

From: Robert Elz <[email-masked]>
Date: Tue, 01 May 2001 16:39:37 +0700

Date:        Tue, 01 May 2001 18:22:09 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	this part i don't really understand.  if we advocate "A6 0 <128bit>"
  | 	there will be resolver implementation that does not chase A6 chains
  | 	at all (like for cellphones or whatever).

I had thought of adding to my message (but I wanted to keep it reasonably
brief) that the full resolver implementations are still needed now, in
the way we decide we need them to operate - which might be via an AAAA
recursive query to a back end resolver (I would expect that most baby devices
will use back end resolvers to do most of the work for IPv6, just as they
have for IPv4 - whether that includes synthesising AAAA from A6 queries though
hasn't been decided, but it certainly has been contemplated).

The advantage of A6 0 is that it would guarantee operational stability to
at least the degree of AAAA - not that it will simplify the implementation
effort (which only needs to be done a smallish number of times in the grand
scheme of things).

kre

---

From: Christian Schild <[email-masked]>
Date: Wed, 02 May 2001 09:57:49 +0200 (CEST)

Itojun,

>       of "A6 0 <128bit>" than "AAAA".

one can still 'advocate' A6 0 <128bit> with the chain resolution implemented.
In my understanding we should suggest to use 128bit records for _now_. If 
in the future, with more testing done and more experience at hand, we have 
developed a good set of rules how to chain A6 records in an unperilous
manner, then we could start to _use_ the chaining.  

Christian

---

From: Ian Jackson <[email-masked]>
Date: Thu, 3 May 2001 18:32:15 +0100 (BST)

Christian Schild writes ("Re: AAAA/A6 thing"):
> one can still 'advocate' A6 0 <128bit> with the chain resolution
> implemented.  In my understanding we should suggest to use 128bit
> records for _now_. If in the future, with more testing done and more
> experience at hand, we have developed a good set of rules how to
> chain A6 records in an unperilous manner, then we could start to
> _use_ the chaining.

That's a hopeless idea.

We should not add features to standards without a clear idea of what
they're good for.  We should not put something in the spec and then
tell people not to use it.  If people shouldn't use it it shouldn't be
in the spec.

Furthermore, deploying A6 0 will not allow anyone to effectively work
the bugs out of prefix-chasing resolvers, so if we were to specify
A6 0 now but decided we wanted A6 >0 later we'd have to wait for new
implementations anyway.  Also, if the spec says A6 but MUST NOT
require prefix chasing, many implementors may avoid implementing it
altogether.

Another way to look at it as a bait-and-switch: we are supposed to
agree to A6 now, despite there being no good reason for it, because
actually `we'll just use A6 0'.  But, everyone still has to implement
A6 >0 !

Ian.

---

From: Jim Bound <[email-masked]>
Date: Thu, 3 May 2001 23:41:09 -0400 (EDT)

After much good discussion with Davkd Conrad and Paul Vixie, and
Christian/Matts view of this I believe we must implement what we have
regarding A6 specs from the implementation perspective.  I will leave it
to others to tell us as we develop this if the specs are to be altered.
Assist with renumbering.  Reduce routing tables.  And make IPv6 more
deployable.  I will leave it to others to find consensus on this or
against this.  It needs to be implemented and used.

/jim

On Thu, 3 May 2001, Ian Jackson wrote:

> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
>

---

From: Ian Jackson <[email-masked]>
Date: Fri, 4 May 2001 14:55:42 +0100 (BST)

Jim Bound writes ("Re: AAAA/A6 thing"):
> regarding A6 specs from the implementation perspective.

`After much good discussion with various people, I believe we must
implement what we have regarding AAAA specs from the implementation
perspective'.

Just because something is Proposed Standard doesn't mean it should be
implemented and/or advanced to Draft Standard.

AAAA is Proposed Standard too, has more operational experience, is
simpler, and can do everything that A6 can do just as well if not
better.

>  I will leave it to others to tell us as we develop this if the
> specs are to be altered.

The A6 spec hasn't been finalised yet.  It hasn't even been approved
as a general way forward !  At the moment there are two proposals on
the table.  You can't say `I will leave it to others to [alter the
spec]', because there is no specification that says you should do A6
rather than AAAA.

> against this.  It needs to be implemented and used.

I agree that we should assist with renumbering, reduce routing tables,
and make IPv6 more deployable.  But A6 does not help with this.  In
fact, requiring a complex protocol like A6 where AAAA is adequate will
*hinder* IPv6 deployment.

Just because A6 was introduced to help with renumbering DOES NOT mean
that it is a good thing for that purpose.  Nor does it mean that A6
opponents are somehow taking sides in some kind of ipngwg politics
about renumbering.  I couldn't care less about that politics, and if
ipngwg say we need easy renumbering, fine. [1]

But ipngwg should not define DNS protocols, dnsext should so so.
In this case we have an overcomplex protocol which allegedly exists to
meet some renumbering requirement, but which is in fact unnecessary.

[1] Actually, as a layman when it comes to IPv6, renumbering, etc., I
approve of making renumbering easy.  But I'm no expert in that field,
and I'll leave that to those who are.  Likewise, DNS protocol and
architecture should be done by the DNS experts.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Fri, 4 May 2001 15:13:34 +0100 (BST)

I'd like to ask a procedural question.  I'm not sure this is the right
place, but this thread will do since this is where the substantive
discussion is happening.  I looked again at 2026 but it wasn't much
help.

I think we are now approaching the time to use whatever the formal
procedure is to declare RFC2874 Historic.  Presumably this will
involve getting rough consensus in at least the dnsext wg [1], which I
think we might be close to.

[1] Some may argue that since 2874 was not really a dnsext document
but an ipngwg one, it can't be withdrawn by dnsext.  If this is true,
then it was probably out of scope for ipng, or at the very least, if
dnsext disagree with it then dnsext should be able to obsolete it and
require ipngwg to state their requirements so that the protocol design
can be done by dnsext.

But how should this be initiated ?  Should I write an I-D summarising
the discussions, with the aim of it eventually becoming an
Informational RFC which obsoletes 2874 ?  (That would be an IESG
standards action, I suppose, despite it being the publication of an
Informational document.)

Should we start work on polishing up AAAA (RFC1886) to move it to
Draft Standard ?  I'm not mistaken, am I, about there being at least
two interoperable implementations of AAAA and ip6.int ?

If we can't get consensus on AAAA going to Draft Standard, can we
polish it up a bit and publish it once more as Proposed Standard but
obsoleting 2874 ?

Are some, all, or none of these the right way to do it ?

Ian.

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 05 May 2001 10:42:45 -0700

Can somebody clarify? I was under the impression that AAAA had already
been deprecated. I'm looking through my archives and can't seem to find
the message that says this explicitly (so I may be mistaken, which is why
I seek clarification). The best I can find is the DNSEXT meeting notes
from IETF 50:

 | Subject: draft IETF-50 DNSEXT meeting notes
 |    Date: Mon, 9 Apr 2001 11:08:57 -0400 (EDT)
 |    From: Olafur Gudmundsson <[email-masked]>
 |      To: DNSEXT mailing list <[email-masked]>

 | IPv6 DNS transition and deployment: Rob Austein
 | - Problems: two complete IPv6 DNS Address record solutions
 |   - One standard, other deprecated
 |   - Known implementations using deprecated one
 |   - Becoming issue for IPv6 deployment

 | - Need to have transition plan to get from AAAA to A6.  Will require
 | protocol things, like synthesizing AAAA records.

 | - Overview of A6 transition plan
 |   - Use A6 in zone files
 |   - Anything that needs AAAA is assumed to be stub resolvers and we
 |     synthesize it
 |   - No AAAA in root or TLD zones

Also, wasn't ipv6.int moved to ipv6.arpa?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Randy Bush <[email-masked]>
Date: Sun, 6 May 2001 07:28:52 -0700 (PDT)

The A6 RFC depricates AAAA, however, the authors did this w/o any A6
 support being available. Some is starting to emerge but it is very
 slow. AAAA clearly has the edge in the installed base, since it has
 been supported since Bind 4.9.6.

 The same folks who depricated AAAA w/o any alternative also picked
 a new place to anchor the delegations with out ensuring it existed.
 After repeated requests to the IANA to make the delegation, it still
 has not occured. No IP6.ARPA.

% 
% Can somebody clarify? I was under the impression that AAAA had already
% been deprecated. I'm looking through my archives and can't seem to find
% the message that says this explicitly (so I may be mistaken, which is why
% I seek clarification). The best I can find is the DNSEXT meeting notes
% from IETF 50:
% 
%  | Subject: draft IETF-50 DNSEXT meeting notes
%  |    Date: Mon, 9 Apr 2001 11:08:57 -0400 (EDT)
%  |    From: Olafur Gudmundsson <[email-masked]>
%  |      To: DNSEXT mailing list <[email-masked]>
% 
%  | IPv6 DNS transition and deployment: Rob Austein
%  | - Problems: two complete IPv6 DNS Address record solutions
%  |   - One standard, other deprecated
%  |   - Known implementations using deprecated one
%  |   - Becoming issue for IPv6 deployment
% 
%  | - Need to have transition plan to get from AAAA to A6.  Will require
%  | protocol things, like synthesizing AAAA records.
% 
%  | - Overview of A6 transition plan
%  |   - Use A6 in zone files
%  |   - Anything that needs AAAA is assumed to be stub resolvers and we
%  |     synthesize it
%  |   - No AAAA in root or TLD zones
% 
% Also, wasn't ipv6.int moved to ipv6.arpa?
% 
% -- 
% Eric A. Hall                                        http://www.ehsco.com/
% Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
% 
% 
% to unsubscribe send a message to [email-masked] with
% the word 'unsubscribe' in a single line as the message text body.
% 

-- 
--bill

---

From: Bill Manning <[email-masked]>
Date: Sun, 6 May 2001 07:28:52 -0700 (PDT)

[ an error in elisp here caused a previous posting of this message as if it
  came From: me.  it did not.  my apologies.  - rb ]

% 

-- 
--bill

---

From: Paul A Vixie <[email-masked]>
Date: Sun, 06 May 2001 10:36:46 -0700

>  been supported since Bind 4.9.6.

Boy oh boy is *my* face red.  I took RFC 1886 at face value when it said
"Standards Track".  I remember the DNSIND meeting where Sue presented it
and there were a couple of area directors there and the question was "is
nybbles the best we can do?" and everybody stared at everybody else and
the consensus seemed to be "uh, yeah."

I'm not sorry that I implemented RFC 1886, since much operational 
experience has been gathered as a result.  However, I am very sorry that
I took a full decade to understand how IETF politics work and to realize
that NOTHING is EVER over, even AFTER the fat lady has sung her heart out.

>  The same folks who depricated AAAA w/o any alternative ...

I dunno man, A6 looks like a proposed alternative and it was part of the
document where AAAA was deprecated.

---

From: Randy Bush <[email-masked]>
Date: Sun, 06 May 2001 11:44:51 -0700

> that NOTHING is EVER over, even AFTER the fat lady has sung her heart out.

what you ran up against was well-dcumented process, not politics [0].  a
meeting does not define wg consensus, and a *proposed* standard is just
that, i.e. not a standard.

specifically,

rfc 2418, 3.2. Session venue

   Each working group will determine the balance of email and face-to-
   face sessions that is appropriate for achieving its milestones.
   Electronic mail permits the widest participation; face-to-face
   meetings often permit better focus and therefore can be more
   efficient for reaching a consensus among a core of the working group
   participants.  In determining the balance, the WG must ensure that
   its process does not serve to exclude contribution by email-only
   participants.  Decisions reached during a face-to-face meeting about
   topics or issues which have not been discussed on the mailing list,
   or are significantly different from previously arrived mailing list
   consensus MUST be reviewed on the mailing list.

rfc2026, 4.1.1  Proposed Standard
   ...
   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

[ 1602-3, which the above two obsoleted, had similar text ]

otoh, the v6/dns (and dnssec) community has often wavered in making our
vision and corresponding tactics clear.  and this has not always been
kind to implementors.  thanks for hanging in.

randy

---

[0] - though i define 'politics' as what happens in life when more than
      one person is involved.  i.e. real life.

---

From: Paul Vixie <[email-masked]>
Date: 06 May 2001 23:26:15 -0700

> that, i.e. not a standard.

if, in 1995, potential ipv6 vendors and users had been told that AAAA was
just the current thinking and that it could well be deprecated before ipv6
reached any kind of wide use, the reaction would've been "oh, a research
toy -- sounds like fun, we'll check in on you again in a few years to see
if you're closer to implementation yet."

instead, the words "standards track" were used.  no matter that rfc1602
says, the Intended Political Impact of those words is to fool, um, i mean
"convince" various people into thinking that the protocol is worth their
trouble to implement, productize, or deploy.

the Full Truth of this axiom was brought to me by a very interesting
messenger.  i wasn't convinced by the "must use RSA" then "must use DSA"
conflicting mandates out of the dnssec crowd.  (angry, yes; despondant, no).
rather, it was the day someone crept into an ipngwg meeting and proposed
that the packet format be changed to put the destination address first, so
as to make cut-through routing happen 6 octets sooner in the frame.  oh,
sure, the proposal was understandable -- there are ivory tower wannabes in
every crowd and ietf has at least its share.  no.  the Full Truth which led
to my current Despondance regarding ietf Politics came from the fact that
this was *debated*.  *seriously* *debated*.  on *technical* grounds.  OUCH!

after that, A6 vs AAAA is no big deal.  for that matter, after everything
we've all seen, switching back to AAAA and announcing that ipv6 will have
no quick renumbering features after all, would be Merely Par For The Course.

the above defense, that the standard was merely proposed, simply seeks to
pave over the raw unpleasant truth that it will NEVER be Truly Safe to
implement, productize, or deploy dnssec (are we using NXT, or NO, or neither?
and is it still DSA this week, or are we back to RSA, or is it something else
now?) or ipv6 (what WILL the packet format be, finally (if that word even
makes any sense), and will it end up, after 10 years of what will have been
transformed into well intentioned lies, giving operators the choice of either
carrying 2^64 routes in the core, or insisting that customers be locked in?),
or anything else.

to be Truly Safe, implementors must simply implement *everything* -- just in
case this is the version that the ietf decides to stop dicking with, and
operators must make full plans to deploy *anything* -- just in case.

> kind to implementors.  thanks for hanging in.

as far as i know, ietf is still the only game in town.  there is hope, though.

---

From: Bill Manning <[email-masked]>
Date: Mon, 7 May 2001 02:09:57 -0700 (PDT)

% >  The A6 RFC depricates AAAA, however, the authors did this w/o any A6
% >  support being available. Some is starting to emerge but it is very
% >  slow. AAAA clearly has the edge in the installed base, since it has
% >  been supported since Bind 4.9.6.
% 
% Boy oh boy is *my* face red.  I took RFC 1886 at face value when it said
% "Standards Track".  I remember the DNSIND meeting where Sue presented it
% and there were a couple of area directors there and the question was "is
% nybbles the best we can do?" and everybody stared at everybody else and
% the consensus seemed to be "uh, yeah."
% 
% I'm not sorry that I implemented RFC 1886, since much operational 
% experience has been gathered as a result.  However, I am very sorry that
% I took a full decade to understand how IETF politics work and to realize
% that NOTHING is EVER over, even AFTER the fat lady has sung her heart out.
% 
% >  The same folks who depricated AAAA w/o any alternative ...
% 
% I dunno man, A6 looks like a proposed alternative and it was part of the
% document where AAAA was deprecated.

This from some private email. Names are elided. My comments are inset.
----------------------------------------------------------------------------
% 
% so it is deprecated? or was the deprecation deprecated?

        when the A6 rr type is a full standard, AAAA will be deprecated.
        until then, things are just claims of what some people think
        ought to happen.
---------------------------------------------------------------------------

that said, I'm still in favor of A6 over the AAAA record, if push comes
to shove.

--bill

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 07 May 2001 08:43:02 -0500

[ first, it was bill who said it, not i.  second, can we move this to some
  list or newsgroup which is not restricted to protocol topics?  much of
  it looks appropriate for poisson.  last approval of this political stuff.
  -- rb ]

Randy, by saying "the authors" and then "the same folks" you give
onlookers the impression that the authors of 2874 chose ip6.arpa.
You know yourself that this is not the case.

---

From: Ian Jackson <[email-masked]>
Date: Mon, 7 May 2001 15:04:07 +0100 (BST)

Randy Bush writes ("Re: AAAA/A6 thing"):
>  The A6 RFC depricates AAAA, [...]

No, it does not.  From rfc-index:

 1886 DNS Extensions to support IP version 6. S. Thomson, C. Huitema.
      December 1995. (Format: TXT=6424 bytes) (Status: PROPOSED STANDARD)

NB, not HISTORIC.  From RFC2874:

 Network Working Group                                        M. Crawford
 Request for Comments: 2874                                      Fermilab
 Category: Standards Track                                     C. Huitema
                                                    Microsoft Corporation

Note lack of Obsoletes: 1886.  Also, in rfc-index:

 2874 DNS Extensions to Support IPv6 Address Aggregation and
      Renumbering. M. Crawford, C. Huitema. July 2000. (Format: TXT=44204
      bytes) (Status: PROPOSED STANDARD)

Again, no `(Obsoletes: )'.

RFC1886 is not deprecated, is widely implemented and used, works well,
supports all the requirements[1] just as well as 2874.  Surely it
meets all the requirements for advancing to Draft Standard ?

[1] *Including* the renumbering requirement as I understand it.  This
is easy to do server-side.  If we need to make it easier eg to make
zonefiles with indirection for the prefix more portable between
implementations then ipngwg should write a requirement and we can
write a MUST implement extension to the zone file format.

Ian.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 7 May 2001 16:37:28 +0200 (CEST)

> I seek clarification).

I think the intent was to have RFC 2874 (A6) obsolete or at least
update RFC 1886 (AAAA) but, if that was the intent, the document
didn't have the annotations of "Update:" or "Obsoletes:" that would
make the rfc-index.txt say anything of that sort.

The only hint is the actual text in 2874
   This memo proposes a replacement for the specification in RFC 1886
   [AAAA] and a departure from current implementation practices.

So in effect it looks like we have two proposed standards at the moment,
which I don't think was the intent at the time.

   Erik