Speaking of Standards

Want to understand what you have to do to make sure your applications work with IPv6?

Over at NetworkWorld, Scott Hogg has a great piece called “Top 10 Tasks for IPv6 Application Developers” that provides a really solid and thorough list of what you need to be thinking about. Scott provides links out to all the relevant RFCs and to other resources as well.

Kudos to Scott for putting this together! And if you’ve been wondering what exactly is involved in making sure your software works with IPv6, it’s a great starting point…

As I mentioned previously, this next few weeks is bound to be full of “It’s the End of The Internet As We Know It” stories and I did have to laugh when this story at FOX News literally began with that text:

Of course, they confused the “web” with the “Internet” (although to many people they are one and the same), and this phrase certainly made standards friends of mine smile (my emphasis added):

Web developers have compensated for this problem by creating IPv6 — a system which recognizes 128-bit addresses as opposed to IPv4′s 32-bit addresses.

… particularly since the original RFC 1883 for IPv6 came out back in 1995 when the “Web” was still in its very early stages.

The article does, though, hit on the key points that there is very little economic incentive for companies to move to IPv6… and that continues to be a challenge. However, as we continue to look at connecting every possible device to the Internet, the looming depletion of the IPv4 address pool does pose challenges for which IPv6 can certainly be an answer.

But stay tuned… I expect we’ll see even more of these stories in the weeks ahead…

So what shall we call this “big event” that the media is now starting to hype around “the end of IPv4 addresses”?

(Cue soundtrack… “It’s the End of the World As We Know It” – pick your artist).

Mashable yesterday was pointing to the aptly named “ARPageddon” Twitter account @IPv4countdown who uses the term:

IPcalypse

And a quick search on Twitter shows that term being significantly retweeted and used in other posts .

I admit, though, that the linguist in me would much prefer:

IPocalypse

It just sounds much better to me… it rolls off the tongue better than “IPcalypse”. Something about that “o” sound makes it sound so much more menacing. Ipocalypse, too, is getting some good play on Twitter.

So what do you think? What should we collectively use?

And yes, I do realize the best choice is probably “neither” and to not engage in the hype… to those out there who wish that the Internet would just go away and that YouTube, Facebook and Twitter would all disappear, I’m sorry to tell you that the Internet will NOT end with the end of IPv4 address allocations. This Internet thing will have a little bit more staying power than that… The existing Internet will continue to function perfectly fine… and NAT will help in many areas… and there’s this IPv6 thing that many folks have been working on for many years now!

However, while the Internet won’t end with the end of IPv4 address availability, there will be challenges for new services to grow and new devices to be deployed if we don’t move to IPv6 addressing. (Now, the good news may be that if your refrigerator can’t get an IP address, it won’t report back to Facebook on how you’ve been snacking when you shouldn’t be! Hmm… although the fridge will probably be on a NAT’d home LAN, so it’s probably okay…)

Still, the media loves a good story and a good bit of over-the-top hype… so whether we like it or not, we’re all going to be going along for the ride…

“IPcalypse” or “IPocalypse”… what’s your choice?

Image credit: pagedooley

Are you creating documentation or examples that use IPv6? Or are you, like me, writing blog posts or other online content related to IPv6?

If so, are you wondering what addresses to use so that you don’t conflict with real IPv6 addresses? Or, if you are using your own addresses, so that you don’t expose your network to attackers?

The answer lies in RFC 3849 where it clearly defines a range for documentation:

The prefix allocated for documentation purposes is 2001:DB8::/32

The result is that any IPv6 address beginning with “2001:db8” will be non-routable on the IPv6 Internet. So you can feel free to use addresses beginning with that in any documentation, examples… or any other content.

Examples could include addresses like:

2001:db8:0:1234:0:5678:9:12
2001:db8:aaaa:bbbb:cccc:dddd:eeee:ffff
2001:db8:42:1af::1
2001:db8:fe58:3efa:deca:212:dd67:c0a9
2001:db8::2

Or any other combination you can come up with. Just remember the “2001:db8” and you’ll be all set. (And upper- or lowercase doesn’t matter.)

Have fun documenting your IPv6 examples!

P.S. There are actually similar ranges set aside in IPv4… know what they are? (Hint: RFC 5737)

Before the media server can talk to the client, both sides have to negotiate the media session description. In Java Media Control API, the media session negotiation is based on SDP offer/answer model.

NetworkConnection in Java Media Control API represents the client connecting to the media server. A NetworkConnection is created when a call is being setup. NetworkConnection contains a Resource called SdpPortManager, which facilitates the SDP negotiation on behalf of the media server.

SdpPortManager provides asynchronous APIs that can generate or process SDP on behalf of the media server. The application must register a MediaEventLister to listen for SdpPortManagerEvent, as discussed in the Event Model. The following table shows the methods and the corresponding returned event types.

Method Name	Description	Event Type
generateSdpOffer	Ask media server to generate a new media session description offer for the client	OFFER_GENERATED
processSdpOffer	Ask media server to process a media session description offer from the client	ANSWER_GENERATED
processSdpAnswer	Ask media server to process a media session description answer from the client	ANSWER_PROCESSED

Typically MsControlFactory is created when the application is initialized, as shown in Driver and Factory. And MediaSession is created from MsControlFactory for each call. In simple IVR applications, the MediaSession serves as the factory for NetworkConnection and other MediaObjects during the life cycle of the call. Make sure you release the MediaSession when the call is terminated.

Here is a sequence diagram that shows how the application uses SdpPortManager to do the SDP negotiation when receiving a SIP based call.

If the INVITE comes with session descriptions (i.e. a SDP offer), sequence A1 will be carried out. Otherwise, sequence A2 will be carried out by sending a SDP offer in the 200OK response.

When ACK is received with additional session descriptions (i.e. a SDP answer), sequence B is carried out first. Otherwise, the call is established and the application can start playing the media to the client.

Here is the code snippet of how the application handles INVITE and ACK, based on SIP Servlet.

  @Override
  protected void doInvite(SipServletRequest req) throws ServletException, IOException {
    if (req.isInitial()) {
      try {
        MediaSession ms = _msFactory.createMediaSession();
        NetworkConnection nc = ms.createNetworkConnection(NetworkConnection.BASIC);
        link(req, ms, nc) // associate SipSession, MediaSession, and NetworkConnection together
        SdpPortManager mgr = nc.getSdpPortManager();
        mgr.addListener(new SdpListener(req));
        final byte[] sdpOffer = req.getRawContent();
        if (sdpOffer == null) {
          mgr.generateSdpOffer();
        }
        else {
          mgr.processSdpOffer(sdpOffer);
        }
      }
      catch (MsControlException e) {
        throw new ServletException(e);
      }
    }
  }

  @Override
  protected void doAck(final SipServletRequest req) throws ServletException, IOException {
    final SipSession ss = req.getSession();
    final NetworkConnection nc = getNetworkConnection(ss); // retrieve NetworkConnection from the session
    final byte[] remoteSdp = req.getRawContent();
    try {
      if (remoteSdp != null) {
        nc.getSdpPortManager().processSdpAnswer(remoteSdp);
      }
      else {
        play(ss);
      }
    }
    catch(MsControlException e) {
      throw new ServletException(e);
    }
  }

Here is the code snippet of how the application handles SdpPortManagerEvent.

  class SdpListener implements MediaEventListener<SdpPortManagerEvent> {
    SipServletRequest _invite;
    SipSession _session;

    SdpListener(SipServletRequest invite) {
      _invite = invite;
      _session = invite.getSession();
    }

    @Override
    public void onEvent(SdpPortManagerEvent event) {
      try {
        EventType type = event.getEventType();
        if (event.isSuccessful()) {
          if (SdpPortManagerEvent.ANSWER_GENERATED.equals(type) ||
              SdpPortManagerEvent.OFFER_GENERATED.equals(type)) {
            final SipServletResponse resp = _invite.createResponse(SipServletResponse.SC_OK);
            resp.setContent(event.getMediaServerSdp(), "application/sdp");
            resp.send();
          }
          else if (SdpPortManagerEvent.ANSWER_PROCESSED.equals(type)){
            play(_session);
          }
        }
        else {
          if (SdpPortManagerEvent.ANSWER_GENERATED.equals(type) ||
              SdpPortManagerEvent.OFFER_GENERATED.equals(type)) {
            _invite.createResponse(SipServletResponse.SC_SERVER_INTERNAL_ERROR).send();
          }
          else if (SdpPortManagerEvent.ANSWER_PROCESSED.equals(type)){
            _session.createRequest("BYE").send();
          }
        }
      }
      catch (final IOException e) {
        _session.invalidate();
      }
    }
  }

In the next Java Media Control API blog, I will show you how to play some music for the client once the SDP is successfully negotiated.

In yesterday’s post about how to configure your home network for IPv6 using an Apple AirPort or Time Capsule access point, I didn’t really mention that the AirPort or TimeCapsule will make IPv6 available for any IPv6-capable devices that connect to the AirPort/Time Capsule via WiFi (or through the Ethernet connections on some of the devices).

This includes the iPad and iPhone! Here, for instance, is what IPv6-test.com looks like on my iPad (with me covering up some IP addresses, of course):

My iPhone 4 generated a similar screen when I visited the site.

On both devices, I was easily able to browse IPv6-enabled websites and check out some of the other “cool stuff” available on IPv6.

Of course, just because the iPad (or iPhone) can get an IPv6 address, that doesn’t mean that iOS applications will work with IPv6. For instance, I used a ssh application and when it connected to a site it was told it was connecting over IPv4 vs IPv6. (The iPad is “dual stack” in that it has both an IPv4 and an IPv6 address.) There was no way I could see in the app to tell the app to use IPv6… so I’m thinking that probably the app is NOT designed to work with IPv6.

Now, the reality is that getting IPv6 access via an iPad or iPhone may not be terribly useful right now… but it’s cool to see that they will work with IPv6. They could also be convenient test platforms to connect to IPv6 sites, simply because of their form factor.

It will be interesting to see how many of the Android and other tablets coming out will also work with IPv6…

Consider my mind blown. I have to confess that I would never have thought of the W3C – a standards organization – launching a branding campaign around HTML5!

Kudos to the W3C for doing something surprising!

And something that is incredibly important… we need to promote HTML5 and all of its related standards because in that direction lies the future of the “Open Internet”. For the sake of innovation… for the sake of competition… for the sake of us all getting better services and better capabilities… we need an open Internet!

And the standards that make up what we commonly call “HTML5″ are one of the key elements of an open Interenet. So kudos to the W3C for launching this campaign… I hope that many sites will use the logo and promote the availability of HTML5-compliant sites. You can download various versions of the logo at (UPDATED WITH W3C LINK):

http://www.w3.org/html/logo/

The page has some great links to HTML5-related resources, too. Well worth a look. You can also purchase T-shirts or request some stickers.

Also, Mashable.com had a post up this morning with comments from the designer and other information.

---

UPDATE: (The W3C does have the logo hosted on their website, but some of the media stories were linking to the Google App Engine site instead of the W3C site.) It seems that all the attention has overwhelmed the Google App Engine account where the logo site was served out of:

One wonders why the W3C didn’t put the logo up on their own web servers, but maybe this was faster/easier for the design firm. Whatever the case, hopefully the site will be back to being available soon…

---

Would you like to get IPv6 up and running on your home network? Do you use an Apple Time Capsule, AirPort Extreme or AirPort Express for your WiFi access point? If so, here are the very simple steps you can take to get set up with IPv6 at home. What you are going to be doing is tunneling IPv6 packets over IPv4. Think of it like a special kind of VPN that you are going to be establishing between your home network and Tunnelbroker.net, which is operated by Hurricane Electric. From Tunnelbroker.net you’ll then connect out to the “regular” IPv6 Internet.

NOTE: This will work with any of the Apple access point devices: Time Capsule, Airport Extreme or Airport Express. However, the instructions below do assume you have the latest firmware, which right now is 7.5.2.

For starters, I’ll go to IPv6-test.com and verify that I am NOT using IPv6 right now (and yes, I’m covering some of the IP addresses in this post):

Now let’s start the process…

1. Register with Tunnelbroker.net

Head over to Tunnelbroker.net and register for a free account if you don’t already have one:

2. Create a new IPv6 tunnel

Once you are logged in, you click on “Create Regular Tunnel”, which will bring you to this page: (I already have created 1 of the 5 tunnels you can create with a free account, so my screen may be different from what you see)

All you really need to do here is copy/paste the IP address you are viewing from into the “IPv4 endpoint” box on the form:

You also need to choose which of the Tunnelbroker servers are nearest to you, but odds are you can just take their recommendation. After entering the IP address and server selection, just hit “Submit” and you’ll have your IPv6-to-IPv4 tunnel all set up on the Tunnelbroker side. Click on the “Tunnel Details” link on the confirmation page and you should see a page like this:

Now you are ready to flip over to your Apple access point and configure IPv6…

3. Connect to your Apple access point

You need to now open the “AirPort Utility” application on a Mac. It is typically found in the “Utilities” folder inside of your “Applications” folder. When you launch it, the app will discover any of your wireless devices and give you the chance to administer them. Select the device you want and then press the “Manual Setup” button in the lower left corner:

4. Open the IPv6 Admin Panel

Next click on the “Advanced” icon on the top and then the “IPv6″ panel tab. You should see a screen that says that IPv6 is currently configured in “Link-local only” mode:

5. Configure the Tunnel

Now you just change the mode to “Tunnel” and enter the information from your Tunnelbroker.net configuration back in step #2. Here are the mappings you need to know from the Tunnelbroker info into the AirPort configuration.

AirPort Utility	Tunnelbroker.net
Remote IPv4 Address	Server IPv4 Address
WAN IPv6 Address	Client IPv6 Address
IPv6 Default Route	Server IPv6 Address
LAN IPv6 Address	Routed /64

The “LAN IPv6 Address” deserves some explanation. This is the range of IP addresses that will be allocated on your internal LAN, and the address you enter here is the IPv6 address of the “LAN interface” of your AirPort device.

Note: I don’t want people on the IPv6 Internet to be able to connect to services running on my AirPort/Time Capsule, so I chose “Block incoming IPv6 connections” so that people on the IPv6 Internet could not connect directly to my device.

Reboot and Revel In Your IPv6-ness!

After you press “Update”, your AirPort device will reboot and when it comes back up you should just be able to browse with your WiFi connected device to IPv6-test.com and see that you are now live on the IPv6 Internet:

Congratulations! You now have IPv6 on your home network!

So Now What?

Okay, so now you have IPv6… what can you do with it? Well… you could visit Google via IPv6 … or Facebook … or any of a range of other IPv6-enabled websites… or check out some of the “cool stuff” for IPv6 identified by Sixxs… or connect over IPv6 to services running on IPv6-enabled servers that you are testing out. Or you could expose services you have running locally out over IPv6 (see caveat below). Or… you could just use IPv6 at home to learn about IPv6… sooner or later we’re all going to need to know more about it.

Two Critical Caveats

Two important things to think about with using this setup:

1. Tunnelbroker.net relies on a static IPv4 address on your end

For the IPv6-to-IPv4 tunnel to work, Tunnelbroker.net assumes your home IP address will not change. For most of us in the US, anyway, that’s not a safe assumption. If your IPv4 address changes, you have to either:

a. Login to Tunnelbroker.net and manually update the info in your tunnel configuration; or
b. Use the URL provided by Tunnelbroker to update your IPv4 endpoint (details at the link).

Those who want to figure it out could create a script that would notice the IP address changing and ping that URL automagically. (Mine doesn’t change enough – and I don’t rely on IPv6 enough – to go through the work. It did happen once that IPv6 wasn’t working, so I just looked at my external IP and then went and manually changed the tunnel info.)

2. Do think about security – you have a live, PUBLIC IPv6 address

You do have a public IPv6 address. Right now there may not be hordes of attackers out there trying to hit IPv6 systems (or there might be)… but do realize that you are on the public Internet (albeit the IPv6 side). There is a IPv6 Firewall part to the AirPort devices. You will want to look at that if you are going to make services available over the IPv6 network. You may also choose to do what I do and simply block all incoming IPv6 connections.

One Final Note

To make this work, your AirPort device does not need to be directly connected to your Internet gateway or cable/DSL modem. In my case, I have a Linux server that is connected to the Internet and is providing a firewall and NAT to my home network. My Time Capsule is then behind that gateway/server on my NAT’ted internal network. What I’ve outlined here still works, though – and I didn’t have to configure anything on the firewall/server. You may or may not need to if you have a similar configuration.

With that, I’ll say… enjoy! And know that you are now one of the folks getting ready for the next stage of Internet evolution!

Most of Java Media Control APIs are asynchronous. The Java Media Control applications are typically event driven. So it is important to understand Java Media Control API’s event model.

There are three entities in the event model, as illustrated in the diagram. MediaEvents are sent by MediaEventNotifier to registered MediaEventListeners. A MediaEventNotifier can have multiple MediaEventListeners.

The following table lists the types MediaEventNotifier in Java Media Control API and the type of MediaEvent each one generates. Italic name indicates the MediaEventNotifier is a MediaObject. Bold name indicates the MediaEventNotifier is a Resource.

Types of MediaEventNotifier	Types of MediaEvent
MediaMixer	MixerEvent
Player	PlayerEvent
Recorder	RecorderEvent
SdpPortManager	SdpPortManagerEvent
SignalDetector	SignalDetectorEvent
SignalGenerator	SignalGeneratorEvent
VideoRenderer	VideoRendererEvet
VxmlDialog	VxmlDialogEvent

In Java Media Control API, the event model is strong type. MediaEventListener is a Java Generic interface. Typically the implementation narrows down to a particular event type.

A successful event indicates the operation that triggers the event succeeded. Otherwise, MediaErr can be retrieved from the event. Each event has a EventType to indicate the nature of the event.

The events from a Resource are ResourceEvents. Each ResourceEvent has a Qualifier to provide additional context about the event. ResourceEvent also has a Trigger to indicate how this event is triggered.

In  the future blogs, I will talk more about each type of MediaEventNotifier, its operations, and corresponding EventType, Qualifier, and Trigger.

In setting up IPv6 on my home network, I naturally wanted to find an easy way to test out my IPv6 connectivity and see if it worked. While I’ve used a whole number of sites over the past year or so, I recently stumbled upon a very simple and easy service at:

http://ipv6-test.com

When you visit the site, it will test whether you have IPv6 and IPv4 connectivity from the browser you are using to visit the site.

Here’s what the page looks like if you are running IPv6 (with my actual addresses covered over because I’m a paranoid security guy):

You can also do a “speed test” for both IPv6 and IPv4. I found my IPv6 speed was only slightly slower than my IPv4 speed, but that would make sense since I’m using Tunnelbroker.net to tunnel IPv6 over IPv4 from my home network out to the native IPv6 cloud.

Anyway, ipv6-test.com is a useful site for those of you experimenting with IPv6.

Any other test sites you like to use?