RFC 6666

RFC 6666 💖 A Discard Prefix for IPv6

Okay bestie, this one is by Nick Hilliard (INEX) and David Freedman (Claranet) 🧚. It's an Informational doc (category), ISSN 2070-1721, published August 2012 🍓. It updates the "IPv6 Special Purpose Address Registry" ✨.

Abstract ✨

Remote triggered black hole filtering is a way to fight denial-of-service attacks by selectively dropping traffic based on source or destination address 🛡️. Remote triggered black hole routing is similar, but it reroutes traffic into a sinkhole router so it can be analyzed, again based on destination address 🕳️. This document updates the "IPv6 Special Purpose Address Registry" 🎀. It explains why IANA should formally assign a unique IPv6 prefix for IPv6 remote triggered black hole filtering and routing 💅.

Status of This Memo 🌸

This document is not an Internet Standards Track specification. It's published for informational purposes 📚.

This document is a product of the Internet Engineering Task Force (IETF) 🫶. It reflects the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 🔥. Not every IESG-approved document is a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for that 👑.

Info about the current status, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc6666 🦋.

Copyright Notice 🌈

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Please review those documents carefully, because they describe your rights and restrictions for this document. Code components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 📜.

Table of Contents 🗺️

1. Introduction ....................................................2
   1.1. Notational Conventions .....................................3
2. A Discard Prefix for IPv6 .......................................3
3. Operational Implications ........................................4
4. IANA Considerations .............................................4
5. Security Considerations .........................................4
6. References ......................................................5
   6.1. Normative References .......................................5
   6.2. Informative References .....................................5

1. Introduction 🎀

Okay so, Remote Triggered Black Hole (RTBH) filtering is a whole class of methods for blocking IP traffic either from a specific source ([RFC5635]) or to a specific destination ([RFC3882]) on a network 🚫. RTBH routing is the matching class for re-routing IP traffic headed to the attacked or targeted host onto a special path (a tunnel) 🚇, where a sniffer can capture the traffic for analysis 🔍.

Both of these methods work by setting the next-hop address of an IP packet with a specified source or destination address to be a unicast prefix. That prefix is connected locally or remotely to a router's discard, null, or tunnel interface 💜. Usually, reachability info for this prefix gets propagated across an autonomous system using a dynamic routing protocol such as BGP ([RFC3882]) 🛤️. Deploy RTBH systems across a network and traffic to or from specific destinations can be selectively black-holed or re-routed to a sinkhole device. It's efficient, scalable, and straightforward to set up ✨.

Some networks set up RTBH using [RFC1918] address space, or the address blocks reserved for documentation in [RFC5737]. That's inadequate, bestie 🙈. RTBH configs aren't documentation. They're operationally important features of many public-facing production networks 🏭. On top of that, [RFC3849] specifies that the IPv6 documentation prefix should be filtered in both local and public contexts. So the idea here is that both private network address blocks and the documentation prefixes described in [RFC5737] are inappropriate for RTBH configurations, and a dedicated IPv6 prefix should be assigned instead 💅.

This document updates the "IPv6 Special Purpose Address Registry" [IANA-IPV6REG] 🦋.

1.1. Notational Conventions 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀.

2. A Discard Prefix for IPv6 🧚

Okay, so to set up an IPv6 RTBH configuration, a unicast address block is required 💖. Right now there are no IPv6 unicast address blocks specifically nominated for implementing RTBH systems 🥺.

Sure, someone could argue that other addresses and prefixes could work, like documentation prefixes or private address space. Or an operator could take a block from their own address space 🤷‍♀️. But there's currently no operational clarity on which block would be appropriate or inappropriate for this 🌫️. By assigning a globally unique discard prefix for IPv6, the IETF will introduce good practice for implementing IPv6 RTBH configurations 🌟. It also gives operators clarity, because they can apply consistent and deterministic inter-domain prefix and traffic filtering policies to black-holed traffic 🍯.

[RFC3882] and [RFC5635] describe situations where more than one discard address may be used for multiple RTBH scenarios. So one single address isn't enough to cover all the likely RTBH situations 😤. That's why an address block is required 🫶.

3. Operational Implications 🌷

This assignment MAY be carried in a dynamic routing protocol within an autonomous system 🛰️. The assignment SHOULD NOT be announced to or accepted from third-party autonomous systems 🚧. IPv6 traffic with a destination address in this prefix SHOULD NOT be forwarded to or accepted from third-party autonomous systems 🚧. If the prefix, or a subnet of it, gets inadvertently announced to or accepted from a third-party autonomous system, it can cause excessive volumes of traffic to pass unintentionally between the two networks 📈. That would aggravate the effect of a denial-of-service attack 💀.

On networks that implement IPv6 remote triggered black holes, some or all of this network block MAY be configured with a next-hop destination of a discard or null interface on any or all IPv6 routers within the autonomous system 🧩.

4. IANA Considerations 🏷️

Per this document, IANA has recorded the allocation of the IPv6 address prefix 0100::/64 as a Discard-Only Prefix in the "Internet Protocol Version 6 Address Space" 🗂️. It also added the prefix to the "IANA IPv6 Special Purpose Address Registry" [IANA-IPV6REG] ✨. No end party has been assigned to this prefix 🙌. The prefix was allocated from ::/3 🍰.

5. Security Considerations 🔐

⚠️ Serious security business, bestie. The prefix in this document ought not normally be transmitted or accepted over inter-domain BGP sessions, for the reasons described in Section 3 🚨.

So it's usually appropriate to include this prefix in inter-domain BGP prefix filters [RFC3704], or otherwise make sure the prefix is neither transmitted to nor accepted from a third-party autonomous system 🛡️🔥.

6. References 📚

6.1. Normative References 💜

• [IANA-IPV6REG] Internet Assigned Numbers Authority, "IPv6 Special Purpose Address Registry", 2012, <http://www.iana.org/assignments/iana-ipv6-special-registry>.
• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, September 2004.
• [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", RFC 5635, August 2009.

6.2. Informative References 🧁

• [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
• [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
• [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004.
• [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010.

Authors' Addresses 🧳

Nick Hilliard
INEX
4027 Kingswood Road
Dublin  24
IE

EMail: nick@inex.ie


David Freedman
Claranet
21 Southampton Row, Holborn
London  WC1B 5HA
UK

EMail: david.freedman@uk.clara.net