分享
 
 
 

RFC2107 - Ascend Tunnel Management Protocol - ATMP

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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

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.

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.

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.

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

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)

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.

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.

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.

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 . . .

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.

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.

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.

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.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.

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.

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.

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)", RFC1701, October 1994.

[2] Lloyd, B., and W. Simpson, "PPP Authentication Protocols",

RFC1334, October 1992.

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

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

[5] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote

Authentication Dial In User Service (RADIUS)", RFC2058,

January 1997.

[6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,

RFC1700, October, 1994.

[7] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321, April

1992.

[8] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD

51, RFC1661, July 1994.

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.

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.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有