RFC 7335

IPv4 Service Continuity Prefix

📅 published August 2014, from ietf

🎀 RFC 7335: IPv4 Service Continuity Prefix 🎀

Okay bestie, this one is a Standards Track doc from August 2014 💅 It was written by C. Byrne from T-Mobile US, and it updates RFC 6333 (DS-Lite) ✨ It's listed under ISSN 2070-1721 too 🧚

Abstract

Okay so DS-Lite, which is RFC 6333, has IANA reserve 192.0.0.0/29 for the Basic Bridging BroadBand (B4) element 🦋 This memo basically takes that reservation and makes it bigger, so it covers any other situation where a non-routed IPv4 interface needs a number as part of an IPv6 transition solution 💖

Status of This Memo

This is an Internet Standards Track document 🌸

It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741 📚

Info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7335 🔥

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please read these carefully, because they spell out your rights and restrictions. Code Components pulled 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
2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  2
3.  The Case of 464XLAT  . . . . . . . . . . . . . . . . . . . . .  2
4.  Choosing 192.0.0.0/29  . . . . . . . . . . . . . . . . . . . .  3
5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  3
6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  3
7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  4
8.  Normative References . . . . . . . . . . . . . . . . . . . . .  4

1. Introduction ✨

DS-Lite [RFC6333] tells IANA to reserve 192.0.0.0/29 for the Basic Bridging BroadBand (B4) element 🍓 This memo generalizes that IANA reservation so it covers other cases where a non-routed IPv4 interface must be numbered in an IPv6 transition solution. IANA has listed the address block 192.0.0.0/29 as reserved for IPv4 Service Continuity Prefix 🦋 So now 192.0.0.0/29 may be used in any system that needs IPv4 addresses for backward compatibility with IPv4 communications in an IPv6-only network, as long as it does not emit IPv4 packets "on the wire" 💅

This generalization does not change how the IPv4 Service Continuity Prefix works in a DS-Lite context 🫶

2. 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] 💖

3. The Case of 464XLAT 🌈

464XLAT [RFC6877] is an architecture for giving you IPv4 communication over an IPv6-only access network 🧚 One of the methods [RFC6877] describes is embedding the customer-side translator (CLAT) in the host, like a smartphone or a CPE (Customer Premises Equipment). In that setup, the host must have an IPv4 address configured to present to the host network stack, and applications need one to bind IPv4 sockets 👑

4. Choosing 192.0.0.0/29 💜

To avoid conflicts with any other network that may talk to the CLAT or some other IPv6 transition solution, a locally unique IPv4 address must be assigned 🙈

IANA has defined a well-known range, 192.0.0.0/29, in [RFC6333], and it's dedicated to DS-Lite. As [RFC6333] defines it, this subnet only exists between the B4 and the Address Family Transition Router (AFTR), and it never emits packets from this prefix "on the wire" 🌸 464XLAT has the same need for a non-routed IPv4 prefix, and other similar solutions probably have it too. It's most prudent and effective to generalize 192.0.0.0/29 for supporting IPv4 interfaces in IPv6 transition technologies, rather than reserving a new prefix for every possible solution 🔥

With this memo, 192.0.0.0/29 is now generalized across multiple IPv4 continuity solutions, like 464XLAT and DS-Lite. A host MUST NOT enable two active IPv4 continuity solutions at the same time in a way that would give a node overlapping 192.0.0.0/29 address space. Overlap is a whole no-go 🚫💅

5. Security Considerations 🔐

There are no new security considerations beyond what is described in [RFC6333] and [RFC6877] 😭

6. IANA Considerations 🧚

IANA has updated the IPv4 Special-Purpose Address Registry, which lives at http://www.iana.org/assignments/iana-ipv4-special-registry/, like this:

OLD:

192.0.0.0/29    DS-Lite         [RFC6333]

NEW:

192.0.0.0/29    IPv4 Service Continuity Prefix  [RFC7335]

   +----------------------+-----------------------------------+
   | Attribute            | Value                             |
   +----------------------+-----------------------------------+
   | Address Block        | 192.0.0.0/29                      |
   | Name                 | IPv4 Service Continuity Prefix    |
   | RFC                  | RFC 7335                          |
   | Allocation Date      | June 2011                         |
   | Termination Date     | N/A                               |
   | Source               | True                              |
   | Destination          | True                              |
   | Forwardable          | True                              |
   | Global               | False                             |
   | Reserved-by-Protocol | False                             |
   +----------------------+-----------------------------------+

7. Acknowledgements 🫶

This doc got a huge glow-up from specific feedback from Dave Thaler, Fred Baker, Wes George, Lorenzo Colitti, and Mohamed Boucadair 💖✨

8. Normative References 📚

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
           Stack Lite Broadband Deployments Following IPv4
           Exhaustion", RFC 6333, August 2011.

[RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
           Combination of Stateful and Stateless Translation", RFC
           6877, April 2013.

Author's Address 🦋

Cameron Byrne Bellevue, WA USA

EMail: Cameron.Byrne@T-Mobile.com

📦 where this page comes from