Internet Engineering Task Force (IETF) C. Byrne
Request for Comments: 7335 T-Mobile US
Updates: 6333 August 2014
Category: Standards Track
ISSN: 2070-1721
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
IPv4服务连续性前缀
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.
RFC 6333中定义的双栈Lite（DS Lite）指示IANA为基本桥接宽带（B4）元素保留192.0.0.0/29。根据这份备忘录，IANA已将该保留推广到包括非路由IPv4接口必须作为IPv6转换解决方案的一部分进行编号的其他情况。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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
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".
DS Lite[RFC6333]指示IANA为基本桥接宽带（B4）元素保留192.0.0.0/29。此备忘录概括了IANA保留，以包括在IPv6转换解决方案中必须对非路由IPv4接口进行编号的其他情况。IANA列出了为IPv4服务连续性前缀保留的地址块192.0.0.0/29。其结果是，192.0.0.0/29可用于任何需要IPv4地址的系统，以在仅IPv6的网络中向后兼容IPv4通信，但不“在线”发射IPv4数据包。
This generalization does not impact the use of the IPv4 Service Continuity Prefix in a DS-Lite context.
此泛化不会影响在DS Lite上下文中使用IPv4服务连续性前缀。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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.
464XLAT[RFC6877]描述了通过仅IPv6接入网络提供IPv4通信的体系结构。[RFC6877]中描述的方法之一是将客户端翻译器（CLAT）嵌入主机中，例如智能手机或CPE（客户场所设备）。在这种情况下，主机必须配置IPv4地址，以呈现给主机网络堆栈，并让应用程序绑定IPv4套接字。
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.
为避免与可能与CLAT或其他IPv6转换解决方案通信的任何其他网络发生冲突，必须分配本地唯一的IPv4地址。
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.
IANA在[RFC6333]中定义了一个众所周知的范围192.0.0.0/29，专门用于DS Lite。如[RFC6333]中所定义，该子网仅存在于B4和地址族转换路由器（AFTR）之间，并且从不从该前缀“在线”发出数据包。464XLAT对非路由IPv4前缀的需求相同，对于其他类似的解决方案，这种需求可能很常见。将192.0.0.0/29推广到IPv6过渡技术中支持IPv4接口的使用，而不是为每个可能的解决方案保留前缀，这是最谨慎和有效的做法。
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.
有了这份备忘录，192.0.0.0/29现在在多个IPv4连续性解决方案（如464XLAT和DS Lite）中得到了推广。主机不能同时启用两个活动IPv4连续性解决方案，因为这样会导致节点具有重叠的192.0.0.0/29地址空间。
There are no new security considerations beyond what is described [RFC6333] and [RFC6877].
除[RFC6333]和[RFC6877]所述内容外，没有新的安全注意事项。
IANA has updated the IPv4 Special-Purpose Address Registry available at (http://www.iana.org/assignments/iana-ipv4-special-registry/) as follows:
IANA已更新IPv4专用地址注册表，该注册表位于(http://www.iana.org/assignments/iana-ipv4-special-registry/)详情如下:
OLD:
旧的：
192.0.0.0/29 DS-Lite [RFC6333]
192.0.0.0/29 DS Lite[RFC6333]
NEW:
新的：
192.0.0.0/29 IPv4 Service Continuity Prefix [RFC7335]
192.0.0.0/29 IPv4服务连续性前缀[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 |
+----------------------+-----------------------------------+
+----------------------+-----------------------------------+
| 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 |
+----------------------+-----------------------------------+
This document has been substantially improved by specific feedback from Dave Thaler, Fred Baker, Wes George, Lorenzo Colitti, and Mohamed Boucadair.
Dave Thaler、Fred Baker、Wes George、Lorenzo Coletti和Mohamed Boucadair的具体反馈大大改进了本文件。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 63332011年8月。
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013.
[RFC6877]Mawatari，M.，Kawashima，M.，和C.Byrne，“464XLAT：有状态和无状态翻译的组合”，RFC 6877，2013年4月。
Author's Address
作者地址
Cameron Byrne Bellevue, WA USA
Cameron Byrne Bellevue，美国华盛顿州
EMail: Cameron.Byrne@T-Mobile.com
EMail: Cameron.Byrne@T-Mobile.com