New commit and merge in FreeBSD source code of MAP-E
-
The backend code has been in pfSense for years: https://github.com/pfsense/FreeBSD-src/commit/2aa21096c7349390f22aa5d06b373a575baed1b4
What are you hoping to do with it?
Steve
-
@stephenw10 I would like to enable MAP-E on pfSense because my ISP requires it
-
There's an open feature request for it: https://redmine.pfsense.org/issues/11901
Looks like it was opened just as the support for it went into pf. I would comment there.
-
I understand, pfSense never enabled MAP-E as this was never implemented on freeBSD, now that they have added it to the source code, in the next few months it should be available on freeBSD and later on pfSense
-
although already included for years in the source code of pfSense, it is not usable
-
Hmm, what was added recently then?
-
Ed Maste in date 2023-08-21 wrote: "Committed and MFC'd, thank you for the contribution." see the link
Is there something wrong with my logic? -
@L0r3 said in New commit and merge in FreeBSD source code of MAP-E:
Ed Maste in date 2023-08-21 wrote: "Committed and MFC'd, thank you for the contribution." see the link
Is there something wrong with my logic?That code was actually imported into the FreeBSD-src tree for pfSense back on April 13, 2021. Here is the actual commit link on Github: https://github.com/pfsense/FreeBSD-src/commit/2aa21096c7349390f22aa5d06b373a575baed1b4. This commit is present in the RELENG_2_7_2 branch of the pfSense FreeBSD-src tree. This is the OS for pfSense CE 2.7.2. Granted, I don't believe there is anything within GUI that mentions this feature, but it is in the FreeBSD source of pfSense.
Not sure which FreeBSD branch Ed was talking about, but it clearly was not the one pfSense has been using.
-
I am confused, if the code was imported within pfsense, does it mean that MAP-E actually could be supported by pfsense by implementing GUI?
-
@L0r3 said in New commit and merge in FreeBSD source code of MAP-E:
I am confused, if the code was imported within pfsense, does it mean that MAP-E actually could be supported by pfsense by implementing GUI?
Don't know about this question. I will say that technology is definitely not needed in the U.S. as IPv6 adoption is quite spotty here. It very much depends on the ISP, but there are many ISPs in the U.S. that do not support IPv6 at all (mine being one -- in fact, none of the four ISPs available in my town support IPv6 for their subscribers). What does seem to be gaining ground here is the use of CGNAT for IPv4.
So, with no large demand from their customer/client base (especially in the U.S.), I would not expect MAP-E to be a high priority item for the Netgate team.
-
Of course, I understand the point, the fact is that public IPs are over, so there are more and more ISPs adopting CGNAT. So thank you for your answers. Too bad the code is there and the GUI is not.
-
Yeah I think that more recent commit was just updating some keywords back from Current. Not a functional update.
As I said the code has been present in pf for almost 3 years and is in pfSense. There is just no GUI code to configure it. Largely because the demand for it is still very low and getting MAP-E/T right is complex.
I also left myself a confusing comment: https://forum.netgate.com/post/1118601
I'm not really sure what I meant by that!As far as can see though you could theoretically create a load a ruleset file that included mape NAT settings. As a test at least.
-
Yeah I understand, at this point anything is welcome
-
I'd suggest that if you can prove it works in a real world scenario it's far more likely to be added to the GUI. Right now we'd only be testing a theoretical setup.
-
@bmeeks said in New commit and merge in FreeBSD source code of MAP-E:
I will say that technology is definitely not needed in the U.S.
Is pfSense a US-only product? Just let us know, people outside US should switch then to a different product. That's different than saying that the adoption of the MAP protocols worldwide is still low.
It's also a bit ironic that one of the main adopters of MAP-T in Europe is US company Comcast (under the Sky brand) because in Europe there are no more IPv4 blocks available, and Comcast couldn't buy enough addresses at an acceptable price. MAP-E is used instead by French company Free/Iliad for the same reason.
@bmeeks said in New commit and merge in FreeBSD source code of MAP-E:
What does seem to be gaining ground here is the use of CGNAT for IPv4.
Which is an older and worse solution, albeit simpler, to the IPv4 exhaution problem, since it doesn't need CPE support. With MAP you get a global IPv6 prefix, and devices can use IPv6 to communicate over the IPv6 internet without issues, while only the IPv4 traffic needs to be tunneled/encapsulated in the MAP protocol. MAP port assignment is deterministic, and it's easier to assing a user the whole port range when needed. Once again, US ISPs look to lag behind. thanks to the lacking of real competition.
-
@LDS said in New commit and merge in FreeBSD source code of MAP-E:
@bmeeks said in New commit and merge in FreeBSD source code of MAP-E:
I will say that technology is definitely not needed in the U.S.
Is pfSense a US-only product? Just let us know, people outside US should switch then to a different product. That's different than saying that the adoption of the MAP protocols worldwide is still low.
It's also a bit ironic that one of the main adopters of MAP-T in Europe is US company Comcast (under the Sky brand) because in Europe there are no more IPv4 blocks available, and Comcast couldn't buy enough addresses at an acceptable price. MAP-E is used instead by French company Free/Iliad for the same reason.
@bmeeks said in New commit and merge in FreeBSD source code of MAP-E:
What does seem to be gaining ground here is the use of CGNAT for IPv4.
Which is an older and worse solution, albeit simpler, to the IPv4 exhaution problem, since it doesn't need CPE support. With MAP you get a global IPv6 prefix, and devices can use IPv6 to communicate over the IPv6 internet without issues, while only the IPv4 traffic needs to be tunneled/encapsulated in the MAP protocol. MAP port assignment is deterministic, and it's easier to assing a user the whole port range when needed. Once again, US ISPs look to lag behind. thanks to the lacking of real competition.
My gosh -- pull back the claws and teeth
. I'm only a pfSense user expressing a view. I certainly do not pretend speak for Netgate.Netgate (pfSense) is a U.S. company, and while I do not know, I would suspect the majority of their customer base to be in the U.S. But I don't know how much of a majority. I was simply saying that until a large enough number of your customers clamour for a particular feature, it is likley to remain on the back burner as this has.
With respect to IPv6 itself, I would love for it to be widespread around the world and actually supplant IPv4. But sadly, that appears at least for now to be quite a distance into the future. The move of cell phones to IPv6 with various IPv4 translations has taken the immediate pressure off the IPv4 address space. I think most smaller ISPs are happy to simply use CGNAT, and the vast majority of their customers neither care nor even know what that technology is. It's only the true computer geeks that disdain CGNAT.
I've tried to encourage my local ISP to provide IPv6 service. They have an assigned block of addresses. I don't know why they have not offered IPv6, but it could be just unfamiliarity with the technology and being more comfortable with IPv4 and CGNAT.
-
For what it's worth, I'd certainly be interested in native MAP (MAP-E) for me as I am in France with Free as my ISP and they use MAP-E to encapsulate JPv4 traffic over IPv6.
I'd really like to replace the mediocre box provided by my ISP with a proper pfsense solution, but as of now, I don't know if I can do that (apart from putting the ISP box in bridge mode).Edited to add I've made a new feature request in pfSense's tracker: https://redmine.pfsense.org/issues/15371
-
@tfboy said in New commit and merge in FreeBSD source code of MAP-E:
I've made a new feature request in pfSense's tracker: https://redmine.pfsense.org/issues/15371
Adding new information to the existing feature request maybe more appropriate give the assumption there was no Freebase support is now wrong https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254577
@stephenw10 said in New commit and merge in FreeBSD source code of MAP-E:
There's an open feature request for it: https://redmine.pfsense.org/issues/11901
But perhaps that does not work now that feature request is closed
-
@Patch yes, seeing the link for the earlier FR, I went to comment on that but couldn't as it was closed, hence the new FR with a link to the previous one. Not sure if that's the "right" way of doing it, but just wanted to bring it to their attention.
I'm hoping that if the new FreeBSD has it built-in, it requires minimal development on the pfSense side to include it as a feature - just a few Web UI tweaks?
