Internet Protocol version 6: Difference between revisions
imported>Howard C. Berkowitz (Lots of open issues. See talk page for related articles) |
imported>Howard C. Berkowitz (more stubs and issues) |
||
Line 66: | Line 66: | ||
Traffic class and flow label are largely new capabilities, which are discussed below. | Traffic class and flow label are largely new capabilities, which are discussed below. | ||
==IPv6 | ==IPv6 addresses== | ||
===Notation=== | |||
IPv6 principally uses [[hexadecimal]] notation, rather than the [[dotted decimal]] of IPv4. It uses the same prefix length notation as IPv4, so a /56 would mean that the high-order 56 bits need to be examined for routing decisions. | |||
=== | |||
IPv6 uses | |||
<pre> | <pre> | ||
# A sample (unicast) address: | # A sample (unicast) address: | ||
Line 105: | Line 88: | ||
(This IS about making your life easier!) | (This IS about making your life easier!) | ||
</pre> | </pre> | ||
===Scope=== | |||
See [[locality of networks]] | |||
===Types of address=== | |||
IPv6 uses some familiar address types - Unicast, Multicast and Anycast. | |||
# [[Unicast]]: traditional one-to-one communication analogy, in which a standard phone call exists between two (unicast) telephone numbers | |||
# [[Multicast]] - one-to-many communication (used for efficient delivery of content) analogy - teacher in a class says something one time, everyone who is interested receives it | |||
# [[Anycast]] - one-to-one-of-many communication, where the one-of-many is the nearest instance analogy - a bit more complicated than unicast or multicast. | |||
Note that IPv6 does not support "broadcast" addresses. Broadcast was really a special case of multicasting; the broadcast group was the group to which every host belonged. Think of broadcast is the kind of private club that Groucho Marx had in mind when he said "I wouldn't belong to any club that would have me as a member. | |||
Everything IPv4 accomplished with broadcast, IPv6 has a form of multicast for. This includes a very much broadcast-like multicast, the "All Nodes" multicast address, <code.FF02::1</code> | |||
===Addressing architecture=== | |||
RFC 4291 defines the IPv6 addressing architecture, which specifies well-known types of addresses. <ref name=RFC4921>{{citation | |||
| id = RFC4291 | |||
| title = IP Version 6 Addressing Architecture. | |||
| authors =R. Hinden, S. Deering. | |||
| date = February 2006 | |||
| url = http://www.ietf.org/rfc/rfc4291.txt}}</ref> | |||
{| class="wikitable" | {| class="wikitable" | ||
'''Special IPv6 unicast addresses / ranges / address formats''' | '''Special IPv6 unicast addresses / ranges / address formats''' | ||
Line 192: | Line 194: | ||
| used for [[Neighbor Discovery]] | | used for [[Neighbor Discovery]] | ||
|} | |} | ||
===Addresses that must be recognized=== | |||
====All hosts==== | |||
All hosts, be they end systems or router interfaces, must recognize the following addresses as identifying themselves: | |||
*Its required Link-Local address for each interface. | |||
*Any additional Unicast and Anycast addresses that have been configured for the node's interfaces (manually or automatically). | |||
*The loopback address. | |||
*The All-Nodes multicast addresses defined in Section 2.7.1. | |||
*The Solicited-Node multicast address for each of its unicast and anycast addresses. | |||
*Multicast addresses of all other groups to which the node belongs. | |||
====Routers==== | |||
A router is required to recognize all addresses that a host is required to recognize, plus the following addresses as identifying itself: | |||
*The Subnet-Router Anycast addresses for all interfaces for which it is configured to act as a router. | |||
*All other Anycast addresses with which the router has been configured. | |||
*The All-Routers multicast addresses | |||
==Hierarchical addressing== | ==Hierarchical addressing== | ||
While IPv6 creates more addresses, in its basic form, it does nothing to help the workload on routers that need to carry an appreciable amount of the global Internet routing table, or the full [[default-free zone]]. Just as CIDR was needed with IPv4, aggregation techniques are needed with IPv6.<ref name=RFC2450>{{citation | ===IANA and address registries=== | ||
===Aggregation=== | |||
While IPv6 creates more addresses, in its basic form, it does nothing to help the workload on routers that need to carry an appreciable amount of the global Internet routing table, or the full [[default-free zone]]. Just as CIDR was needed with IPv4, aggregation techniques are needed with IPv6.<ref name=RFC3587>{{citation | |||
| id = RFC3587 | |||
| title = IPv6 Global Unicast Address Format | |||
| author = R. Hinden, S. Deering, E. Nordmark | |||
| date = August 2003 | |||
| url = http://www.ietf.org/rfc/rfc3587.txt}}</ref> | |||
If a relatively small number of short top-level, highly aggregated prefixes can be the only things which which major interprovider routers need be concerned, there is a potential benefit for global routing salability. <ref name=RFC2450>{{citation | |||
| id = RFC2450 | | id = RFC2450 | ||
| title = Proposed TLA and NLA Assignment Rule | | title = Proposed TLA and NLA Assignment Rule | ||
Line 200: | Line 227: | ||
| url = http://www.ietf.org/rfc/rfc2450.txt}}</ref> | | url = http://www.ietf.org/rfc/rfc2450.txt}}</ref> | ||
==Acquiring addresses== | ==Acquiring addresses== | ||
''these might be separate articles'' | ''these might be separate articles'' | ||
===Stateless autoconfiguration=== | ===Stateless autoconfiguration=== | ||
===Stateful autoconfiguration with DHCPv6=== | ===Stateful autoconfiguration with DHCPv6=== | ||
===Neighbor and router discovery=== | |||
===Registering the autoconfigured address with dynamic DNS=== | ===Registering the autoconfigured address with dynamic DNS=== | ||
===Router renumbering protocol=== | |||
==Controversies== | ==Controversies== |
Revision as of 14:46, 25 August 2008
Template:TOC-right Internet Protocol version 6 (or as it is more commonly known "IPv6") is a method of addressing hosts or nodes on a computer network, using 128 bit addresses. IPv6 was conceived as a "next generation" upgrade from the older Internet addressing scheme IPv4, which relied on a 32-bit address space and is quickly being exhausted by the continued growth of the Internet. The public address space of the Internet is becoming exhausted. [1]
A quick note or two on the design intent(s) of IPv6, aspects that are recurring ideas that will be seen throughout the underlying protocol operation, and aren't bad things to keep in mind when trying to understand what IPv6 does, how it accomplished those things and why those things are done.
- More addresses - obviously IPv6 gives us more addresses, 128bits vs 32bits.
- Flexibility - The ability to readily add "stuff" (capabilities, functions, etc.) to the protocol without needing to rewrite the base protocol or necessarily re-architect our environments.
- Scalability - Reduce overhead, distribute workload, smoother/easier processing.
One common topic of conversation is:
- Should IPv6 be viewed as an evolutionary next-stop from IPv4?
or
- Should IPv6 be viewed as a disruptive technology, a revolutionary change?
The answer is: It Depends.
In many regards IPv6 is, in fact, just a few tweaks different. This is the "96 More Bits, No Magic" view. From a purely technological perspective, this is (largely) true.
However, moving forward, the more bits may just enable radical changes. Changes in how we use our networks, what we expect (require) them to do, etc. From this "bigger picture" view we could be on the precipice of major change. (I did say "could" ... ) As the old saying goes, "May you live in interesting times".
IPv6 packet format
IPv6 is not only a matter of addressing. The packet is structured quite differently than an IPv4 packet; only the first four bits, designating the IP version number, have the same function.[2]
Some of the goals of IPv6 included:
- Efficient hardware processing of packet headers: Some IPv4 header fields have been dropped or made optional (e.g., fragmenttion), to reduce the processing cost for the most common packets, and to reduce the bandwidth cost of the IPv6 header.
- Improved Support for Extensions and Options: The encoding of headers is more efficient for hardware processing and more flexible in adding new options
- Flow Labeling Capability: the ability to label a packet as belonging to a flow or forwarding equivalent class, such as non-default quality of service or "real-time" service.
- Authentication and Privacy Capabilities: built in authentication, data integrity, and optional content confidentiality are part of the base standard.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are fewer fields than in the IPv4 header. Some of the fields that are not part of the header either were not often used, were obsolete, or inefficiently implemented.
The Next Header field, for example, serves the function of the protocol identifier field and even uses the same values, in RFC1700 and later online IANA lists. In addition, however, this field more efficiently implements the Options mechanism from IPv4.
Hop limit is essentially the Time To Live field of IPv4.
Traffic class and flow label are largely new capabilities, which are discussed below.
IPv6 addresses
Notation
IPv6 principally uses hexadecimal notation, rather than the dotted decimal of IPv4. It uses the same prefix length notation as IPv4, so a /56 would mean that the high-order 56 bits need to be examined for routing decisions.
# A sample (unicast) address: 2001:0db8:0001:1001:0000:0000:0000:0001 -- Note the use of Hexadecimal (hex; each character == 4 bits) ---- 4 character (16 bits) per "chunk", 8 chunks, colon separated We can compress this to make our lives easier: -- "Drop leading zeroes" (within each chunk) ---- 2001:db8:1:1001:0:0:0:1 -- "Double-colon" (Replace any number of SEQUENTIAL, ALL ZERO chunks ... one time per address) ---- 2001:db8:1:1001::1 (This double-colon technique is also frequently used when representing a Prefix. For example the above address is taken from the 2001:db8::/32 space - the 2001:0db8 piece (the first 32 bits) is fixed ... the rest (all zeroes) is subject to change) ) Note that something like this is valid as well: 2001:0db8:0000:0000:0000:0000:0000:0001 --> 2001:db8::1 (This IS about making your life easier!)
Scope
Types of address
IPv6 uses some familiar address types - Unicast, Multicast and Anycast.
- Unicast: traditional one-to-one communication analogy, in which a standard phone call exists between two (unicast) telephone numbers
- Multicast - one-to-many communication (used for efficient delivery of content) analogy - teacher in a class says something one time, everyone who is interested receives it
- Anycast - one-to-one-of-many communication, where the one-of-many is the nearest instance analogy - a bit more complicated than unicast or multicast.
Note that IPv6 does not support "broadcast" addresses. Broadcast was really a special case of multicasting; the broadcast group was the group to which every host belonged. Think of broadcast is the kind of private club that Groucho Marx had in mind when he said "I wouldn't belong to any club that would have me as a member.
Everything IPv4 accomplished with broadcast, IPv6 has a form of multicast for. This includes a very much broadcast-like multicast, the "All Nodes" multicast address, <code.FF02::1
Addressing architecture
RFC 4291 defines the IPv6 addressing architecture, which specifies well-known types of addresses. [3]
Special IPv6 unicast addresses / ranges / address formatsRepresentative address | Function | Comments | IPv4 equivalent |
---|---|---|---|
:: | Unspecified_Address | 0.0.0.0 | |
::1 | Loopback localhost ipv6-localhost ipv6-loopback | 127.0.0.1 | |
::<v4 address> | IPv4-Compatible Addresses | Deprecated | <v4 address> |
::ffff:<v4 address> | IPv4-Mapped Addresses | <v4 address> with a particular Route Distinguisher | |
2000::/3 | (Currently active) Global Unicast Addresses | 198.0.2.1 | |
2001:0000::/32 | Teredo service prefix | ||
2002::/16 | 6to4 service prefix | ||
fc00::/7 | Teredo service prefix | Unique-Local Addresses | |
2001:0000::/32 | Teredo service prefix | ||
fe80::/10 | Link-Local Unicast | prefix with all ones host field or packet with TTL=1 | |
fec0::/10 | Site-Local Unicast (DEPRECATED) | RFC 1918 private address space |
Address | Function | Comments |
---|---|---|
ff00::/8 | ipv6-mcastprefix | Analogous to the "Class E" multicast address space |
ff02::1 | ipv6-allnodes | Much like the 255.255.255.255 broadcast |
ff02::2 | ipv6-allrouters | |
ff02::1:ffXX:XXXX | Solicited-Node-Multicast | used for Neighbor Discovery |
Addresses that must be recognized
All hosts
All hosts, be they end systems or router interfaces, must recognize the following addresses as identifying themselves:
- Its required Link-Local address for each interface.
- Any additional Unicast and Anycast addresses that have been configured for the node's interfaces (manually or automatically).
- The loopback address.
- The All-Nodes multicast addresses defined in Section 2.7.1.
- The Solicited-Node multicast address for each of its unicast and anycast addresses.
- Multicast addresses of all other groups to which the node belongs.
Routers
A router is required to recognize all addresses that a host is required to recognize, plus the following addresses as identifying itself:
- The Subnet-Router Anycast addresses for all interfaces for which it is configured to act as a router.
- All other Anycast addresses with which the router has been configured.
- The All-Routers multicast addresses
Hierarchical addressing
IANA and address registries
Aggregation
While IPv6 creates more addresses, in its basic form, it does nothing to help the workload on routers that need to carry an appreciable amount of the global Internet routing table, or the full default-free zone. Just as CIDR was needed with IPv4, aggregation techniques are needed with IPv6.[4]
If a relatively small number of short top-level, highly aggregated prefixes can be the only things which which major interprovider routers need be concerned, there is a potential benefit for global routing salability. [5]
Acquiring addresses
these might be separate articles
Stateless autoconfiguration
Stateful autoconfiguration with DHCPv6
Neighbor and router discovery
Registering the autoconfigured address with dynamic DNS
Router renumbering protocol
Controversies
Coexistence strategies
Equivalents to RFC 1918 private address space
Multihoming
References
- ↑ Huston, Geoff, IPv4 Address Report
- ↑ Deering, S. and R. Hinden (December 1998), Internet Protocol, Version 6 (IPv6) Specification, RFC2460
- ↑ R. Hinden, S. Deering. (February 2006), IP Version 6 Addressing Architecture., RFC4291
- ↑ R. Hinden, S. Deering, E. Nordmark (August 2003), IPv6 Global Unicast Address Format, RFC3587
- ↑ R. Hinden (December 1998), Proposed TLA and NLA Assignment Rule, RFC2450