I have an idea of operating a residential gateway on 240.0.0.0/4 netblock. It will establish a private network with a lot more possible addresses than the current three private netblocks. If this basic configuration works, there are few interesting consequences. So, I posted a Topic on this forum requesting for recommendation of hardware that may require minimal technical skill to handle. One colleague hinted that there might be a $20 solution and a couple others began to test whether the idea is realistic although it is supposedly supported. Unfortunately, before we could reach any definitive answer, the moderator closed the thread because some colleagues went off track from the subject. So, I am starting a new Topic to carry on, hopefully we can stay on the track.
Based on filters such as better memory size, currently supported, no cautionary issues, lowest price at mass merchandisers, etc., I have identified two possible candidates, (Due to certain uncorrelated data between tables, I am not sure whether what I picked up do meet the criteria fully.)
A. TP-LInk TP-Link Archer C20 AC750 Wireless Dual-Band Gigabit Router, $34.99 available from B&H Photo (https://www.bhphotovideo.com)
B. TP-Link TP-Link AC1200 Wireless Dual Band Gigabit Router, $49.99 available from Fry's Electronics (https://www.frys.com/)
Could any colleague confirm that these are suitable choices? Is there any better suited product that I should look at? Lastly, is there any candidate that may even be within the $20 range that I heard?
I actually considered a purchase of the AC1200 today; but it only has a single core CPU
Also, the AC750 only has 100Mbps Ethernet ports
What are you seeking suitability for, though?
Please be aware: There is an issue with using the 240.0.0.0/4 block that must first be solved. You noted this issue as "political" in the previous thread; but such is not the case - as your problem is defined in RFCs, and in your draft (containing the falsity in Section 7).
As you are aware from your previous thread, there are major issues (RFC1112 and RFC3232):
using the IPs as a SRC
using IPs as a DST
using the IPs on a forwarding plane
and therefore, an additional issue with the IPs being used Globally
I hope you begin to understand this limitation, or plan to code around it on all devices you control in this domain/Autonomous System. I also hope you understand that there are many devices hard-coded to not use this block!
I surmise to say, the original topic was regarding an RFC draft and the feasibility of using the technology with 240.0.0.0/4 on OpenWrt devices. You were told that OpenWrt was software and as such, should work.
Of the five points/inquires raised by you in the original topic (numbered 0-4), the [slightly] off-topic post(s) were regarding the purchase of the hardware. The remainder was trying to understand how your technology actually works...why IANA-allocated space cannot be used, why your technology doesn't violate the end-to-end principle - all to discover your draft notes masquerading is used, thus breaking it.
After all, you did post an RFC Draft in an OpenWrt community forum...comments should be expected, even it the mods close the topic.
Thanks for catching me here again. However, as I stated, we need to stay on track to avoid irritating the moderator, again.
But, I will entertain your comments other than "making a current RG to run 240/4 netblock" offline. You can find my eMail address at the end of the EzIP Draft for such purpose. I observe a discipline of responding none-real-time messages within 48 hours or shorter. So, if you do not hear from me, PING me through other channels, such as submitting a new comment on this thread.
Good to know that you approve the two that I picked. Looking at the information about AC1200 on OpenWrt, I just noticed that there is a phrase limited OpenWrt supportability on this device. Should I be worried about this?
"What are you seeking suitability for, though? ":
Simply, all I wanted to do is to demonstrate that a common RG running with OpenWrt can use 240/4 netblock, other than the three common private netblocks. I am not looking for any performance, such as number of ports supported, or throughput. For this phase, we should not distract ourselves with the topic in Pt. 3) below.
**using the 240.0.0.0/4 block that must first be solved. .... **:
This part is associated with the "Demarcation" principle that we need to discuss offline. This is not a trivial topic. You may check my LinkedIn profile to get some idea where I came from and what I probably know:
https://www.linkedin.com/in/chen-abraham-b7a918/
"any candidate that may even be within the $20 range ":
Thanks for the links. I shall study them.
"the moderator closed the thread.... ":
A. All technical discussions and the pending conflicting test results were healthy because they validated my initial request / question as an uninitiated outsider.
B. I believe that the issue was some of the colleagues started to check on my company's profile and credential, etc. then make comments. They would not contribute to the discussion thread, as I already commented on it and asked to stop by providing a brief run-down.
Thanks,
Devices with Broadcom WiFi chipsets have limited OpenWrt supportability (due to limited FLOSS driver availability for Broadcom chips). Consider this when chosing a device to buy, or when deciding to flash OpenWrt on your device because it is listed as supported. See broadcom_wifi for details.
So if this is for Wireless testing, you may wish to pick another device.
If you are merely trying to flash the router with code that will recognize and route 240.0.0.0/4, it should be more than OK.
I think you misunderstand Internet technologies. That information needs to be in your [accurate] RFC Draft - for any interested Internet Engineer to read. I think you're also missing that CODING MAY BE REQUIRED, EVEN ON THE OpenWrt OS....and that is very much on-topic here.
Ignoring the technical merits of your proposed tunneling scheme and looking only at the proposed protocol, any OS will require either kernel-level programming and/or a complex set of packet-rewriting rules implemented in either or both the "firewall" rules or user space. OpenWrt will be not be significantly different than any other Linux-based OS in this regard.
The referenced draft proposal, even in a fully deployed connection between devices both residing in the walled garden, requires packets to be generated and understood that are outside of what is implemented in a standards-compliant TCP stack.
Cooperating devices along the way will require complex packet interpretation and generation capabilities, as well as application programming that will manage the potentially distributed registry of addresses within the walled garden.
" WiFi ... flash the router with code that will recognize and route 240.0.0.0/4, it should be more than OK.":
Correct. The first step that I am attempting is only to verify that the 240.0.0.0/4 is routable. WiFi would add one layer of uncertainty, if the result is negative.
" CODING MAY BE REQUIRED, EVEN ON THE OpenWrt OS... ":
I tried to be open on the first Topic by presenting the EzIP Draft. That got you concerned on many angles. On this Topic, I opened by saying all I wanted to do is to try 240/4 netblock in an ordinary RG. But, you still remembers the tasks down the road! Yes, the next step will involve coding efforts for sure. But, the impression that I got from the "ipset-A Bogons" list in the following thread seems to tell me that the 240/4 netblock is treated by OpenWrt as the same as the three common private network netblocks. This was what I was requesting in my first Topic. But, we got to different ways of discussions. Could you confirm?
As I just explained to lleachii, with a full disclosure in my first Topic, I got colleagues looking at the EzIP task from too many angles. This Topic is purposely focused on just how to get a hardware to verify that the 240/4 netblock is supported by OpenWrt in an RG. Let's try not to go beyond it.
Later on, in the full EzIP deployment, certain modules are expected to be new, which means software related coding is expected either in a new design module or enhancing the code in some existing modules. Still, the change is intentionally confined by system design as described in the EzIP Draft. Only SPR and EzIP-capable IoTs are expected to have new software. Existing modules (routers and EzIP-unaware IoTs) are not to be altered.
" .... within the walled garden. ":
I am not sure why are you using this phrase. Would you say that a private premises served by one of the three private network blocks is a walled garden? If so, there is an old terminology, demarcation that has been used for the four traditional utilities, water, gas, electricity and telephony for a long time. It is normally at the corner of a property where utility meters are located. For telephony, a NID (Network Interface Device) is located at the general vicinity, as well. The exact locations of the demarcations are not important. But, the two sides of each meter or the NID determines who (service provider or the owner of the premises) is responsible for everything on that side. This also applies to the RG (Routing / Residential Gateway) for Internet setups. When I brought up the word "demarcation", no one seemed to respond to it, but followed with "walled garden". So, I suspect that they mean pretty much the same thing. Correct? Instead of implying a physical "wall", "demarcation" is often followed by a word "line" to complete the expression implying conceptual.
The purpose of this discussion appears to be nothing more than driving traffic to the OP's draft and commercial endeavor.
Edit: I'll take that back, it also might be to enlist "free" engineering help so that he can save another of the firm's proprietary, private networking schemes from silent death as the IETF draft expires.
I called a spade a spade before. Nothing I have read from the OP, nor discovered in relation to his supposed company and colleagues' efforts lead me to any other conclusion.
You guys are kidding right?
He asked for a simple router recommendation, and the pitchforks came out almost immediately and went down the same discussion path as last time (that was locked for obvious reasons).
Just let it go.
The answer was given (albeit, with commentary dragging us right back here). That should really just be the end of it.
: 
