[e2e] Discrete IP

[Timothy J. Salo]

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
   Internet.

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...

-tjs