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. The draft aims for informational status and describes a deployment model for traffic from legacy IPv4-only clients (on the Internet) is translated to IPv6 upon reaching the data centre. The document appears mostly ok for publication with a series of comments. One main question: Technically this document looks to me more like standards and not informational as I think we need to enforce consistent behaviour and restrictions to ensure overall consistency. IMO we need to spell this out more explicitly. This is a repeating element, I encountered in this review across multiple sections of the document (see explanations below). COMMENTS: 0. starting with a personal comment: in general it is nice to move again a step closer to a V6, even though these series of baby transition steps are quite small. Whether we need this in addition to other existing 64 protocols, I leave to the V6ops WG who has much better insight into this one than me. 1. This document has two strong requirements, that should be expressed in 2119 language. 1.1. the SIIT algorithm MUST be used. 1.2. And the security considerations section MUST be followed. 2. Section 7 Security Considerations: 2.1. The listed concern is correct. The listed mitigation step may work, I would suggest to also add a sentence when you do choose this distinct translation prefix, you also must configure your FW/GW at the edge to enforce the integrity of that naming scheme (e.g. by dropping packets from that prefix if not coming from a IPv4) to make sure there is no ambiguity or spoofing. We must avoid a blend of translated and untranslated addresses in the same prefix if you use the prefix as a marker. 2.2. I am not sure you covered all the security concerns in this section.  2.2.1. e.g. we might want to expand more on the risk that the DC does by design not see that we translate this down to V4 at the edge and thereby loose some of the capabilities of V6 beyond the edge. Therefore the DC may assume a fully V6 conformant client, which is not the case. This may lead to the need of further filtering or protection mechanisms at the edge. 2.2.2. the authors should expand more on architecture requirements not to put two of these translators in sequence (see possibly conflicts with 2.2.3. the authors should expand more on restrictions of putting this in a mixed environment with NAT64 3. section "4.4. Choice of Translation Prefix" - states: "Either a Network-Specific Prefix (NSP) from the provider's own IPv6 address space or the IANA-allocated Well-Known Prefix 64:ff9b::/96  (WKP) may be used." I think this needs to be a MUST instead of the "may". Also I do not like the ambiguity of prefixes here. We need to make it clear that this translastion MUST be consistent across all edges to the DC. 4. section 4.5. routing considerations: - do we need to specify that all alternate BRs must use the same algorithm and all MUST be able to support SIIT-DC? 5. section 4.6: we say "This should be understood to include all servers," I am not sure this is only a "should". From a lingual perspective it might be meaning that it "it should be understood that it requires..." but as the word "required" is not used, it is a bit unclear to me, whether that is also understood by the author/WG for this protocol. 6. section 4.8.: we use "To facilitate reliable delivery of such ICMPv6 errors n SIIT-DC operator SHOULD implement the recommendations in [RFC6791] in the BRs." Is there a security consideration on the impact what happens if RFC6791 is not followed and ICMPv6 errors are dropped? What would be the security implications of loosing not transmitting these messages? 7. section 4.9. "MTU and Fragmentation": it is good that we spell out the series of key differences between IPv4 and IPv6 relating to packet sizes and fragmentation that one needs to consider when deploying SIIT-DC. I am not sure a "should" is sufficient here. Furthermore, it would be good to consider whether we need to specify and mandate the specific behaviour when encountering these limitations to avoid inconsistent behaviour from the BR if these parameters are encountered and this might be exploited as an attack vector. Thank you and best regards. Tobias