I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines an extension to the TURN protocol, a relay protocol for NAT traversal, that allows endpoints to request that the TURN server allocate them an IPv4 or IPv6 address (the protocol currently supports only IPv4). On important feature of this extension is that it allows a TURN server to act as a relay in all four combinations of protocols (4-4, 4-6, 6-4, 6-6), depending on which protocol the TURN request is carried in and which address family is requested. As the Security Considerations correctly note, TURN with this extension is basically equivalent to TURN without it, with the exception that certain routing loop attacks inherent to TURN could be easier with this mechanism. My only significant concern that is not addressed in the document is how this mechanism relates to the routing loop attacks introduced by other forms of v4/v6 translation and tunneling, e.g., as discussed in this paper: < http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf > It's not immediately obvious to me that extending TURN in this way makes these (currently non-TURN-related) attacks viable, but I would encourage the authors to consider the issue and add some text to the document explaining how the attacks do or do not apply here. A few specific comments follow. --Richard Comments on draft-ietf-behave-turn-ipv6 S.3, Paragraph "Assuming the request..." The server doesn't "assume" that the request is authenticated. Suggest rephrasing as "After the request has been successfully authenticated, ..." S4.1.1 Why not just make this option one byte long? If you're already anticipating a usage for the reserved space, you should just specify it. S4.2, First paragraph As above, suggest rephrasing as "Once a server has verified that the request is authenticated and has not been tampered with, ..." S4.3 Why is this a SHOULD NOT and not a MUST NOT? What's the exceptional case? Section 9, First para It seems overly broad to say that "an IPv4-only client having access to ... this specifictation is now able to access the IPv6 Internet". The client can't just send/receive traffic with any node, right? Explain the restrictions in place here. Section 9, Might some of the Teredo / 6to4 loop attacks apply as well? If not, why not? -- Spoof 4-to-6 allocate request from relay's v4 address -- Spoof authorization relay's v6 address -- Spoof packet from either of relay's addresses If there is some risk here, you might consider saying something like "Server MUST NOT allocate 6to4 or Teredo addresses or accept them as peers"?