IPv6 (Internet Protocol version 6) is a version of the Internet Protocol (IP) intended to succeed IPv4, which is the protocol

currently used to direct almost all Internet traffic.[1] IPv6 was developed by the Internet Engineering Task Force (IETF) to deal with this long-anticipated IPv4 address exhaustion, and is described in Internet standard document RFC 2460, published in December 1998. Like IPv4, IPv6 is an internet-layer protocol for packet-switched internetworking and provides end-to-end datagram transmission across multiple IP networks. While IPv4 allows 32 bits for an IP address, and therefore has 232 (4 294 967 296) possible addresses, IPv6 uses 128-bit addresses, for an address space of 2128 (approximately 3.41038) addresses. This expansion allows for many more devices and users on the internet as well as extra flexibility in allocating addresses and efficiency for routing traffic. It also eliminates the primary need for network address translation (NAT), which gained widespread deployment as an effort to alleviate IPv4 address exhaustion. Comparison to IPv4 IPv6 specifies a new packet format, designed to minimize packet header processing by routers.[3][17] Because the headers of IPv4 packets and IPv6 packets are significantly different, the two protocols are not interoperable. However, in most respects, IPv6 is a conservative extension of IPv4. Most transport and application-layer protocols need little or no change to operate over IPv6; exceptions are application protocols that embed internet-layer addresses, such as FTP and NTPv3, where the new address format may cause conflicts with existing protocol syntax. Larger address space Decomposition of an IPv6 address into its binary form The main advantage of IPv6 over IPv4 is its larger address space. The length of an IPv6 address is 128 bits, compared to 32 bits in IPv4. The address space therefore has 2128 or approximately 3.41038 addresses. By comparison, this amounts to approximately 4.81028 addresses for each of the seven billion people alive in 2011. In addition, the IPv4 address space is poorly allocated, with approximately 14% of all available addresses utilized. While these numbers are large, it was not the intent of the designers of the IPv6 address space to assure geographical saturation with usable addresses. Rather, the longer addresses simplify allocation of addresses, enable efficient route aggregation, and allow implementation of special addressing features. In IPv4, complex Classless Inter-Domain Routing (CIDR) methods were developed to make the best use of the small address space. The standard size of a subnet in IPv6 is 264 addresses, the square of the size of the entire IPv4 address space. Thus, actual address space utilization rates will be small in IPv6, but network management and routing efficiency is improved by the large subnet space and hierarchical route aggregation. Multicasting Multicasting, the transmission of a packet to multiple destinations in a single send operation, is part of the base specification in IPv6. In IPv4 this is an optional although commonly implemented feature. IPv6 multicast addressing shares common features and protocols with IPv4 multicast, but also provides changes and improvements by eliminating the need for certain protocols. IPv6 does not implement traditional IP broadcast, i.e. the transmission of a packet to all hosts on the attached link using a special broadcast address, and therefore does not define broadcast addresses. In IPv6, the same result can be achieved by sending a packet to the link-local all nodes multicast group at address ff02::1, which is 1

analogous to IPv4 multicast to address 224.0.0.1. IPv6 also provides for new multicast implementations, including embedding rendezvous point addresses in an IPv6 multicast group address, which simplifies the deployment of inter-domain solutions. In IPv4 it is very difficult for an organization to get even one globally routable multicast group assignment, and the implementation of inter-domain solutions is very arcane. Unicast address assignments by a local Internet registry for IPv6 have at least a 64-bit routing prefix, yielding the smallest subnet size available in IPv6 (also 64 bits). With such an assignment it is possible to embed the unicast address prefix into the IPv6 multicast address format, while still providing a 32-bit block, the least significant bits of the address, or approximately 4.2 billion multicast group identifiers. Thus each user of an IPv6 subnet automatically has available a set of globally routable source-specific multicast groups for multicast applications. Stateless address auto configuration (SLAAC) IPv6 hosts can configure themselves automatically when connected to a routed IPv6 network using Internet Control Message Protocol version 6 (ICMPv6) router discovery messages. When first connected to a network, a host sends a link-local router solicitation multicast request for its configuration parameters; if configured suitably, routers respond to such a request with a router advertisement packet that contains network-layer configuration parameters. If IPv6 stateless address auto configuration is unsuitable for an application, a network may use stateful configuration with the Dynamic Host Configuration Protocol version 6 (DHCPv6) or hosts may be configured statically. Routers present a special case of requirements for address configuration, as they often are sources for auto configuration information, such as router and prefix advertisements. Stateless configuration for routers can be achieved with a special router renumbering protocol. Mandatory network-layer security Internet Protocol Security (IPsec) was originally developed for IPv6, but found widespread deployment first in IPv4, into which it was back-engineered. Earlier, IPsec was an integral part of the base IPv6 protocol suite, but has since been made optional. Simplified processing by routers In IPv6, the packet header and the process of packet forwarding have been simplified. Although IPv6 packet headers are at least twice the size of IPv4 packet headers, packet processing by routers is generally more efficient, thereby extending the end-to-end principle of Internet design. Specifically:

The packet header in IPv6 is simpler than that used in IPv4, with many rarely used fields moved to separate optional header extensions. IPv6 routers do not perform fragmentation. IPv6 hosts are required to either perform path MTU discovery, perform end-to-end fragmentation, or to send packets no larger than the IPv6 default minimum MTU size of 1280 octets. The IPv6 header is not protected by a checksum; integrity protection is assumed to be assured by both link-layer and higher-layer (TCP, UDP, etc.) error detection. UDP/IPv4 may actually have a 2

checksum of 0, indicating no checksum; IPv6 requires UDP to have its own checksum. Therefore, IPv6 routers do not need to re compute a checksum when header fields (such as the time to live (TTL) or hop count) change. This improvement may have been made less necessary by the development of routers that perform checksum computation at link speed using dedicated hardware, but it is still relevant for software-based routers. The TTL field of IPv4 has been renamed to Hop Limit, reflecting the fact that routers are no longer expected to compute the time a packet has spent in a queue.

Mobility Unlike mobile IPv4, mobile IPv6 avoids triangular routing and is therefore as efficient as native IPv6. IPv6 routers may also allow entire subnets to move to a new router connection point without renumbering. Privacy Like IPv4, IPv6 supports globally unique static IP addresses, which can be used to track a single device's Internet activity. Most devices are used by a single user, so a device's activity is often assumed to be equivalent to a user's activity. This is a cause for concern to anyone who has political, social, or economic reasons for keeping their Internet activity secret. Activity tracking based on IP address is a potential privacy issue for all IP-enabled devices. However, device activity can be particularly simple to track when the host identifier portion of the IPv6 address is automatically generated from the network interface's MAC address. Privacy extensions for IPv6 have been defined to address these privacy concerns. When privacy extensions are enabled, the operating system generates ephemeral IP addresses by concatenating a randomly generated host identifier with the assigned network prefix. These ephemeral addresses, instead of trackable static IP addresses, are used to communicate with remote hosts. The use of ephemeral addresses makes it difficult to accurately track a user's Internet activity by scanning activity streams for a single IPv6 address. Packet format An IPv6 packet has two parts: a header and payload. The header consists of a fixed portion with minimal functionality required for all packets and may contain optional extensions to implement special features. The fixed header occupies the first 40 octets (320 bits) of the IPv6 packet. It contains the source and destination addresses, traffic classification options, a hop counter, and a pointer for extension headers, if any. The Next Header field, present in each extension, points to the next element in the chain of extensions. The last field points to the upper-layer protocol that is carried in the packet's payload. Extension headers carry options that are used for special treatment of a packet in the network, e.g., for routing, fragmentation, and for security using the IPsec framework.

Without special options, a payload must be less than 64KB. With a Jumbo Payload option (in a Hop-ByHop Options extension header), the payload must be less than 4 GB. Extension Headers IPv6 includes an improved option mechanism over IPv4. 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 any router along a packet's delivery path until the packet arrives at its final destination. This feature is a major improvement in router performance for packets that contain options. In IPv4, the presence of any options requires the router to examine all options. Unlike IPv4 options, IPv6 extension headers can be of arbitrary length. Also, the number of options that a packet carries are not limited to 40 bytes. This feature, plus the manner in which IPv6 options are processed, permits IPv6 options to be used for functions that are not practical in IPv4. A good example of IPv6 options is the IPv6 authentication and security encapsulation options. To improve performance when handling subsequent option headers, and the transport protocol that follows, IPv6 options are always an integer multiple of eight octets long. The integer multiple of eight octets retains the alignment of subsequent headers. The following IPv6 extension headers are currently defined.

Routing Extended routing, like IPv4 loose source route Fragmentation Fragmentation and reassembly Authentication Integrity and authentication, security Encapsulation Confidentiality Hop-by-Hop Option Special options that require hop-by-hop processing Destination Options Optional information to be examined by the destination node

Options Among extension headers previously listed, the Hop-by-Hop Options header and the Destination Options header carry variable numbers of options. These options, which are encoded in a format called TLV (Type-Length-Value), are shown in Figure 3-3. The three fields that appear in the described option have the following meanings: Option Type is an 8-bit unsigned integer; it identifies the type of option. Option Data Length is an 8-bit unsigned integer that contains the length of the Option Data field in octets. Option Data is a variable length field that contains the option-type specific data.The Option Type field assigns a particular meaning to the three highest order bits .In particular, the two highest order bits (Action) specify the action that must be taken if the processing IPv6 node doesnt recognize the option type. These bits can have the following values: 00 Skip over this option and continue to process eventual subsequent options. 01 Discard the packet. 10 Discard the packet, regardless of whether the packet destination address is multicast; the source node is notified by an ICMP packet. Figure 3-3

QoS in ipv6
QoS developments in IP networks is inspired by new types of applications: VoIP, audio/video streaming, networked virtual environments, interactive gaming, videoconferencing, video distribution, e-commerce, GRIDs & collaborative enviroments, etc. Quality-of-S ervice (QoS ) is a set of service requirements (performance guarantees) to be met by the network while transporting a flow. QoS Architectures Best Effort Internet Integrated Services Performance guarantees to traffic and resource reservations are provided on per-flow basis. Guaranteed & Controlled Load Service Scaling issues (per flow state information) Differentiated Services Performance guarantees are provided to traffic aggregates rather than to flows. Per-Hop Behaviors (PHB): EF & AF Lack of any signaling protocol for resource allocation (admission control) and QoS mechanisms control. Example of services: Premium, Silver, LBE QoS fields in IPv6 Header Traffic Class An 8-bit field used to distinguish packets from different classes or priorities. Provides the same functionality as the type of service field in the IPv4 header. Flow label A 20-bit field defining the packets of the flow. Selected by the source and never modified in the network. Fragmentation or encryption is not anymore problem, as in IPv4. IPV6 Security IPSec IPv4 also offers IPSec support. However, IPv4s support for IPSec is optional. By contrast, the RFC4301 mandates for IPv6 to use IPSec in all nodes. IPSec consists of a set of cryptographic protocols that provide for securing data communication and key exchange. IPSec uses two wire-level protocols, Authentication Header (AH) and Encapsulating Security Payload (ESP). The first protocol provides for authentication and data integrity. The second protocol provides for authentication, data integrity, and confidentiality. In IPv6 networks both the AH header and the ESP header are defined as extension headers. Additionally, IPSec provides for a third suite of protocols for protocol negotiation and key exchange management known as the Internet Key Exchange (IKE). This protocol suite provides the initial functionality needed to establish and negotiating security parameters between endpoints. Additionally, it keeps track of this information to guarantee that communication continues to be secure up to the end.

4.2.2. Encapsulating Security Payload. In addition to providing the same functionality the AH protocol providesauthentication, data integrity, and replay protection. ESP also provides confidentiality. In the ESP extension header, security parameter index (SPI) field identifies what group of security parameters the sender is using to secure communication. ESP supports any number of encryption mechanisms. However, the protocol specifies DES-CBC as its default. Also, ESP does not provide the same level of authentication available with AH. While AH authenticates the whole IP header (in fact, only those fields that do not change in transit), ESP authenticates only the information that follows it . ESP provides data integrity by implementing an integrity check value (ICV) that is part of the ESP header trailer the authentication field. The ICV is computed once any encryption is complete and it includes the whole ESP header/trailerexcept for the authentication field, of course. The ICV uses hash message authentication code (HMAC) with SHA-1 and MD5 as the recommended cryptographic hash functions. Transport and tunnel modes. In IPv4 networks, IPSec provides two modes of securing traffic. The first one is called transport mode and it is intended to provide secure communication between endpoints by securing only the packets payload. The second one is called tunnel mode and it is intended to protect the entire IPv4 packet. However, in IPv6 networks, there is no need for a tunnel mode because, as mentioned above, both the AH and ESP protocols provide enough functionality to secure IPv6 traffic. Protocol negotiation and key exchange management. In addition to AH and ESP, IPSec also specifies additional functionality for protocol negotiation and key exchange management . IPSec encryption capabilities depend on the ability to negotiate and exchange encryption keys between parties. To accomplish this task, IPSec specifies an Internet key exchange (IKE) protocol. IKE provides the following functionality: Negotiating with other people the protocols, encryption algorithms, and keys, to use. Exchanging keys easily, including changing them often. Keeping track of all these agreements. To keep track of all protocol and encryption algorithm agreements, IPSec uses the SPI field in both the AH and ESP headers. This field is an arbitrary 32-bit number that represents a security association (SA). When communication is negotiated, the receiver node assigns an available SPI which is not in use, and preferably one that has not been used in a while. It then communicates this SPI to its communication partner establishing a security association. From then until that SA expires, whenever a node wishes to communicate with the other using the same SA, it must use the same SPI to specify it. The other node, on receipt, would look at the SPI to determine which SA it needs to use. Then it authenticates and/or decrypts the packet according to the rules of that SA, using the agreed-upon keys and algorithms the SA specifies. The node then uses the same agree-upon information to verify that the data really does come from the node it claims. Also, the node uses the same information to verify that the data has not been modified as well as that no one between the two nodes has read the exchanged data. Of course, before all this happens, both nodes must negotiate a set of keys. The keys will be used to guarantee that the SA parameters are securely exchanged. IPSec allows for using both automatic and manual key exchange. However, because manual exchange does not scale well, IPSec recommends using IKE. IPSec IKE offers a robust mechanism to authenticate communication parties based on a public key infrastructure (PKI). Encryption keys are generated with a Diffie-Hellman algorithm based on each nodes public and private key pairs. This mechanism offers perfect forward secrecy (generating keys that are not reliant on previously generated key values) as well as reasonable scalability. Neighbor discovery and address auto configuration Neighbor discovery (ND) is the mechanism responsible for router and prefix discovery, duplicate address and network un reachability detection, parameter discovery, and link-layer address resolution . This protocol is entirely network-layer based3. ND operates in tandem with auto-configuration, which is the mechanism used by IPv6 nodes to acquire either stateful or 6

stateless configuration information. In the stateless mode, all nodes get what they need for global communication, including potential illegal ones. In stateful mode, configuration information can be provided selectively, reducing the possibility for rogue nodes. Both ND and address auto-configuration contribute to make IPv6 more secure than its predecessor. IPv6 provides for TTL values of up to 255; it prevents against outside sourcing of ND packets or duplicate addresses. IPv6 security issues From a security point of view, the new IPv6 protocol stack represents a considerable advance in relation to the old IPv4 stack. However, despite its innumerable virtues, IPv6 still continues to be by far vulnerable. In this section we will review some of the areas of IPv6 where security continues to be an important issue. Dual-stack related issues Presently, the Internet continues to be mostly IPv4- based. However, it is reasonable to expect that this scenario will change soon as more and more networks are migrated to the new protocol stack. Unfortunately, migrating millions of networks is going to take quite some time. In the meantime, some form of 6to4 dual-stack will supply the desired functionality. Without a doubt, IPv6-IPv4 dual stacks increase the potential for security vulnerabilitiesas a consequence of having two infrastructures with specific security problems. However, most of the issues are not a direct result of specific IPv6 design flaws but mostly a result of inappropriate or careless configuration. Header manipulation issues The use of extension headers and IPSec can deter some common sources of attack based on header manipulation. However, the fact that EH must be processed by all stacks can be a source of troublea long chain of EH or some considerably large-size could be used to overwhelm certain nodes (e.g., firewalls) or masquerade an attack. Best practices recommend to filter out traffic with unsupported services. Spoofing continues to be a possibility in IPv6 networks However, because of ND, spoofing is only possible by nodes on the same network segment. The same does not apply to 6to4 transition networks. Although one approach to 6to4 transition is using some form of dual-stack functionality, another approach is using some type of tunneling. Because tunneling requires that a protocol is encapsulated in another, its use could be a source of security problems such as address spoofingin this case if the spoofed address is used to masquerade an external packet as one that was originated from the inside network. Flooding issues Scanning for valid host addresses and services is considerably more difficult in IPv6 networks than it is in IPv4 networks. As mentioned above, to effectively scan a whole IPv6 segment may take up to 580 billion years because the address space uses 64 bits. However, the larger addressing space does not mean that IPv6 is totally invulnerable to this type of attack. Nor the lack of broadcast addresses makes IPv6 more secure. New features such as multicast addresses continue to be source of problems . Smurf-type attacks are still possible on multicast traffic. Again, filtering out unnecessary traffic is the recommended best practice. Mobility Mobility is a totally new feature of IPv6 that was not available in its predecessor. Mobility is a very complex function that raises a considerable amount of concern when considering security. Mobility uses two types of addresses, the real address and the mobile address. The first is a typical IPv6 address contained in an extension header. The second is a temporary address contained in the IP header. Because of the characteristics of this networks (something more complicated if we consider wireless mobility), the temporary component of a mobile node address could be exposed to spoofing attacks on the home agent. Mobility requires special security measures and network administrators must be fully aware of them. Conclusion 7

Without doubt, IPv6 represents a considerable improvement if compared to the old IPv4 protocol stack. The new suite of protocols provides innumerable features that improve both the overall functionality as well as some specific security functions. However, it is far from being a panacea. Although IPv6 offers better security (larger address space and the use of encrypted communication), the protocol also raises new security challenges. Ultimately, the new protocol creates as many new security problems as it solves old ones. And if that is not enough, the transition from the old protocol stack to the new one may present even more challenges, something that will guarantee plenty of fun for security network professionals in the foreseeable future.

FDB5 DE3D F8B5 06E4 A169 4E46 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Authentication Header (AH) The Authentication Header (AH) provides data integrity and data authentication for the entire IPv6 packet. Anti-replay protection is also provided by the AH. 8

Data authentication refers to the fact that if a given computer receives an IP packet with a given source address in the IP header, it can be assured that the IP packet did indeed come from that IP address. Data integrity refers to the fact that if a given computer receives an IP packet, it can be assured that the contents have not been modified along the path from the source node to the destination node. Anti-replay protection means that if a computer has already received a particular IP packet, another packet with modified data wont also be accepted as valid data. Next, the Authentication Header fields will be examined to determine how these security features are provided. Refer to Figure 3 for the format of the Authentication Header (Kent and Atkinson, RFC 2402, p.3). Ingerpri 1 1 Byte 2 Bytes 3 BytesBytent = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Next Next Header Payload Length Security Parameter Index (SPI) Sequence No Field Authentication Data (Variable) Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Next Header field, which identifies the next Extension Header or transport type (e.g. TCP). The Payload Length field contains the length of the Authentication Header. The Security Parameters Index (SPI) field contains the Security Parameters Index to be used in identifying the Security Association. The Sequence Number field is a counter field. The sequence number is set to 0 when the communication phase between the sender and receiver is established. It is subsequently incremented by 1 when either the sender or receiver transmits data. If the receiver detects an IP packet with a duplicate Sequence Number Field, it is rejected (anti-replay protection). This prevents an attack where a hacker may try to modify data and re-send the altered IP data for malicious means similar to that seen in the Session Replay attacks in the current IPv4based Internet. In the Session Replay attack, the hacker saves off the network transmissions between an authenticated user and server. The hacker then modifies the data and re-sends these modified packets as if they came from the authenticated user in the original session. For example, if in the original session, the authenticated user issued an order to sell a block of shares. The hacker could change certain data to indicate an order to purchase a block of shares. The variable length Authentication Data contains the Integrity Check Value (ICV), which provides the authentication and data integrity. The authentication algorithm used to compute the ICV is specified by the SA. IPv6 authentication is very valuable where auto-configuration is deployed to prevent illicit auto-configuration (King et al). The use of the Authentication Header prevents IP Spoofing Attacks, one of the network attack methods in use today. In IP Spoofing, the hacker creates IP packets, via various hacker utilities, 9 ReservedReserved

with a different IP address then the host computer. This can be used for various malicious reasons. The hacker can act as one side of a trust relationship to gain access to a trusting host. For example, if a trust relationship exists with the r utilities (rlogin, rsh, rcp), one computer processes the rlogin command from the other computer without further authentication (i.e. without prompting for a password). This situation where one computer is allowed to rlogin, unauthenticated, into another computer can be potentially dangerous. If the IP address of one of these trusted computers is spoofed by the hacker, the hacker now has access to the other computer. IP Spoofing is also employed in the TCP Session Hijacking attack. During a currently active established session, the attacker pretends to be one of the session participants, by spoofing the source IP address. IP Spoofing is also seen in the Man-in-the-Middle attack. An attacker basically positions himself in between 2 users communicating, using the technique of IP spoofing to become another users computer. . Encapsulating Security Payload (ESP) Header The Encapsulating Security Payload header provides confidentiality and/or authentication and data integrity to the encapsulated payload. Anti-replay protection is also provided by the ESP header. Note: During authentication in the ESP Header, the authentication algorithm is only applied to the data being encrypted. Therefore, the IP header fields are not protected by the authentication algorithm unless those fields are encapsulated in tunnel mode. Confidentiality refers to the fact that a given computer receiving an IP packet can be assured that nobody else has seen the contents of the IP packet, besides the routers needing necessary information. In the ESP header, both the confidentiality and authentication services are optional, however, at least one of these services must be selected. Next, the ESP Header fields will be examined to determine how these security features are provided. Refer to Figure 4 for the format of the ESP packet (Kent and Atkinson, RFC 2406, p.3). SPI Sequence No. Payload data (Variable) Padding 0-255 Bytes Pad Length Authentication data The Encapsulating Security Payload Header also contains an SPI field containing the Security Parameters Index that is used to identify the Security Association. The Sequence Number field is used to provide anti-replay protection as described in the section on the Authentication Header. The encrypted data is placed in the Payload Data field, as seen in Figure 4. The ESP trailer consists of the Padding, Pad Length, Next Header and Authentication Data fields. The Padding field contains any padding bytes that may be needed by the encryption 10 Next Header

algorithm. The Pad Length field contains the number of bytes in the Padding field. The Next Header Field describes the type of data contained in the Payload Data field (e.g., the entire IP packet if tunnel mode was employed or transport payload (TCP, UDP, ICMP) if transport mode was employed). If the authentication security service is specified by the SA associated with the SPI, the Authentication Data field contains the Integrity Check Value (ICV) which provides the authentication and data integrity. The authentication algorithm used to compute the ICV is also specified by the SA. The ICV is calculated over the entire ESP packet, excluding the Authentication Data field. The Payload Data is encrypted with the encryption algorithm, and key(s) identified by the SA. In transport mode, only the transport data is encrypted. In tunnel mode, the entire IP packet is encrypted. The encrypted data is placed in the Payload Data field, as seen in Figure 4. Confidentiality by the ESP header is achieved via encryption. ESP is designed to be used with symmetric encryption algorithms (Kent and Atkinson, RFC 2406, p.10). In symmetric encryption, or secret key encryption, a single key is used for both encrypting and decrypting the data. The Data Encryption Standard (DES) in Cypher Block Chaining (CBC) mode is the proposed encryption algorithm required for global interoperability by RFC 2406, IP Encapsulating Security Payload (ESP). DES is considered a weak encryption algorithm and no longer secure since it has been proven crackable. However, the ESP Header is also algorithm independent. It can be used with stronger encryption algorithms like Triple-DES or AES. The Advance Encryption Standard (AES) encryption algorithm is the latest standard for encryption, replacing DES. The weaker encryption algorithm is defined for global interoperability due to the US export restrictions on strong encryption algorithms. The use of the ESP header, with the confidentiality service enabled, prevents use of a technique called sniffing. Sniffing is a process of getting network transmission either for the data itself or for providing valuable information which may be used later in attacking other computers. Sniffers are one of the most common tools used by hackers. Examples of sniffers include TCPdump (for UNIX systems) and windump (for WINDOW systems), which is a tool used to collect and print IP packets being transmitted over a network. Sniffers can be used to gather information such as passwords, TCP sequence numbers (which may be used in TCP Session Hijacking attacks), any sensitive information transmitted in clear text between a Web browser and Web server, etc. With the IP packet payload data being encrypted, sniffers will no longer provide such valuable information. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

TCP Extensions TCP TCP TCP tuning techniques adjust the network congestion avoidance parameters of TCP connections over high-bandwidth, high-latency networks. Well-tuned networks can perform up to 10 times faster in some 11

cases. However, blindly following instructions without understanding their real consequences can hurt the performance as well.

Network and system characteristics

Bandwidth-delay product (BDP)
Bandwidth-delay product (BDP) is a term primarily used in conjunction with the TCP to refer to the number of bytes necessary to fill a TCP "path", i.e. it is equal to the maximum number of simultaneous bits in transit between the transmitter and the receiver. High performance networks have very large BDPs. To give a practical example, two nodes communicating over a geostationary satellite link with a round trip delay of 0.5 seconds and a bandwidth of 10 Gbit/s can have up to 0.51010 bits, i.e., 5 Gbit = 625 MB of unacknowledged data in flight. Despite having much lower latencies than satellite links, even terrestrial fiber links can have very high BDPs because their link capacity is so large. Operating systems and protocols designed as recently as a few years ago when networks were slower were tuned for BDPs of orders of magnitude smaller, with implications for limited achievable performance.

Buffers
The original TCP configurations supported buffers of up to 64 kBytes (64 KiB), which was adequate for slow links or links with small round trip times (RTTs). Larger buffers are required by the high performance options described below. Buffering is used throughout high performance network systems to handle delays in the system. In general, buffer size will need to be scaled proportional to the amount of data "in flight" at any time. For very high performance applications that are not sensitive to network delays, it is possible to interpose large end to end buffering delays by putting in intermediate data storage points in an end to end system, and then to use automated and scheduled non-real-time data transfers to get the data to their final endpoints.

TCP speed limits

Maximum achievable throughput for a single TCP connection is determined by different factors. One trivial limitation is the maximum bandwidth of the slowest link in the path. But there are also other, less obvious limits for TCP throughput. Bit errors can create a limitation for the connection as well as roundtrip time.

Window size
In computer networking, RWIN (TCP Receive Window) is the amount of data that a computer can accept without acknowledging the sender. If the sender has not received acknowledgement for the first packet it sent, it will stop and wait and if this wait exceeds a certain limit, it may even retransmit. This is how TCP achieves reliable data transmission. 12

Even if there is no packet loss in the network, windowing can limit throughput. Because TCP transmits data up to the window size before waiting for the acknowledgements, the full bandwidth of the network may not always get used. The limitation caused by window size can be calculated as follows:

where RWIN is the TCP Receive Window and RTT is the round-trip time for the path. At any given time, the window advertised by the receive side of TCP corresponds to the amount of free receive memory it has allocated for this connection. Otherwise it would take the risk to have to drop received packets by lack of space. Unrelated to the TCP receive window, the sending side should also allocate the same amount of memory as the receive side for good performance. That is because, even after data has been sent on the network, the sending side must hold it in memory until it has been acknowledged as successfully received, just in case it would have to be retransmitted. If the receiver is far away, acknowledgments will take a long time to arrive. If the send memory is small, it can saturate and block emission. A simple computation gives the same optimal send memory size as for the receive memory size given above.

TCP Options for High Performance

A number of extensions have been made to TCP over the years to increase its performance over fast high-RTT links ("long fat networks", or LFNs for short). TCP timestamps (RFC 1323) play a double role: they avoid ambiguities due to the 32-bit sequence number field wrapping around, and they allow more precise RTT estimation in the presence of multiple losses per RTT. With those improvements, it becomes reasonable to increase the TCP window beyond 64 kB, which can be done using the window scaling option (RFC 1323). The TCP selective acknowledgment options (SACK, RFC 2018) allows a TCP receiver to precisely inform the TCP server about which segments have been lost. This increases performance on high-RTT links, when multiple losses per window are possible. Path MTU discovery avoids the need for in-network fragmentation, which increases performance in the presence of losses. Transaction Oriented Application T / TCP T/TCP is an experimental extension for the TCP protocol. It was designed to address the need for a transaction-based transport protocol in the TCP/IP stack. TCP and UDP are the current choices available for transaction-based applications. TCP is reliable but inefficient for transactions, whereas UDP is unreliable but highly efficient. T/TCP sits between these two protocols, making it an alternative for certain applications. TCP for Transactions (T/TCP) is a possible successor to both TCP and UDP. It is a transaction-oriented protocol based on a minimum transfer of segments, so it does not have the speed problems associated with TCP. By building on TCP, it does not have the unreliability problems associated with UDP. With this in mind, RFC1379 was published in November 1992. It discussed the concepts involved in 13

extending the TCP protocol to allow for a transaction-oriented service. Some of the main points the RFC discussed were bypassing the three-way handshake and shortening the TIME-WAIT state from 240 seconds to 12 seconds. Eighteen months later, RFC1644 was published, with the specification for Transaction TCP. T/TCP cuts out much unnecessary handshaking and error detection done by the current TCP protocol, and as a result, increases the speed of connection and reduces the necessary bandwidth. Transaction Transmission Control Protocol T/TCP can be considered a superset of the TCP protocol. The reason for this is that T/TCP is designed to work with current TCP machines seamlessly. What follows is a brief description of T/TCP and how it differs from the current TCP standard in operation. What is a Transaction? The term transaction refers to the request sent by a client to a server, along with the server's reply. RFC955 lists some of the common characteristics of transaction processing applications:

Asymmetrical Model: the two end points take different roles; this is a typical client-server role where the client requests the data and the server responds. Short Duration: normally, a transaction runs for a short time span. Few Data Packets: each transaction is a request for a small piece of information, rather than a large transfer of information both ways.

Background to T/TCP The growth of the Internet has put a strain on the bandwidth and speed of networks. There are now more users than ever, and a more efficient form of data transfer is needed. The absolute minimum number of packets required in a transaction is two: one request followed by one response. UDP is the one protocol in the TCP/IP protocol stack that allows this, but the problem is the unreliability of the transmission. T/TCP has the reliability of TCP and comes very close to realizing the 2-packet exchange (three in fact). T/TCP uses the TCP state model for its timing and retransmission of data, but introduces a new mechanism to allow the reduction in packets. Even though three packets are sent using T/TCP, the data is carried on the first two, thus allowing the applications to see the data with the same speed as UDP. The third packet is the acknowledgment to the server by the client that it has received the data, which is how the TCP reliability is incorporated. Basic Operation Consider a DNS system, one where a client sends a request to a server and expects a small amount of data in return. A diagram of the transaction can be seen in Figure 1. This diagram is very similar to a UDP request with a saving of 66% in packets transferred compared to TCP. Obviously, in cases where a large amount of data is being transferred, there will be more packets transmitted and thus a decrease in the percentage saved.

14

TCP Accelerated Open TCP Accelerated Open (TAO) is a mechanism introduced by T/TCP designed to cut down on the number of packets needed to establish a connection with a host. There are a number of new options that T/TCP introduces. These options allow the establishment of a connection with a host using the TAO. T/TCP uses a 32-bit incarnation number, called a connection count (CC). This option is carried in the options part of a T/TCP segment (see Figure 2). A distinct CC value is assigned to each direction of an open connection. Incremental CC values are assigned to each connection that a host establishes, either actively or passively. The three-way handshake is bypassed using the CC value. Each server host caches the last valid CC value it received from each different client host. This CC value is sent with the initial SYN segment to the server. If the initial CC value for a particular client host is larger than the corresponding cached value, the property of the CC options (the increasing numbers) ensures that the SYN segment is new and can be accepted immediately. The TAO test fails if the CC option arriving in the SYN segment is smaller than the last CC value received that was cached by the host, or if a CCnew option is sent. The server then initiates a three-way handshake in the normal TCP/IP fashion. Examples T/TCP can be beneficial to some of the applications that currently use TCP or UDP. At the moment, many applications are transaction-based rather than connection-based, but still have to rely on TCP, along with the overhead. UDP is the other alternative, but not having time-outs and retransmissions built into the protocol means the application programmers have to supply the time-outs and reliability 15

checking themselves. Since T/TCP is transaction-based, there is no set-up and shutdown time, so the data can be passed to the process with minimal delay.

16