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

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.