RFC 1504

Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing

📅 published August 1993, from ietf

Status of This Memo 📄

Okay, quick header check, bestie 🎀 This is RFC 1504, Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing 💖. It's from the Network Working Group, written by A. Oppenheimer at Apple Computer, dated August 1993 🌸. The header doesn't list anything it obsoletes or updates, so there's nothing to track there ✨

This memo is just here to give info to the Internet community. It is not an Internet standard, and distribution is unlimited, so share away 🦋

Introduction 🫶

This memo is going out to the Internet community to fully document an Apple protocol that might be running over the Internet 🌈 The issues here might not be directly about the Internet's research problems, but researchers and implementers could still find them super interesting 🧚

About This Document 💅

Okay so this doc is all about the AppleTalk Update-based Routing Protocol (AURP) and wide area routing 🌍 AURP adds wide area routing enhancements to the AppleTalk routing protocols, and it's fully compatible with AppleTalk Phase 2. It's literally giving organized 📚 The doc is built around the three major components of AURP:

AppleTalk tunneling, which allows AppleTalk data to pass through foreign networks and over point-to-point links 🚇
the propagation of AppleTalk routing information between internet routers connected through foreign networks or over point-to-point links 🦋
the presentation of AppleTalk network information by an internet router to nodes and other Phase 2-compatible routers on its local internet 💜

What This Document Contains 🍓

Here's the tea on each chapter 🫖

Chapter 1, "Introduction to the AppleTalk Update-Based Routing Protocol," introduces the three major components of AURP and the key wide area routing enhancements that AURP provides to the AppleTalk routing protocols ✨
Chapter 2, "Wide Area AppleTalk Connectivity," covers AppleTalk tunneling through IP internets and over point-to-point links 🌸
Chapter 3, "Propagating Routing Information With the AppleTalk Update-Based Routing Protocol," is the core chapter 👑 It describes the essential elements of AURP, including the architectural model for update-based routing. It also gets into the detailed methods AURP uses to propagate routing information between internet routers connected through tunnels 🚀
Chapter 4, "Representing Wide Area Network Information," is the chapter with the optional features of AURP 🎀 Some of these can also run on routers that use RTMP instead of AURP for routing-information propagation. It explains how an exterior router represents imported network information to its local internet and to other exterior routers, and it covers network hiding, device hiding, network-number remapping, clustering, loop detection, hop-count reduction, hop-count weighting, and backup paths 🧩
The Appendix, "Implementation Details," gives info about implementing AURP 🛠️

What You Need to Know 🧠

This doc is for developers of AppleTalk wide area routing products 💻 It assumes you already know the AppleTalk network system, internet routing, and wide area networking terms and concepts. So if you're new, pls go get that background first 🙏

Format of This RFC Document 🎨

Real talk: this text was quickly prepared for RFC format 🫠 The art is more complex and isn't ready in this format yet. The plan is to add it later, but for the actual art, go check the official APDA document mentioned below 🦋

For More Information 📚

Apple has a bunch of manuals and books with extra info about AppleTalk networks, and Addison-Wesley books are at your local bookstore 📖 For technical reference materials for developers, contact APDA, Apple's source for developer tools:

APDA
Apple Computer, Inc.
20525 Mariani Avenue, M/S 33-G
Cupertino, CA  95014-6299

These manuals cover some AppleTalk network products 🧁

The Apple Ethernet NB User's Guide explains how to install and use an Apple Ethernet NB Card and EtherTalk software on an AppleTalk network 🔌
The Apple InteroPoll Network Administrator's Guide describes how to do maintenance and troubleshooting on an AppleTalk network using InteroPoll, a network administrator's utility program 🔍
The Apple Internet Router Administrator's Guide explains how to install the Apple Internet Router Basic Connectivity Package and how to use the Router Manager application program. It also covers setting up the router, configuring ports to create local area and wide area internets, monitoring and troubleshooting router operation, and planning your internet 🗺️
Using the AppleTalk/IP Wide Area Extension explains how to install and use the AppleTalk/IP Wide Area Extension for the Apple Internet Router. It covers tunneling through TCP/IP networks, configuring an IP Tunnel access method for an Ethernet or Token Ring port on the Apple Internet Router, troubleshooting IP tunneling problems, and configuring MacTCP 🌊
The AppleTalk Remote Access User's Guide explains how to use a Macintosh computer to communicate with another Macintosh computer over standard telephone lines to access information and resources at a remote location ☎️
The Apple Token Ring 4/16 NB Card User's Guide explains how to install and operate the card and TokenTalk software on a Token Ring network 💍
The MacTCP Administrator's Guide, version 1.1, explains how to install and configure the MacTCP driver, which implements TCP/IP (Transmission Control Protocol/Internet Protocol) on a Macintosh computer 🍎

These books are the reference shelf for AppleTalk networks 📘

The Advantages of AppleTalk Phase 2 gives a detailed description of the enhanced internetworking capabilities of AppleTalk Phase 2, plus a brief guide to upgrading an AppleTalk internet to Phase 2. Available from Apple Computer ⭐
The AppleTalk Network System Overview is a technical intro to the AppleTalk network system and its protocol architecture. Published by Addison-Wesley Publishing Company 🌷
The AppleTalk Phase 2 Introduction and Upgrade Guide is a detailed guide to upgrading AppleTalk network hardware, drivers, and application programs to AppleTalk Phase 2. It also briefly describes extensions to the AppleTalk network system that enhance its support for large networks. Available from Apple Computer 🔧
The AppleTalk Phase 2 Protocol Specification is an addendum to the first edition of Inside AppleTalk. It defines AppleTalk Phase 2 extensions to AppleTalk protocols that provide enhanced AppleTalk addressing, routing, and naming services. Available from APDA 📜
Inside AppleTalk, second edition, is a technical reference that describes the AppleTalk protocols in detail and includes info about AppleTalk Phase 2. Published by Addison-Wesley Publishing Company 💜
The Local Area Network Cabling Guide covers network media, topologies, and network types. Available from Apple Computer 🧵
Planning and Managing AppleTalk Networks is an in-depth guide for network administrators about planning and managing AppleTalk networks. It covers AppleTalk terms and concepts, plus network services, media, topologies, security, monitoring and optimizing network performance, and troubleshooting. Published by Addison-Wesley Publishing Company 🗂️
Understanding Computer Networks gives an overview of networking, including basic info about protocol architectures, network media, and topologies. Published by Addison-Wesley Publishing Company 🌐
The AppleTalk Update-Based Routing Protocol Specification is the official Apple specification of AURP. It includes the artwork currently missing from this document. Available from APDA 🏆

Table of Contents 🗂️

1.  Introduction to the AppleTalk Update-Based Routing Protocol        6
    Wide area routing enhancements provided by AURP                    6
2.  Wide Area AppleTalk Connectivity                                   7
    AppleTalk tunneling                                                7
    IP tunneling                                                      14
    Point-to-point tunneling                                          17
3.  Propagating Routing Information With the AppleTalk Update-Based
    Routing Protocol                                                  18
    AURP architectural model                                          18
    Maintaining current routing information with AURP                 20
    AURP-Tr                                                           21
    One-way connections                                               22
    Initial information exchange                                      22
    Reobtaining routing information                                   28
    Updating routing information                                      28
    Processing update events                                          33
    Router-down notification                                          38
    Obtaining zone information                                        40
    Hiding local networks from remote networks                        44
    AURP packet format                                                45
    Error codes                                                       55
4.  Representing Wide Area Network Information                        56
    Network hiding                                                    56
    Device hiding                                                     57
    Resolving network-numbering conflicts                             59
    Zone-name management                                              65
    Hop-count reduction                                               66
    Routing loops                                                     67
    Using alternative paths                                           71
    Network management                                                73
Appendix.  Implementation Details                                     75
    State diagrams                                                    75
    AURP table overflow                                               75
    A scheme for updates following initial information exchange       75
    Implementation effort for different components of AURP            76
    Creating free-trade zones                                         77
    Implementation details for clustering                             78
    Modified RTMP algorithms for a backup path                        79
Security Considerations                                               82
Author's Address                                                      82

1. INTRODUCTION TO THE APPLETALK UPDATE-BASED ROUTING PROTOCOL ✨

okay so the AppleTalk Update-based Routing Protocol (AURP) is giving wide area routing upgrades 🦋 for the AppleTalk routing protocols, and it is fully compatible with AppleTalk Phase 2 💖. AURP has three major components:

AppleTalk tunneling through foreign network systems, for example TCP/IP (Transmission Control Protocol/Internet Protocol), and over point-to-point links
the propagation of routing information between internet routers connected through foreign network systems or over point-to-point links
the presentation of AppleTalk network information by an internet router to nodes or to other Phase 2-compatible routers on its local internet, in other words, on the AppleTalk internet connected directly to the router

Chapter 3, "Propagating Routing Information With the AppleTalk Update-Based Routing Protocol," describes the elements of AURP that are essential for a minimal implementation of AURP. AURP includes many optional features for the presentation of network information 🌸. You can implement many of these optional features on routers that use either AURP or RTMP (Routing Table Maintenance Protocol) for routing-information propagation 🧚.

Figure 1-1 shows how the three major components of AURP interact 👑.

<<Figure 1-1  Major components of AURP>>

Wide Area Routing Enhancements Provided by AURP

AURP provides AppleTalk Phase 2-compatible routing for large wide area networks (WANs) 🌈. The key wide area routing enhancements AURP brings are:

tunneling through TCP/IP internets and other foreign network systems
point-to-point tunneling
basic security, including device hiding and network hiding
remapping of remote network numbers to resolve numbering conflicts
internet clustering to minimize routing traffic and routing-information storage requirements
hop-count reduction to allow the creation of larger internets
improved use of alternate paths through hop-count weighting and the designation of backup paths

2. WIDE AREA APPLETALK CONNECTIVITY 🎀

this chapter is all about the wide area connectivity that AURP makes possible, so let's get into it 🫶. It covers:

AppleTalk tunneling
tunneling through TCP/IP internets
tunneling over point-to-point links

AppleTalk Tunneling

Tunneling lets a network administrator connect two or more native internets through a foreign network system to form one big wide area network (WAN) 🌸. For example, an AppleTalk WAN might be made of two or more native AppleTalk internets connected through a tunnel built on a TCP/IP internet. In a setup like that, the native internets use AppleTalk protocols, while the foreign network system uses a different protocol family 💅.

A tunnel that connects AppleTalk internets acts like a single, virtual data link between them ✨. A tunnel can be either a foreign network system or a point-to-point link. Figure 2-1 shows an AppleTalk tunnel.

<<Figure 2-1  AppleTalk tunnel>>

There are two types of tunnels 🦋:

dual-endpoint tunnels, which have only two routers on a tunnel, for example point-to-point tunnels
multiple-endpoint tunnels, herein referred to as multipoint tunnels, which have two or more routers on a tunnel

AURP does multipoint tunneling by providing mechanisms for data encapsulation and for propagating routing information to specific routers 🔥.

Exterior Routers

An AppleTalk router with a port that connects an AppleTalk internet to a tunnel is an exterior router 🧚. An exterior router always sends split-horizoned routing information to the other exterior routers on a multipoint tunnel. That means an exterior router on a multipoint tunnel sends routing information for only its local internet to the other exterior routers on that tunnel. It never exports routing information it got from other exterior routers on the tunnel, because the exterior routers already talk to each other about their own routing information 🙈.

As Figure 2-2 shows, whether there are redundant paths (loops) across a tunnel changes how an exterior router defines its local internet 💜. For more on redundant paths, see the section "Redundant Paths" in Chapter 4. If no loops exist across a tunnel, an exterior router's local internet is made up of all networks connected directly or indirectly to its other ports. When loops exist across a tunnel, an exterior router's local internet includes only those networks whose next internet router is not across a tunnel. With this definition of a local internet, two exterior routers' local internets might overlap if loops exist across a tunnel 💀. For more on routing loops, see the section "Routing Loops" in Chapter 4.

<<Figure 2-2  An exterior router's local internet>>

An exterior router works as an AppleTalk router inside its local internet, and as an end node in the foreign network system that connects AppleTalk internets 💖. It uses RTMP to pass routing information to its local internet, and it uses AURP plus the network-layer protocol of the tunnel's underlying foreign network system to talk to the other exterior routers on the tunnel 🫶. An exterior router encapsulates AppleTalk data packets using the headers the foreign network system requires, then forwards the packets to another exterior router on the tunnel 🎀.

FORWARDING DATA: When an exterior router forwards AppleTalk data packets across a multipoint tunnel, it:

encapsulates the AppleTalk data packets in the packets of the tunnel's underlying foreign network system by adding the headers that network system requires
adds an AURP-specific header, called a domain header, immediately preceding each AppleTalk data packet

A domain header carries extra addressing information, including a source domain identifier and a destination domain identifier 🌈. For more on domain headers, see the sections "AppleTalk Data-Packet Format" and "AppleTalk Data-Packet Format for IP Tunneling" later in this chapter. For the full scoop on domain identifiers, see the section "Domain Identifiers" later in this chapter 📚.

Before an exterior router forwards a data packet to a network in another exterior router's local internet, it must get the foreign-protocol address of the exterior router that is the next internet router on the path to the packet's destination network 🍓. It then sends the packet to that exterior router's foreign-protocol address using the network-layer protocol of the foreign network system. The exterior router doesn't need to know anything else about how the packet travels across this virtual data link 🦋.

Once the destination exterior router receives the packet, it removes the headers the foreign network system requires and the domain header, then forwards the packet to its destination in the local AppleTalk internet ✨.

If the length of an AppleTalk data packet in bytes is greater than the data field of a foreign-protocol packet, a forwarding exterior router must fragment the AppleTalk data packet into multiple foreign-protocol packets, then forward those packets to their destination 🧩. Once the destination exterior router has received all of the fragments that make up the AppleTalk data packet, it reassembles the packet 💅.

CONNECTING MULTIPLE TUNNELS TO AN EXTERIOR ROUTER: An exterior router can also connect two or more multipoint tunnels 👑. As Figure 2-3 shows, when an exterior router connects more than one multipoint tunnel, those tunnels can be built on any of the following:

the same foreign network system
different foreign network systems
similar, but distinct, foreign network systems

<<Figure 2-3  Connecting multiple tunnels to an exterior router>>

Whether the tunnels connected to an exterior router are built on similar or different foreign network systems, each tunnel acts as an independent, virtual data link 🌸. As Figure 2-4 shows, an exterior router connected to multiple tunnels works logically as though it were two or more exterior routers connected to the same AppleTalk network, with each one connected to a different tunnel 🫶.

<<Figure 2-4  An exterior router connected to multiple tunnels>>

Fully Connected and Partially Connected Tunnels

An AppleTalk multipoint tunnel functions as a virtual data link 🦋. AURP assumes full connectivity across a multipoint tunnel, meaning all exterior routers on that tunnel can talk to one another 💖. An exterior router always sends split-horizoned routing information to the other exterior routers on a multipoint tunnel. In other words, it sends routing information for only its local internet, and it never exports routing information it got from other exterior routers on the tunnel, because exterior routers share their routing information with each other directly 🎀.

If every exterior router connected to a multipoint tunnel knows about and can send packets to the others, that tunnel is fully connected 💅. If some of the exterior routers on a multipoint tunnel don't know about one another, the tunnel is only partially connected 🙈. Figure 2-5 shows examples of a fully connected tunnel, a partially connected tunnel, and two fully connected tunnels ✨.

<<Figure 2-5  Fully connected and partially connected tunnels>>

In the second example in Figure 2-5, the network administrator may have connected the tunnel partially for one of these reasons 🧚:

to prevent the local internets connected to exterior routers A and C from communicating with one another, while still providing full connectivity between the local internets connected to exterior router B and the local internets connected to both exterior routers A and C
because local internets connected to exterior routers A and C need access only to local internets connected to exterior router B, not to each other's local internets
because exterior routers A and C, which should be aware of one another, were misconfigured

Generally, an exterior router can't tell whether a multipoint tunnel is fully or partially connected 🤷‍♀️. In the second example in Figure 2-5, exterior router B doesn't know whether exterior routers A and C are aware of one another. Even so, exterior router B must assume that the tunnel is fully connected, and that exterior routers A and C can exchange routing information 💜. An exterior router should never forward routing information it received from other exterior routers back across the tunnel 🚫. It should always send split-horizoned routing information to the other exterior routers 🫶.

If connecting exterior routers A and C directly would be either expensive or slow, a network administrator could instead set up two independent multipoint tunnels: one connecting exterior routers A and B, and another connecting exterior routers B and C, as shown in the third example in Figure 2-5 🌈. Exterior routers A and C could then connect by routing all data packets forwarded by one of them to the other through exterior router B 🦋.

Hiding Local Networks From Tunnels

When you set up a tunneling port on an exterior router, the network admin can give a network some network-level security by hiding it 🙈 Hiding a network in the router's local internet means the internets across a multipoint tunnel never find out it exists 🫣 When the exterior router swaps routing info with the other exterior routers on the tunnel, it exports zero info about hidden networks to the routers they're hidden from. Ghosted 👻

An admin can say certain networks should be hidden from one specific exterior router on the tunnel, or from every exterior router on it 💅

Nodes on the local internet of an exterior router that a network is hidden from can't access that network 🚫 The zones on a hidden network and the names of the devices in those zones don't show up in the Chooser on computers connected to that internet. And when a network is hidden, its nodes also can't reach internets it's hidden from. Say a node on a hidden network sends a packet across a tunnel to a node on an internet it's hidden from. Even if the packet arrives, the receiving node can't reply 😭 The exterior router on the receiver's internet doesn't know the return path to the hidden-network node. So from the hidden node's point of view, the node it messaged is just unreachable. Main character energy, but make it a networking tragedy 💀

Advantages and Disadvantages of Network Hiding

Network hiding has some real perks 💖 Here's what it gives you:

On large, global WANs, a network admin can set up network-level security for an organization's internets 🔐
It cuts down on network traffic across both a tunnel and the internets connected to that tunnel 📉

Network hiding also has some downsides 🥲

Nodes on hidden networks have limited access to internets across a tunnel.
AppleTalk networking software running on a node on a hidden network lists all of the AppleTalk zone names exported by exterior routers connected to a tunnel. But it may list the names of only some devices in those zones, or none at all. It can't list the names of devices that can't respond to Name Binding Protocol (NBP) lookups from a node on a hidden network.

Domain Identifiers

Exterior routers give each AppleTalk internet (or domain) its own unique domain identifier 🪪 These are what let exterior routers on a multipoint tunnel tell the individual AppleTalk internets in a wide area internet apart from each other ✨

The definition of an AppleTalk domain identifier is built to be extensible 🧩 That's so future tunnel types and tunneling topologies can be added later:

Under the current version of AURP, each exterior router connected to a multipoint tunnel assigns a domain identifier to its local AppleTalk internet. That identifier uniquely identifies the internet on the tunnel. If redundant paths connect an AppleTalk internet through more than one exterior router on a tunnel, each exterior router can assign a different domain identifier to that internet, or AppleTalk domain, as shown in Figure 2-6.
Under future routing protocols, a domain identifier will define the boundaries of an AppleTalk domain globally, for all exterior routers. So a domain identifier will be unique among all domains in a wide area internet. All exterior routers within a wide area internet will use the same domain identifier for a given AppleTalk internet, as shown in Figure 2-6.

              <<Figure 2-6  Domain identifiers>>

To make an exterior router's port configuration easier, a parameter that's already administered (like a node address) can be the basis for the router's domain identifier 🎀

General Domain-Identifier Format

Figure 2-7 shows the general form of a domain identifier 🗺️

        <<Figure 2-7  General domain-identifier format>>

The general domain identifier (DI) has the following fields:

Length: Byte 1 is the length of the DI in bytes, not counting the length byte itself. A DI must have an even number of bytes, so the length byte is always an odd-numbered byte. The length field lets you tunnel through foreign network systems with addresses of any length, including the long addresses typical of X.25 and OSI. The value of the length byte changes depending on the format of the DI.

Authority: Byte 2 tells you which authority administers the identifier bytes of the DI. Right now, Apple has defined only two authority-byte values:

$01 means the following bytes are a unique, centrally administered IP address
$00 (the null DI) means no additional bytes follow

Every other authority-byte value is reserved and should not be used 🚷

Identifier: The identifier field starts at byte 3. It's a variable number of bytes, based on the type the authority byte indicates.

Null Domain-Identifier Format

A null domain identifier is only appropriate when there's no need to tell apart the domains connected to a tunnel 🫶 That happens when a tunnel exists within a single internet, or for a point-to-point link. Figure 2-8 shows the null form of a domain identifier.

          <<Figure 2-8  Null domain-identifier format>>

A null domain identifier has these bytes:

Length: Byte 1 contains the value $01, defining the length of the null DI as one byte.

Authority: Byte 2 contains the value $00, indicating a null DI.

AppleTalk Data-Packet Format

Part of the format of an AppleTalk data packet sent across a multipoint tunnel or a point-to-point link depends on the underlying foreign network system 🌈 The headers a foreign-network protocol needs always come before an AppleTalk data packet sent across a multipoint tunnel. A domain header usually comes right before the AppleTalk data packet. Figure 2-9 shows the format of an AppleTalk data packet preceded by a domain header.

  <<Figure 2-9  AppleTalk data-packet format with a domain header>>

A domain header has these fields:

Destination DI: The length of the destination DI field in bytes depends on the type of DI.

Source DI: The length of the source DI field in bytes depends on the type of DI.

Version number: The version number field is two bytes long and currently contains the value 0001.

Reserved: The two-byte field right after the version number field is reserved for future use and is set to 0000.

Packet type: The two-byte packet type field contains the value 0002 to identify the data that follows as AppleTalk data. That sets it apart from other data, like routing data. Apple may define other values for this field in the future 🔮

An AppleTalk data packet does not require a domain header if:

it's sent across a multipoint tunnel or point-to-point link that provides separate channels for data and routing packets
the domain header's destination DI and source DI fields would both contain null DIs

Leaving out the domain header cuts down on the overhead of exchanging routing information, with no loss of routing information 🧠 Figure 2-10 shows the format of an AppleTalk data packet without a domain header.

  <<Figure 2-10  AppleTalk data-packet format without a domain header>>

IP Tunneling

The Transmission Control Protocol/Internet Protocol (TCP/IP) suite is a super widely used communications standard 🌐 It gives interoperability among computers from all kinds of vendors, including Apple, IBM, Digital Equipment Corporation, Sun, and Hewlett-Packard.

Here are three of the most important TCP/IP protocols:

The Transmission Control Protocol (TCP) is a transport-layer protocol that provides reliable data transmission between processes. That means between programs that talk to one another. This connection-oriented, byte-stream protocol makes sure data is delivered error-free and in sequence, without loss or duplication 📦
The User Datagram Protocol (UDP) is a transport-layer protocol that provides best-effort, low-overhead interprocess data transmission. It's datagram-oriented, so higher-layer protocols that don't need reliability can send data without the overhead TCP brings 🏃‍♀️ UDP does no error checking, doesn't acknowledge that data was received, and doesn't sequence incoming messages. UDP messages may be lost, duplicated, or improperly sequenced 🙃
The Internet Protocol (IP) is a network-layer protocol that provides connectionless, best-effort datagram delivery across multiple networks. Each host on a TCP/IP network has a unique, centrally administered internet address, called an IP address, that identifies the node. The header of an IP datagram contains its source and destination IP addresses, so any host can route a datagram to its destination. TCP/IP connects many different network types that use data frames of various sizes, so IP can fragment a datagram before sending it across an internet. Datagram fragments can fit into data frames of any size. Once all of a datagram's fragments reach their destination, IP reassembles the datagram 🧩

Protocols in higher layers pass data to TCP or UDP for delivery to peer processes. TCP and UDP wrap the data in segments with the right headers, then pass the segments to IP. IP wraps the data in IP datagrams, works out each datagram's path to its destination, and sends the datagrams across the internet 🚀

Figure 2-11 shows how the TCP/IP family of protocols lines up with the Open Systems Interconnection (OSI) model 🗂️

    <<Figure 2-11  TCP/IP protocol stack and the OSI model>>

Exterior routers that connect AppleTalk internets through a TCP/IP tunnel are configured as nodes on both an AppleTalk internet and the TCP/IP internet. So an exterior router on a TCP/IP tunnel is also an IP end node in the TCP/IP network system 🧚 Exterior routers use the TCP/IP internet only to swap AppleTalk routing information and AppleTalk data packets with each other. An exterior router wraps AppleTalk data packets in IP datagrams before sending them across the TCP/IP internet to a forwarding exterior router. That router unwraps the packets, then forwards them to their destination AppleTalk networks.

IP Domain-Identifier Format

Under the current version of AURP, exterior routers on IP tunnels must use domain identifiers based on IP addresses 🎯 An exterior router on an IP tunnel gets its domain identifier from its IP address. So a network admin doesn't need to configure an exterior router's domain identifier. Figure 2-12 shows the IP form of a domain identifier.

          <<Figure 2-12  IP domain-identifier format>>

An IP domain identifier has these fields:

Length: Byte 1 contains the value $07, defining the length of the IP DI as seven bytes.

Authority: Byte 2 contains the value $01, indicating that the rest of the DI is based on an IP address.

Distinguisher: Bytes 3 and 4 are reserved for future use and are set to 0 ($00) 🌸

IP address: bytes 5 through 8 hold the four-byte IP address of either the sending or the receiving exterior router. 🌐

NOTE: Future versions of AURP will allow exterior routers to use alternative formats for domain identifiers, even on IP tunnels. 🔮

AppleTalk Data-Packet Format for IP Tunneling

Okay so this is how an AppleTalk data packet gets dressed up for an IP tunnel 💅 The following protocol headers stack up in front of an AppleTalk data packet that an exterior router forwards across an IP tunnel:

a data-link header
an IP header
a User Datagram Protocol (UDP) header
a domain header

An exterior router wraps AppleTalk data packets inside UDP packets when it forwards them through its UDP port 387, across an IP tunnel, to UDP port 387 on another exterior router. When encapsulating data packets, an exterior router should always use UDP checksums. When a destination exterior router receives the UDP packets at UDP port 387, it decapsulates the packets. 🎀

A domain header has the following fields, and they're all giving main character energy 👑

Destination DI: This field contains the DI of the exterior router to which a packet is being forwarded.
Source DI: This field contains the DI of the exterior router that is forwarding a packet.
Version number: The version number field is two bytes in length and currently contains the value 0001.
Reserved: The two-byte field that follows the version number field is reserved for future use and is set to 0000.
Packet type: The two-byte packet type field contains the value 0002 to identify the data that follows as AppleTalk data, distinguishing it from other data, such as routing data. 🦋

An AppleTalk data packet is a domain header plus AppleTalk data. Figure 2-13 shows the format of an AppleTalk data packet forwarded across an IP tunnel:

<<Figure 2-13  AppleTalk data packet forwarded across an IP tunnel>>

Point-to-Point Tunneling

Point-to-point tunneling is when two remote AppleTalk local area networks (LANs) connected to half-routers talk to each other over a point-to-point link. A point-to-point link may consist of modems communicating over a standard telephone line or a leased line, such as a T1 line. Figure 2-14 shows an example of point-to-point tunneling:

             <<Figure 2-14  Point-to-point tunneling>>

Generally, exterior routers use null domain identifiers on point-to-point links, because there is no IP address to be administrated and the opposite end of the tunnel is already uniquely identified. However, an exterior router may use other domain-identifier formats. 💖

Point-to-Point Protocol

The Point-to-Point Protocol (PPP) is a data-link-layer protocol. It's the standard method for encapsulating and decapsulating network-layer protocol information and transmitting that information over point-to-point links ✨ PPP includes an extensible Link Control Protocol (LCP) and a suite of Network Control Protocols (NCPs) that configure, enable, and disable various network-layer protocols.

The AppleTalk Control Protocol (ATCP) is a PPP NCP for AppleTalk protocols. ATCP configures, enables, and disables the AppleTalk network-layer protocol DDP on the half-router at each end of a point-to-point link. ATCP also specifies the protocol that a half-router uses to propagate routing information, for example AURP. When using AURP for routing-information propagation, a half-router uses a specific PPP protocol type to identify AURP routing-information packets, that is, packets preceded by a domain header. PPP provides separate channels for AppleTalk data packets and AppleTalk routing-information packets, so a half-router can use DDP encapsulation to send AppleTalk data packets without including their domain headers. When using AURP, a half-router should accept both AppleTalk data packets that are preceded by domain headers and DDP-encapsulated packets. 🫶

NOTE: The Request for Comments (RFC) 1378, "The PPP AppleTalk Control Protocol (ATCP)," provides a detailed specification of ATCP, as well as information about using PPP to send AppleTalk data. 📚

AURP Architectural Model

AURP provides the functionality of the Routing Table Maintenance Protocol (RTMP) and the Zone Information Protocol (ZIP) while eliminating most of the routing traffic generated by these protocols. Figure 3-1 shows the architectural model for AURP:

             <<Figure 3-1  AURP architectural model>>

Generally, an AppleTalk router uses RTMP and ZIP to maintain routing information, and sends RTMP data packets, ZIP Queries, and ZIP Replies out its ports. However, if one of the router's ports is connected to an AppleTalk tunnel, the architectural model for the router's central routing module becomes more complex. Logically, the central routing module in an exterior router communicates RTMP and ZIP information to an RTMP/ZIP-to-AURP conversion module, which sends AURP data packets out the tunneling port. 🧚

RTMP/ZIP-to-AURP Conversion Module

The RTMP/ZIP-to-AURP conversion module maintains split-horizoned routing-table information and network number-to-zone name mappings for each exterior router on the tunnel. That's a copy of the routing information for each exterior router's local internet. Figure 3-2 shows the architectural components of the RTMP/ZIP-to-AURP conversion module:

      <<Figure 3-2  RTMP/ZIP-to-AURP conversion module architecture>>

The AURP module of the conversion module obtains routing information from the other exterior routers on the tunnel, then periodically updates the routing-table information and the mappings in the conversion module. The RTMP module passes this routing-table information to the exterior router's central routing module. Logically, the RTMP module generates an RTMP data packet for each exterior router on the tunnel every ten seconds (the RTMP retransmission time), then passes the packet to the central routing module. ⏱️

The RTMP/ZIP-to-AURP conversion module also maintains a split-horizoned copy of the routing information maintained by the exterior router in which it resides. Logically, the conversion module obtains the routing information from RTMP data packets and ZIP Replies sent by the exterior router's central routing module, then updates the routing information in the conversion module.

The AURP module exports routing information about its local AppleTalk internet to other exterior routers on the tunnel. 🌸

AURP Transport Layering

AURP can propagate routing information between exterior routers using:

a simple, reliable transport based on an underlying datagram service, such as the default transport-layer service for AURP, AURP-Tr. See the section "AURP-Tr," later in this chapter, for more information.
a more complex transport-layer service, such as TCP

Figure 3-3 shows the AURP transport-layering model:

           <<Figure 3-3  AURP transport-layering model>>

Maintaining Current Routing Information With AURP

AURP allows exterior routers to maintain current routing information for other exterior routers on a tunnel by supporting:

the reliable, initial exchange of split-horizoned routing information, that is, the routing information for an exterior router's local internet
reliable updates to that information whenever it changes

If an internet topology does not change, AURP generates significantly less routing traffic than RTMP and ZIP. Thus, an administrator can connect very large AppleTalk internets through a tunnel, and the resulting internet generates little or no routing traffic on the tunnel. Honestly, that's so efficient it's iconic 🔥

When an exterior router discovers another exterior router on the tunnel, that is, a peer exterior router, it can request that exterior router to send its routing information. In a reliable, initial exchange of split-horizoned routing information, the peer exterior router returns its network-number list. The peer exterior router also returns each connected network's zone information in an unsequenced series of zone-information packets. If the exterior router requesting the routing information does not receive complete zone information for a network, it must retransmit requests for zone information until it receives the information. 🔁

Once an exterior router requesting routing information from a peer exterior router has received that exterior router's network-number list and complete zone information, it typically requests the peer exterior router to notify it of any changes to that routing information. The peer exterior router then provides the requesting exterior router with reliable updates to its routing information. However, it sends no other routing information. 🙈

Notifying Other Exterior Routers of Events

If an exterior router has requested notification of changes in another exterior router's split-horizoned routing information, that exterior router must notify the requesting exterior router of any event that changes its routing information. Thus, an exterior router must send updated routing information to the requesting exterior router whenever any of the following events occur:

the addition of a new, exported network, that is, a network that is not hidden, to the exterior router's local internet and, consequently, to its routing table
a change in the path to an exported network that causes the exterior router to access that network through its local internet rather than through a tunneling port
the removal of an exported network from the exterior router's routing table because a network in the exterior router's local internet has gone down
a change in the path to an exported network that causes the exterior router to access that network through a tunneling port rather than through its local internet
a change in the distance to an exported network
a change to a zone name in the zone list of an exported network, an event not currently supported by ZIP or the current version of AURP
the exterior router goes down or is shut down

Routing-information updates allow an exterior router to maintain accurate, split-horizoned routing information for a peer exterior router on a tunnel. 💅

AURP-Tr

AURP-Tr, the default transport-layer service for AURP, provides a simple, reliable transport that is based on an underlying datagram service. When using AURP-Tr, only one sequenced transaction can be outstanding, or unacknowledged, at a time. That's greatly simplifying the implementation of AURP, without limiting its functionality 🌈

One-Way Connections

okay so a one-way connection is an asymmetrical link 🦋 between a data sender and a data receiver that are both using AURP-Tr. the exterior router acting as the data sender pushes a sequenced, reliable, unidirectional data stream to the exterior router acting as the data receiver. an exterior router can send routing info over a one-way connection as two kinds of data:

sequenced data
transaction data

sequenced data is sent in order by the data sender and delivered reliably to the data receiver. it's usually unprovoked, meaning the data receiver didn't ask for it. however, a data receiver can request sequenced data 💅 Figure 3-4 shows it:

       <<Figure 3-4  Sequenced data on a one-way connection>>

transaction data (also called out-of-band data) is sent unsequenced by the data sender as part of a linked request/response transaction that the data receiver starts 🌸

the data receiver can use a one-way connection to request transaction data from the data sender. if the data receiver doesn't get a response, it must retransmit its request. Figure 3-5 shows a one-way connection where the data receiver asks for transaction data:

<<Figure 3-5  Request for transaction data on a one-way connection>>

usually, communication between two exterior routers is bidirectional 🔥. that means there are two one-way connections between them, and each exterior router is the data sender on one and the data receiver on the other. so each exterior router can send its routing info to the other. iconic, honestly ✨

Initial Information Exchange 🎀

when an AppleTalk exterior router discovers another exterior router on the tunnel, it uses the underlying transport-layer service to open a connection with that router. when using AURP-Tr, the exterior router opens this connection as a one-way connection.

Open Request Packet 🧚

once the data receiver opens a connection through the underlying transport, it sends an Open Request packet (Open-Req) to the data sender. an Open-Req packet includes:

Send update information flags: the states of the four send update information (SUI) flags tell the data sender whether it should send various types of update information over the connection. typically, the four SUI flags are set to 1.
Version number: the version number field shows which version of AURP the data receiver is using. the current version number of AURP is 1.
Data field: the optional data field lets exterior routers with capabilities beyond this document notify other exterior routers about those options, by starting option negotiation. an exterior router with similar capabilities says it accepts the options, which completes option negotiation. an exterior router that lacks those options ignores the info in the data field.

Open Response Packet 🌈

when an exterior router receives an Open-Req, it becomes the data sender and replies with an Open Response packet (Open-Rsp), like this:

if the exterior router accepts the connection, it returns info about its setup in the Open-Rsp. an Open-Rsp also has an optional data field, which shows whether the exterior router accepts the options in the data field of the Open-Req it's replying to.
if the exterior router can't accept the connection (for example, because the Open-Req has the wrong version number), it returns an error in the Open-Rsp and closes the transport-layer connection 💀

Figure 3-6 shows the connection-opening dialog between a data sender and a data receiver:

                 <<Figure 3-6  Connection-opening dialog>>

Routing Information Request Packet 🦋

under AURP, once two exterior routers have a connection, the data receiver can ask the data sender for its routing info by sending a Routing Information Request packet (RI-Req).

Routing Information Response Packets 💖

when the data sender gets an RI-Req, it reliably sends a sequence of Routing Information Response packets (RI-Rsp) to the exterior router that asked for the info.

the RI-Rsp packets give a list of exported networks on the data sender's local internet, plus the distance of each network from the data sender. the data sender must finish sending RI-Rsp packets to the requesting exterior router before it can send any other sequenced data over the connection. Figure 3-7 shows this request/response dialog:

        <<Figure 3-7  Routing-information request/response dialog>>

Zone Information Request Packet 🍓

the data receiver can get zone info for known networks on the data sender's local internet at any time, by sending a Zone Information Request packet (ZI-Req). a ZI-Req lists the network numbers the data receiver wants zone info for.

IMPORTANT: to stop other exterior routers on a tunnel from sending endless streams of ZI-Req packets across the tunnel (aka a ZIP storm 🌪️), an exterior router must not export info about a network until it has a complete zone list for that network.

Zone Information Response Packets 🫶

when the data sender gets a ZI-Req, it replies with unsequenced Zone Information Response packets (ZI-Rsp) to the data receiver. zone info is transaction data, so its reliable delivery isn't guaranteed. Figure 3-8 shows the zone-info request/response dialog:

         <<Figure 3-8  Zone-information request/response dialog>>

Recovering Lost Zone Information 🔥

the data receiver makes a network-to-zone list association in its routing table for each network it gets a ZI-Rsp packet for. if a data receiver that asked for zone info for a network doesn't get a complete zone list for it, it must retransmit ZI-Req packets for that network until it gets the complete zone info.

to figure out if any ZI-Rsp packets got lost, the data receiver periodically scans its routing table for networks whose zone lists are incomplete (zone lists missing some of the zones for those networks). it sends a ZI-Req to each data sender it got incomplete info from, listing the network numbers it still needs. the data sender answers zone info requests by sending ZI-Rsp packets with the requested info to the data receiver 👑

Using AURP-Tr for Initial Information Exchange 🌸

the following sections describe how to use AURP-Tr (the default transport-layer service for AURP) for initial information exchange.

OPEN REQUEST PACKET: an exterior router sends an Open-Req packet to:

request that an AURP-Tr one-way connection with another exterior router be established
specify the connection ID for that connection
pass the AURP version number, SUI flags, and optional data to the other exterior router

if the exterior router doesn't get an Open-Rsp from the router it sent the Open-Req to, it must retransmit the Open-Req 🙈

OPEN RESPONSE PACKET: when using AURP-Tr, an exterior router sends an Open-Rsp to:

acknowledge that a one-way connection has been established
reject a connection
return info about its environment, plus any optional data, to the exterior router that sent the Open-Req

if an exterior router gets an Open-Req on a one-way connection that's already open (meaning an Open-Req with the same connection ID as an open one-way connection), an Open-Rsp sent earlier may have been lost. the exterior router receiving the duplicate Open-Req should send a duplicate Open-Rsp back to the sending exterior router, unless it has already received some other packet on the connection (like an RI-Req) that shows a fully established connection ✨

ROUTING INFORMATION RESPONSE PACKETS: when responding to a routing info request using AURP-Tr, an exterior router sends a sequence of RI-Rsp packets to the exterior router asking for the info. still, an exterior router's full list of network numbers often fits in one RI-Rsp packet. each RI-Rsp packet contains:

Connection ID: identifies the specific one-way connection a packet belongs to.
Sequence number: identifies an individual packet on a connection. packets on a connection are numbered starting at 1.

the data sender sending routing info must wait for the data receiver to acknowledge each RI-Rsp packet in the sequence (by sending an RI-Ack packet) before it sends the next RI-Rsp packet. each RI-Rsp has a flag that shows whether it's the last packet in the sequence. in the last RI-Rsp, this flag is set to 1. if the data sender gets no acknowledgment of an RI-Rsp from the data receiver within a specified period of time, it must retransmit the RI-Rsp 🦋

ROUTING INFORMATION RESPONSE PACKETS: when an exterior router gets an RI-Rsp, it checks the packet's connection ID and sequence number. the connection ID must be the same as the one in the Open-Req. the sequence number must be either:

the last sequence number received, meaning the previous acknowledgment was lost or delayed and this is a duplicate RI-Rsp
the next number in the sequence, meaning this RI-Rsp contains new routing info

if the connection ID or sequence number is invalid, the data receiver discards the packet. Figure 3-9 shows a dialog where the data receiver requests routing info, the data sender responds with its routing info, and the data receiver acknowledges that response. if the data sender gets no acknowledgment, it keeps sending duplicate RI-Rsp packets until the data receiver replies with an acknowledgment 🌈

     <<Figure 3-9 Routing-information request/response/acknowledgment
                                 dialog>>

once the data receiver has checked the info in the RI-Rsp, it replies with a Routing Information Acknowledgment packet (RI-Ack), which contains:

Connection ID: the same as the one in the RI-Rsp packet.
Sequence number: the same as the one in the RI-Rsp packet.
Send zone information flag: the state of the send zone information (SZI) flag in an RI-Ack packet shows whether the RI-Ack packet doubles as a ZI-Req packet. if the SZI flag is set to 1, the data receiver sends the zone info for the networks it sent routing info about in the previous RI-Rsp 💜

Figure 3-10 shows a data receiver sending zone info to a data sender, both in response to a ZI-Req and in response to an RI-Ack. that's the optimization, bestie, the data flow goes brrr 🚀

okay so when the data sender gets an RI-Ack, it checks that the RI-Ack matches the outstanding RI-Rsp. bestie, both packets need the same connection ID AND sequence number 🔍. once it's verified the info in the RI-Ack, it sends the next RI-Rsp in the sequence, if there is one ✨

<<Figure 3-10 Nonoptimized and optimized flows of zone information>>

ZONE INFORMATION RESPONSE PACKETS: if the data sender receives an RI-Ack with its SZI flag set to 1, it responds by sending ZI-Rsp packets that contain the zone information for the networks it sent routing information about in the RI-Rsp being acknowledged. it's giving the same energy as when it gets a ZI-Req for those networks 🎀

The data sender sends RI-Rsp and ZI-Rsp packets as independent data streams 🦋 It sends RI-Rsp packets as sequenced data and ZI-Rsp packets as transaction data. If the data sender receives an RI-Ack with its SZI flag set to 1, it sends an unsequenced series of ZI-Rsp packets that contain the following information:

Connection ID: the connection ID is the same as the one in the associated RI-Req 💜

Network number and zone list tuples: the exterior router sends the zone information for each network number in the corresponding RI-Rsp 🌸

Reobtaining Routing Information

okay this one is so good 🥹 an exterior router can reobtain another exterior router's complete routing information at any time, just by sending an RI-Req packet. an exterior router might need to reobtain complete routing information for a one-way connection where it's the data receiver in these situations:

During the initial routing-information exchange, the exterior router set the SUI flags in the Open-Req to disable updates. the exterior router can poll the other exterior router later by sending it an RI-Req to see whether any of its routing information has changed 👀
the exterior router set the SUI flags to request updates, but it suspects the routing information for the other exterior router on the connection is incorrect or obsolete. the exterior router SHOULD send an RI-Req to the other exterior router to get its complete, updated routing information 💅

Whenever an exterior router gets an RI-Req from an exterior router asking for updated routing information, it responds by sending RI-Rsp packets, just like when it first gets an RI-Req 🫶 The data sender also resets the SUI flags for that one-way connection, so they match the ones in the RI-Req.

⚠️ if the data sender is already sending other sequenced update info when the RI-Req shows up, it can't respond until the data receiver acknowledges the last outstanding packet in the sequence. and if AURP uses an underlying transport-layer service that doesn't provide reliable delivery (like AURP-Tr), it MAY be necessary for the data receiver to retransmit an RI-Req 😭

Updating Routing Information

so once an exterior router gets the routing and zone info for another exterior router's local internet, and it set the SUI flags in the Open-Req to request updates, the data sender tells the data receiver about any later changes to that info 📣

Informed-Routers List

an exterior router keeps an informed-routers list 📋 with the network address of each exterior router that asked for dynamic updates. once an exterior router has sent routing info for its local internet to other exterior routers on the tunnel, it MUST reliably send updated routing info to all accessible exterior routers in its informed-routers list whenever its routing info changes. no skipping, periodt 💖

Sending Routing Information Update Packets

an exterior router shares changes to its routing info by sending Routing Information Update, or RI-Upd, packets to another exterior router 🦋 when the routing info for its local internet changes, it doesn't have to send an RI-Upd right away. usually it buffers the update info and sends updates periodically ⏰ The exterior router MUST wait at least an update interval between sending updates. the value of this update interval:

cannot be less than ten seconds
SHOULD be specifiable by a network administrator

it's possible that more than one update event for a particular network happens within one update interval. one of these events might supercede another, like a Network Added event followed by a Network Deleted event for the same network 🙈 in that case, the exterior router can represent the two events logically as one event. under AURP, an exterior router can have only one event pending for a given network. an exterior router can combine any series of events for a network into a single pending event 🧚 In Figure 3-11, a state diagram shows the update event that an exterior router SHOULD have pending for a network, based on the other events that happened during the update interval.

<<Figure 3-11 A state diagram showing pending update events>>

four of the states match four pending update events. two states mean no update event is pending:

Net Up indicates that no update event is pending for a network in the exterior router's local internet
Net Down indicates that no update event is pending for a network in another exterior router's local internet, or the network does not exist

a single RI-Upd packet MAY contain different types of update events, like several Network Added events and several Network Deleted events. for info about update events, check out "Routing-Information Update Events" later in this chapter 📖

A data sender SHOULD send an RI-Upd packet to an exterior router in its informed-routers list only if the packet contains one or more update events of a type indicated by the SUI flags of the last Open-Req or RI-Req received from that exterior router. Because an RI-Upd that contains one or more events of a type requested by an exterior router MAY also contain events of types it didn't request, an exterior router MUST be able to handle events of all types. so a data sender can send an RI-Upd containing various types of update events to every exterior router that asked for update events of any of those types 💜

Sending Updates Following the Initial Exchange of Routing Information

while a data sender has update events pending (aka update events happened but it hasn't sent RI-Upd packets for them yet), another exterior router MAY establish a new connection with the data sender 👀 The data sender MUST present consistent routing information to all exterior routers on the tunnel, on both existing connections and any new connections. for example, if a pending update event said a new network had become available, the newly connected exterior router could learn about that network by either:

sending it an RI-Rsp packet including routing information for the new network
sending it an RI-Rsp packet that does not include routing information for the new network, then sending it the RI-Upd packet that includes the pending update event

AURP does not specify a scheme for sending update information following the initial exchange of routing information on a new connection. however, the Appendix, "Implementation Details," describes one possible method of doing this 🌈

Using AURP-Tr to Update Routing Information

the next sections explain how AURP-Tr sends routing-information updates 🧚

ROUTING INFORMATION UPDATE PACKETS: each RI-Upd packet contains the following information:

Connection ID: the connection ID identifies the specific one-way connection the RI-Upd belongs to 🎀

Sequence number: the sequence number identifies an individual RI-Upd on a connection ✨

If an update can't fit in one RI-Upd packet, the data sender MUST send a sequence of RI-Upd packets. While the data sender doesn't have to wait for a full update interval before sending each RI-Upd packet in a sequence, it MUST wait for the data receiver to acknowledge the RI-Upd packet that's currently outstanding before sending the next one in the sequence 🫶

if the data sender sending an RI-Upd doesn't get an acknowledgment (an RI-Ack) from the data receiver within a specified period of time, it SHOULD periodically retransmit the RI-Upd until the data receiver acknowledges it 🔁 Once the data sender has retransmitted the RI-Upd a specified number of times and still gets no RI-Ack, it SHOULD assume the one-way connection it's sending on is down. for more on routers going down, see "Using AURP-Tr to Detect Routers Going Down" later in this chapter 🚨

ROUTING INFORMATION ACKNOWLEDGMENT PACKET: when a data receiver gets an RI-Upd, it verifies the packet's connection ID and sequence number. The connection ID MUST be the same as the one in the Open-Req for the connection. The sequence number MUST be either:

the last sequence number received, meaning the previous acknowledgment was lost or delayed and this is a duplicate RI-Upd
the next number in the sequence, meaning the RI-Upd has new routing information

If the sequence number has any other value, the data receiver ignores the RI-Upd 🙅‍♀️ once the data receiver has verified the RI-Upd packet's connection ID and sequence number, it responds by sending a Routing Information Acknowledgment packet, or RI-Ack, which contains the following information:

Connection ID: the connection ID is the same as the one in the RI-Upd packet 💜

Sequence number: the sequence number is the same as the one in the RI-Upd packet 💜

Figure 3-12 shows a data receiver responding to an RI-Upd by sending an RI-Ack 📸

<<Figure 3-12 A routing-information update/acknowledgment dialog>>

when a data sender gets an RI-Ack, it verifies that the RI-Ack corresponds to the outstanding RI-Upd. both packets have the same connection ID and sequence number 🔍 Once the data sender has verified the info in the RI-Ack, it sends the next RI-Upd in the sequence, if there is one ✨

Routing-Information Update Events

an RI-Upd packet MAY contain any of five different types of routing-information update events 🌸 the next sections break them down.

NETWORK ADDED EVENT: an exterior router sends a Network Added (NA) event in these situations:

a new network shows up in the exterior router's routing table, it's in the exterior router's local internet, and it isn't hidden. that means it's an exported network 🍓
the port the exterior router uses to reach a network changes from a tunneling port to another port on the router, and the network isn't hidden 🔥

if a network in an exterior router's routing table becomes accessible across the tunnel, the exterior router does not send an NA event 🙈 An exterior router sends only split-horizoned routing information to other exterior routers on the tunnel 👑

An NA event 💅 lists the network numbers for the new network and its distance in hops. Any other exterior router can ask for that network's zone info at any time by sending a ZI-Req, once it has received an RI-Upd containing an NA event for that network 🦋

When using AURP-Tr, an exterior router can ask for zone info on new networks by setting the SZI bit in an RI-Ack it sends back in response to an RI-Upd. If a data sender gets an RI-Ack with its SZI flag set to 1, it sends the zone info for each new network it sent an NA event for in that RI-Upd. Lowkey so efficient 🧚

Figure 3-13 shows a data receiver replying to an RI-Upd with an RI-Ack where SZI is set to 1. This optimizes the zone info flow because the data sender responds with a ZI-Rsp 🌸

       <<Figure 3-13  An optimized flow of zone information>>

NETWORK DELETED EVENT: An exterior router sends a Network Deleted (ND) event 🥀 if an exported network that used to be reachable through its local internet no longer shows up in its routing table. An ND event lists the network numbers associated with the deleted network.

NETWORK ROUTE CHANGE EVENT: An exterior router sends a Network Route Change (NRC) event if the path to an exported network through its local internet changes to a path through a tunneling port. That causes split-horizoned processing to eliminate that network's routing information. An NRC event lists the network numbers associated with the network the path changed to. It's giving plot twist 🎀

NETWORK DISTANCE CHANGE EVENT: An exterior router sends a Network Distance Change (NDC) event if the distance to an exported network accessible through its local internet changes. An NDC event tells you which network the distance changed for and the network's distance in hops. An exterior router must send an NDC event even if the distance to a network changes to 15 hops. The exterior router that receives an NDC event with a hop count of 15 should process that event just as it would an ND event 💀

ZONE NAME CHANGE EVENT: This event is reserved for future use. 🔮

Processing Update Events 🫶

According to the architectural model, a data receiver processing an event contained in an RI-Upd packet updates the matching information in its central routing table. For example, if a data receiver gets an RI-Upd with an ND event or an NRC event, it sets that network's routing-table entry to BAD. Then it starts a notify-neighbor process by sending RTMP data packets that flag bad entries in its routing table to routers on its local internet 📣

Processing Inconsistent Update Events 🙈

Okay, this part is kinda messy but so important ngl. If the data receiver's copy of the data sender's routing table doesn't match the data sender's current routing table, the data receiver might get an RI-Upd with an event that doesn't line up with what it currently has. For example, this could happen if the data sender's routing table was changing during the initial exchange of routing information with the data receiver, as described in the section "Sending Updates Following the Initial Exchange of Routing Information" earlier in this chapter. The data receiver might get an RI-Upd containing an ND, NRC, or NDC event for a network not known to be in the data sender's routing table, or an NA event for a network already known to be in its routing table. The data receiver should:

ignore ND and NRC events for unknown networks
process an NDC event for an unknown network as an NA event
process an NA event for a known network as an NDC event

Maintaining a Central Routing Table 🗂️

According to the architectural model, an exterior router maintains a separate routing table for each other exterior router on a tunnel. In a typical implementation though, an exterior router keeps a central routing table that holds information about each path to each network it knows about, including its port, next internet router (IR), and distance in hops. Main character energy 👑

If no loops exist across a tunnel, an exterior router can reach a network that's accessible through that tunnel through only one exterior router, as shown in Figure 3-14. That kind of network isn't accessible through the exterior router's local internet or through any other exterior router on the tunnel. So the central routing table would only contain one path for that network 🧚

If a loop exists across a tunnel, an exterior router might be able to reach a network through two or more exterior routers on the tunnel, or through both its local internet and an exterior router. So when a loop exists across a tunnel, the central routing table may contain more than one path for each network. Figure 3-14 shows two examples of internets with loops 🌀

     <<Figure 3-14  Internets with and without loops>>

Maintaining an Alternative-Paths List 🦋

If a loop exists across a tunnel and an exterior router keeps a single central routing table, that table must include an alternative-paths list for each network the exterior router knows about. This list holds the routing information an exterior router might otherwise keep in separate routing tables for the other exterior routers on a tunnel. Each entry for an alternative path to a network consists of the address of the alternative next IR for that network and the network's distance through that next IR.

Since RTMP periodically retransmits information about alternative paths, the exterior router's alternative-paths list only needs to cover alternative paths to networks across tunneling ports. So the alternative-paths list for a network gives complete info about all paths to that network across tunnels, but not necessarily about all paths through the exterior router's local internet ✨

An exterior router must maintain an alternative-paths list, because once a data sender has reliably sent routing information to a data receiver, the data sender doesn't retransmit that information. Even if a path isn't currently the optimal path to a network, the exterior router has to keep info about that path in case it becomes the optimal path later 🙌

NOTE: Zone information is unaffected by the path taken to a network. So an exterior router doesn't need to keep duplicate zone information in the alternative-paths list. 💖

Using the Alternative-Paths List in Event Processing 🎀

An exterior router uses its alternative-paths list when it processes events.

PROCESSING A NETWORK ADDED EVENT: If an exterior router receives an NA event, it searches its central routing table for the network named in the event.

If the exterior router finds no entry for that network in its central routing table, it creates a new entry using the routing information in the NA event.
If the exterior router finds an existing entry for that network in its central routing table, and the next IR for that entry isn't the exterior router that sent the event, it figures out whether the NA event offers a better path to that network.
- If the NA event offers a better path to the network, or the state of the routing-table entry for that network is BAD, the exterior router replaces the current entry with the routing information in the NA event. In the current entry, if the path to the network goes through a tunnel (as indicated by the next IR), the exterior router moves the current entry over to the network's alternative-paths list.
- If the NA event doesn't offer a better path to the network, the exterior router adds the routing information in the NA event to the network's alternative-paths list.
If the exterior router finds an existing entry for that network where the next IR is the exterior router that sent the event, the exterior router should process the NA event just as it would an NDC event. 🫶

PROCESSING A NETWORK DELETED EVENT: If an exterior router receives an ND event, it searches its central routing table for the network named in the event.

If the exterior router finds no entry for that network in its central routing table, it ignores the event. See the section "Processing Inconsistent Update Events" earlier in this chapter. 🙈
If the exterior router that is the data receiver determines that the exterior router that sent the ND event is the next IR for that network, and there's an alternative-paths list for the network, the data receiver replaces the network's current routing information with the entry in the alternative-paths list that gives the shortest distance to that network, then removes that entry from the list. If the alternative-paths list has more than one entry giving the shortest distance to the network, the data receiver can use any of those entries. 🔥
If the exterior router that is the data receiver determines that the exterior router that sent the ND event is the next IR for that network, and there's no alternative-paths list for the network, the data receiver sets the network's routing-table entry to BAD, then starts a notify-neighbor process. 💀
If the exterior router that is the data receiver determines that the exterior router that sent the ND event is not the next IR for that network, the data receiver searches that network's alternative-paths list for an entry where the next IR is the data sender, and removes that entry from the list. 🧹

PROCESSING A NETWORK ROUTE CHANGE EVENT: If an exterior router receives an NRC event, it processes that event as an ND event. Generally, an NRC event shouldn't cause an exterior router to set a network's routing-table entry to BAD. An NRC event means the data sender has an alternative path to the network through the tunnel. The data receiver either already knows about that alternative path or will soon discover it 🦋

PROCESSING A NETWORK DISTANCE CHANGE EVENT: If an exterior router receives an NDC event with a hop count of 15, it processes that event just as it would an ND event. Otherwise, it searches its central routing table for the network named in the event.

If the exterior router finds no entry for that network in its central routing table, it processes that event as an NA event.
If the exterior router that is the data receiver determines that the exterior router that sent the NDC event is the next IR for the network, the data receiver replaces the distance to that network currently in its central routing table with the distance indicated in the NDC event. 🌈
If the exterior router that is the data receiver determines that the exterior router that sent the NDC event is not the next IR for the network, the data receiver:
- replaces the distance in the corresponding entry in the network's alternative-paths list with the distance indicated in the NDC event
- creates an entry in the alternative-paths list that contains the routing information in the NDC event, if it finds no entry for that network in the alternative-paths list 🍓

Okay so, finally 💅 regardless of whether the central routing table says the exterior router that sent the NDC event is the network's next IR, the data receiver compares the distances in the entries on the network's alternative-paths list to the distance in its central routing table. If an alternative-paths entry has a shorter path to the network, the exterior router moves that entry into its central routing table. This keeps the central routing table holding the shortest path to the network ✨

If the data receiver swaps the entry in its central routing table for the one in the NDC event, and the current entry gives a path through a tunnel, the data receiver moves the current entry onto the network's alternative-paths list 🦋
If the data receiver moves an entry from the network's alternative-paths list into its central routing table, it removes that entry from the alternative-paths list 🧚

RESPONDING TO EVENTS IN THE LOCAL INTERNET: An exterior router that uses AURP MUST respond appropriately to events that come from its local internet 🌸 These events happen when the routing information for a network in the exterior router's local internet changes and another path to that network exists through the tunnel. An exterior router handles them like this:

If the exterior router replaces the current routing-table entry for a network with routing information from an event that originates in its local internet (so, information provided by RTMP), and the current path to that network goes through a tunnel, the exterior router moves the current entry onto the network's alternative-paths list 💜
If the exterior router sets a routing-table entry's state to BAD, or removes an entry from its central routing table, it replaces that entry with the alternative-paths entry that gives the shortest distance to the network in the entry being replaced 🔥
If the distance to a network in the exterior router's local internet changes, the exterior router compares the distances in that network's alternative-paths entries to the distance in its central routing table. If an alternative-paths entry gives a shorter distance, the exterior router moves that entry into its central routing table, so the central routing table keeps the shortest path 👑

Router-Down Notification

Before going down, or becoming inactive, an exterior router MUST notify all other exterior routers in its informed-routers list that it is going down 🫶 It does this by using the underlying transport-layer service to close its connection with each exterior router.

Sending a Router Down Packet

Optionally, an exterior router can send a Router Down packet, or RD packet, to each exterior router before it goes down 🍓 An RD packet contains an error code that says the exterior router's reason for terminating its connection with each exterior router.

Generally, only the exterior router functioning as the data sender on a one-way connection sends RD packets. However, if just a single one-way connection exists between two exterior routers, the exterior router functioning as the data receiver on that connection can send an RD packet 💅

Using AURP-Tr to Notify Other Routers That a Router Is Going Down

When using AURP-Tr, an exterior router sends an RD packet to:

notify another exterior router that it is terminating a connection
pass an error code that indicates its reason for terminating the connection

As shown in Figure 3-15, once the data receiver verifies the RD packet's connection ID, it acknowledges that it received the RD packet by sending an RI-Ack. Then the data sender terminates the connection 🦋

<<Figure 3-15  Acknowledging an RD packet>>

If a Router Goes Down Without Notifying Other Routers

If an exterior router crashes or goes down without sending an RD packet, or becomes inaccessible due to a network problem, other exterior routers on the tunnel MUST be able to discover that it's down 😭 Generally, the underlying transport-layer service provides a mechanism for informing an exterior router that an exterior router in its informed-routers list has gone down or become inaccessible.

If an exterior router determines that another exterior router is down, it MUST:

remove that exterior router from its informed-routers list
remove that exterior router's routing information from all of its routing tables
close any one-way connections with that exterior router

If an exterior router rediscovers an exterior router that had previously gone down, it MUST again exchange initial routing information with that exterior router 🌈

Using AURP-Tr to Detect Routers Going Down

An exterior router using AURP-Tr associates a last-heard-from timer with each exterior router it has received routing information from. That is, it associates one with each one-way connection on which it is the data receiver. Each time it receives an RI-Rsp, RI-Upd, or ZI-Rsp over a connection (which verifies that its connection with the data sender is still active), it resets the last-heard-from timer for that connection ⏰

For each one-way connection on which it is the data receiver, the exterior router has a last-heard-from timeout value. If a connection's last-heard-from timer reaches that timeout value, the data receiver sends a Tickle packet over that connection. If the data sender on the connection is still accessible, it responds with a Tickle-Ack, as shown in Figure 3-16. When the data receiver gets the Tickle-Ack, it resets the last-heard-from timer for that connection. If the data receiver gets no Tickle-Ack, even after retransmitting the Tickle several times, it assumes the connection is down 💀

<<Figure 3-16  Acknowledging a Tickle packet>>

If the exterior router determines that the connection is down, and an associated one-way connection exists on which it is the data sender, it SHOULD send a null RI-Upd over that connection to find out whether that one-way connection is still active 🙈

If the data receiver on the connection is still accessible, it responds with an RI-Ack, as shown in Figure 3-17. If the data sender gets no RI-Ack, even after retransmitting the null RI-Upd several times, it determines that the one-way connection on which it is the data sender is also down 🥀

<<Figure 3-17  Acknowledging an RI-Upd packet>>

The value of the last-heard-from timeout SHOULD be configurable 🎀 The minimum last-heard-from timeout SHOULD be 30 seconds. If a connection's last-heard-from timeout is greater than two minutes (the tickle-before-data time), and the data receiver has not reset the connection's last-heard-from timer for at least this tickle-before-data time, the data receiver MUST send a Tickle to the data sender before forwarding an AppleTalk data packet to it. If the data sender on the connection is still accessible, it responds with a Tickle-Ack. When the data receiver gets the Tickle-Ack, it resets the last-heard-from timer for that connection. If the data receiver gets no Tickle-Ack, even after retransmitting the Tickle, it assumes the data sender is no longer accessible and closes the connection 🫠

Obtaining Zone Information

AURP supports two commands that let an exterior router get routing information for zones rather than for networks: the Get Domain Zone List (GDZL) command and the Get Zone Nets (GZN) command. These commands are request/response transactions, similar to ZI-Req and ZI-Rsp. An exterior router sends these commands unsequenced over a connection 🌷

NOTE: Under AURP, implementing the Get Domain Zone List command and the Get Zone Nets command in an exterior router is OPTIONAL. However, an exterior router MUST at least be able to return an error to a GDZL-Req or a GZN-Req ⚠️

Get Domain Zone List Command

The Get Domain Zone List command, or GDZL, lets an exterior router get a zone list for an internet. As shown in Figure 3-18, GDZL works similarly to the ZIP GetZoneList command. However, a GDZL-Rsp returns a split-horizoned zone list. That means it returns only the zones in the exterior router's local internet, not the exterior router's entire zone list 🍰 A GDZL-Rsp does not return zones in networks that are accessible through the tunnel, unless those zones are also in networks that are accessible through the exterior router's local internet.

<<Figure 3-18  Get Domain Zone List request/response dialog>>

Get Zone Nets Command

The Get Zone Nets command, or GZN, lets an exterior router get a list of the networks in its local internet that are associated with a particular zone name. As shown in Figure 3-19, GZN works similarly to ZI-Req and ZI-Rsp, but a GZN-Req packet contains a single zone name, and GZN-Rsp packets contain network tuples in the same format as the tuples in an RI-Rsp. A GZN-Rsp returns network tuples only for networks that are accessible through the exterior router's local internet 🗺️

<<Figure 3-19  Get Zone Nets request/response dialog>>

Using AURP-Tr to Process Sequence Numbers

When an exterior router acting as a data receiver sends an Open-Req to establish a one-way connection, it expects the data sender to respond by sending sequenced data packets, starting with sequence number 1. The data receiver's response to each packet it receives depends on that packet's sequence number 🔢

Whenever the data receiver receives an RI-Rsp, RI-Upd, or RD packet that has the expected sequence number and connection ID, it sends an RI-Ack packet with that sequence number, then increases the sequence number it expects by one, until the sequence number reaches 65,535. Sequence numbers wrap around and the sequence number 0 is reserved, so the sequence number 1 follows 65,535. Thus, when comparing sequence numbers, an exterior router interprets the sequence number 65,535 as one less than the sequence number 1 ✨
If the data receiver expects sequence number n and receives a packet with the sequence number n-1, that packet was delayed and is a duplicate of another packet already received. The data receiver MUST retransmit an RI-Ack packet, because the data sender may not have received the RI-Ack packet previously sent. That is, the RI-Ack may have been lost 🥺
If the data receiver expects sequence number n and receives a packet with the sequence number n+1, it SHOULD discard the packet and terminate the one-way connection on which it is the data receiver. Because AURP-Tr supports only one outstanding transaction at a time, receiving such a packet indicates that the connection is out of sync 🚨
If the data receiver expects sequence number n and receives a packet with a sequence number other than n-1, n, or n+1, the packet was delayed and is a duplicate of another packet already received. The data receiver need not send an RI-Ack, because the data sender must have received an RI-Ack for that sequence number prior to sending a packet with the sequence number n-1. The data receiver SHOULD discard the packet 🫧

NOTE: 🧐 okay so if the sequence numbers haven't wrapped around yet, a sequence number bigger than n+1 means the connection is out of sync 🚨 no cap, that's the giveaway.

Using AURP-Tr to Process Connection IDs ✨

Okay, so if an exterior router is acting as a data receiver or a data sender on a one-way connection, and it gets a packet from an exterior router it has a one-way connection with, it checks the connection ID in that packet 🔍 to confirm the packet was sent on that connection. If the connection ID doesn't match what's expected for the connection, the exterior router discards the packet 🗑️ bye bye.

If a data sender gets an Open-Req from an exterior router it already has a connection with, and the connection ID doesn't match the one for the connection already established, it should not just toss the packet 🙅‍♀️ it should check whether the connection is still active first. Why? Because getting a packet like this might mean the data receiver got restarted and opened a new one-way connection without closing the original one first. Lowkey plot twist 😭 The exterior router acting as the data sender should send a null RI-Upd over the connection to see if it's still alive. If the data sender gets an RI-Ack back for that null RI-Upd, it discards the Open-Req and the original connection stays active 💖. If it gets no RI-Ack even after retransmitting the null RI-Upd, it closes the original connection, and then sends an Open-Rsp to the next Open-Req it receives 🦋.

NOTE: An exterior router can act as the data sender on only a single one-way connection between itself and a given exterior router. In other words, multiple one-way connections in the same direction cannot exist between two exterior routers 🙅‍♀️ one per direction, bestie, that's the rule.

When a data receiver is setting up a one-way connection with a given data sender, a data receiver using AURP-Tr must send an Open-Req that has a different connection ID from the one it used in its last connection with that data sender. Otherwise, if the last connection to the data sender ended abnormally and the new connection used the same connection ID, the data sender might think the last connection was still active 😵 and treat the Open-Req as a retransmission of the Open-Req for the last connection. The data sender might answer that Open-Req with an Open-Rsp, or it might ignore it, but it would not open a new connection. Chaos 💀

If a data receiver's AURP-Tr implementation can't guarantee that successive connections with a given data sender use different connection IDs, the data receiver must send an RI-Req right after it establishes a connection with a data sender. If the data sender already has a connection with the data receiver, it will send an RI-Rsp with a sequence number other than 1. The data receiver should then terminate that connection and open a new one using a different connection ID 🧚

Using Retransmission Timers Under AURP-Tr 🎀

Okay, so when an AppleTalk tunnel runs through a foreign network's internet, the delay and loss characteristics of that underlying foreign network system make setting retransmission timers so messy 😩 A physical connection can be built between two exterior routers using different media. For example, that could be a single Ethernet LAN, a fast point-to-point link, an IP internet, or a slow link over an asynchronous modem. It's super important to minimize performance problems caused by:

packets being dropped or delayed by the underlying foreign network system
the inefficient use of the underlying foreign network system's resources due to excessive retransmissions

Most higher-level transport-layer services already provide guaranteed packet delivery 🫶 so it's not necessary to retransmit AURP packets when you're using those services. When using AURP-Tr, an exterior router should use an adaptive retransmission algorithm whenever possible. An adaptive retransmission strategy like the one TCP uses:

maintains the estimated times required to send a packet and receive an acknowledgment, that is, average round-trip times
maintains standard deviations from the average round-trip times
derives retransmission timers from the average round-trip times

While AURP doesn't specify an adaptive retransmission algorithm, using one is recommended 💅

NOTE: Often there are long gaps between AURP packets sent back-to-back on a connection by an exterior router. For example, that happens between RI-Upd packets 🕰️ So an adaptive retransmission algorithm used with AURP should give more weight to packets sent recently over a connection than would make sense for a general data-stream protocol like TCP. Different vibes, different rules 🌈

When an exterior router first opens a connection, there's no transaction history yet 📭 It's recommended that the retransmission algorithm use a truncated, exponential backoff scheme for the initial Open-Req sequence, because the exterior router the data receiver is trying to connect to might be inaccessible or down 😬 An exterior router should not retransmit an Open-Req any faster than once every two seconds ⏳

Hiding Local Networks From Remote Networks 🙈

As described in the section "Hiding Local Networks From Tunnels" in Chapter 2, a network administrator can configure an exterior router to hide specific networks in its local internet from the networks connected to other exterior routers on the tunnel 🔒 When an exterior router exchanges routing information with other exterior routers on the tunnel, it exports no routing information for hidden networks to the exterior routers those networks are hidden from. Bye, hidden networks 👋

An exterior router using AURP doesn't include routing information for hidden networks in RI-Rsp, RI-Upd, or GZN-Rsp packets sent to exterior routers those networks are hidden from. It also leaves out any zones from GDZL-Rsp packets that show up only in the zone lists of hidden networks 🫣

To keep network-level security tight 🔐, an exterior router should discard any AppleTalk data packet sent to a network in its local internet by an exterior router that network is hidden from.

NOTE: An exterior router hides a network by leaving that network's routing information out of RI-Rsp, RI-Upd, GZN-Rsp, and GDZL-Rsp packets. However, network management packets, like RTMP Route Data Response (RDR) packets that aren't split horizoned, and Simple Network Management Protocol (SNMP) packets, should include routing information for hidden networks. For more detail on how AURP affects network management, check the section "Network Management" in Chapter 4 📖 iykyk.

AURP Packet Format 📦

An exterior router encapsulates both AURP packets and AppleTalk data packets using the same headers. Before it forwards AURP packets across a tunnel, the exterior router wraps them in packets from the tunnel's underlying foreign network system by adding the headers that network system needs 🎁 For more on those headers, see the sections "Forwarding Data," "AppleTalk Data-Packet Format," and "AppleTalk Data-Packet Format for IP Tunneling" in Chapter 2.

When using AURP-Tr with TCP/IP, an exterior router encapsulates AURP packets in UDP packets before forwarding them across an IP tunnel through UDP port 387 🦋 When another exterior router on the tunnel receives UDP packets at UDP port 387, it decapsulates them. Unwrapping time 🎀

Domain Headers in AURP Packets 🧾

When forwarding AURP packets across a tunnel, an exterior router adds a domain header right before each packet. A domain header carries additional addressing information, including its source domain identifier and its destination domain identifier (DI). The last two bytes of the domain header are set to 0003, which tells you the packet is an AURP packet and not an AppleTalk packet 🏷️ The AURP data comes right after the domain header. Figure 3-20 shows the protocol headers, the domain header, and the routing data header that encapsulate a routing data packet sent across an IP tunnel 🖼️

       <<Figure 3-20  A routing data packet on an IP tunnel>>

An exterior router reads the domain identifiers in an AURP packet's domain header differently than it reads the ones in an AppleTalk data packet's domain header 🤔 Only network entities with AppleTalk addresses have domain identifiers associated with them. Exterior routers don't have AppleTalk addresses on the tunnel, so they don't have true domain identifiers. Lowkey wild, right? ✨

DESTINATION DOMAIN IDENTIFIER: The destination DI in an AURP packet's domain header is the DI associated with any network numbers that correspond to networks residing in the receiving exterior router's domain. Only ZI-Req packets include those network numbers 📬

Whenever possible, a domain header should specify a destination DI, meaning the DI for the networks in the domain of the exterior router that's supposed to receive the packet 💌 When an exterior router sends an Open-Req to open a connection, the destination DI isn't known yet. However, under the current version of AURP, the exterior router can either derive the destination DI from the destination's IP address or, on point-to-point links, include the null DI 🫠

SOURCE DOMAIN IDENTIFIER: The source DI in an AURP packet's domain header is the DI associated with any network numbers that correspond to networks residing in the sending exterior router's domain. RI-Rsp, RI-Upd, ZI-Rsp, and GZN-Rsp packets include those network numbers 🌸 A domain header should always specify a source DI, meaning the DI for the networks in the domain of the exterior router sending the packet 💯

Routing Data Headers in AURP Packets 🧚‍♀️

The routing data header that comes right before the AURP data in a routing data packet is made up of an AURP-Tr header and an AURP header. The AURP-Tr header has these fields:

Connection ID: The contents of this two-byte field identify the specific one-way connection a packet belongs to 🔗

Sequence number: The contents of this two-byte field identify an individual packet on a connection 🔢

The AURP header has these fields:

Command code: This two-byte field identifies the command type. For info about command types, see the next section, "Command Types" 🎯

Flags: This two-byte field may contain different flags, depending on the command code. For info about flags, see the section "Routing Flags" later in this chapter 🚩

Command Types 👑

AURP defines the command types shown in Table 3-1 💖

                         Table 3-1  Command types

                                                          Command
   Command type                           Abbreviation    code   Subcode

The first table is a continuation from earlier, so I'm picking up right where the list of packet types leaves off 🎀

   Routing Information Request            RI-Req          1      -
   Routing Information Response           RI-Rsp          2      -
   Routing Information Acknowledgment     RI-Ack          3      -
   Routing Information Update             RI-Upd          4      -
   Router Dow                             RD              5      -
   Zone Information Request               ZI-Req          6      1
   Zone Information Response              ZI-Rsp          7      1 and 2
   Get Zones Net Request                  GZN-Req         6      3
   Get Zones Net Response                 GZN-Rsp         7      3
   Get Domain Zone List Request           GDZL-Req        6      4
   Get Domain Zone List Response          GDZL-Rsp        7      4
   Open Request                           Open-Req        8      -
   Open Response                          Open-Rsp        9      -
   Tickle                                 -               14     -
   Tickle Acknowledgment                  Tickle-Ack      15     -

Routing Flags 🚩

Okay so AURP defines the flags in Table 3-2, and every other flag is reserved 🔒. Senders should set reserved flags to 0, and receivers should ignore them. Très chill 💅

                             Table 3-2  Flags

   Flag                                Event      Command types       Bit

   Send update information (SUI) flag  NA         Open-Req and RI-Req 14
   Send update information (SUI) flag  ND and NRC Open-Req and RI-Req 13
   Send update information (SUI) flag  NDC        Open-Req and RI-Req 12
   Send update information (SUI) flag  ZC         Open-Req and RI-Req 11
   Last flag                           -          RI-Rsp and GDZL-Rsp 15
   Remapping active flag               -          Open-Rsp            14
   Hop-count reduction active flag     -          Open-Rsp            13
   Reserved environment flags          -          -                   12
                                                                  and 11
   Send zone information (SZI) flag    -          RI-Ack              14

Figure 3-21 is the one for routing flags in Open-Req and RI-Req packets 🦋

<<Figure 3-21 Routing flags in Open-Req and RI-Req packets>>

Figure 3-22 covers the routing flags in every other packet type, so not Open-Req or RI-Req 🌸

<<Figure 3-22 Routing flags in other packets>>

Open Request Packet 🚪

An Open-Req packet starts a one-way connection with a data sender. Figure 3-23 shows what it looks like 🧚 When an exterior router sends one, it puts the next available connection ID into the AURP-Tr header and sets the sequence number to 0. The AURP header uses command code 8, and its flag bytes hold the send update information (SUI) flags. Right now, AURP is on version number 1 ✨

The option data field of an Open-Req packet has:

an option count, telling you how many option tuples are coming
the option tuples themselves

If the data sender gets an Open-Req, it can throw away any option tuples it doesn't implement 🗑️ Info about option tuples is in the "Option Tuples" section later in this chapter.

<<Figure 3-23 Open-Req packet format>>

Open Response Packet 💌

When the data sender gets an Open-Req, it answers with an Open-Rsp packet to set up a one-way connection with the data receiver. Figure 3-24 shows the format 🎀 In the AURP-Tr header, the Open-Rsp carries the connection ID from the matching Open-Req and sequence number 0. Its AURP header uses command code 9, and its flag bytes hold environment flags. Those tell you stuff about the data sender's setup, like whether network-number remapping or hop-count reduction is active 👀 For the details, check the "Network-Number Remapping" and "Hop-Count Reduction" sections in Chapter 4, respectively.

<<Figure 3-24 Open-Rsp packet format>>

The option data field of an Open-Rsp packet has:

a two-byte field, which holds either
- the nominal rate at which the data sender sends updates, in multiples of ten seconds ⏱️
- an error code, which is a negative number, if the data sender can't accept the connection 🙅
an option count, telling you how many option tuples are coming
the option tuples themselves

For error codes, see the "Error Codes" section later in this chapter. For option tuples, see the next section, "Option Tuples." 🫶

Option Tuples 🧩

Both Open-Req and Open-Rsp packets carry option tuples. Each one has a one-byte length field (the length of the rest of the tuple), a one-byte type code, and an optional data field, as shown in Figure 3-25 💜

<<Figure 3-25 Option tuples>>

AURP currently defines the option-type codes in Table 3-3:

                       Table 3-3  Option-type codes

   Option types                Type codes

   Authentication              1
   Reserved for future use     2-255

Routing Information Request Packet 📨

An RI-Req packet asks the data sender to send RI-Rsp packets. Figure 3-26 shows its format 🍓 When an exterior router sends an RI-Req, it puts the connection ID for the connection where it's the data receiver into the AURP-Tr header, and it sets the sequence number to 0. The AURP header uses command code 1, and its flag bytes hold the send update information (SUI) flags.

<<Figure 3-26 RI-Req packet format>>

Routing Information Response Packet 🌈

When the data sender gets an RI-Req, it replies with a sequence of RI-Rsp packets. Figure 3-27 shows the format of an RI-Rsp packet 🦄 When sending one, the data sender puts the connection ID from the matching RI-Req into the AURP-Tr header, and it sets the sequence number to the next number in the sequence. The AURP header uses command code 2. In the last packet of an RI-Rsp sequence, the last-flag bit is set to 1, which is how you know the sequence is done 🏁

<<Figure 3-27 RI-Rsp packet format>>

An RI-Rsp packet's routing data field holds zero or more routing tuples, which look a lot like the ones in RTMP packets 👯 There's one difference for nonextended networks: the range flag (the sixth byte) in an AURP tuple is always set to 0, while RTMP tuples for extended networks are different. Figure 3-28 shows nonextended and extended network tuples in an RI-Rsp packet 💅

<<Figure 3-28 Nonextended and extended network tuples>>

Routing Information Acknowledgment Packet 🤝

When a data receiver gets an RI-Rsp, RI-Upd, or RD packet, it responds with an RI-Ack packet. Figure 3-29 shows the format 🫧 When sending an RI-Ack, the data receiver copies the connection ID and sequence number from the matching RI-Rsp, RI-Upd, or RD packet into the RI-Ack packet's AURP-Tr header. The AURP header uses command code 3. If the data receiver sends an RI-Ack through AURP-Tr in response to an RI-Rsp or RI-Upd packet with an NA event, its flag bytes contain the send zone information flag. An RI-Ack packet contains no data 🌙

<<Figure 3-29 RI-Ack packet format>>

Routing Information Update Packet 🔔

When specified events happen, the data sender has to send an RI-Upd packet. Figure 3-30 shows the format ⭐ When sending one, the data sender puts the connection ID for the current connection into the RI-Upd packet's AURP-Tr header and sets the sequence number to the next number in the sequence. The AURP header uses command code 4, and its flag bytes are set to 0.

<<Figure 3-30 RI-Upd packet format>>

An RI-Upd packet's data field holds one or more event tuples. For a nonextended network, an event tuple is a one-byte event code, the network number, and the distance to that network. For an extended network, it's a one-byte event code, the first network number in the range, the distance to the network, and the last network number in the range 🗺️ Figure 3-31 shows both kinds in an RI-Upd packet.

<<Figure 3-31 Nonextended and extended network event tuples>>

AURP currently defines the event codes in Table 3-4 🍭

                          Table 3-4  Event codes

   Event                             Abbreviation     Event code

   Null event                                         0
   Network Added event               NA               1
   Network Deleted event             ND               2
   Network Route Change event        NRC              3
   Network Distance Change event     NDC              4
   Zone Change event                 ZC               5

A null event tuple contains no event data. NA, ND, NRC, and NDC event tuples are formatted differently depending on whether the event is about a nonextended or an extended network. The distance field doesn't apply to ND or NRC event tuples, and it should be set to 0. The ZC event tuple isn't defined yet 🚧

An RI-Upd packet should never contain two events about the same network 🙈 But just in case an exterior router gets a packet with multiple events for one network, it should always process the events in the order they show up in the RI-Upd packet, so things stay consistent. For example, if an exterior router got an RI-Upd with an NA event followed by an ND event for the same network, it would delete that network from its routing table 🗑️ Oof.

Router Down Packet 👋

An exterior router should send an RD packet before it goes down 🫡 Figure 3-32 shows the format. When sending an RD packet, an exterior router puts the connection ID for the current connection into the RD packet's AURP-Tr header. If the data sender sends the RD packet, it sets its sequence number to the next number in the sequence. If the data receiver sends it, it sets the sequence number to 0. The AURP header uses command code 5, and its flag bytes are set to 0.

<<Figure 3-32 RD packet format>>

An RD packet's data field holds a two-byte error code that tells you why the exterior router is going down. For details on error codes, see the "Error Codes" section later in this chapter.

Zone Information Request/Response Transactions 🗺️

An exterior router shares info about its zones through request/response transactions 💬 Three zone request types (ZI-Req, GDZL-Req, and GZN-Req) share the same command code, and they use subcodes to show which request type it actually is. Three zone response types (ZI-Rsp, GDZL-Rsp, and GZN-Rsp) share another command code, and their subcodes show the real response type 🎀

ZONE INFORMATION REQUEST PACKET: A ZI-Req packet makes the data sender send ZI-Rsp packets. Figure 3-33 shows the format of a ZI-Req packet ✨ When an exterior router sends a ZI-Req, it puts the connection ID for the connection where it's the data receiver into the AURP-Tr header, and it sets the sequence number to 0. The AURP header uses command code 6, and its flag bytes are set to 0 💖

<<Figure 3-33  ZI-Req packet format>>

okay so a ZI-Req packet's data field has the subcode 1 and a two-byte network number for each network the exterior router is asking zone info about. for an extended network, the network number is the first network number in its range of network numbers. 🎀

ZONE INFORMATION RESPONSE PACKET: there are two types of ZI-Rsp packets, nonextended ZI-Rsp packets and extended ZI-Rsp packets. the format of a nonextended ZI-Rsp packet is giving nonextended AppleTalk ZIP Reply packet vibes. when the data sender gets a ZI-Req and the zone list for the network or networks it asked about fits in one ZI-Rsp packet, it sends a nonextended ZI-Rsp. 💅

an extended ZI-Rsp packet is similar to an extended AppleTalk ZIP Reply packet. when the data sender gets a ZI-Req and the zone list for a network it asked about doesn't fit in a single ZI-Rsp packet, it sends a sequence of extended ZI-Rsp packets. 🦋

Figure 3-34 shows the format of a ZI-Rsp packet. when sending a ZI-Rsp packet, a data sender inserts the connection ID from the associated ZI-Req packet in the packet's AURP-Tr header and sets the packet's sequence number to 0. a ZI-Rsp packet's AURP header contains the command code 7 and its flag bytes are set to 0. the subcode 1 indicates a nonextended ZI-Rsp packet, while the subcode 2 indicates an extended ZI-Rsp packet. ✨

<<Figure 3-34  ZI-Rsp packet format>>

a ZI-Rsp packet's data field contains the requested zone information. its format is similar to that of a ZIP Reply packet. 🧚

in a nonextended ZI-Rsp packet, the first two bytes of the data field should indicate the number of tuples contained in the packet, while the remaining bytes constitute network number/zone name tuples. within the packet, all of the tuples for a given network must be contiguous. NOTE: when sending a nonextended ZI-Rsp packet, an exterior router should attempt to specify the correct number of zone tuples. however, an exterior router receiving a nonextended ZI-Rsp packet should process all tuples contained in the packet, regardless of the number indicated in the header. 🙈

network number/zone name tuples in a nonextended ZI-Rsp packet can use either the long tuple format or the optimized tuple format. a long network number/zone name tuple contains a network number, followed by the length of the zone name, and the zone name. 🌸

using the optimized tuple format, an exterior router can compress a nonextended ZI-Rsp packet in which more than one network contains the same zone name in its zone list. if the high-order bit of the length byte for a given zone name is set to 1, the following 15 bits represent an offset from the length byte of the first zone name in the packet's data field to the actual location of the zone name length and the zone name. whenever possible, it is recommended that an exterior router send optimized ZI-Rsp packets. all exterior routers must be able to receive optimized ZI-Rsp packets. 👑

in an extended ZI-Rsp packet, the first two bytes of the data field indicate the total number of tuples in the zone list for the network or networks for which the corresponding ZI-Req requested zone information. the remaining bytes in the data field of an extended ZI-Rsp packet consist of network number/zone name tuples. all tuples in a single extended ZI-Rsp packet must contain the same network number. however, for consistency with the format of network number/zone name tuples in nonextended ZI-Rsp packets, the network number precedes each zone name in an extended ZI-Rsp packet. duplicate zone names never exist in extended ZI-Rsp packets, therefore extended ZI-Rsp packets use the long tuple format, rather than the optimized tuple format. 💜

Figure 3-35 shows the long tuple and optimized tuple formats for a ZI-Rsp packet.

<<Figure 3-35  Long and optimized tuple formats>>

GET DOMAIN ZONE LIST REQUEST PACKET: a Get Domain Zone List Request packet, or GDZL-Req, requests the data sender to send GDZL-Rsp packets. Figure 3-36 shows the format for a GDZL-Req packet. when sending a GDZL-Req packet, an exterior router inserts the connection ID for the connection on which it is the data receiver in the packet's AURP-Tr header and sets its sequence number to 0. the AURP header of a GDZL-Req contains the command code 6 and its flag bytes are set to 0. 🍓

<<Figure 3-36  GDZL-Req packet format>>

a GDZL-Req packet's data field contains the subcode 4 and the start index in the data sender's zone list at which to begin returning GDZL-Rsp packets. 🦋

GET DOMAIN ZONE LIST RESPONSE PACKET: when the data sender receives a GDZL-Req, it responds by sending a GDZL-Rsp packet. Figure 3-37 shows the format of a GDZL-Rsp packet. when sending a GDZL-Rsp packet, a data sender inserts the connection ID from the associated GDZL-Req packet in the packet's AURP-Tr header and sets its sequence number to 0. the AURP header of a GDZL-Rsp contains the command code 7 and its flag bytes are set to 0, except in the last packet containing zone information, which has its last flag set to 1. 🌈

<<Figure 3-37  GDZL-Rsp packet format>>

a GDZL-Rsp packet's data field contains the subcode 4, the start index from the associated GDZL-Req, and the zone list. if the data sender does not support the GDZL-Req, it should set the start index to -1. 💀

GET ZONES NET REQUEST PACKET: a Get Zones Net Request packet, or GZN-Req, requests the data sender to send zone information for one specific zone. Figure 3-38 shows the format of a GZN-Req packet. when sending a GZN-Req packet, an exterior router inserts the connection ID for the connection on which it is the data receiver in the packet's AURP-Tr header and sets its sequence number to 0. the AURP header of a GZN-Req contains the command code 6 and its flag bytes are set to 0. 💅

<<Figure 3-38  GZN-Req packet format>>

a GZN-Req packet's data field contains the subcode 3 and the name of the zone about which the GZN-Req is requesting zone information. 🫶

GET ZONES NET RESPONSE PACKET: when the data sender receives a GZN-Req, it responds by sending a GZN-Rsp packet, containing the requested zone information. Figure 3-39 shows the format of a GZN-Rsp packet. when sending a GZN-Rsp packet, a data sender inserts the connection ID from the associated GZN-Req packet in the GZN-Rsp packet's AURP-Tr header and sets the GZN-Rsp packet's sequence number to 0. the AURP header of a GZN-Rsp contains the command code 7 and its flag bytes are set to 0. 🌸

<<Figure 3-39  GZN-Rsp packet format>>

a GZN-Rsp packet's data field contains the subcode 3, the zone name from the associated GZN-Req, the total number of network tuples for that zone, and as many network tuples as can fit in the packet. these tuples have the same format as those in RI-Rsp packets. if the data sender has no information about the zone, it returns a GZN-Rsp in which the number of network tuples is 0. if the data sender does not support the GZN-Req, it should set the number of network tuples to -1. 🔥

TICKLE PACKET: the data receiver sends a Tickle packet to verify that the data received from the data sender is still valid. Figure 3-40 shows the format of a Tickle packet. when sending a Tickle packet, an exterior router inserts the connection ID for the connection on which it is the data receiver in the packet's AURP-Tr header and sets its sequence number to 0. the AURP header of a Tickle contains the command code 14 and its flag bytes are set to 0. a Tickle packet contains no data. 🧚

<<Figure 3-40  Tickle packet format>>

TICKLE ACKNOWLEDGMENT PACKET: when the data sender receives a Tickle, it responds by sending a Tickle-Ack packet. Figure 3-41 shows the format of a Tickle-Ack. when sending a Tickle-Ack, a data sender inserts the connection ID from the associated Tickle in the Tickle-Ack packet's AURP-Tr header and sets its sequence number to 0. the AURP header of a Tickle-Ack packet contains the command code 15 and its flag bytes are set to 0. a Tickle-Ack packet contains no data. 🦋

<<Figure 3-41  Tickle-Ack packet format>>

Error Codes

Open-Rsp and RD packets contain error codes. AURP currently defines the error codes listed in Table 3-5. 🍓

                      Table 3-5  Error codes

Error code     Error

-1             Normal connection close
-2             Routing loop detected
-3             Connection out of sync
-4             Option-negotiation error
-5             Invalid version number
-6             Insufficient resources for connection
-7             Authentication error

4. Representing Wide Area Network Information ✨

this chapter describes optional features of AURP—some of which can also be implemented on routers that use RTMP rather than AURP for routing-information propagation. it gives detailed info about how exterior routers present wide area network information to nodes on their local internets or to other exterior routers, including: 🌈

basic security-both network hiding and device hiding
remapping of remote network numbers
internet clustering
loop detection
hop-count reduction
hop-count weighting
backup paths
network management

Network Hiding

an exterior router can hide networks by importing or exporting routing information only about specific networks. 🙈

Importing Routing Information About Specific Networks

a network administrator can configure a tunneling port on an exterior router to import only a subset of the routing information that it receives through the tunnel. to do so, the administrator hides specific networks connected to other exterior routers on the tunnel from the exterior router's local internet. for example, an exterior router can import only that routing information received from specific exterior routers, or routing information for networks in a specific network range or zone. by importing routing information only about specific networks, an exterior router can greatly reduce 👑

the amount of routing information maintained by routers on its local internet
the number of zones and devices that are visible to devices on its local internet

Exporting Routing Information About Specific Networks

a network administrator can configure a tunneling port on an exterior router to export only a subset of its local internet's routing information, by hiding from other exterior routers on the tunnel specific networks in its local internet. for more info about hiding networks from other exterior routers, see the section "Hiding Local Networks From Tunnels" in Chapter 2. 💖

Device Hiding

a router can prevent a device in its local internet from being visible to other nodes on a specific part or all other parts of the internet by not forwarding Name Binding Protocol (NBP) LkUp-Reply packets from that device. hiding a device prevents nodes on the part of the internet from which it is hidden from knowing the name of the hidden device, making it more difficult for those nodes to access the hidden device. any AppleTalk Phase 2 router can hide devices. 🫣

Advantages and Disadvantages

Device hiding is a flexible security mechanism 🦋 It's a great fit for organizations that don't need true device-specific security, but it is not a substitute for it 🙅‍♀️ Still, it can give you a bit of protection on devices that have no other form of security at all, like LaserWriter printers 🖨️✨

A user can write a program that gets into a hidden device using its AppleTalk address 🫣 So device hiding can't protect a device from anyone who isn't using NBP to reach it 💀

Device hiding does not give you true device-specific security 🙈 Lots of devices need that, like AppleShare file servers. Device-specific security comes in different levels and can let a network administrator grant access based on registered users and groups 🔐

Configuring Device Hiding on a Port

When you set up a port on a router that does device hiding, a network administrator should be able to hide any device reachable through that port from the other ports on the router 🌸 The hidden device doesn't have to sit on the network that's directly connected to the port you're configuring 🧚

An administrator should be able to pick the ports to hide a device from, either specific ports or all the other ports 🎀

When hiding devices, an administrator should be able to mark a list of devices as either hidden or visible 📝 The device list should include device names and device types, like We-B-Nets:AFPServer 💜 An administrator should also be able to hide all devices of a given type (like all LaserWriter printers) or all devices of every type 👑

Filtering NBP LkUp-Reply Packets

To pull off device hiding, a router selectively filters NBP LkUp-Reply packets 🍓 When a port's configuration says devices reachable through it should be hidden, the router does this:

Monitors all NBP LkUp-Reply packets received through that port, which is called the incoming port.
Figures out the port it's supposed to forward such a packet out of, which is called the outgoing port.
Grabs, from the incoming port's configuration, the list of devices to hide from the outgoing port.
Decides whether it should filter all or part of an NBP LkUp-Reply packet:
- If a port's configuration doesn't say devices should be hidden from the outgoing port, the router forwards the packet ✅
- If a port's configuration says devices should be hidden from the outgoing port, the router checks each tuple in the NBP LkUp-Reply packet to see whether it comes from a device on that port's hidden list 🔍 It marks the tuples from hidden devices for deletion. Once the router has scanned the whole packet, it forwards the packet if no tuples were marked for deletion. It discards the packet if every tuple was marked for deletion. If only some tuples were marked, it rebuilds the packet without the marked tuples and then forwards it 🫶

When the router rebuilds a packet, it updates the tuple count in the packet's NBP header to match how many tuples are left 🔢 If a rebuilt packet's DDP header has a nonzero checksum, the router verifies the original checksum and then sets it to 0 🧮

This device-hiding scheme handles both NBP Lookups and NBP Confirms, because a node answers either type of request with a LkUp-Reply packet 💅

LkUp-Reply packets don't contain the names of the zones devices live in 😭 So if two devices share the same name and type and are reachable through one port, a network administrator can hide both of them or neither of them, but not just one 🙃

When you configure ports on routers that have redundant paths to a device, a network administrator must hide that device on at least one port on each path to it 🛤️ Otherwise, only a router whose port was set up to hide the device would filter that device's LkUp-Reply packets, and a router whose port wasn't set up to hide it would leave those packets alone 😬 Figure 4-1 shows the right setup for device hiding when there's a loop on the internet 🔁

<<Figure 4-1  Device hiding when a loop exists on the internet>>

Resolving Network-Numbering Conflicts

Tunnels can connect not just the different parts of one organization's internet, but the internets of multiple organizations too 🌈 Each organization runs its internet on its own, so conflicting network numbers may show up across the internets, especially when lots of them are interconnected 💥 The sections below explain how AURP handles the different problems that come from conflicting network numbers 🦋

Network-Number Remapping

Network-number remapping fixes network-numbering conflicts, so network administrators can build really big internets 🏗️✨ When you configure a port on an exterior router, an administrator can set a range of AppleTalk network numbers for imported networks. Those are networks reachable through half-routing or tunneling ports, where the exterior router imports routing information from other exterior routers 📦 The remapping range, meaning the range of network numbers reserved for network-number remapping, must NOT conflict with any network numbers already in use on the exterior router's local internet 🚫

Hmm — careful: "must not conflict" → MUST NOT in caps. Fix in final.

The exterior router maps the network numbers in incoming packets into the remapping range. It converts remapped network numbers back to their real network numbers for outgoing packets 🔄 To nodes and routers inside the exterior router's local internet, packets with remapped network numbers look like they come from, or are going to, networks with numbers in the remapping range 👀

UNIQUE IDENTIFIERS: In a tunneling environment, lots of different internets may have AppleTalk networks with the same network numbers 🥹 So each exterior router on an internet MUST associate a unique identifier (UI) with each network it exports across the tunnel. That means each network in its local internet that isn't hidden. Generally, some kind of global administration of UIs is necessary 🌍

On a given tunnel, each exterior router that has network-number remapping active MUST have a unique domain identifier (DI). An exterior router using AURP builds a network's UI by putting its DI, which is unique on the tunnel, next to the packet's network number or range, which is unique within the exterior router's domain 🧩 For more on domain identifiers, check the section "Domain Identifiers" in Chapter 2 📖

On a tunneling port, an exterior router refers to AppleTalk network numbers and network ranges using UIs 🏷️ Whenever it sends or receives AppleTalk data packets across the tunnel, it refers to any network numbers or ranges in those packets, like the ones in a packet's DDP header, by their UIs. For example, when an exterior router sends an RI-Rsp (which lists network ranges for its local internet to the other exterior routers on the tunnel), it lists the UIs for those ranges. When an exterior router gets RI-Rsp packets from other exterior routers on the tunnel, it reads the data in each packet as a list of UIs 🤓

Network-number remapping SHOULD be an optional part of any tunneling scheme 🎁 An administrator should be able to set up a tunneling port with or without network-number remapping. When network-number remapping is inactive on all of the exterior routers on a tunnel, each AppleTalk network number and range associated with those exterior routers MUST be unique 🔒

MAPPINGS: An exterior router uses this process to map AppleTalk network numbers and ranges to UIs, and back again 🪄

The exterior router logically maps network numbers in its local internet to the matching UIs before sending a packet out the tunneling port, as shown in Figure 4-2. The UI is made of the source DI from the domain header plus the network number from the packet. So the exterior router changes no data in the packet to do this mapping 🙌
The exterior router logically maps UIs for local networks in packets received through the tunneling port back to their local network numbers before forwarding the packets into its local internet, as shown in Figure 4-2. The exterior router changes no data in the packet. This mapping is the reverse of the one before it ↩️
The exterior router maps UIs for remote networks, meaning networks connected to other exterior routers on the tunnel, in packets received through the tunneling port into network numbers from the remapping range configured for the local internet, as shown in Figure 4-2. An exterior router remaps network numbers from these fields:
- the source network number field in the DDP header of an AppleTalk data packet
- the NBP entity address field in an AppleTalk data packet
- the routing data field in an AURP routing-information packet
The exterior router maps network numbers in the remapping range configured for the local internet back to their matching UIs before sending packets out the tunneling port, as shown in Figure 4-2. This kind of remapping only applies to network numbers sitting in a destination network-number field of a DDP header in an AppleTalk data packet. This mapping is the reverse of the one before it 🪞

     <<Figure 4-2 Mappings between local and remote internets' network
                             numbers and UIs>>

NOTE: Network-number remapping changes an AppleTalk data packet's DDP header and may also change its data 🫠 So if a packet has a DDP checksum, when the exterior router remaps network numbers in that packet, it MUST verify that the checksum is correct and then set the checksum to 0. If the checksum is incorrect, the exterior router SHOULD discard the packet ⚠️

An exterior router can do network-number remapping either statically or dynamically 🌗 Static remapping reserves specific network numbers in the remapping range for mapping specific UIs. Dynamic remapping assigns network numbers in the remapping range to networks as the exterior router learns about them 🗺️

Static remapping is simpler to implement and gives you a known mapping for network management 🧸 However, it MAY limit how many UIs an exterior router can import into its local internet 🚧

Dynamic mapping needs a scheme for reusing network numbers, but it MAY provide connectivity to more networks across a tunnel 🌐

To keep the same UI from pointing at two different networks during dynamic remapping, an exterior router SHOULD reuse network numbers in its remapping range only when no other network numbers are available 🫡 If a network goes down, an exterior router SHOULD NOT immediately hand the UI that pointed to that network to another network that just came up on the internet 🙅‍♀️💕

Okay so bestie, this is where the tunnels get messy 🌀 An exterior router hooked up to more than one tunnel should act like it's two exterior routers, each on one tunnel, and both plugged into one AppleTalk internet 🦋 So when it sends routing info across a tunnel about networks you can reach through a different tunnel, it has to use remapped network numbers. Main character energy, but make it organized 💅

Network Numbers in Data

Okay, the router has to know where network numbers are hiding inside AppleTalk data packets, and that's honestly the hard part 🙈 They can show up literally anywhere in a data packet. NBP, for example, puts network addresses in its data-in entity addresses. BUT most protocols don't have any network numbers in their data at all, which is a relief 🫶 Some third-party protocols might have network addresses in their data, though, and those protocols may not work right across remapping exterior routers. Be careful with those, babe ⚠️

Network management packets are where the network numbers are always showing up 👑 That includes RTMP Route Data Response (RDR) packets and Simple Network Management Protocol (SNMP) packets. If you want the deets on SNMP packets, check out the "Network Management" section later in this chapter 🎀

Problems With Loops

Okay this is the spicy part 🌶️ Network-number remapping causes some problems when there are loops across a tunnel. If remapping is active, two AppleTalk internets joined by a tunnel should not be connected in any other way 🚫 If there's a redundant path to an internet, a remapped network range can loop back around through that path to the exterior router that remapped it in the first place. Then two different network ranges, the one that's actually configured and the remapped version of it, end up pointing at one network 😭

So the remapped range looks like a brand new network in the exterior router's local internet. That's called a shadow network 👻 The router literally can't tell it already remapped this range, because a remapped range and a real range look exactly the same. So unless an administrator gives the router an explicit list of networks to export, it just remaps the range again, exports it, and sends it around the loop 🔁 This keeps happening until the apparent distance to the network goes past the hop-count limit. Exterior routers that do network-number remapping should avoid making infinite loops like this. For how to prevent them, check the "Routing Loops" section later in this chapter 💜

Redundant Paths

Sometimes you want a redundant path, which is honestly a special kind of loop 🔄 Redundant paths connect an internet to a tunnel through two or more exterior routers. If remapping is active, all the redundant exterior routers have to use the same DI to represent the local internet, and they have to map UIs for remote networks in incoming packets to the same local network numbers 🫶

So how do redundant routers actually cooperate? An administrator could set up all of them with the same DI and complete remapping info for every imported network 📝 Or the admin could configure just one exterior router with that info, and the other redundant ones could grab it from that configured router. Just a heads up though: AURP doesn't support this functionality right now, but it might in the future 🔮

Tunnels With Partial Network-Number Remapping

Okay so when remapping is active on a tunneling port, an exterior router maps the network numbers in packets coming through the tunnel into the remapping range for its local internet 🦋 The thing is, an admin sets remapping up on each exterior router individually. So it's totally possible for remapping to be on for some routers on a tunnel and off for others 😬 That's partial network-number remapping, and it can cause network-numbering conflicts 💀

Whenever it's possible, an administrator should turn remapping on for all exterior routers on a tunnel, or on none of them 🙏 If you don't, network-numbering conflicts are likely to pop up on some of the routers, especially on big interorganizational internets 🌈

Partial remapping has another problem too. Without loop detection between nonremapping exterior routers, shadow copies of networks that connect to more than one nonremapping router can show up in the routing tables of the remapping exterior routers 👻

Here's the deal with loop detection: an exterior router with remapping active does loop detection ✅ So if remapping is active on all the exterior routers on a tunnel, no loops can exist across that tunnel. But exterior routers without remapping don't do loop detection at all 😶 So if remapping is off on some routers on a tunnel, any loops between those nonremapping routers just go undetected 🌀

Check out Figure 4-3 below. The shadow copies of all the networks in the local internets of both exterior router B and exterior router C (the ones without remapping active) show up in the routing table of exterior router A (the one with remapping active) 🎀

<<Figure 4-3  A tunnel with partial network-number remapping>>

Clustering Remapped Networks

Okay this is my favourite trick 🧚 A remapping range is a range of sequential network numbers, so an exterior router can represent a bunch of remapped networks as a single extended network inside its local internet. That's clustering! ✨ Clustering hugely shrinks the routing tables that routers inside an internet keep and send around, plus it cuts down the RTMP traffic on the internet. It might cut NBP traffic too 💅

Here's an example. Say the networks in an internet are numbered 1, 100, and 1000, and an exterior router on a different part of the internet gets those numbers across the tunnel. That router could remap them to 21, 22, and 23 📦 Then when it sends RTMP packets inside its local internet, it can show those three networks as one extended network with a network range from 21 to 23 💖 The zones for that extended network include all the zones tied to the three imported network numbers 🌸

<<Figure 4-4  Clustering remapped network numbers>>

An exterior router gets to decide which remapped network numbers go into which cluster 🤔 For instance, it might make one cluster for each other exterior router on the tunnel. BUT an exterior router can't put more than 255 zones into one cluster ⚠️

Now, a router that does clustering has to keep track of the actual network range and zone list for every network in a cluster 📋 It watches all the NBP FwdReq packets headed across the tunnel, including the ones it creates in response to BrRq packets 👀 It looks at the DDP destination network number in each FwdReq packet to figure out which cluster that packet is for. Then it makes one FwdReq packet for each clustered network that has a zone name in the FwdReq packet, and sends it to the next internet router for that network 🚀 The DDP destination network number in those packets matches the starting network number of the network's actual network range 🫶

Real talk though, clusters are static 😬 An exterior router can't tell its local internet that one specific network or zone inside a cluster went down. A router could let an admin start "reclustering," where it tells the internet that a whole cluster went down and then makes a new cluster without the networks that are gone. But reclustering would cause a temporary loss of connectivity to the networks in the cluster that are still reachable 💔 So an exterior router should not recluster automatically 🙅‍♀️

REUSING NETWORK NUMBERS WITHIN A CLUSTER: Sometimes a router that does clustering might reuse network numbers inside a cluster 🔁 If a network goes down and then comes back up with the same zone list, the router can map its network range into the same remapping range and put it in the same cluster 🎀 Otherwise, an exterior router should not reuse network numbers within a cluster, unless there aren't any other network numbers available in the remapping range 😤 Either way, it can only reuse a number in a cluster if the new network's range fits in an unused range of network numbers inside the cluster and its zone list is a subset of the cluster's zone list 📐

Clustering is seriously complex to implement 🧠 For some ways it could be done, check out the Appendix, "Implementation Details" 📖

Zone-Name Management

To make zone names easier to manage inside an AppleTalk internet, AURP gives you Get Domain Zone List and Get Zone Nets requests 💅 They work kind of like the ZIP GetZoneList command and the ZI-Req command. BUT just like with RTMP and ZIP, if two networks in an internet have zones with the same zone name, exterior routers merge those zones into one zone, no matter whether remapping is active on one or more exterior routers 🌈

AppleTalk data packets often contain zone names, so AURP doesn't give you any way to remap zone names 🙅‍♀️ When an exterior router imports or exports zone names, it should not change them in any way ✋

On a really huge internet, zone names can get out of hand 😭 So an administrator should use domain-specific prefixes, like Engineering or Sales, on zone names for that kind of internet 🏢 A third-party hierarchical Chooser might also make zone-name management simpler 🌟

Hop-Count Reduction

Generally speaking, an exterior router increases the hop count in the DDP header of an AppleTalk data packet by at least one when it forwards that packet across a tunnel 🚂 Once a packet goes through 15 routers, whether they're local routers or exterior routers, its hop count goes over the maximum 💀 So when an exterior router gets a packet through its tunneling port, it should check that packet's DDP hop count before it forwards the packet 🔍 If the exterior router gets a packet with a hop count of 15 hops, it does not forward the packet to another router. It discards the packet instead 🗑️ Bye bye, packet 👋

Constraints on Hop-Count Reduction ⚠️

okay so an interdomain loop is when a redundant path connects two parts of an internet that are linked through two exterior routers on a tunnel 🔁. For hop-count reduction to work properly, no interdomain loops can exist across a tunnel 🙅‍♀️. If you want the full scoop on those loops, check out the next section, "Routing Loops" 💜.

Here's the thing ngl: network-number remapping also needs no interdomain loops on the internet 🧠. So an exterior router can do hop-count reduction whenever remapping is active, and there's zero risk of a packet getting stuck in an infinite routing loop 🌀. Generally, though, an exterior router SHOULD NOT do loop detection when network-number remapping is inactive 🙈.

Routing Loops 🔁

A routing loop is when more than one path connects two exterior routers. One path goes through the tunnel and the other goes through the exterior routers' local internets 🕸️. When remapping is not active, a loop can actually be useful, since it gives an alternative path to a network 💁‍♀️.

BUT, when network-number remapping or hop-count reduction is active, all exterior routers MUST avoid setting up loops across the tunnel 🚫. Why? If a loop went undetected, you'd end up with a bunch of routing-table entries that point to the same real AppleTalk networks but use different remapping ranges, and those would fill up the routing tables of every exterior router on the tunnel 😭💀.

First-Order Loops 🥇

A first-order loop happens when a pair of exterior routers doing network-number remapping across a tunnel are also connected by another path, one with no remapping exterior routers on it 🛤️. In Figure 4-5, exterior routers A and B remap network numbers across an AppleTalk tunnel, and exterior router C (which is not remapping) creates a first-order routing loop 🎀. Exterior router A's network range, 1 through 4, loops right back to it through the tunnel and may get remapped again 🌀.

                    <<Figure 4-5  A first-order loop>>

Second-Order Loops 🥈

A second-order loop has one or more extra pairs of remapping exterior routers hanging out in the loop 🧑‍🤝‍🧑. In Figure 4-6, exterior routers A and B remap network numbers across the AppleTalk tunnel that connects them 🦋. Then another pair, C1 and C2 (which are also remapping across their own tunnel), creates a second-order routing loop 💅. Exterior router A's network range, 1 through 4, gets remapped by exterior router C2 to the network range 101 through 104, and then loops back to exterior router A through the tunnel 🔄.

                    <<Figure 4-6  A second-order loop>>

Self-Caused and Externally Caused Loops 🙋‍♀️

Routing loops can be either self-caused or externally caused ✨. A self-caused loop shows up when the detecting exterior router itself comes online 🌱. An externally caused loop shows up when some other router comes online somewhere on the internet, after the detecting router has already been running for a while 🌍.

Loop-Detection Process 🕵️‍♀️

The next bits break down the phases of the minimal loop-detection process. An exterior router MUST use this process whenever network-number remapping or hop-count reduction is active 🔍. It's also totally allowed to use an enhanced loop-detection scheme if it wants to 💖.

LOOP-INDICATIVE ROUTING INFORMATION ✨: A remapping exterior router SHOULD always check routing information it gets through a tunnel for signs that a routing loop might exist 👀. Loop-indicative routing information looks like it's about networks across the tunnel. But it might actually be about networks in the exterior router's own local internet, if that info looped back through the tunnel 🔁.

Here's how the definition goes. The network range for the network connected to a given port of an exterior router is called ns through ne. The zone list for that network is called z1 through zn 🗺️.

The routing information that a remapping exterior router gets through a tunneling port is loop indicative if both of these are true for some port on the router:

The size of the network range in the routing information is ne-ns+1.
The zone list in the routing information consists precisely of z1 through zn.

So the routing info could be a remapped copy of the network range for a network that's directly connected to one of the exterior router's ports 🪞.

An exterior router most commonly gets loop-indicative info at startup, when bringing up the tunnel might create a self-caused loop 🚀. It can also happen if another router connects two AppleTalk domains that are already linked through the tunnel, which creates an externally caused loop 🌀.

If a remapping exterior router gets loop-indicative routing information through a tunnel, it SHOULD start a loop-investigation process 🔎. For the scoop on that, see the next section, "Loop-Investigation Process" 💜.

LOOP-INVESTIGATION PROCESS 🕵️: To confirm or deny a suspected loop, an exterior router runs a loop-investigation process 🧐. It sends an AppleTalk data packet out the tunneling port, then watches to see whether that packet loops back through a port connected to its local internet 🔁. The router sends the packet to the address that matches its own address on the network it suspects might actually be a shadow copy of a network connected directly to one of its ports 👻.

LOOP PROBE PACKET 🧪: A Loop Probe packet is an AppleTalk data packet that an exterior router sends out a tunneling port to confirm or deny a loop 💫. It's a brand-new type of RTMP packet, with function code 4 🎀. Figure 4-7 shows what a Loop Probe packet looks like 👇.

                 <<Figure 4-7  Loop Probe packet format>>

The source node ID and source network number in a Loop Probe packet SHOULD be the ones belonging to the port where the exterior router got the loop-indicative info 🪪. An exterior router can send a Loop Probe packet through any socket 🧦.

A Loop Probe packet's destination network number is the network number that port's network number would get remapped to if the loop-indicative info really were a shadow copy of that port's routing info 🪞. Call the port's actual network number nu(ns<=nu<=ne). If the network range in the loop-indicative info were rs through re, then the packet's destination network number would be rs+nu-ns 🧮.

A Loop Probe packet's destination node ID is that of the exterior router on the port where it got the loop-indicative info 🎯. The destination socket is socket 1, which is the RTMP socket 🧚.

A Loop Probe packet's data field always starts with a long word whose value is 0 🌸. The rest of the data field SHOULD hold info the sending exterior router can use to recognize that packet if it comes back through its local internet 🧠. Why does this matter? An exterior router might get a Loop Probe packet from another exterior router if no loop actually exists, and that other router sent its probe to a random node on the internet instead of to itself 🎲. The node that gets the probe might be an exterior router that also sent one 😱. So, to keep an exterior router from wrongly deciding a loop exists, the exterior router sending the packet MUST put enough data in the packet's data field that it can tell the packet is the one it sent 🫶.

An exterior router starting a loop-investigation process SHOULD forward a Loop Probe packet through the tunnel to the next internet router for the packet's destination network, just like it would with any other AppleTalk data packet 🚚. That next internet router SHOULD always be the exterior router that sent the loop-indicative info 🔁.

A remapping exterior router forwarding a Loop Probe packet into its local internet MUST handle that packet differently from other AppleTalk data packets in one way ✂️. If the exterior router's remapping database doesn't include the source network number in the packet's DDP header, the router SHOULD forward the packet without remapping the source network number 📦. At startup, remapping info is usually unavailable, but that absence SHOULD NOT mess with the loop-detection process 💪.

If a loop exists, the exterior router that first sent the Loop Probe packet gets that packet back through its local internet 🎉. The data in the packet stays unchanged, so the router can use it to confirm the loop is really there 🔍.

If a Loop Probe packet comes back through the tunnel it was sent out of, that means a loop exists between two other exterior routers on the tunnel 🙃. It doesn't involve the router that sent the packet, so the sending router need take no action 💅.

An exterior router SHOULD send a Loop Probe packet at least four times ⏰. The retransmission timeout SHOULD be no less than two seconds ⏳. Once the exterior router has retransmitted a Loop Probe packet four times, and that packet still hasn't come back through its local internet, the exterior router determines that no loop exists 🌷✨.

If the exterior router gets a Loop Probe packet with the correct data field back through its own local internet, that confirms there's a loop 🔁😭 The exterior router should deactivate the tunneling port, log an error, and set every routing-table entry for exterior routers connected to that tunnel to BAD. Harsh, but it's giving protection 💅

NOTE: The exterior router need not deactivate a tunneling port on which it detects a loop 🫶 However, the exterior router must disconnect from the exterior router that sent the loop-indicative information. Still, disconnecting from only that one router could accidentally leave a tunnel partially connected, or cut off connectivity through the tunnel in a way that's really hard to notice 🙈

LIMITATIONS OF LOOP DETECTION: This loop-detection process stops working well if, somewhere in the loop, another exterior router does any of these things:

hides networks connected directly to the ports of the exterior router that sent the Loop Probe packet
clusters the network ranges of networks connected directly to the exterior router's ports
is not remapping network numbers, which causes partial network-number remapping

In those cases, the exterior router that started the loop detection might never get loop-indicative information, even though a loop is really there 💀

Using Alternative Paths

AURP gives a network administrator two mechanisms for setting up a port on an exterior router so it only forwards packets over an alternative path to a network when the primary path is down ✨

hop-count weighting
backup paths

By setting up hop-count weighting on a port, or setting a port up as a backup path, an administrator can cut down the traffic on a slow point-to-point link or tunnel 🐢 These mechanisms are also available on links using RTMP.

Hop-Count Weighting

A network administrator can set up hop-count weighting on a port so that a link to another exterior router counts as more than one hop 🧮 Making the routing distance through a port bigger can push traffic onto an alternative path. The routers on an internet forward packets over an alternative path to a network if:

an alternative path is available
the perceived distance to that network is shorter over the alternative path

But a network administrator should not set the hop-count weight for a link so high that distances between networks across that link go past the limit of 15 hops 🚫 Why? If the link with hop-count weighting were the only path available, the exterior router couldn't give full connectivity to every network on the internet. Major nope 😬

To set up hop-count weighting, an exterior router should make these changes to RTMP and the DDP routing process:

When an exterior router uses RTMP or AURP to broadcast the networks that are reachable through a link with hop-count weighting active, the distance it attributes to each network should equal its actual distance plus the hop-count weight that was specified.
Before an exterior router forwards a DDP data packet to a network across that link, it should add the specified hop-count weight to the value in the hop-count field of the packet's DDP header 🎀

Backup Paths

A network administrator can set up a port on an exterior router as a backup path. The routers on an internet only forward AppleTalk data packets across a backup path when an exterior router whose port is set up as a backup path decides that no other path to a specific network, or networks, is available 🦋

No matter how far routing packets have to travel over a primary path to reach a network, routers on the internet keep using the primary path for as long as it stays available 👑 When the exterior router with the backup-path port figures out that the primary path to a network is gone, and that network can be reached over the backup path, it broadcasts routing information about the networks reachable over the backup path to its local internet.

NOTE: An exterior router at each end of the backup path keeps a complete routing table for the entire internet, and sends AURP or RTMP routing packets across the backup path, whether or not the backup path is in use 🌸

If an exterior router is currently giving access to a network through a backup path, and the primary path to that network comes back, the exterior router starts broadcasting routing information that shows the primary path instead of the backup path. The routers in the exterior router's local internet can go back to using the primary path to that network 🥹

PROBLEMS REACTIVATING THE PRIMARY PATH: When an exterior router is giving access to a network through a backup path, and the primary path to that network comes back, it's possible the exterior router never finds out that the primary path is available again 😩 This can happen when other routers in the exterior router's local internet keep using the backup path, instead of the newly available primary path, because the backup path is shorter. Those other routers have no way of knowing that an active path is a backup path, and they don't tell the exterior router on the shorter backup path about the primary path being back 🙃

Once the primary path goes down and routers on the internet switch to the backup path, you may need to reconfigure the exterior router so it uses the primary path again 🔧

Network Management

A Simple Network Management Protocol (SNMP) Management Information Base (MIB) lets you remotely manage tunneling, routing-information propagation, and the representation of wide area routing information 🖥️ For detailed info about the structure and content of AURP's many remotely manageable parameters, check the "IETF Draft: Macintosh System MIB" on E.T.O. 📚

Network-Number Remapping and Network Management

Network-management packets, whether or not SNMP is what they're built on, often contain information about specific AppleTalk network numbers 🔢 An exterior router cannot remap network numbers in data. So when you query devices across a tunnel, network-management protocols always return network numbers that have not been remapped. Still, a remote network-management station using SNMP can use the AURP MIB to query a remapping exterior router and get remapped network numbers from that router's remapping database 🗂️

Network Hiding and Network Management

Even though an exterior router is hiding a network from a particular port, that network's routing information should be available to a network-management station across that port 👀 Network hiding should not affect network management. So an exterior router should still return routing information for hidden networks in responses to network-management queries. A network-management station using SNMP can use the AURP MIB to query an exterior router and find out about hidden networks 🕵️‍♀️

Unaffected Network-Management Packets

These network-management packets are ones that network-number remapping and network hiding should not affect:

SNMP requests received through an AURP port
SNMP responses sent through an AURP port
RTMP responses sent through an AURP port
Route Data responses sent through an AURP port
ZIP queries received through an AURP port
ZIP requests received through an AURP port
ZIP replies sent through an AURP port

APPENDIX: IMPLEMENTATION DETAILS 🧚

This appendix has info that may help you implement AURP. It does not specify protocol requirements, so it's extra helpful but not a rulebook 💜

Developers building AURP routers may want to buy the Apple Internet Router, a product of Apple Computer. It has lots of extra examples of how you might implement the different AURP features 🍓

State Diagrams

Figure A-1 shows the state diagram for the AURP data receiver 📊

             <<Figure A-1  AURP data receiver state diagram>>

Figure A-2 shows the state diagram for the AURP data sender 📊

              <<Figure A-2  AURP data sender state diagram>>

AURP Table Overflow

It's possible for an AURP data receiver to not have enough storage to keep all the routing information a peer data sender sends it 😰 Because the data sender doesn't retransmit routing information, the data receiver should set a flag that says a table-overflow condition exists. If more storage frees up later, the data receiver should try to get the missing information. If zone information is lost, the data receiver can get complete zone information by sending the appropriate ZI-Req packets. If network information is lost, the data receiver should send an RI-Req to get the complete routing table 🧩

A Scheme for Updates Following Initial Information Exchange

As covered in the section "Sending Updates Following the Initial Exchange of Routing Information" in Chapter 3, an exterior router has to give complete and accurate routing information to all exterior routers. That includes a brand-new connection made while the exterior router still has update events pending, meaning update events not yet sent in RI-Upd packets 🌈 This section walks through one scheme for presenting routing information correctly to both new and old connections, even when several update events happen for a given network during an update period in which the exterior router sets up new connections. Fancier schemes could give more up-to-date info, but they cost more implementation complexity 🤓

Let's say an exterior router has a bunch of AURP connections already set up with other routers, and a series of update events for a given network happens in the exterior router's local internet. After those events, but before the update interval runs out (so before the exterior router sends RI-Upd packets over its connections), the exterior router sets up a new AURP connection with another exterior router and gets an RI-Req packet from it ⏳ This section describes what information about the network the RI-Rsp packet should contain. It also describes the update event the exterior router should send in the next RI-Upd packet, assuming it gets no more update events for that network ✨

There are two possible scenarios. In the first one, a network that the exterior router wasn't exporting at the start of an update interval either comes up in the exterior router's local internet, or a new path to the network that's shorter than the path through the tunnel comes up in the exterior router's local internet 🦋 In either case, the RI-Rsp packet should not include the new network 💅

okay so picking up right where we left off 🦋 if the new network is left out of the RI-Rsp, the implementation can just keep following the state diagram from "Sending Routing Information Update Packets" in Chapter 3 💅 if only an NDC event happens (or no extra update event at all) for that network, the next RI-Upd packet the exterior router sends on both the old and new connections should carry an NA event for the network ✨ and if an NRC or ND event shows up for it, the exterior router should not put an event tuple for that network in the RI-Upd 🙈 this sequence matches the state diagram perfectly, and if the RI-Rsp did include info about the network, new connections would need a whole different state diagram 💀

second scenario, the exterior router first exports info for a network, and then an update event happens for it 👑 in every case, the RI-Rsp packet should have up-to-date info about the network from the exterior router's central routing table, and the next RI-Upd packet should carry whatever specific event the state table says for that network 🌸 like, if an ND or NRC event happens, the network should NOT be in the RI-Rsp, but if an NDC event happens, it should be 🫶

this scheme might mean some exterior routers get surprise update events, which they must process as described in "Processing Inconsistent Update Events" in Chapter 3 😭 for example, another exterior router that our exterior router makes a brand new connection with might get an ND or NRC event for a network it has never heard of. the receiving exterior router just ignores it, no drama 🧚

there's also another way to evaluate and maybe implement this scheme 🎀 the info for a given network that goes in the initial RI-Rsp depends on which update event is pending for that network when the exterior router sends the RI-Rsp. specifically, an exterior router should include a network with a pending update event in the RI-Rsp packet only if that pending event is an NDC. otherwise, the exterior router should not include the network in the RI-Rsp. after this RI-Rsp, the exterior router sends RI-Upd packets as usual, which carry other pending events as needed ✨

Implementation Effort for Different Components of AURP

AURP has all kinds of enhancements to AppleTalk routing 🌈 but the ONLY components that are required are the ones specified in Chapter 3. those required pieces give you everything needed to replace RTMP and ZIP completely and compatibly on tunnels and point-to-point links, with zero functionality lost and way less routing traffic 🍓 the optional features go beyond what RTMP and ZIP can do, and they're especially useful in a wide area network environment 🌍

the chart in Figure A-3 gives rough estimates of the percentage of development time needed to implement, debug, and test each part of a complete AURP implementation 📊 it helps developers get a feel for how complex each component is, and helps them make trade-offs between features and dev time 💖

              <<Figure A-3  Implementation effort for AURP>>

Creating Free-Trade Zones

okay this one is SO cool 😭 AURP lets a network admin create free-trade zones! a free-trade zone is a part of an internet that is reachable by two other parts of the internet, where neither of those two parts can reach the other 👀 an admin might make one to set up some kind of interchange between two organizations that want to keep their internets isolated from each other, or between two orgs that don't have any physical connection to each other at all 🔥

AURP can make free-trade zones in two ways ✨ in the first method, described in "Fully Connected and Partially Connected Tunnels" in Chapter 2, the admin intentionally makes a partially connected tunnel. they configure the exterior router to connect with two exterior routers that have a free-trade zone between them, but they do NOT configure those two exterior routers to connect with each other 🦋

the second method uses network hiding 💅 an admin can configure a single router to create a free-trade zone, and no AURP tunnel is needed at all. as shown in Figure A-4, three ports are configured on one router. one port connects to the free-trade zone, and the other two ports connect to the parts of the internets that are otherwise isolated from each other 🎀

                 <<Figure A-4  Creating free-trade zones>>

on the port connected to the free-trade zone, the admin does NOT configure the router to hide any networks. the exterior router exports all networks from both organizations to the free-trade zone 🌸 on each port connected to an organization's internet, the admin configures the router to export ONLY the networks from the free-trade zone, and the exterior router hides all the networks from the other organization's internet 🙈 that way, each organization can reach the networks in the free-trade zone (and vice versa), but NOT the networks in the other organization's internet 🫶

Implementation Details for Clustering

the data structures an exterior router uses to keep track of clustering info are the key to implementing clustering 🧠 an exterior router should:

maintain mappings between the actual domain identifier and network range; the remapped network range; and the associated cluster
maintain zone lists for each actual network and for the cluster as a whole
use data structures that let parts of the info be marked for deletion, while still keeping that info around for possible later reuse, for example if a network goes down and then comes back up
use data structures that are bidirectional, supporting both converting a single FwdReq into multiple FwdReq packets AND manipulating individual networks within the cluster 🔥

an exterior router can cluster any network numbers that it has remapped into an available range of contiguous network numbers 💜 from both an implementation AND a management point of view, it's generally best for an exterior router to cluster ALL the network numbers it gets from a particular exterior router at a given time 👑 for example, it might be smart to cluster all the network numbers included in the initial information exchange with a particular exterior router, and then later cluster all the network numbers received in NA events in a given RI-Upd packet ✨

⚠️ bestie, the zone limit is where it gets tricky! maintaining compatibility with AppleTalk Phase 2 makes clustering more complicated 😭 an exterior router can include a maximum of 255 zones in a cluster, and this limit might stop it from clustering all the network numbers it gets at one time 💀 when an exterior router gets a list of networks from another exterior router, it doesn't know how many different zone names those networks use. it won't have that info until it receives the associated ZI-Rsp packets 🙈 so an exterior router should NOT build a cluster until it has a complete zone list for the network numbers being clustered 🛑 once it has complete zone info, it can cluster the maximum number of network numbers the 255 zone limit allows 🎀

AURP does NOT specify how an exterior router should figure out the hop count for a cluster when it forms one 🧚 that's the apparent distance in hops to the single extended network that represents the cluster. some possible implementation options are:

always setting the hop count to a constant value
setting the hop count to the minimum, average, or maximum of the hop counts for the networks within the cluster

in a large internet, setting the hop count for a cluster too high might make the networks in that cluster unreachable from some networks in the local internet of the exterior router that's doing the clustering 😱

Modified RTMP Algorithms for a Backup Path

in the following RTMP maintenance algorithms from Inside AppleTalk, the backup path is an RTMP link 📖 these algorithms can be adapted to AURP according to the architectural model in "AURP Architectural Model" in Chapter 3 ✨ the proposed changes to these algorithms show up in boldface Courier font 💅

On Receiving an RTMP Data Packet Through a Port

IF P is connected to an AppleTalk network AND P's network
     number range = 0

THEN BEGIN
     P's network number range := packet's sender network
          number range;
     IF there is an entry for this network number range
     THEN delete it;
     Create a new entry for this network number range with
          Entry's network number range := packet's sender
               network number range;
          Entry's distance := 0;
          Entry's next IR := 0;
          Entry's status := Good;
          Entry's port := P;
     END;
FOR each routing tuple in the RTMP Data packet DO
     IF there is a table entry corresponding to the tuple's
          network number range
          THEN Update-the-Entry
     ELSE IF there is a table entry overlapping with the
          tuple's network number range
          THEN ignore the tuple
     ELSE IF P is not a backup path
          THEN Create-New-Entry
     ELSE     Create-New-Tentative Entry;

Update-the-Entry

IF (Entry's port is not a backup port AND P is a
     backup port)
THEN Return; {Ignore tuple}
IF (Entry's state = Bad) AND (tuple distance <15)
THEN Replace-Entry
ELSE
     IF Entry's distance >= (tuple distance +1) AND (tuple
          distance <15)
          OR  (Entry's port is a backup port and P is not a
               backup port)
     THEN Replace-Entry
     ELSE IF Entry's next IR = RTMP Data packet's sender node
          address AND Entry's port = P
     THEN IF tuple distance <> 31 THEN BEGIN
          Entry's distance := tuple distance + 1;
          IF Entry's distance < 16
          THEN Entry's state := Good
          ELSE Delete the entry
     END
     Else Entry's state := Bad;

an exterior router uses the Create-New-Tentative-Entry algorithm when it discovers a previously unknown network across a backup path 🔍 an exterior router should NOT add an entry to the routing table being broadcast to its local internet until it's definitely sure no alternative path to that network is available 🛑 while it waits for another path to the network to show up, the exterior router temporarily stores the routing-table entry in a tentative routing table, as defined by the following algorithm 🦋

Create-New-Tentative-Entry

   IF tentative entry for tuple's network number range does not
        already exist
        THEN BEGIN
             Tentative entry's network number range =
                  tuple's network number range;
             Tentative entry's distance := tuple's distance;
             Tentative entry's next IR = packet's node address;
             Tentative entry's port := P;
             Start a TBD-minute timer for this entry;
        END;
   WHEN timer for this entry expires
        IF there is a table entry corresponding to or
             overlapping with the tentative entry's network
             number range
             THEN ignore the entry
        ELSE Create-New-Entry; {using data from the tentative
             entry}
        Delete tentative entry;

Okay so that's the last bit of the pseudocode, and it's giving careful timing logic 🧚 The tentative entry sits there waiting on its TBD-minute timer, and when that timer goes off it double-checks whether there's already a table entry covering or overlapping that network number range. If there is, it's ignored 🙈 If there isn't, a new entry gets created from the tentative data, and then the tentative entry gets deleted. Main character energy for the timer 💅

Security Considerations ✨

Okay bestie, this part is short but it's serious 😭 This memo talks about a weak form of security called network hiding or device hiding 🔒 It does NOT cover the bigger, more general security concerns, so those are just not addressed here. Don't go assuming this doc has you covered for everything, periodt 💀

Author's Address

Alan B. Oppenheimer 🎀

Apple Computer, M/S 35-K

20525 Mariani Avenue

Cupertino, California 95014

Phone: 408-974-4744

EMail: Oppenheime1@applelink.apple.com

Note: The author would like to acknowledge the contribution of Pabini Gabriel-Petit here at Apple, who translated the engineering specification into human-readable form. She made the dense engineering stuff readable for everyone, and that's iconic 🫶🌸

📦 where this page comes from

ietf: rfc1504 1993-08
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms