RFC 2644

Status of This Memo 📜

okay so this is a Best Current Practice (BCP 34 🌸), and the Status of This Memo says it's for the Internet Community and it wants discussion and suggestions for improvements 💬 Distribution is unlimited, so share away 🦋

Copyright Notice

Copyright (C) The Internet Society (1999). All Rights Reserved. 💜

Changing the Default for Directed Broadcasts in Routers 🎀

Here's the title block, bestie: it's RFC 2644 🌈 by D. Senie of Amaranth Networks Inc., dated August 1999 ✨ The category is Best Current Practice, and it updates RFC 1812 (that's the Router Requirements doc, aka [1] 🧚). The header doesn't list anything it obsoletes.

1. Introduction 💖

okay so the Router Requirements [1] say routers must receive and forward directed broadcasts 👀 It also says routers MUST have an option to disable this feature, and that this option MUST default to permitting the receiving and forwarding of directed broadcasts. Directed broadcasts do have uses, but on the Internet backbone they seem to be made up entirely of malicious attacks on other networks 💀

Changing the required default for routers would help make sure that new routers connected to the Internet don't add to the problems that already exist 🫶

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 RFC 2119 🔥

2. Discussion 🌸

Damaging denial of service attacks led to the writing of [2] on Ingress Filtering 😭 Lots of network providers and corporate networks have endorsed these methods so their networks don't become the source of these attacks 💅

A recent trend in Smurf Attacks [3] is targeting networks that allow directed broadcasts from outside their networks 🙈 When they permit that, those systems become "Smurf Amplifiers." Continuing to implement ingress filters is still the best way to limit these attacks, but restricting directed broadcasts should get priority too ✨

Network service providers and corporate network operators are urged to make sure their networks aren't vulnerable to directed broadcast packets coming from outside their networks 🦋

Mobile IP [4] had provisions for using directed broadcasts in a mobile node's dynamic agent discovery 🧚 Some implementations support this, but it's unclear whether it's actually useful 🤔 Other methods for getting the same result are documented in [5]. It may be worthwhile to consider removing the language about using directed broadcasts as Mobile IP moves along the standards track 🌈

3. Recommendation 👑

Router Requirements [1] is updated as follows:

Section 4.2.2.11 (d) is replaced with the following 💅

(d) { <Network-prefix>, -1 } Directed Broadcast: a broadcast directed to the specified network prefix. It MUST NOT be used as a source address. A router MAY originate Network Directed Broadcast packets. A router MAY have a configuration option to allow it to receive directed broadcast packets. However, this option MUST be disabled by default, so the router MUST NOT receive Network Directed Broadcast packets unless the end user specifically configures it to 🎀

Section 5.3.5.2, second paragraph, gets replaced with this 🦋

A router MAY have an option to enable receiving network-prefix-directed broadcasts on an interface, and MAY have an option to enable forwarding network-prefix-directed broadcasts. These options MUST default to blocking receipt and blocking forwarding of network-prefix-directed broadcasts. 🙅‍♀️

4. Security Considerations 😭

The goal of this document is to reduce how well certain types of denial of service attacks work 🛡️ Please take this seriously, bestie, because these attacks can really hurt people's networks 💀

5. References 📚

[1] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. 🧚

[2] Ferguson, P. and D. Senie, "Ingress Filtering", RFC 2267, January 1998. 🌸

[3] See the pages by Craig Huegen at http://www.quadrunner.com/~chuegen/smurf.txt, and the CERT advisory at http://www.cert.org/advisories/CA-98.01.smurf.html 🔗

[4] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. 🦋

[5] P. Calhoun, C. Perkins, "Mobile IP Dynamic Home Address Allocation Extensions", Work in Progress. 🚧

6. Acknowledgments 🫶

The author would like to thank Brandon Ross of Mindspring and Gabriel Montenegro of Sun for their input 💖

7. Author's Address 🏡

Daniel Senie
Amaranth Networks Inc.
324 Still River Road
Bolton, MA 01740

Phone: (978) 779-6813
EMail: dts@senie.com

8. Full Copyright Statement 🌈

Copyright (C) The Internet Society (1999). All Rights Reserved. 💜

Okay so the gist: this document and translations of it may be copied and furnished to others, and derivative works that comment on or explain it, or help with its implementation, may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind 🎉 The only catch is that the above copyright notice and this paragraph have to be included on all those copies and derivative works 📋

However, this document itself may not be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations 🙅‍♀️ The exceptions are when it's needed for developing Internet standards (in which case the copyright procedures in the Internet Standards process must be followed) or when it's translated into languages other than English 🌍

The limited permissions above are perpetual, and the Internet Society or its successors or assigns won't revoke them ♾️

Now the legal disclaimer, verbatim because it's serious business 🧾

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society 🫶