summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6214.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6214.txt')
-rw-r--r--doc/rfc/rfc6214.txt395
1 files changed, 395 insertions, 0 deletions
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]
+