Network 44 was conceived back in the days of network classes, e.g. A, B, C, ... with a fairly strict notion of network vs host addressing space. We thought of Network 44 as a Class "A" network, which contained 256 Class "B" networks, which could each could support 256 Class "C" networks, and so forth.

Also in that time we were using DOS and some early Linux systems to provide all of the network resources for routing, services, etc. -- homegrown programs were created to manage the peculiarities of the time and to provide a "bridge" between traditional AX.25 packet and the Internet enabled abilities that Network 44 allowed. This meant mostly messaging/email, NNTP, and bulletin boards that were now IP connected. The network was also sparse so route management was included as well as tunneling via IPIP. Transports were generally very slow, so minimizing "hops" was of high priority.

16 million addresses are too many for one person to manage and it was decided that we needed regional coordinators to manage the "Class B" networks (actually 1/2 Class B) and Brian undertook allocating a series of these "Class B" networks and finding coordinators who understood local needs and would manage the assignment of individual addresses to individual users. The email robot was created to create, read, update, and delete those addresses and the coordinators manage that process. Many coordinators also tried to bring some network management and order to the address space they manage, often creating LANs, etc.

The larger Internet has moved on to Classless Inter-Domain Routing (CIDR) so the whole idea of "subnets" takes on a different meaning and is much more flexible and adaptable. Wouldn't it make more sense to have regional coordinators using these newer tools to take their regional networks and organize them as makes sense for their area? For some things, like a single radio link maybe a PointToPoint mapping makes sense with a CIDR of /31 or /32, for a full duplex repeater maybe a LAN with a CIDR of /28 with some addresses DHCP and others fixed? Or an EOC might have a LAN with a CIDR of /29? Having a coordinator/network manager doing this sort of planning is adding a much higher value.

Off the shelf hardware for routing and infrastructure between subnets has become pervasive and cheap, including some high power routers that can be purchased and run for what may be less money than is used to keep that old recycled PC powered for a year. For about US$40 one can purchase a physically small, 5 port 10/100 Ethernet router, and for about US$80 can purchase a 10/100/1000 Ethernet router with a 1W MIMO 2.4 Wifi capability - each with multiple tunnel capability, sophisticated firewalls, and address management protocols. Microwave Point-to-Point links going 10s of KM can be had for less than $200 (both ends with antennas). Does it really make sense to not use this commercial, off the shelf, modern, and inexpensive equipment for infrastructure?

The only "stations" in Network 44 that benefit from fixed IP addresses are those which are used to provide services (e.g. Websites, Mailserver, NNTP host, Chat Server, VOIP conferencing, etc.) and control/managment/infrastructure. The average user just needs an IP address, and possibly a DNS PTR record for management / identification of users. Mobile stations should definitely be using DHCP as they move from access point to access point, especially when they are mostly clients to services. Modern systems can easily use DNS delegation combined with DHCP and Dynamic DNS to keep up to date DNS A and PTR records.

Fixed assets that are tied directly to Internet / Ethernet -- these can be supported by a "tunneled" CIDR subnet, using one of the inexpensive routers mentioned above. (I use a pair of them to bring my personal Class C network from a datacenter to my home through an L2TP tunnel. I have Fiber Optic to the house and get virtually the same symmetrical bandwidth over the tunnel as I do through my ISP. One end, my house, has a Dynamic IP4 address and the tunnel keeps my fixed addresses on the Class C up.) These could peer to one (or more) regional routers.

IP over AX.25 -- this is still a beast, as IP must be encapsulated in an AX.25 frame. Often these run on simplex frequencies using UNPROTO packets, which works to create a small LAN if all stations can hear each other. One station (or more) could receive a properly sized CIDR subnet and both fixed and DHCP addresses could be allocated. This "gateway" to the LAN might run current IP over AX.25 software and "tunnel" to one (or more) regional routers. (Right now mostly 1200/9600 bps in US, some higher in Europe, some projects to give more speed options underway.)

Part 95 (or 15) WiFi -- HSMM, Emcomm deployment, etc. Fits nicely with drop in an inexpensive off the shelf router with Mesh or upstream / downstream microwave links. Inexpensive Point-To-Point and Multipoint/Mesh off the shelf devices give higher bandwidth over varying distances.

IP over D-STAR -- D-STAR has a "Digital Data" mode that encapsulates Ethernet Frames in D-STAR Frames. Off the shelf radios for 23cm provide a 128K bit rate. Current implementation of gateways, use D-STAR addresses (callsigns) for "Point-to-Point" radio links and look like an Ethernet connection at the endpoints. There are some projects underway that can make this more flexible (e.g. repeaters for on air LANs and bridges between access points for larger "VPNs"), but in general this is just another way to distribute "Network 44 LANs" over radio where an off the shelf router could be plugged in to tie local LANs back into Network 44. (There is also a very slow, e.g. less than 1200 bps, data stream in the D-STAR voice protocol that has carried TCP/IP as well - see D-RATS.)

All of this means we can and should be working toward a unified amateur radio Internet Protocol network, it can live inside Network 44 with stations initiating connections out to the rest of the Internet and with heavy filtering of traffic coming back into the network (like we have now, except it could limit inbound traffic only to specific services that are designated). We can also solve some problems for services that like having known IP addresses and ports, that NAT just doesn't satisfy, like some of the VOIP protocols.

I think if we take this approach and standardize infrastructure on inexpensive "off the shelf" router devices (I like the MikroTik routerboards -- bang for the buck, and we might even be able to build an AX.25 module for them), I can see how we can offer standard configurations and a tool for coordinators to add specifics for LANs, that LAN operators could "load and go!"