Yeah, for android devices is a must, they only use SLAAC.

Hey, thanks for the replies. I'll look into setting it up as a transparent firewall.

Thank you podilarius, I've turned off the default logging in the logger settings and do not see anymore ipv6 anything logging - which is what I would prefer.

@Criggie: @Criggie: I think this redmine bug is going to be related:    https://redmine.pfsense.org/issues/3357 Turns out that bug was not related.  Here's the current bug report for this  https://redmine.pfsense.org/issues/3544 SOLVED!  I don't know when the option appeared but under interface -> WAN there is now an option Use IPv4 connectivity as parent interface  [X] Request a IPv6 prefix/information through the IPv4 connectivity link So now I have full IPv6 native connectivity both inwards and outwards.

you filed it as a feature request, not a bug.. Its a BUG not a feature if dhcpv6 is running when your using dhcp-pd but you can not edit its config or even view what its handing out that is a bug not a feature ;)

Well, as pointed out before, using the same /64 on both the WAN and the LAN interface won't work, and since all you get is a /64, splitting out a sub-prefix will be problematic as well (IPv6 is really designed to use /64 as the maximum prefix size for LAN use; things like SLAAC will not work with anything longer). So, not sure what to tell you at this point.

Hi guys, So can anyone give me some idea where I should change the gateway to wan_stf as ermal suggested earlier in the thread? I'm stumped trying to find it and it's killing me thinking that I could be one single setting away from working 6RD on 2.1.2! -Will

It looks like I got it permanently fixed, my mistake was to boot up my PC "too early" when the firewall was not yet ready (I shut down the firewall and the PC when I don't need it). For some weird (or not weird) reason my PC didn't get any IPv6-address, it kept sending solicit messages according to the DHCP logs, but never sent a request message… After rebooting my PC, according to the logs it sent a solicit message, after receiving the advertise from the firewall it sent a request and got a reply with an IPv6-address and now everything is working... (so I guess it was a layer 8 error...)

Thank you!

I installed the alpha from 17th of April just now. 6RD is still not working, but it does not seem exactly the same either. A few examples: A promising log entry: php: rc.bootup: ROUTING: setting IPv6 default route to 2a01:79d:3e85:a408::213.167.115.92 But: wan_stf is gone from ifconfig, and no ipv6 config apart from fe80 (local link) addresses are seen. The IPv6 address is gone from status | dashboard | wan. These two last problems are probably related to 6rd failing on creation, I have posted this issue in https://forum.pfsense.org/index.php?topic=75707.0

OK, quick update. Previously, the LAN interface was not getting anything but the link-local IPv6 address, but after a reboot, it's now getting a /64. Machines on my LAN are also now getting addresses within that /64, so this issues seems to be resolved. Thanks again.

Bumping to see where I can resolve this issue. As a lark I install m0n0wall and setup IPv6 there. PD allocation worked, yet still no LAN traffic passing the local netgear modem. But when I did enabled IPv6 on the LAN interface, the link-local always stayed in EUI64 format. So just trying to figure out what portion of pfSense code is changing the link-local addresses to fe80:1::1:1, and how to revert back to SLAAC-style addresses.

@adler187: After changing the 'gif tunnel local address' to the IPV6 local address on the GIF and setting IPV6 to None on the interface, I got things working. Yes, that is how it should be. :)

You are indeed wrong; this is perfectly normal for IPv6. Typically an IPv6-enabled host will have a SLAAC address (generated from the NIC's MAC), a temporary address (IPv6 privacy extensions), and possibly a DHCPv6-assigned address on each v6-enabled interface, plus link-local addresses. For privacy reasons, the temporary address is what will generally be used for outbound connections (which is what those websites will see); however, you should still be reachable at the other addresses for inbound connections.

Yes, thank you. That's where I went wrong. I see it now.