RFC 2107
Ascend Tunnel Management Protocol - ATMP
RFC 2107: Ascend Tunnel Management Protocol - ATMP 🎀
okay bestie, this is RFC 2107 💅 It was written by K. Hamzeh at Ascend Communications and published in the Network Working Group in February 1997. It's Category: Informational, so it's here to share info, not to be a standard. It doesn't list anything it obsoletes or updates.
Status of This Memo ✨
This memo gives info to the Internet community. It 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 🌸
ok so this doc lays out a generic tunnel management protocol that lets remote dial-in users reach their home network as if they were plugged right into it 🔥 The user's client software uses an address from the home network's address space for that remote access. Packets going to and from the home network get tunneled between the Network Access Server (NAS) the user dials into and a Home Agent (HA) on the user's home network. This makes access to Virtual Private Networks possible, and it also lets protocols other than IP ride through the tunnel. There's also an example of how RADIUS (Remote Authentication Dial In User Service) can hand over the configuration info needed to make this work 🦋
1. Introduction 🧚
the Ascend Tunnel Management Protocol (ATMP) is already being used in Ascend Communication products 💖 It lets dial-in client software get "virtual presence" on a user's home network from wherever they are. The user calls into a remote NAS, but instead of using an address that belongs to a network the NAS directly supports, the client software uses an address from the user's "Home Network." That address can be provided by the client software, or it can come from a pool of addresses in the Home Network address space. Either way, the address belongs to the Home Network, so special routing is needed to get packets to and from these clients. A tunnel between the NAS and a special "Home Agent" (HA) on the Home Network carries the data to and from the client 🎀
ATMP currently supports tunneling both IP and IPX between the NAS and the HA. Which protocol gets used, which HA gets used, and other user-specific info come from some configuration mechanism that is out of scope for this document. Appendix A shows how RADIUS [5] passes this info to the NAS 🫶
There are a few ways to figure out which Home Network address to use. For example, it could be configured in the client and negotiated through IPCP (or IPXCP). It could also be an address tied to the specific user ID, or it could come from a pool of addresses the Home Network provides for remote dial-in access. Again, how the address gets assigned, and how the NAS decides to invoke ATMP for a specific call, are both out of scope for this document 🌈
1.1 Protocol Goals and Assumptions ✨
ok the ATMP protocol is only implemented by the NAS and HA 💅 No other systems need to know about ATMP. Everything else communicates the normal way and has no idea it might be talking to remote clients. The clients themselves don't know about ATMP either. It's assumed that standard PPP [8] (or SLIP) clients are being used 🦋
Unlike the mobile-IP protocol [3], ATMP assumes that a single NAS provides the physical connection to a remote client for the whole session. The client does not switch between NASes and expect to keep the same IP address and all its sessions running during those transitions 😭 A particular client can be registered with a given HA only once at any given time. Deregistering with an HA means losing all higher layer sessions for that client 💀
IP multicasting is currently not provided by ATMP. 🙈
1.2 Terminology 🍓
the terminology here is pretty similar to mobile-IP's 💖 Like we said earlier, though, ATMP only provides a subset of what mobile-IP does, so the meanings of the terms in this document have been adjusted to match 🧚
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 🔥
so a mobile node that wants to use a home address while connected to a remote NAS has to register with the right home agent 💅 The foreign agent entity on that remote NAS does the registering for the MN. Once that's done, a tunnel gets set up between the FA and HA to carry datagrams to and from the MN. While an MN is registered with an HA, the HA must intercept any packets destined for the MN's home address and forward them through the tunnel to the FA. When the FA notices the MN has disconnected from the NAS, it sends a deregister request to the HA 😭
Because ATMP lets protocols other than IP ride its tunnels, and also lets unregistered IP addresses be used to reach enterprise networks, the HA doesn't always route datagrams from the MN the conventional way 🦋 The registration request can specify a named "Connection Profile." That Connection Profile holds the configuration info that tells the HA where to send packets it gets from the MN 👑
1.4 Specification Language 🫶
ok, this section explains the words the spec uses to signal requirements 🎀 They're often capitalized, and here's what each one means:
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 🦋
ok this is where it gets real 🔥 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 72.1 Registration Request ✨
Okay so the FA sends a Registration Request to tell the HA to set up a mobility binding for the specified MN home address 💖 The FA sends it to the HA as soon as it spots an MN that wants to use a home address the receiving HA supports 🏠
IP fields 🌐
Source Address: the IP address of the foreign agent interface the request is issued from.Destination Address: the IP address of the home agent.
UDP fields 🎀
Source Port: variableDestination Port:5150(or the port number configured in the FA for that 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. It 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 it MUST be set to all 0's. 🧚HN Name: the name of the "Connection Profile" the home agent uses 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 HA issues a Challenge Request whenever it gets a Registration Request from a FA 👑 It's used by the HA, together with the Challenge Reply, to authenticate the FA. Main character energy for sure 💜
IP fields 🌐
Source Address: the IP address of the Home Agent interface from which the request is issued.Destination Address: copied from the Source Address of the Registration Request.
UDP fields 🎀
Source Port: variableDestination 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. It 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 FA issues a Challenge Reply once it receives a valid Challenge Request (one with a Result Code of 0) from the HA ✨ It takes the randomly generated Authenticator value from the Challenge Request, combines it with a shared secret, and makes an MD5 digest 🔐 That digest is what goes back to the HA 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: variableDestination 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. It 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 ✨
okay so a Registration Reply is what a Home Agent sends back after it gets a Challenge Reply from a Foreign Agent 💌 It tells the Foreign Agent whether the registration got accepted, and it hands over a "tunnel ID" so everyone can tell which tunnel belongs to this session 🦋
The Home Agent does the same MD5 hash on the Challenge Request Authenticator field plus the shared secret 🔐 Then it compares that digest with the Reply value in the Challenge Reply. If they match, authentication passes. If they don't, the registration gets rejected, and the Result Code in the reply tells the Foreign Agent it failed because of an authentication failure 💀
- IP fields
Source Address: The IP address of the Home Agent interface the reply is sent from.Destination Address: Copied from the Source Address of the Challenge Reply.
- UDP fields:
Source Port: variableDestination Port: Copied from the Source Port of the Challenge Reply.
After the UDP header comes the ATMP stuff 🧚
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 ReplyIdentifier: Copied from the corresponding Registration Request.Result Code: Tells you the result of the registration and authentication attempt by the Foreign Agent. See Sec. 2.8 for the list of Result Code values and what they mean 📋Tunnel ID: This is the identifier for a given mobility binding between a given Mobile Node and Home Agent. It keeps multiple tunnels between one Foreign Agent-Home Agent pair separate 🫶 It's carried in the "key" field of the GRE [1] tunnel packets that ATMP uses as its tunnel protocol. It also shows up in Deregistration Requests and Error Notification messages so they know which mobility binding they're talking about ✨
2.5 Deregistration Request
the Deregistration Request is sent by the Foreign Agent to the Home Agent to say "hey, end this mobility binding" 🙅♀️ This might happen because the Foreign Agent noticed its connection to the Mobile Node dropped. It can also happen because of an error the Foreign Agent spotted, or because it got an Error Notification from the Home Agent 🚨
- IP fields
Source Address: The IP address of the Foreign Agent interface the request is sent from.Destination Address: 5150 (or port number configured in FA for given HA)
- UDP fields:
Source Port: variableDestination Port: Copied from the Source Port of the Challenge Reply.
Then the ATMP fields follow the UDP header 💅
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 RequestIdentifier: 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 what the Home Agent sends back after a Deregistration Request from a Foreign Agent 🦋 If the request was valid, the Home Agent removes that mobility binding from its tables and sends an affirmative reply, which is giving clean-up energy 🧹 If it wasn't valid, the Home Agent sends a Deregistration Reply with a Result Code that explains why the request failed 💔
- IP fields
Source Address: The IP address of the Home Agent interface the reply is sent from.Destination Address: Copied from the Source Address of the received Deregistration Request.
- UDP fields:
Source Port: variableDestination Port: Copied from the Source Port of the received Deregistration Request.
Now the ATMP part 🌸
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 ReplyIdentifier: Copied from the corresponding Deregistration Request.Result Code: Tells you the result of the registration and authentication attempt by the Foreign Agent. See Sec. 2.8 for the list of Result Code values and what they mean 📋Tunnel ID: Tunnel identifier of the mobility binding specified in the Deregistration Request.
2.7 Error Notification
this one is the Error Notification 🚨 Either agent can send it to tell the other one that something went wrong. It's basically a last-ditch recovery move 🫠 It's for errors that can't be reported back through the normal request-reply flow, like getting a reply nobody asked for
- IP fields
Source Address: The IP address of the issuing agent interface this message is sent from.Destination Address: The IP address of the Home Agent or Foreign Agent this message is going to.
- UDP fields:
Source Port: variableDestination Port: If sent to a Home Agent, 5150 (or the port number configured for the given HA). If sent to a Foreign Agent, the source port number saved from the original Registration Request.
ATMP fields after the UDP header, bestie 💜
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 NotificationIdentifier: If it's sent 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: Shows the type of error detected. The possible result codes are defined in Sec. 2.8.Tunnel ID: Tunnel identifier of the mobility binding this message is about. If the Error Notification is sent in response to an unsolicited reply, the Tunnel ID is copied from the reply.
2.8 Result Codes
here's the full list of Result Codes, the drama queen of this whole section 👑
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 ✨
Okay bestie, so the moment the NAS spots a Mobile Node that needs ATMP service 🦋, it wakes up its ATMP Foreign Agent entity. The FA then goes and grabs the configuration info for that user. How the NAS gets that info is its own business and this spec doesn't cover it 💅. That info MUST include the Home Agent address and the shared secret for this HA. It MAY also include the Home Network Name, if a Connection Profile is gonna be used for the session 🎀.
The FA then sends a Registration Request to the HA to say "hey, an MN wants to register with you" 💌. Then it just waits for the HA to hit back with a Challenge Request. If no Challenge Request shows up, the FA resends the Registration Request every 2 seconds. After 10 retransmissions with still nothing, the FA gives up, logs the registration failure, and disconnects the MN. Rip 💀.
When the Challenge Request finally lands, the FA checks the Result code. If it's an error, the FA logs it and disconnects the MN. If the result is zero 🌸, the FA makes a Challenge Reply. To make it, the FA takes the Authenticator from the Challenge Request, sticks the shared secret (from the config data) onto the end, and then runs an MD5 hash on that whole concatenated string (authenticator + secret). The 16 octet hash goes into the Challenge Reply so the HA can check it 🔐.
Now the HA does the exact same MD5 computation, using the Challenge Request Authenticator and the shared secret (which it also has to be configured with, obvs) 🧚. If its digest matches the one in the Challenge Reply, the authentication passes and the registration is accepted ✨. If the authentication fails, or the HA is out of resources for this attempt, it sends a Registration Reply with a non-zero result code back to the FA 🙅♀️.
If the HA accepts the Challenge Reply, it assigns a Tunnel ID to the session and sends that Tunnel ID back in a Registration Reply with a zero result code 👑. This Tunnel ID needs to be unique for the FA-HA pair. It's what the pair uses to multiplex and demultiplex the packets between each other, so it's kinda the key to the whole thing 🔑.
At the moment the HA decides to accept a registration, it creates a control block that ties the Tunnel ID to the right routing info 🗺️. If the Registration Request had a Home Network Name, the HA saves that name in its table and uses it as the name of the Connection Profile for the session. Iconic ✨.
When the FA gets the Registration Reply, it checks the result code. If it's non-zero, the FA logs the failure and disconnects the MN 😭. If it's zero, the FA saves the Tunnel ID in a control block linked to the MN session. And just like that, the FA and HA are ready to swap data packets for this MN session 🦋💖.
On the FA side, everything the MN sends gets wrapped up in GRE and shipped off to the HA, with the assigned Tunnel ID sitting in the GRE Key field 🎁. When the HA gets a GRE packet, it unwraps it and routes it using the info in its control block for that Tunnel ID. Main character energy 👑.
When the HA gets a packet headed for the MN's Home Address, it MUST wrap it in a GRE packet and forward it to the right FA 🚀. The Tunnel ID goes in the GRE Key field so the FA knows which session the packet belongs to.
When the FA receives a GRE packet, it looks at the Tunnel ID in the GRE Key field and checks whether it matches the Tunnel ID of any MN that's currently connected to that FA 👀. If it matches, the FA unwraps the packet and forwards it to the MN 💅. If the Tunnel ID doesn't match any active MN, the FA sends an Error Notification message to the HA and silently tosses the GRE packet. Not me being ignored 😤.
When the FA wants to disconnect the MN from the HA, it sends a Deregistration Request, and it keeps sending one every 2 seconds 🕰️. If 10 attempts go by and there's still no Deregistration Reply from the HA, the FA logs an error and disconnects the MN anyway. If the FA does get a Deregistration Reply, it frees up the Tunnel ID and disconnects the MN 🫶.
3.0 Security Considerations 🔐
Okay, this part is serious (and honestly kinda iconic 😭). The Registration function of ATMP is protected by a Challenge/Response mechanism that works similarly to CHAP [2]. Every time a Foreign Agent tries to register, the Home Agent throws a challenge at it to authenticate. This only works if you've set up a shared secret for each HA/client pair 🗝️, so don't skip that step, periodt 💀.
4.0 Author's Address 🖋️
Kory Hamzeh
Ascend Communications
1275 Harbor Bay Parkway
Alameda, CA 94502
EMail: kory@ascend.com5.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.
Appendix A
Additional RADIUS Attributes for ATMP 🎀
This appendix lists the RADIUS attributes Ascend added to support ATMP for IP. For now they're non-vendor-specific attributes, but they've 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 HAAppendix B
IPX Operation 🌈
ATMP has a mechanism that lets IPX clients get mobility services from a HA 🧚♀️. Section 2 walks through the protocol used to register, deregister, and authenticate a tunnel for IPX. Heads up though: ATMP is built on IP datagrams for managing tunnels, so IPX tunneling with ATMP always needs an underlying IP network 🌐.
Each IPX mobile client needs an IPX network number and node address pair 🍓. IPX doesn't have anything like IP's "host route," so you have to pick an enterprise-unique network number 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, say a home agent supports two mobile clients. The home agent sits on a LAN with the IPX address AA000001. The home agent's client network can be assigned AA000002. The two mobile clients could have addresses AA000002:0040F1000001 and AA000002:0040F1000002 respectively 🫶.
IPX node numbers have to be unique on a given network. There must be a mechanism that guarantees a given mobile client's node address is unique for each home agent's network 🔒. Several techniques may be used to make sure node addresses are unique. The current ATMP implementation in this document relies on RADIUS to assign a node address at the foreign agent. On top of the Appendix A attributes for IP operation, these RADIUS attributes are included for IPX 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.📦 where this page comes from
- ietf: rfc2107 1997-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms