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

[David Farmer <[e-mail]>]

On Tue, Jul 2, 2019 at 7:51 AM Lorenzo Colitti <[e-mail]> wrote:

> 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.
>

You partly answer this below, it happens all the time in IPv4 today. There
is a reason we have AS112, there is a ton of junk out there. Yes, AS112 is
a different problem, but I still think it illustrates the scale of the
problem. RFC1918 addresses are everywhere and they leak everywhere too.


> 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?
>

One of the reasons we want this RA option is that clients are configured
with DNS servers not provided by the network operator. So even if the
network operator doesn't put these addresses in their DNS, the client could
be using a DNS server serving these addresses to it. For example, what if
the client is hard configured with an enterprise DNS server? Then there are
all the DNS games VPN clients play.  As I said, the NAT64 function can
block this but then it has to receive the traffic just to drop it. Maybe
it's just the price we have to pay for all the brokenness in IPv4.


> 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.
>
>>
If we don't provide a mechanism to configure this, then clients
implementing this feature MUST synthesize DNS entries for RFC1918 and
RFC6598 IPv4 addresses received in A records, and it is up to the NAT64
function to apply an appropriate local policy for these addresses. I think
other special purpose IPv4 addresses MAY be safely excluded from DNS
synthesize.

Thanks
-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================