RFC 7511

Scenic Routing for IPv6

๐Ÿ“… published April 2015, from ietf

Scenic Routing for IPv6 ๐Ÿฆ‹

Okay bestie, let's start with the title block ๐Ÿ“‹. This is RFC 7511, titled Scenic Routing for IPv6. It's an Independent Submission written by M. Wilhelm and dated 1 April 2015 ๐ŸŒธ. The category is Informational, and the ISSN is 2070-1721 โœจ.

Abstract โœจ

Okay so this doc specifies a brand new routing scheme for the current version of the Internet Protocol version 6 (IPv6) ๐ŸŒˆ. It's inspired by the whole "Green IT" movement, and the goal is that packets get routed so they get as much fresh-air time as possible ๐Ÿƒ. Literally a spa day for packets ๐Ÿ’….

Status of This Memo ๐Ÿ“œ

This doc is not an Internet Standards Track spec ๐Ÿ™…โ€โ™€๏ธ. It's published for informational purposes only ๐ŸŽ€.

This is a contribution to the RFC Series, made independently of any other RFC stream ๐Ÿฆ‹. The RFC Editor picked to publish it at their discretion, and they make zero statement about its value for implementation or deployment ๐Ÿคทโ€โ™€๏ธ. Docs the RFC Editor approves for publication are not a candidate for any level of Internet Standard, see Section 2 of RFC 5741 ๐Ÿ’œ.

Info about the current status of this doc, any errata, and how to give feedback can be found at http://www.rfc-editor.org/info/rfc7511 ๐Ÿ”—.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved ๐ŸŒธ.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication ๐Ÿ“š. Please review these carefully, because they describe your rights and restrictions regarding this doc ๐Ÿซถ.

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 goes into cutting the energy use of routers, switches, servers, hosts, and so on, all to save our planet ๐ŸŒฑ. This doc looks at Green IT from a totally different angle, focusing on the network packets that get routed and switched around the world ๐Ÿงš.

Honestly, nobody has ever stopped to think about the millions of packets being chopped into bits every second and forced through copper wires, or getting zapped down dark fiber lines by powerful lasers at ever-increasing speeds โšก. RFC 5841 [RFC5841] did share some thoughts about Packet Moods and started representing them as a TCP option, but ngl, that doesn't actually help the packets escape their torturous routine ๐Ÿ˜ญ.

This doc defines another way to handle Green IT for traffic and network engineers, and it'll hopefully boost the wellbeing of a myriad of network packets everywhere ๐Ÿ’–. It proposes Scenic Routing, which folds the green-ness of a network path into the routing decision ๐Ÿฆ‹. So a routing engine implementing Scenic Routing should choose paths based on Avian IP Carriers [RFC1149] and/or wireless technologies, so the packets can escape the miles or kilometers of dark fiber buried in the ground and soak up as much fresh air and sunlight as possible โ˜€๏ธ๐Ÿ“.

Since the current version of the Internet Protocol (IPv6) has basically become the accepted standard, this doc only focuses on version 6 and ignores communication still based on Vintage 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 doc are to be interpreted as described in RFC 2119 [RFC2119] ๐ŸŽ€.

Also, the key words "MIGHT", "COULD", "MAY WISH TO", "WOULD PROBABLY", "SHOULD CONSIDER", and "MUST (BUT WE KNOW YOU WON'T)" in this doc are to be interpreted as described in RFC 6919 [RFC6919] ๐Ÿ™ˆ.

2. Scenic Routing ๐ŸŒธ

Scenic Routing can be turned on with a new option for IPv6 datagrams ๐ŸŒˆ.

2.1. Scenic Routing Option (SRO) ๐Ÿฆ‹

The Scenic Routing Option (SRO) lives in the IPv6 Hop-by-Hop Options Header, which every node along a packet's delivery path has to examine [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] ๐Ÿง. Here's the layout:

      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 ๐Ÿท๏ธ

This is an 8-bit identifier for the type of option. The option identifier 0x0A (On Air) is proposed for Scenic Routing ๐Ÿ“ก.

           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 that isn't implementing Scenic Routing will skip over this option and keep processing the header ๐Ÿƒโ€โ™€๏ธ. The third-highest-order bit says the SRO does not change en route to the packet's final destination ๐Ÿ”’.

Option Length ๐Ÿ“

This is an 8-bit unsigned integer. It's the length of the option in octets, not counting the Option Type and Option Length fields. The value MUST be greater than 0 ๐Ÿ”ข.

SRO Param ๐ŸŽ›๏ธ

This is an 8-bit identifier that indicates Scenic Routing parameters encoded as a bit string ๐Ÿงฉ.

                             +-+-+-+-+-+-+-+-+
                             | SR A W AA X Y |
                             +-+-+-+-+-+-+-+-+

Figure 3: SRO Param Bit String Layout ๐Ÿช„

The highest-order two bits (SR) define how urgent Scenic Routing is ๐Ÿšจ:

  • 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. ๐Ÿ‘‘

The following BIT (A) decides whether 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. ๐Ÿ•Š๏ธ

The following BIT (W) decides whether wireless links should be used ๐Ÿ“ถ:

  • 0 - Don't use wireless links (maybe the packet is afraid of radiation ๐Ÿ˜ฐ).
  • 1 - Wireless links may be used. ๐Ÿ“ฑ

The following two bits (AA) set the affinity for link types ๐Ÿ’œ:

  • 00 - No affinity. ๐Ÿคทโ€โ™€๏ธ
  • 01 - Avian IP Carriers SHOULD be preferred. ๐Ÿฅ
  • 10 - Wireless links SHOULD be preferred. ๐ŸŒˆ
  • 11 - RESERVED ๐Ÿ”

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

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 want to be fully compliant with Scenic Routing MAY WISH TO -- well, they SHOULD -- have separate MPLS paths ready. Those paths should give the most fresh-air time for a given path and get used whenever a packet requests Scenic Routing ๐ŸŒท. If such a path exists, it MUST be used in favor of any other path, even if another path is cheaper according to the regular path costs, the ones that don't take Scenic Routing into account at all ๐Ÿ’ธ.

3.2. Implications for Hosts ๐Ÿ–ฅ๏ธ

Host systems that implement receiving packets with Scenic Routing requested MUST honor that request, and they 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 they're available and requested within the SRO Params) ๐Ÿฆ๐Ÿ“ถ.

System administrators MIGHT want to configure sensible default parameters for Scenic Routing once it's widely adopted by operating systems ๐Ÿ› ๏ธ. System administrators SHOULD deploy Scenic Routing information wherever it applies ๐Ÿ“ฃ.

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 it saw on the incoming packet ๐Ÿ”„.

Developers SHOULD CONSIDER Scenic Routing when designing and implementing any network service ๐Ÿ’ก.

4. Security Considerations ๐Ÿ”

The security considerations of RFC 6214 [RFC6214] apply to links provided by Avian IP Carriers ๐Ÿง.

The general security considerations of wireless communication apply to links using wireless technologies ๐Ÿ“ก.

Here's the spicy part ๐ŸŒถ๏ธ: since the user can influence where flows and packets get routed within the network, this MIGHT influence traffic-engineering considerations. Network operators MAY WISH TO take this into account before turning on Scenic Routing on their devices โš ๏ธ.

5. IANA Considerations ๐Ÿ“‹

This doc 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 ๐Ÿ™Œ.

Scenic Routing depends heavily on network paths and routing information, so it might be worth designing extensions for popular routing protocols like BGP or OSPF ๐Ÿ›ค๏ธ. That would let large networks built on tons of wireless links and/or Avian IP Carriers unlock the full potential of Scenic Routing ๐Ÿš€. When information about Scenic Routing-compatible links gets built into the routing protocols, the routing algorithms could easily calculate the optimal paths, the ones with the most fresh-air time for a packet, for any given destination ๐Ÿงฎ.

This would even let you prefer wireless paths that run alongside popular or culturally important places ๐Ÿ—ฝ. That way the packets don't just avoid the dark fibers, they get to see the world outside the Internet and experience different cultures around the globe ๐ŸŒ. Which, honestly, might help people understand cultural differences and become more accepting of them ๐Ÿซถ๐ŸŒˆ.

7. References ๐Ÿ“š

7.1. Normative References โœจ

okay so the normative references are the ones this doc literally can't function without ๐Ÿซถ here's the full list, bestie:

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

RFC 1149 is the pigeon one ๐Ÿฆ (IP over avian carriers, yes really), and RFC 6214 is its IPv6 glow-up ๐Ÿฆ‹. RFC 2119 and RFC 6919 are the key-word rulebooks, so they're the ones telling you how MUST and friends are supposed to hit ๐Ÿ’…

7.2. Informative References ๐ŸŒธ

these ones are just good background reading, not required to get the vibe:

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

RFC 791 is the OG IPv4 spec, and RFC 5841 is the TCP option for telling the world your packet's mood ๐Ÿฅน (yes, that's a real thing).


Acknowledgements ๐ŸŽ€

The author wishes to thank all those poor friends who were kindly forced to read this document and that provided some nifty comments. ๐Ÿ˜ญ Honestly the bar for this one is "survived the read," and they did it ๐Ÿซถ

Author's Address ๐Ÿ’œ

Maximilian Wilhelm Paderborn, NRW Germany

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

๐Ÿ“ฆ where this page comes from