XRPi Documentation - Miscellaneous

IP Primer

Name

IP-PRIMER -- IP Addressing / Routing Primer.

Synopsis

Basic introduction to Internet Protocol (IP) address format, IP routing and Address Resolution Protocol (ARP), aimed at sysops with little or no prior knowledge of IP.

Description

IP Addresses

All IP addresses consist of a 32 bit binary number, which is composed of four 8-bit binary numbers. For clarity they are usually expressed as four decimal numbers separated by dots, the so called "dotted quad" form, for example 44.131.91.2.

Each of the numbers which make up the quad can range from 0 to 255, i.e. 256 numbers in total. The numbers 0, 128 and 255 are usually reserved for special purposes.

The most significant (leftmost) number identifies the "network" within the whole Internet. 44 is allocated to Amateur Packet Radio, or "ampr.org".

Within the "amprnet" (Amateur Packet Radio IP Network), the second number from the left usually identifies the country, although in the USA it generally identifies a state. In some parts of the world it identifies a group of countries. In our example 131 is the code for the whole UK (see IP-CODES for a list of country codes).

The third number from the left identifies the "region" within the country or state, and in our example region 91 is North Worcestershire.

The rightmost number identifies up to 256 separate users within the region. The addresses within a region are sometimes allocated on a first come first served" basis, or sometimes in groups to allow further subdivision of a region.

IP Routing

Unlike NetRom routing, IP routing usually (but not always) has to be explicitly defined by the sysop, in XRPi's case using entries in IPROUTE.SYS.

The basic idea is that, for any destination IP address, the router must send the IP packet (usually called a "datagram") either directly to the destination (if it's on the LAN or within radio range), or to a "gateway" which knows how to reach the destination. In the most extreme case, you can simply send all non-local IP traffic to a gateway, who will handle it for you.

Since there are billions of IP addresses, it would be impractical to define a route for every possible destination. This is where the hierarchical structure of IP addresses come to your aid.

If you are in the USA, you don't need to know explicitly how to route to everyone in the UK. All you need to know is how to route to the UK, then the routers within the UK will do the work for you. If you don't know a route to the UK, simply route the traffic to a gateway who does. There is always someone willing to act a a gateway on your behalf.

Routing decisions are made using a special combination of IP addresses and "bits", for example 44.0.0.0/8. This tells XRPi to compare the destination IP address of datagrams with the leftmost 8 bits of 44.0.0.0, ignoring the rightmost 24 bits. This will match any address beginning with 44, i.e. the whole of amprnet. Since the rightmost 24 bits are ignored, 44.131.91.2/8 would have *exactly* the same effect.

The higher the number of bits, the more precise the match, for example 44.131.0.0/16 would "catch" all datagrams addressed to the UK, 44.131.91.0/24 would catch all datagrams addressed to North Worcestershire, UK, and 44.131.91.2/32 would match only one destination, namely 44.131.91.2. The "/32" is always the default if the number of bits is not specified.

Having "caught" a destination, the remainder of a routing entry tells XRPi which gateway (if any) to send it to, which port to send it on, and what mode to use.

IP routing is usually specified in IPROUTE.SYS using commands like this:

    IP ROUTE ADD <host>[/len] <gateway> <port> [mode [metric]]

For Example:

    IP ROUTE ADD 44.131.93.0/24  44.131.93.240  5  d

This would route all region 93 traffic (44.131.93.0 - 44.131.93.255) to the gateway 44.131.93.240 on port 5 using datagram mode.

Routing Modes

The routing [mode] indicates how the traffic is to to be handled, and is specified using a single letter as follows:

        
            d = Datagram (direct)
            e = Encap (ip-over-ip protocol 4)
            i = IPIP  (ip-over-ip protocol 94)
            k = Kernal
            n = Netrom (ip-over-netrom)
            r = Reject
            s = Silent discard
            u = IPUDP  (ip-over-UDP) 
            v = Virtual circuit (ip-over-ax25)

"Datagram" is the usual mode, and is the default if "mode" is omitted. It transmits datagrams "raw" inside SLIP, PPP, Ethernet or AX25 UI frames, according to the protocol used on the the destination port. There is no error correction at the link layer, so datagram mode should only be used on wire links, or RF links with low loss rates.

"Virtual Circuit" mode gives better performance on less than perfect RF links. It transports the IP datagrams inside AX25 <I> frames, detecting and correcting errors at the link layer.

"Netrom" mode is less efficient, but can "tunnel" datagrams across non-ip sections of the network by wrapping them in Netrom layer 3 frames.

"Encap" mode is used for IP/IP encapsulation, i.e. sending 44-net datagrams across the Internet by "wrapping" them in datagrams with public Internet addresses. This uses IP protocol number 4, which is nowadays blocked by Microsoft Windows TCP/IP stack.

"IPIP" is the original IP-within-IP encapsulation mode, using IP protocol number 94. It has the advantage that it is not blocked by Microsoft Windows TCP/IP stack, so it can be used to exchange encapsulated traffic with systems that are hosted on that platform.

"IPUDP" mode is similar to Encap and IPIP, except that the datagrams are first wrapped in UDP before being transported in IP. The advantage is that UDP is usually able to pass through routers which don't support IPIP or IPEncap, and can be selectively routed to different machines according to the UDP service port numbers. More about IPUDP.

"Kernal" mode is a dummy mode, left over from XR32. It instructs XRPi to use Linux kernal TCP/IP services to handle this traffic, instead of its own stack. The mode is of limited use in XRPi.

"Reject" entries are used to reject traffic destined for systems which don't exist, or are which not reachable via any port. If simply routed on the default port, such datagrams would waste resources and would probably end up looping back to us. Datagrams matching a "reject" entry are rejected by returning an ICMP "destination unreachable" report to the sender. The "gateway" ip address should be 0.0.0.0 and the port number is ignored.

"Silent Discard" entries are similar to "Reject", except that they simply dump the unwanted datagrams without sending an ICMP error report. This saves bandwidth when the problem is persistent, and is more suitable than "Reject" for suppressing malicious network probes.

Encap Blocking

Starting with Windows XP Service Pack 2, the IPEncap (encap) protocol 4 was blocked by Windows for "security reasons". This made it awkward for Windows-based systems such as XR32 to use it.

It was possible to bypass this block by using XR32's IP stack on top of an "NDIS" driver, and many people did. But the driver was never developed for systems later than Windows XP, meaning that those running XR32 on Windows 7 etc. could not directly participate in the IPEncap network. They had to use other means such as IPIP (protocol 94), IPUDP and so on.

Linux doesn't block IPEncap, so XRPi has no problem participating in the 44-net IPEncap network.

Address Resolution Protocol (ARP)

ARP is responsible for mapping gateway IP addresses to "hardware" (i.e. AX25 or Ethernet) addresses.

In order to send an IP datagram over an AX25 or Ethernet network, it must be "wrapped" in an AX25, Ethernet, or Netrom packet, and that packet will need a destination address appropriate to that network. For example, to route a datagram to 44.131.91.2 it must be wrapped in an AX25 packet addressed to GB7PZT-5.

The system *will* often work without any ARP entries, due to the process of "ARP resolution", whereby a router can make a broadcast asking adjacent systems if they know the hardware address for a given IP address, but this process takes time and the adjacent routers may not know the answer. Thus, for RF links at least, it is advisable to put ARP entries for each of your direct RF neighbours into IPROUTE.SYS. The general form of an ARP entry is:

    ARP <ADD | PUBLISH> <host> <hwtype> <hwaddr>

<host> is the neighbour's IP address in dotted quad form.

<hwtype> is the hardware address type, i.e. "ax25" "netrom" or "ether".

<hwaddr> is the hardware address, i.e. AX25 callsign or Ethernet address.

Example ARP entries:

This one causes datagrams bound for 44.131.90.6 to be wrapped in AX25 packets addressed to GB7IPT-9:

    arp add 44.131.90.6  ax25  GB7IPT-9

Whereas the following will send datagrams bound for 44.131.95.7 to the G7GHP-5 system via the GB7DIG digipeater. Up to 8 digipeaters may be used in a single comma-delimited string:

    arp add 44.131.95.7  ax25  G7GHP-5,GB7DIG

This one will wrap datagrams destined for 44.131.24.1 in Netrom packets addressed to node GB7CX:

    arp add 44.131.24.1  netrom  GB7CX

The following will wrap the datagrams in ethernet packets.

    arp add 44.131.91.9  ether  00:00:1B:2C:04:81

ARP PUBLISH is used in cases where one system is "hidden" behind another, and allows other systems to discover the correct hardware address to use.

For example, say 44.131.91.127 is only reachable via 44.131.91.245. Unless all the local systems were specifically configured to route to 91.127 via 91.245, they wouldn't know how to do it. Including the entry: "arp publish 44.131.91.127 ax25 g8pzt" on the 91.245 (g8pzt) router causes it to respond to anyone who asks for the hardware address for 91.127, giving its own ax25 address.

See also

ARP(2) -- Address Resolution Protocol Commands.
IP(2) -- IP Routing / Configuration Commands.
IPROUTE.SYS(8) -- IP Router Control File.