WDIFF

draft-ietf-ngtrans-isatap-17.txt --> draft-ietf-ngtrans-isatap-18.txt

Network Working Group F. Templin
Internet-Draft Nokia
Expires: July 20, August 4, 2004 T. Gleeson
Cisco Systems K.K.
M. Talwar
D. Thaler
Microsoft Corporation
January 20,
February 4, 2004

Intra-Site

Internet/Site Automatic Tunnel Addressing Protocol (ISATAP)
draft-ietf-ngtrans-isatap-17.txt
draft-ietf-ngtrans-isatap-18.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance with subject to 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.

This Internet-Draft will expire on July 20, August 4, 2004.

Abstract

The Intra-Site Internet/Site Automatic Tunnel Addressing Protocol (ISATAP)
connects IPv6 neighbors/routers hosts/routers over IPv4 networks. ISATAP views the IPv4
network as a Non-Broadcast, Multiple Access (NBMA) link layer for IPv6 and views other nodes on the network
as potential IPv6
neighbors/routers. hosts/routers. ISATAP interfaces support supports automatic tunneling
whether globally assigned or private IPv4 addresses are used. ISATAP
supports an abstraction for
and a tunnel interface management abstraction similar to the Non-
Broadcast, Multiple Access (NBMA) and ATM Permanent/Switched Virtual
Circuit (PVC/SVC) model. models.

Templin, et al. Expires July 20, August 4, 2004 [Page 1]

Internet-Draft ISATAP January February 2004

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. ISATAP Conceptual Model of Operation . . . . . . . . . . . . . . . . . . . . . . 4
5. Node Requirements . . . . . . . . . . . . . . . . . . . . . . 4 5
6. Addressing Requirements . . . . . . . . . . . . . . . . . . . 4 5
7. Configuration and Management Requirements . . . . . . . . . . 6
8. Automatic Tunneling . . . . . . . . . . . . . . . . . . . . . 12 10
9. Neighbor Discovery for ISATAP Interfaces . . . . . . . . . . . 15
10. Other Requirements for Control Plane Signaling . . . . . . . . 18
11. Security considerations . . . . . . . . . . 17
10. Other Requirements for Control Plane Signalling . . . . . . . 19
11. . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. Security considerations 18
13. IAB Considerations . . . . . . . . . . . . . . . . . . . 20
13. . . . 19
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
Normative References
A. Major Changes . . . . . . . . . . . . . . . . . . . . . 21
Informative References . . . 21
B. Example ISATAP Driver API . . . . . . . . . . . . . . . . . 22
Authors' Addresses . 21
C. The IPv6 Minimum MTU . . . . . . . . . . . . . . . . . . . . . 24
A. Major Changes
D. Modified EUI-64 Addresses in the IANA Ethernet Address Block . 24
E. Proposed ICMPv6 Code Field Types . . . . . . . . . . . . . . . 25
Normative References . . . . . . . . . . . . . . . . . . . . . 25
B. Interface Identifier Construction
Informative References . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . 26 . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . 28 30

Templin, et al. Expires July 20, August 4, 2004 [Page 2]

Internet-Draft ISATAP January February 2004

1. Introduction

This document specifies a simple mechanism called the Intra-Site Internet/Site
Automatic Tunnel Addressing Protocol (ISATAP) that connects IPv6
[RFC2460] neighbors/routers hosts/routers over IPv4 [RFC0791] [STD0005] networks. ISATAP
allows dual-stack Dual-stack
(IPv6/IPv4) nodes use ISATAP to automatically tunnel packets
to the IPv6 next-hop address through packets in
IPv4, i.e., ISATAP sees views the IPv4 network as a link layer for IPv6
and views other nodes on the network as potential IPv6 neighbors/routers. hosts/routers.

ISATAP enables automatic tunneling whether global or private IPv4
addresses are used, and supports an abstraction
for a tunnel interface management
abstraction similar to the Non-Broadcast, Multiple Access (NBMA)
[RFC2491] and ATM Permanent/Switched Virtual Circuit (PVC/SVC)
[RFC2492] paradigms. models.

The main objectives of this document are to: 1) describe the
operational model for ISATAP, ISATAP
conceptual model, 2) specify addressing requirements, 3) discuss
configuration and management requirements, 4) specify automatic
tunneling using ISATAP, 5) specify operational aspects of IPv6
Neighbor Discovery, and 6) discuss IANA; IANA and Security considerations.

This document surveys all IETF v6ops WG documents current up to
February 4, 2004.

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 [RFC2119]. [BCP0014].

3. Terminology

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

ISATAP node:
a dual-stack (IPv6/IPv4) node that implements the specifications in this specification. document.

ISATAP driver: daemon:
an ISATAP node's network driver module server application that provides uses an engine ISATAP driver API
for
encapsulation, decapsulation control plane signaling and forwarding of packets between
tunnel interfaces and the IPv4 stack; it also implements an API
for tunnel interface management.
configuration/management.

Templin, et al. Expires August 4, 2004 [Page 3]

Internet-Draft ISATAP server daemon: February 2004

ISATAP driver:
an ISATAP node's process network driver module that sends/receives tunnel configuration provides an API for
control plane messages, signaling and configures/manages tunnel interfaces
via the ISATAP driver API; often will be the same server daemon
used interface configuration/
management. Also provides an engine for tunneled packet
encapsulation, decapsulation and forwarding.

logical interface:
an IPv6 neighbor/router discovery.

Templin, et al. Expires July 20, 2004 [Page 3]

Internet-Draft address or a configured tunnel interface associated with
an ISATAP January 2004 interface.

ISATAP interface:
an ISATAP node's point-to-multipoint IPv6 interface used for automatic
IPv6-in-IPv4 tunneling of tunneling. Provides a control plane traffic; may also be used
to carry data interface for the
ISATAP daemon and a user plane traffic in some deployments scenarios, e.g.,
certain enterprise networks. nexus for its associated logical
interfaces.

ISATAP interface identifier:
an IPv6 interface identifier with an embedded IPv4 address
constructed as specified in Section section 6.1.

ISATAP address:
an IPv6 unicast address assigned to on an ISATAP interface with an
on-link prefix and an ISATAP interface identifier.

locator:
an IPv4 address-to-interface mapping, i.e., a node's IPv4 address
and the index for it's associated interface.

locator set:
a set of locators associated with a tunnel interface, where each
locator in the set belongs to the same site.

4. ISATAP Conceptual Model of Operation

ISATAP nodes typically act as a host on some interfaces and as a
router on other interfaces; the distinction between host and router
is made per advertising interface.

ISATAP interfaces provide a point-to-multipoint abstraction for
IPv6-in-IPv4 tunneling. They are commonly used as provide a user plane nexus for
automatic configuration tunneling
packets on behalf of point-to-point tunnels via tunnel
configuration their associated logical interfaces. They also
provide a control plane messages interface for tunnel configuration signaling
between the ISATAP daemon and prospective peers (e.g., via IPv6
Neighbor Discovery
and other ICMPv6 messages). For each messages, DNS queries, etc.).

The ISATAP driver sends tunneled packet received, packets via the node's ISATAP driver examines a local forwarding table IPv4 stack
according to determine the sending interface's encapsulation parameters. It
also determines the correct interface to receive the each tunneled packet after decapsulation. It
forwards tunnel configuration control plane messages via an ISATAP
interface to the node's

Templin, et al. Expires August 4, 2004 [Page 4]

Internet-Draft ISATAP server daemon, and forwards data
messages to applications February 2004

after decapsulation via configured tunnel interfaces based on a
specific match for the encapsulating IPv4 source address. forwarding table lookup.

The ISATAP server daemon sends and receives control plane messages, configures and configures/manages manages tunnels via the an ISATAP driver
API. Each such configured tunnel provides a nexus for multiplexing one or more multiple
applications between the remote and local tunnel endpoints using IPv6 addresses as application identifiers. Each
such application identifier provides a nexus for multiplexing one or more multiple sessions.
In summary, each configured tunnel provides a single point-to-point
connection between peers that can be used to carry support multiple applications and
multiple instances of each application.

5. Node Requirements

Nodes that use this specification

ISATAP nodes implement the common functionality required by [NODEREQ]
as well as the additional features specified in this document.

6. Addressing Requirements

Templin, et al. Expires July 20, 2004 [Page 4]

Internet-Draft ISATAP January 2004

6.1 ISATAP Interface Identifiers

ISATAP interface identifiers are constructed in Modified EUI-64
format as specified in ([ADDR-ARCH], section 2.5.1). ([ADDR], appendix A). They are formed by appending concatenating the
24-bit IANA OUI (00-00-5E), the 8-bit hexadecimal value 0xFE, and a
32-bit IPv4 address to in network byte order ([AUTH], section 3.4).

The format for ISATAP interface identifiers is given below (where 'u'
is the 32-bit leading token
'0000:5EFE', then setting IEEE univeral/local bit, 'g' is the universal/local ("u") bit as follows: IEEE group/individual bit,
and the 'm' bits represent the concatenated IPv4 address):

|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|000000ug00000000|0101111011111110|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+

When the IPv4 address is known to be globally unique, the "u" 'u' bit is
set to 1 and the leading token becomes '0200:5EFE'. When the IPv4
address is from a private allocation or not otherwise known to be
globally unique, 1; otherwise, the "u" 'u' bit is set to 0 and the leading token
remains as '0000:5EFE'. ([ADDR], section 2.5.1).
See: Appendix B D for additional non-normative details.

6.2 ISATAP Addresses

Any IPv6 unicast address ([ADDR-ARCH], ([ADDR], section 2.5) that has contains an
ISATAP interface identifier constructed as specified in section 6.1
and an on-link prefix on an ISATAP interface is considered an ISATAP
address.

Templin, et al. Expires August 4, 2004 [Page 5]

Internet-Draft ISATAP addresses are
constructed as follows:

6.3 Multicast/Anycast

ISATAP interfaces recognize a node's required IPv6 multicast/anycast
addresses ([ADDR-ARCH], ([ADDR], section 2.8).

Section 8.2 discusses encapsulation for multicast/anycast packets.

6.4 Source/Target Link Layer Address Options

Source/Target Link Layer Address Options ([RFC2461], section 4.6.1)
for

For IPv6 multicast addresses of interest to local applications,
ISATAP have nodes join the following format:

+-------+-------+-------+-------+-------+-------+-------+--------+
| Type |Length | 0 | 0 | corresponding Organization-Local Scope IPv4 Address
multicast groups ([RFC2529], section 6) on each interface that
appears in an ISATAP interface's locator set (see: section 7.2).

IPv6 multicast addresses of interest include a node's required
multicast addresses, the 'All_DHCP_Relay_Agents_and_Servers' and
'All_DHCP_Servers' multicast addresses (i.e., if the node is
configured as a DHCPv6 server [RFC3315][RFC3633]), multicast
addresses discovered via MLD [RFC2710], etc.

Considerations for IPv6 anycast appear in [ANYCAST].

6.4 Source/Target Link Layer Address Options

Source/Target Link Layer Address Options ([RFC2461], section 4.6.1)
for ISATAP have the following format:

+-------+-------+-------+-------+-------+-------+-------+--------+
| Type |Length | 0 | 0 | IPv4 Address |
+-------+-------+-------+-------+-------+-------+-------+--------+

Type:
1 for Source Link-layer address. 2 for Target Link-layer address.

Templin, et al. Expires July 20, 2004 [Page 5]

Internet-Draft ISATAP January 2004

Length:
1 (in units of 8 octets).

IPv4 Address:
A 32 bit IPv4 address, in network byte order ([RFC2223bis], ([AUTH], section
3.4).

ISATAP nodes use the specifications in ([MECH], section 3.8) that
pertain to sending and receiving Source/Target Link Layer Address
Options.

7. Configuration and Management Requirements

7.1 Network Management

ISATAP nodes MAY support network management; ISATAP nodes those that
support network management do SHOULD
support the following MIBs:
[FTMIB][IPMIB][TUNNELMIB]. The configuration objects cited throughout
the remainder of this document were selected to match the names of
MIB objects. ISATAP nodes that do not support network management MAY
choose their own local representation of these objects.

7.2 ISATAP Driver API

The ISATAP driver provides an API for tunnel interface configuration
and management that may be accessed by processes running on the
ISATAP node, e.g., startup scripts, manual command line entry, kernel
processes, ISATAP server daemons, etc. Access MUST be restricted to
privileged users and applications. The API provides the following
primitives; operational details are given in the subsections that
follow: [FTMIB][IPMIB][TUNMIB][TCPMIB][UDPMIB].

Templin, et al. Expires July 20, August 4, 2004 [Page 6]

Internet-Draft ISATAP January February 2004

'TUNNEL_CREATE':
creates a tunnel interface. Takes as parameters a tunnel
encapsulation method, parameters for setting read-write objects
for the tunnel, and a list of receive addresses

This document defines no new MIB tables, nor extensions to initialize a
forwarding entry any
existing MIB tables. Objects found in the system's ifRcvAddressTable. Returns an
index for MIBs listed above are
supported as described in the new tunnel interface, or a failure code.

'TUNNEL_DELETE':
deletes an existing tunnel interface. Takes following subsections.

7.2 The ifRcvAddressTable

The ISATAP driver maintains ifRcvAddressTable as parameter an
index a bidirectional
association of the locators with tunnel interface to be deleted. Returns success
or interfaces. Each locator in the
table includes a failure code.

'TUNNEL_MODIFY':
adds or deletes attributes for an existing tunnel interface, and
its corresponding forwarding entry preferred IPv4 address-to-interface mapping (i.e., a
preferred IPv4 ipAddressEntry in the ifRcvAddressTable. Takes node's ipAddressTable) and a
list of associated tunnel interfaces. Each tunnel interface in the same
table has a tunnelIfEntry and a list of parameters as for TUNNEL_CREATE, plus associated locators, i.e., a flag that
denotes
"locator set".

The ISATAP driver implements the operation (i.e., "add" or "delete"). Returns success
or following conceptual functions to
manage and search the ifRcvAddressTable:

7.2.1 RcvTableAdd(locator, tunnel_interface)

Creates a failure code.

'TUNNEL_DUP':
duplicates an existing bidirectional association in the ifRcvAddressTable between
the locator and tunnel interface. Takes as parameter interface, i.e., adds the
index of locator to the
tunnel interface's locator set and adds the tunnel interface to be duplicated. Returns an index
for the newly-created tunnel interface,
locator's association list.

Returns success or a failure code.

'TUNNEL_GET':
copies configuration attributes from system table failure.

7.2.2 RcvTableDel(locator, tunnel_interface)

Deletes ifRcvAddressTable entries
associated with according to the specified locator and tunnel
interface into a user's
buffer. Takes calling arguments as parameter an index of a follows:

- if both arguments are NULL, garbage-collects the entire table.

- if both arguments are non-NULL, deletes the locator from the
tunnel interface.
Returns interface's locator set and deletes the number of system table entry data bytes written
into tunnel interface
from the application's buffer or a failure code.

7.2.1 TUNNEL_CREATE

ISATAP drivers implement a 'TUNNEL_CREATE' primitive that provides a
means for configuring locator's association list.

- if the locator is non-NULL and tunnel interface is NULL, deletes
the 'tunnelIfEncapsMethod', locator from the locator sets of all read-write
objects associated with tunnel interfaces.

- if the 'tunnelIfEntry', locator is NULL and a list of receive
addresses for the tunnel which consist of an IPv4 address and an
index for interface is non-NULL,
deletes the tunnel interface to which from the address is assigned (i.e,. an
IPv4 address-to-interface mapping).

When a process on the ISATAP node issues 'TUNNEL_CREATE' primitive,
it includes a parameter for configuring the 'tunnelIfEncapsMethod'
object, and MAY include parameters for configuring other read-write
objects in the 'tunnelIfEntry'. It MAY also include one association lists of all
locators.

Returns success or more
receive address parameters. (Any required configuration parameters
not included in the 'TUNNEL_CREATE' primitive are to be issued in a
subsequent 'TUNNEL_MODIFY' primitive.) failure.

Templin, et al. Expires July 20, August 4, 2004 [Page 7]

Internet-Draft ISATAP January February 2004

When the ISATAP driver processes a 'TUNNEL_CREATE' primitive, it
creates an entry in the 'tunnelInetConfigTable', which results in the
simultaneous creation of a 'tunnelIfEntry' in the 'tunnelIfTable' and
an 'ifEntry' in

7.2.3 RcvTableLocate(packet)

Searches the appropriate 'ifTable'. Next, it sets ifRcvAddressTable to locate the
'tunnelIfEncapsMetod' object correct tunnel interface
to decapsulate a packet. First, determines the 'IANAtunnelType' specified by locator that matches
the
primitive, packet's IPv4 destination address and sets any other "read-write" objects in the
'tunnelIfEntry' based on parameters included.

After configuring ifIndex for the 'tunnelIfEntry', interface
the driver uses packet arrived on. Next, checks each receive
address parameter included to locate a preferred 'ipAddressEntry' in
the system's 'ipAddressTable'. It then creates an entry for the new tunnel interface in the 'ifRcvAddressTable' that includes the
locator's association list of
selected 'ipAddressEntry's, 'tunnelLocalInetAddress',
'tunnelRemoteInetAddress', 'tunnelIfEncapsMethod', and the 'ifIndex' for an exact match of tunnelIfEncapsMethod
with the tunnel interface.

After performing the above actions, the ISATAP driver returns either packet's encapsulation type and an interface index for exact match of
tunnelIfRemoteInetAddress with the packet's IPv4 source address.

If there is no match on the newly-created packet's IPv4 source address, a tunnel
interface or a
failure code.

7.2.2 TUNNEL_DELETE

ISATAP drivers implement a 'TUNNEL_DELETE' primitive that provides with a
means for deleting all table entries associated matching tunnelIfEncapsMethod and with
tunnelIfRemoteInetAddress set to 0.0.0.0 is selected. If there are
multiple matches, a tunnel
interface.

When an ISATAP node's process issues a 'TUNNEL_DELETE' primitive, it
includes an index for interface with tunnelIfLocalInetAddress
that matches the packet's IPv4 destination address is preferred.

Returns a pointer to a tunnel interface returned via if a previous
'TUNNEL_CREATE' or 'TUNNEL_DUP' primitive.

When the match is found; else
NULL.

7.3 ISATAP Driver API

The ISATAP driver processes a 'TUNNEL_DELETE' primitive, it
locates the 'tunnelInetConfigEntry' implements an API for the tunnel interface based on
the interface index parameter and deletes the entry from the
'tunnelInetConfigTable'. This has the result of simultaneously
deleting the 'tunnelIfEntry' calling processes, e.g.,
ISATAP daemons, startup scripts, manual command line entry, kernel
processes, etc. Access MUST be restricted to privileged users and 'ifEntry' from their respective
tables.
applications. The driver also removes the corresponding forwarding table
entry API provides primitives for the sending/receiving
control plane messages as well as creating, deleting, modifying, and
otherwise managing tunnel interface from the 'ifRcvAddressTable'.

After performing the above actions, the interfaces. An example (i.e., non-
normative) API is given in Appendix B.

7.4 ISATAP driver returns either
success or a failure code.

7.2.3 TUNNEL_MODIFY Interface Creation/Configuration

ISATAP drivers implement interfaces are created via the tunnelIfConfigTable, which
results in simultaneous creation of a 'TUNNEL_MODIFY' primitive that provides tunnelIfEntry and a
means for modifying all read-write objects associated with companion
ipv6InterfaceEntry. Each ISATAP interface configures a locator set,
where each locator in the
'tunnelIfEntry' and set represents an IPv4 address-to-
interface mapping for adding or deleting entries from the list of
receive addresses for same site (or, represents a mapping that is
routable on the tunnel. The primitive also provides global Internet). An ISATAP interface MUST NOT
configure a flag locator set that spans multiple sites.

ISATAP interfaces configure the following objects in tunnelIfEntry:

- tunnelIfEncapsMethod is set to an IANATunnelType for specifying whether "isatap".

- tunnelIfLocalInetAddress is set to an IPv4 address from the desired operation
interface's locator set.

- tunnelIfRemoteInetAddress is "add" or "delete". set to 0.0.0.0 to denote wildcard
match for remote tunnel endpoints.

Templin, et al. Expires July 20, August 4, 2004 [Page 8]

Internet-Draft ISATAP January February 2004

(For vector objects, the "add"/"delete" operations have

- other read-write objects in the meaning
intended by their names; tunnelIfEntry are configured as
for scalar objects, the any tunnel interface.

ISATAP driver
interprets an "add" operation as: "change interfaces also configure the following objects in
ipv6InterfaceEntry:

- ipv6InterfaceType is set to new value" and a
"delete" operation as: "reset "tunnel".

- ipv6InterfacePhysicalAddress is set to default".)

When an ISATAP node's process issues a 'TUNNEL_MODIFY' primitive, it
includes an index for the tunnel octet string of zero
length to indicate that this IPv6 interface returned via a previous
'TUNNEL_CREATE' or 'TUNNEL_DUP' primitive, and also includes does not have a flag
that specifies "add" or delete". It MAY include one or more parameter
physical address.

- ipv6InterfaceForwarding and, if necessary, ip6Forwarding for configuring the
node are set to "forwarding".

- other read-write objects in the 'tunnelIfEntry' and MAY
also include one or more receive address (formatted ipv6InterfaceEntry are configured as
for
'TUNNEL_CREATE').

When the ISATAP driver processes a 'TUNNEL_MODIFY' primitive, it
locates the correct 'tunnelIfEntry' any IPv6 interface.

Finally, an ipv6RouterAdvertEntry for the ISATAP interface index parameter is created
in ipv6RouterAdvertTable and modifies its ipv6RouterAdvertIfIndex object is
set to the same value as ipv6InterfaceIfIndex. Other objects in
ipv6RouterAdvertEntry are configured as for the entry based on any included parameters.
If one or more receive address parameters IPv6 router.

7.5 Dynamic Creation of Configured Tunnels

Configured tunnels are included, the driver
also adds or deletes receive addresses from normally created by the forwarding table
entry ISATAP daemon in the 'ifRcvAddressTable' corresponding
dynamic response to the
'tunnelIfEntry'. If no parameters are included, the result is a
NO-OP.

After performing the above actions, the ISATAP driver returns either
success or a failure code.

7.2.4 TUNNEL_DUP tunnel creation request. Configured tunnel
interfaces are configured as for ISATAP drivers implement a 'TUNNEL_DUP' primitive interfaces (see: section
7.4), except that creates a new
tunnel interface by duplicating a tunnelIfRemoteInetAddress is normally set of system table entries from an
existing tunnel interface.

When a user application or a system process issues to a 'TUNNEL_MODIFY'
primitive, it includes an index
specific IPv4 address for the tunnel interface to be
duplicated from a previous 'TUNNEL_CREATE' or 'TUNNEL_DUP' primitive.

When remote node at the ISATAP driver processes a 'TUNNEL_DUP' primitive, it creates
a new entry in far end of the 'tunnelInetConfigTable' exactly tunnel,
i.e., configured tunnels are normally configured as point-to-point.
Also, tunnelIfEncapsMethod for
'TUNNEL_CREATE' (see: Section 7.2.1). Next, it locates the
'tunnelIfEntry' and 'ifEntry' new entry is set to an
IANATunnelType appropriate for the tunnel interface to method of encapsulation.

Configured tunnels MAY be
duplicated and copies all attributes from those objects into "bound" to an ISATAP interface such that
they inherit the
newly-created 'tunnelIfEntry' ISATAP interface's locator set, e.g., for ease of
management and 'ifEntry'. The driver to avoid misconfigurations.

Configured tunnels MAY also creates
a duplicate forwarding table entry in the 'ifRcvAddressTable' using
the existing entry identified by the interface index parameter be created as a
prototype, then sets the newly-created forwarding entry's index to
the 'ifIndex' independent entities and
configure their own locator set, but (as for the newly-created tunnel interface.

After performing the above actions, the ISATAP driver returns either
an interface index for the newly-created tunnel interface or interfaces) they
MUST NOT configure a locator set that spans multiple sites.

Templin, et al. Expires July 20, August 4, 2004 [Page 9]

Internet-Draft ISATAP January February 2004

failure code.

7.2.5 TUNNEL_GET

To aid network administrators, ISATAP drivers SHOULD implement a
'TUNNEL_GET' primitive that returns the current configuration of all
tables in the system associated with the specified tunnel interface.

7.6 Reconfigurations Due to IPv4 Address Changes

When a user application issues a 'TUNNEL_GET' primitive, it includes locator becomes deprecated (e.g., when an index for a IPv4 address is
removed from an IPv4 interface) the locator SHOULD be removed from
all tunnel interface from a previous 'TUNNEL_CREATE' or
'TUNNEL_DUP' primitive, associations via RcvTableDel(locator, NULL).
Also, all tunnel interfaces that used the deprecated IPv4 address as
tunnelIfLocalInetAddress SHOULD configure a pointer to different local IPv4
address from their remaining locator set.

When a character buffer new IPv4 address is added to receive
the configuration information, and an integer indicating the
available space in the buffer.

When IPv4 interface, the ISATAP driver processes a 'TUNNEL_GET' primitive, it
prepares a character string that includes node MAY
add the concatenation of corresponding new locator to the
'tunnelIfEntry' locator set for one or more
tunnel interfaces via RcvTableAdd(locator, tunnel_interface), and the 'ifRcvAddressTable' entry MAY
set tunnelIfLocalInetAddress for the tunnel
interface identified interfaces referenced by the index parameter. (The 'ifEntry' is not
concatenated, since its contents may be examined via primitives from
other APIs.) Next, the driver copies the character string to the
server daemon's character buffer up
updated forwarding entries to the specified available buffer
space.

After performing new address.

Methods for triggering the above actions, the ISATAP driver returns either
the number changes, and for communicating IPv4
address changes to remote nodes, are out of bytes copied or a failure code (to include a code that
indicates "operation not supported").

7.3 ISATAP Interface Configuration scope.

8. Automatic Tunneling

ISATAP interfaces nodes use the basic tunneling mechanisms specified in [MECH].
The following additional specifications are normally configured by an ISATAP node's system
startup scripts or via manual configuration, but may also be created
by a dynamic process. When a node creates (or later modifies) an used:

8.1 Encapsulation

The ISATAP interface, it assigns to the interface one or more receive
address that consists of an driver encapsulates IPv6 packets in IPv4 address using various
encapsulation methods, including ip-protocol-41 (e.g., 6over4
[RFC2529], 6to4 [RFC3056], IPv6-in-IPv4 configured tunnels [MECH],
isatap, etc.), UDP [STD0006] port 3544, and an index others.

AH [RFC2402] and/or ESP [RFC2406] processing and header compression
for the
interface packet's inner headers are performed prior to which the address is assigned (i.e,. an IPv4
address-to-interface mapping). Each receive address assigned MUST
represent a mapping for encapsulation.

8.1.1 NAT Traversal

Native IPv6 and/or ip-protocol-41 encapsulation provides sufficient
functionality to support peer-to-peer communications when both peers
reside within the same site (or, MUST represent a mapping
that is routable on the global Internet), i.e., the receive addresses
assigned to a single tunnel interface MUST NOT span multiple sites.

ISATAP nodes issue 'TUNNEL_CREATE' and 'TUNNEL_MODIFY' primitives for
ISATAP interfaces (i.e., the same as for any tunnel interface;
'TUNNEL_CREATE' primitives include enterprise network). When
the remote peer resides within a parameter to set
'tunnelIfEncapsMethod' to different site, NAT traversal via
UDP/IPv4 encapsulation MAY be necessary.

When an 'IANATunnelType' code for "isatap". A
'TUNNEL_CREATE' or 'TUNNEL_MODIFY' primitive ISATAP node determines that includes parameters NAT traversal is necessary to set 'tunnelIfLocalInetAddress'
reach a particular peer, it encapsulates IPv6 packets using UDP/IPv4
encapsulation with a UDP destination port of 3544. This determination
may come through, e.g., first attempting communications via ip-
protocol-41 then failing over to an IPv4 address UDP/IPv4 port 3544 encapsulation,
administrative knowledge that a NAT traversal will be
used as one of occur along the interface's receive addresses, and
'tunnelIfRemoteInetAddress' to 0.0.0.0 to denote wildcard match for
path, etc.

Templin, et al. Expires July 20, August 4, 2004 [Page 10]

Internet-Draft ISATAP January February 2004

remote tunnel endpoints SHOULD be issued before the IPv6 interface
associated with the tunnel interface is enabled (see below).

When an ISATAP interface UDP/IPv4 port 3544 encapsulation is created, the ISATAP driver also creates
an 'ipv6InterfaceEntry' as the companion 'ifEntry' to the
'tunnelIfEntry'. After setting the required objects in the
'tunnelIfEntry' (see above), used, the ISATAP node configures objects specifications in
the 'ipv6InterfaceEntry' for an ISATAP interface
this document apply the same as for any
IPv6 interface. For form of encapsulation
supported by ISATAP.

8.1.2 Multicast

ISATAP interfaces (and other tunnel interfaces
that use IPv4 as a link layer for encapsulate packets with IPv6 ), the node sets the
'ipv6InterfaceType' object to "tunnel". Next, the node sets the
'ipv6InterfacePhysicalAddress' object to an multicast destination
addresses using a mapped Organization-Local Scope IPv4 multicast
address that will be
used ([RFC2529], section 6) as one of the tunnel interface's receive addresses; this object
MUST be formatted as a 4-octet entity containing an IPv4 destination address in
network byte order ([RFC2223bis], section 3.4). The node next sets
the 'ipv6ScopeZoneIndexLinkLocal' object to a zone index identifier
that denotes the site for which the tunnel interface's receive
addresses are valid. Finally,
encapsulating IPv4 header.

8.2 Tunnel MTU and Fragmentation

Encapsulated packets may incur host-based IPv4 fragmentation, e.g.,
when the node configures all other underlying physical link has a small IPv4 MTU [BCP0048]. In
such cases, host-based IPv4 fragmentation is required
read-write parameters in to satisfy the 'ipv6InterfaceEntry' as for any
1280 byte IPv6
interface, minimum MTU, and sets 'ipv6InterfaceAdminStatus' to "up".

After configuring is not considered harmful [FRAG]. On
the ISATAP interface, other hand, unmitigated IPv4 fragmentation caused by the node sets network
can cause poor performance. For example, since the interface's
'ipv6InterfaceForwarding' object (and, if necessary, minimum IPv4
fragment size is only 8 bytes [STD0005], network middleboxes could
shred a 1280 byte tunneled packet into as many as 160 IPv4 fragments.

ISATAP uses the node's
'ip6Forwarding' object) to "forwarding". The node also creates an
'ipv6RouterAdvertEntry' MTU and fragmentation specifications in the 'ipv6RouterAdvertTable' ([MECH],
section 3.2) and sets the
'ipv6RouterAdvertIfIndex' object to the same value as
'ipv6InterfaceIfIndex'. Objects Maximum Reassembly Unit (MRU) specifications in the 'ipv6RouterAdvertEntry'
([MECH], section 3.6), which provide sufficient measures for an avoiding
excessive IPv4 fragmentation in certain controlled environments
(e.g., 3GPP operator networks, enterprise networks, etc). To minimize
IPv4 fragmentation and improve performance in general use case
scenarios, ISATAP interface are configured as for any IPv6 router, however
'ipv6RouterAdvertLinkMTU' nodes SHOULD NOT be set to a value other than 0
unless add the ISATAP driver will monitor following simple
instrumentation to the IPv4 reassembly cache and
report fragmentation of tunneled packets to the source by sending
IPv6 Router Advertisements with MTU options (see: Section 8.3).
Configuration of objects relating to IPv6 forwarding is normally
managed by cache:

When the ISATAP server daemon.

7.4 Dynamic Creation initial fragment of Configured Tunnels

Configured tunnels are normally created through ISATAP driver API
calls issued by an ISATAP server daemon in dynamic response to a
tunnel creation request. Configured tunnel interfaces are created as
for ISATAP interfaces (see: Section 7.3), except that the
'tunnelIfRemoteInetAddress' for encapsulated packet arrives, the new entry
packet's IPv4 reassembly timer is normally set to a
specific IPv4 address 1 second (i.e., the worst
case store-and-forward delay budget for a remote node at 1280 byte packet). If an
encapsulated packet's IPv4 reassembly timer expires:

- If enough contiguous leading bytes of the far end packet have arrived
(see: section 8.6), reassemble the packet from all fragments
received. (Otherwise, garbage-collect the reassembly buffer and
return from processing.) During reassembly, copy zero-filled or,
heuristically-chosen replacement data bytes in place of any
missing fragments.

- Mark the tunnel,
i.e., configured tunnels are normally configured packet as point-to-point.
As for ISATAP interfaces, configured tunnels MUST NOT select "INCOMPLETE", and also mark it with a list
of receive address mappings
"TOTAL_BYTES" length that span multiple sites.

Processes encodes the total number of data bytes
in fragments that create configured tunnels may find arrived.

- Deliver the 'TUNNEL_DUP' packet to the ISATAP driver as though reassembly had

Templin, et al. Expires July 20, August 4, 2004 [Page 11]

Internet-Draft ISATAP January February 2004

primitive useful (and, in some cases essential) for reducing
administrative complexity. An ISATAP interface may be used as

succeeded.

- Do not send an ICMPv4 "time exceeded" message [STD0005].

Appendix C provides informative text on the
prototype for derivation of the 'TUNNEL_DUP' primitive; 1280
byte IPv6 minimum MTU.

8.3 Handling ICMPv4 Errors

ISATAP interfaces SHOULD process ARP failures and persistent ICMPv4
errors as link-specific information indicating that a path to a
neighbor may have failed ([RFC2461], section 7.3.3).

8.4 Link-Local Addresses

ISATAP interfaces use link local addresses constructed as specified
in section 6.1 of this document.

8.5 Neighbor Discovery over Tunnels

The specification in ([MECH], section 3.8) is used; the configured tunnel
interface inherits additional
specification for neighbor discovery in section 9 of this document
are also used.

8.6 Decapsulation/Filtering

ISATAP nodes typically arrange for the attributes ISATAP driver to receive all
IPv4-encapsulated IPv6 packets that are addressed to one of the
node's IPv4 addresses. Examples include ip-protocol-41 (e.g., 6to4,
6over4, configured tunnels, isatap, etc.), UDP/IPv4 port 3544, and
others. The ISATAP interface, including driver uses the forwarding table entry decapsulation and filtering
specifications in ([MECH], section 3.6), and processes each packet
according to the system's 'ifRecvAddressTable'.
After creating a configured tunnel via following steps:

1. Locate the 'TUNNEL_DUP' primitive, correct tunnel interface to receive the process uses packet (see:
section 7.2.3). If not found, silently discard the 'TUNNEL_MODIFY' primitive to modify specific
attributes.

7.5 Reconfigurations Due to IPv4 Address Changes

When an 'ipAddressEntry' becomes deprecated (e.g., when an IPv4
address is removed packet and
return from an IPv4 interface) processing.

2. If the 'ipAddressEntry' MUST
be removed from all forwarding entries in tunnel uses header compression, reconstitute headers. If
header reconstitution fails, silently discard the 'ifRcvAddressTable'
that referenced it. Also, all 'tunnelIfEntry's that used
'ipAddressAddr' as 'tunnelIfLocalInetAddress' packet and
'ipv6InterfaceEntry's that used 'ipAddressAddr' as
'ipv6InterfacePhysicalAddress' MUST select a different IPv4 address
for those objects
return from their remaining list of receive addresses.
Methods for triggering processing.

3. Verify that the mandatory changes are implementor's
choice.

When a new packet's IPv4 source address is added to an IPv4 interface, the node MAY
add the new 'ipAddressEntry' to the list of receive addresses for
forwarding entries in 'ifRcvAddressTable', and MAY set
'tunnelIfLocalInetAddress' and/or 'ipv6InterfacePhysicalAddress' correct for
interfaces referenced by the updated forwarding entries to the new
encapsulated IPv6 source address.

8. Automatic Tunneling

ISATAP nodes use the basic tunneling mechanisms specified in [MECH].
The following additional specifications are used for ISATAP:

8.1 Encapsulation

The ISATAP driver is responsible for inserting the outermost IPv4
encapsulating header for all tunneled packets. Tunnel interfaces that
use various encapsulation methods (e.g., 6over4 [RFC2529], 6to4
[RFC3056], teredo, IP encapsulation within IP [RFC2003], minimal
encapsulation within IP [RFC2004], basic IPv6-in-IPv4 encapsulation
[MECH], ISATAP encapsulation itself, etc.) can all be For packets received on a
configured tunnel interface, verification is exactly as
encapsulation clients of the ISATAP driver.

The ISATAP driver performs AH [RFC2402] and ESP [RFC2406] processing
for tunnels that use IPsec, and may also perform header compression
prior to encapsulation. specified
in ([MECH], section 3.6).

Templin, et al. Expires July 20, August 4, 2004 [Page 12]

Internet-Draft ISATAP January February 2004

8.2 Multicast/Anycast

ISATAP interfaces tunnel only those

For packets with IPv6 multicast/
anycast destinations to include a node's required multicast/anycast
addresses, the 'All_DHCP_Relay_Agents_and_Servers' and
'All_DHCP_Servers' multicast addresses [RFC3315] and multicast
addresses discovered via MLD [RFC2710]. Packets with unrecognized
IPv6 multicast/anycast destinations are silently dropped. received on an ISATAP interfaces automatically tunnel IPv6 multicast packets with
the 'All_DHCP_Relay_Agents_and_Servers' and 'All_DHCP_Servers' using interface, the IPv4 'all hosts' broadcast address (i.e., 0xffffffff broadcast
address) as the destination source
address in the encapsulating IPv4 header
under is correct if:

- the assumption that DHCPv6 servers will be co-located with
DHCPv4 servers.

For other IPv6 multicast destinations, source address is an ISATAP interfaces
automatically tunnel packets using a mapped Organization-Local Scope
IPv4 multicast address ([RFC2529], section 6) as that embeds the destination
IPv4 source address in its interface identifier, or:

- the encapsulating IPv4 header. ISATAP nodes join IPv6 source address is the
Organization-Local Scope IPv4 multicast groups required to support address of an IPv6 Neighbor Discovery ([RFC2529], Appendix A) neighbor on interfaces that
may receive IPv4 packets to be forwarded to
an ISATAP interface.

NOTE: When interface associated with the ISATAP node enables one or more 6over4 interfaces
[RFC2529], locator that matched
the 6over4 interfaces MAY be used (i.e., instead of ISATAP
interfaces) for sending and receiving multicast packets.

8.3 Tunnel MTU and Fragmentation

The specification in ([MECH], packet (see: section 3.2) is not used; 7.2.3), or:

- the
specification in this section IPv4 source address is used instead:

ISATAP interfaces set a static MTU member of 1280 bytes, i.e., the minimum
MTU for IPv6 interfaces ([RFC2460], Potential Router
List (see: section 5) and do not set the
Don't Fragment bit in 9.1).

If the encapsulating IPv4 headers of tunneled
packets. ISATAP interfaces MAY provide a configuration knob for
setting a larger MTU, but larger MTUs MUST NOT be configured other
than for certain constrained deployments, e.g., in some enterprise
networks). Interfaces that may receive source address is incorrect, silently discard the
packet and return from processing.

4. Perform IPv4 ingress filtering (optional; disabled by default)
then decapsulate the packet. If the IPv6 source address is
invalid (see: [MECH], section 3.6), silently discard the packet
and return from processing.

For UDP port 3544 packets to be forwarded
to received on an ISATAP interface SHOULD configure interface, if the
IPv6 source address is an Effective MTU to Receive
(EMTU_R) [RFC1122], section 3.3.2) of at least 1500 bytes, i.e., they
SHOULD be able ISATAP link local address with the 'u'
bit set to reassemble 0 and an embedded IPv4 packets of 1500 bytes or larger.

1280 bytes was chosen as address that does not match the
IPv4 source address (see: section 6), rewrite the IPv6 interface minimum MTU [DEERING97] source
address to allow extra room for link layer encapsulations without exceeding
the Ethernet MTU inform upper layers of 1500 bytes, i.e., the practical physical cell
size of sender's mapped UDP port
number and IPv4 source address. Specific rules for rewriting the Internet.
IPv6 source address are established during ISATAP interface
configuration.

Next, discard encapsulating headers and continue processing the
encapsulated IPv6 packet.

5. Perform ingress filtering on the IPv6 source address (see:
[MECH], section 3.6). Next, determine the correct transport
protocol listener [FLOW] if the packet is destined to the
localhost; otherwise, perform an IPv6 forwarding table lookup and
site border/firewall filtering (see: [UNIQUE], section 6).

If the packet cannot be delivered, the driver SHOULD send an
ICMPv6 Destination Unreachable message ([RFC2463], section 3.2)
to the packet's source. The 1280 byte MTU provides a fixed upper bound message SHOULD select as its source
address an IPv6 address from the outgoing interface (if the
packet was destined to the localhost) or an ingress-wise correct
IPv6 address from the interface that would have forwarded the
packet had it not been filtered.

Templin, et al. Expires July 20, August 4, 2004 [Page 13]

Internet-Draft ISATAP January February 2004

for the size of IPv6 packets/fragments with a maximum
store-and-forward delay budget of ~1 second assuming worst-case link
speeds

The Code field of ~10Kbps [RFC3150], thus allowing a convenient value for use
in reassembly buffer timer settings. Finally, the 1280 byte MTU
allows transport connections (e.g., TCP) to configure a large-enough
maximum segment size for improved performance even message is set as follows:

- if there is no route to the IPv4
interface that will send destination, the tunneled packets uses a smaller MTU.

When Code field is set
to 0 (see: [RFC2463], section 3.1).

- if communication with the size of destination is administratively
prohibited, the IPv6 destination's receive buffer Code field is known,
applications MAY send IPv6 packets up set to that size using IPv6
fragmentation (or, fragmentation via an alternate form of
encapsulation) with a maximum fragment size that 1 ([RFC2463], section
3.1).

- if the packet is no larger than destined to the minimum of localhost, but the MTU of the IPv4 interface used for tunneling and
1280 bytes. Even so, IPv4 fragmentation MAY still occur along some
paths; in particular, since transport
protocol has no listener, the minimum IPv4 fragment size Code field is only 8
bytes ([RFC0791], set to 4
([RFC2463], section 2), middleboxes with unusual
implementations 3.1).

- if the packet's destination is beyond the scope of IPv4 fragmentation could shatter the tunneled
packets into as many as 187 IPv4 fragments source
address, the Code field is set to accommodate a 1500 byte
IPv4 packet. Such sustained bursts of small packets could result in
poor performance 2 (see: IANA
Considerations).

- if the packet was dropped due to increased loss probability on paths with
non-negligible ingress filtering policies,
the Code field is set to 5 (see: IANA Considerations).

- if the packet loss is dropped due to, e.g., link errors, congested
router queues, etc.

Therefore, ISATAP nodes that anticipate or experience poor
performance along some paths MAY choose to adaptively vary a reject route, the
maximum size for Code field
is set to 6 (see: IANA Considerations).

- if the packets/fragments they send. For example,
implementations may choose packet was received on a point-to-point link and
destined to employ an address within a "fragment size slow start"
scheme subnet assigned to that begins with as little as 8 bytes (i.e., same
link, or if the minimum IPv4
fragment size) and varies reason for the size failure to deliver cannot be
mapped to any of the fragments using, e.g., an
additive-increase, multiplicative-decrease strategy specific conditions listed above, the
Code field is set to determine 3 ([RFC2463], section 3.2).

After sending the
size that yields ICMPv6 Destination Unreachable message, discard
the best performance. The process can be made to
converge more quickly when next-hop IPv6 routers are configured to packet and return from processing.

6. If the packet is "INCOMPLETE" (see section 8.2) send an
authenticated, unsolicited Router Advertisements Advertisement message
([RFC2461], section 6.2.4) to the packet's IPv6 source address
with an MTU options when they experience IPv4
fragmentation, since the sender is made aware option that fragmentation is
occurring, and encodes "TOTAL_BYTES".

7. If the MTU option can be used packet was destined to return the size of a remote host, forward the
largest IPv4 fragment observed which may help packet
and return from processing. Otherwise, apply AH [RFC2402] or ESP
[RFC2406] processing (if necessary), and deliver the sender determine
the optimal fragment size.

Since many nodes are expected to implement this specification, an
overall increase in small packets decapsulated
packet by placing it in the Internet a buffer for upper layers. The buffer may occur as more
nodes with tunnel interfaces implement schemes such as the one
described above to avoid IPv4 fragmentation-related performance
issues. For this reason, network equipment manufacturers and network
administrators are encouraged to observe the Recommendations on Queue
Management and Congestion Avoidance in
be, e.g., the Internet [RFC2309]. In
particular, byte mode queue averaging for RED IPv6 reassembly cache, an application's mapped data
buffer [RFC3542], etc.

If there is encouraged.

With reference clear evidence that upper layer reassembly has
stalled, an ICMPv6 Packet Too Big message [RFC1981] MAY be sent
to the above, it is RECOMMENDED packet's source address with an MTU value indicating a
size that ISATAP nodes use is likely to incur successful reassembly. Some

Templin, et al. Expires July 20, August 4, 2004 [Page 14]

Internet-Draft ISATAP January February 2004

adaptive techniques to minimize IPv4 fragmentation

applications may realize greater efficiency by accepting partial
information from "INCOMPLETE" packets (see: section 8.2) and use IPv6
fragmentation/reassembly (or, fragmentation/reassembly via an
alternate form
requesting selective retransmission of encapsulation) to manage the size of the tunneled
packets they send. It is also RECOMMENDED that missing portions.

9. Neighbor Discovery for ISATAP Interfaces

ISATAP nodes monitor use the IPv4 reassembly cache neighbor discovery mechanisms specified in order to give early indications of IPv4
network fragmentation by sending Router Advertisements
[RFC2461] along with MTU
options securing mechanisms (e.g., [SEND]) to the source of the IPv4 fragments. The MTU options should
include a value create/
change neighbor cache entries and to indicate provide control plane signaling
for automatic tunnel configuration. ISATAP interfaces also implement
the size of following specifications:

9.1 Conceptual Model Of A Host

To the largest packet that can
be expected to arrive without incurring IPv4 fragmentation. Finally,
it is RECOMMENDED that ISATAP nodes set small timeout values, e.g. 1
second, for IPv4 reassembly list of tunneled packets.

8.4 Handling IPv4 ICMP Errors Conceptual Data Structures ([RFC2461], section 5.1),
ISATAP interfaces SHOULD process ARP failures and persistent ICMPv4
errors as link-specific information indicating that a path to a
neighbor may have failed ([RFC2461], section 7.3.3).

8.5 Link-Local Addresses

The specification in ([MECH], section 3.7) is not used; the
specification in Section 6.1 add:

Potential Router List
A set of this document is entries about potential routers; used instead.

8.6 Neighbor Discovery over Tunnels

The specification in ([MECH], section 3.8) is not used; to support the
specification
mechanisms specified in Section 9 of this document is used instead.

8.7 Decapsulation/Filtering

ISATAP nodes arrange for the ISATAP driver to received all tunneled
packets that use section 9.2.2.1. Each entry ("PRL(i)")
has an IPv4 header as the outermost layer of
encapsulation. Examples include ip-protocol-41 (6to4, 6over4, isatap,
etc.), ip-protocol-4 (IP encapsulation within IP, minimal
encapsulation within IP, etc.), UDP port 3544 (teredo, etc.) associated timer ("TIMER(i)"), and
others. The ISATAP driver determines the correct tunnel interface to
receive each packet via a lookup in the 'ifRcvAdddressTable' for the
packet's IPv4 source address, destination address, an index for the
receiving IPv4 interface address
("V4ADDR(i)") that represents a router's advertising ISATAP
interface.

9.2 Router and the type of encapsulation. Packets for
which the correct tunnel interface cannot be determined are silently
discarded.

After determining the correct tunnel interface, Prefix Discovery

9.2.1 Router Specification

As permitted by ([RFC2461], section 6.2.6), the ISATAP driver
verifies that daemon SHOULD
send unicast Router Advertisement messages to the packet's link-layer (IPv4) soliciting node's
address when the solicitation's source address is
correct for not the network-layer (IPv6) source unspecified
address. For configured
tunnels, (Router Advertisements MAY include information delegated via
DHCPv6 [RFC3633]).

Routers MUST NOT send prefix options containing a preferred lifetime
greater than the IPv4 and IPv6 source addresses can be checked directly
against valid lifetime.

9.2.2 Host Specification

9.2.2.1 Host Variables

To the configured tunnel's addresses. For ISATAP interfaces, the
packet's link-layer source address is correct if one (or more) list of the host variables ([RFC2461], section 6.3.2), ISATAP
interfaces add:

Templin, et al. Expires July 20, August 4, 2004 [Page 15]

Internet-Draft ISATAP January February 2004

following are true:

o the network-layer source address is an ISATAP address that embeds
the link-layer source address

PrlRefreshInterval
Time in its interface identifier.

o seconds between successive refreshments of the network-layer source address is an IPv6 neighbor on an
interface that has PRL after
initialization. It SHOULD be no less than 3600 seconds. The
designated value of all 1's (0xffffffff) represents infinity.
Default: 3600 seconds

MinRouterSolicitInterval
Minimum time in seconds between successive solicitations of the
same 'ipv6ScopeZoneIndexLinkLocal' as the
receiving advertising ISATAP interface.

o the link-layer source address is a member The designated value of the all 1's
(0xffffffff) represents infinity.
Default: 900 seconds

9.2.2.2 Potential Router List (see: Section 9.1).

Packets for which the link-layer source address is incorrect Initialization

ISATAP nodes provision an ISATAP interface's PRL with IPv4 addresses
discovered via manual configuration, a DNS fully-qualified domain
name (FQDN) [STD0013], a DHCPv4 option, a DHCPv4 vendor-specific
option, or an unspecified alternate method.

FQDNs are
discarded and, if permitted by the current status of ICMPv6 message
rate limiting parameters [ICMPV6], section 2.4, paragraph f), established via manual configuration or an
ICMPv6 Destination Unreachable message SHOULD be generated and sent
to the IPv6 source unspecified
alternate method. FQDNs are resolved into IPv4 addresses through
lookup in a static host file, querying the inner header of DNS service, or an
unspecified alternate method.

When the encapsulated packet.
The error message SHOULD include only enough bytes from node provisions an ISATAP interface's PRL with IPv4
addresses, it sets a timer for the invoking
packet interface (e.g.,
PrlRefreshIntervalTimer) to convey PrlRefreshInterval seconds. The node re-
initializes the IPv6 header information, i.e., it SHOULD NOT
include up to PRL as specified above when PrlRefreshIntervalTimer
expires, or when an asynchronous re-initialization event occurs. When
the minimum IPv6 MTU.

After determining node re-initializes the correct tunnel interface PRL, it resets PrlRefreshIntervalTimer to receive the packet,
the
PrlRefreshInterval seconds.

9.2.2.3 Processing Received Router Advertisements

The ISATAP driver examines the IPv6 and IPv4 source addresses to
determine whether a rewrite daemon processes Router Advertisements (RAs) exactly as
specified in ([RFC2461], section 6.3.4). The DHCPv6 specification
[RFC3315] is required. If the IPv6 source address
is an ISATAP address stateful mechanism associated with the 'u/l' and 'g' bits set to 0 (see:
Section 6.1), M and the IPv4 source address does not match the IPv4
address encoded in the ISATAP interface identifier, O bits.

When the ISATAP driver
copies daemon receives a Router Advertisement with an MTU
option from a router at the IPv4 source address over far end of a tunnel, it records the IPv4 address embedded
advertised MTU value, e.g., in the node's IPv6 address and sets routing table. If the 'u/l' bit to 1. Other forms
MTU value is less than the MTU of rewrites
(e.g., rewrites for multicast rendezvous points based on the 'u' and
'g' bit) MAY be specified tunnel interface, the value is
recorded in other documents.

Next, such a way that the ISATAP driver discards node will perform upper layer
fragmentation (i.e., above the encapsulating IPv4 header and
locates any existing host-pair information, e.g., via the IPv6 Flow
Label [FLOW]. Then:

o If header compression is indicated, link layer) to reduce the packet's inner header(s)
are reconstituted.

o If a security association is indicated, AH [RFC2402] or ESP
[RFC2406] processing is applied.

o If size of
the packet is a fragment, IPv4 encapsulated packets it sends via the router. The recorded
value is placed in a buffer aged as for
reassembly. The buffer may be, e.g., the IPv6 reassembly cache, an
application's own data buffer [RFC3542], etc.

Finally, when a whole packet has been received, it is delivered to
the correct tunnel interface. If there is clear evidence that path MTU information [RFC1981].

Templin, et al. Expires July 20, August 4, 2004 [Page 16]

Internet-Draft ISATAP January February 2004

reassembly of a fragmented packet has stalled, an ICMPv6 "packet too
big" message [RFC1981] is sent to

For Router Advertisement messages that include prefix options, Route
information options [DEFLT] and/or non-zero values in the packet's source address
(subject Router
Lifetime, the ISATAP daemon resets TIMER(i) to ICMPv6 rate-limiting) with an MTU schedule the next
solicitation event (see: section 9.2.2.4). Let "MIN_LIFETIME" be the
minimum value indicating a size
that is likely to incur successful reassembly.

9. Neighbor Discovery

ISATAP nodes use in the neighbor discovery mechanisms specified Router Lifetime or the lifetime(s) encoded in
options included in
[RFC2461] along with securing mechanisms such as [SEND] to create/
change neighbor cache entries and to provide control plane signalling
for automatic tunnel configuration. ISATAP interfaces also implement the following specifications:

9.1 Conceptual Model Of A Host RA message. Then, TIMER(i) is reset as
follows:

TIMER(i) = MAX((0.5 * MIN_LIFETIME), MinRouterSolicitInterval)

9.2.2.4 Sending Router Solicitations

To the list of Conceptual Data Structures events after which RSs may be sent ([RFC2461], section 5.1),
6.3.2), ISATAP interfaces add:

Potential

- TIMER(i) for some PRL(i) expires.

Router List
A set of entries about potential routers; used Solicitations MAY be sent to support the
mechanisms specified in Section 9.2.2.1. Each entry ("PRL(i)")
has an associated timer ("TIMER(i)"), and an IPv4 ISATAP link-local address
("V4ADDR(i)") that represents a router's advertising ISATAP
interface.

9.2 Router
embeds V4ADDR(i) for some PRL(i) instead of the All-Routers multicast
address.

9.3 Address Resolution and Prefix Discovery

9.2.1 Router Specification

As permitted by Neighbor Unreachability Detection

9.3.1 Address Resolution

The specification in ([RFC2461], section 6.2.6), the 7.2) is used. ISATAP server daemon
SHOULD send unicast Router Advertisement messages to the soliciting
node's address when
addresses for which the solicitation's source neighbor/router's link-layer address is not cannot
otherwise be determined (e.g., from a neighbor cache entry) are
resolved to link-layer addresses by a static computation, i.e., the
unspecified
last four octets are treated as an IPv4 address.

9.2.2 Host Specification

9.2.2.1 Host Variables

Hosts SHOULD perform an initial reachability confirmation by sending
Neighbor Solicitation message(s) and receiving a Neighbor
Advertisement message (NS messages are sent to the list of host variables ([RFC2461], section 6.3.2), target's unicast
address). Routers MAY perform this initial reachability confirmation,
but this might not scale in all environments.

All nodes MUST send solicited Neighbor Advertisements on ISATAP
interfaces add:

PrlRefreshInterval
Time in seconds between successive refreshments of the PRL after
initialization. It ([RFC2461], section 7.2.4).

9.3.2 Neighbor Unreachability Detection

Hosts SHOULD be no less than 3600 seconds. The
designated value of perform Neighbor Unreachability Detection ([RFC2461],
section 7.3). Routers MAY perform neighbor unreachability detection,
but this might not scale in all 1's (0xffffffff) represents infinity.

Default: 3600 seconds environments.

Templin, et al. Expires July 20, August 4, 2004 [Page 17]

Internet-Draft ISATAP January February 2004

MinRouterSolicitInterval
Minimum time

10. Other Requirements for Control Plane Signaling

10.1 Domain Name System (DNS)

The specifications in seconds between successive solicitations of the
same advertising ([MECH], section 2.2) are used. Additional
considerations are found in [DNSOPV6].

10.2 Linklocal Multicast Name Resolution (LLMNR)

ISATAP interface. It nodes SHOULD implement Link Local Multicast Name Resolution
[LLMNR], since they will commonly be deployed in environments (e.g.,
home networks, ad-hoc networks, etc.) with no less than 900
seconds. The designated value of alll 1's (0xffffffff) represents
infinity.

Default: 900 seconds

9.2.2.2 Interface Initialization

The ISATAP node joins the all-nodes multicast address on DNS service.

10.3 Node Information Queries

ISATAP
interfaces, as for multicast-capable interfaces ([RFC2461], section
6.3.3) and nodes MAY also join other multicast groups, e.g., see: Section
8.2

Additionally, implement Node Information Queries as specified in
[NIQUERY], since they may help the node provisions querier discover some subset of
the ISATAP interface's PRL responder's addresses.

11. Security considerations

The security considerations in the normative references apply; also:

- site border routers SHOULD install a black hole route for the IPv6
prefix FC00::/7 to insure that packets with
IPv4 local IPv6 destination
addresses it discovers will not be forwarded outside of the site via manual configuration, a DNS
fully-qualified domain name (FQDN) [RFC1035], a DHCPv4 option, a
DHCPv4 vendor-specific option, or an unspecified alternate method.

ISATAP nodes establish FQDNs via manual configuration or an
unspecified alternate method. Nodes resolves FQDNs into default
route.

- administrators MUST ensure that lists of IPv4 addresses through lookup in a static host file, querying the DNS
service, or an unspecified alternate method. When DNS is used, client
resolvers use the IPv4 transport.

After the node provisions
representing the advertising ISATAP interface's interfaces of PRL with IPv4
addresses, it sets PrlRefreshIntervalTimer to PrlRefreshInterval
seconds. members are
well maintained.

12. IANA Considerations

The node re-initializes IANA is instructed to specify the PRL (i.e., format for Modified EUI-64
address construction ([ADDR], Appendix A) in the IANA Ethernet
Address Block. The text in Appendix D of this document is offered as specified above)
when PrlRefreshIntervalTimer expires, or when
an asynchronous
re-initialization event occurs. When the node re-initializes example specification.
The current version of the PRL,
it resets PrlRefreshIntervalTimer to PrlRefreshInterval seconds.

9.2.2.3 Processing Received Router Advertisements IANA registry for Ether Types can be
accessed at http://www.iana.org/assignments/ethernet-numbers.

The ISATAP server daemon processes Router Advertisements (RAs)
exactly as specified IANA is instructed to assign the new ICMPv6 code field types
found in ([RFC2461], section 6.3.4). Router
Advertisement messages received on a point-to-point tunnel interface Appendix E of this document for the ICMPv6 Destination
Unreachable message. The policy for assigning new ICMPv6 code field
types is First Come First Served, as defined in [RFC2434]. The
current version of the IANA registry for ICMPv6 type numbers can be
accessed at http://www.iana.org/assignments/icmpv6-parameters.

Templin, et al. Expires August 4, 2004 [Page 18]

Internet-Draft ISATAP February 2004

13. IAB Considerations

[RFC3424] ("IAB Considerations for UNilateral Self-Address Fixing
(UNSAF) Across Network Address Translation") section 4 requires that contain an MTU option with a value less than 1280 bytes cause
any proposal supporting NAT traversal must explicitly address the interface to reduce its MTU
following considerations:

13.1 Problem Definition

The specific problem being solved is enabling IPv6 connectivity for
ISATAP nodes that are unable to communicate via ip-protocol-41 or
native IPv6.

13.2 Exit Strategy

ISATAP nodes use UDP/IPv4 encapsulation for NAT traversal as a last
resort. As soon as native IPv6 or ip-protocol-41 support becomes
available, ISATAP nodes will naturally cease using UDP/IPv4
encapsulation.

13.3 Brittleness

UDP/IPv4 encapsulation with ISATAP introduces brittleness into the lesser value, but Router
Advertisements received
system in several ways: the discovery process assumes a certain
classification of devices based on an ISATAP interface MUST NOT cause their treatment of UDP; the
ISATAP interface
mappings need to reduce its MTU be continuously refreshed, and addressing structure
may cause some hosts located beyond a common NAT to be unreachable
from each other.

ISATAP assumes a value less than 1280 bytes.

For Router Advertisement messages received certain classification of devices based on an ISATAP interface their
treatment of UDP. There could be devices that include prefix options and/or non-zero values in the Router
Lifetime, would not fit into one
of these molds, and hence would be improperly classified by ISATAP.

The bindings allocated from the server daemon reset TIMER(i) NAT need to schedule be continuously
refreshed. Since the next
solicitation event (see: Section 9.2.2.4). Let "MIN_LIFETIME" timeouts for these bindings is very
implementation specific, the refresh interval cannot easily be
determined. When the binding is not being actively used to receive
traffic, but to wait for an incoming message, the binding refresh
will needlessly consume network bandwidth.

13.4 Requirements for a Long Term Solution

The devices that implement the IPv4 NAT service should in the future
also become IPv6 routers.

Templin, et al. Expires July 20, August 4, 2004 [Page 18] 19]

Internet-Draft ISATAP January February 2004

minimum value in the Router Lifetime or the lifetime(s) encoded in
options included

14. Acknowledgments

The ideas in this document are not original, and the RA message. Then, TIMER(i) is reset as
follows:

TIMER(i) = MAX((0.5 * MIN_LIFETIME), MinRouterSolicitInterval)

9.2.2.4 Sending Router Solicitations

To authors
acknowledge the list original architects. Portions of events after which RSs may be sent ([RFC2461], section
6.3.2), ISATAP interfaces add:

o TIMER(i) this work were
sponsored through SRI International internal projects and government
contracts. Government sponsors include Monica Farah-Stapleton and
Russell Langan (U.S. Army CECOM ASEO), and Dr. Allen Moshfegh (U.S.
Office of Naval Research). SRI International sponsors include Dr.
Mike Frankel, J. Peter Marcotullio, Lou Rodriguez, and Dr. Ambatipudi
Sastry.

The following are acknowledged for some PRL(i) expires.

Additionally, providing peer review input: Jim
Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader,
Ole Troan, Vlad Yasevich.

The following are acknowledged for their significant contributions:
Alain Durand, Hannu Flinck, Jason Goldschmidt, Nathan Lutchansky,
Karen Nielsen, Mohan Parthasarathy, Chirayu Patel, Art Shelest, Pekka
Savola, Margaret Wasserman, Brian Zill.

The authors acknowledge the ISATAP server daemon MAY send Router Solicitations work of Quang Nguyen on "Virtual
Ethernet" under the guidance of Dr. Lixia Zhang that proposed very
similar ideas to an ISATAP link-local address those that embeds V4ADDR(i) for some PRL(i)
instead of appear in this document. This work was
first brought to the All-Routers multicast address.

9.3 Address Resolution and Neighbor Unreachability Detection

9.3.1 Address Resolution authors' attention on September 20, 2002.

IAB considerations are the same as for Teredo.

The specification in ([RFC2461], section 7.2) is used. ISATAP
addresses following individuals are acknowledged for which their helpful insights
on path MTU discovery: Jari Arkko, Iljitsch van Beijnum, Jim Bound,
Ralph Droms, Alain Durand, Jun-ichiro itojun Hagino, Brian Haberman,
Bob Hinden, Christian Huitema, Kevin Lahey, Hakgoo Lee, Matt Mathis,
Jeff Mogul, Erik Nordmark, Soohong Daniel Park, Chirayu Patel,
Michael Richardson, Pekka Savola, Hesham Soliman, Mark Smith, Dave
Thaler, Michael Welzl, Lixia Zhang and the neighbor/router's link-layer address cannot
otherwise be determined (e.g., from a neighbor cache entry) are
resolved to link-layer addresses by a static computation, i.e., members of the Nokia NRC/
COM Mountain View team.

"...and I'm one step ahead of the shoe shine,
Two steps away from the
last four octets are treated as an IPv4 address.

Hosts SHOULD perform an initial reachability confirmation by sending
Neighbor Solicitation message(s) and receiving a Neighbor
Advertisement message (NS messages are sent county line,
Just trying to the target's unicast
address). Routers MAY perform this initial reachability confirmation,
but this might not scale in all environments.

As specified in ([RFC2461], section 7.2.4), all nodes MUST send
solicited Neighbor Advertisements on ISATAP interfaces.

9.3.2 Neighbor Unreachability Detection

Hosts SHOULD perform Neighbor Unreachability Detection ([RFC2461],
section 7.3). Routers MAY perform neighbor unreachability detection,
but this might not scale in all environments.

10. Other Requirements for Control Plane Signalling

10.1 Node Information Queries

ISATAP nodes SHOULD implement Node Information Queries as specified keep my customers satisfied,
Satisfi-i-ied!" - Paul Simon, 1969

Templin, et al. Expires July 20, August 4, 2004 [Page 19] 20]

Internet-Draft ISATAP January February 2004

in [NIQUERY].

Node Information Queries/Responses provide the following advantages:

o the querier receives unambiguous confirmation that the responder
supports the protocol.

o the querier receives assurance that responses are coming

Appendix A. Major Changes

Major changes from the
correct responder.

o the querier discovers some subset of the responder's addresses.

10.2 Linklocal Multicast Name Resolution (LLMNR)

ISATAP nodes SHOULD implement Link Local Multicast Name Resolution
[LLMNR], since they will commonly be deployed earlier versions to version 17:

- changed first words in environments (e.g.,
home networks, ad-hoc networks, etc.) with no access title from "Intra-site" to a Domain Name
System (DNS) server.

11. IANA Considerations

The IANA is advised "Internet/site"
to specify construction rules for IEEE EUI-64
addresses formed from the Organizationally Unique Identifier (OUI)
"00-00-5E" in more accurately represent the functionality.

- new section on configuration/management.

- new appendices on tunnel driver API; IANA considerations.

- expanded section on MTU and fragmentation.

- expanded sections on encapsulation/decapsulation.

- specified relation to IPv6 Node Requirements.

- introduced distinction between control; user planes.

- specified multicast mappings.

- revised neighbor discovery, address autoconfiguration, IANA "ethernet-numbers" registry. The non-normative
text in Appendix B is offered as an example specification.

12. Security
considerations

The and security considerations in the normative references apply.

Additionally, administrators MUST ensure that lists of IPv4 addresses
representing the advertising sections.

Appendix B. Example ISATAP interfaces of PRL members are Driver API

An ISATAP driver API should include primitives for sending and
receiving control plane messages as well maintained.

13. Acknowledgments

Most of the basic ideas in this document are not original; as primitives for tunnel
configuration/management such as the
authors acknowledge following non-normative
examples:

B.1 ISATAP_SEND, ISATAP_RECEIVE Primitives

Description:
Sends/Receives control plane messages via the original architects of those ideas. Portions
of this work were sponsored through SRI International internal
projects and government contracts. Government sponsors include Monica
Farah-Stapleton
ISATAP driver (e.g., via a routing socket, etc.)

Templin, et al. Expires August 4, 2004 [Page 21]

Internet-Draft ISATAP February 2004

B.2 ISATAP_CREATE Primitive

Description:
Creates a new tunnel interface and Russell Langan (U.S. Army CECOM ASEO), an associated IP
interface by creating a row in tunnelIfConfigTable.
Also optionally configures read-write objects for the
tunnel interface and Dr.
Allen Moshfegh (U.S. Office adds locators to the receive address
table via RcvTableAdd(locator, tunnel_interface).
Required parameter:
- tunnelIfEncapsMethod.
Optional parameters:
- attributes for configuring read-write objects.
- list of Naval Research). SRI International
sponsors include Dr. Mike Frankel, J. Peter Marcotullio, Lou
Rodriguez, and Dr. Ambatipudi Sastry.

The following are acknowledged locators to associate with tunnel interface.
Returns:
- ifIndex for providing peer review input: Jim
Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, the new tunnel interface, or a failure code.

B.3 ISATAP_DELETE Primitive

Description:
Deletes an existing tunnel interface by deleting the
corresponding row in tunnelIfConfigTable. Also frees
its locators via RcvTableDel(NULL, tunnel_interface).
Required parameter:
- ifIndex.
Returns:
- success or a failure code.

B.4 ISATAP_CONFIG Primitive

Description:
Configures attributes for an existing tunnel interface.
Also adds new locators via RcvTableAdd(locator,
tunnel_interface) and deletes old locators via
RcvTableDel(locator, tunnel_interface).
Required parameter:
- ifIndex.
Optional parameters:
- read-write objects for the tunnel interface.
- list of locators to associate with tunnel interface.
- list of locators to delete from association.
Returns:
- success or a failure code.

Templin, et al. Expires July 20, August 4, 2004 [Page 20] 22]

Internet-Draft ISATAP January February 2004

Ole Troan, Vlad Yasevich.

B.5 ISATAP_BIND Primitive

Description:
Binds (or, creates then binds) a configured tunnel interface
to an ISATAP interface. The following are acknowledged configured tunnel interface
inherits the ISATAP interface's locator set and the ISATAP
interface uses the encapsulation parameters associated with
the bound configured tunnel interface.
Required parameter:
- ifIndex for their significant contributions:
Alain Durand, Hannu Flinck, Jason Goldschmidt, Nathan Lutchansky,
Karen Nielsen, Mohan Parthasarathy, Chirayu Patel, Art Shelest, Pekka
Savola, Margaret Wasserman, Brian Zill.

The authors acknowledge the work of Quang Nguyen [VET] under ISATAP interface.
- ifIndex for the
guidance of Dr. Lixia Zhang that proposed very similar ideas to those
that appear in this document. This work was first brought to configured tunnel interface, or NULL.
Conditional parameter:
- if ifIndex for the
authors' attention on September 20, 2002.

The following individuals are acknowledged configured tunnel is NULL,
tunnelIfEncapsMethod.
Optional parameters:
- attributes for their helpful insights
on path MTU discovery: Jari Arkko, Iljitsch van Beijnum, Jim Bound,
Ralph Droms, Alain Durand, Jun-ichiro itojun Hagino, Brian Haberman,
Bob Hinden, Christian Huitema, Kevin Lahey, Hakgoo Lee, Matt Mathis,
Jeff Mogul, Erik Nordmark, Soohong Daniel Park, Chirayu Patel,
Michael Richardson, Pekka Savola, Hesham Soliman, Mark Smith, Dave
Thaler, Michael Welzl, Lixia Zhang configuring read-write objects for the
configured tunnel interface.
Returns:
- ifIndex for the configured tunnel, or a failure code.

B.6 ISATAP_GET Primitive

Description:
Copies configuration attributes from system table entries
associated with the specified tunnel interface into a
calling process' buffer.
Required parameter:
- ifIndex
- address of a buffer in calling process's memory.
- number of bytes available in the user's buffer.
Returns:
- Number of bytes written into the calling process'
buffer, or a failure code.

Templin, et al. Expires August 4, 2004 [Page 23]

Internet-Draft ISATAP February 2004

Appendix C. The IPv6 minimum MTU

The 1280 byte IPv6 minimum MTU was proposed by Steve Deering and
agreed through working group consensus in November 1997 discussions
on the members IPv6 mailing list. The size was chosen to allow extra room for
link layer encapsulations without exceeding the Ethernet MTU of 1500
bytes, i.e., the Nokia NRC/
COM Mountain View team.

"...and I'm one step ahead practical physical cell size of the shoe shine,
Two steps away from Internet. The
1280 byte MTU also provides a fixed upper bound for the county line,
Just trying to keep my customers satisfied,
Satisfi-i-ied!" - Simon and Garfunkel

Normative References

[ADDR-ARCH]
Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", draft-ietf-ipv6-addr-arch-v4-00 (work size of IPv6
packets/fragments with a maximum store-and-forward delay budget of ~1
second assuming worst-case link speeds of ~10Kbps [BCP0048], thus
providing a convenient value for use in
progress), October 2003.

[ICMPV6] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) reassembly buffer timer
settings. Finally, the 1280 byte MTU allows transport connections
(e.g., TCP) to configure a large-enough maximum segment size for
improved performance even if the Internet Protocol Version 6
(IPv6) Specification", draft-ietf-ipngwg-icmp-v3 (work in
progress), November 2001.

[LLMNR] Esibov, L., Aboba, B. and IPv4 interface that will send the
tunneled packets uses a smaller MTU.

Appendix D. Thaler, "Linklocal Multicast
Name Resolution", draft-ietf-dnsext-mdns (work in
progress), January 2004.

[MECH] Gilligan, R. and E. Nordmark, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-00
(work Modified EUI-64 Addresses in progress), February 2003.

[NIQUERY] Crawford, M., "IPv6 Node Information Queries",
draft-ietf-ipngwg-icmp-name-lookups (work the IANA Ethernet Address Block

Modified EUI-64 addresses ([ADDR], Appendix A) in progress), the IANA Ethernet
Address Block are formed as the concatenation of the 24-bit IANA OUI
(00-00-5E) with a 40-bit extension identifier. They have the
following appearance in memory (bits transmitted right-to-left within
octets, octets transmitted left-to-right):

0 23 63
| OUI | extension identifier |
000000ug00000000 01011110xxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx

When the first two octets of the extension identifier encode the
hexadecimal value 0xFFFE, the remainder of the extension identifier
encodes a 24-bit vendor-supplied id as follows:

0 23 39 63
| OUI | 0xFFFE | vendor-supplied id |
000000ug00000000 0101111011111111 11111110xxxxxxxx xxxxxxxxxxxxxxxx

Templin, et al. Expires July 20, August 4, 2004 [Page 21] 24]

Internet-Draft ISATAP January February 2004

June 2003.

[NODEREQ] Loughney, J., "IPv6 Node Requirements",
draft-ietf-ipv6-node-requirements (work

When the first octet of the extension identifier encodes the
hexadecimal value 0xFE, the remainder of the extension identifier
encodes a 32-bit IPv4 address, as specified in progress),
October 2003.

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.

[RFC1122] ([ISATAP], section
6.1) and as follows:

0 23 31 63
| OUI | 0xFE | IPv4 address |
000000ug00000000 0101111011111110 xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx

Modified EUI-64 format interface identifiers are formed by inverting
the "u" bit, i.e., the "u" bit is set to one (1) to indicate
universal scope and it is set to zero (0) to indicate local scope
([ADDR], section 2.5.1).

Appendix E. Proposed ICMPv6 Code Field Types

Three new ICMPv6 Code Field Type definitions are proposed for the
ICMPv6 Destination Unreachable message. The first proposes a new
definition for a currently-unassigned code type (2) in the ICMPv6
Type Numbers registry; the others propose new definitions for code
types (5) and (6). The code type field definition proposals appear
below:

Type Name Reference
---- ------------------------- ---------
1 Destination Unreachable [RFC2463]
Code 2 - beyond the scope of source address
5 - source address failed ingress policy
6 - reject route to destination

Normative References

[STD0003] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.

[STD0005] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.

[STD0006] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.

[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for
IP version 6", RFC 1981, August 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

Templin, et al. Expires August 4, 2004 [Page 25]

Internet-Draft ISATAP February 2004

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.

[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.

[RFC2463] Conta, A., and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification",
RFC 2463, December 1998.

[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.

[RFC3150] Dawkins, S., Montenegro, G., Kojo, M.

[RFC3424] Daigle, L. and V. Magret,
"End-to-end Performance Implications of Slow Links", BCP
48, IAB, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Translation", RFC 3150, July 2001. 3424,
November 2002.

[RFC3542] Stevens, W., Thomas, M., Nordmark, E. and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for IPv6", RFC
3542, May 2003.

Informative References

[DEERING97]
Deering, S., "http://www.cs-ipv6.lancs.ac.uk/ipv6/
mail-archive/IPng/1997-12/0052.html", November 1997.

[FLOW] Rajahalme,

[RFC3582] Abley, J., Conta, A., Carpenter, Black, B. and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003.

[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.

[ADDR] Hinden, R. and S. Deering,
"IPv6 Flow Label Specification", "IP Version 6 Addressing
Architecture", draft-ietf-ipv6-addr-arch-v4 (work in progress),
October 2003.

[AUTH] Reynolds, J. and R. Braden, "Instructions to Request for
Comments (RFC) Authors", draft-rfc-editor-rfc2223bis (work in
progress), August 2003.

[DEFLT] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", draft-ietf-ipv6-router-selection (work in
progress), December 2003.

[ISATAP] Templin, F., Gleeson, T., Talwar, M. and D. Thaler,
"Internet/Site Automatic Tunnel Addressing Protocol", draft-ietf-
ngtrans-isatap (work in progress), February 2004.

[LLMNR] Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast
Name Resolution", draft-ietf-dnsext-mdns (work in progress), January

Templin, et al. Expires July 20, August 4, 2004 [Page 22] 26]

Internet-Draft ISATAP January February 2004

draft-ietf-ipv6-flow-label

2004.

[MECH] Gilligan, R. and E. Nordmark, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2 (work in
progress), December February 2003.

[FTMIB] Haberman, B. and M. Wasserman, "IP Forwarding Table MIB",
draft-ietf-ipv6-rfc2096-update

[NODEREQ] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node-
requirements (work in progress), August October 2003.

[IPMIB] Routhier, S., "Management Information Base for the
Internet Protocol (IP)", draft-ietf-ipv6-rfc2011-update

[UNIQUE] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", draft-ietf-ipv6-unique-local-addr (work in progress), September 2003.

[RFC1035]
January 2004.

Informative References

[BCP0048] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-
to-end Performance Implications of Slow Links", BCP 48, RFC 3150,
July 2001.

[STD0013] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.

[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.

[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.

[RFC2223bis]
Reynolds, J. and R. Braden, "Instructions to Request for
Comments (RFC) Authors", draft-rfc-editor-rfc2223bis (work
in progress), August 2003.

[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J. and L. Zhang, "Recommendations on Queue
Management and Congestion Avoidance in the Internet", RFC
2309, April 1998.

[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.

[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.

[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.

[RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491,
January 1999.

[RFC2492] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM
Networks", RFC 2492, January 1999.

Templin, et al. Expires July 20, 2004 [Page 23]

Internet-Draft ISATAP January 2004

[RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.

[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001.

[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.

[RFC3582] Abley, J., Black, B. and V. Gill, "Goals for IPv6
Site-Multihoming Architectures", RFC 3582, August 2003.

[SEND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B. and P.
Nikander, "Secure Neighbor Discovery (SEND)",
draft-ietf-send-ndopt (work in progress), October 2003.

[TUNNELMIB]
Thaler, D., "IP Tunnel MIB",
draft-ietf-ipv6-inet-tunnel-mib (work in progress),
January 2004.

[VET] Nguyen, Q., "http://irl.cs.ucla.edu/vet/report.ps", spring
1998.

Authors' Addresses

Fred L. Templin
Nokia
313 Fairchild Drive
Mountain View, CA 94110
US

Phone: +1 650 625 2331
EMail: ftemplin@iprg.nokia.com

Tim Gleeson
Cisco Systems K.K.
Shinjuku Mitsu Building
2-1-1 Nishishinjuku, Shinjuku-ku
Tokyo 163-0409
Japan

EMail: tgleeson@cisco.com

Templin, et al. Expires July 20, 2004 [Page 24]

Internet-Draft ISATAP January 2004

Mohit Talwar
Microsoft Corporation
One Microsoft Way
Redmond, WA> 98052-6399
US

Phone: +1 425 705 3131
EMail: mohitt@microsoft.com

Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
US

Phone: +1 425 703 8835
EMail: dthaler@microsoft.com

Appendix A. Major Changes

Major changes from earlier versions to version 17:

o added tunnel driver API

o expanded section on MTU and fragmentation

o expanded sections on encapsulation/decapsulation

o specified relation to Configuration Protocol for IPv6 Node Requirements

o specified use of additional control plane signalling

o specified multicast mappings.

o specified link layer address option format.

o specified setting (DHCPv6)", RFC
3315, July 2003.

[ANYCAST] Hagino, J. and K. Ettikan, "An Analysis of "u" bit IPv6 Anycast",
draft-ietf-ipngwg-ipv6-anycast-analysis (work in interface id's.

o removed obsoleted appendix sections.

o re-organized major sections to match normative references.

o revised neighbor discovery, address autoconfiguration, security
considerations sections. Added new subsections on interface
management, decapsulation/filtering, address lifetime expiry. progress), June

Templin, et al. Expires July 20, August 4, 2004 [Page 25] 27]

Internet-Draft ISATAP January February 2004

Appendix B. Interface Identifier Construction

This section provides an example specification for constructing EUI64
addresses from the Organizationally-Unique Identifier (OUI) owned by
the Internet Assigned Numbers Authority (IANA). It can be used to
construct both modified EUI-64 format interface identifiers for IPv6
unicast addresses ([ADDR-ARCH], section 2.5.1)

2003.

[DNSOPV6] Durand, A., Ihren, J., and "native" EUI64
addresses for future use:

|0 2|2 3|3 3|4 6|
|0 3|4 1|2 9|0 3|
+------------------------+--------+--------+------------------------+
| OUI ("00-00-5E"+u+g) | TYPE | TSE | TSD |
+------------------------+--------+--------+------------------------+

Where the fields are:

OUI IANA's OUI: 00-00-5E Savola P., "Operational
Considerations and Issues with "u" IPv6 DNS", draft-ietf-dnsop-ipv6-dns-
issues, work-in-progress, January 2004.

[FLOW] Rajahalme, J., Conta, A., Carpenter, B. and "g" bits (3 octets)

TYPE Type field; specifies use of (TSE, TSD) (1 octet)

TSE Type-Specific Extension (1 octet)

TSD Type-Specific Data (3 octets)

And the following interpretations are specified based on TYPE:

TYPE (TSE, TSD) Interpretation
---- -------------------------
0x00-0xFD RESERVED for future IANA use
0xFE (TSE, TSD) together contain an IPv4 address
0xFF TSD is interpreted based S. Deering,
"IPv6 Flow Label Specification", draft-ietf-ipv6-flow-label (work in
progress), December 2003.

[FRAG] Mogul, J. and C. Kent, "Fragmentation Considered Harmful", In
Proc. SIGCOMM '87 Workshop on TSE as follows:

TSE TSD Interpretation
--- ------------------
0x00-0xFD RESERVED for future IANA use
0xFE TSD contains 24-bit EUI-48 intf id
0xFF RESERVED by IEEE/RAC

Using this example specification, if TYPE=0xFE, then TSE is an
extension of TSD. If TYPE=0xFF, then TSE is an extension of TYPE.
(Other values Frontiers in Computer Communications
Technology. August, 1987.

[FTMIB] Haberman, B. and M. Wasserman, "IP Forwarding Table MIB",
draft-ietf-ipv6-rfc2096-update (work in progress), August 2003.

[IPMIB] Routhier, S., "Management Information Base for TYPE, the Internet
Protocol (IP)", draft-ietf-ipv6-rfc2011-update (work in progress),
September 2003.

[NIQUERY] Crawford, M., "IPv6 Node Information Queries", draft-ietf-
ipngwg-icmp-name-lookups (work in progress), June 2003.

[SEND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B. and other interpretations of TSE, TSD are
reserved P.
Nikander, "Secure Neighbor Discovery (SEND)", draft-ietf-send-ndopt
(work in progress), October 2003.

[TCPMIB] Raghunarayan, R., "Management Information Base for future IANA use.) When TYPE='0xFE' the EUI64 address
embeds an IPv4 address, encoded
Transmission Control Protocol (TCP)", draft-ietf-ipv6-rfc2012-update
(work in network byte order.

For Modified EUI64 format interface identifiers progress), November 2003.

[TUNMIB] Thaler, D., "IP Tunnel MIB", draft-ietf-ipv6-inet-tunnel-mib
(work in IPv6 unicast
addresses ([ADDR-ARCH], Appendix A) using IANA's OUI, when TYPE=0xFE
and progress), January 2004.

[UDPMIB] Raghunarayan, R., "Management Information Base for the IPv4 address is a globally unique (i.e., provider-assigned)
Transmission Control Protocol (TCP)", draft-ietf-ipv6-rfc2012-update
(work in progress), November 2003.

Templin, et al. Expires July 20, August 4, 2004 [Page 26] 28]

Internet-Draft ISATAP January February 2004

unicast address, the "u" bit is set to 1 to indicate universal scope.
When TYPE=0xFE and the IPv4 address is from a private allocation, the
"u" bit is set to 0 to indicate local scope. Thus, when the first
four octets of the interface identifier in an IPv6 unicast address
are either: '02-00-5E-FE' or: '00-00-5E-FE', the next four octets
embed an IPv4 address and the interface identifier is said to be in
"ISATAP format".

Authors' Addresses

Fred L. Templin
Nokia
313 Fairchild Drive
Mountain View, CA 94110
US

Phone: +1 650 625 2331
EMail: ftemplin@iprg.nokia.com

Tim Gleeson
Cisco Systems K.K.
Shinjuku Mitsu Building
2-1-1 Nishishinjuku, Shinjuku-ku
Tokyo 163-0409
Japan

EMail: tgleeson@cisco.com

Mohit Talwar
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
US

Phone: +1 425 705 3131
EMail: mohitt@microsoft.com

Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
US

Phone: +1 425 703 8835
EMail: dthaler@microsoft.com

Templin, et al. Expires July 20, August 4, 2004 [Page 27] 29]

Internet-Draft ISATAP January February 2004

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights
might or might not be available; neither does it represent that it has
made any effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related standards-
related documentation can be found in BCP-11. Copies of claims of rights
made available for publication and any assurances of licenses to be made
available, or the result of an attempt made to obtain a general license
or permission for the use of such proprietary rights by implementors or
users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive Director.

The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this document.
For more information consult the online list of claimed rights.

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.

Templin, et al. Expires August 4, 2004 [Page 30]

Internet-Draft ISATAP February 2004

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.

Templin, et al. Expires July 20, 2004 [Page 28]

Internet-Draft ISATAP January 2004 This
document and the information contained herein is provided on an "AS IS"
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Templin, et al. Expires July 20, August 4, 2004 [Page 29] 31]

----