Tag Archives: IPv6

Remedial Networking 102: How Multicast Works

Did you ever have anything in your life that you just kind of…ignored until it went away? Or at least, ignored it until you forgot about it or pretended it went away? That’s kind of what I did with multicast.

For a long, long time, I would hear people mention multicast, and I would be like, “oh, multicast, yeah, talking to lots of hosts at one time, yeah, that’s cool…” then do my best to not join in that conversation, because I had less than nothing to add. In fact, all I could do was show my ignorance, and THAT’S no fun.

So my shame of not knowing it drove me deeper into my cave. “It’s not like anyone even uses it. I’ve been doing networking for years and its never come up”.

Then I started learning more about IPv6, and multicast would creep into the conversation. And I’d ignore it, and sure enough, the next paragraph wouldn’t mention it anymore, and I could go back to pretending it didn’t exist. But it kept coming up, and one day I slipped.

I thought to myself, “so, I know that multicast is all about sending data to lots of hosts at once, but how could it really do that?” And so I slipped into the inescapable void of my curiosity.

As it turns out, it’s really not all that crazy, and it’s really not that difficult, at least on the surface. There are two sides of the proverbial coin. There’s the theory of how it works, and there’s the practical application. Lets look at the practical side.

A prototypical example use-case would be video streaming. Every multicast application (and by application, here, I mean every solution, such as a NASA video stream and the like) picks or is assigned a particular multicast IP address, then everyone on the internet that wants to watch the stream joins that multicast IP address…and when I say it joins that multicast IP address, I mean that the machine uses a protocol called IGMP to tell its local router that it wants in on the action.

The local router is hopefully configured to know about IGMP so it listens. If it’s configured properly, then it uses a protocol called PIM (or one much like it) to let the next closest router to the video source know that it has someone who wants to watch. That router then sends PIM updates to the router it thinks is closer to the source than it, and so on.

Eventually, you wind up with a tree starting with the root being the video server, and forming the branches are all of the routers who have clients that used IGMP to let them know that they wanted to watch. The video source sends out one packet, to its closest router, and the router remembers which connections joined that group and sends the packets to those routers, which send the packets to the next routers, and the packets eventually wind up at the clients who are watching the stream.

No one machine sends a ton of packets, and no routers have to remember much besides which interfaces belong to which groups. It works out nicely, even though, and I say this with the greatest apology now that you’ve read the preceding paragraphs, almost no one uses it like this.

Sure, there are some internal networks that use it for things like teleconferencing, but I bet yours doesn’t. Except you Googlers and Yahoos out there. Your university probably does, I guess, especially if it’s on that whole Internet2 thing, but the vast majority of you will never have to deal with multicast video streams.

That doesn’t mean that multicast is going away. Actually, with IPv6, it’s getting more airtime.

The biggest difference between IPv4 and IPv6, in my opinion, is the idea that your interface isn’t going to belong to only one layer 3 (IP) network.

You know how, right now, you are probably on a private block, like 192.168.whatever? Well, with IPv6, you’re still going to have a private block, only it’s called link-local. Your machine, and every other machine, will have a link-local network address on their interface. It doesn’t route to the internet at all. When you have one machine that wants to talk to another local machine, it’s going to happen over the link-local interface.

Of course, your computer will also want to talk to the internet, probably, so you’re going to have an IP with the “real” network prefix (which is probably going to be assigned automatically by the IPv6 autonegotiation process, which I’ll write more about later). This “real” network IP will allow you to communicate with the outside world (and it with you, unless you set up your firewall rules correctly). That’s two IP addresses so far. How many more?

Well, there is also going to be the “All Nodes” multicast group, FF01::1 for “node-local” (AKA “all interfaces on the same machine”) and FF02::1 for the link-local (AKA “the local broadcast domain” because routers don’t forward link-local packets) group. Your machine will belong to these multicast groups, because things like ARP are going away with IPv6.

Instead of ARP (and ping and passive IP collision detection), IPv6 includes a protocol called NDP, which provides for all kinds of things…and most of those features come from using multicast addresses.

So what happens is really just a smaller version of above, where the host tells the router that it wants to join a multicast group. Except that in IPv6, we don’t use IGMP anymore, we use MLD, but it works mostly the same way. The router sends us any packets that are sent to that IP address, and things go swimmingly.

If the machine that you’re working on IS the router, well, then it’s going to join any number of IPv6 multicasts…the “All Routers” multicast (ff02::2), maybe the All DHCP Servers group (ff02::1:2), and seriously, a ton of other multicast groups.

The big reason for all of these groups is service discovery. It’s kind of like, in IPv4, if you had a specific private IP block for, say, DNS servers. If you just knew that somewhere in, there would be a DNS server, you could join that network, ping the broadcast, and the DNS server would respond. You could use that to add it to your configuration. It’s kind of like that, but instead of a broadcast, it’s multicast.

If you’re the rare networking wonk who didn’t know multicast, you’ve probably already asked, “yeah, but how does that work at the switch?”, in which case I invite you to read the wiki entry on IP Multicast: Layer 2 Delivery.

So despite my earlier fears, multicast doesn’t operate by magic, just by protocols that I’ve never configured because they didn’t matter to me. But even with the scant knowledge that I just imparted, you can feel a little bit better about needing to use multicast all over the place with IPv6.

Quick IPv6 Web Server on the HP cloud

I was thrilled to learn that I had been included in the free HP Cloud (@hpcloud on twitter) beta test. I’ve recently been messing a little bit with Amazon Web Services, and I’d requested access to HP to compare the offerings. Success! My gain is yours, so lets take a quick look…

When logging in, you get an interface similar to this:

There are three offerings immediately available. The two cloud compute options at az-1.region-a.geo-1 and az-2.region-a.geo-1, and a cloud object store at region-a.geo-1. I’m certain that they will offer both more geographic areas and services before the end of the beta, and definitely when the service goes public.

Anyway, I wanted to set up a machine and see what the process was like. I clicked on the blue “Activate Now” button in the picture above, and it took me to this screen:

The options for the size are currently as shown below:

The images available right now are here:

Since AMI on Amazon means “Amazon Machine Image”, I’m not sure what the AMI prefix means here, but whatever. I selected the smallest size and the CentOS 6.2 image with the default security group. At first, I didn’t get a chance to select a key pair, but I left instances at 1 and clicked Create. Of course, you have to have a keypair, or you can’t SSH in, so I got a warning box telling me to click “Key Pair” to make a new keypair. Done. I copied the resulting private key into my HPtestCon1.pem file, chmodded it to 400, and went on my merry way.

Incidentally, key pairs on HP are geographically specific. In running through this process again as I write this entry, I’m doing it on the az-2.region-a.geo-1 compute group. I don’t know if this is going to remain the case for public production, but I hope not. I would like my in-production servers to not need me to be aware of which geographic zone they’re running in. I don’t know if AWS or RackSpace are set up in the same way…maybe someone can chime in below in the comments?

I asked @HPCloud on twitter, and I got a response from HP cloud guy @rupakg:

When I asked about the ability to manually add keys (because I don’t really want to have my scripts care which geographic zone these VMs are running in), he suggested that I check out the Cloud CLI. I haven’t had a chance to play with it yet, but it seems promising. There are Powershell commandlets for Windows and a Ruby gem for Unix, in addition to Eucalyptus tools, which makes sense, since all of HP Cloud is based on OpenStack.

After creating a key pair, I was able to start the new instance with no problems whatsoever. Of course, once I started the instance, I ran into a small hiccup…my Private IP was 10.4.7.whatever and I didn’t have a public IP to connect to it using. Right. So I clicked on the instance number listed, and one of the options was “ATTACH PUBLIC IP”, and all of a sudden, I had a public IP. An IPv4 public IP.

I’ve been looking for a cloud provider that has IPv6 out of the box, and sadly, HP doesn’t have it. That’s ok, as far as I can tell, no one else does, either. [Edit: Several people have told me on twitter that Linode has it. Yay!] I still wanted to set up an IPv6 web server as a demo, though, and I wasn’t going to let this stop me, so I went through the path of least resistance: http://www.tunnelbroker.net/.

I created a TunnelBroker account in about a minute. After logging in, I clicked “Create Regular Tunnel”, and was asked for my IPv4 Endpoint, and I gave it the IPv4 address that was assigned to my VM. It then checked the address, determined that it was a potential tunnel endpoint, and suggested I use the Chicago tunnel server. Sure, why not? I clicked Create Tunnel, and in a few seconds, it took me to the Tunnel Details page:

Easy peasy. Anyway, my server was up and running, so to connect to it, I just ran

ssh -i ~/HPtestCon1.pem root@mypublicIP

Once on the server, I quickly configured the IPv6 tunnel from Hurricane Electric. In the Tunnel Details above, you can see the “Example Configurations” tab, which I clicked. Once on that page, there’s a pulldown for “Select your OS”, and when I selected Linux-net-tools, I got the following:

ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:470:1f10:294::2/64
route -A inet6 add ::/0 dev sit1

Pasting this into the shell didn’t produce any errors whatsoever, and I tested my IPv6 connectivity:

[root@server-49193 ~]# ping6 ipv6.google.com
PING ipv6.google.com(mil01s17-in-x10.1e100.net) 56 data bytes
64 bytes from mil01s17-in-x10.1e100.net: icmp_seq=0 ttl=54 time=185 ms
64 bytes from mil01s17-in-x10.1e100.net: icmp_seq=1 ttl=54 time=185 ms
64 bytes from mil01s17-in-x10.1e100.net: icmp_seq=2 ttl=54 time=185 ms
64 bytes from mil01s17-in-x10.1e100.net: icmp_seq=3 ttl=54 time=185 ms

— ipv6.google.com ping statistics —
5 packets transmitted, 4 received, 20% packet loss, time 4016ms
rtt min/avg/max/mdev = 185.038/185.082/185.142/0.432 ms, pipe 2

Excellent. Now for Apache. First, lets install it:

yum install httpd -y

Now we have to configure it. Edit /etc/httpd/conf/httpd.conf, and look for the Listen lines which dictate which IPs the machine responds to. The default line number is 134, if you were curious.

Because we want to be specific, change the line that says:

Listen 80

and change it to

Listen 10.6.whatever.whatever:80

where 10.6.whatever.whatever is your private IP.

We’re also going to add a line specific to the IPv6 address that we’ve been given by Hurricane Electric, so in the commands above, I would use 2001:470:1f10:294::2. That’s my side of the tunnel that they set up for me. Yours will be slightly different. The line I added was:

Listen [2001:470:1f10:294::2]:80

You’ll notice that there are square brackets surrounding the IPv6 address. These are very important. The reason is that, historically, the colon separated the IP address from the port number, as it does in the IPv4 line above. With IPv6, we can shorten the IP by replacing the longest string of zeros with :: – thus making an IP of 2001:470:1f10:294::2 when the full length address is 2001:1f10:2940:0000:0000:0000:0000:0002. Having colons define a port number doesn’t work anymore unless you do something else to determine the IP address, so the standard operation is to enclose it in square brackets. Make sure to do that.

Save the file, then start up Apache:

[root@server-49193 ~]# service httpd start
Starting httpd:
[root@server-49193 ~]# service httpd status
httpd (pid 3002) is running…
[root@server-49193 ~]#

Now, we can test it by going back to the Hurricane Electric page, and clicking “IPv6 Port scan” under “User Functions” on the left. It asks for the IPv6 address to check, so put your end of the tunnel (in my case, 2001:470:1f10:294::2). I put it in, and the submit button didn’t light up, so I hit tab, which made it start checking the IP. The IP was valid, and I could click submit, so I did.

The output on the Nmap window came back like this:

Starting Nmap 5.00 ( http://nmap.org ) at 2012-03-11 19:17 PDT
Interesting ports on standaloneSA-2-pt.tunnel.tserv9.chi1.ipv6.he.net (2001:470:1f10:294::2):
Not shown: 998 closed ports
22/tcp open ssh
80/tcp open http

Nmap done: 1 IP address (1 host up) scanned in 17.62 seconds

Exactly what I was looking for!

So there you have it. Around 5 minutes to set up IPv6 on a web server, and a quick walkthrough of the new HP Cloud beta. I think it has a lot of potential, and I’m looking forward to seeing where HP takes it. You can watch as news comes out by checking the HP Cloud Blog. They’re also at SXSW, which I really want to go to next year. I had a really great time in Austin for Tech Field Day 7…I can’t imagine the spectacle that must be South by SouthWest.

Anyway, I hope you enjoyed this walkthrough. Let me know if you have any questions about this that I can answer (or find you the answer to)!

Random thoughts on Slashdot

I wanted to make a quick reply to someone on slashdot who suggested adding a 5th octet to IP addresses rather than migrating to IPv6. I meant to write a really quick reply, but it got drawn out. I got done with it and thought that some of you might have thoughts on it:

Awesome idea. We’ll give Google 1/8, The government can 2/8, IBM will get 3/8, etc etc etc

Same problem. The ipv6 is not a “bad” idea, it’s just sort of like…imagine in 1950s if the phone company decided “we could go with area codes to subdivide numbers to prevent running out, or we could use letters AND numbers”.

Can you imagine the upheaval?

In a lot of ways, that would have been even easier to deal with, because everyone’s phone was owned by AT&T. New phones could have been issued without too much problem.

No, imagine it instead in the mid 1980s. Ma Bell doesn’t own the phones any more, in fact there are tons of cheap phones available, cell phones are starting to come out, and there are still rotary AND push button phones.

That’s more like what the IPv6 switch is like. Do you give the new people 2 numbers, so that grandma can still call them? How long is it before you stop accepting legacy phones that only have 10 dialing options? How the hell do you get DTMF to work with 36 numbers? Do we need area codes? It would be weird without them, but we don’t really need them.

The equivalent of these questions are still being asked. Just a couple of months ago, there was a huge to-do about NAT and IPv6. “IPv6 is a world without NAT”. The hell it is. My internal routers don’t get publicly routable IP addresses, even if I have to NAT back to IPv4.

When the wrinkles get ironed out, we’re going to wonder how we ever did without it. During the transition, it’s going to be hell for everyone (with the possible exception of the clueless end user, who might have to buy a new router at most).