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

[Ed Horley <[e-mail]>]

Jeremy,
That seems a reasonable approach - I haven't thought through all the
potential situations so perhaps change the MUST NOT to a SHOULD NOT for the
APIPA/link-local IPv4 comments? But I leave that up to far smarter people
than myself. I don't know if there are use cases that leverage APIPA is a
way that might cause issues, but likely those would be nonstandard use
cases and something the IETF doesn't necessarily have to address with this
draft. Just thinking out loud on this one.
- Ed

On Thu, May 30, 2024 at 9:32 AM Jeremy Duncan <[e-mail]>
wrote:

> Ed-
>
>
>
> I 100% agree with this statement. How about more specific working as
> stated below?
>
>
>
> "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 routable IPv4 connectivity over the given interface. If the
> interface has an APIPA/link-local IPv4 address, then this MUST NOT be
> considered routable IPv4 connectivity."
>
> 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 routable IPv4
> connectivity over the given interface. If the interface has an
> APIPA/link-local IPv4 address, then this MUST NOT be considered routable
> IPv4 connectivity."
>
>
>
>
>
> -Jeremy
>
>
>
>
>
> *From:* Ed Horley <[e-mail]>
> *Sent:* Thursday, May 30, 2024 11:09 AM
> *To:* Jeremy Duncan <[e-mail]>
> *Cc:* 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.
>
> 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?
>
> - Ed
>
>
>
> 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/
>


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