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

[Jen Linkova <[e-mail]>]

Hi Terry,

On Thu, Oct 2, 2025 at 1:15 PM Terry Sweetser <[e-mail]> wrote:

> Dear WG members,
>
> I have questions about draft-ietf-v6ops-claton-08 regarding the
> interaction between Option 108 and CLAT disable behavior. Section 6.1
> requires CLAT be disabled immediately when IPv4 appears, but shouldn't
> Option 108 presence override this to prevent rogue DHCPv4 attacks?
>

1.The client connects to the network, sends an RS and DHCPDISCOVER with
Option 108.
2. The client receives an RA with PREF64 and starts CLAT

Now, we are entering The Garden of Forking Paths...
Path1:
3a. DHCPOFFER comes with Option 108 value set to X seconds.
4a. The client stops DHCPv4 for X seconds and continues using CLAT. Section
6 doesn't apply here, as IPv4 is not obtained via DHCPv4.

Path2:
3b. DHCPOFFER comes w/o Option 108.
4b. The client configures an IPv4 address (sends  DHCPREQUEST etc). As per
Section 6 the client stops CLAT.

Path3:
3c. The client waits and receives multiple DHCPOFFERs, some with Option 108
and some w/o.
4c. In this case the outcome would depend on which OFFER the client
chooses. Section 3.2 of RFC8925 says: "If the client waits for multiple
DHCPOFFER responses and selects one of them, it MUST follow the processing
for the IPv6-Only Preferred option based on the selected response. A client
MAY use the presence of the IPv6-Only Preferred option as a selection
criterion." If the client chooses a response with Option 108, we get to 4a,
if it chooses an offer w/o it - 4b.

Section 11 does discuss the rogue DHCPv4 server attack in more detail.
Pls let me know if you think that text needs further clarifications.

Additionally, Section 10 recommends CPE signal PREF64/Option 108 to the LAN,
> but wouldn't this break CPE "stealth mode" operation (analogous to DS-Lite)
> and cause prefix exhaustion in home networks with /60 allocations
>
Has the WG considered distinguishing between CPE-based deployments (where
> CLAT should be transparent to LAN) versus host-based deployments (where
> dynamic signaling makes sense)?
>

The CPE which sends RA and acts as DHCPv4 server can not know if connected
devices are "pure hosts" or also CPEs, right?

If you have a controlled environment, where you can guarantee that all
devices connected to your CPE are also CPEs and you do not want that
upstream CPE to send Option 108 and PREF64 to the downstream devices, you
can indeed configure it not to include that information.
Would you prefer 464XLAT-7 to say "unless configured not to do so"
explicitly?


> Regards,
>
>
> <https://about.me/terry.sweetser?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb>
> Terry Sweetser
> about.me/terry.sweetser
> <https://about.me/terry.sweetser?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb>
>
>
> On Thu, 28 Aug 2025 at 10:51, Nick Buraglio <[e-mail]>
> wrote:
>
>>
>>
>> On Sun, Aug 24, 2025 at 9:21 PM Jen Linkova <[e-mail]> wrote:
>>
>>> On Sat, Aug 23, 2025 at 5:10 AM Nick Buraglio
>>> <[e-mail]> wrote:
>>> > > A dedicated prefix model, which Section 4.1 of [[RFC6877](
>>> https://www.ietf.org/archive/id/draft-ietf-v6ops-claton-06.html#RFC6877)
>>> calls "wireline network architecture".
>>> >
>>> > Suggest "non-mobile, described as 'wireline' in Section 4.1 of
>>> [RFC6877](
>>> https://www.ietf.org/archive/id/draft-ietf-v6ops-claton-06.html#RFC6877)"
>>> or something such to imply that this is not a cellular/mobile network,
>>> which I suspect was the intention of that statement. I do think it is
>>> useful to bridge those terms since RFC6877 is a fairly important foundation
>>> of this doc.
>>>
>>> Actually the intention is to clarify that the media - wireless or
>>> wired - has nothing to do with the model. The only difference between
>>> those models is using a single address to provide IPv4 for local
>>> applications vs a subnet to extend IPv4 connectivity downstream.
>>>
>>> > Or, perhaps simply add it to the terminology section:
>>> > Wireline: "a non-mobile node, as described as in Section 4.1 of
>>> [RFC6877](
>>> https://www.ietf.org/archive/id/draft-ietf-v6ops-claton-06.html#RFC6877)
>>>
>>> Based on Ted's comments, we updated the Terminology section, adding
>>> the following:
>>>
>>> Dedicated prefix model: a scenario when the node performing CLAT
>>> functions also extends the IPv4 network connectivity downstream, to
>>> other connected systems. See Section 7.1. While [RFC6877] uses the
>>> term "wireline network architecture", this scenario is also applicable
>>> for wireless or 3GPP routers. Therefore the term "wireline" is no
>>> longer accurate and not used in this document.
>>>
>>> Single-address model: a scenario when the node performing CLAT
>>> functions provides an IPv4 address and the default route to the local
>>> node's network stack only. See Section 7.1. While [RFC6877] uses the
>>> term "wireless network architecture", this scenario is applicable for
>>> wired networks as well (e.g. desktops or servers using wired
>>> connections). Therefore the term "wireless" is no longer accurate and
>>> not used in this document.
>>>
>>> Would that address your concern?
>>>
>>
>> +1
>>
>>
>>> >
>>> > #### Section 7.2:
>>> >
>>> > > Section 6.3 of [RFC6877] recommends that the CLAT instance acquires a
>>> > > dedicated /64 for translating between IPv4 and IPv6, and only uses a
>>> > > single interface IPv6 address if a dedicated prefix is not available
>>> > > via DHCPv6-PD.
>>> >
>>> > s/uses/use
>>>
>>> Sorry, I need more coffee :) Why?
>>> Section 6.3 recommends that the CLAT instance acquires....and only
>>> uses...
>>>
>>> "Uses" here is the third person singular, as the subject is 'the CLAT
>>> instance'.
>>>
>>
>> I can go either way. It just reads as odd to me, but that could very well
>> be a "me problem" =)
>>
>>
>>> >
>>> > > The node SHOULD treat its CLAT IPv6 addresses as any other IPv6
>>> >
>>> > I think this should be a MUST in cases of at least DAD, I'm struggling
>>> to find a reason not to say it all shouldn't be a MUST.
>>>
>>> Yes, this will be updated in the next revision.
>>>
>> +1
>>
>>>
>>> > #### Section 12
>>> >
>>> > minor nit:
>>>
>>> Done, thank you!
>>>
>>
>> +1
>>
>>>
>>> > On Thu, Aug 21, 2025 at 7:58 AM Jeremy Duncan <jduncan=
>>> [e-mail]> wrote:
>>> >>
>>> >>
>>> >> **** inline below.
>>> >>
>>> >> -Jeremy
>>> >>
>>> >> -----Original Message-----
>>> >> From: Jen Linkova <[e-mail]>
>>> >> Sent: Wednesday, August 20, 2025 8:33 PM
>>> >> 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.
>>> >>
>>> >> Hi Jeremy,
>>> >>
>>> >> On Wed, Aug 20, 2025 at 10:38 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.
>>> >>
>>> >> Oh yes, indeed - the network might provide hosts with invalid
>>> configuration information intentionally (an attack) or unintentionally
>>> (misconfiguration/bugs etc).
>>> >> But at the end of day,  the result is the same: DHCPv4 or RAs content
>>> leads to broken connectivity for the host.
>>> >> I still do not think the problem needs to be solved by CLAT.
>>> >>
>>> >>
>>> >> ****
>>> >> OK, would a good compromise state that the system must provide some
>>> alert or notification that something is happening on the network that is
>>> causing erratic enabling/disabling of the CLAT?? I really think the CLAT
>>> should react to this somehow as this will cause network problems where the
>>> operator would not know how to even troubleshoot.
>>> >>
>>> >>
>>> >>
>>> >> > > > 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:
>>> >>
>>> >> > > 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.
>>> >>
>>> >> I think we are in a violent agreement here ;) May I propose the
>>> following: we keep 'MUST' but clarify that some existing implementations do
>>> not do this, which, in turn, causes some issues.
>>> >>
>>> >> ****
>>> >> Yes, I agree with this approach
>>> >>
>>> >>
>>> >>
>>> >> > > > 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.
>>> >>
>>> >> > > "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.
>>> >>
>>> >> I'm a bit confused, to be honest...may I ask you to elaborate?
>>> >> So:
>>> >> - the interface comes up
>>> >> - the host gets an RA with PREF64=64:ff9b::/96, no IPv4 detected
>>> >> - clat starts
>>> >> - ...some time later the user decided to ping 10.1.1.1 What should
>>> the CLAT do? Drop the packet?
>>> >>
>>> >> Or are you talking specifically about a scenario when multiple
>>> PREF64s are obtained on a given interface?
>>> >>
>>> >>
>>> >> ****
>>> >> I see your misunderstanding here. I am not suggesting the CLAT
>>> implementation do anything. I am basically asking that a statement
>>> outlining a recommendation to not use the 64:ff9b::/96 prefix if RFC 1918
>>> addressing exists in the network. This is not a requirement to enforce on
>>> the CLAT implementation but as an operator to review. As this is meant to
>>> be a node recommendation it should be a place to do this, or no?
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> > > -----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
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Cheers, Jen Linkova
>>> >> _______________________________________________
>>> >> v6ops mailing list -- [e-mail]
>>> >> To unsubscribe send an email to [e-mail]
>>>
>>>
>>>
>>> --
>>> Cheers, Jen Linkova
>>>
>> _______________________________________________
>> 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]
>


-- 
Cheers, Jen Linkova