idnits 2.17.1 draft-ietf-appleip-MacIP-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 9) being 60 lines == It seems as if not all pages are separated by form feeds - found 40 form feeds but 42 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of lines with control characters in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 442: '...rming to MacIP-1 MAY implement either ...' RFC 2119 keyword, line 476: '.... MacIP gateways MAY provide either a...' RFC 2119 keyword, line 516: '...to the Server, and SHOULD then receive...' RFC 2119 keyword, line 531: '... address through NBP. It MUST use its...' RFC 2119 keyword, line 535: '...ring "IPADDRESS" MUST be used. For ex...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 145 has weird spacing: '...netting and r...' == Line 258 has weird spacing: '...tion on a poi...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The IP addresses that the MacIP gateway has that are within the MacIP Range SHOULD be registered with the NBP protocol on the gateway in the same way that IP addresses are registered on MacIP hosts. This guarantees that MacIP hosts will not succeed in registering the same address in the same zone. Also, this makes the IP addresses visible to both MacIP hosts (that may wish to send datagrams to these IP addresses) and to network management software. If the registration fails then MacIP MAY not be able to function on the gateway, and appropriate actions should be taken. "Passive Registration" (section 5.3.2.1) SHOULD not be used. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This may be the Ethernet IP broadcast address which is only "appropriate" for the MacIP hosts if the MacIP gateway is configured in "Forwarding" mode. If it is in "Routing" mode, this field could be anything. MacIP hosts MUST not rely on this data. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The implementation SHOULD not take any notice of the returned NVE name field in the NBP response. However, it should be noted that many implementations expect to find the IP address corresponding to the Server in dotted decimal format. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The implementation SHOULD record the full AppleTalk address returned in the NBP response (including the returned socket) and use it in subsequent transactions with the Server. It SHOULD not simply assume that the Server is on DDP socket 72. However, there are many existing implementations that make this assumption. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 1992) is 11477 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'MacIP' on line 9 -- Looks like a reference, but probably isn't: 'Server' on line 503 == Unused Reference: '5' is defined on line 2016, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2022, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Unknown state RFC: RFC 917 (ref. '5') ** Obsolete normative reference: RFC 1009 (ref. '7') (Obsoleted by RFC 1812) ** Downref: Normative reference to an Unknown state RFC: RFC 1027 (ref. '8') ** Downref: Normative reference to an Historic RFC: RFC 1058 (ref. '9') Summary: 16 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area Tom Evans 3 Internet Draft Webster Computer 4 Expires May 1993 Christopher Ranch 5 Novell, Inc. 6 November 1992 8 A Method for the Transmission of Internet 9 Packets Over AppleTalk Networks [MacIP] 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a 22 ``working draft'' or ``work in progress.'' Please check the 1id- 23 abstracts.txt listing contained in the internet-drafts Shadow 24 Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, 25 ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any 26 Internet Draft. 28 Abstract 30 This Internet Draft describes an existing protocol for transporting 31 IP packets over AppleTalk networks. It is intended to specify, 32 standardize, and enhance existing implementations. Distribution of 33 this memo is unlimited. 35 This Internet Draft is a product of the Apple-IP Working Group of the 36 Internet Engineering Task Force (IETF). 38 Table of Contents 40 (To be generated and inserted later) 42 Overview 44 There is much confusion over what MacIP really is, as it has grown by 45 many small increments designed and implemented by at least as many 46 people. There has been no central or formal design document, so each 47 of the protocol additions and their effects are not well understood. 48 We hope to dissect the anatomy of the current state of the art, and 49 recommend a functional subset of the protocol features and a new 51 MacIP November 1992 53 gateway architecture that will help provide services to multiple 54 zones more reliably. 56 The MacIP protocol is used to transport IP packets across AppleTalk 57 networks. There are many existing host and gateway implementations of 58 this protocol, and most of them have many slight differences. 60 We'll call the functional subset MacIP-1. It is our intention that 61 it is compatible with as many of the current implementations as is 62 practically possible. It also describes a set of existing features 63 that will not work except in specific topologies. A future document, 64 MacIP-2, will describe a protocol that provides the intended 65 features, but does so for all AppleTalk topologies. 67 The new proposed gateway architecture describes an Internal Virtual 68 MacIP (VIM) , which requires a gateway to maintain an internal 69 virtual network that has all zones that are supported in its zones 70 list. This does not require any modifications on existing MacIP host 71 implementations, and existing gateways will have a simple single- 72 point modification. 74 1. Introduction 76 The goal of the MacIP architecture is to provide TCP/IP services and 77 connectivity to computers that are not directly connected to an IP 78 network, but are connected indirectly via an AppleTalk network. 79 Typically these are Apple Macintosh computers, but the use of MacIP 80 is not restricted to them. 82 IP hosts must be connected directly to appropriate media in order to 83 communicate with other IP hosts or gateways. All Macintosh computers 84 come equipped with LocalTalk, Apple Computer's medium speed network 85 media. LocalTalk is not capable of carrying IP directly. Thus, 86 MacIP gateways have been developed to provide IP front-end forwarding 87 agents on behalf of IP hosts embedded in AppleTalk networks. 89 It is recommended that hosts use this protocol only if they do not 90 have a direct connection; that is their network media does not 91 support IP. The details IP hosts directly connected to IP networks 92 are covered in other well known RFCs. 94 1.1. Terminology and Topology 96 In this document, the term "MacIP" refers to the encapsulation 97 protocol and associated services. Specific parts of the protocol are 98 given more specific names as appropriate. In a "MacIP internet" 99 there are two distinct types of devices. 101 MacIP November 1992 103 The first are termed "MacIP hosts", and are usually Apple Macintosh 104 computers. They are running applications over TCP/IP, and can use 105 MacIP to communicate between themselves within the confines of their 106 AppleTalk internet. 108 When communication is desired with common IP devices on IP supported 109 networks (hereafter called "IP hosts"), the services of the second 110 MacIP device, a "MacIP gateway", is required. A MacIP gateway 111 forwards IP datagrams between IP supported networks and MacIP devices 112 on AppleTalk networks, as well as provides other server-type 113 functions. 115 The term "MacIP Packets" specifically refers to IP datagrams 116 encapsulated in AppleTalk packets that are sent between the 117 forwarding modules in MacIP hosts and gateways. 119 The term "MacIP Range" refers to the set of IP addresses configured 120 into a MacIP gateway that are considered to belong to the MacIP hosts 121 being serviced by that MacIP gateway. 123 Other terms will be defined as they are used, and most appear in the 124 Glossary. 126 The AppleTalk protocols used by MacIP are detailed in section 8 which 127 describes DDP (Datagram Delivery Protocol), ATP (AppleTalk 128 Transaction Protocol) and NBP (Name Binding Protocol). If you are 129 not familiar with AppleTalk, then please read the relevant sections 130 in Inside AppleTalk [1]. 132 1.2. Intended Audience 134 It is expected that there are five different groups of people likely 135 to be reading this document: MacIP host implementors, MacIP gateway 136 implementors, system managers in trouble, the terminally curious, and 137 Jon Postel. 139 1.3. Assumptions 141 This document assumes the reader is familiar with the AppleTalk suite 142 of protocols. AppleTalk is documented in "Inside AppleTalk" [1]. It 143 is also assumed that the reader is familiar with the IP suite of 144 protocols, particularly IP [2], IP over Ethernet [4], Ethernet ARP 145 [3], RIP [9], subnetting and routing [6], IP host requirements [10], 146 and as documented in other various RFC's. 148 This document is purposefully confined to the description of the two 149 port gateway, where one port is connected to an AppleTalk network and 150 one port is connected to a Ethernet IP network. This is for 152 MacIP November 1992 154 descriptive simplicity and should not restrict implementations in any 155 way. 157 The described AppleTalk port of the gateway and of the host does not 158 need to be restricted to LocalTalk as AppleTalk may be transmitted 159 over other media, such as Ethernet (EtherTalk), Token Ring 160 (TokenTalk), a Serial connection (ARAP), or anything else. 162 1.4. Structure of this Document 164 MacIP is a complex protocol; there are multiple modules in both the 165 gateway and the host. Some of them operate in a client/server mode. 166 Others operate peer-to- peer and/or peer-to-proxy. 168 The original protocol specification, MacIP-1 is described in sections 169 2 and 3. It begins with a description of the whole system, moves on 170 to detailed descriptions of the individual modules, then describes 171 the protocols used. 173 Section 4 discusses MacIP limitation, and recommends a subset of 174 features and the Virtual Internal MacIP architecture. These 175 limitations and recommendations are for informational purposes. 177 Section 5 provides a brief synopsis of AppleTalk, and discusses MacIP 178 required variations of the AppleTalk Name Binding Protocol, NBP. 180 Sections 6 and 7 provide protocol constant definitions and a 181 glossary. 183 Section 8 provides implementation notes on many of the previous 184 sections. Its section numbering is discontiguous, and follows which 185 previous section the note applies to. These notes are for 186 informational purposes. 188 2. MacIP Protocol Overview 190 MacIP must satisfy requirements imposed by IP, AppleTalk (except 191 where noted), the Macintosh, and the MacIP gateway. 193 2.1. Required Functionality 195 2.1.1. Basic Requirements 197 IP connectivity is required between MacIP hosts embedded in an 198 AppleTalk network, and IP hosts elsewhere on an IP internet. 200 MacIP November 1992 202 [ H1 ] [ H2 ] MacIP Hosts 203 | | 204 +-------+--------+ AppleTalk Net 205 | 206 MacIP GW [ GW1 ] [ IP3 ] IP Host 207 || || 208 ++=======++=====++ IP Ethernet 209 || 210 MacIP Host[ H4 ] [ GW2 ] MacIP GW 211 | | 212 +----------------+ AppleTalk Net 214 Figure 1. Example MacIP Internet 216 There are four different cases to consider in the internet shown in 217 Figure 1. 219 1. Between a MacIP host and an IP Host (H1 and IP3 via 220 GW1). 222 2. Between MacIP hosts on different AppleTalk networks via 223 intervening MacIP gateways (H1 and H4 via GW1 and GW2 ). 225 3. Between MacIP hosts in the same zone connected to the 226 same MacIP gateway (H1 and H2 via GW1). 228 4. Between MacIP hosts in the same zone without a MacIP 229 gateway being present (H1 and H2 directly). 231 Cases 1 and 2 are very similar. Given that MacIP to IP connectivity 232 is established, there is no difficulty supporting MacIP to IP to 233 MacIP. Cases 3 and 4 may appear identical, but are not. Traditional 234 implementations require that MacIP packets must follow the most 235 "efficient" route, and not go through the gateway when the hosts are 236 on the same network. The following is a simple requirement matrix. 238 Local with 239 From/To Local Remote IP Host No Gateway 240 --------------------------------------------- 241 Local | Yes | Yes | Yes | Yes | 242 Remote | Yes | Yes | Yes | - | 243 IP Host | Yes | Yes | - | - | 245 Table 1. MacIP-1 Requirement Matrix 247 MacIP November 1992 249 2.1.2. IP Requirements 251 In order to function as an IP host, a minimum of two things are 252 required: 254 1. An IP Address for the host. 256 2. A means by which to forward packets to the host. 258 With these, an IP host can function on a point-to-point link. In 259 order to function on a broadcast network (such as Ethernet or 260 LocalTalk) the following is also required: 262 3. An Address Resolution scheme (ARP) to resolve IP 263 addresses to native network addresses. 265 4. A subnet mask to allow local and remote routing 266 decisions to be made. 268 5. Gateway address to send off-subnet packets to (more 269 sophisticated routing is sometimes desirable, but not 270 essential). 272 The MacIP protocol can provide all five, although the last two add 273 significant complexity. A variation on ARP provides this 274 functionality. 276 2.1.3. Macintosh Considerations 278 Macintoshes are mobile, and are often moved from one network to 279 another. The AppleTalk protocol handles this automatically without 280 requiring any user reconfiguration of the Macintosh. It would be 281 inconvenient to have to reconfigure the IP Protocol stack under these 282 circumstances. The MacIP protocol provides an automatic IP Address 283 Assignment protocol that can be used to circumvent the requirement 284 for reconfiguration when moved. IP addresses so assigned are called 285 "Dynamic" Addresses. 287 Because Macintoshes often are connected directly to Ethernet, the IP 288 protocol stacks usually support both direct Ethernet and MacIP modes 289 of connection. The MacIP protocol is modular and designed to attach 290 simply to an existing Ethernet implementation. 292 2.2. Protocol Relationships 294 In order to provide the required functions, MacIP has the following 295 relationship to the other protocols in MacIP hosts and gateways: 297 MacIP November 1992 299 MacIP Host MacIP Gateway 300 ------- ------- 301 | TCP | | UDP | 302 +-----+-----+-----+ ---------------------------- 303 | IP |<---->| IP | 304 +-----------------+ +--------------------------+ 305 | MacIP |<---->| MacIP | | Ethernet | 306 +-----------------+ +-----------+ ------------- 307 | AppleTalk |<====>| AppleTalk | 308 ------------------- ------------- 310 Figure 2. MacIP Host and Gateway Connections 312 MacIP acts as a Link-layer protocol to IP, while acting as a client 313 of all the session, transport and network layers of AppleTalk. This 314 should serve to warn readers of the complexities ahead: 316 Layer Name Protocol 317 ------- ------- 318 4 - Transport | TCP | | UDP | 319 +-----+-----+-----+ 320 3 - Network | IP | 321 +-----------------+ 322 2 - Link to IP |.................| 323 5 - Session to | MacIP | 324 AppleTalk +-----+-----. | 325 4 - Transport | ATP | NBP |_____| 326 3 - Network | AppleTalk - DDP | 327 2 - Link | AppleTalk - LAP | 328 ------------------- 330 Figure 3. Relation Between IP and MacIP 332 [Phil doesn't like the above diagram. Shall it go in the appendix?] 334 2.3. Protocol Mapping 336 MacIP uses the zone-wide protocol NBP to perform the ARP function. 337 This makes for a very simple ARP implementation on a Macintosh as 338 most of the code is already built in to the operating system. It 339 does lead to the following unfortunate restrictions: 341 1. There has to be one MacIP gateway per zone, 343 MacIP November 1992 345 2. There can't be more than one MacIP gateway per zone, and 347 3. MacIP hosts can't use a MacIP gateway in a "remote" 348 zone. 350 There have been many attempts to overcome the above restrictions, but 351 they are all "outside" of MacIP-1 and cause problems of their own. 353 2.4. MacIP Functions and Services 355 MacIP provides address assignment, address resolution and packet 356 transport services. 358 2.4.1. Address Assignment 360 The MacIP gateway contains an Address-Assignment module which is 361 configured with a set of IP addresses to assign to MacIP hosts. The 362 module advertises its presence on the network with NBP registration, 363 lookup, and confirmation. The MacIP gateway is discovered by a MacIP 364 host during the initialization of the MacIP host's protocol stack, 365 then an IP address can be requested and granted. MacIP also allows 366 for a MacIP host to be assigned a fixed or "Static" IP address within 367 a range of addresses known to the MacIP gateway. 369 2.4.2. Address Resolution 371 Ethernet-connected IP hosts use the Ethernet Address Resolution 372 Protocol (ARP) to discover the hardware address corresponding to a 373 required IP address. The AppleTalk NBP protocol provides similar 374 capabilities and is used to implement the address resolution function 375 in MacIP. This is referred to as NBP ARP. 377 When any device supporting MacIP acquires an IP address, it registers 378 it through its local NBP process. It is then visible to NBP ARP 379 requests from other MacIP devices. There is the added advantage of 380 possibly discovering configuration errors caused by duplicate IP 381 addresses, as NBP guarantees unique registration within the local 382 zone. 384 With Ethernet ARP, the "working range" of an ARP request is the IP 385 subnet, which corresponds to the "reach" of the Ethernet broadcast 386 packet. With NBP ARP, the "broadcast reach" corresponds to an 387 AppleTalk construct called a "Zone". A zone consists of one or more 388 AppleTalk networks, the actual topology of which is controlled by the 389 network administrator. 391 The zone that the MacIP gateway and the hosts are in is referred to 392 as the "MacIP zone". The zone that a particular device is in is 394 MacIP November 1992 396 referred to as its "local zone". 398 Therefore there is a direct correspondence between an IP Subnet and 399 an AppleTalk Zone for NBP ARP. Unfortunately the same does not apply 400 for the delivery of any other sort of AppleTalk or MacIP packet, as 401 the "broadcast reach" corresponds to a single AppleTalk network. 403 2.4.3. Transport 405 Transport of IP datagrams over LocalTalk is achieved by encapsulating 406 them in Datagram Delivery Protocol (DDP) packets and sending them 407 over an AppleTalk internet. The destination device can be another 408 Macintosh computer supporting MacIP or a gateway. The latter can 409 either be explicitly selected or discovered through a proxy-based 410 process. 412 3. MacIP Protocol Specifics 414 This section describes the MacIP protocol as originally implemented 415 and documented in the Stanford KIP gateway code. This forms the 416 simplest possible version of MacIP, and one which should be supported 417 by all host and gateway implementations. 419 3.1. Gateway Addressing Styles 421 There are two alternative approaches to integrating an AppleTalk 422 network into an IP network. One approach involves treating the 423 AppleTalk network as an IP subnet, with the MacIP gateway assuming 424 the role of an IP router. The alternative is to allocate to the 425 AppleTalk network a small range of addresses "stolen" from the 426 Ethernet IP subnetwork that the MacIP gateway is connected to. In 427 this case, the MacIP gateway forwards IP packets to and from 428 AppleTalk. 430 The forwarding method is conceptually easier, and thus easier to 431 configure. No large range of subnet addresses needs to be calculated 432 and allocated to the AppleTalk network, and no changes need to be 433 made to the rest of the network. 435 The routing method is more difficult conceptually and, hence, harder 436 for an administrator to configure. It is, however, more consistent 437 with the requirements of many large sites, and can be more practical 438 in complicated networks. This is especially true if the MacIP 439 gateway will emit Routing Information Protocol (RIP, [9]) packets to 440 inform the Ethernet network of the MacIP AppleTalk subnet. 442 MacIP gateways conforming to MacIP-1 MAY implement either or both of 443 these styles. This doesn't affect MacIP hosts as they should not be 445 MacIP November 1992 447 able to tell the difference. 449 3.1.1. MacIP Forwarding 451 When forwarding with the MacIP architecture, the AppleTalk network is 452 treated as an extension of the Ethernet IP network. This is done by 453 situating the "MacIP Range" within the range of IP addresses defined 454 by the Ethernet IP network. When a host on the Ethernet ARPs for an 455 IP address which is in the MacIP range, the gateway will answer, 456 performing the proxy ARP function [8]. 458 For example, if the Ethernet has the IP subnet "192.9.200.0", then 459 the MacIP gateway might be configured to assign the addresses 460 "192.9.200.100" through "192.9.200.150" to MacIP hosts. The gateway 461 will respond to ARP requests on Ethernet to all these addresses, plus 462 its own IP address. 464 3.1.2. MacIP Routing 466 Routing via the MacIP protocol is straightforward from the 467 perspective of IP routing. The gateway is configured with two IP 468 addresses and subnet masks, one for the Ethernet and one for the 469 AppleTalk networks. 471 As the MacIP gateway is acting as an IP Gateway (and is thus 472 performing IP routing), it is necessary for the TCP/IP hosts on the 473 Ethernet side of the gateway be informed of the existence of the 474 subnet corresponding to the MacIP Range, and that the MacIP gateway 475 is the gateway to this subnet. This can be done via static routing 476 tables or via the RIP protocol. MacIP gateways MAY provide either a 477 full or conservative (the latter only advertises the MacIP subnet) 478 RIP implementation in the MacIP gateway. 480 3.2. MacIP Initialization 482 3.2.1. Configuration Required For MacIP Hosts 484 The MacIP host requires an IP address for configuration. "Dynamic" 485 or "Static" addresses refer to the method by which the address is 486 acquired. A dynamic address is assigned from the MacIP gateway's 487 address range. A static address is assigned at the MacIP host, then 488 confirmed through the MacIP gateway. 490 3.2.2. MacIP Host Initialization 492 The initialization code is responsible for finding the MacIP 493 gateway's Address Assignment server using NBP, requesting "server" 494 information, acquiring an IP address, either from the address 496 MacIP November 1992 498 assignment service or from a statically-configured address, and 499 registering the MacIP host's IP address with NBP. 501 3.2.2.1. Locating the MacIP gateway's Address Assignment Server 503 The Address Assignment Service in the MacIP gateway [Server] is 504 assumed to have registered itself with NBP with a type of 505 "IPGATEWAY". The MacIP host initialization process uses NBP to 506 search for "=:IPGATEWAY@*", which performs a search for all Servers 507 in the same zone that the MacIP host is in. Under MacIP-1 the 508 implementation assumes that it will only receive one response from 509 one gateway. Multiple gateways in one zone are not covered in MacIP- 510 1. 512 3.2.2.2. Requesting Server Information 514 The MacIP host and the Server exchange information using a protocol 515 called "MacIPGP", described later. The MacIP host can optionally 516 send a MacIPGP SERVER request to the Server, and SHOULD then receive 517 a response packet. The information in the response packet is mainly 518 obsolete and not very useful, although the returned IP Broadcast 519 address might be usable from some gateways. 521 3.2.2.3. Requesting a Dynamic IP Address 523 If the MacIP host is not configured to use a Static IP address, it 524 sends a MacIPGP ASSIGN request to the Server. It will either respond 525 with an appropriate IP address or an error status and optional 526 message which should be displayed to the user. Errors at this point 527 are non-recoverable. 529 3.2.2.4. Registering the IP Address 531 The MacIP host registers its IP address through NBP. It MUST use its 532 IP address in dotted decimal notation as its NBP Name. This 533 representation is the four bytes of the IP address, in network order, 534 in decimal with no leading zeros and separated by periods. For its 535 NBP Type, the string "IPADDRESS" MUST be used. For example, to 536 register the IP address 131.161.1.2, the NBP registration would be 537 "131.161.1.2:IPADDRESS@*". 539 If the registration fails then it is an indication of a duplicate IP 540 address, a gateway, or a network misconfiguration. The failed 541 address MUST NOT be used. This SHOULD be clearly reported to the 542 user. 544 The MacIP host MUST register on DDP socket 72. Some current MacIP 545 gateway implementations assume that the MacIP host is using socket 72 547 MacIP November 1992 549 whether it is or not, so using anything else is not advisable. 551 3.2.2.5 Closing Down 553 When the MacIP protocol stack closes down, it must remove its IP 554 address registration from NBP. 556 3.2.3. Configuration Required For MacIP Gateways 558 A MacIP gateway has to be configured with an IP address, a subnet 559 mask and (possibly) a default gateway. It also needs to be 560 configured with the "range" of IP addresses that are to be allocated 561 to the MacIP hosts so that the gateway can provide address assignment 562 and forwarding service to its MacIP hosts.. The "union of all IP 563 addresses that can be assigned to MacIP hosts and that the MacIP 564 gateway is required to forward packets to" is called the "MacIP 565 Range". Historically, this is a single contiguous range, but 566 implementations are not confined to this. 568 This range contains a "Dynamic" and a "Static" range, either of which 569 may be empty. The "Dynamic" range consists of IP addresses that can 570 be allocated to MacIP hosts on request. The "Static" range consists 571 of IP addresses that can be configured into MacIP hosts that require 572 the same IP addresses all the time. The MacIP gateway will not 573 forward packets to a MacIP host that has an IP address outside of 574 this MacIP range. 576 3.2.4. MacIP Gateway Initialization 578 The initialization code in a MacIP gateway is responsible for setting 579 up certain data structures used by other modules, registering the 580 Address Assignment server and certain IP addresses with NBP, and 581 performing an initial search for already- registered MacIP hosts. 583 3.2.4.1. Proxy ARP Initialization 585 If the MacIP gateway is configured in "forwarding" mode , then the 586 ARP module is initialized to respond to the "MacIP range" of IP 587 addresses in addition to other MacIP gateway addresses. 589 3.2.4.2. Registration of Address Assignment Server 591 The MacIP gateway MUST register itself through NBP, using the type 592 "IPGATEWAY", on DDP socket 72. It is necessary for the registration 593 to be unique in the zone, and early implementations guarantied this 594 by using as the NBP name field (which has to be unique), the dotted 595 decimal representation of their IP address. 597 MacIP November 1992 599 3.2.4.3. Registration of IP Addresses 601 The IP addresses that the MacIP gateway has that are within the MacIP 602 Range SHOULD be registered with the NBP protocol on the gateway in 603 the same way that IP addresses are registered on MacIP hosts. This 604 guarantees that MacIP hosts will not succeed in registering the same 605 address in the same zone. Also, this makes the IP addresses visible 606 to both MacIP hosts (that may wish to send datagrams to these IP 607 addresses) and to network management software. If the registration 608 fails then MacIP MAY not be able to function on the gateway, and 609 appropriate actions should be taken. "Passive Registration" (section 610 5.3.2.1) SHOULD not be used. 612 3.2.4.4. Reregistration Function 614 The MacIP gateway is responsible for assigning unique IP addresses to 615 MacIP hosts. If the gateway has been running, has assigned addresses 616 and is then restarted (or crashes), it is in danger of reassigning 617 the same addresses to other MacIP hosts. In order to recover the 618 previous assignments, the MacIP gateway uses NBP to search for 619 "=:IPADDRESS@*", which will locate all IP addresses registered with 620 NBP ARP in the zone. The NBP responses are directed back to the 621 Initialization module. Those discovered IP addresses that are within 622 the dynamic range assignable by the gateway can be used to initialize 623 the assignment table. 625 It is important that the MacIP gateway attempts to use the same 626 AppleTalk node address after a restart that it had before, as the 627 MacIP hosts will have the node address of the gateway stored in NBP 628 ARP tables and elsewhere. The gateway should not use a "random" node 629 address on restart. 631 3.3. Proxy ARP 633 As mentioned in 4.1.1, when configured to act as a "Forwarding 634 Gateway", the MacIP gateway must perform Proxy ARP for the MacIP 635 Range of addresses. This is simply implemented by adding the MacIP 636 Range to the IP Address(es) that the MacIP gateway's Ethernet ARP 637 process will respond to. All IP addresses in the MacIP range are 638 proxied for, whether there are MacIP hosts using these IP addresses 639 or not as this simplifies the implementation. 641 Proxy ARP MUST be disabled when the MacIP gateway is configured to 642 act as a "Routing Gateway". 644 3.4. NBP ARP - Address Resolution 646 Any MacIP device (host or gateway) can resolve an IP address to an 648 MacIP November 1992 650 AppleTalk address by using NBP to search for the device that has that 651 IP address registered. The name is the requested IP address in 652 "dotted decimal" notation and the type is "IPADDRESS". NBP requires 653 repeat and delay specifications (the number of retries and the delay 654 between them). These should be set particularly leniently, 655 especially considering that MacIP may be running over WANs and/or 656 ARAP (Apple Remote Access Protocol). Recommended values are given in 657 section 10, "Definitions". 659 NBP ARP is functionally very similar to Ethernet ARP, and can often 660 be implemented by using the host or gateway Ethernet ARP code and 661 data structures. Both the MacIP host and gateway are assumed to 662 implement a cache for the addresses resolved by NBP ARP. 664 With Ethernet ARP, the "working range" of an ARP request is the IP 665 subnet, which corresponds to the "reach" of the Ethernet broadcast 666 packet. With NBP ARP, the "reach" corresponds to an AppleTalk 667 construct called a "Zone". A Zone consists of one or more AppleTalk 668 networks, the actual topology of which is controlled by the network 669 administrator. 671 There is therefore a direct correspondence between an IP Subnet and 672 an AppleTalk Zone, but ONLY when performing NBP ARP, and not when 673 routing certain packets such as those to an IP broadcast address, 674 such as might be used by RIP or RWHO. 676 3.4.1. NBP ARP - Details 678 The NBP ARP module is passed an IP address to resolve by the delivery 679 module. Resolution is first attempted by searching for a matching IP 680 address in the local ARP cache. A successful match should reset any 681 usage timers. If a no match is found, then the address has to be 682 searched for. 684 The search on the network is made by using NBP to send an NBP LookUp 685 to all devices in the MacIP zone. The entity-name in the LookUp is 686 the dotted-decimal representation of the IP address (see section 687 6.2.8). The entity type is "IPADDRESS". The entity zone is the MacIP 688 zone. The retry count and time is as specified in section 10. 690 The NBP ARP response carries the AppleTalk address of the 691 destination. The full AppleTalk address (net, node and socket - 692 socket 72 is not to be assumed) must be stored in the ARP cache 693 together with the IP address. 695 3.5. Delivery 697 IP packets including the full IP header MUST be encapsulated in DDP 699 MacIP November 1992 701 packets of type 22 (decimal). The source and destination sockets of 702 the packet are 72 (decimal) by convention. 704 The AppleTalk DDP protocol limits the data size of a DDP packet to 705 586 bytes, which is then the maximum possible Maximum Transmission 706 Unit (MTU) of the AppleTalk network when transporting IP datagrams. 707 The MTU of 576 is more commonly used so as to conform to the minimum 708 IP MTU. 710 The Ethernet network has an MTU size of 1486 bytes. The smaller MTU 711 size of AppleTalk requires that gateways must fragment Ethernet 712 packets bound for AppleTalk which are larger than the AppleTalk MTU 713 [3]. 715 Packets received by the MacIP host MUST be dropped (not processed) if 716 the destination IP address does not match the IP address of the MacIP 717 host. No "IP Broadcast" destination addresses are allowed. This 718 function can be performed either by the Delivery or IP modules. 720 3.6. MacIP Routing Decisions 722 MacIP's design imposes restrictions that renders MacIP hosts 723 incapable of correctly performing IP Broadcasts and of correctly 724 interpreting ICMP Redirects. Both of these features are required in 725 IP implementations. However, current MacIP host implementations do 726 attempt this, so the feature described in the following section was 727 developed. 729 3.7. Gateway NBP Proxy ARP 731 In order to support the simple routing method used by the MacIP 732 client, it is necessary for there to be a service in the MacIP 733 gateway that performs the equivalent of a "Proxy ARP" service, but 734 for all of its MacIP clients. The NBP Proxy ARP service must respond 735 to all NBP ARP requests for all IP addresses EXCEPT for the ones in 736 the MacIP range (those allocated to the MacIP clients). 738 NBP Proxy ARP MUST respond to NBP requests with the IP address being 739 requested, the type "IPADDRESS" and the AppleTalk net, node and 740 socket (72) address of the "Delivery" module. The NBP Proxy ARP 741 module MUST NOT respond to "wildcard" lookups for type "IPADDRESS". 742 NBP Proxy ARP has to be implemented on a "non-standard" NBP 743 implementation described in section 5.3 as "Conditional NBP" (CNBP).. 745 3.8. MacIP Gateway Protocol 747 MacIPGP is a simple request-response protocol based on ATP (AppleTalk 748 Transaction Protocol) ALO (at-least-once) transactions. 750 MacIP November 1992 752 The MacIP host sends an ATP TREQ (ATP Request) packet to the 753 AppleTalk address of the Address Assignment Server, and the MacIP 754 gateway responds with an ATP TRSP (ATP Response) packet. 756 There are two defined functions which MacIP-1 uses. These are "get 757 server info" (SERVER) and "assign IP address" (ASSIGN). 759 3.8.1. SERVER Function 761 The SERVER function returns a list of common server IP addresses, 762 such as name server, file server and the broadcast address. These 763 are usually defined as part of the gateway's configuration and simply 764 passed on via the protocol without interpretation, so their specific 765 contents is not part of the MacIP protocol. Most of these can be 766 considered "obsolete". Their "usual" designation is detailed below. 768 3.8.2. ASSIGN Function 770 The ASSIGN function returns an IP address which can be used by the 771 MacIP host to communicate with other IP hosts. The following is the 772 description of the implementation in the December 1986 KIP code in 773 the "ip.at" document. 775 The gateway is configured with a "Dynamic Range" range of IP 776 addresses and maintains a table of these containing the fields: 778 IP address; timer; flags; AppleTalk address (including socket); 780 When the MacIP Client sends an ASSIGN request to the gateway, the 781 gateway searches the table described above. The service tries to 782 reassign the same IP address to the same AppleTalk address if 783 possible. Otherwise any free IP address is used. If an IP address 784 is available, it is sent in an ASSIGN Reply packet, and the timer 785 field of that table entry will be started. 787 Thereafter, every "Confirm Period" (60 seconds if not configurable), 788 an "echo command"(NBP ARP Confirm) is sent to the client and the 789 timer bumped. Echo replies received will restart the timer. If 5 790 periods pass with no replies received, that table entry will be 791 available for potential reassignment. In making "new" table 792 assignments the timer field is used to locate the oldest unused table 793 entry. This increases the chances of a given MacIP host to keep 794 reusing its previous IP address assignment. 796 It is important to note that IP addresses assigned via the gateway 797 ATP protocol must be registered and resolved using the NBP ARP 798 technique. 800 MacIP November 1992 802 3.8.3. ERROR Response 804 The MacIPGP protocol request return an error if a request other than 805 ASSIGN or SERVER is made. The ASSIGN response may return an error if 806 there are no Dynamic addresses available. 808 3.8.4. MacIPGP Packet Definitions 810 The complete MacIPGP packets consists of: 812 1. Data-link Header, 814 2. DDP Header, 816 3. ATP Header, 818 4. MacIPGP Header, 820 5. MacIPGP Data Packet (only on MacIPGP Response packets). 822 It has the format: 824 0 1 2 3 825 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | | 828 / Data Link Header / 829 | | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | | 832 / DDP Header / 833 | | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | ATP Control | ATP Seq. No | ATP Transaction ID | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | ATP User Bytes - Ignored | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | MacIPGP Request or Response Code | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | | 842 / MacIPGP Data (variable length) / 843 | | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 Figure 6. MacIPGP Packet 848 MacIP November 1992 850 3.8.5. ATP Control Fields 852 The Control Info, Sequence Number and Transaction ID fields are 853 documented in Inside AppleTalk. The MacIP gateway returns these 854 fields as-is to the MacIP host except that the Control Info field is 855 changed from a TREQ to a TRSP. 857 3.8.6. ATP User Bytes 859 These four bytes are unused in MacIP-1 and can be expected to contain 860 random data. 862 3.8.7. MacIPGP Request and Response 864 If the ATP Control info is TREQ, then this is a packet from the MacIP 865 host to the gateway. The MacIPGP Data field is empty (zero length). 866 The defined values of the MacIPGP Request field are: 868 Val. Name Meaning 869 1 ASSIGN Request assignment of Dynamic address. 870 3 SERVER Return Server Information. 871 -1 ERROR Only valid in MacIPGP Response packet. 873 ASSIGN is a request for the MacIP gateway to assign an IP address 874 from its configured "Dynamic Range" to the MacIP host. SERVER is a 875 request for the "Server Information" to be returned. 877 The MacIP gateway normally returns the packet as-is with the MacIPGP 878 Response field in the returned packet set to the MacIPGP Request 879 field in the received packet. If an error occurred, then the Response 880 field is set to "-1" (hex FFFFFFFF) with an optional zero-terminated 881 error string returned in the "Error Message" field. The length of 882 the data field of the returned ATP packet is 64 bytes plus the length 883 of the terminated error string. If the string is empty then 65 bytes 884 are returned. 886 3.8.8. MacIPGP Data Field 888 The MacIPGP Data Field is returned in MacIPGP Response packets. The 889 format is: 891 MacIP November 1992 893 0 1 2 3 894 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Assigned IP Address | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Name Server IP Address | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Broadcast IP Address | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | File Server IP Address | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 |_ Other IP Addresses (16 octets) _| 905 |_ _| 906 |_ _| 907 | | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Error Message (NULL terminated) | 910 / 128 bytes maximum / 911 | | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 Figure 7. MacIPGP Data Field 916 Originally the Name-server, Broadcast, File-server and Other fields 917 were simply copies of configuration data transferred to the MacIP 918 gateway by the AppleTalk Administrative Daemon (atalkad). Their 919 meaning was thus a "private matter" between the administrator and the 920 MacIP host code in use, and did not involve the MacIP gateway at all. 921 It did not interpret or generate the data (except for the Broadcast 922 field which the MacIP gateway does use), it only transferred it. 924 Some manufacturers have changed this simple relationship by using the 925 atalkatab fields for gateway configuration and/or having the gateway 926 generate the data transferred to the MacIP host. Thus, the meaning 927 is unclear, and thus for MacIP-1, undefined. 929 3.8.8.1. Assigned IP Address 931 This is the IP address assigned by the MacIP gateway to the MacIP 932 host. It is only returned in ASSIGN response packets. This field is 933 only valid in ASSIGN response packets. 935 3.8.8.2. Name Server IP Address 937 This historically has been used to contain the IP address of an IEN- 938 116 Domain Name Server. 940 MacIP November 1992 942 3.8.8.3. Broadcast IP Address 944 This may be the Ethernet IP broadcast address which is only 945 "appropriate" for the MacIP hosts if the MacIP gateway is configured 946 in "Forwarding" mode. If it is in "Routing" mode, this field could 947 be anything. MacIP hosts MUST not rely on this data. 949 3.8.8.4. File Server IP Address 951 Originally the address of EFS (Electronic File Server) included with 952 CAP v4 (Columbia AppleTalk Package). Obsoleted by AUFS. 954 3.8.8.5. Other IP Addresses 956 Available for "private" use between consenting MacIP hosts and MacIP 957 gateway configurations. These may contain the "IPOTHER" fields from 958 the "atalkatab" file, but they may not. 960 3.8.8.6. Error Message 962 If the returned MacIPGP Response code is -1, this may contain a 128- 963 byte maximum null-terminated error message. Otherwise it is a zero- 964 length null-terminated string (one byte of null). 966 3.8.9. Delivery Packets 968 If the Address Assignment Service does not have the same AppleTalk 969 address as the Delivery Module (as returned by NBP Proxy ARP), then 970 it may still receive delivery packets (IP packets of DDP type 22) 971 sent by MacIP hosts disobeying MacIP-1. For backward compatibility, 972 these packets SHOULD be forwarded to the Delivery module. 974 4. MacIP Limitations and Recommendations 976 The specification of MacIP imposes certain basic restrictions on 977 operations of both hosts and gateways, particularly on the allowable 978 network topology. Most MacIP gateway vendors have found different, 979 incompatible, and incomplete methods ways to work around these basic 980 protocol limitations. 982 This specification recommends methods for managing the restrictions 983 on both hosts and gateways. The host recommendations focus on the 984 routing decisions hosts are attempting, and the gateway recommends 985 that MacIP gateways reside on a virtual internal network. This 986 network's zones list contains all zones supported by the MacIP 987 gateway, and provides a more reliable mechanism for NBP ARP. This 988 gateway and topology architecture is referred to as Virtual Internal 989 MacIP (VIM). 991 MacIP November 1992 993 4.1. MacIP Routing Decisions 995 MacIP 1 recommends that the MacIP host perform no IP routing 996 decisions whatsoever. There are many advantages to this requirement: 998 1. It simplifies the MacIP host implementation, 1000 2. It minimizes the network-specific information that has 1001 to be sent to or configured into the MacIP host, 1003 3. It allows for MacIP to be extended so that Hosts can use 1004 the services of a MacIP gateway from "out of zone". 1006 Because of restrictions imposed by the design of MacIP, MacIP hosts 1007 are incapable of performing IP Broadcasts and of correctly 1008 interpreting ICMP Redirects, both of which would be expected of a 1009 full IP implementation. 1011 To be specific, it is mandatory that MacIP 1 Hosts should not do any 1012 routing-related operations and should obey the following: 1014 1. They must use NBP ARP to resolve all IP addresses, no 1015 matter what they are, even IP addresses that may be, or 1016 are manifestly in another IP subnet or network, and 1017 includes any possible broadcast IP addresses. 1019 2. They must ignore all subnet masks, network and subnet 1020 numbers and all possible "default gateway" addresses. 1022 3. They should not send IP Datagrams to either the 1023 AppleTalk or IP address of the Address Assignment Server 1024 (received as the "name" field of the NBP LookUp). 1026 4. They should ignore all ICMP Redirect messages and RIP 1027 packets that they may receive. 1029 The simplest way to disable all off-host routing decisions in an 1030 existing IP (or MacIP) implementation is to set the subnet mask to 1031 "0.0.0.0", and to disable any other "special-case" or error-checking 1032 code that may defeat the intention of this. 1034 The MacIP host code should not assume that the Address Assignment 1035 server and the NBP Proxy ARP module have the same socket address, or 1036 even the same AppleTalk address, as it is permissible for them to be 1037 implemented on different hardware and even on different networks. 1039 4.2. Multiple Gateways in One Zone Limitation 1040 MacIP November 1992 1042 As detailed in section 3.7 (Gateway NBP Proxy ARP), having multiple 1043 MacIP gateways in the same zone will completely prevent MacIP hosts 1044 in that zone from working. The following hacks have been invented to 1045 get around this: 1047 4.2.1. NBP Proxy ARP Directed Port 1049 With this method, the MacIP gateway restricts the operation of NBP 1050 Proxy ARP to requests received from networks connected via particular 1051 physical ports, (usually the LocalTalk port, where the majority of 1052 MacIP hosts usually are). This allows multiple MacIP gateways to 1053 exist in the same zone as long as the network topology guarantees 1054 that there is never more than one MacIP gateway's directed port on 1055 one AppleTalk network. This approach also requires NBP (CNBP) in the 1056 gateway to not answer NBP LookUps for "IPGATEWAY" unless they 1057 originate from the same port that NBP Proxy ARP is enabled on. This 1058 asymmetry plays havoc with network management; devices will be 1059 visible depending on where in the AppleTalk topology devices are 1060 looking from. 1062 4.2.2. NBP Proxy ARP Hop Limit 1064 The DDP Hop Count is available to the NBP Proxy ARP process. It can 1065 refuse to answer any requests from MacIP hosts that aren't zero hops 1066 away (directly connected). This solves some problems at the expense 1067 of restricting the topology. It also will not work if two gateways 1068 share a common network. 1070 4.2.3. Friendly Requests - Dynamic 1072 In this method, the NBP Proxy ARP module will only answer requests 1073 from the SAME MacIP hosts that the Address Assignment module knows 1074 about. The source AppleTalk address of the incoming NBP ARP is 1075 compared against all entries in the Assigned Address table. If the 1076 AppleTalk address is present (and the MacIP host is not registering 1077 its own address), then the NBP Proxy ARP module responds. 1079 This fails completely with MacIP hosts that have Static IP addresses, 1080 as they aren't in the in the table. 1082 4.2.4. Friendly Requests - Static 1084 Various methods have been used to force friendly requests to work 1085 with static hosts. In all cases the gateway has to somehow record the 1086 AppleTalk addresses of MacIP hosts with static addresses. This table 1087 has to be filled with periodic "Reregistration" calls (3.3.4.4), or 1088 "directed wildcard NBP ARP" calls have to be issued to "suspected 1089 hosts". VIM provides a superior solution. 1091 MacIP November 1992 1093 4.2.5. NBP Proxy ARP Not Required 1095 If the MacIP host disobeys MacIP-1 and sends all packets to the MacIP 1096 gateway then NBP Proxy ARP may not be required, but MacTCP (Apple's 1097 MacIP driver for the Macintosh) doesn't allow this. 1099 4.2.6. Other Multiple Gateway Problems 1101 Given a choice of multiple MacIP gateways, MacIP hosts will 1102 invariably pick the worst possible one - the one "furthest away". To 1103 date, MacIP hosts cannot select which MacIP gateway to attach 1104 themselves to. Thus, it is a race condition for NBP responses to 1105 return to the MacIP host. Generally, the first response received is 1106 used. See section y.y.y "Out-of-order NBP" for a discussion. 1108 4.3. Out-of-Zone Limitation 1110 NBP ARP can only work between devices that are in the same zone. In 1111 spite of this, most MacIP implementations try to allow the MacIP 1112 hosts to be in a zone different to that of the MacIP gateway (the 1113 MacIP zone). The problems for the MacIP host in the wrong zone are: 1115 1. Its NBP ARP Registration won't find duplicate IP 1116 addresses, 1118 2. It can't answer NBP ARPs from other MacIP hosts, 1120 3. It can't answer NBP ARPs from the MacIP gateway, 1122 4. The gateway "reregistration" function can't find this 1123 host. 1125 The following "Out-of-Zone-Hacks" have been used in existing 1126 implementations. We none of them, and suggest VIM instead (described 1127 in the next sub-section). 1129 4.3.1. Ask Address Assignment - Dynamic 1131 MacIP hosts that have requested Dynamic IP addresses have their 1132 AppleTalk and IP addresses in the Address Assignment Module's table. 1133 NBP ARP can be modified to check this table. This is a very 1134 incomplete solution as it only solves problem (3) above, while 1135 ignoring (1), (2) and (4). It can't work with Statically-addressed 1136 hosts at all. 1138 4.3.2. NBP ARP Reverse Resolution 1140 To allow Static-IP address MacIP hosts to operate out-of-zone, it is 1142 MacIP November 1992 1144 possible for the MacIP gateway to "listen" for NBP ARPs (as it does 1145 in 4.1.2 Friendly Requests). These may be the Static hosts attempting 1146 to "register" their IP addresses in the zone of the MacIP gateway 1147 (they should do this in order to discover duplicate registration, but 1148 none do). It may be the Static hosts performing NBP ARP in the MacIP 1149 gateway's zone. In either case, if the MacIP gateway doesn't find 1150 the source AppleTalk address in the table, it then sends a "directed 1151 wildcard NBP ARP" to the source AppleTalk address. Any response will 1152 be directed by CNBP to the "reregistration" part of the 1153 Initialization Module, and will serve to register the address for the 1154 next time. 1156 This fails to work for statically addressed hosts that are running an 1157 IP service application. IP service applications tend not to send 1158 unsolicited packets, and thus no address mapping exists, preventing 1159 address resolution. It still doesn't solve problems (1) and (2) 1160 either. 1162 4.3.3. Glean From MacIP Packets 1164 Some Static hosts may default to sending MacIP packets to the MacIP 1165 gateway. The IP to AppleTalk address mapping can be "gleaned" from 1166 these packets. There are two problems here. Firstly it is 1167 computationally expensive to "glean" every MacIP packet. Secondly it 1168 relies on the host sending the packet to the gateway, and not all do. 1169 It doesn't work with hosts running a server application, as they 1170 don't send any gleanable MacIP packets. 1172 Gleaning can partly solve the problem that reregistration can't work 1173 with out-of- zone hosts - the next MacIP packet from the MacIP host 1174 after a gateway restart will update the table. 1176 4.4. Virtual Internal MacIP Recommendation 1178 We recommend that MacIP gateways implement a virtual internal network 1179 that has no physical port associated with it, but has a network range 1180 and zones list. The zone list contains all the zones that MacIP 1181 hosts are going to reside. Then, the MacIP gateway is made visible 1182 in all of those zones by registering itself through NBP to all MacIP 1183 hosts in those zones. If the MacIP Host is not in the same zone as 1184 the MacIP Gateway, then you don't get in. 1186 This simplifies everything back to "Classic 1986 MacIP" which we all 1187 have code for. All existing MacIP host code works, both "in" and 1188 "out-of" zone (because there aren't any out-of-zones). Pretty much 1189 all of the existing MacIP Gateway code should be able to remain "as- 1190 is" as well, and should be straight-forward to document and 1191 instrument. 1193 MacIP November 1992 1195 It is possible to make the "VIM zone list acquisition" automatic. 1196 When a new "MacIP Zone" is found (by a MacIP host trying to 1197 register), the gateway uses RTMP to "poison" the old VIM network 1198 range (let's say it was AppleTalk network 10-10), creates a new VIM 1199 network that overlaps the old one (say network 10-11) with all the 1200 old zones and the new one in it, and then advertises that with RTMP. 1201 Disabling "automatic zone list acquisition" counts as a marketable 1202 "security feature". 1204 We could then optionally add Phil Budne's idea of having MacIP 1205 Gateways search for other MacIP Gateways (using NBP to look for 1206 "=:IPGATEWAY@zzz"), and then send RIP packets to them - we've just 1207 solved all of the tricky "RIP-in-MacIP" problems too. 1209 For the "efficiency purists" who demand "minimum path" delivery 1210 between MacIP hosts that are in different zones, that's now easy to 1211 support too. In this case, NBP Proxy ARP would look in its mapping 1212 table for the IP address in question, and use the mapped AppleTalk 1213 address in the NBP Response's Entity address fields. This 1214 effectivley provides an address translation service, or could be 1215 considered NBP Proxy ARP redirect. 1217 5. AppleTalk Basics and Variations 1219 For those not familiar with AppleTalk, this section gives a very 1220 brief summary of the parts of AppleTalk used by MacIP. The reference 1221 for AppleTalk is "Inside AppleTalk, Second Edition", published by 1222 Addison Wesley. 1224 5.1. AppleTalk Addresses 1226 Devices on an AppleTalk Internet are uniquely identified by a 16-bit 1227 network number combined with an 8-bit node number. These addresses 1228 are handled very similarly to the net and host part of a Class C IP 1229 address. MacIP has no special requirements on AppleTalk addresses. 1231 5.2. AppleTalk Zones 1233 AppleTalk networks are grouped together into named collections called 1234 Zones. This is implemented in the routers responsible for the 1235 network numbers by associating a Zone Name (or list of zones for 1236 extended networks) with each network. Zone names form the user- 1237 visible topology of AppleTalk Internets, hiding the actual network- 1238 level topology. 1240 5.3. Name Binding Protocol 1242 NBP provides registration and location services for named entities 1244 MacIP November 1992 1246 within zones. A service entity begins by attempting to register a 1247 "name" and a "type" with the local NBP software. NBP places the 1248 name:type combination into a local registry, so their nodes may 1249 locate it, and then (with the cooperation of the local router) 1250 broadcasts "LookUp" packets on every network that is associated with 1251 the host's zone. If the name:type is already registered in that or 1252 some other host, a "LookUp Reply" packet will be received by NBP and 1253 the registration attempt fails. Generally, the service will modify 1254 the its name, and re-attempt registration. If no LookUp Replies are 1255 received, then the registration is considered successful. 1257 Once a name:type is registered, NBP will answer searches made by 1258 other devices for that name:type, and will supply the AppleTalk 1259 address (net:node:socket) of the registered entity. Wildcard LookUps 1260 are permitted on both the name and type fields. 1262 5.3.1. Strict NBP 1264 The previously-described NBP is the type implemented by the Macintosh 1265 Computer OS. It is characterized by "Active NBP Registration" where 1266 NBP always performing a "uniqueness-search" on registration, and 1267 "Unconditional NBP Replies" where NBP unconditionally answers all NBP 1268 LookUps that match registered entities. 1270 5.3.2. Loose NBP 1272 There are a lot of ways to abuse NBP and to step outside the purposes 1273 for which it was written. The following are some of the ways that 1274 have been found to abuse it, collectively called "Loose NBP". The 1275 problems caused are mainly those of confusion, both to network 1276 managers and to network management software. 1278 5.3.2.1. Passive NBP Registration 1280 Some NBP implementations perform "Passive NBP Registration" by 1281 skipping the "uniqueness search". For the case of registering single 1282 unique entities this can only be described as poor practice, as it 1283 will fail to detect duplicate registration. It may also confuse 1284 network managers who are monitoring the device to see if it is 1285 working properly. 1287 In the case of implementing NBP Proxy ARP it is impractical to 1288 "Actively Register" the 4,261,412,864 IP addresses that the MacIP 1289 gateway is proxying for. 1291 5.3.2.2. Conditional NBP Replies 1293 NBP can also be abused to allow "Conditional NBP Replies" (CNBP) 1295 MacIP November 1992 1297 where the generation of the NBP LookUp Reply does not depend solely 1298 on the contents of the local NBP Registry, but depends on the 1299 requesting device, or the particulars on what is being asked for. 1300 This isn't possible on a Macintosh as NBP is built into the OS. Again 1301 NBP Proxy ARP requires this. 1303 5.3.2.3. Out-of-order NBP 1305 A packet monitor observing an NBP transaction would expect to see the 1306 following operations in the following order, and may in fact depend 1307 on the order to correctly report the operation: 1309 1. MacIP host wishing to search for a particular named 1310 entity within its own zone sends NBP BrRq (Broadcast 1311 Request) to a local AppleTalk router, 1313 2. The router rebroadcasts the NBP Query as an NBP LkUp 1314 (LookUp) on all networks in the requested zone, 1316 3. One or more LkUp Replies are sent from the searched-for 1317 entity to the requesting host. 1319 In the case of a MacIP host searching for a MacIP gateway there 1320 exists a serious problem. The router that the MacIP host sent the 1321 NBP BrRq to is likely to be the most appropriate MacIP gateway. 1322 However while this router/gateway is busy performing step (2) above, 1323 other MacIP gateways in the same zone are likely to be on step (3). 1324 Current MacIP host code will use the first LkUp Reply and will thus 1325 select the inappropriately "remote" gateway. 1327 If the first router reverses steps (2) and (3) above, replying to the 1328 request before rebroadcasting it, then the MacIP host will select it. 1329 It looks weird on a packet monitor though. 1331 5.3.2.4. Port Hopping 1333 NBP is intended to allow a client to search for a service by name, 1334 and to discover the network address which will be used for the 1335 delivery of subsequent datagrams. In the case of a multi-port 1336 service-provider, it is sensible to return the "nearest" AppleTalk 1337 address to the client, in this case the address of the port that the 1338 NBP Reply was returned to the client through. Unfortunately this 1339 port (and address) may not be in the zone that the request was 1340 originally made in. This causes no problems apart from confusion to 1341 network managers again, and should probably be avoided for this 1342 reason. 1344 5.4. DDP 1345 MacIP November 1992 1347 The Datagram Delivery Protocol is close to the AppleTalk equivalent 1348 of UDP/IP. It implements an "unreliable" Datagram Delivery service, 1349 with the destination address being a socket at a specific net:node 1350 address. DDP packets also have a "type" field which permits another 1351 level of multiplexing on top of the socket multiplexor, but is often 1352 used redundantly with the socket. 1354 5.5. ATP 1356 The AppleTalk Transaction Protocol adds a request/response/timeout 1357 and retry mechanism on top of DDP packet delivery. Transactions 1358 commence with an ATP Request packet (TREQ) and must be answered by an 1359 ATP Response (TRSP) or the requestor will retry and eventually time 1360 out and report back an error to the client. 1362 6. Definitions 1364 6.1. AppleTalk Protocol constants 1366 MacIP MTU 576 bytes 1368 DDP constants 1369 MacIP packet type 22 (decimal) DDP 1370 ARP packet type 23 (decimal) 1372 DDP ARP constants 1373 AppleTalk address type 3 (decimal) 1375 NBP constants 1376 gateway object type IPGATEWAY registered IP 1377 address object type IPADDRESS LookUp retransmit 1378 count 4 tries LookUp retransmit interval 5 1379 seconds 1381 6.2. Gateway ATP Protocol Constants 1383 ATP Protocol Constants 1384 ATP retransmit count 4 tries ATP retransmit 1385 interval 5 seconds 1387 ATP request command codes 1388 ASSIGN assign IP address 1 NAME name 1389 server 2 (obsolete) SERVER get server 1390 info 3 1392 ATP response codes 1393 SUCCESS same as request code 1394 ERROR -1 1396 MacIP November 1992 1398 7. Glossary 1400 MacIP 1401 The encapsulation protocol and associated services. 1403 MacIP-1 1404 The original MacIP specification as implemented in the KIP code. 1406 MacIP-2 1407 A future version of MacIP that will allow out-of-zone and 1408 multiple-gateway operation. 1410 MacIP Host 1411 A device implementing the host-side of the MacIP protocol, 1412 usually an Apple Macintosh computer. 1414 MacIP Gateway 1415 A device implementing the gateway-functions of the MacIP 1416 protocol. It converts between the MacIP transport-layer and 1417 those used by the other IP hosts, as well as provides other 1418 server-type functions. 1420 IP Host 1421 An IP host on an IP internet, usually not using MacIP, but with 1422 which MacIP hosts can communicate. 1424 MacIP Packets 1425 IP datagrams encapsulated in AppleTalk packets that are sent 1426 between the "Delivery" modules in MacIP hosts and gateways. 1428 MacIP Network 1429 The collection of MacIP hosts and the MacIP gateway that are in 1430 direct communication with each other - similar to the concept of 1431 an IP Subnet. 1433 MacIP Range 1434 The range of IP addresses configured into a MacIP gateway that 1435 are considered to belong to the MacIP hosts. 1437 MacIP Dynamic Range 1438 The IP addresses in the MacIP range that are available for 1439 automatic assignment to MacIP hosts by the gateway MacIPGP 1440 module. 1442 Dynamic Address 1443 An IP address assigned by a MacIP gateway from its Dynamic range 1444 for the use of a MacIP host. 1446 MacIP November 1992 1448 MacIP Static Range 1449 The IP addresses in the MacIP range that are available for 1450 permanent assignment to MacIP hosts by the system administrator. 1452 Static Address 1453 A fixed IP address assigned by the system administrator to a 1454 MacIP host. This address must be in the MacIP Static range of 1455 the host's MacIP gateway. 1457 MacIP Zone 1458 The AppleTalk zone that the MacIP gateway is situated in, and 1459 which corresponds to the "reach" of the NBP ARP function. 1461 Local Zone 1462 The AppleTalk zone that a MacIP host is in. 1464 MacIP Routing Mode 1465 The MacIP gateway configuration where the MacIP network IP 1466 addresses are in a different subnet to that of the IP backbone, 1467 and where the MacIP gateway is acting as an IP router. 1469 MacIP Forwarding Mode 1470 The MacIP gateway configuration where the MacIP network IP 1471 addresses are in the same subnet as the IP backbone, and where 1472 the MacIP gateway is performing Proxy ARP for the MacIP hosts. 1474 In-Zone Mode 1475 The MacIP host configuration where the host is in the same zone 1476 as the MacIP gateway (the MacIP zone is the same as the Local 1477 zone). 1479 Out-of-Zone Mode 1480 The MacIP host configuration where the host is in a different 1481 zone to the MacIP gateway (the MacIP zone is not the same as the 1482 Local zone). 1484 MacIPGP 1485 The MacIP Gateway Protocol. Used to implement the address 1486 assignment service, and to forward other information. 1488 NBP ARP 1489 Method for resolving an IP address into an AppleTalk address. 1490 Equivalent to Ethernet ARP. 1492 NBP Proxy ARP 1493 Method by which the MacIP gateway answers NBP ARP requests for 1494 IP addresses of IP hosts. 1496 MacIP November 1992 1498 NBP ARP Forwarding 1499 Method by which the MacIP gateway forward NBP ARP requests to 1500 MacIP hosts that ore located outside of the MacIP zone. 1502 Proxy ARP 1503 Method by which the MacIP gateway responds to Ethernet ARP 1504 requests from IP hosts for IP addresses in the MacIP range. 1506 VIM 1507 Virtual Internal MacIP. This refers to the proposed new MacIP 1508 gateway architcture. The gatweway implements an internal, 1509 virtual network, and associates itself with it. If the internal 1510 network's zones list contain more than one zone name, the MacIP 1511 gateway registers itself on all of them, providing gateway 1512 services to all MacIP hosts in those zones. 1514 8. Implementation Notes 1516 This section provides notes and insights to the reader. Its sections 1517 numbers are organized to follow the preceding section numbers. 1519 8.1.2 Intended Audience 1521 It should be noted that members from the various groups mentioned 1522 (host implementors, gateway implementors, system managers, and the 1523 curious) have different preconceived notions about what comprises a 1524 MacIP protocol system. Also, what is acceptable functionality in 1525 undocumented limitations will differ between these groups, and 1526 between members of the groups themselves. Careful attention must be 1527 paid to the fact that TCP/IP is not AppleTalk, and AppleTalk is not 1528 TCP/IP. There are some similarities that are close enough to conceal 1529 the important differences. NBP is nothing like DNS. RIP is 1530 different from RTMP. UDP isn't DDP. Mapping one protocol system to 1531 another presents a significant challenge, and that is what we're 1532 attempting with MacIP. It is very easy for things to go very wrong. 1534 8.2.1.1 Basic Requirements 1536 Implementing MacIP so as to fulfill this requirement as well as the 1537 local with no gateway requirement (which is very rarely used in 1538 practice) is one of the things that makes the protocol so complex. 1540 8.2.3. Protocol Mapping 1542 MacIP follows NBP ARP. The following are two obvious ways to "map" 1543 IP onto AppleTalk at the transport level, but are not followed. 1545 NBP ARP is used instead. This combines some of the worst features of 1547 MacIP November 1992 1549 "Direct Mapping" and "Server Client" without sufficient advantages to 1550 offset it. It also complicates implementation, documentation and 1551 installation. But we're stuck with it. 1553 8.2.3.1. Direct Mapping 1555 MacIP provides very similar capabilities to Ethernet and Ethernet 1556 ARP, so one possible protocol mapping would be to treat each 1557 AppleTalk network as an IP subnet, with IP addresses within each 1558 subnet being resolved by an equivalent network-wide broadcast 1559 protocol to Ethernet ARP. All routing would be performed by the 1560 MacIP gateways, although the hosts would be required to perform 1561 "this- subnet" type routing decisions. 1563 This was actually implemented early on in the history of MacIP. It 1564 has many advantages. It satisfies the "requirement matrix" of 2.1.1 1565 and its similarity to IP makes it easily understandable and 1566 documentable. The downside is that it requires every AppleTalk 1567 router in an Internet to also be an IP router This complicates the 1568 configuration of an Internet and also consumes IP address space at an 1569 alarming rate. This isn't MacIP-1. 1571 8.2.3.2. Client-Server 1573 An approach leading to a very simple implementation would be a strict 1574 client- server one, such as the protocols that are already used to 1575 implement DECnet, LAT and SNA services over AppleTalk. MacIP hosts 1576 would use NBP to find the gateway(s) and then establish a "session" 1577 which would allow the gateway to record the AppleTalk address of the 1578 host so it would know how to route a packet back to them. 1580 Advantages would be the ease of implementation, documentation and 1581 debugging. The MacIP hosts wouldn't have to know anything about 1582 routing - they would send all packets to the gateway. It would also 1583 allow MacIP hosts that are anywhere on a large and complex AppleTalk 1584 Internet to use a gateway no matter where it was - there would only 1585 need to be one gateway. It would allow operation across AppleTalk 1586 zones. The downside is that all traffic between two MacIP hosts on 1587 the same network would have to pass through the gateway, and that the 1588 gateway would be required for the protocol. This isn't MacIP-1 1589 either, much the pity. 1591 8.2.4.4. MacIP Routing Decisions 1593 8.2.4.4.1. Routing in Standard IP Hosts 1595 An IP host on a single point-to-point link only has one simple 1596 routing decision to make when presented with an IP packet to forward: 1598 MacIP November 1992 1600 1. Is the destination IP address equal to my IP address? 1602 If it is, the packet is sent "inwards". If not, it is sent out the 1603 link. An IP host connected to single broadcast medium has another 1604 two questions to answer: 1606 2. Is the destination address within "this" network/subnet? 1608 If it is, the packet can be sent "directly" to the destination. If 1609 it isn't, then the packet has to be sent via a gateway, often a 1610 single "default gateway", the IP address of which is known. 1612 3. Is the destination address a Broadcast address? 1614 In all cases ARP is used to resolve the selected IP address to a 1615 hardware address. In case (3), ARP will substitute the appropriate 1616 configured hardware broadcast address. 1618 8.2.4.4.2. Routing in MacIP Hosts 1620 This "broadcast medium behavior" is insufficient for MacIP, as the 1621 Address Assignment protocol sensibly and deliberately provides 1622 neither the subnet mask nor default gateway information. This 1623 behavior should not be defeated (by allowing manual entry of the 1624 data) as it defeats the Macintosh "plug and play" requirement. 1626 Even if Address Assignment did provide this information, the 1627 disparity between the "reach" of NBP ARP and normal DDP broadcast 1628 datagrams prevents a MacIP host from broadcasting an IP datagram to 1629 all hosts in the zone. This is strictly not "required" by IP, but it 1630 is certainly "expected" by some applications. 1632 MacIP hosts SHOULD never perform any routing. This includes anything 1633 to do with subnet masks, broadcast addresses, default gateways, RIP 1634 or ICMP redirects. 1636 8.3.2. MacIP Modules - Introduction 1638 MacIP can be best understood and described if the various functions 1639 are categorized into functional modules. 1641 The following gives the relationship between the IP , MacIP and 1642 AppleTalk modules in the MacIP host: 1644 MacIP November 1992 1646 ...................................... 1647 : IP Protocol Layer : 1648 :.......... | ............. | .......: 1649 | | 1650 ........... | ............. | ........ 1651 : ---------+-------- ------+------ : 1652 : | Initialization | | Delivery | : 1653 : ----+---------+--- -+--+-------- : 1654 : | | | | : 1655 : ----+---- ---+-----+- | MacIP : 1656 : | MIPGP*| | NBP ARP | | Protocol : 1657 : ----+---- -----+----- | : 1658 :..... | ......... | .... | .........: 1659 | | | 1660 ...... | ......... | .... | .......... 1661 : ----+---- -----+---- | : 1662 : | ATP | | NBP | | AppleTalk: 1663 : ----+---- -----+---- | Protocol : 1664 : | | | : 1665 : ----+-----------+------+-------- : 1666 : | DDP (Datagram Delivery Proto)| : 1667 : ----------------+--------------- : 1668 : | : 1669 : ----------------+--------------- : 1670 : | LAP (Link Access Protocol) | : 1671 : ----------------+--------------- : 1672 :................. | ................: 1673 | 1674 .................. | ................. 1675 : AppleTalk Hardware : 1676 :....................................: 1677 (*) "MIPGP" is short for "MacIPGP". 1679 Figure 4. MacIP Host Implementation 1681 The following gives the relationship between the IP , MacIP and 1682 AppleTalk modules in the MacIP gateway: 1684 MacIP November 1992 1686 ......................................................... 1687 : IP Protocol Layer +-----( IP Router )----+ : 1688 :.......... | ............. | .................... | ...: 1689 | | | 1690 ........... | ............. | .................. | 1691 : | | : | 1692 : ---------+-------- ------+------ MacIP : | 1693 : | Initialization | | Delivery | Protocol : | 1694 : ----+------+------ --------+-+-- : | 1695 : | | | | : | 1696 : ----+----- | ------------- | | --------- : | 1697 : | Assign | | | NBP Proxy | | | | Proxy | : | 1698 : ----+--+-- | ------+------ | | | ARP | : | 1699 : | \__|___ | | | ----+---- : | 1700 : | | \ | / | | : | 1701 : ----+---- | ---+--+-----+-- | \ : | 1702 : | MIPGP | | | NBP ARP | | | : | 1703 : ----+---- | ---+----------- | | : | 1704 : | | | | | : | 1705 :..... | .... | .. | .......... | ........ | ..: | 1706 | | | | | | 1707 ...... | ..... \ . | .......... | .... .. | ..... | .... 1708 : | | | | : : | | : 1709 : ----+---- --+--+---- Apple- | : : | ------+-- : 1710 : | ATP | | CNBP * | Talk | : : | | Ether | : 1711 : ----+---- -----+---- | : : | | Proto | : 1712 : | | | : : | --+--+--- : 1713 : ----+-----------+------------+-- : : \ | \ E : 1714 : | DDP (Datagram Delivery Proto)| : : --+-+-- | t : 1715 : ----------------+--------------- : : | ARP | | h : 1716 : | : : ---+--- | e : 1717 : ----------------+--------------- : : | | r : 1718 : | LAP (Link Access Protocol) | : : | | n : 1719 : ----------------+--------------- : : | | e : 1720 : | : : | | t : 1721 :................. | ................: :.... | ... | ..: 1722 | | | 1723 .................. | ................. ..... | ... | ... 1724 : AppleTalk Hardware : : Ether Hardware: 1725 ...................................... ................. 1726 (*) "CNBP" is "Conditional NBP". See section 8.3 for details. 1728 Figure 5. MacIP Gateway Implementation 1730 8.3.2.1. Configuration Required For MacIP Hosts 1731 MacIP November 1992 1733 The terms static and dynamic SHOULD be used consistently in the user 1734 interface. 1736 If the host has multiple MacIP and/or IP interfaces, then a mechanism 1737 is required to allow selection between them. It is important to 1738 distinguish plainly between MacIP- based and "Native" IP connections. 1740 8.3.2.2.1. Locating the MacIP gateway's Address Assignment Server 1742 The implementation SHOULD not take any notice of the returned NVE 1743 name field in the NBP response. However, it should be noted that 1744 many implementations expect to find the IP address corresponding to 1745 the Server in dotted decimal format. 1747 The implementation SHOULD record the full AppleTalk address returned 1748 in the NBP response (including the returned socket) and use it in 1749 subsequent transactions with the Server. It SHOULD not simply assume 1750 that the Server is on DDP socket 72. However, there are many existing 1751 implementations that make this assumption. 1753 8.3.2.4.2. Registration of Address Assignment Server 1755 Unfortunately many MacIP host implementations wrongly rely on the 1756 name being an IP address, so for compatibility with these the use of 1757 the IP address as the name is "recommended". A simple two-port MacIP 1758 gateway configured in "forwarding" mode may only have one IP address 1759 to use for this purpose, but a multi-IP-port MacIP gateway may suffer 1760 an embarrassment of choices, so the question arises as to which IP 1761 address to use for this purpose. Fortunately this choice can be 1762 narrowed by the existence of bugs in some MacIP host implementations 1763 that can require the name of the Server to be an IP address in the 1764 same "subnet" as the IP address of the MacIP host. Good luck! 1766 8.3.4.1. NBP ARP - Details 1768 The aging of ARP cache entries is required. The mobility of 1769 Macintoshes makes this particularly important. Any algorithm may be 1770 used as long it is at least as good as the following. 1772 Each use of the ARP cache entry should reset a "usage" timer. When a 1773 new entry is to be put into the cache, it might be full (or the 1774 bucket associated with the hashing function might be full). The 1775 entry with the oldest "usage" timer should be the one chosen to be 1776 replaced. 1778 ARP cache entries should be "confirmed" by sending a single NBP 1779 Confirm directly to the AppleTalk address in the cache entry once a 1780 minute. If no response is received after five requests the entry 1782 MacIP November 1992 1784 should be deleted. 1786 The NBP Cache should be capable of being flushed on request by other 1787 modules. 1789 8.3.5. Delivery 1791 If the "Delivery" module experiences a hard error (the packet 1792 transport code cannot transmit the packet, and returns an error) when 1793 attempting to transmit a MacIP packet, then it is recommended that 1794 the NBP ARP cache entry for the destination IP address should be 1795 flushed and the transmit retried. This is to recover from MacIP 1796 gateway restarts where the gateway has picked a different node 1797 address to the one it previously had. 1799 8.3.6. MacIP Routing Decisions 1801 The requirement in section 3.6 that MacIP hosts should always use NBP 1802 ARP for all destination IP addresses is widely disobeyed in actual 1803 practice. Most MacIP host implementations disobey this fundamental 1804 specification, as the requirements of being an IP host were not well 1805 understood at the time. 1807 It is thus expected that some MacIP-1 hosts will send some or all 1808 packets directly to the AppleTalk address of the discovered MacIP 1809 gateway for delivery. However it should be noted that if the MacIP 1810 gateway restarts, it may acquire a different AppleTalk node address 1811 to the one it had prior to the restart. If the host is sending MacIP 1812 packets to the old gateway address, they will not be delivered. The 1813 MacIP host SHOULD take measures to recover from this by following 1814 address cache aging and updating algorithms as discussed in the Host 1815 Requirements RFC [10]. This applies to NBP ARP caches as well. 1817 8.3.7. Gateway NBP Proxy ARP 1819 It is the implementation of this service that causes the most 1820 problems in MacIP. If the NBP Proxy ARP module wrongly responds to 1821 an IP addresses that is assigned to a MacIP host, then the response 1822 from the gateway will look to the host attempting to register its 1823 address as a duplicate registration. 1825 This results in the restriction that with MacIP-1 there must never be 1826 multiple MacIP gateways in the one zone configured with different 1827 MacIP Ranges, as they will defeat registration attempts by MacIP 1828 hosts that have been assigned addresses by another gateway. Then 1829 again, two MacIP gateways can't be configured with the same MacIP 1830 range, as normal IP routing (Routing case) and Proxy ARP (Forwarding 1831 case) would fail to route packets under these circumstances. 1832 Therefore there can't be more than one MacIP gateway in any one zone. 1834 MacIP November 1992 1836 This is the "Multiple Gateways in the One Zone" problems, and will be 1837 addressed later. 1839 8.5.3. Name Binding Protocol 1841 NBP can be though of implementing a form of "zone-wide broadcast". 1842 The only thing that can be broadcast is a search for a named entity - 1843 it is not possible to broadcast data-containing packets. This is 1844 important when considering mapping one network protocol (such as IP) 1845 onto an AppleTalk Internet. 1847 It is not possible to discriminate a "registration attempt" NBP 1848 LookUp from a "searching for" one. This makes the implementation of 1849 NBP Proxy ARP far more difficult than you would first suspect. 1851 9. Issues 1853 9.1 IP Routing Issues 1855 Phil pointed out that we didn't discuss IP hop count or checksum 1856 issues. Since we are subject to rfc1122 (naturally), should we still 1857 discuss it? Furthermore, what do y'all think of bumping [or not 1858 bumping] the hop count if we are just in 'forwarding mode'? 1860 Also, Phil asked if forwarding gateways need to intercept ICMP 1861 redirects. IP routers must ignore all ICMP redirects, as they're 1862 meant to have their routing tables updated by a "more reliable" 1863 method. Thus, all ICMP redirects MUST be ignored by the gateway, and 1864 MacIP hosts SHOULD ignore all ICMP redirects too. Should this go 1865 into this document? Where? 1867 9.2 More Hacks 1869 Jonathan described the following additional 'hacks'. Should they be 1870 in this document, and if so, where? 1872 (1) The EtherGate has one ethernet port and 2 localtalk ports. We 1873 doclient IP address assignment out of a single range of addresses for 1874 both localtalk ports. This means that besides it's usual 1875 weirdnesses, we had to make NBP-proxy-ARP work across both localtalk 1876 ports if they're in different zones. When a Mac tries to confirm 1877 that it can use its IPADDRESS the EtherGate forwards the NBP Lookup 1878 to the other port and changes the zone name. Yuck. 1880 (2) When the EtherGate receives an NBP-ARP for an IPADDRESS not in 1881 its client range and on the same (sub)net as the EtherGate itself, it 1882 IP ARPs on the ethernet side to see if it can reach the IP host 1883 before responding on the NBP side. 1885 MacIP November 1992 1887 Would someone with a good familiarity of Proxy ARP routers like to 1888 contribute - there may be some good practice in existing Proxy ARP 1889 routers that we can adopt, copy, steal documentation from etc. 1891 One last note, I assume the implementation notes will include hints 1892 for the host (Mac client) implementor as well as the gateway 1893 implementor? We should clearly point out pitfalls and suggestions 1894 for both! 1896 Any host-implementors like to contribute a few paragraphs? 1898 9.3 MacIP Host Recommendations - Another Idea 1900 From: Tom Evans 1902 The MacIP _HOST_ doesn't need a "session" with anything. 1904 Q. What is this "session" actually FOR? 1906 A. It is established at MacIP Host startup for the sole purpose of 1907 getting a Dynamic IP Address assigned. 1909 Q. Does the MacIP Host have to MAINTAIN the "session" with the 1910 Address Assignment Service? 1912 A. NO. 1914 Q. What is the ADDRESS of the IPGATEWAY? 1916 A. I've been reading Radia's "Interconnections" too. By her 1917 definition in section 2.3, an AppleTalk "address" doesn't fit her 1918 definition of an "address". The node-part of an AppleTalk address 1919 CHANGES. 1921 So the "address" of the IPGATEWAY starts out as its NAME, which is 1922 initially "=:IPGATEWAY@*" ("any gateway"). The MacIP Host picks a 1923 particular one (which is now "aa.bb.cc.dd:IPGATEWAY@*"), which fits 1924 the definition of a NAME (but has an IP ADDRESS embedded in it). 1925 This is the only real "fixed" representation of the "address". The 1926 AppleTalk address MAY CHANGE, so it shouldn't be stored. If the 1927 IPGATEWAY is required for some reason, it should probably be searched 1928 for again at the time that it is needed. 1930 The IP Address ("aa.bb.cc.dd" above) is a better "fixed address" than 1931 the AppleTalk address is. It can be resolved to an AppleTalk address 1932 when required by existing (NBP ARP) code. 1934 Q. "My code treats IPGATEWAY as a "default IP gateway", so I have to 1936 MacIP November 1992 1938 keep its address". 1940 A. XXXXXXXXXXX (removed by censors). Nothing else that I know of in a 1941 Mac stores AppleTalk addresses - they're too volatile. The 1942 LaserWriter driver stores the NAME of the printer. The AppleTalk 1943 address "A_Router" stored by any Mac is never more than 40 seconds 1944 old. ASP sessions store the AppleTalk address, but they're 1945 continuously maintained sessions that tell you when they break. 1947 The logical thing to do is to store the MacIP Gateway's IP Address 1948 and NOT its AppleTalk Address. This will make a lot more sense in the 1949 host's existing IP Routing table after all. No "special case MacIP 1950 code" required in the IP layer. 1952 Use NBP ARP to resolve ALL IP addresses passed down from the IP 1953 layer, including the one for the Default Gateway. The ARP/NBP-ARP 1954 code should have timeouts and confirmation. This will recover nicely 1955 if the IPGATEWAY changes its AppleTalk address, which it is "allowed" 1956 to do. 1958 Q. How does the MacIP Gateway keep ITS session information (required 1959 for NBP Proxy ARP)? 1961 A. By REREGISTRATION at gateway startup, by answering MacIPGP 1962 requests, by "tickling" them thereafter and by "probing" suspected 1963 "clients" that it receives NBP ARP requests from. It isn't the MacIP 1964 Host's problem. 1966 So the MacIP Host shouldn't keep any information that it doesn't need 1967 to, and thus it shouldn't be in the MIB. If it is, then it should be 1968 the IP address that is stored and not the AppleTalk address. 1970 Of course the above seems to be contradicted in the MacIP doc in 1971 sections 5.2.5 and 6.2 where it says that the MacIP Host should be 1972 able to receive multiple IPGATEWAY responses and then choose the 1973 "best" one. However, once the MacIP Host HAS an IP address, it 1974 doesn't need the Address Assignment Server anymore, and it should 1975 probably throw all the information away. So if the multiple gateway's 1976 addresses WERE accessible via SNMP, then they'd only be there for 1977 less than a second. 1979 10. Acknowledgments 1981 Bill Croft, for the initial implementation of this protocol in the 1982 SEAGATE gateway at Stanford University and for the documents provided 1983 with the KIP code. 1985 Gaige Paulson and Tim K., for the NCSA Telnet source code. 1987 MacIP November 1992 1989 John Romkey, for the original PC/IP source code. 1991 Tim Maroney and ?, for the port of PC/IP to Macintosh. 1993 Jeannine Smith for TCP and UDP in MacTCP, and John Veizades and his 1994 team for the rest. 1996 Brad Parker and Josh Littlefield. This document is directly based on 1997 theirs written in February 1990. 1999 John Veizades, for a version of this document and for being the Chair 2000 of the Apple- IP working group. 2002 11. References 2004 [1] Sidhu, G., Andrews, R., and Oppenheimer, A., Apple 2005 Computer, "Inside AppleTalk, 2nd. Edition" Addison-Wesley 2006 Publishing Company, Inc., Reading, MA, May, 1990. 2008 [2] Postel J., "Internet Protocol", RFC-791, USC Information 2009 Sciences Institute, September 1981. 2011 [3] Plummer, D., "An Ethernet Address Resolution Protocol", 2012 RFC-826, Symbolics, September 1982. 2013 [4] Hornig, C., "Standard for the transmission of IP datagrams 2014 over Ethernet", RFC-894, Symbolics, April 1984. 2016 [5] Mogul, J., "Internet Subnets", RFC-917, Stanford 2017 University, October 1984. 2019 [6] Mogul, J., and Postel, J., "Internet Standard Subnetting 2020 Procedure", RFC-950, Stanford University, August 1985. 2022 [7] Brandon, R., and Postel, J., "Requirements for Internet 2023 Gateways", RFC-1009, USC Information Sciences Institute, June 2024 1987. 2026 [8] Carl-Mitchell, S., Quarterman, J.S., "Using ARP to 2027 Implement Transparent Subnet Gateways", RFC-1027, October 1987. 2029 [9] Hendrick, C., "Routing Information Protocol", RFC-1058, 2030 June 1988. 2032 [10] Braden, R.T., ed, "Requirements for Internet Hosts", RFC- 2033 1122, October 1989. 2035 MacIP November 1992 2037 12. Expiration Date 2039 This Internet Draft will expire in May 1993. 2041 13. Security 2043 This document does not discuss security in any manner. 2045 14. Contact Points 2047 The Apple-IP working group can be contacted by emailing the following 2048 address: 2050 apple-ip@cayman.com 2052 The Apple-IP Working Group Chairperson is: 2054 John Veizades 2055 Apple Computer 2056 Cupertino, CA 2057 (408)974-2672 2059 EMail: veizades@apple.com 2061 The author's addresses are: 2063 Tom Evans 2064 Webster Computer Corporation 2065 1270 Ferntree Gully Rd 2066 Scoresby Melbourne 2067 3179 Victoria, Australia 2068 61-3-764-1100 2070 EMail: tom@wcc.oz.au 2072 Christopher S. Ranch 2073 Novell, Inc. 2074 2180 Fortune Drive 2075 San Jose, CA 95131 2076 (408)473-8667 2078 EMail: cranch@novell.com