Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add MAP-T/MAP-E support #4983

Closed
2 tasks done
hitech95 opened this issue May 11, 2021 · 11 comments
Closed
2 tasks done

Add MAP-T/MAP-E support #4983

hitech95 opened this issue May 11, 2021 · 11 comments
Labels
help wanted Contributor missing / timeout

Comments

@hitech95
Copy link

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

Is your feature request related to a problem? Please describe.

No

Describe the solution you like

Please add MAP-T and other transitional technologies support as soon as possible.

Additional context

The depletion of IPv4 addresses is forcing many ISPs, especially new ones, to migrate to IPv6 networks while supporting IPv4 using transition mechanism built on IPv6 (IPv4aaS - IPv4 as a Service), like MAP-T, MAP-E, 464XLAT and others (see RFC8585). Fibre and FTTH-GPON deployments are accelerating this changes, as new ISPs are entering the market but can't source IPv4 blocks large enough, and IPv6 based transition technologies are more appealing than IPv4-based ones like a dual stack with CG-NAT.

In Europe, Sky Italia (Comcast owned) will switch using from a dual stack implementation used till now to a IPv6 + MAP-T network from August 2021. Melita (another ISP in EUROPE) is already using MAP-T. Looks like that Japan ISPs are heavily depending on MAP-T. Others may follow, especially local ISPs offering specific services for the SMB market.

Italy is a country where users have a right to use their own CPEs regardless of what the ISP provides - but the CPE must be able to comply with common standards used by the ISP network.

Right now there little to nothing CPEs capable to do so. The only open solution so far is Openwrt. Without MAP-T support, OPNsense won't be able to obtain a IPv4 address and access IPv4-only destinations.

@OPNsense-bot
Copy link

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.

@OPNsense-bot OPNsense-bot added the help wanted Contributor missing / timeout label Nov 7, 2021
@luponata
Copy link

Even Iliad (Free) with the new internet offer via FTTH will also use the same protocols

@GianlucaCesari
Copy link

Any news on this issue? I would like to contribute but I don't even know where to start

@fichtner
Copy link
Member

fichtner commented Aug 25, 2022

No news. pf.conf(5) holds a feature here:

     map-e-portset ⟨psid-offset⟩ / ⟨psid-len⟩ / ⟨psid⟩
           With nat rules, the map-e-portset option enables the source port
           translation of MAP-E (RFC 7597) Customer Edge.  In order to make
           the host act as a MAP-E Customer Edge, setting up a tunneling
           interface and pass rules for encapsulated packets are required in
           addition to the map-e-portset nat rule.

           For example:

                 nat on $gif_mape_if from $int_if:network to any \
                       -> $ipv4_mape_src map-e-portset 6/8/0x34

           sets PSID offset 6, PSID length 8, PSID 0x34.

I suppose it would have to be added to 1:1 rules?

The original ticket is a bit light on the requirements part. We can offer what pf(4) offers, but if that is enough here has not been established and how it should be configured from the GUI...

@psychowood
Copy link

Besides MAP-T/MAP-E support, it's not clear to me if "standard" ipip6 (i.e. with manual parameters instead of being provided by DHCPv6) is supported in opnsense...

@ShuntaIto
Copy link

ShuntaIto commented Dec 21, 2022

Looks like that Japan ISPs are heavily depending on MAP-T.

Let me share about the situation in Japan.
I'm Japanese opnsense user and I reach here after much effort and unsuccessful attempts to connect with MAP-E.
Japanese ISPs depend on MAP-E (RFC7597) or DS-lite (RFC6333).
I think MAP-E seems to be more common.

As far as I know, some Japanese users who are building routers on FreeBSD or OpenBSD are using map-e-portset to connect.
However, it's not simple and they face some problems.

https://qiita.com/yshdsnd/items/f8fb7ed136c19092b538
https://hoshizuki.hateblo.jp/entry/2022/08/05/065823
https://mano.xyz/post/2022-08-21-openbsd-map-e-pf/

I found someone patching the kernel to connect with MAP-E. Wow!
https://mano.xyz/post/2021-12-30-openbsd-map-e/

@fuomag9
Copy link

fuomag9 commented Feb 11, 2023

Is there anyway to implement this inside opnsense? https://github.com/toru-mano/openbsd-pf-map-e-ce

@AdSchellevis
Copy link
Member

unlikely, best check man pf.conf if what you need is supported.

@schmitmd
Copy link

I think Japan users (such as myself) are still interested in this. Seems someone got things working as needed for OpenWRT: https://github.com/fakemanhk/openwrt-jp-ipoe Maybe that could act as a guide for OPNsense? I haven't tried yet, but it sounds like the map-e-portset is sufficient, so long as appropriate NAT rules are specified as seen in the aforementioned pf.conf man page snippet.

@AdSchellevis
Copy link
Member

Well, same comment #4983 (comment) still applies, if someone wants to investigate how this can work on bsd, the starting point is implementing what's described in man pf.conf and open a ticket with the additions you need and how you tested them to be functional. Our ruleset is written to /tmp/rules.debug.

@schmitmd
Copy link

I'll get testing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Contributor missing / timeout
Development

No branches or pull requests

10 participants