Title: review of draft-arkko-dual-stack-extra-lite-03 I 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 is a very brief (8-page) document. It defines how to employ address translation (NAT) to serve a large (> 2^24) user population without making use of a large private address space. Thus the focus here is a bit different from the usual NAT context, where one uses a large-enough private address space behind a NAT, and maps that space into a smaller (typically IPV4) address space on the other side of a NAT. The authors review several other approaches to dealing with the problem, as a prelude to presenting the proposed solution. The solution put forth here is applicable to nets where each endpoint has a point-to-point link to a NAT (vs. a broadcast net). The authors note that if tunneling is already being used to connect endpoints to a gateway/NAT, this technique also is applicable. In either case the NAT maintains a map between the overlapping private address spaces and the public space by associating a network interface ID (as well as the private IP address) with each endpoint. The authors recommend employing their solution for dealing with the IPv4 addresses that need to be associated with endpoints in the dual stack [RFC 4213] deployment model for IPv6. They also note that their proposal could be used in another IPv6 deployment model [I-D.ietf-behave-v6v4-xlate-stateful], but that it probably is not necessary there, because of the abundance of IPv6 address space. The security considerations section is but one sentence: "This practices outlined in this document do not affect the security properties of address translation." I think this needs to be expanded upon : . The authors should cite at least one RFC that deals with NAT and has sustentative security considerations section. If they can't find a suitable RFC (2993 is the obvious candidate, but it is outdated in several of its references and comments) then they at least describe why they believe that this proposal introduces no new security implications.