summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2529.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2529.txt')
-rw-r--r--doc/rfc/rfc2529.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc2529.txt b/doc/rfc/rfc2529.txt
new file mode 100644
index 0000000..912d6da
--- /dev/null
+++ b/doc/rfc/rfc2529.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group B. Carpenter
+Request for Comments: 2529 IBM
+Category: Standards Track C. Jung
+ 3Com
+ March 1999
+
+
+ Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+Abstract
+
+ This memo specifies the frame format for transmission of IPv6 [IPV6]
+ packets and the method of forming IPv6 link-local addresses over IPv4
+ domains. It also specifies the content of the Source/Target Link-
+ layer Address option used in the Router Solicitation, Router
+ Advertisement, Neighbor Solicitation, and Neighbor Advertisement and
+ Redirect messages, when those messages are transmitted on an IPv4
+ multicast network.
+
+ The motivation for this method is to allow isolated IPv6 hosts,
+ located on a physical link which has no directly connected IPv6
+ router, to become fully functional IPv6 hosts by using an IPv4 domain
+ that supports IPv4 multicast as their virtual local link. It uses
+ IPv4 multicast as a "virtual Ethernet".
+
+Table of Contents
+
+ 1. Introduction....................................................2
+ 2. Maximum Transmission Unit.......................................2
+ 3. Frame Format....................................................3
+ 4. Stateless Autoconfiguration and Link-Local Addresses............3
+ 5. Address Mapping -- Unicast......................................4
+ 6. Address Mapping -- Multicast....................................4
+ 7. Scaling and Transition Isues....................................5
+ 8. IANA Considerations.............................................6
+ 9. Security Considerations.........................................6
+
+
+
+Carpenter & Jung Standards Track [Page 1]
+
+RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
+
+
+ Acknowledgements...................................................7
+ References.........................................................7
+ APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery........8
+ Authors' Addresses.................................................9
+ Full Copyright Notice.............................................10
+
+1. Introduction
+
+ This memo specifies the frame format for transmission of IPv6 [IPV6]
+ packets and the method of forming IPv6 link-local addresses over IPv4
+ multicast "domains". For the purposes of this document, an IPv4
+ domain is a fully interconnected set of IPv4 subnets, within the same
+ local multicast scope, on which there are at least two IPv6 nodes
+ conforming to this specification. This IPv4 domain could form part
+ of the globally-unique IPv4 address space, or could form part of a
+ private IPv4 network [RFC 1918].
+
+ This memo also specifies the content of the Source/Target Link-layer
+ Address option used in the Router Solicitation, Router Advertisement,
+ Neighbor Solicitation, Neighbor Advertisement and Redirect messages
+ described in [DISC], when those messages are transmitted on an IPv4
+ multicast domain.
+
+ The motivation for this method is to allow isolated IPv6 hosts,
+ located on a physical link which has no directly connected IPv6
+ router, to become fully functional IPv6 hosts by using an IPv4
+ multicast domain as their virtual local link. Thus, at least one
+ IPv6 router using the same method must be connected to the same IPv4
+ domain if IPv6 routing to other links is required.
+
+ IPv6 hosts connected using this method do not require IPv4-compatible
+ addresses or configured tunnels. In this way IPv6 gains considerable
+ independence of the underlying links and can step over many hops of
+ IPv4 subnets. The mechanism is known formally as "IPv6 over IPv4" or
+ "6over4" and colloquially as "virtual Ethernet".
+
+ 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].
+
+2. Maximum Transmission Unit
+
+ The default MTU size for IPv6 packets on an IPv4 domain is 1480
+ octets. This size may be varied by a Router Advertisement [DISC]
+ containing an MTU option which specifies a different MTU, or by
+ manual configuration of each node.
+
+
+
+
+
+Carpenter & Jung Standards Track [Page 2]
+
+RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
+
+
+ Note that if by chance the IPv6 MTU size proves to be too large for
+ some intermediate IPv4 subnet, IPv4 fragmentation will ensue. While
+ undesirable, this is not disastrous. However, the IPv4 "do not
+ fragment" bit MUST NOT be set in the encapsulating IPv4 header.
+
+3. Frame Format
+
+ IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4
+ protocol type of 41, the same as has been assigned in [RFC 1933] for
+ IPv6 packets that are tunneled inside of IPv4 frames. The IPv4
+ header contains the Destination and Source IPv4 addresses. The IPv4
+ packet body contains the IPv6 header followed immediately by the
+ payload.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| IHL |Type of Service| Total Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identification |Flags| Fragment Offset |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time to Live | Protocol 41 | Header Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Destination Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options | Padding |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IPv6 header and payload ... /
+ +-------+-------+-------+-------+-------+------+------+
+
+ If there are IPv4 options, then padding SHOULD be added to the IPv4
+ header such that the IPv6 header starts on a boundary that is a 32-
+ bit offset from the end of the datalink header.
+
+ The Time to Live field SHOULD be set to a low value, to prevent such
+ packets accidentally leaking from the IPv4 domain. This MUST be a
+ configurable parameter, with a recommended default of 8.
+
+4. Stateless Autoconfiguration and Link-Local Addresses
+
+ The Interface Identifier [AARCH] of an IPv4 interface is the 32-bit
+ IPv4 address of that interface, with the octets in the same order in
+ which they would appear in the header of an IPv4 packet, padded at
+ the left with zeros to a total of 64 bits. Note that the "Universal/
+ Local" bit is zero, indicating that the Interface Identifer is not
+ globally unique. When the host has more than one IPv4 address in use
+
+
+
+Carpenter & Jung Standards Track [Page 3]
+
+RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
+
+
+ on the physical interface concerned, an administrative choice of one
+ of these IPv4 addresses is made.
+
+ An IPv6 address prefix used for stateless autoconfiguration [CONF] of
+ an IPv4 interface MUST have a length of 64 bits except for a special
+ case mentioned in Section 7.
+
+ The IPv6 Link-local address [AARCH] for an IPv4 virtual interface is
+ formed by appending the Interface Identifier, as defined above, to
+ the prefix FE80::/64.
+
+ +-------+-------+-------+-------+-------+-------+------+------+
+ | FE 80 00 00 00 00 00 00 |
+ +-------+-------+-------+-------+-------+-------+------+------+
+ | 00 00 | 00 | 00 | IPv4 Address |
+ +-------+-------+-------+-------+-------+-------+------+------+
+
+5. Address Mapping -- Unicast
+
+ The procedure for mapping IPv6 addresses into IPv4 virtual link-layer
+ addresses is described in [DISC]. The Source/Target Link-layer
+ Address option has the following form when the link layer is IPv4.
+ Since the length field is in units of 8 bytes, the value below is 1.
+
+ +-------+-------+-------+-------+-------+-------+-------+-------+
+ | Type |Length | must be zero | IPv4 Address |
+ +-------+-------+-------+-------+-------+-------+-------+-------+
+
+
+ Type:
+ 1 for Source Link-layer address.
+ 2 for Target Link-layer address.
+
+ Length:
+ 1 (in units of 8 octets).
+
+ IPv4 Address:
+
+ The 32 bit IPv4 address, in network byte order. This is the address
+ the interface currently responds to, and may be different from the
+ Interface Identifier for stateless autoconfiguration.
+
+6. Address Mapping -- Multicast
+
+ IPv4 multicast MUST be available. An IPv6 packet with a multicast
+ destination address DST MUST be transmitted to the IPv4 multicast
+ address of Organization-Local Scope using the mapping below. These
+ IPv4 multicast addresses SHOULD be taken from the block
+
+
+
+Carpenter & Jung Standards Track [Page 4]
+
+RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
+
+
+ 239.192.0.0/16, a sub-block of the Organization-Local Scope address
+ block, or, if all of those are not available, from the expansion
+ blocks defined in [ADMIN]. Note that when they are formed using the
+ expansion blocks, they use only a /16 sized block.
+
+ +-------+-------+-------+-------+
+ | 239 | OLS | DST14 | DST15 |
+ +-------+-------+-------+-------+
+
+ DST14, DST15 last two bytes of IPv6 multicast address.
+
+ OLS from the configured Organization-Local
+ Scope address block. SHOULD be 192,
+ see [ADMIN] for details.
+
+ No new IANA registration procedures are required for the above. See
+ appendix A. for a list of all the multicast groups that must be
+ joined to support Neighbor Discovery.
+
+7. Scaling and Transition Issues
+
+ The multicast mechanism described in Section 6 above appears to have
+ essentially the same scaling properties as native IPv6 over most
+ media, except for the slight reduction in MTU size which will
+ slightly reduce bulk throughput. On an ATM network, where IPv4
+ multicast relies on relatively complex mechanisms, it is to be
+ expected that IPv6 over IPv4 over ATM will perform less well than
+ native IPv6 over ATM.
+
+ The "IPv6 over IPv4" mechanism is intended to take its place in the
+ range of options available for transition from IPv4 to IPv6. In
+ particular it allows a site to run both IPv4 and IPv6 in coexistence,
+ without having to configure IPv6 hosts either with IPv4-compatible
+ addresses or with tunnels. Interfaces of the IPv6 router and hosts
+ will of course need to be enabled in "6over4" mode.
+
+ A site may choose to start its IPv6 transition by configuring one
+ IPv6 router to support "6over4" on an interface connected to the
+ site's IPv4 domain, and another IPv6 format on an interface connected
+ to the IPv6 Internet. Any enabled "6over4" hosts in the IPv4 domain
+ will then be able to communicate both with the router and with the
+ IPv6 Internet, without manual configuration of a tunnel and without
+ the need for an IPv4-compatible IPv6 address, either stateless or
+ stateful address configuration providing the IPv6 address to the IPv6
+ host.
+
+
+
+
+
+
+Carpenter & Jung Standards Track [Page 5]
+
+RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
+
+
+ During transition, routers may need to advertise at least two IPv6
+ prefixes, one for the native LAN (e.g. Ethernet) and one for
+ "6over4". As with any IPv6 prefix assigned to an IPv6 subnet, the
+ latter MUST be unique within its scope, whether site-local or global
+ addressing is used.
+
+ Also note that when a router is handling both native LAN and "6over4"
+ on the same physical interface, during stateless autoconfiguration,
+ there is a period when IPv6 link-local addresses are used, in both
+ cases with the prefix FE80::/64. Note that the prefix-length for
+ these link-local adddress MUST then be 128 so that the two cases can
+ be distinguished.
+
+ As the site installs additional IPv6 routers, "6over4" hosts which
+ become physically adjacent to IPv6 routers can be changed to run as
+ native IPv6 hosts, with the the only impact on IPv6 applications
+ being a slight increase in MTU size. At some stage during transition,
+ it might be convenient to dual home hosts in both native LAN and
+ "6over4" mode, but this is not required.
+
+8. IANA Considerations
+
+ No assignments by the IANA are required beyond those in [ADMIN].
+
+9. Security Considerations
+
+ Implementors should be aware that, in addition to posssible attacks
+ against IPv6, security attacks against IPv4 must also be considered.
+ Use of IP security at both IPv4 and IPv6 levels should nevertheless
+ be avoided, for efficiency reasons. For example, if IPv6 is running
+ encrypted, encryption of IPv4 would be redundant except if traffic
+ analysis is felt to be a threat. If IPv6 is running authenticated,
+ then authentication of IPv4 will add little. Conversely, IPv4
+ security will not protect IPv6 traffic once it leaves the IPv6-over-
+ IPv4 domain. Therefore, implementing IPv6 security is required even
+ if IPv4 security is available.
+
+ There is a possible spoofing attack in which spurious 6over4 packets
+ are injected into a 6over4 domain from outside. Thus, boundary
+ routers MUST discard multicast IPv4 packets with source or
+ destination multicast addresses of organisation local scope as
+ defined in section 6 above, if they arrive on physical interfaces
+ outside that scope. To defend against spurious unicast 6over4
+ packets, boundary routers MUST discard incoming IPv4 packets with
+ protocol type 41 from unknown sources, i.e. IPv6-in-IPv4 tunnels
+ must only be accepted from trusted sources. Unless IPSEC
+
+
+
+
+
+Carpenter & Jung Standards Track [Page 6]
+
+RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
+
+
+ authentication is available, the RECOMMENDED technique for this is to
+ configure the boundary router only to accept protocol type 41 packets
+ from source addresses within a trusted range or ranges.
+
+Acknowledgements
+
+ The basic idea presented above is not original, and we have had
+ invaluable comments from Matt Crawford, Steve Deering, Dan
+ Harrington, Rich Draves, Erik Nordmark, Quang Nguyen, Thomas Narten,
+ and other members of the IPNG and NGTRANS working groups.
+
+ This document is seriously ripped off from RFC 1972 written by Matt
+ Crawford. Brian Carpenter was at CERN when the work was started.
+
+References
+
+ [AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
+
+ [ADMIN] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
+ RFC 2365, July 1998.
+
+ [CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address
+ Autoconfiguration", RFC 2462, December 1998.
+
+ [DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
+ Discovery for IP Version 6 (IPv6)", RFC 2461, December
+ 1998.
+
+ [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
+ 1981.
+
+ [RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.
+ and E. Lear, "Address Allocation for Private Internets",
+ RFC 1918, February 1996.
+
+ [RFC 1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
+ IPv6 Hosts and Routers", RFC 1933, April 1996.
+
+ [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC 1972] Crawford, M., "A Method for the Transmission of IPv6
+ Packets over Ethernet Networks", RFC 1972, August 1996.
+
+
+
+
+Carpenter & Jung Standards Track [Page 7]
+
+RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
+
+
+APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery
+
+ The following IPv4 multicast groups are used to support Neighbor
+ Discovery with this specification. The IPv4 addresses listed in this
+ section were obtained by looking at the IPv6 multicast addresses that
+ Neigbour Discovery uses, and deriving the resulting IPv4 "virtual
+ link-layer" addresses that are generated from them using the
+ algorithm given in Section 6.
+
+ all-nodes multicast address
+ - the administratively-scoped IPv4 multicast address used to
+ reach all nodes in the local IPv4 domain supporting this
+ specification. 239.OLS.0.1
+
+ all-routers multicast address
+ - the administratively-scoped IPv4 multicast address to reach
+ all routers in the local IPv4 domain supporting this
+ specification. 239.OLS.0.2
+
+ solicited-node multicast address
+ - an administratively scoped multicast address that is computed
+ as a function of the solicited target's address by taking the
+ low-order 24 bits of the IPv4 address used to form the IPv6
+ address, and prepending the prefix FF02:0:0:0:0:1:FF00::/104
+ [AARCH]. This is then mapped to the IPv4 multicast address by
+ the method described in this document. For example, if the
+ IPv4 address used to form the IPv6 address is W.X.Y.Z, then
+ the IPv6 solicited node multicast address is
+ FF02::1:255.X.Y.Z and the corresponding IPv4 multicast
+ address is 239.OLS.Y.Z
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter & Jung Standards Track [Page 8]
+
+RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
+
+
+Authors' Addresses
+
+ Brian E. Carpenter
+ Internet Division
+ IBM United Kingdom Laboratories
+ MP 185, Hursley Park
+ Winchester, Hampshire S021 2JN, UK
+
+ EMail: brian@hursley.ibm.com
+
+
+ Cyndi Jung
+ 3Com Corporation
+ 5400 Bayfront Plaza, Mailstop 3219
+ Santa Clara, California 95052-8145
+
+ EMail: cmj@3Com.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter & Jung Standards Track [Page 9]
+
+RFC 2529 Transmission of IPv6 Packets over IPv4 March 1999
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter & Jung Standards Track [Page 10]
+