[要約] RFC 7511は、IPv6の景観ルーティングに関する標準仕様であり、IPv6ネットワークの効率的なルーティングを実現することを目的としています。景観ルーティングは、ネットワークのトポロジー情報を活用して最適な経路を選択する手法です。

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.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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.

Copyright(c)2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

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
1. はじめに

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]はPacket Moodsについていくつかの考えを提供し、それらを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に対処する別の方法を定義しており、世界中の無数のネットワークパケットの幸福を支援することができれば幸いです。ネットワークパスのグリーンネスをルーティングの決定に組み込むScenic Routingを提案します。したがって、シーニックルーティングを実装するルーティングエンジンは、Avian 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]に基づく通信を無視しています。

1.1. Conventions and Terminology
1.1. 表記法と用語

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].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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].

さらに、このドキュメントのキーワード「MIGHT」、「COULD」、「MAY WISH TO」、「WOULD PROBABLY」、「SHOULD CONSIDER」、および「MUST(BUT WE KNOW YOU YOU WN'TW)」は、説明どおりに解釈されますRFC 6919 [RFC6919]。

2. Scenic Routing
2. シーニックルーティング

Scenic Routing can be enabled with a new option for IPv6 datagrams.

シーニックルーティングは、IPv6データグラムの新しいオプションで有効にできます。

2.1. Scenic Routing Option (SRO)
2.1. Scenic Routing Option(SRO)

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].

Scenic Routing Option(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データグラムにも含めることができますが、複数のSROを同じIPv6データグラムに含めることはできません。 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   |                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

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ビットID。オプションの識別子0x0A(オンエア)は、シーニックルーティング用に提案されています。

           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.

最上位の2ビットは00に設定されているため、シーニックルーティングを実装していないノードはこのオプションをスキップして、ヘッダーの処理を続行します。 3番目に上位のビットは、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 |
                             +-+-+-+-+-+-+-+-+
        

Figure 3: SRO Param Bit String Layout

図3:SROパラメータビット文字列のレイアウト

The highest-order two bits (SR) define the urgency of Scenic Routing:

最上位の2ビット(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:

次のBIT(A)は、Avian IPキャリアを使用する必要があるかどうかを定義します。

0 - Don't use Avian IP Carrier links (maybe the packet is afraid of pigeons).

0-Avian IPキャリアリンクを使用しないでください(おそらく、パケットはハトを恐れています)。

1 - Avian IP Carrier links may be used.

1-Avian IPキャリアリンクを使用できます。

The following BIT (W) defines if wireless links should be used:

次のBIT(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:

次の2ビット(AA)は、リンクタイプのアフィニティを定義します。

00 - No affinity.

00 ー の あっふぃにty。

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.

最下位の2ビット(XY)は現在使用されておらず、将来の使用のために予約されています。

3. Implications
3. 含意
3.1. Routing Implications
3.1. ルーティングの影響

If Scenic Routing is requested for a packet, the path with the known longest Avian IP Carrier and/or wireless portion MUST be used.

パケットに対してシーニックルーティングが要求された場合、既知の最長のAvian 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.

Scenic Routingに完全に準拠することを望むバックボーンオペレーターは、必要に応じて、特定のパスに最もフレッシュエア時間を提供する個別のMPLSパスを準備しておく必要があり、Scenic Routingが要求されたときに使用されますパケット。そのようなパスが存在する場合は、シーニックルーティングを考慮せずに、定期的に使用されるパスコストに応じて別のパスが安価であると見なされている場合でも、他のパスを優先して使用する必要があります。

3.2. Implications for Hosts
3.2. ホストへの影響

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).

ローカル発信元の接続でシーニックルーティングが要求された場合、ホストはその要求に従い、ワイヤレスリンク経由でパケットをルーティングするか、Avian 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.

オペレーティングシステムでシーニックルーティングが広く採用されている場合、システム管理者は、シーニックルーティングの適切なデフォルトパラメータを設定する必要がある場合があります。システム管理者は、必要に応じてシーニックルーティング情報を展開する必要があります。

3.3. Proxy Servers
3.3. プロキシサーバー

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.

開発者は、ネットワークサービスを設計および実装する際には、シーニックルーティングを検討する必要があります。

4. Security Considerations
4. セキュリティに関する考慮事項

The security considerations of RFC 6214 [RFC6214] apply for links provided by Avian IP Carriers.

RFC 6214 [RFC6214]のセキュリティに関する考慮事項は、Avian 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.

ユーザーはフローとパケットがネットワーク内でルーティングされる場所に影響を与えることができるため、これはトラフィックエンジニアリングの考慮事項に影響を与える可能性があり、ネットワークオペレーターはデバイスでシーニックルーティングを有効にする前にこれを考慮に入れる必要があります。

5. IANA Considerations
5. IANAに関する考慮事項

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.

このドキュメントでは、セクション2.1で説明されている新しいIPv6ホップバイホップオプションであるScenic Routing Optionを定義しています。この作業が標準化されている場合、IANAは、シーニックルーティングの目的で、「宛先オプションとホップバイホップオプション」レジストリから値を割り当てるように要求されます。

There are no IANA actions requested at this time.

現在、リクエストされているIANAアクションはありません。

6. 関連作業

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.

Scenic Routingはネットワークパスとルーティング情報に大きく依存しているため、BGPやOSPFなどの一般的なルーティングプロトコルの拡張機能を設計して、多数のワイヤレスリンクやAvianで構築された大規模ネットワークでのScenic Routingの可能性を最大限に活用することを検討する価値があるかもしれません。 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.

これにより、人気のある、または文化的に重要な場所に沿って進むワイヤレスパスを優先することもできます。このように、パケットはダークファイバーを回避するだけでなく、インターネットの外の世界を見ることができ、世界中のさまざまな文化にさらされているため、文化の違いを理解し、これらの違いの受け入れを促進するのに役立ちます。 。

7. References
7. 参考文献
7.1. Normative References
7.1. 引用文献

[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、「Adaptation of RFC 1149 for IPv6」、RFC 6214、2011年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>。

7.2. Informative References
7.2. 参考引用

[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 5841、2010年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 791、1981年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

マクシミリアンヴィルヘルムパーダーボルン、NRWドイツ

   Phone: +49 176 62 05 94 27
   EMail: max@rfc2324.org