[e2e] Discrete IP

Sun Sep 16 07:08:39 PDT 2012

On Sun, Sep 16, 2012 at 3:07 PM, Ralph Droms (rdroms) <rdroms at cisco.com>wrote:

>
> On Sep 16, 2012, at 1:21 AM 9/16/12, Pars Mutaf wrote:
>
> > Hi Timothy,
> >
> > Please see in-line.
> >
> > On Sat, Sep 15, 2012 at 11:04 PM, Timothy J. Salo <salo at saloits.com>
> wrote:
> > 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.
> >
> > I am not sure to understand the similarity with 6lowpan. 6lowpan is IPv6.
> > I am talking about using any IP version.
>
> The principles in Timothy's post are correct; 6lowpan isn't such a great
> example.  NAT64 is a better example.  Sure, you can replace an IPv4 header
> with an IPv6 header.  That's what layered design and architecture is about,
> right?  But there are many little details that keep NAT64 from working well.
>

How TCP works over NAT64? I can't find doc on this but it sounds different
than what I mean.

In my proposal TCP doesn't work because TCP assumes that the source and
destination addresses have the same IP version.
My proposal needs an additional host identification layer above IP. It is a
different and long term solution.

I propose that we add new Internets to the current one. A new IPv4 Internet
(reusing the same IPv4 space, you can reuse yahoo's address at home for
example), IPv6, or IPv7 Internets. We can reuse IP addresses because hosts
are not identified using IP addresses anymore.

If you want to be able to reach new Internets, implement Discrete IP.

A host implementing Discrete IP does the following:

If the destination host is in the current Internet, use normal IP.
If the destination host is in a new Internet (IPv4 or IPv6 or IPv7), use
Discrete IP.

Details are in the paper:
http://www.scribd.com/doc/105448105/Discrete-IP

>
> - Ralph
>
> >
> >
> >
> > 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.
> >
> >
> > Yes we will change the IPv4 header and replace it with a IPv6 header and
> vice versa.
> > Or IPv7.
> >
> >
> > 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...)
> >
> >
> > This is my problem. Again, what is this illusion that you can take
> design decisions for me?
> > ***Enable technology instead***
> >
> > No one asked you to design my IP. ***Enable technology instead***
> >
> > Discrete IP is one way to enable IP technology. If there were Discrete
> IP today,
> > many people would be using IPv6 already and doing research on new IP
> versions
> > freely (without touching the IPv4 Internet).
> >
> >
> > 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?
> >
> >
> > DNS needs modification probably, we also need a new identifier.
> > This is much better than changing the whole Internet. Do not touch the
> > existing core network, change the end-nodes instead.
> >
> >
> > 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".
> >
> >
> > TCP will probably change. Again, this is better than changing the whole
> > core Internet and disabling technology. IETF made a mistake 20 years ago.
> > The right way to save the Internet was not Inventing a new IP
> > version, it was reviewing the IP architecture. Saying that it is now too
> late is
> > a technology blocker approach.
> >
> > TCP assumes that source and destination addresses have the same IP
> version.
> > We need another identification layer above IP. A new global identifier
> which is
> > not used for routing. We all know since long years that IP address is
> not an
> > identifier.
> >
> >
> > 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?
> >
> >
> > Ideally, everybody takes care about their own network. There is no
> global design, no global
> > decision for others. I don't know yet about all details.
> > My question here for the moment is "What is good for the Internet?"
> > Discrete or Continuous IP?
> >
> >
> > 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...
> >
> >
> > I am not sure to understand the similarity with 6lowpan. 6lowpan is IPv6.
> > I am talking about using any IP version.
> >
> >
> > -tjs
> >
> >
> >
> >
> > --
> > http://www.content-based-science.org
> >
>
>

-- 
http://www.content-based-science.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20120916/6453bf0a/attachment-0001.html