Subject: (ngtrans) Possible AAAA Record Transition Strategies

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 17 Sep 1998 12:00:45 +0200

I'm repeating this message because the previous one didn't elicit
*any* suggestions about what the answers ought to be.
We've got agreement (I think) that these are the questions.
But we can't build networks out of questions. We need answers.
Come on, folks! Shoot!

                   Harald A

---------------------------------------------------------------------

OK, now we're settled (I think):

- The One True Draft is draft-ietf-ipngwg-dns-lookups-01.txt
- The One True Record Type is "A6"
- The IPNG WG has agreement that they want "A6" to be deployed.

Now it's a transition issue.

QUESTION 1: What is the current state?

- Fact: AAAA records exist.
- Possibility 1: Deployed code that uses AAAA only exists, and is
prohibitively
                 expensive to update
- Possibility 2: Deployed code that uses AAAA only exists, but can be
                 updated at reasonable cost to A6 given enough time

QUESTION 2: What is the desired final state?

- Possibility 1: Only A6 records exist in the DNS
- Possibility 2: Some sites have A6 records, some sites have AAAA records
- Possibility 3: Some sites have A6 records, all sites have AAAA records
- Possibility 4: All sites have A6 records, some sites have AAAA records

I sure hope we're not aiming for 2.....

QUESTION 3: What are the intermediate states between now and the final state?

No suggestions.

                 Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Thu, 17 Sep 1998 07:33:59 -0400

> - Fact: AAAA records exist.

Agreed.

>  prohibitively  expensive to update

The issue isn't "cost to upgrade", it's can we have a single flag day
where everyone changes over, or things break.  Given that IPv6 is
shipping in some products today, I think it is unrealistic to have a
single flag day, unless we are willing to simply make the current AAAA
format flat-out obsolete and break for folks that are using them
today.

Is this necessary or a Good Thing?

>                  updated at reasonable cost to A6 given enough time

We should certainly assume that existing AAAA implementations can be
phased out over a period of time. If we can't do this, it raises
questions about whether we should even do A6.

> - Possibility 1: Only A6 records exist in the DNS

This would clearly be the desired end point. Having two ways in the
DNS for doing name -> v6 mappings would be an undesirable thing.

> QUESTION 3: What are the intermediate states between now and the

One idea I've heard discussed is just bury the AAAA vs. A6 question in
the resolver. Applications shouldn't care. For a transition period,
folks can have a resolver that does both/either AAAA queries and/or
A6. During the "transition" both could be used. Once enough folks have
move to A6, the AAAA support can be removed.

Big reality check here. No DNS code today supports the new A6 record
type. So getting A6 records deployed will not happen overnight and
talking about having a single flag day with no coexistence seems a
non-starter.

Thomas

---

From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group <[email-masked]>
Date: Thu, 17 Sep 1998 11:12:41 -0400

Harald,

>- The IPNG WG has agreement that they want "A6" to be deployed.

Now its draft-ietf-ipngwg-dns-lookups-02.txt 

Agreed.

>- Fact: AAAA records exist.

Yes.

>prohibitively expensive to update

Yes this will be a fact and not just on the 6bone, but we can change our
resolvers as vendors so AAAA or A6 is transparent.  It should be
transparent to applications calling getipnodebyname or getipnodebyaddr
(new API adjuncts for IPv6).

>                 updated at reasonable cost to A6 given enough time

I would say can be made to be upgraded to take into account AAAA and A6
record types and then at some future time vendors would declare support
for AAAA records at the resolver is gone.  But the code to carry around
supporting both AAAA and A6 in a BIND resolver is not a big deal.

>- Possibility 1: Only A6 records exist in the DNS

Some day this will be the case but it will take time and will depend on
the deployment rate of IPv6.

>- Possibility 2: Some sites have A6 records, some sites have AAAA records

If someone does not deploy IPv6 until lets say the year 2000 they will
have no need of AAAA types as A6 types will be possible and implemented.

>- Possibility 3: Some sites have A6 records, all sites have AAAA records

This will happen once the vendors can ship A6 types and they can be
supported.

>- Possibility 4: All sites have A6 records, some sites have AAAA records

This will happen as A6 types are deployed moving towards possibility #1.

>I sure hope we're not aiming for 2.....

I don't think we should "aim" for that but the market will point the gun
that way because deployment will start before we can even do A6 types in
our code bases as this is going to take at least 18 months to get
debugged and working in BIND as one example.

>QUESTION 3: What are the intermediate states between now and the final state?

State 1:

   Deploy IPv6 with AAAA records today.  This is where NGTRANS would
   say we must use the previous AAAA record work RFCs for now and 
   those RFCs should be made to "Historical Status" with a caveat 
   from this working group that they will be used in State 1 but
   see State 2-4 below.  Or some such statement from the ngtrans 
   group to the Internet community at large.

State 2:

   Vendors start working on code base support for A6 and the one
   true draft and relative other specs listed by IPng and DNSIND.  
   This I predict will take 18 months.  I think we could probabaly see
   interoperability testing of this work at UNH events by the summer
   of 1999 with a little probing.

State 3:

   Work on what type of implementation scenarios must exist at a  
   DNS server and resolver to make sure this is all transparent
   to the APIs calling DNS at the application layer.

     -  At the server should we synthesize the A6 types to AAAA
        type for AAAA only aware resolver?   
     -  Or have the resolvers synthesize the A6 to AAAA types.

   My vote and plea is don't do that at the resolver.  Way too 
   much work for desktop machines do it at the servers...I can
   support this more if need be but will stop for now.

State 4:

    Users can now begin to change their DNS database to support 
    A6 types and delete AAAA types and it will be transparent
    to the IPv6 "aware" applications and IPv6 will keep on ticking
    without interruption.  This will be the transition to possibility
    #1 above.

I agree with Tom a flag day to turn on A6 records will not work and flag
days are always bad anyway.  Even if no one deploys IPv6 or NOT the
above default will be possibility #1 anyway.  This way we have a win-win
scenario from the IETF.  If you deploy you get there and if you don't
deploy to get there by default.

But I am not clear how or what the IETF ngtrans group can do to assist
States 2 and 3 above.  We could discuss an architecture for the
algorithms as NUD did in Neighbor Discovery conceptional model of ND in
IPv6 where the states are laid out pretty clear.  But it would have to
be a conceptual model and should be very close to real psuedo code. I
also think if ngtrans did this it would not be stepping on the toes of
IPng or DNSIND WG's.  But then any work like this should be run by
entities like BIND Workers, Internet Software Consortia, and the work on
DNS at Microsoft as they are building a DNS implementation too.

What should the IETF NGTRANS group do to support State 4?

I think the answer to the above is to document the states and the issues
and the results of analyzing states 2 and 3 via the implementors of DNS
listed above.

/jim

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 18 Sep 1998 17:57:19 +0200

>   support this more if need be but will stop for now.

Those who know me know that I'm terribly eager to jump to conclusions
at times, this time even trying to make the Jim-and-me chorus into
a consensus, but still:

I think that in the short run, a DNS server that has A6 records in
its databases and is asked for an AAAA record will have to synthesize
that AAAA record. No other deployment scenario makes sense to me.

This means that:

- A6 records shouldn't be installed in "production" IPv6 environments
  until the DNS severs have the A6-to-AAAA synthesis code in place
- There is no need for the resolver library to do the synthesizing,
  because either it asks for A6 and does the Right Thing, or it asks
  for AAAA, and the DNS server does the Right Thing.

Can we call this a consensus?

                       Harald, jumper to conclusions

---

From: [email-masked]
Date: Fri, 18 Sep 1998 09:25:46 -0700 (PDT)

> Is this necessary or a Good Thing?

	Good question. 
	
> questions about whether we should even do A6.

	How long did it take to kill WKS records?
	
> DNS for doing name -> v6 mappings would be an undesirable thing.

	Then killing off  A records should be considered as well.

> move to A6, the AAAA support can be removed.

	Getting a new resolver deployed is not simple.
	This was the single most significant reason why
	ip4.int as a replacement for in-addr.arpa did not 
	fly.

> talking about having a single flag day with no coexistence seems a

	True.

--bill

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 18 Sep 1998 14:03:24 -0500

>   until the DNS severs have the A6-to-AAAA synthesis code in place

I would modify this to say that the AAAA records shouldn't be
removed, rather than that the A6 shouldn't be installed.  The -02
draft mentions the possibility of using A6, then running a script
which creates AAAA records in the zone file for compatibility.

>   for AAAA, and the DNS server does the Right Thing.

Recall also that an A6 query is defined to do type A & AAAA
additional section processing.  That should be a transition plus as
well.
				Matt

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 18 Sep 1998 22:50:04 +0200

>which creates AAAA records in the zone file for compatibility.

that's one implementation of AAAA synthesis.

What I'm looking for is some way of stating that we don't want
a situation where a client asking for an AAAA record won't get an
answer, but a client asking for an A6 record does get one.

                 Harald A