73

Internet Protocol version 10 (IPv10) Specification

The name is funny (IPv4 + IPv6 == IPv10), but the actual proposal looks strange (one more packet format to battle incompatibility between packet formats).

Is it a normal proposal that have balanced pros and cons or just a minimally viable document to make fun of "IPv10" with a serious face?

If serious, please describle it in a "tl;dr" fashion. Why this and not another transition technology like nat64/teredo?

Ron Maupin
  • 98,218
  • 26
  • 115
  • 191
Vi.
  • 853
  • 1
  • 6
  • 7
  • 9
    When initially following the link there I expected to see "April 1". – Vi. Sep 09 '17 at 17:27
  • 14
    [Obligatory XKCD?](https://xkcd.com/927/) – A C Sep 10 '17 at 06:44
  • 6
    While the proposal may be a joke, the name is not. IPv4 through IPv9 are [already reserved](https://www.iana.org/assignments/version-numbers/version-numbers.xhtml) (although only IPv4 and IPv6 are used). IPv10 is the next available unassigned version. – user4556274 Sep 10 '17 at 12:21
  • 5
    Interestingly, the author proposes to use 16bit for the ASN field, when 32bit ASN are already common practice – Hagen von Eitzen Sep 10 '17 at 14:45
  • 4
    There is a fine tradition of light-hearted RFCs, traditionally published on 1st April. https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for_Comments is a good place to start. – Dominic Cronin Sep 10 '17 at 16:11
  • 2
    AFAIK people are seriously trying to fund his appearance at an IETF conference and supply generous amounts of popcorn (and a live stream). :-) – Martin Schröder Sep 10 '17 at 19:42
  • 1
    @HagenvonEitzen It also assumes all IP hosts are on Ethernet segments and I see no proposal for long-distance ARP. – user253751 Sep 11 '17 at 04:21
  • 1
    I faintly remember a Chinese IPv10 proposal from ~14 years ago or so, that was, as I remember, somewhat serious, although seemed to be tailored to faciliate surveillance. The only quote of that that I could unearth via a quick Google search: https://www.ietf.org/mail-archive/web/architecture-discuss/current/msg01041.html (middle of that e-mail) – Boldewyn Sep 11 '17 at 13:24
  • For reference, the author's name currently shows up on 5 Internet Drafts: https://datatracker.ietf.org/doc/search/?name=&sort=&rfcs=on&activedrafts=on&olddrafts=on&by=author&author=Khaled+Omar – IMSoP Sep 11 '17 at 17:27
  • The IPv10 RFC draft appears to have been submitted 2016-12-21, though it was [posted in a blog](http://internetprotocolv10.blogspot.com/2014/08/internet-protocol-version-10-ipv10-v.html) 2014-08-30. – Nat Sep 12 '17 at 03:17
  • 1
    @user4556274 "From here the name of IPv10 arises, as the IP packet can contain (IPv6 + IPv4 /IPv4 + IPv6) addresses in the same layer 3 packet header." – OrangeDog Sep 12 '17 at 09:54
  • 3
    a summary for anyone who hasn't read it: the author observes that the transition from IPv4 to IPv6 has been slow because not all vendors are implementing IPv6 in their devices. the author proposes IPv10 which can carry either type of address. the problem with this proposal is that vendors would need to implement IPv10 -- which means IPv10 doesn't solve the existing problem at all. – Woodrow Barlow Sep 12 '17 at 20:12

5 Answers5

87

As Ron said, anyone can write a proposal. I have a hard time taking proposals seriously from someone who suggests interconnecting satellites with optical fiber, though.

Also, I can't imagine this actual proposal gaining any momentum, especially due to this note:

All Internet connected hosts must be IPv10 hosts to be able to communicate regardless the used IP version, and the IPv10 deployment process can be accomplished by ALL technology companies developing OSs for hosts networking and security devices.

So, to solve the problem of IPv4-only hosts not being able to talk to IPv6-only hosts (and vice versa) you need to implement another protocol: IPv10. Then, why bother with that and not just implement IPv6 on that IPv4-only host and be done with it.

In addition, as can be read in RFC7059, there are already more than enough tunnel mechanisms available which can be used to solve parts of this problem.

To be honest, I think the author is hoping on some commercial success by claiming copyright, as can be read in these tweets:

ANNOUNCEMENT: Protecting the Copyright, The #IPv10 and KHALED Routing Protocol (#KRP or #RRP) are developed by @The_Road_Series CEO.

They MUST NOT be represented or published by any organization without approval from their developer @Eng_Khaled_Omar

Today 26th of May, 2017, a 2nd request was sent to the ietf for removing #IPv10 #KRP (#RRP) drafts from their repository.

Teun Vink
  • 16,953
  • 6
  • 44
  • 70
  • 15
    Well you know what they say - you can solve all problems with another layer of abstraction, except for the problem of too many layers of abstraction! – bye Sep 09 '17 at 22:39
  • 15
    ROFL at the satellites linked by fiber. Sounds about as reasonable as IPoAC. – reirab Sep 10 '17 at 06:41
  • 16
    He is out of luck with the copyright. He has already assigned copyright to the IETF by engaging in the RFC process, regardless of what it may say in the text of the document, which does not conform to [IETF policies](https://tools.ietf.org/html/bcp78#section-5.6). – user207421 Sep 10 '17 at 12:52
  • 16
    Time to re-train my brain not to implicitly trust anything I read in the RFC format. – Matt Sep 10 '17 at 16:04
  • 6
    Tweet link made my day(/week/month) – Failed Scientist Sep 10 '17 at 16:13
  • 1
    If the discussion on that tweet is to be believed, the proposal won't be around for much longer. – Mast Sep 10 '17 at 18:41
  • 2
    @reirab Except IPoAC actually got implemented once. – cpast Sep 11 '17 at 03:05
  • 2
    @cpast Cool. Did they perform extensive testing / bandwidth measurements etc., or solve the RTT delay problem? – Hagen von Eitzen Sep 11 '17 at 12:03
  • 1
    It requires routers to implement IPv10, but all hosts inside a network can keep using whatever they use now: IPv4 or IPv6. It does address a problem which is a reason why it's taking so long for IPv6 to replace IPv4: there was never a direct way for an IPv4 host to talk to an IPv6. Not that I think the presented solution is a viable one. –  Sep 11 '17 at 15:07
  • 2
    @HagenvonEitzen: [It had a ~55% packet loss ratio, but supposedly the throughput ain't too bad.](https://en.wikipedia.org/wiki/IP_over_Avian_Carriers) – tonysdg Sep 11 '17 at 17:50
  • 3
    The fiber-satellite proposal has some ASCII art, er, "a technical figure", that I am unable to interpret as anything *but* a tie fighter. I can't decide if the author is a serial troller or completely serious, but I laughed either way. – brichins Sep 11 '17 at 22:41
  • Can you add the tweet as text? The link mays be broken someday. – aloisdg Sep 12 '17 at 09:02
  • 1
    @brichins It looks like a Tie-Advanced maybe? You're totally right. – BlackVegetable Sep 12 '17 at 15:46
  • @tonysdg I would be more concerned about latency though... – Maciej Piechotka Sep 12 '17 at 22:10
  • What's wrong with the satellites being linked by fiber? I'd also link them by fiber to the earth, for added redundancy. – user276648 Sep 13 '17 at 02:15
  • 2
    @user276648 Scale. You'd need roughly 40,000 km of fiber for a single orbital "ring" of satellites -- simply manufacturing that much fiber would be monumentally expensive, let alone getting it into orbit. And in anything other than a geosynchronous orbit, it'd break under its own weight! –  Sep 13 '17 at 06:34
  • 1
    @user276648: There's also the worry of [space debris](https://en.wikipedia.org/wiki/Space_debris). We have a hard enough time ensuring it doesn't hit any of the more critical satellites, the ISS, etc. 40,000 km of fiber would make one helluva target. – tonysdg Sep 13 '17 at 13:18
  • @tonysdg & duskwuff: I thought it would be clear I was being ironic, adding that for added redundancy those satellites should be tethered to earth by yet another fiber... – user276648 Sep 14 '17 at 01:41
  • @user276648: Sorry :) Add a "/s" next time at the end, just in case ;) – tonysdg Sep 14 '17 at 13:50
28

You must remember that anyone can submit proposals to the IETF, and they are taken seriously, until they are either adopted or die due to lack of interest.

This particular proposal has expired and been renewed by the author several times. It doesn't appear to have much, if any, support, and it doesn't even have a proposed RFC status, e.g. Standards Track. The author is probably serious about his proposal, but he doesn't appear to have garnered any serious support for the proposal.

There is a proposal to sunset IPv4 that is serious, and it has a full working group behind it, but it has a long hard road ahead of it to full adoption. It intends to address the problems inherent in the transition from IPv4 to IPv6.

Ron Maupin
  • 98,218
  • 26
  • 115
  • 191
19

Is “IPv10” a joke or a serious RFC draft?

Both. That draft doesn't solve a single problem but opens a can of new ones. I guess that bloke is serious and he doesn't get what ridiculous schemes he's proposing. The joke's on him.

There's an excellent reply to that draft on xkcd, inevitably.

The Fiber Satellite proposal is even more ludicrous as it neglects required fiber lengths (265,000 km per orbit in geosynchronous altitude) and totally ignores orbital mechanics (it's utterly impossible to keep satellites in different orbits at the same distance).

IETF should block him for trolling.

Zac67
  • 81,287
  • 3
  • 67
  • 131
1

It's a serious attempt to solve a real problem. Whether the solution is good or bad (it's probably rubbish), its problem statement is correct: the current strategy of trying to implement IPv6 has so far failed. As its introduction says, 19 years of IPv6 and there is still no way we can see ourselves to have transitioned in any meaningful way.

As it mentions, we have already got some bridging solutions such as NAT64 (it mentions others too). These are fine and good but still don't allow a full transition to IPv6 either - they assume public IPv4-only hosts are here to stay.

That said, I am skeptical about how this specification would help given what I see are fundamental problems with the transition to IPv6. I haven't spent much time trying to understand how it tries to, and maybe it is wiser than I (though consensus among the other answers suggests I'm right), but it seems to suffer the same bootstrapping problem that IPv6 has in the first place.

To answer the But it is still a serious attempt at solving the problem.

thomasrutter
  • 119
  • 3
  • 4
    Everything is ready for IPv6 for years. Actual adoption may seem slow, and the reason is only because IPv4 still "works". However IPv6 traffic is about 20% and growing quite fast. In 2017 an internet service not providing IPv6 should really reconsider its position. The thing we really don't need now is yet another transition mechanism. – ch7kor Sep 12 '17 at 16:05
  • All true. But I feel that IPv6 will never ever reach a meaningful penetration (the first 20% is supposed to be the easiest, the last 20% should be much harder) and one day people will decide on some other way forward. The thing about technologies intended to ease the transition is that once they are around for long enough, you realize they have *become* the new internet. – thomasrutter Sep 12 '17 at 23:23
  • 5
    Actually, one could argue that the last 20% will be the easiest because when IPv6 has 80% of the Internet traffic, the proposal to sunset IPv4 will probably be the standard, and most ISPs will stop routing IPv4 traffic. The situation will be reversed from the inception of IPv6 so that IPv4 traffic must be tunneled across the (IPv6) Internet. – Ron Maupin Sep 13 '17 at 13:32
0

There is some validity with the implementation of a new protocol. The current translation protocol is NAT64.

NAT64 is an IPv6 transition mechanism that facilitates communication between IPv6 and IPv4 hosts by using a form of network address translation (NAT). The NAT64 gateway is a translator between IPv4 and IPv6 protocols,1 for which function it needs at least one IPv4 address and an IPv6 network segment comprising a 32-bit address space. An IPv6 client embeds the IPv4 address it wishes to communicate with using the host part of the IPv6 network segment, resulting in an IPv4-embedded IPv6 addresses (hence the 32-bit address space in the IPv6 network segment), and sends packets to the resulting address. The NAT64 gateway creates a mapping between the IPv6 and the IPv4 addresses, which may be manually configured or determined automatically.

Source

The main idea for IPv10 would be the elimination of NAT64. Strictly speaking, NAT has always been a bottleneck.