home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / ip / manage / snmp / kip / doc / ip.at < prev    next >
Encoding:
Text File  |  1989-01-17  |  11.1 KB  |  243 lines
  1. IP ADDRESS MANAGEMENT ON APPLETALK            (rev. 12/3/86)
  2.  
  3.  
  4. TRADITIONAL IP ADDRESSING
  5.  
  6. The original scheme of having a local 'Configuration File' on each Mac
  7. containing the local and gateway IP addresses has several disadvantages:
  8.  
  9.     - Each user must have a proper configuration file on his disk;
  10.       this creates administration problems.
  11.     - The IP address space is scarce, dedicating IP nets or subnets
  12.       to each AppleTalk cable is wasteful.
  13.     - Routing issues are also involved:  if unique IP net/subnet
  14.       numbers are used for the AppleTalk cables, then routers
  15.       throughout the IP internet system must know the routes to 
  16.       those numbers.  
  17.     - The IP client user generally doesnt care or wish to know
  18.       what his local IP address is.
  19.     - ARP on DDP as originally implemented does not work over
  20.       multiple bridged (non kbox) networks.
  21.     - IP users are more interested in locating NAMED IP entities.
  22.  
  23.  
  24. REVISED IP ADDRESSING SCHEME
  25.  
  26. A new technique for IP address management utilizes the preexisting
  27. AppleTalk protocols NBP (name binding) and ATP (transaction) to provide
  28. these related services:
  29.  
  30.     (1) Address Assignment:  upon startup most client hosts dynamically
  31.         obtain their IP address assignment via a transaction with
  32.         an 'assignment server'.  This still allows for certain
  33.         hosts to have fixed address assignment via the traditional 
  34.         configuration file method.
  35.  
  36.     (2) Address Resolution:  NBP is used to perform the ARP
  37.         protocol that maps IP addresses into AppleTalk 'hardware'
  38.         addresses.
  39.  
  40.     (3) Other services:  the 'assignment' server is also extensible
  41.         in that future services may also be provided.  For example
  42.         a domain name lookup service could be provided so that
  43.         the Mac does not have to be concerned with the details or
  44.         locations of such services.
  45.  
  46. The assignment / lookup services are typically implemented within an
  47. AppleTalk/Ethernet gateway (Kinetics KFPS ('kbox') or Seagate).  These
  48. services could also be located on an 'open architecture' Mac or UNIX
  49. box with both AppleTalk and Ethernet interfaces.  We refer below to the
  50. location of this service as simply the 'gateway'.
  51.  
  52. The address resolution service exists in each client as a name binding
  53. in its local Name Table.  IP addresses are represented within NBP
  54. requests in the ascii 'dot notation', i.e., four bytes of address
  55. represented by four decimal strings, separated by dots.  For example:
  56. '36.44.0.99'.
  57.  
  58.  
  59. IPGATEWAY SERVICE(S)
  60.  
  61. All IP address related services (EXCEPT for the address resolution
  62. protocol, ARP) are located at the gateway as NBP service type 'IPGATEWAY'.
  63. To use one of the services, the client first does an NBP Lookup for
  64. name='=', type='IPGATEWAY', zone='*' (this means, ANY instance name, MY
  65. zone, service type IPGATEWAY).  After receiving the NBP reply the client
  66. should remember the AppleTalk address returned.  Subsequent requests are
  67. then sent to this address using the AppleTalk Transaction Protocol (ATP).
  68. In both the NBP and ATP requests the client program should set the 
  69. retransmit timer to no less than 5 seconds and retry counter to
  70. around 4 trys.
  71.  
  72. The request sent with ATP to the gateway is a structure of the following
  73. form:
  74.  
  75.     struct IPGP {
  76.         long    opcode;        /* opcode */
  77.                     /* return values: */
  78.         long    ipaddress;    /* my IP address (or lookup reply)*/
  79.         long    ipname;        /* address of my name server */
  80.         long    ipbroad;    /* my broadcast address */
  81.         long    ipfile;        /* my file server */
  82.         long    ipother[4];    /* other addresses/flags */
  83.         char    string[128];    /* null terminated string */
  84.     };
  85.     /* opcode is one of */
  86.     #define    ipgpAssign    1    /* assign me an address */
  87.     #define    ipgpName    2    /* name lookup */
  88.     #define ipgpServer    3    /* just return my server addresses */
  89.     #define    ipgpError    -1    /* error return, string = message */
  90.  
  91. To make a request of an IPGATEWAY service, the client fills in the
  92. appropriate request opcode and any parameters needed;  it then sends
  93. the packet with ATP.  When the ATP reply is received, opcode will be
  94. positive if the request completed ok, otherwise negative.  If an error
  95. occured a user readable string will be available in 'string';
  96. otherwise the requested information is located in the ip* fields and/or
  97. string.
  98.  
  99.  
  100. ADDRESS ASSIGNMENT SERVICE
  101.  
  102. Most client machines will go through an address assignment phase as
  103. they begin running a given IP package or program.  In the case of the
  104. current MacIP implementation, each invocation of 'telnet', 'ftp', etc.
  105. will perform this assignment phase at startup time.  However future
  106. MacIP implementations may only perform address assignment once when the
  107. IP/TCP layer is loaded onto the system heap/BufPtr;  subsequent IP
  108. applications then utilize the state obtained by this base protocol
  109. layer.
  110.  
  111. Clients (typically service hosts) which already have obtained their
  112. IP address assignment from a local configuration file, will bypass
  113. this assignment phase entirely.  However such a client still must
  114. register its chosen IP address with NBP as described in the ADDRESS
  115. RESOLUTION section below.
  116.  
  117. To implement the assignment service the gateway contains a table
  118. (configured at boot time) designating a 'range' of IP addresses (on the
  119. ethernet side) which are available for assignment to clients.  Each
  120. table entry record/structure contains these fields:
  121.  
  122.     IP address;  timer;  flags;  AppleTalk address;
  123.  
  124. When the client startup code sends an ipgpAssign request to the gateway,
  125. the gateway searches the IPaddress/AppleTalkaddress table described
  126. above.  The service trys to 'reassign' the same IP address to the same
  127. AppleTalk address if possible.  Otherwise any free slot is used.  If a
  128. slot is obtained the reply is sent with 'ipaddress' containing the
  129. assigned address and the timer field of that table entry will be
  130. started.
  131.  
  132. Thereafter, every 60 seconds an 'echo command' (NBP confirm) is 
  133. sent to the client and the timer bumped.  Echo replies received will
  134. restart the timer.  If 5 minutes pass with no replies received, that
  135. table entry will be available for potential reassignment.  In making
  136. 'new' table assignments the timer field is used to locate the oldest
  137. unused table entry.  This increases the chances of a given client to
  138. keep reusing his IP address assignment if it has recently been active.
  139.  
  140.  
  141. ADDRESS RESOLUTION
  142.  
  143. As each client IP package starts up, it enters its own IP address (in
  144. dot notation) into its local Name Table via a call on NBP Register:
  145.  
  146.     name: 'WW.XX.YY.ZZ', type: 'IPADDRESS', zone: '*'
  147.  
  148. No errors should result from the NBP Register call.  (If 'duplicate name'
  149. resulted it would mean that somehow the IP address assignment service
  150. was misbehaving.)  This name binding should be removed by the client
  151. upon exit from the IP package, or of course if the client powers off or
  152. reboots.
  153.  
  154. In the client and gateway 'IP output' code, NBP is then used as the
  155. the address resolution protocol (ARP) to turn an IP address into an
  156. AppleTalk address.  The usual code in IP output that checks 'is the
  157. destination IP address on the same IP network as I am' is now disabled.
  158. ALL IPs are directed via NBP to the appropriate AppleTalk address.
  159. (Recall that the IP output code caches one or more of these mappings
  160. so that NBP is only called once per new connection.)  If the client
  161. is connecting to other clients on AppleTalk, they will answer the NBP.
  162. If the IP address in question requires gateway routing, then the gateway
  163. will reply to the NBP as being the appropriate next hop address for this
  164. packet.
  165.  
  166. For clients with local disk file configuration tables, the gateway
  167. actually has TWO ranges of IP addresses that it manages.  The first set
  168. of addresses are dynamically assigned as we discussed previously.  The
  169. second set of addresses are statically assigned to clients that are
  170. locally configured.  In this second case the gateway locates these
  171. clients as expected using NBP lookups for IPADDRESS types.
  172.  
  173.  
  174. 'SERVER ADDRESS' SERVICE
  175.  
  176. The 'ipgpAssign' opcode discussed above under 'address assignment
  177. service' really performs two functions:  (1) it returns the assigned
  178. client IP address in the 'ipaddress' field and (2) it fills in the
  179. 'ipname', 'ipfile', 'ipother', etc. fields with the addresses of those
  180. services.  This is because the client usually does not have a
  181. 'configuration file' and the client may need to know several other IP
  182. addresses to get started.  For example, since the 'ipgpName' opcode is
  183. currently unimplemented, a client desiring name service should perform
  184. a lookup itself to the address given in 'ipname'.  The Stanford MacIP
  185. code uses the simple UDP IEN116 name lookup server;  but the 'ipname'
  186. host also runs a full domain name server and the MacIP code could be
  187. changed to use this instead.
  188.  
  189. Even if the client HAS a configuration file, some of the entries in
  190. that table may be undefined and so it is useful to have another opcode
  191. 'ipgpServer' that just returns the server addresses without assigning a
  192. dynamic client IP address.
  193.  
  194.  
  195. ROBUSTNESS ISSUES
  196.  
  197. In general the gateways are a good location for the address assignment
  198. function because they are distributed close to the clients requesting
  199. service and in particular, kboxes tend to remain up over long periods
  200. and thru power failures.
  201.  
  202. However if the address assignment state information is lost in a gateway
  203. reload, the assignment function is still robust and recoverable.  This
  204. is because the gateway reloads its dynamic address mapping table at
  205. startup time.  It does this by asking several times (via NBP) for all
  206. type=IPADDRESS names.  The replies that are received are entered into
  207. the address mapping table, just as if they had been rerequested by the
  208. client.
  209.  
  210.  
  211. GATEWAY CONFIGURATION
  212.  
  213. To reduce the amount of information that has to be locally configured
  214. into each gateway, the gateway performs a 'configure' protocol with the
  215. 'appletalk administrator' host upon startup.  Thus the only
  216. information that the gateway must know at download time is its own IP
  217. address and that of the adminstrator.
  218.  
  219. The configuration information includes the ranges of IP addresses
  220. mentioned above, the special IP addresses provided in the IPGP packet,
  221. flags, etc.  One of the flags that may be set will disable the IPGATEWAY
  222. NBP service, so that a local Mac or UNIX host on appletalk may provide
  223. the assignment service(s) instead.
  224.  
  225. The appletalk IP addresses (static and dynamic) and the gateway's own
  226. IP address, form a contiguous group of IP numbers on the ethernet side
  227. of the gateway.  For example if the configuration places the gateway at
  228. 36.99.0.20 with 4 static and 6 dynamic addresses, the static addresses
  229. will be from 36.99.0.21 thru .24;  and the dynamic addresses will go from
  230. 36.99.0.25 thru .30.
  231.  
  232. In the case when several kboxes are on a single ethernet acting as a
  233. backbone between appletalk segments, another simplification is possible.
  234. Rather than having to specify a specific small static/dynamic range for each
  235. kbox (and effectively limiting the number of free slots available on
  236. a given appletalk segment), one can use a special configuration.  All of
  237. the kboxes except one are setup with zero static and dynamic ranges.
  238. Then the final kbox is is setup with a larger range of addresses and a
  239. special configuration flag is set.  This flag allows this box to provide
  240. the assignment and ARP-faking service for ALL the kboxes on the same
  241. ether segment, resulting in more available IP addresses in the pool for
  242. assignment.
  243.