IPv6: back to basics

Recently I have enabled IPv6 on my home network. My ISP – Internode – supports IPv6 for some time now, and I finally got around to purchase new router with IPv6 support. Most operating systems that I run at home (including Maemo on Nokia N810) support IPv6 too. Fast forward few weeks to the World IPv6 Day – as it happens, I have found a problem with my setup on the day when the whole world makes an effort to prove IPv6 maturity:


C:\Users\spadmin>ping ipv6.google.com
Ping request could not find host ipv6.google.com. Please check the name and try again.

C:\Users\spadmin>nslookup ipv6.google.com
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
        primary name server = 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
        responsible mail addr = (root)
        serial  = 0
        refresh = 28800 (8 hours)
        retry   = 7200 (2 hours)
        expire  = 604800 (7 days)
        default TTL = 86400 (1 day)
Server:  UnKnown
Address:  ::1

Non-authoritative answer:
Name:    ipv6.l.google.com
Address:  2404:6800:4006:802::1010
Aliases:  ipv6.google.com


C:\Users\spadmin>ping 2404:6800:4006:802::1010

Pinging 2404:6800:4006:802::1010 from 2001:44b8:78e1:1320:2d10:241c:5668:2f6a with 32 bytes of data:
Reply from 2404:6800:4006:802::1010: time=53ms
Reply from 2404:6800:4006:802::1010: time=51ms
Reply from 2404:6800:4006:802::1010: time=52ms
Reply from 2404:6800:4006:802::1010: time=53ms

Ping statistics for 2404:6800:4006:802::1010:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 51ms, Maximum = 53ms, Average = 52ms

C:\Users\spadmin>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : ACE
   Primary Dns Suffix  . . . . . . . : example.net
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : example.net

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) PRO/1000 PL Network

Connection
   Physical Address. . . . . . . . . : 00-1C-25-E7-B0-75
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2001:44b8:78e1:1320:2d10:241c:5668:2f6a(Deprecated)
   Link-local IPv6 Address . . . . . : fe80::2d10:241c:5668:2f6a%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.1.1.200(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 192.168.178.254(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : fe80::be05:43ff:fea6:127b%10
                                       10.1.1.1
   DHCPv6 IAID . . . . . . . . . . . : 167779365
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-10-3D-2B-1A-00-1C-25-E7-B0-75
   DNS Servers . . . . . . . . . . . : ::1
                                       127.0.0.1
   NetBIOS over Tcpip. . . . . . . . : Enabled





After disabling and re-enabling the NIC everything works:



C:\Users\spadmin>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : ACE
   Primary Dns Suffix  . . . . . . . : example.net
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : example.net

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) PRO/1000 PL Network

Connection
   Physical Address. . . . . . . . . : 00-1C-25-E7-B0-75
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2001:44b8:78e1:1320:2d10:241c:5668:2f6a(Preferred)
   Link-local IPv6 Address . . . . . : fe80::2d10:241c:5668:2f6a%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.1.1.200(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 192.168.178.254(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : fe80::be05:43ff:fea6:127b%10
                                       10.1.1.1
   DHCPv6 IAID . . . . . . . . . . . : 167779365
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-10-3D-2B-1A-00-1C-25-E7-B0-75
   DNS Servers . . . . . . . . . . . : ::1
                                       127.0.0.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

C:\Users\spadmin>ping ipv6.google.com

Pinging ipv6.l.google.com [2404:6800:4006:802::1011] from 2001:44b8:78e1:1320:2d10:241c:5668:2f6a with 32 bytes of data:
Reply from 2404:6800:4006:802::1011: time=53ms
Reply from 2404:6800:4006:802::1011: time=51ms
Reply from 2404:6800:4006:802::1011: time=51ms
Reply from 2404:6800:4006:802::1011: time=51ms

Ping statistics for 2404:6800:4006:802::1011:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),


Approximate round trip times in milli-seconds:


    Minimum = 51ms, Maximum = 53ms, Average = 51ms


 


Evidently the IPv6 protocol stack is left semi-functional. I admit I haven’t spent a lot of time configuring the network but for my home autoconfiguration features of the protocol are sufficient (and I was getting 10/10 scopr in the IPv6 test)


So why the global IPv6 address gets deprecated? An Internode engineer thought it was a Windows 7 bug (How to report IPv6 bug to Microsoft – Vista and 7 won’t “undeprecate” a prefix) but AVM, the makers of the router that I use apparently released a firmware update that addresses this issue (W7 ignores ICMPv6 Router Advertisments setting an IPv6 prefix from invalid to valid). Details of this issue are also discussed on Whirlpool. I’m on a test firmware that is addressing another issue with the router, so will have to report, wait and see.


I guess my point is this: the protocols are quite robust but it will take some time to shake down some implementation issues. It’s been four years since I have posted my view on the IPv6 enterprise. I stand by it.


And yes – my home network is on the Internet, without firewalls, gateways or any other masquerade.


UPDATE: Microsoft recognised irreversible IPv6 address deprecation a bug in Windows Vist, 7, Server 2008 and 2008 R2 and will release a hotfix. I have the prerelease code and tested it successfully.

More ping goodness

Strange problems with the corporate WAN? Welcome to my world. I’m a big enthusiast of ICMP diagnostics with ping (see Let there be ping!), and traceroute and pathping as well. One particular issue is quickly identifiable with stock-standard ICMP ping. Look at this output, for example:


C:\Users\spadmin>ping -n 25 dc-0001.asia.example.net

Pinging dc-0001.asia.example.net [172.25.7.71] with 32 bytes of data:
Reply from 172.25.7.71: bytes=32 time=38ms TTL=115
Reply from 172.25.7.71: bytes=32 time=20ms TTL=115
Reply from 172.25.7.71: bytes=32 time=42ms TTL=115
Reply from 172.25.7.71: bytes=32 time=48ms TTL=115
Reply from 172.25.7.71: bytes=32 time=124ms TTL=115
Reply from 172.25.7.71: bytes=32 time=33ms TTL=115
Reply from 172.25.7.71: bytes=32 time=80ms TTL=115
Reply from 172.25.7.71: bytes=32 time=31ms TTL=115
Reply from 172.25.7.71: bytes=32 time=33ms TTL=115
Reply from 172.25.7.71: bytes=32 time=32ms TTL=115
Reply from 172.25.7.71: bytes=32 time=20ms TTL=115
Reply from 172.25.7.71: bytes=32 time=22ms TTL=114
Reply from 172.25.7.71: bytes=32 time=20ms TTL=115
Reply from 172.25.7.71: bytes=32 time=21ms TTL=115
Reply from 172.25.7.71: bytes=32 time=22ms TTL=115
Reply from 172.25.7.71: bytes=32 time=23ms TTL=115
Reply from 172.25.7.71: bytes=32 time=26ms TTL=115
Reply from 172.25.7.71: bytes=32 time=25ms TTL=115
Reply from 172.25.7.71: bytes=32 time=21ms TTL=115
Request timed out.
Reply from 172.25.7.71: bytes=32 time=21ms TTL=115
Reply from 172.25.7.71: bytes=32 time=20ms TTL=115
Reply from 172.25.7.71: bytes=32 time=35ms TTL=115
Reply from 172.25.7.71: bytes=32 time=36ms TTL=115
Reply from 172.25.7.71: bytes=32 time=26ms TTL=115


Obviously there’s packet loss, not a good sign ever. But the other line is out of ordinary and signifies not just congested link or faulty cable. That’s the line where the return TTL is different from any other TTL. That means that ICMP echo response took different route, not the same as the other 23 packets that were returned. Which, in turn, signifies a problem with WAN routing infrastructure. Although IP, the Internet Protocol, was designed to sustain full scale attack affecting communication lines and changing routes are standard, that shouldn’t occur on a normal day on your corporate network.


There’s one more thing. Check out Smokeping. It’s ping monitor on steroids – something you really need in very dynamic and partially stable environments. And it’s free, as in free beer.