Re: [spfbis] RFC6147 and RFC7208 interoperability issues

[Scott Kitterman <[e-mail]>]

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.

Is there enough here that it would be worth an Applicability Statement?

Scott K