?

Log in

No account? Create an account
entries friends calendar profile Feren's dART gallery Previous Previous Next Next
IPv6 additionals - Paint It Black
Living the American dream one heartbreaking piece at a time
feren
feren
IPv6 additionals
Some folks (looking at you, hakeber) may remember this post from 2008 wherein I delivered IPv6 to my network at home.

My poking and prodding with the "next generation" protocol has continued over the following two years. Today I was trying to reach my home machine's IPv6 address from my IPv6-enabled machine at work. I've found a few things that have vexed me. I'm not the first person to find them or post the work-arounds, but I'm probably the first person to put them all together in one place so you can just get all the pain out of the way at once instead of stumbling from one obstacle to the next.

First, I found something important to note about IPv6 on Windows Vista/Windows 7: both Windows Vista and Windows 7, when in stateless autoconfig, use "privacy extensions" (specified in RFC4941) by default rather than EUI-64 addresses (deriving the host portion of the address by using the NIC's MAC as per RFC2464 and RFC2373). What this means is the OS automatically generates random interface IDs for every attached IPv6 interface and uses them for privacy addresses. This is great for "privacy" of users who are primarily content consumers, browsing the web. Every few hours or days they get an entirely new IPv6 address (from their subnet) and thus maintain a degree of anonymity (which completely ignores spyware, tracking cookies and the like but I won't go into that here).

The downside of this great privacy feep is that if I have a machine I want to connect to over IPv6, I'm unlikely to know from day to day what address it has (temporary) nor can I derive what to attach to (public) because they're both scrambled and in no way directly related to the NIC's MAC. Yes, in addition to the "temporary" addresses (used for outbound connections to global addresses) Microsoft has included a "public" privatized address, similarly scrambled but at least not prone to rotation.

Since I have no privacy issues to worry about at home, there's a relatively easy fix that gets rid of all this Security Through Obscurity and gets me back to sane, predictable behavior:
* Open an elevated privilege command prompt
* Disable the "temporary" outbound IPv6 addresses with: netsh int ipv6 set privacy=disable
* Disable non EUI-64 IPv6 interface identifiers with: netsh int ipv6 set global randomizeidentifiers=disabled store=persistent

The second thing I found was, even after configuring my IPv6-over-IPv4 tunnel and firewall to pass traffic through, I still couldn't ping my IPv6 address. What I found was that even though "core IPv6 networking" was permitted through the Windows Vista firewall by default, ICMP echo requests weren't passing properly and were being dropped. In the case of my personal workstation at home, the offending Firewall Policy was the "Public" one. I ended up creating a custom policy to do this. Note that this cannot be done via the basic Windows Firewall interface, that'd be too simple. No, instead I had to:
* Start
* Administrative Tools
* Windows Firewall with Advanced Security
* Inbound Rules
* New Rule
* Custom
* All Programs
* Protocol Type: ICMPv6
* Any IP / Any IP
* Allow the Connection
* Apply to Domain, Private and Public (Though for me only Public was the important one)
* name and describe it

The downside is ANY ICMPv6 packets can get through, beyond the echo request and reply I wanted. I'll likely have to circle back to that.

Tags: , , , , ,
Current Location: Z'ha'dum
Current Music: Dr. Steel - The Singularity | Powered by Last.fm

2 thoughts or Leave a thought
Comments
steelhelix From: steelhelix Date: May 17th, 2010 09:50 pm (UTC) (Link)
In my opinion, the only real limiting factor holding back IPv6 is the consumer grade OSes that M$ and Apple put out. Both have serious issues that their simplistic interfaces can't fix without work-arounds. Linux is usually a more complicated interface on it's own, so while it has issues, they're more a matter of user knowledge than true lack of feature.

Most hardware out there seems IPv6 compliant these days, and it's really going to become a necessity soon for major systems to start adopting the protocol, I'm wondering why it's been so slow a process.
feren From: feren Date: May 18th, 2010 08:03 pm (UTC) (Link)

Mixed bag o' trouble

It's a many-splendored ball of suck. I do not claim to be an expert like Randy Bush but my own experiences at home and in the professional field, paired with near-obsessive reading of NANOG, has given me some insights.

  • There is a chicken&egg sort of problem going on -- providers won't take IPv6 seriously, nor deploy it seriously, until there's demand. There's no demand for it because it hasn't been deployed. Right now there is no "killer app" that is driving IPv6 adoption. Mostly it is nerds & the occasional government mandate.
  • Consumer support -- most home CPE doesn't support IPv6. What I use for firewalls and routing as well as for switching at home does, but it's not "consumer-grade" as it was aimed more at the small branch-office market. My actual DSL "modem," something very consumer-grade that was provided by my ISP, doesn't know thing one about IPv6 (Some consumer devices, like various WAPs from Linksys and Buffalo and friends, can have a third-party firmware hacked into them that supports IPv6. This is not to be confused with "from the factory/provider" firmware images, which decidedly do NOT support IPv6). While a very few consumer-oriented providers are doing trials with IPv6, they're the minority and they face a lot of "legacy" equipment out in the field that will need to be replaced.
  • Cost for replacement of legacy gear -- the money has to come from somewhere. If there's one thing about being a service provider in the US that I've seen, it's that being a provider is a drive towards zero-sum. People want internet, they want it fast, and they want it cheap. And they want all three, no subset of the options is acceptable. The second they think they can get a better deal elsewhere, they'll jump ship. This makes capital investment by providers extremely difficult! If they invest there's a strong risk they won't realize sufficient revenue to pay for the cost before the subscriber jumps to a different provider. Likewise, if they try to subsidize by passing the cost of the gear on to the subscriber (even in a limited percentage over a long time period) the customer will likely find the hike in cost unacceptable and jump ship.
  • Lots of FUD about IPv6, from how it will explode the cost of core routing infrastructure to how every person on the planet should receive a globally routable network allocation. Let's not forget the absence of my old "pal" NAT, which some people in the operations community view as a feature and some as a failure.
  • Lack of coherent direction -- A quick look at threads about IPv6 on NANOG, a forum full of networking experts, shows that there's nothing even close to a consensus on what needs to be done in what order or how to even go about it. Some will tell you that the protocol is a non-starter since some of its premises are broken out of the gate (using the MAC for the latter half of the IP address as I mentioned can be bypassed. The IETF ratified that the DUID can be permanently generated so the IP survives NIC swaps. Which sounds great, but can break all sorts of processes for businesses).
  • The afore-mentioned lack of supply & demand? It applies to the commercial (non-residential) ISP/NSP market as well. I have two very large transit providers serving my datacenter. Neither of them has native IPv6 transit, I have to bring everything I want into $EMPLOYER via a tunnel from the Hurricane Electric IPv6 Tunnel Broker. My third ISP, recently ditched, claimed to support native IPv6 -- when I inquired about it through no less than 4 different channels I got blank stares.


It goes on like this.
2 thoughts or Leave a thought