Can OpenWrt Route 240.0.0.0/4?

Installing and Using OpenWrt Network and Wireless Configuration
1

Dear Colleagues:

  1. I am new to this forum. So, please pardon my ignorance, and coach me along. Thanks a lot in advance.

  2. Our team has come upon an approach nicknamed EzIP (phonetic for Easy IPv4) that can expand each public IPv4 address by 256M (Million) fold, utilizing the long-reserved yet hardly-used 240.0.0.0/4 block, to create a RAN (Regional Area Network) that can serve an area as big as the largest city (Tokyo Metro) or 75% of countries around the world. The
    RANs occupy a newly identified cyberspace between the public WAN (the Internet) and the private LAN / HAN (business and private networks). This approach resolves the IPv4 address pool depletion issue, as well as introduces a few interesting benefits. The following is a proposal that we have submitted to IETF:

https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03

  1. Since each of these RANs (called "sub-Internet" in the Draft) architecturally appears to be a private premises (or simply an IoT) tethering off the end of the access channel to an Internet ER (Edge Router), we thought that the closest existing physical product to verify
    the basic function of the implementation module, SPR (Semi- Public / Private Router) would be an RG (Routing / Residential Gateway). To facilitate the development of the rest of the SPR functions, we thought that an OpenWrt supported RG probably is the optimal baseline vehicle.

  2. Going through the OpenWrt website, I am impressed by the amount of work that has been done. As a newcomer, however, I do not know how to choose from the long list of hardware. What I am looking for is an OpenWrt supported router that can perform the functions expected from the SPR on page 8 0f the following whitepaper. It is essentially an extra stage of the common RG, but based on 240.0.0.0/4. I am hoping some of the current
    OpenWrt supported RGs on the market can be quickly configured to deliver this. I have come across a few topics on this website mentioning 240.0.0.0/4. But, with my limited knowledge, I can not tell whether they imply that this address block will be routed or blocked.

https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf
  1. After verifying the architecture as above, the next step will be enhancing the software in this RG with the capability to recognize an EzIP header (IPv4 header with EzIP Option Words) as described in the IETF Draft above. So that a plain router, instead of a NAT, function will be provided to the associated packet.

I would appreciate very much any guidance that could be offered.

Regards,

Abe (2018-10-01 14:01)
VP Engineering
Avinta Communications, Inc.
Milpitas, CA, 95035 USA

2

OpenWrt uses a Linux kernel that is close to stock, along with iptables pre-installed and nftables available.

I personally can't get behind carrier-grade NAT or other approaches to keep IPv4 on life support, but if all the hooks are there in the Linux kernel, then OpenWrt should be able to support your explorations.

https://openwrt.org/docs/guide-developer/build-system/start

1 Like
3

Can_OpenWrt_Route_240.0.0.0/4?

To answer your title question, I have successfully routed all valid CIDR ranges I've tested on an OpenWrt router.

Since it seems that only RFCxxxx
...BTW, you are aware that - the RFC Editor has not issued you a number, yet?

You will probably have to write code to recognize the IP Options Header for your purposes.

Per the community guidelines , please refrain from signing posts.

4

Hi, Jeff:

  1. Appreciate very much for the quick response. However, your recommendation seems to be too advanced for a beginner like us. What we need to get our feet wet is some simple guidance for the dummies.

  2. The RAN that I described is basically a virgin IPv4 environment that is isolated from the current Internet sophistication, public or private, because it is previously unused since the 240/4 block was "Reserved" dated back to 1981-09. With the size of Tokyo Metro that each RAN can serve, a RAN can pretty much stand alone, and everything in it can be built from scratch. No CG-NAT or such to be concerned with. Just think a RAN is a common private network on a residential premises, but it is huge.

  3. To illustrate the limited knowledge that we have, we found that 240/4 is listed along with common private network blocks, 10/8, 172.16/12 and 192.168/16 among quite a few others in tables on discussion threads such as the following:

[Solved] Can two ipsets be used in a single rule
NAT leakage on TL-WR1043ND v4

Our intuitive reaction is that these imply that 240/4 are routable just like the three private networks as inherent OpenWrt capabilities. Is this correct? If so, would this mean any OpenWrt supported hardware is capable of handling this 240/4 block, so that all we need to do is to specify 240/4 as the beginning address for the DHCP server configuration in such RGs?

  1. If not all OpenWrt supported hardware can do so, how could we find out which ones may be able to?

What we need is something as dumb as the above for the time being, so that we can begin to demonstrate the EzIP architecture.

Thanks in advance,

Abe (2018-10-01 15:53)

5

Same software, so all hardware is therefore capable. The CPU overhead - you will have to benchmark yourself once you have a network stack capable of RFC-draft-chen-ati-adaptive-ipv4-address-space-03.

6

There's unlikely anything OpenWrt-specific about what you're trying to accomplish. I don't need to be "sold" on the product.

If you find it technically challenging, then you might want to have someone with deeper networking skills join your team.

All in all, I'm confused by why you're asking here for basic, technical guidance, given that the Draft is from your own organization

<Network Working Group>                                      A. Y. Chen
Internet Draft                                                 R. R. Ati
Intended status: Experimental               Avinta Communications, Inc.
Expires: December 2018                                    A. Karandikar
                                          India Institute of Technology
                                                          June 10, 2018
1 Like
7

Also, you'll have to eventually work with the IANA to reallocate the block 240.0.0.0/4, as this block is listed as:

  • Not vaild as a source address
  • Not valid as a destination address
  • Not forwardable
  • Not globally reachable

See: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

  • Why can't the Carrier Grade NAT block be used for this technology, instead?
  • Can't IPv6 over IPv4 technologies be used instead?
1 Like
8

Hi, Jeff:

  1. Yes, my two coauthors are seasoned IT professionals. They have been looking at OpenWrt. However, their initial impressions were that it may be some endeavor to get into it. So, I thought that I would ask a dumb question to see if colleagues on this forum would offer a tip to focus our attention on the initial step.

Hi, lleachii:

  1. What you said is true. However, I did not make a explicit conclusion about the RAN after described it as isolated from the WAN and the LAN. That is, with the Demarcation principle, the RAN is quite independent from both WAN and LAN. Since the RAN is in a space defined by the 240/4 block which was "condemned" by every current Internet rules and conventions, yet it is being treated by EzIP as a new found "frontier land", hardly anything from the current Internet applies, unless it is desirable for this RAN. As correctly pointed out by several reviewers, the deployment of RANs can be done stealthily without the blessing from IETF. In fact, EzIP has been in private review for awhile, even though the last IPv4 Working Group SunSet4 has been concluded almost half year ago. EzIP has also gotten into records of two of ITU-T Study Groups.

  2. The whole EzIP solution turns out to be getting the job (resolve IP address shortage) done without anything more advanced than RFC791. Because it can be deployed stealthily, it is much easier to proceed than IPv6 based approaches that seem to rely on hard marketing promotion tactics.

  3. Thanks for the advice about not signing off explicitly. I thought that since I was posting a document of mine through URL, anyone who has curiosity can figure out who am I via a few mouse clicks on the web. It would be prudent for me to identify myself right from the beginning, so that we can converse with more direct language to expedite the progress. Also, I have found time stamping my writing extremely helpful in tracing back a long thread.

  4. " you are aware that - the RFC Editor has not issued you a number, yet? ":

Yes, I have been very careful about referring to the EzIP document as Draft. It is not anywhere close to have a RFC number. But, that is not the point. Please see Pt. 2) above.

  1. As I stated in my initial posting, I am new to this forum. I am having trouble to respond to multiple feedback from several colleagues at the same time, because they seem to be interleaved. If I missed responding to anyone's comment, please let me know.

Thanks,

Abe (2018-10-01 21:09)

9

Hi, lleachii:

  1. "Why can't the Carrier Grade NAT block be used for this technology, instead?":

Because the goal is to establish end-to-end connectivity. SPR does have the CG-NAT equivalent functionality included to maintain the service to EzIP-unaware (existing) IoTs. The plain router function for the EzIP-capable IoTs is what the long term goal of the SPR.

Abe (2018-10-01 21:33)

10

Abe, you do realize that the 240.0.0.0/4 netblock is on pretty much every DNR list and every decent firewall list out there.

Good luck with your idea.

If they find Linux networking challenging, you may need more than just good luck.

11

Hi, Jeff:

  1. "the 240.0.0.0/4 netblock is on pretty much every DNR list ... ":

Thank you for pointing this out. However, this was the first thing that we checked and then figured out a system configuration to totally get around these types of restrictions. As I described, the RAN is not in any of the currently defined cyberspaces, because it is using and only using the "condemned" 240/4 block. By tethering a RAN off the end of one IPv4 address, the demarcation principle isolates all the concerns that you identified. These are very subtle but important aspects behind the RAN. This is why RANs can be deployed stealthily and got IETF related people "nervous".

  1. The reason that ITU-T is paying attention to this proposal is that the RANs can realize the CiR (Country-based Internet Registry) proposed by ITU-T a few years ago without establishing an organization that got the five RIRs "uptight". Now, the RANs can do it stealthily anyway.

  2. You may want to browse over Reference [2] of the EzIP Draft. It is a historical work by "Internet officials" (check the credentials of the authors) showing how close they had gotten to the EzIP solution. But, they missed the critical concepts behind creating the semi-public space for and applying the demarcation to the RAN. So, we know that our solution is not out-of-the-blue crazy. (The way that we are citing this important reference is actually not "kosher", because it was only a Draft, just like EzIP.)

Let's carry on the discussion.

Abe (2018-10-01 23:48)

12

Well, I personally don't think the world needs another half-baked tunneling scheme, especially one that fails to address many of the shortcomings of IPv4 in ways other than a limited address space and requires complete rework of network infrastructure and security. The time for that was 10-20 years ago. Quoting some ancient draft that went nowhere isn't terribly supportive of the merits of your company's proposal.

IPv6 is well on the way to adoption, and you should check the stats you quote

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

image

13

I wasn't aware that the ITEF was looking for any long term solutions to IPv4 exhaustion, except for IPv6. Can you provide this information?

Incorrect. No one [here] has pointed this out!!!

  • The IP space you wish to use is reserved
  • Your paper states in Section 7 - that you don't have to coordinate with IANA, that is false.
  • You must get the blessing of the IANA in order for other manufacturers to remove the 240.0.0.0/4 space from their code, bogon lists, etc.

What does this mean???
Internal to your company?
On the RFC website?

The paper appears to be about 22 months old. The paper says what you're describing is EzIP, so how has it existed for "awhile?"

  • What does marketing have to do with a IPv4 exhaustion technology!?!?

  • Wouldn't ISPs have to implement EZIP too (meaning you have to market this technology to them)?

  • Wouldn't the provider just setup the router with another exhaustion technology, in a same manner you do here?

  • Please explain what advantage this technology has over IPv6 or Carrier-Grade NAT...I'm not quite understanding how you maintain an end-to-end principle?

  • If an end-to-end principle is maintained, how do you open IPv4 ports with your technology?

  • How do you solve port exhaustion at the Public Border???

  • How do you maintain the end-to-end principal without mangling ports???

It's also difficult to hold discussion when you refer to this technology as if it is already released and ubiquitous.

1 Like
14

The simple answer is that OpenWRT and any Linux based system can be told to route your desired netblock, just add the appropriate routes to the kernel using "ip add route" or the like. There's nothing in the kernel that prevents you from adding these routes.

The merits of your proposal should be discussed elsewhere. It's just not relevant to OpenWRT.

1 Like
15

Hi, Jeff:

  1. "tunneling scheme":

Honestly, I do not classify the EzIP scheme as anything significant enough worth being given a fancy name like this. EzIP is just a specific use of the Option Word within the RFC791 design, already used by various applications, at least one RFC and one Draft for address improvements. EzIP is just one specific case that happens to touch a rather sensitive topic.

  1. "IPv6 is well on the way to adoption .... ":

I am not surprised that you bring up this statistics. A simple keyword search on Google normally brings this up as the first hit. This is part of the hidden push for IPv6. I wonder if you noticed a subtle phrase at the end of the description " users that access Google over IPv6 "? Google is very careful with consequences of legal implications.

  1. I was no exception. When I was studying this topic, I came upon this initially. It was through a tip from a senior Internet staff that led me to the AMS-IX statistics which he stated clearly that it was one of a few places that such information was accessible. With regulate update of about every 15 minutes continuously for the past few years since I started monitoring it, I will be hard pressed to trust another data, unless you can show me the diligence.

  2. By the way, if you trace the history back, this ongoing set of stats started at least back to 2012 when it was presented to the "IPv6 Day". It is rather serious effort, as far as I could tell.

https://ripe65.ripe.net/presentations/122-ams-ix_ipv6_day_2012.pdf

Abe (2018-10-02 15:43)

16

Hi, lleachii:

  1. "I wasn't aware that the ITEF was looking ... ":

Please try following the events related to IETF SunSet4 WG Conclusion. You will find that there was a setup to watch for future IPv4 topics, "just in case". Plus, there was an article about whether to call IPv4 "Historical" that touched the regret of IETF neglecting NAT development. Putting these together, I hope that you can see the unusual events that may be going on. If you can not figure the above out, I will be glad to supply you the URLs.

  1. " No one [here] ":

I was not referring to colleagues here, because I hinted that EzIP is being reviewed by quite a few parties. Bing sensitive, I can not disclose their identities at this juncture. We have to discuss on its own merits as I could help you to see them.

  1. "You must get the blessing of the IANA.. ":

Not if I can find a never existed frontier cyberspace to implement the EzIP scheme.

  1. " The paper appears to be about 22 months old. ... ":

Where did you decipher this information from? The latest version of the Draft as I referred to from this forum was posted in 2018 June.

  1. " What does marketing have to do with a IPv4 exhaustion technology!?!? ":

You are wrapping around the IPv6 issue to EzIP. It is getting confusing.

  1. "Wouldn't ISPs have to implement EZIP too ... ":

In a Kosher sense, yes. In practice, no. This is because anyone can start a RAN from an IPv4 address to begin a regional Internet-like service in parallel / overlap the existing global Internet.

  1. " ... I'm not quite understanding how you maintain an end-to-end principle? ":

Simply look at SPR as a CG-NAT with bypassing plain router path setup for packets with EzIP header, then you have end-to-end connectivity.

  1. " ... port exhaustion at the Public Border??? .... ":

I am not sure what specific Internet element that you are referring to. But, with so many IPv4 addresses becoming spares due to the expansion of assignable (semi-) public addresses, Do we need to worry about this subject? Won't it become moot issue?

  1. "It's also difficult to hold discussion when you refer to this technology as if it is already released and ubiquitous. ":

Sorry about the grammar issue. I believe that in writing specification, or similar, it is preferred to write it in present tense. Otherwise, it will be awkward in the future to read something already working for a long time. Or, all the documentations have to be re-written or tense adjusted at certain point of time. If it helps, please just treat any present tense of every sentence as future tense when you read it. Thanks.

  1. " ... please refrain from signing posts. ... ":

As an old timer, I believe attempting to stay anonymous or private is another odd behavior these days from being upfront to others in the past. However, I am not going to start a distracting debate on this. I will try not to sign off on this forum and see what happens.

17

Hi, dlakelan:

  1. " ... OpenWRT and any Linux based system can be told to route your desired netblock ... ":

Thanks for the clarification. But, you still did not address my basic dumb question. That is, is 240.0.0.0/4 inherently routable in OpenWRT as the three common private network blocks? Do I need to specifically specify it?

  1. " The merits of your proposal should be discussed elsewhere. It's just not relevant to OpenWRT ":

Basically, I agree. Well, if I could get a straight answer without being looked upon as crazy, I would do so. This was actually how I started this thread. I condensed the EzIP work to the simplest metaphor that I can come up with after learned from the reactions on quite a few fora. Look what is happening. Some colleague wants to know what is going on behind the EzIP. It would be impolite to not respond such valid inquiry.

18

:open_mouth:

Each IP uses about 65,000 TCP and UDP ports, if you alter either the IP/port of the SRC or DST, you have broken the end-to-end principle.

So, no, it won't become moot. That's the concept of the end-to-end principle; and why there's IPv4 exhaustion.

Yes, we need to worry. If we didn't, why are you discussing your EzIP???
Just use the "spares."

I think this question has been answered multiple times. OpenWrt doesn't have a concept of "private," they're just IP addresses. You have to specify all IP blocks, so this question is confusing.

You issue is with devices in this "new found cyberspace" you're refering to. But, I assume this "space" will be controlled by ISP routers, they need to be able to route 240.0.0.0/4 as well.

Also, you don't have to make a reply to each person.

:+1:

This is no longer related to if it works with OpenWrt.

19

Hi, lleachii:

  1. "I have successfully routed all valid CIDR ranges I've tested on an OpenWrt router.":

I spotted this earlier response from you. Since the 240.0.0.0/4 block was "condemned" for a long time, it must be outside of the "valid CIDR ranges". So, you have not tested the netblock that I am interested in. Correct?

20

@lleachii is correct, there is nothing special within the kernel about this address range, it's treated like every address range. To be sure I just created a dummy device and gave it 240.0.0.1/4 as an address and then pinged it... it worked fine on my linux desktop machine. At this point I think you need to just get yourself a device and install OpenWRT on it and start playing with it. Just give one of your interfaces a 240.0.0.1 or similar address in the configs and see what happens. I don't anticipate any problems when all devices are under your control.