draft-ietf-ngtrans-isatap-01.txt   draft-ietf-ngtrans-isatap-02.txt 
INTERNET-DRAFT Fred L. Templin
SRI International
17 May 2001
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
Copyright Notice NGTRANS Working Group Fred L. Templin
INTERNET-DRAFT SRI International
Expires 21 May 2001 21 November 2001
Placeholder for ISOC copyright. Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
draft-ietf-ngtrans-isatap-01.txt draft-ietf-ngtrans-isatap-02.txt
Abstract Abstract
This document specifies an intra-site automatic tunneling protocol This document specifies an intra-site automatic tunneling protocol
(ISATAP) for connecting IPv6 hosts and routers (nodes) within (ISATAP) for connecting IPv6 hosts and routers (nodes) within
predominantly IPv4-based networks. This method is based on an IPv6 predominantly IPv4-based networks. This method is based on an IPv6
aggregatable global unicast address format (described herein) that aggregatable global unicast address format (described herein) that
embeds the IPv4 address of a node within the EUI-64 format interface embeds the IPv4 address of a node within the EUI-64 format interface
identifier. This document assumes that, during the IPv4 to IPv6 co- identifier. This document assumes that, during the IPv4 to IPv6 co-
existence and transition phase, many sites will deploy IPv6 existence and transition phase, many sites will deploy IPv6
incrementally within their IPv4 interior routing domains; especially incrementally within their IPv4 interior routing domains; especially
those sites which have large and complex pre-existing IPv4 those sites which have large and complex pre-existing IPv4
infrastructures. Within such sites, the address format and methods infrastructures. Within such sites, the address format and methods
described in this document will enable IPv6 deployment for nodes that described in this document will enable IPv6 deployment for nodes that
do not share a common data link with an IPv6 gateway for their site. do not share a common link with an IPv6 gateway for their site.
While other works in progress in the NGTRANS working group propose While other works in progress in the NGTRANS working group propose
mechanisms for assigning globally-unique IPv6 address prefixes to mechanisms for assigning globally-unique IPv6 address prefixes to
sites and methods for inter-domain routing between such sites, the sites and methods for inter-domain routing between such sites, the
approach outlined in this memo enables large-scale incremental approach outlined in this memo enables large-scale incremental
deployment of IPv6 for nodes within a site's pre-existing IPv4 deployment of IPv6 for nodes within a site's pre-existing IPv4
infrastructure without incurring aggregation scaling issues at the infrastructure without incurring aggregation scaling issues at the
border gateways nor requiring site-wide deployment of special IPv4 border gateways nor requiring site-wide deployment of special IPv4
services such as multicast. The approach proposed by this document services such as multicast. The approach proposed by this document
supports IPv6 routing within both the site-local and global IPv6 supports IPv6 routing within both the site-local and global IPv6
skipping to change at page 2, line 19 skipping to change at page 2, line 16
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
1. Introduction 1. Introduction
The IETF NGTRANS working group anticipates an heterogeneous IPv4/IPv6 The IETF NGTRANS working group anticipates an heterogeneous IPv4/IPv6
infrastructure in the near future and thus is chartered to develop infrastructure in the near future and thus is chartered to develop
mechanisms to support IPv4/IPv6 coexistence and transition toward mechanisms to support IPv4/IPv6 coexistence and transition toward
global IPv6 deployment. For the most part, existing NGTRANS global IPv6 deployment. For the most part, existing NGTRANS
approaches focus on inter-domain routing between IPv6 islands using approaches focus on inter-domain routing between IPv6 islands using
the existing global IPv4 backbone as transit. But, these islands may the existing global IPv4 backbone as transit. But, these islands may
themselves comprise complex heterogeneous IPv4/IPv6 networks (e.g. themselves comprise complex heterogeneous IPv4/IPv6 networks (e.g.
large academic or commercial campus intranets) that require intra- large academic or commercial campus intranets) that require intra-
domain IPv4 to IPv6 transition mechanisms and strategies as well. In domain IPv4 to IPv6 transition mechanisms and strategies as well. In
order to address this requirement, this document presents a simple order to address this requirement, this document presents a simple
and scalable approach that enables incremental deployment of IPv6 and scalable approach that enables incremental deployment of IPv6
nodes within predominantly IPv4-based intranets. We refer to this nodes within predominantly IPv4-based intranets. We refer to this
approach as the Intra-Site Automatic Tunnel Addressing Protocol, or approach as the Intra-Site Automatic Tunnel Addressing Protocol, or
ISATAP (pronounced: "ice-a-tap"). ISATAP (pronounced: "ice-a-tap").
The ISATAP approach is based on an aggregatable global unicast ISATAP is based on an aggregatable global unicast address format that
address format that carries a standard 64-bit IPv6 address prefix carries a standard 64-bit IPv6 address prefix [ADDR][AGGR] with a
[ADDR][AGGR] with a specially-constructed 64-bit EUI-64 Interface specially-constructed 64-bit EUI-64 Interface Identifier [EUI64].
Identifier [EUI64]. This address format is fully compatible with This address format is fully compatible with both native IPv6 and
both native IPv6 and NGTRANS routing practices (e.g. [6to4],[6BONE]). NGTRANS routing practices (e.g. [6to4],[6BONE]). But, the interface
But, the interface identifier in an ISATAP address employs a special identifier in an ISATAP address employs a special construction that
construction (using the IEEE Organizationally Unique Identifier (OUI)
reserved by the Internet Assigned Numbers Authority [IANA]) that
encapsulates an IPv4 address suitable for automatic IPv6-in-IPv4 tun- encapsulates an IPv4 address suitable for automatic IPv6-in-IPv4 tun-
neling. Since tunneling occurs only within the site-level prefix of neling. Since tunneling occurs only within the site-level prefix of
the ISATAP address, the embedded IPv4 address NEED NOT be globally the ISATAP address, the embedded IPv4 address NEED NOT be globally
unique; rather, it need only be topologically correct for (and unique unique; rather, it need only be topologically correct for (and unique
within) the context of the site. within) the context of the site.
This approach allows dual-stack nodes that do not share a common ISATAP allows dual-stack nodes that do not share a common link with
datalink with an IPv6 gateway to join the global IPv6 network by an IPv6 gateway to join the global IPv6 network by automatically tun-
automatically tunneling IPv6 messages through the IPv4 routing neling IPv6 messages through the IPv4 routing infrastructure within
infrastructure within their site. Two methods for automatic discovery their site. Two methods for automatic discovery of an IPv6 gateway
of an off-link IPv6 gateway for ISATAP address autoconfiguration are for ISATAP address autoconfiguration are provided. This approach
provided. This approach allows large-scale intra-site deployment allows large-scale intra-site deployment without incurring aggrega-
without incurring aggregation scaling issues at the border gateways, tion scaling issues at border gateways, since only a single global
since only a single IPv6 address prefix is used for the entire site. IPv6 address prefix need be used for the entire site. (Multiple pre-
Finally, this approach supports intranets which use non-globally fixes are, however, supported and may be used for site renumbering
unique IPv4 addresses, such as when private address allocations and simliar purposes.) Finally, this approach supports networks which
[PRIVATE] and/or Network Address Translation [NAT] are used. use non-globally unique IPv4 addresses, such as when private address
allocations [PRIVATE] and/or Network Address Translation [NAT] are
used.
2. Changes 2. Changes
Major changes from version -00 to version -01: Major changes from version 01 to version 02:
- Cleaned up text and tightened up terminology. Changed "IPv6 destination
address" to "IPv6 next-hop address" under "sending rules". Changed
definition of ISATAP prefix to include link and site-local. Changed
language in sections 4 and 5
- Updated status of Linux implementation
Major changes from version 00 to version 01:
- Revised draft to require *different* /64 prefixs for ISATAP - Revised draft to require *different* /64 prefixs for ISATAP
addresses and native IPv6 addresses. Thus, a node's ISATAP addresses and native IPv6 addresses. Thus, a node's ISATAP
interface is assigned a /64 prefix that is distinct from the interface is assigned a /64 prefix that is distinct from the
prefixes assigned to any other interfaces attached to the prefixes assigned to any other interfaces attached to the
node - be they physical or logical interfaces. This approach node - be they physical or logical interfaces. This approach
eliminates ISATAP-specific sending rules presented in earlier eliminates ISATAP-specific sending rules presented in earlier
draft versions. draft versions.
- Changed sense of 'u/l' bit in the ISATAP address interface - Changed sense of 'u/l' bit in the ISATAP address interface
identifier to indicate "local scope", since ISATAP interface identifier to indicate "local scope", since ISATAP interface
identifiers are unique only within the scope of the ISATAP identifiers are unique only within the scope of the ISATAP
prefix. (See section 4.) prefix. (See section 4.)
Major changes from version personal draft to NGTRANS WG version -00: Major changes from personal draft to version 00:
- Title change to provide higher-level description of field of - Title change to provide higher-level description of field of
use addressed by this draft. Removed other extraneous text. use addressed by this draft. Removed other extraneous text.
- Major new section on automatic discovery of off-link IPv6 routers - Major new section on automatic discovery of off-link IPv6 routers
when IPv6-IPv4 compatibility addresses are used. when IPv6-IPv4 compatibility addresses are used.
3. Terminology 3. Terminology
The terminology of [IPv6] applies to this document. Additionally, the The terminology of [IPv6] applies to this document. Additionally, the
following terms are used extensively throughout this document: following terms are used extensively throughout this document:
ISATAP prefix: ISATAP prefix:
Any globally aggregatable 64-bit IPv6 routing prefix (whether from a Any link-local, site-local or globally aggregatable IPv6 prefix declared
native IPv6 assigned numbers authority or from a special-purpose numbering as such. An ISATAP prefix configures ONLY ISATAP addresses within its
scheme such as [6BONE][6TO4]) reserved by a local network administrator scope; native IPv6 addresses SHOULD NOT be configured on an ISATAP prefix.
specifically for ISATAP purposes. ISATAP prefixes are used to configure
ISATAP addresses ONLY; native IPv6 addresses SHOULD NOT be configured
using an ISATAP prefix.
ISATAP address: ISATAP address:
An IPv6 address with an ISATAP prefix and having an IPv4 address An IPv6 address with an ISATAP prefix and an IPv4 address embedded in
embedded in the interface identifier in the manner described in the interface identifier in the manner described in section 4 below.
section 4 below.
Native IPv6 address:
An IPv6 address constructed using a non-ISATAP prefix.
ISATAP pseudo-interface: ISATAP pseudo-interface:
ISATAP encapsulation of IPv6 packets inside IPv4 packets occurs ISATAP encapsulation of IPv6 packets inside IPv4 packets occurs
at a point that is logically equivalent to an IPv6 interface, at a point that is logically equivalent to an IPv6 interface,
with the link layer being the IPv4 unicast network. This point with the link layer being the IPv4 unicast network. This point
is referred to as a pseudo-interface. An ISATAP pseudo-interface is referred to as a pseudo-interface. An ISATAP pseudo-interface
is assigned an ISATAP address through address autoconfiguration. is assigned an ISATAP address through address autoconfiguration.
ISATAP router: ISATAP router:
An IPv6 router supporting an ISATAP pseudo-interface. It is normally An IPv6 router supporting an ISATAP pseudo-interface. It is normally
an interior router within an heterogeneous IPv6/IPv4 network. an interior router within an heterogeneous IPv6/IPv4 network.
ISATAP host: ISATAP host:
An IPv6 host which has an ISATAP pseudo-interface. An IPv6 host which has an ISATAP pseudo-interface.
4. ISATAP Address Format 4. ISATAP Address Format
In sections 4.1 and 4.2, we will motivate our proposed extensions of In the following sections, we will motivate our proposed extensions
the existing IEEE OUI reserved by IANA to support IEEE EUI-64 format of the existing IEEE OUI reserved by the Internet Assigned Numbers
addresses. While these proposed extensions are intended support the Authority [IANA] to support IEEE EUI-64 format addresses as well as
ISATAP address format, they also provide a flexible framework for the ISATAP address format itself.
future IANA use. Therefore, the extensions proposed in sections 4.1
and 4.2 may provide beneficial future use to IANA beyond the scope of
ISATAP addresses. We present the ISATAP address format itself in sec-
tions 4.3 and 4.4.
4.1. IEEE EUI-64 Interface Identifiers in IPv6 Addresses 4.1. IEEE EUI-64 Interface Identifiers in IPv6 Addresses
IPv6 aggregatable global and local-use unicast addresses [ADDR] IPv6 aggregatable global and local-use unicast addresses [ADDR]
include a 64-bit interface identifier in IEEE EUI-64 format [EUI64], include a 64-bit interface identifier in IEEE EUI-64 format [EUI64],
which is specified as the concatenation of a 24-bit company_id value which is specified as the concatenation of a 24-bit company_id value
(also known as the OUI) assigned by the IEEE Registration Authority (also known as the OUI) assigned by the IEEE Registration Authority
(IEEE/RAC) and a 40-bit extension identifier assigned by the address- (IEEE/RAC) and a 40-bit extension identifier assigned by the address-
ing authority for that OUI. (Normally, the addressing authority is ing authority for that OUI. (Normally, the addressing authority is
the organization to which the IEEE has allocated the OUI). IEEE EUI- the organization to which the IEEE has allocated the OUI). IEEE EUI-
skipping to change at page 7, line 32 skipping to change at page 7, line 48
FE80::0:5EFE:140.173.129.8 FE80::0:5EFE:140.173.129.8
FEC0::200:0:5EFE:140.173.129.8 FEC0::200:0:5EFE:140.173.129.8
4.4. Advantages 4.4. Advantages
By embedding an IPv4 address in the interface identifier portion of By embedding an IPv4 address in the interface identifier portion of
an IPv6 address as described in section 4.3, we can construct aggre- an IPv6 address as described in section 4.3, we can construct aggre-
gatable global unicast IPv6 addresses that can either be routed glo- gatable global unicast IPv6 addresses that can either be routed glo-
bally via the IPv6 infrastructure or automatically tunneled locally bally via the IPv6 infrastructure or automatically tunneled locally
across portions of a site's IPv4 infrastructure which have no native across portions of a site's IPv4 infrastructure which have no native
IPv6 support. Additionally, a node with an ISATAP address could act IPv6 support. Additionally, a node with both an ISATAP link and a
as a gateway for nodes with native IPv6 addresses with which it native IPv6 link could act as a router for nodes that share its
shares a common physical link, since the ISATAP node could automati- native link, since the ISATAP node could automatically tunnel mes-
cally tunnel messages across a site's IPv4 domain on behalf of the sages across a site's IPv4 domain on behalf of the native IPv6 nodes.
native IPv6 nodes. An example would be deployment of IPv6 on some An example would be deployment of IPv6 on a workgroup LAN. In this
subset of the hosts attached to a workgroup's LAN. In this case, one case, one host could configure an ISATAP address and act as a router
host could configure an ISATAP address and act as a gateway for other for other hosts which use native IPv6 addresses on the LAN.
hosts on the LAN which use native IPv6 addresses.
An additional advantage for our proposed method of embedding an IPv4 An additional advantage for our proposed method of embedding an IPv4
address in the interface identifier portion of an IPv6 address not address in the interface identifier portion of an IPv6 address not
found in other approaches such as [6TO4] is that large numbers of found in other approaches such as [6TO4] is that large numbers of
ISATAP addresses could be assigned within a common IPv6 routing pre- ISATAP addresses could be assigned within a common IPv6 routing pre-
fix, thus providing maximal aggregation at the border gateways. For fix, thus providing maximal aggregation at the border gateways. For
example, the single 64-bit IPv6 prefix: example, the single 64-bit IPv6 prefix:
3FFE:1a05:510:2412::/64 3FFE:1a05:510:2412::/64
skipping to change at page 8, line 23 skipping to change at page 8, line 38
analogy to the US Postal system, inter-domain transition approaches analogy to the US Postal system, inter-domain transition approaches
such as [6TO4] provide means for routing messages "cross-country" to such as [6TO4] provide means for routing messages "cross-country" to
the "street address" of a distant site while the approach outlined in the "street address" of a distant site while the approach outlined in
this document provides localized routing information to reach a this document provides localized routing information to reach a
specific (mailstop, apartment number, post office box, etc) WITHIN specific (mailstop, apartment number, post office box, etc) WITHIN
that site. Thus, the site-level routing information need not have that site. Thus, the site-level routing information need not have
relevance outside the scope of that site. relevance outside the scope of that site.
5. ISATAP Deployment Considerations 5. ISATAP Deployment Considerations
ISATAP addresses should only be used by nodes which do not share a Hosts should only use ISATAP on interfaces which do not share a com-
common datalink with a native IPv6 router. At least one ISATAP router mon link with a native IPv6 router. Routers may configure both ISATAP
must be configured within the site which advertises an and Native IPv6 links on the same physical interface, but the pre-
administratively- assigned ISATAP prefix in response to an Rtsol mes- fixes used will be distinct. An ISATAP router can be configured on
sage from an off-link host. Such off-link hosts will configure an any ISATAP link to advertise the prefix(es) administratively assigned
ISATAP pseudo-interface and assign it an address using the ISATAP to that link. Since ISATAP is NBMA, these advertisements are not
prefix it receives in an Rtadv message solicited from an ISATAP periodically multicast by the router, but are solicited by Rtsols
router. sent by hosts. Hosts will configure an ISATAP pseudo-interface and
assign it address(es) based on the ISATAP prefix(es) in the solicited
Rtadv messages.
Following ISATAP address configuration, ISATAP hosts automatically Following ISATAP address configuration, ISATAP hosts communicate as
and transparently communicate the IPv4 address of their *own* end of regular IPv6 peers. The source address of such packets will be in
the ISATAP tunnel to any ISATAP host or router which uses the same ISATAP format. Replies sent to this address can thus be automatically
ISATAP prefix. While nodes may optionally use stateful configuration tunneled over the last IPv6 hop, which occurs on the ISATAP network.
to set an ISATAP prefix and a "default" route that points to an ISA- While nodes may optionally use stateful configuration to set an ISA-
TAP router, a greatly preferred alternative is to provide for TAP prefix and a "default" route that points to an ISATAP router, a
automatic intra-site IPv6 router discovery and stateless address greatly preferred alternative is to provide for automatic intra-site
autoconfiguration [DISCUSS]. The following section presents a means IPv6 router discovery and stateless address autoconfiguration [DIS-
for the automatic discovery of ISATAP routers. CUSS]. The following section presents a means for the automatic
discovery of ISATAP routers.
5.1. Automatic Discovery of ISATAP Routers 5.1. Automatic Discovery of ISATAP Routers
As described in [AUTO], a node that does not share a common multiple As described in [AUTO], a node that does not share a common link with
access datalink with an IPv6 router will NOT receive unsolicited an IPv6 router will NOT receive unsolicited Router Advertisements
Router Advertisements (Rtadv's), nor will Router Solicitations (Rtadv's), nor will Router Solicitations (Rtsol's) from that node
(Rtsol's) from that node reach an IPv6 router on the local link. But, reach an IPv6 router on the local link. But, the node may still be
the node may still be able to connect to the global IPv6 Internet if able to connect to the global IPv6 Internet if an ISATAP router for
an ISATAP router for the site exists. Hence, a means for ISATAP the site exists. Hence, a means for ISATAP router discovery is
router discovery is required. We present the following procedure for required. We present the following procedure for a node to initiate
a node to initiate ISATAP router discovery (and for an ISATAP router ISATAP router discovery (and for an ISATAP router to respond) when an
to respond) when an on-link IPv6 router is not available: on-link IPv6 router is not available:
- The node constructs an ISATAP link local address for itself - The node constructs an ISATAP link local address for itself
(as described in section 4.) as: (as described in section 4.) as:
FE80::0:5EFE:V4ADDR_NODE FE80::0:5EFE:V4ADDR_NODE
- The node discovers the IPv4 address for an ISATAP router - The node discovers the IPv4 address for an ISATAP router
as: V4ADDR_RTR (**) as: V4ADDR_RTR (**)
- The node sends an Rtsol to the IPv6 "all-routers-multicast" address - The node sends an Rtsol to the IPv6 "all-routers-multicast" address
skipping to change at page 10, line 15 skipping to change at page 10, line 31
lish the IPv4 address of a gateway which implementations could use to lish the IPv4 address of a gateway which implementations could use to
discover V4ADDR_RTR. This method has the advantage that it can be discover V4ADDR_RTR. This method has the advantage that it can be
deployed immediately using existing mechanisms. However, it requires deployed immediately using existing mechanisms. However, it requires
name service lookups and may not always provide the optimum name service lookups and may not always provide the optimum
V4ADDR_RTR resolution for isolated hosts if multiple ISATAP routers V4ADDR_RTR resolution for isolated hosts if multiple ISATAP routers
are available. are available.
5.3. IPv4 Anycast for ISATAP routers 5.3. IPv4 Anycast for ISATAP routers
[6TO4ANY] proposes an IPv4 anycast prefix for 6to4 relay routers. [6TO4ANY] proposes an IPv4 anycast prefix for 6to4 relay routers.
The proposal suggests an IPv4 prefix assignment 'x.x.x.0/nn' ('nn' is The proposal suggests an IPv4 prefix assignment '192.88.99.0/24'
currently proposed as 16) where the single address 'x.x.x.1' is where the single address '192.88.99.1' is assigned as the "6to4 IPv6
assigned as the "6to4 IPv6 relay anycast address". We propose analo- relay anycast address". We propose analogous assignments for the pur-
gous assignments for the purpose of an "ISATAP router anycast pose of an "ISATAP router anycast address". (Whether the reservation
address". (Whether the reservation of a second /32 assignment from of a second /32 assignment from the 6to4 IPv4 anycast prefix proposed
the 6to4 IPv4 anycast prefix proposed in [6TO4ANY] would be possible, in [6TO4ANY] would be possible, or a separate prefix assignment would
or a separate prefix assignment would be required is a matter of be required is a matter of debate and TBD.)
debate and TBD.)
ISATAP routers would advertise the ISATAP router anycast prefix via ISATAP routers would advertise the ISATAP router anycast prefix via
the intra-domain IPv4 routing infrastructure. Isolated IPv6 nodes the intra-domain IPv4 routing infrastructure. Isolated IPv6 nodes
would then use the ISATAP router anycast address as the V4ADDR_RTR would then use the ISATAP router anycast address as the V4ADDR_RTR
IPv4 destination for off-link Rtsol's. This approach has the signifi- IPv4 destination for off-link Rtsol's. This approach has the signifi-
cant advantages that: cant advantages that:
- implementations could hard-code the well-known ISATAP - implementations could hard-code the well-known ISATAP
anycast address, thus avoiding service discovery via DNS anycast address, thus avoiding service discovery via DNS
skipping to change at page 10, line 35 skipping to change at page 11, line 4
the intra-domain IPv4 routing infrastructure. Isolated IPv6 nodes the intra-domain IPv4 routing infrastructure. Isolated IPv6 nodes
would then use the ISATAP router anycast address as the V4ADDR_RTR would then use the ISATAP router anycast address as the V4ADDR_RTR
IPv4 destination for off-link Rtsol's. This approach has the signifi- IPv4 destination for off-link Rtsol's. This approach has the signifi-
cant advantages that: cant advantages that:
- implementations could hard-code the well-known ISATAP - implementations could hard-code the well-known ISATAP
anycast address, thus avoiding service discovery via DNS anycast address, thus avoiding service discovery via DNS
- an optimum path to an ISATAP router would be ensured - an optimum path to an ISATAP router would be ensured
by intra-domain IPv4 routing by intra-domain IPv4 routing
As described above, the IPv4 anycast method for locating ISATAP As described above, the IPv4 anycast method for locating ISATAP
routers provides significant functional advantages over the DNS routers provides significant functional advantages over the DNS
approach, while the DNS approach can be implemented immediately pend- approach, while the DNS approach can be implemented immediately pend-
ing the registration of a WKS name with IANA. While either method ing the registration of a WKS name with IANA. While either method
will work, the decision of which to push for standardization is TBD will work, the decision of which to push for standardization is TBD
pending discussion at upcoming NGTRANS WG meetings. pending discussion at upcoming NGTRANS WG meetings.
6. Sending Rules and Routing Considerations 6. Sending Rules and Routing Considerations
Since each node will be assigned an ISATAP prefix which is adminis- Since each node will be assigned one or more ISATAP prefixes which
tratively reserved for use ONLY by ISATAP nodes, no special sending are administratively reserved for use ONLY by ISATAP nodes, no spe-
rules are needed. In particular, correspondent nodes that share a cial sending rules are needed. In particular, correspondent nodes
common ISATAP prefix will always exchange messages using their ISATAP that share a common ISATAP prefix will always exchange messages using
pseudo-interfaces, whereas nodes that do not share a common ISATAP their ISATAP pseudo-interfaces, whereas nodes that do not share a
prefix will always exchange messages via standard IPv6 routing. When common ISATAP prefix will always exchange messages via standard IPv6
sending a message on an ISATAP pseudo-interface, an implementation routing. When sending a message on an ISATAP pseudo-interface, an
SHOULD verify that the IPv6 destination address employs the ISATAP implementation SHOULD verify that the IPv6 next-hop address employs
address construction rules described in section 4 in order to detect the ISATAP address construction rules described in section 4 in order
mis-configured addresses. No other sending rules are necessary. to detect mis-configured addresses. No other sending rules are neces-
sary.
7. Address Selection 7. Address Selection
No special address selection rules are necessary. No special address selection rules are necessary.
8. Automatic Deprecation 8. Automatic Deprecation
ISATAP addresses are intended for use only by nodes which do not ISATAP addresses are intended for use only by nodes which do not
receive native IPv6 Rtadv's due to not sharing a common datalink with receive native IPv6 Rtadv's due to not sharing a common link with an
an IPv6 router. When native IPv6 Rtadv's become available (such as IPv6 router. When native IPv6 Rtadv's become available (such as when
when an IPv6 router is deployed on a node's datalink), the node an IPv6 router is deployed on a node's link), the node should con-
should construct a non-ISATAP aggregatable global IPv6 unicast struct a non-ISATAP aggregatable global IPv6 unicast address using
address using address auto-configuration [AUTO] for a non-ISATAP IPv6 address auto-configuration [AUTO] for a non-ISATAP IPv6 prefix
prefix discovered through normal means [DISC]. After the node's discovered through normal means [DISC]. After the node's native IPv6
native IPv6 address is populated in the DNS, the node should eventu- address is populated in the DNS, the node should eventually cease
ally cease sending Rtsol's to the ISATAP router and discontinue use sending Rtsol's to the ISATAP router and discontinue use of its ISA-
of its ISATAP pseudo-interface. In this way, ISATAP addresses will TAP pseudo-interface. In this way, ISATAP addresses will gradually
gradually (and automatically) disappear as IPv6 routers are widely (and automatically) disappear as IPv6 routers are widely deployed
deployed within sites. within sites.
9. Multicast Considerations 9. Multicast Considerations
Other works in progress [6TO4MULTI] are currently investigating mul- Other works in progress [6TO4MULTI] are currently investigating mul-
ticast addressing issues for [6TO4]. The address format discussed in ticast addressing issues for [6TO4]. The address format discussed in
this document is expected to be compatible with those emerging this document is expected to be compatible with those emerging
approaches. approaches.
10. IANA considerations 10. IANA considerations
skipping to change at page 12, line 15 skipping to change at page 12, line 29
address, and the ISATAP address format described in this document address, and the ISATAP address format described in this document
accomplishes this same goal. accomplishes this same goal.
Additional security issues are called out in [6TO4] and probably Additional security issues are called out in [6TO4] and probably
apply here as well. apply here as well.
12. Implementation status 12. Implementation status
The author has implemented the mechanisms described in this draft The author has implemented the mechanisms described in this draft
through modifications to the FreeBSD 3.2-RELEASE [FBSD] operating through modifications to the FreeBSD 3.2-RELEASE [FBSD] operating
system with the INRIA [INRIA] IPv6 distribution. A Linux implementa- system with the INRIA [INRIA] IPv6 distribution. As of November 12,
tion is planned for the June, 2001 timeframe. 2001, a Linux implementation is now integrated in the USAGI Linux
distribution [USAGI].
Additionally, Windows XP RC1 will implement elements of the mechanism Additionally, Windows XP RC1 will implement elements of the mechanism
proposed in this paper. proposed in this paper.
Acknowledgements Acknowledgements
The original ideas presented in this draft were derived from SRI con- The original ideas presented in this draft were derived from SRI con-
tractual work. The author recognizes that ideas similar to those in tractual work. The author recognizes that ideas similar to those in
this document may have already been presented by others and wishes to this document may have already been presented by others and wishes to
acknowledge any other such authors. The author also wishes to ack- acknowledge any other such authors. The author also wishes to ack-
skipping to change at page 12, line 38 skipping to change at page 13, line 8
projects from which these works derived as well as his SRI colleagues projects from which these works derived as well as his SRI colleagues
with whom he has discussed and reviewed this work, including Monica with whom he has discussed and reviewed this work, including Monica
Farah-Stapleton, Dr. Mike Frankel, J. Peter Marcotullio, Lou Rodri- Farah-Stapleton, Dr. Mike Frankel, J. Peter Marcotullio, Lou Rodri-
guez, and Dr. Ambatipudi Sastry. guez, and Dr. Ambatipudi Sastry.
The author acknowledges valuable input from numerous members of the The author acknowledges valuable input from numerous members of the
NGTRANS community which has helped guide the direction of the draft. NGTRANS community which has helped guide the direction of the draft.
The list of contributors is too long to enumerate, but the input from The list of contributors is too long to enumerate, but the input from
the community has been vital to the draft's evolution. Alain Durand the community has been vital to the draft's evolution. Alain Durand
deserves special mention for contributing the title of this draft and deserves special mention for contributing the title of this draft and
the ISATAP acronym. the ISATAP acronym. Additionally, Tim Gleenson and Nathan Lutchansky
numerous helpful suggestions for improvement.
The author finally wishes to provide special acknowledgement to Dave The author finally wishes to provide special acknowledgement to Dave
Thaler, Art Shelest, Richard Draves, and others at Microsoft Research Thaler, Art Shelest, Richard Draves, and others at Microsoft Research
for their ideas on automatic discovery of off-link IPv6 routers. Much for their ideas on automatic discovery of off-link IPv6 routers. Much
of the text in section on deployment considerations derives directly of the text in section on deployment considerations derives directly
from discussions with Dave, Art, Rich and others. from discussions with Dave, Art, Rich and others.
References References
[AGGR] Hinden., R, O'Dell, M., and Deering, S., "An IPv6 [AGGR] Hinden., R, O'Dell, M., and Deering, S., "An IPv6
skipping to change at page 13, line 43 skipping to change at page 14, line 14
[IPV4] Postel, J., "Internet Protocol", RFC 791 [IPV4] Postel, J., "Internet Protocol", RFC 791
[IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460 (IPv6) Specification", RFC 2460
[6TO4] Carpenter, B., and K. Moore, "Connection of IPv6 Domains [6TO4] Carpenter, B., and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[6TO4ANY] Huitema, C., "An anycast prefix for 6to4 relay routers", [6TO4ANY] Huitema, C., "An anycast prefix for 6to4 relay routers",
draft-ietf-ngtrans-6to4anycsat-02.txt (work in progress) RFC 3068, June 2001.
[6TO4MULTI] Thaler, D., "Support for Multicsat over 6to4 Networks", [6TO4MULTI] Thaler, D., "Support for Multicast over 6to4 Networks",
draft-ietf-ngtrans-6to4-multicast-00.txt (work in pro- draft-ietf-ngtrans-6to4-multicast-00.txt (work in pro-
gress) gress)
[MECH] Gilligan, R., and E. Nordmark, "Transition Mechanisms for [MECH] Gilligan, R., and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 2893, August 2000. IPv6 Hosts and Routers", RFC 2893, August 2000.
[SELECT] Draves, R., Default Address Selection for IPv6, draft- [SELECT] Draves, R., Default Address Selection for IPv6, draft-
ietf- ietf-
ipngwg-default-addr-select-00.txt (work in progress) ipngwg-default-addr-select-06.txt (work in progress)
[FBSD] http://www.freebsd.org [FBSD] http://www.freebsd.org
[USAGI] http://www.linux-ipv6.org
[INRIA] ftp://ftp.inria.fr/network/ipv6/ [INRIA] ftp://ftp.inria.fr/network/ipv6/
[6BONE] Rockell, R., and R. Fink, RFC 2772, February 2000. [6BONE] Rockell, R., and R. Fink, RFC 2772, February 2000.
[PRIVATE] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. [PRIVATE] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., J.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
RFC 1918, February 1996. RFC 1918, February 1996.
[PRIVACY] Narten, T., R. Draves, "Privacy Extensions for Stateless [PRIVACY] Narten, T., R. Draves, "Privacy Extensions for Stateless
skipping to change at page 14, line 38 skipping to change at page 15, line 12
Fred L. Templin Fred L. Templin
SRI International SRI International
333 Ravenswood Ave. 333 Ravenswood Ave.
Menlo Park, CA 94025, USA Menlo Park, CA 94025, USA
Email: templin@erg.sri.com Email: templin@erg.sri.com
Intellectual Property Intellectual Property
PLACEHOLDER for full IETF IPR Statement if needed. The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this docu-
Full Copyright Statement ment. For more information consult the online list of claimed
rights.
PLACEHOLDER for full ISOC copyright Statement if needed.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/