Specifications
IPNetRouter is Macintosh router software which permits you to share
your Internet connection. This includes PPP, Cable Modem, DSL, ADSL,
and PPPoE Internet connections. Designed from the ground up to take
full advantage of Open Transport, IPNetRouter offers superior performance
with greatly reduced cost and complexity.
As shown above, before installing IPNetRouter you have one machine
directly connected to the Internet and one or more machines networked
via a personal LAN (Local Area Network). Unfortunately, the other
machines cannot access the Internet with this setup.
After installing IPNetRouter, the PowerBook and any other computers
on the LAN have full Internet access. At the same time IPNetRouter
becomes an Internet sentry (firewall) and prevents unauthorized
access to machines on your LAN. This is because IPNetRouter enables
Open Transport to forward packets between the Internet and the Personal
LAN through a mechanism called "Network Address Translation"
(aka "NAT"). With both NAT and the packet filtering capabilities
of IPNetRouter, you can build a very solid firewall which prevents
unauthorized access from the Internet to any of your machines on
your personal LAN.
Since IPNetRouter understands network addresses that are independent
of the LAN hardware, it can connect networks using different physical
media. That is, you could have a private LocalTalk network, a private
ethernet network, a private wireless network and IPNetRouter would
be able to make intelligent decisions about which packets to forward
to/from the Internet and how to transfer packets from one network
to another. This capability is called "multilink multihoming"
and permits your Macintosh to have several different IP addresses
on several different physical networks...a feature most often associated
with much more complicated UNIX based computers.
System Requirements
- MacOS 7.5.3 and Open Transport 1.1.1 or later (OT
1.1.2 for 68k)
- Macintosh PowerPC or 68030 or higher.
- A Macintosh capable of connecting to the Internet using the
TCP/IP protocol suite.
Technical Description and Specification
IPNetRouter consists of the following major components:
- A utility for sending commands to the IP module in Open Transport
- A STREAMS module that performs Network Address Translation and
IP Filtering
- Support for PPP dial-on-demand
- Support for saved configuration files
- A graphical user interface
- A DHCP Server
The following sections examine each of these components in detail.
Utility for Sending Commands to IP
This component sends IOCTL commands to configure and bring up additional
IP interfaces based on the following parameters:
- The user port name or physical port name (from
the OT Port Registry)
- The interface name
- The IP address
- The network mask
- A set of boolean values that specify whether to bring the interface
up or down; enable IP masquerading on this interface; designate
the interface as unnumbered; and prevent a saved IP address from
overriding a DHCP assigned address.
This component builds additional Link Stacks (the chain of modules
between IP and a Data Link Provider (such as Ethernet) to support
multilink multi homing. Any Link Stacks created by IPNetRouter will
be dismantled when the program is quit.
In general, IPNetRouter can work with most Open Transport compatible
Data Link Providers such as Ethernet, Fast Ethernet, Token Ring,
PPP and others. In the case of PPP however, dial on demand support
is more limited (see below).
IPNetRouter supports MacIP (IP in AppleTalk) as a client. This
means IPNetRouter can build a Link Stack that will add or remove
the AppleTalk wrapper for MacIP allowing LocalTalk connected devices
to access TCP/IP services via IPNetRouter. IPNetRouter does not
assign IP addresses to other MacIP hosts at this time (as a traditional
MacIP gateway), it is necessary to configure each MacIP host manually.
This component enables or disables how the host forwards IP datagrams.
IP_FORWARD_NEVER (0) to inhibit forwarding (RFC
1122 compliance); IP_FORWARD_ALWAYS (1) to always forward; IP_FORWARD_AUTOMATIC
(2) to forward only if the number of IP interfaces on the system
is greater than 1 (SunOS 4.1.x compatible).
IPNetRouter supports static routing. It does not participate in
RIP exchanges or other routing table update protocols at this time.
STREAMS module that performs Network Address Translation (NAT)
and IP Filtering
An Open Transport STREAMS module (shared library) named OTModl$Proxy
is stored in the Extensions folder and inserted in any IP Link Stacks
immediately below the IP module itself. We will refer to this module
as the "Proxy" module through out the rest of this specification.
The Proxy module performs Network Address Translation (RFC-1631)
with extensions for Port Multiplexing and ICMP translation. Port
Multiplexing allows an entire LAN to hide behind a single public
(globally unique) IP address by assigning unique port numbers to
each actual endpoint. ICMP translation allows diagnostic tools like
Trace Route to work through the translator by keying off the "triggering
datagram" returned in ICMP response packets.
The use of a single public address with Port Multiplexing means
that protocols that do not include a protocol port number (ICMP
and GRE for example) are limited to a single host at a time.
The NAT function translates IP address and port information in
the IP header, TCP header, and UDP header. Certain protocols also
embed IP address and port information within the datagram body itself.
Among the most heavily used protocols, FTP does this when configured
to use "PORT" mode as opposed to "passive" (PASV)
mode. The Proxy module recognizes PORT commands on the standard
FTP control connection (port 21) and translates them as a special
case to provide ftp masquerading. Specialized gaming or streaming
protocols may not work with NAT without additional support.
GRE packets are passed unmodified to support PPTP for Window-NT
VPN.
The NAT function is normally enabled based on the physical port
(from the OT Port Registry). To facilitate using cable modems with
a single Ethernet (two IP interfaces on the same physical port),
IPNetRouter can designate one IP interface as a "Private Network"
so it will not translate datagrams to or from this IP interface
even though it is translating other datagrams on the same physical
port.
The Proxy module currently supports masquerading on up to four
Interfaces at a time (one translation table) using a single public
address with a maximum of 500 simultaneous connections (the translation
table can hold 500 entries).
The NAT table can be edited under user control to support Inbound
Port Mapping. See the Port
Mapping page at
<http://www.sustworks.com/site/ipr_guide/port_mapping.html>.
The Proxy module also supports IP Filtering on a per port basis.
See the Building Your Own Low
Cost Firewall page at
<http://www.sustworks.com/site/ipr_guide/firewall.html>
The module includes built-in filtering for Windows-95 and Windows-NT
NetBIOS DNS queries to prevent spurious connection attempts (UDP
datagrams from source ports 137, 138, and 139).
Support for PPP dial-on-demand
Open Transport 2.0 and earlier as supplied by Apple assumes there
can only be one IP data link active at a time. If that data link
is temporary in nature such as PPP, Open Transport will initiate
a connection when an application on that machine tries to open an
IP endpoint. Since IPNetRouter allows multiple data links to be
active and might receive IP traffic for a PPP interface from another
host, the existing mechanism does not provide the desired capability.
IPNetRouter implements dial-on-demand as follows. The IPNetRouter
application monitors the state of the PPP interface and notifies
the Proxy module whether that interface is up or down. While the
interface is down, IPNetRouter will periodically poll the Proxy
module to determine if it has seen any IP traffic for an on demand
interface. When an instance of the Proxy module that is pushed above
a PPP data link provider detects IP traffic for an interface that
is disconnected, it sets a flag to notify the IPNetRouter application
the next time it polls. The IPNetRouter application then launches
a connection attempt for that interface.
Since IPNetRouter needs to monitor the state of the PPP connection
and initiate a connection attempt when there is traffic for the
corresponding interface, IPNetRouter requires some PPP specific
code to carry out this task. It is for this reason the dial-on-demand
feature only works with certain PPP implementations. IPNetRouter
supports dial-on-demand with OT/PPP and FCR PPP (a.k.a. LinkUPPP
or LeoMLP) at this time.
When IPNetRouter initiates a PPP connection attempt, it is possible
the connection attempt will fail (line is busy, modems fail to connect,
ISP is offline, etc...). In this event, IPNetRouter will retry the
connection attempt five times. The first 3 tries tell PPP to initiate
a connection attempt. The next three tries will remove the PPP interface
and then add it back. If all 6 tries fail to connect, IPNetRouter
will wait 10 minutes and then try again to launch a connection attempt
repeating the process above.
It is possible for other PPP implementations to support dial-on-demand
directly without oversight from IPNetRouter. In this case, PPP would
initiate a connection when it receives IP traffic, and inform IPNetRouer
of the negotiated local IP address possibly using the command file
interface described below.
Support for saved configuration files
IPNetRouter allows you to save the current networking configuration
including any interfaces, routes, port mapping, filters, or other
gateway settings you have specified. To save the current configuration
you can choose Save under the IPNetRouter File menu. To restore
this configuration at a later time, you can open the corresponding
configuration file from the Finder by double-clicking or placing
it in the Startup Items Folder. IPNetRouter configuration files
contain human readable text to simplify debugging or controlling
the application directly from stored configuration files.
The format of IPNetRouter configuration files is largely self evident.
Consider the following example:
#forwardingAutomatic +interface\ \lo0\127.0.0.1\255.0.0.0\
+interface\Ethernet\mace0\192.168.0.2\255.255.255.0\ +interface\PPP\IPCP0\0.0.0.0\0.0.0.0\masquerading\
+route\Direct\192.168.0.0\192.168.0.2 +route\Direct\224.0.0.0\192.168.0.2
+route\Default-Gateway\0.0.0.0\0.0.0.0 +map\icmp\209.6.64.35:0\209.6.64.35:0\1\
#end
Keywords corresponding to individual settings begin with the pound
character "#" in the first column. Commands to the IP
module begin with a plus "+" or minus "-" character.
Command parameters are delimited by the backslash "\"
character. The configuration ends with a line containing "#end".
Any line beginning with a character other than "#", "+",
or "-" will be treated as a comment and ignored.
IPNetRouter process the commands in order trying to make the current
networking configuration match the configuration contained in the
file. Any existing interfaces or routes not listed in a saved configuration
will be removed. If the keyword "#addOnly" is seen, IPNetRouter
will not try to match the entire configuration, but simply execute
any commands in the file. If the keyword "#delete" is
seen, IPNetRouter will delete the configuration file after processing
the commands therein.
"+interface" specifies to bring up an interface. "-interface"
specifies to remove an interface. "+route" adds a route,
"-route" removes a route. "+map" and "+filter"
entries work similarly.
IPNetRouter recognizes the Open File Apple Event which can be used
to programmatically change the networking configuration. The application
creator signature for IPNetRouter is "IPnl". IPNetRouter
can be configured as a faceless background application to hide the
default user interface described below.
Keyword commands:
#forwardingNever #forwardingAlways #forwardingAutomatic #configureOnly
#configureDisplay #auto #addOnly #remainConnected #remainconnectedOff
#disconnectAtQuit #disconnectAtQuitOff #showPPPdialogs #showPPPdialogsOff
#dialOnDemand #dialOnDemandOff #enableLocalNAT #enableLocalNATOff
#TRCableModem #TRCableModemOff #PPPName=<name-of-TCP/IP-config>
#disconnect #connect #delete #quit
Interface parameters
\masquerading
\unnumbered
\dhcp
\nogateway
\mtu=
Graphical User Interface
In Macintosh fashion, the IPNetRouter user interface consists of
a menu bar with standard commands and a set of windows that allow
you to edit application data thereby controlling the application
and networking configuration. Individual windows can be invoked
from the Window menu. To allow a single IPNetRouter configuration
document to represent the entire network configuration, the Routes
Window, Gateway Window, Port Map Window, and IP Filtering Window
are children of the Interfaces Window and correspond to different
views of a single document. Closing the Interfaces Window closes
the corresponding document and will automatically close its dependent
windows.
Each IPNetRouter window contains a help button in the lower left
corner that describes the window controls in more detail.
Many of the windows follow a similar model for sending commands
to the IP module in Open Transport. A table along the top of the
window shows the current configuration. You specify the parameters
of the command in an entry area below the table, and then send the
command by pressing the Add or Remove button. The Interfaces table
for example shows the actual IP interfaces the IP module knows about.
When you click on a line in the table, it copies the current information
from that line to the Configure Interface box below to save you
the trouble of retyping it, thus making it easier to modify an existing
interface. It is the parameters in the entry area that control what
happens, not what line of the table is selected. The IP module identifies
which interface you are trying to modify by the interface name field
in the Configure Interface box.
If you try to send commands that don't make any sense, the IP Module
will not accept them and no changes will appear in the table.
A status line along the bottom of the window provides a summary
of any unexpected conditions or errors encountered while trying
to perform a command. The IPNetRouter Log window records what the
program is doing and will often provide additional information that
would not fit in the status area. The contents of the log are also
written to the file "IPNR.log" in your Preferences Folder.
The log file is automatically re-used each time you launch the IPNetRouter
application. In the event of a system crash that precludes reviewing
the log window, it is important to rename or copy the IPNR.log file
before re-launching IPNetRouter.
DHCP Server
The DHCP window allows you to configure the DHCP server built-in
to IPNetRouter. In order to access the Internet, each computer on
your LAN needs to be configured with four pieces of information
(IP Address, Network Mask, Router Address, and Name Server Address).
The DHCP server in IPNetRouter allows other computers on your LAN
to get this information automatically from IPNetRouter by selecting
"Configure via DHCP" in the corresponding TCP/IP control
panel.
Using DHCP (Dynamic Host Configuration Protocol) avoids the need
to manually configure each computer on your LAN before it can be
used, and is especially useful if you have many computers on your
LAN or frequently move computers from one network to another.
Before you can use DHCP to configure other hosts on your LAN, the
DHCP Server itself needs to be configured. In most cases, you can
simply press the "Use Defaults" button and enable the
server by selecting "DHCP Server On". These settings assume
your LAN will use IP addresses from the range 192.168.0.x and that
your gateway running IPNetRouter will use 192.168.0.1 as its local
address. [*WARNING* If you are connecting using a cable modem and
single Ethernet, you must not enable DHCP on this Ethernet since
DHCP requests are broadcast to all interfaces on that physical network.]
If your Local Area Network has additional requirements, you can
use the DHCP Window to control what IP addresses to assign, to whom,
for how long, and other operational parameters. The information
in the DHCP Window is divided into four tables or panels which are
briefly described below. For more information on DHCP, refer to
RFC-2131, RFC-2132, or a good book on TCP/IP.
Status Table
This table keeps track of Lease Bindings. What addresses are currently
leased, to whom (hardware address or clientID), and when the lease
expires. It also keeps a state value for each entry so it can track
bindings that are not currently active (such as bindings that have
been offered, released, or expired). The intent here is to remember
previously assigned leases so clients will always get the same lease
whenever possible. Finally, this table keeps track of when each
entry was last updated so the server can re-use the oldest unused
entry first ("Least Recently Used"). This table should
normally be viewed as "Read Only", but you can use the
button on the right to remove an obsolete lease binding. You can
also copy rows to the clipboard as text for use in other panels.
The Status Table is stored in a separate file in the Preferences
Folder called "DHCP Server Status". Any time a lease is
granted to a client, the corresponding entry is written out to this
file (committed to non-volatile storage). If the server is stopped
for any reason, it can recover all the current lease information
from here. You can also move your DHCP Server to another machine
by copying this file and the corresponding IPNetRouter configuration
file.
Static Config Table
This table keeps track of any static address assignments the administrator
wants to create. The fields are: (1) Network Interface - the IP
address of which interface a request must arrive on [If a host moves
from one network to another, we need to assign a different IP address
depending on which network it is attached to. If a BOOTP relay agent
is used, we match this network as well.]; (2) Lease Address - the
address to grant; (3) What host or client this address is reserved
for as specified by the Ethernet hardware address or ClientID. The
ClientID will override the hardware address if specified in the
table. The entries in this table can be edited in place by clicking
in a cell. Use the buttons on the right to insert or delete entire
rows. You can use Tab, Shift Tab, Return, and Shift Return to move
the selected cell.
The Static Config Table is stored as part of your IPNetRouter configuration
when you save from the file menu.
Dynamic Config Table
This table keeps track of ranges of IP addresses that can be automatically
assigned to hosts as needed and later reclaimed. The fields are:
(1) Network Interface - the IP address of which interface a request
must arrive on [Each network interface that accepts DHCP requests
will normally assign IP addresses from a different range.]; (2)
Starting Lease Address - start of range used for address pool; (3)
Ending Lease Address - end of range used for address pool. The entries
in this table can be edited in place by clicking in a cell. Use
the buttons on the right to insert or delete entire rows. You can
use Tab, Shift Tab, Return, and Shift Return to move the selected
cell.
There are no restrictions on how many address ranges can be defined
to serve from multiple interfaces or multiple ranges on a single
interface. Any IP address in a dynamic address pool that overlaps
with an address in the Static Config Table will be reserved for
static configuration and not dynamically assigned. The Dynamic Config
Table is stored as part of your IPNetRouter configuration when you
save from the file menu.
Some clients may use BOOTP, an older subset of DHCP. BOOTP clients
are normally not eligable to receive dynamic IP addresses because
BOOTP does not provide any mechanism to reclaim an expired address.
To avoid requiring the network administrator to create a static
assignment for each BOOTP client, IPNetRouter will try to assign
BOOTP clients a dynamic address if no static configuration is found
and display a warning message in the log window. In order not to
lose addresses permanently, the server will try to reclaim "BOOTP
dynamic addresses" after 60 days.
Lease Options Table
This table stores the other information that is given out to clients
based on what network they are attached to. The fields are: (1)
Network Interface - the IP address of which interface a request
must arrive on [Each network interface that accepts DHCP requests
can potentially give out different information.]; (2) Network Mask
- the network mask for this network; (3) Routers - the router addresses
for this network; (4) Name Servers - the name server addresses for
this network; (5) Default Lease Time - lease time granted if none
is explicitly requested; (6) Maximum Lease Time - the maximum lease
time to grant regardless of what is requested; (7) Domain Name -
A default domain clients can use for DNS lookups; (8) Enable DHCP
on this interface - DHCP serving can be selectively enabled on a
per interface basis.
The Network Interface popup menu lists the IP interfaces which
have a lease options entry currently defined. It selects which row
of the table to view in the rest of the panel. If you select a new
interface, IPNetRouter will try to fill in appropriate values for
the subnet mask, router, name server and default lease times. The
Lease Options Table is stored as part of your IPNetRouter configuration
when you save from the file menu.
More About DHCP Data and Editing
When you edit data in place, you are only editing a visible copy
of that data on the display. You can undo any changes you make by
pressing "Restore". To have your changes take effect,
you must press "Apply". To save your settings to an IPNetRouter
configuration file, you must still select "Save" from
the File menu.
DHCP should be seen as a mission critical service since hosts on
your LAN may not be able to use the Internet if your server is unavailable.
DHCP is designed so that more than one server can be configured
to provide the same information for reliability. Clients normally
try to renew an existing lease and only the Server with a record
of that lease will respond. If the existing lease cannot be renewed,
the client may then try to obtain a new lease. The Server pings
any new proposed lease address before offering it to a client to
check that the address is not already in use. If the Server discovers
an address conflict, it will mark the corresponding address in the
Status Table as "In Use" or "Declined" and no
longer try to assign it. You can see when the conflict was detected
from the "Last Update" column in the Status Table. In
order not to loose addresses permanently, the server will try to
reclaim "In Use" or "Declined" addresses after
60 days.
Since the Status Table is kept as plain text in the file "DHCP
Server Status", you can edit this table manually if desired.
Resource Options
IPNetRouter supports a number of resource switches that can be
used to further customize the application. These are stored in 'STR#'
resource 131 named "Option Settings". The setting names
and their defaults are listed here:
SleepTime=6
Parameter passed to WaitNextEvent
LogFileName=IPNR.log
Name of IPNR log file in Preferences folder
ConfigFileName=Router Config
Name of config file in Preferences folder to load automatically
at application startup.
PPPName=IPNetRouter
Name of configuration in TCP/IP control panel to temporarily activiate
for PPP connection.
IPNetRouterDials=1
Selects whether IPNetRouter will always tell PPP to dial before
building a PPP link stream. Setting this to zero (0) allows PPP
to decide when to dial on demand.
DynamicBOOTP=1
Allow BootP clients to receive an IP address from the dynamic address
pool (like DHCP clients) instead of requiring a static configuration
for each client.
AuthorizationName=wireless-authority
Name used to determine whether a wireless base station is permitted
on this network.
DHCPPingCheck=1
Allows you to control whether the DHCP Server will ping a new address
to verify it is not in use before offering it to a client.
MapBroadcast=1
Allows you to control whether IPNetRouter will automatically create
a port mapping entry to forward directed broadcasts to your private
LAN. This can be used to help locate services on your LAN using
NSL/SLP.
Top
|