rfc1504.txt
来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,548 行 · 第 1/5 页
TXT
1,548 行
It reduces the amount of network traffic across both a tunnel and the internets connected to that tunnel. Network hiding has the following disadvantages: 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 may list the names of only some or none of the devices in those zones. It cannot list the names of devices that are unable to respond to Name Binding Protocol (NBP) lookups originating from a node on a hidden network. Domain Identifiers Exterior routers assign a unique domain identifier to each AppleTalk internet, or domain. Domain identifiers enable exterior routers on a multipoint tunnel to distinguish individual AppleTalk internets in a wide area internet from one another. The definition of an AppleTalk domain identifier is extensible to allow for future use when many additional types of AppleTalk tunnels and tunneling topologies may exist: Under the current version of AURP, each exterior router connected to a multipoint tunnel assigns a domain identifier to its local AppleTalk internet that uniquely identifies that 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. Thus, 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 simplify an exterior router's port configuration, a parameter that is already administrated-such as a node address-can serve as the basis for an exterior router's domain identifier.Oppenheimer [Page 12] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 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) consists of the following fields: Length: Byte 1 represents the length of the DI in bytes, not including the length byte. A DI must consist of an even number of bytes. Thus, the length byte is always an odd-numbered byte. The length field permits tunneling through foreign network systems that have addresses of any length-including the long addresses characteristic of X.25 and OSI. The value of the length byte varies, depending on the format of the DI. Authority: Byte 2 indicates the authority that administrates the identifier bytes of the DI. At present, Apple has defined only two authority-byte values: $01-indicates that the subsequent bytes correspond to a unique, centrally administrated IP address $00-the null DI-indicates that no additional bytes follow All other authority-byte values are reserved and should not be used. Identifier: The identifier field starts at byte 3 and consists of a variable number of bytes of the type indicated by the authority byte. NULL DOMAIN-IDENTIFIER FORMAT: The use of a null domain identifier is appropriate only when there is no need to distinguish the domains connected to a tunnel-for example, where 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 consists of the following 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 underlyingOppenheimer [Page 13] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 foreign network system. The headers required by a foreign-network protocol always precede an AppleTalk data packet sent across a multipoint tunnel. A domain header generally immediately precedes 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 consists of the following 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 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. In the future, Apple may define other values for this field. An AppleTalk data packet does not require a domain header if it is 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 Omitting a domain header reduces overhead associated with the exchange of routing information, without any 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) protocol suite is a widely used communications standard that provides interoperability among computers from various vendors, including Apple, IBM, Digital Equipment Corporation, Sun, and Hewlett-Packard.Oppenheimer [Page 14] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 Descriptions of three of the most important TCP/IP protocols follow: The Transmission Control Protocol (TCP) is a transport-layer protocol that provides reliable data transmission between processes-that is, between programs that communicate with one another. This connection-oriented, byte-stream protocol ensures error-free, sequential data delivery, without loss or duplication. The User Datagram Protocol (UDP) is a transport-layer protocol that provides best-effort, low-overhead interprocess data transmission. This datagram-oriented protocol allows higher-layer protocols that do not require reliability to transmit data without incurring the overhead associated with TCP. UDP does no error checking, does not acknowledge its successful receipt of data, and does not 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 administrated internet address, called an IP address, that identifies the node. The header of an IP datagram contains its source and destination IP addresses, allowing any host to route a datagram to its destination. TCP/IP provides connectivity between many different network types that use data frames of various sizes. Therefore, 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 encapsulate the data in segments, using the appropriate headers, then pass the segments to IP. IP further encapsulates the data in IP datagrams, determines 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 conforms to 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 on the TCP/IP internet. Thus, 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 exchange AppleTalk routing information and AppleTalk data packets with one another. An exterior router encapsulates AppleTalk data packets in IP datagrams beforeOppenheimer [Page 15] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 sending them across the TCP/IP internet to a forwarding exterior router, which decapsulates 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 that are based on IP addresses. An exterior router on an IP tunnel derives its domain identifier from its IP address. Thus, a network administrator does not 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 consists of the following 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 remainder 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 contain the four-byte IP address of either the sending or the receiving exterior router. NOTE: Future versions of AURP will allow exterior routers to usealternative formats for domain identifiers, even on IP tunnels. AppleTalk Data-Packet Format for IP Tunneling The following protocol headers precede an AppleTalk data packet that is forwarded across an IP tunnel by an exterior router: a data-link header an IP header a User Datagram Protocol (UDP) header a domain header An exterior router encapsulates AppleTalk data packets in UDP packets when forwarding them through its UDP port 387, across an IP tunnel, to UDP port 387 on another exterior router. When encapsulating dataOppenheimer [Page 16] RFC 1504 Appletalk Update-Based Routing Protocol August 1993 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 consists of the following fields: 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 consists of a domain header and 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>>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?