draft-ietf-mext-binding-revocation-11.txt   draft-ietf-mext-binding-revocation-12.txt 
Network Working Group A. Muhanna Network Working Group A. Muhanna
Internet-Draft M. Khalil Internet-Draft M. Khalil
Intended status: Standards Track Nortel Intended status: Standards Track Nortel
Expires: March 9, 2010 S. Gundavelli Expires: March 14, 2010 S. Gundavelli
Cisco Systems Cisco Systems
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
P. Yegani P. Yegani
Juniper Networks Juniper Networks
September 05, 2009 September 10, 2009
Binding Revocation for IPv6 Mobility Binding Revocation for IPv6 Mobility
draft-ietf-mext-binding-revocation-11.txt draft-ietf-mext-binding-revocation-12.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 48 skipping to change at page 1, line 48
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 9, 2010. This Internet-Draft will expire on March 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 25 skipping to change at page 3, line 25
3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 9 3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 9
3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding
Revocation . . . . . . . . . . . . . . . . . . . . . . 10 Revocation . . . . . . . . . . . . . . . . . . . . . . 10
3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 11 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 11
4. Binding Revocation Messages over IPv4 Transport Network . . . 12 4. Binding Revocation Messages over IPv4 Transport Network . . . 12
5. Binding Revocation Message . . . . . . . . . . . . . . . . . . 12 5. Binding Revocation Message . . . . . . . . . . . . . . . . . . 12
5.1. Binding Revocation Indication Message . . . . . . . . . . 14 5.1. Binding Revocation Indication Message . . . . . . . . . . 14
5.2. Binding Revocation Acknowledgement Message . . . . . . . . 17 5.2. Binding Revocation Acknowledgement Message . . . . . . . . 17
6. Binding Revocation Process Operation . . . . . . . . . . . . . 20 6. Binding Revocation Process Operation . . . . . . . . . . . . . 20
6.1. Sending Binding Revocation Messages . . . . . . . . . . . 20 6.1. Sending Binding Revocation Messages . . . . . . . . . . . 20
6.2. Receiving Binding Revocation Messages . . . . . . . . . . 21 6.2. Receiving Binding Revocation Messages . . . . . . . . . . 20
6.3. Retransmission of Binding Revocation Indication . . . . . 22 6.3. Retransmission of Binding Revocation Indication . . . . . 22
7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22 7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22
7.1. Sending Binding Revocation Indication . . . . . . . . . . 22 7.1. Sending Binding Revocation Indication . . . . . . . . . . 22
7.2. Receiving Binding Revocation Acknowledgement . . . . . . . 24 7.2. Receiving Binding Revocation Acknowledgement . . . . . . . 24
8. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 24 8. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 24
8.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 24 8.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 24
8.1.1. Sending Binding Revocation Indication . . . . . . . . 24 8.1.1. Sending Binding Revocation Indication . . . . . . . . 24
8.1.2. Receiving Binding Revocation Acknowledgement . . . . . 29 8.1.2. Receiving Binding Revocation Acknowledgement . . . . . 29
8.2. Binding Revocation Responder . . . . . . . . . . . . . . . 29 8.2. Binding Revocation Responder . . . . . . . . . . . . . . . 29
8.2.1. Receiving Binding Revocation Indication . . . . . . . 29 8.2.1. Receiving Binding Revocation Indication . . . . . . . 29
skipping to change at page 7, line 6 skipping to change at page 7, line 6
registration message by sending a Proxy Binding Update with a registration message by sending a Proxy Binding Update with a
lifetime of zero to indicate to the local mobility anchor of the lifetime of zero to indicate to the local mobility anchor of the
termination of the PMIPv6 mobile node binding registration. In this termination of the PMIPv6 mobile node binding registration. In this
case, the mobile access gateway includes the MN-HNP option, the MN-ID case, the mobile access gateway includes the MN-HNP option, the MN-ID
option and all other required mobility options as per [RFC5213] in option and all other required mobility options as per [RFC5213] in
order for the local mobility anchor to identify the mobile node order for the local mobility anchor to identify the mobile node
PMIPv6 binding. Additionally, in the case when the mobile access PMIPv6 binding. Additionally, in the case when the mobile access
gateway communicates a bulk termination of PMIPv6 mobility sessions, gateway communicates a bulk termination of PMIPv6 mobility sessions,
the mobile access gateway sends a Binding Revocation Indication the mobile access gateway sends a Binding Revocation Indication
message with the Global (G) and Acknowledge (A) bits set and includes message with the Global (G) and Acknowledge (A) bits set and includes
the mobile access gateway identity in the MN-ID option, see sections the mobile access gateway identity in the MN-ID option, see
Section 8.1.1 and Section 9.1.1. When the local mobility anchor Section 8.1.1 and Section 9.1.1. When the local mobility anchor
receives such Binding Revocation Indication message, it ensures that receives such Binding Revocation Indication message, it ensures that
the mobile access gateway is authorized to send such bulk termination the mobile access gateway is authorized to send such bulk termination
message and then processes the Binding Revocation Indication message message and then processes the Binding Revocation Indication message
accordingly. If the local mobility anchor processes the Binding accordingly. If the local mobility anchor processes the Binding
Revocation Indication message successfully and the Acknowledge (A) Revocation Indication message successfully and the Acknowledge (A)
bit was set, the local mobility anchor responds to the mobile access bit is set, the local mobility anchor responds to the mobile access
gateway by sending Binding Revocation Acknowledgement message. gateway by sending Binding Revocation Acknowledgement message.
In any of the above cases, the initiator of the binding revocation In any of the above cases, the initiator of the binding revocation
procedure, e.g., home agent, local mobility anchor, or mobile access procedure, e.g., home agent, local mobility anchor, or mobile access
gateway, uses the Revocation Trigger field in the Binding Revocation gateway, uses the Revocation Trigger field in the Binding Revocation
Indication message to indicate to the receiving node the reason for Indication message to indicate to the receiving node the reason for
initiating the revocation procedure. initiating the revocation procedure.
3.2. MIPv6 and DSMIP6 Use Case 3.2. MIPv6 and DSMIP6 Use Case
skipping to change at page 11, line 38 skipping to change at page 11, line 38
In addition, the local mobility anchor can send a Binding Revocation In addition, the local mobility anchor can send a Binding Revocation
Indication message to indicate that all bindings which are hosted by Indication message to indicate that all bindings which are hosted by
the peer mobile access gateway and registered with the local mobility the peer mobile access gateway and registered with the local mobility
anchor are being revoked by setting the Global (G) bit as described anchor are being revoked by setting the Global (G) bit as described
in Section 8.1.1. in Section 8.1.1.
3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings
The mobile access gateway sends a BRI message with the Global (G) bit The mobile access gateway sends a BRI message with the Global (G) bit
set and the Revocation Trigger field is set to "Per-Peer Policy" to set and the Revocation Trigger field set to "Per-Peer Policy" to
indicate that all mobility bindings which are registered at the local indicate that all mobility bindings which are registered at the local
mobility anchor and attached to the mobile access gateway are being mobility anchor and attached to the mobile access gateway are being
revoked as in Section 9.2.1. When the local mobility anchor receives revoked as in Section 9.2.1. When the local mobility anchor receives
this Binding Revocation Indication message from the specified mobile this Binding Revocation Indication message from the specified mobile
access gateway, the local mobility anchor first checks if the mobile access gateway, the local mobility anchor first checks if the mobile
access gateway is authorized to use global revocations and if the access gateway is authorized to use global revocations and if the
Acknowledge (A) bit is set, then responds with the appropriate status Acknowledge (A) bit is set, then responds with the appropriate status
code by sending a Binding Revocation Acknowledgement message as in code by sending a Binding Revocation Acknowledgement message as in
Section 8.2.2. Section 8.2.2.
skipping to change at page 12, line 28 skipping to change at page 12, line 28
traverse NATs, then the Binding Revocation messages are sent using traverse NATs, then the Binding Revocation messages are sent using
the same UDP encapsulation. The same UDP source and destination port the same UDP encapsulation. The same UDP source and destination port
numbers and IPv4 addresses used for exchanging the Proxy Binding numbers and IPv4 addresses used for exchanging the Proxy Binding
Update and Proxy Binding Acknowledgement or the Binding Update and Update and Proxy Binding Acknowledgement or the Binding Update and
Binding Acknowledgement messages MUST be used when transporting Binding Acknowledgement messages MUST be used when transporting
Binding Revocation messages over IPv4 using UDP encapsulation. For Binding Revocation messages over IPv4 using UDP encapsulation. For
example, the source UDP port number, the destination UDP port number, example, the source UDP port number, the destination UDP port number,
the source IPv4 address, and the destination IPv4 address of the the source IPv4 address, and the destination IPv4 address of the
Binding Revocation Indication message are set to the destination UDP Binding Revocation Indication message are set to the destination UDP
port number, the source UDP port number, destination IPv4 address, port number, the source UDP port number, destination IPv4 address,
and source IPv4 address of the latest successfully processed Proxy and source IPv4 address of the latest received and successfully
Binding Update or Binding Update message received, respectively. For processed Proxy Binding Update or Binding Update message,
more details on tunneling Proxy Mobile IPv6 and Mobile IPv6 signaling respectively. For more details on tunneling Proxy Mobile IPv6 and
messages over IPv4, see [ID-PMIP6-IPv4] and [RFC5555], respectively. Mobile IPv6 signaling messages over IPv4, see [ID-PMIP6-IPv4] and
[RFC5555], respectively.
5. Binding Revocation Message 5. Binding Revocation Message
This section defines the Binding Revocation Message format using a MH This section defines the Binding Revocation Message format using a MH
Type <IANA-TBD> as illustrated in Figure 4. The value in the Binding Type <IANA-TBD> as illustrated in Figure 4. The value in the Binding
Revocation Type field defines whether the Binding Revocation message Revocation Type field defines whether the Binding Revocation message
is a Binding Revocation Indication or Binding Revocation is a Binding Revocation Indication or Binding Revocation
Acknowledgement. If the Binding Revocation type field is set to 1, Acknowledgement. If the Binding Revocation type field is set to 1,
the Binding Revocation Message is a Binding Revocation Indication as the Binding Revocation Message is a Binding Revocation Indication as
in Section 5.1. However, if the value is 2, it is a Binding in Section 5.1. However, if the value is 2, it is a Binding
skipping to change at page 15, line 40 skipping to change at page 15, line 40
Global Revocation Trigger: Global Revocation Trigger:
128 Per-Peer Policy 128 Per-Peer Policy
129 Revoking Mobility Node Local Policy 129 Revoking Mobility Node Local Policy
Sequence # Sequence #
A 16-bit unsigned integer used by the sending mobility node to A 16-bit unsigned integer used by the sending mobility node to
match a returned Binding Revocation Acknowledgement with this match a returned Binding Revocation Acknowledgement with this
Binding Revocation Indication. This sequence number could be a Binding Revocation Indication. This sequence number could be a
random number. At any time,implementations MUST ensure that there random number. At any time, implementations MUST ensure that
is no collision between the sequence numbers of all outstanding there is no collision between the sequence numbers of all
Binding Revocation Messages. outstanding Binding Revocation Indication Messages.
Proxy Binding (P) Proxy Binding (P)
The Proxy Binding (P) bit is set by the sending mobility node to The Proxy Binding (P) bit is set by the sending mobility node to
indicate that the revoked binding(s) is a PMIPv6 binding. indicate that the revoked binding(s) is a PMIPv6 binding.
IPv4 HoA Binding Only (V) IPv4 HoA Binding Only (V)
The IPv4 HoA Binding Only (V) bit is set by the sending mobility The IPv4 HoA Binding Only (V) bit is set by the sending mobility
node, home agent or local mobility anchor, to indicate to the node, home agent or local mobility anchor, to indicate to the
receiving mobility entity the termination of the IPv4 Home Address receiving mobility entity the termination of the IPv4 Home Address
binding only as in Section 7.1, and Section 8.1.1. binding only as in Section 7.1, and Section 8.1.1.
Global (G) Global (G)
The Global (G) bit is set by the sending mobility node, LMA or The Global (G) bit is set by the sending mobility node, LMA or
MAG, to indicate the termination of all Per-Peer mobility Bindings MAG, to indicate the termination of all Per-Peer mobility Bindings
or Multiple Bindings which share a common identifier that are or Multiple Bindings which share a common identifier(s) that are
served by the sending and receiving mobility entities as in served by the sending and receiving mobility entities as in
Section 8.1.1 and Section 9.2.1. Section 8.1.1 and Section 9.2.1.
Acknowledge (A) Acknowledge (A)
The Acknowledge (A) bit is set by the sending mobility node, e.g. The Acknowledge (A) bit is set by the sending mobility node, e.g.
LMA, HA, or MAG, to request a Binding Revocation Acknowledgement LMA, HA, or MAG, to request a Binding Revocation Acknowledgement
be returned upon receipt of the Binding Revocation Indication as be returned upon receipt of the Binding Revocation Indication as
in Section 7.1, Section 8.1.1, and Section 9.2.1. If Acknowledge in Section 7.1, Section 8.1.1, and Section 9.2.1. If Acknowledge
(A) bit is set in the BRI message, the sending mobility node (A) bit is set in the BRI message, the sending mobility node
follows section Section 6.3 for retransmitting the BRI message. follows Section 6.3 for retransmitting the BRI message.
Reserved Reserved
These fields are unused. They MUST be initialized to zero by the These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
skipping to change at page 17, line 5 skipping to change at page 17, line 5
the specific binding or bindings that the sending mobility entity the specific binding or bindings that the sending mobility entity
requesting to be revoked. requesting to be revoked.
The following options are valid in a Binding Revocation Indication: The following options are valid in a Binding Revocation Indication:
o Home Network Prefix option [RFC5213]. This option MAY be used o Home Network Prefix option [RFC5213]. This option MAY be used
only when the (P) bit is set. This option MUST be present when only when the (P) bit is set. This option MUST be present when
the BRI is used to revoke a single Proxy MIPv6 binding cache the BRI is used to revoke a single Proxy MIPv6 binding cache
entry. entry.
o Mobile Node Identifier Option [RFC4283]. This option is mandatory o Mobile Node Identifier Option [RFC4283]. This option MUST be
when the (P) bit is set. Additionally, if the Global (G) bit is present when the (P) bit is set. Additionally, if the Global (G)
set by the mobile access gateway, this option carries the MAG bit is set by the mobile access gateway, this option MUST carry
identity. In this specification, only Mobile Node Identifier the MAG identity. In this specification, only Mobile Node
option with subtype 1 is required and other subtypes are currently Identifier option with subtype 1 is required and other subtypes
not supported. are currently not supported.
o Binding Identifier mobility option [ID-MCoA]. This option is o Binding Identifier mobility option [ID-MCoA]. This option MUST be
mandatory if the sending mobility entity requests to terminate one present if the sending mobility entity requests to terminate one
binding of a multi care-of addresses bindings for the same mobile binding of a multiple care-of addresses bindings for the same
node. The sending mobility entity may include more than one of mobile node. The sending mobility entity may include more than
the BID mobility options. one of the BID mobility options.
o IPv4 Home Address option which contains the mobile node home IPv4 o IPv4 Home Address option which contains the mobile node home IPv4
address [RFC5555]. This option is included only when the IPv4 HoA address [RFC5555]. This option MUST only be included when the
Binding only (V) bit is set. IPv4 HoA Binding only (V) bit is set.
o Alternate Care-of Address mobility option [RFC3775]. This option o Alternate Care-of Address mobility option [RFC3775]. This option
MAY be included to indicate the Care-of Address of the mobile MAY be included to indicate the Care-of Address of the mobile
node's binding that is being revoked. In the case when the Global node's binding that is being revoked. In the case when the Global
(G) bit set, this option identifies all the mobility bindings that (G) bit set, this option identifies all the mobility bindings that
share the same care-of address. Additionally, if the Global (G) share the same care-of address. Additionally, if the Global (G)
bit set, more than one Alternate Care-of Address mobility options bit set, more than one Alternate Care-of Address mobility options
MAY be present in the Binding Revocation Indication message. MAY be present in the Binding Revocation Indication message.
If no mobility options are present in this message, 4 octets of If no mobility options are present in this message, 4 octets of
skipping to change at page 20, line 36 skipping to change at page 20, line 36
However, when the responder acknowledges the Binding Revocation However, when the responder acknowledges the Binding Revocation
Indication message, the responder MUST construct the Binding Indication message, the responder MUST construct the Binding
Revocation message packet as it would any other Mobility Header with Revocation message packet as it would any other Mobility Header with
the exception of setting the MH Type field to <IANA-TBD>. It also the exception of setting the MH Type field to <IANA-TBD>. It also
MUST construct the Binding Revocation Message Data following the MUST construct the Binding Revocation Message Data following the
format of the Binding Revocation Acknowledgement message as described format of the Binding Revocation Acknowledgement message as described
in Section 5.2. In this case, the responder MUST set the Sequence in Section 5.2. In this case, the responder MUST set the Sequence
Number field by copying the value from the Sequence Number field of Number field by copying the value from the Sequence Number field of
the received Binding Revocation Indication. Additionally, it MUST the received Binding Revocation Indication. Additionally, it MUST
set the status field to a valid value that reflects the processing of set the status field to a valid value that reflects the processing of
the received Binding Revocation Indication. the received Binding Revocation Indication message.
The Binding Revocation Indication and Binding Revocation The Binding Revocation Indication and Binding Revocation
Acknowledgement messages MUST be protected using the same underlying Acknowledgement messages MUST be protected using the same underlying
security association, e.g., IPsec, that is being used between the two security association, e.g., IPsec, that is being used between the two
peers to protect the mobile node's Mobile IPv6 and its extensions peers to protect the mobile node's Mobile IPv6 and its extensions
binding registration signaling. If IPsec is not used as the binding registration signaling. If IPsec is not used as the
underlying security mechanism to protect the binding registration underlying security mechanism to protect the binding registration
signaling, the used underlying security mechanism MUST provide signaling, the used underlying security mechanism MUST provide
protection against all identified security threats as described under protection against all identified security threats as described under
Security Considerations in [RFC3775] and [RFC5213]. Security Considerations in [RFC3775] and [RFC5213].
skipping to change at page 22, line 8 skipping to change at page 21, line 45
with the Revocation Trigger field is set to a value that the mobility with the Revocation Trigger field is set to a value that the mobility
node does not support and the Acknowledge (A) bit is set, the node does not support and the Acknowledge (A) bit is set, the
receiving mobility node SHOULD reject the Binding Revocation receiving mobility node SHOULD reject the Binding Revocation
Indication message by sending a Binding Revocation Acknowledgement Indication message by sending a Binding Revocation Acknowledgement
message with the Status field set to "Revocation Trigger NOT message with the Status field set to "Revocation Trigger NOT
Supported". Supported".
If a mobility node receives a Binding Revocation Indication message If a mobility node receives a Binding Revocation Indication message
with a Revocation Trigger value that is NOT allowed with the Binding with a Revocation Trigger value that is NOT allowed with the Binding
Revocation Indication message intent, e.g., the Global (G) bit set Revocation Indication message intent, e.g., the Global (G) bit set
and the Revocation Trigger field vale is a per-MN specific, the and the Revocation Trigger field value is a per-MN specific, the
receiving mobility node SHOULD reject the Binding Revocation receiving mobility node SHOULD reject the Binding Revocation
Indication message by sending a Binding Revocation Acknowledgement Indication message by sending a Binding Revocation Acknowledgement
message with the Status field set to "Revocation Function NOT message with the Status field set to "Revocation Function NOT
Supported". Supported".
6.3. Retransmission of Binding Revocation Indication 6.3. Retransmission of Binding Revocation Indication
If the sending mobility entity set the Acknowledge (A) bit in the BRI If the sending mobility entity set the Acknowledge (A) bit in the BRI
and does not receive a Binding Revocation Acknowledgement in response and does not receive a Binding Revocation Acknowledgement in response
to the outstanding Binding Revocation Indication before the to the outstanding Binding Revocation Indication before the
skipping to change at page 24, line 6 skipping to change at page 23, line 45
In a race condition case, the home agent may receive a Binding Update In a race condition case, the home agent may receive a Binding Update
from the mobile node while the mobile node's BCE has the revocation from the mobile node while the mobile node's BCE has the revocation
in progress flag set, the home agent SHOULD handle this case based on in progress flag set, the home agent SHOULD handle this case based on
the reason for sending the Binding Revocation Indication message and the reason for sending the Binding Revocation Indication message and
its local policy. In this case, if the home agent accepts the its local policy. In this case, if the home agent accepts the
Binding Update, it needs to update the mobile node BCE accordingly, Binding Update, it needs to update the mobile node BCE accordingly,
e.g. removing the revocation in progress flag. e.g. removing the revocation in progress flag.
When the home agent needs to revoke one or more of a mobile node When the home agent needs to revoke one or more of a mobile node
bindings that were created using Multi Care-of address registration bindings that were created using Multiple Care-of address
as in [ID-MCoA], the home agent MUST include all the related BID registration as in [ID-MCoA], the home agent MUST include all the
mobility options that identify these bindings in the Binding related BID mobility options that identify these bindings in the
Revocation Indication message. In the case when the home agent needs Binding Revocation Indication message. In the case when the home
to revoke all of the mobile node bindings, the home agent SHOULD NOT agent needs to revoke all of the mobile node bindings, the home agent
include any of the BID mobility options. SHOULD NOT include any of the BID mobility options.
7.2. Receiving Binding Revocation Acknowledgement 7.2. Receiving Binding Revocation Acknowledgement
When the home agent receives a packet carrying a valid Binding When the home agent receives a packet carrying a valid Binding
Revocation Acknowledgement that was successfully processed as in Revocation Acknowledgement that was successfully processed as in
Section 6.2, the home agent SHOULD examine the Status field as Section 6.2, the home agent SHOULD examine the Status field as
follows: follows:
o If the Status field indicates that the Binding Revocation o If the Status field indicates that the Binding Revocation
Indication was processed successfully, the home agent MUST delete Indication was processed successfully, the home agent MUST delete
skipping to change at page 25, line 25 skipping to change at page 25, line 15
o If the Mobile Node Identifier, MN-ID, is registered in more than o If the Mobile Node Identifier, MN-ID, is registered in more than
one of the mobile node's BCE and the local mobility anchor does one of the mobile node's BCE and the local mobility anchor does
NOT need to revoke all of the mobile node's bindings, the Binding NOT need to revoke all of the mobile node's bindings, the Binding
Revocation Indication message MUST contain another identifier to Revocation Indication message MUST contain another identifier to
uniquely identify the mobile node binding(s) that is being uniquely identify the mobile node binding(s) that is being
revoked, e.g., at least one Home Network Prefix option which revoked, e.g., at least one Home Network Prefix option which
contains the mobile node's registered Home Network Prefix (HNP) contains the mobile node's registered Home Network Prefix (HNP)
for the binding being revoked. for the binding being revoked.
o In case of revoking all Per-Peer bindings, the Global (G) bit MUST o In case of revoking all Per-Peer bindings, the Global (G) bit MUST
be set and the Revocation Trigger MUST contain a value of "Per- be set and the Revocation Trigger MUST contain the value "Per-Peer
Peer Policy" to request the mobile access gateway to remove all Policy" to request the mobile access gateway to remove all Per-
Per-Peer bindings that are registered with the local mobility Peer bindings that are registered with the local mobility anchor
anchor and this mobile access gateway. and this mobile access gateway.
o Whenever the Global (G) bit is set in the Binding Revocation o Whenever the Global (G) bit is set in the Binding Revocation
Indication, the Acknowledge (A) bit MUST be set to request the Indication, the Acknowledge (A) bit MUST be set to request the
mobile access gateway to send a Binding Revocation mobile access gateway to send a Binding Revocation
Acknowledgement. Acknowledgement.
o The care-of address for the binding MUST be used as the o The care-of address for the binding MUST be used as the
destination address in the packet's IPv6 header, unless an destination address in the packet's IPv6 header, unless an
Alternate Care-of Address mobility option is included in the Alternate Care-of Address mobility option is included in the
Binding Revocation Indication message. If an Alternate Care-of Binding Revocation Indication message. If an Alternate Care-of
Address option is included in the Binding Revocation Indication Address option is included in the Binding Revocation Indication
message, the destination address in the packet's IPv6 header message, the destination address in the packet's IPv6 header
SHOULD be set to the source IP address of the packet that carried SHOULD be set to the source IP address of the packet that carried
the latest successful Binding Update with the Alternate Care-of the latest successful Proxy Binding Update with the Alternate
address included. Care-of address included.
The Acknowledge (A) bit in the Binding Revocation Indication requests The Acknowledge (A) bit in the Binding Revocation Indication requests
the mobile access gateway to return a Binding Revocation the mobile access gateway to return a Binding Revocation
Acknowledgement. If the local mobility anchor set the Acknowledge Acknowledgement. If the local mobility anchor sets the Acknowledge
(A) bit in the Binding Revocation Indication message, the local (A) bit in the Binding Revocation Indication message, the local
mobility anchor SHOULD retransmit Binding Revocation Indication mobility anchor SHOULD retransmit the Binding Revocation Indication
message by following the procedure described in Section 6.3 until it message by following the procedure described in Section 6.3 until it
receives a matching Binding Revocation Acknowledgement or the receives a matching Binding Revocation Acknowledgement or the
BRIMaxRetransmitNumber is reached before deleting the mobile node IP BRIMaxRetransmitNumber is reached before deleting the mobile node IP
tunnel to the mobile access gateway. The local mobility anchor MAY tunnel to the mobile access gateway. The local mobility anchor MAY
delete the mobile node(s) IP tunnel immediately after sending the delete the mobile node(s) IP tunnel immediately after sending the
initial Binding Revocation Indication and before receiving the initial Binding Revocation Indication and before receiving the
Binding Revocation Acknowledgement message. Binding Revocation Acknowledgement message.
When the local mobility anchor sends a Binding Revocation Indication When the local mobility anchor sends a Binding Revocation Indication
to the mobile access gateway to remove a specific binding and the to the mobile access gateway to remove a specific binding and the
skipping to change at page 26, line 26 skipping to change at page 26, line 16
receives a Binding Revocation Acknowledgement or the receives a Binding Revocation Acknowledgement or the
BRIMaxRetransmitNumber is reached. In the case when the local BRIMaxRetransmitNumber is reached. In the case when the local
mobility anchor sets the Revocation Trigger field to a value which mobility anchor sets the Revocation Trigger field to a value which
indicates inter-MAG handover, the local mobility anchor MAY switch indicates inter-MAG handover, the local mobility anchor MAY switch
the mobile node IP tunnel to the target mobile access gateway before the mobile node IP tunnel to the target mobile access gateway before
sending the Binding Revocation Indication to the source mobile access sending the Binding Revocation Indication to the source mobile access
gateway. gateway.
In a race condition case, the local mobility anchor may receive a In a race condition case, the local mobility anchor may receive a
Proxy Binding Update from the mobile access gateway while the mobile Proxy Binding Update from the mobile access gateway while the mobile
node's proxy BCE has the revocation in progress flag set, the local node's proxy BCE has the revocation in progress flag set. The local
mobility anchor should handle this case based on the reason for mobility anchor should handle this case based on the reason for
sending the Binding Revocation Indication message and its local sending the Binding Revocation Indication message and its local
policy. In this case, if the local mobility anchor accepts the Proxy policy. In this case, if the local mobility anchor accepts the Proxy
Binding Update, it needs to update the mobile node proxy BCE Binding Update, it needs to update the mobile node proxy BCE
accordingly, e.g. removing the revocation in progress flag. accordingly, e.g. removing the revocation in progress flag.
When the local mobility anchor needs to revoke all the mobile nodes When the local mobility anchor needs to revoke all the mobile nodes
proxy BCEs that are registered with the local mobility anchor and the proxy BCEs that are registered with the local mobility anchor and the
mobile access gateway, it MUST set the Global (G) bit and set the mobile access gateway, it MUST set the Global (G) bit and set the
value of the Revocation Trigger field to "Per-Peer Policy". In this value of the Revocation Trigger field to "Per-Peer Policy". In this
skipping to change at page 26, line 51 skipping to change at page 26, line 41
BCEs that belong to a specific realm and are registered with the BCEs that belong to a specific realm and are registered with the
local mobility anchor and the mobile access gateway, the local local mobility anchor and the mobile access gateway, the local
mobility anchor MUST set the Global (G) bit and set the value of the mobility anchor MUST set the Global (G) bit and set the value of the
Revocation Trigger field to "Revoking Mobility Node Local Policy". Revocation Trigger field to "Revoking Mobility Node Local Policy".
In this case, the local mobility anchor MUST include a mobility In this case, the local mobility anchor MUST include a mobility
option in the Binding Revocation Indication that is shared among all option in the Binding Revocation Indication that is shared among all
the impacted mobile nodes BCEs, e.g., the mobile node identifier the impacted mobile nodes BCEs, e.g., the mobile node identifier
option, MN-ID option, with subtype value of 1. In this case, the NAI option, MN-ID option, with subtype value of 1. In this case, the NAI
value in the MN-ID MUST follow the format where the content after the value in the MN-ID MUST follow the format where the content after the
"@" character defines the realm which is shared amongst all of the "@" character defines the realm which is shared amongst all of the
impacted mobile nodes proxy BCEs. As an example: @example.one.com impacted mobile nodes proxy BCEs. As an example: @example.com
identifies all mobile nodes which their MN-ID value contain identifies all mobile nodes which their MN-ID value contain
"example.one.com as the realm, e.g., "1234abdelta@example.one.come" "example.com" as the realm, e.g., "1234abdelta@example.com",
and "axxxyzd@example.one.com, and abcdefg.xyz123@example.one.com. "axxxyzd@example.com", and "abcdefg.xyz123@example.com", but not
"1234abdelta@foo.example.com".
When the local mobility anchor needs to revoke a subgroup of the When the local mobility anchor needs to revoke a subgroup of the
mobile nodes proxy BCEs that belong to a specific realm and are mobile nodes proxy BCEs that belong to a specific realm and are
registered with the local mobility anchor and the mobile access registered with the local mobility anchor and the mobile access
gateway, the local mobility anchor MUST set the Global (G) bit and gateway, the local mobility anchor MUST set the Global (G) bit and
set the value of the Revocation Trigger field to "Revoking Mobility set the value of the Revocation Trigger field to "Revoking Mobility
Node Local Policy". In this case, the local mobility anchor MUST Node Local Policy". In this case, the local mobility anchor MUST
include an additional mobility option to the mobile node identifier include an additional mobility option to the mobile node identifier
option, MN-ID option, with subtype value of 1. In other words, the option, MN-ID option, with subtype value of 1. In other words, the
impacted mobile node BCEs are those which have a MN-ID with a realm impacted mobile node BCEs are those which have a MN-ID with a realm
as specified above and is assigned the same proxy care-of address as as specified above and, e.g., are assigned the same proxy care-of
the one included in the Alternate Care-of address mobility option. address as the one included in the Alternate Care-of address mobility
option.
When the mobile node is registered with multiple Home Network When the mobile node is registered with multiple Home Network
Prefixes for the same proxy care-of address, the local mobility Prefixes for the same proxy care-of address, the local mobility
anchor SHOULD include a HNP option for each registered HNP in the anchor SHOULD include a HNP option for each registered HNP in the
Binding Revocation Indication. Alternatively, it MAY include only Binding Revocation Indication. Alternatively, it MAY include only
the mobile node identifier, MN-ID, option with the mobile node NAI the mobile node identifier, MN-ID, option with the mobile node NAI
included to indicate to the mobile access gateway to remove all included to indicate to the mobile access gateway to remove all
bindings of the specified mobile node NAI in the MN-ID option. bindings of the specified mobile node NAI in the MN-ID option.
According to Proxy Mobile IPv6 specification [RFC5213], if the local According to Proxy Mobile IPv6 specification [RFC5213], if the local
skipping to change at page 28, line 45 skipping to change at page 28, line 35
binding cache entry for too long, if the mobile node is actually binding cache entry for too long, if the mobile node is actually
attaching to the new MAG with a different interface. attaching to the new MAG with a different interface.
When the mobile node is registered with an IPv4 proxy home address in When the mobile node is registered with an IPv4 proxy home address in
addition to the Home Network Prefix where both of the IPv4 pHoA and addition to the Home Network Prefix where both of the IPv4 pHoA and
HNP are bound to the same proxy CoA, the local mobility anchor MAY HNP are bound to the same proxy CoA, the local mobility anchor MAY
revoke the mobile node IPv4 proxy HoA binding to the current mobile revoke the mobile node IPv4 proxy HoA binding to the current mobile
node proxy CoA while maintaining the mobile node binding of the HNP node proxy CoA while maintaining the mobile node binding of the HNP
to its current pCoA as part of the mobile node BCE. In this case, if to its current pCoA as part of the mobile node BCE. In this case, if
the local mobility anchor decides to revoke the mobile node IPv4 the local mobility anchor decides to revoke the mobile node IPv4
proxy HoA ONLY, it MUST send a Binding Revocation Indication message proxy HoA only, it MUST send a Binding Revocation Indication message
following the procedure in Section 6.1 and the following rules: following the procedure in Section 6.1 and the following rules:
o The IPv4 HoA Binding Only (V) bit MUST be set in the BRI to o The IPv4 HoA Binding Only (V) bit MUST be set in the BRI to
indicate that only the IPv4 home address binding is being revoked. indicate that only the IPv4 home address binding is being revoked.
o The Acknowledge (A) bit MUST be set to request the mobile access o The Acknowledge (A) bit MUST be set to request the mobile access
gateway to send a Binding Revocation Acknowledgement message. gateway to send a Binding Revocation Acknowledgement message.
o The IPv4 Home Address option MUST be included with the mobile o The IPv4 Home Address option MUST be included with the mobile
node's registered IPv4 home address that is being released in node's registered IPv4 home address that is being released in
skipping to change at page 30, line 10 skipping to change at page 29, line 48
When the local mobility anchor receives a packet carrying a Binding When the local mobility anchor receives a packet carrying a Binding
Revocation Indication that was successfully processed as in Revocation Indication that was successfully processed as in
Section 6.2, the local mobility anchor SHOULD in addition process the Section 6.2, the local mobility anchor SHOULD in addition process the
message as follows: message as follows:
o Validate that Binding Revocation Indication is formatted as in o Validate that Binding Revocation Indication is formatted as in
Section 5.1 and if the (P) bit is set, the local mobility anchor Section 5.1 and if the (P) bit is set, the local mobility anchor
MUST validate that all impacted binding(s) have the proxy binding MUST validate that all impacted binding(s) have the proxy binding
flag set. flag set.
o If the Global (G) bit is set and the Revocation Trigger value is o If the Global (G) bit is set and the Revocation Trigger field
"Per-Peer Policy", the Proxy (P) bit MUST be set and the Binding value is "Per-Peer Policy", the LMA MUST validate that the Proxy
Revocation Indication SHOULD contain the mobile access gateway ID (P) bit is set and the MN-ID option is present with the mobile
in the MN-ID option. The local mobility anchor MUST verify that access gateway identity included. In addition, the local mobility
the identified mobile access gateway as per the value in the MN-ID anchor MUST verify that the identified mobile access gateway as
option is authorized to use the Global revocation, see section per the value in the MN-ID option is authorized to use the global
Section 13. revocation with revocation trigger value "Per-Peer Policy", see
Section 13. If the Acknowledge (A) bit is set and the local
mobility anchor processes the Global Binding Revocation Indication
message successfully, it MUST send a successful Binding Revocation
Acknowledgement message. However, if the Acknowledge (A) bit is
not set, the local mobility anchor SHOULD silently discard the
Binding Revocation Indication message.
o If the Global (G) bit is set and the Revocation Trigger value is o If the Global (G) bit is set and the Revocation Trigger value is
"Per-Peer Policy", and only the mobile node identifier, MN-ID, "Per-Peer Policy", and only the mobile node identifier, MN-ID,
option is included, the local mobility anchor MUST revoke all option is included, the local mobility anchor MUST revoke all
mobile nodes bindings which proxy CoA is the one used as the mobile nodes bindings which proxy CoA is the one used as the
source of the IPv6 packet that carried the Binding Revocation source of the IPv6 packet that carried the Binding Revocation
Indication. However, if one or more Alternate Care-of Address Indication. However, if one or more Alternate Care-of Address
options are included in addition to the mobile node identifier options are included in addition to the mobile node identifier
option, the local mobility anchor MUST revoke all mobile nodes option, the local mobility anchor MUST revoke all mobile nodes
bindings which proxy Care-of Address matches one of the Care-of bindings which proxy Care-of Address matches one of the Care-of
address(es) in the Alternate Care-of Address option(s). address(es) in the Alternate Care-of Address option(s).
o The local mobility anchor identifies all impacted mobile nodes o The local mobility anchor identifies all impacted mobile nodes
bindings and if the Acknowledge (A) bit is set, the local mobility bindings and if the Acknowledge (A) bit is set, the local mobility
anchor MUST send a Binding Revocation Acknowledgement following anchor MUST send a Binding Revocation Acknowledgement following
Section 8.2.2 using the appropriate status code. Section 8.2.2 using the appropriate status code.
o If the Global (G) bit is NOT set, the local mobility anchor SHOULD o If the Global (G) bit is not set, the local mobility anchor SHOULD
use the included mobility options to identify the impacted mobile use the included mobility options to identify the impacted mobile
node binding as follows: node binding as follows:
1. If only the mobile node identifier, MN-ID, option is included, 1. If only the mobile node identifier, MN-ID, option is included,
the local mobility anchor MUST revoke all bindings for this the local mobility anchor MUST revoke all bindings for this
mobile node which use the specified mobile node NAI. mobile node which use the specified mobile node NAI including
the IPv4 Home Address binding(s) if present.
2. If the mobile node identifier, MN-ID, and the Home Network 2. If the mobile node identifier, MN-ID, and one Home Network
Prefix option are included, the local mobility anchor MUST Prefix option are included, the local mobility anchor MUST
only remove the specified proxy binding. only remove the specified mobile node proxy binding.
3. If the mobile node identifier, MN-ID, option and more than one 3. If the mobile node identifier, MN-ID, option and more than one
Home Network Prefix options are included, the local mobility Home Network Prefix options are included, the local mobility
anchor MUST remove all bindings which are referenced by these anchor MUST remove all bindings which are referenced by these
multiple Home Network Prefixes for the specified mobile node Home Network Prefixes for the specified mobile node NAI.
NAI.
4. If the IPv4 HoA binding Only (V) bit is set and the mobile 4. If the IPv4 HoA binding Only (V) bit is set and the mobile
node identifier, MN-ID, option and the IPv4 Home Address node identifier, MN-ID, option and the IPv4 Home Address
option are included, the local mobility anchor MUST remove option are included, the local mobility anchor MUST remove
only the IPv4 HoA address binding to the mobile node current only the IPv4 HoA address binding to the mobile node current
proxy Care-of address. proxy Care-of address.
The Revocation Trigger field value in the received Binding Revocation The Revocation Trigger field value in the received Binding Revocation
Indication could be used by the local mobility anchor to log an event Indication could be used by the local mobility anchor to log an event
or update some local parameters which tracks the state of the peer or update some local parameters which tracks the state of the peer
skipping to change at page 32, line 4 skipping to change at page 31, line 48
bit set and the Revocation Trigger field is set to "Per-Peer bit set and the Revocation Trigger field is set to "Per-Peer
Policy", but the MN-ID option is not included, the local mobility Policy", but the MN-ID option is not included, the local mobility
anchor MUST set the Status field to (Global Revocation NOT anchor MUST set the Status field to (Global Revocation NOT
Authorized). Authorized).
o In the case that one of the bindings identified in the received o In the case that one of the bindings identified in the received
Binding Revocation Indication message has already been released, Binding Revocation Indication message has already been released,
the local mobility anchor MAY set the Status field to partial the local mobility anchor MAY set the Status field to partial
success and in this case it MAY include the mobile node identifier success and in this case it MAY include the mobile node identifier
or the Home Network Prefix option to identify the binding(s) that or the Home Network Prefix option to identify the binding(s) that
failed revocation. failed the revocation procedure.
o The destination IP address of the IPv6 packet of the Binding o The destination IP address of the IPv6 packet of the Binding
Revocation Acknowledgement is set to the source IP address of the Revocation Acknowledgement is set to the source IP address of the
received Binding Revocation Indication. received Binding Revocation Indication.
9. Mobile Access Gateway Operation 9. Mobile Access Gateway Operation
9.1. Binding Revocation Responder 9.1. Binding Revocation Responder
9.1.1. Receiving Binding Revocation Indication 9.1.1. Receiving Binding Revocation Indication
Upon receiving a packet carrying a Binding Revocation Indication, the Upon receiving a packet carrying a Binding Revocation Indication, the
mobile access gateway MUST validate the packet according to mobile access gateway MUST validate and process the packet according
Section 6.2 and the following: to Section 6.2 and the following:
o Binding Revocation Indication MUST be formatted as in Section 5.1 o Binding Revocation Indication MUST be formatted as in Section 5.1
and the (P) bit is set. and the (P) bit is set.
o If the Acknowledge (A) bit in the received Binding Revocation o If the Acknowledge (A) bit in the received Binding Revocation
Indication is set, the mobile access gateway MUST send a Binding Indication is set, the mobile access gateway MUST send a Binding
Revocation Acknowledgement following Section 9.1.2 using the Revocation Acknowledgement following Section 9.1.2 using the
appropriate status value. appropriate status value.
o If the Global (G) bit is set and the Revocation Trigger field o If the Global (G) bit is set and the Revocation Trigger field
value is "Per-Peer policy", the mobile access gateway identifies value is "Per-Peer policy", the mobile access gateway identifies
all bindings that are registered at the local mobility anchor and all bindings that are registered at the local mobility anchor and
the mobile access gateway. If this Binding Revocation Indication the mobile access gateway. If this Binding Revocation Indication
message does not include any mobility options and the Acknowledge message does not include any mobility options and the Acknowledge
(A) bit is set, the mobile access gateway MUST send a successful (A) bit is set, the mobile access gateway MUST send a successful
Binding Revocation Acknowledgement with the appropriate status Binding Revocation Acknowledgement with the appropriate status
code to the local mobility anchor. Since such this Binding code to the local mobility anchor. Since such Binding Revocation
Revocation Indication message impacts all the mobility sessions Indication message impacts all mobility sessions that are
that are registered with the mobile access gateway and the local registered with the mobile access gateway and the local mobility
mobility anchor, no mobility option is expected in this Binding anchor, no mobility option MUST be present in this Binding
Revocation Indication message. However, if this received Binding Revocation Indication message. However, if this received Binding
Revocation Indication message includes any mobility option and the Revocation Indication message includes any mobility option and the
Acknowledge (A) bit set, the mobile access gateway MUST send a Acknowledge (A) bit set, the mobile access gateway MUST send a
Binding Revocation Acknowledgement with status code set to Binding Revocation Acknowledgement with status code set to
"Revocation Function NOT Supported". "Revocation Function NOT Supported".
o If the Global (G) bit is set and the Revocation Trigger field o If the Global (G) bit is set and the Revocation Trigger field
value is "Revoking Mobility Node Local Policy", the mobile access value is "Revoking Mobility Node Local Policy", the mobile access
gateway MUST identify all bindings that are registered at the gateway MUST identify all bindings that are registered at the
local mobility anchor and the mobile access gateway and share the local mobility anchor and the mobile access gateway and share the
criteria based on the mobility option(s) included in the Binding criteria based on the mobility option(s) included in the Binding
Revocation Indication. In this case, the mobile access gateway Revocation Indication. In this case, the mobile access gateway
MUST verify that at least the MN-ID option with the subtype value MUST verify that at least the MN-ID option with the subtype value
of 1 is included in the Binding Revocation Indication and it is of 1 is included in the Binding Revocation Indication and it is
formatted as specified is section Section 8.1.1. If the mobile formatted as specified is Section 8.1.1. If the mobile access
access gateway successfully process the BRI and the Acknowledge gateway successfully process the Binding Revocation Indication and
(A) bit is set, the mobile access gateway MUST send a successful the Acknowledge (A) bit is set, the mobile access gateway MUST
Binding Revocation Acknowledgement with the appropriate status send a successful Binding Revocation Acknowledgement with the
code to the local mobility anchor. appropriate status code to the local mobility anchor.
o If the Global (G) bit is set and the Revocation Trigger field o If the Global (G) bit is set and the Revocation Trigger field
value is "Revoking Mobility Node Local Policy", and no mobility value is "Revoking Mobility Node Local Policy", and no mobility
options are included in the Binding Revocation Indication message options are included in the Binding Revocation Indication message
or the mobile access gateway is not able to identify the impacted or the mobile access gateway is not able to identify the impacted
mobile nodes bindings based on the included mobility options, the mobile nodes bindings based on the included mobility options, the
mobile access gateway MUST treat this as an error scenario. In mobile access gateway MUST treat this as an error scenario. In
this case, the mobile access gateway SHOULD send a Binding this case, if the Acknowledge (A) bit is set, the mobile access
Revocation Acknowledgement message with status "Revoked Mobile gateway MUST send a Binding Revocation Acknowledgement message
Nodes Identity Required". with status "Revoked Mobile Nodes Identity Required".
o If the Revocation Trigger field value in the received Binding o If the Revocation Trigger field value in the received Binding
Revocation Indication message indicates inter-MAG handover, e.g., Revocation Indication message indicates inter-MAG handover, e.g.,
Inter-MAG Handover - Unknown, and the Acknowledge (A) bit is set, Inter-MAG Handover - Unknown, and the Acknowledge (A) bit is set,
the mobile access gateway uses the mobility option(s) included in the mobile access gateway uses the mobility option(s) included in
the Binding Revocation Indication message to identify the mobile the Binding Revocation Indication message to identify the mobile
node binding. The mobile access gateway SHOULD ensure that the node binding. The mobile access gateway SHOULD ensure that the
mobile node is no longer attached to the mobile access gateway mobile node is no longer attached to the mobile access gateway
before sending a successful Binding Revocation Acknowledgement before sending a successful Binding Revocation Acknowledgement
message to the local mobility anchor. However, if the mobile message to the local mobility anchor. However, if the mobile
access gateway verified that the mobile node is still directly access gateway verified that the mobile node is still directly
attached, the mobile access gateway MUST set the status field in attached, the mobile access gateway MUST set the status field in
the Binding Revocation Acknowledgement to "Revocation failed - MN the Binding Revocation Acknowledgement to "Revocation failed - MN
is Attached". is Attached".
o If the IPv4 HoA Binding Only (V) bit in the received Binding o If the IPv4 HoA Binding Only (V) bit is set, the mobile access
Revocation Indication message is set, the mobile access gateway gateway uses the MN-ID option to identify the mobile node binding
uses the MN-ID option to identify the mobile node binding entry in entry in the Binding Update List (BUL). It MUST verify that the
the Binding Update List (BUL). It MUST verify that the IPv4 IPv4 address included in the IPv4 Home Address option in the
address included in the IPv4 Home Address option in the received received Binding Revocation Indication is the same as the IPv4
Binding Revocation Indication is the same as the IPv4 proxy HoA proxy HoA that is assigned to the mobile node. After the mobile
that is assigned to the mobile node. After the mobile access access gateway successfully validates the received IPv4 home
gateway successfully validates the received IPv4 home address as address as the mobile node IPv4 HoA, it MUST consider this as an
the mobile node IPv4 HoA, it MUST consider this as an indication indication to ONLY release the mobile node IPv4 proxy HoA binding
to ONLY release the mobile node IPv4 proxy HoA binding to the to the mobile node current proxy CoA. Consequently, it MUST
mobile node current proxy CoA. Consequently, it MUST continue to continue to maintain the mobile node IPv6 proxy HoA or HNP binding
maintain the mobile node IPv6 proxy HoA or HNP binding to the to the current mobile node proxy CoA as part of the mobile node
current mobile node proxy CoA as part of the mobile node binding binding in the BUL entry and release all resources associated with
in the BUL entry and release all resources associated with the MN the MN IPv4 proxy HoA binding to the MN pCoA. In this case, if
IPv4 proxy HoA binding to the MN pCoA. In this case, if the the Acknowledge (A) bit is set, the mobile access gateway MUST
Acknowledge (A) bit is set, the mobile access gateway MUST send a send a Binding Revocation Acknowledgement message with the Status
Binding Revocation Acknowledgement message with the Status field field is set to success. On the other hand, if the mobile access
is set to success. On the other hand, if the mobile access
gateway is able to identify the mobile node binding using the gateway is able to identify the mobile node binding using the
MN-ID but failed to identify the received IPv4 proxy HoA, it MUST MN-ID but failed to identify the received IPv4 proxy HoA, it MUST
send a Binding Revocation Acknowledgement with Status field is set send a Binding Revocation Acknowledgement with Status field is set
to "Binding Does NOT Exist". to "Binding Does NOT Exist".
The Revocation Trigger field value in the received Binding Revocation The Revocation Trigger field value in the received Binding Revocation
Indication could be used by the mobile access gateway to define what Indication could be used by the mobile access gateway to define what
actions the mobile access gateway could do to inform the mobile node actions the mobile access gateway could do to inform the mobile node
that its IP connectivity to the current HNP has been terminated, that its IP connectivity to the current HNP has been terminated,
e.g., if the Revocation Trigger field is set to "Administrative e.g., if the Revocation Trigger field is set to "Administrative
skipping to change at page 35, line 27 skipping to change at page 35, line 23
gateway to inform the local mobility anchor to terminate all mobile gateway to inform the local mobility anchor to terminate all mobile
nodes bindings which are registered at the local mobility anchor and nodes bindings which are registered at the local mobility anchor and
the mobile access gateway, the mobile access gateway sends a Binding the mobile access gateway, the mobile access gateway sends a Binding
Revocation Indication message following Section 6.1 and the Revocation Indication message following Section 6.1 and the
following: following:
o The Acknowledge (A) bit MUST be set to request the local mobility o The Acknowledge (A) bit MUST be set to request the local mobility
anchor to send a Binding Revocation Acknowledgement upon receipt anchor to send a Binding Revocation Acknowledgement upon receipt
of the Binding Revocation Indication. of the Binding Revocation Indication.
o The Proxy Binding (P) bit MUST be set to indicate that bindings o The Proxy Binding (P) bit MUST be set to indicate that the
that being revoked is a PMIPv6 binding. binding(s) being revoked is a PMIPv6 binding.
o The Global (G) bit MUST be set and the Revocation Trigger MUST o The Global (G) bit MUST be set and the Revocation Trigger MUST
contain a value of "Per-Peer Policy" in the Binding Revocation contain a value of "Per-Peer Policy" in the Binding Revocation
Indication to request the local mobility anchor to remove all Per- Indication to request the local mobility anchor to remove all Per-
Peer bindings that are registered with the local mobility anchor Peer bindings that are registered with the local mobility anchor
and this mobile access gateway. In this case, the MN-ID option and this mobile access gateway. In this case, the MN-ID option
MUST be included in the Binding Revocation Indication and contain MUST be included in the Binding Revocation Indication and contain
the mobile access gateway identity. In addition, the mobile the mobile access gateway identity. In addition, the mobile
access gateway MAY include one or more Alternate Care-of Address access gateway MAY include one or more Alternate Care-of Address
option(s). The Alternate Care-of Address option(s) contain the option(s). The Alternate Care-of Address option(s) contain the
proxy Care-of address(es) the bindings of which are being impacted proxy Care-of address(es) the bindings of which are being impacted
by this Binding Revocation Indication message. by this Binding Revocation Indication message.
o The mobile access gateway address MAY be used as the source o The mobile access gateway address MAY be used as the source
address in the packet's IPv6 header. address in the packet's IPv6 header.
The Acknowledge (A) bit in the Binding Revocation Indication requests The Acknowledge (A) bit in the Binding Revocation Indication requests
the local mobility anchor to return a Binding Revocation the local mobility anchor to return a Binding Revocation
Acknowledgement in response to this Binding Revocation Indication. Acknowledgement in response to this Binding Revocation Indication.
As described in Section 6.3, the mobile access gateway SHOULD As described in Section 6.3, if the Acknowledge (A) bit is set, the
retransmit this Binding Revocation Indication to the local mobility mobile access gateway SHOULD retransmit this Binding Revocation
anchor until it receives a matching Binding Revocation Indication to the local mobility anchor until it receives a matching
Acknowledgement or the BRIMaxRetransmitNumber is reached. The mobile Binding Revocation Acknowledgement or the BRIMaxRetransmitNumber is
access gateway MAY delete the mobile nodes IP tunnels immediately reached. The mobile access gateway MAY delete the mobile nodes IP
after sending the Binding Revocation Indication and before receiving tunnels immediately after sending the Binding Revocation Indication
a Binding Revocation Acknowledgement message from the LMA. and before receiving a Binding Revocation Acknowledgement message
from the LMA.
9.2.2. Receiving Binding Revocation Acknowledgement 9.2.2. Receiving Binding Revocation Acknowledgement
When the mobile access gateway receives a packet carrying a valid When the mobile access gateway receives a packet carrying a valid
Binding Revocation Acknowledgement that was successfully processed Binding Revocation Acknowledgement that was successfully processed
according to Section 6.2, the mobile access gateway MUST process the according to Section 6.2, the mobile access gateway MUST process the
received Binding Revocation Acknowledgement as per the followings: received Binding Revocation Acknowledgement as per the followings:
o When the mobile access gateway receives a packet carrying a valid o When the mobile access gateway receives a packet carrying a valid
Binding Revocation Acknowledgement and the Global (G) and Proxy Binding Revocation Acknowledgement and the Global (G) and Proxy
Binding (P) bits are set and the mobile nodes BCEs are in the Binding (P) bits are set and the mobile nodes BCEs are in the
state of Revocation in Progress, the mobile access gateway SHOULD state of Revocation in Progress, the mobile access gateway SHOULD
examine the Status field as follows: examine the Status field as follows:
o If the Status field indicates that the Binding Revocation * If the Status field indicates that the Binding Revocation
Indication was processed successfully, the mobile access gateway Indication was processed successfully, the mobile access
MUST delete the current timer and the mobile nodes proxy bindings gateway MUST delete the current timer and the mobile nodes
and all associated resources. proxy bindings and all associated resources.
o If the Status field indicates (Global Revocation NOT Authorized), * If the Status field indicates (Global Revocation NOT
the mobile access gateway is not authorized to participate in a Authorized), the mobile access gateway is not authorized to
Per-Peer Global Revocation. The mobile access gateway SHOULD NOT participate in a Per-Peer Global Revocation. The mobile access
retry sending a Binding Revocation Indication with the Global (G) gateway SHOULD NOT retry sending a Binding Revocation
bit set and the Revocation Trigger field value is set to "Per-Peer Indication with the Global (G) bit set and the Revocation
Policy" to the same local mobility agent. The mobile access Trigger field value set to "Per-Peer Policy" to the same local
gateway should raise an alarm or log an event to indicate this mobility agent. The mobile access gateway should raise an
rejection. alarm or log an event to indicate this rejection.
10. Mobile Node Operation 10. Mobile Node Operation
10.1. Receiving Binding Revocation Indication 10.1. Receiving Binding Revocation Indication
Upon receiving a packet carrying a Binding Revocation Indication, the Upon receiving a packet carrying a Binding Revocation Indication, the
mobile node MUST validate the packet according to Section 6.2 and the mobile node MUST validate the packet according to Section 6.2 and the
following tests: following tests:
o The mobile node MUST verify that the IP address in the Type 2 o The mobile node MUST verify that the IP address in the Type 2
skipping to change at page 41, line 29 skipping to change at page 41, line 23
described under Security Considerations in [RFC3775] and [RFC5213]. described under Security Considerations in [RFC3775] and [RFC5213].
The Proxy Mobile IPv6 [RFC5213] requires the local mobility anchor to The Proxy Mobile IPv6 [RFC5213] requires the local mobility anchor to
restrict the creation and manipulation of proxy bindings to restrict the creation and manipulation of proxy bindings to
specifically authorized mobile access gateways. Therefore, the specifically authorized mobile access gateways. Therefore, the
mobile access gateway which is authorized to create or manipulate the mobile access gateway which is authorized to create or manipulate the
mobile node proxy BCE is also authorized to revoke such mobile node mobile node proxy BCE is also authorized to revoke such mobile node
registration by sending a de-registration with lifetime of zero. registration by sending a de-registration with lifetime of zero.
However, since bulk termination using Binding Revocation Indication However, since bulk termination using Binding Revocation Indication
with the Global (G) bit set and the Revocation Trigger field set to with the Global (G) bit set and the Revocation Trigger field set to
"Per-Peer Policy" impact all mobility sessions that are registered "Per-Peer Policy" impacts all mobility sessions that are registered
with the mobile access gateway and its local mobility anchor peer, with the mobile access gateway and its local mobility anchor peer,
the local mobility anchor MUST be locally configurable to authorize the local mobility anchor MUST be locally configurable to authorize
such specific functionality. Additional mechanisms, such as a policy such specific functionality. Additional mechanisms, such as a policy
store or Authentication, Authorization, and Accounting (AAA) may be store or Authentication, Authorization, and Accounting (AAA) may be
employed, but these are outside the scope of this specification. employed, but these are outside the scope of this specification.
14. Acknowledgements 14. Acknowledgements
The authors would like to thank Ryuji Wakikawa, Bruno Mongazon- The authors would like to thank Ryuji Wakikawa, Bruno Mongazon-
Cazavet, Domagoj Premec, Arnaud Ebalard, Patrick Stupar, Vijay Cazavet, Domagoj Premec, Arnaud Ebalard, Patrick Stupar, Vijay
 End of changes. 44 change blocks. 
121 lines changed or deleted 130 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/