decapsulates the packets.
Domain Headers in AURP Packets
When forwarding AURP packets across a tunnel, an exterior router adds
a domain header immediately preceding each packet. A domain header
contains additional addressing information, including its source
domain identifier and destination domain identifier (DI). The last
two bytes of the domain header are set to 0003, indicating that the
packet is an AURP packet rather than an AppleTalk packet. AURP data
follows 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 interprets the domain identifiers in the domain
header of an AURP packet differently from those in the domain headers
of an AppleTalk data packet. Only network entities with AppleTalk
addresses have domain identifiers associated with them. Exterior
routers do not have AppleTalk addresses on the tunnel-thus, they do
not have true domain identifiers.
DESTINATION DOMAIN IDENTIFIER: The destination DI in an AURP packet's
domain header is the DI that is associated with any network numbers
corresponding to networks that reside in the receiving exterior
router's domain. Only ZI-Req packets include such network numbers.
Whenever possible, a domain header should specify a destination DI-
that is, the DI for the networks that reside in the domain of the
exterior router that is to receive the packet. When an exterior
router sends an Open-Req to open a connection, the destination DI is
not yet known. 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 that is associated with any network numbers
corresponding to networks that reside in the sending exterior
router's domain. RI-Rsp, RI-Upd, ZI-Rsp, and GZN-Rsp packets include
such network numbers. A domain header should always specify a source
DI-that is, the DI for the networks that reside in the domain of the
exterior router that is sending the packet.
Routing Data Headers in AURP Packets
The routing data header that immediately precedes the AURP data in a
routing data packet consists of an AURP-Tr header and an AURP header.
The AURP-Tr header consists of the following fields:
Connection ID: The contents of this two-byte field identify the
specific one-way connection to which a packet belongs.
Sequence number: The contents of this two-byte field identify an
individual packet on a connection.
The AURP header consists of these fields:
Command code: This two-byte field identifies the command type. For
information about command types, see the next section, "Command
Types."
Flags: This two-byte field may contain different flags, depending on
the command code. For information 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
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
AURP defines the flags shown in Table 3-2. All other flags are
reserved. A data sender should set reserved flags to 0. A data
receiver should ignore reserved flags.
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 shows the routing flags in Open-Req and RI-Req packets.
<<Figure 3-21 Routing flags in Open-Req and RI-Req packets>>
Figure 3-22 shows the routing flags in all packets other than Open-
Req and RI-Req packets.
<<Figure 3-22 Routing flags in other packets>>
Open Request Packet
An Open-Req packet initiates the establishment of a one-way
connection with a data sender. Figure 3-23 shows the format of an
Open-Req packet. When sending an Open-Req packet, an exterior router
inserts the next available connection ID in the packet's AURP-Tr
header and sets its sequence number to 0. The AURP header of an
Open-Req contains the command code 8. Its flag bytes contain send
update information (SUI) flags. For the current version of AURP, the
version number is 1.
An Open-Req packet's option data field contains
an option count-indicating the number of option tuples to follow
the option tuples
When the data sender receives an Open-Req, it can discard the option
tuples for any options it does not implement. For information about
option tuples, see the section "Option Tuples" later in this chapter.
<<Figure 3-23 Open-Req packet format>>
Open Response Packet
When the data sender receives an Open-Req, it responds by sending an
Open-Rsp packet to establish a one-way connection with the data
receiver. Figure 3-24 shows the format of an Open-Rsp packet. In its
AURP-Tr header, an Open-Rsp packet contains the connection ID from
the associated Open-Req packet and the sequence number 0. The AURP
header of an Open-Rsp contains the command code 9 and its flag bytes
contain environment flags that provide information about the data
sender's environment-such as whether network-number remapping or
hop-count reduction is active. For information about network-number
remapping and hop-count reduction, see the sections "Network-Number
Remapping" and "Hop-Count Reduction," respectively, in Chapter 4.
<<Figure 3-24 Open-Rsp packet format>>
An Open-Rsp packet's option data field contains
a two-byte field that indicates 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
cannot accept the connection
an option count-indicating the number of option tuples to follow
the option tuples
For information about error codes, see the section "Error Codes"
later in this chapter. For information about option tuples, see the
next section, "Option Tuples."
Option Tuples
Both Open-Req and Open-Rsp packets contain option tuples. An option
tuple contains a one-byte length field that indicates the length of
the remainder 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 shown 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 requests the data sender to send RI-Rsp packets.
Figure 3-26 shows the format for an RI-Req packet. When sending an
RI-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 the packet's sequence number to 0. The AURP header of
an RI-Req contains the command code 1 and its flag bytes contain the
send update information (SUI) flags.
<<Figure 3-26 RI-Req packet format>>
Routing Information Response Packet
When the data sender receives an RI-Req, it responds by sending a
sequence of RI-Rsp packets. Figure 3-27 shows the format of an RI-Rsp
packet. When sending an RI-Rsp packet, a data sender inserts the
connection ID from the associated RI-Req in the RI-Rsp packet's
AURP-Tr header and sets its sequence number to the next number in the
sequence. The AURP header of an RI-Rsp packet contains the command
code 2. In the last packet in a sequence of RI-Rsp packets, the
last-flag bit is set to 1.
<<Figure 3-27 RI-Rsp packet format>>
An RI-Rsp packet's routing data field contains zero or more routing
tuples, which have a format similar to those in RTMP packets. An AURP
tuple for a nonextended network is different from an RTMP tuple for
an extended network in one respect-the range flag, or the sixth byte,
in an AURP tuple for a nonextended network is set to 0. 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 receives an RI-Rsp, RI-Upd, or RD packet, it
responds by sending an RI-Ack packet. Figure 3-29 shows the format of
an RI-Ack packet. When sending an RI-Ack packet, a data receiver
inserts the connection ID and sequence number from the associated
RI-Rsp, RI-Upd, or RD packet in the RI-Ack packet's AURP-Tr header.
The AURP header of an RI-Ack contains the command code 3. If the data
receiver sends an RI-Ack using AURP-Tr, in response to an RI-Rsp or
RI-Upd packet that contains 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
The occurrence of specified events requires the data sender to send
an RI-Upd packet. Figure 3-30 shows the format of an RI-Upd packet.
When sending an RI-Upd packet, a data sender inserts the connection
ID for the current connection in the RI-Upd packet's AURP-Tr header
and sets its sequence number to the next number in the sequence. The
AURP header of an RI-Upd contains the 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 contains one or more event tuples. An
event tuple for a nonextended network consists of a one-byte event
code, the network number, and the distance to that network. An event
tuple for an extended network consists of a one-byte event code, the
first network number in the range of network numbers, the distance to
the network, and the last network number in the range of network
numbers. Figure 3-31 shows nonextended and extended network tuples in
an RI-Upd packet.
<<Figure 3-31 Nonextended and extended network event tuples>>
AURP currently defines the event codes shown 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. The format of NA, ND, NRC,
and NDC event tuples differs, depending on whether the event pertains
to a nonextended or an extended network. The distance field does not
apply to ND or NRC event tuples and should be set to 0. The ZC event
tuple is not yet defined.
An RI-Upd packet should never contain two events that pertain to the
same network. However, to ensure consistent behavior in the event
that an exterior router receives a packet containing multiple events
for one network, an exterior router should always process events in
the order in which they occur in the RI-Upd packet. Thus, if an
exterior router were to receive an RI-Upd that contained an NA event,
then an ND event for the same network, the exterior router would
delete the network from its routing table.
Router Down Packet
An exterior router should send an RD packet before it goes down.
Figure 3-32 shows the format of an RD packet. When sending an RD
packet, an exterior router inserts the connection ID for the current
connection in the RD packet's AURP-Tr header. If the data sender
sends an RD packet, it sets its sequence number to the next number in
the sequence. If the data receiver sends an RD packet, it sets its
sequence number to 0. The AURP header of an RD packet contains the
command code 5 and its flag bytes are set to 0.
<<Figure 3-32 RD packet format>>
An RD packet's data field contains a two-byte error code that
indicates the exterior router's reason for going down. For
information about the error codes, see the section "Error Codes"
later in this chapter.
Zone Information Request/Response Transactions
An exterior router returns information about its zones through
request/response transactions. Three types of zone requests-ZI-Req,
GDZL-Req, and GZN-Req-share the same command code and have subcodes
that indicate the actual request type. Three types of zone
responses-ZI-Rsp, GDZL-Rsp, and GZN-Rsp-share another command code
and have subcodes that indicate the actual response type.
ZONE INFORMATION REQUEST PACKET: A ZI-Req packet causes the data
sender to send ZI-Rsp packets. Figure 3-33 shows the format of a ZI-
Req packet. When sending a ZI-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 the packet's sequence number
to 0. The AURP header of a ZI-Req contains the command code 6 and its
flag bytes are set to 0.
<<Figure 3-33 ZI-Req packet format>>
A ZI-Req packet's data field contains the subcode 1 and a two-byte
network number for each network about which the exterior router is
requesting zone information. The network number for an extended
network 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 similar to that of a
nonextended AppleTalk ZIP Reply packet. When the data sender receives
a ZI-Req and the zone list for the network or networks for which that
ZI-Req requested zone information 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 receives a ZI-Req and the zone
list for a network about which that ZI-Req requested zone information
does not 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 provides detailed information
about the presentation of wide area network information by exterior
routers 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 information 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 that is appropriate
for organizations that do not require true device-specific security.
It is not a substitute for device-specific security. Device hiding
can provide a degree of security on devices for which no other form
of security exists-such as LaserWriter printers.
A user can write a program that can obtain access to a hidden device
using its AppleTalk address. Device hiding cannot secure a device
from a user that is not using NBP to access the device.
Device hiding does not provide true device-specific security. Many
devices require device-specific security-for example, AppleShare file
servers. Device-specific security can provide various levels of
security, and may allow a network administrator to grant access
privileges based on registered users and groups.
Configuring Device Hiding on a Port
When configuring a port on a router that implements device hiding, a
network administrator should be able to hide any device that is
accessible through that port from the other ports on the router. The
device being hidden need not reside on the network connected directly
to the port being configured.
An administrator should be able to specify the ports from which to
hide a device-either specific ports or all other ports.
When hiding devices, an administrator should be able to specify that
a list of devices either be hidden or visible. The device list should
include device names and device types-for example, We-B-
Nets:AFPServer. An administrator should also be able to hide all
devices of a given type-for example, all LaserWriter printers-or all
devices of all types.
Filtering NBP LkUp-Reply Packets
To implement device hiding, a router selectively filters NBP LkUp-
Reply packets. When a port's configuration specifies that devices
accessible through the port be hidden, the router
monitors all NBP LkUp-Reply packets received through that port-
called the incoming port
determines the port through which it is to forward such a packet-
called the outgoing port
obtains-from the port configuration for the incoming port-the list
of devices to be hidden from the outgoing port
determines whether it should filter all or part of an NBP LkUp-
Reply packet
If a port's configuration does not specify that devices be
hidden from the outgoing port, the router forwards the packet.
If a port's configuration specifies that devices be hidden from
the outgoing port, the router checks each tuple in the NBP LkUp-
Reply packet to determine whether it is from a device in the
port's list of hidden devices. It marks tuples from hidden
devices for deletion. Once the router scans the entire packet,
it forwards the packet if no tuples were marked for deletion; it
discards the packet if all tuples were marked for deletion; or,
if only some tuples were marked for deletion, it rebuilds the
packet without the tuples marked for deletion, then forwards the
packet.
When the router rebuilds a packet, it adjusts the tuple count in the
packet's NBP header to reflect the number of tuples remaining. If a
rebuilt packet's DDP header contains a nonzero checksum, the router
verifies the original checksum, then sets it to 0.
This device-hiding scheme can handle both NBP Lookups and NBP
Confirms, because a node responds to requests of either type with a
LkUp-Reply packet.
LkUp-Reply packets do not contain the names of zones in which devices
reside. Thus, if two devices having the same name and type are
accessible through a port, a network administrator can hide both
devices or neither device, but not just one of the devices.
When configuring ports on routers through which redundant paths to a
device exist, a network administrator must hide that device on at
least one port on each path to that device. Otherwise, only a router
on which such a port was configured to hide the device would filter
LkUp-Reply packets from the device. A router on which such a port was
not configured to hide the device would not filter its LkUp-Reply
packets. Figure 4-1 shows the proper configuration of device hiding
when a loop exists on the internet.
<<Figure 4-1 Device hiding when a loop exists on the internet>>
Resolving Network-Numbering Conflicts
In addition to interconnecting different parts of one organization's
internet, tunnels can interconnect the internets of multiple
organizations. Each organization administrates its internet
independently. Therefore, conflicting network numbers may exist on
the internets, especially when many internets are interconnected. The
following sections describe the methods that AURP uses to resolve
various problems due to conflicting network numbers.
Network-Number Remapping
Network-number remapping resolves network-numbering conflicts,
allowing network administrators to build very large internets. When
configuring a port on an exterior router, an administrator can
specify a range of AppleTalk network numbers to be used for imported
networks-that is, networks that are accessible through half-routing
or tunneling ports, for which the exterior router imports routing
information from other exterior routers. The remapping range-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.
The exterior router maps the network numbers in incoming packets into
the remapping range. It converts remapped network numbers back to
their actual network numbers for outgoing packets. To nodes and
routers within the exterior router's local internet, packets
containing remapped network numbers apparently originate from or are
being sent to networks having numbers in the remapping range.
UNIQUE IDENTIFIERS: In a tunneling environment, many different
internets may include AppleTalk networks that have the same network
numbers. Therefore, each exterior router on an internet must
associate a unique identifier (UI) with each network that it exports
across the tunnel-that is, each network in its local internet that is
not hidden. Generally, some type of global administration of UIs is
necessary.
On a given tunnel, each exterior router on which network-number
remapping is active must have a unique domain identifier (DI). An
exterior router using AURP derives a network's UI by concatenating
the exterior router's DI-which is unique on the tunnel-with the
packet's network number or range-which is unique within the exterior
router's domain. For more information about domain identifiers, see
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 an exterior router
sends or receives AppleTalk data packets across the tunnel, it refers
to any network numbers or ranges in the packets-for example, in a
packet's DDP header-by their UIs. For example, when an exterior
router sends an RI- Rsp, which provides a list of network ranges for
its local internet to other exterior routers on the tunnel, it lists
the UIs corresponding to those network ranges. When an exterior
router receives RI-Rsp packets from other exterior routers on the
tunnel, it interprets the data in each packet as a list of UIs.
Network-number remapping should be an optional component of any
tunneling scheme. An administrator should be able to configure a
tunneling port with or without specifying 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 the exterior routers must be unique.
MAPPINGS: An exterior router uses the following process to map
AppleTalk network numbers and ranges to UIs, and vice versa:
The exterior router logically maps network numbers in the exterior
router's local internet to the corresponding UIs before sending a
packet out the tunneling port, as shown in Figure 4-2. The UI
consists of the source DI in the domain header and the network
number from the packet. Therefore, the exterior router changes no
data in the packet to perform this mapping.
The exterior router logically maps UIs corresponding to local
networks in packets received through the tunneling port back to
their local network numbers before forwarding the packets to the
exterior router's local internet, as shown in Figure 4-2. The
exterior router changes no data in the packet. This mapping is the
inverse of the previous mapping.
The exterior router maps UIs corresponding to network numbers for
remote networks-that is, networks connected to other exterior
routers on the tunnel-that are in packets received through the
tunneling port to network numbers in the remapping range configured
for the local internet, as shown in Figure 4-2. An exterior router
remaps network numbers from the following fields in this way:
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 the corresponding UIs
before sending packets out the tunneling port, as shown in Figure
4-2. This type of remapping applies only to network numbers that
reside in a destination network-number field of a DDP header in an
AppleTalk data packet. This mapping is the inverse of the previous
mapping.
<<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. Thus, if a packet contains a
DDP checksum, when the exterior router remaps network numbers
contained in the packet, it must verify that the checksum is correct,
then set the checksum to 0. If the checksum is incorrect, the
exterior router should discard the packet.
An exterior router can perform 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 they become known to an exterior router.
Static remapping is simpler to implement and provides a known mapping
for use in network management. However, it may limit the number of
UIs that an exterior router can import into its local internet.
Dynamic mapping requires a scheme for network number reuse, but may
provide connectivity to a greater number of networks across a tunnel.
To avoid having the same UI refer to two different networks when
remapping network numbers dynamically, 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 reassign the UI that referred to that
network to another network that just came up on the internet.
An exterior router connected to more than one tunnel should function
as though it were two exterior routers-each connected to one tunnel
and both connected to one AppleTalk internet. Thus, such an exterior
router must use remapped network numbers when sending routing
information across a tunnel about networks that are accessible
through another tunnel.
Network Numbers in Data
To remap network numbers properly, an exterior router must be aware
of their presence within AppleTalk data packets. It is difficult to
detect network numbers in data packets, because they could be
anywhere within a data packet. For example, NBP includes network
addresses as part of its data-in entity addresses. However, the data
packets for very few protocols contain any network numbers. Some
third-party protocols may contain network addresses in their data.
Protocols that contain network addresses in their data may not
function properly across remapping exterior routers.
Packets used for network management-such as RTMP Route Data Response
(RDR) and Simple Network Management Protocol (SNMP) packets-contain
network numbers in their data. For detailed information about
handling network numbers in SNMP packets, see the section "Network
Management" later in this chapter.
Problems With Loops
Network-number remapping introduces some problems on an internet when
loops exist across a tunnel. If network-number remapping is active,
two AppleTalk internets connected by a tunnel should not be
interconnected in any other way. If a redundant path to an internet
exists, a remapped network range can loop back through that path to
the exterior router that originally remapped the network range. When
this occurs, two different network ranges-the network range actually
configured and the remapping of the configured range-refer to one
network.
The remapped network range apparently refers to a new network in the
exterior router's local internet. Such a network is referred to as a
shadow network. The exterior router cannot determine that it has
received a network range that it had previously remapped, because
there is no apparent difference between a remapped network range and
an actual network range. Thus, unless an administrator configures an
exterior router with an explicit list of networks to export, the
exterior router again remaps the network range, then exports the
remapped network range, sending it around the loop. The network range
is remapped repeatedly until the apparent distance to the network
exceeds the hop-count limit. Exterior routers that implement
network-number remapping should avoid establishing such infinite
loops. For information about preventing such loops, see the section
"Routing Loops" later in this chapter.
Redundant Paths
Under certain circumstances, it might be desirable to create a
redundant path, which is a special type of loop. Redundant paths
connect an internet to a tunnel through two or more exterior routers.
If network-number remapping is active, all redundant exterior routers
must use the same DI to represent the local internet-and must map UIs
representing remote networks in incoming packets to the same local
network numbers.
To allow redundant exterior routers to achieve such cooperation, a
network administrator might configure all redundant exterior routers
with the same DI and complete remapping information for all imported
networks. Alternatively, a network administrator might configure one
exterior router with this information and all redundant exterior
routers could obtain the information from the configured exterior
router. AURP does not currently support this functionality, but may
do so in the future.
Tunnels With Partial Network-Number Remapping
When network-number remapping is active on a tunneling port, an
exterior router maps network numbers in packets received through the
tunnel into the remapping range for its local internet. Because a
network administrator configures network-number remapping on
individual exterior routers, network-number remapping may be
configured on some exterior routers on a tunnel, but not on others-
potentially causing network-numbering conflicts due to partial
network-number remapping. Whenever possible, an administrator should
configure network-number remapping either on all exterior routers on
a tunnel or on none of them. Otherwise, network-numbering conflicts
are likely to occur on some of the exterior routers-especially on
large, interorganizational internets.
In addition to potential network-numbering conflicts, partial
network-number remapping and the lack of loop detection between
nonremapping exterior routers may cause shadow copies of networks
connected to more than one nonremapping exterior router to appear in
the routing tables on remapping exterior routers.
An exterior router on which network-number remapping is active
performs loop detection. Therefore, when network-number remapping is
active on all of the exterior routers on a tunnel, no loops can exist
across the tunnel. However, exterior routers on which network-number
remapping is not active do not perform loop detection. Thus, when
network-number remapping is not active on some of the exterior
routers on a tunnel, any loops that exist between nonremapping
exterior routers are not detected.
In the example shown in Figure 4-3, shadow copies of all networks
that are in the local internets of both exterior router B and
exterior router C, on which network-number remapping is not active,
appear in the routing table of exterior router A, on which network-
number remapping is active.
<<Figure 4-3 A tunnel with partial network-number remapping>>
Clustering Remapped Networks
Because a remapping range is a range of sequential network numbers,
an exterior router can represent multiple remapped networks as a
single extended network within its local internet-that is, it can
cluster remapped networks. Clustering greatly reduces the size of the
routing tables that are maintained and sent by routers within an
internet, as well as the amount of RTMP traffic on the internet.
Clustering may also reduce the amount of NBP traffic on an internet.
For example, as shown in Figure 4-4, if networks in an internet have
the numbers 1, 100, and 1000, and an exterior router connected to a
different part of the internet receives these network numbers across
the tunnel, that exterior router might remap the network numbers to
21, 22, and 23. When sending RTMP packets within its local internet,
the remapping exterior router can represent the three networks as a
single extended network with a network range from 21 to 23. The zones
associated with the extended network include all of the zones
associated with the three imported network numbers.
<<Figure 4-4 Clustering remapped network numbers>>
An exterior router determines which remapped network numbers it
should cluster. For example, an exterior router might create one
cluster for each other exterior router on the tunnel. However, an
exterior router can include no more than 255 zones in one cluster.
An exterior router that implements clustering must maintain the
actual network range and zone list for each network in a cluster. The
exterior router monitors all NBP FwdReq packets to be forwarded
across the tunnel-including those it generates in response to BrRq
packets. It examines the DDP destination network number in each
FwdReq packet to determine the cluster to which it is addressed. The
exterior router then generates one FwdReq packet for each clustered
network for which the FwdReq packet contains a zone name, and sends
that packet to the next internet router for the network. The DDP
destination network number in such a FwdReq packet corresponds to the
starting network number of a network's actual network range.
A disadvantage of clustering is that clusters are static. An exterior
router cannot notify its local internet that a specific network or
zone in a cluster has gone down. An exterior router's implementation
of clustering could allow a network administrator to initiate
reclustering-in which the exterior router notifies the internet that
an entire cluster has gone down, then creates a new cluster that does
not include the networks that have gone down. However, such
reclustering would cause a temporary loss of connectivity to those
networks in the cluster that are still accessible. Therefore, an
exterior router should not automatically recluster network numbers.
REUSING NETWORK NUMBERS WITHIN A CLUSTER: Under certain conditions,
an exterior router that implements clustering might reuse network
numbers within a cluster. If a network went down, then came back up
with the same zone list, an exterior router could map its network
range into the same remapping range and include it in the same
cluster. Otherwise, an exterior router should not reuse network
numbers within a cluster, unless no other network numbers within the
remapping range are available. In any case, an exterior router can
reuse network numbers within a cluster only if a new network has a
network range that fits in an unused range of network numbers within
the cluster and a zone list that is a subset of the cluster's zone
list.
The implementation of clustering in an exterior router is complex.
See the Appendix, "Implementation Details," for some ways in which
clustering could be implemented.
Zone-Name Management
To enhance zone-name management within an AppleTalk internet, AURP
provides Get Domain Zone List and Get Zone Nets requests-which
function similarly to the ZIP GetZoneList command and ZI-Req command,
respectively. However, as when using RTMP and ZIP, if two networks in
an internet include zones that have the same zone name in their zone
lists, exterior routers merge the zones into one zone-regardless of
whether network-number remapping is active on one or more of the
exterior routers.
Because AppleTalk data packets often contain zone names, AURP
provides no means of remapping zone names. When importing or
exporting zone names, an exterior router should not modify them in
any way.
On a very large internet, zone names may become unmanageable.
Therefore, an administrator should use domain-specific prefixes-such
as Engineering or Sales-for zone names on such an internet. The use
of a third-party hierarchical Chooser also might simplify zone-name
management.
Hop-Count Reduction
Generally, an exterior router increases the hop count in the DDP
header of an AppleTalk data packet by at least one when it forwards
the packet across a tunnel. Once a packet traverses 15 routers-either
local routers or exterior routers-its hop count exceeds the maximum.
Thus, when an exterior router receives a packet through its tunneling
port, it should examine that packet's DDP hop count before forwarding
the packet. If the exterior router receives a packet with a hop count
of 15 hops, it does not forward the packet to another router, but
discards the packet.
When a tunnel or point-to-point link connects AppleTalk internets,
the distance that a packet must traverse can easily exceed 15 hops. A
network administrator might need full connectivity between two
internets at a distance exceeding 15 hops. If the distance across an
exterior router's local internet is already at or near the 15-hop
limit, the exterior router must reduce the perceived distance that a
packet must traverse to allow the packet to reach a destination at a
distance that exceeds 15 hops. To overcome DDP's 15-hop limit, an
exterior router reduces the hop count in the DDP header of an Apple
data packet received through a tunnel before forwarding the packet
into its local AppleTalk internet. An exterior router should reduce
the hop count only by the number of hops necessary to allow the