Subject: (ngtrans) draft

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 06 Sep 2002 12:35:50 -0700

Hello,

Randy Bush invited me to post a draft, so I'm including one below.
(Pls distribute further if I've missed anyone on the "To:" or "Cc:".)

Fred Templin
[email-masked]

P.S. Jim Fleming - I'm asking you a third time - WHO ARE YOU??

XXX Working Group                                             F. Templin
XXX-DRAFT                                                          Nokia

Expires Someday                                                    Today

                      ISATAP interactions with TSP

                      draft-templin-xxx

Status of this Memo

Abstract

   This document discusses interactions between the Intra-Site Automatic
   Tunnel Addressing Protocol (ISATAP) and the Tunnel Setup Protocol [TSP].

1. Introduction

   The Tunnel Setup Protocol [TSP] is an XML-based control protocol for
   establishing configured IPv6 or IPv4 tunnels between end-nodes. The
   protocol also sets up optional security associations between tunnel
   endpoints and provides autoconfiguration options including prefix
   delegation, DNS delegation, etc. [ISATAP] is an automatic tunneling
   mechanism that requires no pre-arranged configuration between tunnel
   endpoints, yet ISATAP may use TSP services in some instances. This
   document proposes a profile for ISATAP with or without the use of the
   TSP, or a stripped-down version thereof (call it "TSP-Lite").

2. Motivation

   ISATAP configures a single tunnel interface in system kernel data
   structures and uses finite soft-state caching for per-destination
   information. Conversely, configured tunnels [MECH] require per- des-
   tination hard state that grows linearly with the number of destina-
   tions. Thus, ISATAP does not suffer from finite scaling limitations
   and loss due to single point of failure as in the configured tunnels
   case. Also unlike configured tunnels, ISATAP derives IPv4 tunnel end-
   point addresses directly from the IPv6 addresses assigned to ISATAP
   links. Thus, communicating nodes can use automatic IPv6-in-IPv4
   encapsulation to send packets directly to one another without going
   through a tunnel endpoint server and without incurring connection
   setup latency to setup a configured tunnel, i.e., route optimization
   is automatically enabled.

Templin                      Expires Someday                    [Page 1]

XXX   Draft           ISATAP Interactions with TSP                 Today

   It would therefore seem that a stateful tunnel setup protocol such as
   TSP would have no application for an automatic tunneling mechanism
   such as ISATAP. But, in addition to tunnel setup, TSP also provides a
   rich autoconfiguration environment that could provide future benefits
   for ISATAP as well as a "poor man's method" for determining the maxi-
   mum receive unit (MRU) and maximum transmit unit (MTU)'s for the tun-
   nel endpoint interfaces . Thus, the following section presents an
   ISATAP profile using TSP (or, "TSP-lite").

3. ISATAP Profile for TSP or "TSP-lite"

   The TSP profile for ISATAP proposed by this document is similar to
   any TSP profile that might already exist for IPv6-in-IPv4 tunnels,
   with the exception that ISATAP defines a NULL TUNNELTYPE, meaning
   that NO configured tunnel state is created in the kernel. Thus, the
   full service set of TSP is NOT NEEDED and we can postulate a "TSP-
   lite".

   When an ISATAP host resolves the Potential Router List [ISATAP,
   5.2.1], it MAY (as an option) issue a "TSP-lite" connection request
   to router(s) in the PRL. The ISATAP router(s) and the hosts will
   negotiate as to whether SECURE or TRUSTING modes will be
   used. If TRUSTING mode is used, the router will send an RFC 2461-com-
   patible router advertisment (in the form specified by [ISATAP]; per-
   haps within the context of the connection, perhaps seperately) and
   the router and host will also exchange MTU/MRU information for their
   respective network interfaces. If SECURE mode is used,
   the router and host will (optionally) arrange a security association
   and each end will place the other's IPv4 address in an interface
   access list for the interface on which the connection arrived.
   (Other methods may be better, your mileage may vary.) It will then
   return the router advertisement and both sides will exchange MRU/MTU
   information as above.  Thus, both stateful and stateless methods for
   affiliating with an ISATAP router are supported, with security
   configured only if needed.

   When an ISATAP host connects to another ISATAP host on the same link,
   it MAY somehow transparently be directed to engage in a TSP session
   before both sides can communicate. Again, "TSP-Lite" is used, and NO
   configured tunnel hard state is set in the kernel. As with the router
   example above, interface MTU/MRU information is exchanged but no
   router advertisements are sent. Also as for the router case, TRUSTING
   and SECURE modes are supported.

Templin                      Expires Someday                    [Page 2]

XXX Draft             ISATAP Interactions with TSP                 Today

   The above processes MAY require periodic repetition to refresh the
   MTU/MRU exchanges.  In the case of the host contacting the router,
   a nice side effect is realized in that new router advertisments may
   be issued; thus eliminating the need for the vanilla ISATAP router
   polling method in [ISATAP,5.2.4].  Other than that, the other
   autoconfiguration aspects of TSP MAY be used, but DHCP is probably
   just as good if not better. Finally, if a site is being administered
   responsibly, the SECURE more of "TSP-Lite" is not needed. If a site's
   infrastructure consists of homogeneous network interfaces, the
   negotiation of MTU/MRU info is not needed. If both cases are true,
   then the vanilla features of [ISATAP] may be used.

4. IANA Considerations

   The TUNNELTYPE "isatap" is registered for this document.

5. Security Considerations

   Secure when you want it; not when you don't

Acknowledgments

   If anyone wants to be named, let me know

Normative References
   [TSP]      Blanchet, M. "Tunnel Setup Protocol", July 2002,
              (work in progress).

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

Author's  Address:

   Fred L. Templin
   Nokia
   313 Fairchild Drive
   Mountain View, CA 94043 USA
   Phone: (650)-625-2331
   Email: [email-masked]

---

From: Alain Durand <[email-masked]>
Date: Fri, 06 Sep 2002 12:49:39 -0700

> (Pls distribute further if I've missed anyone on the "To:" or "Cc:".)

Fred,

The correct way to publish a draft is through the ID editor.
See http://www.ietf.org/ietf/1id-guidelines.txt.

	- Alain.

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Sep 2002 21:26:58 -0700

> (Pls distribute further if I've missed anyone on the "To:" or "Cc:".)

you missed internet-drafts@ietf,org

randy