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

[Tore Anderson <tore fud no>]

* Bjørn Mork

> I'm not going to pretend I have anything to say WRT mobile access.  I'm
> just a normal user there, (ab)using whatever cabal I can to become part
> of the tests going on :-)
>
> So I can only state the obvious: They are testing IPv6 only access using
> DNS64/NAT64/464XLAT. When this will be provided as a normal commercial
> service depeds on lots of stuff.  Some of it is even technical...
>
> The challenges are similar to those which have prevented us from doing a
> full DSL/FTTH IPv6 rollout yet: The end user experience depends on the
> terminal equipment.  Degraded user experience due to IPv6 is
> unacceptable.  Most terminal equipment sucks bigtime.  And it sucks even
> more if you enable IPv6.
>
> Yes, _some_ Android phones will just work in a DNS64/NAT64/464XLAT
> environment.  But that's still an exception, unfortunately. And even
> those that work may have small, but stupid and unnecessary, problems
> like the lack of IPv6 tethering you helped me sort out in another list.

Well, I'm crossing my fingers you'll be able to sort out the challenges
and see you guys show up with more than a meager pixel in my graphs at
<http://fud.no/munin/Networking/Networking> pretty soon, both for mobile
and fixed. I do believe that you'll be able to dethrone Get as the
biggest IPv6 deployment in .no pretty easily, at least if you get your
ZyXEL CPEs enabled. :-)

Anyway, Network Norway actually fixed their NAT64 yesterday so I'm fine
for now. \o/

> bjorn nemi:~$ mmcli -b 0
> Bearer '/org/freedesktop/ModemManager1/Bearer/0'
>   -------------------------
>   Status             |   connected: 'yes'
>                      |   suspended: 'no'
>                      |   interface: 'wwan0'
>                      |  IP timeout: '20'
>   -------------------------
>   Properties         |         apn: 'telenor.ipv6'
>                      |     roaming: 'allowed'
>                      |     IP type: 'ipv6'
>                      |        user: 'none'
>                      |    password: 'none'
>                      |      number: 'none'
>                      | Rm protocol: 'unknown'
>   -------------------------
>   IPv4 configuration |   method: 'unknown'
>   -------------------------
>   IPv6 configuration |   method: 'static'
>                    |  address: '2a02:2121:1:8d03:1071:2644:9af8:1353'
>                    |   prefix: '64'
>                    |  gateway: '2a02:2121:1:8d03:b8aa:bdb9:24af:f588'
>                    |      DNS: '2001:4600:4:fff::54', '2001:4600:4:1fff::54'
>
>
> bjorn nemi:~$ ifconfig wwan0
> wwan0     Link encap:Ethernet  HWaddr f6:6f:09:a5:cc:39  
>           inet6 addr: fe80::f46f:9ff:fea5:cc39/64 Scope:Link
>           inet6 addr: 2a02:2121:1:8d03:f46f:9ff:fea5:cc39/64 Scope:Global
>           UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
>           RX packets:15750 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:10439 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000 
>           RX bytes:17693802 (16.8 MiB)  TX bytes:2424185 (2.3 MiB)

Hmm, interesting. Is there some support for IPv6 on mobile broadband in
NM nowadays? On my Fedora 20, there is no «IPv6» tab in
nm-connetion-editor for mobile broadband connection profiles like there
is for e.g. WiFi. Also I find it curious that ModemManager knows
anything about Layer 3, as I thought that would be NetworkManager's job.
Hmmm! I'll have to fiddle around more with this I think...

> bjorn nemi:~$ ip -6 route
> 2a02:2121:1:8d03::c1a7 dev clat  metric 1024 
> 2a02:2121:1:8d03::/64 dev wwan0  proto kernel  metric 256 

Also this I find interesting. I first tried setting up TAYGA on my
desktop connected to an Ethernet segment with routing looking pretty
much like yours, but I ran into a problem - my CPE would do ICMPv6 NS
for the ::c1a7 address, not getting any NA responses because that
address isn't found anywhere on the Ethernet link.

Is the fact that it works for you on Ethernet some artifact of the
Ethernet implementation in the WWAN module being bastardised in some way
causing it to blindly forward everything in the /64 to the fake MAC
address f6:6f:09:a5:cc:39, or did you manage make the Linux IPv6 stack
respond to NS for the ::c1a7 address, or convince the WWAN module to
send packets to ::c1a7 to f6:6f:09:a5:cc:39 in some other way?

If it's blindly forwarding everything to your computer, does that mean
that bridging wwan0 with e.g. wlan0 (to make a wireless hotspot, say)
won't work?

Tore