Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite
RFC 7785
Document | Type |
RFC - Informational
(February 2016; No errata)
Was draft-vinapamula-softwire-dslite-prefix-binding (individual)
|
|
---|---|---|---|
Authors | Suresh Vinapamula , Mohamed Boucadair | ||
Last updated | 2016-02-16 | ||
Stream | ISE | ||
Formats | plain text html xml pdf htmlized bibtex | ||
Reviews | |||
IETF conflict review | conflict-review-vinapamula-softwire-dslite-prefix-binding | ||
Stream | ISE state | Published RFC | |
Consensus Boilerplate | Yes | ||
Document shepherd | Adrian Farrel | ||
Shepherd write-up | Show (last changed 2015-11-04) | ||
IESG | IESG state | RFC 7785 (Informational) | |
Action Holders |
(None)
|
||
Telechat date | |||
Responsible AD | Terry Manderson | ||
Send notices to | (None) | ||
IANA | IANA review state | IANA OK - No Actions Needed | |
IANA action state | No IANA Actions |
Independent Submission S. Vinapamula Request for Comments: 7785 Juniper Networks Category: Informational M. Boucadair ISSN: 2070-1721 Orange February 2016 Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite Abstract This document discusses issues induced by the change of the Dual- Stack Lite (DS-Lite) Basic Bridging BroadBand (B4) IPv6 address and sketches a set of recommendations to solve those issues. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7785. Copyright Notice 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Vinapamula & Boucadair Informational [Page 1] RFC 7785 Prefix Binding for DS-Lite February 2016 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 IPv6 deployment models assume IPv6 prefixes are delegated by Service Providers to the connected CPEs (Customer Premises Equipment) or hosts, which in turn derive IPv6 addresses from that prefix. In the case of Dual-Stack Lite (DS-Lite) [RFC6333], which is an IPv4 service continuity mechanism over an IPv6 network, the Basic Bridging BroadBand (B4) element derives an IPv6 address for the IPv4-in-IPv6 softwire setup purposes. The B4 element might obtain a new IPv6 address for a variety of reasons that include (but are not limited to) a reboot of the CPE, power outage, DHCPv6 lease expiry, or other actions undertaken by the Service Provider. If this occurs, traffic forwarded to a B4's previous IPv6 address may never reach its destination or may be delivered to another B4 that now uses the address formerly assigned to the original B4. This situation affects all mapping types, both implicit (e.g., by sending a TCP SYN) and explicit (e.g., using Port Control Protocol (PCP) [RFC6887]). The problem is further elaborated in Section 2. This document proposes recommendations to soften the impact of such renumbering issues (Section 4). 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]. Vinapamula & Boucadair Informational [Page 2] RFC 7785 Prefix Binding for DS-Lite February 2016 2. The Problem Since private IPv4 addresses assigned to hosts serviced by a B4 element overlap across multiple CPEs, the IPv6 address of a B4 element plays a key role in demultiplexing connections, enforcing policies, and in identifying associated resources assigned for each of the connections maintained by the Address Family Transition Router (AFTR) [RFC6333]. For example, these resources maintain state of Endpoint-Independent Mapping (EIM) as defined in Section 4.1 ofShow full document text