• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Let's Talk IPV6

Hmm. So in the rule I'd need to list BOTH the IPV4 and IPV6 addresses it applies to? I guess that's a little bit better, but still more addresses to keep track of when doing this shit.

How would this work in the case where

Do you have to firewall off the automatically generated link-local addresses as well or are they automatically local only? I haven't wrapped my brain around how this works quite yet.
Link local addresses (any address in the fe80::/10 range) are non-routable addresses. Applying firewall rules to this range could potentially interfere with their intended function, which is to establish connectivity to all IPv6 neighbors on a network via NDP for SLAAC address negotiation. No firewall rules should be necessary.
Also, how do you keep track of your firewall rules when SLAAC could change them at any moment, or - as the problem Ready4Dis has, when his ISP changes the block on him?

Does a change in the block, result in a change in the address, and if I have written my rules against a specific address, it is now different, and breaks?

Or can you somehow write the rules against only the last /64 portion of the address and have the rest of it be a wildcard?

Still, seems way more complicated to manage than the status quo, even with the complications of NAT.
The ISP only controls a certain portion of your IPv6 address. (usually the first 4 hextets) Trying to create firewall rules that only apply to individual hosts that use SLAAC to acquire IP addresses will not work for the reason you have stated - they constantly change and (IMO) defeats the purpose of SLAAC. If you want to hand out specific IPv6 addresses for crazy per host firewall rules, you would need to utilize DHCPv6 with static assignments and create rules that can be crafted using REGEX expressions if your firewall supports it.

In PFSense, I have made my DUID permanent and enabled an option that will NEVER send a dhcpv6 "release" on the WAN interface. Theoretically, I should be able to maintain my block with Verizon forever as long as they don't decide to re-IP their entire network.
So I am trying to figure out how to do this in pfsense:

The dropdowns allow me to select the protocol for my rule as IPv4 + IPV6 but I still just have the one source and one destination field to enter the affected address:

View attachment 504131
Do I have to create an alieas, and then in that alias list, list both the IPV4 and IPV6 addresses?
PFSense is a firewall. It blocks all traffic by default unless you have an "allow any any" rule somewhere. The way this rule is written, you would be inserting another rule that effectively blocks ALL network traffic in BOTH directions. By default, your rules should look like this:

1661554427625.png

(ignore the first 2 lines)
And how do I even structure it, such that it still works when the block changes or the SLAAC assigns a different address?

How do I even use static IP's on my local network anymore if IP's are doled out by the ISP via SLAAC?
SLAAC is a protocol that is negotiated between IPv6 capable hosts on the same VLAN and has nothing to do with your ISP for address assignment on your internal VLANs. Your ISP merely assigns a "prefix" that your firewall/router will take and inject into SLAAC and say "Hey! This is our subnet! This is the next hop!" (and some other misc. information that is configurable information). This is called a "RA" or "Router Advertisement". You can configure how PFSense handles and sends Router Advertisements here:
1661554749609.png


There are multiple RA modes - if you click the blue "i," it explains the differences.
1661554842504.png


In your situation, I would recommend "Managed." Keep in mind that that will break devices that don't support DHCPv6 (ie. Android)
Does this mean I can't use static IP's on my local network without paing my ISP for "business internet" that includes static IP's?
I would recommend using DHCPv6 with reservations. The last few hextets will always stay the same while the first 4 can change.

IPv6 is superior here IMO because there are things you can configure to maintain your IPv6 subnet that you get from your ISP forever as I outlined above. Keep in mind that static IP's were never really offered to home customers for IPv4 either. For business plans, I imagine you can get your own dedicated IPv6 prefix just like you can get your own static IPv4 addresses/subnets depending on ISP.
I guess I could play around with it a little bit, by enabling IPV6 only on my WAN, and then creating a new VLAN, and enabling IPV6 only on that LAN, giving me some space to experiment without tanking my current setup, but as of right now IPV6 is still making very little sense to me, and it is making me pretty angry that I am being forced into dealing with this shit.
No one is forcing you to do anything. :) If you are in the US, you can still operate on IPv4 only and not notice a thing.

Who is your ISP? If you use PFsense, there is ton of info out there for best configuration practices for each ISP and other good information, especially on Netgate's forum. For example, I think Comcast uses /60 delegated prefixes while Verizon FiOS is using /56.
 
Sorry, haven't delved into PFsense, just PaloAlto, cisco & fortigate, so I can't help you without training up on PFsense. As ComputerBox34 said, the link-local addresses are just for neighbor discovery (the mechanism that ipv6 uses for auto-discovery) and shouldn't be used for routing. IPv4 will be around for quite a while, you have plenty of time to learn ipv6. I just looked at my pihole stats, looks like about 20% of my dns lookups (AAAA) are ipv6, I don't use ipv6 on my internal lan and my isp doesn't do ipv6, yet (no ipv6 ip on the wan side of my router).
 
Who is your ISP? If you use PFsense, there is ton of info out there for best configuration practices for each ISP and other good information, especially on Netgate's forum. For example, I think Comcast uses /60 delegated prefixes while Verizon FiOS is using /56.
Comcast tends to hand out /64 prefixes (at least for myself and my friends that have setup ipv6 at home, on comcast).
 
Well, having done some more reading, I think I am fine putting this off for now.

Maybe if google gets their heads out of their asses and start supporting DHCPv6 in Android, I'll make the transition, but until that time I am happy to stay on IPV4.

The overwhelming majority of my network traffic is local anyway, and for that IPV4 will continue to work just fine forever.

If stuff starts breaking, or if they CG-NAT me such that I can no longer port forward inbound traffic, I'll probably keep a "block all" rule both inbound and outbound on IPV6 and carve out holes for specific clients/servers that need IPV6 on a case by case basis, leaving everything else blocked.
 
I don't understand hating on DNS, forcing memorizing IPs, or hesitating on jumping on decades old tech stacks... but, it sounds like you found your own path forward. I ran dual stack ipv6 for a few years, and, now most of my systems are ipv6 only. Not dealing with any NAT and other BS alone has been worth it (recall, too, that NAT is a hacky protocol simply there to battle against IP exhaustion and was intended to be temporary during the transition to ipv6. Oh, how optimistic folks were).
 
I don't understand hating on DNS, forcing memorizing IPs, or hesitating on jumping on decades old tech stacks... but, it sounds like you found your own path forward. I ran dual stack ipv6 for a few years, and, now most of my systems are ipv6 only. Not dealing with any NAT and other BS alone has been worth it (recall, too, that NAT is a hacky protocol simply there to battle against IP exhaustion and was intended to be temporary during the transition to ipv6. Oh, how optimistic folks were).
How are you handling 6to4 for websites like Amazon that don't do IPv6?
 
NAT64 -- works for TCP, UDP, and ICMP only though (+ WAN still have an ipv4 interface). Sites and services that aren't reachable via ipv6 are the only reason I have a handful of things still dual stacked.
 
Comcast tends to hand out /64 prefixes (at least for myself and my friends that have setup ipv6 at home, on comcast).

Unless your region is weird and non-standard for them, Comcast will hand out a /60 (consumer) or /56 (business) IPv6 block if the router requests it. This can then be parted out by the router as /64 subnets to its various VLANs/interfaces.


NAT64 -- works for TCP, UDP, and ICMP only though (+ WAN still have an ipv4 interface). Sites and services that aren't reachable via ipv6 are the only reason I have a handful of things still dual stacked.

I thought about trying this, but it seems to me like it's just trading one NAT headache for another even less mature one.
 
Unless your region is weird and non-standard for them, Comcast will hand out a /60 (consumer) or /56 (business) IPv6 block if the router requests it. This can then be parted out by the router as /64 subnets to its various VLANs/interfaces.




I thought about trying this, but it seems to me like it's just trading one NAT headache for another even less mature one.
Hm, when I do a request from them, and set a prefix hint of ::/0, they hand me a /64. I'll have to play around with it more and see if I just have something configured elsewhere.

It was certainly "fun" to play with, and it does work, but, only minimally. For now, just going dual stack seems the best bet until everyone gets on board with ipv6.
 
Hm, when I do a request from them, and set a prefix hint of ::/0, they hand me a /64. I'll have to play around with it more and see if I just have something configured elsewhere.

It was certainly "fun" to play with, and it does work, but, only minimally. For now, just going dual stack seems the best bet until everyone gets on board with ipv6.

Not sure what router you're using. I'm more familiar with setting up the Edgerouter for IPv6. The following is what I have, FWIW, maybe it'll help:

Code:
interfaces {
    ethernet eth0 {
        description Local
        duplex auto
        speed auto
        vif 10 {
            *snip*
        }
        vif 19 {
            *snip*
        }
        vif 21 {
           *snip*
        }
        vif 25 {
            *snip*
        }
        vif 29 {
            *snip*
        }
        vif 99 {
            *snip*
        }
        vif 915 {
            *snip*
        }
    }
    ethernet eth1 {
        address dhcp
        description eth1
        disable
        duplex auto
        firewall {
            in {
            }
            local {
            }
        }
        speed auto
    }
    ethernet eth2 {
        address dhcp
        description WAN
        dhcpv6-options {
        }
        dhcpv6-pd {
            pd 1 {
                interface eth0.10 {
                    host-address ::1
                    no-dns
                    prefix-id :0
                    service slaac
                }
                interface eth0.19 {
                    host-address ::1
                    no-dns
                    prefix-id :4
                    service slaac
                }
                interface eth0.21 {
                    host-address ::1
                    no-dns
                    prefix-id :2
                    service slaac
                }
                interface eth0.25 {
                    host-address ::1
                    no-dns
                    prefix-id :5
                    service slaac
                }
                interface eth0.29 {
                    host-address ::1
                    no-dns
                    prefix-id :3
                    service slaac
                }
                interface eth0.99 {
                    host-address ::1
                    no-dns
                    prefix-id :1
                    service slaac
                }
                prefix-length 60
            }
            rapid-commit enable
        }
        duplex auto
        firewall {
            *snip*
        }
        speed auto
    }
    loopback lo {
    }
}

efh0 is the LAN, eth2 is WAN. each vif on eth0 is a VLAN (eth1 is unused). There is a specific option prefix-length on the WAN interface. It seems counter-intuitive, but the prefix hints/etc. for each LAN VLAN are also specified on the WAN (I don't know if this is some Edgerouter/VyOS quirk, or extends deeper into Linux, I'm guessing the latter).
 
(recall, too, that NAT is a hacky protocol simply there to battle against IP exhaustion and was intended to be temporary during the transition to ipv6. Oh, how optimistic folks were).

I think people overstate the problems with NAT, and completely dismiss the benefits of it.

No, it's not a matter of security, anyone who relies on NAT as a form of security is deluding themselves, but it IS a matter of flexibility.

I guess I take exception with the fact that my local network is "a part of the internet" that should be one to one addressable with the greater internet.

I see my network as my network, as having nothing to do with the internet. The overwhelming majority of traffic on my network is local only, and doesn't care about the outside world or even if it exists at all.

NAT offers a ton of flexibility. As long as I just use the predefined private IP addressees, I can do whatever the hell I want with my local configurations, and don't have to care about the internet, and that's how I like it.

As soon as I have to have and use externally defined globally unique addresses assigned by an ISP, my network feels less like my network. It feels like it is just an extension of the internet, and I have a great deal of reservations when it comes to that.

My local network is mine, it's purpose is not solely as a way to access the internet, it is separate from the internet, and retains the ability to occasionally access it via a bridge that I have defined, and that's the way I like it. I PREFER NAT and really don't ever want to see it go away.

My local network is not the internet, and should not have to be 1:1 addressable with anything outside of my network, ever.
 
  • Like
Reactions: pek
like this
It's time to revisit this lovely little topic.

It's been almost two years, and I still haven't gotten around to becoming comfortable with IPV6.

So, IPV6 is still disabled on my routers WAN and LAN interfaces, all IPV6 traffic is blocked in every firewall I control, and IPV6 is disabled on every host and client on my network.

....and it will probably stay that way until Android supports DHCPv6. I'm not even going to bother embracing IPV6 until I can make sure I can control ALL hosts and clients on my network and assign them one and only one IP address that I can firewall as I see fit.

From Googles perspective I think this is about control. Their excuse is that tethering is difficult if you can only have one IP address, but who the fuck tethers a LAN anyway? If you have a LAN there is no need for tethering.

To me, it sounds more like they want the ability to grab as many addresses as they want, and make it difficult to control clients on the local network. Google wants to make it as difficult as possible for you to properly firewall off things you don't want them to connect to.

Anyway, the whole address exhaustion issue finally got real for me today. I got a significant discount offer from a cloud backup service provider if I can connect only via IPV6 to avoid them burning an IPV4 address.

Well, I would like to take advantage of that, but I would need to be able to enable IPV6 on the LAN and allow one and only one host with one and only one IP address through, because I just do not have the time to reconfigure my entire network for IPV6, and that simply will not happen until Google supports proper DHCPv6 with one IP address per client and only one IP address per client and I control which IP address it gets.
 
I remember like 15-16 years ago, worked on software network stack product that delt with all the the NAT issues that ipv4 made, with 3 big family of them (there a combo that make it particularly hard I remember in that era if 2 people had that type of firewall they could not play head to head with their PS3), stun, ice and what not...

The vast majority of personal user never wanted a NAT, they want to give internet access to a device and a firewall, would you tell me back then that in 2024 in North America at least, ipv4 would still be vastly the norm..... that is a bit nut, but we have much more address by people here, but I feel like there must be something that was unexpectedly hard to do the transition we did not thought about back in the days (how many device used now are older than when the ipv6 transition was certain to happen....).
 
I'm not even going to bother embracing IPV6 until I can make sure I can control ALL hosts and clients on my network and assign them one and only one IP address that I can firewall as I see fit.
Then you'll almost certainly never be able to use IPv6, as the spec mandates support for multiple IPs per interface, and it's integral into the protocol.
 
Then you'll almost certainly never be able to use IPv6, as the spec mandates support for multiple IPs per interface, and it's integral into the protocol.

So how do you craft reasonable firewall rules that present devices from just requesting another IP and circumventing them? Firewall off everything and only allow through outbound traffic from addresses you have specifically allowed, and assigning categories of devices to dedicated VLANs that have the same access permissions?

That sounds tedious and unmanageable as all hell.

I also wonder how my "entire network exits via VPN" setup will work.

My VPN service supports IPV6, but I don't know how it would work with IPV6 that expects to be 1:1. With my VPN setup everything exits through a single IP on the other end.

I'm really uncomfortable with all of these devices having separate addresses they can do with as they please locally too. I wish I could firewall every port on every switch to block anything that is not IPV4 traffic. At least that way I understand what is getting through, and I can control it.

Heck, I don't even like IPV4 broadcast/multicast. I don't think devices should have the ability to detect each other on a network. If you want to connect to something (like a printer) you should know its IP address and enter it manually.
 
Last edited:
So how do you craft reasonable firewall rules that present devices from just requesting another IP and circumventing them?
I think you should be able to setup your network and device so that they can have a single global ip address (and not sure how much you have to think about the local one, but the second one will be a local only addr).

And for device that do not need to talk to some external world, just in pure local situation they can have only their link-local addr with no global at all.
 
I haven't managed a firewall IP by IP in... many years. I don't know anyone that still tries to do it that way. Ports, protocols, traffic shape, DPI, etc. all are not only better ways to manage it, but, they actually scale higher without causing a lot of KTLO and toil for people. Also a lot more automatable that way, too.

I don't know Windows stack too well, but, I think LubeTbk may be correct that if you have no WAN traffic at all, then you can just statically (ew) assign only a link local to it. If you want any WAN traffic at all, you'll get global addresses, and by default those are ephemeral and will change (even if you just assign one).
Android I don't know at all - it looks like it's in a pretty F'd state and they're trying to push through some RFCs to get things their way. I honestly hope they fail at that.
iOS/MacOS, options seem minimal if you just do through the UI. You can drop in a link-local if you want, but as soon as you want global addressing, you'll get n-addresses.
Linux depends a bit on distro, but you'll generally find yourself defaulting to 1x link local + n-global addresses. I'm sure you could dig deep enough and find a config for that and change the behavior, and I'm equally sure that would change your network experience for the worse overall. At the very least you're going to piss off RA, which I'm not even sure what all that would break. Good luck if you do.

Edit: I'm basing all the above on using SLAAC or DHCPv6. If you're going to run around and manually do IPv6 on your entire network, most of it doesn't apply. Also good luck though.

My suggestion is to just get caught up to within the past 10-15 years of networking. Or stick with IPv4 and pay the little bit more from your backup company.
 
I've been using IPv6 on my home network and production network at work for 2 years without any problems. (or security "incidents")

With your approach and frame of thinking, I don't think you'll ever be able to deploy it. There are things that you are saying that is the equivalent of running nails across a chalkboard for Network Engineers.

Oh - and Google will never support DHCPv6. If you have many hours of time to kill, you can follow the drama here - https://issuetracker.google.com/issues/36949085?pli=1
 
....and it will probably stay that way until Android supports DHCPv6

I suspect you're going to be waiting a long time. I don't think Android is likely to support that any time soon, if ever. But they've surprised me before; they did eventually enable PMTU backhole workarounds for broken networks... So maaaybe.

So how do you craft reasonable firewall rules that present devices from just requesting another IP and circumventing them?

You could firewall by mac address assuming there isn't an IP router in between your clients and the firewall.
 
I've been using IPv6 on my home network and production network at work for 2 years without any problems. (or security "incidents")

With your approach and frame of thinking, I don't think you'll ever be able to deploy it. There are things that you are saying that is the equivalent of running nails across a chalkboard for Network Engineers.

Examples? I'd like to understand just how I disagree with those who claim to know what they are doing :p

Because if they are claiming my private local Internet as part of the greater Internet, they can fuck right off.

It is - and should only ever be - a private network first, that occasionally connects to the outside world via a bridge, but only the packets I approve of should get through.

As the owner of the network, I should have all the tools that puts me in absolutely control and clamp down access to everything as I see fit.

Oh - and Google will never support DHCPv6. If you have many hours of time to kill, you can follow the drama here - https://issuetracker.google.com/issues/36949085?pli=1

It's absurd. I don't think you should be able to claim IPV6 support without DHCPv6 compliance.
 
  • Like
Reactions: Meeho
like this
Examples? I'd like to understand just how I disagree with those who claim to know what they are doing :p

Because if they are claiming my private local Internet as part of the greater Internet, they can fuck right off.

It is - and should only ever be - a private network first, that occasionally connects to the outside world via a bridge, but only the packets I approve of should get through.

As the owner of the network, I should have all the tools that puts me in absolutely control and clamp down access to everything as I see fit.



It's absurd. I don't think you should be able to claim IPV6 support without DHCPv6 compliance.
I'm not sure what you're actually complaining about. You can, and should, block incoming traffic just as you do today. You can filter outbound traffic by prefix or MAC. If you're problem is NAT then as network guy I would say that you can fuck right off. :) NAT, actually PAT in most home cases, is a kludge that was designed to solve a problem, IP exhaustion, that IPv6 doesn't have. It was never about security or privacy and it isn't either. It served the purpose of getting us through IP exhaustion but it is time to toss that shit out with the dirty bathwater. IPv6 isn't rocket science.
 
How is NAT not beneficial to privacy?

Also, IPv6 was, is, and probably always will be shit, and that's why most don't bother moving from IPv4 today.
 
How is NAT not beneficial to privacy?

Also, IPv6 was, is, and probably always will be shit, and that's why most don't bother moving from IPv4 today.
What is shit about IPv6? Be specific and show your work.

NAT is "beneficial" to privacy, but that's not the problem it was trying to solve, and never (still is not) a goal of NAT's purpose. You can certainly use a screwdriver as a hammer, but, it's not a great idea or what it's supposed to be used for, either.
 
What is shit about IPv6? Be specific and show your work.

NAT is "beneficial" to privacy, but that's not the problem it was trying to solve, and never (still is not) a goal of NAT's purpose. You can certainly use a screwdriver as a hammer, but, it's not a great idea or what it's supposed to be used for, either.

Actually, it's not really any kind of privacy enhancement IMO.

With IPv4 NAT/PAT, you're pretty much always going to be coming from the same IP address (i.e., your ISP probably isn't going to randomly issue your router a new one). Aggregating a bunch of hosts behind a single address doesn't change this. Most people's networks are going to be too small to effectively hide a single host's activity in the noise.

However, with IPv6 privacy extensions, the address used to connect to the outside world is randomized and changes up on a regular basis. This makes correlating usage to a particular address over time near-impossible. Pretty much every major OS enables this by default.

And if a site really wants to track users there are better ways, such as cookies/browser fingerprinting.
 
Actually, it's not really any kind of privacy enhancement IMO.

With IPv4 NAT/PAT, you're pretty much always going to be coming from the same IP address (i.e., your ISP probably isn't going to randomly issue your router a new one). Aggregating a bunch of hosts behind a single address doesn't change this. Most people's networks are going to be too small to effectively hide a single host's activity in the noise.

However, with IPv6 privacy extensions, the address used to connect to the outside world is randomized and changes up on a regular basis. This makes correlating usage to a particular address over time near-impossible. Pretty much every major OS enables this by default.

And if a site really wants to track users there are better ways, such as cookies/browser fingerprinting.
This +1

IPv6 technically employs more "privacy" mechanisms than NAT ever did.

"NAT" is not a security mechanism - it's a hack that was designed to preserve IP addresses. Your firewall is what actually enforces security policies and the most important appliance when it comes securing one network from another (ie. the internet).
 
What is shit about IPv6? Be specific and show your work.
I'll keep it general for simplicity: it's as good as its adoption and IPv4 abandonment.

NAT is "beneficial" to privacy, but that's not the problem it was trying to solve, and never (still is not) a goal of NAT's purpose. You can certainly use a screwdriver as a hammer, but, it's not a great idea or what it's supposed to be used for, either.
It wasn't its purpose, that doesn't mean it isn't a practical feature.
 
NAT is "beneficial" to privacy, but that's not the problem it was trying to solve, and never (still is not) a goal of NAT's purpose. You can certainly use a screwdriver as a hammer, but, it's not a great idea or what it's supposed to be used for, either.
It wasn't its purpose, that doesn't mean it isn't a practical feature.

It really isn't. Maybe at the very beginning there was a modicum of truth to this but with today's standards and practices you're deluded if you believe there is any privacy, or security, protection provided by NAT/PAT.
 
I'll keep it general for simplicity: it's as good as its adoption and IPv4 abandonment.
That isn't at all showing anything of value here. Do you have anything technical or reasoned on why YOU made the claim that an entire protocol is "shit"? This is a tech forum, and quite full with folks who deeply understand these things, so there is no need to "keep it general for simplicity".
 
It really isn't. Maybe at the very beginning there was a modicum of truth to this but with today's standards and practices you're deluded if you believe there is any privacy, or security, protection provided by NAT/PAT.

The only benefit you get is all of your traffic being mashed together behind the same IP.

It is more difficult (but not impossible, based on unethical fingerprinting tech) to discern who behind that IP is doing what. Especially when so many leave their WiFi wide open for anyone to use.


But the sense is less one of actual privacy, and more one of comfort with the structure.

A single entry and exit point from my local network to the wider internet makes it feel like my private network that only just happens to be connected to the internet as a whole because I built a bridge between it and the internet.

When everything is 1:1 and mashed together that sense of ownership over my own LAN feels less real. It's yucky.
 
Either way for me it seems to be a moot point.

After making sure I had it firewalled off on all of my LAN side VLAN's, I enabled IPV6 on the wan interface.

I followed some guides I have seen for Verizon FiOS and pfSense/OPNSense which suggest you should:

  • Set IPV6 Configuration to DHCPv6
  • Request only an IPV6 Prefix enabled
  • Prefix delegation size /56
  • Send IPV6 prefix hint enabled

Nothing. I just get the fe80: hardware IP on the WAN interface.

I tried enabling "Request IPV6 information through IPV4" to see if that would do it, but it didn't either.

I'm not sure if my settings are wrong, or if Verizon just hasn't enabled ipv6 in my area yet.

I'd imagine I would know if it is working by seeing my WAN interface pull a public IPV6 IP address, correct? Or is that no longer needed these days with everything being 1:1? Maybe the public firewall interface no longer needs an IP if it is not doing any routing, since all of the devices on the LAN have 1:1 addresses?

I have yet to find a good guide on this stuff that really takes it down to basics from a "so you are new to IPV6 but are pretty good with IPV4" perspective.

Everything seems to assume a certain level of base understanding of how it is supposed to work.

I wish someone would explain it to me like I am a Network Engineer who has been in a coma since the mid 1990's. In other words, high on technical detail, but low on assumed pre-existing IPV6 specific knowledge.
 
And as an aside, sure, you can tear apart the arguments about preferring NAT, but that doesn't change the fact that the IPV6 address format is atrocious and not human usable.

I've never been one to use host names or DNS for my LAN. I just have a process for assigning my IPV4 addresses and keep them all in memory. I'm probably going to wind up keeping IPV4 for everything local for that purpose, as I'd hate to have to start assigning local domain/host names to every single little host on my LAN.

Because - quite frankly - the IPV6 addressing scheme/format is borderline useless unless you are a computer.
 
A single entry and exit point from my local network to the wider internet makes it feel like my private network that only just happens to be connected to the internet as a whole because I built a bridge between it and the internet.

When everything is 1:1 and mashed together that sense of ownership over my own LAN feels less real. It's yucky.

Maybe I'm off base here but this is no different when using IPv6, IPv4 with routable IPs or IPv4 with rfc1918+NAT/PAT. Your statements above lead to me to believe that you have no idea how IP routing actually works. Unless you you have multiple circuits there is only way into or out of your network. The only thing that is different not using NAT/PAT is both endpoints know each other's IP. The pathing does not change and any firewall rules you have in place are still applicable.
 
Either way for me it seems to be a moot point.

After making sure I had it firewalled off on all of my LAN side VLAN's, I enabled IPV6 on the wan interface.

I followed some guides I have seen for Verizon FiOS and pfSense/OPNSense which suggest you should:

  • Set IPV6 Configuration to DHCPv6
  • Request only an IPV6 Prefix enabled
  • Prefix delegation size /56
  • Send IPV6 prefix hint enabled

Nothing. I just get the fe80: hardware IP on the WAN interface.

I tried enabling "Request IPV6 information through IPV4" to see if that would do it, but it didn't either.

I'm not sure if my settings are wrong, or if Verizon just hasn't enabled ipv6 in my area yet.
Seeing the fe80 address on your WAN interface is normal and correct. Verizon will assign a /56 which pfSense will parse and then take and assign to your LAN interface(s) provided that you have them setup correctly. Make sure you have it set to only use /64's.

Verizon completed their IPv6 rollout for all FiOS customers in 2022. I've been using it since then with 0 issues on a pfsense setup and they have never changed my /56 assignment. For FiOS areas which Verizon sold to other providers in certain areas of the country (Brightspeed?), I do not know if those new network operators rolled out IPv6.

A great guide on how to setup IPv6 on pfsense can be found here: https://forum.netgate.com/topic/155534/verizon-fios-and-ipv6-which-settings-work

Pay attention to both the LAN and WAN interface settings. PFSense also has a global "switch" for IPv6 buried somewhere in the global admin settings you need enable as well.

I'd imagine I would know if it is working by seeing my WAN interface pull a public IPV6 IP address, correct? Or is that no longer needed these days with everything being 1:1? Maybe the public firewall interface no longer needs an IP if it is not doing any routing, since all of the devices on the LAN have 1:1 addresses?
Nope - your "LAN" interfaces are what get public IPv6 addresses, not WAN.

The way it works is that VZ will advertise and route your assigned /56 block to your WAN interface, which is assigned a PRIVATE fe80 address. Your router is responsible for assigning a PUBLIC IPv6 address (with a block assigned by Verizon using DHCPv6-PD) to your LAN interfaces that you have enabled for IPv6.
I have yet to find a good guide on this stuff that really takes it down to basics from a "so you are new to IPV6 but are pretty good with IPV4" perspective.

Everything seems to assume a certain level of base understanding of how it is supposed to work.

I wish someone would explain it to me like I am a Network Engineer who has been in a coma since the mid 1990's. In other words, high on technical detail, but low on assumed pre-existing IPV6 specific knowledge.
I would walk into this with an open mind and do not assume IPv4 is a conceptually 1:1 prototocl to IPv6 - it's not! You will bend your mind into pretzels by taking this approach.

There are plenty of great YouTube videos that explain the protocol and how it's supposed to run on a production network.
And as an aside, sure, you can tear apart the arguments about preferring NAT, but that doesn't change the fact that the IPV6 address format is atrocious and not human usable.

I've never been one to use host names or DNS for my LAN. I just have a process for assigning my IPV4 addresses and keep them all in memory. I'm probably going to wind up keeping IPV4 for everything local for that purpose, as I'd hate to have to start assigning local domain/host names to every single little host on my LAN.
You are in for a bad time if you do not enable DNS and automatic assignment of DNS records to your DHCP server. PFsense makes this super easy.
Because - quite frankly - the IPV6 addressing scheme/format is borderline useless unless you are a computer.
Bingo! These protocols are designed to make it easy for computers to talk to each other at massive world-wide scale - not make life easy for the humans that build and operate the network. For that, more protocols are developed (or augmented, such as DNS) to help make things easier for humans to access and interact with the computers on the internet. IPv4 was great but as we found out, quickly hit it's scalable limitations. IPv6 resolves that at the expense of what some would consider the "convenience" but that's why we have DNS.

I use DNS exclusively on my internal network using PFSense's DNS resolver. I don't know any of my hosts IPv6 addresses, but I know all of their DNS hostnames and everything works perfectly fine.
 
Last edited:
Bingo! These protocols are designed to make it easy for computers to talk to each other at massive world-wide scale - not make life easy for the humans that build and operate the network. For that, more protocols are developed (or augmented, such as DNS) to help make things easier for humans to access and interact with the computers on the internet. IPv4 was great but as we found out, quickly hit it's scalable limitations. IPv6 resolves that at the expense of what some would consider the "convenience" but that's why we have DNS.

I use DNS exclusively on my internal network using PFSense's DNS resolver. I don't know any of my hosts IPv6 addresses, but I know all of their DNS hostnames and everything works perfectly fine.

I'm not sure I am comfortable with that kind of abstraction. I prefer to live in the details.

I always set everything static and manual so I know exactly what it is, and I know it isn't "moving" on me. I detest everything auto-detection and auto-configuration. I want to know that everything always has the same IP I tell it to have, every time, and nothing ever changes on me.

The only thing that uses DHCP at all on my network is WiFi due to its somewhat unpredictable nature, but I minimize reliance on WiFi all together. Only devices on the Wifi are a couple of laptops (which are rarely used) and the phones. Everything else gets copper (or fiber)

But that's fine. I can just continue to use IPV4 on my LAN.

That's what I am going to have to do anyway, since Google refuses to support DHCPv6. I'm not about to rely on SLAAC.

So, unless Google changes their minds (seems unlikely any time soon) I will keep everything - except a onesy or twosey manually applied IP for something like the backup situation I mentioned above - on my network IPV4 and NAT:ed indefinitely.

...or at least until being on IPV4 starts having some real consequences, at which point I'll be forced to make some decisions. Maybe just get rid of all devices that don't support DHCPv6
 
Maybe I'm off base here but this is no different when using IPv6, IPv4 with routable IPs or IPv4 with rfc1918+NAT/PAT. Your statements above lead to me to believe that you have no idea how IP routing actually works. Unless you you have multiple circuits there is only way into or out of your network. The only thing that is different not using NAT/PAT is both endpoints know each other's IP. The pathing does not change and any firewall rules you have in place are still applicable.

I know you are right on an intellectual basis, but I still don't like it.

It feels wrong.
 
So, how does the internet work in your world, then? Do you memorize the IPs for everything you're connecting to?
Internet? No. I use DNS.

But the Internet is a completely separate thing from my LAN.

The two have nothing to do with eachother, other than that a small minority of traffic occasionally has to transit out to the WAN.
 
Internet? No. I use DNS.

But the Internet is a completely separate thing from my LAN.

The two have nothing to do with eachother, other than that a small minority of traffic occasionally has to transit out to the WAN.
Technologically speaking though, they're identical. You LAN is just a tiny example of it. I don't understand the fear against extremely well established tooling. What do you do when guests come over? "Hold on, I need to consult my spreadsheet and give you an IP address"?
 
I'd imagine guests aren't allowed on the lan, or they're given a guest network to connect to. That's a pretty reasonable thing to do even if you aren't paranoid or ocd (which some might argue you should be, about your home network).
 
Z, FWIW you might want to go through some of the free tutorials these folk offer. It's been a long time, but from what I recall the info was very useful and to the point without a lot of fluff. I'm guessing you will come through it understanding a lot more of what is going on and your comfort level will go up significantly. In the end you may even be able to get a +5 comfort block of addresses. :)

https://ipv6.he.net/certification/


**edit**

One thing I think may be getting glossed over is that if/when you switch to IPv6 it will almost certainly be dual stack meaning you're not giving up IPv4. You'll still be able to use IPv4 internally to move around your LAN if you desire. The bulk of the Internet is still IPv4 so getting rid of it really isn't on the table today ... one day maybe but not soon.
 
Last edited:
Back
Top