Practical TCP/IP and Ethernet Networking- P25 pps


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.