Independent Submission B. Carpenter
Request for Comments: 6214 Univ. of Auckland
Category: Informational R. Hinden
ISSN: 2070-1721 Check Point Software
1 April 2011
Independent Submission B. Carpenter
Request for Comments: 6214 Univ. of Auckland
Category: Informational R. Hinden
ISSN: 2070-1721 Check Point Software
1 April 2011
Adaptation of RFC 1149 for IPv6
RFC 1149对IPv6的适应性
Abstract
摘要
This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149.
本文档规定了在RFC 1149中为IPv4数据报指定的相同介质上传输IPv6数据报的方法。
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.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc6214.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6214.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 2
3. Detailed Specification . . . . . . . . . . . . . . . . . . . . 2
3.1. Maximum Transmission Unit . . . . . . . . . . . . . . . . . 2
3.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Address Configuration . . . . . . . . . . . . . . . . . . . 3
3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Quality-of-Service Considerations . . . . . . . . . . . . . . . 4
5. Routing and Tunneling Considerations . . . . . . . . . . . . . 4
6. Multihoming Considerations . . . . . . . . . . . . . . . . . . 5
7. Internationalization Considerations . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 2
3. Detailed Specification . . . . . . . . . . . . . . . . . . . . 2
3.1. Maximum Transmission Unit . . . . . . . . . . . . . . . . . 2
3.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Address Configuration . . . . . . . . . . . . . . . . . . . 3
3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Quality-of-Service Considerations . . . . . . . . . . . . . . . 4
5. Routing and Tunneling Considerations . . . . . . . . . . . . . 4
6. Multihoming Considerations . . . . . . . . . . . . . . . . . . 5
7. Internationalization Considerations . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . . 6
As shown by [RFC6036], many service providers are actively planning to deploy IPv6 to alleviate the imminent shortage of IPv4 addresses. This will affect all service providers who have implemented [RFC1149]. It is therefore necessary, indeed urgent, to specify a method of transmitting IPv6 datagrams [RFC2460] over the RFC 1149 medium, rather than obliging those service providers to migrate to a different medium. This document offers such a specification.
如[RFC6036]所示，许多服务提供商正积极计划部署IPv6，以缓解IPv4地址即将短缺的问题。这将影响所有已实施[RFC1149]的服务提供商。因此，确实迫切需要指定通过RFC 1149介质传输IPv6数据报[RFC2460]的方法，而不是强制这些服务提供商迁移到不同的介质。本文件提供了此类规范。
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]中所述进行解释。
Unless otherwise stated, the provisions of [RFC1149] and [RFC2460] apply throughout.
除非另有说明，[RFC1149]和[RFC2460]的规定始终适用。
As noted in RFC 1149, the MTU is variable, and generally increases with increased carrier age. Since the minimum link MTU allowed by RFC 2460 is 1280 octets, this means that older carriers MUST be used for IPv6. RFC 1149 does not provide exact conversion factors between age and milligrams, or between milligrams and octets. These
如RFC 1149中所述，MTU是可变的，通常随着携带者年龄的增加而增加。由于RFC2460允许的最小链路MTU为1280个八位字节，这意味着IPv6必须使用较旧的载波。RFC1149没有提供年龄和毫克之间，或毫克和八位字节之间的精确转换系数。这些
conversion factors are implementation dependent, but as an illustrative example, we assume that the 256 milligram MTU suggested in RFC 1149 corresponds to an MTU of 576 octets. In that case, the typical MTU for the present specification will be at least 256*1280/576, which is approximately 569 milligrams. Again as an illustrative example, this is likely to require a carrier age of at least 365 days.
转换因子取决于实现，但作为示例，我们假设RFC 1149中建议的256毫克MTU对应于576个八位字节的MTU。在这种情况下，本规范的典型MTU将至少为256*1280/576，约为569毫克。再次作为一个说明性示例，这可能需要至少365天的承运人年龄。
Furthermore, the MTU issues are non-linear with carrier age. That is, a young carrier can only carry small payloads, an adult carrier can carry jumbograms [RFC2675], and an elderly carrier can again carry only smaller payloads. There is also an effect on transit time depending on carrier age, affecting bandwidth-delay product and hence the performance of TCP.
此外，MTU问题与承运人年龄呈非线性关系。也就是说，年轻的航母只能携带小的有效载荷，成年航母可以携带巨型航母[RFC2675]，而老年航母也只能携带较小的有效载荷。传输时间也会受到载波年龄的影响，影响带宽延迟积，从而影响TCP的性能。
RFC 1149 does not specify the use of any link layer tag such as an Ethertype or, worse, an OSI Link Layer or SNAP header [RFC1042]. Indeed, header snaps are known to worsen the quality of service provided by RFC 1149 carriers. In the interests of efficiency and to avoid excessive energy consumption while packets are in flight through the network, no such link layer tag is required for IPv6 packets either. The frame format is therefore a pure IPv6 packet as defined in [RFC2460], encoded and decoded as defined in [RFC1149].
RFC 1149未指定任何链路层标记的使用，如Ethertype或更糟糕的OSI链路层或快照头[RFC1042]。事实上，众所周知，报头快照会恶化RFC 1149运营商提供的服务质量。为了提高效率并避免数据包在网络中传输时过度消耗能量，IPv6数据包也不需要这样的链路层标签。因此，帧格式是[RFC2460]中定义的纯IPv6数据包，按照[RFC1149]中的定义进行编码和解码。
One important consequence of this is that in a dual-stack deployment [RFC4213], the receiver MUST inspect the IP protocol version number in the first four bits of every packet, as the only means to demultiplex a mixture of IPv4 and IPv6 packets.
这样做的一个重要结果是，在双栈部署[RFC4213]中，接收器必须检查每个数据包的前四位中的IP协议版本号，这是对IPv4和IPv6数据包混合进行解复用的唯一方法。
The lack of any form of link layer protocol means that link-local addresses cannot be formed, as there is no way to address anything except the other end of the link.
缺乏任何形式的链路层协议意味着无法形成链路本地地址，因为除了链路的另一端之外，没有其他地址。
Similarly, there is no method to map an IPv6 unicast address to a link layer address, since there is no link layer address in the first place. IPv6 Neighbor Discovery [RFC4861] is therefore impossible.
类似地，没有将IPv6单播地址映射到链路层地址的方法，因为首先没有链路层地址。因此，IPv6邻居发现[RFC4861]是不可能的。
Implementations SHOULD NOT even try to use stateless address auto-configuration [RFC4862]. This recommendation is because this mechanism requires a stable interface identifier formed in a way compatible with [RFC4291]. Unfortunately the transmission elements specified by RFC 1149 are not generally stable enough for this and may become highly unstable in the presence of a cross-wind.
实现甚至不应该尝试使用无状态地址自动配置[RFC4862]。此建议是因为此机制需要以与[RFC4291]兼容的方式形成稳定的接口标识符。不幸的是，RFC 1149规定的传动元件通常不够稳定，在侧风存在时可能变得高度不稳定。
In most deployments, either the end points of the link remain unnumbered, or a /127 prefix and static addresses MAY be assigned. See [IPv6-PREFIXLEN] for further discussion.
在大多数部署中，要么链路的端点保持不编号，要么可以分配/127前缀和静态地址。有关进一步的讨论，请参阅[IPv6 PREFIXLEN]。
RFC 1149 does not specify a multicast address mapping. It has been reported that attempts to implement IPv4 multicast delivery have resulted in excessive noise in transmission elements, with subsequent drops of packet digests. At the present time, an IPv6 multicast mapping has not been specified, to avoid such problems.
RFC 1149未指定多播地址映射。据报道，尝试实现IPv4多播传输导致传输元素中的噪声过大，随后数据包摘要下降。目前，尚未指定IPv6多播映射以避免此类问题。
[RFC2549] is also applicable in the IPv6 case. However, the author of RFC 2549 did not take account of the availability of the Differentiated Services model [RFC2474]. IPv6 packets carrying a non-default Differentiated Services Code Point (DSCP) value in their Traffic Class field [RFC2460] MUST be specially encoded using green or blue ink such that the DSCP is externally visible. Note that red ink MUST NOT be used to avoid confusion with the usage of red paint specified in RFC 2549.
[RFC2549]也适用于IPv6情况。然而，RFC2549的作者没有考虑到差异化服务模型[RFC2474]的可用性。在其流量类别字段[RFC2460]中携带非默认区分服务代码点（DSCP）值的IPv6数据包必须使用绿色或蓝色墨水进行特殊编码，以便DSCP在外部可见。请注意，不得使用红色墨水，以避免与RFC 2549中规定的红色油漆的用法混淆。
RFC 2549 did not consider the impact on quality of service of different types of carriers. There is a broad range. Some are very fast but can only carry small payloads and transit short distances, others are slower but carry large payloads and transit very large distances. It may be appropriate to select the individual carrier for a packet on the basis of its DSCP value. Indeed, different carriers will implement different per-hop behaviors according to RFC 2474.
RFC 2549没有考虑到不同类型的运营商对服务质量的影响。范围很广。有些速度很快，但只能携带小的有效载荷和短途运输；另一些速度较慢，但可以携带大的有效载荷和非常长的运输距离。基于分组的DSCP值为分组选择单个载波可能是合适的。实际上，根据RFC 2474，不同的运营商将实现不同的每跳行为。
Routing carriers through the territory of similar carriers, without peering agreements, will sometimes cause abrupt route changes, looping packets, and out-of-order delivery. Similarly, routing carriers through the territory of predatory carriers may potentially cause severe packet loss. It is strongly recommended that these factors be considered in the routing algorithm used to create carrier routing tables. Implementers should consider policy-based routing to ensure reliable packet delivery by routing around areas where territorial and predatory carriers are prevalent.
在没有对等协议的情况下，通过类似运营商的区域路由运营商，有时会导致路由突然改变、数据包循环和无序交付。类似地，通过掠夺性载波的区域路由载波可能导致严重的分组丢失。强烈建议在用于创建载波路由表的路由算法中考虑这些因素。实施者应该考虑基于策略的路由，以确保在区域和掠夺性载波盛行的区域周围路由可靠的分组传递。
There is evidence that some carriers have a propensity to eat other carriers and then carry the eaten payloads. Perhaps this provides a new way to tunnel an IPv4 packet in an IPv6 payload, or vice versa.
有证据表明，一些航母有吃掉其他航母的倾向，然后携带吃掉的有效载荷。也许这提供了一种在IPv6有效负载中隧道IPv4数据包的新方法，反之亦然。
However, the decapsulation mechanism is unclear at the time of this writing.
然而，在撰写本文时，脱封机制尚不清楚。
Some types of carriers are notoriously good at homing. Surprisingly, this property is not mentioned in RFC 1149. Unfortunately, they prove to have no talent for multihoming, and in fact enter a routing loop whenever multihoming is attempted. This appears to be a fundamental restriction on the topologies in which both RFC 1149 and the present specification can be deployed.
某些类型的航母以擅长寻的而闻名。令人惊讶的是，RFC1149中没有提到这个属性。不幸的是，事实证明他们没有多宿的天赋，事实上，每当尝试多宿时，他们都会进入一个路由循环。这似乎是对可以部署RFC 1149和本规范的拓扑的基本限制。
In some locations, such as New Zealand, a significant proportion of carriers are only able to execute short hops, and only at times when the background level of photon emission is extremely low. This will impact the availability and throughput of the solution in such locations.
在一些地方，如新西兰，很大一部分载波只能执行短跳，并且只有在光子发射的背景水平极低时才能执行。这将影响解决方案在这些位置的可用性和吞吐量。
The security considerations of [RFC1149] apply. In addition, recent experience suggests that the transmission elements are exposed to many different forms of denial-of-service attacks, especially when perching. Also, the absence of link layer identifiers referred to above, combined with the lack of checksums in the IPv6 header, basically means that any transmission element could be mistaken for any other, with no means of detecting the substitution at the network layer. The use of an upper-layer security mechanism of some kind seems like a really good idea.
[RFC1149]的安全注意事项适用。此外，最近的经验表明，传输元件会受到多种不同形式的拒绝服务攻击，尤其是在驻留时。此外，缺少上面提到的链路层标识符，再加上IPv6报头中缺少校验和，基本上意味着任何传输元素都可能被误认为任何其他元素，而无法在网络层检测替换。使用某种上层安全机制似乎是一个非常好的主意。
There is a known risk of infection by the so-called H5N1 virus. Appropriate detection and quarantine measures MUST be available.
已知存在被所谓的H5N1病毒感染的风险。必须采取适当的检测和检疫措施。
This document requests no action by IANA. However, registry clean-up may be necessary after interoperability testing, especially if multicast has been attempted.
本文件不要求IANA采取任何行动。然而，在互操作性测试之后，注册表清理可能是必要的，特别是在尝试多播的情况下。
Steve Deering was kind enough to review this document for conformance with IPv6 requirements. We acknowledge in advance the many errata in this document that will be reported by Alfred Hoenes.
Steve Deering非常友好地审查了该文档是否符合IPv6要求。我们提前确认阿尔弗雷德·霍恩斯将报告的本文件中的许多勘误表。
This document was produced using the xml2rfc tool [RFC2629].
本文档是使用xml2rfc工具[RFC2629]生成的。
[RFC1149] Waitzman, D., "Standard for the transmission of IP datagrams on avian carriers", RFC 1149, April 1990.
[RFC1149]Waitzman，D.，“鸟类载体上IP数据报传输标准”，RFC 1149，1990年4月。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC2675]Borman，D.，Deering，S.，和R.Hinden，“IPv6巨型程序”，RFC 26751999年8月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[IPv6-PREFIXLEN] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-bit IPv6 Prefixes on Inter-Router Links", Work in Progress, October 2010.
[IPv6前缀Xlen]Kohno，M.，Nitzan，B.，Bush，R.，Matsuzaki，Y.，Colitti，L.，和T.Narten，“在路由器间链路上使用127位IPv6前缀”，正在进行的工作，2010年10月。
[RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, February 1988.
[RFC1042]Postel，J.和J.Reynolds，“通过IEEE 802网络传输IP数据报的标准”，STD 43，RFC 1042，1988年2月。
[RFC2549] Waitzman, D., "IP over Avian Carriers with Quality of Service", RFC 2549, April 1999.
[RFC2549]Waitzman，D.，“具有服务质量的鸟类携带者IP”，RFC 2549，1999年4月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]Rose，M.，“使用XML编写I-D和RFC”，RFC 26292999年6月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider Scenarios for IPv6 Deployment", RFC 6036, October 2010.
[RFC6036]Carpenter，B.和S.Jiang，“IPv6部署的新兴服务提供商场景”，RFC 6036，2010年10月。
Authors' Addresses
作者地址
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand
Brian Carpenter奥克兰大学计算机系，奥克兰92019，新西兰1142
EMail: brian.e.carpenter@gmail.com
EMail: brian.e.carpenter@gmail.com
Robert M. Hinden Check Point Software Technologies, Inc. 800 Bridge Parkway Redwood City, CA 94065 US
Robert M.Hinden Check Point Software Technologies，Inc.800 Bridge Parkway美国加利福尼亚州红木市94065
Phone: +1.650.387.6118
EMail: bob.hinden@gmail.com
Phone: +1.650.387.6118
EMail: bob.hinden@gmail.com