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

[Lorenzo Colitti <[e-mail]>]

On Tue, Jul 2, 2019 at 9:09 PM David Farmer <[e-mail]> wrote:

> Right. That was the gist of my earlier comment. I believe we all agree
>> that in the most common deployment scenario (i.e., an IPv6-only host with
>> no IPv4), an exclusion list is not useful, because the host really can't
>> reach anything that's not reachable via IPv6.
>>
>
> 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.
>

Hmm... but why will hosts want to send traffic to those addresses? Hosts
(especially IPv6-only hosts) won't just arbitrarily decide to connect to
RFC1918 addresses of their own accord. They will only do that if there is a
reason to do so - for example, if there is an A record in the DNS pointing
at such addresses. But why would the network operator publish A records in
the DNS for IP addresses that it intentionally wants to make unreachable
from some hosts? What is the reason for doing so compared to obvious
alternatives such as a) don't publish said A records, or b) publish said A
records together with corresponding AAAA records?

Also, this problem already exists today in IPv4. Any IPv4-only or
dual-stack host asked to connect to an RFC1918 address will send packets to
it, regardless of whether the address is reachable and of whether it's in
the same NAT domain as the host. For example, applications using STUN, such
as video chat applications, will often try all addresses advertised by the
remote host, even in the common case that the remote host is in a different
NAT domain (e.g. video chat between two residential users each of whom is
behind their own NAT).

Now a complicated APL capability isn't probably needed to handle this, a
> simple one-bit option flag or two would suffice, I believe.
>

In the common case of a /96 prefix I don't think there are any bits left in
the current packet format without increasing the size of the option from 16
to 24 bytes.

>