Tech Info - 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 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 pressing need for IPv6's increased address range.

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 we are rapidly approaching the time when we have little choice.

You need to be fairly comfortable with Hex stuff to handle IPv6 [quick overview of Hexadecimal, Binary and Decimal]

Contents

1. IPv6 Overview
2. IPv6 Address Notation
3. IPv6 Prefix or Slash Notation
4. IPv6 Address Types
5. IPv6 Global Unicast Address Format
6. IPv6 End-User Address Format
7. IPv6 Link-Local Address Format
8. IPv6 Multicast Address Format
9. IPv6 - IPv4 Interworking
10. IPv6 over IPv4 Interworking (6to4)
11. IPv6 Frame Format
12. IPv6 Header Format
13. IPv6 Order of Headers
14. IPv6 Extension Headers
15. IPv6 Stateless Autoconfiguration
16. IPv6 Discovery
17. IPv6 ICMP
18. IPv6 ping6 command
19. IPv6 traceroute6 command
20. IPv6 RFCs

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 the 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.	Private network address with multi-homed interface is closest equivalent.	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.
Global Unicast	Globally unique. Fully routable. Assigned by IANA/Regional Internet Registries (RIRs).	Global IP address.	IPv6 and IPv4 similar but IPv6 can have other scoped addresses. Format.
Multicast	One-to-many. Hierarchy of multicasting.	Similar to IPv4 Class D.	Significantly more powerful than IPv4 version. No broadcast in IPv6, replaced by multicast. Multicast may also be scoped to link-local (RFC 4489). Format.
Anycast	One-to-nearest. Uses Global Unicast Addresses. Routers only. Discovery uses.	Unique protocols in IPv4, for example, IGMP.	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) 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:

# raw ipv6 address
2001:0000:0234:C1AB:0000:00A0:AABC:003F
# address with single 0 dropped
2001::0234:C1ab:0:A0:aabc:003F
# alternate version - address with single 0 dropped
2001:0:0234:C1ab::A0:aabc:003F
# the following is INVALID
2001::0234:C1ab::A0:aabc:003F

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 where the normal IPv4 dotted decimal notation may be used after the first 6, 16 bit address elements:

# generic IPv6-IPv4 format x.x.x.x.x.x.d.d.d.d
# example of an IPv4 mapped IPv6 address
# with an IPv4 number of 192.168.0.5
2001:db8:0:0:0:0:FFFF:192.168.0.5
# or using zero ommission
2001.db8::FFFF:192.168.0.5

Note: 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 must always be a 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:

# single user address
2001:db8::1/128
# normal user IPv6 address allocation 
# allows the user to control the low order 80 bits
2001:db8::/48
# values only required to cover the prefix
FE8::/10
# or top 3 bits only with fixed value 001 (binary)
2::/3

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):

Use	Binary Prefix	Slash	Description/Notes
Unspecified	00...0	::/128	IPv6 address = 0:0:0:0:0:0:0:0 (or ::) Used before an address allocated by DHCP (equivalent of IPv4 0.0.0.0)
Loopback	00...1	::1/128	IPv6 address = 0:0:0:0:0:0:0:1 (or ::1) Local PC Loopback (equivalent of IPv4 127.0.0.1)
Multicast	1111 1111	FF::/8	Format. There is now a link-local multicast format defined by RFC 4489.
Link-Local unicast	1111 1110 10	FE8::/10	Local LAN scope. Lower bits created from MAC address. Format. There is now a link-local multicast format defined by RFC 4489.
Site-Local unicast	1111 1110 11	FEC::/10	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
global routing prefix	Variable	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.
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 (home or business)	/48	The user controls the full 80 bits addresses comprising the subnet ID and interface ID
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

The justification for this, seemingly generous, address allocation policy is that the 45 address bits (48 bit global routing prefix - 3 bit binary prefix) still allow 35 trillion /48 allocations (contrasted with the earth's population prediction of a mere 9 billion by 2050).

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:

global routing prefix of 48 bits - assigned by IANA.
Name	Size	Description/Notes
reserved	3 bits	001 (or simply not 000 in some RFCs) - Global Unicast Address prefix (assigned by IANA)
-	Variable	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 bits - typically assigned by the user
Name	Size	Description/Notes
subnet ID	16 bits	Used for subnet routing. Se 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.
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 configurations the EUI-64 address part may be created from the MAC as described below. RFC 4941 defines a method by which temporary (essential random) addresses (EUI-64) may be created in order to create privacy (or anonymity).

IPv6 Addresses may be assigned to interfaces using one of three methods:

1. Stateful - Statically assigned = manual configuration
2. Stateful - DHCPv6 - Automatically assigned
3. Stateless - Automatically assigned

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
MAC	24 bits	top 24 bits of the 48 bit interface MAC. Vendor ID
ID	16 bits	Fixed value of FFFE inserted
MAC	24 bits	low 24 bits of the 48 bit interface MAC. Serial number.

Example

# Interface MAC
00-40-63-ca-9a-20
# IPv6 Interface ID (EUI-64)
::0040:63FF:FECA:9A20
# or
::40:63FF:FECA:9A20
# link local
FE80::40:63FF:FECA:9A20

IPv6 Multicast Address Format

The Multicast format (which also replaces broadcast in IPv4) is defined by RFC 4291 Section 2.7. There is now a link-local multicast format defined by RFC 4489. The fomat of a global (non link-local) multicast address is defined below:

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	Where T may be either: 0 = "well-known" or permanently (IANA) assigned group 1 = "transient" group which has no IANA assignment R flag: (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.
scope	12-15	4	-	May take one of the following assigned values: 0 - reserved 1 - interface-local scope 2 - link-local scope 3 - reserved 4 - admin-local scope 5 - site-local scope 6 - (unassigned) 7 - (unassigned) 8 - organization-local scope 9 - (unassigned) A - (unassigned) B - (unassigned) C - (unassigned) D - (unassigned) E - global scope F - reserved
Group ID	16 - 127	112	-	Uniquely assigned by IANA if "well-known" bit = 0 set in T flag above. The current list of IANA IPv6 Multicast assignments

The following lists some of the more common multicast groups:

Address	Description/Notes
FF01::1	Interface local - all nodes
FF02::1	Link local - all nodes
FF01::2	Interface local - all routers
FF02::2	Link local - all routers

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
Reserved	16 - 23	8	-	Reserved - must be 0
plen	24 - 31	8	-	Fixed value of 1111 1111 denotes a link-local (or link scoped) multicast address
IID (EUI-64)	32 - 95	64	-	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

Name	Bits	Size	Value	Description/Notes
Unicast Prefix	0 - 15	16	2002::/16	IANA assigned value.
IPv4 Address	16 - 47	32	IPv4 Global Address	IPv4 address associated with this 6to4 relay or transit service
subnet ID	48 - 63	16	-	Normal usage
IID	64 - 1273	64	-	Interface ID (EUI-64)

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.

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:

1. Zero or more Extension headers may be present.

2. Multiple Extension headers of any type may be present.

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

4. 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.

5. 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.

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

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

   Name	Size	Description/Notes
   Source	128 bits	IPv6 source address
   Destination	128 bits	IPv6 destination address
   Packet Length	32 bits	Length in octets of the upper layer data packet plus associated header.
   -	24 bits	Must be zeros
   Next Header	8 bits	Assumed to contain the value of the protocol carried in the upper layer e.g. 6 = TCP etc..

IPv6 Header Format

IPv6 Header Format
Name	Length	Description/Notes
version	4 bits	value = 6. Same location as IPv4 - everything after this changes.
traffic class	8 bits	None formally defined with IANA (late 2004). When used with Explicit Congestion Notification (ECN) (RFC 3168) may take values defined here and here.
Flow Label	20 bits	-
payload length	16 bits	unsigned length in octets of payload (excludes header but includes extensions)
next header	8 bits	Identifier in following header - same values as IPv4 Protocol field Some common values: 0 (0x00) IPv6 Hop-by-Hop Option 1 (0x01) ICMP protocol 2 (0x02) IGMP protocol 4 (0x04) IP over IP 6 (0x06) TCP protocol 17 (0x11) UDP protocol 41 (0x29) IPv6 protocol 58 (0x3A) IPv6 ICMP protocol 59 (0x3B) IPv6 No Next Header (terminates a no upper layer frame) Definitive list is here
hop limit	8 bits	Maximum number of hops. Formalises the current practice when using the TTL in IPv4.
source IP	128 bits	-
destination IP	128 bits	-

Order of Headers

Where multiple headers are present the recommended sender order is (but the receiver must accept in any order):

IPv6 Header
Hop-by-Hop Header
Destination Options
Routing Headers
Fragment Headers
Authentication Headers
Encapsulation Security Payload (ESP) Header
Destination Options
Upper Layer Header + data

Extension Headers

Extension headers are always multiples of 8 octets. To allow skipping and processing of extension headers they all begin with the following 16 bit stub format:

IPv6 Extension Header - Stub format
Name	Length	Description/Notes
Next Header	8 bits	Same values as IPv6 Next Header
Extension Hdr Len	8 bits	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 Configuration

IPv6 systems are typically multi-homed by default and have a link-local address configured by the host and may have a global unicast address which may be configured by one of three methods:

1. Stateful - Statically assigned = manual configuration
2. Stateful - DHCPv6 - Automatically assigned
3. Stateless - Automatically assigned

IPv6 Stateless Autoconfiguration

IPv6 systems may be configured to provide global unicast addresses using stateless autconfiguation. Stateless autoconfiguration requires a router to be present but not a DHCP server. In stateless autoconfiguration a default router address is provided but not a DNS and other information that is normally provided by DHCP. The process of creating a stateless IPv6 address is as follows:

1. Host sends a Router Solicitation message

2. Host waits for a Router Advertisement message.

3. Host takes top 64 bits from Subnet Prefix part of Router Advertisement and combines it with the 64 bit EUI-64 address (in the case of Ethernet this is created from the MAC) to create a Global Unicast address. The host also takes the default gateway address from the Router Advertisement message.

   RFC 4941 defines a method by which temporary (essential random) addresses (EUI-64) may be created in order to create privacy (or anonymity).

4. Host then performs a Duplicate Address Detection to ensure the address is unique. If this check fails the host immediately aborts the autoconfiguration process and must be manually configured.

IPv6 RFCs

The following RFCs define IPv6. Wow is this a list. You can get the RFCs from the IETF.

RFC	Description/Status
RFC 1809	Using the Flow Label Field in IPv6. C. Partridge. June 1995. (Format: TXT=13591 bytes) (Status: INFORMATIONAL)
RFC 1881	IPv6 Address Allocation Management. IAB, IESG. December 1995. (Format: TXT=3215 bytes) (Status: INFORMATIONAL)
RFC 1883	Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. December 1995. (Format: TXT=82089 bytes) (Obsoleted by RFC2460) (Status: PROPOSED STANDARD)
RFC 1885	Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6). A. Conta, S. Deering. December 1995. (Format: TXT=32214 bytes) (Obsoleted by RFC2463) (Status: PROPOSED STANDARD)
RFC 1887	An Architecture for IPv6 Unicast Address Allocation. Y. Rekhter, T. Li, Eds.. December 1995. (Format: TXT=66066 bytes) (Status: INFORMATIONAL)
RFC 1888	OSI NSAPs and IPv6. J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd. August 1996. (Format: TXT=36469 bytes) (Status: EXPERIMENTAL)
RFC 1924	A Compact Representation of IPv6 Addresses. R. Elz. Apr-01-1996. (Format: TXT=10409 bytes) (Status: INFORMATIONAL)
RFC 1932	IP over ATM: A Framework Document. R. Cole, D. Shur, C. Villamizar. April 1996. (Format: TXT=68031 bytes) (Status: INFORMATIONAL)
RFC 2080	RIPng for IPv6. G. Malkin, R. Minnear. January 1997. (Format: TXT=47534 bytes) (Status: PROPOSED STANDARD)
RFC 2375	IPv6 Multicast Address Assignments. R. Hinden, S. Deering. July 1998. (Format: TXT=14356 bytes) (Status: INFORMATIONAL)
RFC 2428	FTP Extensions for IPv6 and NATs. M. Allman, S. Ostermann, C. Metz. September 1998. (Format: TXT=16028 bytes) (Status: PROPOSED STANDARD)
RFC 2460	Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. December 1998. (Format: TXT=85490 bytes) (Obsoletes RFC1883) (Updated by RFC5095, RFC5722) (Status: DRAFT STANDARD)
RFC 2461	Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson. December 1998. (Format: TXT=222516 bytes) (Obsoletes RFC1970) (Status: DRAFT STANDARD)
RFC 2462	IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. December 1998. (Format: TXT=61210 bytes) (Obsoletes RFC1971) (Status: DRAFT STANDARD)
RFC 2463	Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering. December 1998. (Format: TXT=34190 bytes) (Obsoletes RFC1885) (Status: DRAFT STANDARD)
RFC 2464	Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. December 1998. (Format: TXT=12725 bytes) (Obsoletes RFC1972) (Status: PROPOSED STANDARD)
RFC 2465	Management Information Base for IP Version 6: Textual Conventions and General Group. D. Haskin, S. Onishi. December 1998. (Format: TXT=77339 bytes) (Status: PROPOSED STANDARD)
RFC 2466	Management Information Base for IP Version 6: ICMPv6 Group. D. Haskin, S. Onishi. December 1998. (Format: TXT=27547 bytes) (Status: PROPOSED STANDARD)
RFC 2467	Transmission of IPv6 Packets over FDDI Networks. M. Crawford. December 1998. (Format: TXT=16028 bytes) (Obsoletes RFC2019) (Status: PROPOSED STANDARD)
RFC 2492	IPv6 over ATM Networks. G. Armitage, P. Schulter, M. Jork. January 1999. (Format: TXT=21199 bytes) (Status: PROPOSED STANDARD)
RFC 2526	Reserved IPv6 Subnet Anycast Addresses. D. Johnson, S. Deering. March 1999. (Format: TXT=14555 bytes) (Status: PROPOSED STANDARD)
RFC 2529	Transmission of IPv6 over IPv4 Domains without Explicit Tunnels. B. Carpenter, C. Jung. March 1999. (Format: TXT=21049 bytes) (Status: PROPOSED STANDARD)
RFC 2545	Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing. P. Marques, F. Dupont. March 1999. (Format: TXT=10209 bytes) (Status: PROPOSED STANDARD)
RFC 2673	Binary Labels in the Domain Name System. M. Crawford. August 1999. (Format: TXT=12379 bytes) (Updated by RFC3363, RFC3364) (Status: EXPERIMENTAL)
RFC 2675	IPv6 Jumbograms. D. Borman, S. Deering, R. Hinden. August 1999. (Format: TXT=17320 bytes) (Obsoletes RFC2147) (Status: PROPOSED STANDARD)
RFC 2710	Multicast Listener Discovery (MLD) for IPv6. S. Deering, W. Fenner, B. Haberman. October 1999. (Format: TXT=46838 bytes) (Updated by RFC3590, RFC3810) (Status: PROPOSED STANDARD)
RFC 2711	IPv6 Router Alert Option. C. Partridge, A. Jackson. October 1999. (Format: TXT=11973 bytes) (Status: PROPOSED STANDARD)
RFC 2732	Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. December 1999. (Format: TXT=7984 bytes) (Updates RFC2396) (Status: PROPOSED STANDARD)
RFC 2740	OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy. December 1999. (Format: TXT=189810 bytes) (Status: PROPOSED STANDARD)
RFC 2766	Network Address Translation - Protocol Translation (NAT-PT). G. Tsirtsis, P. Srisuresh. February 2000. (Format: TXT=49836 bytes) (Updated by RFC3152) (Status: PROPOSED STANDARD)
RFC 2893	Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. Nordmark. August 2000. (Format: TXT=62731 bytes) (Obsoletes RFC1933) (Status: PROPOSED STANDARD)
RFC 2894	Router Renumbering for IPv6. M. Crawford. August 2000. (Format: TXT=69135 bytes) (Status: PROPOSED STANDARD)
RFC 2928	Initial IPv6 Sub-TLA ID Assignments. R. Hinden, S. Deering, R. Fink, T. Hain. September 2000. (Format: TXT=11882 bytes) (Status: INFORMATIONAL)
RFC 3041	Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves. January 2001. (Format: TXT=44446 bytes) (Obsoleted by RFC4941) (Status: PROPOSED STANDARD)
RFC 3056	Connection of IPv6 Domains via IPv4 Clouds. B. Carpenter, K. Moore. February 2001. (Format: TXT=54902 bytes) (Status: PROPOSED STANDARD)
RFC 3111	Service Location Protocol Modifications for IPv6. E. Guttman. May 2001. (Format: TXT=25543 bytes) (Status: PROPOSED STANDARD)
RFC 3122	Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification. A. Conta. June 2001. (Format: TXT=40416 bytes) (Status: PROPOSED STANDARD)
RFC 3146	Transmission of IPv6 Packets over IEEE 1394 Networks. K. Fujisawa, A. Onoe. October 2001. (Format: TXT=16569 bytes) (Status: PROPOSED STANDARD)
RFC 3152	Delegation of IP6.ARPA. R. Bush. August 2001. (Format: TXT=5727 bytes) (Obsoleted by RFC3596) (Updates RFC2874, RFC2772, RFC2766, RFC2553, RFC1886) (Also BCP0049) (Status: BEST CURRENT PRACTICE)
RFC 3162	RADIUS and IPv6. B. Aboba, G. Zorn, D. Mitton. August 2001. (Format: TXT=20492 bytes) (Status: PROPOSED STANDARD)
RFC 3175	Aggregation of RSVP for IPv4 and IPv6 Reservations. F. Baker, C. Iturralde, F. Le Faucheur, B. Davie. September 2001. (Format: TXT=88681 bytes) (Status: PROPOSED STANDARD)
RFC 3177	IAB/IESG Recommendations on IPv6 Address Allocations to Sites. IAB, IESG. September 2001. (Format: TXT=23178 bytes) (Status: INFORMATIONAL)
RFC 3266	Support for IPv6 in Session Description Protocol (SDP). S. Olson, G. Camarillo, A. B. Roach. June 2002. (Format: TXT=8693 bytes) (Updates RFC2327) (Status: PROPOSED STANDARD)
RFC 3306	Unicast-Prefix-based IPv6 Multicast Addresses. B. Haberman, D. Thaler. August 2002. (Format: TXT=12713 bytes) (Status: PROPOSED STANDARD)
RFC 3307	Allocation Guidelines for IPv6 Multicast Addresses. B. Haberman. August 2002. (Format: TXT=15742 bytes) (Status: PROPOSED STANDARD)
RFC 3314	Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards. M. Wasserman, Ed.. September 2002. (Format: TXT=48168 bytes) (Status: INFORMATIONAL)
RFC 3315	Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July 2003. (Format: TXT=231402 bytes) (Status: PROPOSED STANDARD)
RFC 3363	Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS). R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain. August 2002. (Format: TXT=11055 bytes) (Updates RFC2673, RFC2874) (Status: INFORMATIONAL)
RFC 3364	Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6). R. Austein. August 2002. (Format: TXT=26544 bytes) (Updates RFC2673, RFC2874) (Status: INFORMATIONAL)
RFC 3484	Default Address Selection for Internet Protocol version 6 (IPv6). R. Draves. February 2003. (Format: TXT=55076 bytes) (Status: PROPOSED STANDARD)
RFC 3513	Internet Protocol Version 6 (IPv6) Addressing Architecture. R. Hinden, S. Deering. April 2003. (Format: TXT=53920 bytes) (Obsoletes RFC2373) (Status: obsoleted by RFC4291)
RFC 3587	IPv6 Global Unicast Address Format. R. Hinden, S. Deering, E. Nordmark. August 2003. (Format: TXT=8783 bytes) (Obsoletes RFC2374) (Status: INFORMATIONAL)
RFC 3596	DNS Extensions to Support IP Version 6. S. Thomson, C. Huitema, V. Ksinant, M. Souissi. October 2003. (Format: TXT=14093 bytes) (Obsoletes RFC3152, RFC1886) (Status: DRAFT STANDARD)
RFC 3633	IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6. O. Troan, R. Droms. December 2003. (Format: TXT=45308 bytes) (Status: PROPOSED STANDARD)
RFC 3646	DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms, Ed.. December 2003. (Format: TXT=13312 bytes) (Status: PROPOSED STANDARD)
RFC 3697	IPv6 Flow Label Specification. J. Rajahalme, A. Conta, B. Carpenter, S. Deering. March 2004. (Format: TXT=21296 bytes) (Status: PROPOSED STANDARD)
RFC 3736	Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6. R. Droms. April 2004. (Format: TXT=18510 bytes) (Status: PROPOSED STANDARD)
RFC 3775	Mobility Support in IPv6. D. Johnson, C. Perkins, J. Arkko. June 2004. (Format: TXT=393514 bytes) (Status: PROPOSED STANDARD)
RFC 3776	Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents. J. Arkko, V. Devarapalli, F. Dupont. June 2004. (Format: TXT=87076 bytes) (Status: PROPOSED STANDARD)
RFC 3810	Multicast Listener Discovery Version 2 (MLDv2) for IPv6. R. Vida, Ed., L. Costa, Ed.. June 2004. (Format: TXT=153579 bytes) (Updates RFC2710) (Status: PROPOSED STANDARD)
RFC 3831	Transmission of IPv6 Packets over Fibre Channel. C. DeSanti. July 2004. (Format: TXT=53328 bytes) (Status: PROPOSED STANDARD)
RFC 3849	IPv6 Address Prefix Reserved for Documentation. G. Huston, A. Lord, P. Smith. July 2004. (Format: TXT=7872 bytes) (Status: INFORMATIONAL)
RFC 3901	DNS IPv6 Transport Operational Guidelines. A. Durand, J. Ihren. September 2004. (Format: TXT=10025 bytes) (Also BCP0091) (Status: BEST CURRENT PRACTICE)
RFC 3956	Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. P. Savola, B. Haberman. November 2004. (Format: TXT=40136 bytes) (Updates RFC3306) (Status: PROPOSED STANDARD)
RFC 4007	IPv6 Scoped Address Architecture. S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill. March 2005. (Format: TXT=53555 bytes) (Status: PROPOSED STANDARD)
RFC 4038	Application Aspects of IPv6 Transition. M-K. Shin, Ed., Y-G. Hong, J. Hagino, P. Savola, E. M. Castro. March 2005. (Format: TXT=69727 bytes) (Status: INFORMATIONAL)
RFC 4074	Common Misbehavior Against DNS Queries for IPv6 Addresses. Y. Morishita, T. Jinmei. May 2005. (Format: TXT=13073 bytes) (Status: INFORMATIONAL)
RFC 4147	Proposed Changes to the Format of the IANA IPv6 Registry. G. Huston. August 2005. (Format: TXT=21196 bytes) (Status: INFORMATIONAL)
RFC 4193	Unique Local IPv6 Unicast Addresses. R. Hinden, B. Haberman. October 2005. (Format: TXT=35908 bytes) (Status: PROPOSED STANDARD)
RFC 4213	Basic Transition Mechanisms for IPv6 Hosts and Routers. E. Nordmark, R. Gilligan. October 2005. (Format: TXT=58575 bytes) (Obsoletes RFC2893) (Status: PROPOSED STANDARD)
RFC 4215	Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks. J. Wiljakka, Ed.. October 2005. (Format: TXT=52903 bytes) (Status: INFORMATIONAL)
RFC 4242	Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). S. Venaas, T. Chown, B. Volz. November 2005. (Format: TXT=14759 bytes) (Status: PROPOSED STANDARD)
RFC 4260	Mobile IPv6 Fast Handovers for 802.11 Networks. P. McCann. November 2005. (Format: TXT=35276 bytes) (Status: INFORMATIONAL)
RFC 4283	Mobile Node Identifier Option for Mobile IPv6 (MIPv6). A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. November 2005. (Format: TXT=14653 bytes) (Status: PROPOSED STANDARD)
RFC 4283	Mobile Node Identifier Option for Mobile IPv6 (MIPv6). A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. November 2005. (Format: TXT=14653 bytes) (Status: PROPOSED STANDARD)
RFC 4291	IP Version 6 Addressing Architecture. R. Hinden, S. Deering. February 2006. (Format: TXT=52897 bytes) (Obsoletes RFC3513) (Status: DRAFT STANDARD)
RFC 4295	Mobile IPv6 Management Information Base. G. Keeni, K. Koide, K. Nagami, S. Gundavelli. April 2006. (Format: TXT=209038 bytes) (Status: PROPOSED STANDARD)
RFC 4311	IPv6 Host-to-Router Load Sharing. R. Hinden, D. Thaler. November 2005. (Format: TXT=10156 bytes) (Updates RFC2461) (Status: PROPOSED STANDARD)
RFC 4339	IPv6 Host Configuration of DNS Server Information Approaches. J. Jeong, Ed.. February 2006. (Format: TXT=60803 bytes) (Status: INFORMATIONAL)
RFC 4380	Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs). C. Huitema. February 2006. (Format: TXT=132607 bytes) (Status: PROPOSED STANDARD)
RFC 4429	Optimistic Duplicate Address Detection (DAD) for IPv6. N. Moore. April 2006. (Format: TXT=33123 bytes) (Status: PROPOSED STANDARD)
RFC 4443	Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering, M. Gupta, Ed.. March 2006. (Format: TXT=48969 bytes) (Obsoletes RFC2463) (Updates RFC2780) (Status: DRAFT STANDARD)
RFC 4449	Securing Mobile IPv6 Route Optimization Using a Static Shared Key. C. Perkins. June 2006. (Format: TXT=15080 bytes) (Status: PROPOSED STANDARD)
RFC 4489	A Method for Generating Link-Scoped IPv6 Multicast Addresses. J-S. Park, M-K. Shin, H-J. Kim. April 2006. (Format: TXT=12224 bytes) (Updates RFC3306) (Status: PROPOSED STANDARD)
RFC 4649	Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option. B. Volz. August 2006. (Format: TXT=10940 bytes) (Status: PROPOSED STANDARD)
RFC 4704	The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option. B. Volz. October 2006. (Format: TXT=32359 bytes) (Status: PROPOSED STANDARD)
RFC 4727	Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers. B. Fenner. November 2006. (Format: TXT=19745 bytes) (Status: PROPOSED STANDARD)
RFC 4773	Administration of the IANA Special Purpose IPv6 Address Block. G. Huston. December 2006. (Format: TXT=10580 bytes) (Status: INFORMATIONAL)
RFC 4776	Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information. H. Schulzrinne. November 2006. (Format: TXT=45495 bytes) (Obsoletes RFC4676) (Status: PROPOSED STANDARD)
RFC 4779	ISP IPv6 Deployment Scenarios in Broadband Access Networks. S. Asadullah, A. Ahmed, C. Popoviciu, P. Savola, J. Palet. January 2007. (Format: TXT=188511 bytes) (Status: INFORMATIONAL)
RFC 4798	Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE). J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur. February 2007. (Format: TXT=31381 bytes) (Status: PROPOSED STANDARD)
RFC 4818	RADIUS Delegated-IPv6-Prefix Attribute. J. Salowey, R. Droms. April 2007. (Format: TXT=12993 bytes) (Status: PROPOSED STANDARD)
RFC 4843	An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID). P. Nikander, J. Laganier, F. Dupont. April 2007. (Format: TXT=32483 bytes) (Status: EXPERIMENTAL)
RFC 4852	IPv6 Enterprise Network Analysis - IP Layer 3 Focus. J. Bound, Y. Pouffary, S. Klynsma, T. Chown, D. Green. April 2007. (Format: TXT=76199 bytes) (Status: INFORMATIONAL)
RFC 4861	Neighbor Discovery for IP version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson, H. Soliman. September 2007. (Format: TXT=235106 bytes) (Obsoletes RFC2461) (Status: DRAFT STANDARD)
RFC 4862	IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten, T. Jinmei. September 2007. (Format: TXT=72482 bytes) (Obsoletes RFC2462) (Status: DRAFT STANDARD)
RFC 4864	Local Network Protection for IPv6. G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein. May 2007. (Format: TXT=95448 bytes) (Status: INFORMATIONAL)
RFC 4866	Enhanced Route Optimization for Mobile IPv6. J. Arkko, C. Vogt, W. Haddad. May 2007. (Format: TXT=145757 bytes) (Status: PROPOSED STANDARD)
RFC 4877	Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture. V. Devarapalli, F. Dupont. April 2007. (Format: TXT=57941 bytes) (Updates RFC3776) (Status: PROPOSED STANDARD)
RFC 4882	IP Address Location Privacy and Mobile IPv6: Problem Statement. R. Koodli. May 2007. (Format: TXT=24987 bytes) (Status: INFORMATIONAL)
RFC 4890	Recommendations for Filtering ICMPv6 Messages in Firewalls. E. Davies, J. Mohacsi. May 2007. (Format: TXT=83479 bytes) (Status: INFORMATIONAL)
RFC 4891	Using IPsec to Secure IPv6-in-IPv4 Tunnels. R. Graveman, M. Parthasarathy, P. Savola, H. Tschofenig. May 2007. (Format: TXT=46635 bytes) (Status: INFORMATIONAL)
RFC 4919	IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals. N. Kushalnagar, G. Montenegro, C. Schumacher. August 2007. (Format: TXT=27650 bytes) (Status: INFORMATIONAL)
RFC 4941	Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves, S. Krishnan. September 2007. (Format: TXT=56699 bytes) (Obsoletes RFC3041) (Status: DRAFT STANDARD)
RFC 4942	IPv6 Transition/Co-existence Security Considerations. E. Davies, S. Krishnan, P. Savola. September 2007. (Format: TXT=102878 bytes) (Status: INFORMATIONAL)
RFC 4943	IPv6 Neighbor Discovery On-Link Assumption Considered Harmful. S. Roy, A. Durand, J. Paugh. September 2007. (Format: TXT=16719 bytes) (Status: INFORMATIONAL)
RFC 4944	Transmission of IPv6 Packets over IEEE 802.15.4 Networks. G. Montenegro, N. Kushalnagar, J. Hui, D. Culler. September 2007. (Format: TXT=67232 bytes) (Status: PROPOSED STANDARD)
RFC 4968	Analysis of IPv6 Link Models for 802.16 Based Networks. S. Madanapalli, Ed.. August 2007. (Format: TXT=34536 bytes) (Status: INFORMATIONAL)
RFC 5006	IPv6 Router Advertisement Option for DNS Configuration. J. Jeong, Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format: TXT=26136 bytes) (Status: EXPERIMENTAL)
RFC 5007	DHCPv6 Leasequery. J. Brzozowski, K. Kinnear, B. Volz, S. Zeng. September 2007. (Format: TXT=47186 bytes) (Status: PROPOSED STANDARD)
RFC 5014	IPv6 Socket API for Source Address Selection. E. Nordmark, S. Chakrabarti, J. Laganier. September 2007. (Format: TXT=53601 bytes) (Status: INFORMATIONAL)
RFC 5026	Mobile IPv6 Bootstrapping in Split Scenario. G. Giaretta, Ed., J. Kempf, V. Devarapalli, Ed.. October 2007. (Format: TXT=63138 bytes) (Status: PROPOSED STANDARD)
RFC 5072	IP Version 6 over PPP. S.Varada, Ed., D. Haskins, E. Allen. September 2007. (Format: TXT=33910 bytes) (Obsoletes RFC2472) (Status: DRAFT STANDARD)
RFC 5094	Mobile IPv6 Vendor Specific Option. V. Devarapalli, A. Patel, K. Leung. December 2007. (Format: TXT=11430 bytes) (Status: PROPOSED STANDARD)
RFC 5095	Deprecation of Type 0 Routing Headers in IPv6. J. Abley, P. Savola, G. Neville-Neil. December 2007. (Format: TXT=13423 bytes) (Updates RFC2460, RFC4294) (Status: PROPOSED STANDARD)
RFC 5096	Mobile IPv6 Experimental Messages. V. Devarapalli. December 2007. (Format: TXT=13669 bytes) (Status: PROPOSED STANDARD)
RFC 5121	Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks. B. Patil, F. Xia, B. Sarikaya, JH. Choi, S. Madanapalli. February 2008. (Format: TXT=50092 bytes) (Status: PROPOSED STANDARD)
RFC 5149	Service Selection for Mobile IPv6. J. Korhonen, U. Nilsson, V. Devarapalli. February 2008. (Format: TXT=18746 bytes) (Status: INFORMATIONAL)
RFC 5156	Special-Use IPv6 Addresses. M. Blanchet. April 2008. (Format: TXT=11931 bytes) (Status: INFORMATIONAL)
RFC 5157	IPv6 Implications for Network Scanning. T. Chown. March 2008. (Format: TXT=29054 bytes) (Status: INFORMATIONAL)
RFC 5158	6to4 Reverse DNS Delegation Specification. G. Huston. March 2008. (Format: TXT=25536 bytes) (Status: INFORMATIONAL)
RFC 5175	IPv6 Router Advertisement Flags Option. B. Haberman, Ed., R. Hinden. March 2008. (Format: TXT=12463 bytes) (Obsoletes RFC5075) (Status: PROPOSED STANDARD)
RFC 5180	IPv6 Benchmarking Methodology for Network Interconnect Devices. C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin. May 2008. (Format: TXT=41712 bytes) (Status: INFORMATIONAL)
RFC 5181	IPv6 Deployment Scenarios in 802.16 Networks. M-K. Shin, Ed., Y-H. Han, S-E. Kim, D. Premec. May 2008. (Format: TXT=36671 bytes) (Status: INFORMATIONAL)
RFC 5213	Proxy Mobile IPv6. S. Gundavelli, Ed., K. Leung, V. Devarapalli, K. Chowdhury, B. Patil. August 2008. (Format: TXT=226902 bytes) (Status: PROPOSED STANDARD)
RFC 5269	Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND). J. Kempf, R. Koodli. June 2008. (Format: TXT=32742 bytes) (Status: PROPOSED STANDARD)
RFC 5270	Mobile IPv6 Fast Handovers over IEEE 802.16e Networks. H. Jang, J. Jee, Y. Han, S. Park, J. Cha. June 2008. (Format: TXT=42358 bytes) (Status: INFORMATIONAL)
RFC 5271	Mobile IPv6 Fast Handovers for 3G CDMA Networks. H. Yokota, G. Dommety. June 2008. (Format: TXT=49316 bytes) (Status: INFORMATIONAL)
RFC 5375	IPv6 Unicast Address Assignment Considerations. G. Van de Velde, C. Popoviciu, T. Chown, O. Bonness, C. Hahn. December 2008. (Format: TXT=83809 bytes) (Status: INFORMATIONAL)
RFC 5380	Hierarchical Mobile IPv6 (HMIPv6) Mobility Management. H. Soliman, C. Castelluccia, K. ElMalki, L. Bellier. October 2008. (Format: TXT=58330 bytes) (Obsoletes RFC4140) (Status: PROPOSED STANDARD)
RFC 5419	Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6). B. Patil, G. Dommety. January 2009. (Format: TXT=45178 bytes) (Status: INFORMATIONAL)
RFC 5447	Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction. J. Korhonen, Ed., J. Bournelle, H. Tschofenig, C. Perkins, K. Chowdhury. February 2009. (Format: TXT=38656 bytes) (Status: PROPOSED STANDARD)
RFC 5453	Reserved IPv6 Interface Identifiers. S. Krishnan. February 2009. (Format: TXT=11754 bytes) (Status: PROPOSED STANDARD)
RFC 5534	Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming. J. Arkko, I. van Beijnum. June 2009. (Format: TXT=88152 bytes) (Status: PROPOSED STANDARD)
RFC 5555	Mobile IPv6 Support for Dual Stack Hosts and Routers. H. Soliman, Ed.. June 2009. (Format: TXT=92387 bytes) (Status: PROPOSED STANDARD)
RFC 5568	Mobile IPv6 Fast Handovers. R. Koodli, Ed.. July 2009. (Format: TXT=121373 bytes) (Obsoletes RFC5268) (Status: PROPOSED STANDARD)
RFC 5570	Common Architecture Label IPv6 Security Option (CALIPSO). M. StJohns, R. Atkinson, G. Thomas. July 2009. (Format: TXT=128032 bytes) (Status: INFORMATIONAL)
RFC 5637	Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6. G. Giaretta, I. Guardini, E. Demaria, J. Bournelle, R. Lopez. September 2009. (Format: TXT=23409 bytes) (Status: INFORMATIONAL)
RFC 5722	Handling of Overlapping IPv6 Fragments. S. Krishnan. December 2009. (Format: TXT=11838 bytes) (Updates RFC2460) (Status: PROPOSED STANDARD)

---

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.