Subject: (IPng 6734) Re: DNS implementation of IPv6 A6 and other new features

From: [email-masked] (Peter R. Tattam)
Date: Fri, 13 Nov 1998 02:04:00 +1100

In article <[email-masked]> Robert Elz <[email-masked]> writes:
>From: Robert Elz <[email-masked]>
>To: [email-masked] (Peter R. Tattam)
>Cc: [email-masked]
>Subject: Re: (IPng 6729) DNS implementation of IPv6 A6 and other new features 
>Date: Fri, 13 Nov 1998 01:11:31 +1100

>    Date:        Thu, 12 Nov 1998 16:38:09 +1100
>    From:        [email-masked] (Peter R. Tattam)
>    Message-ID:  <[email-masked]>

>  | The initial AAAA only requires a single query which would be atomic

>Only if one presumes a dumb stub resolver using a smarter host to do the
>name resolution for it.   If the resolver is going to do the entire
>resolution on its own, it will need be able to do multiple queries to chase
>the NS records from the root to the zone of interest.

Um, wouldn't the number of queries potentially increase or am I 
misunderstanding the A6 scheme.

What's the relative percentage of dumb stub resolvers to smart ones out there. 
 I would suspect that the major of leaf sites use a single DNS server with a 
recursive call to their nearest DNS server to do the job of resolution, 
especially when the RFC mentions that it's the correct way to do things.   How 
well will existing DNS servers cope with the added demand from stub resolvers 
having to make repeated calls.  The traffic is commonly UDP, and might get 
really slow over PPP links.   In my resolver, I'm already doing repeated calls 
to cycle through the domain suffix list.   I don't do caching because I have 
to control memory utilization, and stale records can be a pain.  Best to let 
the DNS server handle that as it would do a better job.

My concern is that in my experience, the weakest link in TCP/IP is the name 
services.  If they slow down or break for any reason, they cause the most 
headaches.   I've had misbehaving DNS servers cause significant problems for 
ISPing.  Often you don't know there's a problem until other services start to 
break, or the customers start beating down your door.

>  | Also, while compression and the regular DNS method of string handling will 
>  | reduce the size of the queries it's likely to be larger than the equivalent 
>  | AAAA entry for the address.

>I think this is likely to just the opposite where it matters.    That is,
>for a minimal sized AAAA query, yes, it is possible that an A6 query might
>be larger.   But you can't know that an AAAA query will result in a minimal
>sized answer, so you need to allow for more than that.  Once the AAAA result
>starts getting potentially larger (that is, when there are multiple records
>to be returned), the likelihood is that the A6 result will actually be smaller
>than the AAAA response.   It seems to me that this is a good result - what
>happens to small responses, for which more space needs to be allowed anyway
>isn't so important, but keeping large responses smaller, so they will keep
>fitting in a UDP response, is important.

Has there been some real life analysis of this?  And how much CPU is the 
compression going to take, memory use to code the algorithm?  These are 
important at the low end of the scale for smaller machines..  IPv6 is being 
touted for the appliance market don't forget.

>  | Considering that resolution of names to addresses is one of the most 
>  | fundamental operations in the use in the internet, this may make or break
>  | the  adoption of IPv6 if it is insisted that we deply this system in
>  | favour of AAAA records.

>You mean instead of AAAA records.   All of these issues are judgement calls.
>Personally, I feel that the increased flexibility of A6, especially when a
>renumbering of a site is required, means that because A6 is used will make the
>whole thing practical in a reasonable way, especially for larger sites, and
>be one of the big selling points of IPv6 over IPv4.   I know I would hate to
>think about renumbering our site (the DNS is under the control of a diverse
>group of people) under v4, but with v6, and A6, where we could all simply defer
>to a single instance of the base (upper bits) part of the address, the
>DNS changes would be the easiest part of any renumbering, instead of one
>of the harder parts.

>  | I propose that if you insist on keeping the A6 structure, that it be used for 
>  | inter server communication and management while AAAA continue to be fully 
>  | supported at leaf sites, with servers performing the necessary translations.

>It isn't clear just what that would mean - DNS servers (as they are defined
>in the DNS) can't do it, for all kinds of reasons that we discovered when it
>was originally proposed that it be done exactly that way.

>However, I suspect that you really mean that the back end part of a
>stub-resolver / real-resolver split (the real resolver part) do the A6
>processing (as they do NS chain chasing, CNAME handling, etc) and return
>just a synthesised AAAA record to the stub resolver.    That might be
>a reasonable approach - the only difficulty is in having the back end part of
>the resolver knowing that the particular query it has received is for a
>stub resolver rather than a random query from some other source.  As things
>are currently done, there is no difference - all queries look the same.

>Perhaps if TSIG is in use (which it ought be between stub resolvers and
>their back ends, in the future) then that mighht be enough (the TSIG
>association can be configured that way) to provide this info, and the
>back end would know to allow AAAA records to be synthesised out of A6
>responses, and handed back complete.

Sorry, you'll have to enighten me on the acronym TSIG.

>kre

Your points are valid, and I fully understand the benefits of the A6 scheme 
from a management point of view.  My concern is that should my gut feelings 
about this be confirmed, it could set back the deployment of IPv6 further.

Just my extra 2 cents worth.

Peter

--
Peter R. Tattam - Managing Director          
Trumpet Software International Pty Ltd.
Phone: +61-362-450220     Fax: +61-362-450210
--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Fri, 13 Nov 1998 03:02:28 +1100

Date:        Fri, 13 Nov 1998 02:04:00 +1100
    From:        [email-masked] (Peter R. Tattam)
    Message-ID:  <[email-masked]>

  | Um, wouldn't the number of queries potentially increase or am I 
  | misunderstanding the A6 scheme.

There might be more queries, in some cases, yes - but it is "more" that
is important here, that it it isn't a change from a single query/response
to a complicated process, but a slight potential expansion of an already
complicated process (in general).  In many typical cases, all the necessary
data will be provided in exactly the same number of packets as occurs now
(where the names used in A6 responses are in the same domain, or a domain
served by the same server, as the name being sought).

  | I don't do caching because I have to control memory utilization,

For something which is mostly over PPP, I think that's a mistake - memory
is comparatively cheap these days, ppp bandwidth isn't - but that's an
implementation choice.

  | Has there been some real life analysis of this?

I'm not sure, it will certainly depend upon local configuration.

  | And how much CPU is the 
  | compression going to take, memory use to code the algorithm?

No, I think you miss the point.   There are no new algorithms, or magic
compressions.   The savings come because to get a large response, you're
getting multiple addresses (that's what makes the response larger than
normal).   For AAAA records, that means 128 bits of date for every address
being returned.   For A6, it will typically be 64 bits, an 8 bit count, plus
a reference to a name.   You'd normally expect that the names referenced
would be largely similar, and so regular DNS name compression will allow
the name part of the response to be quite short - with intelligent 
configuration it is likely that 4 bytes will be enough for most cases (32 
bits).   That means perhaps 104 bits per address (after the first perhaps)
rather than 128 bits.

Even better, if the reason for multiple addresses is that the site has
multiple prefixes, rather than, or in addition to, the host having multiple
interfaces (physical or logical), then there's an even bigger saving potential,
as instead of having an interfaces by prefixes product of AAAA records, you
end up with interfaces plus prefixes plus a couple A6 records - generating the
multiples of addresses is done inside the resolver, insteaad of all being
included in the packet.

That is, the bigger the response would have been, the more likely it will be
that A6 will generate packet space savings.

  | Sorry, you'll have to enighten me on the acronym TSIG.

Proposed method of achieving authentication between stup resolvers and
their back ends - if you consider that A6 is too comples for low end
resolvers, go look at what is required to implement DNSSEC.   It is going
to be important that DNS responses be authenticated, DNSSEC is how that is
done, but that is by no means trivial.  TSIG is a proposal to make 
authentication for low end stub resolvers possible (the back end of the
resolver does DNSSEC, and uses TSIG to the stub resolver).

See draft-ietf-dnsind-tsig-06.txt  - there are a couple of (comparatively
minor) issues left to be resolved, then this is due to be sent to IETF last
call - it is almost done.

kre