rfc2107.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,180 行 · 第 1/3 页

      Result Code              Specifies the result of the registration
                               and authentication attempt by the Foreign
                               Agent.  Sec. 2.8 for a list of Result
                               Code values and their meanings.

      Tunnel ID                Tunnel identifier of the mobility binding
                               specified in the Deregistration Request.

2.7 Error Notification

   This message is sent by either agent to inform the other agent that
   an error condition has occurred.  It provides a last-ditch error
   recovery mechanism that is used for conditions that cannot be
   reported back to the sender by the normal request-reply mechanism,
   such as the receipt of a spontaneously generated reply.

   IP fields

      Source Address           The IP address of the issuing agent
                               interface from which this message is
                               issued.

      Destination Address      The IP address of the Home Agent or
                               Foreign Agent to which this message is to
                               be issued.

   UDP fields:

      Source Port              variable

      Destination Port         If issued to a Home Agent, 5150 (or the
                               port number configured for the given HA).
                               If issued to a Foreign Agent, the source
                               port number saved from the original
                               Registration Request.


   The UDP header is followed by the ATMP fields shown below:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |    Type       |         Identifier            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Result Code          |         Tunnel ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Hamzeh                       Informational                     [Page 15]

RFC 2107                          ATMP                     February 1997


      Version                  The ATMP protocol version.  MUST be 1.

      Type                     7 for Error Notification

      Identifier               If issued in response to a received reply
                               type message, this value should be copied
                               from the identifier field of the reply.
                               Otherwise the identifier should be the
                               value that would be used for the next
                               generated request.

      Result Code              This indicates the type of error
                               detected.  The possible result codes are
                               defined in Sec. 2.8.

      Tunnel ID                Tunnel identifier of the mobility binding
                               to which this message pertains.  If the
                               Error Notification is being sent in
                               response to an unsolicited reply, the
                               Tunnel ID is copied from the reply.

2.8 Result Codes

   Error Code          Description

   0 NO_ERROR          Successful operation

   1 AUTH_FAILED       Authentication of the Foreign Agent failed.
                       Registration denied.

   2 NOT_ENABLED       The Home Agent is not configured to run ATMP.

   3 TOO_MANY          Too many Mobile Node sessions.  Home Agent is out
                       of resources.

   4 PARAMETER_ERROR   An invalid value was detected in an ATMP message.

   5 INVALID_TUNNEL_ID The Tunnel ID contained in a GRE packet is
                       invalid or the corresponding mobility binding
                       does not exist.  This usually occurs when either
                       the MN or HA has reset.

   6 TIMEOUT           A response to an ATMP request was not received in
                       time.







Hamzeh                       Informational                     [Page 16]

RFC 2107                          ATMP                     February 1997


   7 NET_UNREACHABLE   The Home Network for this mobility binding is not
                       operational (the "Connection Profile" is "down"
                       or is not defined).

   8 GENERAL_ERROR     General Error indication.

2.9 Protocol Operation

   Upon detection of a Mobile Node requiring ATMP service, the NAS
   invokes its ATMP Foreign Agent entity.The FA retrieves configuration
   information for the user involved.This information is obtained in a
   method particular to the NAS and is not specified by this document.
   The information obtained MUST include the Home Agent address and the
   shared secret for this HA.It also MAY include the Home Network Name,
   if a Connection Profile is to be used for this session.

   The FA then sends a Registration Request to the HA informing it that
   an MN wishes to register with it.  The FA then waits for the HA to
   respond with a Challenge Request.  The FA retransmits the
   Registration Request every 2 seconds until it receives the Challenge
   Request.  If, after 10 retransmissions, no Challenge Request is
   received, the FA will terminate the Registration Request, logs the
   registration failure, and disconnects the MN.

   Upon receipt of the Challenge Request, the FA examines the Result
   code.  If it indicates an error condition, the condition is logged
   and the MN is disconnected.  If the result is zero, the FA generates
   a Challenge Reply.  The Challenge Reply is generated by appending the
   Authenticator obtained from the Challenge Request with the shared
   secret (obtained from the configuration data) and then computing the
   MD5 hash of this concatenated string (authenticator + secret).  The
   16 octet hash is then returned in the Challenge Reply for validation
   by the HA.

   Upon receipt of the Challenge Reply from the FA, the HA does the same
   computation of the MD5 hash based on the Challenge Request
   Authenticator and the shared-secret (which it too must be configured
   with).  If this digest matches that provided in the Challenge Reply
   by the FA then the authentication is successful and the registration
   is accepted.  If the authentication fails, or resource limitations
   prohibit the registration attempt, the HA returns a Registration
   Reply with a non-zero result code to the FA.

   If the HA accepts the Challenge Reply from the FA, it assigns a
   Tunnel ID to this session and returns this Tunnel ID in a
   Registration Reply with a zero result code.  This Tunnel ID needs to
   be unique for the FA-HA pair.  The Tunnel ID is used to multiplex and
   demultiplex the packets sent between a given FA-HA pair.



Hamzeh                       Informational                     [Page 17]

RFC 2107                          ATMP                     February 1997


   At the time the HA decides to accept a registration, it creates a
   control block that associates the Tunnel ID with the appropriate
   routing information.  If the Registration Request included a Home
   Network Name, this name is saved in the table and used as the name of
   the Connection Profile for this session.

   Upon receipt of the Registration Reply, the FA examines the result
   code. If it is non-zero, the FA logs the registration failure and
   disconnects the MN.  If it is zero, the FA saves the Tunnel ID in a
   control block associated with the MN session.  The FA and HA are now
   ready to exchange data packets for this MN session.

   On the FA side, all data received from the MN will be encapsulated
   using GRE and sent to the HA with the assigned Tunnel ID included in
   the GRE Key field.  When the HA receives a GRE packet it decapsulates
   it and routes it using the routing information contained in the HA's
   control block associated with this Tunnel ID.

   When the HA receives a packet destined for the MN's Home Address, it
   MUST encapsulate it in a GRE packet and forward it to the appropriate
   FA.  The Tunnel ID is included in the GRE Key field to allow the FA
   to demultiplex the packet.

   When the FA receives a GRE packet, it will examine the Tunnel ID in
   the GRE Key field to see if it matches the Tunnel ID assigned to any
   of the MN's currently connected to the FA.  If so, the packet is
   decapsulated and forwarded to the MN.  If the Tunnel ID doesn't match
   any active MN's, an Error Notification message is issued to the HA
   and the GRE packet is silently discarded.

   When the FA wishes to disconnect the MN from the HA, it issues a
   Deregistration Request.  This request is issued every 2 seconds.  If
   after 10 attempts a Deregistration Reply is not received from the HA,
   an error condition is logged and the MN is disconnected.  Upon
   receipt of a Deregistration Reply from the HA, the FA deallocates the
   Tunnel ID and disconnects the MN.

3.0 Security Considerations

   The Registration function of ATMP is protected by a
   Challenge/Response mechanism similar to CHAP [2]. The Home Agent
   challenges each registration attempt by a Foreign Agent for
   authentication.This authentication requires the configuration of a
   shared secret for each HA/client pair.







Hamzeh                       Informational                     [Page 18]

RFC 2107                          ATMP                     February 1997


4.0 Author's Address

   Kory Hamzeh
   Ascend Communications
   1275 Harbor Bay Parkway
   Alameda, CA 94502

   EMail: [e-mail]

5.0 References

   [1]  Hanks, S. Li, T., Farinacci, D., and Traina, P., "Generic
        Routing Encapsulation (GRE)", RFC 1701, October 1994.

   [2]  Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
        RFC 1334, October 1992.

   [3]  Perkins, C., "IP Mobility Support", RFC 2002, October 1996.

   [4]  Postel, J., "User Data Protocol",  STD 6, RFC 768, August 1990.

   [5]  Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote
        Authentication Dial In User Service (RADIUS)", RFC 2058,
        January 1997.

   [6]  Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
        RFC 1700, October, 1994.

   [7]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
        1992.

   [8]  Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
        51, RFC 1661, July 1994.


















Hamzeh                       Informational                     [Page 19]

RFC 2107                          ATMP                     February 1997


Appendix A

   Additional RADIUS Attributes for ATMP

   This appendix indicates the RADIUS attributes that have been added by
   Ascend to support ATMP for IP.  Currently these are defined as non-
   vendor-specific attributes but have been included in [5].

       Attribute: "Ascend-Home-Agent-IP-Addr"
       Type:      IP-Address
       Value:     The IP address of the Home Agent

       Attribute: "Ascend-Home-Agent-Password"
       Type:      String
       Value:     Secret shared for this user with HA

       Attribute: "Ascend-Home-Network-Name"
       Type:      String
       Value:     Name of Connection Profile for this session

       Attribute: "Ascend-Home-Agent-UDP-Port"
       Type:      Integer
       Value:     The destination UDP port number for the specified HA

Appendix B

      IPX Operation

      ATMP specifies a mechanism which allows IPX clients to receive
      mobility services from a HA. Section 2 details the protocol used
      to register, deregister, and authenticate a tunnel used for IPX.
      Note that ATMP is based on IP datagrams for the management of
      tunnels and, thus, IPX tunneling with ATMP always requires an
      underlying IP network.

      Each IPX mobile client requires an IPX network number and node
      address pair.  Since IPX does not support a similar facility to
      IP's "host route," an enterprise-unique network number needs to be
      chosen for each home agent. This network number MUST be distinct
      from the IPX network number assigned to any of the home agent's
      LAN interfaces. Each mobile client tunneled to the home agent MUST
      use the same IPX network number.

      For example, consider a home agent which supports two mobile
      clients.  The home agent is on a LAN network with an IPX address
      of AA000001. The home agent's client network may be assigned
      AA000002. The two mobile clients may have addresses
      AA000002:0040F1000001 and AA000002:0040F1000002 respectively.



Hamzeh                       Informational                     [Page 20]

RFC 2107                          ATMP                     February 1997


      IPX node numbers need to be unique on a given network. A mechanism
      must exist to guarantee that for each home agent's network, a
      given mobile client's node address is unique. Several techniques
      may be employed to assure unique node addresses. The current
      implementation of ATMP described in this document relies on RADIUS
      to assign a node address at the foreign agent. The following
      RADIUS attributes are included for IPX operation in addition to
      the attributes described in Appendix A for IP operation:

       Attribute: "Framed-IPX-Network" (See [5] for details).

       Attribute: "Ascend-IPX-Node-Addr"
       Type:      String
       String:    The node address for the mobile client in 12 octet
                  ASCII representing the hexadecimal string. Both
                  lower and upper case characters are permissible.



































Hamzeh                       Informational                     [Page 21]