Basic Transition Mechanisms for IPv6 Hosts and Routers
draft-ietf-v6ops-mech-v2-07

Reviewed by Joel Halpern, Gen-ART

His review:

This draft is ready for publication as a Proposed Standard RFC.

Minor comment:

The description of tunneling seems to say that it is only for use by
routers.  It does say that the decision about using tunnels should be
based on routing information.  It would be helpful if there were a
short section on "method selection" which stated, for at least most
common circumstances, which method should be used and why.

Given that this document addresses two mechanisms, dual-stacks and tunneling, I'm kind of surprised that the Security Considerations seems to talk exclusively about tunneling. Are there no security considerations in the use of a dual-stack host? Especially given the fact that some applications on a given host may be configured to use only one stack or another, as Section 2 suggests? I can imagine a number of cases in which different protocols may be used in concert by a host (say, SIP and RTP), where conceivably different protocols employing different stacks could be used by the same application. Surely there's some security implications of that.

Section 7.2 should be titled "Informative References", not "Non-normative References".

Since mrw is already holding a discuss on 2.2, I've listed this is a comment,
but it might be worth the authors' considering when they look at her discuss.

I'm concerned both about this text:

   However, when a query locates an AAAA
   record holding an IPv6 address, and an A record holding an IPv4
   address, the resolver library MAY filter or order the results
   returned to the application in order to influence the version of IP
   packets used to communicate with that node.

and the general approach of describing the filtering mechanism
available to the resolver as if it were the primary way of
preferring AAAA to A or vice versa.  The most obvious way
to prefer one address family over the other is to query for
one RR in preference to the other.  You may still get other
data back, of course, but this gives control earlier than
filtering post-facto, and it deserves a mention here.  

To take a random example, if I dig for the AAAA
record associated with ns-ext.isc.org, I get the A record in
the additional section; that might be filtered, but the preference
is already established.  The case they seem to be focused
on is the one like that in which a dig for the ns records for isc.org
returns both A and AAAA records associated with hosts
like ns-ext.isc.org.  That's fine, and it should be included,
but as part of the larger context.  I suspect they simply thought
the choice of RR was too obvious to list, but I'm guessing it
is not for the intended audience of this document.