What is the Relationship Among Different Versions of Softwares?

[OugCPC]

Hi, mbo2o:

You are really getting me lost. What question are you talking about? Something earlier, not in the last couple messages?
Thanks,

[lleachii]

@OugCPC

the unplanned rapid firing can only produce disappointments, because there are hardly any target right now for you to shot at.

You had 12 hours. I wouldn't call that "rapid firing." I find it odd that you're using that phrase.

@OugCPC

The issue that we are dealing with has been around for at least 3 decades.

Longer.

@OugCPC

There probably have been 3 thousand engineers, planners, etc. who have looked at this challenge and dreamed for solutions.

More worked on CG-NAT and IPv6; and as you recall IPv6 is currently working in today's Internet paradigm, with no new technology needed.

@OugCPC

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.

Totally lost what you mean here, I'll cover this next.

@OugCPC

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.

They didn't do a good job. Neither have you - if, in 3 years, you still haven't found a router that will route the IP range. It took 5 unpaid colleagues to discover this for you - in this community!

@OugCPC

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.

A new technology is involved (hence, why an off-the-shelf rotuer hasn't worked for you in 3 years); and again, this appears to be advertising. Can you provide this set theory mathematical formula, please?

@OugCPC

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?

THAT'S EASY: now that we know the router works with the block, provide the formula and perhaps someone would assist with the SPR. You haven't described anything complex to me. Perhaps the Avinta staff should be fired - for wasting 3 years of your life; and their incompetence (I venture to say, possible fraud).

EDIT: If you're paying them, I'd re-think your investment!!!

@OugCPC

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.

You're delaying and stalling...perhaps since the 2 threads you quoted are unrelated to your "goal"?

@OugCPC

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.

I think we all understand, now. I'm personally capable of understanding the full scope of this project - without a "divide and conquer" approach; especially if I'm providing assistance - for no pay. Please don't use such an approach when addressing me.

@OugCPC

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.

In this and previous threads, you identified the EzIP space a a new cyber "domain" or something similar. It's extremely concerning that you have to find another space to make your new technology work. I fear this other space will be the Public Internet.

@OugCPC

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.

This should work - this is the concept of IP! I don't understand the need for this test.

@OugCPC

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.

I thought we covered the word "proprietary" above. Also, you have not once provided a correct link to the documentation: https://openwrt.org/docs/start

You've been referring to the Community Forum as documentation, previously.

---

• Lastly, you never addressed a major question of mine:

@lleachii

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 surmise, because of this:

@lleachii

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)

[lleachii]

@OugCPC

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.

Dear Colleague:

By the way, you asked me to ping you if you had missed anything. You will need to provide the Virtual Machine test results before expecting anyone to proceed further.

@OugCPC

3 of us to prove or disprove the scheme by spending three days to do 3 experiments

You identified 3 persons as having conducted the test. That appears to be false. Only @mbo2o and I performed that test (in this thread).

You were to:

• Setup OpenWrt in VMs
• Setup a network with 240.xxx.xxx.xxx/xx
• Setup routing accordingly
• Attempt connectivity.

Please provide those results before asking other colleagues to proceed.

As you stated before about something else, truly providing your work and results:

@OugCPC

it is one of the golden rules in system engineering

[OugCPC]

Dear Colleagues:

0. It is apparent that we are getting off the track again, probably due to the anxiety for quick progress. Before the moderator again closes this thread, allow me to address a couple fundamental misunderstandings.

1. The 3 years that 3 Avinta colleagues spent on this project was not doing any experiment. We were analyzing the intertwined aspects around the issue, peeling away the smoke screens. If we had tried to test anything prematurely, we would have given up a long time ago. Now that we have a proposal that looks stupidly simple, it is why you can do quick tests and get at least one positive result.

2. The 3 of us doing 3 experiments refers to my description of what need be done to verify that OpenWrt supports 240/4 netblock, mbo2o did a test with positive result, followed by both of you reporting negative results, but I cherry-picked the first one as the foundation ("there exists one example") for moving forward. This is called team work. Extremely positive if you do not get anxious and begin to take what follows negatively.

3. I have been reading the OpenWrt documentation. This is why I ask for your knowledge to locate any material in it that may relate to the 240/4 netblock. What is on this forum about this topic is what I already referenced to when I started the original Topic.

Again, thank you very much for your help. This is sincerely from my heart. I will concentrate on moving forward and report my progress when I arrive at any.

Regards,

Abe (2018-10-07 08:26)

[lleachii]

@OugCPC

It is apparent that we are getting off the track again, probably due to the anxiety for quick progress. Before the moderator again closes this thread, allow me to address a couple fundamental misunderstandings.

Dear Colleague:

Please just provide test results. I understand everything you proceeded to list; and I find nothing to be off-track. Please stop stalling and delaying.

@OugCPC

The 3 years that 3 Avinta colleagues spent on this project was not doing any experiment. We were analyzing the intertwined aspects around the issue, peeling away the smoke screens. If we had tried to test anything prematurely, we would have given up a long time ago. Now that we have a proposal that looks stupidly simple, it is why you can do quick tests and get at least one positive result.

I did not have a misunderstanding here. I do not see smoke screens, vis a vis IPv4 exhaustion "myth." In fact myths like this:

@OugCPC

For a region as big as Tokyo Metro that each block of 240/4 can serve, there should be no double about whether web-servers like Google, Amazon, etc. will set up their own caching gateway there to reduce the traffic to their main data banks.

Anycast currently performs such tasks, and can do so on IPv4 and IPv6, exhausting only 1 IP per IP_version and "region" under your terminology. Problem solved!

• I also fear your SPR "in-band signaling" requires some Layer 7 interaction.
• Assigning an Anycast address to a device and routing to its subnet already works in OpenWrt, have you tried this?

@OugCPC

The 3 of us doing 3 experiments refers to my description of what need be done to verify that OpenWrt supports 240/4 netblock, mbo2o did a test with positive result, followed by both of you reporting negative results, but I cherry-picked the first one as the foundation ("there exists one example") for moving forward. This is called team work. Extremely positive if you do not get anxious and begin to take what follows negatively.

Incorrect. I had identical results to @mbo2o. You might be referring to another thread; but again, I wouldn't identify those results as "negative" in either case. This is simply false. You have an issue with falsities, especially in RFC Drafts.

@OugCPC

I have been reading the OpenWrt documentation. This is why I ask for your knowledge to locate any material in it that may relate to the 240/4 netblock. What is on this forum about this topic is what I already referenced to when I started the original Topic.

This has been covered. RFC1112 does not allot use of this netblock. You seem to have an issue understanding that. Therefore, you will not find any responsible software developer with any meaningful documentation regarding it. You will likely have to read the code yourself. ALL of it is available for your consumption:

OpenWrt

@OugCPC

Again, thank you very much for your help. This is sincerely from my heart. I will concentrate on moving forward and report my progress when I arrive at any.

I find this statement to be false and disingenuous; but nonetheless, I wish you well.