![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
IPv6 additionals
May. 17th, 2010 08:36 pmSome folks (looking at you, ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
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.
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.
Quick summary of the $JOB as of 2/12/2010
Feb. 12th, 2010 05:08 amI have had some major, incredibly important deadline pushed up by 5 days. We were supposed to disconnect the old datacenter on 2/20, and yesterday I found out we're turning the power off to the old facility on 2/15. Joy.
I was at the office from 1930 last night until 0400 this morning doing the first phase of a circuit migration (using AT&T's "Opt-E-MAN" WAN/Ethernet service). What should have been simple went really sideways and we encountered some significant problems. The irony of it all is that it turns out I had completely overthought the situation and made a simple, elegant solution vastly more complex than it needed to be. When I returned to the simple solution everything started working. Thankfully I realized this at around 0240 and reeled everything back in, successfully completing that stage of the trasition. Hooray for smoke breaks and my coworker NF who let me bounce thoughts off of him (and watched me draw with a whiteboard marker on a non-whiteboard surface. I'll be staring at that for the next 15 years).
Right after I fixed things up on the Opt-E-MAN I got some news from the good folks over at Hurricane Electric's IPv6 tunneling service that made me happy: the tunnel I had requested to $EMPLOYER's router should be fixed (it hadn't been working before). When I tested things out, it was! Not only did I have IPv6 connectivity on the most rudimentary level, my BGP session for IPv6 was also working! After I got home at around 0400, I couldn't sleep (surprise surprise, given the events of the evening) so I settled into the office and did some tinkering to see if I couldn't get $EMPLOYER's IPv6 allocation to be announced out to the global Internet (what little of it that speaks IPv6, anyway) via the Hurricane Electric tunnel. It took a bit of fiddling but eventually I was able to successfully announce 2620:0:1400::/42 out of my Juniper M10i router into the IPv6 Internet (all hail the MultiServices PIC).
So, over a year after I got $EMPLOYER a provider-independent IPv6 allocation, it is finally being announced into the Internet (from ASN 22734). The next step? I probably need to get the traffic through the firewall....
I was at the office from 1930 last night until 0400 this morning doing the first phase of a circuit migration (using AT&T's "Opt-E-MAN" WAN/Ethernet service). What should have been simple went really sideways and we encountered some significant problems. The irony of it all is that it turns out I had completely overthought the situation and made a simple, elegant solution vastly more complex than it needed to be. When I returned to the simple solution everything started working. Thankfully I realized this at around 0240 and reeled everything back in, successfully completing that stage of the trasition. Hooray for smoke breaks and my coworker NF who let me bounce thoughts off of him (and watched me draw with a whiteboard marker on a non-whiteboard surface. I'll be staring at that for the next 15 years).
Right after I fixed things up on the Opt-E-MAN I got some news from the good folks over at Hurricane Electric's IPv6 tunneling service that made me happy: the tunnel I had requested to $EMPLOYER's router should be fixed (it hadn't been working before). When I tested things out, it was! Not only did I have IPv6 connectivity on the most rudimentary level, my BGP session for IPv6 was also working! After I got home at around 0400, I couldn't sleep (surprise surprise, given the events of the evening) so I settled into the office and did some tinkering to see if I couldn't get $EMPLOYER's IPv6 allocation to be announced out to the global Internet (what little of it that speaks IPv6, anyway) via the Hurricane Electric tunnel. It took a bit of fiddling but eventually I was able to successfully announce 2620:0:1400::/42 out of my Juniper M10i router into the IPv6 Internet (all hail the MultiServices PIC).
So, over a year after I got $EMPLOYER a provider-independent IPv6 allocation, it is finally being announced into the Internet (from ASN 22734). The next step? I probably need to get the traffic through the firewall....
Network geekery
Sep. 7th, 2008 07:48 pmThanks to the coolest little firewall appliance on the market, SixXS, frostyw, nius, the help of several websites and tutorials in addition to a lot of patience... I now have IPv6 service on my wired and wireless networks at the house via an IPv6 tunnel. I had to force an IPv6 address onto my laptop and manually set the default gateway to point to the IPv6 address on the SSG-5's wireless interface, but once I did I was able to see IPv6 websites. I'm also pleased that my SSG-5 is reporting IPv6 packets flowing through it (I have the firewall's policies set to log pretty much everything IPv6). I really did enjoy visiting http://www.WhatIsMyIPv6.net/ and seeing my new, much-more-complex address come up on the page as confirmation.
So now my house is 2001:4978:1a0::/48 on the IPv6 Internet and I'm posting from my wireless workstation with IP 2001:4978:1a0:200:201d:e0ff:f340:7adb. Best of all, it is entirely without NAT! Speaking as a user and as a network engineer I absolutely hate NAT.
Now I just need to figure out how to make stateless autoconfiguration or DHCPv6 work so I don't have to keep executing obscure Windows CLI commands....
[Edit @2013:] Or, if WhatIsMyIPv6 is giving you trouble, you can try http://www.runningipv6.net/what-is-my-ipv6-address.php
frostyw, nius, the help of several websites and tutorials in addition to a lot of patience... I now have IPv6 service on my wired and wireless networks at the house via an IPv6 tunnel. I had to force an IPv6 address onto my laptop and manually set the default gateway to point to the IPv6 address on the SSG-5's wireless interface, but once I did I was able to see IPv6 websites. I'm also pleased that my SSG-5 is reporting IPv6 packets flowing through it (I have the firewall's policies set to log pretty much everything IPv6). I really did enjoy visiting http://www.WhatIsMyIPv6.net/ and seeing my new, much-more-complex address come up on the page as confirmation.So now my house is 2001:4978:1a0::/48 on the IPv6 Internet and I'm posting from my wireless workstation with IP 2001:4978:1a0:200:201d:e0ff:f340:7adb. Best of all, it is entirely without NAT! Speaking as a user and as a network engineer I absolutely hate NAT.
Now I just need to figure out how to make stateless autoconfiguration or DHCPv6 work so I don't have to keep executing obscure Windows CLI commands....
[Edit @2013:] Or, if WhatIsMyIPv6 is giving you trouble, you can try http://www.runningipv6.net/what-is-my-ipv6-address.php
