Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Klaus Frank <[e-mail]>]

On 2022-02-07 16:56, Christian Huitema wrote:
>   
>
>> On Feb 7, 2022, at 5:11 AM, Keith Moore <[e-mail]> wrote:
>>
>> Sent from my iPhone
>>
>>> On Feb 7, 2022, at 1:42 AM, marcelo bagnulo braun <[e-mail]> wrote:
>>>
>>> I guess one operative question is whether this issue can be dealt with an errata or should require an update in the spec.
>> Neither.  That SPF and TXT records are not altered is a feature, not a bug
> Marcelo,
>
> Errata is for errors, not for changing the specifications. The current text absolutely reflects the decisions of the WG at the time. To change the decision would require a new version. In fact, it would also require a debate, because there are two solutions.
>
> One potential solution is to say that the text is right, that NAT64 should only work with A and AAAA records, and that applications using other records that embed IP addresses should be cognizant of NAT64 and apply their own logic.
>
> That's not what Klaus hoped for, but there are several arguments for that approach, especially in the case of records with security implications like SPF. Arguably, applications relying on such records should acquire them in secure ways, which precludes alterations in the middle.
I was hoping for clarification and an alignment between both working 
groups (and maybe an official recommendation i.e. Informational RFC) and 
to find a solution for the future. So that this problem doesn't stay 
unresolved.
> There are also deployment arguments for the end to end approach. New records can be created at any time. The applications using them know that, and are expected to have code to handle them. NAT64 don't. They ship in devices like home routers that are notoriously slow to upgrade. Even if we told them to upgrade, they would only do that slowly, and applications that need it immediately will still need to add the NAT64 code.

I want to disagree partially with you on this one. You always say NAT64 
as a combination of DNS64 and NAT64. Truth is, that these are two 
distinct things that are offered from two different origins. Even though 
a NAT64 may be on slow updating home routers (though unlikely, a CLAT 
would be more likely here). The DNS64 isn't. The home routers only have 
plain forwarding. They forward to the DNS infrastructure of the ISP. 
Therefore changing DNS64 (not NAT64) would indeed be feasible as it is 
within a way better maintained and updated environment. And also the 
NAT64 gateways would residue in the ISP infrastructure and not within 
the home router itself. The home router would then just forward IPv6 
only traffic towards the ISP... (see figure 2, 3 and 4 
https://tools.ietf.org/id/draft-ietf-v6ops-nat64-deployment-03.html)

> So, no, this is not material for an errata. Maybe just additional guidance about deployment and knowledge in applications. Or, failing that, a revised RFC.
>
> -- Christian Huitema
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave