[WIP,RFC] general improvements for map-t and other protocols

[Nicolò Veronese]

This is my first post on the mailing list, so if I'm wrong please let me know.
I would like to discuss a number of improvements that I would like to
implement on openwrt to better integrate this technology.

So I would like to understand with you what changes could be useful
to the community and what is a patch only for my ISP.
Since December 2021 my ISP offers IPv4 connectivity through MAP-T.
The configuration arrives via DHCP and is now automatic on Openwrt.
The share ratio which can be 1:16 or 1:1. The CPE provided
automatically opts out from
1:16 to 1:1 if you activate:
- DMZ
- Port forwarding
- UPNP

Let's move on to the improvements I've made and would like to integrate:
- The map.sh script of the "map" module now creates a json structure
in the "data" field [1],
  in this structure there is all the information of the interface configuration:
  the type of map, the prefix of the BR, the various FMRs and the
shared v4 address.
  For an example of the generated JSON: https://pastebin.com/raw/7WQ30LVy
- Luci allows a protocol to generate the DOM for its state [2], so a protocol
  could override the general behavior of the "luci-mod-network" module.
  This is used together with the new JSON structure [3] to show the
user the range of associated ports
  and other useful information. For the visual results:
https://i.ibb.co/FB7FHVd/immagine.png
  https://i.ibb.co/PmGVNFg/immagine.png.
  As you may have noticed, the default overview behavior is overridden
[4] and the "EDIT" key is
  changed to "Status" if the interface is "virtual" and does not have
an associated UCI node.
  If the button is pressed, a modal is opened with the call to the new
"renderStatus" function
  of the protocol. Alternatively, if the protocol has an associated
UCI node, a "Status" TAB is populated
  in the classic modal. [5][6]
- We have added to odhcp6c the possibility to prefix to send an
IA_PREFIX [7], this can be useful as
  my ISP foresees this behavior. (The v6 prefix also determines the
port range and v4, so being able to
  request the same prefix is very important to firewall rules).
  To date, this function can be configured in the "Request IPv6-prefix
of length" in Luci with the format:
  "v6-pd\len:IADID".
  I would therefore like to discuss whether it might be worth
splitting this option into several fields.
  For now it has not been done for reasons of backward compatibility.

All this still needs to be tested, especially with MAP-E to see if
there may be some kind of regression.
For this we have a local lab where we do all the tests.

Now we come to the sore keys:
- miniupnp should be configured at runtime when the map interface goes UP.
  Specifically, the range of ports to whitelist, and the shared IPv4.
  Being MAP a "tunnel", it does not have an IPv4 assigned to the
interface and therefore
  miniupnp thinks it is not active (miniupnp uses the IP to understand
if an interface is up or down [8]).
  Passing an IPv4 address is also quite simple to implement, but it
would be a specific implementation
  for this protocol so I don't know how to go about it. I'll have to
add a parser in the init.d script to read
  the interface JSON described in the point above.
  Specifically unlike Luci, netifd does not have a method for
extracting data resolved by a protocol.
  Netifd only takes care of configuring or deactivating an interface.
  It would therefore be necessary to define a standard JSON structure
for the protocols so a single parser
  can be implemented for other protocols as well. This might be useful
for DDNS and other packages
  that require access to the WAN IP. My idea was to implement ubus
into miniupnp to get the device status
  and interface IP using the conventional JSON structure described above.
- Due to the overhead the MAP-T process sometimes makes connections to
hangs/stalls. My ISP
  supports mini jumbo frames, so in my case I can set WAN6 that way.
It would therefore be necessary to
  make a firewall rule to do MSS clamping if the MTU of the uplink
interface is set to 1500. So far I have
  not seen any way in fw3 to do this. The auto generated rule seems hard-coded.
  The ISP CPE has that rule set [9], and it seems that other users
that have MAP have the MTU manually set [10].

- When Share ratio is 1:1 the port set is not necessary and the CPE
has a full port range available.
  Non TCP/UDP protocols fail to work in 1:1 ratio; to make them work
we assign the calculated IP address [11]
  to the MAP interface. I'm not sure if this is the correct way to go
but it is working. (tested with GRE)

I also wish the whole team a happy new year!

Thanks in advance for any feedback,
Nicolò

References:
[1]: https://github.com/hitech95/openwrt/commit/6ed00a53325008f586f36c6e136bf06b950ba419
[2]: https://github.com/hitech95/openwrt_luci/commit/a401a42d0d8023909abfe6c2c3a3db141f12178e
[3]: https://github.com/hitech95/openwrt_luci/commit/6dd7beb3d244eb5370a9732dd5e4f675352a2be9
[4]: https://github.com/hitech95/openwrt_luci/commit/042a2ae0eb463649f9f170fa5a8f2eeb67acfdd7
[5]: https://github.com/hitech95/openwrt_luci/commit/080cacd6fb7c308f37c7f3a69473fb11f238786a
[6]: https://github.com/hitech95/openwrt_luci/commit/087b954c3b70aa6b7c80125719edfb87192a00ff
[7]: https://github.com/hitech95/openwrt_odhcp6c/commit/f2a9a2fd56935cce4bccf98d44f8697aadb22792
[8]: https://github.com/miniupnp/miniupnp/blob/master/miniupnpd/getconnstatus.c#L38
[9]: https://code.rdkcentral.com/r/c/rdkb/components/opensource/ccsp/Utopia/+/58220/1/source/firewall/firewall.c#1086
[10]: https://forum.openwrt.org/t/map-portsets-not-fully-utilized-and-only-16-ports-available-due-to-discrepancies-between-connlimit-and-nat/105020
[11]: https://github.com/hitech95/openwrt/commit/8651e72592095058f513ab2a54e7c18418e143fd