Practical TCP/IP and Ethernet Networking- P25 pps

5 149 0
Practical TCP/IP and Ethernet Networking- P25 pps

Đang tải... (xem toàn văn)

Thông tin tài liệu

 6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM   • SCOP is a 4-bit multicast scope value used to limit the scope of the multicast group, for example to ensure that packets intended for a local videoconference are not spread across the Internet. The values are: 1 Interface-local scope 2 Link-local scope 3 Subnet-local scope 4 Admin-local scope 5 Site-local scope 8 Organization-local scope • GROUP ID identifies the multicast group, either permanent or transient, within the given scope. Permanent group IDs are assigned by IANA. The following example shows how it all fits together. The multicast address FF:08::43 points to all NTP servers in a given organization, in the following way: • FF indicates that this is a multicast address • 0 indicates that the T flag is set to 0, i.e. this is a permanently assigned multicast address • 8 points to all interfaces in the same organization as the sender (see SCOPE options above) • Group ID = 43 has been permanently assigned to network time protocol (NTP) servers  ,RU]RGHKRY The 20-bit flow label field in the IPv6 header may be used by a source to label those packets for which it requests special handling by the IPv6 routers. Hosts or routers that do not support the functions of the flow label field are required to set the field to zero when originating a packet, pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet. The actual nature of that special handling might be conveyed to the routers by a control protocol, such as a resource reservation protocol (e.g. RSVP), or by information within the flow’s packets themselves, e.g., in a hop-by-hop option. A flow is uniquely identified by the combination of a source IP address and a non- zero flow label. A flow label is assigned to a flow by the flow’s source node. Flow labels are chosen (pseudo-) randomly and uniformly from the range 0x1 to 0xFFFFFF. The purpose of the random allocation is to make any set of bits within the flow label field suitable for use as a hash key by routers, for looking up the state associated with the flow. All packets belonging to the same flow must be sent with the same source address, same destination address, and same (non-zero) flow label. If any of those packets includes a hop-by-hop options header, then they all must be originated with the same hop-by-hop options header contents (excluding the next header field of the hop-by-hop options header). If any of those packets includes a routing header, then they all must be originated with the same contents in all extension headers up to and including the routing header (excluding the next header field in the routing header). The /TZKXTKZRG_KXVXUZUIURY   routers or destinations are permitted, but not required, to verify that these conditions are satisfied. If a violation is detected, it should be reported to the source by an ICMP parameter problem message, code 0, pointing to the high-order octet of the flow label field.  'JJXKYYXKYUR[ZOUTVXUZUIUR'86 ARP is used with IPv4. Initially the designers of IPv6 assumed that it would use ARP as well, but subsequent work by the SIP, SIPP and IPv6 working groups led to the development of the IPv6 ‘neighbor discovery’ procedures that encompass ARP, as well as those of router discovery. Some network technologies make address resolution difficult. Ethernet interface boards, for example, come with built-in 48-bit hardware addresses. This creates several difficulties: • No simple correlation, applicable to the whole network, can be created between physical (MAC) addresses and Internet protocol (IP) addresses • When the interface board fails and has to be replaced the Internet protocol (IP) address then has to be remapped to a different MAC address • The MAC address is too long to be encoded into the 32-bit Internet protocol (IP) address To overcome these problems in an efficient manner, and eliminate the need for applications to know about MAC addresses, the address resolution protocol (ARP) (RFC 826) resolves addresses dynamically. When a host wishes to communicate with another host on the same physical network, it needs the destination MAC address in order to compose the basic level 2 frame. If it does not know what the destination MAC address is, but has its IP address, it broadcasts a special type of datagram in order to resolve the problem. This is called an address resolution protocol (ARP) request. This datagram requests the owner of the unresolved Internet protocol (IP) address to reply with its MAC address. All hosts on the network will receive the broadcast, but only the one that recognizes its own IP address will respond. While the sender could, of course, just broadcast the original datagram to all hosts on the network, this would impose an unnecessary load on the network, especially if the datagram was large. A small address resolution protocol (ARP) request, followed by a small Address Resolution Protocol (ARP) reply, followed by a direct transmission of the original datagram, is a much more efficient way of resolving the problem. Figure 6.26 ARP operation  6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM    'JJXKYYXKYUR[ZOUTIGINK Because communication between two computers usually involves transfer of a succession of datagrams, it is prudent for the sender to ‘remember’ the MAC information it receives, at least for a while. Thus, when the sender receives an ARP reply, it stores the MAC address it receives as well as the corresponding IP address in its ARP cache. Before sending any message to a specific IP address it checks first to see if the relevant address binding is in the cache. This saves it from repeatedly broadcasting identical address resolution protocol (ARP) requests. To further reduce communication overheads, when a host broadcasts an ARP request it includes its own IP address and MAC address, and these are stored in the ARP caches of all other hosts that receive the broadcast. When a new host is added to a network it can be made to send an ARP broadcast to inform all other hosts on that network of its address. Some very small networks do not use ARP caches, but the continual traffic of ARP requests and replies on a larger network would have a serious negative impact on the network’s performance. The ARP cache holds 4 fields of information for each device: IF index – the number of the entry in the table Physical address – the MAC address of the device Internet protocol (IP) address – the corresponding IP address Type – the type of entry in the ARP cache. There are 4 possible types: 4 = static – the entry will not change 3 = dynamic – the entry can change 2 = the entry is invalid 1 = none of the above  '86NKGJKX The layout of an ARP datagram is as follows: Figure 6.27 ARP header .GXJ]GXKZ_VK HOZY Specifies the hardware interface type of the target, e.g.: 1 = Ethernet 3 = X.25 4 = Token ring 6 = IEEE 802.x 7 = ARCnet /TZKXTKZRG_KXVXUZUIURY   6XUZUIURZ_VK HOZY Specifies the type of high-level protocol address the sending device is using. For example, 2048 10 (0x800): IP 2054 10 (0x806): ARP 3282 10 (0xcd2): RARP .'RKTMZN HOZY The length, in bytes, of the hardware (MAC) address. For Ethernet it is 6. 6'RKTMZN HOZY The length, in bytes, of the internetwork protocol address. For IP it is 4. 5VKXGZOUT HOZY Indicates the type of ARP datagram: 1 = ARP request 2 = ARP reply 3 = RARP request 4 = RARP reply 9KTJKX.' HOZY The hardware (MAC) address of the sender. 9KTJKX6' HOZY The (internetwork) protocol address of the sender. Target HA: 48 bits The hardware (MAC) address of the target host. :GXMKZ6' The (internetwork) protocol address of the target host. Because of the use of fields to indicate the lengths of the hardware and protocol addresses, the address fields can be used to carry a variety of address types, making ARP applicable to a number of different types of network. The broadcasting of ARP requests presents some potential problems. Networks such as Ethernet employ connectionless delivery systems i.e. the sender does not receive any feedback as to whether datagrams it has transmitted were received by the target device. If the target is not available, the ARP request destined for it will be lost without trace and no ARP response will be generated. Thus the sender must be programmed to retransmit its ARP request after a certain time period, and must be able to store the datagram it is attempting to transmit in the interim. It must also remember what requests it has sent out so that it does not send out multiple ARP requests for the same address. If it does not receive an ARP reply it will eventually have to discard the outgoing datagrams. Because it is possible for a machine’s hardware address to change, as happens when an Ethernet interface fails and has to be replaced, entries in an ARP cache have a limited life span after which they are deleted. Every time a machine with an ARP cache receives an ARP message, it uses the information to update its own ARP cache. If the incoming address binding already exists it overwrites the existing entry with the fresh information and resets the timer for that entry. The host trying to determine another machine’s MAC address will send out an ARP request to that machine. In the datagram it will set operation = 1 (ARP request), and insert  6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM   its own IP and MAC addresses as well as the destination machine’s IP address in the header. The field for the destination machine’s MAC address will be left zero. It will then broadcast this message using all ‘ones’ in the destination address of the LLC frame so that all hosts on that subnet will ‘see’ the request. If a machine is the target of an incoming ARP request, its own ARP software will reply. It swaps the target and sender address pairs in the ARP datagram (both HA and PA), inserts its own MAC address into the relevant field, changes the operation code to 2 (ARP reply), and sends it back to the requesting host.  6XU^_'86 Proxy ARP enables a router to answer ARP requests made to a destination node that is not on the same subnet as the requesting node. Assume that a router connects two subnets, A and B. If host A1 on subnet A tries to send an ARP request to host B1 on subnet B, this would normally not work as an ARP can only be performed between hosts on the same subnet (where all hosts can ‘see’ and respond to the FF:FF:FF:FF:FF:FF broadcast MAC address). The requesting host, A1, would therefore not get a response. If proxy ARP has been enabled on the router, it will recognize this request and issue its own ARP request, on behalf of A1, to B1. Upon obtaining a response from B1, it would report back to A1 on behalf of B1. It must be understood that the MAC address returned to A1 will not be that of B1, but rather that of the router NIC connected to subnet A, as this is the physical address where A1 will send data destined for B1.  -XGZ[OZU[Y'86 Gratuitous ARP occurs when a host sends out an ARP request looking for its own address. This is normally done at the time of boot-up. This can be used for two purposes. Firstly, a host would not expect a response to the request. If a response does appear, it means that another host with a duplicate IP address exists on the network. Secondly, any host observing an ARP request broadcast will automatically update its own ARP cache if the information pertaining to the destination node already exists in its cache. If a specific host is therefore powered down and the NIC replaced, all other hosts with the powered down host’s IP address in their caches will update when the host in question is re-booted.  8K\KXYKGJJXKYYXKYUR[ZOUTVXUZUIUR8'86 As its name suggests, reverse address resolution protocol (RARP) (RFC 903) does the opposite to ARP. It is used to obtain an IP address when the physical address is known. Usually, a machine holds its own IP address on its hard drive, where the operating system can find it on startup. However, a diskless workstation is only aware of its own hardware address and has to recover its IP address from an address file on a remote server at startup. It uses RARP to retrieve its IP address. A diskless workstation broadcasts an RARP request on the local network using the same datagram format as an ARP request. It has, however, an opcode of 3 (RARP request), and identifies itself as both the sender and the target by placing its own physical address in both the sender hardware address field and the target hardware address field. Although the RARP request is broadcast, only a RARP server (i.e. a machine holding a table of addresses and programmed to provide RARP services) can generate a reply. There should be at least one RARP server on a network, often there are more. . combination of a source IP address and a non- zero flow label. A flow label is assigned to a flow by the flow’s source node. Flow labels are chosen (pseudo-) randomly and uniformly from the range. swaps the target and sender address pairs in the ARP datagram (both HA and PA), inserts its own MAC address into the relevant field, changes the operation code to 2 (ARP reply), and sends it back. opcode of 3 (RARP request), and identifies itself as both the sender and the target by placing its own physical address in both the sender hardware address field and the target hardware address

Ngày đăng: 04/07/2014, 08:21

Tài liệu cùng người dùng

  • Đang cập nhật ...

Tài liệu liên quan