Subject: Introducing : Brand-new Internet Protocol "Five Fields"

From: Alexey Eromenko <[email-masked]>
Date: Thu, 10 Dec 2015 14:42:03 +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.

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

---

From: Niels Dettenbach <[email-masked]>
Date: Thu, 10 Dec 2015 13:59:44 +0100

> both, and intended as a replacement for both. Substantial improvement

I think one main argument against "Five" would/will be it's "inefficiency" 
from a very first, historical and theoretical view onto it. IPv4 and 6 
addresses fit "exactly" binary structures which are widely found in hardware 
(32/64bit) - but i know, the praxis could be more or less another story 
today...

And if i read correctly, do you used the IPv4 specs widely and "just" added 
the "fifth field" / 8bits, which at least some of us still had in mind some 
times in the past too ß)
  
Do you have any working setup or implementation anywhere? Or a small howto for 
implementing a own test bed with open source stuff?

many thanks,

Niels.

-- 
 ---
 Niels Dettenbach
 Syndicat IT & Internet
 http://www.syndicat.com
 PGP: https://syndicat.com/pub_key.asc
 ---

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 10 Dec 2015 14:00:32 +0100

Dear Alexey,

Speaking as sergeant-at-arms.

I think this topic may be not appropriate for this list, unless it is submitted as an IETF ID.

So I will suggest, if you want to continue discussing it here, you first submit it so it becomes “officially” part of the process.

You may need to talk with the IESG to work on a BoF, specific mailing list, etc.

Regards,
Jordi

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Dec 2015 13:13:14 +0000

Alexey

However good the idea, I cannot imagine that many people will
wish to open a random zip file.

- Stewart

On 10/12/2015 12:42, Alexey Eromenko wrote:
> .

---

From: Alexey Eromenko <[email-masked]>
Date: Thu, 10 Dec 2015 15:27:57 +0200

I tried to submit my docs, by inserting the following:

"Internet Protocol Five Fields", Alexey Eromenko, 2015-12-10,
<draft-ietf-ipff-00.txt>

but no luck...

Submitted here:
https://datatracker.ietf.org/submit/

Got an ERROR:
"There is no active group with acronym 'ipff', please rename your draft"

any ideas?
-- 
-Alexey Eromenko "Technologov"

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 10 Dec 2015 14:31:59 +0100

Right, because you’re trying a WG submission, while at the time being those documents are personal Ids.

I will suggest you read about the process, look for the newcomers presentations, etc.

Regards,
Jordi

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 10 Dec 2015 13:39:45 +0000

A name for an individual submission would be something like
    draft-eromenko-ipff-00.txt
It should accept that.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 10 Dec 2015 08:43:46 -0500

Alexey,

If you rename your draft “draft-eromenko-ipff.txt” you’ll have much more
success. See http://www.ietf.org/ietf-ftp/1id-guidelines.txt for the
details.

Cheers,
Andy

---

From: Scott Brim <[email-masked]>
Date: Thu, 10 Dec 2015 08:45:05 -0500

https://www.ietf.org/rfc/rfc1924.txt

---

From: Saku Ytti <[email-masked]>
Date: Thu, 10 Dec 2015 16:47:29 +0200

Hey Alexey,

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

Evolution does not not end up having best solution popularised, but
first good enough.
I'm not biggest IPv6 fan, but I believe it to be good enough.

>   2001:db8:2e1:1a73:149f:88ff:fe81:6116

Binary number presentation preference is quite poor argument for all
new protocol.
But I see that you have other, more compelling arguments as well.

> magnitude simpler, and requires no access to routers and

Good goal. But I prefer L4 solution like MinimaLT and QUIC, where IP
is just low level
routing detail, not identity. Identity being PKI based, IP can change
arbitrarily without any
signalling.

> -IP-VRF header extension, allows doing VRF-VPN without MPLS (and

I can see use cases. But personally, I'd just update MPLS labels
slightly (MPLSv2) and make that
part of IP spec.

> -No IP header checksums (done at layer 4)

I think this was huge mistake in IPv6, instead of removing header
checksum from L3, they should have
added proper polynomial function like ethernet.
Routers and switches today do not guarantee data integrity, they can
mangle data and calculate working
IP checksum and ethernet CRC on mangled data. In IPv4 we would usually
notice this in egress PE,
in IPv6 we have no way of knowing it is happening.
Correct solution would be to have CRC on IP, which does not change and
is not allowed to be recalculated
to the packet on transit.
But this is again problem proper L4, like MinimaLT and QUIC addresses.

> -No autoconfiguration/SLAAC (this belongs to DHCP territory)

Fully agreed.

> -No Layer2 resolution. ARP-free protocol.

This is really cute, I like it. But probably rustles someone's
jimmies, how they rely on MAC not changing.

> both, and intended as a replacement for both. Substantial improvement

Even if it would be superior, unfortunately deployability is not
function of protocols 'goodness'. But great
work and some really nice ideas.

I'd be more conservative and just axe bunch of useless crap from IPv6,
add some point-to-point (i.e host-switch) routing-protocol as
mandatory (a'la ES-IS) instead of ARP, mandate that implementation
includes new PKI based L4 protocol (something along lines of MinimaLT
and QUIC) and mandate that addresses are published in DNS in something
like SVCINFO (think SRV, but correctly:)

Anyhow great work, fun to read.
-- 
  ++ytti

---

From: Alexey Eromenko <[email-masked]>
Date: Thu, 10 Dec 2015 18:05:17 +0200

I have tried to submit my docs numerous times, but failed.

  ** Looks like you're using RFC 2026 boilerplate.  This must be updated to
     follow RFC 3978/3979, as updated by RFC 4748.

... Now the problem is that those RFCs are long, and I don't even
understand them.

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 10 Dec 2015 11:16:20 -0500

There are tools for formatting drafts. See

https://www.rfc-editor.org/materials/tools_ids_rfcs_94.pdf

If you are not willing to go to the effort of formatting your "new IP"
ideas so they can be submitted as an draft or recruiting a co-author
who will do that for you, then I am not willing to go to the effort of
looking at your ideas.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Dec 2015 08:32:29 -0800

> I think this topic may be not appropriate for this list, unless it is submitted as an IETF ID.

I'm always glad to see active seargant-at-arms efforts, attending to
mailing list propriety.

But I cannot guess at the basis for claiming Eromenko's posting was
inappropriate.  What policy or documented practice does it violate?

I am not aware of any IETF or ietf mailing list requirement that a new
topic first have an I-D before it is 'proper' to discuss it.

There are considerable benefits in pressing a proponent to write up a
specification, so that people can discuss concrete specifics, rather
than vague ideas. So offering the guidance as a strong encouragement is
reasonable, of course.  But the efficacy of this is quite independent of
formal institutional rules.

(An in case this isn't clear, I'm not offering an opinion on the merits
of Eromenko's proposal, merely about the propriety of the posting.)

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Dec 2015 18:03:49 +0100

> topic first have an I-D before it is 'proper' to discuss it.

+1.  It used to be the case where we could actually have substantive
discussions on this list.

Eliot

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 10 Dec 2015 18:18:13 +0100

That’s why I said “may not”, because is a bit fuzzy and probably subjective if this work make sense to be discussed in this list vs. asking the IESG to  create a specific mail exploder and so on.

RFC3005 indicates that “technical issues that are candidates for IETF work” are appropriate, but also I think this thread could create a bunch of controversial and unnecessary discussion (vs. the actual IPv6 adoption status).

Yes, it may be a bit subjective, and some times my job is not easy as you may guess, but I wanted to make sure the “may not”, and providing orientation to possible alternative paths, such as talking to IESG for an alternative exploder, etc.

The difference between this and other postings is clear, when I directly ask for completely stopping a given thread.

Regards,
Jordi

---

From: Hector Santos <[email-masked]>
Date: Thu, 10 Dec 2015 12:19:57 -0500

I like the basic premise of this.  I think there are many people that 
may feel the same about the "obscure" formatting nature of IP6 
compared to IP4 -- who can read/use it (easily)?  Only the IPv6 geeks, 
the majority would have difficulty.  There is a lost of control, IMO.

I think anything that can help promote IP6 and the assist in migration 
from IP4 is a plus.

+1 for further work here.

-- 
HLS

---

From: Alexey Eromenko <[email-masked]>
Date: Thu, 10 Dec 2015 19:53:00 +0200

Good news: After much jumping through hoops I was able to decipher
what-it-takes to get my draft spec submitted (I still don't understand
it fully, though).

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/

Yeehoo ! Submitted !

---

From: Hector Santos <[email-masked]>
Date: Thu, 10 Dec 2015 13:29:09 -0500

> inappropriate.  What policy or documented practice does it violate?

+1.

Bored, perhaps. I don't get it.  I think the OP should explore this 
further with discussions in the IETF and then he can decide if a I-D 
is worthy of his time.

Personally, I think it will encourage more IPv6 considerations by 
legacy IPv4 operations.  I also had same concerns about the 
non-trivial IPv6 readability.

-- 
HLS

---

From: John C Klensin <[email-masked]>
Date: Thu, 10 Dec 2015 13:29:48 -0500

Folks,

I'm delighted that Alexey managed to get past the various
barriers our boilerplate and posting tool requirements set up
and hope he is now all set, but I'd like to make a suggestion
for that future in line with our claims that we are trying to be
welcoming to newcomers.

The most obvious way to figure out the requirements for and
prepare a new I-D is not to navigate a serious of RFCs that lay
out the rules but to take a recent or relevant RFC or I-D and
try to copy the relevant formats, boilerplate, and other
material from it.  It turns out that, if one does not already
understand the rules, that isn't as obvious as it appears,
leading the author to get frustrated with the submission process
and various expressions of frustration on this list (few of
which are really helpful).

By contrast, simply picking up the would-be draft, mashing the
front and back matter into the appropriate form, and sending it
back to the author as a sample and accompanying it with a
friendly note takes very little time (pushing the document name,
title, author, and abstract information into XML2RFC and then
compiling it took about 15 minutes and I'm sure there are folks
around with more talent and better tools who could do it more
quickly).

I trust I am not the only one who thinks that is a better way to
spend 15 minutes than reading and participating in a long thread
about appropriateness or pointing the author to a string of
references that are a lot more likely to useful once the sense
of beating one's head against the wall dissipates.

best,
      john

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 10 Dec 2015 13:30:25 -0500

Alexey,

My initial comment is that IP version 5 is already assigned to RFC 1190.
See https://www.iana.org/assignments/version-numbers/version-numbers.xhtml
for the current list of assigned IP version numbers. 2, 3, and 10-14 are
currently available, and are assignable by IETF standards action. In the
meantime, I suggest that you leave the version field TBD (to be
determined), and just refer to your proposal as IPFF.

Cheers,
Andy

---

From: Randy Bush <[email-masked]>
Date: Fri, 11 Dec 2015 04:16:39 +0900

> So I will suggest, if you want to continue discussing it here, you
> first submit it so it becomes “officially” part of the process.
> 

you gotta love censorship.  thanks jordi.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 10 Dec 2015 10:25:48 -0900

++

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Dec 2015 20:42:32 +0100

Dave Crocker wrote:
> inappropriate.

Well, I can guess.

In another community, there is the concept of FUSSP.

http://www.rhyolite.com/anti-spam/you-might-be.html

We probably need a similar form for the FUSTIP (Final Ultimate Solution
to the 32-bit Internet Problem).

Speaking of Jordi's intervention, the ultimate outcome was great, we now
have actual drafts to look at.

(And, yes, submitting drafts should be easier, http://rfc.space probably
needs better documentation as well.)

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Dec 2015 08:42:43 +1300

Alexey,

The dropbox URL is 404 for me, so unfortunately I can't read your proposal.

However, a simple extension of the IPv4 address field was proposed in
various forms 20+ years ago, before we started on the IPv6 adventure.
My own contribution, for example, was
https://www.cs.auckland.ac.nz/~brian/draft-carpenter-aeiou-00.txt

The first problem with this approach is (as shown by the matrix in the draft)
exactly the same as with all other such proposals that we have seen over
the years: an unmodified legacy host cannot communicate with a host
using the address extension. So we need all the same tricks that we
need with IPv6 - dual stack, tunnels, and in the worst case NATs.

The second problem is that existing legacy routers will drop the packets.

That being so, and well understood since 1994, the choice was made to
develop a new protocol. We chose binary addresses for obvious reasons;
reverting to telephone-like decimal addresses was certainly not
considered.

You are correct that IPv6 addresses are hard to remember. We decided
that doesn't matter: users should never need to know about addresses
anyway.

Regards
   Brian Carpenter

Regards
   Brian Carpenter

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Dec 2015 20:52:08 +0100

> that doesn't matter: users should never need to know about addresses

Yes, but to help the poor admins (also a class of users!) we should have
gone for a variant of RADIX50 presentation instead of bland hex.

So many more vanity addresses, instead of being limited to face:b00c and
9o:o91E.

(OK, I'll shut up now in this thread.  But thank you for going ahead and
starting the FUSTIP work.)

Grüße, Carsten

---

From: Alexey Eromenko <[email-masked]>
Date: Thu, 10 Dec 2015 21:58:50 +0200

I have uploaded to Internet-draft repository.
On Dec 10, 2015 9:42 PM, "Brian E Carpenter" <[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 11 Dec 2015 10:43:20 +0100

> what-it-takes to get my draft spec submitted (I still don't understand

Where's the transition plan?

---

From: <[email-masked]>
Date: Mon, 14 Dec 2015 04:10:34 +0000 (UTC)

Going to 50-bit addresses with ten bits per field?That makes no sense from a computing efficiencyviewpoint, as those are not powers of 2.

48 bits would be on octet boundaries, but harder toprocess than 64 bits in a word (ATM had trouble with48-byte payloads, too. A fudge between those whowanted 32 bytes and those who wanted 64.)

IP protocol version 5 is already defined and in usefor RFC1190, and that use would have to be deprecatedfirst. Picking 7 is easier; for a long time someoneon this list was pushing an idea of IPv8... and IPv9.

(Try this: sitting through talks about how awesome IPv6 isand how it solves addressing problems and routing tableproblems, then asking innocently 'why is there ajump from IPv4 to IPv6? What happened to 5?' If they can'ttell you that, then just maybe they shouldn't be tryingto sell you stuff.)

L.

 'don't understand it fully' may be somewhat understated.

 Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Harald Alvestrand <[email-masked]>
 To: [email-masked] 
 Sent: Friday, 11 December 2015, 20:43
 Subject: Re: Introducing : Brand-new Internet Protocol "Five Fields"

---

From: Robert Withers <[email-masked]>
Date: Sun, 13 Dec 2015 23:30:59 -0500

This isn't so odd from the standpoint of immediate values on the stack, 
with tag bits, in a bytecode jitted language, such as squeak. It 
certainly fits within the prominent 64-bit architectures.

best regards,
robert

On 12/13/2015 11:10 PM, [email-masked] wrote:
> Going to 50-bit addresses with ten bits per field?
> That makes no sense from a computing efficiency
> viewpoint, as those are not powers of 2.
>
>
> 48 bits would be on octet boundaries, but harder to
> process than 64 bits in a word (ATM had trouble with
> 48-byte payloads, too. A fudge between those who
> wanted 32 bytes and those who wanted 64.)
>
>
> IP protocol version 5 is already defined and in use
> for RFC1190, and that use would have to be deprecated
> first. Picking 7 is easier; for a long time someone
> on this list was pushing an idea of IPv8... and IPv9.
>
>
> (Try this: sitting through talks about how awesome IPv6 is
> and how it solves addressing problems and routing table
> problems, then asking innocently 'why is there a
> jump from IPv4 to IPv6? What happened to 5?' If they can't
> tell you that, then just maybe they shouldn't be trying
> to sell you stuff.)
>
>
> L.
>
>
> ------------------------------------------------------------------------
> *From:* Harald Alvestrand <[email-masked]>
> *To:* [email-masked]
> *Sent:* Friday, 11 December 2015, 20:43
> *Subject:* Re: Introducing : Brand-new Internet Protocol "Five Fields"
>

---

From: <[email-masked]>
Date: Mon, 14 Dec 2015 04:47:45 +0000 (UTC)

#yiv2733965662 blockquote, #yiv2733965662 div.yiv2733965662yahoo_quoted {margin-left:0 !important;border-left:1px #715FFA solid !important;padding-left:1ex !important;background-color:white;}Well, we do have self-documenting xml templates that can be mashed athttps://tools.ietf.org/tools/templates/
not sure how well they are called out in introductory material though.

(This self-documenting template approach is quite common, e.g. IEEExplore hashttp://www.ieee.org/conferences_events/conferences/publishing/templates.html
etc.)

On Friday, December 11, 2015, 05:31, John C Klensin <[email-masked]> wrote:
Folks,

best,
      john

---

From: Alexey Eromenko <[email-masked]>
Date: Mon, 14 Dec 2015 08:28:17 +0200

Yes, the idea is to deprecate ver 5, since no one is using it, to my
knowledge.

50-bit addresses fit 64-bit unsigned integers perfectly,  after a bitmask,
which is way faster than 128-bit processing anyway.

As for me, I'm studying and analyzing ILNP architecture, and preparing
transition plan.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 14 Dec 2015 15:30:05 +0900

Alexey Eromenko wrote:

> IPv4 has great look & feel, but it is exhausted. So

So, use NAT to enjoy 48 bit addressing, may be with class E.

You can still enjoy full end to end transparency for applications
over TCP/UDP through UPnP capable NAT boxes.

> several hundred years, including IoT)

If 48 bit space by NAT is not large enough, the least painful
way to extend it is to make port numbers 32 bit long.

> discovery is the way to go.

That's as bad as IPv6.

> -No broadcasts.

That's as bad as IPv6.

> -No IGMP required (it is optional now for Multicasts)

You do better than IPv6, here.

						Masataka Ohta

---

From: Alexey Eromenko <[email-masked]>
Date: Mon, 14 Dec 2015 09:03:18 +0200

> over TCP/UDP through UPnP capable NAT boxes.

I thought about extending port ranges to 32-bit, but it invites a massive
Carrier-Grade NATs. Lets call it Large variants of TCP and UDP. TCP.L and
UDP.L.

Besides, all the middle boxes will need to be replaced with those new
protocols, just like with IPFF.

But the good news, is that NAT is fully supported in IPFF.

> > discovery is the way to go.

Look, for most links, fragmentation and checksums slow down Core Router
processing (those big boxes doing 100 Gigs per port).
With those features removed,  routers can become faster.
And with fragmentation removed embedded devices and new IPFF
implementations can be simpler.

The downsides for fragmentation?  Narrow links.

As for narrow links, like IEEE 802.15.something, they are too narrow to be
useful with fragmentation. It allows only (128?) Bytes natively, while
TCP/IP header alone is 40 bytes. Do you suggest supporting links with 30%
overhead ?
I think such links need to develop "layer 2.5", to allow bigger packets.

IPv4 doesn't do it either,  defining minimum MTU at 576 bytes.

> That's as bad as IPv6.

Why is it bad ? IPFF defines a new mode: "silent multicast", which is
somewhere between tradional Multicast and Broadcast. I.e it is being
flooded at layer 2 to all, but every node can filter it at layer 2, 3 or 4.
It doesn't require IGMP advertising. It is a more efficient version of
Broadcast, if you will.

Written in IPFF addressing architecture spec.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 14 Dec 2015 16:03:44 +0900

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

Why haven't you eliminated IP options entirely? IPv4 is a
live evidence that they are totally unnecessary (assuming
fragmentation enabled).

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

I'm not sure how DHCP request can be sent from a host with
no IP addresses. Maybe, the host has and uses a globally
unique MAC address.

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

What if two mobile hosts are communicating, moves simultaneously
and send "Migrate" messages to old (and, now invalid) addresses
of their peers?

Note that falling back to DNS updates means minutes of delay.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 14 Dec 2015 16:24:33 +0900

Alexey Eromenko wrote:

> I thought about extending port ranges to 32-bit,

For the time being, 16bit is good enough.

> but it invites a massive

32bit port number, if any, is a long term goal and, unlike home
routers, you can expect carriers upgrade their equipments
regularly.

> processing (those big boxes doing 100 Gigs per port).

Wrong. Within the core, MTU is 1500. Hardware computation of
checksums are done at wire speed with small amount of hardware
(much smaller than additional hardware to support IPFF in
addition to IPv4).

Even edges, to make PMTU discovery quickly react against
PMTU increase, packets a little larger than the current
PMTU must be sent frequently, which  burdens devices
at the edges.

> Do you suggest supporting links with 30% overhead ?

No, requiring 1280 or 9000 should be fine.

> IPv4 doesn't do it either,  defining minimum MTU at 576 bytes

FYI, it is 68, not 576.

> Why is it bad ?

Because broadcast is useful and IPv6 foolishly abandoned it
because of the wrong understanding that some architecture
of IP over ATM was broadcast incapable.

> IPFF defines a new mode: "silent multicast", which is
> somewhere between tradional Multicast and Broadcast.

No complication, please. Just say "broadcast".

						Masataka Ohta

---

From: Alexey Eromenko <[email-masked]>
Date: Mon, 14 Dec 2015 10:25:48 +0200

>Yes, if they move simultaneously, they will get minutes of delay (due
>to DynDNS update), and the TCP session will break.

BTW - delay can be reduced by using blockchain technologies - e.g.
Ethereum, (being Bitcoin 2.0 platform) -- it has only 15 seconds of
delay. Perhaps even few seconds. (for unconfirmed transactions)

Ethereum is even more secure than Secure Dynamic DNS, because old
transactions / bindings are world-visible.

It will work, but requires small amount of money to change IP
addresses (i.e. small amount of Ethereum on every mobile server or
mobile node), and implement Ethereum protocol on mobile nodes.
Also this approach is a *very* innovative and non-traditional one.

---

From: Robert Withers <[email-masked]>
Date: Mon, 14 Dec 2015 03:25:44 -0500

> For the time being, 16bit is good enough.
This NAT within 16bit architectures is mystical to me. That is always a 
caution and a calling, may you imagine, Ohta-san.

It pleases that you may receive merriment at my sharing that I have 
always tried to approach new domains and challenges by inquiring into 
how new principles may shape new understandings of a tradional state of 
affairs.

Alright, as usual, new principles to the domaing of broadcast, let us 
raise the trinity,  imperfection, eventually consistent, redundancy, 
host and meta-principlse by building a superstructure and see how big it 
is, just for fun.

In bytes
48 = 3 X 16bit port redundency.
50 = global address
98 = 48bit + 50bit slice
294 = 3 X 98bit packet redundancy
320 = 294bit + 26bit sanguinity mysticly measured,

320bits is Five 64bit registers.

5 64bit registers to hold the Five Fields. That's lovely.

best regards,
robert

---

From: Robert Withers <[email-masked]>
Date: Mon, 14 Dec 2015 03:35:45 -0500

Ohta-san, my apologies for saying things strangely, sometimes. The 
measure of sanguinity is like a priority, and the higher the number, the 
lower the priority. Then use genetic algorithms to tune the music, as it 
were.

3200 PMTU = 10 X 320 FFF (Five Field Frames) which is a pretty good size 
I think, if I've followed your most interesting conversation here.

I appreciate you,
Robert

On 12/14/2015 03:25 AM, Robert Withers wrote:
> This NAT within 16bit architectures is mystical to me. That is always 
> a caution and a calling, may you imagine, Ohta-san.
>
> how new principles may shape new understandings of a tradional state 
> of affairs.
>
> host and meta-principlse by building a superstructure and see how big 
> it is, just for fun.
>
> In bytes

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 14 Dec 2015 17:38:46 +0900

> 320 = 294bit + 26bit sanguinity mysticly measured,

I'm afraid triple redundancy makes effective address space
size smaller (one third of the original).

Anyway, if you want to have unrealistically large IP address
space, feel free to use IPv6.

						Masataka Ohta

---

From: Robert Withers <[email-masked]>
Date: Mon, 14 Dec 2015 03:49:49 -0500

> size smaller (one third of the original).

I was thinking each "address" slice was a separate address for purposes
of replication towards eventual consistency. As well, this support for
EC is in both communications & storage.  and even computation itself
with 26bits of control flag space.

-- 
... ^,^ best regards, robert

---

From: Alexey Eromenko <[email-masked]>
Date: Mon, 14 Dec 2015 10:58:55 +0200

> That's not a problem. User's experience of the delay is, which is
> why Mobile IP has servers of home agents as a stable point to
> receive packets.
>
> Note that, as you assume NAT (not very elegantly at the application
> layer), mobility must be port wise (which requires NAT transparency
> at the transport layer), because access points may be behind NAT.
>

MOPS (Mobile TCP) - as defined in my spec, will work fine through
source NATs (Home routers), assuming the Mobile Node is well...
mobile.

But it doesn't cover load-balancers (a.k.a. destinations NATs), and
doesn't cover if mobile node client is behind NAT, but the server has
moved (Home Router becomes a destination NAT, on traffic from
Internet).

---

From: Saku Ytti <[email-masked]>
Date: Mon, 14 Dec 2015 11:57:06 +0200

On 14 December 2015 at 06:10,  <[email-masked]> wrote:

Hey,

> viewpoint, as those are not powers of 2.

Can you explain which operation becomes significantly more costly,
which you'd use here?

I keep hearing this power of two argument, bit I'm finding hard time
imagining efficient parser or lookup implementation which cares about
it.
-- 
  ++ytti

---

From: Robert Withers <[email-masked]>
Date: Mon, 14 Dec 2015 05:05:15 -0500

> imagining efficient parser or lookup implementation which cares about

It strikes me that trisate gates are the future, when you think about it.

http://www.dauniv.ac.in/downloads/Digitalsystems_PPTs/DigDesignCh08L03.pdf

I'll have to work that math to see if 320 works in tristate. No, it 
doesn't but 324 works nicely, based on 4 bit nibbles.  In both cases, 
existing hardware can be used.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 14 Dec 2015 19:36:42 +0900

> Also this approach is a *very* innovative and non-traditional one.

Good luck.

					Masataka Ohta

---

From: John Kristoff <[email-masked]>
Date: Mon, 14 Dec 2015 07:23:49 -0600

On Mon, 14 Dec 2015 04:10:34 +0000 (UTC)
<[email-masked]> wrote:

> IP protocol version 5 is already defined and in usefor RFC1190, and
> that use would have to be deprecatedfirst. Picking 7 is easier; for a
> long time someoneon this list was pushing an idea of IPv8... and IPv9.

I believe the IPv8 you are referring to was hardly a serious proposal.
Regardless, 7, 8 and 9 were reserved for TP/IX, PIP and TUBA
respectively.

  <https://www.iana.org/assignments/version-numbers/version-numbers.xhtml>

John

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 14 Dec 2015 14:29:50 +0100

>   <https://www.iana.org/assignments/version-numbers/version-numbers.xhtml>

If we're including proposals not taken seriously, we should include
IPv16, although it always made my head hurt to fit that number into a
4-bit field.
I do believe the proposer took them seriously, though.

---

From: Robert Withers <[email-masked]>
Date: Mon, 14 Dec 2015 09:33:55 -0500

> I do believe the proposer took them seriously, though.

Group symmetries of multiword bus using tristate tryte word architectures:

a 4-tristate nibble has 99 states.
9 phrases of 12 tristates = 324 bits
3 words of 4 tristates = 1 36bit phrase
2 6bit trytes  = 12bit word
3 bytes = 2 trytes = 1 word.
9 bytes = 3 words = 1 phrase.
9 phrases = 27 words = 81 bytes

robert

logical symmetry: 99 tristate nibbles is 324bits.

---

From: Robert Withers <[email-masked]>
Date: Mon, 14 Dec 2015 09:44:13 -0500

It's 99 nibbles! :)

> 2 6bit trytes  = 12bit word

Oops! these are nibbles, so lets double in...
> 3 bytes = 2 trytes = 1 word.
This is wrong, it is 3 nibbles = 2 trytes = 1 word. We will need a 40 
bytes + 1 nibble register width.

Is this right? I think so. Is this right? I am not sure at all. It's 
instinct.

> 9 nibbles = 3 words = 1 phrase.
> 9 phrases = 27 words = 81 nibbles

Alright, that;s better
robert

"All the goodness is from God; All the mistakes are mine" - sufi proverb

---

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

Please keep this discussion on-topic.

Else I will have to set version to "FF" :)

-Alexey

---

From: Mike StJohns <[email-masked]>
Date: Mon, 14 Dec 2015 14:40:29 -0500

>    <https://www.iana.org/assignments/version-numbers/version-numbers.xhtml>

At this point I would suggest that the discussion on this topic has 
exceeded the mandate for the list.  I would suggest that creating a 
separate list and announcing it and moving all further discussion on the 
specifics of this proposal to that list would be appropriate.

At the beginning of this discussion the question was asked of why the 
sergeant at arms threatened posting restriction.  I wasn't actually 
surprised at that PR warning as we've already got a replacement for IPv4 
in the form of IPv6.   It took us over 20 years to get from initial 
discussions to reasonable deployments and we're still working on it. The 
form of the proposal - BCD representation of IP addresses as its best 
claim to fame - initially led me to believe it was a troll proposal 
rather than something serious.  I now see the author believes it to be a 
serious proposal, but I also believe that it's 20 years too late and 
provides no benefit over IPv6.   I'm willing to be shown wrong, but I'd 
really like not to read further discussions about it on this list until 
there's something of a buy in from a greater crowd.

Mike

---

From: Alexey Eromenko <[email-masked]>
Date: Mon, 14 Dec 2015 22:51:26 +0200

>
> At this point I would suggest that the discussion on this topic has exceeded
> the mandate for the list.  I would suggest that creating a separate list and
> announcing it and moving all further discussion on the specifics of this
> proposal to that list would be appropriate.
>
> surprised at that PR warning as we've already got a replacement for IPv4 in
> the form of IPv6.   It took us over 20 years to get from initial discussions
> to reasonable deployments and we're still working on it. The form of the
> proposal - BCD representation of IP addresses as its best claim to fame -
> initially led me to believe it was a troll proposal rather than something
> serious.  I now see the author believes it to be a serious proposal, but I
> also believe that it's 20 years too late and provides no benefit over IPv6.
> I'm willing to be shown wrong, but I'd really like not to read further
> discussions about it on this list until there's something of a buy in from a
> greater crowd.
>
> Mike

Fair enough.

1. How to create a mailing-list, (or Working Group) ?
2. Should I do it inside / as-part-of IETF, or some 3rd party resource ?

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 14 Dec 2015 14:54:41 -0600

Hi Mike,

If it is  in the form of next generation IP (especially in the context
of upcoming 5G) we welcome the discussions on our list, 5Gangip,
[email-masked] to subscribe
https://www.ietf.org/mailman/listinfo/5gangip

Behcet

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 14 Dec 2015 22:21:19 +0100

Hi Alexey,

As I suggested in my first post on this, you may want to talk to the IESG, they may suggest if this topic requires a BoF, a new mailing list, or the discussion to be continued in an alternative list (INTarea, others).

http://www.ietf.org/iesg/

Regards,
Jordi

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Dec 2015 13:43:56 +0900

> Regardless, 7, 8 and 9 were reserved for TP/IX, PIP and TUBA

When IPv6 WG decided to use a different EtherType from that of IPv4,
the WG decided to keep the version number field of IPv6, even
though the field is unnecessary, only to keep calling IPv6 IPv6.

That is, for new IPs, we have 16 bit space managed by IEEE, not IANA.

						Masataka Ohta

---

From: <[email-masked]>
Date: Tue, 15 Dec 2015 05:18:41 +0000 (UTC)

Important NewsFlash!

IP travels over things that aren't Ethernet, or don'thave Ethernet EtherTypes!

Film at 11!
 Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Masataka Ohta <[email-masked]>
 To: [email-masked] 
 Sent: Tuesday, 15 December 2015, 15:43
 Subject: Re: Introducing : Brand-new Internet Protocol "Five Fields"

                        Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Dec 2015 16:08:37 +0900

> IP travels over things that aren't Ethernet, or don'thave Ethernet EtherTypes!

Are you saying that some datalink protocol relies on IP version
field to demultiplex IPv4 and IPv6, even though the protocol
must have some field to demultiplex IP and non-IP?

For example?

IP travels over things over which non-IP packets also travel.

						Masataka Ohta

---

From: <[email-masked]>
Date: Tue, 15 Dec 2015 13:32:41 +0000 (UTC)

ISO HDLC.
 Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Masataka Ohta <[email-masked]>
 To: [email-masked]; "[email-masked]" <[email-masked]> 
 Sent: Tuesday, 15 December 2015, 18:08
 Subject: Re: Introducing : Brand-new Internet Protocol "Five Fields"

For example?

                        Masataka Ohta

---

From: Brian Haberman <[email-masked]>
Date: Tue, 15 Dec 2015 11:35:14 -0500

Hi Alexey,

> 2. Should I do it inside / as-part-of IETF, or some 3rd party resource ?

I don't think there is a need for a new mailing list for this topic.
Rather, I suggest employing an existing list that we have for larger
architecture issues. Info on the list is available at:

https://www.ietf.org/mailman/listinfo/architecture-discuss

I would encourage folks interested in this topic to participate in the
discussion on the architecture-discuss list.

Regards,
Brian

---

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

Hi Brian,

> discussion on the architecture-discuss list.

Right now, Alexey's protocols are being discussed in 5gangip list from
5G and next generation IP protocols perspective and I think he is
getting quite good feedback :-)

Regards,

Behcet

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Dec 2015 16:27:58 +0900

> ISO HDLC.

What do you mean "ISO HDLC"? Where is a specification of "IP over
ISO HDLC"?

						Masataka Ohta

PS

You should learn to quote properly.