Subject: [5gangip] Introducing: Brand-new Internet Protocol "Five Fields"

From: Alexey Eromenko <[email-masked]>
Date: Mon, 14 Dec 2015 23:00:39 +0200

Hi all,

I have created a new Internet Protocol "Five Fields".

Why ?
Because IPv6 is hard to use, and I wanted to keep look & feel similar
to IPv4. Problem with IPv6, is that those addresses are very hard for
humans to remember, compare and visualize topologies in human brain.
IPv4 has great look & feel, but it is exhausted. So I wrote a new
replacement for IP.

I did it, because I don't like to work with something long like this:
   2001:db8:2e1:1a73:149f:88ff:fe81:6116

And it would be better, if we work with simpler addressing:

      192.168.510.971.11

      10.0.0.0.1

      382.201.769.25.133

Draft spec. available.

"Five Fields" offers 0...999 in each field, in dotted decimal
notation, and includes unique features not found *anywhere else*.
10-bits x 5 fields.

- x230,000 times larger address space than IPv4 (should be enough for
several hundred years, including IoT)
-Mobile TCP, allows moving Mobile Nodes between subnets, without
losing connectivity. A replacement for Mobile IP. An order of
magnitude simpler, and requires no access to routers and
configuration-free.
-IP-VRF header extension, allows doing VRF-VPN without MPLS (and
without dot1q VLANs)
-Super-lightweight, and should be faster than IPv4 or IPv6 by 1%-2%.
Small overhead.
-UDP/IP overhead is 28 bytes; UDP/IPv6 overhead is 48 bytes, but
UDP/IP-FF overhead is just 26 bytes ! Even shorter than the original,
yay !
-Simpler to implement than IPv4/v6, because no fragmentation. MTU path
discovery is the way to go.
-No broadcasts.
-No IP header checksums (done at layer 4)
-No autoconfiguration/SLAAC (this belongs to DHCP territory)
-No IGMP required (it is optional now for Multicasts)
-No Layer2 resolution. ARP-free protocol.

I believe, that it is superior to both IPv4 and IPv6, simpler than
both, and intended as a replacement for both. Substantial improvement
on both.

This draft specification describes various parts, the protocol itself,
addressing scheme, Address Resolution Algorithm (without ARP), DNS
extensions, Mobile TCP, and more...

Draft spec download here:
https://www.dropbox.com/s/mbyjo5da5zgi4kp/IP-FF-2015-12-10.zip?dl=0

IP-FF is about:
 o  Short, human-readable addresses
 o  Modularization of some perceived IPv6 bloat
(NDP/IGMP/MLD/IPsec/SLAAC/Flow/...)
 o  New features: IP-VRF and Mobile TCP, TCP Anycast.
 o  Optimization: UDP/IPFF combo is just 26 bytes. Almost 50% cut in
overhead vs IPv6. And no ARP.

Please take a look, and see how good it is.

If anybody would like to help me promoting this new protocol and
implement it in code, feel free to write to my email.

My proposal draft.
In seven parts.

1. Internet Protocol - Five Fields:
https://datatracker.ietf.org/doc/draft-eromenko-ipff/

2. Internet Protocol - Five Fields: Addressing Architecture
https://datatracker.ietf.org/doc/draft-eromenko-ipff-addressing/

3. Internet Protocol - Five Fields: ICMP
https://datatracker.ietf.org/doc/draft-eromenko-ipff-icmp/

4. Internet Protocol - Five Fields: Link Address Resolution Algorithm
(ARP replacement)
https://datatracker.ietf.org/doc/draft-eromenko-ipff-lara/

5. Internet Protocol - Five Fields: Mobile TCP (Mobile IP replacement)
https://datatracker.ietf.org/doc/draft-eromenko-ipff-mops/

6. Internet Protocol - Five Fields: DNS extensions
https://datatracker.ietf.org/doc/draft-eromenko-ipff-dns/

7. Internet Protocol - Five Fields: UDP modification
https://datatracker.ietf.org/doc/draft-eromenko-ipff-udp/

Best wishes,
-- 
-Alexey Eromenko "Technologov" (from 10.Dec.2015)
[email-masked]

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 14 Dec 2015 17:07:16 -0600

Folks,

I suggested Alexey to post his ideas on our list since we are
interested in the next generation IP protocol suite.

Here he does have a proposal. They may be only a bit different than
the current IP stack but who knows, the next generation may come as an
evolution not necessarily as a revolution :-)

Behcet

On Mon, Dec 14, 2015 at 3:00 PM, Alexey Eromenko <[email-masked]> wrote:
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 14 Dec 2015 19:19:27 -0800

I have to confess that yet another attempt to reinvent IP does not grab
me.  But so be it...

Suggest, while you're in the frame of mind: a next generation transport
protocol.

TCP has been remarkably durable despite known defects.  It's outlasted
several wannabe replacements.  So, first, why should we worry about a
next generation transport protocol?

1.  Reliable multicast.  TCP cannot be expanded from it's unicast state
without breaking it.  But with radio network segments in the internet,
the payoff for multicast increases considerably.
     A great deal of traffic is/can be multicast in nature.  But today
we either UDP spray it out there without reliability protection or we
open multiple unicast TCP connections.  Neither of which sound good in
anything past near term duct tape affairs.  

2.  Inherent security.  TLS (aka SSL) has been grafted onto TCP ... can
we do better?  In particular, a nextgen transport protocol must have
better resistance to syn-flood type of attacks.

3.  QoS sensitivity.  Right now TCP reacts to dropped packets as
evidence of congestion.  And it's reaction is to tighten credit windows
to ease the congestion and at least not be a contributor.  This
one-size-fits-all has been a rather poor one size for an all-terrestrial
internet where we've generally overprovisioned.  But with the advent of
radio networks, especially radio-WANs in the interior of the internet,
we need something a bit more versatile.  

4.  Early open.  Vintage TCP passes syn, ack-syn, ack packets across the
internet end-to-end and that handshake has to complete before the first
byte of real data passes.  This contributes enormously to latency in
situations where there is significant propagation delay (e.g. satellite
throws).  Prototypes that piggyback data onto the syn/ack packets have
been around.  They are particularly useful for short messages that can
fit into a single TCP PDU.

Over the years, implementations that incorporate some of these
requirements have appeared ... and generally slid into obscurity.  A
replacement that gets uptake in the industry should, IMHO, incorporate
all these improvements, not just one or two.  And flexibility to 'tune'
the protocol (short of recompiling it) would help, methinks.

What say?

b

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Tue, 15 Dec 2015 07:21:44 +0000

Hi list,

This looks to me like Fools’ Day, but exactly 2 weeks ahead of time. Why? In Spain, we celebrate Fools’ Day on the 28th of December. I don’t see the point in yet another protocol proposal when IPv6 is just taking up. I’d rather say it could back-fire and…
Add yet another layer of NAT, so why don’t we propose the IPv4 NAT^n architecture based on X.25 with 128kbps links?

Season’s greetings and best wishes for 2016
---
Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation
email: pedroa d0t aranda At telefonica d0t com
Telefónica, Investigación y Desarrollo
C/ Zurbarán,12
28010 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.
Fragen sind da, um gestellt zu werden.
Georg Kreisler

-----Mensaje original-----
De: 5gangip <[email-masked]> en nombre de Alexey Eromenko <[email-masked]>
Fecha: lunes, 14 de diciembre de 2015, 22:00
Para: "[email-masked]" <[email-masked]>
Asunto: [5gangip] Introducing: Brand-new Internet Protocol "Five Fields"

>IPv4 has great look & feel, but it is exhausted. So I wrote a new

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Dec 2015 08:57:54 +0100 (CET)

> I have to confess that yet another attempt to reinvent IP does not grab

I have been involved in trying to get IPv6 deployed at ISPs for close to 
10 years now. As far as I can tell, the standardization work is 20 years 
old. To me, trying to re-do this again now, when IPv6 finally has started 
to gain traction is not something that seems reasonable.

However, there is one part of the proposal from Alexey that I like:

"-Mobile TCP, allows moving Mobile Nodes between subnets, without
losing connectivity. A replacement for Mobile IP. An order of
magnitude simpler, and requires no access to routers and
configuration-free."

I wouldn't want this to be only for TCP, but for all protocols. Basically, 
mobile nodes should be able to handle their own mobility for all 
protocols. This can be done either by tunneling (which I want to avoid) or 
by having temporal radio overlap of a few seconds when there is handover, 
enough to be able to tell other end that "I'm moving, new address here:", 
something along the lines of SHIM6, or in case of MP-TCP, this can be done 
at the transport protocol itself.

Currently, 3GPP network relies on the network moving a tunnel around 
between base stations, and the endpoint address is kept the same. However, 
bulk of the traffic today is video that is split up into smaller chunks 
and fetched on demand. This traffic doesn't have to be mobile (it could 
be), instead the mobile device could just start requesting the chunks from 
the new address. Traffic that needs address stability would have to be 
tunneled, but this tunnel could be handled by the mobile node itself 
towards a central tunnel server, it doesn't have to involve the access 
network.

So there are a few things that would need to happen:

When connecting to a new access type, access needs to be established 
quickly, the IP layer would probably need to be established sub-second 
(RS/RA is probably enough).

Mobile devices would need to support logic to send traffic that is 
endpoint address flexible direcly over the network, and tunnel traffic 
that needs a stable endpoint address.

... other things, but that of course would need to be investigated 
further.

So when this is done, network access is mostly about authentication. Here 
it could also be simplified by means of a cryptographic token that might 
be valid for an hour or so, then the access layer wouldn't even need to 
talk to a central authentication server for each access attachment 
request, instead it just checks the validity of the cryptographic token 
(signed by someone it trusts), and would give immediate access.

Above is mostly for "bulk Internet access", other use-cases might require 
more functionality than this, but my take is that the IETF should focus on 
making transport protocols endpoint address independent. My user 
experience with for instance MOSH (https://mosh.mit.edu/) is exactly what 
I'm looking for, I open my laptop, it connects to the wifi, and before I 
am able to unlock my screen, mosh is already connected and I see my shell 
window and can start typing. Brilliant. All protcols need to behave like 
this.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexey Eromenko <[email-masked]>
Date: Tue, 15 Dec 2015 10:17:24 +0200

On Tue, Dec 15, 2015 at 9:57 AM, Mikael Abrahamsson <[email-masked]> wrote:
> I have been involved in trying to get IPv6 deployed at ISPs for close to 10
> years now. As far as I can tell, the standardization work is 20 years old.
> To me, trying to re-do this again now, when IPv6 finally has started to gain
> traction is not something that seems reasonable.
>
> mobile nodes should be able to handle their own mobility for all protocols.

Well, my module is called "MOPS - MObile Protocol Stack" - and
theoretically supports any Transport Layer Protocol with 16-bit ports.

It already supports standard operation and Source NATs, but I need to
write specification for destination NATs (and maybe optimize Source
NATs).

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Dec 2015 11:27:10 +0100 (CET)

> write specification for destination NATs (and maybe optimize Source 

5G should be IPv6 only, with IPv4 as a service. Please do not involve NAT 
in this, apart from that IPv4-as-a-service AFTR.

---

From: Alexey Eromenko <[email-masked]>
Date: Tue, 15 Dec 2015 12:32:24 +0200

On Tue, Dec 15, 2015 at 12:27 PM, Mikael Abrahamsson <[email-masked]> wrote:
>> write specification for destination NATs (and maybe optimize Source NATs).
>
>
> 5G should be IPv6 only, with IPv4 as a service. Please do not involve NAT in this, apart from that IPv4-as-a-service AFTR.

IP-FF, is an alternative to IPv6.
I write specs only for IP-FF.

-- 
-Alexey Eromenko "Technologov"

---

From: <[email-masked]>
Date: Tue, 15 Dec 2015 14:33:03 +0000

Hi all,

a replacement of IP(v6) is a challenging job ;-)
I absolutely agree with Mikael addressing issues from a customer point of view. What do we need for a fast or seamless handover between different networks for example? Lets focus on the transport layer and decouple the service from the interface addressing. As Mikael mentioned there are some solutions available that could be useful in the context of 5G. Let's focus on identifying the open issues for 5G here. 

I think IPv6 will be a the standard feature in 5G especially if we talk about a time frame of 5-7 years.

Br,

Ruediger

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Tue, 15 Dec 2015 15:13:00 +0000

Hi Rüdiger,

Do you actually see an end user writing an IPv6 address anywhere? I’m dual stacked and when I have reliable IPv6 connectivity, I tend to use IPv6. And I have not written an IPv6 address for the last 10 years.

Anyhow you are absolutely right… let’s focus on 5G issues here :-)

---

Technology Exploration -

---

From: Alexey Eromenko <[email-masked]>
Date: Tue, 15 Dec 2015 17:26:15 +0200

Read my MOPS spec. I will work to improve it, to support destination NAT.

You say IPv6 has no NATs. But it also means IPv6 has no load balancers,
because load balancers are, in fact, destination NATs.

---

From: Bill Gage <[email-masked]>
Date: Tue, 15 Dec 2015 15:32:40 +0000

+1.

There is no going back to IPv4 so we should assume that 5G will be an IPv6 world. Unless it solves particular wireless-specific problems in a uniquely elegant way, there is no point in speculating about yet-another IP variant. Been there, done that.

So, what are the issues with using IPv6 in a (5G) wireless world? -- e.g.
- mobility (cf. DMM)
- transport (cf. QUIC)
- authentication
- privacy (cf. DTLS)
- MTC
- ...

Cheers ...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, December 15, 2015 9:33 AM
> Subject: Re: [5gangip] Introducing: Brand-new Internet Protocol "Five
> Fields"
> 
> Hi all,
> 
> I absolutely agree with Mikael addressing issues from a customer point of
> view. What do we need for a fast or seamless handover between different
> networks for example? Lets focus on the transport layer and decouple the
> service from the interface addressing. As Mikael mentioned there are some
> solutions available that could be useful in the context of 5G. Let's focus
> on identifying the open issues for 5G here.
> 
> > 5G should be IPv6 only, with IPv4 as a service. Please do not involve
> NAT in this, apart from that IPv4-as-a-service AFTR.
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 15 Dec 2015 07:50:01 -0800

> - …

How about using IPv6 with LISP? That is:

- mobility (cf. DMM)     use LISP
- transport (cf. QUIC)   use what you have at the transport today including QUIC
- authentication         use lisp-crytpo
- privacy (cf. DTLS)     use lisp-crypto
- multi-homing		 you get this for free with LISP
- underlay		 use IPv6 EIDs with whatever underlay you want (IPv4, IPv6, MPLS, 5G)

Dino

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 15 Dec 2015 10:12:27 -0600

I like this message, it lays out some issues in the next generation or
5G IP protocols without mentioning IPv6.
I think it will also help Alexey to look into FF IP suite from this angle.

Speaking of this, I wonder why Alexey did not come up with any
multicast protocol.
Another point to look into.

Regarding IPv6, as I understand IPv6 now has some momentum to be more
fully deployed, maybe still within the next 5-7 years and that people,
especially the operators do not have taste to even look for a
replacement. What a pity!

Regards,

Behcet

---

From: Alexey Eromenko <[email-masked]>
Date: Wed, 16 Dec 2015 00:31:00 +0200

I did not come with new Multicast,  because I feel it has low value,
outside blockchain protocols. For full nodes.

Even Television,  which used to be broadcast, is now Unicast video on
demand.  Why? Because it is more convenient to pause, get popcorn,  resume.

And online games?  Small battlefields of 10-15 players, everyone from a
different country/ISP, so it will be not more optimal than Unicast.
Although maybe good Multicast can make games with 10, 000 players on one
virtual battlefield possible.

So Multicast has kinda low priority at the moment.

Which use cases do you see for Multicast anyway?

---

From: Alexey Eromenko <[email-masked]>
Date: Wed, 16 Dec 2015 00:42:31 +0200

If IP FF is not Welcome here, I can create my own forum or mailing list.
Either inside IETF, or outside.

5gangip people should vote if I stay, or leave.
On Dec 15, 2015 5:50 PM, "Dino Farinacci" <[email-masked]> wrote:

> > +1.
> >
> > There is no going back to IPv4 so we should assume that 5G will be an
> IPv6 world. Unless it solves particular wireless-specific problems in a
> uniquely elegant way, there is no point in speculating about yet-another IP
> variant. Been there, done that.
> >

---

From: Alexey Eromenko <[email-masked]>
Date: Wed, 16 Dec 2015 00:47:14 +0200

Speaking about Multicast: do we have experimental transport layer
protocol,  that is:
A) support Multicast and
B) is connection-oriented ?  -- Multicast games kinda impossible without
that one.

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 15 Dec 2015 16:50:59 -0800

> Which use cases do you see for Multicast anyway?

Many pre-internet setups in defense use what we would call multicast to
deliver track reports to multiple destinations.  Weather grids are
another example of a file that needs to go to multiple places ... many
at the far end of a tight-bandwidth link.

In emergency services much data is multicast in nature.  Subject
yourself sometime to some cop ranting about the need for 'group
communications'.  

These are cases where the nature of the data is multicast.

On the demand side, these are also cases where there is a radio-WAN in
the internetwork somewhere.  So we have four orders of magnitude less
capacity to play with.  Since radio is a shared media anyway ...

b

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Dec 2015 06:55:18 +0100 (CET)

> replacement. What a pity!

https://www.google.com/intl/en/ipv6/statistics.html

After 5-10 years of hard deployment work, we're now at 10% of Internet 
traffic being IPv6.

Most likely we're still 5-10 years out until 90% of the traffic is IPv6, 
or even until most devices will have IPv6 access at all.

This is the biggest infrastructure change in the history of the Internet, 
and it's still going on. Asking it to change again to accomodate a new IP 
protocol just doesn't make sense to me at all.

So, in my mind any 5G mobile network would be built on top of IPv6, but it 
might contain new transport/tunneling protocols to solve specific 
requirements. As Dino suggested, LISP or similar protocols might be 
solutions for part of this problem space. I would like to avoid all 
traffic being tunneled if possible, and that we only tunnel the traffic 
that needs to be tunneled.

---

From: Dirk Kutscher <[email-masked]>
Date: Wed, 16 Dec 2015 12:56:46 +0000

Hi,

so, upgrading the network layer for better human readability of the address text representation may be a hard sell, but I agree to others in this thread that there is definitely potential to improve forwarding layer capabilities, considering what we have learned in the past 40 years:

- CDN and application layer overlays seem to illustrate a need for scalable, high-performance transport services -- is there a way to come up with a non-silo, application-independent approach?

- Multicast was mentioned in the context of video distribution. One of the things that we may see is the blending of video on demand and linear TV. For an example, when Netflix releases the new weekly "House of Cards" sequel, many of their customers would watch it immediately (or close to immediately), so approaching linear TV consumption schemes, although it is called VoD. For that, a scalable distribution service with multicast capabilities would really help. Instead of building individual silos of such infrastructure for Netflix, Akamai, Social networks etc., I'd suggest to figure what the network could do to support that.

- QUIC, ubiquitous deployment of TCP proxies seem to suggest that there is room for better support for transport layer functions. Especially in 5G, where we expect greater heterogeneity with respect to access technologies and network setups.

IPv6 is probably going to be around for some time. But that does not mean you cannot innovate anymore. But I'd really focus on these performance and service enabling aspects instead of a new IP with better readability.

Best regards,
Dirk

> From: 5gangip [mailto:[email-masked]] On Behalf Of Mikael
> Abrahamsson
> Sent: Mittwoch, 16. Dezember 2015 06:55
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [5gangip] Introducing: Brand-new Internet Protocol "Five Fields"
> 
> After 5-10 years of hard deployment work, we're now at 10% of Internet traffic
> being IPv6.
> 
> Most likely we're still 5-10 years out until 90% of the traffic is IPv6, or even until
> most devices will have IPv6 access at all.
> 
> This is the biggest infrastructure change in the history of the Internet, and it's
> still going on. Asking it to change again to accomodate a new IP protocol just
> doesn't make sense to me at all.
> 
> So, in my mind any 5G mobile network would be built on top of IPv6, but it might
> contain new transport/tunneling protocols to solve specific requirements. As
> Dino suggested, LISP or similar protocols might be solutions for part of this
> problem space. I would like to avoid all traffic being tunneled if possible, and
> that we only tunnel the traffic that needs to be tunneled.
> 
> --

---

From: Bill Gage <[email-masked]>
Date: Wed, 16 Dec 2015 14:43:49 +0000

Hello Alexey -
	The problem is practicality -- it will be impossible to standardise IP FF either in 3GPP or in IETF unless it can be shown to solve a problem that would be difficult to solve within an existing framework.

Unfortunately, IP FF only appears to solve one problem -- readability of a raw end point address. For the vast majority of users, end points are known by their FQDN, such as <google.com> or <twitter.com>. Yes, there will be a number of network engineers who will grumble about trying to read IPv6 addresses but that is hardly a compelling technical or business justification.

I only skimmed the IP FF documentation, but your proposal isn't even backward compatible with IPv4. Most of the alternatives to IPv6 at least tried to provide backward compatibility in order to ease the transition to a new world.

The biggest criticism of IPv6 is that it did *not* take backward compatibility into account, which is why we are now having this long, long transition period. IP FF will not help this -- in fact, we would have to start all over again and address the deployment issues that IPv6 has struggled with for the past decade.

IP FF might have been a good idea 20 years ago, or maybe 20 years from now. In the timeframe of 5G (which is the focus of this mailing list), I don't see it as a viable alternative.

Sorry ...

> 
> From: Alexey Eromenko [mailto:[email-masked]] 
> Sent: Tuesday, December 15, 2015 5:43 PM
> Subject: Re: [5gangip] Introducing: Brand-new Internet Protocol "Five Fields" -- NOT!
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 16 Dec 2015 06:56:37 -0800

> I would like to avoid all traffic being tunneled if possible, and that we only tunnel the traffic that needs to be tunneled.

Can I ask why? Are you worried about packet overhead or something else?

Dino

---

From: John Kaippallimalil <[email-masked]>
Date: Wed, 16 Dec 2015 16:53:32 +0000

>> I would like to avoid all traffic being tunneled if possible, and that we only tunnel the traffic that needs to be >> tunneled.

(1) extra overhead of 15% for current mobile traffic mixes (closer to 20% with IPv6 overheads). Assuming GTP tunneling vs. no tunneling for these calc. For some services with smaller packets, the overhead is obviously higher. This overhead may be relevant to those carriers that lease backhaul, and perhaps not too significant for others.

(2) with no IP tunnels (but with SDN/L2 flow forwarding provisioned), processing/forwarding packets based on L2 can be simpler. Reprogramming the flow state should be fine in access networks (there were some studies with iBGP that showed that it was feasible - I have not seen an SDN study, but consider it similar in this aspect).

(3) considering that we need slicing in 5G (and tunnels of some sort per slice), if we use per flow tunnels also - it would be the tunnel-in-tunnel: an IP packet in IP tunnel (flow) in IP tunnel (slice). Not sure if this is needed)
(Note: considering tunnels for slices: Lookups are likely to be about 10-15 -- corresponding to number of slices)

- John

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Wednesday, December 16, 2015 8:57 AM
To: Mikael Abrahamsson
Cc: [email-masked]; [email-masked]
Subject: Re: [5gangip] Introducing: Brand-new Internet Protocol "Five Fields"

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 16 Dec 2015 08:58:10 -0800

I would say the 15% of overhead is worth the features tunneling can bring. And the underlay could do IPv4 where you cut your overhead in half. That is all devices run IPv6 and only the internal 5G nodes use IPv4. Whatdaya think about that?

Dino

> On Dec 16, 2015, at 8:53 AM, John Kaippallimalil <[email-masked]> wrote:
>

---

From: John Kaippallimalil <[email-masked]>
Date: Wed, 16 Dec 2015 17:00:59 +0000

Agree that we need some tunneling - e.g. slicing. These tunnels are per slice (and not per flow), and the 15% + overhead would be worth it for the features - isolation, etc.
For per flow tunneling, I'm skeptical ...

- John

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Wednesday, December 16, 2015 10:58 AM
To: John Kaippallimalil
Cc: Mikael Abrahamsson; [email-masked]; [email-masked]
Subject: Re: [5gangip] Introducing: Brand-new Internet Protocol "Five Fields"

Dino

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Dec 2015 18:12:56 +0100 (CET)

> Can I ask why? Are you worried about packet overhead or something else?

No, it's that handling tunneling increases cost of the tunnel termination 
devices.

Tunnel encap/decap, MTU handling (sending ICMP need-to-frag for instance), 
potentially fragmentation handling etc, all of this adds complexity and 
cost to the devices involved.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 16 Dec 2015 09:17:08 -0800

On Wed, 16 Dec 2015, Dino Farinacci wrote:
> No, it's that handling tunneling increases cost of the tunnel termination devices.
> 
> Tunnel encap/decap, MTU handling (sending ICMP need-to-frag for instance), potentially fragmentation handling etc, all of this adds complexity and cost to the devices involved.

We can hide it. There is off the shelf silicon that can do tunneling very well (in single pass). At the end of the day, a data-plane that adds another IP header is no different than a router adding a MAC header.

MTU needs to be dealt with but just go with a lower effective MTU. It will be worth the features it brings.

Dino

---

From: Alexey Eromenko <[email-masked]>
Date: Wed, 16 Dec 2015 21:18:18 +0200

Well, IP-FF is much more optimal than either IPv4 or IPv6.

Things like LARA - for the first time we have IP without ARP !
And Mobile - MOPS specification is a BIG one (although it will be
improved very soon).

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 16 Dec 2015 11:22:31 -0800

You can have IPv6 without ARP/ND. EUI-64 addresses can be the MAC address that a system listens to.

Dino

> On Dec 16, 2015, at 11:18 AM, Alexey Eromenko <[email-masked]> wrote:
>

---

From: Bill Gage <[email-masked]>
Date: Wed, 16 Dec 2015 19:28:51 +0000

Can you distill the concept of MOPS into something that is not dependent on IP FF? If so, then we could discuss its merits vis-à-vis other mobility solutions.

Cheers ...

> Sent: Wednesday, December 16, 2015 2:18 PM
> Fields" -- NOT!

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Dec 2015 13:26:15 +0100 (CET)

On Wed, 16 Dec 2015, Dino Farinacci wrote:

> We can hide it. There is off the shelf silicon that can do tunneling 
> very well (in single pass). At the end of the day, a data-plane that 
> adds another IP header is no different than a router adding a MAC 
> header.
>

I still don't see the need for tunneling when most of the traffic involves 
pulling down video chunks that are hundreds of kilobytes in size and cover 
1 second worth of video to put in the playout buffer. If I change my IP 
address I can start pulling this data from the new address.

I agree that tunneling brings benefit for 10% or less of the traffic, but 
why not tunnel just that traffic and not all of it?

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 17 Dec 2015 08:22:48 -0800

On Wed, 16 Dec 2015, Dino Farinacci wrote:
> I still don't see the need for tunneling when most of the traffic involves pulling down video chunks that are hundreds of kilobytes in size and cover 1 second worth of video to put in the playout buffer. If I change my IP address I can start pulling this data from the new address.

There are 100s of other applications. You solved the mobility use-case for just this one application.

> I agree that tunneling brings benefit for 10% or less of the traffic, but why not tunnel just that traffic and not all of it?

Because you have to treat the IP address change logic in each and every application. The app developer wants a network that just delivers packets when in fact the underlying network is (1) changing paths, (2) changing addresses, and (3) changing queue lengths. The app developer wants to focus on the application logic and not entropy that happens under them.

Dino

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Dec 2015 17:32:41 +0100 (CET)

On Thu, 17 Dec 2015, Dino Farinacci wrote:

> Because you have to treat the IP address change logic in each and every 
> application. The app developer wants a network that just delivers 
> packets when in fact the underlying network is (1) changing paths, (2) 
> changing addresses, and (3) changing queue lengths. The app developer 
> wants to focus on the application logic and not entropy that happens 
> under them.

It's my belief that the major mobile device operating system vendors 
already are solving a lot of this so the application developers don't need 
to understand what's going on at this level, and I have full trust in them 
to have solved this abstraction by the time 5G is ready.

Imagine a media player sitting connected to a TV that then has the uplink 
via 5G network. This device will never move around, and it might be 
connected to something that is close to "wifi" as it looks today. I don't 
see the need for it to tunnel all of its traffic.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 17 Dec 2015 08:40:41 -0800

> It's my belief that the major mobile device operating system vendors already are solving a lot of this so the application developers don't need to understand what's going on at this level, and I have full trust in them to have solved this abstraction by the time 5G is ready.

Well that is a better answer than your previous one.  ;-)

> Imagine a media player sitting connected to a TV that then has the uplink via 5G network. This device will never move around, and it might be connected to something that is close to "wifi" as it looks today. I don't see the need for it to tunnel all of its traffic.

But there will be IoT devices behind it that may not have provider-assigned addressing. 

I understand your point that tunneling should not be used for everything. But having EIDs assigned to systems DOES make sense. And to not have flat routing tables in every core box across service providers, you have to abstract. So that means tunneling or translation. Choose your poison.

Dino

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 17 Dec 2015 14:20:37 -0600

> 5gangip people should vote if I stay, or leave.

I think you are getting good feedback so far which should make you happy.
For example you are missing the multicast part of your IP protocol suite.
Maybe you should look at IGMP/MLD and see what you can do. Next see
how you can propagate join requests up to the source.
I don't think multicast goes well with TCP which is connection
oriented. It is sometimes UDP encapsulated or it is just IP.

Also people in 5gangip show great interest on MOPS.

I don't think you can get coding people in this list, you should look
for somewhere else.

Behcet

---

From: Alexey Eromenko <[email-masked]>
Date: Thu, 17 Dec 2015 22:30:31 +0200

> I don't think you can get coding people in this list, you should look

IGMP in IPFF will probably stay almost as-is, unchanged. (like in IPv4)
The reason is because it is supported by switches.
One exception is that in IP-FF there is a new mode called "silent
multicast", which is somewhere between traditional Multicast and
broadcast. (which doesn't requires IGMP)

It lets people to subscribe to special addresses, without advertising
it, like broadcast, but they listen on specific IP + MAC address, so
it is more efficient from CPU perspective.

As for MOPS -- I do have a Major update for it -- supporting
Destination NATs and other goodies.
And of course it supports *any* Transport-Layer protocol, that has
16-bit ports in it.

Plus I have an idea for 64-bit TCP + idea for IPsec ESP NAT(-PT) traversal.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 17 Dec 2015 20:41:20 +0000

It is likely that V4 and V6 would co-exist in 5G. This is because a 5G slicing environment would very likely run 3G / 4G and multiple 5G slices in the same equipment end to end (but different terminals of course). Ie migration.

LTE-* for example running its EPC (mid/backhaul) over V4 could exist in a slice, while a 5G IOT slice could possibly be running both a non IP (and non Ethernet) and a 5G data slice likely over V6. Slicing has to allow ALL of these possibilities.

The question about what is V6 missing is interesting. I think that LISP/Mobility is likely one of the main areas that will be of interest 'within' a slice for a next generation packet core. Anything that reduces the gateway/tunneling problems will be of interest.

Using various IP technologies to implement (i.e. 'outside the slice') some of the slicing will depend on how much delay/jitter they introduce and if stat mux bandwidth is desired v.s. absolute isolation, in which case DWDM/OTN etc. may be a better slicing 'knife'.

Some of the work in 802.1TSN and detnet is likely quite relevant too.

Early days ...

Peter

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Thursday, December 17, 2015 3:21 PM
To: Alexey Eromenko
Cc: [email-masked]; Bill Gage; Dino Farinacci
Subject: Re: [5gangip] Introducing: Brand-new Internet Protocol "Five Fields" -- NOT!

I think you are getting good feedback so far which should make you happy.
For example you are missing the multicast part of your IP protocol suite.
Maybe you should look at IGMP/MLD and see what you can do. Next see how you can propagate join requests up to the source.
I don't think multicast goes well with TCP which is connection oriented. It is sometimes UDP encapsulated or it is just IP.

I don't think you can get coding people in this list, you should look for somewhere else.

Behcet
>> > IPv6 world. Unless it solves particular wireless-specific problems 
>> > in a uniquely elegant way, there is no point in speculating about 
>> > yet-another IP variant. Been there, done that.
>> >
>> >> a replacement of IP(v6) is a challenging job ;-) I absolutely 
>> >> agree with Mikael addressing issues from a customer point of view. 
>> >> What do we need for a fast or seamless handover between different 
>> >> networks for example? Lets focus on the transport layer and 
>> >> decouple the service from the interface addressing. As Mikael 
>> >> mentioned there are some solutions available that could be useful 
>> >> in the context of 5G. Let's focus on identifying the open issues 
>> >> for 5G here.
>> >>
>> >> On Tue, Dec 15, 2015 at 12:27 PM, Mikael Abrahamsson 
>> >> <[email-masked]>
>> >> wrote:
>> >>>> It already supports standard operation and Source NATs, but I 
>> >>>> need to write specification for destination NATs (and maybe 
>> >>>> optimize Source
>> >> NATs).
>> >>>
>> >>>

---

From: Alexey Eromenko <[email-masked]>
Date: Thu, 17 Dec 2015 22:47:15 +0200

Sorry, but what is LISP ?

I know there is a programming language called "LISP" -- but you refer
to some protocol in some RFC ?
Link please.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 17 Dec 2015 20:52:27 +0000

Yes LISP is/was a great programming language. I implemented it years ago for fun as an open source project. 

However I was referring to Location/Identification Separation Protocol. 

Google search "draft lisp ietf" should turn up what you are looking for.

Cheers,

Peter

-----Original Message-----
From: Alexey Eromenko [mailto:[email-masked]] 
Sent: Thursday, December 17, 2015 3:47 PM
To: AshwoodsmithPeter
Cc: [email-masked]; [email-masked]; Bill Gage; Dino Farinacci
Subject: Re: [5gangip] IPV4/V6

I know there is a programming language called "LISP" -- but you refer to some protocol in some RFC ?
Link please.

---

From: Alexey Eromenko <[email-masked]>
Date: Thu, 17 Dec 2015 22:58:24 +0200

Ohh.. here is my updated MOPS draft:
https://www.dropbox.com/s/m4e2qksq5oo7m34/IPFF-MOPS-RFC-draft.txt?dl=0

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 17 Dec 2015 16:47:33 -0500

> to some protocol in some RFC ?

RFC 6830-6836. 

Dino

---

From: Ca By <[email-masked]>
Date: Thu, 17 Dec 2015 13:47:59 -0800

> Google search "draft lisp ietf" should turn up what you are looking for.
LISP has a lot of warts that may not make it properly operational on the
internet, this is just my opinion not a invitiation for Dino to jump up and
down

 That said, if we are looking at a clean slate approach, i really like ilnp
which addresses the LISP problem set with a simple core network "just ip" and
smarter end points

https://tools.ietf.org/html/rfc6740

-----Original Message-----
> From: Alexey Eromenko [mailto:[email-masked] <javascript:;>]
> Cc: [email-masked] <javascript:;>; [email-masked] <javascript:;>;
> Bill Gage; Dino Farinacci
> [email-masked] <javascript:;>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 17 Dec 2015 16:53:11 -0500

> That said, if we are looking at a clean slate approach, i really like ilnp which addresses the LISP problem set with a simple core network "just ip" and smarter end points

You can do that with LISP too. And LISP supports multiple address families not limited to IPv6 but can support geo-coordinates and E.164 addressing as well. 

Dino