Practical TCP/IP and Ethernet Networking- P12 ppt


6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM


,XGMSKTZULLYKZ HOZY
This field indicates where in the original datagram this fragment belongs. The fragment
offset is measured in units of 8 bytes (64 bits). The first fragment has offset zero. In other
words, the transmitted offset value is equal to the actual offset divided by eight. This
constraint necessitates fragmentation in such a way that the offset is always exactly
divisible by eight. The 13-bit offset also limits the maximum sized datagram that can be
fragmented to 64 kb.
:OSKZURO\K HOZY
The purpose of this field is to cause undeliverable datagrams to be discarded. Every
router that processes a datagram must decrease the TTL by one and if this field contains
the value zero, then the datagram must be destroyed.
The original design called for TTL to be decremented not only for the time it passed a
datagram, but also for each second the datagram is held up at a router (hence the ‘time’ to
live). Currently all routers simply decrement it every time they pass a datagram.
6XUZUIUR HOZY
This field indicates the next (higher) level protocol used in the data portion of the Internet
datagram, in other words the protocol that resides above IP in the protocol stack and
which has passed the datagram on to IP.
Typical values are 0x0806 for ARP and 0x8035 for RARP. (0x meaning ‘hex’.)
.KGJKXINKIQY[S HOZY
This is a checksum on the header only, referred to as a ‘standard Internet checksum’.
Since some header fields change (e.g. TTL), this is recomputed and verified at each point
that the IP header is processed. It is not necessary to cover the data portion of the
datagram, as the protocols making use of IP, such as ICMP, IGMP, UDP and TCP, all
have a checksum in their headers to cover their own header and data.
To calculate it, the header is divided up into 16-bit words. These words are then added
together (normal binary addition with carry) one by one, and the interim sum stored in a

32-bit accumulator. When done, the upper 16 bits of the result is stripped off and added to
the lower 16 bits. If, after this, there is a carry out to the 17th bit, it is carried back and
added to bit 0. The result is then truncated to 16 bits.
9U[XIKGTJJKYZOTGZOUTGJJXKYYKY HOZYKGIN
These are the 32-bit IP addresses of both the origin and the destination of the datagram.
 6GIQKZLXGMSKTZGZOUT
It should be clear by now that IP might often have difficulty in sending packets across a
network since, for example, Ethernet can only accommodate 1500 octets at a time and
X.25 is limited to 576. This is where the fragmentation process comes into play. The
relevant field here is ‘fragment offset’ (13 bits) while the relevant flags are DF (don’t
fragment) and MF (more fragments).
Consider a datagram consisting of an IP header followed by 3500 bytes of data. This
cannot be transported over an Ethernet network, so it has to be fragmented in order to
‘fit’. The datagram will be broken up into three separate datagrams, each with their own
IP header, with the first two frames around 1500 bytes and the last fragment around 500
bytes. The three frames will travel to their destination independently, and will be
recognized as fragments of the original datagram by virtue of the number in the identifier
/TZKXTKZRG_KXVXUZUIURY


field. However, there is no guarantee that they will arrive in the correct order, and the
receiver needs to reassemble them.
For this reason the fragment offset field indicates the distance or offset between the
start of this particular fragment of data, and the starting point of the original frame. One
problem though – since only 13 bits are available in the header for the fragment offset
(instead of 16), this offset is divided by 8 before transmission, and again multiplied by 8
after reception, requiring the data size (i.e. the offset) to be a multiple of 8 – so an offset
of 1500 won’t do. 1480 will be OK since it is divisible by 8. The data will be transmitted
as fragments of 1480, 1480 and finally the remainder of 540 bytes. The fragment offsets
will be 0, 1480 and 2960 bytes respectively, or 0, 185 and 370 – after division by 8.

Incidentally, another reason why the data per fragment cannot exceed 1480 bytes for
Ethernet, is that the IP header has to be included for each datagram (otherwise individual
datagrams will not be routable) and hence 20 of the 1500 bytes have to be forfeited to the
IP header.
The first frame will be transmitted with 1480 bytes of data, fragment offset = 0, and MF
(more flag) = 1
The second frame will be transmitted with the next 1480 bytes of data, fragment offset
= 185, and MF = 1
The last third frame will be transmitted with 540 bytes of data, fragment offset = 370,
MF = 0.
Some protocol analyzers will indicate the offset in hexadecimal, hence it will be
displayed as 0xb9 and 0x172, respectively.
For any given type of network the packet size cannot exceed the so-called MTU
(maximum transmission unit) for that type of network. The following are some default
values:
16 Mbps (IBM) token ring: 17 914 (bytes)
4 Mbps (IEEE802.5) token ring 4464
FDDI 4352
Ethernet/ IEEE802.3 1500
X.25 576
PPP (low delay) 296
The fragmentation mechanism can be checked by doing a ‘ping’ across a network, and
setting the data (–l) parameter to exceed the MTU value for the network.

Figure 6.16
IPv4 fragmentation

6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM



 /TZKXTKZVXUZUIUR\KXYOUT/6\/6TM
 /TZXUJ[IZOUT
IPng (‘IP new generation’), as documented in RFC 1752, was approved by the Internet
Engineering Steering Group in November 1994 and made a Proposed Standard. The
formal name of this protocol is IPv6 (‘IP version 6’). After extensive testing, IANA gave
permission for its deployment in mid-1999.
IPv6 is an update of IPv4, to be installed as a ‘backwards compatible’ software
upgrade, with no scheduled implementation dates. It runs well on high performance
networks such as ATM, and at the same time remains efficient enough for low bandwidth
networks such as wireless LANs. It also makes provision for Internet functions such as
audio broadcasting and encryption.
Upgrading to and deployment of IPv6 can be achieved in stages. Individual IPv4 hosts
and routers may be upgraded to IPv6 one at a time without affecting any other hosts or
routers. New IPv6 hosts and routers can be installed one by one. There are no pre-
requisites to upgrading routers, but in the case of upgrading hosts to IPv6 the DNS server
must first be upgraded to handle IPv6 address records.
When existing IPv4 hosts or routers are upgraded to IPv6, they may continue to use
their existing address. They do not need to be assigned new IPv6 addresses, neither do
administrators have to draft new addressing plans.
The simplicity of the upgrade to IPv6 is brought about through the transition
mechanisms built into IPv6. They include the following:
• The IPv6 addressing structure embeds IPv4 addresses within IPv6 addresses,
and encodes other information used by the transition mechanisms
• All hosts and routers upgraded to IPv6 in the early transition phase will be
‘dual’ capable (i.e. implement complete IPv4 and IPv6 protocol stacks)
• Encapsulation of IPv6 packets within IPv4 headers will be used to carry
them over segments of the end-to-end path where the routers have not yet
been upgraded to IPv6

The IPv6 transition mechanisms ensure that IPv6 hosts can inter-operate with IPv4

hosts anywhere in the Internet up until the time when IPv4 addresses run out, and allows
IPv6 and IPv4 hosts within a limited scope to inter-operate indefinitely after that. This
feature protects the huge investment users have made in IPv4 and ensures that IPv6 does
not render IPv4 obsolete. Hosts that need only a limited connectivity range (e.g., printers)
need never be upgraded to IPv6.
 /6\U\KX\OK]
The changes from IPv4 to IPv6 fall primarily into the following categories:
• Expanded routing and addressing capabilities
IPv6 increases the IP address size from 32 bits to 128 bits, to support more
levels of addressing hierarchy and a much greater number of addressable
nodes, and simpler auto-configuration of addresses
• Anycasting
A new type of address called an anycast address is defined; to identify sets
of nodes where a packet sent to the group of anycast addresses is delivered
/TZKXTKZRG_KXVXUZUIURY


to (only) one of the nodes. The use of anycast addresses in the IPv6 source
route allows nodes to control the path that their traffic flows
• Header format simplification
Some IPv4 header fields have been dropped or made optional, to reduce the
effort involved in processing packets. The IPv6 header was also kept as
small as possible despite the increased size of the addresses. Even though the
IPv6 addresses are four times longer than the IPv4 addresses, the IPv6
header is only twice the size of the IPv4 header
• Improved support for options
Changes in the way IP header options are encoded allows for more efficient
forwarding, less stringent limits on the length of options, and greater
flexibility for introducing new options in the future
• Quality-of-service capabilities

A new capability is added to enable the labeling of packets belonging to
particular traffic ‘flows’ for which the sender requests special handling, such
as special ‘quality of service’ or ‘real-time’ service
• Authentication and privacy capabilities
IPv6 includes extensions that provide support for authentication, data
integrity, and confidentiality
  /6\NKGJKXLUXSGZ

Figure 6.17

IPv6 header

The header contains the following fields:
<KX HOZY
The Internet protocol version number, viz. 6.
)RGYY HOZY
Class value. This replaces the 4-bit priority value envisaged during the early stages of the
design and is used in conjunction with the Flow label.

6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM


,RU]RGHKR HOZY
A flow is a sequence of packets sent from a particular source to a particular (unicast or
multicast) destination for which the source desires special handling by the intervening
routers. This is an optional field to be used if specific non-standard (‘non-default’)
handling is required to support applications that require some degree of consistent
throughput in order to minimize delay and/or jitter. These types of applications are
commonly described as ‘multi-media’ or ‘real-time’ applications.
The flow label will effect the way the packets are handled but will not influence the

routing decisions.
6G_RUGJRKTMZN HOZY
The payload is the rest of the packet following the IPv6 header, in octets. The maximum
payload that can be carried behind a standard IPv6 header cannot exceed 65 536 bytes.
With an extension header this is possible, the datagram is then referred to as a Jumbo
datagram. Payload length differs slightly from the IPv4 in that the ‘total length’ field
does not include the header.
4K^ZNJX HOZY
This identifies the type of header immediately following the IPv6 header, using the same
values as the IPv4 protocol field. Unlike IPv4, where this would typically point to TCP or
UDP, this field could either point to the next protocol header (TCP) or to the next IPv6
extension header.

Figure 6.18

Header insertion and ‘next header’ field

.UVROSOZ HOZY
This is an unsigned integer, similar to TTL in IPv4. It is decremented by 1 by each node
that forwards the packet. The packet is discarded if hop limit is decremented to zero.
9U[XIKGJJXKYY HOZY
This is the address of the initial sender of the packet.
*KYZOTGZOUTGJJXKYY HOZY
This is address of the intended recipient of the packet, which is not necessarily the
ultimate recipient, if an optional routing header is present.
/TZKXTKZRG_KXVXUZUIURY


 /6\K^ZKTYOUTY
IPv6 includes an improved option mechanism over IPv4. Instead of placing extra options

bytes within the main header, IPv6 options are placed in separate extension headers that
are located between the IPv6 header and the transport layer header in a packet.
Most IPv6 extension headers are not examined or processed by routers along a packet’s
path until it arrives at its final destination. This leads to a major improvement in router
performance for packets containing options. In IPv4 the presence of any options requires
the router to examine all options.
IPv6 extension headers can be of arbitrary length and the total amount of options
carried in a packet is not limited to 40 bytes as with IPv4. They are also not carried within
the main header, as with IPv4, but are only used when needed, and are carried behind the
main header. This feature plus the manner in which they are processed, permits IPv6
options to be used for functions, which were not practical in IPv4. Good examples of this
are the IPv6 authentication and security encapsulation options.
In order to improve the performance when handling subsequent option headers and the
transport protocol which follows, IPv6 options are always an integer multiple of 8 octets
long, in order to retain this alignment for subsequent headers.
The IPv6 extension headers currently defined are:
• Routing header (for extended routing, similar to the IPv4 loose source route).
• Fragment header (for fragmentation and reassembly).
• Authentication header (for integrity and authentication).
• Encrypted security payload (for confidentiality).
• Hop-by-hop options header (for special options that require hop-by-hop
processing).
• Destination options header (for optional information to be examined by the
destination node).


Figure 6.19
Carrying IPv6 extension headers
 /6\GJJXKYYKY
IPv6 addresses are 128 bits long and are identifiers for individual interfaces or sets of

interfaces. IPv6 Addresses of all types are assigned to interfaces (i.e. network interface
Cards) and NOT to nodes i.e. hosts. Since each interface belongs to a single node, any of

6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM


that node’s interface’s unicast addresses may be used as an identifier for the node. A
single interface may be assigned multiple IPv6 addresses of any type.
There are three types of IPv6 addresses. These are unicast, anycast, and multicast.
• Unicast addresses identify a single interface
• Anycast addresses identify a set of interfaces such that a packet sent to an
anycast address will be delivered to one member of the set
• Multicast addresses identify a group of interfaces, such that a packet sent to
a multicast address is delivered to all of the interfaces in the group. There are
no broadcast addresses in IPv6, their function being superseded by multicast
addresses

The IPv6 address is four times the length of IPv4 addresses (128 vs 32). This is 4
billion times 4 billion (2
96
) times the size of the IPv4 address space (2
32
). This works out
to be 340 282 366 920 938 463 463 374 607 431 768 211 456. Theoretically this is
approximately 665 570 793 348 866 943 898 599 addresses per square meter of the
surface of the planet Earth (assuming the Earth surface is 511 263 971 197 990 square
meters). In more practical terms, considering that the creation of addressing hierarchies,
which reduces the efficiency of the usage of the address space, IPv6 is still expected to
support between 8×10
17

to 2×10
33
nodes. Even the most pessimistic estimate provides
around 1500 addresses per square meter of the surface of planet Earth.
The leading bits in the address indicate the specific type of IPv6 address. The variable-
length field comprising these leading bits is called the format prefix (FP). The current
allocation of these prefixes is as follows:

Figure 6.20
IPv6 address ranges
This allocation supports the direct allocation of global unicast addresses, local use
addresses, and multicast addresses. Space is reserved for NSAP addresses, IPX addresses,
and geographic-based unicast addresses. The remainder of the address space is
unassigned for future use. This can be used for expansion of existing use (e.g., additional
/TZKXTKZRG_KXVXUZUIURY


provider addresses, etc) or new uses (e.g., separate locators and identifiers). Note that
anycast addresses are not shown here because they are allocated out of the unicast address
space.
Approximately fifteen per cent of the address space is initially allocated. The remaining
85% is reserved for future use.
;TOIGYZGJJXKYYKY
There are several forms of unicast address assignment in IPv6. These are:
• Global unicast addresses
• Unspecified addresses
• Loopback addresses
• IPv4-based addresses
• Site local addresses
• Link local addresses

-RUHGR[TOIGYZGJJXKYYKY
These addresses are used for global communication. They are similar in function to IPv4
addresses under CIDR. Their format is:


Figure 6.21

Address format: Global unicast address

The first 3 bits identify the address as a global unicast address.
The next, 13-bit, field (TLA) identifies the top level aggregator. This number will be
used to identify the relevant Internet ‘exchange point’, or long-haul (‘backbone’)
provider. These numbers (8192 of them) will be issued by IANA, to be further distributed
via the three regional registries (ARIN, RIPE and APNIC), who could possibly further
delegate the allocation of sub-ranges to national or regional registries such as the French
NIC managed by INRIA for French networks.
The third, 32-bit, field (NLA) identifies the next level aggregator. This will probably
be structured by long-haul providers to identify a second-tier provider by means of the
first n bits, and to identify a subscriber to that second-tier provider by means of the
remaining 32–n bits.
The fourth, 16-bit, field is the SLA or site local aggregator. This will be allocated to a
link within a site, and is not associated with a registry or service provider. In other words,
it will remain unchanged despite a change of service provider. Its closest equivalent in
IPv4 would be the ‘NetID’.
The last field is the 64-bit interface ID. This is the equivalent of the ‘HostID’ in IPv4.
However, instead of an arbitrary number it would consist of the hardware address of the
interface, e.g. the Ethernet MAC address.
• All identifiers will be 64 bits long even if there are only a few devices on the
network
• Where possible these identifiers will be based on the IEEE EUI-64 format

Existing 48-bit MAC addresses are converted to EUI-64 format by splitting them in the
middle and inserting the string FF-FE in between the two halves.

6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM



Figure 6.22
Converting a 48-bit MAC address to EUI-64 format
;TYVKIOLOKJGJJXKYYKY
This can be written as 0:0:0:0:0:0:0:0, or simply ‘::’ (double colon). This address can be
used as a source address by a station that has not yet been configured with an IP address.
It can never be used as a destination address. This is similar to 0.0.0.0 in IPv4.
2UUVHGIQGJJXKYYKY
The loopback address 0:0:0:0:0:0:0:1 can be used by a node to send a datagram to itself.
It is similar to the 127.0.0.1 of IPv4.
/6\HGYKJGJJXKYYKY
It is possible to construct an IPv6 address out of an existing IPv4 address. This is done by
prepending 96 zero bits to a 32-bit IPv4 address. The result is written as
0:0:0:0:0:0:192.100.100.3, or simply ::192.100.100.3.
9OZKRUIGR[TOIGYZGJJXKYYKY
Site local addresses are partially equivalent of the IPv4 private addresses. The site local
addressing prefix 111 1110 11 has been reserved for this purpose. A typical site local
address will consist of this prefix, a set of 38 zeros, a subnet ID, and the interface
identifier. Site local addresses cannot be routed in the Internet, but only between two
stations on a single site.
The last 80 bits of a site local address are identical to the last 80 bits of a global unicast
address. This allows for easy renumbering where a site has to be connected to the
Internet.

Figure 6.23

Site-local unicast addresses
2OTQRUIGR[TOIGYZGJJXKYYKY
Stations that are not yet configured with either a provider-based address or a site local
address may use link local addresses. Theses are composed of the link local prefix, 1111
1110 10, a set of 0s, and an interface identifier. These addresses can only be used by
stations connected to the same local network and packets addressed in this way cannot
traverse a router.
/TZKXTKZRG_KXVXUZUIURY



Figure 6.24
Link-local unicast addresses
'T_IGYZGJJXKYYKY
An IPv6 anycast address is an address that is assigned to more than one interface
(typically belonging to different nodes), with the property that a packet sent to an anycast
address is routed to the ‘nearest’ interface having that address, according to the routing
protocols’ measure of distance. Anycast addresses, when used as part of a route
sequence, permits a node to select which of several internet service providers it wants to
carry its traffic. This capability is sometimes called ‘source selected policies’. This
would be implemented by configuring anycast addresses to identify the set of routers
belonging to Internet service providers (e.g. one anycast address per Internet service
provider). These anycast addresses can be used as intermediate addresses in an IPv6
routing header, to cause a packet to be delivered via a particular provider or sequence of
providers.
Other possible uses of anycast addresses are to identify the set of routers attached to a
particular subnet, or the set of routers providing entry into a particular routing domain.

Anycast addresses are allocated from the unicast address space, using any of the defined
unicast address formats. Thus, anycast addresses are syntactically indistinguishable from
unicast addresses. When a unicast address is assigned to more than one interface, thus
turning it into an anycast address, the nodes to which the address is assigned must be
explicitly configured to know that it is an anycast address.
3[RZOIGYZGJJXKYYKY
An IPv6 multicast address is an identifier for a group of interfaces. An interface may
belong to any number of multicast groups. Multicast addresses have the following format:

Figure 6.25
Address format: IPv6 multicast
The 11111111 (0xFF) at the start of the address identify the address as being a multicast
address.
• FLGS. Four bits are reserved for flags. The first 3 bits are currently
reserved, and set to 0. The last bit (the one on the right) is called T for
‘transient’. T = 0 indicates a permanently assigned (‘well-known’) multicast
address, assigned by IANA, while T = 1 indicates a non-permanently
assigned (‘transient’) multicast address