I apologize. I understand now and stand corrected - because of @mbo2o's posting.
For some reason, I keep thinking that there's an organization (i.e. IANA) that already handles that for the entire globe...that's incorporated by law in some territories. I also remember some companies program this IP space; and that all type of machines can be used on the Internet. So if I mention a Windows or MacOS-based Server/router (for example), I get confused when our colleague corrects me. I've never been beholden to a single individual, or by what I'm required to use and understand from a closed source - to access the "real Internet." I only understood one nation on Earth to currently do so; and that's the D;RK.
RFCs used by all Internet Engineers on planet Earth seem easier to comprehend - but they keep getting in my way of understanding his technology.
This is not accurate (by RFC) since the year 1994 (when the Autonomous System Number was proposed for use in routing). ISPs have no restriction on "being careful" than any other Internet user. They can employ the addresses anywhere in their system as they desire...
Hence I don't understand this telephone thing...WHAT HARDWARE CONTROLS THAT?
Relevance: If you intend to use hardware that must use:
What hardware is controlling this "telephone book?" IT WILL NEED A LOT OF CPU AND MEMORY, MORE THAN THE EQUIPMENT YOU'RE SUGGESTING FOR THIS EXPERIMENT WITH THE GPL'ED SOFTWARE.
Proof I'm on track:
(off track thought to all of this):
Now, who controls that hardware, and hence, all the "Regional 240/4 'Telephone Books'"?
You may be mixing a couple topics into one another.
" ISPs have no restriction on "being careful" ":
I was referring to the often mentioned "address leak" related issues when people talk about CG-NAT. I am no expert to dig into their issues.
"What hardware is controlling this "telephone book?" ":
You seem to be inserting your own words into an expression that I made somewhere else and then make comment on it. I was responding to your question about how would the 240/4 block be managed, by saying one obvious approach is mimicking the good old day telephony practices. It lead to a lot of topics that is not relevant on this forum. Also, the "hardware" seems to come from a different thread (see Pt. 3) below.) Thus, please contact me via eMail if you like to dig into this.
"What kind of hardware configuration should I look in them to qualify for supporting this approach? ":
I believe that you may be citing this out of the context. I was asking about the PC hardware that would support the OpenWrt emulation program that was recommended by another colleague.
By the way, this is a good example of why I have developed my style and format of writing non-real-time messages, especially forums like this that multiple threads are going on, not only in parallel, but often out of time sequence.
Correct, so am I. So we're still on the same page.
Yes, so I'm following the conversation in context of all 34 posts this far. So since your concept requires use of these 240/4 address, your hardware will need to be more robust.
Otherwise, as I noted, your current testing can be done with a MacOS PC configured to your specifications. Nothing fruther is required.
My traceroute [v0.92]
user-dsktp (192.168.xxx.xxx) 2018-10-06T09:40:47-0400
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. OpenWrt.lan 0.0% 22 0.4 0.4 0.3 0.5 0.0
2. xxx-xx.xxx-VFTTP-xxxx.xxxx 0.0% 22 0.7 2.2 0.6 17.1 4.0
3. ???
So also OpenWrt works here with an Ubuntu Lunix machine.
Since our Colleague Abe may be following contrived parallel conversations here, this may confuse him...but I'm not sure what this thread is regarding now. Routing and forwarding of this 240.0.0.0/4 works already in OpenWrt.
Great! Let's work together to either prove or disprove the idea.
To expedite the progress, allow me to recommend a couple general guidelines:
A. Let's contribute what each of us know and capable of when requested. (I follow an almost contradicting philosophy. That is, I know that I know enough of certain topics, so that I am not shy about admitting that I do not know some topics.)
B. Respect the other's approach / opinion. Raise comments only for the purpose of understanding it, not to critique. (In the process of clarifying, the other party learns how to convey his idea better in future presentations.)
Appreciate your preceding interesting comments that do have certain amount of truth in it. Let's put them in the background for now, except I should address "untold wealth ":
It is too early to dream about this possibility. On the other hand, I have taken appropriate steps to be sure that it will not be totally thrown away. I can only promise that when reward does shows up at the door, each and every contributor will get respective fair share from it.
While I will be continuing my study of OpenWrt documentation and learn from the manufacturers, there were two initial questions cut short by the SysAdmin because the discussions went off track. I would like to ask again for possible confirmation which will expedite my learning curve.
A. There were lists in two Topics (see below) on this Forum that mentioned the 240/4 netblock. Each also included the common private 10/8, 172.16/12, 192.168/16 plus others. My question is, does this mean the 240/4 is inherently included in the OpenWrt routable table, or can easily be set up under OpenWrt? And, where can either be confirmed in the OpenWrt documents?
B. There were a couple initial tests conducted by colleagues (see below) with apparently contradicting results that the specifics were completely out of my league. I was hoping to see some definitive result with finite steps that could guide me to replicate.
Incorrect. I ran the following command prior to testing:
ipset del bogons 240.0.0.0/4
(this command has no bearing on success of the trace , nor OpenWrt's ability to route.)
This has no bearing on if it's routable, this was covered here, asked and answered, as I am the author of the statement you're referencing - WHICH YOU KNOW!::
Why would the OpenWrt documents discuss a restricted address space!?!?
Why would an unused IP of any block be in any OpenWrt route table (or any router for that matter)?
Thanks for doing the experiments. Let me digest the result from an amateur's perspective.
"my PC (Archlinux) and OpenWrt Router/Modem (DGN3500) play nice,":
It is great that the 240.0.0.0 works on your own network. This is what I was hoping for as the baseline of what OpenWrt will do.
" the ISP drops the ball.":
This is expected, because the 240.0.0.0 in your packet is in plain view of the ISP. As described in the EzIP Draft, any packet leaving your private network needs to carry the 240/4 related information by the Option Word so that it will appear to the ISP equipment as innocent payload on the IP Header. The experiment that you try against the ISP must use packets constructed with the full EzIP Header (See Figure 4.).
The basic idea of Option Word mechanism utilizes the "payload" concept.
This is a very powerful concept in communications technology, because it is kind like carrying goods in the driver cabin of a tractor trailer, not the normal big trailer. (kind of smuggling :smiley: )
It is expected that all Internet routers (Edge and Core) to be "blind" on Option Words for the mechanism to work. Through the reports from EnIP (Enhanced IPv4 -- https://www.enhancedip.org/ ) work, I believe that at least many of such routers these days are "transparent" in this respect.
However, there apparently are some routers that do "Log and Drop" to packets with Option Word in an attempt to be "smart" in dealing with cyber attacks. Unfortunately, such approach is deviating form the fundamental definition and requirement (What goes in at one end is what comes out from the other end.) of a transmission system (vs. terminal devices such as IoTs) that ERs and CRs belong to, causing complications. Based on my discussions with colleagues knowledgeable about this aspect, they do agree with me that such "picky" behavior is an unnecessary overkill. It should be stopped for the long term.
A common Windows OS based PC is a terminal device, unless it is specifically configured as a router. As such, it is categorized in EzIP proposal as EzIP-unaware IoT. It will be left alone as it is in the overall EzIP scheme. I would not be at all concerned with a Windows PC not supporting 240/4 activities.
When you brought up the OpenWrt software for PC, my understanding was to install it on a PC to experiment it as an OpenWrt environment. If that interpretation was correct, then we should see similar behavior of the successful results on your own network earlier.
Let's not re-hash on the details of the events on the earlier discussion threads. I already stated that I was struggling to understand what they meant. Please update with what you find is more helpful for advancing to the goal.
" **Why would the OpenWrt documents discuss a restricted address space!?!? **" :
Somewhere along the line, I saw statements on OpenWrt about treating netblocks that are not part of the routable public netblocks. This is why I found that the lists in those two Topics interesting, because they seem to cover such. But, the languages were too technical for me to understand. So, I am requesting expert interpretation of those discussions.
To be clear. The command ipset is a part of the Netfilter suite of software. From a simple web search, you should realize as a VP of Engineering - that's simply a firewall. Since that's firewall software, you noted above that's not a concern to you - as other colleagues (unknown to those in this thread) have told you it's unnecessary. So, in order to stay on topic, please refrain from mentioning the ipset thread where I refer to the 240/4 block, thanks.
Again. incorrect. As I noted, that's simply firewall software, you already noted this is of no concern to you:
So Colleague, what exactly are you concerns at this time?
I think we're all following the thread now.
I Should note, if you remove Netfilter, you can't masquerade, as required in you RFC draft.
If this is the case, your packet is leaving an SPR for the global Internet. According to your RFC draft, this additionally means that it's leaving the EzIP space.
Why would a packet be altered at this time/place in your model, even internally? (I asked you this previously, this is how we discovered you break the end-to-end principle by needing masquerade)?
I really don't understand how ISPs and/or Autonomous Systems work in their present model - using your RFC Draft
Your RFC draft must be edited to also override BCP38 and many RFCs (including ones you cite/reference)
If this information is carried to another Region, then the 240/4 space is being reused, and you have not created an IPv4 exhaustion technology (or, as I noted above, your technology must replace the current Internet in-whole)
I'm not really clear still on what you need to test:
To be clear on this, colleagues have tested this for you already in a thread you quoted above. You simply need to setup the router and attempt the same steps to add an interface and route to it. Have you tested it yet?
This requires the ip route command; but this command also seems unfamiliar to you:
The poster at https://forum.openwrt.org/t/nat-leakage-on-tl-wr1043nd-v4/1712/27 made a blackhole route for this range, according to BCP38 and RFC1112. You simply make a valid route going to the Interface of the network you assign 240.0.0.0/4, instead (as your colleagues tested in the threads you quoted above). That simple.
I appreciate your enthusiasm by trying various things right away. However, the unplanned rapid firing can only produce disappointments, because there are hardly any target right now for you to shot at. Please pause and take a deep breath then digest the following short sentences. I will be using "three" as a figurative expression for many, not necessarily meaning anything exact.
The issue that we are dealing with has been around for at least 3 decades.
There probably have been 3 thousand engineers, planners, etc. who have looked at this challenge and dreamed for solutions.
If on the average, each of the above has spent 300 hours (about 8 weeks) on this topic, there would have been 900 thousand or nearly one million man-hours spent on dealing with this problem. This gives us some idea how involved / difficult this topic is.
It took 3 Avinta staff spending 3 years to peel off layers of the smoke screens over this IPv4 Address pool shortage "myth" to come up with an unorthodox solution, called EzIP.
This solution is actually a mathematical analysis based on set theory, although it is dealing with a technical problem. It is deceivingly simple, because no new technology is involved. So, reactions to EzIP covers the full spectrum, from obvious for some, to totally crazy for others.
Now, how could we expect that it is possible for 3 of us to prove or disprove the scheme by spending three days to do 3 experiments in an environment that is mostly (actually, almost all) not EzIP ready?
I can see your frustration by just reading the eMails. But, trust me, patience is the virtue of dealing with challenging tasks like this. It helps to detect the missing links or things hidden in the cracks, etc. in the analysis phase. For the initial feasibility tests now, it is the ability to spot the encouraging sign that may advance the project. From such, we have a base to move to the next plateau. If you keep on looking for the promised final performance, I can guarantee you that you will call quits right away.
One important hidden discipline behind these is called "Divide and Conquer". Although this was originally said by Julius Caesar about military maneuver strategy carrying certain bad intonation, it is one of the golden rules in system engineering. That is, divide a system to the smallest units possible, so that each may be within our ability to handle properly.
Let's apply the above to the recent test result by mbo2o that I copied to below:
" Looks like my PC (Archlinux) and OpenWrt Router/Modem (DGN3500) play nice, but the ISP drops the ball.
192.168.1.1 is my router , 10.xx.xx.xx. is the ISP equipment
Are you sure this going to work Abe without any coordination or cooperation with your ISP.
$ traceroute 240.0.0.0
traceroute to 240.0.0.0 (240.0.0.0), 30 hops max, 60 byte packets
1 _gateway (192.168.1.1) 1.544 ms 3.237 ms 3.231 ms
2 10.xx.xx.xx (10.xx.xx.xx) 16.032 ms 16.039 ms 19.854 ms
3 * * *
``` "
**********************************************
I read the above as that a target address 240.0.0.0 was sent by the PC, properly handled by the gateway and the modem, but not beyond. As I commented then, this was perfect as I hoped that the OpenWrt environment would do. This is the first solid marker for going forward.
9) However, we can not jump to do similar tests in other combination of environments that EzIP packet may go, because I have not identified what could be the next "friendly" environment. If you try any of them, I am not surprised that you got failure responses.
10) The only next test that you may want to try is what I recommended right after the above result. That is, try creating a packet with EzIP header like what is shown in Figure 4, then send it from the PC in the above setup to the Internet (or equivalent simulation). This essentially mimics an EzIP-capable IoT initiating a session request. Because the Option Word should be ignored by routers, this packet should arrive at the destination end. If this is successful, we will have the confidence that the EzIP scheme is likely viable. Please do describe to me how will you do this before actually trying it, so that we can minimize the chance for the disappointment.
11) In the meantime, I will continue studying the OpenWrt document and pressing TP-Link TechSupport to describe to me how close is their factory software to the OpenWrt version.
Thanks,