as jitchy says, the header length is no longer required because the ipv6 header is always 40 bytes long... there is comfort in that...
according to rfc2460:
Version 4-bit Internet Protocol version number = 6. Traffic Class 8-bit traffic class field. See section 7. Flow Label 20-bit flow label. See section 6. 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 [section 4] 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 [RFC-1700 et seq.]. 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.
the header checksum is gone and source and destination are painfully obvious, excepting being 4X as long... (32 v 128)
read this http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-3/ipv6_internals.html
or the last post for jitchy's v4/v6 comparison...
by virtue of less fields, no checksum, always 40 bytes, it is streamlined...
IPv6 no longer has a header checksum to protect the IP header, meaning that when a packet header is corrupted by transmission errors, the packet is very likely to be delivered incorrectly. However, higher-layer protocols should be able to detect these problems, so they are not fatal. Also, lower layers almost always employ a Cyclic Redundancy Check (CRC) to detect errors.
No comments:
Post a Comment