rfc2583.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   TCP is a connection orientated protocol that provides per-process
   state information using a TCP Protocol Control Block (PCB).  This PCB
   can be used to save the shortcut/routed path state information. Using
   a quad-state flag that shows the USE_SHORT_CUT, TRY_SHORT_CUT,
   USE_ROUTED_PATH, or TRY_ROUTED_PATH states would allow each process
   to use the service it chooses.  The advantage of this approach is
   that it allows per flow control over the use of the shortcut or
   routed path.  The disadvantage is that this PCB is only created for
   TCP connections.  UDP connections will only use the system default
   action.

   A second option is to store this information in the socket PCB and
   use the socket function (setsockopt) to save this information.  This
   option will allow both TCP and UDP applications to set a per flow
   action to override the system default operation.  To enable this
   option, the IP kernel code will need to be modified to allow this
   quad-state flag to be set.  In addition this flag will need to be
   checked when each packet is sent to determine the if the shortcut or
   routed path is being used.







Carlson & Winkler            Informational                      [Page 5]

RFC 2583             Guidelines for NHC Developers              May 1999


5.2 Using UDP

   UDP is a connectionless orientated protocol that doesn't provide any
   support for state information.  It relies on the application to
   provide the necessary state information.  In this case where should
   the state be stored?  The user application could store this itself
   and pass this down to the kernel in some manner.  Another option is
   to store this information in an ATM MIB structure.  A third option is
   to allow a socket option (setsockopt) that the user application can
   set to override the default behavior.

5.3 Using ICMP

   In keeping with the tradition of using ICMP echo packets for Internet
   management functions (e.g. ping, traceroute) then it will be
   necessary to allow these applications to run over the shortcut and
   routed paths.  The user will need to be able to specify which path to
   use and a default action needs to be defined too.

6. Conclusions

   NHRP provides new services and functionality for IP nodes using ATM
   networks.  To use these services the client must store state
   information that describes whether a destination node is reachable
   via a shortcut or a routed path.

   The state information should be stored on a global per-application
   basis with per-process override functionality.  This allows short
   lived functions (e.g. DNS requests) and long lived requests (e.g. ftp
   sessions) to use different paths.  Storing state only based on the
   destination address means that all processes must use the same path
   and this creates unreasonable demands on the network.  To accomplish
   this the /etc/services file should be modified to carry a new flag to
   indicate the per-application default (shortcut vs. routed path)
   behavior.

   This state information is required to avoid having the client make a
   call to the NHS for every packet it sends along the routed path.  It
   is recommended that the IP routing table be modified to support a new
   flag.  This flag will indicate whether the NHS returned an ACK or NAK
   to the NHRP request.

   In addition, application programmers and system administrators
   require the ability to explicitly request a specific service (e.g.
   use the routed path or shortcut path).  This includes the ability to
   verify network operation by specifying how ICMP echo requests (e.g.
   ping, traceroute) are handled.  The NHC must support the manual
   setting of this state information.  A new socket option that allows



Carlson & Winkler            Informational                      [Page 6]

RFC 2583             Guidelines for NHC Developers              May 1999


   the user to specify the operation needs to be supported.

   To support this capability a new socket option will be created to
   allow the user application to control the operation of a particular
   connection (flow).  This option will allow the user to specify that a
   connection use one of the following:

   *      USE_SYSTEM_DEFAULT.  Use the shortcut or routed path based on
          the system configuration information for this application.
          (This is the default behavior.)
   *      USE_SHORT_CUT.  If a shortcut path exists, then use it to
          deliver the data.  If it doesn't exist, then try and create
          it.  If the shortcut cannot be created, fail the connection
          and notify the user.
   *      TRY_SHORT_CUT.  If a shortcut path exists, then use it to
          deliver the data.  If it doesn't exist, then try and create
          it.  If the shortcut cannot be created, try using the routed
          path.
   *      USE_ROUTED_PATH.  Use the routed path regardless of whether a
          shortcut exists or not.
   *      TRY_ROUTED_PATH.  If a shortcut doesn't exist, don't try and
          create it, use the routed path instead.

7. Security

   The security issues for NHRP are addressed in other NHRP documents
   [2,3].  Some specific security issues for the NHC developer are
   discussed below.

   *      Address spoofing at the IP or ATM layer may allow an attacker
          to hi-jack an IP connection or service. This threat may be
          reduced by limiting the scope of the ATM routing domain.  In
          this way only trusted IP hosts will be able to reach and use
          the services of the NHS.
   *      Denial of service attacks may be launched at both the IP and
          ATM layers of the NHS.  At the ATM layer, the attacker may
          repeatedly generate signaling messages that consuming system
          resources thus preventing NHCs from using the NHS services.
          At the IP layer, the attacker may register false IP to ATM
          mappings thus preventing a NHC from registering the correct IP
          to ATM mapping.
   *      When a NHC creates or accepts a short-cut path it bypasses the
          site border router.  Therefore, any security features in the
          border router are also bypassed.  This threat may be reduced
          by limiting the scope of the ATM routing domain, increasing






Carlson & Winkler            Informational                      [Page 7]

RFC 2583             Guidelines for NHC Developers              May 1999


          security features in the NHC host, allowing the NHS to
          evaluate security features when short-cut paths are requested
          or a compination of all of these methods.

8. Authors' Addresses

   Richard Carlson
   Argonne National Laboratory

   EMail: [e-mail]


   Linda Winkler
   Argonne National Laboratory

   EMail: [e-mail]

9. References:

   [1] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM", RFC
       2225, April 1998.

   [2] Luciani, J., Katz, D., Piscitello, D., Cole B. and N. Doraswamy,
       "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.

   [3] Cansever, D., "NHRP Protocol Applicability Statement", RFC 2333,
       April 1998.

   [4] Luciani, J., "Classical IP to NHRP Transition", RFC 2336, July
       1998.

   [5] Rekhter, Y. and D. Kandlur, "Local/Remote Forwarding Decision in
       Switched Data link Subnetworks", RFC 1937, May 1996.


















Carlson & Winkler            Informational                      [Page 8]

RFC 2583             Guidelines for NHC Developers              May 1999


10.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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 assigns.

   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.

Acknowledgement

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



















Carlson & Winkler            Informational                      [Page 9]