Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_i/draft-ietf-ion-transition-00.txt

Text File | 1996-11-04 | 10KB | 279 lines

Internetworking Over NBMA Working Group                 James V. Luciani
INTERNET-DRAFT                                            (Bay Networks)
<draft-ietf-ion-transition-00.txt>                    Expires March 1997






                    Classical IP to NHRP Transition


Status of this Memo

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

Abstract

   This document describes methods and procedures for the graceful
   transition from an ATMARP LIS[1] to an NHRP LIS[2] network model over
   ATM.

1. Introduction

   ATMARP defines an initial application of classical IP and ARP in an
   ATM network environment configured as a LIS[1].  ATMARP only
   considers application of ATM as a direct replacement for the "wires"
   and local LAN segments connecting IP end-stations and routers
   operating in the "classical" LAN-based paradigm.

   The NBMA Next Hop Resolution Protocol (NHRP) allows a source station
   (a host or router), wishing to communicate over a Non-Broadcast,
   Multi-Access (NBMA) subnetwork, to determine the internetworking
   layer addresses and NBMA addresses of suitable "NBMA next hops"



Luciani                                                         [Page 1]

INTERNET-DRAFT                 NBMA NHRP              Expires April 1997


   toward a destination station. If the destination is connected to the
   NBMA subnetwork and direct communication is administratively allowed,
   then the NBMA next hop is the destination station itself.  Otherwise,
   the NBMA next hop is the egress router from the NBMA subnetwork that
   is "nearest" to the destination station.  For the purposes of this
   document, the NBMA network is of type ATM.

   It is reasonable to expect that ATMARP Clients and NHRP Clients will
   initially coexist within a LIS.  Thus, it is necessary to define a
   graceful transition, including a period of coexistance, from the use
   of ATMARP to the use of NHRP for address resolution in the LIS
   [1][2]. In short, NHSs will be required to respond to ATMARP Client
   queries in a fashion which will permit continued use of the ATMARP
   Client within the LIS during the ATMARP to NHRP transition period.
   Note that this document places no protocol requirements upon
   ATMARP[1] servers.

   For the following, it will be assumed that the reader is familiar
   with the terminology as described in [1][2][3].

2. Service Requirements

   If NHRP is to be used in a LIS then only NHSs will be used in the
   LIS; that is, there will not be a mixture of NHSs and ATMARP servers
   within the same LIS.  Since ATMARP servers will not be able to
   understand NHCs and since since, as described below, NHSs will
   respond to ATMARP Clients, this is a reasonable simplifying
   restriction.

   This document will only address SVC based environments and will not
   address PVC environments.  This document will refer only to ATM AAL5
   as the NBMA and IP as the protocol layer since ATMARP only addresses
   these protocols.

2.1 NHRP Server Requirements

   If NHRP Servers (NHS) are to be deployed in a LIS which contains both
   ATMARP Clients and NHRP Clients then NHSs MUST respond to
   ATMARP_Requests sent by ATMARP Clients in the same fashion that an
   ATMARP Server would respond as described in [1].  To do this, the NHS
   MUST first recognize the LLC/SNAP ATMARP code point with LLC=0xAA-
   AA-03, OUI=0x00-00-00, and ethertype=0x08-06.  Further, the NHS MUST
   recognize the packet formats described in Section 8.7 of [1].
   However, since this document does not extend to PVC environments,
   NHSs MUST only receive/respond to values of ar$op of 1,2,10
   (Decimal).  If an NHS receives an ATMARP message with ar$op values
   other than those previously noted then the NHS MUST discard the
   packet and MUST NOT take any further action.



Luciani                                                         [Page 2]

INTERNET-DRAFT                 NBMA NHRP              Expires April 1997


   When an NHS receives a valid (as defined in the previous paragraph)
   ATMARP_Request packet, the NHS MUST follow the rules described in
   Section 8.4 of [1] with the following additional processing:

     1) When an ATMARP_Request causes a new table entry in the NHS for an ATMARP Client,
        that table entry MUST be marked as being of type "ATMARP" so that it can be
        differentiated from an NHRP sourced entry.

     2) An ATMARP_Request MUST NOT cause an ATMARP_Reply to be sent if that ATMARP_Request
        contains an off-LIS protocol address.  This should never happen because the IP stack
        on the requesting machine should automatically send the packet to the default
        router.  If this does occur then the ATMARP_Request MUST cause an ATMARP_NAK to
        be sent to the originator.

   In [1], an ATMARP_Request packet also serves as a
   registraion/registration-update packet which would cause a server to
   add an entry to a server's cache or to update a previously existing
   entry.  When an NHS receives an ATMARP_Request which causes the
   creation of a new cache entry in the NHS or updates an existing entry
   then that cache entry will have a holding time of 20 minutes (this is
   the default value in [1]).

   An NHS receiving an NHRP Resolution Request MUST NOT send a positive
   NHRP Resolution Reply for a station which registered via ATMARP if
   the station sending the NHRP Resolution Request is outside the LIS of
   the station which registered itself via ATMARP.  This is because the
   station which registered via ATMARP is almost certainly not prepared
   to accept a cut-through.   When this occurs, the replying NHS must
   send NHRP Resolution Reply which contains a CIE code of "12 - No
   Internetworking Layer Address to NBMA Address Binding Exists" as
   described in [2].  This type of reply does not preclude the station
   sending the NHRP Resolution Request from sending its data packets
   along the routed path but it does preclude that station from setting
   up a cut-through VC.



2.2 Multi-server environments

   Since NHRP works in a multi-server environment on a per LIS basis, it
   is useful to make a few comments about the cache synchronization
   necessary in a hybrid ATMARP/NHRP LIS.  ATMARP and NHRP have
   different cache overwrite rules.  An NHC is permitted to register its
   addresses with multiple NHSs while ATMARP Clients are not.  The cache
   over-write rules are described in [1][2].

   A simple rule of thumb for the synchronization of ATMARP initiated
   entries in an NHS is as follows:



Luciani                                                         [Page 3]

INTERNET-DRAFT                 NBMA NHRP              Expires April 1997


     if it were the case that the LIS contained only a single NHRP
     server acting as an ATMARP server and, as a result of an
     ATMARP_Request, a cache update would occur in that single server
     then in a multi-server environment the resultant cache update MUST
     be propagated to all NHSs in the LIS.

   Further information on cache over-write strategies for ATMARP and
   NHRP servers can be found in [3].

3. Security Considerations

   Not all of the security issues relating to IP over ATM are clearly
   understood at this time, due to the fluid state of ATM
   specifications, newness of the technology, and other factors.

   It is believed that ATM and IP facilities for authenticated call
   management, authenticated end-to-end communications, and data
   encryption will be needed in globally connected ATM networks.  Such
   future security facilities and their use by IP networks are beyond
   the scope of this memo.

   There are known security issues relating to host impersonation via
   the address resolution protocols used in the Internet [4].  No
   special security mechanisms have been added to ATMARP.  While NHRP
   supplies some mechanisms for authentication, ATMARP does not.  Since
   any security mechanism is only as good as its weakest link, it should
   be assumed that when NHRP and ATMARP exist with a given LIS, the
   security of a combination is only as good as that supplied by ATMARP.

References

   [1] Classical IP and ARP over ATM, Laubach, Halpern,
       draft-ietf-ion-classic2-00.txt

   [2] NBMA Next Hop Resolution Protocol (NHRP), Luciani, Katz, Piscitello,
       Cole, draft-ietf-rolc-nhrp-10.txt.

   [3] Server Cache Synchronization Protocol (SCSP) - NBMA,
       J. Luciani, G. Armitage, J. Halpern, Work In Progress.

   [4] Security Problems in the TCP/IP Protocol Suite, Bellovin,
       ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48,
       1989.








Luciani                                                         [Page 4]

INTERNET-DRAFT                 NBMA NHRP              Expires April 1997


Acknowledgments

   Thanks to Andy Malis for his input on this draft.

Author's Addresses


   James V. Luciani
   Bay Networks
   3 Federal Street
   Mail Stop: BL3-04
   Billerica, MA 01821
   Phone:  [phone]
   Email:  [e-mail]





































Luciani                                                         [Page 5]