Network Working Group F. Templin
Request for Comments: 4214 Nokia
Category: Experimental T. Gleeson
Cisco Systems K.K.
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2005).
The content of this RFC was at one time considered by the IETF, and
therefore it may resemble a current IETF work in progress or a
published IETF work. This RFC is not a candidate for any level of
Internet Standard. The IETF disclaims any knowledge of the fitness
of this RFC for any purpose, and in particular notes that the
decision to publish is not based on IETF review for such things as
security, congestion control or inappropriate interaction with
deployed protocols. The RFC Editor has chosen to publish this
document at its discretion. Readers of this RFC should exercise
caution in evaluating its value for implementation and deployment.
See RFC 3932 for more information.
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects
IPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network
as a link layer for IPv6 and views other nodes on the network as
potential IPv6 hosts/routers. ISATAP supports an automatic tunneling
abstraction similar to the Non-Broadcast Multiple Access (NBMA)
Templin, et al. Experimental [Page 1]RFC 4214 ISATAP October 20051. Introduction
This document specifies a simple mechanism called the Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP) that connects IPv6
hosts/routers over IPv4 networks. Dual-stack (IPv6/IPv4) nodes use
ISATAP to automatically tunnel IPv6 packets in IPv4, i.e., ISATAP
views the IPv4 network as a link layer for IPv6 and views other nodes
on the network as potential IPv6 hosts/routers.
ISATAP enables automatic tunneling whether global or private IPv4
addresses are used, and presents a Non-Broadcast Multiple Access
(NBMA) abstraction similar to [RFC2491][RFC2492][RFC2529][RFC3056].
The main objectives of this document are to: 1) describe the domain
of applicability, 2) specify addressing requirements, 3) specify
automatic tunneling using ISATAP, 4) specify the operation of IPv6
Neighbor Discovery over ISATAP interfaces, and 5) discuss Site
Administration, Security, and IANA considerations.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [BCP14].
This document also uses internal conceptual variables to describe
protocol behavior and external variables that an implementation must
allow system administrators to change. The specific variable names,
how their values change, and how their settings influence protocol
behavior are provided in order to demonstrate protocol behavior. An
implementation is not required to have them in the exact form
described here, as long as its external behavior is consistent with
that described in this document.
The terminology of [RFC2460][RFC2461] applies to this document. The
following additional terms are defined:
A node that implements the specifications in this document.
An ISATAP node's Non-Broadcast Multi-Access (NBMA) IPv6 interface,
used for automatic tunneling of IPv6 packets in IPv4.
Templin, et al. Experimental [Page 2]RFC 4214 ISATAP October 2005
ISATAP interface identifier:
An IPv6 interface identifier with an embedded IPv4 address
constructed as specified in Section 6.1.
An IPv6 unicast address that matches an on-link prefix on an
ISATAP interface of the node, and that includes an ISATAP