@virgiliomi:

If you only request a /64 from your ISP on the WAN, then you'll only have one /64 to use (presumably for your LAN). In order to use other /64's for other networks (i.e. guest, DMZ, etc.), you'll need to request a smaller prefix than /64. I don't know the smallest size that can be requested on TWC though (Comcast allows residental accounts to request as small as a /60, which results in 16 /64 blocks).

If you tick the "Send IPv6 prefix hint" box on your WAN interface config page and change the drop down just above it to "56" then TWC will give you a /56 block. This lets you have 256 /64 networks on your LAN.

Strange, my DUID is persistent across reboots and reconnects. It could have something to do with David_W patch https://forum.pfsense.org/index.php?topic=105002.0

Captive portal blocks all IPv6 at this time. No immediate plans to add support for it.

Actually, it looks like the setup is ok, your tcpdump is showing ping going out and replies coming back on WAN interface, thanks that helps troubleshoot!

What version of pfSense are you running?

If <2.2.x have you enabled IPv6 processing (System -> Advanced -> Networking -> Allow IPv6)?

Make sure your IPv6 prefix isn't in the IPv6 bogons space.  Either uncheck Bock bogons networks on WAN interface, or Diagnostics -> Tables -> bogonsv6 and make sure its not in the list (or its parent subnet), and if yes, updates bogons list, and if still present, then yell at your ISP.

You can also set Status -> System Logs -> Settings -> Filter Descriptions -> Display as column to find out what rule is dropping the traffic.  If it is the default deny rule, then there is a problem in your policy.

Second, your inbound rule only allows ICMP to the WAN address.  IPv6 by nature allows full routability, so you might want an inbound ping rule on WAN for testing.  It also might allow unsolicited pinging, but that can be controlled by limiting the valid destinations.

Action: Pass
Interface: WAN
TCP/IP Version: IPv6
Protocol: ICMP
IPCMPv6 type: Echo request if you want to allow inbound pinging, or Echo reply if you're trying to diagnose non-responses.
Source: any
Destination: LAN net or host alias

Don't think so, no.

Don't know what to tell you. Use HE as has been suggested. TWCs "Native IPv6" sucks.

You might try calling them and asking for a static IPv6 PD.

You'll get "eye pee vee what?" but it's probably worth a try.

Ok thanks just read the support doc time to get learning and playing windstream thinks they might be able todo native IPv6 by 2017

Okay, while investigating this issue I found a very interesting coloration between the dropped packets and when the router is performing an RA.

I've also noticed the stated router lifetimes are quite low, at 60 seconds, with 20 seconds for the rdnss, which will increase the number of RS on the network, which increases the number of RAs, which may explain, if there is a relationship here, why the packet loss can get so high.

It depends on the circumstances. In this case in a datacenter environment, or in any business class Internet connectivity situations, the ISP can be confident there will be a router or firewall on the interconnect to them. Where that's the case, it's fine to use a longer prefix.

There is something to be said for limiting the possibilities for NDP exhaustion. Surprises me to see "mitigated with reasonable firewall rules" from Owen DeLong, given his background at he.net and other service providers. Maybe it's just missing context. For an end user, yeah for sure, no problem with reasonable firewall rules. For ISPs, no, you have no filtering of that sort at all as an ISP. NDP exhaustion is only relevant in the context we're discussing here for the ISP's side (unless something inside your network is scanning out to your WAN subnet).

@infinityz:

Check " Send ipv6 prefix hint" then reboot your appliance, it should work

That worked great, thank you!

"Config: PPPoE WAN connection with native /48 IPv6"

So you have a /48 routed to you??  Why would you be using track on lan side then?

I would really suggest you understand how ipv6 works before trying to deploy it..  So do you have a /48 actually routed, or does your wan interface get a prefix of /48 address?  That doesn't sound like a correct sort of deployment??

I would use /64 out of that /48 and put them on your lan, you can then setup RA and or dhcpv6 how you want it to make sure your ipv6 clients discovery and or get assigned the ipv6 nameserver(s) you want them to use.

Same problem here, LAN won't get any ipv6 address. Radvd gives same error over and over again. P.s. WAN works just fine. PFsene can ping and traceroute over ipv6.

Jan 2 12:17:29 radvd[14977]: IPv6 forwarding seems to be disabled, but continuing anyway. Jan 2 12:17:29 radvd[14977]: IPv6 forwarding setting is: 0, should be 1

With the /60, you could set up a second network (i.e. for guests to your home) and allocate a /64 for that network… I'd say you could use a third /64 for any servers, if you wanted to keep them separate from your LAN, but I know Comcast  looks down upon running servers (unless you happen to have their 2Gb fiber service). You could also delegate a block to a downstream router... so if you happened to be in a situation where you have a roommate, you could delegate a /64 or /63 to them to keep their stuff separate from yours.

Hi cmb,

I configured only a few things – all other options are in default.

Configured:

WAN (hn0): Static IPv4, Static IPv6 (in unique local fd00::/8 range) + gateway to another IPv4 / IPv6 router

LAN (hn1): Same, without GW

NAT: Disabled

FW: Pass all IPv4/6 on WAN and LAN (I’m building testing environment so security isn’t my concern right now and I’m going to add rules later)

DHCPv4/6 and Router Advertisement: Disabled

DNS Resolver: Disabled

basically – it’s just a router…

Windows Servers that are in several subnets and should communicate each other get IPv6 addresses from pfSense. That’s problem since Windows Servers (their interfaces are in default so RA is enabled) have configured static IPv4 and 6 (fd00::/8).

When radvd is up then Windows Server gets another IPv6 and I can see lease in "Status: DHCPv6 leases" section. Windows Server then tries to communicate with another in different subnet using IPv6 from DHCPv6 and that’s not possible since another router doesn’t have correct static route (IP from DHCPv6 has different subnet).

@Alex:

@David_W:

Choose DHCP6 and configure it for Prefix Delegation only. You will get an IPv6 address for your WAN interface via SLAAC if your ISP supports SLAAC.

If you are using PPPoE for your WAN, you might find the patch I posted yesterday in the IPv6 forum to be helpful.

Did you need to use that patch for your Zen connection or is it only a problem with certain ISPs implementations?

That patch addresses two issues in pfSense.

Firstly, the interface ID is usually random on the first connection after boot. When SLAAC is in use, as in Zen's IPv6 implementation, this leads to a random lower 64 bits of the WAN IPv6 address. The patch is imperfect, as it does not result in the same interface identifier following a disconnect and reconnect, though I will address that in time and update the patch.

Secondly, it prevents dhcp6c from being started twice on the same connection, which results in significant brokenness when it occurs. This issue seems to affect a relatively small number of people using 2.2.5 and 2.2.6, but it needed addressing. I haven't personally experienced this issue, but it's something of a show stopper for those affected by it.

@chamont:

neiltiffin, Do you have Comcast business or residential? I can't seem to find a straight answer (yet) on < /64 for residential customers (which I am).
Monty

Residential and it is hit and miss.  Checked it today an no IPv6.  Uptime 47 days.  Rebooted and IPv6 is back.

A workaround is to use SLAAC as IPv6 Configuration Type on the LAN. Works well.

Even tho i seem to be talking to myself, i give it a go (again).

Had a 7 day "streak" without any incidents, but the previous night i had a WAN disconnect according to the logs. This in turn lead to me loosing ipv6 a few hours later. Now, i wonder, could it be that whenever i loose WAN connectivity something "hangs" in that RA wont broadcast/refresh my prefix until i either reboot or restart wan? (By saving wan settings and applying without actually changing anything).

It could be just a coincidence that i had 7 days uptime on WAN now vs. before changing nic's, as it usually happen at night (2 pm ish), which COULD indicate some ISP maintenance or something like that. Anyway, the thing is that it does seem as when WAN link goes down, something weird will happen with my prefix.

I just upgraded to 2.2.6 today, but havent really had the chance to study the patchnotes yet, so not sure if this is something that is specifically addressed there tho.

C

HowTo (In Dutch) for the scenario (pfSense, XS4ALL and IPv6) can be found http://blog.firewallonline.nl/how-to-en-tutorials/xs4all-pfsense-opnsense-ipv6/.
Using it myself and working ok. Beware that there is a nasty bug: https://redmine.pfsense.org/issues/2762 preventing normal IPv6 usage with pfSense (slow loading sites).
That is why I use 2.3 alpha.

The only difference with my scenario is I skipped out de FB and working with VLANs on WAN side.

To reduce potential problems: use MTU=1492 and MSS=1472 on WAN Interface

For that issue in particular, apinger has been replaced with dpinger in 2.3, and that's something we're in the middle of working on right now. So not something we'll pursue with apinger since it's gone in development versions. We'll make sure that scenario works in 2.3.