IPv6 Day

[Snowhog]

No color, so IPv4 here.

[vinnywright]

if you want a cute way to see if you have IPv6 connectivity open telnet and go to towel.blinkenlights.nl if you get black and white you're IPv4 if color IPv6 he he

VINNY

[SteveRiley]

A number of transition technologies will be in place for a few years to ease the migration from IPv4 to IPv6. It isn't possible to handle all cases with only one kind of tunneling or encapsulation mechanism because it's necessary to deal with a variety of situations. In any given situation, a client might be IPv6 capable but a server might not. The converse might also occur. Clients, or servers, might be behind NAT gateways. These, and other, cases require transition technologies that are designed for the specific connection characteristics.

Wikipedia covers all of these. Some, but not all, are mentioned in the general IPv6 transition mechanisms article. The column on the right side of that page contains links to individual pages describing all transition technologies, including Teredo.

[Snowhog]

What benefits does one gain by installing miredo? Should one install it?

[GreyGeek]

Your're right, it isn't that Google isn't returning to IPv4, what they said and what I should have wrote is that they aren't turning off their IPv6 facilities or websites. I was able to see their IPv6 DNS.

I was doing all my testing with miredo installed, which explains the appearance of the unlinked "Teredo" device. Having Teredo tunneling activated created a problem with my internet connection, which would hang until Teredo timed out and fell through to the IPv4 connection. During those hang periods my mouse could move around on the desktop but clicking on icons appeared to do nothing ... until Teredo timed out, then the application of every icon I had clicked on popped onto the screen. Things would be fine until another IP address was queried and the whole thing repeated it self. I uninstalled miredo this morning and my Internet and desktop are behaving themselves.

I just went to the various test sites, like http://test-ipv6.com/ and http://ipv6test.google.com/ to test my "IPv6" readiness. The Google site says

"No problems detected.You don’t have IPv6, but you shouldn’t have problems on websites that add IPv6 support"

but the test-i[v6 site says:


"You appear to be able to browse the IPv4 Internet only. You will not be able to reach IPv6-only sites."

which is probably the more truthful statement.

My ISP, Earthlink.net, apparently isn't ready to support IPv6 but the carrier it piggy-backs off of, TimeWarner, had converted "1%" of its consumer base to IPv6. If I swapped my TWC router for an IPv6 capable device, it might be worth swapping out my TP-TL1043DN wireless router for a native IPv6 version because as TWC goes, so goes Earthlink.

When checking out IPv6 "ready" wireless modems on Amazon I noticed that all the inexpensive ones which reported being "IPv6 ready" were using tunneling to do it. I am not going to buy a router that mimics IPv6 by tunneling, I can do that in software and the process is explained clearly on that Ubuntu wiki IPv6 link I cited above. I am not going to pay $200+ for a wireless modem just to get native IPv6 either.

If I don't it probably doesn't matter anyway. IPv4 will probably still be the major protocol on the Internet when I am drooling into my bib at some nursing home.

Anyway, I removed miredo and the hangs caused by it are no longer occurring.

[SteveRiley]

Good research, Jerry!

As most of you probably know, Google and several other websites are switching to IPv6 today and are never returning to IPv4.

"Never returning to IPv4"? Where did you see that? According to Google's own IPv6 FAQ, they specifically state "IPv4 services will continue to operate as usual." Wouldn't surprise me if some tech "journalist" got it wrong...

Yesterday ping6 would only return results if I pinged the localhost using "ping6 ::1". "ping6 google.com" returned nothing... Here are the results today.

Because their IPv6 DNS wasn't on yesterday.

I find it odd that ping6 is resolving to an IPv4 address instead of eight quad digits. aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh or an abbreviated version of an 8 quad. Tracing doesn't give a hint of IPv6 routing.

A later statement you made explains why:

My TP-Link 1043DN wireless doesn't support IPv6. I am not sure my TimeWarner modem does either.

Tunneling takes its toll on speed it appears.

Indeed. And, possibly, your NIC doesn't have offload capability for tunneling, and therefore your IP stack has to perform the tunneling (and corresponding header checksum calculations) using the CPU.

Checking my own address:

:~$ [B]ip -6 addr show dev wlan0 scope link[/B]
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fe80::76de:2bff:fe36:e435/64 scope link 
       valid_lft forever preferred_lft forever

The range fe80::/10 is reserved for autoconfigured and unroutable link-local addresses. This is equivalent to the IPv4 block 169.254/16.

[GreyGeek]

Test your connection for IPv6 or tunneling:
http://ipv6test.google.com/

[GreyGeek]

From the Ubuntu Wiki on IPv6:

Special IPv6 address ranges

Address ranges are specified using a prefix. This is similar to the IPv4 concept of a network prefix and netmask, but in IPv6 we always use CIDR notation to specify the number of bits at the start of the mask that are 1. For example, the address range fe80::/10 includes all addresses that are the same as the address fe80:: in the first 10 bits, i.e. all beginning with the bit pattern 1111 1110 10. One hex digit corresponds to four bits: 1111 is f, 1110 is e. 10 is the most significant two bits of 1000 which is 8 in hex, but since this length is not a multiple of 4, the range also includes addresses with this digit set to 9 (1001), a (1010) and b (1011). Obviously a network prefix of length 128 specifies an individual address.

IPv6 address	Prefix length (bits)		Description		Notes
::	128		unspecified		Used for default route and router solicitations. cf. 0.0.0.0 in IPv4
::1	128		loopback address		cf. 127.0.0.1 in IPv4
::ffff:a.b.c.d	96		IPv4 mapped IPv6 address		The lower 32 bits are the IPv4 address. Used in socket API's to represent IPv4 hosts.
fe80::	10		link-local		Unroutable autoconfigured addresses used on a LAN, e.g. for DHCPv6
fc00::	7		unique local		Addresses used only within an autonomous system, unroutable globally. Cf. RFC 1918 addresses such as used in NAT.
ff00::	8		multicast
2000::	3		global unicast		All global unicast addresses currently begin with 2.

Some IPv6 address prefixes have been deprecated, and should no longer be used.

deprecated IPv6 address	Prefix length (bits)		Description		Notes
3ffe::	16		6bone prefix		Used 1998-2006.
::a.b.c.d	96		embedded IPv4		96 zero bits followed by 32 IPv4 bits. Also called “IPv4 compatible IPv6 address”. Replaced by mapped addresses.
fec0::	10		site-local		Replaced by Unique Local Addresses

Some address prefixes are special use:

special IPv6 address	Prefix length (bits)		Description		Notes
2001:db8::	32		documentation examples		Not to be routed.
2001:0::	32		Teredo tunnels		the remaining bits come from a Teredo server and the client NAT device.
2002::	16		6to4 tunnels		the next 32 bits are the client IPv4 address

[GreyGeek]

I located Google's IPv6 website. It is ipv6.google.com
Using whois I got this IP address: 2a00:1450:4016:801::1010

Using ping6 I got this return:

:~$ [COLOR=#ff0000][B]ping6[/B][/COLOR] 2a00:1450:4016:801::1010
PING 2a00:1450:4016:801::1010(2a00:1450:4016:801::1010) 56 data bytes
64 bytes from 2a00:1450:4016:801::1010: icmp_seq=4 ttl=57 time=651 ms
64 bytes from 2a00:1450:4016:801::1010: icmp_seq=3 ttl=57 time=1674 ms
64 bytes from 2a00:1450:4016:801::1010: icmp_seq=2 ttl=57 time=2682 ms
64 bytes from 2a00:1450:4016:801::1010: icmp_seq=1 ttl=57 time=3691 ms
64 bytes from 2a00:1450:4016:801::1010: icmp_seq=5 ttl=57 time=240 ms
64 bytes from 2a00:1450:4016:801::1010: icmp_seq=6 ttl=57 time=265 ms
64 bytes from 2a00:1450:4016:801::1010: icmp_seq=7 ttl=57 time=256 ms
64 bytes from 2a00:1450:4016:801::1010: icmp_seq=8 ttl=57 time=228 ms
64 bytes from 2a00:1450:4016:801::1010: icmp_seq=9 ttl=57 time=243 ms
^C
--- 2a00:1450:4016:801::1010 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8031ms
rtt min/avg/max/mdev = 228.723/1103.750/3691.810/1219.875 ms, pipe 4
:~$

Checking my own address:

:~$ [FONT=courier new][B]ip -6 addr show dev wlan0 scope link[/B][/FONT]
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fe80::76de:2bff:fe36:e435/64 scope link 
       valid_lft forever preferred_lft forever
jerry@jerry-Aspire-7739:~$

Google has added IPv6 DNS addresses:

Hi, Google Public DNS users,
To celebrate World IPv6 Day
<http://googleblog.blogspot.com/2011/06/world-ipv6-day-begins-24-hours...>,
Google Public DNS <http://code.google.com/speed/public-dns/> is now
also available to IPv6 users. Although it has always been possible to
resolve AAAA records with Google Public DNS, today we are adding the
ability to reach Google Public DNS servers over IPv6.

We will be soon publishing detailed information related to the use and
configuration of Google Public DNS over IPv6. In the meantime, systems
with IPv6 support can use Google Public DNS over IPv6 by changing the
system DNS server settings to use one or both of the following Google

Public DNS IPv6 addresses:

2001:4860:4860::8888
2001:4860:4860::8844


Happy IPv6 day!

Firewalls:

One can install ip6tables:
sudo modprobe ip6_tables

and lsmod will list it:

:~$[B][FONT=courier new] lsmod | grep ip6[/FONT][/B]
ip6_tables             27864  0 
x_tables               29846  1 ip6_tables
:~$

The ip6tables command will list the current rules after a fresh modprobe:

:~$ sudo ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         


Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         


Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
jerry@jerry-Aspire-7739:~$

How about this:

:~$[SIZE=2][B][FONT=courier new] ip addr[/FONT][/B][/SIZE]
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 38:60:77:78:40:c8 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 74:de:2b:36:e4:35 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.100/24 brd 192.168.1.255 scope global wlan0
    inet6 fe80::76de:2bff:fe36:e435/64 scope link 
       valid_lft forever preferred_lft forever
10: teredo: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN qlen 500
    link/none 
    inet6 2001:0:53aa:64c:188e:2c81:e720:5a2/32 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::ffff:ffff:ffff/64 scope link 
       valid_lft forever preferred_lft forever
:~$

That listing mentions Teredo, and I haven't run Miredo.


ALL of this stuff is totally new to me. I've only paid attention to IPv4. Guess it's back to the books...

Ubuntu has a site on IPv6: https://wiki.ubuntu.com/IPv6

I found at http://www.bieringer.de/linux/IPv6/
which leads to:
http://www.ibiblio.org/pub/Linux/doc...N-DEBIAN-LINUX

[GreyGeek]

As most of you probably know, Google and several other websites are switching to IPv6 today and are never returning to IPv4.

Linux and Kubuntu are IPv6 capable using 6to4 tunneling. Teredo automatic tunneling can be had by installing Miredo, a Teredo clone running as a daemon.

Anyway, I decided to test the relative speed of IPv4 vs IPv6 using ping and ping6. Yesterday ping6 would only return results if I pinged the localhost using "ping6 ::1". "ping6 google.com" returned nothing.

Here are the results today.

:~$ [B][COLOR=#ff0000]ping6[/COLOR][/B] google.com
PING google.com(iad23s08-in-x09.1e100.net) 56 data bytes
64 bytes from iad23s08-in-x09.1e100.net: icmp_seq=1 ttl=59 time=395 ms
64 bytes from iad23s08-in-x09.1e100.net: icmp_seq=2 ttl=59 time=72.6 ms
64 bytes from iad23s08-in-x09.1e100.net: icmp_seq=3 ttl=59 time=73.7 ms
64 bytes from iad23s08-in-x09.1e100.net: icmp_seq=4 ttl=59 time=76.4 ms
64 bytes from iad23s08-in-x09.1e100.net: icmp_seq=5 ttl=59 time=71.0 ms
64 bytes from iad23s08-in-x09.1e100.net: icmp_seq=6 ttl=59 time=74.9 ms
64 bytes from iad23s08-in-x09.1e100.net: icmp_seq=7 ttl=59 time=75.1 ms
64 bytes from iad23s08-in-x09.1e100.net: icmp_seq=8 ttl=59 time=73.5 ms
64 bytes from iad23s08-in-x09.1e100.net: icmp_seq=9 ttl=59 time=73.4 ms
^C64 bytes from iad23s08-in-x09.1e100.net: icmp_seq=10 ttl=59 time=70.3 ms


--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9002ms
rtt min/avg/max/mdev = 70.335/105.650/395.130/96.509 ms




:~$ [B]ping[/B] google.com
PING google.com (74.125.228.5) 56(84) bytes of data.
64 bytes from iad23s05-in-f5.1e100.net (74.125.228.5): icmp_req=1 ttl=47 time=52.9 ms
64 bytes from iad23s05-in-f5.1e100.net (74.125.228.5): icmp_req=2 ttl=47 time=54.9 ms
64 bytes from iad23s05-in-f5.1e100.net (74.125.228.5): icmp_req=3 ttl=47 time=54.9 ms
64 bytes from iad23s05-in-f5.1e100.net (74.125.228.5): icmp_req=4 ttl=47 time=51.6 ms
64 bytes from iad23s05-in-f5.1e100.net (74.125.228.5): icmp_req=5 ttl=47 time=53.1 ms
64 bytes from iad23s05-in-f5.1e100.net (74.125.228.5): icmp_req=6 ttl=47 time=52.0 ms
64 bytes from iad23s05-in-f5.1e100.net (74.125.228.5): icmp_req=7 ttl=47 time=52.1 ms
64 bytes from iad23s05-in-f5.1e100.net (74.125.228.5): icmp_req=8 ttl=47 time=51.7 ms
64 bytes from iad23s05-in-f5.1e100.net (74.125.228.5): icmp_req=9 ttl=47 time=53.3 ms
64 bytes from iad23s05-in-f5.1e100.net (74.125.228.5): icmp_req=10 ttl=47 time=51.2 ms
^C
--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 51.250/52.823/54.996/1.269 ms
:~$

An IP lookup for Google.com gives:
IP: 74.125.228.9
IP Country: Canada
This IP address resolves to iad23s05-in-f9.1e100.net
which is what is given when I use ping6.


I find it odd that ping6 is resolving to an IPv4 address instead of eight quad digits. aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh or an abbreviated version of an 8 quad. Tracing doesn't give a hint of IPv6 routing.


Also, it is odd that for 10 pings both returned essential the same time, 9000ms, but the IPv6 packets averaged 2 times longer than IPv4 packets and the deviation was 75 times wider. Somethings wrong with the way IPv6 is collecting, computing or recording its data. When adding up the returns I compute:
ping6 1,055.9
ping 527.7
which shows that IPv4 is twice as fast as IPv6. Yet, by my watch they both took about the same amount of time, ten seconds. IF IPv4 were twice as fast as IPv6 it should have taken only about 5 seconds, or IPv6 should have taken 20 seconds.


Tunneling takes its toll on speed it appears.

My TP-Link 1043DN wireless doesn't support IPv6. I am not sure my TimeWarner modem does either. Looks like I will be looking into buying a wireless router that does and replacing my modem with one that does.