NGTRANS Working Group F. Templin
INTERNET-DRAFT Nokia
T. Gleeson
Cisco Systems K.K.
M. Lehman
Microsoft
Expires 1 May 2003 1 November 2002
ISATAP Transition Scenario for Enterprise/Managed Networks
draft-ietf-ngtrans-isatap-scenario-01.txt
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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
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-
cast)
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-
figuration
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-
vice.
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
[NAT]
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].
Acknowledgments
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
Nokia
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
Microsoft
One Microsoft Way
Redmond, WA 98052 USA
Phone: (206)-826-5160
Email: mlehman@microsoft.com
Templin, et. al. Expires 1 May 2003 [Page 6]
