Handbook of Local Area Networks, 1998 Edition:Advanced LAN Interconnectivity Issues and Solutions
Click Here!
Search the site:
ITLibrary
ITKnowledge
EXPERT SEARCH
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games
EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info
Previous
Table of Contents
Next
IPV6 EXTENSION HEADERS AND OPTIONS
In IPv6, optional IP layer information is encoded in separate extension headers that are placed between the IPv6 basic header and the higher-layer protocol header. An IPv6 packet may carry zero, one, or more such extension headers, each identified by the next header field of the preceding header and each containing an even multiple of 64 bits (see Exhibit 4-1-4). A fully compliant implementation of IPv6 includes support for the following extension headers and corresponding options:
Exhibit 4-1-4. IPv6 Extension Header Examples
The hop-by-hop options header. This header carries information that must be examined by every node along a packets path. Three options are included in this category. The pad1 option is used to insert a single octet of padding into the options area of a header for 64-bit alignment, whereas the padN option is used to insert two or more octets of padding. The jumbo payload option is used to indicate the length of the packet when the payload portion is longer than 65,535 octets. This option is employed when the payload length field is set to zero.
The routing header. This header is used by an IPv6 source to list one or more intermediate nodes that must be visited as part of the packets path to the destination; this option is functionally similar to IPv4s loose and strict source route options. This header contains a list of addresses and an indication of whether each address is strict or loose. If an address is marked strict, it means that this node must be a neighbor of the previously addressed node; if an address is marked loose, this node does not have to be a neighbor of the previous node.
The fragment header. This header is used by an IPv6 source to send packets that are larger than the maximum transmission unit (MTU) on the path to the destination. This header contains a packet identifier, fragment offset, and final fragment indicator. Unlike IPv4, where fragmentation information is carried in every packet header, IPv6 only carries fragmentation/reassembly information in those packets that are fragmented. In another departure from IPv4, fragmentation in IPv6 is performed only by the source and not by the routers along a packets path. All IPv6 hosts and routers must support an MTU of 576 octets; it is recommended that path MTU discovery procedures (per RFC 1981) be invoked to discover, and take advantage of, those paths with a larger MTU.
The destination options header. This header carries optional information that has to be examined only by a packets destination node(s). The only destination options defined so far are pad1 and padN, as described above.
The IP authentication header (AH) and IP encapsulating security payload (ESP). These are IPv6 security mechanisms (a section on IPv6 security appears later in this chapter).
With the exception of the hop-by-hop option, extension headers are only examined or processed by the intended destination nodes. The contents of each extension header determine whether or not to proceed to the next header and, therefore, extension headers must be processed in the order that they appear in the packet.
IPV6 QUALITY-OF-SERVICE (QOS) PARAMETERS
The priority and flow label fields in the IPv6 header are used by a source to identify packets needing special handling by network routers. The concept of a flow in IP is a major departure from IPv4 and most other connectionless protocols; flows are sometimes referred to as a form of connection-less virtual circuit because all packets with the same flow label are treated similarly and the network views them as associated entities.
Special handling for nondefault quality of service is an important capability for supporting applications that require guaranteed throughput, end-to-end delay, and jitter, such as multimedia or real-time communication. These QOS parameters are an extension of IPv4s type-of-service (TOS) capability.
The priority field allows the source to identify the desired priority of a packet. Values 0 through 7 are used for congestion-controlled traffic, or traffic that backs off in response to network congestion, such as TCP segments. For this type of traffic, the following priority values are recommended:
Zero is recommended for uncharacterized traffic.
One is recommended for filler traffic (e.g., Netnews).
Two is recommended for unattended data transfer (e.g., E-mail).
Three is recommended for reserved traffic.
Four is recommended for attended bulk transfer, such as FTP or hypertext transfer protocol (HTTP).
Five is also recommended for reserved traffic.
Six is recommended for interactive traffic (i.e., telnet).
Seven is recommended for Internet control traffic (i.e., routing protocols and simple network management protocol).
Values 8 through 15 are defined for noncongestion-controlled traffic, or traffic that does not back off in response to network congestion, such as real-time packets being sent at a constant rate. For this type of traffic, the lowest priority value (8) should be used for packets that the sender is most willing to have discarded under congestion conditions (e.g., high-fidelity video traffic) and the highest value (15) should be used for those packets that the sender is least willing to have discarded (e.g., low-fidelity audio traffic).
The flow label is used by a source to identify packets needing nondefault QOS. The nature of the special handling might be conveyed to the network routers by a control protocol, such as the resource reservation protocol (RSVP), or by information within the flow packets themselves, such as a hop-by-hop option. There may be multiple active flows from a source to a destination, as well as traffic that is not associated with any flow (i.e., flow label = 0). A flow is uniquely identified by the combination of a source address and a nonzero flow label. This aspect of IPv6 is still in the experimental stage and future definition is expected.
IPV6 SECURITY
In the early days of TCP/IP, the ARPANET user community was small and close, and security mechanisms were not the primary concern. As the number of TCP/IP hosts grew, and the user community became one of strangers (some nefarious) rather than friends, security became more important. As critical and sensitive data travels on todays Internet, security is of paramount concern.
Although many of todays TCP/IP applications have their own devices, security should be implemented at the lowest possible protocol layer. IPv4 has few, if any, security mechanisms, and authentication and privacy at lower protocol layers is largely absent. IPv6 builds two security schemes into the basic protocol.
Previous
Table of Contents
Next
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited.
Please read our privacy policy for details.
Wyszukiwarka
Podobne podstrony:
381 685378,6,artykulBY Barejsza J , Ab atrybucyi i datawanni dzwiuch maniet Aleksinskaha skarbu, Bankauski wiesnik, nr [381 385 bkxxfouzvuxv2ywm5ifjqi5m2dmkizz5w7ktqni381,8,artykul374 378376 381 axc5jlpeya5e5e26gci7bke4decmlk4qn57mrkyindex (381)01 (378)378 379więcej podobnych podstron