Subject: [BEHAVE] Review of draft-boucadair-behave-dns-a64-01

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Nov 2009 12:14:14 -0500

Dear colleagues,

I have read draft-boucadair-behave-dns-a64-01.  I have some comments.
This is a somewhat lengthy review, but I decided to post it anyway
because I think the draft touches on the fundamental questions of the
utility (and disutility, not to say harmfulness) of NAT64/DNS64.  If
you don't care about my views on A64, but want to see two alternatives
that could be integrated in to DNS64 if we really need this, then skip
to section 3, near the end.

To begin with, I am sympathetic to the concerns behind the proposal.
When it was first suggested to me that the DNS might be used to solve
v4-v6 interoperation, my reaction was that it was a bad idea precisely
because of the kind of issue the authors raise.  From a purist point
of view, any time you start mucking with data in the DNS, or adding
data that sort of works but that isn't quite right, you introduce a
pile of new failure modes that you ought not to be introducing.  The
authors have identified some of those failure modes peculiar to the
DNS64 arrangement combined with certain use cases.

Nevertheless, my overall view is that the proposal in the draft is not
a good idea.  It is effectively introducing a new kind of query that,
if deployed, will live a long time (maybe forever) on the Internet,
for as long as people are looking up AAAA records.  That seems to me
to be a high cost for what I regard as a low-value and short-term
benefit.

    1.  Is the problem this solves something that should be or can be
        solved?

To begin with, I am not sure I find the important use case terribly
compelling.

DNS64 relies on the fact that an IPv6-using host will query for AAAA
records when it is trying to resolve another host on the Internet.
The DNS64 function captures that AAAA lookup, returns a AAAA record if
there is one, and then proceeds to A records in order to see whether
it can generate a synthetic response.  

A similar, if ugly, expedient is used for sites that wish to provide
v6 access to a v4-only service: they just put a synthetic AAAA (that
is to say, "A v6 address they control") into the zone, and do nat64 at
athe site.  This case is slightly more problematic than the previous
one, for while client-end DNS64 functions can be used or not depending
on whether the client is provisioned with both v4 and v6 connectivity,
the target-site-published synthetic AAAA record looks just like any
other AAAA, even though the target host does not actually speak v6.
So v6-enabled hosts will almost always get the v6 answer (since almost
all of them ask for AAAA first).  The effect of this is that the NAT64
will be used even when v4-only transit could better be used.

Now, there are two things to say about this.  First, the draft is
quite concerned about the case where site-published synthetic AAAA
records cause clients to use NAT64 when they could have native v4
transit, with possible concomitant loss of functionality.  My overall
reaction to that is, "Tough."  The plain fact is that the NAT64
functionality is still a NAT, and if your application loses
functionality across NATs, then NAT64 is just a poor choice.  Don't
publish synthetic AAAA records for that application.  (If such advice
is not abundantly clear from the DNS64 document, please send text.  It
should be.)  In my view, the cost of clients using NAT64 when they
don't need to is just part of the cost of deploying with NAT64, and if
you don't like that there's an easy solution open to you: get v6
transit, and deploy your applications using IPv6.  NAT64 is supposed
to help make that less hard when applications, or hosts, or whatever,
simply can't be upgraded.  But it is not a really good long-term
strategy for v4/v6 interoperation, and we have to stop imagining that
it will be.  We similarly have to make those limitations plain to
potential deployers.  Many IT shops to this day remain completely
astonished at the damage their NATs do, and I think this is partly
because during the early adoption of NATs there was not enough
information that made it plain, "This is going to break all manner of
things you might want later to have working.  Don't be surprised."

The second is that, in the presence of A64-unaware caches, the
strategy does not provide the desired guarantees anyway.  For an
A64-unaware recursor serving an A64-unaware initiating host will just
get the AAAA record anyway, no matter what.  This results in a
first-mover problem: there's no benefit to deploying A64-aware
recursors if nobody has published A64 records; and there's no reason
to publish and maintain additional host records in case nobody is
going to ask for them.  But in both cases, there is a cost to using
the A64 functionality, so there's actually a disincentive to deploy
the proposed technology.  This brings us to the cost of the A64
proposal, which results from how it has to be used.

          2.  How A64 will actually work

To understand my worry, we need to unpack the real meaning of section
4.6 of the draft.  The section obscures what is in fact required to
make this proposal work.  For the long-term effect of adding A64 to
the DNS is that every AAAA lookup will require an A64 lookup too.
Over the long term (i.e. as IPv6 becomes widely deployed), what this
means is a doubling of host queries to the DNS, with an effective
retirement time of "never".

We have three classes of actors in the DNS chain that are relevant to
the A64 proposal.  The first is the initiating host.  It can either be
A64-aware, or not.  If it is A64-aware; then it must query first for
A64; if it gets no result, then for AAAA, then for A; but if it gets a
result, maybe for A or maybe it can do something clever to strip the
prefix and extract the v4 address.  Since it cannot know whether the
target site has published v4-mapped v6-records, it always has to ask.
(Worse, if the goal really is to avoid using NAT64 when v4 is
available, it might query for the A _anyway_ after querying for AAAA,
in order to try to see whether the AAAA is actually an A record "in
disguise".  Until A64-awareness is universal, a site operator that
wants to offer NAT64 has to publish synthetic AAAA anyway, and it
might not have published A64.  To be charitable, let's assume every
mapped-v4-publishing site decides to publish A64, and ignore this
issue.)  The reason the initiator has to query for the A64 first is
that it needs to know whether the AAAA record it would get will
contain a v4-mapped address, and make a decision on that basis.  (You
could reverse the order, of course, but it makes no difference: you
have to do both.)

The second actor is the recursive resolver(s) in the path between the
initiating host and the authority server.  This case is interesting
only if the initiator is A64-oblivious (if the initiator is A64-aware,
then the recursor will presumably just do what the initator needs.
Let's ignore for the moment the case where the A64-aware initiator
acidentally gets hooked up to an A64-aware DNS64 node, and suppose
that it works).  If the recursor is A64-oblivious, it will simply
query for the AAAA, just as the host did, and the v4-mapped address
will be what gets used.  If the recursor knows A64, however, on
receiving a AAAA query, it first needs to perform an A64 query; if
that returns an answer, it can either extract the v4 address in some
way, or just query for the A record.  If the A64 query does not return
an answer, then the recursor asks for a AAAA record.  The reason it
has to ask for A64 first is that it needs to know whether the AAAA it
might get is a "real" one or not.  As before, you could reverse this,
but you still have to do it.

But it gets worse.  The recursor now does not know whether the
initiating host is dual-stack or not.  Of course, it might implicitly
know (i.e. by configuration) because it is a recursor that only serves
the dual-stack hosts (this supposes that the recursors for an ISP's
dual-stack and v6-only customers are different pools.  I'll leave
aside the complications arising from different ISPs, one for v6 and
another for v4, being involved in this nightmare).  But depending on
whether it is serving dual stack hosts or NAT64-requiring hosts, it
has to follows different paths.  If it is serving dual-stack hosts,
then if it gets an A64 record, it returns the A record to the
initator.  If it is serving v6-only hosts, then it converts the A64
record into a AAAA record, and returns that instead.  Unless, of
course, the initator set the CD bit on the query, in which case the
conversion is not allowed, because the initator will notice the
tampering and reject the answer.  In the case of the CD bit being set,
the recursor instead has to ask for the AAAA record and return that
answer, instead.

Finally, we have the authority server at the target site.  There are
two configuration possibilities and three action possibilities here.
Either the authority server has only A64 records in its zone, or it
has A64 records and equivalent AAAA records.  If it has only A64
records, then it either has to do special processing when it receives
a AAAA query, and convert the AAAA into an A64 query; or it has to
return NOERROR with an empty answer for the AAAA query, and simply not
get the communication benefit of NAT64 that was the whole purpose of
the exercise in the first place.  In either case, signing (if desired)
needs to be done on the fly.  If it is configured with the equivalent
AAAA record, that is functionally equivalent to the special processing
action above, except that it imposes on the server administrator the
burden to keep the A64 record in sync with the AAAA record (and, of
course, increases the size of the zone (but eliminates the need to
sign on the fly).  It introduces a powerful new set of failure
conditions, where the A64 record and the AAAA record don't match.

I haven't really thought through the security implications of any of
this, but at first blush it seems to me that the A64 record is going
to offer another opportunity to inject DNS poison, since an attacker
is going to know something about the capabilities of a querying host
and will also automatically know what query is coming next.  This
makes DNSSEC even more important in the case of A64, yet A64 presents
another stumbling block for DNSSEC, since an initator that is DNSSEC
validating but A64 oblivious is either out of luck, or just going to
experience the issues that the A64 draft is supposed to solve.

In any case, it is plain that adding A64 awareness either to hosts, or
to recursors, or both will guarantee an additional query for every
single AAAA query, effectively until the end of time.  (You would need
to know that there are no more v4-only hosts offering NAT64 before you
could shut this off.  How would you learn that?)  Depending on its
deployment at a target site, the A64 RR either requires server-side
processing (convertying an AAAA query into an A64 query) or else
requires the operator to forego most of the benefit that was supposed
to come from NAT64, which is making v4-only networks available to
v6-only networks without having to upgrade everything on (or even
significant parts of) the Internet in a co-ordinated fashion.

    3.  Alternatives

Those of us working on the DNS64 draft asked at various DNS working
group meetings, "Should we have a way of identifying these synthetic
answers?" and received, "No," in answer, as far as the DNS people are
concerned.  However, if it is desirable to be able to identify the
synthetic answers in some way, then there are two obvious ways to do
so without requiring an additional query for every AAAA query.

    a.  Add the "base" A record to the Additional section

If a DNS64 server were to provide synthetic AAAA records and include
the corresponding A record in the Additional section, a DNS64-aware
querying client could take the presence of that A record as a hint
that there might be more to the answer than meets the eye.  It should
be able to extract the equivalent IPv4 address from the AAAA record,
and thereby infer that the AAAA is synthetic.  A dual-stack host could
then just use the A record instead.  A signficant disadvantage of this
approach is that the Additional section is the first thing to be
truncated when a response gets long, so it's possible that the
Additional section won't have the "base A" when it's needed.  In
addition, a site publishing statically-configured synthetic AAAA
records can do so with a bog-standard DNS server, and there'd be no
way to tell that the records are in fact synthetic, so such servers
wouldn't include the A record without some kind of additional work.

    b.  Use an EDNS0 option to signal DNS64 awareness

If we defined an EDNS0 option (call it the SY bit, for synthetic) to
signal DNS64 awareness, then either an initiator or a recursor could
signal its ability to understand DNS64.  A server receiving such a
signal could include the Pref64::/n in the answer using a new RRTYPE
(say, PREF64).  That prefix could then be stripped off the AAAA by
whatever node got the answer, and the resulting IPv4 address could be
used as appropriate.  One disadvantage of this approach is that it
requires participating nodes to upgrade in order to achieve the
functionality; but in fact, A64 also requires that, and so the effect
is no worse.  Moreover, it does not introduce new queries or anything
of the sort to the mix, so we aren't increasing the number of queries.

    4.  Conclusion

Even if this is a problem that needs to be solved -- a position that
is not obvious to me -- it is not plain that A64 solves it.  Even if
it does solve it, it solves it at a very great price, and a price that
will be paid long after A64 is broadly useful.  In any case, there are
other ways to solve the same problem, and they are less disruptive
than adding A64 to the DNS.  Therefore, I do not think the A64
proposal should be adopted.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Nov 2009 12:23:38 +1300

FWIW, I think either of these suggestions would have a better
chance of deploying than a new RR type. Think about the
ill-fated A6 record.

Incidentally, the draft doesn't mention whether reverse
entries are also needed.

   Brian

On 2009-11-07 06:14, Andrew Sullivan wrote:
...

---

From: Mark Andrews <[email-masked]>
Date: Mon, 09 Nov 2009 09:33:44 +1100

One could also publish prefixes via DHCP and insert them into to
address selection algorithms to de-preference these addresses.  This
should work for internal use and a ISP supplying a NAT64.  It also
provides a mechanism to push DNS64 back into the application for when
DNSSEC is in use.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 Nov 2009 10:29:15 +0900

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mark Andrews
> Sent: Monday, November 09, 2009 7:34 AM
> To: Brian E Carpenter
> Cc: Andrew Sullivan; [email-masked]
> Subject: Re: [BEHAVE] Review of draft-boucadair-behave-dns-a64-01
> 
> 
> should work for internal use and a ISP supplying a NAT64. 

That seems a reasonable thing for draft-chown-addr-select-considerations 
to consider (that document is proposing updates to RFC3484), which is
on the agenda for 6man.  I don't know if there are other proposals 
in 6man in the space of re-evaluating/expanding RFC3484.  6man agenda:
http://www.ietf.org/proceedings/09nov/agenda/6man.html

> It also

-d

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Nov 2009 04:00:11 -0500

> provides a mechanism to push DNS64 back into the application for when

This wouldn't solve the problem of any random site publishing DNS64
records, which is supposed to be one of the big advantages of the
draft.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 09 Nov 2009 22:20:36 +1100

> records, which is supposed to be one of the big advantages of the

Then it doesn't get optimised to IPv4 which isn't that big of an
issue.  This uss of NAT64 will mostly go away as software vendors
get their act together and will be relegated to supporting a few
legacy applications.  In the meantime they can deploy more NAT64
boxes in parallel if they are overwhelmed.

---

From: <[email-masked]>
Date: Mon, 9 Nov 2009 14:52:15 +0100

Dear Andrew, all,

Please find some answers inline.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Andrew Sullivan
Envoyé : vendredi 6 novembre 2009 18:14
À : [email-masked]
Objet : [BEHAVE] Review of draft-boucadair-behave-dns-a64-01

Dear colleagues,

Med/Eric: Thank you for your careful review. Just a clarification about an argument which is mentioned in your review: In fact there is a misunderstanding about how records are handled in the authoritative servers. In the draft an authoritative server will generate A64 records for IPv4-embedded IPv6 addresses but will not generate AAAA records for these addresses. So a host or a resolver needs to ask first for AAAA records. If an AAAA record is received there is no need to ask for A64 records. Moreover, with A64 records, IPv6-only hosts will generate exactly the same load on DNS server as dual-stack hosts. Dual-stack hosts ask first for an AAAA record. If they failed they ask for an A record. With A64 records, IPv6-only hosts ask first for an AAAA record. If they failed they ask for an A64 record.

This is a somewhat lengthy review, but I decided to post it anyway because I think the draft touches on the fundamental questions of the utility (and disutility, not to say harmfulness) of NAT64/DNS64.

Med/Eric: To be clear, our position is that we are for DNS64 proposal but it needs to be enhanced to solve some issues as discussed in the draft.

  If you don't care about my views on A64, but want to see two alternatives that could be integrated in to DNS64 if we really need this, then skip to section 3, near the end.

To begin with, I am sympathetic to the concerns behind the proposal.
When it was first suggested to me that the DNS might be used to solve
v4-v6 interoperation, my reaction was that it was a bad idea precisely because of the kind of issue the authors raise.  From a purist point of view, any time you start mucking with data in the DNS, or adding data that sort of works but that isn't quite right, you introduce a pile of new failure modes that you ought not to be introducing.  The authors have identified some of those failure modes peculiar to the
DNS64 arrangement combined with certain use cases.

Nevertheless, my overall view is that the proposal in the draft is not a good idea.  It is effectively introducing a new kind of query that, if deployed, will live a long time (maybe forever) on the Internet, for as long as people are looking up AAAA records.  That seems to me to be a high cost for what I regard as a low-value and short-term benefit.

Med/Eric: Arguable. It will last until no IPv4-only network is connected to the Internet. For instance, draft-boucadair describes how A64 records can be added to authoritative servers and therefore this may simplify further transition phase (e.g., removing those records). We have the same constraints as for removing A records.

To begin with, I am not sure I find the important use case terribly compelling.

DNS64 relies on the fact that an IPv6-using host will query for AAAA records when it is trying to resolve another host on the Internet.
The DNS64 function captures that AAAA lookup, returns a AAAA record if there is one, and then proceeds to A records in order to see whether it can generate a synthetic response.

Med/Eric: but draft-behave-dns64 describes in appendix B cases where both IPv4-mapped IPv6 address and native IPv6 can be returned in AAAA records. Then you need a "hint" for the selection of the appropriate record otherwise you will overload the translators even if native communications can be supported.

A similar, if ugly, expedient is used for sites that wish to provide
v6 access to a v4-only service: they just put a synthetic AAAA (that is to say, "A v6 address they control") into the zone, and do nat64 at athe site.  This case is slightly more problematic than the previous one, for while client-end DNS64 functions can be used or not depending on whether the client is provisioned with both v4 and v6 connectivity, the target-site-published synthetic AAAA record looks just like any other AAAA, even though the target host does not actually speak v6.
So v6-enabled hosts will almost always get the v6 answer (since almost all of them ask for AAAA first).  The effect of this is that the NAT64 will be used even when v4-only transit could better be used.

Now, there are two things to say about this.  First, the draft is quite concerned about the case where site-published synthetic AAAA records cause clients to use NAT64 when they could have native v4 transit, with possible concomitant loss of functionality.

Med/Eric: What about the multi-homing issue?

My overall reaction to that is, "Tough."  The plain fact is that the NAT64 functionality is still a NAT, and if your application loses functionality across NATs, then NAT64 is just a poor choice.  Don't publish synthetic AAAA records for that application.  (If such advice is not abundantly clear from the DNS64 document, please send text.  It should be.)  In my view, the cost of clients using NAT64 when they don't need to is just part of the cost of deploying with NAT64, and if you don't like that there's an easy solution open to you: get v6 transit, and deploy your applications using IPv6.  NAT64 is supposed to help make that less hard when applications, or hosts, or whatever, simply can't be upgraded.  But it is not a really good long-term strategy for v4/v6 interoperation, and we have to stop imagining that it will be.  We similarly have to make those limitations plain to potential deployers.  Many IT shops to this day remain completely astonished at the damage their NATs do, and I think this is partly because during the early adoption of NATs there was not enough information that made it plain, "This is going to break all manner of things you might want later to have working.  Don't be surprised."

Med: As an SP, we don't wont to break the service delivered to our customers. We would like to manage IPv6 transition in a smooth and transparent scheme to our customers. Introducing new breaking bricks wouldn't help to move to the IPv6-only scenario. We would like to have means to reduce the co-existence period of both IPv4 and IPv6 (OPEX and CAPEX concerns, skills, etc.).

The second is that, in the presence of A64-unaware caches, the strategy does not provide the desired guarantees anyway.  For an A64-unaware recursor serving an A64-unaware initiating host will just get the AAAA record anyway, no matter what.  This results in a first-mover problem: there's no benefit to deploying A64-aware recursors if nobody has published A64 records;

Med/Eric: I think this is not an issue as draft-boucadair proposes that A64 records can be added in authoritative servers. More concretely, we assume a two-step approach which solve the "first mover problem":
-       First NAT64 will be introduced mainly to serve new IPv6-only customers. NAT64 will be used to connect an IPv6 network to IPv4 internet. During this phase A64 records will be scarce, but new DNS64 able to convert A64 records to AAAA and A records to AAAA will be deployed. The main drawback of this phase is that the scope of the IPv4-mapped-IPv6 address is restricted and these IPv4-mapped-IPv6 address can not be exchange outside of the operator network.
-       In a second step: A64 records will be introduced in Authoritative DNS server and they can be used by DNS64 resolvers from step 1. The main benefit of this second step is that theses IPv4-embedded IPv6 addresses (i.e., A64) have a global scope and may be exchanged in referral (i.e., by applications).

 and there's no reason to publish and maintain additional host records in case nobody is going to ask for them.

Med/Eric: we have a guarantee that requests will be received: NAT64 boxes! This is a "hot plate" for IP network providers (perhaps other business cases to offer nat64 services can emerge) which will deploy DNS infrastructure to enable the delivery of IP connectivity services. The migration to IPv6 would be a grantee that those A64 will be received (especially coming from boxes managed by the IP network provider).

  But in both cases, there is a cost to using the A64 functionality, so there's actually a disincentive to deploy the proposed technology.  This brings us to the cost of the A64 proposal, which results from how it has to be used.

To understand my worry, we need to unpack the real meaning of section
4.6 of the draft.  The section obscures what is in fact required to make this proposal work.  For the long-term effect of adding A64 to the DNS is that every AAAA lookup will require an A64 lookup too.

Med/Eric: I'm afraid to not agree with this conclusion. Please see below an excerpt form the draft:

"Only AAAA records SHOULD be returned when AAAA only type is specified
   in the query.

   But during a transition phase, some hosts with IPv6-only connectivity
   may not be updated to perform A64 queries.  Specific IPv6 DNS
   servers, called DNS64 recursors, may be used to serve those hosts.  A
   DNS64 recursor may return an A64 record as a response to AAAA query
   if no AAAA record is available for the specified resource (A64
   records are converted to AAAA records in the answer).  This behaviour
   advocates for enhancing the chance for a communication to be
   established even through a translator).  DNS64 recursors SHOULD not
   be used by dual-stack hosts which do not support A64 query type.
   When A64 query type is received, only A64 record type MUST be
   Returned".

Over the long term (i.e. as IPv6 becomes widely deployed), what this means is a doubling of host queries to the DNS, with an effective retirement time of "never".

Med/Eric: Idem as above.

We have three classes of actors in the DNS chain that are relevant to the A64 proposal.  The first is the initiating host.  It can either be A64-aware, or not.  If it is A64-aware; then it must query first for A64; if it gets no result, then for AAAA, then for A; but if it gets a result, maybe for A or maybe it can do something clever to strip the prefix and extract the v4 address.  Since it cannot know whether the target site has published v4-mapped v6-records, it always has to ask.
(Worse, if the goal really is to avoid using NAT64 when v4 is available, it might query for the A _anyway_ after querying for AAAA, in order to try to see whether the AAAA is actually an A record "in disguise".  Until A64-awareness is universal, a site operator that wants to offer NAT64 has to publish synthetic AAAA anyway, and it might not have published A64.  To be charitable, let's assume every mapped-v4-publishing site decides to publish A64, and ignore this
issue.)  The reason the initiator has to query for the A64 first is that it needs to know whether the AAAA record it would get will contain a v4-mapped address, and make a decision on that basis.  (You could reverse the order, of course, but it makes no difference: you have to do both.)

Med/Eric: This is the aim of section 4.7. We think that a new query type would be useful to avoid this issue. This new query would be used to retrieve both A64 and AAAA records. A more generic proposal as currently discussed in dnsext mailing list would be solve this issue.

The second actor is the recursive resolver(s) in the path between the initiating host and the authority server.  This case is interesting only if the initiator is A64-oblivious (if the initiator is A64-aware, then the recursor will presumably just do what the initator needs.
Let's ignore for the moment the case where the A64-aware initiator acidentally gets hooked up to an A64-aware DNS64 node, and suppose that it works).  If the recursor is A64-oblivious, it will simply query for the AAAA, just as the host did, and the v4-mapped address will be what gets used.  If the recursor knows A64, however, on receiving a AAAA query, it first needs to perform an A64 query; if that returns an answer, it can either extract the v4 address in some way, or just query for the A record.  If the A64 query does not return an answer, then the recursor asks for a AAAA record.  The reason it has to ask for A64 first is that it needs to know whether the AAAA it might get is a "real" one or not.  As before, you could reverse this, but you still have to do it.

Med/Eric: Why? for A64-compliant recursors, the behaviour is as follows: a
   DNS64 recursor may return an A64 record as a response to AAAA query
   if no AAAA record is available for the specified resource (A64
   records are converted to AAAA records in the answer).

But it gets worse.  The recursor now does not know whether the initiating host is dual-stack or not.  Of course, it might implicitly know (i.e. by configuration) because it is a recursor that only serves the dual-stack hosts (this supposes that the recursors for an ISP's dual-stack and v6-only customers are different pools.  I'll leave aside the complications arising from different ISPs, one for v6 and another for v4, being involved in this nightmare).  But depending on whether it is serving dual stack hosts or NAT64-requiring hosts, it has to follows different paths.  If it is serving dual-stack hosts, then if it gets an A64 record, it returns the A record to the initator.  If it is serving v6-only hosts, then it converts the A64 record into a AAAA record, and returns that instead.  Unless, of course, the initator set the CD bit on the query, in which case the conversion is not allowed, because the initator will notice the tampering and reject the answer.  In the case of the CD bit being set, the recursor instead has to ask for the AAAA record and return that answer, instead.

Finally, we have the authority server at the target site.  There are two configuration possibilities and three action possibilities here.
Either the authority server has only A64 records in its zone, or it has A64 records and equivalent AAAA records.

Med/Eric: Our draft assumes that only A64 records are stored.

  If it has only A64 records, then it either has to do special processing when it receives a AAAA query, and convert the AAAA into an A64 query; or it has to return NOERROR with an empty answer for the AAAA query, and simply not get the communication benefit of NAT64 that was the whole purpose of the exercise in the first place.

Med/Eric: The draft says that at a first stage, an A64 can be returned when a AAAA query is received (only when no AAAA is stored).

  In either case, signing (if desired) needs to be done on the fly.  If it is configured with the equivalent AAAA record, that is functionally equivalent to the special processing action above, except that it imposes on the server administrator the burden to keep the A64 record in sync with the AAAA record (and, of course, increases the size of the zone (but eliminates the need to sign on the fly).  It introduces a powerful new set of failure conditions, where the A64 record and the AAAA record don't match.

I haven't really thought through the security implications of any of this, but at first blush it seems to me that the A64 record is going to offer another opportunity to inject DNS poison, since an attacker is going to know something about the capabilities of a querying host and will also automatically know what query is coming next.

Med/Eric: This is valid for all query types, right?

  This makes DNSSEC even more important in the case of A64, yet A64 presents another stumbling block for DNSSEC, since an initator that is DNSSEC validating but A64 oblivious is either out of luck, or just going to experience the issues that the A64 draft is supposed to solve.

Med/Eric: Yes, but the draft assumes that this should be a first stage deployment scenario. Once A64 is adopted, then this case is not anymore valid.

In any case, it is plain that adding A64 awareness either to hosts, or to recursors, or both will guarantee an additional query for every single AAAA query, effectively until the end of time.  (You would need to know that there are no more v4-only hosts offering NAT64 before you could shut this off.  How would you learn that?)

Med/Eric: When A64 are introduced in the authoritative servers, removing these records have the same issue as per removing A records.

  Depending on its deployment at a target site, the A64 RR either requires server-side processing (convertying an AAAA query into an A64 query) or else requires the operator to forego most of the benefit that was supposed to come from NAT64, which is making v4-only networks available to v6-only networks without having to upgrade everything on (or even significant parts of) the Internet in a co-ordinated fashion.

    3.  Alternatives

Those of us working on the DNS64 draft asked at various DNS working group meetings, "Should we have a way of identifying these synthetic answers?" and received, "No," in answer, as far as the DNS people are concerned.  However, if it is desirable to be able to identify the synthetic answers in some way, then there are two obvious ways to do so without requiring an additional query for every AAAA query.

If a DNS64 server were to provide synthetic AAAA records and include the corresponding A record in the Additional section, a DNS64-aware querying client could take the presence of that A record as a hint that there might be more to the answer than meets the eye.  It should be able to extract the equivalent IPv4 address from the AAAA record, and thereby infer that the AAAA is synthetic.  A dual-stack host could then just use the A record instead.  A signficant disadvantage of this approach is that the Additional section is the first thing to be truncated when a response gets long, so it's possible that the Additional section won't have the "base A" when it's needed.  In addition, a site publishing statically-configured synthetic AAAA records can do so with a bog-standard DNS server, and there'd be no way to tell that the records are in fact synthetic, so such servers wouldn't include the A record without some kind of additional work.

If we defined an EDNS0 option (call it the SY bit, for synthetic) to signal DNS64 awareness, then either an initiator or a recursor could signal its ability to understand DNS64.  A server receiving such a signal could include the Pref64::/n in the answer using a new RRTYPE (say, PREF64).  That prefix could then be stripped off the AAAA by whatever node got the answer, and the resulting IPv4 address could be used as appropriate.  One disadvantage of this approach is that it requires participating nodes to upgrade in order to achieve the functionality; but in fact, A64 also requires that, and so the effect is no worse.  Moreover, it does not introduce new queries or anything of the sort to the mix, so we aren't increasing the number of queries.

    4.  Conclusion

Even if this is a problem that needs to be solved -- a position that is not obvious to me -- it is not plain that A64 solves it.  Even if it does solve it, it solves it at a very great price, and a price that will be paid long after A64 is broadly useful.  In any case, there are other ways to solve the same problem, and they are less disruptive than adding A64 to the DNS.  Therefore, I do not think the A64 proposal should be adopted.

Med/Eric: We have two parts here: the problems to be solved and the solution space. The current draft describes both the problem and a solution candidate. Should we separate both parts and lets agree first on the issues, then analyse the solutions candidates?

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: <[email-masked]>
Date: Mon, 9 Nov 2009 14:58:48 +0100

Dear Brian,

At this stage, the draft does not discuss the reverse DNS. Do you have in mind a particular hurdle related to the use of A64?

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Brian E Carpenter
Envoyé : samedi 7 novembre 2009 00:24
À : Andrew Sullivan
Cc : [email-masked]
Objet : Re: [BEHAVE] Review of draft-boucadair-behave-dns-a64-01

FWIW, I think either of these suggestions would have a better chance of deploying than a new RR type. Think about the ill-fated A6 record.

Incidentally, the draft doesn't mention whether reverse entries are also needed.

   Brian

---

From: <[email-masked]>
Date: Mon, 9 Nov 2009 15:03:46 +0100

Dear Andrew,

Yes, this may solve the problem when the prefix used to build the IPv4-embedded IPv6 address is a WKP or an NSP belonging to the prefix managed by the underlying IP network provider. But this is not the exclusive case that we would have: the NAT64 box can be located in a remote realm.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Mark Andrews
Envoyé : dimanche 8 novembre 2009 23:34
À : Brian E Carpenter
Cc : Andrew Sullivan; [email-masked]
Objet : Re: [BEHAVE] Review of draft-boucadair-behave-dns-a64-01

One could also publish prefixes via DHCP and insert them into to address selection algorithms to de-preference these addresses.  This should work for internal use and a ISP supplying a NAT64.  It also provides a mechanism to push DNS64 back into the application for when DNSSEC is in use.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 10 Nov 2009 00:03:39 +0900

> [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Monday, November 09, 2009 6:00 PM
> To: [email-masked]

(Contrary to what the draft says,) I don't think a site, publishing an AAAA
record that points to their own translator (to cover the "the IPv6 Internet to
an IPv4 network" scenario), truely cares their translator will be "over-"used
by dual-stack nodes.  Dual-stack didn't happen (to any reasonable degree of
"happen") and due to v4 exhaustion we're going to have clients doing some sort
of BEHAVE scenario or clients doing some sort of Dual-Stack Lite scenario.

I had envisioned A64 being primarily useful for an ISP's own services, with
clients that it can control (e.g., mobile phones, DNS proxies built into CPE
devices).

-d

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Nov 2009 10:18:50 -0500

On Mon, Nov 09, 2009 at 02:52:15PM +0100, [email-masked] wrote: 

> authoritative servers. In the draft an authoritative server will
> generate A64 records for IPv4-embedded IPv6 addresses but will not
> generate AAAA records for these addresses. So a host or a resolver
> needs to ask first for AAAA records. If an AAAA record is received
> there is no need to ask for A64 records. Moreover, with A64 records,
> IPv6-only hosts will generate exactly the same load on DNS server as
> dual-stack hosts. Dual-stack hosts ask first for an AAAA record. If
> they failed they ask for an A record. With A64 records, IPv6-only
> hosts ask first for an AAAA record. If they failed they ask for an
> A64 record.

Then your other criterion fails: in order for this to work, all the
resolvers in the entire world need to be updated.  Otherwise, how does
a host that needs v6-only access to a v4-only host reach that host?

If your answer is that you put an A64-enabled recursor in front of the
authority server, this is no help: as far as anyone else in the world
can tell, you're just server DNS64-generated AAAAs.  In such a case,
A64 is a wheel that does no work.

> Med/Eric: but draft-behave-dns64 describes in appendix B cases where
> both IPv4-mapped IPv6 address and native IPv6 can be returned in
> AAAA records. Then you need a "hint" for the selection of the
> appropriate record otherwise you will overload the translators even
> if native communications can be supported.

The draft also says, "Don't do that."  I don't think people should do
it.  And indeed, part of the reason not to do it is because you might
cause people to use NAT64 when they shouldn't.  But note that the
alternatives I suggest would work just as well in this case.

> -       In a second step: A64 records will be introduced in
> -       Authoritative DNS server and they can be used by DNS64
> -       resolvers from step 1. The main benefit of this second step
> -       is that theses IPv4-embedded IPv6 addresses (i.e., A64) have
> -       a global scope and may be exchanged in referral (i.e., by
> -       applications).

To give you some understanding of the requirement you're imposing
here, there's currently a dispute going on over in DNSOP about whether
it is safe to introduce DNAMEs at the root.  One of the arguments
against them is that they're too new.  The DNAME specification,
RFC2672, dates from 1999, and DNAME has a backward compatibility mode
where CNAMEs are synthesized in order to deal with clients that don't
know about DNAME.  A64 doesn't offer such a compatibility mode, so it
will simply break for such users.

The basic problem you have here is that you want to solve a backward
compatibility problem (make v6-only hosts talk to v4-only hosts) by
introducing a new feature.  But the very fact that you want backward
compatibility means in itself that you can't just upgrade all the
hosts.  That means a new RRTYPE will not solve your problem, because
the only people who can use it are the ones who can upgrade.  If they
can upgrade, why not just move them to v6?

> Med/Eric: I'm afraid to not agree with this conclusion. Please see below an excerpt form the draft:

I _know_ that's what your draft says.  I claim you're wrong.  There's
no way to make the scheme actually work with the deployed software and
still achieve the goal of not having to upgrade everyone on the
Internet unless you sometimes hand a synthetic AAAA to someone who
asked for a AAAA.  You suggest that you'll reply with an A64 record to
a AAAA query; but that's no good, of course, because the client asked
for a AAAA and if it gets something else in the answer it's as likely
as not to throw it away as malformed.  So, you admit that you're going
to convert that A64 to a AAAA in the answer.  From the point of view
of a querying agent, there is actually no difference here between the
synthetic AAAA that comes from a DNS64 synthesizing from an A recor,
and the A64-munger that synthesizes the AAAA from the A64.  It's still
a AAAA record.

> Med/Eric: This is the aim of section 4.7. We think that a new query
> type would be useful to avoid this issue. This new query would be
> used to retrieve both A64 and AAAA records. A more generic proposal
> as currently discussed in dnsext mailing list would be solve this
> issue.

This is again the "upgrade everyone" answer in disguise.  Changing all
the DNS software on the Internet so that it can query for more than
one RR at the same time using an as-yet-unspecified mechanism is not
the way to quick deployment of cheap solutions intended to paper over
the fact that IPv6 deployment has not happened in time for v4
exhaustion.  The point of the work we're doing is supposed to be fast
and fairly easy deployment with few barriers.  Deploying a new query
type that likely requires server-side processing (and to work out the
not insignificant problem of what the caches do when they have a
partial answer) does not meet that requirement.

>    records are converted to AAAA records in the answer).

All you're doing here is moving around who has to make the
A64-in-case-AAAA query decision.  The DNS64 recursor needs to
instead.  _Someone_ has to.

> Med/Eric: The draft says that at a first stage, an A64 can be returned when a AAAA query is received (only when no AAAA is stored).

Yes.  So "special processing".  The first state will, I predict, never end.

> and will also automatically know what query is coming next.
> 
> 

How?

> Med/Eric: We have two parts here: the problems to be solved and the
> solution space. The current draft describes both the problem and a
> solution candidate. Should we separate both parts and lets agree
> first on the issues, then analyse the solutions candidates?

I'm reasonably content with the problem you described: I get why it's
a problem, and you're putting a finer point on my original impulse
that whenever you have funky data in the DNS you want to be able to
identify it in case it's relevant.  In this case, it turns out for
some applications it _is_ relevant, so the only question is how one
identifies the data, especially since part of the problem to be solved
is that the whole thing works without anyone else doing any upgrades.
A new RRTYPE doesn't solve that latter problem, so I think it has to
be discounted as a solution.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 9 Nov 2009 10:23:40 -0800

> can upgrade, why not just move them to v6?

Agreed

---

From: <[email-masked]>
Date: Mon, 9 Nov 2009 20:02:41 +0100

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Andrew Sullivan
Envoyé : lundi 9 novembre 2009 16:19
À : [email-masked]
Objet : Re: [BEHAVE] Review of draft-boucadair-behave-dns-a64-01

> hosts ask first for an AAAA record. If they failed they ask for an

Then your other criterion fails: in order for this to work, all the resolvers in the entire world need to be updated.  Otherwise, how does a host that needs v6-only access to a v4-only host reach that host?

If your answer is that you put an A64-enabled recursor in front of the authority server, this is no help: as far as anyone else in the world can tell, you're just server DNS64-generated AAAAs.  In such a case,
A64 is a wheel that does no work.

Med: The draft describes a scheme in which it is not required to update all resolvers, see http://tools.ietf.org/html/draft-boucadair-behave-dns-a64-01#section-3.2. Is there any harm with what is described there? BTW, a solution based on http://potaroo.net/ietf/idref/draft-bellis-dns-recursive-discovery/ (i.e., "DNS64.LOCAL.ARPA") can be used to retrieve the server that can answer to the A64/DNS64 queries.

> both IPv4-mapped IPv6 address and native IPv6 can be returned in AAAA 
> records. Then you need a "hint" for the selection of the appropriate 
> record otherwise you will overload the translators even if native 
> communications can be supported.

The draft also says, "Don't do that."  I don't think people should do it.  And indeed, part of the reason not to do it is because you might cause people to use NAT64 when they shouldn't.  But note that the alternatives I suggest would work just as well in this case.

Med: I read that. The pb I see is that IPv4-embedded IPv6 addresses will be used to populate DNS servers, even independently on the DNS64 proposal. The type of these addresses should be signaled somehow to avoid overload translators and also avoid failure (when no ALG are deployed in the core network), etc. 

> -       a global scope and may be exchanged in referral (i.e., by

To give you some understanding of the requirement you're imposing here, there's currently a dispute going on over in DNSOP about whether it is safe to introduce DNAMEs at the root.  One of the arguments against them is that they're too new.  The DNAME specification, RFC2672, dates from 1999, and DNAME has a backward compatibility mode where CNAMEs are synthesized in order to deal with clients that don't know about DNAME.  A64 doesn't offer such a compatibility mode, so it will simply break for such users.

Med: I'm aware of some limitations of A64 proposal, but the proposal still work with legacy servers and the DNS behaviour is the same for legacy nodes.  

The basic problem you have here is that you want to solve a backward compatibility problem (make v6-only hosts talk to v4-only hosts) by introducing a new feature.  But the very fact that you want backward compatibility means in itself that you can't just upgrade all the hosts.  That means a new RRTYPE will not solve your problem, because the only people who can use it are the ones who can upgrade.  

If they can upgrade, why not just move them to v6?

Med: But the hosts which will use A64 are IPv6-enabled! If you are talking about the remote hosts, other issues such us ensuring service continuity and to not disturb engineered/offered services (not to mention IS problems) may induce complications to move to v6 quickly.

> Med/Eric: I'm afraid to not agree with this conclusion. Please see below an excerpt form the draft:

I _know_ that's what your draft says.  I claim you're wrong.  There's no way to make the scheme actually work with the deployed software and still achieve the goal of not having to upgrade everyone on the Internet unless you sometimes hand a synthetic AAAA to someone who asked for a AAAA.  You suggest that you'll reply with an A64 record to a AAAA query; but that's no good, of course, because the client asked for a AAAA and if it gets something else in the answer it's as likely as not to throw it away as malformed.  So, you admit that you're going to convert that A64 to a AAAA in the answer.  >From the point of view of a querying agent, there is actually no difference here between the synthetic AAAA that comes from a DNS64 synthesizing from an A recor, and the A64-munger that synthesizes the AAAA from the A64.  It's still a AAAA record.

> type would be useful to avoid this issue. This new query would be used 
> to retrieve both A64 and AAAA records. A more generic proposal as 
> currently discussed in dnsext mailing list would be solve this issue.

This is again the "upgrade everyone" answer in disguise.  Changing all the DNS software on the Internet so that it can query for more than one RR at the same time using an as-yet-unspecified mechanism is not the way to quick deployment of cheap solutions intended to paper over the fact that IPv6 deployment has not happened in time for v4 exhaustion.  The point of the work we're doing is supposed to be fast and fairly easy deployment with few barriers.  Deploying a new query type that likely requires server-side processing (and to work out the not insignificant problem of what the caches do when they have a partial answer) does not meet that requirement.

Med: fair enough.

>    records are converted to AAAA records in the answer).

All you're doing here is moving around who has to make the A64-in-case-AAAA query decision.  The DNS64 recursor needs to instead.  _Someone_ has to.

Med: What do you mean by "state"? If your are referring to "first stage" of my previous answer, i recall you that we adopt the same behaviour as draft-behave-dns64.

How?

Med: I meant that if the attacker can get the request sent by the host, it can deduce its capabilities (e.g., v4, v6, dual stack). Are you talking about this kind of capabilities? If not, I admit that I missed your initial point.

> solution candidate. Should we separate both parts and lets agree first 
> on the issues, then analyse the solutions candidates?

I'm reasonably content with the problem you described: I get why it's a problem, and you're putting a finer point on my original impulse that whenever you have funky data in the DNS you want to be able to identify it in case it's relevant.  In this case, it turns out for some applications it _is_ relevant, so the only question is how one identifies the data, especially since part of the problem to be solved is that the whole thing works without anyone else doing any upgrades.

Med: but even for draft-ietf-behave-dns64 we need upgrade to work...I don't understand this constraint.

A new RRTYPE doesn't solve that latter problem, so I think it has to be discounted as a solution.

Med: I'm still not convinced about this even if I agree with some of your comments.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Nov 2009 11:57:47 +1300

Med,

I have nothing in mind, and I wish the world didn't appear to believe
that there MUST be a reverse entry for everything. But since that is
the belief, you need to cover it in the proposal, I think.

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 10 Nov 2009 15:01:38 +0900

> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Monday, November 09, 2009 11:04 PM
> To: Mark Andrews; Brian E Carpenter
> Yes, this may solve the problem when the prefix used to build 
> the IPv4-embedded IPv6 address is a WKP or an NSP belonging 
> to the prefix managed by the underlying IP network provider. 
> But this is not the exclusive case that we would have: the 
> NAT64 box can be located in a remote realm.

I would like to gauge if participants folks feel it useful for a dual-stack
host to avoid a 6->4 translator in front of a server.  Perhaps we should ask
in the BEHAVE meeting, or have you present slides at an interim teleconference
call?

-d

> One could also publish prefixes via DHCP and insert them into 
> to address selection algorithms to de-preference these 
> addresses.  This should work for internal use and a ISP 
> supplying a NAT64.  It also provides a mechanism to push 
> DNS64 back into the application for when DNSSEC is in use.
> 
> --
> Mark Andrews, ISC
> This message and any attachments (the "message") are 
> confidential and intended solely for the addressees. 
> If you are not the intended addressee of this message, please 
> cancel it immediately and inform the sender.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 10 Nov 2009 06:37:54 +0000

> in the BEHAVE meeting, or have you present slides at an interim teleconference

In practice, that is more important than avoid translators in P2P/SIP scenarios. The big difference is DNS versus ICE. In P2P, ICE includes an end-to-end probe of the link, which means that the client will in most cases pick the faster path, whether translation is implied or not. Not so in server based scenarios, in which the client has to somehow choose from the addresses returned by DNS.

-- Christian Huitema

---

From: <[email-masked]>
Date: Tue, 10 Nov 2009 09:01:05 +0100

Dear Christian, all

Some comments about the use of ICE/STUN:
- The faster path should be understood as the faster path among the gathered candidates and not among all possible paths. 
- Gathering the candidates depends on the location of STUN servers: new constraints are induced due to the deployment of carrier grade NATs and NAT64 boxes
- Therefore, having means to prefer direct communications based on DNS scheme for instance may also be useful for ICE (since this does not depends on the location/deployment of STUN servers, can be integrated in the phase of gathering candidates (still need to know an name to use for resolution purposes))

Cheers,
Med 

-----Message d'origine-----
De : Christian Huitema [mailto:[email-masked]] 
Envoyé : mardi 10 novembre 2009 07:38
À : Dan Wing; BOUCADAIR Mohamed NCPI/NAD/TIP; 'Mark Andrews'; 'Brian E Carpenter'
Cc : 'Andrew Sullivan'; [email-masked]
Objet : RE: [BEHAVE] optimizing dual-stack client to avoid IPv6->IPv4 translator [was RE: Review of draft-boucadair-behave-dns-a64-01]

> I would like to gauge if participants folks feel it useful for a 
> dual-stack host to avoid a 6->4 translator in front of a server.  
> Perhaps we should ask in the BEHAVE meeting, or have you present 
> slides at an interim teleconference call?

-- Christian Huitema

---

From: <[email-masked]>
Date: Tue, 10 Nov 2009 14:21:33 +0100

Thanks for your comments.

After reading various e-mails and answers, I have the feeling that there is always a misunderstanding about our proposal. Indeed, in this draft we are fully aware about the drawback which may be induced by the backward compatibility problem. We are also aware about the difficulty to upgrade all DNS servers (which is not required as elaborated below).
 
In fact we are trying to explain the short term solution and the long term objective in the same draft. That is why the mechanism may be seen as difficult to implement. I understand also that it may be confusing since the draft is still not stable and several parts needs to be elaborated more.

So I will try to clarify the different steps (to be understood as deployment scenario examples) in which it is not required to update all existing infrastructure:

Step 1: 

Due to lack of public IPv4 addresses, ISP will provide some customers with IPv6-only access instead of dual-stack access. In counterpart they need to provide access to IPv4 internet to these IPv6-only customers. To interconnect this IPv6 network to the IPv4 internet, ISPs must provide NAT64 service, a specific recursor called DNS64 recursor and must provision these customers with the address of this new DNS64 recursor. Existing customers will be provisioned with the address of a legacy recursor (not aware of DNS64).

This first step is very similar to the approach described in draft-ietf-behave-dns64 except that this DNS64 resolver is also able to convert A64 records to AAAA records and includes a mechanism to query an authoritative DNS server for the address of an A64-enabled DNS server also authoritative for the same domain. A solution proposal which is not explained so far in the current version of draft (inspired from http://potaroo.net/ietf/idref/draft-bellis-dns-recursive-discovery/ ) can be adopted. Particularly, a new domain name "A64.LOCAL.ARPA" in the authoritative server with an AAAA records containing the address of an A64 DNS server authoritative for the same domain but A64 compliant. This new domain name exists in the authoritative DNS server if and only if one A64 address has been allocated to a host for which this server is authoritative for (but this A64 record is not recorded in this server if this server is not A64 aware.

Step 2 : 

Due to the (hopefully) success of IPv6 deployment, it is now useful to interconnect existing IPv4 networks with IPv6 internet. New NAT64 boxes will be introduced. But in this case, the IPv4-embedded IPv6 address must be introduced in authoritative DNS servers and not in DNS64 servers.

At least one A64 DNS server will be introduced in this network (an IPv4 network but with dual-stack DNS servers accessible by IPv6 hosts on IPv6 internet). The new A64 records containing the IPv4-embedded IPv6 address is introduced only in this A64 server. Other existing DNS servers authoritative for this domain does not need to be upgraded. Just a new domain name "A64.LOCAL.ARPA" is introduced in their database with the IPv6 address of this A64 compliant DNS server. The IPv4-embedded IPv6 address is not included in the legacy DNS servers.

Only IPv6-only customers provided with a DNS64 resolver in step 1 are able to use this IPv4-embedded IPv6. Other legacy customers are not able to use this address. But it is not a problem because only IPv6-only customers need to know about this address and today there is no legacy IPv6-only customers (or to be honest a very few number of IPv6-only customers that are not aware of NAT64 specification and needs upgrade to use it).

During step 2, some new DNS recursors or new DNS servers may be introduced due to obsolescence of existing equipment to provide services to dual-stack host or to legacy hosts. Recursors will be updated/replaced by A64-DNS64-recursors (a DNS recursor that synthesizes A64 records from A records to answer an A64 query instead of synthesizing AAAA records from A records in answer to AAAA query as a legacy DNS64 recursor do) and DNS server will be updated/replaced by A64-DNS servers. Therefore, AAAA requests will be answered only with native IPv6 addresses. IPv4-embedded IPv6 addresses are synthesized only by A64-DNS64-recursors to answer to A64 requests. So they can be used by legacy customers without any trouble.

Step 3: 

It is now time for operating systems or hosts to introduce new stub resolvers aware to manage A64 records.
 
A new domain name "A64DNS64.LOCAL.ARPA" will be introduced in all DNS64 recusors and in all A64-DNS64 recusors. The AAAA records associated to this domain will contain the address of an A64-DNS64-recusror. In A64-DNS64 recusor it will be the address of the recursor itself. 
A new domain name "DNS64.LOCAL.ARPA" will be introduced in all DNS64 recursors and in all A64-DNS64 recursors. The AAAA records associated to this domain will contain the address of an DNS64 recusor. In DNS64 recusor it will be the address of the recursor itself.

This new A64 stub resolver will be able to locate the A64-DNS-recursor and will use this recursor instead of the DNS64 provision by the ISP.

Step4 :

All DNS64 recursor will be removed when all stub resolver will be updated. 

I hope that this is more clear now.
 
Best regards. 

        Eric BURGEY

-----Message d'origine-----

How?

A

---

From: <[email-masked]>
Date: Tue, 10 Nov 2009 15:10:03 +0100

Hello,

4 billion of IPv4 public addresses is not a small number even if they are quite all used today.

So I am expecting that even a small proportion of IPv4 public addresses users will also request an IPv6 address and will be dual-stack in the near future.

I perfectly agree that dual-stack is not a possible solution to fulfil the growth of internet user. But the fact than IPv6 only is the only realistic solution to provide an IP address to access internet for new users does not mean that existing IPv4 customers will not used also IPv6 and will not move toward dual-stack.

Dual-stack customer must also be seriously taken in account if you don't want to saturate NAT64 with unwanted traffic.

	Eric BURGEY

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : lundi 9 novembre 2009 16:04
À : 'Andrew Sullivan'; [email-masked]
Objet : Re: [BEHAVE] Review of draft-boucadair-behave-dns-a64-01

-d

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 10 Nov 2009 10:00:20 -0500

Hi,

I can't tell if there's something subtle I'm missing, if there's a
terminological barrier here, or whether we simply disagree.  I'm going
to focus mainly on one issue below, in order to try to figure out what
the barrier is.

On Tue, Nov 10, 2009 at 02:21:33PM +0100, [email-masked] wrote:
> DNS server also authoritative for the same domain. A solution
> proposal which is not explained so far in the current version of
> draft (inspired from
> http://potaroo.net/ietf/idref/draft-bellis-dns-recursive-discovery/
> ) can be adopted. Particularly, a new domain name "A64.LOCAL.ARPA"
> in the authoritative server with an AAAA records containing the
> address of an A64 DNS server authoritative for the same domain but
> A64 compliant. This new domain name exists in the authoritative DNS
> server if and only if one A64 address has been allocated to a host
> for which this server is authoritative for (but this A64 record is
> not recorded in this server if this server is not A64 aware.

This is a part that I simply don't get.  Step 1 starts out sounding
just like DNS64.  Then you say "a64.local.arpa in the authoritative
server".  What I understand from that is "in the authoritative server
of the site the v6-only node is trying to reach".  But if that's what
you're trying to say, then you've moved from "ISP provides v6-only
nodes with a NAT64" to "ISP provides v6-only nodes with a NAT64 and
also a bunch of people on the Internet publish A64 records for some
reason."  The _only_ reason A64 is worth anything at Step 1 is that
there are people publishing such records.  But there is no utility to
those people in publishing them, as near as I can tell, and there is
an operational cost.  So why would they do it?

More importantly, since you never know in advance whether a site has
this A64 support (or, more accurately, whether the DNS server you're
talking to has this A64 support), then you have to ask every time.
You're delaying the work of actually resolving names, you're adding
another opportunity for failure, and you're getting no benefit during
Step 1, because _ex hypothesi_ the only people who are asking for the
A64 record for sure need to do NAT64 anyway.  This is just extra work,
therefore, and since you are going to have to do plain DNS64 anyway
(in case the authority server you ask doesn't have A64 records), you
might as well just do it every time.

Therefore, there is only a tiny theoretical gain to either the
publisher or consumer side in this exchange in having A64 records.
The consumer can't do anything differently on the basis of them
anyway, and the publisher gets no advantage.  What, then, will drive
deployment?  If the answer is, "Well, we have an RFC," then forget it:
the DNS protocol police are even more absent than the rest of them on
the Internet, so there is no hope that publishing an RFC alone will
help.  There needs to be a compelling reason to do this as opposed to
just plain DNS64+NAT64, right from the beginning, or the RRTYPE will
not get published and won't get used.

> A new domain name "A64DNS64.LOCAL.ARPA" will be introduced in all
> DNS64 recusors and in all A64-DNS64 recusors.

Note that that proposal is also by no means certain to be adopted.  It
looks like it might be, but we're not there yet (and sensible ideas
have failed in the past).  

> All DNS64 recursor will be removed when all stub resolver will be updated. 

I.e. "never".  You have no way to know when this happens.  There isn't
a mechanism in your proposal, and given that different queries for
different RRTYPEs are completely atomic, there isn't even a reliable
way to infer it.  

Also, you haven't addressed the other issue, which is that there are
alternatives to the A64 RRTYPE that are way less invasive.  Adding the
A record to the additional section, for instance, requires exactly no
change to the DNS protocol: we could do it today (Apple's mDNS does
exactly that whenever replying to AAAA queries anyway, and conversely;
and there's discussion in DNSEXT right now about recommending as much
for everyone). 

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: <[email-masked]>
Date: Tue, 10 Nov 2009 18:56:20 +0100

Hi,
Thanks for your patience.

Your are right it is better to explain step by step.

In step 1 we need to introduce a new functionality called DNS64 to connect the IPv6 network to IPv4 internet. But as we need to built this new functionality, this functionality is built to be ready for step 2. So we introduce in step 1 some mechanism that are used only in step 2.
You are right step 1 sounds just like DNS64 except that it is a DNS64 functionality aware of step2. But this functionality is not used at step 1. 

In fact in step 1 the new domain name "A64.LOCAL.ARPA" is not present in any DNS server. But the mechanism to use it is introduced in DNS64 recursor.
You are right this new domain name will be introduce in step 2 "in the authoritative server of the site the v6-only node is trying to reach" or most exactly will try to reach in step2.

Your also right, the mechanism with a name like "A64.LOCAL.ARPA" is just a proposal and not yet an IETF RFC. But in fact what we need is an IETF approved mechanism to be able to locate a DNS server with the appropriate functionality (A64 aware or DNS64 aware recursor or A64-DNS64 aware recursor)and I choose this one as a simple example. 

You are right there is no utility of A64 mechanism in step1. It is just to prepare a step2. But if we hope that DNS4 from step1 will be ready for step2, the A64 mechanism must be introduce in IETF recommendation in step1.

The problem solved by A64 mechanism is just a problem that will appear in step2 when the number of IPv6 only host will grow so that IPv4 network manager will need to access to IPv6 internet. 

You are right I do the assumption that it is worth to do it and that equipment provider will do it if it is mandatory in the IETF RFC. But it is not only because it is in the RFC. It is because the additional cost to introduce this functionality in step1 is very small and because ISP or operator are not stupid. ISP or operator are not ready to invest without a clear return of investment but in their day to day life they are anticipating functionality when they think that it is needed to do a future proof investment. For example replacement of existing router with IPv4/IPv6 router has been done only for new routers that need to be replaced, but it has been done for this routers. If ISP and operator request this functionality it will be provided by equipment manufacturer.

You are right at the end of the DNS resolution process I add a new step to check if it is not an A64 DNS authoritative server. It is the price of backward compatibility. This price is not too big in my mind because it does not affect legacy user and this price is not paid if there is an AAAAA records. The price is paid only when the DNS64 is activated and only for host which will get the benefits in step2. 
But if it is a way to reduce this price with an alternative solution I will be very happy.

Concerning step4, you are right it is a long term step, but the DNS64 is used only in a specific IPv6 network. When it is not used by the host on this network it can be removed.

Adding a A64 RRTYPE in the additional section of an AAAA records is clearly an alternative solution that must be considered. 
But if you do that in an authoritative DNS server how are you sure that all dual-stack stub resolver are updated to understand this new mechanism to be sure that they will recognise this additional section and will not use the received AAAA records ?
As explain in another mail with 4 billion of public IPv4 adresses used today, it is a risk that a significant part of existing public IPv4 users will move toward dual-stack solution and will overload any NAT64 introduced to connect an IPv4 network to the IPv6 internet (in that case the number of IPv4 user is under control but not the number of IPv6 internet user). Take in account that most of legacy operating system are now IPv6 ready, they just need an IPv6 access to be activated in dual-stack mode.

The main difference between the A64 proposal and this new A64 RRTYPE proposal is that only IPv6 only user will access to the A64 records thanks to their DNS64 recursor. Legacy dual-stack user are not affected by the A64 proposal.

Best regards

	Eric BURGEY

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Andrew Sullivan
Envoyé : mardi 10 novembre 2009 16:00
À : [email-masked]
Objet : Re: [BEHAVE] Review of draft-boucadair-behave-dns-a64-01

Hi,

Best,

A

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 10 Nov 2009 14:03:08 -0500

On Tue, Nov 10, 2009 at 06:56:20PM +0100, [email-masked] wrote:

> Adding a A64 RRTYPE in the additional section of an AAAA records is
> clearly an alternative solution that must be considered.

No, I don't want to do that, because I don't want to define the A64
address at all.  Just include the A record that underlies the AAAA record.  

> But if you do that in an authoritative DNS server how are you sure
> that all dual-stack stub resolver are updated to understand this new
> mechanism to be sure that they will recognise this additional
> section and will not use the received AAAA records ?

You can't be.  But in the A64 approach, it will only work for people
who've upgraded their systems.  And note that this doesn't only mean
the end nodes: every piece of garbage middlebox on the Internet will
have to disappear for A64 really to work, because many of those
garbage middleboxes will filter out the A64 records if they don't know
what they are.  Again, I return to the goal of the NAT64/DNS64 work,
which is to make v4-v6 interoperation possible fairly cheaply.
"Cheap" includes, "I needn't worry whether my Starbucks' or hotel's
access point works with this."  A64 does not meet that test.  Just
adding more informaiton to the additional section _might_ work.

> The main difference between the A64 proposal and this new A64 RRTYPE
> proposal is that only IPv6 only user will access to the A64 records
> thanks to their DNS64 recursor. Legacy dual-stack user are not
> affected by the A64 proposal.

But v6-only users who are somewhere that A64 isn't supported are out
of luck.  Right?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: <[email-masked]>
Date: Wed, 11 Nov 2009 16:33:19 +0100

Hello,
I don't really understand why "many garbage middleboxes" will filter the A64 records because the A64 is exchanged directly between the A64 DNS authoritative server for the requested qualified name and the DNS64 recursor. All "garbage middleboxes" will only exchange or stored AAAA records containing addresses of intermediate DNS server that are asked to find one DNs server authoritative for the requested qualified name and this DNS server will be asked for the AAAA address of the A64 DNS server. All "garbage middleboxes" will not see any A64 records. If you mean the firewall protecting the A64 DNS authoritative server, I agree that this firewall must be compliant with A64 records, but it is clear that if you put a firewall to protect equipment this firewall must be compatible with the service provided by this equipment!

Concerning your last point, I agree, if a customer is in location where it can get only one IPv6 address without any public IPv4 and where no DNS64 recursor is available, so this customer will not be able to join any NAT 64 and this customer does not need any A64 record. Probably this customer is on an IPv6 only network not interconnected with IPv4 internet and if it is not able to access to any other DNS64 recursor this IPv6 network is probably not connected to the IPv6 internet. 

Best regards,

	Eric BURGEY

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Andrew Sullivan
Envoyé : mardi 10 novembre 2009 20:03
À : [email-masked]
Objet : Re: [BEHAVE] Review of draft-boucadair-behave-dns-a64-01

A

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 11 Nov 2009 13:26:26 -0500

On Wed, Nov 11, 2009 at 04:33:19PM +0100, [email-masked] wrote:

> I don't really understand why "many garbage middleboxes" will filter
> the A64 records because the A64 is exchanged directly between the
> A64 DNS authoritative server for the requested qualified name and
> the DNS64 recursor.

And you are going to enforce this how?  There is no control in the DNS
that says, "Only people doing job J are allowed to use RRTYPE R."

> Concerning your last point, I agree, if a customer is in location
> where it can get only one IPv6 address without any public IPv4 and
> where no DNS64 recursor is available, so this customer will not be
> able to join any NAT 64 and this customer does not need any A64
> record. Probably this customer is on an IPv6 only network not
> interconnected with IPv4 internet and if it is not able to access to
> any other DNS64 recursor this IPv6 network is probably not connected
> to the IPv6 internet.

So doesn't that mean that a network operator who wants to offer such
interconnection has to undertake a higher operational cost in order to
use the facility in the A64 case?  

Anyway, as I've now said repeatedly, if the WG thinks that we need to
be able to identify these  cases, there are two strategies open that
we could add to DNS64, that are easier to deploy and require fewer
updates, and that will mostly achieve the goal you want while still
mostly working with already deployed components.  I still do not get
the motivation for the additional RRTYPE (and the additional query
load that will come with it).

I get the feeling we're in a vortex here, however, and we'll just keep
going around unless someone else steps in.  So I'm going to stop
talking about this now.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.