Jump to content
  • 1

MAP-T


fl4co
 Share

Question

 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 by fl4co
Link to comment
Share on other sites

12 answers to this question

Recommended Posts

  • 1
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 by fl4co
  • Thanks 1
Link to comment
Share on other sites

  • 1

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.

Link to comment
Share on other sites

  • 1

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 by edoardo396
  • Thanks 1
Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

FTTH 1000/300 Mbps Sky MAP-T with Keenetic HERO AXimage.thumb.png.2cc7b57b231d2775f596e522ee014c50.png

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

image.thumb.png.379b42bbf967ea512df771d550feacf2.png

image.thumb.png.675e49c2df9775fe4b723d6d396e234a.png

Server IPv6: 50955, 50954, 11427

Server IPv4: 7839, 4302, 27276

image.thumb.png.cea6d1a58b83c0507ba6aef715b2ee35.png

Dual stack server with IPv6 disabled

3.9 Beta 1 (offloading)

Spoiler

image.thumb.png.d2be66ca600f12004adfe39af69821ac.png

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 by Simone
add more ipv4 speedtest + test for 3.9 beta 1 + mtu
  • Thanks 1
  • Upvote 4
Link to comment
Share on other sites

  • 0
Цитата
  • 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).

  • Thanks 1
Link to comment
Share on other sites

  • 0
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?

Link to comment
Share on other sites

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

  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...