Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Keith Moore <[e-mail]>]

On 2/6/22 21:04, Klaus Frank wrote:

>
> On 2022-02-07 01:58, Dan Wing wrote:
>> The philosophy in RFC3338 became 464XLAT, 
>> https://datatracker.ietf.org/doc/html/rfc6877
> Right, deploying a CLAT as 464XLAT has would also be a possibility. 
> But then the node would be dualstack again and not IPv6 only. That 
> would also add administrative overhead compared to NAT64+DNS64 which 
> can be deployed on the provider side only.
>> As for the DNS64 issue, could the application become NAT64-aware and 
>> do the SPF rewriting itself? See 
>> https://datatracker.ietf.org/doc/html/rfc7050 which discusses how 
>> that can work on the local application.
>
> I also sent this request to the spfbis mailinglists. And there is also 
> currently a discussion on this topic and this has been mentioned 
> before. The Tl;Dr of it is the argument on one side that as DNS64 
> already rewrites the DNS and is intended to provide a IPv6 only few of 
> the dualstack DNS. Therefore it would also be fair for anyone relying 
> on it to assume that it rewrites entries like the SPF record (which 
> counter intuitively is currently prohibited by the RFC). And on the 
> other side adding a reference to RFC7050 and RFC8880 to the SPF one 
> and patch the library because the it would require that the DNS64 
> server parses through all TXT records which can contain arbitrary data 
> in combination with the SPF record. It was also mentioned that this 
> could require a new informational RFC to be written containing 
> implementation recommendations and an evaluation of what other 
> problems mail server admins could have with ipv6 only networks.

One problem is, the NAT64 cannot notice every occurrence of an IPv4 
address in every protocol that might reach a host on the "inside" and 
correctly know whether it should translate the address.  It's simply 
impossible for a variety of reasons - the NAT can't track every 
protocol, and it doesn't have cleartext access to all of the traffic 
flowing through it.   Even something as relatively simple as trying to 
translate FTP PORT commands didn't work well.

Another problem is, what you are proposing is an incompatible change, 
which would then require SMTP servers or other spam appliances to adapt 
to the specific NAT64 model and version in use to know whether they 
should respect an SPF record.

The net is far better off if individual SMTP servers or spam filtering 
appliances can be configurable to translate the SPF records themselves, 
and NOT expect NAT64s to do it.   NAT is bad enough without changing how 
it works every time a new protocol is found that needs special handling.

>
>> A problem with rewriting SPF records within DNS64 is that other IPv4 
>> addresses may well appear in TXT records, throwing a loop to 
>> applications which won't know if the DNS64 has done rewriting or if 
>> the application needs to do rewriting.  A long-standing problem with 
>> NAT "support" for applications since the days of FTP PASV.
>>
>> I will also +1 Keith's comment that SPF is a borked standard, even if 
>> the world had no NATs.  DKIM and DMARC are superior.
> We've reached common ground on the dismissal of NAT and SPF as failed 
> standards. But neither of our opinions will change that both are 
> broadly used, industry favored and therefore we'll having to be dealt 
> with them. 

Yes, NATs need to be dealt with.  And the way to deal with them is to 
adopt IPv6 wholesale and deprecate NATs, with extreme prejudice, as soon 
as possible.   That won't stop people from using them anyway, but it 
might discourage people from expecting NATs to forever be patched to 
accommodate every new application that they break.

And what is IETF's purpose if not to communicate to the industry how the 
Internet will evolve?   Insisting that IETF must do whatever the 
industry does gets it exactly backwards.   The industry will always 
paint itself into corners without some adult supervision, because that's 
what maximizes short-term profit.

Keith

p.s. I was just thinking of something I heard in 1980, from a friend who 
worked at Xerox PARC: "The problem with smart intermediaries..." (what 
we'd now call middleboxes) "is that they have to be smarter than their 
endpoints."   And that's why it's always been obvious to me not only 
that NATs were a Bad Idea, but also why.