RFC 7785

Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite

📅 published February 2016, from ietf

Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite 🎀

okay so this is RFC 7785, and it's giving fix the B4 address problem before it breaks everything 💅 Here's the title block, bestie:

  • Stream: Independent Submission ✨ (not from an IETF working group)
  • Number and title: RFC 7785, "Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite"
  • Authors: S. Vinapamula (Juniper Networks) and M. Boucadair (Orange) 🫶
  • Category: Informational 🦋 (not a standards track spec, just vibes and advice)
  • ISSN: 2070-1721
  • Date: February 2016
  • Obsoletes and updates: the header doesn't list any RFCs that this one obsoletes or updates 🙈

Abstract ✨

This doc talks about the problems that show up when the Dual-Stack Lite (DS-Lite) Basic Bridging BroadBand (B4) IPv6 address changes, and it sketches some recommendations to fix them 🌸

Status of This Memo 📜

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

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor chose to publish this document at its discretion, and they make no statement about its value for implementation or deployment. Documents the RFC Editor approves for publication are not a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for that 💅

Info about the current status of this document, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc7785. Go check it out 🍓

Copyright (c) 2016 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 stand on the publication date. Please read these carefully, because they explain your rights and restrictions for this document 🫶

Table of Contents 📚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
2.  The Problem . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Introducing Subscriber-Mask . . . . . . . . . . . . . . . . .   4
4.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   5
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   6
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
  7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction ✨

okay so IPv6 deployment models assume that Service Providers hand out IPv6 prefixes to connected CPEs (Customer Premises Equipment) or hosts. Those devices then make their own IPv6 addresses from that prefix 🎀 Now with Dual-Stack Lite (DS-Lite) [RFC6333], which is basically how you keep IPv4 service going over an IPv6 network, the B4 element derives an IPv6 address so it can set up the IPv4-in-IPv6 softwire 🦋

Here's the tea. The B4 element might get a brand new IPv6 address for a bunch of reasons. That includes (but isn't limited to) a CPE reboot, a power outage, a DHCPv6 lease expiring, or something else the Service Provider decides to do 💀 When that happens, traffic sent to the B4's old IPv6 address might never reach its destination. Or worse, it gets delivered to some other B4 that now has the address the original one used to have 😭 This affects every mapping type. That includes implicit ones (like sending a TCP SYN) and explicit ones (like using Port Control Protocol (PCP) [RFC6887]). I'll go deeper on this in Section 2 🌸

This document puts forward recommendations to soften the impact of these renumbering issues (Section 4) 💖

Also, this document complements [RFC6908] 🧚

1.1. Requirements Language 💅

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. The Problem 🫠

Okay, so private IPv4 addresses assigned to hosts behind a B4 element overlap across multiple CPEs. That means the B4's IPv6 address plays a huge role in demultiplexing connections, enforcing policies, and identifying the resources that the Address Family Transition Router (AFTR) [RFC6333] assigns to each connection it maintains 🔥 For example, these resources keep track of Endpoint-Independent Mapping (EIM) state as defined in Section 4.1 of [RFC4787]. They also handle Endpoint-Independent Filtering (EIF) as defined in Section 5 of [RFC4787], keep the external IPv4 address assigned in the AFTR (the "IP address pooling" behavior from Section 4.1 of [RFC4787]), track PCP mappings, and more 💜

But here's the problem. The IPv6 address used by the B4 element can change for some reason. Maybe the CPE itself changed, or maybe privacy extensions are turned on for generating the IPv6 address (for example [RFC7217] or [RFC4941]) 👀 Whenever the B4's IPv6 address changes, the mappings created in the AFTR stop being valid. That can lead to a whole new set of mappings getting created in the AFTR 💀

It gets worse, bestie. A misbehaving user might be tempted to change the B4's IPv6 address so they can "grab" more ports and resources on the AFTR side 😤 That behavior can be seen as a potential denial-of-service (DoS) attack from misbehaving users. And this DoS attack can work no matter what port assignment policy the AFTR enforces, whether that's individual ports, port sets, randomized port bulks, or something else 🙈

Service Providers may want to enforce policies to limit how much AFTR resource each subscriber uses, for fairness (see REQ-4 of [RFC6888]) 🎀 These policies are used for dimensioning and also to make sure AFTR resources don't get exhausted. If the B4's IPv6 address can change, then tracking resources by that address gives incomplete results. Also, when the B4's IPv6 address changes, enforcing policies based on that address doesn't clean up stale mappings hanging around in the system. Those stale mappings eat system resources and also shrink the subscriber's available quota ⚠️ Clearing those mappings could be considered, but that would cause a lot of churn in the AFTR and could disrupt existing connections, which is not desirable 🥲

Even more concretely: if stale mappings haven't been migrated to the new B4's IPv6 address so packets can be forwarded to the right B4, then the AFTR will reject all incoming packets associated with those mappings. That isn't desirable, because it's bad for quality of experience 😭

Now let's talk about application servers hosted behind a B4 element. If the B4's IPv6 address changes and that changes the external IPv4 address and/or the external port number at the AFTR side, these servers have to advertise the change (see Section 1.1 of [RFC7393]) 📣 So some way to discover the change of the B4's IPv6 address, the external IPv4 address, and/or the external port is required. Latency issues are likely when an application server has to advertise its newly assigned external IPv4 address and port, and the application clients have to find that new address and/or port and re-initiate connections with the server 🐢

Here's the solution the document is going for. Instead of enforcing policies based on the B4's IPv6 address, enforce them based on the IPv6 prefix assigned to subscribers who have DS-Lite service. Section 3 introduces the subscriber-mask, which derives the IPv6 prefix assigned to a subscriber's CPE from the source IPv6 address of a packet received from a B4 element 🦋✨

3. Introducing Subscriber-Mask 🧚

The subscriber-mask is defined as an integer. It indicates the number of significant bits to apply to the source IPv6 address (internal side) so that a CPE can be uniquely identified 💖

The subscriber-mask is an AFTR system-wide configuration parameter. It's used to enforce generic per-subscriber policies. Applying these generic policies does not require configuring every subscriber's prefix. So much less work, bestie 🙌

Subscriber-mask must be configurable. The default value is 56. That default is motivated by current practices of assigning IPv6 prefix lengths of /56 to end-sites (for example [RIPE] and [LACNIC]) 🌸

Example time! 🎀

Say the prefix 2001:db8:100:100::/56 is assigned to a CPE that has DS-Lite enabled. Also say the address 2001:db8:100:100::1 is the IPv6 address used by the B4 element living in that CPE. When the AFTR gets a packet from this B4 element, meaning the source address of the IPv4-in-IPv6 packet is 2001:db8:100:100::1, the AFTR applies the subscriber-mask (for example 56) to the source IPv6 address. That computes the prefix for this B4 element, which is 2001:db8:100:100::/56. Then the AFTR enforces policies based on that prefix (2001:db8:100:100::/56), not on the exact source IPv6 address 🥹✨

4. Recommendations ✨

okay so to fix the problems from Section 2, here are the recs 🫶

  1. A policy SHOULD be enforced at the AFTR to limit the number of active DS-Lite softwires per subscriber. The default value MUST be 1.

this policy is giving "no sneaky extras" 🙅‍♀️. It stops a misbehaving subscriber from mounting a bunch of DS-Lite softwires, which would eat up extra AFTR resources (like extra external ports if the quota were enforced per softwire, or extra processing from a large number of active softwires) 💅

  1. Resource contexts created and maintained by the AFTR SHOULD be based on the delegated IPv6 prefix instead of the B4's IPv6 address. The AFTR derives the delegated prefix from the B4's IPv6 address by means of a configured subscriber-mask (Section 3). Administrators SHOULD configure per-prefix limits of resource usage, instead of per-tunnel limits. These resources include the maximum number of active flows, the maximum number of PCP-created mappings, NAT pool resources, etc.
  2. In the event a new IPv6 address is assigned to the B4 element, the AFTR SHOULD migrate existing state to be bound to the new IPv6 address. This operation ensures that traffic destined to the previous B4's IPv6 address will be redirected to the newer B4's IPv6 address. The destination IPv6 address for tunneling return traffic from the AFTR SHOULD be the last seen as the B4's IPv6 source address from the CPE.

this one is about avoiding stale mappings at the AFTR so subscribers don't get disrupted. it's giving continuity 🦋

The AFTR uses the subscriber-mask to determine whether two IPv6 addresses belong to the same CPE (e.g., if the subscriber-mask is set to 56, the AFTR concludes that 2001:db8:100:100::1 and 2001:db8:100:100::2 belong to the same CPE assigned with 2001:db8:100:100::/56).

As discussed in Section 5, changing the source B4's IPv6 address may be used as an attack vector. Packets with a new B4's IPv6 address from the same prefix SHOULD be rate-limited. It is RECOMMENDED to set this rate limit to 30 minutes; other values can be set on a per-deployment basis.

one side effect of migrating mapping state is that a server behind an AFTR doesn't need to update its DNS records (if any) with dynamic DNS, for example. If a dedicated mapping is instantiated, migrating the state during its validity lifetime ensures the server keeps the same external IP address and port 🎀

  1. In the event of change of the CPE WAN's IPv6 prefix, unsolicited PCP ANNOUNCE messages SHOULD be sent by the B4 element to internal hosts connected to the PCP-capable CPE so that they update their mappings accordingly.

this lets internal PCP clients update their mappings with the new B4's IPv6 address and trigger updates to rendezvous servers (e.g., dynamic DNS). A PCP-based dynamic DNS solution is specified in [RFC7393] 🌸

  1. When a new prefix is assigned to the CPE, stale mappings may exist in the AFTR. This will consume both implicit and explicit resources. In order to avoid such issues, stable IPv6 prefix assignment is RECOMMENDED.
  2. If for any reason an IPv6 prefix has to be reassigned, it is RECOMMENDED to reassign an IPv6 prefix (that was previously assigned to a given CPE) to another CPE only when all the resources in use associated with that prefix are cleared from the AFTR. Doing so avoids redirecting traffic, destined to the previous prefix owner, to the new one. the old owner's traffic stays with the old owner 🙈

5. Security Considerations 💀

security stuff related to DS-Lite is covered in [RFC6333], so go read that too 📚

okay but this part is seriously important 😭. Enforcing the recommendations in Section 4 together with rate-limiting softwires that have new source IPv6 addresses from the same prefix defends against DoS attacks where someone keeps changing the B4's IPv6 address to drain AFTR resources. A misbehaving CPE can be blacklisted by enforcing appropriate policies based on the prefix derived from the subscriber-mask 🚫

6. Privacy Considerations 🫣

a CPE on a DS-Lite network is identified by a bunch of info that's specific to each network domain (e.g., service credentials, device identifiers, etc.). This document doesn't make any assumptions or add new requirements on how that identification works network-wide 🧚

this document follows Sections 6 and 8 of [RFC6333] for handling IPv4-in-IPv6 packets and IPv4 translation operations. In particular, it does not leak extra information in packets leaving a DS-Lite network domain 🔐

the recommendations in Section 4 (item 6, in particular) make sure traffic gets forwarded to a legitimate CPE. If those recommendations aren't implemented, privacy concerns may arise. For example, if an IPv6 prefix is reassigned while mapping entries associated with that prefix are still active in the AFTR, sensitive data that belongs to a previous prefix owner may be disclosed to the new prefix owner. that would be a total nightmare 😱

these recommendations don't interfere with privacy extensions for generating IPv6 addresses (e.g., [RFC7217] or [RFC4941]). They let a CPE generate new IPv6 addresses with privacy extensions without experiencing DS-Lite service degradation. Even though privacy extensions make it harder to track a CPE over time compared to using a permanent Interface Identifier, tracking a CPE is still possible based on the first 64 bits of the IPv6 address. This is even more true for deployments relying on stable IPv6 prefixes 👀

this document doesn't cancel out the privacy effects that may motivate the use of non-stable IPv6 prefixes. Particularly, the subscriber-mask does not enable identifying a CPE across renumbering (even within a DS-Lite network domain). This document does help with some of the undesired effects of reassigning an IPv6 prefix to another CPE (e.g., updating a rendezvous service, clearing stale mappings) ✨

7. References 📖

7.1. Normative References

7.2. Informative References

Acknowledgments 🫶

G. Krishna, C. Jacquenet, I. Farrer, Y. Lee, Q. Sun, R. Weber, T. Taylor, D. Harkins, D. Gillmor, S. Sivakumar, A. Cooper, and B. Campbell provided useful comments. Many thanks to them 💜

Authors' Addresses 🎀

Suresh Vinapamula
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, CA  94089
United States

Phone: +1 408 936 5441
Email: sureshk@juniper.net
Mohamed Boucadair
Orange
Rennes  35000
France

Email: mohamed.boucadair@orange.com
📦 where this page comes from