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

[Jeremy Duncan <[e-mail]>]

Thanks Jen, what about the part about changes these:

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


-Jeremy

-----Original Message-----
From: Jen Linkova <[e-mail]> 
Sent: Thursday, June 6, 2024 11:10 PM
To: Ed Horley <[e-mail]>
Cc: Jeremy Duncan <[e-mail]>; IETF Secretariat <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [v6ops] Re: 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.

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