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

* 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

- 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]