Tech Stuff - Ipv6

Version 6 of the IP Protocol. Defined in RFC 2460 (and updated by RFC5095 and RFC5722). Everything about IPv6 is BIG. An IPv4 address is 32 bits, an IPv6 address is 128 bits. This is about the number where each blade of grass on the planet could have its own IPv6 address.

IPv6 has been around since at least 1995 but the CIDR initiative of the mid-nineties pushed back any, then pressing, need for IPv6's increased address range. The can was effectively kicked down the road. In retrospect this was probably a Good Thing ™ since much of the recent (2010/2015) IPv6 work has been to reduce IPv6 address complexity, interworking and overall functionality.

IPv6 is big and complex in comparison with IPv4. This fact alone will keep users from implementation if they have any choice in the matter. Nevertheless, the internet is rapidly approaching the time - primarily due to IPv4 address depletion - when there is little choice but to move to IPv6. The transition will be accompanied by much yelling, screaming, gnashing of teeth and grim resignation. It is not helped by the constant roll-back and fiddling with the IPv6 specifications.

8 of the 13 DNS root-servers are advertising both IPv4 and IPv6 access (abfhjklm - as of 2010).

Increasing demand for end user address transparency, for example, VoIP.

Widespread availability of IPv6 protocol stacks for almost all major OS platforms.

Increasingly dire warnings (2010) from the major Regional Internet Registries (RIRs), responsible for Internet address allocation, about depletion of IPv4.

The IPv4 vs IPv6 debate is also about the bigger issue of end user transparency vs NAT. Between those who see NAT as being inherently evil - since it hides end user addresses thus removing address transparency (using a variety of simple to gruesome techniques) - and those who see NAT as being a life saving technology that may indefinitely postpone the need for IPv6.

To be truly useful IPv6 must also finally remove the need for end users to know anything about their IP address as a matter of routine - simply because it will be impossible for any sane human being to remember one of these gruesome strings of digits. Imagine asking your Father to read his IPv6 address over the phone. Got the picture. DNS and DHCPv6 can work seemlessly to make the IP address disappear at the user level and auto-configuration (stateless or SLAAC configuration) can simplify address allocation. For IPv6 to work we must treat any need for a visible IP address as a system failure.

IPv6 may have been, to use an unattributed quote, "too much, too early" and certainly the latest RFCs try and back-pedal from some of the earlier specification constraints and functionality (frequently making them even more complex to read if that is possible). Nevertheless, there are a significant number of implementations, proving IPv6 is a production ready technology. Much of the new IPv6 work appearing in the RFCs is, apart from routine maintenance, concerned with the impact of IPv6 in the tightly constrained mobile world.

It is noted that RFC 6540 (published April 2012) now formally suggests that best practice protocol stacks should now include both IPv6 and IPv4. While IPv6 and IPv4 have been available, for many years, with mainstream OSs (Linux, BSD, Windows and others) and, due to its application in the mobile world, Android and other mobile centric OSs, most network boxes (DSL/cable modems) are still IPv4 only. High quality Open Source IPv6 stacks and this nudging from the IETF may change this. Then again, perhaps holding one's breath may not be a sensible strategy just yet since it will be many years before all that IPv4 NAT investment used by most ISPs will obsolete IPv4 functionality.

IPv6 Overview

First things first. Each PC - more properly each network interface - may have more than one IPv6 address - IPv6 is naturally multi-homed. Second, an IPv6 address has a scope, that is, it can be restricted to a single LAN or a private network or be globally unique. The following table defines the types of IPv6 addresses that can be supported and contrasts them with their closest IPv4 functional equivalent.

IPv6 Name

Scope/Description

IPv4 Equivalent

Notes

Link-Local

Local LAN only. Automatically assigned based on MAC. Cannot be routed outside local LAN.

No real equivalent. Assigned IPv4 over ARP'd MAC.

Scoped address concept new to IPv6. Multicast may also be scoped to link-local (RFC 4489). Format.

Site-Local

Optional. Local Site only. Cannot be routed over Internet. Assigned by user.

Scoped address concept new to IPv6. Unlike the IPv4 private network address the IPv6 device can have, and most likely will have, Link-Local, Site-Local and a Global Unicast address. Site-Local while continuing to exist in the IPv6 specification is the subject of on-going work in the IETF and is currently not supported. The address block used for this purpose has been marked Reserved by IANA.

Addresses are indistinguishable froma normal unicast address. Anycast (router-to-router) is also used with IPv4 addresses, specifically with DNS root servers, though there may be other instances.

Loopback

Local interface scope.

Same as IPv4 127.0.0.1

Same function

IPv6 Address Notation

An IPv6 address consists of 128 bits - an IPv4 address consists of 32 bits - and is written as a series of 8 hexadecimal strings separated by colons. (Format defined by RFC 4291 and updated by RFC 5952) Examples:

# all the following refer to the same address
2001:0000:0234:C1AB:0000:00A0:AABC:003F
# leading zeros can be omitted
2001:0:234:C1AB:0:A0:AABC:3F
# not case sensitive - any mixture allowed
2001:0:0234:C1ab:0:A0:aabc:3F

One or more zeros entries can be omitted entirely but only once in an address. The user can choose the most efficient place to omit multiple zero entries. Examples:

Multiple zeros can be omitted entirely but only once in an address. Examples:

# omitting multiple 0's in address
2001:0:0:0:0:0:0:3F
# can be written as
2001::3F
# lots of zeros (loopback address)
0:0:0:0:0:0:0:1
# can be written as
::1
# all zeros (unspecified a.k.a unassigned IP)
0:0:0:0:0:0:0:0
# can be written as
::
# but this address
2001:0:0:1:0:0:0:3F
# cannot be reduced to this
2001::1::3F # INVALID
# instead it can only be reduced to
2001::1:0:0:0:3F
# or
2001:0:0:1::3F

A hybrid format may be used when dealing with IPv6 - IPv4 addresses called an IPv4-Mapped IPv6 Address (RFC 4291 - updated by RFC 5952 and RFC 6052) where the normal IPv4 dotted decimal notation may be used after the first 6, 16 bit address elements:

The FFFF element in the 6th position is fixed and must be present (see also RFC 6052 for a peculiar shifted version of this format when used with certain IPv4/IPv6 translators).

To avoid publication of a global IPv4 the example above shows a private (non-globally unique) IPv4 address purely to illustrate the principle but the IPv4 address used in IPv4-Mapped IPv6 must always be globally unique address.

IPv6 Prefix or Slash Notation

IPv6 uses a similar / (forward slash) notation to IPv4 CIDR (Classless Interdomain Routing) which describes the number of contiguous bits used in its netmask. Formally this way of writing an address is called an IP prefix but more commonly called the slash format. Examples:

IPv6 Address Types

The type of IP address is defined by a variable number of the top bits known as the binary prefix (BP). Only as many bits as required are used to identify the address type as shown in the following table (defined in RFC 4291):

Local Site scope. Lower bits assigned by user. This binary prefix has been marked Reserved by IANA to reflect the currently unsupported state of Site-Local addressing.

Global Unicast

All other values

2::/3

A note in RFC 3513 recommended that IANA should continue to allocate only from the binary prefix 001 (as in RFC 2373 version) but RFC 3587 obsoletes this recommendation. Format.

The revised definition is a conceptual change and is both more flexible than the previous (RFC 2373/RFC 3513) definition if a tad confusing. IPv4 and NSAP prefixes are still allowed for but are now simply unicast addresses. Subsequent changes (from RFC 3513 to RFC 4291) seem to be trying to remove some of the restrictions previously imposed such that RFCs now use the distinction between a binary prefix of 000 (covering IPv6 mapped IPv4, unassigned and loopback) and not 000 (all other unicast) rather than explicity using 001 as previously. The obsolescence of address block assignment from the previous binary prefix 001 seems to be of a theoretical nature since all current IANA address block assigments are still from this prefix.

IPv6 Global Unicast Address Format

The IPv6 Global Unicast 128 bits was historically divided into a 48 bit global routing prefix (a.k.a site prefix) which is assigned by various authorities, a 16 bit subnet ID and 64 bits which the Interface ID (IID). The 16 bit subnet ID and IID (a total of 80 bits) is normally assigned and used by the user. While this structure is still the normal address allocation, the standards (RFC 4291) now define both the global routing prefix and the subnet ID to be of variable length (and using a total of 64 bits) in order to allow greater flexibility for the RIRs in allocating addresses. The formal structure is therefore:

Name

Size

Description/Notes

GRP

Variable

Global Routing Prefix. Variable format depending on the Binary Prefix, for instance, if 001 - Global Unicast Address (assigned by IANA) uses this format. See note about current standards structure above. Normally this part is 48 bits in length but - depending on RIR policies - can be as long as 56 bits.

subnet ID

Variable

Used for subnet routing. See notes about current standards structure above. Normally this part is 16 bits in length but - depending on RIR policies - can be as low as 8 bits or 0 is the user only requires a single subnet.

interface ID

64 bits

The unique interface identifier (host address equivalent in IPv4).

The current IPv6 address allocation policy adopted by the various Regional Internet Registries should be based on the IETF/IAB recomendation (in RFC 3177) which allows for:

Name

Allocation

Description/Notes

Normal User

/48

May cover home or business use. The user controls the full 80 bits addresses comprising the subnet ID (16 bits) and Interface ID (IID - 64 bits). Regional (RIRs) or Local Internet Registries (LIRs) seem to be able to allocate a /56 in which case the subnet is defined to be 8 bits and the IID remains, as normal, 64 bits. It is not clear under what circustances /56 addresses are allocated other than they provide another level of allocation flexibility for the RIRs/LIRs.

Single subnet

/64

Where it is known that only a single subnet can be used the user is assigned control of the interface ID part only

Single Device

/128

Where it is known that only one device can be used the user is assigned a single interface ID

IPv6 End-User Address Format

End-User addresses are assigned from the Global Unicast pool (current IANA IPv6 address block assignments). In addition a list of special assigments was created by RFC 4773. The IETF 6bone used a special range of 3FFe::/16 but the 6bone is disbanded and the address range has been returned to the IANA Reserved pool. The 128 bits breakdown as follows:

Prior to RFC 4291 this field was 45 bits in length and for the global unicast address defined a strict hierarchy of Aggregators using the terms, TLA (Top Level Aggregator), sub-TLA and NLA (Next Level Aggregator). RFC 4291 obsoleted this structure and essentially leaves any sub format to Regional Internet Registries (RIRs). In addition the subnet ID field (previously defined to be 16 bits in length) is also defined to of variable length thus many of the current IPv6 specifications confusingly refer to the whole of this address space plus the subnet ID simply as the subnet ID to this field. IPv6 Global unicast address block assigments are maintained by IANA. The size of the IANA IPv6 address block assigment varies from /12 to /23.

80 - 64 bits - typically assigned by the user

Name

Size

Description/Notes

subnet ID

16 bits

Used for subnet routing. See notes above. This field is formally (within RFC 4291) of variable length and while 16 bits is the normal allocation it can be - depending on the RIR policies - as low as 8 bits or 0 is the user only requires a single subnet.

interface ID (IID)

64 bits

End User Interface (EUI-64). Equivalent to IPv4 host address - since this field alone is bigger that the whole IPv4 address space it is fairly generous! When used in stateless (SLAAC) configurations the EUI-64 address part may be created from the MAC as described below in Link Local. RFC 4941 defines a method by which temporary (pseudo random) addresses (EUI-64) may be created in order to create privacy (or anonymity).

IPv6 Stateless Autoconfiguration (SLAAC)

IPv6 systems may be configured to provide global unicast addresses using Stateless Address AutoConfiguation (SLAAC - defined by RFC 4862) using what is called generically the Neighborhood Discovery Protocol (NDP). Stateless autoconfiguration requires a router to be present but not a DHCP server. The process of creating a stateless IPv6 address is as follows:

Host takes top bits as defined in the Prefix Information of the Router Advertisement message and combines it with the 64 bit EUI-64 address (in the case of Ethernet this is created from the MAC address using this process) to create a Global Unicast address. The host also uses the source IP address - in the IP header - of the Router Advertisement (RA) message as its default gateway address. And since RFC 6106 can also obtain information about DNS service from the RA messages.

RFC 4941 defines a method by which temporary (essentially pseudo-random from the interface derived EUI-64 address) addresses may be created in order to create privacy (or anonymity). RFC 4941 defines the default state of anonymous address creation as being off. If you wish anoymous access under IPv6 you may have to look for a specific configuration variable in your system to turn the anonymous feature on.

Host then performs a Duplicate Address Detection (DAD) to ensure the address is unique (and on any of the anaonymous addresses generated by RFC 4941 procedures). If this check fails the host immediately aborts the autoconfiguration process and must be manually configured.

In stateless autoconfiguration (SLAAC) the global unicast (public address) and the default router address are configured automatically. Additional address information, such as DNS addresses, are not and must be provided by either DHCPv6 or manual configuration.

IPv6 Link-Local Address Format

Link-Local addresses are automatically assigned by the end user equipment and require no external configuration. Format defined by RFC 4291 Section 2.5.6. The address format uses a unique binary prefix (FE8::/10) and the remaining bits (118) are built from the local interface identifier. In the case of ethernet (RFC 2464) the MAC (48 bits) is used to create the EUI-64 value as shown below. Each physical layer supported has a separate RFC for example, FDDI, IEEE 802.15.4 etc. defining, among other things, how the link-local address is created. If an interface identifier has more than 118 bits the link-local address cannot be generated and the unit must be manually configured. Link-local addresses are not routable globally (outside the local LAN/network - however that is defined). The 128 bits of a link-local address for an ethernet interface breakdown as follows:

10 bits - Binary Prefix

Name

Size

Description/Notes

Binary Prefix

10 bits

1111 1110 10 or FE8::/10 Link-Local Prefix

118 bits - constructed from interface MAC

Name

Size

Description/Notes

-

54 bits

all zeros

EUI-64 Contructed from the 48 bit MAC (802 LAN) or from a EUI-64 address(firewire etc.). Used both in Link-Local and SLAAC global unicast address construction

MAC

24 bits

Top 24 bits of the 48 bit interface MAC. Vendor ID. Additionally, when created using the MAC address - or another EUI-48 derivation scheme - bit 7 (bits numbered from 1 in normal IETF convention) of this value is set to 1. Manually configured addresses do not set this bit thus both simplifying their generation and allowing external systems to identify how the address was generated. Note: This is the reverse of the meaning of this bit in the MAC address.

Bizarre:RFC 4291 supposedly defines the IPv6 address structure including multi-cast addresses (2.7), however both RFC 3306 and RFC 3956 (earlier RFCs) define a more detailed format (not reflected in RFC 4291) which have been used to update the table below. Very disconcerting.

Name

Bits

Size

Value

Description/Notes

Binary Prefix

0 - 7

8

1111 1111

Fixed value a.k.a the routing prefix, binary prefix

ff1

8-11

4

XRPT

Flag field 1.
X flag:
Currently unused must be set to zero.
R flag: (Defined as R flag in RFC 3956)
0 = no Rendevous Point (RP) encoded
1 = RP encoded using method defined by RFC 3956. T = 1 must also be set.
P flag: (RFC 3306)
0 = The multicast address is not based on the network prefix
1 = the multicast address is assigned based on the network prefix (format defined in RFC 3306). T = 1 must also be set.
T flag:
0 = "well-known" or permanently (IANA) assigned group
1 = "transient" group which has no IANA assignment

If P = 1 (in ff1 above) indicates the number of bits used in the Network Prefix field below.

Network Prefix

33 - 96

64

-

"network prefix identifies the network prefix of the unicast subnet
owning the multicast address. If P = 1, this field contains the
unicast network prefix assigned to the domain owning, or allocating,
the multicast address". Assumed to be a right aligned field (RFC silent on the matter), further assumed that if P = 0 field is not used (again RFC is silent on the matter).

IPv6 Link Local Multicast Address Format

As if this stuff was not already complicated RFC 4489 introduced the concept of a link-local (or link scoped) multicast format for situations where all configuration is stateless. Theoretically, routers (and other equipment) servicing a local (non-global) network could be now made self-configuring.

Name

Bits

Size

Value

Description/Notes

Binary Prefix

0 - 7

8

1111 1111

Fixed value a.k.a the routing prefix, binary prefix

flags

8-11

4

0RPT

Flags have same meaning as defined for global multicast and must be set to 0011 meaning that T = 1 = "transient" group which has no IANA assignment and R = 1 = RP (Rendevous Point) encoded using method defined by RFC 3956.

scope

12-15

4

-

Scope has the same meaning as defined for global multicast but can only take the values:
0 - reserved
1 - interface-local scope
2 - link-local scope

Assigned using the normal link-local process depending on the media type.

Group ID

96 - 127

32

-

Since the T bit is set this group ID is not defined by IANA though RFC 4489 does indicate that the guidelines for multicast address generation could be used (RFC 4489 and its position within the address also implies a mask of /96 applied to both the glocal and link-local format would yield a similar result. The current list of IANA IPv6 Multicast assignments

IPv6 - IPv4 Interworking

IPv6 allows transport of IPv4 addresses using two methods. The methods are described in RFC 2893/RFC 4038 and RFC 4291 Section 2.5.5.

The first method is termed an "IPv4-compatible IPv6 address" and must use a globally unique IPv4 address. Please note: To avoid publication of a global IPv4 the example below shows a private (non-globally unique) IPv4 address purely to illustrate the principle:

# IPv4-compatible IPv6 address
# assume the host has an IPv4 address of:
192.168.0.5
# this is represented by the hex value C0A80005
# the IPv4-compatible IPv6 address would be
::C0A8:5
# or if you like writing zeros
0:0:0:0:0:0:C0A8:5
# or using the hybrid IPv6 - IPv4 notation
::192.168.0.5

The IPv4-compatible IPv6 address format is used when the end interface supports both IPv6 and IPv4 (a dual stack interface). This method is now deprecated (RFC 4291).

The second method is termed an "IPv4-mapped IPv6 address" and must use a globally unique IPv4 address. Please note: To avoid publication of a global IPv4 the example below shows a private (non-globally unique) IPv4 address purely to illustrate the principle:

# IPv4-mapped IPv6 address
# assume the host has an IPv4 address of:
192.168.0.5
# this address is represented by the hex value C0A80005
# the IPv4-mapped IPv6 address would be
::FFFF:C0A8:5
# or if you like writing zeros
0:0:0:0:0:FFFF:C0A8:5
# or using the hybrid IPv6 - IPv4 notation
::FFFF:192.168.0.5

The IPv4-mapped IPv6 address format is used when the end interface supports only IPv4 and indicates that a configured IPv6 system, for instance, a router or the IPv6 stack will have to perform conversion to the IPv4 protocol prior to communicating with the interface.

IPv6 over IPv4 Interworking

IPv6 over IPv4 (more commonly refered to these days as 6to4) allows two IPv6 networks/devices to communicate over an IPv4 network (defined by RFC 3056). Both ends of the network must have a globally unique IPv4 address and the end points must run either a 6to4 relay or a 6to4 transit service. A special unicast address block has been assigned for these classes of service (2002::/16). The IPv6 address format used by this address block is defined below

The low order 80 bits allow for end user transparency within the IPv6 address. The relay or transit service will extract the IPv4 address when communicating accross the IPv4 cloud.

Note: Another IPv4 to IPv6 transition method is biting the dust.RFC 7526 deprecates the reserved Unicast prefix (2002::/16) used in 6to4 tunneling. For backward compability the feature will still exist but for new implementations: forget it. Meh.

IPv6 Address Calculator

IPv6 Calculator: Enter an IPv6 address with its /Prefix (or slash) notation in the IPv6/Prefix: box and click IPv6 Info. The calculator will fully expand the IPv6 address and place in IPv6 Expanded:, IPv6 Netmask in compressed format, IPv6 GPR contains the top part or the address which may be the Global Routing Prefix (GRP) or not depending on the /Prefix value and IPv6 User: is the lower part of the address based on the /Prefix value. Finally, the reverse map zone name of the IPv6 address is calculated based on the /Prefix value (IPv6 addresses below this name will be defined in the reverse zone file) and shown in FQDN format in Reverse Zone. In Zone IPv6: shows the IPv6 address element that would appear with the zone file based on the /Prefix value. Since IPv6 addresses cover very serious numbers the No. of IPs: box is only used in the alternative mode described below and is only updated in that context.

Alternatively, enter a single IPv6 address (that lies anywhere in the desired range) without the /prefix in IPv6/Prefix and the number of desired IP addresses (if it is not a power of 2 it will be rounded up to the nearest power of 2 - a maximum of 6 digits is allowed) in No. of IPs then click IPv6 Info. The calculator will populate IPv6/Prefix (with the calculated /Prefix to cover the required or calculated number of IP addresses), No. of IPs will be updated if needed (due to any power of 2 rounding required) and IPv6 Netmask, IPv6 GPR, IPv6 User:, Reverse Zone and In Zone IPv6: will be populated normally.

The Clear button zaps ALL entries in IPv6 Calculator only.

Notes:

Validation and other errors are shown in the IPv6 Netmask box for no very good reason.

When entering a /prefix IPv6 address you only need to enter as many colon elements as are required by the /prefix (more is not a problem), if you enter less than the required number the calculator silently pads to the right with zeros.

While a /Prefix for IPv6 is most normally a multiple of 8 (or even 16) the calculator allows any bit value. You can break on very strange boundaries if desired.

The calculator follows the recommendation of RFC 5952 about use of lower case hexadecimal characters, removal of all leading zeros in address elements, largest zero block elimination but it will eliminate a single zero block if this is the only one available (since this obeys the longest zero block elimination rule).

The calculator accepts IPv6 addresses in IPv4-Mapped IPv6 format (x:x:x:x:x:x:d.d.d.d) but does not verify that the required selectors are present. You currently have to do some work.

IPv6/Prefix:

No. of IPs:

IPv6 Expanded:

IPv6 Netmask:

IPv6 GPR:

IPv6 User:

Reverse zone:

In Zone IPv6:

Notes:

Javascript implementations may vary from browser to browser. This feature was tested with MSIE 10, Gecko (Firefox 25.0.1), Opera 11.10 and Chrome (31.0.1650.57 m) - so will likely work with any WebKit based browser, which obviously includes Safari (and now even Opera!)). If the tester does not work for you we are very, very sad - but yell at your browser supplier not us. However, if you do think you have found, or want to suggest improvements, an error please take the time to email using the link at the foot of this page.

IPv6 Frame Format

IPv6 headers are daisy chained. The Next Header field - present in every header except the upper layer header - indicates which header comes next as shown in the diagram below:

Notes:

Zero or more Extension headers may be present.

Multiple Extension headers of any type may be present.

All Extension headers are assumed to be of variable length and contain a length value (expressed in multiples of 8 octets).

Only one upper layer header may be present and is unchanged from IPv4 e.g. tcp with the exception of the format of the 'pseudo-header' used to generate the checksum.

Data (MTU) length is defined to be a minimum of 1280 octets with a recommendation of 1500+ octets. If any routing link cannot carry this size of MTU, link specific fragmentation must be carried out below (i.e. invisible to) IPv6.

When carrying UDP traffic in the upper layers the optional (in IPv4) UDP checksum MUST be present.

The pseudo header used in TCP, UDP and IPv6 ICMP is assumed be a 40 octet field and have the following format:

Unsigned integer. The total length of the extension header in multiples of 8 octets, excluding the first 8 octets e.g. a value of 0 = 8 octet header length, value = 2 = 24 octet header length etc. NB the length field in ICMPv6 does not use this convention - it's always good to have consistency in standards.

Header Options

The Hop-By-Hop and Destination Headers carry a variable number of options within the header and use a classic TLD (or TLV in the standards paralance) format as shown below:

Name

Length

Description/Notes

Type

8 bits

The two high order (or low order depending on your numbering convention) bits indicate what action to take if the option is not recognized and may take one of the following values:
00 = skip option - keep processing
01 = discard packet
10 = discard packet and send ICMPv6 Parameter Problem (Code 2) message
11 = discard packet and, if not Multicast address, send ICMPv6 Parameter Problem (Code 2) message
The third high order bit indicates whether the option can change before reaching its destination 0 = data will not change, 1 = data may change. If the bit is set and an Authentication Header is present then an all zero option value must be assumed when computing any digest.

Length

8 bits

Length in octets of the option data - does not include the type or length value.

Data

variable

Depends on Type

In order to force so-called natural alignment of option fields two padding options are provided. An Option Type of 0 indicates a 1 octet pad (and does not have associated length or data fields), a standard Option with a Type of 1 allows for multiple octet padding. NB in this case a 2 octet pad will have an Option Length of 0.

IPv6 Hop-By-Hop Header

One Day Real Soon Now ™

IPv6 Destination Header

One Day Real Soon Now ™

IPv6 RFCs

This rather daunting list of RFCs describe IPv6 or are relevant to it. Many of the later RFCs simply roll-back features of the earlier ones. Most of the new work is associated with mobile development and various tunneling methods.

Note: The main repository for RFCs is maintained by the IETF, text versions (the normative reference) may be viewed at www.ietf.org/rfc/rfcXXXX.txt or www.rfc-editor.org/rfc/rfcXXXX.txt (where XXXX is the 4 digit RFC number - left padded with zeros as necessary). Currently published RFCs are pointed to https://www.rfc-editor.org/info/rfcXXXX (where XXXX is the 4 digit RFC number - left padded with zeros as necessary) which contains various information and links to the text (normative) reference and a PDF (non-normative) version. The RFC may also be viewed at http://datatracker.ietf.org/doc/rfcXXXX/ (where XXXX is the 4 digit RFC number - left padded with zeros as necessary) which also contains various RFC status information together with a list of alternative formats, such as, text, PDF and HTML (this is the working area version of the document). Finally, there is now a searchable RFC list.

<ingrained habit> The RFC links below yield a plain text version which was copied to our site when the RFC was issued. We started this service a long time ago when the world was young, RFCs were maintained in some strange places, occasionally moved location, and performance and reliability of the repositories was very variable (being generous). None of these conditions apply today, far from it. Nevertheless, we persist in our ingrained habits for no particularly good reason (old dog...new tricks..). If you want/prefer/need more choice you are advised to use one of the links identified above, if, however, you just want to read the blasted RFC, feel free to click the links below.</ingrained habit>

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.