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.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

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.

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
   D.  Modified EUI-64 Addresses in the IANA Ethernet Address Block . 24
   A.  Major Changes
   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

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 daemon:
      an ISATAP node's server application that uses an ISATAP driver API
      for control plane signaling and tunnel interface
      configuration/management.

   ISATAP driver:
      an ISATAP node's network driver module that provides an engine 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 configuration/
      management.

   ISATAP server daemon: Also provides an ISATAP node's process that sends/receives tunnel configuration
      control plane messages, engine for tunneled packet
      encapsulation, decapsulation and configures/manages forwarding.

   logical interface:
      an IPv6 address or a configured tunnel interfaces
      via the interface associated with
      an ISATAP driver API; often will be the same server daemon
      used for IPv6 neighbor/router discovery. 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 decapsulation via an ISATAP
   interface to the node's a forwarding table lookup.

   The ISATAP server daemon, daemon configures and forwards data
   messages to applications manages tunnels via an ISATAP driver
   API. Each such configured tunnel interfaces based on provides a
   specific match nexus for the encapsulating IPv4 source address.

   The ISATAP server daemon sends and receives control plane messages,
   and configures/manages tunnels via the 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

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. ISATAP addresses are
   constructed as follows:

    |           64 bits            |     32 bits   |    32 bits     |
    +------------------------------+---------------+----------------+
    |            prefix            | 000[0/2]:5EFE |  IPv4 Address  |
    +------------------------------+---------------+----------------+

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 IPv6 multicast addresses of interest to local applications,
   ISATAP nodes join the corresponding Organization-Local Scope IPv4
   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 multicast/anycast packets. 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.

   Length:
      1 (in units of 8 octets).

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

7. Configuration and Management Requirements

7.1 Network Management

   ISATAP nodes MAY support network management;

   ISATAP nodes that
   support network management 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; those that do SHOULD
   support the following MIBs:
   [FTMIB][IPMIB][TUNNELMIB]. The configuration objects cited throughout
   the remainder of this [FTMIB][IPMIB][TUNMIB][TCPMIB][UDPMIB].

   This document were selected defines no new MIB tables, nor extensions to match the names of any
   existing MIB objects. ISATAP nodes that do not support network management MAY
   choose their own local representation of these objects. tables. Objects found in the MIBs listed above are
   supported as described in the following subsections.

7.2 ISATAP Driver API The ifRcvAddressTable

   The ISATAP driver provides an API for maintains ifRcvAddressTable as a bidirectional
   association of locators with 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 interfaces. Each locator in the following
   primitives; operational details are given
   table includes a preferred IPv4 address-to-interface mapping (i.e., a
   preferred IPv4 ipAddressEntry in the subsections that
   follow:

   'TUNNEL_CREATE':
      creates node's ipAddressTable) and a
   list of associated tunnel interface. Takes as parameters a interfaces. Each tunnel
      encapsulation method, parameters for setting read-write objects
      for interface in the tunnel,
   table has a tunnelIfEntry and a list of receive addresses associated locators, i.e., a
   "locator set".

   The ISATAP driver implements the following conceptual functions to initialize
   manage and search the ifRcvAddressTable:

7.2.1 RcvTableAdd(locator, tunnel_interface)

   Creates a
      forwarding entry bidirectional association in the system's ifRcvAddressTable. Returns an
      index for ifRcvAddressTable between
   the new locator and tunnel interface, or a failure code.

   'TUNNEL_DELETE':
      deletes an existing i.e., adds the locator to the
   tunnel interface. Takes as parameter an
      index of interface's locator set and adds the tunnel interface to be deleted. the
   locator's association list.

   Returns success or a failure code.

   'TUNNEL_MODIFY':
      adds or deletes attributes for an existing tunnel interface, and
      its corresponding forwarding entry in the ifRcvAddressTable. Takes failure.

7.2.2 RcvTableDel(locator, tunnel_interface)

   Deletes ifRcvAddressTable entries according to the same list of parameters locator and tunnel
   interface calling arguments as for TUNNEL_CREATE, plus a flag that
      denotes follows:

   -  if both arguments are NULL, garbage-collects the operation (i.e., "add" or "delete"). Returns success
      or a failure code.

   'TUNNEL_DUP':
      duplicates an existing tunnel interface. Takes as parameter entire table.

   -  if both arguments are non-NULL, deletes the
      index of locator from the
      tunnel interface to be duplicated. Returns an index
      for interface's locator set and deletes the newly-created tunnel interface, or a failure code.

   'TUNNEL_GET':
      copies configuration attributes interface
      from system table entries
      associated with the specified locator's association list.

   -  if the locator is non-NULL and tunnel interface into a user's
      buffer. Takes as parameter an index of a tunnel interface.
      Returns the number of system table entry data bytes written
      into is NULL, deletes
      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 from the 'tunnelIfEncapsMethod', 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 from the association lists of all
      locators.

   Returns success or failure.

7.2.3 RcvTableLocate(packet)

   Searches the ifRcvAddressTable to which locate the address is assigned (i.e,. an
   IPv4 address-to-interface mapping).

   When correct tunnel interface
   to decapsulate a process on packet. First, determines the ISATAP node issues 'TUNNEL_CREATE' primitive,
   it includes a parameter for configuring locator that matches
   the 'tunnelIfEncapsMethod'
   object, packet's IPv4 destination address and MAY include parameters ifIndex for configuring other read-write
   objects in the 'tunnelIfEntry'. It MAY also include one or more
   receive address parameters. (Any required configuration parameters
   not included in interface
   the 'TUNNEL_CREATE' primitive are to be issued packet arrived on. Next, checks each tunnel interface in a
   subsequent 'TUNNEL_MODIFY' primitive.)
   When the ISATAP driver processes a 'TUNNEL_CREATE' primitive, it
   creates
   locator's association list for an entry in the 'tunnelInetConfigTable', which results in the
   simultaneous creation exact match of a 'tunnelIfEntry' in tunnelIfEncapsMethod
   with the 'tunnelIfTable' packet's encapsulation type and an 'ifEntry' in the appropriate 'ifTable'. Next, it sets the
   'tunnelIfEncapsMetod' object to exact match of
   tunnelIfRemoteInetAddress with the 'IANAtunnelType' specified by packet's IPv4 source address.

   If there is no match on the
   primitive, and sets any other "read-write" objects in the
   'tunnelIfEntry' based on parameters included.

   After configuring the 'tunnelIfEntry', the driver uses each receive
   address parameter included packet's IPv4 source address, a tunnel
   interface with a matching tunnelIfEncapsMethod and with
   tunnelIfRemoteInetAddress set to locate 0.0.0.0 is selected. If there are
   multiple matches, a preferred 'ipAddressEntry' in
   the system's 'ipAddressTable'. It then creates an entry for the new tunnel interface in the 'ifRcvAddressTable' with tunnelIfLocalInetAddress
   that includes the list of
   selected 'ipAddressEntry's, 'tunnelLocalInetAddress',
   'tunnelRemoteInetAddress', 'tunnelIfEncapsMethod', and the 'ifIndex'
   for matches the packet's IPv4 destination address is preferred.

   Returns a pointer to a tunnel interface.

   After performing the above actions, the interface if a match is found; else
   NULL.

7.3 ISATAP Driver API

   The ISATAP driver returns either implements an interface index API for the newly-created tunnel interface or a
   failure code.

7.2.2 TUNNEL_DELETE calling processes, e.g.,
   ISATAP drivers implement a 'TUNNEL_DELETE' primitive that daemons, startup scripts, manual command line entry, kernel
   processes, etc. Access MUST be restricted to privileged users and
   applications. The API provides a
   means primitives for deleting all table entries associated with a sending/receiving
   control plane messages as well as creating, deleting, modifying, and
   otherwise managing tunnel
   interface.

   When an interfaces. An example (i.e., non-
   normative) API is given in Appendix B.

7.4 ISATAP node's process issues a 'TUNNEL_DELETE' primitive, it
   includes an index for the tunnel interface returned Interface Creation/Configuration

   ISATAP interfaces are created via a previous
   'TUNNEL_CREATE' or 'TUNNEL_DUP' primitive.

   When the tunnelIfConfigTable, which
   results in simultaneous creation of a tunnelIfEntry and a companion
   ipv6InterfaceEntry. Each ISATAP driver processes interface configures a 'TUNNEL_DELETE' primitive, it
   locates locator set,
    where each locator in the 'tunnelInetConfigEntry' set represents an IPv4 address-to-
   interface mapping for the tunnel interface based same site (or, represents a mapping that is
   routable on the global Internet). An ISATAP interface index parameter and deletes the entry from the
   'tunnelInetConfigTable'. This has the result of simultaneously
   deleting MUST NOT
   configure a locator set that spans multiple sites.

   ISATAP interfaces configure the 'tunnelIfEntry' and 'ifEntry' following objects in tunnelIfEntry:

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

   -  tunnelIfLocalInetAddress is set to an IPv4 address from their respective
   tables. The driver also removes the corresponding forwarding table
   entry
      interface's locator set.

   -  tunnelIfRemoteInetAddress is set to 0.0.0.0 to denote wildcard
      match for the remote tunnel interface from the 'ifRcvAddressTable'.

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

7.2.3 TUNNEL_MODIFY

   ISATAP drivers implement a 'TUNNEL_MODIFY' primitive that provides a
   means for modifying all endpoints.

   -  other read-write objects associated with the
   'tunnelIfEntry' and for adding or deleting entries from in the list of
   receive addresses tunnelIfEntry are configured as
      for the tunnel. The primitive any tunnel interface.

   ISATAP interfaces also provides a flag
   for specifying whether configure the desired operation following objects in
   ipv6InterfaceEntry:

   -  ipv6InterfaceType is "add" or "delete".

   (For vector objects, the "add"/"delete" operations have the meaning
   intended by their names; for scalar objects, the ISATAP driver
   interprets an "add" operation as: "change 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 tunnel creation request. Configured tunnel
   interfaces are configured as for ISATAP driver returns either
   success or a failure code.

7.2.4 TUNNEL_DUP

   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 be created as independent entities and
   configure their own locator set, but (as for ISATAP interfaces) they
   MUST NOT configure a duplicate forwarding table entry in the 'ifRcvAddressTable' using
   the existing entry identified by locator set that spans multiple sites.

7.6 Reconfigurations Due to IPv4 Address Changes

   When a locator becomes deprecated (e.g., when an IPv4 address is
   removed from an IPv4 interface) the locator SHOULD be removed from
   all tunnel interface index parameter associations via RcvTableDel(locator, NULL).
   Also, all tunnel interfaces that used the deprecated IPv4 address as
   tunnelIfLocalInetAddress SHOULD configure a
   prototype, then sets different local IPv4
   address from their remaining locator set.

   When a new IPv4 address is added to an IPv4 interface, the newly-created forwarding entry's index node MAY
   add the corresponding new locator to the 'ifIndex' locator set for the newly-created one or more
   tunnel interface.

   After performing interfaces via RcvTableAdd(locator, tunnel_interface), and MAY
   set tunnelIfLocalInetAddress for tunnel interfaces referenced by the above actions,
   updated forwarding entries to the ISATAP driver returns either
   an interface index new address.

   Methods for triggering the newly-created tunnel interface or a
   failure code.

7.2.5 TUNNEL_GET

   To aid network administrators, ISATAP drivers SHOULD implement a
   'TUNNEL_GET' primitive that returns the current configuration above changes, and for communicating IPv4
   address changes to remote nodes, are out of all
   tables in the system associated with scope.

8. Automatic Tunneling

   ISATAP nodes use the basic tunneling mechanisms specified tunnel interface.

   When a user application issues a 'TUNNEL_GET' primitive, it includes
   an index in [MECH].
   The following additional specifications are also used:

8.1 Encapsulation

   The ISATAP driver encapsulates IPv6 packets in IPv4 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 others.

   AH [RFC2402] and/or ESP [RFC2406] processing and header compression
   for a tunnel interface from a previous 'TUNNEL_CREATE' or
   'TUNNEL_DUP' primitive, a pointer the packet's inner headers are performed prior to a character buffer encapsulation.

8.1.1 NAT Traversal

   Native IPv6 and/or ip-protocol-41 encapsulation provides sufficient
   functionality to receive
   the configuration information, and an integer indicating support peer-to-peer communications when both peers
   reside within the
   available space in same site (i.e., the buffer. same enterprise network). When
   the remote peer resides within a different site, NAT traversal via
   UDP/IPv4 encapsulation MAY be necessary.

   When an ISATAP driver processes node determines that NAT traversal is necessary to
   reach a 'TUNNEL_GET' primitive, particular peer, it
   prepares encapsulates IPv6 packets using UDP/IPv4
   encapsulation with a character string that includes the concatenation UDP destination port of the
   'tunnelIfEntry' and the 'ifRcvAddressTable' entry for the tunnel
   interface identified by the index parameter. (The 'ifEntry' is not
   concatenated, since its contents 3544. This determination
   may be examined come through, e.g., first attempting communications via primitives from
   other APIs.) Next, the driver copies the character string to the
   server daemon's character buffer up ip-
   protocol-41 then failing over to UDP/IPv4 port 3544 encapsulation,
   administrative knowledge that a NAT traversal will occur along the specified available buffer
   space.

   After performing the above actions,
   path, etc.

   When UDP/IPv4 port 3544 encapsulation is used, the ISATAP driver returns either specifications in
   this document apply the number same as for any form of bytes copied or a failure code (to include a code that
   indicates "operation not supported").

7.3 ISATAP Interface Configuration encapsulation
   supported by ISATAP.

8.1.2 Multicast

   ISATAP interfaces 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 encapsulate packets with IPv6 multicast destination
   addresses using a node creates (or later modifies) an
   ISATAP interface, it assigns to mapped Organization-Local Scope IPv4 multicast
   address ([RFC2529], section 6) as the interface one or more receive destination address that consists of an in the
   encapsulating IPv4 address header.

8.2 Tunnel MTU and an index for Fragmentation

   Encapsulated packets may incur host-based IPv4 fragmentation, e.g.,
   when the
   interface underlying physical link has a small IPv4 MTU [BCP0048]. In
   such cases, host-based IPv4 fragmentation is required to which satisfy the address
   1280 byte IPv6 minimum MTU, and is assigned (i.e,. an IPv4
   address-to-interface mapping). Each receive address assigned MUST
   represent a mapping for not considered harmful [FRAG]. On
   the same site (or, MUST represent a mapping
   that is routable on other hand, unmitigated IPv4 fragmentation caused by the global Internet), i.e., network
   can cause poor performance. For example, since the receive addresses
   assigned to minimum IPv4
   fragment size is only 8 bytes [STD0005], network middleboxes could
   shred a single tunnel interface MUST NOT span multiple sites. 1280 byte tunneled packet into as many as 160 IPv4 fragments.

   ISATAP nodes issue 'TUNNEL_CREATE' uses the MTU and 'TUNNEL_MODIFY' primitives fragmentation specifications in ([MECH],
   section 3.2) and the Maximum Reassembly Unit (MRU) specifications in
   ([MECH], section 3.6), which provide sufficient measures for 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 interfaces nodes SHOULD add the same as for any tunnel interface;
   'TUNNEL_CREATE' primitives include a parameter to set
   'tunnelIfEncapsMethod' to an 'IANATunnelType' code for "isatap". A
   'TUNNEL_CREATE' or 'TUNNEL_MODIFY' primitive that includes parameters
   to set 'tunnelIfLocalInetAddress' following simple
   instrumentation to an the IPv4 address that will be
   used as one reassembly cache:

   When the initial fragment of an encapsulated packet arrives, the interface's receive addresses, and
   'tunnelIfRemoteInetAddress' to 0.0.0.0 to denote wildcard match for
   remote tunnel endpoints SHOULD be issued before the IPv6 interface
   associated with the tunnel interface is enabled (see below).

   When an ISATAP interface
   packet's IPv4 reassembly timer is created, set to 1 second (i.e., the ISATAP driver also creates worst
   case store-and-forward delay budget for a 1280 byte packet). If an 'ipv6InterfaceEntry' as
   encapsulated packet's IPv4 reassembly timer expires:

   -  If enough contiguous leading bytes of the companion 'ifEntry' to packet have arrived
      (see: section 8.6), reassemble the
   'tunnelIfEntry'. After setting packet from all fragments
      received.  (Otherwise, garbage-collect the required objects 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
   'tunnelIfEntry' (see above), packet as "INCOMPLETE", and also mark it with a
      "TOTAL_BYTES" length that encodes the ISATAP node configures objects total number of data bytes
      in fragments that arrived.

   -  Deliver the 'ipv6InterfaceEntry' for an ISATAP interface packet to the same ISATAP driver as for any though reassembly had
      succeeded.

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

   Appendix C provides informative text on the derivation of the 1280
   byte IPv6 interface. For minimum MTU.

8.3 Handling ICMPv4 Errors

   ISATAP interfaces (and other tunnel interfaces
   that use IPv4 SHOULD process ARP failures and persistent ICMPv4
   errors as link-specific information indicating that a link layer for IPv6 ), the node sets the
   'ipv6InterfaceType' object to "tunnel". Next, the node sets the
   'ipv6InterfacePhysicalAddress' object path to an IPv4 address that will be
   used a
   neighbor may have failed ([RFC2461], section 7.3.3).

8.4 Link-Local Addresses

   ISATAP interfaces use link local addresses constructed as one specified
   in section 6.1 of the tunnel interface's receive addresses; this object
   MUST be formatted as a 4-octet entity containing an IPv4 address document.

8.5 Neighbor Discovery over Tunnels

   The specification in
   network byte order ([RFC2223bis], ([MECH], section 3.4). The node next sets
   the 'ipv6ScopeZoneIndexLinkLocal' object to a zone index identifier
   that denotes 3.8) is used; the site additional
   specification for which the tunnel interface's receive
   addresses neighbor discovery in section 9 of this document
   are valid. Finally, also used.

8.6 Decapsulation/Filtering

   ISATAP nodes typically arrange for the node configures ISATAP driver to receive all other required
   read-write parameters in the 'ipv6InterfaceEntry' as for any
   IPv4-encapsulated IPv6
   interface, and sets 'ipv6InterfaceAdminStatus' packets that are addressed to "up".

   After configuring 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, driver uses the node sets decapsulation and filtering
   specifications in ([MECH], section 3.6), and processes each packet
   according to the interface's
   'ipv6InterfaceForwarding' object (and, if necessary, following steps:

   1.  Locate the node's
   'ip6Forwarding' object) correct tunnel interface to "forwarding". The node also creates an
   'ipv6RouterAdvertEntry' in receive the packet (see:
       section 7.2.3). If not found, silently discard the 'ipv6RouterAdvertTable' packet and sets
       return from processing.

   2.  If the
   'ipv6RouterAdvertIfIndex' object to tunnel uses header compression, reconstitute headers.  If
       header reconstitution fails, silently discard the same value packet and
       return from processing.

   3.  Verify that the packet's IPv4 source address is correct for the
       encapsulated IPv6 source address. For packets received on a
       configured tunnel interface, verification is exactly as
   'ipv6InterfaceIfIndex'. Objects specified
       in ([MECH], section 3.6).

       For packets received on an ISATAP interface, the 'ipv6RouterAdvertEntry' for IPv4 source
       address is correct if:

       -  the IPv6 source address is an ISATAP address that embeds the
          IPv4 source address in its interface are configured as for any identifier, or:

       -  the IPv6 router, however
   'ipv6RouterAdvertLinkMTU' SHOULD NOT be set to a value other than 0
   unless source address is the address of an IPv6 neighbor on
          an ISATAP driver will monitor interface associated with the locator that matched
          the packet (see: section 7.2.3), or:

       -  the IPv4 reassembly cache and
   report fragmentation source address is a member of tunneled packets to the source by sending
   IPv6 Potential Router Advertisements with MTU options
          List (see: Section 8.3).
   Configuration of objects relating to IPv6 forwarding is normally
   managed by section 9.1).

       If the ISATAP server daemon.

7.4 Dynamic Creation of Configured Tunnels

   Configured tunnels are normally created through ISATAP driver API
   calls issued IPv4 source address is incorrect, silently discard the
       packet and return from processing.

   4.  Perform IPv4 ingress filtering (optional; disabled by an ISATAP server daemon in dynamic response to a
   tunnel creation request. Configured tunnel interfaces are created as
   for ISATAP interfaces default)
       then decapsulate the packet. If the IPv6 source address is
       invalid (see: Section 7.3), except that [MECH], section 3.6), silently discard the
   'tunnelIfRemoteInetAddress' for packet
       and return from processing.

       For UDP port 3544 packets received on an ISATAP interface, if the new entry
       IPv6 source address is normally an ISATAP link local address with the 'u'
       bit set to a
   specific 0 and an embedded IPv4 address for a remote node at that does not match the far end of
       IPv4 source address (see: section 6), rewrite the tunnel,
   i.e., configured tunnels are normally configured as point-to-point.
   As for ISATAP interfaces, configured tunnels MUST NOT select a list
   of receive IPv6 source
       address mappings that span multiple sites.

   Processes that create configured tunnels may find to inform upper layers of the 'TUNNEL_DUP'
   primitive useful (and, in some cases essential) sender's mapped UDP port
       number and IPv4 source address.  Specific rules for reducing
   administrative complexity. An rewriting the
       IPv6 source address are established during ISATAP interface may be used as the
   prototype for
       configuration.

       Next, discard encapsulating headers and continue processing the 'TUNNEL_DUP' primitive;
       encapsulated IPv6 packet.

   5.  Perform ingress filtering on the configured tunnel
   interface inherits IPv6 source address (see:
       [MECH], section 3.6). Next, determine the attributes of correct transport
       protocol listener [FLOW] if the ISATAP interface, including packet is destined to the
       localhost; otherwise, perform an IPv6 forwarding table entry in the system's 'ifRecvAddressTable'.
   After creating a configured tunnel via the 'TUNNEL_DUP' primitive, lookup and
       site border/firewall filtering (see: [UNIQUE], section 6).

       If the process uses packet cannot be delivered, the 'TUNNEL_MODIFY' primitive to modify specific
   attributes.

7.5 Reconfigurations Due to IPv4 Address Changes

   When an 'ipAddressEntry' becomes deprecated (e.g., when driver SHOULD send an IPv4
   address is removed from an IPv4 interface)
       ICMPv6 Destination Unreachable message ([RFC2463], section 3.2)
       to the 'ipAddressEntry' MUST
   be removed packet's source. The message SHOULD select as its source
       address an IPv6 address from all forwarding entries in the 'ifRcvAddressTable'
   that referenced it. Also, all 'tunnelIfEntry's that used
   'ipAddressAddr' as 'tunnelIfLocalInetAddress' and
   'ipv6InterfaceEntry's that used 'ipAddressAddr' as
   'ipv6InterfacePhysicalAddress' MUST select a different IPv4 outgoing interface (if the
       packet was destined to the localhost) or an ingress-wise correct
       IPv6 address
   for those objects from their remaining list the interface that would have forwarded the
       packet had it not been filtered.

       The Code field of receive addresses.
   Methods for triggering the mandatory changes are implementor's
   choice.

   When a new IPv4 address message is added set as follows:

       -  if there is no route to an IPv4 interface, the node MAY
   add destination, the new 'ipAddressEntry' Code field is set
          to 0 (see: [RFC2463], section 3.1).

       -  if communication with the list of receive addresses for
   forwarding entries in 'ifRcvAddressTable', and MAY destination is administratively
          prohibited, the Code field is set
   'tunnelIfLocalInetAddress' and/or 'ipv6InterfacePhysicalAddress' for
   interfaces referenced by to 1 ([RFC2463], section
          3.1).

       -  if the updated forwarding entries packet is destined to the new
   address.

8. Automatic Tunneling

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

8.1 Encapsulation

   The ISATAP driver transport
          protocol has no listener, the Code field is responsible for inserting set to 4
          ([RFC2463], section 3.1).

       -  if 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 configured as
   encapsulation clients packet's destination is beyond the scope 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 source
          address, the Code field is set to encapsulation.

8.2 Multicast/Anycast

   ISATAP interfaces tunnel only those packets with IPv6 multicast/
   anycast destinations 2 (see: IANA
          Considerations).

       -  if the packet was dropped due to include a node's required multicast/anycast
   addresses, ingress filtering policies,
          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.

   ISATAP interfaces automatically tunnel IPv6 multicast packets with Code field is set to 5 (see: IANA Considerations).

       -  if the 'All_DHCP_Relay_Agents_and_Servers' and 'All_DHCP_Servers' using packet is dropped due to a reject route, the IPv4 'all hosts' broadcast address (i.e., 0xffffffff broadcast
   address) as Code field
          is set to 6 (see: IANA Considerations).

       -  if the destination packet was received on a point-to-point link and
          destined to an address in within a subnet assigned to that same
          link, or if the encapsulating IPv4 header
   under reason for the assumption that DHCPv6 servers will failure to deliver cannot be co-located with
   DHCPv4 servers.

   For other IPv6 multicast destinations, ISATAP interfaces
   automatically tunnel packets using a
          mapped Organization-Local Scope
   IPv4 multicast address ([RFC2529], to any of the specific conditions listed above, the
          Code field is set to 3 ([RFC2463], section 6) as 3.2).

       After sending the destination
   address in ICMPv6 Destination Unreachable message, discard
       the encapsulating IPv4 header. ISATAP nodes join packet and return from processing.

   6.  If the
   Organization-Local Scope IPv4 multicast groups required packet is "INCOMPLETE" (see section 8.2) send an
       authenticated, unsolicited Router Advertisement message
       ([RFC2461], section 6.2.4) to support the packet's IPv6 Neighbor Discovery ([RFC2529], Appendix A) on interfaces that
   may receive IPv4 packets to be forwarded to source address
       with an ISATAP interface.

   NOTE: When MTU option that encodes "TOTAL_BYTES".

   7.  If the ISATAP node enables one or more 6over4 interfaces
   [RFC2529], packet was destined to a remote host, forward the 6over4 interfaces MAY be used (i.e., instead of ISATAP
   interfaces) for sending packet
       and receiving multicast packets.

8.3 Tunnel MTU return from processing. Otherwise, apply AH [RFC2402] or ESP
       [RFC2406] processing (if necessary), and Fragmentation

   The specification in ([MECH], section 3.2) is not used; deliver the
   specification decapsulated
       packet by placing it in this section is used instead:

   ISATAP interfaces set a static MTU of 1280 bytes, i.e., the minimum
   MTU for IPv6 interfaces ([RFC2460], section 5) and do not set the
   Don't Fragment bit in 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 buffer for certain constrained deployments, e.g., in some enterprise
   networks). Interfaces that upper layers. The buffer may receive IPv4 packets to be forwarded
   to
       be, e.g., the IPv6 reassembly cache, an ISATAP interface SHOULD configure application's mapped data
       buffer [RFC3542], etc.

       If there is clear evidence that upper layer reassembly has
       stalled, an Effective MTU to Receive
   (EMTU_R) [RFC1122], section 3.3.2) of at least 1500 bytes, i.e., they
   SHOULD ICMPv6 Packet Too Big message [RFC1981] MAY be able to reassemble IPv4 packets of 1500 bytes or larger.

   1280 bytes was chosen as the IPv6 interface minimum MTU [DEERING97] sent
       to allow extra room for link layer encapsulations without exceeding
   the Ethernet MTU of 1500 bytes, i.e., the practical physical cell
   size of the Internet. The 1280 byte packet's source address with an MTU provides value indicating a fixed upper bound
   for the
       size that is likely to incur successful reassembly. Some
       applications may realize greater efficiency by accepting partial
       information from "INCOMPLETE" packets (see: section 8.2) and
       requesting selective retransmission of IPv6 packets/fragments with a maximum
   store-and-forward delay budget of ~1 second assuming worst-case link
   speeds of ~10Kbps [RFC3150], thus allowing a convenient value missing portions.

9. Neighbor Discovery for ISATAP Interfaces

   ISATAP nodes use
   in reassembly buffer timer settings. Finally, the 1280 byte MTU
   allows transport connections neighbor discovery mechanisms specified in
   [RFC2461] along with securing mechanisms (e.g., TCP) [SEND]) to configure a large-enough
   maximum segment size create/
   change neighbor cache entries and to provide control plane signaling
   for improved performance even if the IPv4
   interface that will send the tunneled packets uses a smaller MTU.

   When the size of automatic tunnel configuration. ISATAP interfaces also implement
   the IPv6 destination's receive buffer is known,
   applications MAY send IPv6 packets up to that size using IPv6
   fragmentation (or, fragmentation via an alternate form of
   encapsulation) with a maximum fragment size that is no larger than following specifications:

9.1 Conceptual Model Of A Host

   To the minimum list of the MTU Conceptual Data Structures ([RFC2461], section 5.1),
   ISATAP interfaces add:

   Potential Router List
      A set of the IPv4 interface entries about potential routers; used for tunneling and
   1280 bytes. Even so, IPv4 fragmentation MAY still occur along some
   paths; in particular, since to support the minimum IPv4 fragment size is only 8
   bytes ([RFC0791],
      mechanisms specified in  section 2), middleboxes with unusual
   implementations of IPv4 fragmentation could shatter the tunneled
   packets into as many as 187 9.2.2.1. Each entry ("PRL(i)")
      has an associated timer ("TIMER(i)"), and an IPv4 fragments to accommodate address
      ("V4ADDR(i)") that represents a 1500 byte
   IPv4 packet. Such sustained bursts of small packets could result in
   poor performance due to increased loss probability on paths with
   non-negligible packet loss due to, e.g., link errors, congested
   router queues, etc.

   Therefore, router's advertising ISATAP nodes that anticipate or experience poor
   performance along some paths MAY choose
      interface.

9.2 Router and Prefix Discovery

9.2.1 Router Specification

   As permitted by ([RFC2461], section 6.2.6), the ISATAP daemon SHOULD
   send unicast Router Advertisement messages to adaptively vary the
   maximum size for soliciting node's
   address when the packets/fragments they send. For example,
   implementations may choose to employ solicitation's source address is not the unspecified
   address. (Router Advertisements MAY include information delegated via
   DHCPv6 [RFC3633]).

   Routers MUST NOT send prefix options containing a "fragment size slow start"
   scheme that begins with as little as 8 bytes (i.e., preferred lifetime
   greater than the minimum IPv4
   fragment size) and varies valid lifetime.

9.2.2 Host Specification

9.2.2.1 Host Variables

   To the size list of host variables ([RFC2461], section 6.3.2), ISATAP
   interfaces add:

   PrlRefreshInterval
      Time in seconds between successive refreshments of the fragments using, e.g., 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 advertising ISATAP interface. The designated value of all 1's
      (0xffffffff) represents infinity.
      Default: 900 seconds

9.2.2.2 Potential Router List Initialization

   ISATAP nodes provision an
   additive-increase, multiplicative-decrease strategy to determine 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 established via manual configuration or an unspecified
   alternate method. FQDNs are resolved into IPv4 addresses through
   lookup in a static host file, querying the
   size that yields DNS service, or an
   unspecified alternate method.

   When the best performance. The process can be made node provisions an ISATAP interface's PRL with IPv4
   addresses, it sets a timer for the interface (e.g.,
   PrlRefreshIntervalTimer) to
   converge more quickly PrlRefreshInterval seconds. The node re-
   initializes the PRL as specified above when next-hop IPv6 routers are configured PrlRefreshIntervalTimer
   expires, or when an asynchronous re-initialization event occurs. When
   the node re-initializes the PRL, it resets PrlRefreshIntervalTimer to
   send
   PrlRefreshInterval seconds.

9.2.2.3 Processing Received Router Advertisements

   The ISATAP daemon processes Router Advertisements (RAs) exactly as
   specified in ([RFC2461], section 6.3.4). The DHCPv6 specification
   [RFC3315] is the stateful mechanism associated with MTU options when they experience IPv4
   fragmentation, since the sender is made aware that fragmentation is
   occurring, M and O bits.

   When the ISATAP daemon receives a Router Advertisement with an MTU
   option can be used to return from a router at the size far end of a tunnel, it records the
   largest IPv4 fragment observed which may help the sender determine
   the optimal fragment size.

   Since many nodes are expected to implement this specification, an
   overall increase in small packets
   advertised MTU value, e.g., in the Internet 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 node's IPv6 routing table. If the Internet [RFC2309]. In
   particular, byte mode queue averaging for RED
   MTU value is encouraged.

   With reference to less than the above, it is RECOMMENDED that ISATAP nodes use
   adaptive techniques to minimize IPv4 fragmentation and use IPv6
   fragmentation/reassembly (or, fragmentation/reassembly via an
   alternate form MTU of encapsulation) to manage the size of tunnel interface, the tunneled
   packets they send. It value is also RECOMMENDED
   recorded in such a way that ISATAP nodes monitor the IPv4 reassembly cache in order to give early indications of IPv4
   network node will perform upper layer
   fragmentation by sending Router Advertisements with MTU
   options to the source of (i.e., above the IPv4 fragments. The MTU options should
   include a value link layer) to indicate reduce the size of
   the largest packet that can
   be expected to arrive without incurring IPv4 fragmentation. Finally, encapsulated packets it sends via the router. The recorded
   value is RECOMMENDED that ISATAP nodes set small timeout values, e.g. 1
   second, for IPv4 reassembly of tunneled packets.

8.4 Handling IPv4 ICMP Errors

   ISATAP interfaces SHOULD process ARP failures and persistent ICMPv4
   errors aged as link-specific for IPv6 path MTU information indicating [RFC1981].

   For Router Advertisement messages that a path include prefix options, Route
   information options [DEFLT] and/or non-zero values in the Router
   Lifetime, the ISATAP daemon resets TIMER(i) to a
   neighbor may have failed ([RFC2461], schedule the next
   solicitation event (see: section 7.3.3).

8.5 Link-Local Addresses

   The specification 9.2.2.4). Let "MIN_LIFETIME" be the
   minimum value in ([MECH], section 3.7) is not used; the
   specification Router Lifetime or the lifetime(s) encoded in Section 6.1 of this document is used instead.

8.6 Neighbor Discovery over Tunnels

   The specification
   options included in ([MECH], section 3.8) is not used; the
   specification in Section 9 of this document RA message. Then, TIMER(i) is used instead.

8.7 Decapsulation/Filtering

   ISATAP nodes arrange for the ISATAP driver to received all tunneled
   packets that use an IPv4 header reset as
   follows:

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

9.2.2.4 Sending Router Solicitations

   To the outermost layer list 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.) and
   others. The events after which RSs may be sent ([RFC2461], section
   6.3.2), ISATAP driver determines the correct tunnel interface to
   receive each packet via a lookup in the 'ifRcvAdddressTable' interfaces add:

      -  TIMER(i) for the
   packet's IPv4 source address, destination address, some PRL(i) expires.

   Router Solicitations MAY be sent to an index ISATAP link-local address that
   embeds V4ADDR(i) for some PRL(i) instead of the
   receiving IPv4 interface All-Routers multicast
   address.

9.3 Address Resolution and the type of encapsulation. Packets Neighbor Unreachability Detection

9.3.1 Address Resolution

   The specification in ([RFC2461], section 7.2) is used. ISATAP
   addresses for which the correct tunnel interface neighbor/router's link-layer address cannot
   otherwise be determined (e.g., from a neighbor cache entry) are silently
   discarded.

   After determining the correct tunnel interface, the ISATAP driver
   verifies that the packet's
   resolved to link-layer (IPv4) source address is
   correct for the network-layer (IPv6) source address. For configured
   tunnels, the IPv4 and IPv6 source addresses can be checked directly
   against the configured tunnel's addresses. For ISATAP interfaces, the
   packet's link-layer source address is correct if one (or more) of by a static computation, i.e., the
   following
   last four octets are true:

   o  the network-layer source address is treated as an ISATAP address that embeds
      the link-layer source address in its interface identifier.

   o  the network-layer source address is an IPv6 neighbor on IPv4 address.

   Hosts SHOULD perform an
      interface that has the same 'ipv6ScopeZoneIndexLinkLocal' as the initial reachability confirmation by sending
   Neighbor Solicitation message(s) and receiving ISATAP interface.

   o  the link-layer source address is a member of the Potential Router
      List (see: Section 9.1).

   Packets for which the link-layer source address is incorrect Neighbor
   Advertisement message (NS messages are
   discarded and, if permitted by sent to the current status of ICMPv6 message
   rate limiting parameters [ICMPV6], 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 ([RFC2461], section 2.4, paragraph f), an
   ICMPv6 Destination Unreachable message 7.2.4).

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 Signaling

10.1 Domain Name System (DNS)

   The specifications in ([MECH], section 2.2) are used. Additional
   considerations are found in [DNSOPV6].

10.2 Linklocal Multicast Name Resolution (LLMNR)

   ISATAP nodes SHOULD implement Link Local Multicast Name Resolution
   [LLMNR], since they will commonly be generated and sent
   to the IPv6 source deployed in environments (e.g.,
   home networks, ad-hoc networks, etc.) with no DNS service.

10.3 Node Information Queries

   ISATAP nodes MAY implement Node Information Queries as specified in
   [NIQUERY], since they may help the inner header querier discover some subset of
   the encapsulated packet. responder's addresses.

11. Security considerations

   The error message SHOULD include only enough bytes from the invoking
   packet to convey security considerations in the IPv6 header information, i.e., it normative references apply; also:

   -  site border routers SHOULD NOT
   include up to install a black hole route for the minimum IPv6 MTU.

   After determining the correct tunnel interface
      prefix FC00::/7 to receive the packet,
   the ISATAP driver examines the insure that packets with local IPv6 and IPv4 source destination
      addresses to
   determine whether will not be forwarded outside of the site via a rewrite default
      route.

   -  administrators MUST ensure that lists of IPv4 addresses
      representing the advertising ISATAP interfaces of PRL members are
      well maintained.

12. IANA Considerations

   The IANA is required. If instructed to specify the IPv6 source 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
   an ISATAP address with example specification.
   The current version of the 'u/l' and 'g' bits set IANA registry for Ether Types can be
   accessed at http://www.iana.org/assignments/ethernet-numbers.

   The IANA is instructed to 0 (see:
   Section 6.1), and assign the IPv4 source address does not match new ICMPv6 code field types
   found in Appendix E of this document for the IPv4
   address encoded 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 ISATAP interface identifier, IANA registry for ICMPv6 type numbers can be
   accessed at http://www.iana.org/assignments/icmpv6-parameters.

13. IAB Considerations

   [RFC3424] ("IAB Considerations for UNilateral Self-Address Fixing
   (UNSAF) Across Network Address Translation") section 4 requires that
   any proposal supporting NAT traversal must explicitly address the
   following considerations:

13.1 Problem Definition

   The specific problem being solved is enabling IPv6 connectivity for
   ISATAP driver
   copies the IPv4 source address over 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 IPv4 address embedded
   system in several ways: the
   IPv6 address and sets the 'u/l' bit to 1. Other forms discovery process assumes a certain
   classification of rewrites
   (e.g., rewrites for multicast rendezvous points devices based on their treatment of UDP; the 'u'
   mappings need to be continuously refreshed, and
   'g' bit) MAY addressing structure
   may cause some hosts located beyond a common NAT to be specified in other documents.

   Next, the unreachable
   from each other.

   ISATAP driver discards 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, 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 the packet is assumes a fragment, it is placed in a buffer for
      reassembly. certain classification of devices based on their
   treatment of UDP. There could be devices that would not fit into one
   of these molds, and hence would be improperly classified by ISATAP.

   The buffer may be, e.g., bindings allocated from the IPv6 reassembly cache, an
      application's own data buffer [RFC3542], etc.

   Finally, when a whole packet has been received, it is delivered NAT need to be continuously
   refreshed.  Since the correct tunnel interface. If there timeouts for these bindings is clear evidence that
   reassembly of a fragmented packet has stalled, an ICMPv6 "packet too
   big" message [RFC1981] very
   implementation specific, the refresh interval cannot easily be
   determined.  When the binding is sent not being actively used to the packet's source address
   (subject receive
   traffic, but to ICMPv6 rate-limiting) with wait for an MTU value indicating incoming message, the binding refresh
   will needlessly consume network bandwidth.

13.4 Requirements for a size Long Term Solution

   The devices that is likely to incur successful reassembly.

9. Neighbor Discovery

   ISATAP nodes use implement the neighbor discovery mechanisms specified IPv4 NAT service should 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 the future
   also implement become IPv6 routers.

14. Acknowledgments

   The ideas in this document are not original, and the following specifications:

9.1 Conceptual Model Of A Host

   To authors
   acknowledge the list of Conceptual Data Structures ([RFC2461], section 5.1),
   ISATAP interfaces add:

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

9.2 Router this work were
   sponsored through SRI International internal projects and Prefix Discovery

9.2.1 Router Specification

   As permitted by ([RFC2461], section 6.2.6), the ISATAP server daemon
   SHOULD send unicast Router Advertisement messages to the soliciting
   node's address when the solicitation's source address is not the
   unspecified address.

9.2.2 Host Specification

9.2.2.1 Host Variables

   To the list of host variables ([RFC2461], section 6.3.2), ISATAP
   interfaces add:

   PrlRefreshInterval
      Time in seconds between successive refreshments of the 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 advertising ISATAP interface. It SHOULD be no less than 900
      seconds. The designated value government
   contracts. Government sponsors include Monica Farah-Stapleton and
   Russell Langan (U.S. Army CECOM ASEO), and Dr.  Allen Moshfegh (U.S.
   Office of alll 1's (0xffffffff) represents
      infinity.

      Default: 900 seconds

9.2.2.2 Interface Initialization Naval Research). SRI International sponsors include Dr.
   Mike Frankel, J. Peter Marcotullio, Lou Rodriguez, and Dr. Ambatipudi
   Sastry.

   The ISATAP node joins the all-nodes multicast address on ISATAP
   interfaces, as following are acknowledged for multicast-capable interfaces ([RFC2461], section
   6.3.3) and MAY also join other multicast groups, e.g., see: Section
   8.2

   Additionally, the node provisions the ISATAP interface's PRL with
   IPv4 addresses it discovers 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 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 the ISATAP interface's PRL with IPv4
   addresses, it sets PrlRefreshIntervalTimer to PrlRefreshInterval
   seconds. providing peer review input: Jim
   Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader,
   Ole Troan, Vlad Yasevich.

   The node re-initializes the PRL (i.e., as specified above)
   when PrlRefreshIntervalTimer expires, or when an asynchronous
   re-initialization event occurs. When the node re-initializes the PRL,
   it resets PrlRefreshIntervalTimer to PrlRefreshInterval seconds.

9.2.2.3 Processing Received Router Advertisements 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 ISATAP server daemon processes Router Advertisements (RAs)
   exactly as specified in ([RFC2461], section 6.3.4). Router
   Advertisement messages received on a point-to-point tunnel interface
   that contain an MTU option with a value less than 1280 bytes cause
   the interface to reduce its MTU to authors acknowledge the lesser value, but Router
   Advertisements received work of Quang Nguyen on an ISATAP interface MUST NOT cause "Virtual
   Ethernet" under the
   ISATAP interface to reduce its MTU guidance of Dr. Lixia Zhang that proposed very
   similar ideas to a value less than 1280 bytes.

   For Router Advertisement messages received on an ISATAP interface those that include prefix options and/or non-zero values appear in the Router
   Lifetime, the server daemon reset TIMER(i) this document. This work was
   first brought to schedule the next
   solicitation event (see: Section 9.2.2.4). Let "MIN_LIFETIME" be the
   minimum value in the Router Lifetime or the lifetime(s) encoded in
   options included in authors' attention on September 20, 2002.

   IAB considerations are the RA message. Then, TIMER(i) is reset same as
   follows:

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

9.2.2.4 Sending Router Solicitations

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

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

   Additionally, Teredo.

   The following individuals are acknowledged 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 and the ISATAP server daemon MAY send Router Solicitations
   to an ISATAP link-local address that embeds V4ADDR(i) for some PRL(i)
   instead members of the All-Routers multicast address.

9.3 Address Resolution and Neighbor Unreachability Detection

9.3.1 Address Resolution

   The specification in ([RFC2461], section 7.2) is used. ISATAP
   addresses for which Nokia NRC/
   COM Mountain View team.

      "...and I'm one step ahead of the neighbor/router's link-layer address cannot
   otherwise be determined (e.g., shoe shine,
       Two steps away from a neighbor cache entry) are
   resolved to link-layer addresses by a static computation, i.e., 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 keep my customers satisfied,
       Satisfi-i-ied!" - Paul Simon, 1969

Appendix A. Major Changes

   Major changes from earlier versions to version 17:

   -  changed first words in ([RFC2461], title from "Intra-site" to "Internet/site"
      to more accurately represent the functionality.

   -  new 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], configuration/management.

   -  new appendices on tunnel driver API; IANA considerations.

   -  expanded 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 on MTU and fragmentation.

   -  expanded sections on encapsulation/decapsulation.

   -  specified relation to IPv6 Node Information Queries Requirements.

   -  introduced distinction between control; user planes.

   -  specified multicast mappings.

   -  revised neighbor discovery, address autoconfiguration, IANA
      considerations and security considerations sections.

Appendix B. Example ISATAP nodes SHOULD implement Node Information Queries Driver API

   An ISATAP driver API should include primitives for sending and
   receiving control plane messages as well as primitives for tunnel
   configuration/management such as specified
   in [NIQUERY].

   Node Information Queries/Responses provide the following advantages:

   o non-normative
   examples:

B.1 ISATAP_SEND, ISATAP_RECEIVE Primitives

      Description:
         Sends/Receives control plane messages via the querier receives unambiguous confirmation that
         ISATAP driver (e.g., via a routing socket, etc.)

B.2 ISATAP_CREATE Primitive

      Description:
         Creates a new tunnel interface and an associated IP
         interface by creating a row in tunnelIfConfigTable.
         Also optionally configures read-write objects for the responder
      supports
         tunnel interface and adds locators to the protocol.

   o receive address
         table via RcvTableAdd(locator, tunnel_interface).
      Required parameter:
         - tunnelIfEncapsMethod.
      Optional parameters:
         - attributes for configuring read-write objects.
         - list of locators to associate with tunnel interface.
      Returns:
         - ifIndex for the querier receives assurance that responses are coming from new tunnel interface, or a failure code.

B.3 ISATAP_DELETE Primitive

      Description:
         Deletes an existing tunnel interface by deleting the
      correct responder.

   o
         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 querier discovers some subset tunnel interface.
         - list 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 in environments (e.g.,
   home networks, ad-hoc networks, etc.) locators to associate with no access tunnel interface.
         - list of locators to delete from association.
      Returns:
         - success or a Domain Name
   System (DNS) server.

11. IANA Considerations

   The IANA is advised failure code.

B.5 ISATAP_BIND Primitive

      Description:
         Binds (or, creates then binds) a configured tunnel interface
         to specify construction rules an ISATAP interface. The 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 the ISATAP interface.
         - ifIndex for IEEE EUI-64
   addresses formed from the Organizationally Unique Identifier (OUI)
   "00-00-5E" in configured tunnel interface, or NULL.
      Conditional parameter:
         - if ifIndex for the IANA "ethernet-numbers" registry. The non-normative
   text in Appendix B configured tunnel is offered as an example specification.

12. Security considerations

   The security considerations in NULL,
           tunnelIfEncapsMethod.
      Optional parameters:
         - attributes for configuring read-write objects for the normative references apply.

   Additionally, administrators MUST ensure that lists of IPv4 addresses
   representing
           configured tunnel interface.
      Returns:
         - ifIndex for the advertising ISATAP interfaces 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 PRL members are
   well maintained.

13. Acknowledgments

   Most a buffer in calling process's memory.
         - number of the basic ideas bytes available in this document are not original; the
   authors acknowledge 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 and Russell Langan (U.S. Army CECOM ASEO), and Dr.
   Allen Moshfegh (U.S. Office user's buffer.
      Returns:
         -  Number of Naval Research). SRI International
   sponsors include Dr.  Mike Frankel, J. Peter Marcotullio, Lou
   Rodriguez, and Dr. Ambatipudi Sastry. bytes written into the calling process'
            buffer, or a failure code.

Appendix C. The following are acknowledged for providing peer review input: Jim
   Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader,
   Ole Troan, Vlad Yasevich. IPv6 minimum MTU

   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. 1280 byte IPv6 minimum MTU was proposed by Steve Deering and
   agreed through working group consensus in November 1997 discussions
   on the IPv6 mailing list. The authors acknowledge size was chosen to allow extra room for
   link layer encapsulations without exceeding the work Ethernet MTU of Quang Nguyen [VET] under 1500
   bytes, i.e., the
   guidance practical physical cell size of Dr. Lixia Zhang that proposed very similar ideas the Internet. The
   1280 byte MTU also provides a fixed upper bound for the 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 reassembly buffer timer
   settings. Finally, the 1280 byte MTU allows transport connections
   (e.g., TCP) to those configure a large-enough maximum segment size for
   improved performance even if the IPv4 interface that appear will send the
   tunneled packets uses a smaller MTU.

Appendix D. Modified EUI-64 Addresses in this document. This work was first brought to the
   authors' attention on September 20, 2002.

   The following individuals IANA Ethernet Address Block

   Modified EUI-64 addresses ([ADDR], Appendix A) in the IANA Ethernet
   Address Block are acknowledged 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 and formed as the members 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
   When the first octet of the Nokia NRC/
   COM Mountain View team.

      "...and I'm one step ahead extension identifier encodes the
   hexadecimal value 0xFE, the remainder of the shoe shine,
       Two steps away from extension identifier
   encodes a 32-bit IPv4 address, as specified in ([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 county line,
       Just trying "u" bit, i.e., the "u" bit is set 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 in
              progress), October 2003.

   [ICMPV6]   Conta, A. one (1) to indicate
   universal scope and S. Deering, "Internet Control Message
              Protocol (ICMPv6) 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 Internet Protocol Version 6
              (IPv6) Specification", draft-ietf-ipngwg-icmp-v3 (work in
              progress), November 2001.

   [LLMNR]    Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast
              Name Resolution", draft-ietf-dnsext-mdns (work
   ICMPv6 Destination Unreachable message. The first proposes a new
   definition for a currently-unassigned code type (2) in
              progress), January 2004.

   [MECH]     Gilligan, R. and E. Nordmark, "Basic Transition Mechanisms the ICMPv6
   Type Numbers registry; the others propose new definitions for IPv6 Hosts code
   types (5) and Routers", draft-ietf-v6ops-mech-v2-00
              (work in progress), February 2003.

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

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

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

   [RFC1122] (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, 3, RFC 1122, October 1989.

[STD0005]  Postel, J., "Internet Protocol", STD 5, RFC 1122, October 1989. 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.

[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 S. Deering, V. Gill, "Goals for IPv6 Site-
   Multihoming Architectures", RFC 3582, August 2003.

[RFC3633]  Troan, O. and R. Droms, "IPv6 Flow Label Specification",
              draft-ietf-ipv6-flow-label (work in progress), Prefix Options for Dynamic Host
   Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.

   [FTMIB]    Haberman, B.

[ADDR]     Hinden, R. and M. Wasserman, S. Deering, "IP Forwarding Table MIB",
              draft-ietf-ipv6-rfc2096-update (work in progress), August
              2003.

   [IPMIB]    Routhier, S., "Management Information Base for the
              Internet Protocol (IP)", draft-ietf-ipv6-rfc2011-update Version 6 Addressing
   Architecture", draft-ietf-ipv6-addr-arch-v4 (work in progress), September 2003.

   [RFC1035]  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] 2003.

[AUTH]     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,

[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
   2004.

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

[NODEREQ]  Loughney, J., Davie, B., Deering,
              S., Estrin, D., Floyd, "IPv6 Node Requirements", draft-ietf-ipv6-node-
   requirements (work in progress), October 2003.

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

Informative References

[BCP0048]  Dawkins, S., Jacobson, V., Minshall, Montenegro, G.,
              Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
              S., Wroclawski, J. Kojo, M. and L. Zhang, "Recommendations on Queue
              Management V.  Magret, "End-
   to-end Performance Implications of Slow Links", BCP 48, RFC 3150,
   July 2001.

[STD0013]  Mockapetris, P., "Domain names - implementation and Congestion Avoidance in the Internet",
   specification", STD 13, RFC
              2309, April 1998. 1035, November 1987.

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

[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
   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 S., Fenner, W. and fragmentation

   o  expanded sections on encapsulation/decapsulation

   o  specified relation to 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 of "u" bit 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.

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) and "native" EUI64
   addresses Haberman, "Multicast Listener
   Discovery (MLD) 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 with "u" IPv6", RFC 2710, October 1999.

[RFC3056]  Carpenter, B. and "g" bits (3 octets)

      TYPE    Type field; specifies use K. Moore, "Connection 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 IPv6 Domains via
   IPv4 address
      0xFF         TSD is interpreted based 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 Clouds", RFC 3056, February 2001.

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

[ANYCAST]  Hagino, J. and other interpretations K. Ettikan, "An Analysis of TSE, TSD are
   reserved IPv6 Anycast",
   draft-ietf-ipngwg-ipv6-anycast-analysis (work in progress), June
   2003.

[DNSOPV6]  Durand, A., Ihren, J., and Savola P., "Operational
   Considerations and Issues with IPv6 DNS", draft-ietf-dnsop-ipv6-dns-
   issues, work-in-progress, January 2004.

[FLOW]     Rajahalme, J., Conta, A., Carpenter, B. and 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 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 future IANA use.) When TYPE='0xFE' the EUI64 address
   embeds an IPv4 address, encoded Internet
   Protocol (IP)", draft-ietf-ipv6-rfc2011-update (work in network byte order.

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

[NIQUERY]  Crawford, M., "IPv6 Node Information Queries", draft-ietf-
   ipngwg-icmp-name-lookups (work in IPv6 unicast
   addresses ([ADDR-ARCH], Appendix A) using IANA's OUI, when TYPE=0xFE
   and the IPv4 address is a globally unique (i.e., provider-assigned)
   unicast address, the "u" bit is set to 1 to indicate universal scope.
   When TYPE=0xFE progress), June 2003.

[SEND]     Arkko, J., Kempf, J., Sommerfield, B., Zill, B.  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 P.
   Nikander, "Secure Neighbor Discovery (SEND)", draft-ietf-send-ndopt
   (work in an IPv6 unicast address
   are either: '02-00-5E-FE' or: '00-00-5E-FE', progress), October 2003.

[TCPMIB]   Raghunarayan, R., "Management Information Base for the next four octets
   embed an IPv4 address and
   Transmission Control Protocol (TCP)", draft-ietf-ipv6-rfc2012-update
   (work in progress), November 2003.

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

[UDPMIB]   Raghunarayan, R., "Management Information Base for the interface identifier is said to be
   Transmission Control Protocol (TCP)", draft-ietf-ipv6-rfc2012-update
   (work in
   "ISATAP format". progress), November 2003.

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

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

Copyright (C) The Internet Society (2004). All Rights Reserved.

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.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.  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.