@johnpoz: you shouldn't be getting a /128 on your pi…  The smallest prefix with ipv6 is /64..  And its not just linux that works that way its every OS there is that can work with IPv6.. anything other /64 is going to break all kinds of shit from working correctly.. I dusted off my raspberry pi over the weekend, and installed latest NOOBS + raspbian, sure enough it comes up with /128 in addition to /64. The /128 is the address assigned by the DHCP server; the /64, I guess it is deciding thru SLAAC on its own because of RA.  I have some android clients on the network, so need SLAAC too. radvd on pfsense 2.2.4 is set to Assisted, with the RA Subnet set to WWWW:XXXX:YYYY:ZZZZ::/64 Win2K8 DHCP server is handing out IPs in WWWW:XXXX:YYYY:ZZZZ::/64 Resolv.conf on PI ends up with Domain Controller IPv4+IPv6 IP as well as pfSense IPv6 IP, not ideal since it doesn't have any knowledge of the domain.  Strange that it ended up with the pfSense IPv6 IP because the DNS Servers entry is blank in the RA config tab. eth0      Link encap:Ethernet  HWaddr b8:27:eb:35:53:31            inet addr:10.2.95.18  Bcast:10.2.95.255  Mask:255.255.254.0           inet6 addr: WWWW:XXXX:YYYY:ZZZZ:fcef:f7d6:12c3:f393/64 Scope:Global           inet6 addr: fe80::bd6c:2ed5:a452:1eff/64 Scope:Link           inet6 addr: WWWW:XXXX:YYYY:ZZZZ:c439:ca13:15f5:31a9/128 Scope:Global           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:80378 errors:0 dropped:5856 overruns:0 frame:0           TX packets:4106 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:6121679 (5.8 MiB)  TX bytes:662612 (647.0 KiB) wlan0    Link encap:Ethernet  HWaddr 34:08:04:a0:5d:3d            inet addr:10.2.95.20  Bcast:10.2.95.255  Mask:255.255.254.0           inet6 addr: WWWW:XXXX:YYYY:ZZZZ:927a:28a4:a3e3:73f8/128 Scope:Global           inet6 addr: fe80::b69e:3850:a1d0:6935/64 Scope:Link           inet6 addr: WWWW:XXXX:YYYY:ZZZZ:d9d4:1377:f075:8c05/64 Scope:Global           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:315611 errors:0 dropped:17236 overruns:0 frame:0           TX packets:325 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:121355585 (115.7 MiB)  TX bytes:63491 (62.0 KiB)

@Vetal: So, on VPS, VPN tunnel (tun mode) is VPS end: prefix_64:8000::1/64 pfSense end: prefix_64:8000::2/64 LAN: prefix_64:8000::1001/116 DHCPv6, Router Advertisements - Managed So far, so good, everything is pingable within VPS <=> pfSense world. … ... I am testing similar setup, trying to follow https://community.openvpn.net/openvpn/wiki/IPv6 - the only sample I found so far. gateway is getting IPv6, I can ping VPS eth0 but not outside. From prefix_64:8000::1 icmp_seq=1 Destination unreachable: Administratively prohibited. net.ipv6.conf.all.forwarding is enabled. Would you mind sharing your openvpn config files?

I am told this the way IPv6 can legitimately operate. there is no problem setting up route manually in Linux on the same network: https://clients.inceptionhosting.com/knowledgebase.php?action=displayarticle&id=8 The FreeBSD variant of Linux ip commnds route add -inet6 -net prefix_48::/48 -interface vtnet0 route add -inet6 -prefixlen 0 default prefix_48::1 produces virtually the same routing table as DHCP6 (probably via routing advertisement) created one but there is no IPv6 connectivity. Update: on Little Happy Cloud CentOS 6 static IPv6 configuration looks like: cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static ONBOOT=yes IPADDR=nnn.nnn.nnn.XXX GATEWAY=nnn.nnn.nnn.1 NETMASK=255.255.255.0 IPV6INIT=yes IPV6_AUTOCONF=no IPV6_DEFAULTGW=prefix_48::1 IPV6ADDR=prefix_48:XXXX::X/64 Could anyone explain how to configure pfSense to achieve the same configuration?

Just curious, what hardware are you running comcast connected pfsense on?

While it is possible for IPv6 to talk to IPv4 (in theory) using special addresses, the reverse isn't true. You'd need a full proxy to take the requests from the IPv4 host and then issue new IPv6 requests out from the proxy itself.

Hi! Ive updated [https://redmine.pfsense.org/issues/4470](https://redmine.pfsense.org/issues/4470) after Iv seen progress with one option now available in GUI. Is there any takers, this would be huge step up to RA configurability. I would do it myself, really, but my coding skills are ermmmm well I have almost none :)

@jimp: Time to call the ISP and hope you reach someone with IPv6 experience… argll They are good but not that good… in fact not good but nice. Thanks a lot for yours lights, I'm quite relief, it's not my fault. :D I keep you inform. Librement, ryoanji

Not really. With IPv6 it's quite a bit different and geared toward privacy. You might get lucky and spot the host by its MAC address in the NDP table or catch it in the DHCPv6 leases if it didn't use SLAAC. Otherwise you have to check the client.

@David_W: Android does not support DHCPv6 and, despite many requests, the engineer responsible for this issue at Google seems implacably opposed to adding DHCPv6 support. You need to use SLAAC. If someone really needs DHCPV6 on android there is a nice client aviable on google play https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client It works fine on my Z1 compact (5.01 lolipop). Root required of course.

filed a bug: https://redmine.pfsense.org/issues/5812 fixed in 2.3 – antonio

filed a bug: https://redmine.pfsense.org/issues/5812 fixed in 2.3 – antonio

Great ! no less than 65,535 LAN's ;). Basically you don't need a WAN public address because you do not want communications with the pfSense WAN, but with a public LAN-client which is part of a public LAN.  So therefore just in a scenario for one host/PC (no router), you could utilize a /128 address…

Hi, did not work for me either…. I tried it just one time copying the mentioned configuration Don't know what the problem is - in the log file I see there : Jan 23 11:51:22 ppp: [wan] IPV6CP: LayerStart Jan 23 11:51:22 ppp: [wan] IPV6CP: state change Initial –> Starting Jan 23 11:51:22 ppp: [wan] IPV6CP: Open event Jan 23 11:51:22 ppp: [wan] IPV6CP: SendConfigReq #1 Jan 23 11:51:22 ppp: [wan] IPV6CP: state change Starting –> Req-Sent Jan 23 11:51:22 ppp: [wan] IPV6CP: Up event But  then: Jan 23 11:51:22 ppp: [wan] IPV6CP: LayerFinish Jan 23 11:51:22 ppp: [wan] IPV6CP: state change Req-Sent –> Stopped Jan 23 11:51:22 ppp: [wan] IPV6CP: protocol was rejected by peer …so, if I didn't try it myself with a FritzBox and got myself a 2003::  address, I'd say the login data isn't capable of native IPv6.... Any other hints? Cheers 4920441

@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