Subject: Re: qtype addr scorecard

From: Danny Mayer <[email-masked]>
Date: Tue, 27 Aug 2002 21:53:52 -0400

At 01:26 PM 8/21/02, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= 
wrote:
>I don't know much about Windows, but in my understanding, (at least
>some previous versions of) winsock does even not have the support of
>IPv4-mapped addresses (as described in RFC 2553).

According to the documentation that I have Windows XP and later supports
4 types of compatibility addresses: ISATAP, 6to4 (RFC 3056), 6over4
(RFC 2529) and IPv4 compatible ( ::w.x.y.z). The supported getaddrinfo()
is only available on XP and later.  I don't expect any of this to be available
on WNT, W2K or any of the Win9x O/S's even with MSR's IPv6 stack or
the Win2K Technology Preview, though I could be wrong.

Maybe one of the Microsoft people could comment.

Danny

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 19 Aug 2002 10:23:59 -0500

End-of-thread summary. Based on arguments made so far, a qtype ADDR would
be provably better than the existing qtype ALL, and would also be bettter
than the include-A-with-AAAA alternative.

A qtype ADDR would be slightly better than distinct queries for AAAA
followed by A, although it would be a disadvantage during any transition
period, and the resulting savings are small enough to make the benefit
unworthy of the cost. However, if a sufficient number of people end up
using qtype ALL as an alternative to double lookups, the transition costs
of qtype ADDR will have been worth it.

Paul's proposal for multiple questions is provably better due to its
generalized nature (capable of asking for MX as well as AAAA+A, for
example). That spec doesn't currently address the weird scenarios that can
occur from multiple answer types within a single message so I don't think
it's viable in it's current form. Once those descriptions and rules were
added, however, I would endorse it completely. Under the assumption that
this work will eventually happen, and given that it is more flexible, I
think that's where any subsequent discussion should focus. IMO, of course.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Robert Elz <[email-masked]>
Date: Mon, 19 Aug 2002 23:41:18 +0700

Date:        Mon, 19 Aug 2002 10:23:59 -0500
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | End-of-thread summary. Based on arguments made so far, a qtype ADDR would
  | be provably better than the existing qtype ALL,

Two comments on that - first, from 1035, the qtype you mean (value 255) is
* not ALL.   If it is to be represented with a name, using ANY would be a
better, as that's what it actually retrieves.

And second, being better than that qtype (however it is styled) is
precisely equivalent to being better than nothing, as qtype *
doesn't work at all for this, or any other non-debugging purpose.

  | and would also be bettter than the include-A-with-AAAA alternative.

As a summary, I fail to see where that came from.   A a protocol mod
A with AAAA makes little sense.   As an implementation hack it is just
fine (the only issue to be dealt with is making sure implementations can
handle A records in the additional section of a NODATA type response,
ie: one where the rcode==0 and answer count == 0).

Because A with AAAA can be done as an implementation hack, and backed out
the same way, it has essentially no costs.  If we assume that nodes query
for AAAA before A (which most seem to do), then it means just one round
trip to the auth server to load the cache while nodes have A records.
When nodes stop having A records, the benefit will tail away, but then
the AAAA records that were returned will generally be sufficient, and the
later A query will become rare.

  | A qtype ADDR would be slightly better than distinct queries for AAAA
  | followed by A,

I'm not sure about that even.   Look carefully at how a cache would
be supposed to implement ADDR.   If it does an ADDR query, and gets
just AAAA (or just A) records in the answer, how long can it cache the
fact that there were none of the alternative?   There's no SOA in there
from which a negative cache value might normally be taken.   Most probably
it can't add the negative cache at all.   That means that a subsequent query
to the same cache is going to either result in the same ADDR query repeated
(cache effectiveness== 0), or perhaps reading the draft very carefully,
a query for the type that wasn't cached.   Assuming the latter, two queries
to the cache will result in two queries to the auth server, which is
exactly what would have resulted from two AAAA and A pairs of queries to
the cache.   So the only time ADDR could be better is when nodes have both
AAAA and A.

  | although it would be a disadvantage during any transition
  | period, and the resulting savings are small enough to make the benefit
  | unworthy of the cost.

I agree with that part.

  | However, if a sufficient number of people end up
  | using qtype ALL as an alternative to double lookups, the transition costs
  | of qtype ADDR will have been worth it.

I'm not sure if that's suggesting we should do ADDR just in case
someone is dumb enough to try qtype *, or whether it is saying that
after we see people using qtype * we'll be lamenting the lack of
qtype addr.

In either case, since I forsee zero use of qtype * for this purpose,
I don't think it matters.

  | Paul's proposal for multiple questions is provably better due to its
  | generalized nature'

Yes, if we can get that right, we can get plenty of benefits, not just
for IPv6 transition, but all over the place.

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 19 Aug 2002 13:20:06 -0500

on 8/19/2002 11:41 AM Robert Elz wrote:

> As a summary, I fail to see where that came from.   A a protocol mod A
> with AAAA makes little sense.   As an implementation hack it is just
> fine (the only issue to be dealt with is making sure implementations
> can handle A records in the additional section of a NODATA type
> response, ie: one where the rcode==0 and answer count == 0).

No, that's not the only issue. Additional issues include the potential for
message overload which can result from unsolicited extraneous data, and
future potential problems with specifications that have AAAA as additional
section processing. It's a bad idea.

> for IPv6 transition, but all over the place.

Let's move on this, and leave the other options behind, then.

---

From: Greg Hudson <[email-masked]>
Date: 19 Aug 2002 15:27:54 -0400

On Mon, 2002-08-19 at 14:20, Eric A. Hall wrote:
> message overload which can result from unsolicited extraneous data

This is a previously solved problem.  Any time you might want to put an
RR set in the additional section (for any reason), you check if you will
overflow the packet, and if you will, you don't put the records in.

> and

I don't understand this issue.  Almost anything we do seems like it will
work out okay.  (Putting in A records when you put in AAAA records,
putting in A records only when you don't have any AAAA records to put
in, etc.)

[About multiple queries:]
> Let's move on this, and leave the other options behind, then.

That's reasonable, though if we run into a wall on EDNS1, I think
remembering A-in-additional would be worthwhile.

---

From: Robert Elz <[email-masked]>
Date: Tue, 20 Aug 2002 20:31:18 +0700

Date:        Mon, 19 Aug 2002 13:20:06 -0500
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | No, that's not the only issue. Additional issues include the potential for
  | message overload which can result from unsolicited extraneous data,

This is simply silly.   First because of Greg Hudson's answer (this is
already a non-problem - at worst it would be equivalent to not implementing
the proposal, and an extra query happens) - but more significantly, if
AAAA and A records aren't going to fit in the same packet, how can ADDR
possibly work (or even a dual query with EDNS1)?   You'd have TC responses
all over the place, which is much worse than "just do an extra query".
In practice, unless you're looking up the NS list for ".", this is just
a non-issue (and that one is an issue for AAAA ignoring the A records...)

  | and
  | future potential problems with specifications that have AAAA as additional
  | section processing.

Huh?   I haven't gone back to check, but I thought that 1886 already
said that anything that requires A additional section processing, also
requires AAAA additional section processing.    And I certainly can't
imagine a specification ever (until A is just a zombie) requiring AAAA
additional section processing without A.

That is, it is already the case, that if you do a MX lookup, and discover
that
	mailsystem.example.com.
is the MX target for some domain or other, you will already get both A
and AAAA records for mailsystem in the additional section (assuming the
server has them to give, of course).

  | Let's move on this, and leave the other options behind, then.

Fine.

Just remember that A with AAAA doesn't require any movement here.   Nothing
has to be specified for that to be done - no protocol work at all.   This
is something that some implementations can simply decide would be a good idea,
and go implement it.   I kind of suspect there's been enough discussion of
it now that any implementors who feel the need can already be doing it.
If none do, that's OK...

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Aug 2002 09:44:08 -0500

on 8/20/2002 8:31 AM Robert Elz wrote:

> significantly, if AAAA and A records aren't going to fit in the same
> packet, how can ADDR possibly work (or even a dual query with EDNS1)?

EDNS can handle a larger message.

ADDR and EDNS both allow the sender to specifically request it, meaning
they can be prepared for it.

A system that does it sometimes but doesn't do it other times and which is
not controllable by the requester and which is undocumented is the worst
of the options.

> Just remember that A with AAAA doesn't require any movement here.

You keep saying this like it's a feature, when sympotmatically it amounts
to a bug.

---

From: Greg Hudson <[email-masked]>
Date: 20 Aug 2002 12:55:04 -0400

> not controllable by the requester and which is undocumented is the worst

But we already have that for, say, A records in the additional section
of an MX answer.  That's the whole point of the additional section. 
Simply claiming that it is the "worst of the options" isn't a very
strong argument when you can't demonstrate that it's bad.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Aug 2002 12:43:52 -0500

> strong argument when you can't demonstrate that it's bad.

This is not an applicable precedent. The A RRset which is returned in
response to an MX answer is (1) documented by the canonical specification
for MX, (2) can be expected from all servers, (3) can be expected by all
clients, and (4) has additional requirements when truncation occurs which
is also documented in the canonical specification (notably, that the NS
glue takes precedence in the truncated answer).

The just-include approach is not represented by (1), (2), or (3), and can
arguably be claimed not to mesh with (4) although I won't make this
argument at the moment.

> strong argument when you can't demonstrate that it's bad.

I only need to demonstrate that it is worse than qtype ADDR. There are two
arguments in support of this position.

First is that just-include increases the overall complexity because it
puts a burden on the servers without removing a burden from the clients
(the clients cannot rely on the presence of the information since it is
optional, and therefore must either continue issuing multiple queries, or
be tempted to use qtype ANY). Conversely, the qtype ADDR approach puts
complexity on servers but it removes complexity from the client. [both
analysis assume that deployment is widespread]

Secondarily, the nature of an undocumented server-side option makes
pointing to bugs impossible. What if they include the A data but not the
delegation glue in a truncated answer. Where is it written that they would
be wrong to do this? How can we prove otherwise?

[Bonus] DNS is fragile already. Introducing new functionality pretty much
requires that the end-points negotiate extended features. Undocumented
optional extensions which may or may not be present without client having
requested the extension is just begging for trouble. It is the worst
possible option, IMO.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 20 Aug 2002 20:43:38 +0200

> glue takes precedence in the truncated answer).

I'm not sure what the argument is here, but if you mean that a client
can simply assume it will receive A records for mail servers when
asking for MX, I don't think that approach works in the real world.

Consider for instance a server for the zone example.org returning the
MX's for example.org, say mail.foobar.net and www.barfoo.net.  The
server for example.org may not know the IP addresses for
mail.foobar.net and www.barfoo.net, so it doesn't include them.  A
client shouldn't break because of this.  Is this scenario invalid
according to some specification?  Which?

---

From: Greg Hudson <[email-masked]>
Date: 20 Aug 2002 15:00:10 -0400

> glue takes precedence in the truncated answer).

As Simon pointed out, (2) and (3) are false, so you're pretty much left
with (1).  If you want to argue that "just include" should be formally
documented before implementation, then I won't disagree loudly, though I
don't particularly agree either.

> I only need to demonstrate that it is worse than qtype ADDR.

No, you need to demonstrate that it is so much worse than qtype ADDR as
to outweigh the caching problems of qtype ADDR.  (For instance, as kre
pointed out, if you do a qtype ADDR and get only A record replies, how
long can you cache that there are no AAAA records?  There is no SOA, so
you have no idea.)

Even if these problems can be solved, the solution would almost
certainly put a much larger burden on servers than "just include A
records in AAAA queries" does.

> Conversely, the qtype ADDR approach puts

It takes a long time before deployment is so widespread as to allow
clients to stop having to fall back to AAAA and a queries.  About as
long as the IPv6 migration, if that ever happens.

> be wrong to do this? How can we prove otherwise?

(Technically, I don't think the answer would qualify as "truncated.")  I
don't find this issue compelling, but again, I wouldn't disagree with an
effort to document the idea.

> [Bonus] DNS is fragile already.

Not really.  It's an old and bizarre standard, but that doesn't really
make it fragile.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Aug 2002 14:52:35 -0500

> long can you cache that there are no AAAA records?  There is no SOA, so

How is just-include better here? I mean, qtype ADDR can be patched to
include SOA with the statement that the value applies to any missing
RRsets, and since all available RRsets would be returned, a client would
know what that means.

You can't do this with an optional undescribed tag-along service. Missing
RRsets could mean that (1) the data doesn't exist but since there's no
formalized way to indicate NODATA treat it like the cache isn't playing
along, or (2) the cache really isn't playing along. In either scenario the
just-include approach requires a followup query EVERYTIME the data isn't
provided. I would also argue that since clients aren't expecting this data
they will probably throw it away whenever it is provided (the resolver
won't have anything to pass it to or through). The complexity is twice as
large with just-include as it is with qtype ADDR.

> long as the IPv6 migration, if that ever happens.

Granted, which is why I said that qtype ADDR is a wash in comparison to
separate queries. The opposition is using the end-game of pure v6, not me.
Unfortunately for them, the end-game is more efficient with qtype ADDR,
since applications can STOP USING IT and just issue qtype AAAA when they
get there.

> Not really.  It's an old and bizarre standard, but that doesn't really

There are a lot of opportunites for problems, is all. cf the bind 9.2
comment made by paul.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Aug 2002 14:59:00 -0500

>>clients

> asking for MX, I don't think that approach works in the real world.

No, the argument is that clients know that it may be provided, they are
ready for it, they know what to do when it arrives. This is different
mindset from a just-include approach, where the data may show up sometimes
but not others, without being requested.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 20 Aug 2002 22:17:05 +0200

> but not others, without being requested.

MX is almost an just-include approach.  There are no guarantees it
will happen.  The application must be ready to query for MX's
addresses.  If the server happens to include some IPs in the first
reply, the application may optimize things and use that data, although
prudent resolvers may not want to do so anyway in some cases (think
cache corruption).

The only difference I can see is that there is text in a specification
suggesting servers to include A records when returning MX, to allow
for this optimization.  A similar recomendation for A/AAAA could be
written, and would perhaps even be a good idea -- I'm annoyed by the
doubled DNS delays in modern applications (queries for both A and
AAAA).  IMHO this path seems easier to get to work than a new QTYPE.

---

From: David Terrell <[email-masked]>
Date: Tue, 20 Aug 2002 16:09:25 -0700

> but not others, without being requested.

Can you posit or demonstrate a scenario where an application doing
a lookup for AAAA and getting an A record in the extra section would
be harmful?  Assuming we're specifying new, optional behavior and
that as always they can fall back to a second A query (as is done
today) -- the ADDR query seems more harmful, as it will result in
THREE round trips in the likely case of a remote resolver not
supporting it (one error, one AAAA, one A).  A in the extra data
results in no additional round trips if it's not supported.

What happens if you make an EDNS1 multiple question query and the
remote side (forwarder or authoritative server) doesn't support
ENDS1?  Three round trips?  That doesn't seem like a reasonable
upgrade path.

-- 
David Terrell            | Q. Is C an acronym? 
[email-masked]             | A. Yes, it stands for ``C''. It's another
Nebcorp Prime Minister   |    of those funky recursive acronyms.
http://wwn.nebcorp.com/  |  - "Infrequently asked questions in comp.lang.c"

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Aug 2002 19:37:57 -0500

on 8/20/2002 6:09 PM David Terrell wrote:

> Can you posit or demonstrate a scenario where an application doing a
> lookup for AAAA and getting an A record in the extra section would be
> harmful?

Again, I only have to prove that it is the worst.

> Assuming we're specifying new, optional behavior and that as always they
> can fall back to a second A query (as is done today)

Correction, will almost certainly always fallback, since even in those
situations where the A RR was provided, the application won't have
expected it. Heck, some resolvers may not even pass it along to the
application since it wasn't part of the question. The leftover benefit is
that the cache will have the data on hand to issue the next query, but
this by itself does not make anything operate more efficiently. Remember,
this is the scenario at peak deployment, and not just during deployment,
since this is being flogged as voluntary.

> ADDR query seems more harmful, as it will result in THREE round trips
> in the likely case of a remote resolver not supporting it (one error,
> one AAAA, one A).

> remote side (forwarder or authoritative server) doesn't support ENDS1?
> Three round trips?  That doesn't seem like a reasonable upgrade path.

During deployment yes, at peak no. We have deployed new RRs before (MX).
We are early enough into the IPv6 deployment to do this.

---

From: Robert Elz <[email-masked]>
Date: Wed, 21 Aug 2002 14:21:55 +0700

Date:        Tue, 20 Aug 2002 12:43:52 -0500
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I only need to demonstrate that it is worse than qtype ADDR.

No you don't, as they're not alternatives.   We could do ADDR, if we
thought it worth the effort, and still have servers supplying A when
they get an AAAA query.   If ADDR really took off, then there would be
essentially no AAAA queries, so it wouldn't matter one way or the other.
On the other hand, if clients don't bother implementing ADDR, because
it means an extra RTT waiting for the NOTIMPL error, because relatively
few deployed servers support it, then the AAAA+A approach can have some
benefits.

You can't just assume full (or close to it) deployment - there has to be
an implementable path to get us there.   That is, you somehow have to
convince resolvers to start doing ADDR queries while few servers
support the thing, otherwise they'll never appear (upgrading servers
takes a long time, upgrading resolvers takes an eternity).

  | First is that just-include increases the overall complexity because it
  | puts a burden on the servers without removing a burden from the clients

True, as has been stated before - but the aim of all of this is to
reduce the burden on the network, not on either implementation.  DNS
servers and resolvers are complex beasts now, the extra complexity to
add in A's is negligible (the code for it already exists, it just
needs to be run in one more case).   The resolver better be able to
handle the answer already, even if it just means ignoring the A's.
If resolver implementors start to see that A's are appearing with the
AAAA replies, then they will take advantage of that.

  | Conversely, the qtype ADDR approach puts
  | complexity on servers but it removes complexity from the client. [both
  | analysis assume that deployment is widespread]

Unless you assume universal deployment (which will not happen) the client
still has to be able to deal with the one old server out there which does
not implement ADDR, so it still needs the fallback logic.

  | Secondarily, the nature of an undocumented server-side option makes
  | pointing to bugs impossible. What if they include the A data but not the
  | delegation glue in a truncated answer. Where is it written that they would
  | be wrong to do this? How can we prove otherwise?

If the specs say that the delegation info should be provided, then it
should be.   If there is available glue for that, it can be included as
well, but in one of these queries, it never has to be, and in general,
is completely useless anyway.   That is needed in referals, it isn't
otherwise.

I just did an AAAA lookup for munnari.oz.au.   It happens that I got
an AAAA answer, and I got A records for munnari.oz.au in the additional
section.   (You might even imagine a server that was implemented by
someone with lots of foresight, as the server there hasn't changed since
well before this idea was floated...)

Of course, the reason for those particular A records is that munnari.oz.au
is in the NS list for itself, so the A records were part of the delegation
glue.   But, not all of the delegation glue A records were provided.
oz.au has 4 servers, there were addresses in the answer I received for only
3 of them (I am doing this query from nowhere near munnari, so this is the
kind of thing that anyone else would see).

The A records in the answer don't seem to be breaking anything... (whether
or not resolvers take any notice is a different issue).   The lack of
the glue record for the 4th server breaks nothing.

For the record, here is the answer...

; <<>> DiG 8.3 <<>> munnari.oz.au. aaaa 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 6
;; QUERY SECTION:
;;      munnari.oz.au, type = AAAA, class = IN

;; ANSWER SECTION:
munnari.oz.au.          10M IN AAAA     2001:388:c02:4000::1:21

;; AUTHORITY SECTION:
oz.au.                  1d6h49m59s IN NS  mulga.cs.mu.oz.au.
oz.au.                  1d6h49m59s IN NS  dmssyd.nsw.cmis.CSIRO.au.
oz.au.                  1d6h49m59s IN NS  munnari.oz.au.
oz.au.                  1d6h49m59s IN NS  ns.UU.NET.

;; ADDITIONAL SECTION:
mulga.cs.mu.oz.au.      7h24m23s IN A   128.250.1.22
mulga.cs.mu.oz.au.      7h24m23s IN A   128.250.37.150
dmssyd.nsw.cmis.CSIRO.au.  5h36m14s IN A  130.155.16.1
munnari.oz.au.          1d6h49m59s IN A  128.250.1.21
munnari.oz.au.          1d6h49m59s IN A  128.250.22.2
munnari.oz.au.          10M IN AAAA     2001:388:c02:4000::1:21

;; Total query time: 475 msec
;; FROM: delta.cs.mu.OZ.AU to SERVER: default -- 172.30.0.9
;; WHEN: Wed Aug 21 14:13:23 2002
;; MSG SIZE  sent: 31  rcvd: 279

(and yes, this was done from deep inside a NAT'd area of the net, so the
local cache has a 1918 address...)

[Aside: the AAAA glue record there looks like a bug, I thought the
practice of repeating answers in the additional data section had been
squashed long ago...]

  | [Bonus] DNS is fragile already.

What fragility the DNS has all comes from configuration problems
(in the past some from implementation bugs, but that's less common now).
Nothing here is changing anything related to how operators run their
DNS servers, so nothing is likely to impact on whatever fragility you're
seeing.

There are two arguments that an implementor might choose to use for
not bothering to implement this (aside from just "I can't be bothered"
which is OK too).

One is based upon Paul's comment - if you believe that caches aren't
going to remember the A records, then the potential benefit drops.
It doesn't vanish though - the answer (complete with additional info)
will still get sent back to the requesting client.   In cases where
the same info is requested again, the cache won't have the A's, and
will need to fetch them.   The cache is less effective than it could
be, but we still get just 2 queries out of the cache, for data which
is apparently being required multiple times.

On the other hand, if it is a one off (queries needed less frequently
than the TTL of the RRs) then what the cache does is immaterial anyway,
and getting the A along with the AAAA could halve the number of these
queries to the remote servers.

That's going to mean there's a judgment issue, and once again, implementors
get to decide what they want to do (and then users get to decide which
server they will deploy).

The second reason why one might not bother with implementing this is
more compelling though I think, but it depends upon the behaviour of
resolvers.   Currently, I believe, most resolvers end up doing an AAAA
query, and then when that fails (no AAAA records are returned, I don't
mean NXDOMAIN or similar) they retry with an A query.   That means
2 RTT's to get the answer (three if they start with ADDR...).
If that's what ends up being "normal" then AAAA+A looks attractive.

On the other hand, resolvers could issue the AAAA and A queries more
or less simultaneously (two queries one after the other, I don't mean
EDNS1 here).   If that's what resolvers do, so they get the answer
back in 1 RTT, then AAAA+A is useless, the AAAA answer with A records
would only get back at about the same time as the A answer anyway.

But in any case, I have no idea why you're bothering to argue against
this.   Implementors will make their own decisions (probably based upon
customer demand).

kre

---

From: Markku Savela <[email-masked]>
Date: Wed, 21 Aug 2002 11:37:21 +0300

> From: Robert Elz <[email-masked]>

> section.

Instead of additional section, why not my other proposal: return IPv4
addresses in AAAA query as IPv6 addresses (ipv4 mapped format).

- there would be no problems with caching servers

- the answer set is always complete (the same DNS server will always
  have both A and AAAA data for the same name)

- there would be issue about what would current IPv6 implementations
  do, if IPv4 mapped addresses are returned for AAAA. I know mine
  would work just fine (as I already internally represent all IPv4 as
  IPv4-mapped). How about KAME? Microsoft?

AAAA query is relatively new and IPv6 stacks are still in developement
stage (and must be upgraded in near future anyway, becuase apparently
there are several drafts or changes in the pipeline, that will become
mandatory standards.. although I don't like some of them :-)

Thus, the handling of AAAA query could easily be changed to cope with
IPv4 mapped addressess, and to cope with existing old DNS

 - if host needs IPv4 address and AAAA reply didn't contain any IPv4
   addresses, it could issue the normal A query too.

 - further optimization, there could also be some flag or signal in
   the reply, that would say "there are no IPv4 addresses, there is no
   point trying A"

These are about the last moments to act on this. Very soon cell phones
will have IPv6 stacks and there will be millions of nodes doing
queries in some way, which will hard to change after the fact...

---

From: Robert Elz <[email-masked]>
Date: Wed, 21 Aug 2002 16:40:05 +0700

Date:        Wed, 21 Aug 2002 11:37:21 +0300
    From:        Markku Savela <[email-masked]>
    Message-ID:  <[email-masked]>

  | Instead of additional section, why not my other proposal: return IPv4
  | addresses in AAAA query as IPv6 addresses (ipv4 mapped format).

I think this has the same problem as all of the proposals to have
server created on the fly RR data - it doesn't work at all well with
dnssec.

Not certain about Microsoft, but KAME doesn't much like IPv4 mapped
IPv6 addresses I believe, and avoids them wherever possible... (one of
the KAME people might correct that if I'm wrong).

But if we really thought ...

  | Thus, the handling of AAAA query could easily be changed to cope with
  | IPv4 mapped addressess, and to cope with existing old DNS

I think we would have thought the same about A6, but apparently we
didn't...   (even the most ardent A6 supporters had given up on the
possibility of having the clients ever use it - already too late).

I don't follow the cell phone industry, but are they planning to put
dual stack in their phones, os just IPv6.   It is such a specialised
market, and such a large one, that they could do v6 alone, and force the
rest of the world that cares to communicate to simply support v6.

Doing v4 would require NAT, which would seem to be very ugly for mobile 
devices.

If they're only doing v6 then they're just going to want AAAA queries,
and methods to get A answers to them simply wouldn't matter.   If...

kre

---

From: Markku Savela <[email-masked]>
Date: Wed, 21 Aug 2002 13:14:56 +0300

> rest of the world that cares to communicate to simply support v6.

Currently there is no IPv6 in real use, but there is GPRS with iPv4. Thus
support for IPv4 is required. Future plans apparently call for IPv6,
thus that too must be supported.

So, by default the dual stack is the way to go, it will work in both
or mixed environments.

---

From: Derek Atkins <[email-masked]>
Date: 21 Aug 2002 10:39:40 -0400

> addresses in AAAA query as IPv6 addresses (ipv4 mapped format).

Dynamic construction of responses: BAD.  How do you sign it?

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Aug 2002 16:06:04 +0000

> they get an AAAA query. ...

Gentlemen, you have both been heard to say that the EDNS1 ("QDCOUNT>1")
solution appeared viable and would be a good generic solution to this
problem.  Could we do a little deeper into that topic, and let the
alternatives ("just send A" and QTYPE=ADDR) drop for now?

Who thinks EDNS1 isn't ready for last call?  OK, state your issues --
that is, tell us all how the document should be improved.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 22 Aug 2002 02:26:56 +0900

>>>>> On Wed, 21 Aug 2002 11:37:21 +0300, 
>>>>> Markku Savela <[email-masked]> said:

>> an AAAA answer, and I got A records for munnari.oz.au in the additional

In general, I think this idea is problematic.  Some people have

> - there would be no problems with caching servers

I'm not really sure about this.  Caching servers also (may) ask AAAA
RRs by themselves to follow referrals, and the answers would affect
their behavior.

>   IPv4-mapped). How about KAME? Microsoft?

I've not tested it, but according to the code, our getaddrinfo() built
with normal installation procedure seems to reject AAAA RRs that
specify IPv4-mapped IPv6 addresses.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Rob Austein <[email-masked]>
Date: Wed, 21 Aug 2002 13:53:54 -0400

> that is, tell us all how the document should be improved.

Apologies if this is already covered and I missed it (am a bit fuzzed
out by the head cold of the month), but don't QDCOUNT values greater
than one have the same general deployment problem as EDNS0 extended
labels?  That is, don't you have to upgrade every name server in the
resolution chain at least to EDNS0 before you can stop worrying about
getting back RCODE=1 ("Format Error")?  So we immediately run up
against the question of whether the problem we'd be solving is
important enough to be worth this kind of upgrade effort.  Yes I know
there are other reasons (eg, IPv6, DNSSEC) why old DNS software ought
to be upgraded anyway, but let's get all the issues out on the table.

On the plus side, the general approach here does at least attempt to
deal with the naming granularity problem directly, so I agree that
it's worth discussing in some detail whether we conclude that it's the
right answer or not.  I think, however, that it'd be premature to last
call this, because I don't think we yet have a crisp statement of the
problem we're trying to solve.

Backing up a bit to a more abstract level in an attempt to start down
the path towards a crisp problem statement: I think that, broadly
speaking, we have two choices when talking about the general issue of
applications that expect to need multiple RRsets with the same owner
name in quick succession:

1) We can take the approach that the application just asks for
   whatever specific RRset it needs, one RRset at a time, and assume
   that the DNS caching mechanism will do whatever it does but that
   optimization of the query process is not the client's problem; or

2) We can use an approach like what Paul is proposing in EDNS1 to let
   the client be more explict about what data it expects to need in
   the immediate future.

It would probably be worth reviewing the archives from the last time
that this draft came around; I don't know that there's anything there
that's particularly relevant to this discussion, but I'd rather learn
from history than loop.

Last, a nit in the current EDNS1 draft: the EDNS1 draft refers to the
LM flag, which is defined in the EDNS2 draft.  Based on what I think I
remember of Paul's theory about how the general EDNS framework should
evolve, I'd guess that this is just an editing oversight rather than a
deliberate cross dependency, but it would be good to confirm that.