A Proposal for Amateur Radio IP Addressing Conventions for the Wisconsin and Upper Michigan Network (Version One/IPAP-1) 

Foreward - Internet IP address assignment has certain conventions to allow uniformity and intuitive setup of routers by those who may not be familiar with a neighboring network, but need to gain access to it. There are other subtle conventions that allow relatively easy interoperability. For this reason, it is proposed that Internet address assignment for the Wisconsin and Upper Michigan Amateur Packet Radio Network (amprnet) be standardized.

It is important for the amprnet to have a standardized address assignment method, as we have a cooperative network that has more administrative interaction than may be custom on the internet. Amprnet operators are, by custom, more open than their Internet counterparts as communication is our hobby. We also have a host of unique-to-Amateur services and this makes it is even more desirable to have conventions that are as intuitive as they can possibly be.

In addition to our own operating compatibility, we also have to consider that it is more common than ever for amprnet hosts to be interconnected to the Internet. Even more common is the practice of linking local area networks via closed links (IP Tunnels) through the Internet.

There are expected exceptions to this proposed standardization, however. For instance, it is impractical for existing holders of IP addresses to make a massive change in an existing subnet simply to satisfy a certain system of addressing. There also may be valid reasons that are not yet known to violate this proposed protocol.

However, when new subnets are created or the cooperation of operators in an existing subnet is obtained, the convention should be followed as closely as possible so that IP routing and related issues are intuitive.

In addition to this issue, this convention will also allow for a number of uniqe-to-Amateur Packet Radio situations and services.

Proposed IP Addressing Structure:

The best way to illustrate this proposed system is by example. In our example, we will use a currently non-existent network of

This is the network address, as per the Internet standard.

Is the primary high-speed network access point - the router used to access the network. This should be a reliable connection as it is the primary access point - generally a node or IP host with IP routing capabilities. through

These addresses are designated for other secondary routing ports in a nodestack or multi-port IP host/BBS. The preference is to have lower numbered routers, nodes, or a multi-port host within this block as the most reliable connections. Higher numbered hosts within the block are the least reliable or less-used routers, nodes, or ports in a multi-port IP host.

For example: is a UHF, SHF or Microwave high-speed X-1J backbone node is a VHF or UHF 9600 bps X-1J backbone node is a 220 MHz 9600 bps backbone node is a 50 MHz 2400 bps backbone node is a low-speed VHF user port routing to the Local Area Network is a high-speed UHF user port routing to the Local Area Net and

These are reserved for future usage. Should some new technology allow us to take advantage of an as-yet unseen service, these addresses will be available for such use.,, and

These are reserved for Primary, Secondary, and Tertiary Domain Name Servers designed to serve the Local Area Network. and

These two addresses are designated for POP3 (or subsequent protocol-based) mail servers. through

This address block is to be divided between DX Cluster BBSs, Local IP hosts (such as NOS) that are not performing network routing functions but are public facilities, and standard AX.25 BBSs that support IP operation (such as MSYS or FBB) and are public facilities.

The operative term here is "public facilities". This address block is not designed to be issued to an end user simply because he or she uses a NOS program as a client. They are to be assigned to public server-type facilities. through

This block is designated for end users who wish a permanent IP address. These addresses are not limited to client use only. An end user may provide a public service of some type that does not fit into the above reserved-block.

For example, a private user may provide a public weather station that provides local weather conditions on demand. If a private user decides to provide supplemental DNS service for a LAN, there is no valid reason to deny that end user the opportunity to provide such a service. If an end user is the only DNS on a local LAN however, it is suggested that he or she be assigned one of the addresses from the block or 3 reserved for that purpose.

In some circumstances, this end user address block may be further subdivided into different LAN frequencies for ease of routing. For example, our network has two user LAN ports on different frequencies. A common situation would be one low-speed VHF port and one high-speed UHF port. In this case, the block of to may be designated for the VHF user LAN, while to may designated for the UHF user LAN.

As higher-speed operation becomes more common, and more user ports are added, this subdivision or the numbering scheme for end users may be carried out further. It is entirely possible to envision 900 MHz ports in the near future, making yet one more division desirable. through

These addresses are reserved for dynamically-assigned addresses. Again, this block may be further subdivided to accomodate different user ports.

Subdivision of End User Address Blocks

This policy is to be set in accordance with local operating situations. In some cases where a subnet is not well populated, and there is only one user LAN, then there may not be a need for subdivision of network address blocks. In other areas with multiple well-populated user LANs, it makes sense to do this.

Whatever situation is needed, it is suggested that the operator(s) of the local router, node or IP host consult and work with the local subnet IP address coordinator (if one is available), or the state IP address coordinator.

This is a designated _short-term_ network address reserved for testing purposes and should not be assigned.

This is a Network Broadcast Address and should -never- be issued to a host. This will cause widespread havoc on the local network, as it is typically used for arp (address resolution protocol) requests.

Special Conditions

There are circumstances where an end user may request a block of addresses for his or her own personal network, and may wish to have access to and from the Local Area Network. Routing and subnet issues come into consideration here, and as such, a block may be assigned for purposes that conflict with the proposed addressing system.

The nature of such a network cannot be anticipated, and no special provision is made to guarantee ease of routing. In addition, local IP address Subnet Mangers and the State IP address coordinator are not network engineers and cannot be asked to provide such expertise. Their function is to cheerfully assign a suitable address.

Many may be able to help in such matters, if they have knowledge of such a network. If an end user has such special circumstances, attempts will be made to accomodate them. However, end users and network service providers should not expect anything other than an IP address (or block of addresses) from the IP address coordinator that they are interacting with.

System Changes

While there has been an attempt at providing for future changes and additions in network technology and services, no one can fully anticipate what the future will bring. For that reason, this system and this document are subject to change. In referncing this system, it will be referred to as IPAP-1 (IP Addressing Plan 1)

Submitted for comments on November 16, 2001 by Andy Nemec, KB9ALN Wisconsin and Upper Michigan IP amprnet address coordinator (

A Brief Word About Policies and Procedures:

IP addresses are only issued for the ampr.org domain, no other IP addresses are issued through your volunteer ampr.org IP address coordinator. IP addresses for other domains (such as .com, .biz, .tv, .gov, .net, .mil or other .org) can be obtained from commercial sources.

Likewise, your ampr.org coordinator cannot issue you a static IP address for a gateway or other facility for the internet side of such a system. IP addresses can only be assigned from the 44.92.x.x block of addresses, and this is limited to the amprnet side of your gateway. To obtain a static IP address for the internet side of your facility, contact your ISP. Alternatively, you can contact and obtain static routing for your dynamic address.

This coordinator only serves the State of Wisconsin and the Upper Peninsula of the State of Michigan (the 44.92.x.x subnet). Assistant coordinators manage certain areas of the network, called sub-nets and issue addresses for their designated area at the request of, and with the authority of the designated IP address coordinator. Requests for IP addresses in other states should be made with that state's IP address coordinator.

Different parts of the state have specific subnets. For example, the Green Bay area is designated the 44.92.20.x subnet, while Appleton and the Fox Valley have been designated the 44.92.18.x subnet. This is done not only to expand the available pool of IP addresses, but to allow easier routing for the networking of ampr.org hosts.

Special IP addresses can be issued, but it is a practice that is discouraged. To bring some uniformity of IP addressing and routing to the state, there are a number of conventions that are followed regarding the IP addresses assigned to routers, Domain Name Servers and BBSs. These closely reflect the Internet's customs, with special allowances made for the unique nature of our Service. As a result, your request for a specific IP address may not be in concert with these conventions.

However, there may be times when it is necessary to "swap" IP addresses or obtain a specific one. While nothing can be guaranteed, we'll try to work with all parties and assign an address appropriately. If no specific function for a host is specified and it is a "private" station/host, then a sequential IP address will be assigned from the available pool of addresses.

All IP addresses are assigned for as long as they are needed. No yearly maintenance or updating is required. However, if you move within the state (or the U.P. of Michigan), please notify the coordinator so that you can be assigned another address.

If you move out of state, you are asked to please surrender your current address by notifying the coordinator. You may obtain another address in another state through a process that is similar to this one.

IP addresses are usually assigned on an individual basis, however there is no reason why any club or organization with a valid ham callsign should be denied a block of 44-net IP addresses of any size.

Approach for Coordinators:

The most efficient way is probably the way the regional internet registries have been handling out allocation in the last couple of years. It's probably just easier to determinate the network size and assign the first available network of that size. Eventually you could temporarily reserve the adjacent network of the same size so that the network could be extended to that size if necessary. An example:

44.a.0.0/27 for user A
44.a.0.32/27 reserved for user A extension or until exhaustion of the
44.a.0.0/16 block
44.a.0.64/27 for user B
44.a.0.92/27 reserved for user B or until exhaustion
44.a.0.128/26 for user C
44.a.0.192/26 reserved for user C

Once you have filled all of 44.a.0.0/16 you can start allocating the reserved blocks. However if in the meantime user B needs more addresses, you can extend his allocation from 44.a.0.64/27 to 44.a.0.64/26. The renumbering is pretty easy in that case, a change if netmask is all that is required (in this example). On the other hand there is no link between a physical LAN and the addressing, a physical LAN might be using 2 or more subnets (44.a.0.64/26 and 44.a.0.192/26) for addressing.

In the AMPRnet this is the way IP allocation is handled.  I think this is the best approach when you are dealing with subnetting  and you do not know how usage will expand.

Local Subnets:

New subnets should be based on connectivity to a server (gateway, switch, node, etc).  Subnets and hosts will not be assigned to geographic areas (e.g., cities or counties) but to servers.

44.92.0.x Madison Area
44.92.1.x Milwaukee Area
44.92.2.x Sturgeon Bay/ Door County area
44.92.3.x Onalaska/ Tomah Areas
44.92.8.x Manistique/ Gladstone, MI area
44.92.12.x Houghton, MI area (145.090)
44.92.14.x Elkhorn/ Webster area
44.92.17.x Chippewa Falls area
44.92.18.x Appleton/ Fox Cities area
44.92.20.x Green Bay area
44.92.24.x Plymouth/ Sheboygan area
44.92.25.x Porterfield/ Peshtigo, WI
44.92.26.x Fort Atkinson
44.92.31.x Wittenberg area
44.92.34.x Ogema, WI area
44.92.35.x Racine area
44.92.36.x Stevens Point area

The old NetRom node names used the airport code standard for a naming convention.  i.e WIGRB (Green Bay), WIWIT (Wittenburg), WIAPL (Appleton), WISTB (Sturgeon Bay) etc.  Since there is logic in this, it is a still good recommendation for hostnames.   To ensure that all hostnames are unique, they must include an amateur radio callsign. Compound hostnames (e.g., "switch.n9dkh.ampr.org") are acceptable. Hosts may be given aliases like "wigate.ampr.org" through CNAME records.

For a metro-area /24 subnet (256 hosts - 254 usable, netmask, we suggest these standards:	subnet.grb-wi.ampr.org      gw.kb9mwr.ampr.org      ke9lz.ampr.org      kb9aln.ampr.org     n9pav.ampr.org    253-dhcp.grb-wi.ampr.org    254-dhcp.grb-wi.ampr.org	broadcast.grb-wi.ampr.org 

Reserve the first 4-5 addresses for routers and primary access points with IP routing capabilities, mail and DNS severs.  Reserve the last 4-5 for DHCP.  The last add

In reality, 256 host is quite a few, especially since things are in the decline.  Depending on activity, you might want to split your existing areas subnet.  I am guessing you never made it close to 128 hosts per subnet/city.  You may still have some 1200 baud AX.25 activity.  So why not something like this: (Netmask  Conventional packet:      subnet.grb-wi.ampr.org (subnet id)      gw.kb9mwr.ampr.org      ke9lz.ampr.org      kb9aln.ampr.org     n9pav.ampr.org    125-dhcp.grb-wi.ampr.org    126-dhcp.grb-wi.ampr.org    broadcast.grb-wi.ampr.org (broadcast address) (Netmask HSMM: hsmm-subnet.grb-wi.ampr.org  (subnet id) hsmm-gw.kb9mwr.ampr.org n9dkh.ampr.org hsmm-broadcast.grb-wi.ampr.org  (broadcast address)