IPv6 sanity check

Guest

On the DHCPv6 page, I have the range set to 2001:xxxx:xxxx:6901::2 - 201:xxxx:xxxx:6901:ffff.

When trying to solicit help from someone remote, specific details and accuracy are important.

A said in my first reply to the OP that he cannot use 6901, see message 2 of this thread. His ISP is assigning him the following:

ISP: AT&T
IP Block: 2001:xxxx:xxxx:6900::/56
First usable: 2001:xxxx:xxxx:6900::2/56
Gateway: 2001:xxxx:xxxx:6900::1/56

I have given up!

Derelict

Of course he can use 6901.

You do not use a /56 on an interface, ever.

Split it into /64s however you want.

ISP: AT&T
IP Block: 2001:xxxx:xxxx:6900::/56
First usable: 2001:xxxx:xxxx:6900::2/56
Gateway: 2001:xxxx:xxxx:6900::1/56

That is, essentially, nonsense from AT&T. But it should work.

awebster

There is a piece of the puzzle missing…Its kinda technical, so please bear with me while I attempt to explain it.

In a static IPv6 WAN configuration, if the provider is expecting /56 and you set /64 on the WAN interface (others have said setting /56 on the WAN interface is ridiculous; they are correct), the ISP assumes that 2001:xxxx:xxxx:6901:: is on the same L2 subnet, but it isn't because the subnets sizes don't match.
If and only if the provider were to have routed the remainder of the addresses 2001:xxxx:xxxx:6901 thru 2001:xxxx:xxxx:69ff to the 2001:xxxx:xxxx:6900::2 address would it actually work, and unless they told you to use 2001:xxxx:xxxx:6900::2 on your side, they have no clue what IP is your gateway, and wouldn't know where to route it to.

In your case, if you ping google from a LAN side PC @ 2001:xxxx:xxxx:6901::2, the packet most likely gets to the intended destination, but the issue is with the return traffic. It has no way to figure out how to get back beyond the ISP.
The provider will send "ICMP6 neighbor solicitation who has 2001:xxxx:xxxx:6901::2" packets to ff02::1:ff00:2 on the WAN interface, but these are ignored.
The actual address used is ff02::1:ffxx:xxxx where xx:xxxx are the least significant 24 bits of the target IP, or 00:0002. If the LAN side PC was at 2001:xxxx:xxxx:6901:1234, then the "neighbor solicitation who has" packets would be going to ff02::1:ffcd:1234. Neighbor solicitation packets function similarly to ARP who-has, but are sent as multicast packets instead of broadcast to limit their spread. Nevertheless their functionality is similar; that is to map a MAC address to an IPv6 address. pfSense supports proxy ARP via Virtual IPs, but this support does not extend to IPv6.

To put your issue into perspective from an IPv4 point of view, it would be the equivalent of the ISP allocating 100.64.96.0/20 to a client and having 100.64.96.1/20 on the ISP side and 100.64.96.2/24 on the client side (note the differing netmasks). The provider will send ARP who-has packets to try and figure out how to reach other hosts on the /20 subnet, but anything outside of the first /24 subnet (eg: 100.64.97.1) would be ignored by the firewall, unless it was told to proxy ARP for those IPs.

Dynamic WAN configuration would make much more sense, the ISP uses DHCP6 to give out a dynamic IPv6 address (it could also be a static IPv6 via DUID) to which a "statically" assigned IPv6 netblock is routed. At the ISP once the link is up, and the DHCP6 has run its course, a route is automatically added to their routing table for the /56 netblock VIA the assigned IPv6 address.

In a static only config there is just not enough info exchanged for the ISP to know where to send the traffic.
Talk to them and see what other types of config they support, because what you've got right now is kinda useless.

JKnott

In a static IPv6 WAN configuration, if the provider is expecting /56 and you set /64 on the WAN interface (others have said setting /56 on the WAN interface is ridiculous; they are correct), the ISP assumes that 2001:xxxx:xxxx:6901:: is on the same L2 subnet, but it isn't because the subnets sizes don't match.

Think of the /56 as 256 /64s. PfSense can pick select /64 for each LAN or VLAN interface.