An assortment of ideas about transitioning from the IPv4/6 Internet to a Nimrod Internet.
To start, there are two broad scenarios. One is supporting legacy IP devices in a Nimrod world and the other is figuring out how Nimrod devices could communicate before the rest of the Internet figures out the Right Thing. The first is easier but the latter is probably more important in allowing the gradual adoption and spread of something so radically different.
So I'll take the easier scenario first. This imagines that the Internet is running Nimrod but you have either individual hosts or even a whole network of computers still running IP (v4 or v6) only. There are also two scenarios here: the hosts are clients only or the hosts are servers.
For machines that are clients, the answer is NAT with protocol translation - ought to be straightforward enough. Outgoing DNS requests are intercepted and converted to some sort of Nimrod Naming equivalent (okay, I'm not exactly sure how that part works), an IP address is allocated, and mapping tables setup to forward TCP and UDP packets from the Nimrod side to the IP side and vice versa.
Servers need to be advertised in the Nimrod naming tables and maps but with destination information that points to an appropriate NAT device that handles the conversion. With appropriate flexibility added to the naming system, this ought to be straightforward.
To start, this is by far the most important transition direction. The core of the Internet is not going to move over to an entirely new protocol suite before substantial pressure comes from somewhere. That's only going to happen if a lot of people are running Nimrod and it's proven to work and to solve real problems that people have.
So, to start we're going to have hosts at the network edges that want to run Nimrod to communicate with each other, but they need to use the existing IP based Internet to do so.
Much like the NAT-PT for supporting legacy IP over Nimrod, there'd need to be a NAT-PT in the other direction here. Although, it could be running on the host itself rather than as a separate NAT box.
So the NAT code would take Nimrod name requests and do lookups in the DNS. It could try to present the DNS as a two-step lookup process like Nimrod but it's probably easier to just do it all with one. Names that look like DNS names get the answer from DNS while names that look like Nimrod names get a Nimrod lookup.
The short answer to how to do this is that we simply treat the IP Internet as a Nimrod subnet that doesn't have broadcast capability. The details of how to do this need to be worked out.
The IP Internet has a lot of structure that's mostly invisible to hosts. That's quite a bit different from how Nimrod works. As different Nimrod machines communicate over this IP based subnet, they can trade IP addresses of other Nimrod nodes they know about. Then the host can use traceroute-like technology to investigate that connectivity and create a Nimrod map for the Internet.
I think the big thing Nimrod gives to early adopters is multi-path routing and automatic fail-over. So if you had two connections to the Internet, those could be explored separately by the Nimrod code. Put a Nimrod packet forwarder near each exit point and then Nimrod hosts within your site would be able to route out whichever path looked best to the Nimrod routing code.
last updated: Wed Oct 31 15:13:06 2012 by David Bridgham