Neighbor Discovery Protocol (NDP) Proxy - Revisited
-
Hello all
Regarding NDP, I see there has been a previous discussion but I think this needs to be revised. The fact is that many of us are in a situation where we must have an ISP router with our pfSense router behind it. In those situations the ISP is typically going to delegate the IPv6 prefix to their router and their ISP-provided router will not delegate another prefix to our pfSense router. This kind of scenario was what NDP was invented for in the first place.
However, in the previous discussion there seemed to be some hostility to the idea of implementing NDP because it's "not pure". I'm somewhat of a purist myself, certainly more than most, but at the end of the day one has to decide if it's better to be perfect or increase adoption of the protocol. It simply will not be that we are delegated an IPv6 prefix in the above scenario. And it's not a question of changing ISPs as there are probably not a single ISP in my country that would delegate a second prefix to my pfSense router. So that means either taking out the ISP-provided router completely (not possible in my case because it terminates proprietary services that I use) or bridging my own pfSense router (also not desirable).
I realise there is concern about doing NAT in IPv6 but I think it's important to point out that one of the motivating factors for NDP was to avoid the need of NAT. Many of us see how awful NAT is and would like to be rid of it but some kind of compromise has to be made here. At this point I can only interpret hostility toward an officially supported compromise that avoids the need for NAT and also avoids completely unrealistic expectations on ISPs as hostility towards IPv6 adoption. If we really want IPv6 to succeed we must make it work and not look for some reason we can claim to have "done all we could". There is a technical solution to the problem I, and many others, face. If pfSense is not willing to accept it (and I'm not expecting implementation tomorrow here, just acknowledgement that this is a valid solution) then I can neither use it nor recommend it to anyone in my personal network because I will not use or recommend technologies hostile to IPv6 adoption if I have a choice.
-
@jasonArloUser
What discussion are you referring to?
What prefix size is being delegated to the first router? It should be big enough to delegate it down to a pfSense device either via DHCPv6 prefix delegation or via static route.
If that's not possible you suggest that NDP is another possibility. I do not understand, how.@jasonArloUser said in Neighbor Discovery Protocol (NDP) Proxy - Revisited:
This kind of scenario was what NDP was invented for in the first place.
No. Where do you get that from? NDP is for Neighbor Discovery within the same Broadcast Domain.
@jasonArloUser said in Neighbor Discovery Protocol (NDP) Proxy - Revisited:
but at the end of the day one has to decide if it's better to be perfect or increase adoption of the protocol
I vote for perfect
@jasonArloUser said in Neighbor Discovery Protocol (NDP) Proxy - Revisited:
And it's not a question of changing ISPs as there are probably not a single ISP in my country that would delegate a second prefix to my pfSense router
You do not need a "second" prefix. All you need is one prefix that just needs to be big enough in order to be able to delegate to a downstream device. A good idea would be /48 for companies and something like /56 for private customers IMO.
Here in Germany we have Routerfreiheit which means the user has freedom to choose its own firewall which is great but providers try to undermine that constantly. My pfSense has the full static /48 I get from my ISP on my VDSL line. But even if I used the provider's box I would be able to delegate a portion of that /48 to my pfSense.@jasonArloUser said in Neighbor Discovery Protocol (NDP) Proxy - Revisited:
one of the motivating factors for NDP was to avoid the need of NAT
Your understanding of NDP is weird. Where do you get that from?
@jasonArloUser said in Neighbor Discovery Protocol (NDP) Proxy - Revisited:
If pfSense is not willing to accept it (and I'm not expecting implementation tomorrow here, just acknowledgement that this is a valid solution) then I can neither use it nor recommend it to anyone in my personal network because I will not use or recommend technologies hostile to IPv6 adoption if I have a choice.
Why do you think pfSense is hostile to IPv6 adoption? Can you please refer these other discussions to shed some light into what you mean? I have the feeling that you want some NDP proxy in pfSense but I'm not able to see why there would be the need for that in the first place.
-
@pmisch said in Neighbor Discovery Protocol (NDP) Proxy - Revisited:
@jasonArloUser
What discussion are you referring to?I linked to it in my initial post.
What prefix size is being delegated to the first router? It should be big enough to delegate it down to a pfSense device either via DHCPv6 prefix delegation or via static route.
A /64. So there is nothing left to delegate and I wouldn’t know how to delegate further in any case because the first router is ISP provided and does not offer DHCPv6 or anything.
If that's not possible you suggest that NDP is another possibility. I do not understand, how.
When I did this post I believe I took the title of the previous discussion or I simply made a typo here but to clear up any ambiguity I did link to the “NDP” I was referring to: neighbor discovery Proxies, which was invented specifically for cases like mine.
@jasonArloUser said in Neighbor Discovery Protocol (NDP) Proxy - Revisited:
This kind of scenario was what NDP was invented for in the first place.
No. Where do you get that from? NDP is for Neighbor Discovery within the same Broadcast Domain.
Sorry for the confusion, I’m talking about neighbor discovery Proxies not neighbor discovery protocol which is indeed for a given broadcast domain.
I vote for perfect
I assume that your joking here and not saying that you’d rather have a perfect protocol used by no one.
You do not need a "second" prefix. All you need is one prefix that just needs to be big enough in order to be able to delegate to a downstream device. A good idea would be /48 for companies and something like /56 for private customers IMO.
I have a /64 that is delegated to the router provided by my ISP so it’s not wide enough for any further delegation.
Why do you think pfSense is hostile to IPv6 adoption?
As I mentioned, I’m a purist myself in general but in some cases you have to accept compromises (especially when they come literally from the standards bodies) in pursuit of adoption. If you’d rather have perfection regardless of what this means to adoption then that is effectively hostility to adoption.
I have the feeling that you want some NDP proxy in pfSense but I'm not able to see why there would be the need for that in the first place.
In the neighbor discovery proxy RFC they describe exactly the case I and the original poster are facing as the motivation for this standard.
-
@jasonArloUser said in Neighbor Discovery Protocol (NDP) Proxy - Revisited:
What prefix size is being delegated to the first router? It should be big enough to delegate it down to a pfSense device either via DHCPv6 prefix delegation or via static route.
A /64. So there is nothing left to delegate and I wouldn’t know how to delegate further in any case because the first router is ISP provided and does not offer DHCPv6 or anything.
With IPv6, the LAN is supposed to be a /64. If you go with a longer prefix things, such as SLAAC, break. The solution is to get a better prefix. Also, are you being limited by your modem? For example, if I use my modem in gateway mode, I get a single /64. If I put it in bridge mode, I can get a /56, which I can then split with pfSense into multiple /64s.
-
@JKnott Yes, I had read that /64 was the smallest prefix I could use. I am being limited by the ISP, they only give out /64s.
-
I agree with @JKnott
Just because pfSense won't support NDP Proxy doesn't mean they're hostile to IPv6 at all nor does it mean that anybody can't use IPv6. Decent providers will give you /56, don't blame netgate for what your provider blows.
In my opinion your provider is hostile to IPv6 since they are only distributing a /64 which is against what RIPE suggest, I don't know about ARIN or other RIR but I expect them not to differ significantly.
You seem quite desperate about what you do, trying to get a NDP Proxy for pfSense.
If I was in your position I would just switch the solution. For OpenWRT there's a package called ndppd which seems to do what you want.What I indeed find hostile of pfSense to IPv6 is that this ticket isn't being adressed. This is by far a more common scenario / problem people are facing and there's not solution available, yet.
-
@pmisch said in Neighbor Discovery Protocol (NDP) Proxy - Revisited:
I agree with @JKnott
Just because pfSense won't support NDP Proxy doesn't mean they're hostile to IPv6 at all nor does it mean that anybody can't use IPv6. Decent providers will give you /56, don't blame netgate for what your provider blows.I get what you’re saying but so many providers do this that at some point if adoption is a priority then one will do what it takes to ensure adoption. In the case of providers like mine (and no I won’t drop them over this and doing so wouldn’t help me because all providers I could switch to do the same or don’t even support IPv6 at all) they will not change soon but there is a standard created by the standard body made to deal with this. At that point it’s hard to think of a good faith argument for not implementing it except “we lack the resources” or “IPv6 adoption is not a priority for us”.
In my opinion your provider is hostile to IPv6 since they are only distributing a /64 which is against what RIPE suggest, I don't know about ARIN or other RIR but I expect them not to differ significantly.
Fair enough but many providers seem to be and at least this one offers something at all. If we wait for everyone to behave perfectly then we may as well cancel the migration and hope we can keep coming up with IPv4 hacks to keep it going.
You seem quite desperate about what you do, trying to get a NDP Proxy for pfSense.
Not desperate just frustrated at how standard solutions are shut down. If you lack the resources fair enough.
If I was in your position I would just switch the solution. For OpenWRT there's a package called ndppd which seems to do what you want.
Well, that is what I am forced to do. Pfsense is a nice product but I’ve decided IPv6 is a priority for me so I’ll have to go with a solution that supports the standards my setup requires.
What I indeed find hostile of pfSense to IPv6 is that this ticket isn't being adressed. This is by far a more common scenario / problem people are facing and there's not solution available, yet.
That’s unfortunate. But it adds to the mental picture I have that IPv6 adoption is no goal for Pfsense.
-
@jasonArloUser
Even if you switch over to a solution that supports NDP proxy I would still consider this to be a workaround.
As you say, IPv6 is there to prevail and to spread but when the providers implement it with such bad practices then you don't gain anything from IPv6 and could stick with IPv4 as long as there aren't decent solutions. -
I completely disagree with this. Even with ND proxy, I still avoid things like NAT. The router has to keep track of addresses that it forwards to a different broadcast domain but it doesn’t have to keep protocol state tables for active connections, it needs no workarounds for protocols that expect the endpoint to be addressable (e.g. FTP). It’s just doing a form of routing which routing is the main thing it does anyway.
It is a workaround but a tiny workaround compared to the abominations we already engage in. Further, ISPs don’t play well with IPv6 because most people don’t care about. If we ever get large IPv6 adoption then it becomes a point to compete over. They have no reason to do the right thing today because most customers don’t know or care about IPv6. If half the internet was IPv6 only they would start to care. But we’ll never get anywhere near that if people continue to be such purists about implementing it. IPv4 got where it is today precisely because they would do anything, no matter how ugly to keep it going.
-
Trudging up an old topic, apologies.
This problem is quite common, actually. The sad state of last mile IPv6 is causing these requests. I myself have personally just run into this exact problem: "Huge last mile provider broke proper prefix-delegation with CPE upgrade" which has been detailed in its pailful reality here.
Essentially, I am receiving a prefix-delegation but the modem is misbehaving in that it is attempting to do neighbor solicitation for addresses that it has delegated via a proper dhcpv6-pd to my equipment. This is broken and incorrect behavior and will never allow IPv6 to work as it did on the modem that was originally replaced, which performed correctly.
This broken layer2 behavior is driving requests for NDP proxy. And while I completely agree that being forced to use NDP proxy is undesirable, I would not be so brash as to make perfect the enemy of the good. End to end connectivity is what IPv6 is all about, and at least with NDP proxy that would be possible until the provider can address their blunder.
As far as the comment "your ISP is stupid/broken/whatever, get a new one". While, sure, that's correct, that is not useful and for many that is simply not an option. I've built more ISPs than I can count and it's non-trivial, expensive, and thankless - I don't blame them for stupidity because I've literally done it myself and keeping the 1% of folks that need IPv6 happy is a tiny detail in an ocean of fires to put out daily. I have not built anything for pfsense in many years, but if it still has a plugin system it should be possible to add NDP proxy pretty easily. -
@buraglio
It's not really hard for a provider to setup decent IPv6 but well, let's not discuss this further. They are fooling us, and we cannot do anything about it.
If you need something like NDP proxy, use OpenWrt. It is also a really really good solution for a home internet connection and it supports such features. It runs on almost anything, it's fast, it's mature. It has plenty of additional packages.
Obviously pfSense is not the right solution in this scenario as they won't be supporting it. -
You're right, I've built IPv6 into existing ISPs and rolled green field deployments as dual stack. It's not hard, except when it is. Regardless, that's a moot point when there is zero control over the ISP network.
I can write my own package for NDP proxy as I did for a number of other packages back in the beginning of the pfSense project. My point is not that it is or isn't possible with pfSense, it's that .001% of users using pfSense have any say whatsoever over what their ISP does, much of which seems to defy logic and best practices, and having the flexibility to work around is a functional requirement for many. -
@pmisch Well that's the thing. More and more the answer is "just use a competing product". What is Pfsense even for anymore if they can't fix years old bugs and they can't do IPv6 under realistic real world scenarios? Pfsense looks like a dying project to me so I've personally been steering people away from it.