Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Christian Huitema <[e-mail]>]

 

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

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.

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