IPv6 Intelligence

IPv6, the Protocol

The following sections describe in detail the selected and tested parts of the IPv6 protocol, how the results of testing and documentation review were used and which information sources were utilized.

Obsoleted RFCs are printed in italics.

Content of this page is from: 2006/2007, updated April 2009.

Functional areas

Not all parts of the IPv6 specification are reviewed on the selected operating systems and software packages. For this purpose, the various subprotocols are grouped into functional areas, which describe defined sets of IPv6 functionality.

For a discussion of these standards documents, read the IETF documents section on this page.

The selection process for these functional areas itself is partially based on a standards document, from which basic functions and requirements were deduced:

Basic functions

The Basic functions contain a set of IPv6 functionality for performing stateless autoconfiguration on Ethernet and communicating with the public Internet. This included the following standards:

Addresses

The various IPv6 addressing schemes are specified in the IPv6 address architecture, revised multiple times (only the current is listed):

Additionally, operating systems should support the generation and use of privacy addresses with random interface-identifiers as stated in

If the system includes a packet filter (i.e. firewall), an attempt is made to review its IPv6 filtering capabilities.

up

6to4

Automatic tunneling of IPv6 over IPv4 in 6to4 as defined in: RFC 3056: Connection of IPv6 Domains via IPv4 Clouds (B. Carpenter and K. Moore: February 2001). 6to4 clients need to have a public IPv4 address.

Clients are integrated into most operating systems and require not much setup. Necessary data includes the router anycast address(es) and the client’s own 6to4 prefix.

Configured Tunnels

Manual tunnelling over so-called configured tunnels. A special tunnel server (sometimes called tunnel broker) contains configuration for every tunnel client that wants to establish an IPv4 connection and encapsulate its IPv6 traffic in this tunnel. Clients who want to use configured tunnels need to have a public IPv4 address.

Most operating systems include the necessary software and require only mild configuration steps.

DHCPv6

The stateful autoconfiguration mechanism for IPv6 — DHCP for IPv6 (DHCPv6). Two modes of operation are available: stateful and stateless, the latter being the more simple variant. DHCPv6 is specified in the base documents for

The various DHCPv6 options — such as DNS and domain information etc. — are specified in various RFCs and drafts not listed here separately.

PPPv6

Transmission of IPv6 over Point-to Point (PPP) links — PPPv6 as specified in:

Support for PPPv6 was mostly more or less covertly added to several popular PPP packages and software.

Areas not reviewed (yet)

In descending order of current relevance for future research and probability of inclusion.

Mobile IP
A research effort is currently complicated by the fact that Mobile IP in general is still under development. Most software packages which support Mobile IP are themselves also under development and it is not clear which RFCs and/or drafts will be relevant in the future. The available software and their inclusion will be watched closely.
IPsec
While the IPv6 node requirements state that every IPv6 node must support IPsec, IPv6 works without the IPsec protocol(s). And, similar to Mobile IP, IPsec woudl require very complex testing scenarios, making a distinct review difficult.
Translation (NAT-PT and SIIT et al)
The translation mechanisms — in principle dedicated proxy servers translating individual requests for each connection — are unlikely to have a greater impact in the future (if at all) due to their high complexity.
Media types
Different media and connection types can be used with IPv6. However, several of the older media types will not be discussed due to their limited relevance (i. e. ARCnet, ATM, FDDI); similar considerations apply to the newer ones as e.g. Firewire or InfiniBand. Interesting would be a review of IPv6 support for the newer wireless IEEE networking protocols.
Backbone and routing
As the current focus of this site lies on enduser systems, backbone and routing specifics are not relevant and discussed. This could change to a limited degree when enduser routers (CPEs) with IPv6 support are reviewed.

up

Methodical access & sources

The content of this site is principally based on three sources of information:

  1. Selected IPv6 functions were tested in several of the listed operating systems and software packages. This means that after the general selection process of the IPv6 features these aspects were practically tested on a live testing system under research conditions. The results were cross-checked and afterward taken into (the thesis and) this site as tested information.
  2. The IPv6 content and specifics are taken (as primary sources) directly from the relevant standardization organisation — the IETF. The used documents include standard-quality RFCs and pre-standard or work-in progress IDs.
  3. Several software and systems pages contain information not based on practical testing but on (literature and internet) research. This content is based on (mostly official) vendor documentation and in very few cases on secondary sources.

IETF documents

The aspects and details on IPv6 and its subprotocols are mainly deduced from the official standards documents from the Internet Engineering Task Force (IETF) — mainly the Requests for Comments (RFCs) and, to a lesser extent, the work-in progress Internet Drafts (IDs).

The standards documents serve as primary sources for the IPv6 specification content on this site. The sections on IPv6 specifics and aspects reference the relevant IETF documents, if applicable.

The relevant IPv6 documents are mainly developed and maintained by the IETF IPv6 Operations (v6ops) working group (WG) and IPv6 Maintenance (6man) working group (WG) of the IETF. Some of the relevant documents are developed in other working groups (WGs), however.

Vendor documents

We basically trust what the vendors say on the supported features of their products. Items are taken over keeping with the vendors’ wording and description. If the vendor references an RFC it is assumed the complete content of the RFC is supported; qualifications are taken over if available. If the vendor does not supply an RFC an educated guess is made.

As most vendors do not give exact features for each single version and revision of their software, the following algorithm is used when non-conclusive documentation is available for releases N and N+1:

Documentation on N states that N supports A, B and C.
Documentation on N+1 states that N+1 supports D and E.
→ We assume N+1 supports A, B, C, D and E.

up