NDP proxy where are you
-
Just came across this issue with OVH using their Dedicated Private Cloud product. They terminate a /56 on the WAN vlan and provide no routing capability for /64 addresses. I'm trying to find out if there is some way to use PD or RA to get them to route /64's properly but no responses from their team yet.
-
Just a follow up, OVH provide no way to route /64 at all, you are forced to use ndp proxy if you want to use some of the /56 address space internally.
-
Then take your money elsewhere. That is an AWFUL network design and it's impossible to expect anyone to have a /56 in one massive flat network. Don't let them get away with that lazy crap. They have to route it to you, full stop. NDP Proxy isn't happening.
-
Im with jimp that sort of setup is just moronic… There is zero reason to be so freaking stupid in their design. Route networks they assign to you be it a /48, /56 or /60 even - or for that matter even a single /64 should be routed to you if your going to be doing anything other than hosting a few hosts on their network directly.
-
I've worked around this by putting a linux box on the wan segment that runs ndppd with ipv6 forwarding enabled. Now I can configure any of the /64s within the /56 in ndppd and it works as if it was properly routed to pfsense and can be used on my internal network segments.
-
News flash:
Just this week, ndproxy by Aexandre Freyo (a package that has already been mentioned earlier in this thread) has been added to the official FreeBSD ports tree!
See: https://github.com/AlexandreFenyo/ndproxyThat may open up new possibilities. I will ask if feature request #7746 can be reopened: https://redmine.pfsense.org/issues/7746
BTW: I love pfSense, to me it's like a Swiss Army knife for networking. I can solve any IPv4 problem with it. pfSense should be able to solve real world IPv6 problems like this one as well.
-
It is not a real world IPv6 problem. It is a completely broken ISP configuration. They need to fix it.
18-billion-billion * 256 addresses on one flat interface. Asinine. Don't host there.
-
Keep it away from pfSense, stuff the matter in the face of your ISP instead.
-
Not trying to be contrarian, but ISPs are not exactly known for giving a sh*t about their customers. I googled "america's most hated companies". Comcast was number 1 and Charter was number 12. ISPs aren't any more well liked in Canada, for good reason. It's probably no different in a lot of other countries. Some people are located in areas where there are few or no alternatives.
As an engineer, it has always grated on me to pollute a design or an implementation in order to accommodate something because someone else didn't do their job properly or at all. Unfortunately, sometimes you have to accept such things. With respect to pfsense, the "Do not wait for a RA" setting could be considered such a thing. I'm not in a position to do any development, but thankfully marjohn56 had the same issue and he implemented a fix that works very well. pfsense has a few more users because of this.
-
It is not a real world IPv6 problem. It is a completely broken ISP configuration. They need to fix it.
18-billion-billion * 256 addresses on one flat interface. Asinine. Don't host there.
Easier set than done ;(
-
I came across this thread and tickets for ndproxy, because like others my ISP gave me a flat /112.. In my case it was just given to me with my ipv4 address's. I wanted to play around with ipv6 but got stuck because there is no ndproxy support so i'm just going to disable it, as it's basically useless with pfsense as a firewall.
I agree the ISP should fix the way it's routed, but it doesn't seem ISPs are doing that, and it will likely be sometime before a majority of ISPs get ipv6 figured out correctly. I don't see what harm would come in adding ndproxy as a package.
-
Then lobby to your ISP to get it fixed.
It we add workarounds for broken designs, then ISPs will have no incentive to fix their broken designs.