The /x indicates the prefix length. Your LAN gets a /64 prefix, which means 64 bits for the network address, leaving 64 for the device within the LAN. A /128 means the entire 128 bits is prefix leaving no bits for more than 1 device. I doubt it would have anything to do with the MAC, as it's assigned by DHCP. If it was MAC based, it would be obvious. Your LAN gateway demonstrates the link local address is used, not a public address.
It's amazing how CHEAP some ISPs are, considering the IPv6 address space is so vast. While my ISP initially provided a single /64, that was only temporary and they soon moved to /56. Then there's he.net, which will provide a /48 for free! Before my ISP offered IPv6, I used a tunnel and got a /56 again for free.
BTW, the address space is so vast that every single person on earth could have over 4000 /48s and that's with only 1/8th of the entire address space assigned to anything.
My ISPs don't even offer more expensive plans, not that I'd accept paying. A tech even told me that only government companies are forced to follow IPv6 standards. As it's a private ISP company, they can use proprietary protocols, and it's my problem if Internet doesn't work fully. Another one told me that I'm "welcome" to cancel the contract if I want to.
Indeed, according to IPv6 standard, every ISP receives at least a /32 prefix. With it, these 2 ISPs have more /56 prefixes than IPv4 addresses.
My ISP only route single /64 subnet to resident connection. I'm planning to deploy ULA for each of my VLANs and then NPT to that public /64 prefix assigned by ISP. Do I need to worry about suffix conflict?
Is there any drawbacks (e.g. latency...) in deploying ULA + NPt compared to just GUA via Track interface? The only problem i can think of is that I would need to manually adjust NPt entries every time my ISP routed prefix change and will try to get it working.
Were you able to get it to work? That's what I was considering doing on my OpenWRT a couple years ago but got tired after 2 long fights with both ISPs. Now I'm considering moving to pfSense because of some BusyBox limitations.
Are you able to update your VLANs prefixes when your ISP changes it?
One ugly thing I consider doing is choosing a random /60 prefix from one of my ISPs /32 and setting it as base for my VLANs. ALAIK, some OSs will use IPv4 if only ULA is provided for them, because it implies that no Internet is available on IPv6, even if router manages ULA to GUA correctly.
Using a global prefix that's not delegated to me breaks me from reaching out any device that's on that prefix, but I don't access any residential IP other than mine anyway.
The only places I'm aware of it being available so far are select areas in Northern and Central VA (areas served by five different Verizon central offices have been confirmed) and Waltham MA (where a Verizon Technology Development Center is - or at least was - located).
But determining what areas it might be available in is kind-of off topic for here since that's not directly pfSense-related. The settings to make it work are above, and there's also a script you can set up to detect when Verizon is sending out IPv6 router advertisements in your area.
There's a topic over in the FiOS forum on DSLReports that might be a better place for tracking availability. Don't feel the need to read all 2 years worth of posts... the most current list is within the last two pages (and was just quoted by someone on the last page).
Well... in the packet capture, the MAC address of the Ethernet frame matches the MAC address of the default gateway from my ISP (which is not unusual when dealing with packets being routed to you). But the IPv6 address is definitely not the same, and it doesn't appear to be an EUI64 address, so I can't match it to a MAC address. I do realize that I masked part of the address that would have identified that fact.
It's likely a misconfiguration on my ISP's part... they only just got IPv6 up and running about a week ago, and it may not even be completed yet (But I've figured out how to make it work with pfSense, not knowing whether their own routers even work with it).
It's kind-of annoying that this is logged in the general system log though...it'd be nice if it were in the routing log... but I assume since it's the kernel generating these messages, that's why it's in the system log.
I have been working on a similar setup. Dual WAN IPv4+IPv6. I get native IPv4 from my ISP. For IPv6 I have been using Hurricane Electric for at least a decade. Recently, I stumbled upon a tunnel service that does both IPv4 and IPv6. This makes it possible to rather easily move services, yet keeping IPs the same, both IPv4 and IPv6.
But that's more of a backstory. I have been researching quite the same problem you describe. Packets that are generated on the router (e.g. ICMP TTL Exceeded when doing a traceroute) should be sent back through the same interface they entered, but for IPv6, this doesn't work.
With thanks to Netgate tech support, the solution was to turn off my interface's Block private networks and loopback addresses. Upon reflection, this does make sense and with it disabled, my DHCPv6 server with RA set to either managed or assisted is now responding to DHCPv6 client requests and issuing assignments.
And yet, I will submit a feature request such that when the DHCPv6 Server is enabled, an alert should be posted saying "but you need to disable Block private networks and loopback addresses on the interface, otherwise the DHCPv6 server will never receive the incoming IPv6 client's request for a local RA server..."
That's called "dual stack" and will be needed for a while yet. If the games support IPv6, then it will work that way for you. The operating systems prefer IPv6, but will use IPv4 when necessary.
@qsystems If you are using Unifi APs (Multicast Enhancement, rings bell for those) make sure you have the latest firmware loaded, they have had some issues with multicast recently and supposedly corrected with newer firmware.
It seems that I have found the issue...
By analyzing the tcpdump, I have noticed that there was another ip that was answering to the request of the dhcp.
The problem is that I didn't know what it was. It was in the ndp table of my computer, it was in the neighbour list of the switch.
At the end it was a stupid raspberry that was advertising itself as router. Disconnected, everything works like a charm.
Thanks for the help anyway. Case closed!
I mentioned in my OP that when this happens, I can both ping and ping6 from the pfSense box itself. It's only my local network that can't talk over IPv6 to the public internet.
You have to test various things to isolate the problem. You were able to ping from pfSense, so that shows the WAN connection works. When you try from the LAN and watch the WAN, you can determine if the problem is with pfSense or elsewhere. This sort of thing is just basic troubleshooting. You try to isolate where the problem is coming from.
That was something RMO asked initially, and yes, my default deny IPv6 rule is blocking my LAN from reaching the internet over IPv6. Almost all of my rules have the source (LAN net) that matches the interface where the rule exists. And it appears that after a reboot, the devices that have DHCP6 addresses are not considered part of that LAN net source, and therefor they get caught by the default deny rule.
Interestingly enough, I did what you suggested in RMO's thread and enabled Do not allow PD/Address release and that appears to have fixed my issue. Should it have though?
I would expect that might be the case if you had addresses hard coded somewhere and the prefix changed.
But they're not hard coded, and my IPv6 prefix does not change :).
However, after a reboot, pfSense does not appear to be storing the IPv6 prefix in my "net" source rules I mentioned above. And it's only after I renew my DHCP lease (which doesn't change the lease), that that my pass rules start allowing IPv6 through, that something gets updated within pfSense and my prefixes for each /64 LAN are now stored in the "LAN net" rule. Hopefully that makes sense?
I'm happy to test other scenarios to help narrow things down further.
No matter what I change I just cannot seem to see any leases in the 'DHCPv6 Leases' section. Am I missing something? Hoping someone is able to point me in the right direction to enable IPv6 on my LAN.
Is your modem in bridge or gateway mode? It has to be in bridge mode. If in gateway, only devices directly connected to it will get IPv6 addresses. For example, I get a /56 prefix from my ISP, with the modem in bridge mode, which pfSense can then split into 256 /64s. In gateway mode, I only get as single /64, which cannot be passed through pfSense.
I'm in Canada, so it's not an Aussie thing. As for why it's there, previously it wasn't and the prefix would frequently change. I suppose there is a reason why someone would want to always release the prefix, but I don't know what that is, other than perhaps changing ISP or something.
That is an excellent book for IPv6, though it's about the general principles and doesn't get into connecting to an ISP, DHCPv6-PD, etc.. It's also a good idea to use Wireshark, to examine what's actually on the wire.
BTW, I have copies of that book on both my computer and tablet.
Here's something you can try that might provide some useful info. Disconnect the WAN cable. Run Packet Capture, filtering on DHCPv6 and then reconnect the WAN cable. Download the capture and post it here. I'm assuming they use DHCPv6.
Yes, sorry, I was not very precise regarding the "not to use IPv6 for internal communication for now". I meant more I'm not using it explicitly like e.g. having DNS entries for my local servers (NAS etc.), having firewall rules that allow specific IPv6 traffic (e.g. from or to specific hosts between VLANs) etc..
Generally, I want to push IPv6 as far as possible, but without any compromise or "ugly" setups. IPv6 addresses are running out and in my opinion everyone should do their part moving to IPv6 (and I'm also very interested in it ;) ). And IPv6 definitely has its advantages, e.g. like getting rid of NAT. (Using NPt is fine from my perspective, because it's 1:1 without any state, and it's very helpful e.g. for Multi-WAN setups.)
My setup looks like this:
I have two ISPs that support full DualStack with dynamic /56 prefixes via DHCPv6. But because of https://redmine.pfsense.org/issues/6880 I have disabled IPv6 completely for "WAN2" (actually OPT1 ;) ). (As soon as this issue is solved, I maybe use WAN1 for some VLANs and WAN2 for others. Currently for IPv4 I have a setup where some VLANs use WAN1 with fallback to WAN2 and for some others the other way around.)
For most VLANs I have IPv6 enabled using "track interface", but for some I have disabled it.
I use "Stateless DHCP", so SLAAC for address configuration. (DHCP e.g. to distribute the name server, but my DNS doesn't include any local DNS entries apart from the one of pfSense that pfSense adds automatically.)
I block basically all IPv6 communication between VLANs using a block rule with "xxx net". I need this, because I want to allow Internet traffic where I need an "allow to any". I haven't found any other way to block IPv6 traffic between my VLANs, but allow it for Internet. For IPv4 it's easily done with one "block 192.168.0.0/16" rule, but as discussed above this doesn't work when I get my prefix dynamically via DHCP without a variable or an automatically generated alias that contains the whole prefix or whatever. The downside with the "xxx net" approach is that for n VLANs you need n*n rules (so in my setup 5*5=25) instead of just n, or even 0, because with an alias I could already exclude local traffic from the "allow to any" rule.
I "don't care" (at least in the context of this discussion) what happens within my VLANs, because when IPv6 is used there somewhere "automatically", it's just an implementation detail. If I want to control the traffic within a VLAN, I have to go down to layer 2. What does it help when I block IPv6 there and the devices use another never-heard-of protocol on top of layer 2. My switches (Cisco SG300) have some layer 2 filtering capabilities I think, but I haven't used it so far.
Well, I think that's it basically. I will move on further as soon as more pfSense features support dynamic prefixes. For example when 6880 is solved and NPt support dynamic prefixes, I will try to extend my Multi-WAN setup to IPv6. As I will then also have ULAs, I will probably then also set up IPv6 DNS entries for my NAS etc. Haven't thought about how to allow only individual hosts to some destinations then (regarding the temporary address problem), but I think I still have some time to think about that before I get to that point. ;) But probably that's not even an issue, because I think all use cases where I need this is some kind of server-to-server communication (e.g. mail server to NAS for backups) that don't need temporary addresses anyway.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.