[e2e] Discrete IP
Timothy J. Salo
salo at saloits.com
Sat Sep 15 13:04:06 PDT 2012
On 9/15/2012 8:57 AM, Pars Mutaf wrote:
> For example me, I want to use IPv9 in my country and for this I am ready
> to pay the following processing cost for each packet:
> IPv4 packet comes in.
> I remove the header.
> I replace it with a IPv9 header.
> I route the packet.
> (and vice versa)
Of course you can do this. The IETF does precisely this with, for
example, the 6lowpan protocol. The principal difference is that
the IETF isn't going to call 6lowpan a new version of IP.
As the IETF 6lowpan work has shown, there are some good reasons for
running another network layer protocol within a network. In the case
of 6lowpan, it is to create a network protocol that works with very
small frames, very little bandwidth, no inexpensive multicast, nodes
that sleep much of the time, and a few other constraints. Of course,
this is the IETF, so we don't view 6lowpan as anything other than IPv6,
although a typical IPv4/IPv6 router will choke on a 6lowpan packet.
As the 6lowpan work has shown, there are a lot of challenges to
running your own private network protocol. Here is some of the
challenges that come to mind, although there are others:
o Your private protocol has to be close enough to IPv4 and/or IPv6
that you can reasonably translate between IPv4/IPv6 and your private
protocol. I assume that you want your private protocol to
interoperate (through gateways) with the global IPv4 and/or IPv6
o Gateways have to maintain a bunch of state to support the mapping
between IPv4/IPv6 and your private protocol. Some of this mapping
can be static (e.g., 6lowpan's static mapping between port numbers),
although some of this information is dynamic. For example, your
gateway has to maintain mappings between IPv4/IPv6 addresses and the
addresses you are using internally. There is a bit of tedium to
maintaining these mappings. (Personally, I think this translation
might work better if the gateways maintain even more state. This
might be a good research topic...)
o You have to figure out what to do about naming. (6lowpan pretty
much punted on this.) Will your network use the existing DNS
system? How will IPv4/IPv6 hosts learn the name and the IPv4/IPV6
address of your hosts. Oh, and how will IPv4/IPv6 addresses be
assigned to your hosts, since the existing Internet won't be able
to route to your private addresses. I assume that you aren't going
to use IPv4 or IPv6 addresses internally. What will happen when one
of your hosts requests the address of an IPv4/IPv6 host? Will this
address need to be translated into an internal address? If so, where
is this translation done?
o All of this stuff works much better if your network is an edge
network. Trying to be a transit network for IPv4/IPv6 traffic
probably gets pretty hard.
o What are you going to do about higher-level protocols. For example,
will your hosts implement a pretty standard TCP? If not, will your
hosts interoperate with IPv4/IPv6 TCP hosts? You can certainly
translate between TCP and your own favorite transport protocol, but
your protocol has to be close enough to TCP for a reasonable mapping
to be possible. There has been quite of bit of work done on this
topic; start with "performance enhancing proxies".
o How are multiple gateways going to work? A gateway has to maintain
a bunch of state: at a minimum address mappings. Will you support
multiple gateways? If so, will they work well? Will you try to
synchronize state between all of your gateways? Or, if a flow
moves from one gateway to another, do you start a process that will
create the state in the new gateway? Can you make movement between
gateways invisible to your hosts? To your transport protocol? To
your application? Will you handle asymmetric routing (in through one
gateway and out through another)? Will you permit a flow to be
distributed among multiple gateways simultaneously?
You might want to thoroughly examine 6lowpan and understand what it
does, what it doesn't do, and what it doesn't do, but could.
In my view 6lowpan is sort of an initial, fairly limited attempt at
translating between IPv6 and a private network protocol. It turns out
that this translation is difficult to do well. I believe that this
topic of how to translate between IPv4/IPv6 and a private network
protocol, and maybe private higher-level protocols, would benefit from
some comprehensive thought: there are a lot of existing techniques that
have been developed, but I don't think that they have been pulled
together into one integrated solution.
One lesson from the 6lowpan work is that all of this is easier to
sell if you call your new protocol an optimized or an enhanced version
of IPv6, rather than a new version of IP...
More information about the end2end-interest