Default Network Address

For Developers
21

To all following this, Seasons' Greetings. :star:

For those truly interested in the educational value of this discussion:

  • This means that 240.0.0.0/4 is [mathematically] incomplete, and therefore not a [complete] subnet. It also means that no device has an RFC-known method of sending broadcast packets (in the normal manner) to its network.
  • I'm sure you all know...he must think of something creative way - to do broadcast on this network...or...not use the addressing mode "Broadcast."

:bulb:

EDIT: The addressing mode broadcast is used for the DHCP he wishes to have OpenWrt change. :wink:

2 Likes
22

Hi, lleachii:

  1. "This makes sense! ": I hope this establishes a common reference line for follow-up discussions.

  2. " But, the development team at Avinta Communications, Inc. needs to expand the capabilities, not OpenWrt!":

It depends. For example, I can see two basic approaches:

A. The "Kosher" approach from my system engineering training is to expand the list of netblocks usable by OpenWrt's DHCP to include 240/4, thus expanding the capability of the OpenWrt.

B. The business perspective would be to customize and restrict the DHCP netblocks to only 240/4, thus forming a restrictive and specific derivative of the OpenWrt that is only usable by the SPR proposed by Avinta.

Approach A. will be simple, because everything stays within OpenWrt. Approach B., on the other hand, will involve some kind of legal agreement to establish the separation.

Happy Holidays!

Abe (2018-12-22 23:41)

23

Hi, biangbiangmian:

  1. No, we are not offering a paid job at this moment. The part of the activities disclosed on this forum is only part of our overall R&D efforts to resolve IPv4 address shortage induced issues. We are still in the facts-finding mode of whether OpenWrt is the approach for implementing the EzIP scheme proposed in the IETF Draft.

  2. We do invite whoever concurs with our direction and inclines to participate. As I stated sometime ago on a separate thread, current team members are all on "volunteer" basis, while many regard us as crazy. When there is some sign of commercialization movement, reward / compensation will be discussed based on past and potential contributions at that juncture.

Happy Holidays!

Abe (2018-12-22 23:59)

24

Incorrect. Neither approach A nor B - requires any involvement of OpenWrt. As I've explained:

But you do have an issue:

  • You again failed to offer any feedback that you comprehend the problem (that you have problems in code, wrong addressing modes in Class E, no complete subnet, etc.)
  • You failed to address my information in post 17 - that you need to inquire with the makers of dnsmasq regarding the problem you specifically addressed regarding DHCP.
  • You seem to still pretend that OpenWrt must do something for you
  • You seem to be under the impression that anyone wishes to assist with your "Approach A" endeavor. Approach A instantly makes OpenWrt unusable for all other people on planet Earth, except you!
  • I've noted programming this into a device is likely illegal in some nations
  • Approach B is a delusion. You have no obligation or requirement to implement a: "business perceptive... to customize and restrict the DHCP netblocks to only 240/4, thus forming a restrictive and specific derivative of the OpenWrt that is only usable by the SPR proposed by Avinta." If fact, it's unethical, and likely illegal given OpenWrt is free and open-source software
  • I assure you, Approach B will get someone paid (not you)
  • Approach B offers no proof-of-concept to the world
  • Be advised, I'm sure some in this community plan to request the GPL modifications you [may] make to dnsmasq :wink:
  • This lack of offering a proof-of-concept is contrary to the concept of filing a Draft RFC
  • Therefore, you're making a "black-box" product
  • Per your response to @biangbiangmian, it seems to confirm you want free advice
  • I think the reason you believe people take you as crazy - stems from activities in these threads (e.g. such as pretending to ignore sound advice; but it magically appearing in your technical documentation, and stating you must sign your posts because of some method of communication you use, etc.)
  • Future conversations should involve compensation for the colleagues that have been assisting you.
  • You have already given signs of "commercialization movement" ...or a military purpose
3 Likes
25

@OugCPC

as for use of the 240/x netblock, I think the netblock described in:

https://tools.ietf.org/html/rfc6598

is far more appropo' for your application. I would strongly advise you do that rather than squatting on 240/4, as no patches to anything are required... or just use rfc1918. If you must squat, there's vast amounts of the US military and Halliburton space not publicly advertised worth making a political statement on, which will "just work" util that far off day when they return it to the global pool.

/24s are going for about 4k on the open market if you need truly public ip space.

As it happens, I've been engaged with john gilmore and others since august in exploring the hardware and software (and political) ramifications as to what it would take to make 240/4 generally usable. Test failures of note include many cisco routers and all of windows, can't take it. Windows apps need a recompile in one major case. Successes included ios, osx, android, and most modern linuxes.

We've developed an ever increasing (in)compatibility list (which we hope to publish when it stops getting longer) and have landed patches in the linux kernel, openwrt, several routing daemons, and openwrt to make it one day more feasible to deploy these and hope to take a proposal for public, global, experimental use of the experimental space up to the appropriate IRTF, IANA, and IETF groups, after we test interop with a lot more hardware.

Unlike early proposals (in the 2008 era), now that the de-facto standard for class-e is unicast (RFC1112 was written in an era when we thought routed multicast would work out), we hope to make these 268m new addresses more generally useful to everyone than rfc1918 or rfc6598 in the long run, but first up was feasibility, and then taking the tasks to the appropriate authorities, and for all we know that might not fly. I'm painfully aware of how one crash bug stalled internet deployment of ECN for over a decade.

If anyone here would like to know more about a saner plan to open up class-e, help out on the pending rfcs, or get in on the upcoming tests, please contact me offlist. I don't read web forums often.

26

Hi, dtaht:

  1. Appreciate very much of your comments. I believe that we share quite a bit common paths and understandings

  2. "RFC6598, RFC1918, squat ... US military and Halliburton space .. RFC1112... ": We went through studying these and concluded that most of them are pretty involved, and each has its limitations not mention the complications. Upon figuring out the RAN (Regional Area Network) configuration (See IETF Draft referenced at 10/25 of this thread.), we created, between the Internet public and private spaces, a new layer of space that starts as a private space but can cover a very significant region. This alters the current Internet architecture and opens up a lot of possibilities. I can state that the quoted sentence from an APNIC blog cited just above our IETF Draft is not incidental.

  3. With the help from OpenWrt colleagues, we have gotten to a point that it appears only finite work is required to demonstrate the feasibility of operating a RAN using 240/4 netblock, with minimal interaction with the current Internet.

  4. "please contact me offlist. ... ": From your writing, I can sense that your team has experienced as much as, if not more, hurdles of all sorts that we have come across. These are not suitable to take up the time and space on this forum for sharing. I will send you a separate note through the "Message" facility to carry on the details. Since I am the lead author of the IETF Draft that I mentioned in Pt. 1), you can get hold of me through the contact information there, more directly. I practice a discipline of responding none-real time communication within 24 hours. So, if you do not hear from me on something that you expect my response, by all means try to alert me, through repeating the message or an alternative channel.

Happy Holidays,

Abe (2108-12-23 22:15)

27

I have briefly scanned your internet draft. Is there an ietf mailing list on which it has been discussed?

It's the holiday, and I don't intend to be online for several days. I will re-read again when I have more time.

My first take on it was:

For a new application such as this, an IPv6 or an IPv4 tunnel would be just as effective, and require less work to deploy.

Any existing ipv4 range could be used for this application. And essentially, already is.

Scribbling on existing tcp option headers is generally a no-no, and leveraging an existing protocol like quic has better connectivity and security properties.

But I'll read harder later.

1 Like
28

Hi, dtaht:

  1. " Is there an ietf mailing list on which it has been discussed?": No, the initial submission of the Draft was in the midst of IPv4 "Sun Setting" process. We were told that it was not aligned with any of the activities. We decided to keep the revision process going anyway for continuity purposes. After submitted the -03 version in June of this year, I discovered that there was a person designated to keep an eye on any IPv4 ideas, just in case. So, I submitted a copy through that channel.

I look forward to your comments.

Abe (2018-12-23 23:33)

29

LOL -- nothing new about this, he's / they've been pushing it as the Phoenix that will rise from the ashes for years -- at least since 2008. Oh, forgive me, there's a 2001 press release on this.

That draft keeps expiring and he/they keep adding and removing names and a sentence or paragraph or two. Note that it's never made it to an RFC.

So far it's expired on

  • June 2017
  • Dec 2017
  • June 2018
  • Dec 2018

After nearly two decades, there's nothing new here.

3 Likes
30

Is this a good time to ask for payment/compensation?

2 Likes
31

Hi, dtaht:

  1. I reread your initial comment again more carefully. I see synergy between our two teams.

  2. "Test failures of note include many cisco routers and all of windows, can't take it. Windows apps need a recompile in one major case. Successes included ios, osx, android, and most modern linuxes. ": It appears to me that this sentence may sum up the correlation between your and our efforts very well. That is, our system architectural proposal is in-line with / taking advantage of your experimental results.

  3. Starting from one single IPv4 public address, we may use Linux based routers to establish a RAN utilizing the 240/4 netblock for covering a significant geographical region (with population up to 39M), as long as these routers avoid intertwining with the transmission facility of the existing Internet (public as well as private). At each customer premises, a Linux based RG (Routing / Residential Gateway) can operate on existing RFC1918 netblocks to support current IoTs, thus without requiring them modified. Only those IoTs wishing to be directly addressable from the Internet will need be programmed to handle the 240/4 netblock.

  4. The above simplistic-minded configuration will avoid the limitation of the current Cisco based routers because the new traffic does not go through them, while most of Windows based IoTs can continue the current operations.

Regards,

Abe (2018-12-24 16:18)

32

keep it up! :sweat_smile:
maybe we live in the "stupidest of timelines" but i'm all for standardizing another layer of indirection :rofl:

3 Likes
33

Dear Colleagues:

  1. I am pleased to update you with the latest discovery of the OpenWrt capability. It validates my speculation from earlier observations that the OpenWrt might be routing 240/4 addressed packets all the time, even when its Default Network Address is set to use the 240/4 netblock that renders the router appearing to be not operational.

  2. The diagram below depicts the current EzIP test bed. It is slightly modified from the previously shared version. The main differences are,

A. The conversion of the Asus EeePC from Win10 to Xubuntu OS and,

B. The insertion of the Ethernet cable Tap, DualComm DCSW-1005PT.

The latter was added originally for the purpose of monitoring for possible probing signals during the quiescent state of the LAN port on the OpenWrt router when its gateway address is set to 240/4. It unexpectedly assisted in identifying a subtle behavior of the NBs, As a consequence, the incident experiment and its results became possible.

https://www.dropbox.com/s/5bvkypj81vb9fa3/EzIP_TestBedA.pdf?dl=0

  1. The following is a screenshot of the WireShark report showing two Xubuntu NBs successfully PINGing each other simultaneously, but using two different sets of netblock addresses. Since the HP Pavilion NB is monitoring the traffic between the other two NBs through the DualComm Ethernet Tap, this screenshot is the same on all three NBs. In addition, this screenshot is the same when the OpenWrt router is set to use either 192.168/16 or 240/4 netblock.

https://www.dropbox.com/s/a8snil97szaayc7/DualPINGing201812270941.pcapng?dl=0

  1. The above almost conclusively demonstrates that the OpenWrt router is routing 240/4 netblock packets all the time "unintentionally", even though it is currently not assigning such through its DHCP server. Perhaps some kind of short patch in the kernel could open up this netblock for the DHCP server to use?

Happy New Year!

Abe (2018-12-28 10:36)

34

:laughing:

You're wasting time. These discoveries aren't new. You're only stealing credit for your so-called work - from those in the OpenWrt community. You were told this by @dlakelan over two months ago:

You have been told this over 5 times already.

  • Why do you keep pretending that "your OpenWrt colleagues" aren't telling you!?!?
  • Why isn't your development team at Avinta Communications, Inc. wokring on this!?!?
  • When do we get paid, since you're wasting our time!?!?
  • Avinta Communications, Inc. could have done this YEARS ago!!!
3 Likes
35

Perhaps you could write the patch and test it. Stop trolling this forum.

3 Likes
36

@OugCPC

I've objected on multiple occasions to your use of this forum for what appears to me to be little more than boosting the commercial viability of your supposed firm and its commercial venture. Use of these forums to SEO your commercial venture is against the terms of use for these forums.

Ignoring the technical merits of your approach, you appear to me to be a fraud on multiple fronts, including, but not limited to the shell company that is nothing more than an address at a UPS location and the inconsistencies between your claim on LinkedIn to hold a Master's degree in EE from MIT, the lack of level of understanding, insight, and ability to acquire information that you have repeatedly demonstrated here, contrasting to my personal knowledge of what getting that degree teaches and entails.

I would ask that for your posts:

  • You remove all links to off-site content from your posts
  • You remove all references to the names under which you or others have been trying to market this idea
  • You remove all references to the name of the companies under which you or others have been trying to market this idea
3 Likes
37

Hi, dtaht:

  1. "I've been engaged with john gilmore ... to make 240/4 generally usable. ... We've .... landed patches in the linux kernel, openwrt, ..... to make it one day more feasible to deploy .... these 268m new addresses more generally useful to everyone than rfc1918 or rfc6598 in the long run.... ": Connecting the dots, I located a piece of code, originated by Vince Fuller in 2001, that you recently updated and posted on GitHub:

https://github.com/openwrt/openwrt/blob/master/target/linux/generic/backport-4.19/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch

It looks like a patch intended to make the OpenWrt capable of using the 240/4 netblock in a general sense. Am I correct in my interpretation? Please comment.

  1. If the above is affirmative, the EzIP project would have the necessary ingredients to proceed with demonstrating its realizability.

Thanks,

Abe (2019-01-08 18:04)

38

Wow,

After months of mucking about with this, you find a patch and instead of just testing it you want confirmation from openwrt.

6 Likes
39

Here we go again, something based on a Draft RFC...

Expires: September 25, 2008

  • Also, does Cisco have any claim to this patch!?!?!
3 Likes
40

a couple notes -

  1. my "class-e" effort has zip, zero, nothing to do with @OugCPC. Goal is to sanely enable "e" addresses universally, not support any particular business model. Been at it for ~5 months, expect the effort to take 5-7 years , cause much debate in the ietf, and I expect the end result to be a better internet in some regard.

  2. I'd meant to go into detail on all that is wrong in @OugCPC's internet draft but that runs to pages and pages. The biggest problem is - like many - most - maybe all - drafts in this space - is that they are at "step 18"... "Profit!". I think the @OugCPC draft has not the slightest hope of clearing the ietf process as written. Just the TCP modification alone is a show stopper. Many other forms of IoT enablement exist...

... where my little group is focused on step 1 and 2 - make 'em work, turn the defacto standard of 240/4 = unicast into a internet standard... then figure out what to do with them.

We landed about half those patches last month. OpenWrt still needs one for the bcp38 package, but it (and linux 4.20) are now fully capable of routing and assigning class-e. Babeld took the patch, bird and FRR are dithering. The patch to FRR led to some reasonable roadblocks:

which I hope to address as soon as I get that testbed up. Or perhaps someone else will leap on it.

ANYWAY:

Given the hostile interactions here between various folk, which I innocently seem to have stepped in... I do not intend to participate further on this thread.

Instead of writing an epic reply here, last week I focused on fixing the top 5 IOT stacks. RIOT for example was fine, lwip might need a patch, Zephyr needs a patch. lwip might need a huge amount of backports, might not, will know next week. After those are done, next up are bootloaders, and after that network configuration tools, after that a few firewall products... all while writing down what we did to find and fix each problem. It's a really big internet with millions of devices in the supply chain that have to - at least not crash spectacularly.

Simultaneously we're assembling a testbed of needed BGP gear from a half dozen makers.

If more people had just focused on making class-e just work, 10 years ago, or I had known how easy this was during the cerowrt project - we'd be done by now.

Lastly:

I note that no matter how crazy some idea might appear, the ietf processes allow submissions from anybody. Good ideas sometimes actually emerge. If anyone would like to write a ID on this topic (or any other!), and submit to the ietf, I'm always glad to help - and we could use some help on the three (saner! I hope!) ones we have pending, actually.

and that's all I'm going say here. Happy hacking.

3 Likes