LoginSignup
0
0

More than 1 year has passed since last update.

[Joke-RFC] RFC7511 IPv6における景観ルーティング

Last updated at Posted at 2022-04-22

はじめに

  • この文書は RFC7511 を勉強と好奇心のため適当に訳したものです。
  • 翻訳の正確さは全く保証しません。
  • 誤字誤訳等の指摘はいつでも大歓迎です。

Scenic Routing for IPv6(IPv6における景観ルーティング)

  • Independent Submission
  • Request for Comments: 7511
  • Category: Informational
  • ISSN: 2070-1721
  • M. Wilhelm
  • 1 April 2015

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.

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.

この文書はインターネット標準過程の仕様ではなく、情報提供の目的で発行されたものである。

この文書は、他のいかなるRFCストリームとも無関係に、RFCシリーズに貢献するものである。
RFCエディターは自らの裁量でこの文書の公開を選択し、実装や配備のための価値について何ら表明するものではない。
RFCエディターによって発行が承認された文書は、どのレベルのインターネット標準の候補にもならない;RFC 5741 の2章を参照のこと。

この文書の現在の状態、正誤表、それに対するフィードバックの提供方法に関する情報は、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.

   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.

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(序論)

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.

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.

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.

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

グリーンITの時代には、環境保全のために、ルーター、スイッチ、サーバー、ホストなどのエネルギー消費量の削減に多くの努力が払われている。
本書では、グリーンITを別の角度からとらえ、世界中でルーティングやスイッチングが行われているネットワークパケットに焦点を当てる。

ほとんどの場合、毎秒数百万個のパケットがビットに分解され、銅線を強制的に通過したり、強力なレーザーによってダークファイバー回線に連続的に高速で発射されていることなど、誰も考えたことがないだろう。
RFC5841 [RFC5841] はパケットのムードについていくつかの考えを提供し、TCPオプションとして表現し始めたが、これはパケットがその拷問的な日常から逃れる助けにはならない。

この文書は、トラフィックエンジニアとネットワークエンジニアのためにグリーンITに対処する別の方法を定義し、世界中の無数のネットワークパケットの幸福を助けることを望むものである。
この文書では、ネットワークパスのグリーン度をルーティングの決定に組み込む、景観ルーティングを提案する。
したがって、景観ルーティングを実装するルーティングエンジンは、パケットが地中にある数マイル/数キロメートルの暗いファイバーから抜け出し、できるだけ新鮮な空気の時間と太陽光を得られるように、鳥類 IP キャリア [RFC1149] や無線技術に基づいた経路を選択する必要がある。

インターネットプロトコルの現行バージョン(IPv6)が広く受け入れられているため、この文書ではバージョン6にのみ焦点を当て、ヴィンテージ IP [RFC791] に基づく通信は無視している。

1.1. Conventions and Terminology(規約と用語)

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

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

本文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC2119 [RFC2119] に記述されているように解釈されるものである。

さらに、本文書中のキーワード「MIGHT」、「COULD」、「MAY WISH TO」、「WOULD PROBABLY」、「SHOULD CONSIDER」、「MUST (BUT WE KNOW YOU WON'T)」はRFC 6919 [RFC6919] に記述されているように解釈されるものとする。

2. Scenic Routing(景観ルーティング)

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

景観ルーティングは、IPv6データグラムの新しいオプションで有効にすることができる。

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

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.

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.

The following Hop-by-Hop Option is proposed according to the specification in Section 4.2 of RFC 2460 [RFC2460].

景観ルーティングオプション (SRO) はIPv6の Hop-by-Hop オプションヘッダーに含まれ、パケットの配送経路に沿った各ノードによって検査されなければならない [RFC2460]。

SRO は任意の IPv6 データグラムに含めることができるが、同じIPv6データグラムに複数のSROが存在してはならない(MUST NOT)。
SROはアライメントを要求しない。

パケットにSROが設定された場合、パケット送信元からパケットの最終宛先までの経路上のすべてのノードは、そのオプションを保持しなければならない(MUST)。

RFC2460 [RFC2460] の4.2節の仕様に基づき、以下の Hop-by-Hop オプションを提案する。

      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

Option Type(オプションタイプ)

8-bit identifier of the type of option.
The option identifier 0x0A (On Air) is proposed for Scenic Routing.

オプションの種類を示す 8 ビットの識別子。
景観ルーティングには、オプション識別子 0x0A (On Air) を提案する。

           HEX         act  chg  rest
           ---         ---  ---  -----
           0A           00   0   01010     Scenic Routing

                   Figure 2: Scenic Routing Option Type

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 ビットの符号なし整数。
オプションの長さをオクテット単位で指定する (Option Type および Option Length フィールドは除く)。
この値は 0 より大きくなければならない(MUST)。

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

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

00 - Scenic Routing MUST NOT be used for this packet.

01 - Scenic Routing MIGHT be used for this packet.

10 - Scenic Routing SHOULD be used for this packet.

11 - Scenic Routing MUST be used for this packet.

最上位の2ビット(SR)は景観ルーティングの緊急度を定義する。

  • 00 - このパケットに景観ルーティングを使ってはならない(MUST NOT)。

  • 01 - このパケットに景観ルーティングを使われるかもしれない(MIGHT)。

  • 10 - このパケットに景観ルーティングを使用されるべきである(SHOULD)。

  • 11 - このパケットに景観ルーティングを使用されなければならない(MUST)。

The following BIT (A) defines if Avian IP Carriers should be used:

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

1 - Avian IP Carrier links may be used.

次のビット(A)は、鳥類 IP キャリアを使用すべきかどうかを定義する。

  • 0 - 鳥類 IP キャリアリンクを使用しない(パケットが鳩を恐れているのかもしれない)。

  • 1 - 鳥類 IP キャリアリンクを使用することができる。

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

0 - Don't use wireless links (maybe the packet is afraid of radiation).

1 - Wireless links may be used.

次のビット(W)は、ワイヤレスリンクを使用すべきかどうかを定義する。

  • 0 - ワイヤレスリンクを使用しない(パケットが放射を恐れているのかもしれない)。

  • 1 - ワイヤレスリンクを使用することができる。

The following two bits (AA) define the affinity for link types:

00 - No affinity.

01 - Avian IP Carriers SHOULD be preferred.

10 - Wireless links SHOULD be preferred.

11 - RESERVED

続く2ビット(AA)でリンクタイプに対する親和性を定義する。

  • 00 - 親和性なし。

  • 01 - 鳥類 IP キャリアが優先されるべき(SHOULD)。

  • 10 - ワイヤレスリンクが優先されるべき(SHOULD)。

  • 11 - 予約済み

The lowest-order two bits (XY) are currently unused and reserved for future use.

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

3. Implications(影響)

3.1. Routing Implications(ルーティングの影響)

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

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.

景観ルーティングがパケットに要求された場合、最も長い鳥類 IP キャリアおよび/またはワイヤレスな経路が使用されなければならない(MUST)。

景観ルーティングに完全に準拠することを望むバックボーンオペレータは、景観ルーティングがパケットで要求されたときに使用される、与えられた経路に対して最も新鮮な空気時間を提供する別々のMPLS経路を準備することを希望してもよい(MAY WISH TO) —— そして、そうすべきだ(SHOULD)。
そのような経路が存在する場合、たとえ他の経路の方が、景観ルーティングを考慮せずに通常使用される経路コストに従って安いと考えられる場合でも、その経路は他のどの経路よりも優先して使用されなければならない(MUST)。

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

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

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.

景観ルーティングが要求されたパケットを受信するこのオプションを実装するホストシステムは、この要求を尊重しなければならない(MUST)し、現在の接続の発信元ホストに返送されるパケットに対して景観ルーティングを有効化しなければならない(MUST)。

ローカルオリジンの接続に対して景観ルーティングが要求された場合、ホストはその要求に従い(利用可能で、SRO パラメータで要求された場合)、ワイヤレスリンクを介してパケットをルーティングするか、鳥類 IP キャリアを使用する必要がある(MUST)。

景観ルーティングがオペレーティングシステムに広く採用されている場合、システム管理者は景観ルーティングの適切なデフォルトパラメータを設定したい場合がある(MIGHT)。
システム管理者は、該当する場合には、景観ルーティング情報を展開する必要がある(SHOULD)。

3.3. Proxy Servers(プロキシ―サーバー)

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.

Developers SHOULD CONSIDER Scenic Routing when designing and implementing any network service.

ホストがプロキシサーバーや他のパケット中継アプリケーションを実行している場合、 景観ルーティングを実装するアプリケーションは、受信パケットにある SRO パラメータを送信パケットに同じように設定しなければならない(MUST)。

開発者は、ネットワークサービスを設計・実装するときに、景観ルーティングを考慮すべきである(SHOULD CONSIDER)。

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

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

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.

RFC 6214 [RFC6214] のセキュリティに関する考察は、鳥類 IP キャリアが提供するリンクに適用される。

無線通信の一般的なセキュリティの考慮事項は、無線技術を使用するリンクに適用される。

ユーザーはネットワーク内でフローとパケットがルーティングされる場所に影響を与えることができるので、これはトラフィックエンジニアリングの考察に影響するかもしれず、ネットワークオペレータは彼らのデバイスで景観ルーティングを有効にする前にこれを考慮に入れることを望むかもしれない(MAY WISH TO)。

5. IANA Considerations(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.

There are no IANA actions requested at this time.

本文書は、2.1節で述べた新しいIPv6 Hop-by-Hop オプションである景観ルーティングオプションを定義する。
この作業が標準化された場合、IANAは "Destination Options and Hop-by-Hop Options" レジストリから景観ルーティングの目的のために値を割り当てるよう要求される。

現時点では、IANAに要求されるアクションはない。

6. Related Work(関連課題)

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

景観ルーティングはネットワーク経路とルーティング情報に大きく依存しているので、BGP や OSPF のような一般的なルーティングプロトコルの拡張を設計し、多くのワイヤレスリンクや鳥類 IP キャリアで構築された大規模ネットワークで景観ルーティングの可能性を最大限に利用することを検討する価値があるかもしれない。
景観ルーティングと互換性のあるリンクの情報を組み込むと、ルーティングアルゴリズムは、任意の宛先のパケットに最も新鮮な空気時間を提供する最適な経路を簡単に計算することができるようになる。
これにより、人気のある場所や文化的に重要な場所に沿って行くワイヤレス経路を優先することも可能になる。
こうすることで、パケットは暗いファイバーを避けるだけでなく、インターネットの外の世界を見ることができ、世界中の異なる文化に触れ、文化の違いを理解し、その違いを受け入れることを促進することができるかもしれない。

7. References

7.1. Normative References

   [RFC1149]  Waitzman, D., "Standard for the transmission of IP
              datagrams on avian carriers", RFC 1149, April 1990,
              <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>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998,
              <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>.

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

7.2. Informative References

   [RFC5841]  Hay, R. and W. Turkal, "TCP Option to Denote Packet Mood",
              RFC 5841, April 2010,
              <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>.

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
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0