> Mobile IP Registration Revocation
> This chapter describes Registration Revocation for Mobile-IP and Proxy Mobile-IP and explains how it is configured. The product administration guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model and configure the required elements for that model, as described in the respective product administration guide before using the procedures in this chapter.
> Important: This license is enabled by default; however, not all features are supported on all platforms and other licenses may be required for full functionality as described in this chapter.
> Overview
> Registration Revocation is a general mechanism whereby either the HA or the FA providing Mobile IP functionality to the same mobile node can notify the other mobility agent of the termination of a binding. This functionality provides the following benefits:

> • | Timely release of Mobile IP resources at the FA and/or HA

> • | Accurate accounting

> • | Timely notification to mobile node of change in service

> Mobile IP Registration Revocation can be triggered at the FA by any of the following:

> • | Session terminated with mobile node for whatever reason

> • | Session renegotiation

> • | Administrative clearing of calls

> • | Session Manager software task outage resulting in the loss of FA sessions (sessions that could not be recovered)

> Important: Registration Revocation functionality is also supported for Proxy Mobile IP. However, only the HA can initiate the revocation for Proxy-MIP calls.
> Mobile IP Registration Revocation can be triggered at the HA by any of the following:

> • | Administrative clearing of calls

> • | Inter-Access Gateway handoff. This releases the binding at the previous access gateway/FA

> • | Session Manager software task outage resulting in the loss of FA sessions (for sessions that could not be recovered)

> • | Session Idle timer expiry (when configured to send Revocation)

> • | Any other condition under which a binding is terminated due to local policy (duplicate IMSI detected, duplicate home address requested, etc.)

> The FA and the HA negotiate Registration Revocation support when establishing a Mobile IP call. Revocation support is indicated to the Mobile Node (MN) from the FA by setting the 'X' bit in the Agent Advertisement to MN. However the MN is not involved in negotiating the Revocation for a call or in the Revocation process. It only gets notified about it. The X bit in the Agent Advertisements is just a hint to the MN that revocation is supported at the FA but is not a guarantee that it can be negotiated with the HA
> At the FA, if revocation is enabled and a FA-HA SPI is configured, the Revocation Support extension is appended to the RRQ received from the MN and protected by the FA-HA Authentication Extension. At the HA, if the RRQ is accepted, and the HA supports revocation, the HA responds with an RRP that includes the Revocation Support extension. Revocation support is considered to be negotiated for a binding when both sides have included a Revocation Support Extension during a successful registration exchange.
> Important: The Revocation Support Extension in the RRQ or RRP must be protected by the FA-HA Authentication Extension. Therefore, an FA-HA SPI must be configured at the FA and the HA for this to succeed.
> If revocation is enabled at the FA, but an FA-HA SPI is not configured at the FA for a certain HA, then FA does not send Revocation Support Extension for a call to that HA. Therefore, the call may come up without Revocation support negotiated.
> If the HA receives an RRQ with Revocation Support Extension, but not protected by FA-HA Auth Extension, it will be rejected with “FA Failed Authentication” error.
> If the FA receives a RRP with Revocation Support Extension, but not protected by FA-HA Auth Extension, it will be rejected with “HA Failed Authentication” error.
> Also note that Revocation support extension is included in the initial, renewal or handoff RRQ/RRP messages. The Revocation extension is not included in a Deregistration RRQ from the FA and the HA will ignore them in any Deregistration RRQs received.
> Configuring Registration Revocation
> Support for MIP Registration Revocation requires the following configurations:

> • | FA service(s): Registration Revocation must be enabled and operational parameters optionally configured.

> • | HA service(s): Registration Revocation must be enabled and operational parameters optionally configured.

> Important: These instructions assume that the system was previously configured to support subscriber data sessions for a core network service with FA and/or an HA according to the instructions described in the respective product Administration Guide.
> Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
> Configuring FA Services
> Configure FA services to support MIP Registration Revocation by applying the following example configuration:
> configure
> context <context_name>
> fa-service <fa_service_name>
> revocation enable
> revocation max-retransmission <number>
> revocation retransmission-timeout <time>
> end
> Save your configuration as described in Saving Your Configuration.
> Configuring HA Services
> Configure HA services to support MIP Registration Revocation by applying the following example configuration:
> configure
> context <context_name>
> ha-service <ha_service_name>
> revocation enable
> revocation max-retransmission <number>
> revocation retransmission-timeout <time>
> end
> Save your configuration as described in Saving Your Configuration.

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883