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

[Lorenzo Colitti <[e-mail]>]

I read this document and I think there are two issues that need to be
resolved before it progresses.

First, I think there is some confusion about the addressing models (section
7.2). RFC 6877 defines two models:

   - A dedicated prefix model, where the CLAT uses stateless NAT46 (RFC
   7915) to translate the IPv4 addresses behind it to IPv6 addresses within
   the prefix. This implies that the dedicated prefix must be of one of the
   types in RFC 6052 section 2.2 (because that's how stateless NAT46 works;
   that's stated in RFC 6877 section 6.1).
   - A single-address model, where the CLAT only translates packets from a
   single IPv4 address belonging to the CLAT itself. This model is commonly
   implemented by mobile OSes, and can only support multiple IPv4 addresses by
   using NAT44. This is defined in section 6.3.

This draft doesn't define these models clearly, and doesn't say which
requirements apply where. In particular, these statements in section 7.2
are incorrect:

   - "Perform stateful NAT44 to translate all IPv4 addresses from the
   dedicated prefix to a single IPv4 address, then perform stateless CLAT."
   This is incorrect - the dedicated prefix is an IPv6 prefix, not an IPv4
   prefix. Stateful NAT44 is used in the single-address model, not in the
   dedicated prefix model.
   - "Obtain a dedicated IPv6 address for each CLAT IPv4 address." I don't
   think this is correct - the translation must be stateless NAT46 as defined
   in RFC 7915 and RFC 6052. In the dedicated prefix model, the CLAT cannot
   "obtain" addresses from the network, it must translate them statelessly.


Second, this text:

=====
In a single-address model, the CLAT instance SHOULD obtain a dedicated IPv6
address used exclusively for CLAT functions. This is needed to
differentiate between inbound native IPv6 traffic and traffic which needs
to be passed to the CLAT instance. For example:
=====

Should say that the address MUST be dedicated to clat. for two reasons:

   1. The translation must be stateless, as stated several times in RFC
   6877 (including in the title). This draft explains why ("This is needed to
   differentiate between inbound native IPv6 traffic and traffic which needs
   to be passed to the CLAT instance").
   2. RFC 6877 section 6.3 says, "one interface IPv6 address that is
   claimed by the CLAT via the Neighbor Discovery Protocol (NDP) and defended
   with Duplicate Address Detection (DAD)".

It's not possible to run 464xlat on an address that also carries native
traffic, because doing so requires stateful NAT46, and 464xlat uses
stateless NAT46. It might be possible to design a different translation
mechanism that uses stateful NAT46 on the customer side, but such a
translation mechanism is not 464xlat.

On Thu, Jul 31, 2025 at 6:26 AM Nick Buraglio <[e-mail]>
wrote:

> This begins the working group last call of
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-claton/
> Please review this document and provide feedback at your convenience.
> This adoption call will conclude 13-Aug-2025
>
> Thanks!
> Nick, Ron, Xipeng
>
> ---------- Forwarded message ---------
> From: IETF Secretariat <[e-mail]>
> Date: Wed, Jul 30, 2025 at 4:23 PM
> Subject: IETF WG state changed for draft-ietf-v6ops-claton
> To: <[e-mail]>, <[e-mail]>
>
>
>
> The IETF WG state of draft-ietf-v6ops-claton has been changed to "In WG
> Last
> Call" from "WG Document" by Nick Buraglio:
>
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-claton/
>
>
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>