Re: [spfbis] RFC6147 and RFC7208 interoperability issues

[Klaus Frank <[e-mail]>]

On 2022-02-07 15:28, Scott Kitterman wrote:
> On Sunday, February 6, 2022 5:16:18 PM EST John Levine wrote:
>> It appears that Scott Kitterman  <[e-mail]> 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.
> Thanks.
>
> Reading RFC 7050, it looks like ipv4only.arpa can return more than one name.
> That would seem to be a complication if I'm reading it correctly.
>
> As a practical matter, it probably doesn't matter, but RFC 7050 doesn't update
> RFC 6147, so in theory other prefix determination methods could be used.
>
> I guess the ::ffff:0:0/96 (IPv4-mapped Address) prefix should be considered
> similarly.
Oh yes, for sure good that you remind me of this one. We had one 
mailserver application (proprietary) that once we changed the binding 
from "0.0.0.0:25" to "[::]:25" on a linux system got everything as 
::ffff:0:0/96 and SPF validation also failed. But I'm not sure if that 
was an implementation simplification on their end or a OS dependent 
behavior of when binding a socket... The workaround we got was to "just 
deploy another VM for IPv6 and put them behind the same public DNS name. 
One for IPv4 and another one for the IPv6"
> Is there enough here that it would be worth an Applicability Statement?
>
> Scott K
>
>
>
> _______________________________________________
> spfbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spfbis