@gadams999:

Do you have a Comcast provided router or your own? My SMC router is only giving /64 PD's. I think customer routers/modems are getting /56's according to Comcast, but still collecting info.

Any device being used as a MODEM (either leased or owned) can have whatever router is connected request whatever prefix size is available based on your class of service (residential /60 or business /56).

Any device being used as a GATEWAY - a modem and router combined into one unit - will only likely request a /64. If a GATEWAY device is put into BRIDGE MODE (some allow you to do this in the web-based GUI, some require calling Comcast), this essentially makes it function similar to a MODEM, and your own router can request whatever prefix size is available based on your class of service.

Comcast has been moving away from renting regular modems, and mostly rents gateway devices now. This has allowed them to raise their rental fees ("We're renting you more than just a modem now, we're renting you a modem AND router!") as well as have some management control over the router portion.

Hi!

I experienced the same problems. I was able to fix this with the attached patch. I'm not sure but probably we should file a bug report.

The problem is that tcp resets get filtered as the 'pass out' rule for  the firewall itself is limited to TCP SYN pakets. However I still receive no ICMPv6 unreachables if i'm trying to reject IPv6 udp traffic.

Here the patch:

diff --git a/filter.inc b/filter.inc index c49403a..a4e3c45 100644 --- a/filter.inc +++ b/filter.inc @@ -2854,8 +2854,8 @@ EOD;         $ipfrules .= << <eod<br># let out anything from the firewall host itself and decrypted IPsec traffic -pass out inet all keep state allow-opts label "let out anything IPv4 from firewall host itself" -pass out inet6 all keep state allow-opts label "let out anything IPv6 from firewall host itself" +pass out inet all flags any keep state allow-opts label "let out anything IPv4 from firewall host itself" +pass out inet6 all flags any keep state allow-opts label "let out anything IPv6 from firewall host itself" EOD;</eod<br>

Cheers

If you're getting a WAN IPv6 address and a LAN prefix via DHCP…

The IPv6 setting for your WAN interface should be set to DHCP.

On the LAN interface, you should set your IPv6 setting to Track Interface, then in the IPv6 section select WAN as the interface to be tracked. If you're getting a /64 prefix from your provider then the field below should be 0.

It appears to be working now.  All I did was go into the LAN interface in the interfaces section of pfSense, (changed nothing) clicked save, and then did the same on my WAN.

As I said, consistently inconsistent .

@kejianshi:

You will like it.  Too bad its not replaced IPV4 significantly yet.

Looking forward to it …. might be ready to retire when it finally become mainstream.

Was afraid of this answer. Yes, it´s a good thing - for me the admin. Not sure, my users will appreciate as much as I do.

Thanks
    Martin

I persuaded my colocation service provider to allocate a range of IPv4's to me so my panic is over.
I even considered buying a /24 range of IPs, but that would cost around £2100 which didn't strike me as fun.

I'll test IPv6 slowly - seems to me we're a long way from actually using IPv6 in Europe. Probably decades.

I'm really freaking out here.
This Fritzbox doesn't do PPPoE Passthrough with current firmware 6.something.
My other modem doesn't sync and now I'm pissed with this crappy software / hardware.

Seems like I need even another Modem.

It's my understanding the broadcast are gone in IPv6 so you need to specify your router (Ra) in ipv6 in the absence of a dhcp server. That way devices will know their gateway. I wouldn't advertise my router on the wan and but could be missing something.

@Derelict:

DHCPv6 is out because you can't set up DHCPv6 on a dynamic interface, which a "Track Interface/WAN" is.

Because you can't get into that menu, you can't set any RA characteristics for that segment either.

There is a way to run DHCPv6 on a dynamic LAN interface.  It is probably considered unsupported and exploitation of a bug.  But, mine has been running this way for over a year.  This is with 2.1.x

Configure your LAN for a static IPv6 address (just make something up).

Enable DHCPv6 Server/RA.

Go back and change the LAN interface to dynamic with WAN Tracking.    It will prompt you to disable DHCPv6 Server.  Do so and then finish the LAN interface configuration.

config.xml will be left with a remnant like …

<dhcpdv6><lan><ramode>assist</ramode> <rapriority>high</rapriority> <rainterface><radomainsearchlist><range><prefixrange><defaultleasetime><maxleasetime><netmask><failover_peerip><domain><domainsearchlist><ddnsdomain><tftp><ldap><nextserver><filename><rootpath><dhcpv6leaseinlocaltime>yes</dhcpv6leaseinlocaltime></rootpath></filename></nextserver></ldap></tftp></ddnsdomain></domainsearchlist></domain></failover_peerip></netmask></maxleasetime></defaultleasetime></prefixrange></range></radomainsearchlist></rainterface></lan> 4) The DHCPv6 Server will continue to run and hand out address on the dynamic IPv6 network.  To make any changes to the DHCPv6 Server/RA you need to directly edit the config.xml. **Caveats** + I have not tried to make a lot of edits to the config,  have just let it run on "auto-pilot".  No advanced configurations. + This is apparently "unsupported" and may stop working at anytime, due to code changes to the base system. + Not recommended to production environments.  **Other** This explains why I noticed this behavior:  https://forum.pfsense.org/index.php?topic=83534.0 It is possible that this behavior lead to major problem when I upgraded to 2.2-BETA:  https://forum.pfsense.org/index.php?topic=83256.0</dhcpdv6>

Hey guys,

Thanks for your help.
I did exactly what you described but hdas Addition was the missing Piece and got me on track.

It is now working as I thought it has to be and similiar to my second Fritz.box.
I'm playing around a bit and will come back if I have more questions.

Thanks again.  :D

Here's the post that was published on the account's main news feed:

Authentication updates
[January 31, 2014]
In order to improve account security, some changes have been made to how tunnel endpoint updates are authenticated.

Tunnels made after this post now are configured with an "Update Key" (under the "Advanced" tab on the tunnel information page), which is used instead of the general account password when performing automated updates via either the https://ipv4.tunnelbroker.net/ipv4_end.php or the /nic/update (Dyn-alike) mechanisms.  Do not MD5() this value before use.

When an "Update Key" exists, the account password will not work for updates on that tunnel.  Existing tunnels can set an "Update Key" to take advantage of this new mechanism.

Thank you for updating the docs! :)

@Satras:

Who needs IPv6 right now ? I just want to be prepared and start my first tests with it.
I won't get a 2001 or similar public Network for various reasons.

So still the questions, how do I configure it to work now ?

As I can see you're running a german Windows.
So whats your Provider right now?

Several Cable Providers and Telekom can give you IPv6 prefix to get your stuff runing.

What the others tried to tell you. There are some Options via Tunneling but right now  what do you have and what you done, is creating an "internal" Network with FDxx adresses also known as ULAs (unique LOCAL adresses).

These adresses where invented as replacement for site local adresses and as a Transition technique and These adresses are designed not to be routable.

You Need a tunnel Broker which is able to encaplsulate IPv6 through IPv4 or the mentioned ISP with IPv6 UGA prefix (unique GLOABL adresses, similiar to IPv4 public adresses).

I'm prepraring a Video tutorial series in english and german to explain all these basics and walk trough the processes.

if you interested stay tuned and give me some Feedback and Inputs.
call for ideas is open. ;)

How often are you losing IPv6 connectivity/routing? I wonder if it's the same problem I am seeing with my LAN clients losing ability to route IPv6 to and from internet every few days. I thought I had checked the default route, but perhaps not. Next time it happens, I will check what the RAs are doing.