I would be cautions about IPv6. Bill and Rob brought some very good points. Also, the ISP Hurricane Electric offers a free certification course if anyone wishes to further pursue IPv6. With ransomware, I advise keeping regular timed cloud backups or regularly updated offline copies. The local network of my operations center at work was hit by an engineer hitting a link. Due to our 1Gbps connection (and that he had the drive set to mount persistently, which is very common, especially in Windows), our file server was encrypted in less than an hour. Restoring the drive was my only option. We only lost data the engineer didn't save on the file server and recent edits to files-in-use. *Lastly, RULE No. 1 - under no circumstances pay a ransomware developer, and RULE No. 2 - if you weren't prepared for that, remember Rule No. 1. There is still 0% guarantee that the developer will in fact provide you a key for the money spent, and in some jurisdictions, paying a criminal is a crime.* I recall when I first started working with AMPR and IPv6, I used a DD-WRT router with IPv6 routing daemons, etc; but it did not have ip6tables. Other routers had no way of manipulating ip6tables in the GUI. This meant you had to figure out how to make a persistent IPv6 firewall script, if possible. Over time, I've found various quirks with IPv6 implementations in devices. I believe some of the earlier versions of OpenWRT also lacked ip6tables installed by default (meaning, it was not installed unless it's made a dependency of the IPv6 packages). In some, RA worked, but DHCPv6 was not implemented. In some earlier PCs, IPv6 privacy is not implemented at all, or (as in Ubuntu) not enabled by default. It was interesting how my search for an IPENCAP-capable router aligned with my search for an IPv6-ready router as well. I currently have a Verizon FiOS device that was provided by my ISP, and I noted in the past that they can somehow access my device (and remove the IPENCAP forward rule) and in addition that IPv6 appears unfiltered, or leaves various ports open (none of which are documented). Lastly, there is no IPv6 firewall to edit in the GUI; and they offer no documentation on navigating the CLI of their device (it's probably an added feature only to allow SSH tunneling and perhaps as a failsafe for resetting and rebooting the device). Luckily, I provide my IPv6 tunnel, and it's not via my ISP. I solved this by placing my LEDE as the border router with my ISP, the Verizon device is downstream (with IPv4 IGMPproxy enabled on its interface, something else not noted in Verizon's Bring-your-own-device documentation). In fact, Verizon never notes that they use IGMP whatsoever, you may wish to check if your devices are sending multicast requests upstream to you ISP. It appears they send firmware updates and television listings via this method. 73, - Lynwood KB3VWG

On Sun, 14 May 2017 12:24:10 +0200, Rob Janssen <pe1chl(a)amsat.org> said: Some consumer quality routers assume that all LAN addresses *MUST* be in an RFC1918 range, e.g., 192.168.n.n. The routers usually allow the user to set the third octet, but not the first or second, and they reserve the last octet for DHCP and/or local fixed addresses. IIRC, most allow the user to set the subnet mask's last octet too, but that's as much flexibility as users get. Sometimes, the same restrictions apply to the other devices on the LAN, especially printers, and so it's often easier to put a 44net address on the "WAN" side of a router and do NAT. Bill, W4EWH