Dynamic IPv6 Prefix assignment issue in xDSL users
-
I tested senario and I got Problem with end user,Read below …
Every time pppoe connection take down ip wan and lan (delegated prefix ) cpe has changed and cpe announced new prefix to end-user and end-user get new ip address the problem is that end-user now has 2 ip address from different delegated prefix and until the old ip address is valid due to release time we have packet lost because we have route for old delegated prefix on BRAS has deleted and bras doesnot have return route, so what can I do to solve this problem ? -
In the WAN configuration, ensure "Do not allow PD/Address release" is selected. That should keep your prefix from changing.
-
@jknott you mean that i change the configuration of CPE (Modem) and what is the usage ? cpe must send a message to client(windows) to set the valid time for old delegated prefix to zero and use new delegated prefix instead of old delegated prefix .
your answer i think cannot change any things, please describe me more about your answer if you are sure that is true and work fine. -
It's a setting in pfSense, on the WAN interface, that tells it to not release the prefix. IPv6 uses something called DUID to retain the same prefix. If that setting is not selected, the prefix will not be retained.
-
In the WAN configuration, ensure "Do not allow PD/Address release" is selected. That should keep your prefix from changing.
That is true and works, but it don't works if the prefix changed nevertheless (hope my english is ok) at power loss or so.
In my opinion pfsense is not accepting changing ipv6 adresses as they exist in germany and maybe somwhere else. so there is no solution to changing firewallrules or their sideeffects. So you can not build rules with the prefix as variable plus identifyer.pfadmin
-
Get a new ISP. They are probably not properly honoring the DUID. pfSense can only work with what it is given.
Right. It is a complete pain when your PD is changed by your ISP. That is why they are not supposed to do that.
-
That is what I mean. You ignore the reality in germany. A few changes and it is out of world. A changing IPv6 is nothing forbidden, but you want that I change my provider. AVM can work whith it. Why you won't?
-
If you need a firewall that will automatically track a changing prefix delegation and adjust firewall rules, etc, pfSense is not for you. A lot of effort has been put into working with ISPs that do the right thing - and it works well. Ultimately the ISP controls the user experience here. Yours apparently doesn't care and wants to treat IPv6 like IPv4+NAT.
You can probably ease the pain somewhat using firewall aliases but it will still require manual intervention.
You can see if someone has opened a similar feature request on redmine.pfsense.org and, if not, do so. I am not going to do it since I do not know all of the specifics of your situation.
-
@derelict said in Dynamic IPv6 Prefix assignment issue in xDSL users:
Get a new ISP. They are probably not properly honoring the DUID. pfSense can only work with what it is given.
Many German ISPs actually enforce a regular IP change for IPv4 and prefix change for IPv6. That is intended by the ISPs because a fixed IP is a premium option for their business offerings. You cannot change this with any option on pfSense, but for IPv6 you can switch to using a tunnel broker like He.net.
-
@grimson said in Dynamic IPv6 Prefix assignment issue in xDSL users:
Many German ISPs actually enforce a regular IP change for IPv4 and prefix change for IPv6.
Criminal.
-
@grimson said in Dynamic IPv6 Prefix assignment issue in xDSL users:
@derelict said in Dynamic IPv6 Prefix assignment issue in xDSL users:
Get a new ISP. They are probably not properly honoring the DUID. pfSense can only work with what it is given.
Many German ISPs actually enforce a regular IP change for IPv4 and prefix change for IPv6. That is intended by the ISPs because a fixed IP is a premium option for their business offerings. You cannot change this with any option on pfSense, but for IPv6 you can switch to using a tunnel broker like He.net.
That's nuts! I can understand static addresses being considered premium on IPv4, where there is a severe shortage of addresses, but that doesn't hold with IPv6, with it's incredibly huge address space. That's just blatant greed.
There is a possible work around for this, assuming you're only using host name lookup for the local LAN and not from outside. It's possible to assign Unique Local Addresses, in addition to the global addresses. Just configure your DNS so that it points to the ULA rather than global addresses.
-
There is no equivalent in the IPv4 world. If you are provisioned such that you have routed IPv4 space and use that space on inside subnets, the ISP simply cannot change them on you. Everything would break.
It is ludicrous to think IPv6 would be different.
The only reason they have gotten away with dynamic IPv4 addressing for so long is we all use NAT and set our own static inside addresses.
The answer is not to work around their nonsense but to stop paying them until they do it right. Penalize the stupid ones and reward those who do it correctly.
-
I can stop paying with stopping be a part of the internet. Thats it what you want from me if you say this. Maybe you are right, but it helps nothing here. There is a feature request from someone else, I will look for it and paste it here.
-
As has been stated, if your ISP has broken IPv6 (and it sounds like that is the case), I would bug them about it. The S in ISP is for Service.
In the meantime, as has been mentioned, you can get a static /48 - free - from www.tunnelbroker.net.
-
I'm sorry but "change of ISP" or "stop paying" is not an answer...
I live in Belgium and I've the exact same problem, ALL the ISP give dynamic prefix and they don't give a shit about my complains.
There is a feature request for this problem on the tracker
https://redmine.pfsense.org/issues/4881
With this feature, we could use ULA on the LAN and nat the prefix... But it's dead since 2-3 years :(
Pfsense has already static NPT, just make it dynamic please
English is not my first language, sorry
-
https://www.tunnelbroker.net/
-
"Yeah, just use a tunnel broker and add 10-15ms of latency for each ipv6 connexion, it's fine"
No, it's not. I realy don't understand your attitude... Pfsense is already capable of doing static NPT, you know it's a thing and there is a feature request for dynamic NPT... You can implement it and solve this stupid issue...
-
@chaispaquichui said in Dynamic IPv6 Prefix assignment issue in xDSL users:
"Yeah, just use a tunnel broker and add 10-15ms of latency for each ipv6 connexion, it's fine"
So what? Those few ms won't kill you.
NAT is ugly and has to die as fast as possible, reviving it for IPv6 would be more than stupid.
-
There is a HE pop in Amsterdam, NL - I doubt that is going to A 10-15ms to your path.. Maybe 2 or 3 tops.. Its only what 200 miles from one side of belgium to the other side of NL.. So yeah lets at worse call it 3 ms..
Also one in Frankfort - about the same distance.. Paris as well isn't far from any point in Belgium... So you have like 3 that I know of that are what 3ms from anywhere you could be Belgium.. I could see your point if closest pop was 3000 miles away from you... But EU is pretty freaking tiny when it comes to total latency anywhere.. Adding 3ms is not going to be any sort of issue.
Added bonus is the /48 you get.. You can use that on ANY isp you move too.. I have had the same /48 since 2013.. My current isp doesn't even have any ipv6.. Same addressing...
That is going to be way better than doing some nonsense nat on ipv6 because your isp is stupid.
-
@chaispaquichui said in Dynamic IPv6 Prefix assignment issue in xDSL users:
"Yeah, just use a tunnel broker and add 10-15ms of latency for each ipv6 connexion, it's fine"
No, it's not. I realy don't understand your attitude... Pfsense is already capable of doing static NPT, you know it's a thing and there is a feature request for dynamic NPT... You can implement it and solve this stupid issue...
Your ISP can deploy IPv6 correctly and solve this stupid issue.