[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

NGTRANS Working Group                                         F. Templin
INTERNET-DRAFT                                                     Nokia
                                                              T. Gleeson
                                                      Cisco Systems K.K.
                                                               M. Lehman

Expires 1 May 2003                                       1 November 2002

       ISATAP Transition Scenario for Enterprise/Managed Networks


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   This document discusses application of the Intra-Site Automatic
   Tunnel Addressing Protocol (ISATAP) as a transition tool for
   enterprise/managed networks. The enterprise/manged network problem
   space is described, and the ISATAP transition scenario for
   enterprise/managed network environments is presented.

Templin, et. al.           Expires 1 May 2003                   [Page 1]

Internet Draft         ISATAP Transition Scenario        1 November 2002

1.  Introduction

   The Intra-Site Automatic Tunnel Addressing Protocol [ISATAP] is an
   NGTRANS mechanism intended for use within arbitrarily large enter-
   prise/managed networks. Examples include corporate intranets and aca-
   demic campus networks. This document describes the enterprise/managed
   network problem space and the role of ISATAP within that space.

2.  Enterprise/Managed Network Problem Space

   Enterprise/managed networks include corporate and academic campus
   networks (sometimes known as "intranets") that fall under the control
   of a single administrative authority. The administrative authority
   may be centralized or distributed, but is ordinarily governed by a
   commonality of interests and/or policies. These networks typically
   attach to the global Internet as "stub" networks such that all commu-
   nications originate and/or terminate internally, i.e., "transit" for
   foreign traffic is normally blocked by policy restrictions.

   Enterprise/managed networks may be arbitrarily large (in both the
   topological and geographical sense) and may peer with the global
   Internet at multiple border gateways. They may deploy security mecha-
   nisms such as firewalls, proxies, packet filters, etc. to protect
   intellectual property and other private assets, but the same proto-
   cols and services available in the global Internet are typically sup-
   ported. Enterprise/managed networks are usually constrained by a con-
   servative change/upgrade policy, and in contrast to many service
   provider networks they are characterized by having a large number of
   leaf nodes which are often difficult to manage. This makes automation
   of transition mechanisms critical.

   Many nodes (hosts and routers) in existing enterprise/managed net-
   works still communicate using the legacy IPv4 Internet protocol, with
   IPv4 addresses allocated from either globally assigned prefixes or
   prefixes from private address spaces. Such networks require transi-
   tion scenario analysis and transition mechanisms to enable seamless
   migration to IPv6. In the following sections, we present the antici-
   pated transition scenario for ISATAP in Enterprise/Managed networks
   and demonstrate ISATAP's applicability for such environments.

3.  Enterprise/Managed Network Transition Scenario for ISATAP

   [ISATAP] specifies a "simple, scalable approach that enables incre-
   mental deployment of IPv6 within IPv4-based sites". The document does
   not define "site", nor does it place any limits on the topological or
   geographical scope that a site might cover.  But, [ISATAP,2]

Templin, et. al.           Expires 1 May 2003                   [Page 2]

Internet Draft         ISATAP Transition Scenario        1 November 2002

   ("Applicability Statement") and [ISATAP,6] ("ISATAP Deployment Con-
   siderations") describe functional and operational aspects of ISATAP
   that appear to provide a good fit for the enterprise/managed network
   problem space.

   The transition scenario for ISATAP in an enterprise/managed network
   begins with an administrative decision to enable the service. First,
   the administrative authority identifies (or deploys) one or more
   router(s) to carry the ISATAP service. Each such router must config-
   ure one or more native IPv4 link(s) and zero or more native IPv6
   link(s).  An interface for automatic IPv6-in-IPv4 tunneling is con-
   figured over one or more IPv4 links that will support ISATAP routing.
   (Some of these links may also configure IPv6 natively, but this is
   not required.) Thus, the links configured for IPv6 may include any
   combination of native IPv6, IPv6-over-IPv4 tunnels, or (in some
   instances) no IPv6 links at all."

   After ISATAP routers have been deployed as described above, the
   administrative authority for the enterprise/managed network enters
   the IPv4 address(es) of each ISATAP routing interface into the DNS as
   described in [ISATAP, 5.2.1]. Following this action, hosts that
   enable ISATAP will begin to automatically discover ISATAP routers and
   thus gain access to the global IPv6 network. (Hosts may actually
   enable ISATAP prior to the administrative deployment of the service,
   but their ISATAP interfaces will have IPv6 link-local operation only
   until the first router becomes available.) No other administrative
   actions are necessary.

4.  Applicability

   [ISATAP,2] provides an applicability statement that shows direct rel-
   evance for enterprise/managed networks. We discuss each aspect of the
   applicability statement in the following subsections:

4.1.  Treats site's IPv4 infrastructure as an NBMA link layer using
automatic IPv6-in-IPv4 tunneling (i.e., no configured tunnel state)

   No configuration of tunnel endpoints is required - ISATAP is an
   "automatic tunneling" mechanism whereby the layer 2 (i.e. IPv4)
   address of other nodes within the ISATAP network is encoded in the
   layer 3 (i.e. IPv6) address.

   IPv6 destinations outside the enterprise/managed network are reached
   via a router within the enterprise/managed network, the latter being
   reached by the same ISATAP mechanisms.

Templin, et. al.           Expires 1 May 2003                   [Page 3]

Internet Draft         ISATAP Transition Scenario        1 November 2002

   Since ISATAP effectively forms an NBMA overlay on the enterprise/man-
   aged network, router discovery cannot proceed via standard broadcast
   discovery mechanisms. Instead, the recommended method is to use DNS
   resource records to store and distribute the list of routers. (Other
   mechanisms are also allowed, but not currently specified.)

4.2.  Enables incremental deployment of IPv6 hosts within IPv4 sites
with no aggregation scaling issues at border gateways

   Additional hosts can be added with no need for manual configuration
   (though this is possible, if desired). Such hosts will (when using
   the recommended mechanism) discover the set of ISATAP routers via a
   lookup of DNS resource record. These routers are polled (using ISATAP
   encapsulation) and auto-configuration can be performed, resulting in
   aggregation efficiency when many hosts configure addresses from pre-
   fixes advertised by the routers.

4.3.  Requires no special IPv4 services within the site (e.g., multi-

   IPv4 unicast connectivity within the enterprise/managed network is,
   of course, required. ISATAP recommends the use of the DNS for estab-
   lishing essential state, (the list of site ISATAP routers) but apart
   from this, no other special IPv4 services are required.

4.4.  Supports both stateless address autoconfiguration and manual con-

   Stateless address configuration has many benefits, and ISATAP enables
   this by the establishment of a list of potential routers in every
   node within the enterprise/managed network participating in the ser-

4.5.  Supports networks that use non-globally unique IPv4 addresses
(e.g., when private address allocations [PRIVATE] are used), but does
not allow the virtual ISATAP link to span a Network Address Translator

   ISATAP uses IPv4 as a layer 2 transport mechanism, but only within
   the enterprise/managed network itself. Thus the only requirement that
   ISATAP imposes on these addresses is that they be unique within the
   local scope - non-global addresses are perfectly usable. Off-site
   connectivity is achieved via IPv6 routing.

Templin, et. al.           Expires 1 May 2003                   [Page 4]

Internet Draft         ISATAP Transition Scenario        1 November 2002

4.6.  Compatible with other NGTRANS mechanisms (e.g., [6TO4])

   ISATAP encodes the layer 2 (i.e. IPv4) addresses within the interface
   identifier portion of an IPv6 address, so ISATAP is unconcerned with
   the higher-order part of an address. Thus ISATAP can be perfectly
   well used with global unicast addresses in general, and 6to4
   addresses in particular.

   Two different enterprise/managed networks, both using the same non-
   globally unique IPv4 addresses internally, and each provided with a
   single globally-unique IPv4 address for external connectivity through
   a NAT, can employ 6to4 for external connectivity and ISATAP for
   internal connectivity.

   6to4 encodes the globally-unique IPv4 address (representing the
   external point of connectivity) within the 6to4 prefix. ISATAP
   encodes the unique-within-the-site IPv4 address of a node within the
   interface identifier.

5.  IANA Considerations

   See [ISATAP, 7].

6.  Security Considerations

   See [ISATAP, 8].

   The authors acknowledge Alain Durand, Bob Hinden, and Margaret
   Wasserman for their helpful comments and/or guidance.

Normative References
   [ISATAP]   Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
              "Intra-Site Automatic Tunnel Addressing Protocol
              (ISATAP)", draft-ietf-ngtrans-isatap-06.txt, (work
              in progress).

Author's  Address:

   Fred L. Templin
   313 Fairchild Drive
   Mountain View, CA 94043 USA
   Phone: (650)-625-2331
   Email: ftemplin@iprg.nokia.com

Templin, et. al.           Expires 1 May 2003                   [Page 5]

Internet Draft         ISATAP Transition Scenario        1 November 2002

   Tim Gleeson
   Cisco Systems K.K.
   Shinjuku Mitsu Building
   2-1-1 Nishishinjuku, Shinjuku-ku
   Tokyo 163-0409, JAPAN
   Email: tgleeson@cisco.com

   Matthew Lehman
   One Microsoft Way
   Redmond, WA 98052 USA
   Phone: (206)-826-5160
   Email: mlehman@microsoft.com

Templin, et. al.           Expires 1 May 2003                   [Page 6]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/