Difference between revisions of "RFC6214"
Line 5: | Line 5: | ||
1 April 2011 | 1 April 2011 | ||
− | Adaptation of RFC 1149 for IPv6 | + | Adaptation of [[RFC1149|RFC 1149]] for IPv6 |
'''Abstract''' | '''Abstract''' | ||
This document specifies a method for transmission of IPv6 datagrams | This document specifies a method for transmission of IPv6 datagrams | ||
− | over the same medium as specified for IPv4 datagrams in RFC 1149. | + | over the same medium as specified for IPv4 datagrams in [[RFC1149|RFC 1149]]. |
'''Status of This Memo''' | '''Status of This Memo''' | ||
Line 22: | Line 22: | ||
implementation or deployment. Documents approved for publication by | implementation or deployment. Documents approved for publication by | ||
the RFC Editor are not a candidate for any level of Internet | the RFC Editor are not a candidate for any level of Internet | ||
− | Standard; see Section 2 of RFC 5741. | + | Standard; see Section 2 of [[RFC5741|RFC 5741]]. |
Information about the current status of this document, any errata, | Information about the current status of this document, any errata, | ||
Line 33: | Line 33: | ||
document authors. All rights reserved. | document authors. All rights reserved. | ||
− | This document is subject to BCP 78 and the IETF Trust's Legal | + | This document is subject to [[BCP78|BCP 78]] and the IETF Trust's Legal |
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | ||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | ||
Line 42: | Line 42: | ||
== Introduction == | == Introduction == | ||
− | As shown by | + | As shown by [[RFC6036]], many service providers are actively planning |
to deploy IPv6 to alleviate the imminent shortage of IPv4 addresses. | to deploy IPv6 to alleviate the imminent shortage of IPv4 addresses. | ||
This will affect all service providers who have implemented | This will affect all service providers who have implemented | ||
− | + | [[RFC1149]]. It is therefore necessary, indeed urgent, to specify a | |
− | method of transmitting IPv6 datagrams | + | method of transmitting IPv6 datagrams [[RFC2460]] over the [[RFC1149|RFC 1149]] |
medium, rather than obliging those service providers to migrate to a | medium, rather than obliging those service providers to migrate to a | ||
different medium. This document offers such a specification. | different medium. This document offers such a specification. | ||
Line 54: | Line 54: | ||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||
− | document are to be interpreted as described in | + | document are to be interpreted as described in [[RFC2119]]. |
== Detailed Specification == | == Detailed Specification == | ||
− | Unless otherwise stated, the provisions of | + | Unless otherwise stated, the provisions of [[RFC1149]] and [[RFC2460]] |
apply throughout. | apply throughout. | ||
=== Maximum Transmission Unit === | === Maximum Transmission Unit === | ||
− | As noted in RFC 1149, the MTU is variable, and generally increases | + | As noted in [[RFC1149|RFC 1149]], the MTU is variable, and generally increases |
with increased carrier age. Since the minimum link MTU allowed by | with increased carrier age. Since the minimum link MTU allowed by | ||
− | RFC 2460 is 1280 octets, this means that older carriers MUST be used | + | [[RFC2460|RFC 2460]] is 1280 octets, this means that older carriers MUST be used |
− | for IPv6. RFC 1149 does not provide exact conversion factors between | + | for IPv6. [[RFC1149|RFC 1149]] does not provide exact conversion factors between |
age and milligrams, or between milligrams and octets. These | age and milligrams, or between milligrams and octets. These | ||
conversion factors are implementation dependent, but as an | conversion factors are implementation dependent, but as an | ||
illustrative example, we assume that the 256 milligram MTU suggested | illustrative example, we assume that the 256 milligram MTU suggested | ||
− | in RFC 1149 corresponds to an MTU of 576 octets. In that case, the | + | in [[RFC1149|RFC 1149]] corresponds to an MTU of 576 octets. In that case, the |
typical MTU for the present specification will be at least | typical MTU for the present specification will be at least | ||
256*1280/576, which is approximately 569 milligrams. Again as an | 256*1280/576, which is approximately 569 milligrams. Again as an | ||
Line 79: | Line 79: | ||
Furthermore, the MTU issues are non-linear with carrier age. That | Furthermore, the MTU issues are non-linear with carrier age. That | ||
is, a young carrier can only carry small payloads, an adult carrier | is, a young carrier can only carry small payloads, an adult carrier | ||
− | can carry jumbograms | + | can carry jumbograms [[RFC2675]], and an elderly carrier can again |
carry only smaller payloads. There is also an effect on transit time | carry only smaller payloads. There is also an effect on transit time | ||
depending on carrier age, affecting bandwidth-delay product and hence | depending on carrier age, affecting bandwidth-delay product and hence | ||
Line 86: | Line 86: | ||
=== Frame Format === | === Frame Format === | ||
− | RFC 1149 does not specify the use of any link layer tag such as an | + | [[RFC1149|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 | + | Ethertype or, worse, an OSI Link Layer or SNAP header [[RFC1042]]. |
Indeed, header snaps are known to worsen the quality of service | Indeed, header snaps are known to worsen the quality of service | ||
− | provided by RFC 1149 carriers. In the interests of efficiency and to | + | provided by [[RFC1149|RFC 1149]] carriers. In the interests of efficiency and to |
avoid excessive energy consumption while packets are in flight | avoid excessive energy consumption while packets are in flight | ||
through the network, no such link layer tag is required for IPv6 | through the network, no such link layer tag is required for IPv6 | ||
packets either. The frame format is therefore a pure IPv6 packet as | packets either. The frame format is therefore a pure IPv6 packet as | ||
− | defined in | + | defined in [[RFC2460]], encoded and decoded as defined in [[RFC1149]]. |
One important consequence of this is that in a dual-stack deployment | 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 | in the first four bits of every packet, as the only means to | ||
demultiplex a mixture of IPv4 and IPv6 packets. | demultiplex a mixture of IPv4 and IPv6 packets. | ||
Line 108: | Line 108: | ||
Similarly, there is no method to map an IPv6 unicast address to a | 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 | link layer address, since there is no link layer address in the first | ||
− | place. IPv6 Neighbor Discovery | + | place. IPv6 Neighbor Discovery [[RFC4861]] is therefore impossible. |
Implementations SHOULD NOT even try to use stateless address auto- | Implementations SHOULD NOT even try to use stateless address auto- | ||
− | configuration | + | configuration [[RFC4862]]. This recommendation is because this |
mechanism requires a stable interface identifier formed in a way | mechanism requires a stable interface identifier formed in a way | ||
− | compatible with | + | compatible with [[RFC4291]]. Unfortunately the transmission elements |
− | specified by RFC 1149 are not generally stable enough for this and | + | specified by [[RFC1149|RFC 1149]] are not generally stable enough for this and |
may become highly unstable in the presence of a cross-wind. | may become highly unstable in the presence of a cross-wind. | ||
Line 123: | Line 123: | ||
=== Multicast === | === Multicast === | ||
− | RFC 1149 does not specify a multicast address mapping. It has been | + | [[RFC1149|RFC 1149]] does not specify a multicast address mapping. It has been |
reported that attempts to implement IPv4 multicast delivery have | reported that attempts to implement IPv4 multicast delivery have | ||
resulted in excessive noise in transmission elements, with subsequent | resulted in excessive noise in transmission elements, with subsequent | ||
Line 131: | Line 131: | ||
== Quality-of-Service Considerations == | == 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 | + | of [[RFC2549|RFC 2549]] did not take account of the availability of the |
− | Differentiated Services model | + | Differentiated Services model [[RFC2474]]. IPv6 packets carrying a |
non-default Differentiated Services Code Point (DSCP) value in their | non-default Differentiated Services Code Point (DSCP) value in their | ||
− | Traffic Class field | + | Traffic Class field [[RFC2460]] MUST be specially encoded using green |
or blue ink such that the DSCP is externally visible. Note that red | 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 | ink MUST NOT be used to avoid confusion with the usage of red paint | ||
− | specified in RFC 2549. | + | specified in [[RFC2549|RFC 2549]]. |
− | RFC 2549 did not consider the impact on quality of service of | + | [[RFC2549|RFC 2549]] did not consider the impact on quality of service of |
different types of carriers. There is a broad range. Some are very | different types of carriers. There is a broad range. Some are very | ||
fast but can only carry small payloads and transit short distances, | fast but can only carry small payloads and transit short distances, | ||
Line 171: | Line 171: | ||
Some types of carriers are notoriously good at homing. Surprisingly, | Some types of carriers are notoriously good at homing. Surprisingly, | ||
− | this property is not mentioned in RFC 1149. Unfortunately, they | + | this property is not mentioned in [[RFC1149|RFC 1149]]. Unfortunately, they |
prove to have no talent for multihoming, and in fact enter a routing | prove to have no talent for multihoming, and in fact enter a routing | ||
loop whenever multihoming is attempted. This appears to be a | loop whenever multihoming is attempted. This appears to be a | ||
− | fundamental restriction on the topologies in which both RFC 1149 and | + | fundamental restriction on the topologies in which both [[RFC1149|RFC 1149]] and |
the present specification can be deployed. | the present specification can be deployed. | ||
Line 187: | Line 187: | ||
== Security Considerations == | == Security Considerations == | ||
− | The security considerations of | + | The security considerations of [[RFC1149]] apply. In addition, recent |
experience suggests that the transmission elements are exposed to | experience suggests that the transmission elements are exposed to | ||
many different forms of denial-of-service attacks, especially when | many different forms of denial-of-service attacks, especially when | ||
Line 212: | Line 212: | ||
this document that will be reported by Alfred Hoenes. | this document that will be reported by Alfred Hoenes. | ||
− | This document was produced using the xml2rfc tool | + | This document was produced using the xml2rfc tool [[RFC2629]]. |
11. References | 11. References | ||
Line 218: | Line 218: | ||
11.1. Normative References | 11.1. Normative References | ||
− | + | [[RFC1149]] Waitzman, D., "Standard for the transmission of IP | |
− | datagrams on avian carriers", RFC 1149, April 1990. | + | datagrams on avian carriers", [[RFC1149|RFC 1149]], April 1990. |
− | + | [[RFC2119]] Bradner, S., "Key words for use in RFCs to Indicate | |
− | Requirement Levels", BCP 14, RFC 2119, March 1997. | + | Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997. |
− | + | [[RFC2460]] Deering, S. and R. Hinden, "Internet Protocol, | |
− | Version 6 (IPv6) Specification", RFC 2460, | + | Version 6 (IPv6) Specification", [[RFC2460|RFC 2460]], |
December 1998. | December 1998. | ||
− | + | [[RFC2474]] Nichols, K., Blake, S., Baker, F., and D. Black, | |
"Definition of the Differentiated Services Field | "Definition of the Differentiated Services Field | ||
− | (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, | + | (DS Field) in the IPv4 and IPv6 Headers", [[RFC2474|RFC 2474]], |
December 1998. | December 1998. | ||
− | + | [[RFC2675]] Borman, D., Deering, S., and R. Hinden, "IPv6 | |
− | Jumbograms", RFC 2675, August 1999. | + | Jumbograms", [[RFC2675|RFC 2675]], August 1999. |
− | + | [[RFC4213]] Nordmark, E. and R. Gilligan, "Basic Transition | |
− | Mechanisms for IPv6 Hosts and Routers", RFC 4213, | + | Mechanisms for IPv6 Hosts and Routers", [[RFC4213|RFC 4213]], |
October 2005. | October 2005. | ||
Line 247: | Line 247: | ||
October 2010. | October 2010. | ||
− | + | [[RFC1042]] Postel, J. and J. Reynolds, "Standard for the | |
transmission of IP datagrams over IEEE 802 | transmission of IP datagrams over IEEE 802 | ||
− | networks", STD 43, RFC 1042, February 1988. | + | networks", [[STD43|STD 43]], [[RFC1042|RFC 1042]], February 1988. |
− | + | [[RFC2549]] Waitzman, D., "IP over Avian Carriers with Quality | |
− | of Service", RFC 2549, April 1999. | + | of Service", [[RFC2549|RFC 2549]], April 1999. |
− | + | [[RFC2629]] Rose, M., "Writing I-Ds and RFCs using XML", | |
− | RFC 2629, June 1999. | + | [[RFC2629|RFC 2629]], June 1999. |
− | + | [[RFC4291]] Hinden, R. and S. Deering, "IP Version 6 Addressing | |
− | Architecture", RFC 4291, February 2006. | + | Architecture", [[RFC4291|RFC 4291]], February 2006. |
− | + | [[RFC4861]] Narten, T., Nordmark, E., Simpson, W., and H. | |
Soliman, "Neighbor Discovery for IP version 6 | Soliman, "Neighbor Discovery for IP version 6 | ||
− | (IPv6)", RFC 4861, September 2007. | + | (IPv6)", [[RFC4861|RFC 4861]], September 2007. |
− | + | [[RFC4862]] Thomson, S., Narten, T., and T. Jinmei, "IPv6 | |
− | Stateless Address Autoconfiguration", RFC 4862, | + | Stateless Address Autoconfiguration", [[RFC4862|RFC 4862]], |
September 2007. | September 2007. | ||
− | + | [[RFC6036]] Carpenter, B. and S. Jiang, "Emerging Service | |
− | Provider Scenarios for IPv6 Deployment", RFC 6036, | + | Provider Scenarios for IPv6 Deployment", [[RFC6036|RFC 6036]], |
October 2010. | October 2010. | ||
Latest revision as of 05:22, 22 October 2020
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.
Contents
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.
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.
Detailed Specification
Unless otherwise stated, the provisions of RFC1149 and RFC2460 apply throughout.
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
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.
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.
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.
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.
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.
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.
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.
However, the decapsulation mechanism is unclear at the time of this writing.
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.
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.
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.
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.
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.
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: [email protected]
Robert M. Hinden Check Point Software Technologies, Inc. 800 Bridge Parkway Redwood City, CA 94065 US
Phone: +1.650.387.6118 EMail: [email protected]