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

[Xipengxiao <[e-mail]>]

I support the adoption of draft-link-v6ops-claton.  When IPv6-mostly is deployed, some dual stack nodes become IPv6-only nodes, and they need CLAT enabled to support any IPv4-only devices tethered to them.  This draft provides recommendations on when/how to enable/disable CLAT. I think this is a necessary complement to the IPv6-mostly solution.  Thank you.

XiPeng

From: Ed Horley <[e-mail]>
Sent: Thursday, May 30, 2024 5:09 PM
To: Jeremy Duncan <jduncan=[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"

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]<mailto:[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]<mailto:[e-mail]>>
Sent: Tuesday, May 28, 2024 11:20 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
v6ops mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


--
Ed Horley
[e-mail]<mailto:[e-mail]> | [phone]
Advancing Cloud, IoT, and Security with IPv6
https://hexabuild.io<https://hexabuild.io/>
And check out the IPv6 Buzz Podcast at https://packetpushers.net/series/ipv6-buzz/