Archive for ‘Uncategorized’ Category

February 16, 2011 Meeting Summary

datePosted on 11:41, March 7th, 2011 by Alan Whinery

The big discussion of the day was IANA address depletion, and this hot topic was probably responsible for record attendance, both in-person and over the netcast.

An overview of recently attended conferences included:

APRICOT/APAN IPv6 Transition (see video archive at):

http://www.apricot-apan.asia/program/ipv6-trans-conf

Joint Techs:

http://events.internet2.edu/2011/jt-clemson/agenda.cfm?tracks=67&types=&details=

And discussion of regional 6to4, which has changed recently, due to LavaNet’s disconnection from the HIX.

 

categoryPosted in Uncategorized | commentsComments Off on February 16, 2011 Meeting Summary | moreRead More »

The End Of Guessing

datePosted on 16:59, February 16th, 2011 by Alan Whinery

It has been a continual surprise to me that, with so many things to do, people who work in IPv6 advocacy have spent so much time arguing about the accuracy of IPv4 depletion predictions, and asking why competing estimates didn’t match.

Since two weeks ago, or so, the guessing stopped, and yesterday, a ceremony/press conference was held in Miami, a joint event among ICANN, NRO, AfriNIC, APNIC, ARIN, LACNIC, RIPE-NCC, IANA, and the Internet Society.

So far, ICANN’s summary page is the most complete that I’ve seen:

http://icann.org/

What happened is this: IANA, the dispenser of all IP addresses, handed out the last of their IPv4 addresses and will dispense no more.

What does this mean? It means that the addresses in the hands of the Regional Internet Registries will be the last that they dispense to end-users, and that alternate means of acquiring addresses will be sought.  People who have addresses will do deals with people who need addresses.

I was tempted to scoff when the assertion was made by NRO that address selling will still occur by the guidelines currently used by RIRs, because I had sort of pictured the post-depletion address market as wild west black market kind of thing. But when you think it through, would you give want to give somebody money for addresses which would not be described as belonging to you in the registry? Probably not.  At the same time, address rentals will become common too, and they may not need to heed RIR procedures. A brave new world, hopefully not a Huxley-esque.

I wax:

“Ending is better than mending. The more stitches, the less riches.”
– Aldous Huxley, Brave New World, Ch. 3

or, if you prefer:

“Cleanliness is next to fordliness.”
– Aldous Huxley, Brave New World, Ch. 7

categoryPosted in Uncategorized | commentsComments Off on The End Of Guessing | moreRead More »

February 16, 2011 Hawaii IPv6 Task Force Meeting

datePosted on 15:19, February 7th, 2011 by Alan Whinery

Aloha Everyone,

The Hawaii IPv6 Task Force will hold its next meeting:

Wednesday, February 16, 2011
6:30 – 8:30 PM HST
UH Manoa Campus, POST 801

Agenda will include:

– NRO/ICANN/IANA/ISOC/RIRs “Significant Announcement” Highlights
– Why you should/shouldn’t panic about IPv4 Address depletion
(Which happened last week)
– Recent Conferences Attended (RCA) Highlights
[PITA, HIC, Joint Techs, !PTC]
– IPocalypse survival advice
– Living with IPv6: day to day issues
– Common sense about post-depletion IPv4 address block transfers
(Why you should work within RIR allocation rules)
– Upcoming meetings/conferences
– Future of HIX 6to4.

Everyone is welcome.
Please RSVP.
Refreshments will be provided — Pizza this time; feel free to express
preferences. We are not able to provide refreshments to remote participants.

Parking: see UH Manoa visitor parking rules:
http://www.hawaii.edu/parking/visitorparking.html

Remote participation will be available through the Ustream web site:
http://www.ustream.tv/channel/ipv6hawaiimeeting

Live Netcast will run from 19:00 to 20:00 HST 16 February 2011
(GMT 05:00-06:00, 17 February, 2011)

Please use UStream chat functions to participate remotely

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

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

categoryPosted in Uncategorized | commentsComments Off on February 16, 2011 Hawaii IPv6 Task Force Meeting | moreRead More »

T-Mobile Mobile IPv6 Trial

datePosted on 09:14, July 30th, 2010 by Alan Whinery

“T-Mobile USA is keenly aware of the IPv4 address exhaustion issue and we are working diligently to ensure an orderly transition from IPv4 services to IPv6 services.  To that end, we are working with our industry partners, the IETF, and the 3GPP to develop the right standards and the right ecosystem to make the IPv6 Internet a reality.”

Read more here.

Learned from Derek Morr

categoryPosted in Uncategorized | commentsComments Off on T-Mobile Mobile IPv6 Trial | moreRead More »

IPv6, PPTP, and BitTorrent

datePosted on 10:56, June 22nd, 2010 by Alan Whinery

There is much blog traffic this week about the so-called “security flaw”, supposedly in PPTP, when “combined with IPv6”. A number of explanations have been offered, none of which have aptly described the situation.

See this article, which includes an embedded video of the Telecomix Cipher conference talk that started the controversy. The talk makes several interesting points about anonymity, through proxies and VPNs, and how sites work around them to see who you really are.

The problem is not due to a security flaw in PPTP, or in PPTP when used with IPv6. It is an effect of trying to implement a solution that simply ignores IPv6, a strategy which has become inappropriate in the current Internet.

Any VPN, or other tunneling solution will route some portion of its traffic over an alternative path, like a tunnel. A very common type of VPN, which addresses the “road warrior” scenario, allows a client to connect securely to its home network. For instance, a “road warrior” VPN client which is connected to its home net can be recognized as part of that network and allowed access to resources such as file servers, email servers, etc. Connection to a VPN may also offer the client the ability to hold a real, routable IP address when they are actually situated behind a NAT device. If the VPN connection is set up to route all traffic through the VPN, then the VPN-assigned address will represent your “identity” as far as the world is concerned.

Of course, having a VPN connection, and being represented by a VPN-assigned address does not give you anonimity. That VPN-assigned IP address was allocated to your VPN provider, and they will probably have logs and records of who you are and when you occupied what address, especially if they authenticate you, and if you use Relakks or Ipredator, or any service which requires sign-up, or especially if they charge you money, the “anonymity” is relative. You trust these providers either to completely forgo logging, which they don’t, or to deny warrants and subpoenas, which they won’t.  Anonymity, security, are just not this simple to achieve, and the average user is not equipped to evaluate what he’s getting.

The problem isn’t that the VPN solutions in question are flawed, it’s that they only affect the routing of IPv4, so that when your computer connects to an IPv6 resource, it will use your normal IPv6 routing, which has not been changed by the VPN set-up.

If you are using ANY tunnel-style VPN which tunnels IPv4 and not IPv6, then your IPv6 address will be visible to any resource you access via IPv6. I have seen many comments that suggested using OpenVPN, or IPSec VPNs, or etc. But they will all suffer from the same problem, unless they are set up to deal with all of the network protocols (IPv4 and IPv6) on your computer.

Of course, if you zoom out and look at the real problems in this scenario, you realize that VPNs, current operating systems, the World Wide Web, are all designed with absolutely no attention to anonymity.  In order to provide anonymity, you would have to reorganize the OS, the VPN, etc. If you built a special anonomyzing browser app, from the ground up, you could begin to address proxy-based anonymity, but there would still be much trial and error.

Of course, if you turn off IPv6 altogether, it will prevent you from reaching IPv6 resources, and thereby prevent the described issue with IPv6 addresses. But the way forward is to challenge the implementers to stop ignoring IPv6, which is growing at an increasing rate, and modernize their applications.

categoryPosted in Uncategorized | commentsComments Off on IPv6, PPTP, and BitTorrent | moreRead More »

June 23, 2010 Meeting

datePosted on 09:30, June 14th, 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 June 23rd, 2010
6:30 – 8:30 PM
UH Manoa Campus, POST 801

Agenda will include:

– IPv6 appliance development
– Facebook IPv6 trial
– North American IPv6 Task Force Meeting
– Network updates
– IPv6 strategy for your network

Everyone is welcome.
RSVP.
Refreshments will be provided.

Parking: see UH Manoa visitor parking rules:
http://www.hawaii.edu/parking/visitorparking.html

Remote participation will be available through the Ustream web site:
http://www.ustream.tv/channel/ipv6hawaiimeeting

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.

Alan Whinery
President Hawaii IPv6 Task Force
Chief Network Engineer, University of Hawaii
alan.whinery@ipv6hawaii.org

categoryPosted in Uncategorized | commentsComments Off on June 23, 2010 Meeting | moreRead More »

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
 ip
 BusyBox v1.15.3 (2009-12-13 23:28:29 CET) multi-call binary

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

 ip [OPTIONS] OBJECT {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 127.0.0.1/8 scope host lo
>     inet6 ::1/128 scope host
>        valid_lft forever preferred_lft forever
> 2: sit0: <NOARP> mtu 1480 qdisc noop
>     link/sit 0.0.0.0 brd 0.0.0.0
> 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 97.182.217.154 peer 66.174.216.149/32 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 127.0.0.1/8 scope host lo
>     inet6 ::1/128 scope host
>        valid_lft forever preferred_lft forever
> 2: sit0: <NOARP> mtu 1480 qdisc noop
>     link/sit 0.0.0.0 brd 0.0.0.0
> 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 0.0.0.0
>     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 ::192.88.99.1 dev tun6to4 metric 1
> ip -6 route add 2000::/3 via ::192.88.99.1 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 ::192.88.99.1 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 192.88.99.1 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.

categoryPosted in Uncategorized | commentsComments Off on Droid does… (6to4 over Verizon 3G) | moreRead More »

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")
categoryPosted in Uncategorized | commentsComments Off on Rogue RA suppression with Python and Scapy | moreRead More »

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

categoryPosted in Uncategorized | commentsComments Off on Droid Does IPv6! | moreRead More »

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.
RSVP.
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.

categoryPosted in Uncategorized | commentsComments Off on Third Meeting Of The Hawaii IPv6 Task Force | moreRead More »
123PreviousNext
Search: