IPv6

[GreyGeek]

For the last five or so years I have been using the SIXXS IPv6 tunnel. It has been good ... until about two weeks ago. That's when I noticed that my "apt-get update" command was hanging on the first line. It didn't take long to find the cause -- my IPv6 tunnel was not functioning. Using "sudo aiccu stop && sudo aiccu start" didn't help. A visit to the website revealed that my tunnel was down. They knew about it but didn't know when it would be back up. Two weeks later, earlier this morning, I did something about it. I removed aiccu and went to the Hurricane website and activated a tunnel through their service. It took all of three minutes. All I had to do was unblock the ICMP in my firewall and run the following code:

ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::xxx.xxx.xxx.xxx (redacted)
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:(redacted):2/64
route -A inet6 add ::/0 dev sit1

and I was in business. I didn't need to install a service.

My IPv6 connection is the default and is, like SIXXS was, seen as native.
I added the code to /etc/rc.local

[ronw]

Your ISP isn't handing out IPv6 addresses yet?

I assumed Comcast would be one of the last to do anything, and that if I had one most of the world probably did.

ronw@gazp6:~ $ ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2601:44:c300:347d:290:f5ff:fec8:3040/64 scope global noprefixroute dynamic 
       valid_lft 254416sec preferred_lft 254416sec
    inet6 fe80::290:f5ff:fec8:3040/64 scope link 
       valid_lft forever preferred_lft forever

[GreyGeek]

Your ISP isn't handing out IPv6 addresses yet?

I assumed Comcast would be one of the last to do anything, and that if I had one most of the world probably did.
....

I wish!
TimeWarner talks a good game but drags their heels as long as possible, and, they seem to be moving toward a configuration process that leaves the user out of the process of setting up an Internet network. As the author of the link wrote:

In the meantime, the best workaround is to use dual-stack (IPv4/IPv6) on all hosts on the internal (local) network and prefer using IPv4 for all local traffic (ie. use IPv6 only when addressing Internet hosts). I don't like this solution because it encourages the continued use of IPv4 and underscores the futility of a mass-deployment of IPv6. It additionally gives equipment manufacturers an excuse to not support (or not fully support) IPv6 in new products or updated firmware. Adopting IPv6 in the home motivates manufacturers to move forward with IPv6 support.
Finally, the proper way to deploy IPv6 prefixes to the customer is to assign them on a per-customer basis when establishing service rather than dynamically from a prefix pool. This will require ISPs to provide this information to customers during service establishment (through the customer service portal would be ideal), and the CMTS (or similar on the DSL and FTTx side) to be able to properly handle routing the assigned prefix to the customer's CPE.

Which is what I am doing. Even with IPv6-in-IPv4, my IPv6 speeds are as fast or faster than IPv4. IPv6 is set as my default.

[GreyGeek]

IPv6 through TWC in Lincoln is defective ...

It
It looks like I'll have to wait until around the 1st of September to get full IPv6 service in Lincoln, NE

What are the qualifications and skills of the people who installed and maintained the DHCPv6 architecture that it takes three months to fix? They must be using one team and ferrying them around to all the locations that are busted.
http://forums.timewarnercable.com/t5...eas/td-p/76462

TWC-PhilB
Community Manager


IPv6 Issue Identified in Select Market Areas

06-09-2015 11:42 AM
There is currently a DHCPv6 architecture issue that is limiting full IPv6 support in a small number of our market areas.
Our engineers are aware of the issue and are actively working to deploy a new architecture, however we do not currently have a timeline for completion.

Areas affected:

Kansas City (KS and MO)
Lincoln, NE
Richlands, Tazewell, Keen Mountain, and Grundy VA
Enterprise and Dothan, AL
Pullman, WA
Idaho Falls and Coeur d'Alene, ID
Yuma, AZ/El Centro, CA
Clarksburg, WV
Central Kentucky
Western Kentucky
Terre Haute, IN

We are hopeful that this will be resolved soon, and will post updates as we receive them.

Thanks

TWC-PhilB
Community Manager
Time Warner Cable

TWC-PhilB
Community Manager

Re: IPv6 Issue Identified in Select Market Areas

Monday
FYI, the latest estimate I've received on resolution of this is issue is within the next 4-6 weeks.

Thanks
TWC-PhilB
Community Manager
Time Warner Cable

[MoonRise]

As far as I know not many have switched yet to IPv6. I know here in SC they have not. It's sad when it's known that IPv4 is out of numbers and there is no move to IPv6.

[GreyGeek]

My SIXXS tunnel, which has been down a couple weeks, is back up. The SIXXS tunnel is much faster than the Hurricane tunnel, and generally is faster than my IPv4 connection.

[SteveRiley]

Earlier this month, some researchers discovered (pdf) that IPv6 leakage is a pervasive problem with many public VPN providers:

This paper thus investigates the
claims of privacy and anonymity in commercial VPN services.
We analyse 14 of the most popular ones, inspecting their inter-
nals and their infrastructures. Despite being a known issue, our
experimental study reveals that the majority of VPN services
suffer from IPv6 traffic leakage. The work is extended by de-
veloping more sophisticated DNS hijacking attacks that allow
all traffic to be transparently captured.

Their discoveries include:

• Many of the services use outdated technologies such as PPTP (with MS-CHAPv2), which can be broken using brute-force attacks.
• Most of the commercial VPN clients allowed data leakage in dual-stack networks (i.e., those supporting IPv4 and IPv6).
• Using various applications, websites, and operating systems, the researchers determined that traffic was exposed to public detection.
• With IPv6 traffic leaking outside the VPN tunnel, it could expose the user's browsing history even on IPv4-only websites.

The recommended fix? Disable IPv6 when using a public VPN.

IPv6 is still so new to so many people, despite being nearly 17 years old. People will make rookie mistakes. IPv6 is not automatically "more secure." What makes a stack secure? Not its address size. Security comes from encryption and digital signatures, which are actually features of IPsec. IPsec is mandatory in IPv6, but optional in IPv4. Amusingly, there are more IPv4 implementations of IPsec than IPv6! (source)

[GreyGeek]

Great info, Steve. Recently I've been reading about leaky VPN's on IPv6 connections.

I've also read lots of claims that VPN's are more secure that TOR, which gives disclaimers about its own security, and faster as well because the translations to and from anonymous network addresses take place at the first and last nodes and not at every node along the route. A VPN maybe faster but it seems to me that it reduces the number of points an intruder would have to attack. Also, a VPN's security can be no better than that of the vendor supplying the service. If they lack integrity or are forced by governments to install apps like "Legal Intercept" then a VPN is worthless.

[dtr]

Interesting. However I've completely disabled IPv6 since my ISP hasn't implemented it yet for residential customers.