Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Klaus Frank <[e-mail]>]

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.

> 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. 
And I rather have NAT64+DNS64 than dualstack with NAT44 (or sometimes 
NAT444). It's already bad enough that the k8s people want to advocate 
for NAT66 because of a false sense of security. But that's a topic for 
another day...
> -d
>> On Feb 6, 2022, at 4:47 PM, Klaus Frank <[e-mail]> wrote:
>>
>> This is neither helpful nor constructive.
>>
>> But if you really want to talk about spilled milk, why don't we talk about RFC3338 then? If that one is a bit polished it could completely eliminate the need for NAT64. But it was dropped in the process and never got past Experimental. I'd have some ideas on how to make it fly, but I don't see value in following up an RFC that was dropped 20 years ago and diverge from a bad but industry favored solution (NAT64) that compared to RFC3338 has seen adoption and is also already used in the wild...
>>
>> On 2022-02-07 01:41, Keith Moore wrote:
>>> On 2/6/22 19:38, Klaus Frank wrote:
>>>
>>>> I can understand you. I also don't like NAT. And I would also have favored different migration paths from IPv4 to IPv6. But NAT64+DNS64 is the one we got. I'm sure there have been discussions earlier. I didn't want to resume or repeat those discussions. I'm certain there are valid reasons for why we have the current migration paths and that the pros and cons of different strategies have been covered adequately.
>>>>
>>>> Nonetheless DNS64 is incomplete without also addressing the SPF record.
>>>>
>>> Disagree.  DNS64 is inherently incomplete and cannot be fixed.  I will strongly object to any effort to further pollute DNS in the name of making NAT appear to work.
>>>
>>> Keith
>>>
>>>
>>> _______________________________________________
>>> Behave mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/behave
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave