Independent Submission M. Wilhelm
Request for Comments: 7511 1 April 2015
Category: Informational
ISSN: 2070-1721
Independent Submission M. Wilhelm
Request for Comments: 7511 1 April 2015
Category: Informational
ISSN: 2070-1721
Scenic Routing for IPv6
IPv6的风景路由
Abstract
摘要
This document specifies a new routing scheme for the current version of the Internet Protocol version 6 (IPv6) in the spirit of "Green IT", whereby packets will be routed to get as much fresh-air time as possible.
本文件本着“绿色IT”的精神，为当前版本的互联网协议第6版（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/rfc7511.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7511.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3
2. Scenic Routing . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Scenic Routing Option (SRO) . . . . . . . . . . . . . . . 3
3. Implications . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Routing Implications . . . . . . . . . . . . . . . . . . 5
3.2. Implications for Hosts . . . . . . . . . . . . . . . . . 5
3.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3
2. Scenic Routing . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Scenic Routing Option (SRO) . . . . . . . . . . . . . . . 3
3. Implications . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Routing Implications . . . . . . . . . . . . . . . . . . 5
3.2. Implications for Hosts . . . . . . . . . . . . . . . . . 5
3.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
In times of Green IT, a lot of effort is put into reducing the energy consumption of routers, switches, servers, hosts, etc., to preserve our environment. This document looks at Green IT from a different angle and focuses on network packets being routed and switched around the world.
在绿色IT时代，为了保护我们的环境，我们投入了大量精力来降低路由器、交换机、服务器、主机等的能耗。本文档从另一个角度看待绿色IT，重点关注全球路由和交换的网络数据包。
Most likely, no one ever thought about the millions of packets being disassembled into bits every second and forced through copper wires or being shot through dark fiber lines by powerful lasers at continuously increasing speeds. Although RFC 5841 [RFC5841] provided some thoughts about Packet Moods and began to represent them as a TCP option, this doesn't help the packets escape their torturous routine.
最有可能的是，没有人想到过，每秒有数百万个数据包被分解成比特，然后被迫穿过铜线，或者以不断提高的速度被强大的激光射穿黑暗的光纤线路。尽管RFC 5841[RFC5841]提供了一些关于数据包情绪的想法，并开始将其表示为TCP选项，但这并不能帮助数据包摆脱其痛苦的例程。
This document defines another way to deal with Green IT for traffic and network engineers and will hopefully aid the wellbeing of a myriad of network packets around the world. It proposes Scenic Routing, which incorporates the green-ness of a network path into the routing decision. A routing engine implementing Scenic Routing should therefore choose paths based on Avian IP Carriers [RFC1149] and/or wireless technologies so the packets will get out of the miles/kilometers of dark fibers that are in the ground and get as much fresh-air time and sunlight as possible.
本文档为流量和网络工程师定义了处理绿色IT的另一种方法，并有望帮助世界各地无数网络数据包的福祉。它提出了风景路由，将网络路径的绿色性融入到路由决策中。因此，实现风景路由的路由引擎应该选择基于鸟类IP载波[RFC1149]和/或无线技术的路径，以便数据包能够从数英里/公里深的地下暗光纤中传输出去，获得尽可能多的新鲜空气时间和阳光。
As of the widely known acceptance of the current version of the Internet Protocol (IPv6), this document only focuses on version 6 and ignores communication still based on Vintage IP [RFC791].
由于人们普遍接受当前版本的互联网协议（IPv6），本文档仅关注版本6，忽略了仍然基于老式IP的通信[RFC791]。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Additionally, the key words "MIGHT", "COULD", "MAY WISH TO", "WOULD PROBABLY", "SHOULD CONSIDER", and "MUST (BUT WE KNOW YOU WON'T)" in this document are to interpreted as described in RFC 6919 [RFC6919].
此外，本文件中的关键词“可能”、“可能”、“可能希望”、“可能”、“应该考虑”和“必须（但我们知道您不会）”应按照RFC 6919[RFC6919]中的说明进行解释。
Scenic Routing can be enabled with a new option for IPv6 datagrams.
可以使用IPv6数据报的新选项启用场景路由。
The Scenic Routing Option (SRO) is placed in the IPv6 Hop-by-Hop Options Header that must be examined by every node along a packet's delivery path [RFC2460].
场景路由选项（SRO）位于IPv6逐跳选项报头中，每个节点必须沿数据包的传递路径检查该报头[RFC2460]。
The SRO can be included in any IPv6 datagram, but multiple SROs MUST NOT be present in the same IPv6 datagram. The SRO has no alignment requirement.
SRO可以包含在任何IPv6数据报中，但同一IPv6数据报中不得存在多个SRO。SRO没有校准要求。
If the SRO is set for a packet, every node en route from the packet source to the packet's final destination MUST preserve the option.
如果为数据包设置了SRO，则从数据包源到数据包最终目的地的路由中的每个节点都必须保留该选项。
The following Hop-by-Hop Option is proposed according to the specification in Section 4.2 of RFC 2460 [RFC2460].
根据RFC 2460[RFC2460]第4.2节中的规范，提出以下逐跳选项。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRO Param | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRO Param | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Scenic Routing Option Layout
图1：风景路线选项布局
Option Type
选项类型
8-bit identifier of the type of option. The option identifier 0x0A (On Air) is proposed for Scenic Routing.
选项类型的8位标识符。建议将选项标识符0x0A（空中）用于风景路线。
HEX act chg rest
--- --- --- -----
0A 00 0 01010 Scenic Routing
HEX act chg rest
--- --- --- -----
0A 00 0 01010 Scenic Routing
Figure 2: Scenic Routing Option Type
图2：风景路线选项类型
The highest-order two bits are set to 00 so any node not implementing Scenic Routing will skip over this option and continue processing the header. The third-highest-order bit indicates that the SRO does not change en route to the packet's final destination.
最高顺序的两位被设置为00，因此任何未实现风景路由的节点都将跳过此选项并继续处理报头。第三高阶位表示SRO在前往数据包最终目的地的途中没有改变。
Option Length
选项长度
8-bit unsigned integer. The length of the option in octets (excluding the Option Type and Option Length fields). The value MUST be greater than 0.
8位无符号整数。以八位字节为单位的选项长度（不包括选项类型和选项长度字段）。该值必须大于0。
SRO Param
SRO参数
8-bit identifier indicating Scenic Routing parameters encoded as a bit string.
8位标识符，指示编码为位字符串的路由参数。
+-+-+-+-+-+-+-+-+
| SR A W AA X Y |
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| SR A W AA X Y |
+-+-+-+-+-+-+-+-+
Figure 3: SRO Param Bit String Layout
图3:SRO参数位字符串布局
The highest-order two bits (SR) define the urgency of Scenic Routing:
最高阶两位（SR）定义了风景路线的紧迫性：
00 - Scenic Routing MUST NOT be used for this packet.
00-此数据包不得使用风景路由。
01 - Scenic Routing MIGHT be used for this packet.
01-此数据包可能使用风景路由。
10 - Scenic Routing SHOULD be used for this packet.
10-此数据包应使用风景路由。
11 - Scenic Routing MUST be used for this packet.
11-此数据包必须使用风景路由。
The following BIT (A) defines if Avian IP Carriers should be used:
以下位（A）定义了是否应使用IP载波：
0 - Don't use Avian IP Carrier links (maybe the packet is afraid of pigeons).
0-不要使用鸟类IP载波链接（可能数据包害怕鸽子）。
1 - Avian IP Carrier links may be used.
1-可使用IP载波链路。
The following BIT (W) defines if wireless links should be used:
以下位（W）定义了是否应使用无线链路：
0 - Don't use wireless links (maybe the packet is afraid of radiation).
0-不要使用无线链接（可能数据包害怕辐射）。
1 - Wireless links may be used.
1-可以使用无线链路。
The following two bits (AA) define the affinity for link types:
以下两位（AA）定义链接类型的关联性：
00 - No affinity.
00-没有亲缘关系。
01 - Avian IP Carriers SHOULD be preferred.
01-应首选鸟类IP载体。
10 - Wireless links SHOULD be preferred.
10-应首选无线链路。
11 - RESERVED
11-保留
The lowest-order two bits (XY) are currently unused and reserved for future use.
最低阶两位（XY）当前未使用，保留供将来使用。
If Scenic Routing is requested for a packet, the path with the known longest Avian IP Carrier and/or wireless portion MUST be used.
如果为数据包请求风景路由，则必须使用具有已知最长IP载波和/或无线部分的路径。
Backbone operators who desire to be fully compliant with Scenic Routing MAY WISH TO -- well, they SHOULD -- have separate MPLS paths ready that provide the most fresh-air time for a given path and are to be used when Scenic Routing is requested by a packet. If such a path exists, the path MUST be used in favor of any other path, even if another path is considered cheaper according to the path costs used regularly, without taking Scenic Routing into account.
希望完全符合场景路由的主干网运营商可能希望——嗯，他们应该——拥有单独的MPLS路径，为给定路径提供最新鲜的空气时间，并在数据包请求场景路由时使用。如果存在这样一条路径，则该路径必须优先于任何其他路径使用，即使根据经常使用的路径成本，另一条路径被认为更便宜，但不考虑风景路线。
Host systems implementing this option of receiving packets with Scenic Routing requested MUST honor this request and MUST activate Scenic Routing for any packets sent back to the originating host for the current connection.
实现此选项的主机系统接收请求了场景路由的数据包时，必须满足此请求，并且必须为发送回发起主机的用于当前连接的任何数据包激活场景路由。
If Scenic Routing is requested for connections of local origin, the host MUST obey the request and route the packet(s) over a wireless link or use Avian IP Carriers (if available and as requested within the SRO Params).
如果为本地来源的连接请求风景路由，则主机必须遵守该请求，并通过无线链路路由数据包，或使用鸟类IP载波（如果可用且符合SRO参数中的请求）。
System administrators MIGHT want to configure sensible default parameters for Scenic Routing, when Scenic Routing has been widely adopted by operating systems. System administrators SHOULD deploy Scenic Routing information where applicable.
当操作系统广泛采用风景路由时，系统管理员可能希望为风景路由配置合理的默认参数。系统管理员应在适用的情况下部署场景路由信息。
If a host is running a proxy server or any other packet-relaying application, an application implementing Scenic Routing MUST set the same SRO Params on the outgoing packet as seen on the incoming packet.
如果主机正在运行代理服务器或任何其他数据包中继应用程序，则实现场景路由的应用程序必须在传出数据包上设置与传入数据包上相同的SRO参数。
Developers SHOULD CONSIDER Scenic Routing when designing and implementing any network service.
在设计和实现任何网络服务时，开发人员应考虑景区路由。
The security considerations of RFC 6214 [RFC6214] apply for links provided by Avian IP Carriers.
RFC 6214[RFC6214]的安全考虑适用于鸟类IP运营商提供的链路。
General security considerations of wireless communication apply for links using wireless technologies.
无线通信的一般安全考虑适用于使用无线技术的链路。
As the user is able to influence where flows and packets are being routed within the network, this MIGHT influence traffic-engineering considerations and network operators MAY WISH TO take this into account before enabling Scenic Routing on their devices.
由于用户能够影响流和分组在网络内路由的位置，这可能会影响流量工程考虑，并且网络运营商可能希望在其设备上启用风景路由之前考虑到这一点。
This document defines a new IPv6 Hop-by-Hop Option, the Scenic Routing Option, described in Section 2.1. If this work is standardized, IANA is requested to assign a value from the "Destination Options and Hop-by-Hop Options" registry for the purpose of Scenic Routing.
本文档定义了一个新的IPv6逐跳选项，即场景路由选项，如第2.1节所述。如果这项工作是标准化的，IANA需要从“目的地选项和逐跳选项”注册表中分配一个值，用于风景路由。
There are no IANA actions requested at this time.
目前没有请求IANA操作。
As Scenic Routing is heavily dependent on network paths and routing information, it might be worth looking at designing extensions for popular routing protocols like BGP or OSPF to leverage the full potential of Scenic Routing in large networks built upon lots of wireless links and/or Avian IP Carriers. When incorporating information about links compatible with Scenic Routing, the routing algorithms could easily calculate the optimal paths providing the most fresh-air time for a packet for any given destination.
由于风景路由在很大程度上依赖于网络路径和路由信息，因此有必要为流行的路由协议（如BGP或OSPF）设计扩展，以充分利用基于大量无线链路和/或IP运营商的大型网络中风景路由的潜力。当结合与风景路由兼容的链路信息时，路由算法可以轻松计算为任何给定目的地的数据包提供最新鲜空气时间的最佳路径。
This would even allow preference for wireless paths going alongside popular or culturally important places. This way, the packets don't only avoid the dark fibers, but they get to see the world outside of the Internet and are exposed to different cultures around the globe, which may help build an understanding of cultural differences and promote acceptance of these differences.
这甚至可以让人们更倾向于选择与流行或文化上重要的地方相邻的无线路径。通过这种方式，这些数据包不仅可以避开暗纤维，还可以看到互联网之外的世界，接触到全球不同的文化，这可能有助于理解文化差异，促进对这些差异的接受。
[RFC1149] Waitzman, D., "Standard for the transmission of IP datagrams on avian carriers", RFC 1149, April 1990, <http://www.rfc-editor.org/info/rfc1149>.
[RFC1149]Waitzman，D.，“鸟类载体上IP数据报传输标准”，RFC 1149，1990年4月<http://www.rfc-editor.org/info/rfc1149>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC6214] Carpenter, B. and R. Hinden, "Adaptation of RFC 1149 for IPv6", RFC 6214, April 2011, <http://www.rfc-editor.org/info/rfc6214>.
[RFC6214]Carpenter，B.和R.Hinden，“适用于IPv6的RFC 1149”，RFC 62142011年4月<http://www.rfc-editor.org/info/rfc6214>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words for Use in RFCs to Indicate Requirement Levels", RFC 6919, April 2013, <http://www.rfc-editor.org/info/rfc6919>.
[RFC6919]Barnes，R.，Kent，S.，和E.Rescorla，“在RFC中用于指示需求水平的更多关键词”，RFC 6919，2013年4月<http://www.rfc-editor.org/info/rfc6919>.
[RFC5841] Hay, R. and W. Turkal, "TCP Option to Denote Packet Mood", RFC 5841, April 2010, <http://www.rfc-editor.org/info/rfc5841>.
[RFC5841]Hay，R.和W.Turkal，“表示数据包情绪的TCP选项”，RFC 58412010年4月<http://www.rfc-editor.org/info/rfc5841>.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月<http://www.rfc-editor.org/info/rfc791>.
Acknowledgements
致谢
The author wishes to thank all those poor friends who were kindly forced to read this document and that provided some nifty comments.
作者希望感谢所有被迫阅读本文件并提供了一些漂亮评论的穷朋友。
Author's Address
作者地址
Maximilian Wilhelm Paderborn, NRW Germany
马克西米利安·威廉·帕德伯恩，德国西北部
Phone: +49 176 62 05 94 27
EMail: max@rfc2324.org
Phone: +49 176 62 05 94 27
EMail: max@rfc2324.org