Viagenie

2600 boul. Laurier, suite 625 Quebec QC G1V 4W1 Canada Marc.Blanchet@viagenie.ca http://www.viagenie.ca

This document is a compilation of special IPv6 addresses defined in other RFCs. It can be used as a checklist of invalid routing prefixes for developing filtering policies for routes and IP packets. It does not discuss addresses that are assigned to operators and users through the Regional Internet Registries.

This document is a compilation of special IPv6 addresses defined in other RFCs. It can be used as a checklist of invalid routing prefixes for developing filtering policies for routes and IP packets. It does not discuss addresses that are assigned to operators and users through the Regional Internet Registries. The document is structured by address types. The document format is similar to . Some tips about filtering are given, but are not mandatory to implement. The addresses listed in this document must not be hard-coded into implementations.

::1/128 is the loopback address . ::/128 is the unspecified address . These two addresses should not appear on the public Internet.

::FFFF:0:0/96 are the IPv4-mapped addresses . Addresses within this block should not appear on the public Internet.

::<ipv4-address>/96 are the IPv4-compatible addresses . These addresses are deprecated and should not appear on the public Internet.

fe80::/10 are the link-local unicast addresses. Addresses within this block should not appear on the public Internet.

fc00::/7 are the unique-local addresses . Addresses within this block should not appear by default on the public Internet. Procedures for advertising these addresses are further described in .

The 2001:db8::/32 are the documentation addresses . They are used for documentation purposes such as user manuals, RFCs, etc. Addresses within this block should not appear on the public Internet.

2002::/16 are the 6to4 addresses . The 6to4 addresses may be advertised when the site is running a 6to4 relay or offering a 6to4 transit service. Running such a service [RFC3964] entails filtering rules specific to 6to4 . IPv4 addresses disallowed in 6to4 prefixes are listed in section 5.3.1 of .

2001::/32 are the Teredo addresses . The Teredo addresses may be advertised when the site is running a Teredo relay or offering a Teredo transit service.

5f00::/8 were the addresses of the first instance of the 6bone experimental network . 3ffe::/16 were the addresses of the second instance of the 6bone experimental network . Both 5f00::/8 and 3ffe::/16 were returned to IANA . These addresses are subject to future allocation, similar to current unallocated address space. Addresses within these blocks should not appear on the public Internet until they are reallocated.

2001:10::/28 are Overlay Routable Cryptographic Hash IDentifiers (ORCHID) addresses . These addresses are used as identifiers and are not routable at the IP layer. Addresses within this block should not appear on the public Internet.

::/0 is the default unicast route address.

An IANA registry (iana-ipv6-special-registry) exists for Special-Purpose IPv6 address block assignments for experiments and other purposes. Addresses within this registry should be reviewed for Internet routing considerations.

ff00::/8 are multicast addresses . They contain a 4-bit scope in the address field where only some values are of global scope . Only addresses with global scope in this block may appear on the public Internet. Multicast routes must not appear in unicast routing tables.

Filtering the invalid routing prefixes listed in this document should improve the security of networks.

To ensure consistency and to provide cross-referencing for the benefit of the community, IANA has inserted the following paragraph in the header of the iana-ipv6-special-registry. "Other special IPv6 addresses requiring specific considerations for global routing are listed in RFC 5156."

Florent Parent, Pekka Savola, Tim Chown, Alain Baudot, Stig Venaas, Vincent Jardin, Olaf Bonness, David Green, Gunter Van de Velde, Michael Barnes, Fred Baker, Edward Lewis, Marla Azinger, Brian Carpenter, Mark Smith, Kevin Loch, Alain Durand, Jim Bound, Peter Sherbin, Bob Hinden, Gert Doering, Niall O'Reilly, Mark Townsley, Jari Arkko, and Iain Calder have provided input and suggestions to this document.

This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t><t> This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS TRACK] Ipsilon Networks, Inc.

2191 E. Bayshore Road Suite 100 Palo Alto CA 94303 US +1 415 846 4604 +1 415 855 1414 hinden@ipsilon.com

University of Southern California, Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90292-6695 US +1 310 822 1511 +1 310 823 6714 postel@isi.edu

Nokia

232 Java Drive Sunnyvale CA 94089 USA +1 408 990-2004 hinden@iprg.nokia.com

Lawrence Berkeley National Laboratory

MS 50A-3111 Berkeley CA 94720 USA +1 510 486-5692 rlfink@lbl.gov

Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90292-6695 USA

Internet IP address internet protocol version 6 IPv6 This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. [STANDARDS TRACK] IANA The 6bone was established in 1996 by the IETF as an IPv6 Testbed network to enable various IPv6 testing as well as to assist in the transitioning of IPv6 into the Internet. It operates under the IPv6 address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its production deployment it is appropriate to plan for the phaseout of the 6bone. This document establishes a plan for a multi-year phaseout of the 6bone and its address allocation on the assumption that the IETF is the appropriate place to determine this. This document obsoletes RFC 2471, "IPv6 Testing Address Allocation", December, 1998. RFC 2471 will become historic. This memo provides information for the Internet community. To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation. This memo provides information for the Internet community. The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems. This memo provides information for the Internet community. This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS TRACK] We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays". The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4". [STANDARDS TRACK] This is a direction to IANA concerning the management of the IANA Special Purpose IPv6 address assignment registry. This memo provides information for the Internet community. This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.</t><t> This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2014, with continued use requiring IETF consensus. This memo defines an Experimental Protocol for the Internet community.