Closed mstojens closed 3 months ago
@furry13 do you want me to take a stab at this after your PR is merged, or leave this for post-adoption?
@furry13 do you want me to take a stab at this after your PR is merged, or leave this for post-adoption?
If you have time to do it this week - sure, would be great!
Merged my PR, so the floor is yours ;)
on it :) PR within 24 hours or your money back
PR issued. It isn't trivial in its modification to requirements, so I'm not expecting a rubber stamp.
On Thu, Feb 29, 2024 at 3:58 AM Tommy Jensen @.***> wrote:
PR issued. It isn't trivial in its modification to requirements, so I'm not expecting a rubber stamp.
Wow, just when I started counting on getting my money back ;)) I've added a comment.. Let me know if you'd like to discuss it over voice/video chat (not sure if you were following Ipv6-only RA flag story..)
—
Reply to this email directly, view it on GitHub https://github.com/furry13/v6ops-464xlat-enable/issues/7#issuecomment-1969429298, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOSDTRM6SXLHVGKKJUXJSTYV5O3XAVCNFSM6AAAAABBMHCT2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRZGQZDSMRZHA . You are receiving this because you were mentioned.Message ID: @.***>
-- Cheers, Jen Linkova
I was writing an extensive response to your last comment but then I started thinking that maybe we shall ask for adoption and bring that question to the group? Because I suspect it will trigger a discussion anyway.. What do you think?
On Thu, Feb 29, 2024 at 3:58 AM Tommy Jensen @.***> wrote:
PR issued. It isn't trivial in its modification to requirements, so I'm not expecting a rubber stamp.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
-- Cheers, Jen Linkova
I'm totally fine with that. I'm happy with submitting the current main branch content to datatracker. All I ask is we keep my PR open for now so we can revisit the discussion later, even if it eventually needs to be abandoned for a new PR due to other changes.
On Thu, Feb 29, 2024 at 7:50 AM Tommy Jensen @.***> wrote:
I'm totally fine with that. I'm happy with submitting the current main branch content to datatracker. All I ask is we keep my PR open for now so we can revisit the discussion later,
Indeed! I totally agree that it might make sense in some cases to prefer clat even if IPv4 is available. We just need to think about how to do it safely. I guess I will see you in a couple of weeks? So we can do some brainstorming over a drink (or two ;))
even if it eventually needs to be abandoned for a new PR due to other
changes.
— Reply to this email directly, view it on GitHub https://github.com/furry13/v6ops-464xlat-enable/issues/7#issuecomment-1969895903, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOSDTUIAXEPIVWYX2NJZXDYV6KCTAVCNFSM6AAAAABBMHCT2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRZHA4TKOJQGM . You are receiving this because you were mentioned.Message ID: @.***>
-- Cheers, Jen Linkova
Sounds like a plan! Can't wait :) 🍻
Yeah, decided this was a bad idea.
If a network is handing out DHCP Option 108 responses, but a node isn't aware of that option or is IPv4 only, it may proceed with acquiring a lease anyway. However, RFC 8925 compliant node won't. Such a compliant node will end up always activating CLAT since it by definition won't have an IPv4 address (module odd hard coding cases, in which case it's beyond RFC scope).
So why bother calling this out? Because this won't happen if the network advertises the prefix only using the PREF64 RA. In that case, if the network is also dual stack, then every client per the existing text will end up using native IPv4. So it might be useful to point out to deployers that if they want to tell their IPv6-capable devices to be IPv6-only even if there's IPv4 networking present (for the sake of IPv4-only devices), the answer is to deploy DHCP Option 108 along with the RA (or RFC 7050, or 7225).
If we don't want to require DHCP Option 108 for that scenario, we should add a MAY to give some flexibility to admins who want to configure non-default behavior ("ok node, I know what I'm doing, continue using CLAT even if you find IPv4"). The scenario would be "we want to audit and reduce IPv4 traffic, yes we know it will be less performant."