Re: NAT64 in RA, draft-ietf-6man-ra-pref64

[Jen Linkova <[e-mail]>]

On Tue, Jul 2, 2019 at 10:09 PM David Farmer <[e-mail]> wrote:
> I mostly agree, but there is a scenario I've been thinking about;
>
> What if the network operator doesn't want RFC1918 and RFC 6598 IPv4 addresses synthesized at all? I suppose the NAT64 function could block these addresses. However, for a large enough population that could be a lot of useless traffic going to the NAT64 function. While on the other hand some network operators, especially enterprise operators, will probably want these addresses synthesized.

Oh funny you should mention that..I've been thinking about it but have
not managed to untangle the chain of RFCs yet...

So, https://tools.ietf.org/html/rfc6052 explicitly states that
"The Well-Known Prefix MUST NOT be used to represent non-global IPv4
   addresses, such as those defined in [RFC1918] or listed in Section 3
   of [RFC5735].  Address translators MUST NOT translate packets in
   which an address is composed of the Well-Known Prefix and a non-
   global IPv4 address; they MUST drop these packets."

So I'd expect that if I run an internal network which has some
Ipv4-only segments and would like to ensure they are not translated,
all should work fine if those segments are using RFC1918 address space
and WKP is used for translation.

However DNS64 RFC does not explicitly mention that.
https://tools.ietf.org/html/rfc6147#section-5.1.4 talks about
Exclusion Set for AAAA Records but it only recommends including
::ffff/96 by default.
Does it mean that if I do not explicitly configure the exclusion set
for the DNS64 *somehow*, the DNS64 is going to synthesise AAAA for
RFC1918 space using the WKP while the translators would drop those
packets?

RFC6146 does not mention RFC1918 or WKP but it refers to RFC6052 so
I'd expect it to inherit the requirement of not using the WKP with
RFC1918 addresses...But I could not find the explicit confirmation.

-- 
SY, Jen Linkova aka Furry