All things considered, I'd rather be in Pittsburgh

or - what I saw at the 48th IETF in Pittsburgh, July 30 to August 4, 2000

First, some personal matters:
As of August 1 (coincidentally, the second day of this IETF meeting), I am now a consultant with Cisco Systems, and my work email is now alvestrand@cisco.com.
However, this note does not represent a company position in any way, shape or form - given how new I am with the company, it will take me quite a bit of time to figure out what the company position is!
And I intend to make sure the harald@alvestrand.no address remains viable for a long time yet.

The quote from Ezra Pound's gravestone in the title seems strangely appropriate, but maybe in a different way from the author's intention. The centre of Pittsburgh today is a strange mixture - lovingly restored churches and brownstones, gigantic office towers intermixed with older buildings that seem to remain standing mostly out of habit - the architecture seems to reflect the checkered history of the economy of this city.
But Pittsburgh of today is certainly a city worth visiting - and the direction of the economy seems "up".
Not that we spent much time studying the architecture - most IETFers seemed, as usual, to concentrate on the meetings, rushing out to meals and rushing back to the next meeting. Sometimes I wonder whether we should hand out warning flyers to the restaurants before we hit them....
 

Drama ongoing: Instant Messaging doesn't get the message

In the ongoing media war between the AOL "monopoly" and the Microsoft+allies "underdog", the IETF is one battlefield among many. AOL simplified the battle by choosing not to offer a proposal for the IETF; that meant that we were only left with 3 or 4 proposals that were technically sound, backed by reasonably committed groups of engineers, and completely impossible to merge.
The lead proposals seemed to be IMXP, growing out of a traditional "Internet engineer" grouping led by such well known and not uncontroversial figures as Marshall Rose and Dave Crocker, and proposing an entirely new protocol with some nice engineering; the other team, with strong ties to the voice-over-IP industry, suggested building on the framework of the runaway-successful SIP (Session Initiation Protocol) to create the basis for this new application.
At the end of the meeting, a few facts stood out: The area directors and working group chairs at last punted, suggesting that a 3-man team from each "camp" prepare detailed proposals on a very short timescale (2 weeks). The next round is forthcoming!

Of course, IETF delay serves the nonstandard monopolist in this matter. Something will give.
 

The Hammer-of-the-month prize goes to....MPLS!

The Multi-Protocol Label Switching protocol/architecture/suite is a mechanism to move packets more efficiently through a network, by making sure the switches (not quite routers) in the middle of the network can do simple lookups on short identifiers, rather than doing longest-prefix match on long ones.
The resulting architecture bears a resembleance to ATM, in the same way that Frame Relay resembles X.25: Most of the extra bells and whistles are gone, just the model remains.

It's been popular with many service providers for a while, and as with all tools that fit a need, people are looking at other things it might be useful for.
One suggestion is provisioning of virtual private networks (VPNs); if this network has customers on different providers' networks (a common case), this of course requires the interconnection of multiple MPLS clouds.

Question: What is the difference between a subnet layer and the Internet?
Answer: The Internet can reach any customer, anywhere.
Question: When you can do MPLS to any customer, then....?
Answer: Oops....

Scaling a system based on hop-by-hop identifiers to Internet scale does not seem trivial. It's an useful tool, but may be stretched beyond its natural usefulness.

The news that someone had suggested carrying MPLS over IP in order to get between service providers was greeted with a storm of suggestions for other "interesting" stacks one could builld - the one I remember best is MPLS over IP over IPSec over IP over ATM over IP over HTTP.....all of these are suggested, built or already in production somewhere in the Internet..and it was not the longest one.
 

Spaghetti junctions on the Infobahn (with tollbooths)

There seems to be a growing tendency to depend on tunnels in the modern Internet.
We've got encryption tunnels using IPSec or SSH, VPN tunnels using IPSEC, L2TP or GRE, service tunnels for multicast and IPv6, special-purpose tunnels for routing info and other things.
This is one instance of "boxes in the middle" - things that are interested in doing other things to packets than merely get rid of them ASAP. Other examples are TCP ACK finaglers, NAT boxes, "transparent" webcaches, DNS-based source optimizers and the "anycast" approach to service provisioning.
The IAB is worried enough about this that it's spending some time at a workshop worrying aloud about them.

¥æÛ and other interesting names

What's in a name?
For the longest time, the Internet has been getting along on a strange theory: That the characters a-z,  0-9 and the dash were enough to name anything that needed global names (that is, DNS names).
This worked great for most names that were in English, and for a lot of others - especially if you were willing to use names that just vaguely resembled the "real" name of the referred-to object..
But once the bizarre idea that an Internet nametag "should" belong to someone who was using the name for something in Real Life, it was a very short step to the conclusion that names that didn't fit into the model of A-Z also "deserved" to be represented in domain names.
Once the first instance of this idea turned up, it was not long before others jumped on the bandwagon, and now there are more than a dozen companies registering domain names tthat have non-ASCII characters in them.
However, there are some problems. And so on and so forth. Like with some other thorny issues, "if you aren't scared, you don't understand the problem".
The IDN working group has been looking at this for a while now. A lot of people have looked at the problem too (like the ICANN DNSO ccTLD forum), and decided it¨s our problem. They won't move until we do.
But we'd better get something that works soon. And get it right.

It looks as if we know what the best solution we can make based on the DNS looks like.
But if that doesn't work well enough - we have to try something else.
 

Throwing multicast around

It would not be fair to call multicast a roaring success.
Still, having a single box send a video stream to 10.000 other boxes does not work very well.
There are multiple alternatives: The last alternative doesn't sound right. There are many other things to use multicast for than 10.000 TV channels.
But the most effective way to deploy multicast is probably that seen in the Netherlands: Put the TV stations on the multicast backbone, and post instructions on how to get connected to it.

Content is king.

IPv6: The absence of alternatives....

....clears the mind marvellously.
Everyone realizes that the IPv4 model doesn't work for mobile phones.
And the walled garden approach taken by the current WAP specification has already proved itself too painful for words. (the DoCoMo IMode service in Japan is a success - perhaps mainly because it focuses on content, not technology. Content is king.)

And Perry Metzger claims that he can now use an IPv6-only box for something useful, something that was impossible 6 months ago. Progress!
 

DNS security: Not a done deal

OK, we know how to put digital signatures into DNS records.
From there to a secure DNS service involves a number of steps, some of which were noted in previous notes in this series.
The calculation of the week was this:
If it is required to put an NS record, an A record, an A6 record, a NXT record, SIG records and a KEY record for all of these into a DNS packet, how many nameservers can you list within a 1280-byte packet?
The answer seems to be on the order of four.
Oops. Perhaps increasing the default max buffer size from 512 bytes to 1280 bytes won't solve all the world's problems after all.
OTOH, if the current experiment with "anycast DNS servers" (draft-ietf-dnsop-ohta-shared-root-server-test) works well enough, perhaps we won't need 13 root server names in the packets anyway?
 

Rumours, factoids, nibbles, teasers...

did you know that....


It's time to get this document distributed. So I won't say anything more.
Enjoy!