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

[<mohamed.boucadair at orange-ftgroup.com>]

Dear Andrew, all,

Please find some answers inline.

Cheers,
Med


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

Dear colleagues,

I have read draft-boucadair-behave-dns-a64-01.  I have some comments.


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.


    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.


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.

          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.


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.

    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.


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.
********************************