IPv6在校园网中的应用-IP安全分析 第3页
2.2 IPv6
2.2.1 The defect of IPv4
The current version of IP (known as Version 4 or IPv4) has not been substantially changed since RFC 791 was published in 1981.IPv4 has proven to be robust, easily implemented and interoperable, and has stood the test of scaling an internetwork to a global utility the size of today’s Internet. This is a tribute to its initial design.
However, the initial design did not anticipate the following
The recent exponential growth of the Internet and the impending exhaustion of the IPv4 address space.
IPv4 addresses have become relatively scarce, forcing some organizations to use a Network Address Translator (NAT) to map multiple private addresses to a single public IP address. While NATs promote reuse of the private address space, they do not support standards-based network layer security or the correct mapping of all higher layer protocols and can create problems when connecting two organizations that use the private address space.
Additionally, the rising prominence of Internet-connected devices and appliances ensures that the public IPv4 address space will eventually be depleted
The growth of the Internet and the ability of Internet backbone routers to maintain large routing tables.
Because of the way that IPv4 address prefixes have been and are currently allocated, there are routinely over 85,000 routes in the routing tables of Internet backbone routers. The current IPv4 Internet routing infrastructure is a combination of both flat and hierarchical routing
The need for simpler configuration.
Most current IPv4 implementations must be either manually configured or use a stateful address configuration protocol such as Dynamic Host Configuration Protocol (DHCP). With more computers and devices using IP, there is a need for a simpler and more automatic configuration of addresses and other configuration settings that do not rely on the administration of a DHCP infrastructure
The requirement for security at the IP level
Private communication over a public medium like the Internet requires encryption services that protect the data being sent from being viewed or modified in transit. Although a standard now exists for providing security for IPv4 packets (known as Internet Protocol security or IPsec), this standard is optional and proprietary solutions are prevalent
The need for better support for real-time delivery of data—also called quality of service (QoS)
While standards for QoS exist for IPv4, real-time traffic support relies on the IPv4 Type of Service (TOS) field and the identification of the payload, typically using a UDP or TCP port. Unfortunately, the IPv4 TOS field has limited functionality and over time there were various local interpretations. In addition, payload identification using a TCP and UDP port is not possible when the IPv4 packet payload is encrypted
To address these and other concerns, the Internet Engineering Task Force (IETF) has developed a suite of protocols and standards known as IP version 6 (IPv6). This new version, previously called IP-The Next Generation (IPng), incorporates the concepts of many proposed methods for updating the IPv4 protocol. The design of IPv6 is intentionally targeted for minimal impact on upper and lower layer protocols by avoiding the random addition of new features.
2.2.2 The advantage of IPv6
A. Expanded Addressing Capabilities
IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy, a much greater number of addressable nodes, and simpler auto-configuration of addresses. The scalability of multicast routing is improved by adding a "scope" field to multicast addresses. And a new type of address called an "anycast address" is defined, used to send a packet to any one of a group of nodes
B. Header Format Simplification
Some IPv4 header fields have been dropped or made optional, to reduce the common-case processing cost of packet handling and to limit the bandwidth cost of the IPv6 header
C. Improved Support for Extensions and 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.
D. Flow Labeling Capability
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 non-default quality of service or "real-time" service.
E. Authentication and Privacy Capabilities
Extensions to support authentication, data integrity, and (optional) data confidentiality are specified for IPv6
2.2.3 IPv6 header format
图表 2 2: IPv6 header format
Version: 4-bit Internet Protocol version number = 6.
Traffic Class: 8-bit traffic class field The 8-bit Traffic Class field in the IPv6 header is available for use by originating nodes and/or forwarding routers to identify and distinguish between different classes or priorities of IPv6 packets. At the point in time at which this specification is being written, there are a number of experiments underway in the use of the IPv4 Type of Service and/or Precedence bits to provide various forms of "differentiated service" for IP packets, other than through the use of explicit flow set-up. The Traffic Class field in the IPv6 header is intended to allow similar functionality to be supported in IPv6.
Flow Label: 20-bit flow label. The 20-bit Flow Label field in the IPv6 header may be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time" service. This aspect of IPv6 is, at the time of writing, still experimental and subject to change as the requirements for flow support in the Internet become clearer. 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
Payload Length: 16-bit unsigned integer. Length of the IPv6 payload, i.e., the rest of the packet following this IPv6 header, in octets.
(Note that any extension headers present are considered part of the payload, i.e., included in the length count.)
Next Header: 8-bit selector. Identifies the type of header immediately following the IPv6 header. Uses the same values as the IPv4 Protocol field
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.
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).
2.2.4 IPv6 Extension Headers
The IPv4 header includes all options. Therefore, each intermediate router must check for their existence and process them when present. This can cause performance degradation in the forwarding of IPv4 packets. With IPv6, delivery and forwarding options are moved to extension headers. The only extension header that must be processed at each intermediate router is the Hop-by-Hop Options extension header. This increases IPv6 header processing speed and improves forwarding process performance.
RFC 2460 defines the following IPv6 extension headers that must be supported by all IPv6 nodes:
• Hop-by-Hop Options header
• Destination Options header
• Routing header
• Fragment header
• Authentication header
• Encapsulating Security Payload header
In a typical IPv6 packet, no extension headers are present. If special handling is required by either the intermediate routers or the destination, one or more extension headers are added by the sending host.
Each extension header must fall on a 64-bit (8-byte) boundary. Extension headers of variable size contain a Header Extension Length field and must use padding as needed to ensure that their size is a multiple of 8 bytes
Figure1-3 shows the Next Header field in the IPv6 header and zero or more extension headers that form a chain of pointers. Each pointer indicates the type of header that comes after the immediate header until the upper layer protocol is ultimately identified.
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>