Re: [spfbis] RFC6147 and RFC7208 interoperability issues

[Mark Andrews <[e-mail]>]

> On 8 Feb 2022, at 11:09, Klaus Frank <[e-mail]> wrote:
> 
> 
> 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.

The SPF libraries (or the MTAs) could also use RFC 8781, Discovering PREF64
in Router Advertisements.  Failing that, as has already been mentioned they
could use ipv6only.arpa to get the mapping.

>>>> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]