[v6ops] Re: The V6OPS WG has placed draft-link-v6ops-claton in state "Call For Adoption By WG Issued"

[Jen Linkova <[e-mail]>]

First of all, sorry for the radio silence, I was on vacation.

On Fri, May 31, 2024 at 1:09 AM Ed Horley <[e-mail]> wrote:
> Jeremy,
> While I am okay with changing these to a MUST, I do wonder about the situation with APIPA addresses and if that might potentially impact a given node that might have self provisioned an IPv4 address to a given interface. Is an APIPA address considered valid IPv4 connectivity (perhaps the node is doing mDNS and has discovered a resource it needs?) There might need to be an exception to account for this?

The draft currently exclude link-local addresses from SHOULD NOT, as
the second paragraph of 'Disabling CLAT' section clarifies:

"The node SHOULD disable CLAT immediately upon obtaining an IPv4
address via DHCP or a non-link-local ([RFC3927]) IPv4 address through
manual or automated fallback configuration."

IMHO the presence of link-local IPv4 addresses shouldn't impact CLAT,
as the security considerations do not apply in that case.

We'll make the changes to clarify that "IPv4 connectivity" doesn't
include IPv4 link-local addresses.

> On Tue, May 28, 2024 at 8:39 AM Jeremy Duncan <jduncan=[e-mail]> wrote:
>>
>> I support adoption and request making these changes:
>>
>> "For performance and security reasons CLAT SHOULD NOT be enabled if
>>    the node has IPv4 connectivity over the given interface."
>>
>> To
>>
>> "For performance and security reasons CLAT MUST NOT be enabled if
>>    the node has IPv4 connectivity over the given interface."
>>
>> And
>>
>> "From a performance perspective, native IPv4 connectivity is
>>    preferrable over 464XLAT, so CLAT SHOULD NOT be enabled if the node
>>    has IPv4 connectivity over the given interface."
>>
>> To
>>
>> "From a performance perspective, native IPv4 connectivity is
>>    preferrable over 464XLAT, so CLAT MUST NOT be enabled if the node
>>    has IPv4 connectivity over the given interface."
>>
>>
>> The discussion points and arguments made for security and performance reasons are laid out well as I think could make the case that this be a MUST NOT instead of a SHOULD NOT.
>>
>>
>> -Jeremy
>>
>>
>> -----Original Message-----
>> From: IETF Secretariat <[e-mail]>
>> Sent: Tuesday, May 28, 2024 11:20 AM
>> To: [e-mail]; [e-mail]; [e-mail]
>> Subject: [v6ops] The V6OPS WG has placed draft-link-v6ops-claton in state "Call For Adoption By WG Issued"
>>
>> CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you validate the sender and know the content is safe. Please forward this email to [e-mail] if you believe this email is suspicious.
>>
>> The V6OPS WG has placed draft-link-v6ops-claton in state Call For Adoption By WG Issued (entered by Nick Buraglio)
>>
>> The document is available at
>> https://datatracker.ietf.org/doc/draft-link-v6ops-claton/
>>
>> Comment:
>> This email starts an adoption call for the following document:
>>
>> Title : 464 Customer-side Translator (CLAT): Node Recommendations Authors : J. Linkova, T. Jensen Pages : 14 Date : 28-May-2024
>>
>> https://datatracker.ietf.org/doc/draft-link-v6ops-claton/
>>
>> This draft details how CLAT shall operate on endpoints.
>>
>> _______________________________________________
>> v6ops mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>> _______________________________________________
>> v6ops mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>
>
>
> --
> Ed Horley
> [e-mail] | [phone]
> Advancing Cloud, IoT, and Security with IPv6
> https://hexabuild.io
> And check out the IPv6 Buzz Podcast at https://packetpushers.net/series/ipv6-buzz/



-- 
Cheers, Jen Linkova