Basic Transition Mechanisms for IPv6 Hosts and Routers
RFC 4213

Note: This ballot was opened for revision 07 and is now closed.

(Steven Bellovin) Discuss

Discuss (2004-09-10 for -** No value found for 'p.get_dochistory.rev' **)
3.3: what is the benefit of using TTL 255 here?  Please delete that.  (I see that it's left over from a hint to use GSTM; I asked that that be deleted.  But why leave the TTL suggestion in that case?)  Frankly, I think the entire paragraph is useless, since the remaining text boils down to "do it the standard way".)
Comment (2004-09-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(David Kessens) Yes

(Harald Alvestrand) No Objection

Comment (2004-09-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Margaret Cullen) (was Discuss) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2004-05-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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, 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
returns both A and AAAA records associated with hosts
like  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.

(Scott Hollenbeck) (was Discuss) No Objection

Comment (2004-05-13)
No email
send info
Section 7.2 should be titled "Informative References", not "Non-normative References".

(Russ Housley) No Objection

(Allison Mankin) No Objection

(Thomas Narten) No Objection

(Jon Peterson) No Objection

Comment (2004-05-12 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Bert Wijnen) No Objection

(Alex Zinin) (was Discuss) No Objection