Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
RFC 2529
|
| Document |
Type |
|
RFC - Proposed Standard
(March 1999; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 2529 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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
Show full document text