Droid does… (6to4 over Verizon 3G)

datePosted on 11:21, May 12th, 2010 by Alan Whinery

Further study indicates that Android 2.x doesn’t simply offer v6 only on the 802.11 side, it does v6 where it finds SLAAC. My Droid surprised me the other day by loading the ipv6.netflix.com page at home, and doing it very quickly! This is because the Belkin SOHO device that I installed a couple of months ago apparently goes all 6to4 and stuff, and then offers RAs on the home net, and also is helped by TW Roadrunner’s promiscuity accepting routes from the Hawaii Internet Exchange, which explains why Lavanet’s public 6to4 relay got so busy a couple of months back.

But Android seems only to do native v6, not 6to4, for instance, yet, it looks as if it has the components to do it. Once one gains root access to one’s Android device, there is a BusyBox package available that includes the “ip” command:

 # ip
 BusyBox v1.15.3 (2009-12-13 23:28:29 CET) multi-call binary

 Usage: ip [OPTIONS] {address | route | link | tunnel | rule} {COMMAND}

 where OBJECT := {address | route | link | tunnel | rule}
 OPTIONS := { -f[amily] { inet | inet6 | link } | -o[neline] }

and the default “ip link show” looks like:

> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet scope host lo
>     inet6 ::1/128 scope host
>        valid_lft forever preferred_lft forever
> 2: sit0: <NOARP> mtu 1480 qdisc noop
>     link/sit brd
> 3: ip6tnl0: <NOARP> mtu 1460 qdisc noop
>     link/tunnel6 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd
> 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
> 16: tiwlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 100
>     link/ether a4:ed:4e:6a:31:31 brd ff:ff:ff:ff:ff:ff
> 17: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
> pfifo_fast qlen 3
>     link/ppp
>     inet peer scope global ppp0

Which is interesting, since it doesn’t appear to be doing anything with ip6tnl0.


At this point, it’s hard not to try to set up 6to4. (the shell parrots all commands back to the console, which doesn’t always mean that it did anything, or that the command exists, although it tends to say “permission denied” when you invoke a command it doesn’t possess…):

> # ip tunnel add tun6to4 mode sit ttl 32 remote any local a.b.c.d
> ip tunnel add tun6to4 mode sit ttl 32 remote any local a.b.c.d
> # ip link set dev tun6to4 up
> ip link set dev tun6to4 up

Address derived from my current Verizon 3G (ppp0) v4 address.

> # ip -6 addr add 2002:a0b:c0d::1/16 dev tun6to4
> ip -6 addr add 2002:a0b:c0d:::1/16 dev tun6to4
> # ip addr
> ip addr
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet scope host lo
>     inet6 ::1/128 scope host
>        valid_lft forever preferred_lft forever
> 2: sit0: <NOARP> mtu 1480 qdisc noop
>     link/sit brd
> 3: ip6tnl0: <NOARP> mtu 1460 qdisc noop
>     link/tunnel6 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd
> 00:00:00:00
> :00:00:00:00:00:00:00:00:00:00:00:00
> 34: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
> pfifo_fast ql
> en 3
>     link/ppp
>     inet a.b.c.d peer e.f.g.h/32 scope global ppp0
> 35: tun6to4: <NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue
>     link/sit a.b.c.d brd
>     inet6 2002:a0b:c0d::1/16 scope global
>        valid_lft forever preferred_lft forever
>     inet6 ::a.b.c.d/128 scope global
>        valid_lft forever preferred_lft forever
> # ip -6 route add 2000::/3 via :: dev tun6to4 metric 1
> ip -6 route add 2000::/3 via :: dev tun6to4 metric 1
> # ip -6 route
> ip -6 route
> ::/96 via :: dev tun6to4  metric 256
> 2002::/16 dev tun6to4  metric 256
> 2000::/3 via :: dev tun6to4  metric 1
> fe80::/64 dev tun6to4  metric 256
> unreachable default dev lo  metric -1  error -101
> ff00::/8 dev tun6to4  metric 256
> unreachable default dev lo  metric -1  error -101

At this point, the lack of ping6 and traceroute6 becomes a little frustrating, but having done this 6to4 setup, the browser loads ipv6.netflix.com and ipv6.google.com, somewhat slowly. Pinging 6to4 anycast gets responses with TTL=240, which looks as if it means that the responder’s TTL of 255 has traversed 15 hops (or has been decremented by 15). This is reinforced by pinging a host here at UH, which is sending responses with TTL=64, and Android ping reports TTL=47 (!).

In order to test the name resolution order, I attempted to load a couple of dual-stacked “toy surprise” pages, which reward v6 connectivity with a visual indicator, and found that both www.kame.net and net.its.hawaii.edu ( i have php-induced ipv6 wallpaper there) do seem to resolve the AAAA first, but it doesn’t load. Each of those 2 dual-stacked pages tried to load the page by v6 first, but actually just timed out after something like a minute, and then loaded the no-toy-surprise IPv4 page, which you’ll have to admit, isn’t as “neat”.

Of the other obvious dual stackers that I tried, www.ucla.edu was the only one that loaded quickly, apparently over v6. It may be that UCLA has a v6 peering with Verizon…

www.ietf.org was also a time-out on 6, followed by success on v4.

So, the good news is that you can set up 6to4 on Android 2.x, and use v6 from 3G, the less-good news is that you can’t reach some stuff. The more important point is the latter: this is an example of 6to4 routing that doesn’t work. If this were a Windows or Mac machine instead of a smart phone, the user might find themselves unable to reach certain resources, because their machine had automatically built a 6to4 connection, which doesn’t work well.

Rogue RA suppression with Python and Scapy

datePosted on 13:20, May 11th, 2010 by Alan Whinery

After the University Of Hawaii began getting Google Over IPv6 in March of 2010, we began noticing problems with user devices on our wireless sending router advertisements and “black-holing” traffic. This problem is, of course made more apparent by initiating Google Over IPv6, which causes significantly more content to be requested by clients over IPv6. Despite first appearances, this is a good thing, since it is a problem that must be faced and dealt with in order to operate a IPv6 network for the near term.

In a nutshell, a “rogue RA” scenario occurs when some device besides an “official” router identifies itself as a router using “router advertisement” ICMP6 messages. Once client hosts see the “rogue”  as a router, they may prefer it as their next hop to send traffic out to the Internet.

This can result in one of two problems:

  1. the rogue router can use its position as a router to intercept and eavesdrop upon or otherwise mess with traffic
  2. the rogue router can neglect to forward traffic such that the client cannot reach things by IPv6

These issues are not IPv6 specific problems. There are numerous similar problems that occur in IPv4 networks, on 802.11 “WiFi” networks, and on Layer 2 switched wired networks.

The best-known cause of rogue RAs on an IPv6 network comes from Windows Vista hosts with Internet Connection Sharing (ICS) enabled. Other causes are probably common, since the “personalities” of rogue RAs seem to differ widely.

Several drafts have been published in the IETF addressing the problem, and there is work currently proceeding in the IETF to address better RA controls, but as with most things, production implementations of standards currently in the IETF will not appear for some time.

One remedy that you will find referenced on the internet is rafixd (see also here), which had some compile issues when I tried it.

Other solutions include layer2 filtering for the “FF02::1″ multicast group, in order that RAs coming from segments where RAs should not be are excluded. This can help isolate the problem, but it does not protect other hosts in the rogue’s “filtered region” from the rogue, and it makes rogue detection more complex.

On the U.H. wireless network, it is simple to listen to the appropriate multicast group, and see router advertisements:

tcpdump -ln -i wlan0 dst host ff02::1

which will show only messages to the all-nodes multicast group, no other traffic.

A notable attribute of all of the rogue RA messages that I have looked at is that they all have “router lifetime” of more than 9000 seconds (2.5 hours), which is higher than the max of 9000 seconds specified by RFC 4861. Apparently this includes mis-configured Microsoft ICS hosts, which advertise router lifetime of 65,536 seconds, and many rogues advertise even higher router lifetime.

Of course, the high router lifetime “feature” has two sides (or perhaps three). It is discouraging that Microsoft released code that “violates” the RFC-specified behavior, and it is further discouraging that clients (perhaps especially Mac OS X) believe these illicit announcements. Of course, it also provides a way to distinguish between “legal” and illegal messages.

Since the clients are so gullible, the rafixd approach is to follow each illegal with a spoofed message (ostensibly) from the rogue which resets the router lifetime to zero, supposedly negating the rogue’s effect.

In the course of seeking a way to mitigate rogue RA problems on our wireless network, and having encountered resistance on the part of rafixd to compile, I lit upon a solution using Python module/tool scapy. My very simple script, shown below, is built upon the scapy docs “simple ARP monitor”, but I have since seen similar RA monitors elsewhere. This script has been working on the UH wireless for about a month, and seems to have mitigate issues that we were having with Apple clients unable to reach Google (and other) IPv6 resources. It differentiates between “bad” and “good” RAs by assuming that good ones will advertise router lifetime <= 9000.

This requires root permissions (to set the listening interface to promiscuous mode and capture packets), and is indicative of the power and utility of Scapy. If you are a network admin/engineer/monitor and you are unfamiliar with Scapy, you really need to look into it. It can change your life…

#!/usr/bin/env python
from scapy.all import *
def ra_monitor_callback(pkt):
 if ICMPv6ND_RA in pkt and pkt[ICMPv6ND_RA].routerlifetime > 9000:
 send(IPv6(src=pkt[IPv6].src)/ICMPv6ND_RA(routerlifetime=0) )
 u = pkt.sprintf("rogue %Ether.src% %IPv6.src% > %IPv6.dst% %ICMPv6ND_RA.routerlifetime%")
 s = time.asctime()
 t = "\t"
 return s + t + u

sniff(prn=ra_monitor_callback, filter="dst host ff02::1", store=0, iface="wlan0")

Droid Does IPv6!

datePosted on 08:24, May 9th, 2010 by Alan Whinery

Copyright 2010, NETFLIX This week, I have been getting used to my new phone, which is a Motorola Droid, running Android 2.1. One of my primary interests was to “see if I could get IPv6 working”, since it is based on a recent Linux kernel (which does IPv6). I looked into how to get the kernel source, and what environment I would need to recompile it, and reading web posts about people who tried, in vain to figure out “how to get IPv6 working on Android”, without a single useful answer.

For the uninitiated, “Android” is a mobile operating system (or more specifically a “software stack”), driven by (IPv6 bastion) Google, and “Droid” is a motorola phone, one of many phones which run Android.

On about my 8th day thinking about this, it occurred to me to try loading an IPv6-only web page. It worked the first time. I felt foolish.

As it turns out, Android has been doing native IPv6 on the 802.11 (WiFi) interface since about November 2009, if the device in question supports an Android version that supports 2.X firmware (not all do).

To answer the obvious question: iPhone doesn’t. Plans are in place, however, to include it in upcoming iPhone OS 4.0.

Read more in Derek Morr’s blog

Third Meeting Of The Hawaii IPv6 Task Force

datePosted on 09:16, May 4th, 2010 by Alan Whinery

IPv6 – A Bigger, Stronger, Better Internet, Today and Tomorrow

Aloha Everyone,

The Hawaii IPv6 Task Force will hold its next meeting:

Wednesday May 12th, 2010
6:30 – 8:30 PM
UH Manoa Campus, POST 801

Parking: see UH Manoa visitor parking rules

Agenda will include:
- Rogue Router-advertisement mitigation
- UH 6to4 gateway
- Your network updates.
- IPv6 strategy for your network

Everyone is welcome.
Refreshments will be provided.

If you would like to participate remotely, please
email alan.whinery@ipv6hawaii.org.

Meeting page:  http://ipv6hawaii.org/?p=135

Visit http://ipv6hawaii.org for updates.

Please also forward this invitation message to interested parties. Your
participation and support are vital to the smooth and successful
deployment of IPv6 in Hawaii.

Much Mahalo.

View of the March 10 Meeting

datePosted on 13:14, March 14th, 2010 by Alan Whinery

A good meeting with a primarily open agenda, March 10 benefited from new input from several first-time-attendees.

Brian made a phone-picture-panorama of us in mid-discussion.

Second meeting of the Hawaii IPv6 Task Force

datePosted on 11:18, February 23rd, 2010 by Alan Whinery
The Hawaii IPv6 Task Force will hold its second meeting:

Wednesday March 10th, 2010
6:30 - 8:30 PM
UH Manoa Campus, POST 801

Everyone is welcome. RSVP.

If you are not on Oahu and would like to participate remotely, please
email alan.whinery@ipv6hawaii.org.

Agenda may include:
- Update on UH Google-over-IPv6
- Availability of recursive DNS-over IPv6 for testers
- Additional network updates. 
- IPv6 strategy for your network

Refreshments will be provided.

Meeting page: http://ipv6hawaii.org/?page_id=119

Visit http://ipv6hawaii.org for updates.

IPv6 at Joint Techs Salt Lake City

datePosted on 18:43, February 14th, 2010 by Alan Whinery
Some talks from JT Salt Lake City
with links to Flash Video
(for more about Joint Techs, visit events.internet2.edu, or jointtechs.es.net)
DREN IPv6 Update (23 minutes)
Ron Broersma , Defense Research and Engineering Network (DREN)

Perennial favorite -- he made new slides the night before, so if you've
seen previous talks with the same title, this is probably different.

IPv6 Campus Deployment Updates Panel  (40 minutes)

Randy Bush , Internet Initiative Japan
Shumon Huque , University of Pennsylvania
Alan Whinery , University of Hawaii

Mostly for Shumon's bit, which you *may* not have heard before. Randy
did not use slides.


Challenges and Experiences in the use of IPv6 in the UNAM campus to offer IPv6 connectivity

Azael Fernandez , National Autonomous University of Mexico

Good to hear reports from the neighbors. 


IPv6 SNMP Network Management

Michael O''Connor , Energy Sciences Network (ESnet) 


IPv6 Roundtable at PTC 2010

datePosted on 10:30, January 8th, 2010 by Alan Whinery

Join us for PTC 2010 IPv6 Roundtable!

(To attend, you need to register for PTC 2010: See the Registration Page)

From the Pacific Telecommunications Council web page:

Sunday 17 January 2010

09.00 – 10.30
Roundtable 1: IPv6 – The Next Big Bail-Out: Will IPv6 Save the Internet?
Location: Nautilus 1

Organized by:

The transition to IPv6 had the objective of achieving smooth and low-cost Internet sustainability through incremental refresh of technology. Unfortunately, this transition did not happen over the past decade. The reasons can be traced back to the mixed messages sent to industry: hard-to-justify ROI; address depletion confusion and the lack of market demand. IP is a plumbing exercise. Only engineers should fix it and offer IPv6 as an extended service to sustain the Internet growth and continuity.

Now, it’s abundantly clear that the address space is going to be consumed in just the next 24 months, putting an end to the growth of the Internet. The address space is now down to just 10%. A new Y2K in the making!

IPv6 on Bytemarks Cafe

datePosted on 19:35, January 4th, 2010 by Alan Whinery

Please join Burt Lum, Ryan Ozawa of the Bytemarks Cafe radio program,
and their guests Antonio Querubin (Lavanet) and Alan Whinery (University
of Hawaii) for a discussion about the new bigger, stronger, better
Internet, using the Internet Protocol Version 6.

Bytemarks Cafe
Wednesday, January 6th, 2010
5:00 – 6:00 PM Hawaii Time
on Hawaii Public Radio KIPO, 89.3 FM

You can listen over the Internet, by visiting the following link:

Hawaii Time (HST) is UTC -10 hours.

You can also visit the Bytemarks Cafe web site, www.bytemarkscafe.org,
and download an MP3 file of the broadcast, after the show.

First Hawaii IPv6 Task Force Meeting: January 14

datePosted on 23:24, December 28th, 2009 by Alan Whinery

The First Meeting of the Hawaii IPv6 Task Force will take place:

January 14, 2010

7:00 PM to 9:00 PM

University Of Hawaii at Manoa

POST 801

Everyone is welcome. RSVP.

If you are not on Oahu and would like to participate remotely, please email alan.whinery@ipv6hawaii.org.
Agenda will include:

- Presentation about the current status of IPv6 implementation and deployment globally and locally
- Discussion of the IPv6 Forum Roadmap here and now
- Open discussion and plans for future meetings and events.

Refreshments will be provided.

A meeting page will be set up on this web site soon, for information about parking, remote participation, etc.

Visit meeting page at http://ipv6hawaii.org/?page_id=98  for updates.

Wishing you all prosperity in the coming New Year

Alan Whinery
President Hawaii IPv6 Task Force