[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Jun-ichiro itojun Hagino <itojun@iijlab.net>
cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se
From: Robert Elz <kre@munnari.OZ.AU>
Date: Wed, 15 Aug 2001 21:31:35 +0700
In-Reply-To: <20010815123411.E40457BA@starfruit.itojun.org>
Sender: owner-dnsop@cafax.se
Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary

    Date:        Wed, 15 Aug 2001 21:34:11 +0900
    From:        Jun-ichiro itojun Hagino <itojun@iijlab.net>
    Message-ID:  <20010815123411.E40457BA@starfruit.itojun.org>

  | 	we (pick any community i'm involved with) are already operating AAAA
  | 	in a lot of places.

Fine.

  |	we need to keep those configuration to work fine
  | 	while we migrate to A6 + AAAA synthesis.

Of course.

  |	you have
  | 	been proposing a migration path with a hard "flag day",

No I haven't.   What I said was that I can change my AAAA records to
A6 records any time I like.   I can simply delete my AAAA records and
not replace them at all any time I like.   You will never notice, I'm
quite sure that you don't care in the least about my few AAAA records.

For any new systems I can install only A6 records - while you're only
doing AAAA lookups you won't find them.  You won't find them now while
they have no v6 records at all either...  Either way, you cope.

  |	- all existing zone files must be rewritten to from AAAA to A6 in one
  | 	  night (of which timezone?)

No, I didn't say anything like that.   I said that a server could convert
(or a human operating a server could), I didn't ever claim that it all
has to happen at once, there's no reason for that.

  | 	- all AAAA queriers can stay as is, but there has to be AAAA synthesis
  | 	  server at every leaf

Eventually, yes.   In the short term, one used as a forwarder anywhere
(one per ISP would do just fine).

  | 	- no AAAA traffic in core DNS cloud, only A6 traffic.

That's not a requirement, just a target.   It will probably never be
reached.   But who cares?   There are probably MB queries out there in
the net now, somewhere, no-one cares about those either.

In another message you asked (Nathan Jones I think, but I will answer anyway)

  | 	how long do you think it will take, and how many people do you think
  | 	get bitten by this? 

Time, depending upon how committed various people are, a month or two,
perhaps three.  It depends how urgent it is seen to be.

People, maybe 10K or so, perhaps realistically just a thousand.
Compared to the millions of internet users, almost no-one.

Of course, if you're one of the 10K (or 1K or whatever it is) then you're
going to suffer a bit - you'll have some extra work to do, and you might
want to maintain both AAAA and A6 for a while (you probably would,
I wouldn't).

That's extra work.   It is also a part of the price of being an early
adopter, which tends to hit everything new as it is being introduced.
You get the benefits of being among the first, you have to pay the costs
as well.

And in another message ...

  | 	what I have been arguing about is that, AAAA synthesis advocators
  | 	never mention about transition period like the above four lines. 

That's because it is kind of obvious.   Clearly the net that we have now
is going to have to transition (assuming A6 is selected).   You can read
my messages about how impossible that will be if left a few years as
implying that I don't think this is a trivial exercise, even now.  It isn't.
But it is manageable now.  It can be done.   We could even do it in stages,
ask everyone to put A6 records in their servers wherever AAAA records exist.
Then when we see (by querying the servers that we care about) that has been
done, we can install A6->AAAA synthesis resolvers.  Then when we see that
the number of AAAA queries hitting our servers has dropped to an acceptably
low level (which each of us can define individually), remove the AAAA
records from our servers.    Allow 3 weeks for the first step, and then
everything is self timimg (we each proceed at our own pace).

  | 	wait, AAAA synthesis is a transition tool to A6,

You can view it that way - but it is also possible to view it as
simply a part of the infrastructure, the same way that TSIG/AD is
a part of the DNSSEC infrastructure.   Allow end nodes to do just
simple things (if they want, they can always do A6, or full dnssec,
if they prefer - most won't) forever.  Nothing transition about it.

  |	and we need a transition period to move to AAAA synthesis?

Yes, but this isn't hard.

  |	what is the merit of doing such a complex thing?

It isn't complex.   It is simple.   It gets us to a much more
flexible DNS RR - one which incidentally (aside from all the other
benefits) means we need just N+M RR's in the DNS (and answers)
rather than N*M for every node (where N is the number of interfaces
a node has, and M is the number of prefixes).  That may very well
allow UDP queries to continue to work in situations (especially major
serves - which are what most people want to reach) that AAAA would
require TCP be used instead (ie: the 1280 (or 512 for basic v4 transport)
bytes of DNS packet will hold much bigger A6 RRsets - sanely designed -
then it will AAAA RRsets).

eg: for AAAA, in a 512 byte packet, you can fit (maybe, if you're
lucky and the name isn't too long) 27 RRs.   If you have 4 providers,
then the max addresses for a node before you get TC problems is 6.
That's pretty limiting...   With A6, you could probably fit 20 addresses
for the node (and the 4 providers).   This is one of the things the
tests I am about to start doing will measure...  If you're using many
addresses to get load balancing, this matters.

kre



Home | Date list | Subject list