Re: [spfbis] RFC6147 and RFC7208 interoperability issues

[Klaus Frank <[e-mail]>]

On 2022-02-08 00:57, Mark Andrews wrote:
>
>> On 8 Feb 2022, at 02:19, Klaus Frank <[e-mail]> wrote:
>>
>> 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"
> One could have just set IPV6_V6ONLY=1 at the system level (sysctl net.ipv6.bindv6only=1) or prior to bind(2)
> on the individual sockets if you don’t want mapped connections.  IPV6_V6ONLY is described in RFC 2535, Basic
> Socket Interface Extensions for IPv6 (February 2003) and is in also in POSIX as of 2008.  Alternatively SPF
> libraries could just learn about mapped connections and apply IPv4 rules against them.

Thanks for the hint. I know that that existed, but didn't know how to 
configure it or what exactly causes it.

Also I just re-read the SPF record RFC, and it indeed should already 
cover IPv4-mapped IPv6. So strictly speaking that's a violation of the 
RFC and therefore an implementation bug...

    When any mechanism fetches host addresses to compare with <ip>, when
    <ip> is an IPv4, "A" records are fetched; when <ip> is an IPv6
    address, "AAAA" records are fetched.  SPF implementations on IPv6
    servers *need to handle both "AAAA" and "A" records, for clients on**
**   IPv4-mapped IPv6 addresses *[RFC4291].  IPv4 <ip> addresses are only
    listed in an SPF record using the "ip4" mechanism.

>>> 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
>> _______________________________________________
>> spfbis mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spfbis