From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6214.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc6214.txt (limited to 'doc/rfc/rfc6214.txt') diff --git a/doc/rfc/rfc6214.txt b/doc/rfc/rfc6214.txt new file mode 100644 index 0000000..50fc71e --- /dev/null +++ b/doc/rfc/rfc6214.txt @@ -0,0 +1,395 @@ + + + + + + +Independent Submission B. Carpenter +Request for Comments: 6214 Univ. of Auckland +Category: Informational R. Hinden +ISSN: 2070-1721 Check Point Software + 1 April 2011 + + + Adaptation of RFC 1149 for IPv6 + +Abstract + + This document specifies a method for transmission of IPv6 datagrams + over the same medium as specified for IPv4 datagrams in RFC 1149. + +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/rfc6214. + +Copyright Notice + + Copyright (c) 2011 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. + + + + + + + + + + +Carpenter & Hinden Informational [Page 1] + +RFC 6214 IPv6 and RFC 1149 1 April 2011 + + +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 + + As shown by [RFC6036], many service providers are actively planning + to deploy IPv6 to alleviate the imminent shortage of IPv4 addresses. + This will affect all service providers who have implemented + [RFC1149]. It is therefore necessary, indeed urgent, to specify a + method of transmitting IPv6 datagrams [RFC2460] over the RFC 1149 + medium, rather than obliging those service providers to migrate to a + different medium. This document offers such a specification. + +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 otherwise stated, the provisions of [RFC1149] and [RFC2460] + apply throughout. + +3.1. Maximum Transmission Unit + + As noted in RFC 1149, the MTU is variable, and generally increases + with increased carrier age. Since the minimum link MTU allowed by + RFC 2460 is 1280 octets, this means that older carriers MUST be used + for IPv6. RFC 1149 does not provide exact conversion factors between + age and milligrams, or between milligrams and octets. These + + + +Carpenter & Hinden Informational [Page 2] + +RFC 6214 IPv6 and RFC 1149 1 April 2011 + + + conversion factors are implementation dependent, but as an + illustrative example, we assume that the 256 milligram MTU suggested + in RFC 1149 corresponds to an MTU of 576 octets. In that case, the + typical MTU for the present specification will be at least + 256*1280/576, which is approximately 569 milligrams. Again as an + illustrative example, this is likely to require a carrier age of at + least 365 days. + + Furthermore, the MTU issues are non-linear with carrier age. That + is, a young carrier can only carry small payloads, an adult carrier + can carry jumbograms [RFC2675], and an elderly carrier can again + carry only smaller payloads. There is also an effect on transit time + depending on carrier age, affecting bandwidth-delay product and hence + the performance of TCP. + +3.2. Frame Format + + RFC 1149 does not specify the use of any link layer tag such as an + Ethertype or, worse, an OSI Link Layer or SNAP header [RFC1042]. + Indeed, header snaps are known to worsen the quality of service + provided by RFC 1149 carriers. In the interests of efficiency and to + avoid excessive energy consumption while packets are in flight + through the network, no such link layer tag is required for IPv6 + packets either. The frame format is therefore a pure IPv6 packet as + defined in [RFC2460], encoded and decoded as defined in [RFC1149]. + + One important consequence of this is that in a dual-stack deployment + [RFC4213], the receiver MUST inspect the IP protocol version number + in the first four bits of every packet, as the only means to + demultiplex a mixture of IPv4 and IPv6 packets. + +3.3. Address Configuration + + The lack of any form of link layer protocol means that link-local + addresses cannot be formed, as there is no way to address anything + except the other end of the link. + + Similarly, there is no method to map an IPv6 unicast address to a + link layer address, since there is no link layer address in the first + place. IPv6 Neighbor Discovery [RFC4861] is therefore impossible. + + Implementations SHOULD NOT even try to use stateless address auto- + configuration [RFC4862]. This recommendation is because this + mechanism requires a stable interface identifier formed in a way + compatible with [RFC4291]. Unfortunately the transmission elements + specified by RFC 1149 are not generally stable enough for this and + may become highly unstable in the presence of a cross-wind. + + + + +Carpenter & Hinden Informational [Page 3] + +RFC 6214 IPv6 and RFC 1149 1 April 2011 + + + In most deployments, either the end points of the link remain + unnumbered, or a /127 prefix and static addresses MAY be assigned. + See [IPv6-PREFIXLEN] for further discussion. + +3.4. Multicast + + RFC 1149 does not specify a multicast address mapping. It has been + reported that attempts to implement IPv4 multicast delivery have + resulted in excessive noise in transmission elements, with subsequent + drops of packet digests. At the present time, an IPv6 multicast + mapping has not been specified, to avoid such problems. + +4. Quality-of-Service Considerations + + [RFC2549] is also applicable in the IPv6 case. However, the author + of RFC 2549 did not take account of the availability of the + Differentiated Services model [RFC2474]. IPv6 packets carrying a + non-default Differentiated Services Code Point (DSCP) value in their + Traffic Class field [RFC2460] MUST be specially encoded using green + or blue ink such that the DSCP is externally visible. Note that red + ink MUST NOT be used to avoid confusion with the usage of red paint + specified in RFC 2549. + + RFC 2549 did not consider the impact on quality of service of + different types of carriers. There is a broad range. Some are very + fast but can only carry small payloads and transit short distances, + others are slower but carry large payloads and transit very large + distances. It may be appropriate to select the individual carrier + for a packet on the basis of its DSCP value. Indeed, 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. Similarly, routing + carriers through the territory of predatory carriers may potentially + cause severe packet loss. It is strongly recommended that these + factors be considered in the routing algorithm used to create carrier + routing tables. Implementers should consider policy-based routing to + ensure reliable packet delivery by routing around areas where + territorial and predatory carriers are prevalent. + + There is evidence that some carriers have a propensity to eat other + carriers and then carry the eaten payloads. Perhaps this provides a + new way to tunnel an IPv4 packet in an IPv6 payload, or vice versa. + + + + +Carpenter & Hinden Informational [Page 4] + +RFC 6214 IPv6 and RFC 1149 1 April 2011 + + + However, the decapsulation mechanism is unclear at the time of this + writing. + +6. Multihoming Considerations + + Some types of carriers are notoriously good at homing. Surprisingly, + this property is not mentioned in RFC 1149. Unfortunately, they + prove to have no talent for multihoming, and in fact enter a routing + loop whenever multihoming is attempted. This appears to be a + fundamental restriction on the topologies in which both RFC 1149 and + the present specification can be deployed. + +7. Internationalization Considerations + + In some locations, such as New Zealand, a significant proportion of + carriers are only able to execute short hops, and only at times when + the background level of photon emission is extremely low. This will + impact the availability and throughput of the solution in such + locations. + +8. Security Considerations + + The security considerations of [RFC1149] apply. In addition, recent + experience suggests that the transmission elements are exposed to + many different forms of denial-of-service attacks, especially when + perching. Also, the absence of link layer identifiers referred to + above, combined with the lack of checksums in the IPv6 header, + basically means that any transmission element could be mistaken for + any other, with no means of detecting the substitution at the network + layer. The use of an upper-layer security mechanism of some kind + seems like a really good idea. + + There is 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. We acknowledge in advance the many errata in + this document that will be reported by Alfred Hoenes. + + This document was produced using the xml2rfc tool [RFC2629]. + + + +Carpenter & Hinden Informational [Page 5] + +RFC 6214 IPv6 and RFC 1149 1 April 2011 + + +11. References + +11.1. Normative References + + [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 + + [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. + + + + + + +Carpenter & Hinden Informational [Page 6] + +RFC 6214 IPv6 and RFC 1149 1 April 2011 + + + [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 + + 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 + + + + + + + + + + + + + + + + + + + +Carpenter & Hinden Informational [Page 7] + -- cgit v1.2.3