RFC 6214

Adaptation of RFC 1149 for IPv6

📅 published March 2011, from ietf

RFC 6214 🎀 Adaptation of RFC 1149 for IPv6

  • Request for Comments: 6214
  • Title: Adaptation of RFC 1149 for IPv6
  • Authors: B. Carpenter (Univ. of Auckland) and R. Hinden (Check Point Software)
  • Category: Informational, as an Independent Submission 📄
  • ISSN: 2070-1721
  • Date: 1 April 2011 🌸
  • Obsoletes and updates: the title block doesn't list either one, so this doc doesn't obsolete or update anything 🙅‍♀️

Abstract

Okay so this doc is all about sending IPv6 datagrams over the exact same medium that RFC 1149 defines for IPv4 datagrams 🦋 Same vibe, new protocol, no new wires needed!

Status of This Memo

This one is not an Internet Standards Track spec. It's published just for info 💅

It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor picked it for publication at their discretion and makes no claims about whether it's worth implementing or deploying 🤷‍♀️ Docs the RFC Editor approves aren't candidates for any level of Internet Standard. See Section 2 of RFC 5741 for the details.

For the latest status, errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6214 🔗

Copyright (c) 2011 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 read those carefully, because they spell out your rights and restrictions for this doc 📜

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 🌷

Per [RFC6036], lots of service providers are actively planning to roll out IPv6 🚀 because we're running out of IPv4 addresses, and it's getting urgent. Every provider that has implemented [RFC1149] is affected. So it's really necessary, like, urgent, to specify a way to send IPv6 datagrams [RFC2460] over the RFC 1149 medium. The alternative would be making those providers migrate to a totally different medium, and nobody wants that 😭 This document is that spec ✨

2. Normative Notation 💜

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

3. Detailed Specification 🧚

Unless stated otherwise, the rules in [RFC1149] and [RFC2460] apply all the way through 🫶

3.1. Maximum Transmission Unit 🍓

As RFC 1149 notes, the MTU is variable, and it generally goes up as the carrier gets older. The minimum link MTU that RFC 2460 allows is 1280 octets, so older carriers MUST be used for IPv6. RFC 1149 doesn't give exact conversion factors between age and milligrams, or between milligrams and octets. Those conversion factors are implementation dependent. As an illustrative example, we assume the 256 milligram MTU suggested in RFC 1149 corresponds to an MTU of 576 octets. In that case, the typical MTU for this spec will be at least 256*1280/576, which is about 569 milligrams. Again, as an illustrative example, that probably takes a carrier age of at least 365 days 🗓️

It gets even more dramatic, because the MTU issues are non-linear with carrier age. A young carrier can only carry small payloads 🐣 An adult carrier can carry jumbograms [RFC2675] 💪 And an elderly carrier can go back to carrying only smaller payloads 👵 Carrier age also affects transit time, which changes the bandwidth-delay product and therefore TCP performance. Iconic chaos, honestly 💀

3.2. Frame Format 🎀

RFC 1149 doesn't specify any link layer tag, like an Ethertype or, worse, an OSI Link Layer or SNAP header [RFC1042]. Header snaps are known to make the quality of service on RFC 1149 carriers worse 😤 To keep things efficient and avoid using too much energy while packets are in flight, no link layer tag is required for IPv6 packets either. So the frame format is a pure IPv6 packet as defined in [RFC2460], encoded and decoded as defined in [RFC1149] 🫧

One important consequence: in a dual-stack deployment [RFC4213], the receiver MUST inspect the IP protocol version number in the first four bits of every packet. That's the only way to tell IPv4 and IPv6 packets apart when they're mixed together 👀

3.3. Address Configuration 🌈

Without any link layer protocol, link-local addresses can't be formed, because there's no way to address anything except the other end of the link 🙃

There's also no way to map an IPv6 unicast address to a link layer address, since there is no link layer address in the first place. So IPv6 Neighbor Discovery [RFC4861] is impossible 💀

Implementations SHOULD NOT even try to use stateless address autoconfiguration [RFC4862]. This is because that mechanism needs a stable interface identifier formed in a way compatible with [RFC4291]. Unfortunately, the transmission elements specified by RFC 1149 aren't stable enough for that, and they can get really unstable in the presence of a cross-wind 🌬️

In most deployments, either the end points of the link stay unnumbered, or a /127 prefix and static addresses MAY be assigned. See [IPv6-PREFIXLEN] for more on this 📌

3.4. Multicast 🦋

RFC 1149 doesn't specify a multicast address mapping. People have reported that trying to implement IPv4 multicast delivery caused excessive noise in transmission elements, with packet digests getting dropped as a result 😵 So for now, no IPv6 multicast mapping has been specified, to avoid those problems 🙅‍♀️

4. Quality-of-Service Considerations 💅

[RFC2549] also applies to the IPv6 case. However, the author of RFC 2549 didn't account for the Differentiated Services model [RFC2474]. IPv6 packets that carry a non-default Differentiated Services Code Point (DSCP) value in their Traffic Class field [RFC2460] MUST be specially encoded using green or blue ink, so the DSCP is externally visible 🖍️ Red ink MUST NOT be used, so nobody confuses it with the red paint specified in RFC 2549 🎨

RFC 2549 also didn't consider how QoS is affected by different types of carriers, and there's a huge range. Some are super fast but can only carry small payloads and only go short distances. Others are slower but carry large payloads and travel very far 🏃‍♀️🐢 It may make sense to pick the individual carrier for a packet based on its DSCP value. And different carriers will implement different per-hop behaviors according to RFC 2474 ✨

5. Routing and Tunneling Considerations 🗺️

Routing carriers through the territory of similar carriers without peering agreements will sometimes cause abrupt route changes, looping packets, and out-of-order delivery 🌀 Routing carriers through the territory of predatory carriers may cause severe packet loss 😬 It is strongly recommended that these factors be considered in the routing algorithm used to build carrier routing tables. Implementers should consider policy-based routing to keep delivery reliable, by routing around areas where territorial and predatory carriers are prevalent 🛣️

There's evidence that some carriers have a habit of eating other carriers and then carrying the eaten payloads. Maybe that gives us a new way to tunnel an IPv4 packet in an IPv6 payload, or vice versa 🍽️ However, the decapsulation mechanism is unclear as of this writing 🤔

6. Multihoming Considerations 🏠

Some types of carriers are notoriously good at homing. Surprisingly, RFC 1149 doesn't mention this property. Unfortunately, these carriers have no talent for multihoming, and they actually enter a routing loop whenever multihoming is attempted 🔁 This appears to be a fundamental restriction on the topologies where both RFC 1149 and this spec can be deployed. Not it 💀

7. Internationalization Considerations 🌏

In some places, like New Zealand, a big share of carriers can only do short hops, and only at times when the background level of photon emission is extremely low ☀️ This will affect the availability and throughput of the solution in those locations 😩

8. Security Considerations 🔐

The security considerations of [RFC1149] apply, and this section is serious. Read it all 🚨

The security considerations of [RFC1149] apply. On top of that, recent experience suggests that transmission elements are exposed to many different kinds of denial-of-service attacks, especially when perching 🐦 The absence of the link layer identifiers mentioned above, plus the lack of checksums in the IPv6 header, basically means any transmission element could be mistaken for any other, with no way to detect the substitution at the network layer 😱 Using some kind of upper-layer security mechanism seems like a really good idea 🛡️

There's a known risk of infection by the so-called H5N1 virus. Appropriate detection and quarantine measures MUST be available 🧼

9. IANA Considerations 📋

This document requests no action by IANA. However, registry clean-up may be necessary after interoperability testing, especially if multicast has been attempted 🧹

10. Acknowledgements 🫶

Steve Deering was kind enough to review this document for conformance with IPv6 requirements 👑 The authors acknowledge in advance the many errata that Alfred Hoenes will report in this document 🙈

This document was produced using the xml2rfc tool [RFC2629] 🌸

11. References 📚

11.1. Normative References

11.2. Informative References

The reference entries aren't in the text I was given for this part, so I've left these headings empty instead of filling in anything I'd have to guess at 🥺

11.1. Normative References 💅

okay bestie, these are the must-read docs 📚 the spec leans on. no cap, you need all of them to follow along 🎀

[RFC1149]         Waitzman, D., "Standard for the transmission of IP
                  datagrams on avian carriers", RFC 1149, April 1990.

[RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2460]         Deering, S. and R. Hinden, "Internet Protocol,
                  Version 6 (IPv6) Specification", RFC 2460,
                  December 1998.

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

[RFC2675]         Borman, D., Deering, S., and R. Hinden, "IPv6
                  Jumbograms", RFC 2675, August 1999.

[RFC4213]         Nordmark, E. and R. Gilligan, "Basic Transition
                  Mechanisms for IPv6 Hosts and Routers", RFC 4213,
                  October 2005.

11.2. Informative References 🦋

these ones are extra reading, the spec doesn't depend on them to work 🧚 but they're so worth a peek ✨

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

[RFC1042]         Postel, J. and J. Reynolds, "Standard for the
                  transmission of IP datagrams over IEEE 802
                  networks", STD 43, RFC 1042, February 1988.

[RFC2549]         Waitzman, D., "IP over Avian Carriers with Quality
                  of Service", RFC 2549, April 1999.

[RFC2629]         Rose, M., "Writing I-Ds and RFCs using XML",
                  RFC 2629, June 1999.

[RFC4291]         Hinden, R. and S. Deering, "IP Version 6 Addressing
                  Architecture", RFC 4291, February 2006.

[RFC4861]         Narten, T., Nordmark, E., Simpson, W., and H.
                  Soliman, "Neighbor Discovery for IP version 6
                  (IPv6)", RFC 4861, September 2007.

[RFC4862]         Thomson, S., Narten, T., and T. Jinmei, "IPv6
                  Stateless Address Autoconfiguration", RFC 4862,
                  September 2007.

[RFC6036]         Carpenter, B. and S. Jiang, "Emerging Service
                  Provider Scenarios for IPv6 Deployment", RFC 6036,
                  October 2010.

Authors' Addresses 🫶

and that's the squad behind it! 💖 here's where you can find them 🌈

Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland,   1142
New Zealand

EMail: brian.e.carpenter@gmail.com


Robert M. Hinden
Check Point Software Technologies, Inc.
800 Bridge Parkway
Redwood City, CA  94065
US

Phone: +1.650.387.6118
EMail: bob.hinden@gmail.com
📦 where this page comes from