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

[Nick Buraglio <[e-mail]>]

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
>