[v6ops] Re: IETF WG state changed for draft-ietf-v6ops-claton

[Jeremy Duncan <[e-mail]>]

In line ---* below

-Jeremy


-----Original Message-----
From: Jen Linkova <[e-mail]> 
Sent: Wednesday, August 20, 2025 1:30 AM
To: Jeremy Duncan <[e-mail]>
Cc: Edward Lemon <[e-mail]>; IPv6 Operations <[e-mail]>; Lorenzo Colitti <[e-mail]>
Subject: Re: [v6ops] Re: IETF WG state changed for draft-ietf-v6ops-claton

[EXTERNAL] Verify links and attachments with sender.

+Lorenzo as there is a discussion about "MUST" vs "SHOULD" for DAD..

Hi Jeremy,

First of all, thank you very much for your feedback!

On Tue, Aug 19, 2025 at 10:39 PM Jeremy Duncan <[e-mail]> wrote:
> 1. Should there be something that addresses erratic IPv4 behavior in section 6? Meaning, sometimes an IPv4 address is received, is received from an untrusted or incorrect source, or the network DNS resolvers are incorrectly configured? This could cause a DoS or mess with overall on and off behavior of CLAT. Something similar to having a mechanism similar to RFC 8925 that sets a clock for network-accessible IPv4. If it's seen for 5 minutes (or whatever is set) wait to re-enable CLAT. Does that make sense?

> Also, the same could be said for erratic IPv6-only as well. If the RA sends pref64 but it's not a valid option, etc.

To be honest, I'm not convinced this document is the right place to solve this.
You are describing attack vectors which are not specific to CLAT:
rogue RAs and rogue DHCP servers can break IPv6 and IPv4 connectivity for hosts w/o CLAT.
So it's fate sharing, and the questions are:
What is an IPv4-enabled host supposed to do when it connects to a network but couldn't get IPv4 connectivity? Or if an IPv6-enabled host gets a rogue RA with incorrect information?
But they are out of scope for this draft (though we do  discuss it in the Security section, which will be expanded in the next revision.

Does it make sense?

---* 
Yeah it makes sense, however, it's more than just a security problem as most of the time it's misconfigurations as well. So, a wild DHCP server that sends DHCP offers/replies sometimes, or a segment with (2) routers in HA, where one is configured to send the pref64 but the other isn’t and the host sees varying behavior. So, it's more likely network misconfiguration than it is security problems.
 

> 2. I would argue that this section should be a MUST and not a SHOULD. At least in the case of conducting DAD. Especially since it is a MUST in RFC 8504 Node requirements for all nodes to conduct DAD.
>
>    The node SHOULD treat its CLAT IPv6 addresses as any other IPv6
>    address and comply with [RFC4861] and [RFC4862].  In particular:
>
>    *  Performing Duplicate Address Detection for each dedicated CLAT
>       address (Section 5.4 of [RFC4862]);
>
>       -  Justification: performing DAD minimizes loss of connectivity in
>          the unlikely event of address collision.  Additionally, real
>          world deployment experience shows that network infrastructure
>          devices mandate a DAD packet from the client before enabling
>          network access.
>
>    *  Processing received unicast Neighbor Solicitations (NSes) as well
>       as multicast ones sent to the solicited-node multicast address
>       ([RFC4861]) for the node CLAT addresses.

Ah, that's a good one. It was 'MUST' in -04, but after discussion during the v6ops session at IETF122 we changed it to SHOULD, as Lorenzo pointed out that it's very hard to do. So we downgraded it to SHOULD with clarifications.
Personally, I agree it should be MUST, especially as
https://datatracker.ietf.org/doc/html/rfc4862#section-5.4 says:
"Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface,..." (there are exceptions but they are not applicable in the CLAT case).

Lorenzo, any comments? Should we keep clarifications but use MUST? I recall you mentioned you migth be OK with it?

---*
I think this is a big deal, and I still don't understand why a CLAT node should be exempted from DAD. I haven't heard a good argument that can't be used for other things in the network as well. Unless I am missing something this should be a MUST.



> 3. Since RFC 1918 addresses can't be NATed in NAT64 using the 64:ff9b:: prefix, maybe having some discussion on recommending not using that prefix if the network provides 1918 addressing and CLAT nodes are needed to communicate with them.

Ah, funny you should ask..
First of all, I've never seen a PLAT implementation which follows that MUST.
Secondly, as we discussed in Madrid - maybe it's time to reconsider?
You are suggesting  "recommending not using that prefix if the network provides 1918 addressing and CLAT nodes are needed to communicate with
them.": when a node starts CLAT, using 64:ff9b::/96 and - how does it know if it is needed to communicate with private IPv4 addresses?
Also, that requirement is defined in rfc6052, which specifies the translation algorith which is used by CLAT. So, strictly speaking, it is already MUST - an RFC6052-compliant CLAT implementation would fail translating a packet from 192.0.0.0/29 to private destinations anyway.
It's not about enabling/disabling CLAT, it is expected to be hardcoded deeper in the translator algorithm, which is out of scope for this document.


---*
I am saying this for the application of CLAT for operators not the software implementation itself. Make it a SHOULD to say when RFC 1918 addresses are known and being used in a network, do not use the well-known 64:ff9b::/96 prefix. The prefix should be a configurable aspect anyway right? I know that is how the linux clatd is implemented.



> 4. I also agree that the appendix diagram could get very confusing very fast as each conditional application were added. I'm a bit torn on this, because it could shed a lot of light to alleviate confusion for some but could cause a lot of confusion with others. Many in our field love pictures and this could be one that will help a lot.

So would you prefer to keep it in the appendix (maybe with some clarifying text about 'it doesn't cover all possible cases, it's just an illustration for overall state machine") or to delete it?

---* 
Honestly, I could go either way here, I see it either way.





> -----Original Message-----
> From: Jen Linkova <[e-mail]>
> Sent: Monday, August 18, 2025 10:27 PM
> To: Edward Lemon <[e-mail]>
> Cc: IPv6 Operations <[e-mail]>
> Subject: [v6ops] Re: IETF WG state changed for draft-ietf-v6ops-claton
>
> [EXTERNAL] Verify links and attachments with sender.
>
> Hi Ted,
>
> Thank you for such a detailed review!
> Sorry for the delayed response, comments inline.
>
> On Mon, Aug 11, 2025 at 7:22 PM Edward Lemon <[e-mail]> wrote:
> >> Because IPv4-only networks are inherently IPv6-ignorant, they might lack IPv6 layer2 security features, such as RA Guard, that would prevent spoofed RAs. An attacker can send an RA containing the PREF64 option, while the network doesn't provide any PLAT functionality. If the node keeps CLAT enabled and uses it for IPv4-only destinations, that traffic could be dropped (availability attack) or routed through an attacker-controlled route (active attack on insecure traffic or hoarding secure traffic for "Harvest Now, Decrypt Later" attacks for non-PQC secure traffic, see Section 8 of [I-D.ietf-pquip-pqc-engineers]). Rogue RAs can also disturb traffic to destinations that support both IPv4 and IPv6 by causing IPv6 through an attacker's PLAT to be used instead of the legitimate network owner's IPv4 path.
> >
> >
> > This is very specific to managed networks,
>
> Actually it is also applicable for unmanaged networks. If a managed network allows for rogue RAs to be sent, we can call it ‘a misconfiguration’ and let the administrators figure it out and fix it.
> In unmanaged networks such cases are much harder to detect/troubleshoot.
>
> >and nodes don't know whether or not they are on managed networks. On an unmanaged IPv6-only network with PREF64, do we suppose that the opposite attack (a rogue DHCPv4 server) is not possible? In this case turning off CLAT enables, rather than preventing, the attack.
>
> You are right, both attack vectors are possible. However, the authors believe that those scenarios are not really equal: nowadays it looks much more likely that an IPv4-only network has  IPv6-unaware admin/configuration, than an IPv6-only network not having IPv4 L2 security features deployed.
>
>
> > On managed networks, I think it's pretty clear that a better approach, if you are managing an IPv4-only network, is to have RA guard deployed if you don't want there to be RAs. Expecting the node to be able to figure out when to ignore RAs and when to ignore DHCP configurations isn't realistic.
> >
> > And in the unmanaged network context, which BTW is most networks, if we want the user to be safe, we should propose a way to make that happen that doesn't rely on the node guessing correctly.
>
> So, the network gives the host two signals:
>
> - It offers an IPv4 address via DHCP (no Option108). This looks like a strong indication that the network wants the host to use IPv4 (otherwise it would have provided 108).
> - It also sends PREF64. It allows the host to enable CLAT but it can’t be used as a strong signal indicating what the network wants hosts to do.
>
> So the host is getting two conflicting signals. It might be a misconfiguration, it might be an attack or it might be a transition period before migrating the network to IPv6-mostly.
>
> There is no way to make a choice which is 100% safe (if the host still enables CLAT, it allows attacks based on rogue RAs, and if CLAT is disabled, it enables a rogue DHCP attack vector). So it comes down to risk management: how probable is the attack, what the impact, what’s the cost of mitigation.
>
> As I’ve mentioned already, a rogue RA in an IPv4-only network does look much more likely currently. By the time this changes (when IPv6-only networks are the default) we can revisit this in the context of CLAT being less necessary in the first place..
>
> Thank you for making that point, I think we should expand this text (or move some of it to the Security Considerations, probably).
>
> > Thus:
> >
> > >There are some corner cases when the administrator might prefer the node to use CLAT even if the native IPv4 connectivity is available (e.g. for performance reasons, if IPv4 as a Service performs better than native IPv4). However for the reasons described above such behaviour MUST be explicitly enabled by the administrator via a configuration knob and MUST NOT be a default behaviour, especially for unmanaged nodes.
> >
> >
> > Also seems like questionable advice. Realistically, on most networks no such configuration knob exists. And is the idea that we would configure this on the node?
>
> Yes. Basically, always enable CLAT - no matter what DHCP tells you.
> Strictly speaking such knobs do exist: I can build a CLAT on my linux machine and start it unconditionally.
>
>
> >What happens when the node is connected to a network for which this advice doesn't necessarily apply? E.g. an end user laptop that roams between work and home. At work, perhaps we want to enable CLAT when there is IPv4. At home we probably don't want that. But who knows? Reasoning about this now, based on what sorts of networks are commonly deployed now, is not particularly future-proof.
>
> That’s why this text is *allowing* for the knob to exist, but the administrator MUST enable it explicitly. So it’s all about managed networks. For example, I would definitely want this behaviour on workstations and servers, which do not move between networks. If we do not have this text, any node which enables CLAT unconditionally would violate requirements in this draft.
>
>
> > My point here is that I think someone proposed adding this advice because it made sense to them and they wanted to close a gap, but I don't think a serious threat analysis has been done, and I don't think the language in the document actually does a good job of mitigating possible threats. If we want to actually solve this problem, we should come up with a serious solution and not hand-wavey advice. And hence we should not give hand-wavey advice that is maybe usually right now but can't be assumed to continue to usually be right going forward.
> >
> > So, if you think that the right thing to do is to disable CLAT when native IPv4 is present, I think it would be better to just say that, and not claim that this solves a problem it doesn't fully solve.
>
> IMHO, there are at least two reasons to document what hosts are supposed to do:
>
> 1. It makes implementations behave more predictable during gradual rollouts, which is the safe way of moving to IPv6-mostly networking.
> For example, when I was rolling out IPv6-mostly in my network, I first rolled out PREF64 on all routers (well in advance), and then I was enabling 108 on a per-vlan basis. So there was a substantial period of time when my network was providing hosts with PREF64 but not option 108. Fortunately, all endpoints behaved the same and kept using IPv4 until they received option 108, otherwise it would have been a disaster.
>
> 2. People might disagree but we strongly believe it’s beneficial to document the reasoning behind decisions. So later, when we might want to reconsider, we know what made us put those “MUST” and “SHOULD” and whether those reasons are still applicable.
>
> Let us try to come up with a better threat analysis if one is needed, instead of removing all reasonings from the text.
>
> >> A dedicated prefix model, which Section 4.1 of [RFC6877] calls "wireline network architecture".
> >
> >
> > Does importing the terms "wireline" and "wireless" from RFC6877 benefit this document in any way? If not, I'd just take that out—there's a lot of additional text to try to clarify why these terms don't mean what they literally mean, when I think just not using these terms at all would be clearer. After reading these two paragraphs, I have no idea what either of the terms means. Why not just explain what they mean here using the new terms, which seem clearer to me even though I don't at this point actually know what they mean.
>
> We are using the old terms (“wireline” and “wireless”) only in this section, exactly to establish the mapping between the old and the new terms, so the reader of this document who is familiar with RFC6877 was not confused.
>
> Would it be better if we rephrase the text and remove the last sentences in each bullet point, starting from “Despite the word ..”?
> So the text will look like
>
> "There are two different 464XLAT deployments models:
>
> * A dedicated prefix model ([RFC6877] uses the term "wireline network architecture"). In that case, the node performing CLAT functions also extends the network downstream and provides network connectivity services to other connected systems. Those systems can be physical (e.g. various clients connected to a CPE router), or logical (e.g.
> virtual systems running on a node, while the host system acts as a router and performs CLAT). In all those cases, systems behind the CLAT node usually use [RFC1918] addresses.
>
> * A single-address model, ([RFC6877] uses the term "wireless network architecture"). In that case, the CLAT instance provides an IPv4 address and the default route to the local node's network stack only.
> When [RFC6877] was published, this deployment scenario was  limited to 3GPP cases, while currently it is also deployed in other types of networks, such as enterprise networks and Wi-Fi hotspots, where hosts (as mobile phones, laptops and desktops) use CLAT to provide connectivity to IPv4-only local applications."
>
>
> >
> >> This approach limits the number of CLAT instances per node to 8, which seems to be more that sufficient at the time of writing. If in the future some deployment scenarios require more that 8 CLAT instances per node, a new larger IPv4 range will be requested from IANA.
> >
> >
> > This appears to be limited to the "wireless" case.
>
> The whole paragraph is about the single address model. It currently begins with:
>
> “In the single-address model, the CLAT instance needs a single IPv4 CLAT address and a single CLAT-only IPv6 address (which is distinct from the one or more IPv6 addresses used by the node running CLAT for its own native IPv6 connectivity, see Section 7.2). The node providing CLAT functions to local applications SHOULD use IPv4 addresses from the dedicated 192.0.0.0/29 range..”
>
> We’ll look into clarifying that text even more, thank you!
>
>
> > As I read back through the documents to understand that, I became even more convinced that you should not use these terms—they just make the document hard to read. You should have a terminology section where you define the two addressing modes, and not use the terms "wireless" and "wireline" anywhere else in the document. Just my opinion, but honestly, this is really confusing.
>
> The term “wireline” is used 3 times in the doc, once in the introduction and twice in the list in the section 7.1 - with the proposed changes (see above) it will be used once in 7.1. We’ll update the introduction to remove “wireline”.
>
> “Wireless” is used exclusively in 7.1, and nowhere else - so it’s only for explaining how the new term is related to RFC6877 terminology.
> With the changes proposed above, the word “wireless” will be used only once. Would that address your concern?
>
>
> > I would suggest turning the first two paragraphs of section 7 into the terminology section, and explicitly say that the dedicated prefix model means using an RFC1918 prefix, and the single-address model means using an RFC7335 prefix, and that they are otherwise the same. And then just say "this model is called wireline in RFC6877, but that term is no longer accurate and therefore is not used here" and the same for "wireless."
>
> Ack, will update the text
>
>
> >> The node MUST NOT send packets on wire from the local CLAT address.
> >
> > This implies there's only one, but in both cases there's actually a prefix, so maybe say prefix rather than address?
>
> How about "In a single-address model, the node MUST NOT send packets on wire from the addresses belonging to the CLAT prefix"?
> Or "The node MUST NOT send packets on wire from the local CLAT addresses"?
>
> >> The host SHOULD use 255.255.255.255 as a netmask for the CLAT address. That allows all 8 addresses from 192.0.0.0/29 to be used, if needed.
> >
> > Maybe add "since this means that each address is treated as being its own subnet, rather than being part of a subnet delineated by the prefix." Maybe that's obvious—I guess I figured it out.
>
> Makes sense, will update the text
>
>
> >> In a dedicated prefix model, the CLAT instance MAY do one of the following:
> >> - Perform stateful NAT44 to translate all IPv4 addresses from the dedicated prefix to a single IPv4 address, then perform stateless CLAT.
> >>  - Obtain a dedicated IPv6 address for each CLAT IPv4 address
> >>   - Obtain a dedicated /64 prefix via DHCPv6-PD.
> >
> > This feels really thin, and I'm starting to remember that the dedicated prefix model wasn't central to this work. There are paragraphs and paragraphs following this that describe the single-address model, but there's no further discussion of the dedicated prefix model. That's consistent with the previous comments I made about section 7. I wonder if this is actually making things better, or just confusing the issue? Maybe this should just say "the dedicated prefix model is out of scope for this document" or something like that.
>
> To be honest I’m not sure it’s a good idea. The difference between the single-address and the dedicated prefix is minimal. If you think we are missing some requirements for the dedicated prefix - we should fix it. Writing recommendations about what a phone, for example, should do when it does CLAT for an IPv4 app running locally but completely avoiding the discussion about tethering behaviour might be undesirable.
>
> Also, until we get PD-per-host on laptops/desktops, they might use CLAT in both single-address mode and dedicated prefix (e.g. when virtualization is enabled). Why should we avoid giving guidance?
>
> >> In a single-address model, the CLAT instance SHOULD obtain a 
> >> dedicated IPv6 address used exclusively for CLAT functions.  This 
> >> is required [...]
> >
> >
> > What's the exception that makes this not a MUST? "This is required..." seems to be saying that it's a MUST, not a SHOULD...
>
> How about s/This is required/This is needed/?
>
> .I guess we need to clarify the text further to say this is necessary 
> to avoid state-requiring complications rather than required in the
> 2119 sense. The goal of this paragraph was to explain that w/o a dedicated address, CLAT cannot be stateless and the node would need to keep the state. So if the implementors are willing to go that path…well..
>
> >> the CLAT instance SHOULD ensure that the address is 
> >> checksum-neutral
> >
> >
> > What does "checksum-neutral" mean? I get what the effect is, but as an implementor what code do I need to write?
>
> Good point, we’ll update the text.
> Clarifying question: are you looking for a definition of it, or for an algorithm to generate it?
>
> >> 464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC8781] ("Discovering PREF64 in Router Advertisements") and SHOULD implement [RFC7050] ("Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis") in order to discover the provider-side translator (PLAT) translation IPv4 and IPv6 prefix(es)/suffix(es).
> >
> >
> > SHOULD or MAY? We discussed this in the Thread Group and concluded that there isn't sufficient deployment of RFC7050 in the field to justify recommending 7050. If the implementor wants to do it, more power to them, but we concluded there was no need to recommend it.
>
> Unfortunately PREF64 is non-existent in 3GPP world yet, where 7050 
> enjoys enough deployment to raise concerns from 3GPP participants in
> IPv6 forums when we initially suggested preferring 8781 in the first place.
> See https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefer8781/ as well..
>
> >> 464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC8781] ("Discovering PREF64 in Router Advertisements") and SHOULD implement [RFC7050] ("Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis") in order to discover the provider-side translator (PLAT) translation IPv4 and IPv6 prefix(es)/suffix(es).
> >
> > Why do we prefer PCP to PREF64? I don't know of any implementations that use PCP to advertise the NAT64 prefix.
>
> RFC8781 recommends a specific order. We do not think this draft is the 
> right place to make changes and update RFC8781. Anyway, if there are 
> no implementations using PCP - well, then it doesn’t really matter…:)
>
> >> 464XLAT-7: If the IPv6 Transition CE Router performs CLAT functions it SHOULD also include the PLAT prefix in Router Advertisements ([RFC8781]) sent via the LAN interfaces. If the IPv6 Transition CE Router acts as a DHCP server it SHOULD enable DHCP Option 108 ([RFC8925]) processing. The router SHOULD have a configuration knob to disable DHCP Option 108 processing.
> >
> >
> > Do you mean it SHOULD include it in a PREF64 option or a PIO option?
>
> Thank you, we’ll update the text to make it explicit that we are talking about the PREF64.
>
> >> Using the PREF64 RA option to detect PLAT presence and the NAT64 prefix is less prone to such attacks than DNS-based detection ([RFC7050]), as the attacker needs to be on-link and be able to bypass layer-2 security features such as RA Guard. Therefore Section 5 recommends the PREF64 RA option as a preferred way to detect PLAT presence.
> >
> >
> > What about PCP? Is PCP similarly robust against off-link attacks and 
> > layer 2 security? (I haven't thought about this, so I'm not saying 
> > you're wrong here, but not talking about it seems like an omission 
> > given the current stated requirements.)
>
> We are trying to be realistic here and recommend a method which can be used currently. From a practical perspective in common deployments, the actual choice is between PREF64 and DNS64, so we focus on it, to ensure that implementers are not just implementing RFC7050 and consider it done.
>
>
> >> If the instance utilizes the same CLAT address for an extensive 
> >> period of time or
> >
> >
> > I think you mean "CLAT IPv6 address" here?
>
> Yes, we’ll fix it, thank you!
>
> >How does this advice impact checksum neutrality? :)
>
> I do not think it does…May I ask you to elaborate?
>
> >> To summarize, this document does not introduce any new privacy considerations.
> >
> > I would suggest leading with this, like so:
> >
> > This document does not introduce any new privacy considerations. Existing privacy considerations not documented in RFC6877 include:
>
> Makes sense, thank you!
>
> > The flowchart in Appendix A doesn't seem to shed a lot of light. There are no states, just arrows, and it's not clear where it starts. It feels a bit escheresque, which is a valid artistic posture, of course, but not necessarily helpful for implementations. As an example, there's a box at the top left that says "has native IPv4 route?" but how do we know that? Probably via DHCP, which we only start after determining that there is no native IPv4 default route.
>
> The draft actually does discuss it. But you're right, we shall change it to “native ipv4 connectivity”
>
> >The more I look at this flowchart the more confused I get. I think it should just go away unless you want to completely rework it. As a general rule my experience has been that non-normative flow charts are more likely to create than prevent interop problems, because it's so hard to be sure that you've gotten it right. E.g. the state transition diagram in RFC2132 wound up being wrong in a way that created interop issues (long since resolved, of course) because we actually didn't clearly understand all the states until there were a bunch of implementations.
>
> The authors would like to hear the WG opinion on that. Our personal experience is that this particular flowchart did help a lot to get a clear picture of what behavior we want to achieve. If you are convinced it’s harmful we can remove it, but I’m wondering if anyone else actually found it helpful.
>
> --
> Cheers, Jen Linkova (on behalf of the draft authors)
>
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



--
Cheers, Jen Linkova