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

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.