summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7335.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7335.txt')
-rw-r--r--doc/rfc/rfc7335.txt227
1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc7335.txt b/doc/rfc/rfc7335.txt
new file mode 100644
index 0000000..a43caf1
--- /dev/null
+++ b/doc/rfc/rfc7335.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) C. Byrne
+Request for Comments: 7335 T-Mobile US
+Updates: 6333 August 2014
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ IPv4 Service Continuity Prefix
+
+Abstract
+
+ Dual-Stack Lite (DS-Lite), defined in RFC 6333, directs IANA to
+ reserve 192.0.0.0/29 for the Basic Bridging BroadBand (B4) element.
+ Per this memo, IANA has generalized that reservation to include other
+ cases where a non-routed IPv4 interface must be numbered as part of
+ an IPv6 transition solution.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in 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/rfc7335.
+
+Copyright Notice
+
+ Copyright (c) 2014 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. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+Byrne Standards Track [Page 1]
+
+RFC 7335 IPv4 Service Continuity Prefix August 2014
+
+
+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] directs IANA to reserve 192.0.0.0/29 for the Basic
+ Bridging BroadBand (B4) element. This memo generalizes that IANA
+ reservation to include 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 reserved for IPv4 Service Continuity
+ Prefix. The result is that 192.0.0.0/29 may be used in any system
+ that requires IPv4 addresses for backward compatibility with IPv4
+ communications in an IPv6-only network but does not emit IPv4 packets
+ "on the wire".
+
+ This generalization does not impact the use of the IPv4 Service
+ Continuity Prefix 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] describes an architecture for providing IPv4
+ communication over an IPv6-only access network. One of the methods
+ described in [RFC6877] is for the customer-side translator (CLAT) to
+ be embedded in the host, such as a smartphone or a CPE (Customer
+ Premises Equipment). In such scenarios, the host must have an IPv4
+ address configured to present to the host network stack and for
+ applications to bind IPv4 sockets.
+
+
+
+
+
+
+
+
+
+
+Byrne Standards Track [Page 2]
+
+RFC 7335 IPv4 Service Continuity Prefix August 2014
+
+
+4. Choosing 192.0.0.0/29
+
+ To avoid conflicts with any other network that may communicate with
+ the CLAT or 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],
+ which is dedicated for DS-Lite. As defined in [RFC6333], this subnet
+ is only present between the B4 and the Address Family Transition
+ Router (AFTR) and never emits packets from this prefix "on the wire".
+ 464XLAT has the same need for a non-routed IPv4 prefix, and this same
+ need may be common for other similar solutions. It is most prudent
+ and effective to generalize 192.0.0.0/29 for the use of supporting
+ IPv4 interfaces in IPv6 transition technologies rather than reserving
+ a prefix for every possible solution.
+
+ With this memo, 192.0.0.0/29 is now generalized across multiple IPv4
+ continuity solutions such as 464XLAT and DS-Lite. A host MUST NOT
+ enable two active IPv4 continuity solutions simultaneously in a way
+ that would cause a node to have overlapping 192.0.0.0/29 address
+ space.
+
+5. Security Considerations
+
+ There are no new security considerations beyond what is described
+ [RFC6333] and [RFC6877].
+
+6. IANA Considerations
+
+ IANA has updated the IPv4 Special-Purpose Address Registry available
+ at (http://www.iana.org/assignments/iana-ipv4-special-registry/) as
+ follows:
+
+ OLD:
+
+ 192.0.0.0/29 DS-Lite [RFC6333]
+
+ NEW:
+
+ 192.0.0.0/29 IPv4 Service Continuity Prefix [RFC7335]
+
+
+
+
+
+
+
+
+
+
+
+Byrne Standards Track [Page 3]
+
+RFC 7335 IPv4 Service Continuity Prefix August 2014
+
+
+ +----------------------+-----------------------------------+
+ | 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 document has been substantially improved by 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
+
+
+
+
+
+
+
+
+
+
+Byrne Standards Track [Page 4]
+