Re: [spfbis] RFC6147 and RFC7208 interoperability issues

Either way one of both RFCs needs an addendum to address this.

I personally think that because the SPF record is part of DNS it should 
be updated by DNS64 as well. But if RFC7208 gets an addendum that 
mandates the SPF library to consider the NAT64 (RFC7050 and RFC8880) 
prefix when doing validation would also work for me.

On 2022-02-06 23:16, John Levine wrote:
> It appears that Scott Kitterman  <spf2@kitterman.com> said:
>> It looks like situations like this one were contemplated by the RFC 6147
>> authors:
>>
>>> 6.  Deployment Notes
>>>
>>>     While DNS64 is intended to be part of a strategy for aiding IPv6
>>>     deployment in an internetworking environment with some IPv4-only and
>>>     IPv6-only networks, it is important to realize that it is
>>>     incompatible with some things that may be deployed in an IPv4-only or
>>>     dual-stack context.
>> On the SPF side of the discussion, I think it would, at least in theory, be
>> feasible to interpret an ip4: mechanism as <prefix> + <address> if the
>> connection is IPv6, but I don't see how a receiving SPF processor could know
>> what the prefix is.  As I read RFC 6147 Section 5.2, it could be anything.
> See RFCs 7050 and 8880 for how you find the prefix(es).
>
> That seems like a more reasonable way to go, patch the SPF library so it
> can use the NAT's Pref64 to fudge the interpretation of ip4 and ptr.
>
> It looks like you could automate the entire thing -- when the library starts
> up, do an AAAA query on ipv4only.arpa, and if you get plausible answers,
> you know you're behind NAT64 and reinterpret ip4 and ptr terms appropriately.
>
> R's,
> John
>
>
> _______________________________________________
> spfbis mailing list
> spfbis@ietf.org
> https://www.ietf.org/mailman/listinfo/spfbis

Re: [spfbis] RFC6147 and RFC7208 interoperability issues

Attachment: smime.p7s