Subject: [arch-d] Development of Internet Protocol "Five Fields" (IP-FF): Presentation

From: Alexey Eromenko <[email-masked]>
Date: Sun, 3 Jan 2016 15:41:53 +0200

Hello,

Secretly in the shadows, I have been developing a new Internet
Protocol "Five Fields" for quite some time. It is designed to be
superior than both IPv4 and IPv6. And even made a nice presentation
about IP-FF and it's features:

https://docs.google.com/presentation/d/1XbqWOwv0GASmSjYZimfK64QKQQ-0yK9xQ1_spRhlf8Y/edit?usp=sharing

It now consists of 10 parts: (submitted as IETF drafts)

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: Babysitter (new NAT)
https://datatracker.ietf.org/doc/draft-eromenko-ipff-babysitter/

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

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

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

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

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

9. Internet Protocol - Five Fields: TCP.64 extensions
https://datatracker.ietf.org/doc/draft-eromenko-ipff-tcp64/

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

Happy new year, and new Internet beginning !
--
-Alexey Eromenko "Technologov"

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 3 Jan 2016 23:20:22 +0100

Hi Alexey,

> about IP-FF and it's features:

I read 13 slides or so, but I hadn't encountered the header diagram yet.

The part that bothers me is that you feel the address notation is the biggest issue.

We can fix that without getting rid of IPv6. There's no reason why 1234.5678.910.1112.1314 can't be an IPv6 address. Just pad the ~ 50 bits specified with 78 zero bits and you're in business.

---

From: Alexey Eromenko <[email-masked]>
Date: Mon, 4 Jan 2016 00:30:10 +0200

To save you time: header on slide 18 :)

---

From: Alexey Eromenko <[email-masked]>
Date: Mon, 4 Jan 2016 00:36:25 +0200

And yes, I have tried to shorten it up. Bad result.

Either this funny stuff:
READ: A Compact Representation of IPv6 Addresses
https://www.ietf.org/rfc/rfc1924.txt

-or- 39 decimal digits. No less.

---

From: Theodore V Faber <[email-masked]>
Date: Tue, 5 Jan 2016 17:43:47 +0000

On 1/3/16, 05:41, "Architecture-discuss on behalf of Alexey Eromenko"
<[email-masked] on behalf of [email-masked]>

>https://datatracker.ietf.org/doc/draft-eromenko-ipff/

Mostly Harmless.

Let us know when you’ve implemented something.

-- 
Ted Faber <[email-masked]>
Engineering Specialist
Computer Systems Research Department
310-336-7373

---

From: Tony Li <[email-masked]>
Date: Tue, 5 Jan 2016 10:14:01 -0800

> On Jan 5, 2016, at 9:43 AM, Theodore V Faber <[email-masked]> wrote:
> 

… and when you’ve thought about the routing implications of your design.

Five fields doesn’t not seem to provide boundless scalability in a hierarchical routing architecture.

And to (mis)quote Ross Callon: ~When it comes to architectural constants, if the number isn’t obviously ample, it’s not big enough.~

Tony

---

From: Joe Touch <[email-masked]>
Date: Tue, 5 Jan 2016 12:56:25 -0800

> … and when you’ve thought about the routing implications of your design.

...and when you have a plan for tech transition.

It's very easy to redesign any protocol if you ignore the need to
support legacy systems.

Joe

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 7 Jan 2016 18:48:47 +0000

Alexy,

I suspect you are most proud of the fact that you have produced a set of 
ideas that all work well together.
But see inline...

On 05/01/16 20:56, Joe Touch wrote:
>>>> On Jan 5, 2016, at 9:43 AM, Theodore V Faber<[email-masked]>  wrote:
>>>>

*1. Deployability**
*
...I would argue that the value of each part of FF has to be assessed as 
if that part was separate from the rest, for the reason Joe gives... 
...there is little mention or consideration of incremental deployability 
{note 1} of the whole system, let alone each of the parts (other than 
the NAT part).

But even though the FF system is unlikely to ever be deployable as a 
whole, it might be possible to modify some of the individual ideas in FF 
to add incremental deployability, so that the most valuable ideas can 
become usable individually.

*2. Private problem statement?**
*
The biggest problem with FF is that you have been working on solving a 
set of problems that few would agree have been articulated as the real 
underlying problem that needs to be solved. The problem statement is the 
part that should be done in public, even if you do the design in private.

* v6 address space too big - so what? it's more important to agree on 
any size, than to have the "right" size.
* v6 addresses hard to transliterate, read etc - so what? - just a tools 
problem
* mobility without breaking transport - need to solve this without 
compromising other features like ability to keep ports private. A number 
of alternative ways already solve this: multipath TCP, or Teemu Koponen 
et al's "Resilient Connections for SSH and TLS," USENIX Annual Technical 
Conference
* ports at L3 or L4 - Just because ports can be useful at L3, doesn't 
mean they should be moved to L3. A better answer is "Design for Tussle", 
ie on the wire it needs to be possible to have ports hidden or not, and 
everything works (for some definition of "works") whichever way you 
choose. {note 2}
* no ARP - looks useful to replace with an algo. The question then 
becomes how do you introduce new MAC layer addressing schemes in future 
- ARP is agnostic to the internal semantics of a L2 address, but an algo 
cannot be.
* stronger L4 checksums - useful, but needs to be considered as part of 
the bigger problem of L4 extensibility currently being addressed.
* IP-VRF - again the problem here is the extensibility architecture of 
existing IP. We can't keep changing to a completely new Internet 
Protocol every time we realise we missed an extension we should have 
thought of. Well it would be worth the change if the new Internet 
Protocol had a brilliant extensibility architecture...
* ...which raises a good question...

Where's your extensibility architecture? Should be the first design 
decision, not the last.

I'm trying to be helpful while being critical.

Cheers

Bob

{Note 1} If IPv6 had been proposed today, given how important everyone 
now knows incremental deployment is, it would have been rejected out of 
hand. Incremental deployment alongside v4 involved messy dual-stack, 
gateway and tunnelling additions, rather than incremental deployment 
intrinsic to the protocol design. And future protocol extensibility 
proved to be badly architected as well.

{Note 2} Ports can be added incrementally to L3, by 
agreeing/standardising the port fields as a shim betw layers, then 
altering protocols like IPsec ESP to move the SPI to the same location 
as the unencrypted ports would be found in. At the same time, the source 
IP port can be moved to this shim because it is really transport layer 
info, and the space where it was in the IP header can be used to double 
the bits for dest addresses (eliding the details on how to identify the 
different header format). See sourceless network architecture (SNA) from 
Jon Crowcroft and Marcelo Bagnulo Braun, and see Bryan Ford and 
Janardhan Iyengar: “Breaking Up the Transport Logjam”, HotNets-VII.

> Joe
>
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Alexey Eromenko <[email-masked]>
Date: Fri, 8 Jan 2016 04:53:13 +0200

Tony Li <[email-masked]>:

Routing is described in [IPFF-ADDRESSING] spec.

On Thu, Jan 7, 2016 at 8:48 PM, Bob Briscoe <[email-masked]> wrote:

> On Jan 5, 2016, at 9:43 AM, Theodore V Faber <[email-masked]> <[email-masked]> wrote:
>
> *1. Deployability*
> {note 1} of the whole system, let alone each of the parts (other than the
> NAT part).
>
> whole, it might be possible to modify some of the individual ideas in FF to
> add incremental deployability, so that the most valuable ideas can become
> usable individually.
>
>
IPFF-Babysitter (new NAT) solves Deploy-ability problems (for desktops).
IPFF private servers will be useful in-house, and IPFF desktops can browse
IPv4 Internet.
IPFF Internet servers will obviously require new Internet core. (just like
IPv6 requires)

> *2. Private problem statement?*
>
> The biggest problem with FF is that you have been working on solving a set
> of problems that few would agree have been articulated as the real
> * v6 address space too big - so what? it's more important to agree on any
> size, than to have the "right" size.
> * v6 addresses hard to transliterate, read etc    - so what? - just a
> tools problem
>
There are no tools for that. IPv6 is unusable in every way.

> compromising other features like ability to keep ports private. A number of
> alternative ways already solve this: multipath TCP, or Teemu Koponen et
> al's "Resilient Connections for SSH and TLS," USENIX Annual Technical
> Conference
>

My "Mobile Protocol Stack" works with every Transport Protocol in theory,
although my paper describes "Mobile TCP" and "Mobile UDP".

> * ports at L3 or L4 - Just because ports can be useful at L3, doesn't mean
> they should be moved to L3. A better answer is "Design for Tussle", ie on
> the wire it needs to be possible to have ports hidden or not, and
> everything works (for some definition of "works") whichever way you choose.
> {note 2}
>

Ports were moved to layer 3 for fast firewalling and fast Flow-based
routing, the latter of which explained in detail. Doing some kind of Layer
3.5 shim will not solve those problems.

> * no ARP - looks useful to replace with an algo. The question then becomes
> how do you introduce new MAC layer addressing schemes in future - ARP is
> agnostic to the internal semantics of a L2 address, but an algo cannot be.
>

Right. LARA is specified for Ethernet. Other data links will require other
specifications, and I don't mind if some are still using ARP. (Frame-Relay?)

> existing IP. We can't keep changing to a completely new Internet Protocol
> every time we realise we missed an extension we should have thought of.
> Well it would be worth the change if the new Internet Protocol had a
> brilliant extensibility architecture...
>
> decision, not the last.
You are right.

I'm working hard to improve IP-FF extensibility (both L3 [IP options] and
L4, [future Transports]), and also working on new Multicast solution.

Thanks for link to SNA: Sourceless Network Architecture; I need to study
that one.

---

From: Simon Leinen <[email-masked]>
Date: Fri, 8 Jan 2016 14:48:58 +0100

Alexey Eromenko writes:
>     * v6 addresses hard to transliterate, read etc    - so what? -
>       just a tools problem

> There are no tools for that. IPv6 is unusable in every way.

No, obviously not in *every* way, since it is being used in the real world.

However, I agree there *are* usability problems, and I found Bob Briscoe's
"so what? - just a tools problem" a bit cavalier.  (I should say that this
was the only part of Bob's message I have a problem with - overall I find
it extremely well thought through and on the topic.)

Of course people can and should use hostnames and not bother with these
addresses at all.  Most end users already do.  But still, developers and
operators often use (and, worse, sometimes force other users to use)
literal IP addresses.  In some cases this is hard to avoid (e.g. an
operator debugging a routing issue and looking at prefixes in the routing
or BGP table), in other cases I don't quite understand myself why people
use literal addresses when they should be using hostnames.

Personally I don't think this is reason enough to throw out IPv6.

But we would do well to take this usability problem more seriously.  I'm
optimistic that much of this could be addressed, and yes, tools (including
better UIs) will play a major role.

So it may well be a tooling problem... but "JUST a tools problem"?
If tools were an easy problem, shouldn't we have solved it by now?

I'm not saying that no tools exist (for example, hostnames exist), but
there's definitely still a gap in that people find IPv6 hard to use -
maybe the tools are there but for some reason they aren't used.

Wouldn't (y)our time be better spent working on this: Trying to make the
fact that IPv6 addresses are "hard to transliterate, read etc" (with which
I agree) less relevant for those who currently feel the pain?

And who is it who's feeling that pain? I'm guessing that many people who
have to configure firewalls and access lists are in that group today.
Who else?
-- 
Simon.

---

From: Alexey Eromenko <[email-masked]>
Date: Fri, 8 Jan 2016 16:01:43 +0200

>
> I don't see a solution to this problem.

> have to configure firewalls and access lists are in that group today.

Debugging stuff is slow with IPv6. This includes quick comparison of
addresses, of host portion and of network portion of two (or more) source
or destination addresses.
In IPv4, it is possible to visualize (average sized, corporate) network in
human brain.
Network consists not only of nodes (which DNS can fix), but also of address
ranges, multicast addresses, subnets, etc...

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 8 Jan 2016 15:37:02 +0100

On 08 Jan 2016, at 15:01, Alexey Eromenko <[email-masked]> wrote:

> Debugging stuff is slow with IPv6. This includes quick comparison of addresses, of host portion and of network portion of two (or more) source or destination addresses.
> In IPv4, it is possible to visualize (average sized, corporate) network in human brain.

Untrue.

With IPv6 things are super easy: you get a /48, put your VLAN ID in the subnet bits and /64 per subnet. Easy peasy.

With IPv4 when you go beyond mod 2^8 subnet sizes you need to convert between decimal and binary and do bitmask operations in your head.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 8 Jan 2016 15:40:21 +0100

On Fri, Jan 08, 2016 at 04:53:13AM +0200,
 Alexey Eromenko <[email-masked]> wrote 

> There are no tools for that. IPv6 is unusable in every way.

OK, my employer uses IPv6 in production for more than ten years. We
have probably been dreaming during this time.

That's why I do not intend to spend time on Five Fields: you pretend
to solve a problem... that nobody else has.