Protocol Action: Transmission of IPv6 over IPv4 Domains without Explicit Tunnels to Proposed Standard
The IESG <iesg-secretary@ietf.org> Tue, 02 February 1999 18:15 UTC
Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id NAA27582 for ietf-123-outbound.10@ietf.org; Tue, 2 Feb 1999 13:15:02 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA27528; Tue, 2 Feb 1999 13:14:02 -0500 (EST)
Message-Id: <199902021814.NAA27528@ietf.org>
To: IETF-Announce:;
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: ipng@sunroof.eng.sun.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Transmission of IPv6 over IPv4 Domains without Explicit Tunnels to Proposed Standard
Date: Tue, 02 Feb 1999 13:14:02 -0500
Sender: scoya@ns.cnri.reston.va.us
The IESG has approvedTransmission of IPv6 over IPv4 Domains without Explicit Tunnels <draft-ietf-ipngwg-6over4-02.txt> as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary This document specifies how to run IPv6 over an IPv4 multicast domain. The entire IPv4 cloud is treated as a virtual local link. 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." This document specifies the frame format for transmission of 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. Working Group Summary There was consensus in the WG for this approach. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. Note to RFC Editor: RFC 1972 is mentioned in the text, but is not listed in the references. Please add a reference.