Beruflich Dokumente
Kultur Dokumente
(Page 2 of 4)
The calculation of the authentication header is similar for both IPv4 and
IPv6. One difference is in the exact mechanism used for placing the
header into the datagram and for linking the headers together. I'll
describe IPv6 first since it is simpler, as AH was really designed to fit
into IPv6’s mechanism for this.
In transport mode, the AH is placed into the main IP header and appears
before any Destination Options header containing options intended for
the final destination, and before an ESP header if present, but after any
other extension headers. In tunnel mode, it appears as an extension
header of the new IP datagram that encapsulates the original one being
tunneled. This is shown graphically in Figure 121.
Figure 121: IPv6 Datagram Format With IPSec Authentication Header (AH)
At top is an example IPv6 datagram with two extension headers linked using the
standard IPv6 mechanism (see Figure 106.) When AH is applied in transport
mode, it is simply added as a new extension header (shown in pink) that goes
between the Routing extension header and theDestination Options header. In
tunnel mode, the entire original datagram is encapsulated into a new IPv6
datagram that contains the Authentication Header. In both cases the Next
Header fields are used to link each header one to the next. Note the use of Next
Header value 41 in tunnel mode, which is the value for the encapsulated IPv6
datagram.
IP v6 must also take into account that these users must have more than 1
networked device. Even if the addresses are allocated in a less than efficient
manner, IP v6 should still be able to cope with the demand, whereas without
preventative measures, it was predicted that under IP v4 we would have run out
of addresses by 2000.
However many users IP v6 can cope with, there is no way for the world to simply
switch to IP v6 overnight, which is why one of the greatest challenges for the
creators of IP v6 was to make it backwards compatible with IP v4 and for its
transition to be complete before IPv4 routing and addressing break.
2: Simplification of headers
Now as there are only 7 fields compared to a previous 13 in IP v4 - there is less
overhead as would be expected from headers for addresses of this size. This leads
to faster processing by routers and improved throughput. With some IPv4 header
fields dropped or made optional, the cost of processing packets is reduced and
the bandwidth cost is also limited. Another major difference is the absence of the
"Checksum" field. With the advent of data and transport layers that have their
own checksums, it was a waste or processing power and in an IP is now mostly
redundant.
7: Automatic Configuration
IPv6 has provision for "plug and play" automatic configuration, which promises
reduced complexity of network deployment and administration.
8: Backwards Compatibility
Pretty good backward compatibility and interoperability - can embed IP v4
addresses within IP v6 addresses. Dual capable routers and hosts - IPv6 and IPv4,
encapsulating IPv6 packets within IPv4 headers to carry them over segments of
the end-to-end path where the routers have not yet been upgraded to IPv6. The
header translation technique to allow the eventual introduction of routing
topologies that route only IPv6 traffic, and the deployment of hosts that support
only IPv6
Traffic Class 8-bit traffic class field, also known as priority field
Distinguishes between packets that can be flow controlled and those that cannot.
1-7 indicate lower priority transmissions that can be slowed down in case of
congestion while 8 - 15 could represent real time traffic whose sending rate is
constant - e.g. audio or video. 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.
Flow Label 20-bit flow label
Still experimental but allows different connections between different sources and
destinations to specify special treatment for some of those connections compared
to the others, e.g. no delay allowed on this connection
Source Address
128-bit address of the originator of the packet.
Destination Address
128-bit address of the intended recipient of the packet (possibly not the ultimate
recipient, if a Routing header is present).
In more detail
Reserved for
Neutral-Interconnect-Based
Unicast Addresses 100 1/8
The new address lengths support more levels of addressing hierarchy, a much
greater number of addressable nodes, and simpler auto-configuration of
addresses.
Addresses beginning with 80 zeros are reserved for IPv4. Separate prefixes for
provider-based and geographic-based addresses. The geographic-based structure
is divided up in much the same fashion as the current Internet. The last 15 bits of
the provider-based addresses can be divided up at the provider's discretion. Flags
within the multicast addresses differentiate between permanent and transient
groups and now has a scope field to allow the multicast to be limited to a
particular link, site, organisation, etc.
The notation for writing IPv6 addresses is to write it them as 8 groups of four
hexadecimal digits with colons between the groups.
8000:1234:0345:4321:1234:0000:0000:abcd
Leading zeroes within a group may be omitted and groups of zeros may be
replaced by a pair of colons.
8000:1234:345:4321:1234::abcd
IPv4 addresses can be written as a pair of colons and the old dotted decimal
number.
::159.124.237.6
Extension headers are not examined or processed by any node along a packet's
delivery path, until the packet reaches the node (or each of the set of nodes, in
the case of multicast) identified in the Destination Address field of the IPv6
header. Extension headers must be processed strictly in the order they appear in
the packet.
The exception to this is the Hop-by-Hop Options header, see below. Each
extension header is an integer multiple of 8 octets long, in order to retain 8-octet
alignment for subsequent headers.
Routing
The Routing header is used by an IPv6 source to list one or more intermediate
nodes to be "visited" on the way to a packet's destination. This function is very
similar to IPv4's Loose Source and Record Route option. The Routing header is
identified by a Next Header value of 43 in the immediately preceding header. A
Routing header is not examined or processed until it reaches the node identified
in the Destination Address field of the IPv6 header.
Fragment
The Fragment header is used by an IPv6 source to send a packet larger than would
fit in the path MTU to its destination. (Note: unlike IPv4, fragmentation in IPv6 is
performed only by source nodes, not by routers along a packet's delivery path.
The Fragment header is identified by a Next Header value of 44 in the
immediately preceding header. In order to send a packet that is too large to fit in
the MTU of the path to its destination, a source node may divide the packet into
fragments and send each fragment as a separate packet, to be reassembled at the
receiver.
The initial, large, unfragmented packet is referred to as the "original packet", and
it is considered to consist of two parts:
1. The Unfragmentable Part which consists of the IPv6 header plus any extension
headers that must be processed by nodes en route to the destination.
2. The Fragmentable Part consists of the rest of the packet, that is, any extension
headers that need be processed only by the final destination node(s), plus the
upper-layer header and data.
Authentication
"IPng Authentication Header", is an extension header, which provides
authentication and integrity (without confidentiality) to IPng datagrams. The
receiver of a packet can be sure who sent it, unlike in IPv4 in which no guarantee
is present. The payload of the authenticated packet is sent unencrypted. The
extension is algorithm- independent and will support many different
authentication techniques.
Encapsulating
"IPng Encapsulating Security Header" - This mechanism provides integrity and
confidentiality to IPv6 datagrams using encrypted security payload extension
headers. It is simpler than some similar security protocols (e.g., SP3D, ISO NLSP)
but remains flexible and algorithm-independent.
Destination options
The Destination Options header is used to carry optional information that need be
examined only by a packet's destination node(s). The Destination Options header
is identified by a Next Header value of 60 in the immediately preceding header.
Optional destination information could also be encoded as a separate extension
header. Which to use depends on what action is desired of a destination node.
Hop by hop
This carries information that must be examined and processed by every node
along a packet's delivery path, including the source and destination nodes. The
Hop-by-Hop Options header, when present, must immediately follow the IPv6
header and its presence is indicated by the value zero in the Next Header field of
the IPv6 header.