Re: (ngtrans) Possible AAAA Record Transition Strategies

[Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group <[e-mail]>]

Harald,

>- 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 its draft-ietf-ipngwg-dns-lookups-02.txt 

>Now it's a transition issue.

Agreed.

>QUESTION 1: What is the current state?

>- Fact: AAAA records exist.

Yes.

>- Possibility 1: Deployed code that uses AAAA only exists, and is
>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).

>- Possibility 2: Deployed code that uses AAAA only exists, but can be
>                 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.

>QUESTION 2: What is the desired final state?

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