IPSec Authentication Header (AH)

(Page 2 of 4)

Authentication Header Datagram Placement and Linking

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.

IPv6 Authentication Header Placement and Linking

The AH is inserted into the IP datagram as an extension header,

following the normal IPv6 rules for extension header linking. It is linked
by the previous header (extension or main) putting into its Next
Header field the assigned value for the AH header (51). The AH header
then links to the next extension header or the transport layer header
using its Next Header field.

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.

Technical Details of IPv6

IP version 6 (IPv6) or IP next Generation (IPng) is a new version of the Internet
Protocol, designed as the successor to IP version 4 (IPv4). The changes from IPv4
to IPv6 fall primarily into the following categories:

1: Longer addresses - 128 bits compared to 32 bits

Why is this needed? At present 4 billion IP addresses available - population
estimate for 2050 is approximately 9 billion. IP v6 must be able to cope with the
eventuality that all of these people would like Internet access. With 128-bit long
addresses, superficially that appears to offer about 340 trillion, trillion, trillion
(3.4x1038) addresses. In reality, addresses are structured, and as a result the
number effectively available is somewhat less according to the administrative
policy adopted. Even the most pessimistic projections still indicate that with an
address length of 128 bits, there should be enough for 9 billion people.

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.

3: Better support for options

While IP v6 must aim to be a long-term protocol that can evolve, it must also
provide support for current useful options from IP v4. Any IP v4 options that
weren't "successful" were dropped completely. The way in which options are
represented was changed now allowing routers to ignore options that aren't meant
for them - so speeding up packet forwarding. Other new features mean that there
are less stringent limits on the length of options, and greater flexibility for
introducing new options in the future is provided for.

4: New extensions that support authentication and data

integrity
These extensions are optional therefore do not slow down overall throughput of
connections that have no need for security constraints.

5: Flow labelling capability

This is a new capability to enable the labelling of packets belonging to particular
traffic "flows" for which the sender requests special handling, such as non-default
quality of service or "real-time" service.

6: Anycast address choice added and Multicast altered

The new "anycast" address is used to send a packet to one node belonging to a
specified group of nodes. The scalability of multicast routing is improved by
adding a "scope" field to multicast addresses.

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

IPv6 Header Format - 32 bits

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
|Version| Traffic Class | Flow Label
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
| Payload Length | Next Header | Hop Limit
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
|
|
+
+
|
|
+ Source Address
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
|
|
+
+
|
|
+ Destination Address
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+

Version 4-bit Internet Protocol version number =

6 for IP v6.

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

Payload Length 16-bit unsigned integer

Length of the IPv6 payload, i.e., the rest of the packet following this IPv6 header,
in octets. Any extension headers present are considered part of the payload, i.e.,
included in the length count (this field used to be called "Total Length" in IP v4).

Next Header 8-bit selector

Identifies the type of header immediately following the IPv6 header. This is the
field that allows the header structure of IP v6 to be simplified compared to that
of IP v4. This field selects which if any of the (currently) 6 extension headers
follow the present header. If the present header is the last header, the next
header field contains the name of the transport protocol handler to be used for
that packet (making the "Protocol" field from Ipv4 redundant).

Hop Limit 8-bit unsigned integer

Decremented by 1 by each node that forwards the packet. The packet is
discarded if Hop Limit is decremented to zero. This replaces the "Time to Live"
field from IP v4. Using the number of hops rather than a number of seconds
reflects more the way packets are actually sent and dealt with by routers.

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).

IPv6 addresses and how they are allocated

The addresses are divided up into

• Reserved for IPv4.

• OSI NSAP addresses
• Novell Netware IPX addresses
• Reserved for provider-based addresses
• Reserved for geographic-based addresses
• Unassigned
• Link local use addresses
• Site local use addresses
 • Multicast addresses

In more detail

Allocation Prefix(binary) Fraction of

Address Space

Reserved 0000 0000 1/256

Unassigned 0000 0001 1/256

Reserved for NSAP Allocation0000 001 1/128

Reserved for IPX Allocation 0000 010 1/128

Unassigned 0000 011 1/128

Unassigned 0000 1 1/32
Unassigned 0001 1/16
Unassigned 001 1/8

Provider-Based Unicast Address 010 1/8

Unassigned 011 1/8

Reserved for
Neutral-Interconnect-Based
Unicast Addresses 100 1/8

Unassigned 101 1/8

Unassigned 110 1/8
Unassigned 1110 1/16
Unassigned 1111 0 1/32
Unassigned 1111 10 1/64
Unassigned 1111 110 1/128
Unassigned 1111 1110 0 1/512

Link Local Use Addresses 1111 1110 10 1/1024

Site Local Use Addresses 1111 1110 11 1/1024

Multicast Addresses 1111 1111 1/256

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

Components of IP v6 in more detail:

Extension Headers
In IPv6, optional internet-layer information is encoded in separate headers that
may be placed between the IPv6 header and the upper- layer header in a packet.
Each extension headers is identified by a distinct Next Header value. An IPv6
packet may carry zero, one, or more extension headers, each identified by the
Next Header field of the preceding header.

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.

The main extension headers we will discuss are:

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.

For every packet that is to be fragmented, the source node generates an

Identification value. If a Routing header is present, the Destination Address of
concern is that of the final destination.

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.

At the destination, fragment packets are reassembled into their original,

unfragmented sizes.

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.