RFC 6540

Part 1 of 2 🎀

RFC 6540: IPv6 Support Required for All IP-Capable Nodes 💖

Okay so this one is a Best Current Practice (BCP 177) from April 2012, and it's giving "IPv6 is no longer optional, bestie." 💅 It was written by W. George (Time Warner Cable), C. Donley (CableLabs), C. Liljenstolpe (Big Switch Networks), and L. Howard (Time Warner Cable). It's published in the IETF Request for Comments series under ISSN 2070-1721. Its title block doesn't list any Obsoletes or Updates entries, so it's not replacing or changing anything else. 🦋

Abstract

Okay, the vibe here is that IPv4 addresses are running out globally, and the IPv4 extension and transition tech has limits too. So this doc says IPv6 support is no longer considered optional ✨. It also warns about spots in older IETF docs where the word "IP" gets used in a confusing way. "IP" has turned into a generic term that could mean IPv4 + IPv6, IPv6-only, or IPv4-only depending on context and application, so implementers could easily misread it 🙈.

Status of This Memo

This memo documents an Internet Best Current Practice. 🌸

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🫶. If you want more on BCPs, check Section 2 of RFC 5741.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6540 🧚.

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) as they were in effect on the publication date. Please actually read these, bestie, because they spell out your rights and restrictions for this document 📜. Code Components pulled out of 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
2. Clarifications and Recommendation ...............................3
3. Acknowledgements ................................................4
4. Security Considerations .........................................5
5. Informative References ..........................................5

1. Introduction ✨

Okay, so IP version 4 (IPv4) has been connecting public and private hosts all over the world for over 30 years 🌍. But the Internet got SO popular and creative with IP networking that billions of hosts are now connected and need unique addressing. 😭 That demand exhausted the IANA global pool of unique IPv4 addresses [IANA-EXHAUST], and the free pool for each Regional Internet Registry (RIR) is going to follow, with APNIC being the first one to go [APNIC-EXHAUST]. Transition technologies and other ways to stretch IPv4 do exist, but nearly all of them come with trade-offs, so they're not optimal long-term compared to deploying IP version 6 (IPv6) for continued growth 💅. For some discussion on this, see [RFC6269] and [NAT444-IMPACTS].

IPv6 [RFC1883] was proposed back in 1995 as, among other things, a fix for the limited globally unique addressing that IPv4's 32-bit address space came with 🦋. It's been continuously refined (for example, [RFC2460]) and deployed ever since. IPv4 running out plus the Internet's continued growth worldwide is basically what created the driver for widespread IPv6 deployment 🚀.

But the IPv6 deployment we need to reduce our reliance on IPv4 has been held back by a lack of ubiquitous hardware and software support across the industry 😩. Lots of vendors, especially in the consumer space, have kept treating IPv6 support as optional. Even now they're still selling "IP-capable" or "Internet-Capable" devices that aren't IPv6-capable 💀, which keeps pushing back the point where the natural hardware refresh cycle will meaningfully boost IPv6 support in the average home or enterprise network. They're also choosing not to update existing software to turn on IPv6 for devices that can be updated in software 🙃. That's a real problem, because it's not realistic to expect the hardware refresh cycle to single-handedly clear IPv4-only devices off the active network in a reasonable amount of time. This is a big deal, especially in the consumer space, where the network operator often has zero control over which hardware the consumer picks 🫠.

Here's the thing: the average consumer isn't choosing their Internet-capable devices and services based on whether they have IPv6 support, so they're unlikely to replace still-functional devices just to add IPv6 🛍️. They don't know or don't care about IPv6. They just want their devices to work as advertised 🍓.

This lack of support is making the eventual IPv6 transition way harder 😤. It also drives the need for expensive and complicated transition technologies that stretch out the life of IPv4-only devices and eventually let IPv4-only and IPv6-only hosts interwork. IPv4 is expected to coexist with IPv6 on the Internet for many years, but a shift from IPv4 as the dominant Internet Protocol version to IPv6 as the dominant one will need to happen. The sooner most devices support IPv6, the less drawn-out that transition period will be ⭐.

---

More of this slay is coming in Part 2! 🌈

Authors' Addresses 💌

okay bestie, these are the four people who wrote this doc, and their contact info is right here 🫶 I'm keeping every detail exactly as it was, so you can actually reach them.

Wesley George, from Time Warner Cable 🎀

   Wesley George
   Time Warner Cable
   13820 Sunrise Valley Drive
   Herndon, VA  20171
   US

   Phone: +1 703-561-2540
   EMail: wesley.george@twcable.com

Chris Donley, from CableLabs 🌸

   Chris Donley
   CableLabs
   858 Coal Creek Circle
   Louisville, CO  80027
   US

   Phone: +1-303-661-9100
   EMail: C.Donley@cablelabs.com

Christopher Liljenstolpe, from Big Switch Networks 🦋

   Christopher Liljenstolpe
   Big Switch Networks
   430 Cowper St.
   Palo Alto, CA  94301
   US

   EMail: cdl@asgaard.org

Lee Howard, from Time Warner Cable again 🧚

   Lee Howard
   Time Warner Cable
   13820 Sunrise Valley Drive
   Herndon, VA  20171
   US

   Phone: +1-703-345-3513
   EMail: lee.howard@twcable.com

That's the whole crew, periodt 💅✨