diff options
Diffstat (limited to 'doc/rfc/rfc2107.txt')
| -rw-r--r-- | doc/rfc/rfc2107.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc2107.txt b/doc/rfc/rfc2107.txt new file mode 100644 index 0000000..13f6da8 --- /dev/null +++ b/doc/rfc/rfc2107.txt @@ -0,0 +1,1179 @@ + + + + + + +Network Working Group K. Hamzeh +Request for Comments: 2107 Ascend Communications +Category: Informational February 1997 + + + Ascend Tunnel Management Protocol - ATMP + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +IESG Note: + + This note documents a private protocol for tunnel management. This + protocol is NOT the product of an IETF working group nor is it a + standards track document. There is ongoing effort in an IETF working + group which could result in a standards track document which + specifies a protocol which provides similar functionality. + +Abstract + + This document specifies a generic tunnel management protocol that + allows remote dial-in users to access their home network as if they + were directly attached to the home network. The user's client + software uses an address contained in the home network address space + for the remote access. Packets to and from the home network are + tunneled by the Network Access Server (NAS) to which the user + connects and a Home Agent (HA) on the user's home network. This + allows for the support of access to Virtual Private Networks and also + allows for the use of protocols other than IP to be carried over the + tunnel. An example of how the RADIUS (Remote Authentication Dial In + User Service) can be used to provide the necessary configuration + information to support this service is also provided. + +1. Introduction + + The Ascend Tunnel Management Protocol (ATMP) is a protocol currently + being used in Ascend Communication products to allow dial-in client + software to obtain virtual presence on a user's home network from + remote locations. A user calls into a remote NAS but, instead of + using an address belonging to a network directly supported by the + NAS, the client software uses an address belonging to the user's + "Home Network". This address can be either provided by the client + software or assigned from a pool of addresses from the Home Network + address space. In either case, this address belongs to the Home + Network and therefore special routing considerations are required in + + + +Hamzeh Informational [Page 1] + +RFC 2107 ATMP February 1997 + + + order to route packets to and from these clients. A tunnel between + the NAS and a special "Home Agent" (HA) located on the Home Network + is used to carry data to and from the client. + + ATMP currently allows for both IP and IPX protocols to be tunneled + between the NAS and the HA. The protocol to be used, the HA to use, + and other user specific information is provided by some configuration + mechanism that is beyond the scope of this document. Appendix A + illustrates how RADIUS [5] is used to convey this information to the + NAS. + + The determination of the Home Network address to be used can be + accomplished in different ways. It could, for example, be configured + in the client and negotiated by IPCP (or IPXCP). Alternatively, it + could be defined to be an address specific to the given user ID, or + it could be assigned from a pool of addresses provided by the Home + Network for the purpose of remote dial-in access. Again, how this + address is assigned and how the NAS decides to invoke ATMP for a + specific call is beyond the scope of this document. + +1.1 Protocol Goals and Assumptions + + The ATMP protocol is implemented only by the NAS and HA. No other + systems need to be aware of ATMP. All other systems communicate in + the normal manner and are unaware that they may be communicating with + remote clients. The clients themselves are unaware of ATMP. It is + assumed that standard PPP [8] (or SLIP) clients are being used. + + Unlike the mobile-IP protocol [3], ATMP assumes that a single NAS + will provide the physical connection to a remote client for the + duration of the session. The client will not switch between NASes + expecting to keep the same IP address and all associated sessions + active during these transitions. A particular client can be + registered with a given HA only once at any given time. + Deregistration with a HA implies loss of all higher layer sessions + for that client. + + IP multicasting is currently not provided by ATMP. + +1.2 Terminology + + The terminology used in this document is similar to that used in + mobile-IP. As pointed out in the previous section, however, ATMP + provides a subset of the functionality provided by mobile-IP and the + meanings of the various terms used herein have been modified + accordingly. + + + + + +Hamzeh Informational [Page 2] + +RFC 2107 ATMP February 1997 + + + Connection Profile + + A table used to route packets other than by destination + address. The Connection Profile is a named entity that + contains information indicating how packets addressed to it are + to be routed. It may be used to route packets to unregistered + IP addresses and for routing protocols other than IP (e.g., + IPX). + + Foreign Agent (FA) + + A routing entity that resides in a NAS on a remote network that + allows a mobile node to utilize a home network address. It + tunnels datagrams to, and detunnels datagrams from, the home + agent for the given home network. + + Home Address + + An address that is assigned for an extended period of time to a + mobile node. It may remain unchanged regardless of where the + MN is attached to the Internet. Alternatively, it could be + assigned from a pool of addresses. The management of this pool + is beyond the scope of this document. + + Home Agent (HA) + + A router on a mobile node's home network which tunnels + datagrams for delivery to, and detunnels datagrams from, a + mobile node when it is away from home. + + Home Network + + The address space of the network to which a user logically + belongs. When a workstation is physically connected to a LAN, + the LAN address space is the user's home network. ATMP + provides for a remote virtual connection to a LAN. + + Mobile Node (MN) + + A host that wishes to use a Home Network address while + physically connected by a point-to-point link (phone line, + ISDN, etc.) to a NAS that does not reside on the Home Network. + Also referred to as the client. + + Mobility Binding + + The association of a Home Address with a Foreign Agent IP + address and a Tunnel ID. + + + +Hamzeh Informational [Page 3] + +RFC 2107 ATMP February 1997 + + + Network Access Server (NAS) + + A device providing temporary, on-demand, network access to + users. This access is point-to-point using phone or ISDN + lines. + + Tunnel + + The path followed by a datagram when it is encapsulated. The + model is that, while it is encapsulated, a datagram is routed + to a knowledgeable decapsulation agent, which decapsulates the + datagram and then correctly delivers it to its ultimate + destination. Each mobile node connecting to a home agent does + so over a unique tunnel, identified by a tunnel identifier + which is unique to a given FA-HA pair. A tunnel can carry both + IP and IPX datagrams simultaneously. + +1.3 Protocol Overview + + A mobile node that wishes to use a home address while connected to a + remote NAS must register with the appropriate home agent. The + foreign agent entity of the remote NAS performs this registration on + behalf of the MN. Once registered, a tunnel is established between + the FA and HA to carry datagrams to and from the MN. While a MN is + registered with an HA, the HA must intercept any packets destined for + the MN's home address and forward them via the tunnel to the FA. When + the FA detects that the MN has disconnected from the NAS, it issues a + deregister request to the HA. + + Because ATMP allows protocols other than IP to be carried on its + tunnels and also allows unregistered IP address to be used to provide + for access to enterprise networks, the HA doesn't necessarily route + datagrams received from the MN in the conventional manner. The + registration request allows for a named "Connection Profile" to be + specified in the registration request. This Connection Profile + contains configuration information that tells the HA where to send + packets that it receives from the MN. + +1.4 Specification Language + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST This word, or the adjective "required", means + that the definition is an absolute requirement + of the specification. + + + + + +Hamzeh Informational [Page 4] + +RFC 2107 ATMP February 1997 + + + MUST NOT This phrase means that the definition is an + absolute prohibition of the specification. + + SHOULD This word, or the adjective "recommended", + means that, in some circumstances, valid + reasons may exist to ignore this item, but + the full implications must be understood and + carefully weighed before choosing a different + course. Unexpected results may result + otherwise. + + MAY This word, or the adjective "optional", means + that this item is one of an allowed set of + alternatives. An implementation which does + not include this option MUST be prepared to + interoperate with another implementation which + does include the option. + + silently discard The implementation discards the datagram + without further processing, and without + indicating an error to the sender. The + implementation SHOULD provide the capability of + logging the error, including the contents of + the discarded datagram, and SHOULD record the + event in a statistics counter. + +2.0 Protocol Specification + + ATMP defines a set of request and reply messages sent with UDP [4]. + The HA listens on UDP port 5150 [6]) for requests from FA's. The UDP + checksum field MUST be computed and verified. There are 7 different + ATMP message types represented by the following Type values: + + Message Type Type code + + + Registration Request 1 + + Challenge Request 2 + + Challenge Reply 3 + + Registration Reply 4 + + + + + + + + +Hamzeh Informational [Page 5] + +RFC 2107 ATMP February 1997 + + + Deregister Request 5 + + Deregister Reply 6 + + Error Notification 7 + +2.1 Registration Request + + The FA issues a Registration Request to request the HA to establish a + mobility binding for the specified MN home address. The request is + issued to the HA by the FA upon detecting a MN that wishes to use a + home address supported by the HA receiving the request. + + IP fields + + Source Address The IP address of the foreign agent + interface from which the request is + issued. + + Destination Address The IP address of the home agent. + + UDP fields: + + Source Port variable + + Destination Port 5150 (or port number configured in FA + for given HA) + + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh Informational [Page 6] + +RFC 2107 ATMP February 1997 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Foreign Agent | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mobile Node | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mobile Node Mask | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mobile Node IPX Net | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Mobile Node IPX Station . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Home Network Name . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Version The ATMP protocol version. MUST be 1. + + Type 1 for Registration Request. + + Identifier A 16 bit number used to match replies + with requests. A new value should be + provided in each new request. + Retransmissions of the same request + should use the same identifier. + + Foreign Agent The IP address of the foreign agent + issuing the request (typically the same + as the UDP source address). + + Mobile Node The IP address to be used by the mobile + node. This is the mobile node's home + address. This field can be all 0's if + IPX is to be tunneled to the mobile node. + + Mobile Node Mask The network bit mask for the mobile node. + Currently this value should be set to all + 1's. + + Mobile Node IPX Net The Network portion of the mobile node's + IPX address. This value should be set to + all 0's if only IP is to be tunneled. + + + +Hamzeh Informational [Page 7] + +RFC 2107 ATMP February 1997 + + + Mobile Node IPX Station The 6 octet value used to represent the + station portion of the mobile node's IPX + address. This value should be set to all + 0's if only IP is to be tunneled instead + of IPX. + + Reserved This field is for future extensibility + and MUST be set to all 0's. + + HN Name This is the name of the "Connection + Profile" to be used by the home agent to + forward all packets received from the + mobile node. This character string is + terminated by a NUL character and can be + up to 32 characters long, including the + NUL terminator. + +2.2 Challenge Request + + The Home Agent issues a Challenge Request in response to the receipt + of a Registration Request from a Foreign Agent. It is used by the + Home Agent, in conjunction with the Challenge Reply, to authenticate + the Foreign Agent. + + IP fields + + Source Address The IP address of the Home Agent + interface from which the request is + issued. + + Destination Address Copied form the Source Address of the + Registration Request. + + UDP fields: + + Source Port variable + + Destination Port Copied from the Source Port of the + Registration Request. + + + + + + + + + + + + +Hamzeh Informational [Page 8] + +RFC 2107 ATMP February 1997 + + +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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Version The ATMP protocol version. MUST be 1. + + Type 2 for Challenge Request + + Identifier A 16 bit number used to match replies + with requests. A new value should be + provided in each new request. + Retransmissions of the same request + should use the same identifier. + + Authenticator A series of 16 octet values randomly + generated by the Home Agent. The + receiving Foreign Agent is to perform an + MD5 [7] hash of these values along with a + shared secret. The resultant digest is + returned in the Challenge Reply. See + Sec. 2.3 Retransmissions of the Challenge + Request should use the same Authenticator + value. + + A value of all 0's in this field + indicates an error occurred with the + Registration Request. The error code + will be in the following field. + + + + + + + + + + + +Hamzeh Informational [Page 9] + +RFC 2107 ATMP February 1997 + + + Result Code If non-zero, this value indicates the + error condition that occurred. See Sec. + 2.8 for a list of Result Code values and + their meanings. + + A non-zero value in this field implies + that the Authenticator field will be + zero. + +2.3 Challenge Reply + + The Foreign Agent issues a Challenge Reply upon receipt of a valid + Challenge Request (one with a Result Code of 0) from the Home Agent. + The Foreign Agent uses the randomly generated Authenticator value + from the Challenge Request along with a shared secret to produce an + MD5 digest value which is returned to the Home Agent in the Challenge + Reply. + + IP fields + + Source Address The IP address of the Foreign Agent + interface from which the reply is issued. + + Destination Address Copied from the Source Address of the + Challenge Request. + + UDP fields: + + Source Port variable + + Destination Port Copied from the Source Port of the + Challenge 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reply Length | Reply . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + +Hamzeh Informational [Page 10] + +RFC 2107 ATMP February 1997 + + + Version The ATMP protocol version. MUST be 1. + + Type 3 for Challenge Reply + + Identifier Copied from the corresponding + Deregistration Request. + + Reply Length This field specifies the length of the + challenge reply computation based on the + received Authenticator and the shared + secret. For MD5 this length will always + be 16. This field is provided for future + extensibility. + + Reply This is the computed challenge reply. It + is computed by performing an MD5 message + digest computation over the Authenticator + value received in the Challenge Request + appended with the secret shared between + the Foreign Agent and the Home Agent. + The digests produced by MD5 are always 16 + octets long. + +2.4 Registration Reply + + A Registration Reply is issued by a Home Agent in reply to a + Challenge Reply received from a Foreign Agent. The Registration + Reply indicates to the Foreign Agent whether the registration was + accepted by the Home Agent or not. It also provides a "tunnel ID" to + uniquely identify the tunnel to be associated with this session. + + The Home Agent calculates the same MD5 hash on the Challenge Request + Authenticator field and the shared secret. The resulting digest is + compared with the Reply value in the Challenge Reply and if it is + equal, authentication is successful. Otherwise the registration is + not accepted and the Foreign Agent is informed by the Result Code of + the Registration Reply that registration failed due to an + authentication failure. + + IP fields + + Source Address The IP address of the Home Agent + interface from which the reply is issued. + + Destination Address Copied from the Source Address of the + Challenge Reply. + + + + + +Hamzeh Informational [Page 11] + +RFC 2107 ATMP February 1997 + + + UDP fields: + + Source Port variable + + Destination Port Copied from the Source Port of the + Challenge Reply. + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Version The ATMP protocol version. MUST be 1. + + Type 4 for Registration Reply + + Identifier Copied from the corresponding + Registration Request. + + 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 This is the identifier used to indicate a + given mobility binding between a given + Mobile Node and Home Agent. This + identifier is used to distinguish + multiple tunnels between a given Foreign + Agent-Home Agent pair. It is carried in + the "key" field of the GRE [1] tunnel + packets that ATMP uses as the tunnel + protocol. It is also used in + Deregistration Requests and Error + Notification messages to indicate the + particular mobility binding to which they + relate. + + + + + + + +Hamzeh Informational [Page 12] + +RFC 2107 ATMP February 1997 + + +2.5 Deregistration Request + + The Deregistration Request is issued by the Foreign Agent to the Home + Agent to indicate that the specified mobility binding is to be ended. + This request may result from the Foreign Agent detecting that its + connection to the Mobile Node has terminated. It can also be issued + in response to a detected error condition by the Foreign Agent or + receipt of an Error Notification message from the Home Agent. + + IP fields + + Source Address The IP address of the Foreign Agent + interface from which the request is + issued. + + Destination Address 5150 (or port number configured in FA + for given HA) + + UDP fields: + + Source Port variable + + Destination Port Copied from the Source Port of the + Challenge Reply. + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tunnel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Version The ATMP protocol version. MUST be 1. + + Type 5 for Deregistration Request + + Identifier A 16 bit number used to match replies + with requests. A new value should be + provided in each new request. + Retransmissions of the same request + should use the same identifier. + + + + + +Hamzeh Informational [Page 13] + +RFC 2107 ATMP February 1997 + + + Tunnel ID Tunnel identifier of the mobility binding + to be terminated. + +2.6 Deregistration Reply + + The Deregistration Reply is issued by the Home Agent in response to a + Deregistration Request received from a Foreign Agent. If the + Deregistration Request was valid, the Home Agent removes the + specified mobility binding from its tables and issues an affirmative + reply. Otherwise the Home Agent issues a Deregistration Reply with a + Result Code indicating the reason for failure of the Deregistration + Request. + + IP fields + + Source Address The IP address of the Home Agent + interface from which the reply is issued. + + Destination Address Copied from the Source Address of the + received Deregistration Request. + + UDP fields: + + Source Port variable + + Destination Port Copied from the Source Port of the + received Deregistration 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Version The ATMP protocol version. MUST be 1. + + Type 6 for Deregistration Reply + + Identifier Copied from the corresponding + Deregistration Request. + + + + + + +Hamzeh Informational [Page 14] + +RFC 2107 ATMP February 1997 + + + 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: kory@ascend.com + +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] + |