Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
RFC 4214

Document Type RFC - Experimental (October 2005; No errata)
Obsoleted by RFC 5214
Last updated 2013-03-02
Stream ISE
Formats plain text pdf html
Stream ISE state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 4214 (Experimental)
Telechat date
Responsible AD David Kessens
Send notices to <dthaler@microsoft.com>, <tgleeson@cisco.com>, <mtalwar@isi.edu>, <templin@erg.sri.com>
Network Working Group                                         F. Templin
Request for Comments: 4214                                         Nokia
Category: Experimental                                        T. Gleeson
                                                      Cisco Systems K.K.
                                                               M. Talwar
                                                               D. Thaler
                                                   Microsoft Corporation
                                                            October 2005

        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 Notice

   Copyright (C) The Internet Society (2005).

IESG Note

   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.

Abstract

   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)
   model.

Templin, et al.               Experimental                      [Page 1]
RFC 4214                         ISATAP                     October 2005

1.  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.

2.  Requirements

   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.

3.  Terminology

   The terminology of [RFC2460][RFC2461] applies to this document.  The
   following additional terms are defined:

   ISATAP node:
      A node that implements the specifications in this document.

   ISATAP interface:
      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.

   ISATAP address:
      An IPv6 unicast address that matches an on-link prefix on an
      ISATAP interface of the node, and that includes an ISATAP
Show full document text