Re: little bit off topic CLAT-Daemon for 464xlat for "Linux" (not android)

[Tore Anderson <tore fud no>]

* Bjørn Mork

> FWIW I've had a tayga NAT64 test setup running at home all those three
> years and I'm inclined to believe it hasn't seen any development because
> it's already complete :-)
>
> I know that is a strange thing to say about any software, but the fact
> is that tayga works really well.  And it also scales surprisingly
> well. I cannot see any reason to replace tayga with an in-kernel
> implementation.  You'll either do fine with tayga, or you'll buy some
> hardware accelerated NAT64 solution.  There just isn't any need for
> in-kernel software based NAT64.

Well, I would have liked an option to set the IPv6 Path MTU to something
else than 1280, which is the hard-coded default. That's however
primarily for data centre usage, where I know that the path between the
TAYGA instance and the IPv6 servers can support at least 1500. Also I
believe it is single-threaded, which does give me some pause with
regards to performance in such an environment where we're talking
throughput in Gb/s rather than Mb/s.

However, come to think of it, it being stateless and all I can probably
just spin up as many TAYGA processes as I have CPU cores and do ECMP
between them. :-)

In any case, I guess you're right. For CLAT usage, TAYGA should do just
fine.

> > - If we can rely on all 3GPP modems that are operating in fake Ethernet
> > mode to do blind forwarding of all IPv6 traffic to the MAC address of
> > the fake Ethernet interface without doing NS for them first (my HP
> > hs2350 a.k.a. Ericsson F5321gw behaves like that), you don't have to
> > muck about with ND proxy at all.
>
> I don't think you can rely on this.  There are modem firmwares requring
> NS between modem and host, even if it is meaningless.  Thomas knows :-)

Ugh. I suppose that makes implementing sharing somewhat painful. If the
firmware does perform NS, you can't move the /64 off to some other link
à la draft-ietf-v6ops-64share, you'd have to bridge it. However if the
firmware does not perform NS, you can move the /64, but you can't bridge.

I suppose in theory you could have always move the /64 and set up ND for
the entire prefix to deal with firmwares requiring NS/NA, but "ip -6
neigh add proxy" only seems to accept single hosts, not prefixes, so
that option is out as well - you certainly don't want a neigh cache with
2^64 entries...

> But I don't think the CLAT feature should be tied to 3GPP in any case,
> even if that's where it is most likely to be used.  It could be made
> more generic, depending on:
>  a) no IPv4 default route, and
>  b) IPv6 default route points to an interface with a /64 prefix and
>     autoconf true, and
>  c) NAT64 detected
>
> If all these are true, then it makes sense to enable CLAT.  The outgoing
> interface type doesn't matter.

Agreed. Except that for that you can do DHCPv6 IA_PD or IA_NA at point B
if autoconf is off. In fact RFC 6877 suggests a CLAT should first try to
get an IA_PD prefix, and only fall back on a single IPv6 address if
that's not available. That's beneficial in the case of hotspot/sharing,
as then the device with the CLAT doesn't have to implement stateful
NAPT44 from the "LAN", it can just do a stateless 1:1 from an IPv4 /24
to an IPv6 /120 for example.

Tore