Subject: (IPng 6451) Query: Performance analysis of AAAA vs A6 records?

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 13 Sep 1998 22:55:47 +0200

The IPNG WG seems to have decided that it wants to introduce a new record
type for IPv6 addresses called "A6", which has the property of recording
the site-designated suffix of an address rather than a whole address.

How to get that record type deployed is now an NGTRANS issue.

Questions for this community:

- When analyzing performance of the record types, what are the relative
  number of DNS queries expected for a client looking up an AAAA record
  and constructing an address from an A6 record chain?

- If the answer to the above depends strongly on the use of "additional
  information" in DNS answer packets, what is the average size of DNS
  responses expected when an A6 record is queried?

- Do the answers to the two above questions change when security
  implications are considered (cache poisoning, for instance)?

The context for which I'm asking these questions is to look at whether
it's an appropriate transition/coexistence strategy to ask a DNS server
to synthesize AAAA records when needed, removing the need to transition
clients, rather than asking clients to switch to looking for A6 records.

Apologies if these numbers/issues have been discussed to death earlier - 
yes, I'm too lazy to spend the night reading archives!

                         Harald A

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

--------------------------------------------------------------------
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: "Matt Crawford" <[email-masked]>
Date: Tue, 15 Sep 1998 10:30:15 -0500

> How to get [A6] deployed is now an NGTRANS issue.

I hope it settles onto one mailing list or another!  :-/

> Questions for this community:

I just submitted draft-ietf-ipngwg-dns-lookups-02.txt so I'll have a
go at your questions.

For background, draft-ietf-ipngwg-dns-lookups-01.txt should suffice,
if you globally replace AAAA by A6.  (There are more changes, but
that's a first-order approximation.)  I'm going to make up some
additional terminology for the purpose of this discussion.

	o A no-prefix A6 record will be one which contains a complete
	  IPv6 address and has prefix length = 0.

	o A chain of A6 records for a name "N" is a sequence which
	  starts with one owned by N has subsequent records owned by
	  the prefix name contained in the previous record.

	o A complete chain of A6 records is a chain which ends with
	  records having prefix length = 0.

>   and constructing an address from an A6 record chain?

We can talk about worst case or typical case.  The trouble is, the A6
system hasn't been built so any talk about typical case involves some
handwaving about the deplayment.  There are also several dimensions
along which the case can be bad or good.

One possibly-typical case:

	A stub resolver looks for the IPv6 address of www.example.com,
	sending its query to a recursive server which initially has
	nothing more useful than the root hints.

With AAAA only, the recursive server does this work:

	Q1 to root server, which happens to be a COM server too.  Gets
	back NS and glue for example.com.

	Q2 to a server for example.com, gets back desired AAAA records.

With A6 only, the recursive server does this work:
	Q1 to root server, as above, gets back NS and glue for
	example.com.  What is the glue?  For each server
	nsN.example.com, the minimum glue is a chain of A6 records
	from nsN.example.com up to and including one whose prefix name
	is not in example.com.  There's a new opportunity for shooting
	oneself in the foot here by having a later A6 in the chain
	point back into example.com.  Similar opportunities for foot
	wounds in the DNS already exist, so we can accept this new
	one, or declare that glue consists of complete chains of A6
	records.  For reasons discussed below, I'll assume that glue
	is complete chains.  So ...

	Q2 to a server for example.com.  If that server has processed
	any queries before this one, it will have complete chains of
	A6 records to return and the necessary information can now be
	returned to the resolver.

>   responses expected when an A6 record is queried?

It does depend on additional information, and the amount of such
information depends on the number of levels of address delegation
hierarchy there are.  So here comes the handwaving.  Let's suppose the
site connects to a retail ISP-A, which connects to a wholesale ISP-C,
which gets its space from a TLA-administering organization.  That's
four layers, counting the site's own.  And let's further suppose that
the site elects to break out subnets as a layer in the A6 structure
and "indirects" all the subnets to make it as easy as possible to
switch providers.  (See the draft, previous or current, for details.)

Then it takes all the following to form an IPv6 address
2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 for ns1.example.com:

$ORIGIN example.com.
ns1		A6 64 ::1234:5678:9ABC:DEF0	SUBNET-1.IP6
SUBNET-1.IP6	A6 48 0:0:0:1::			IP6
IP6		A6 48 0::0			EXAMPLE-COM.IP6.ISP-A.NET.
EXAMPLE-COM.IP6.ISP-A.NET. A6 40 0:0:0011::	A-NET.IP6.C.NET.
A-NET.IP6.C.NET.	   A6 28 0:1:CA00::	C-NET.ALPHA-TLA.ORG.
C-NET.ALPHA-TLA.ORG.	   A6  0 2345:00C0::

Totaling up the sizes and assuming standard compression only, the AAAA
format uses
	Owner +	fixed +	RDATA =	total
	2	10	16	 28
bytes for ns1's glue record.  Additional singly-homed nameservers
require another 28 bytes each.

Specification of the above glue records in the A6 format uses
	Owner +	fixed +	RDATA =	total
	2	10	35	 47
	15	10	28	 53
	2	10	38	 50
	38	10	29	 77
	15	10	35	 60
	21	10	17	 48
				---
				335

Local compression (draft-ietf-dnsind-local-compression-02.txt) cuts
the RDATA fields by 11+15+0+3+0+0 = 28 bytes, leaving 307 bytes.

But this size should not be multiplied by the number of nameservers.
An additional nameserver ns2.example.com, in a different subnet of the
same prefix, needs two additional A6 records as glue, occupying
(2+10+35)+(11+10+28) = 96 bytes with standard compression only, or
(2+10+24)+(11+10+13) = 70 bytes with local compression.

So it looks like this example, supposing just the two nameservers are
returned by the top-level server, with 12 bytes of DNS header, 21
bytes of question, 0 bytes of answer, 2x(2+10+6) of authority, and
335+96 bytes of additional data (total = 500 bytes) will seriously
push the envelope of the 512 byte limit for today's UDP DNS replies,
but it should easily fit within the 1280 byte minimum IPv6 MTU using
one of the proposals for larger DNS replies.

>   implications are considered (cache poisoning, for instance)?

I don't see how.

> clients, rather than asking clients to switch to looking for A6 records.

What I wrote in the draft you haven't seen yet was

    A server providing recursive service MAY be configurable to
    synthesize AAAA records from A6 records in response to clients' AAAA
    queries.

				Matt

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 16 Sep 1998 08:42:17 +0200

At 10:30 15.09.98 -0500, Matt Crawford wrote:

....<lots of very enlightening description deleted>

>>   implications are considered (cache poisoning, for instance)?

If badguy.com knows that goodguy.com has 123.ip6.isp-a.net in his
A6-record chain, AND that client resolvers reuse "additional" information
from unrelated queries, badguy.com could try to install a fake
A6 record for 123.ip6.isp-a.net into a client resolver, effectively
stealing traffic by modifying the AAAA records.

If the answer is "DNSSEC", we then have much more data that needs to
go across as "additional", alternatively more queries to fetch those data,
and the UDP-across-IPv4 DNS is in trouble.

I believe the internic.net redirect hack was solved by not placing so
much faith in additional info, but that might negatively impact the
ability of the DNS servers to cache, so might influence your scenarios
where you assume that the example.com DNS server has complete caches
of A6 chains to hand out; I don't know enough about DNS to be sure.

>    synthesize AAAA records from A6 records in response to clients' AAAA

But if clients are to be written to depend on this, it has to be a MUST.
Over to NGTrans....what's our desired end state?

Thanks again!

                            Harald

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 16 Sep 1998 09:53:31 -0500

> ..., badguy.com could try to install a fake A6 record for ...

Yes, that seems to me to be an update to a problem that already
exists, but I don't see how it affects "the answers to the two above
questions," which were "how many queries?" and "how big are the
answers?"

> ... 123.ip6.isp-a.net into a client resolver,

I think you said "client resolver" where you should have said
"intermediate server", but that doesn't make the issue go away.  It
does, however, admit the solution of a hard-working DNSSEC-aware
intermediate server using TSIG with its clients.

> of A6 chains to hand out; I don't know enough about DNS to be sure.

Is there a real DNS expert paying attention?  If not, I'll try
answering that if example.com's DNS server has those additional A6
records, it should have gotten them by specifically asking for them,
not as additional data.  But if somebody's spoofing non-secure DNS at
all, then I don't think you can say that answers are trustworthy
while additional info is not.

> But if clients are to be written to depend on this, it has to be a MUST.

While if clients are written to work either way, the site
administrator gets to choose.

> Over to NGTrans....what's our desired end state?

Does this topic need its own ad-hoc mailing list, with ipng, ngtrans
and dns people recruited to work on it?

				Matt