[e2e] Discrete IP

[Pars Mutaf]

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.



>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20120916/ef6e0d78/attachment-0001.html