An RFC from the IAB -Reply

[Radia Perlman <[e-mail]>]

Actually, there's a lot I disagree with in the RFC. First of all, I don't quite understand the purpose of it. Is it to
push IPv6? (If so, it's kind of weird because one of the strongest worded points is that a single network layer
protocol is essential to internetworking). If not that, I absolutely have no idea what its purpose is.

I don't believe that having a single protocol at the network layer is the key to internetworking, nor that it will ever
happen, nor that it is necessary in order for the internet to work. For instance, IPv4 and IPv6 are different
protocols, as different as IP and CLNP, or IP and Appletalk, etc. IPv4 will not go away for years. There's a
tendency in the IETF to view IP as  "religion" rather than a protocol -- they want it to take over the world, they
are worried about any mindshare that, say, ATM might have. It's kind of like having tried to take a stand on
Ethernet vs token ring. Life would be simpler if there was only one type of technology, but various types of
things will spring up, and what we should do is make everything work together, not try to squash things or claim
that we can't make things work together.

Technologically, there's no problem with having a multiprotocol backbone, or a backbone that is purely IP with
corporate networks behind firewalls with non-globally unique IP addresses, or some totally different network
layer protocol, with the firewall dynamically handing out TCP ports and presenting the entire corporate network
to the internet as a single IP address (or a few, if there's not only clients in the corporate network, but services
that need to be reachable from outside). There's not that much difference between having different network
layers in operation than different data link layers, or different Transport layers. WIth a firewall translating
addresses, there's nothing intrinsically harder about translating from something other than IP to IP than from
translating from IP to IP.

I'd think consistent names is even more important than a single addressing scheme, but even for names I
wouldn't want to claim that internetworking was impossible without it. Certainly we'll wind up with a totally
different name space springing up for email than for VISA principals, not that it's necessarily desirable for the
names to be different.

In terms of saying things ought to be end-to-end -- again, generalization is a problem. Multicast requires routers
to keep state. RSVP requires routers to keep state. There are times when it is desirable to have firewalls keep
state, and have email services that happen at places other than end-to-end. Again, what is the purpose of
putting out an RFC saying that things should be done end-to-end? Is this to educate people on how to design
protocols? If there were a specific example, such as that "security is best done end-to-end" it would be
reasonable, but in general it's not correct to say everything must be done end-to-end.

Basically, I think the strength of the IETF is being able to allow lots of things to flourish and figure out how to
make things work together. Experiment with things. Deploy things. See what works. Throw out what doesn't.
Within reason, of course. Adopt and work with protocols, even if they were not invented here, even if they have
a different flavor (as in being connection-oriented) than what we're used to. In the real world people are faces
with lots of seemingly incompatible stuff. Rather than viewing anything other than IP as evil and competition, we
should be the organization that helps people in the real world get all their stuff working together. We will wind up
being more useful and powerful as an organization as a result.

Radia