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 of
Show full document text