@shadowlaw:

…
Do you happen to know if the /48 xs4all gives you is static?
...

Basically yes, but I call it quasi-static, cause they reserve the rights to change just as they could do with IPv4 ;)
Right, it works with prefix delegation request by dhcp6c.

They forced the default behavior to be this way in 2.2.1. You aren't the only one that did not like this change (there are a lot of reasons not to use Track Interface, IMO but there are other discussions here about that).

This is what I had to do in order to be able to enable DHCPv6 as it was prior to 2.2.1: http://www.cmoullas.net/pfsense-2-2-1-breaks-teksavvy-ipv6-on-the-lan/

For a very complete video guide on how to configure IPv6 you can see this series of videos: https://www.youtube.com/watch?v=zdSI7Ez0Xhs

While I wouldn't claim to be any sort of expert on ipv6, the clearest part of ipv6 to me is the routing.

The default route must be on the same subnet as the address.  Any other configuration leads to a network without a router, which means local traffic only.

The way I see it, doing what you have been doing is essentially adding another network configuration on top of the same physical device, which means your existing ipv6 address will only be used for local traffic.

I don't know of anyone doing that, but it's possible to configure if both prefixes are static. The RA config can advertise multiple subnets, but can only do so today if they're both static. Then you should be able to policy route by source network out the correct ISP.

Source address selection by end hosts is possibly a bigger impediment. Client machines generally would only use one or the other. It's probably less problematic with servers with static IPs, such as if you want multi-WAN redundancy to the same internal system on native IPs of both.

I understand. It's only a concern moving between networks that have IPv6 and those that do not. My motivation behind all of this is when I introduced a new backup WAN that is IPv4 only. Instead of disabling IPv6 altogether, I thought I could easily toggle it on and off so I could force all clients to IPv4 automatically when only my IPv4 WAN is available. I think the best approach is to forget about it until I can support it everywhere.

@gsiemon:

If I use Track Interface then I can't edit the RA details anymore although I seem to be able to trick pfSense as per my earlier post.

Yep… and there's a long-standing feature request asking for the ability to modify DHCP6 Server and RA settings when Track Interface is being used...

https://redmine.pfsense.org/issues/3029

Solved: The issue was using a virtual MAC address when running PFSense on a single NIC (router on a stick).

When I was running with the virtual MAC, the NDP table showed my physical MAC still on my external VLAN interface. So, the NDP table wouldn't populate with the MAC of my cable modem.

When I changed to another virtual MAC, it wasn't fixed.

When I changed to my physical MAC, it worked.

The "right" answer is to have a dedicated external NIC, I know this. I'm betting it isn't just the virtual MAC, but the combination of running a VLAN for my external interface AND a virtual MAC.

What is the best way to submit this bug?

Most likely you need to switch to advance DHCPv6 config. See this post for details: https://forum.pfsense.org/index.php?topic=90699.msg502875#msg502875

Did I understand this correctly: dhcp6c constantly tries to get a PD because I told it I want a PD? Well it should! If I don't want it to do it why would I tell it, that it should fetch a PD? Those that have issues with that should simply untick the checkbox, why make it overly complex and intransparent when a PD is fetched and when not? Simple solution as it has been: Checkbox checked: fetch PD, not checked: dont fetch PD. Now it depends if an interface has track interface enabled or I circumvent it by talking directly to the deamon in its config language. For the sake of simplicity and transparency please revert it. And please, dont say who is a majority and a minority, you probably have no full analysis of that, its not a very scientific argument and just makes bad feelings - despite, this argument is highly dynamic and can change easily over time, but you probably dont track that.

After doing some more digging and clearing out all the deprecated ipv6 addresses on my client, I noticed I was getting two separate, but similar address ranges.  Somehow during the upgrade radvd.conf found itself with two subnet advertisements, one for the valid address range and another for an older range that I had not received in quite some time.  I manually removed the old range from radvd.conf, HUP'ed radvd, and after a reboot to ensure a clean network slate my client is connecting again.

@antillie:

I imagine most ISPs wont do this unless you are a large account that spends lots of money.

Depends on how you define "lots." Generally in the US if you have fiber connectivity, they're willing to do it, even if it's just a single connection you're buying with them. Looking at ~$1000 USD/month at the low end for that type of connection, though that can vary widely depending on location.

If you are sending a tagged voice VLAN to a phone along with an untagged VLAN intended to be used by the host chained off the phone and the host chained off the phone is seeing both the tagged traffic and the untagged traffic, the phone is either broken or configured incorrectly.

In my case, this problem was caused by a wireless access point in the network running OpenWRT trying to hand out IPv6 addresses when it had no business doing so. Hope this helps someone.

If everything is configured right, you'll always end up with /64 prefixes on your LAN interfaces; the /60 is the total address space delegated to you, and pfSense will split it up into up to 16 /64 prefixes, one for each interfaces configured to track the WAN.

The ICMP types you are referring to were removed from ICMPv6 for exactly the reasons you mentioned. There really isn't anything worth blocking aside from ping on a layer 3 device. There are ICMP types you might want to block on a switch, such as router advertisements, but that's layer 2 stuff.

And for the love of god don't rate limit ICMPv6 on your edge device. I knew a guy that rate limited ICMPv6 to 20 packets per minute on the linux router in his lab. He was then very confused when I brought down the entire lab by pinging his router from a windows machine with the -t option over IPv6.

Don't approach ICMPv6 with an ICMPv4 mentality. They are totally different protocols with totally different jobs that need to be handled in totally different ways.

Hi,

my ISP will provice native ipv6 in  couple of months, so, there is no need to get any kind if -IM-proper tunnel.
Tunnelbrokers are all (!) slower than the nativ ISP. In another router I used gogonet, HE and SIxxs - the are all slower than my 6to4 solution - and
the not reachable-issue didnot occur once for me…..

The point is not the tunnel, there is another bug which makes this happen - or don't you think so, then, please, explain it to me.

Cheers

4920441

Not sure if this has much if anything to do with 2.2.1, but as this is a development environment for me I was able to upgrade to version 2.2.2-DEVELOPMENT.  My issues are fixed (right now).

I will report back if they break again.

@JasonTracy:

That said, I'm interested to hear more about how you're doing this!

What ?  :D  I will outline the principle for non-tracking setups.

Comcast, I am not with them. But they supply a /60, I understood from elsewhere.
Try [Interfaces: WAN] (Advanced(Send Options=ia-pd 0)) and (prefix delegation: checked)
If you get the /60 on the WAN, then you can know your prefixnumber as the first 64 bits.

Let's assume you get a prefixnumber like 2015:911:abcd:ff80(::1) on your WAN.
The last placeholder (0) in :ff80: is actually the supplied space, your 4-bits equals 15 LAN's possibly.
Now in webgui pfSense you can make a LAN-1 static as 2015:911:abcd:ff81::1/64 or a LAN-2 static as 2015:911:abcd:ff82::1/64. (The space available is :ff81: tru :ff8f: ).

A (PC) serverhost on LAN-1 (:ff81:) could get a number issued by you, (not by DHCPv6), say 2015:911:abcd:ff81::1001.
Or you could config a DHCPv6-Server/RA with a pool like [2015:911:abcd:ff81::1051 upto 2015:911:abcd:ff81::1100].

You make your WAN firewall rules on a wellknown server fixed IPv6 address.

So when ISP pulls/changes your 2015:911:abcd:ff8::/60, then your IPv6 LAN's and public server are securely off-line.

Ditto for Comcast.

EDIT: Sorry, it's actually just a /60 for Comcast.