MAP-T

[fl4co]

 In my country, Italy, Sky (the satellite TV provider) became an ISP and started with a dual-stack network, but it's planning to switch to IPv6-only by the end of the year and you need a router supporting MAP-T to access their network.

There is a failry new law in Italy that allows a customer to use any router they want with their ISP, but as far as I know only the router provided by Sky, and OpenWrt, support MAP-T among consumer routers. It may be a good idea to support MAP-T since not many routers support it right now.

Would Keenetic be interested in implementing MAP-T?

Edited June 19, 2021 by fl4co

[Le ecureuil]

Interesting idea, but we need example set of settings.

[fl4co]

54 minutes ago, Le ecureuil said:

Interesting idea, but we need example set of settings.

In their configuration page they just say this:

• IPoE IPv4/IPv6 protocol
• NAT: MAP-T Mapping of Address and Port, Translation mode (RFC7599)

I will post more information when they make the switch or if they release new information.

Edited June 19, 2021 by fl4co

[fl4co]

Hello, are there any news on the MAP-T implementation? Since mid December Sky Italia officially switched to MAP-T, especially for new customers. Old customers are in MAP 1:16, MAP 1:1 if port forwarding is detected and in dual stack in some rare cases (but bound to switch to MAP-T in January).

Sky Italia seems to be one of the fastest growing ISPs in Italy, and there's currently no alternative to their CPE besides customized OpenWrt which is not feasible for non techincal users. It would be nice to have Keenetic as an option.

[edoardo396]

I'm interested on this as well.

For reference this is the configuration they are using, taken from a working OpenWRT router with 1:16 sharing ratio profile.

It is passed via DHCPv6 option 95, then passed to the nat46 module by odhcp6c (on OpenWRT)

root@RouterMi:~# cat /tmp/map-wan6_4.rules
rule=fmr,type=map-t,ealen=16,prefix4len=20,prefix6len=32,ipv4prefix=101.56.48.0,ipv6prefix=2a0e:41b::,offset=6,psidlen=4,psid=57344,dmr=2a0e:402:101:101::/64,
RULE_1_FMR=1
RULE_1_EALEN=16
RULE_1_PSIDLEN=4
RULE_1_OFFSET=6
RULE_1_PREFIX4LEN=20
RULE_1_PREFIX6LEN=32
RULE_1_IPV4PREFIX=101.56.48.0
RULE_1_IPV6PREFIX=2a0e:41b::
RULE_1_IPV6PD=2a0e:41b:xxxx::
RULE_1_PD6LEN=48
RULE_1_PD6IFACE=wan6
RULE_1_IPV6ADDR=2a0e:41b:xxxx::6538:36f1:e
RULE_BMR=1
RULE_1_IPV4ADDR=101.56.54.x
RULE_1_ADDR4LEN=32
RULE_1_PORTSETS='1920-1983 2944-3007 3968-4031 4992-5055 6016-6079 7040-7103 8064-8127 9088-9151 10112-10175 11136-11199 12160-12223 13184-13247 14208-14271 15232-15295 16256-16319 17280-17343 18304-18367 19328-19391 20352-20415 21376-21439 22400-22463 23424-23487 24448-24511 25472-25535 26496-26559 27520-27583 28544-28607 29568-29631 30592-30655 31616-31679 32640-32703 33664-33727 34688-34751 35712-35775 36736-36799 37760-37823 38784-38847 39808-39871 40832-40895 41856-41919 42880-42943 43904-43967 44928-44991 45952-46015 46976-47039 48000-48063 49024-49087 50048-50111 51072-51135 52096-52159 53120-53183 54144-54207 55168-55231 56192-56255 57216-57279 58240-58303 59264-59327 60288-60351 61312-61375 62336-62399 63360-63423 64384-64447 65408-65471 '
RULE_1_DMR=2a0e:402:101:101::/64
RULE_COUNT=1

root@RouterMi:~# cat /proc/net/nat46/control 
add map-wan6_4
insert map-wan6_4 local.v4 0.0.0.0/0 local.v6 ::/0 local.style NONE local.ea-len 0 local.psid-offset 0 remote.v4 101.56.48.0/20 remote.v6 2a0e:41b::/32 remote.style MAP remote.ea-len 16 remote.psid-offset 6 debug 0
config map-wan6_4 local.v4 101.56.48.0/20 local.v6 2a0e:41b::/32 local.style MAP local.ea-len 16 local.psid-offset 6 remote.v4 0.0.0.0/0 remote.v6 2a0e:402:101:101::/64 remote.style RFC6052 remote.ea-len 0 remote.psid-offset 0 debug 0

I removed the part of the IPv4 and IPv6 addresses since they are fairly static.

The 1:1 profile is basically the same except it uses ealen=12, psidlen=0 and other mapping ranges (obviously)

Unfortunately there are no third party CPE compatible with this protocol for now and the CPE from the ISP is lacking in many ways for more advanced users as this is big ISP.

If you need something else feel free to ask.

Edited December 26, 2021 by edoardo396

[admin]

15 hours ago, Simone said:

I am also interested to know if there is any news, Sky Italia is offering I think the best offer in the field of connections

Not yet implemented. Thanks for your interest, we are working in this direction.

[Simone]

I am also interested to know if there is any news, Sky Italia is offering I think the best offer in the field of connections, it's a shame that I'm covered by FTTC/VDSL and unfortunately there are no third party CPE compatible with MAP-T and FTTC (if not using unlocked and modded modems of the former incumbent as it uses a very pure OpenWrt*), so I'm very interested to know if MAP-T support will arrive or not in the short time.

*also with MAP-T 1:X with X != 1 and a third party CPE with OpenWrt, has the big problem that only the first range of ports is used, so most of the port of the IP address is wasted.

[Simone]

2 hours ago, admin said:

Not yet implemented. Thanks for your interest, we are working in this direction.

I am happy and hope it comes soon.

[vst]

Implemented in 3.8.A.8

[Simone]

FTTH 1000/300 Mbps Sky MAP-T with Keenetic HERO AX

Honestly, I am incredulous of the performance (in IPv4 with offloading), I am used to seeing poor results on most of the hardware I have seen/tested.

I want to congratulate all the Keenetic staff who did a great job. 

In particular a raspberry pi only works with a customised image made by a forum.fibra.click user that modifies the load balancing management between the cpu's for a moment and requires a specific NIC tp link.

Despite this, very good performance is only achieved in IPv6, a speedtest server in IPv4 witout offloading gives results in line with or worse than other devices with OpenWrt, but with offloading the performance are good!. In any case, the values eventually settle at very similar devices such as the belkin ax3200 with a very similar hw.

 

3.8.5 (no offloading)

Spoiler

Server IPv6: 50955, 50954, 11427

Server IPv4: 7839, 4302, 27276

Dual stack server with IPv6 disabled

3.9 Beta 1 (offloading)

Spoiler

Only IPv4 server

 

Then we come to the MTU side, which has never been written about on this forum but I imagine the engineers who have worked on it know: MAP-T requires an extra 20 bytes of MTU per packet in IPv4, there are two solutions:

1. increase the IPv6 MTU to 1520
2. decrease the IPv4 MTU to 1480

If not handled correctly this causes problems on sites such as atm.it, ebay.

All of these sites do, so again I congratulate the person who made this implementation. What's more, it works the site that never worked in the openwrt implementation of MAP-T www1.sky.com/opensourcesoftware/

As you can see from speedguide.net/analyzer.php it is reduced to 1480 because MTUs above 1500 are not supported, the other option would also be convenient.

Quote

« SpeedGuide.net TCP Analyzer Results » 
Tested on: 2022.10.16 07:36 
IP address: 101.58.xxx.xxx 
Client OS/browser: Windows 10 (Chrome 106.0.0.0) 
 
TCP options string: 020405a00103030801010402 
MSS: 1440 
MTU: 1480 
TCP Window: 263424 (not multiple of MSS) 
RWIN Scaling: 8 bits (2^8=256) 
Unscaled RWIN : 1029 
Recommended RWINs: 63360, 126720, 253440, 506880, 1013760 
BDP limit (200ms): 1054 Mbps (105 Megabytes/s) 
BDP limit (500ms): 421 Mbps (42 Megabytes/s) 
MTU Discovery: OFF 
TTL: 53 
Timestamps: OFF 
SACKs: ON 
IP ToS: 00000000 (0) 

what is missing from this implementation?

• implementation of the possibility of requesting an IPv6 prefix (sky leaves the possibility of requesting a prefix that you have already obtained via ia_pd), this was implemented by a user of the forum.fibre.click on openwrt, the patch can be found here https://github.com/edofullin/odhcp6c
• Jumbo Frame to allow you to have a MTU > 1500 and thus not have to have a 1480 MTU in IPv4. (the OP tells me it is possible via CLI, as soon as I have some time I will test it)
• Better IPv4 performance, performance in IPv6 is very good (I hope that improving the hw/sw offloading will bring about the canonical 930 Mbps in IPv4).

Edited October 16, 2022 by Simone
add more ipv4 speedtest + test for 3.9 beta 1 + mtu

[Le ecureuil]

Цитата

• Jumbo Frame to allow you to have a MTU > 1500 and thus not have to have a 1480 MTU in IPv4. (the OP tells me it is possible via CLI, as soon as I have some time I will test it)

The most convenient solution is to enable TCP MSS tuning, and to set the default value of MAP-T interface to 'MTU of parent - 20' bytes. We will think of this. Of course you can override this settings in cli, but as default for the vast majority it is enough.

Цитата

• Better IPv4 performance, performance in IPv6 is very good (I hope that improving the hw/sw offloading will bring about the canonical 930 Mbps in IPv4).

Do you want to have 900 dl / 900 ul in IPv4 as MAP-T? As I understand from your results download speed is good enough, but upload stuck on 250 mbps. Please send us (to official support) self-test file taken in exact moment when you run speedtest for upload (it's better to increase test time to 1 minute for example to easy your task if possible).

[Simone]

19 minutes ago, Le ecureuil said:

Do you want to have 900 dl / 900 ul in IPv4 as MAP-T? As I understand from your results download speed is good enough, but upload stuck on 250 mbps. Please send us (to official support) self-test file taken in exact moment when you run speedtest for upload (it's better to increase test time to 1 minute for example to easy your task if possible).

No, the ideal would be to have a higher download speed, i.e. up to 930 Mbps, of course the values are good (and I don't ask more for a MISP, in fact I want to try it as soon as the Keenetic Hopper or the Keenetic Sprinter come out)., but there is always a delta of 150-200 Mbps compared to the speed the line offers.

The line is limited to 300 Mbps upload.

I can certainly send the data to support. 

24 minutes ago, Le ecureuil said:

The most convenient solution is to enable TCP MSS tuning, and to set the default value of MAP-T interface to 'MTU of parent - 20' bytes. We will think of this. Of course you can override this settings in cli, but as default for the vast majority it is enough.

I don't agree that this is OK for most people that use MAP-T, having an easy way to set the MTU to 1500 and not 1480 allows you to have a higher MTU in VPNs and have the highest value without jumbo frames possible.
I also believe that many providers using MAP-T/E will increase the standard MTU to have the mini jumbo frames and put a v4 MTU at 1500.

In any case, should I increase the value on MapT0?

[Le ecureuil]

51 минуту назад, Simone сказал:

I also believe that many providers using MAP-T/E will increase the standard MTU to have the mini jumbo frames and put a v4 MTU at 1500.

In any case, should I increase the value on MapT0?

It needs to be investigated. Unfortunately there is no possibility to check whether jumbo or baby jumbo are available, so we must choose a "safe for all" defaults: so they will be 1480 on mapt and 1500 on ipv6. But of course you and anyone who sure in availability of baby jumbo can enable it anytime.

[Simone]

I also recently got the Titan 2nd generation AX, and I see that the speedtest in IPv4 reaches 930 Mbps in IPv4 (https://www.speedtest.net/result/c/948d22c8-1d32-4bf1-aa9f-c0bcc8e507bc - https://www.speedtest.net/result/c/69d52820-cf76-45c5-a7b5-54e0f2ee444e) compliments for the implementation.

 

On 10/17/2022 at 10:57 AM, Le ecureuil said:

It needs to be investigated. Unfortunately there is no possibility to check whether jumbo or baby jumbo are available, so we must choose a "safe for all" defaults: so they will be 1480 on mapt and 1500 on ipv6. But of course you and anyone who sure in availability of baby jumbo can enable it anytime.

If I understood @fl4co correctly, the commands to increase the MTU should be:

interface GigabitEthernet0 ip mtu 1520
interface GigabitEthernet0/Vlan101 ip mtu 1520
interface GigabitEthernet0/Vlan101/MapT0 ip mtu 1520

but they do not work and the maximum MTU that can be set is 1514

 

 

Edited July 27, 2023 by Simone