One document matched: draft-ietf-netext-bulk-re-registration-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-netext-bulk-re-registration-00"
ipr="trust200902">
<front>
<title abbrev="PMIPv6 Bulk Re-registration">Bulk Re-registration for Proxy
Mobile IPv6</title>
<author role="editor" fullname="Fuad Abinader" initials="F." surname="Abinader">
<organization>Instituto Nokia de Tecnologia</organization>
<address>
<postal>
<street>Av. Torquato Tapajos, 7200 - Km. 12 - Col Terra Nova</street>
<city>Manaus</city>
<region>AM</region>
<code>69048-660</code>
<country>BRAZIL</country>
</postal>
<email>fuad.junior@indt.org.br</email>
</address>
</author>
<author fullname="Sri Gundavelli" initials="S." surname="Gundavelli">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>sgundave@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Kent Leung" initials="K." surname="Leung">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>kleung@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
<organization>Ericsson</organization>
<address>
<postal>
<street>8400 Decarie Blvd.</street>
<city>Town of Mount Royal</city>
<region>QC</region>
<code></code>
<country>Canada</country>
</postal>
<phone>+1 514 345 7900 x42871</phone>
<facsimile></facsimile>
<email>suresh.krishnan@ericsson.com</email>
<uri></uri>
</address>
</author>
<author fullname="Domagoj Premec" initials="D." surname="Premec">
<organization>Unaffiliated</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region></region>
<country></country>
</postal>
<email>domagoj.premec@gmail.com</email>
</address>
</author>
<date year="2010" />
<area>Internet Area</area>
<workgroup>Netext Working Group</workgroup>
<keyword>Proxy Mobile IPv6</keyword>
<keyword>PMIPv6</keyword>
<keyword>bulk registrations</keyword>
<keyword>MN group ID</keyword>
<abstract>
<t>Proxy Mobile IPv6 specification requires the Mobile Access Gateway
(MAG) to send a separate Proxy Binding Update (PBU) message to the Local
Mobility Agent (LMA) for each mobile node (MN) to renew the MN’s
mobility binding. This document defines a mechanism by which a MAG can
update the mobility bindings of multiple MNs attached to it with a
single PBU message to the serving LMA. This document also specifies a
new mobility option that can be used by the mobility entities in a Proxy
Mobile IPv6 domain for carrying the group affiliation of a mobile node
in any of the mobility signaling messages.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>The Proxy Mobile IPv6 base specification <xref
target="RFC5213"></xref> uses the mobile node identifier in the mobility
signaling messages for identifying the mobile node. However, the
signaling messages lack the capability to identify a set of mobile nodes
which have a common characteristic. A group identifier associated with a
mobile node enables the ability to perform protocol operation on a set
of mobile nodes via a single transaction. The group identifier provides
a more optimal mechanism for protocol operation which would otherwise
require multiple atomic transactions on a per mobile node basis.
Following are some of the use-cases where such identifier can be
used.</t>
<t><list style="symbols">
<t>In a blade architecture system running the local mobility anchor
service, all the mobile node sessions anchored on a given card can
be part of one single group. When there is a failure on a specific
card, the local mobility anchor can initiate the revocation
signaling to the mobile access gateway by sending a single
revocation request carrying the group identifier.</t>
<t>For periodic re-registrations, the mobile access gateway may send
a single re-registration message for each of the mobile nodes'
groups and perform re-registrations for all the mobile node's that
are part of that group.</t>
<t>The mobile access gateway or the local mobility anchor in a proxy
mobile IPv6 domain may choose to revoke the registration of mobile
node associated with a specific realm. In such cases the mobile
access gateway or the local mobility anchor can perform the binding
revocation signaling using the group ID associated with a specific
set of mobile nodes.</t>
</list>The remainder of this document defines a new mobility option,
named Mobile Node Group Identifier option, that can be used by a local
mobility anchor and a mobile access gateway for exchanging the mobile
node's group identifier as well as its application for bulk periodic
re-registrations.</t>
</section>
<section title="Terminology">
<t>General mobility related terminology is defined in <xref
target="RFC3775"></xref>. Additional PMIPv6 specific terminology can be
found in <xref target="RFC5213"></xref>.</t>
<t><list style="hanging">
<t hangText="PMIPv6 domain"><vspace blankLines="0" />Network
providing the network based IP mobility service as defined in <xref
target="RFC5213"></xref>.</t>
<t hangText="PMIPv6"><vspace blankLines="0" />Proxy Mobile IPv6
protocol specified in <xref target="RFC5213"></xref>.</t>
<t hangText="Bulk re-registration"><vspace
blankLines="0" />PBU/PBAck message exchange where the bulk
re-registration flag (B) is set to 1</t>
<t hangText="Bulk re-registration set"><vspace blankLines="0" />a
set of MNs identified by the Mobile Node Group ID option to which the
bulk re-registration operation applies.</t>
</list></t>
</section>
<section anchor="overview" title="Bulk Re-registration Overview">
<section title="Motivation for bulk re-registration">
<t>In a PMIPv6 domain a single LMA serves multiple MAGs and the
capacity of the LMA in terms of the number of attached MNs can be
quite large. It can be expected that LMA capacity in managed networks
may easily exceed hundreds of thousands or more attached MNs.</t>
<t>The following simple formula gives an estimate of the average
number of re-registration transactions per second as a function of the
number of registered MNs and the binding lifetime period:</t>
<t>transactions/sec = (number of registered MNs) / (binding
lifetime*4)</t>
<t>For 50.000 MNs and the binding lifetime of half an hour this gives:
50000 MNs / 1800 sec = 27,7 transactions/sec</t>
<t>Based on the above formula it is apparent that the default
re-registration process where the MAG sends a separate message for
each MN is inefficient or suboptimal. These re-registration messages
consume significant network resources both in terms of processing
power at the LMA and MAG and network bandwidth.</t>
<t>This document proposes an optimization of the re-registration
process by which the signaling load for re-registration can be reduced
to a single transaction per MAG, irrespective of the number of
attached MNs.</t>
<t>According to this proposal a MAG adds a MN to a set of MNs
re-registered in a bulk mode by setting the bulk re-registration bit
(B) in the PBU message. The PBU message sent in response contains the
Mobile Node Group Identifier mobility option which is defined later in
this document. In the context of bulk re-registrations the Mobile Node
Group Identifier is an opaque identifier that is allocated by the LMA
and which uniquely identifies the bulk set to which the MN was
added.</t>
<t>A MAG requests a bulk re-registration for a set of MNs by sending a
single PBU message which includes a Mobile Node Group Identifier
mobility option and the LMA extends the binding lifetime of MNs that
are members of that group. By using this method, the MAG and LMA
accomplish the re-registration of MNs attached to a MAG in a single
transaction. The number of re-registration transactions at the LMA
becomes independent of the number of attached MNs; instead it is
dependent only on the number of MAGs (i.e. bulk re-registration
sets).</t>
<t>In addition to minimizing the signaling overhead associated with
the lifetime extension of the mobility bindings, the MAG and LMA may
use a single timer per bulk re-registration set to monitor the binding
lifetime of all the member MNs instead of an individual timer per
MN.</t>
</section>
<section title="Bulk re-registration operation">
<t>The bulk re-registration mechanism allows the MAG and the LMA to
extend the binding lifetime for a number of MNs with a single
transaction. The MAG and LMA maintain a set of MNs that can be
re-registered in bulk mode. Such set is called a bulk re-registration
set and is a subset of the MNs attached to a MAG. There can be
multiple bulk re-registration sets for a given MAG-LMA pair; however,
there can be only one MAG and one LMA associated with a given bulk
re-registration set.</t>
<t> Initially
the bulk re-registration set is empty. MAG requests to add individual
MNs to the bulk set by sending a regular PBU message that identifies
an individual MN and additionally the bulk registration flag in the
message is set to 1. Based on the received bulk re-registration bit
the LMA adds the MN to the bulk re-registration set and responds with
the PBAck message with the bulk registration flag (B) set to 1. The
LMA identifies the bulk re-registration set to which the MN was added
by including the Mobile Node Group ID option in the PBAck message.</t>
<t>Once there is a non-empty bulk re-registration set, MAG can request
to extend the binding lifetime for all MNs that are part of the bulk
re-registration set by sending a PBU message with the bulk (B) bit set
and by including the Mobile Node Group ID identify the bulk
re-registration set. Such PBU message lacks any options that identify
an individual MN. In particular, the MAG omits both the MN ID (Mobile
Node Identifier) and the HNP (Home Network Prefix) options. From that,
dual operations that try to operate (either adding or removing MNs)
over the current bulk re-registration set while at the same time
performing the bulk re-registration operation itself are not possible,
and must be done with the use of two separate PBU messages.</t>
<t>There may be different triggers that cause the MAG to request a
bulk re-registration. Typically the trigger is the binding lifetime
expiry of a MN that is a member of a bulk re-registration set. There
could be other triggers as well, but they may be implementation or
domain specific and outside the scope of this specification.</t>
<t>When the MAG requests the MN to be added to the bulk
re-registration set, the LMA includes the Mobile Node Group Identifier
mobility option in the PBAck message. The Mobile Node Group Identifier
is an opaque identifier allocated by the LMA that uniquely identifies
the bulk set at the LMA to which the MN was added. The MAG associates
the MN with the Mobile Node Group Identifier received in the
PBAck.</t>
<t>The MAG includes the Mobile Node Group Identifier mobility option
set to the value previously received from the LMA to request the bulk
re-registration for the MNs that are part of this particular bulk
re-registration set. The MAG may include multiple instances of the
Mobile Node Group Identifier option in the PBU message to request
lifetime refreshment for several bulk sets in a single message.</t>
<t>The LMA extends the mobility binding of all MNs that are members of
indicated bulk re-registration sets and responds with PBAck message
echoing the received Mobile Node Group Identifier mobility
options.</t>
<t>A MAG may remove a MN from a bulk re-registration set by sending a
regular PBU message identifying the MN to be removed and with the bulk
re-registration flag set to 0.</t>
<t>When requested to add a MN to the bulk re-registration set, the LMA
may reject the request. In this case the LMA processes the PBU message
as if the bulk re-registration flag was not set and responds with
PBAck message where the bulk re-registration flag is set to 0.</t>
<t>Dual operations that try to extend binding time to some bulk
re-registration sets while at the same time terminating bindings with
other bulk re-registration sets (e.g. by setting zero lifetime) in the
same PBU message are not possible; as a consequence, these must be
performed with two separate PBU messages.</t>
<t></t>
</section>
</section>
<section title="Message formats">
<t>This section introduces extensions to PBU and PBAck messages used in
this specification.</t>
<section title="Proxy Binding Update message" anchor="pbu_message">
<figure anchor="PBU-format">
<artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|B| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>A Proxy Binding Update message is defined in the <xref
target="RFC5213"></xref>. A new flag (B) is defined for the Binding
Update message, as seen on <xref target="PBU-format"/>.</t>
<t>Bulk Registration Flag (B)</t>
<t>If the bulk registration flag (B) is set to 1, then the PBU message
is a request to add the MN to the bulk re-registration set. If the
bulk registration flag (B) is set to 0 and if the MN is found to be a
member of the bulk re-registration set, then the MN is removed from
the bulk re-registration set.</t>
<t>Mobility Options</t>
<t>For descriptions of the mobility options, refer to <xref
target="RFC5213"></xref>. When the PBU message is sent to refresh
bindings in a bulk mode, the message MUST contain at least one Mobile
Node Group Identifier mobility option and does not contain the MN-ID
and the HNP mobility options.</t>
</section>
<section title="Proxy Binding Acknowledgment message" anchor="pback_message">
<figure anchor="PBAck-message"
title="Proxy Binding Acknowledgment message">
<artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|B| Res. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>A Proxy Binding Acknowledgment message is defined in the <xref
target="RFC5213"></xref>. A new flag (B) is defined for the Binding
Acknowledgment message, as seen on <xref target="PBAck-message"/>.</t>
<t>Bulk Registration Flag (B)</t>
<t>A new flag (B) is included in the Binding Acknowledgment message to
indicate to the MAG that the MN was successfully added to the bulk
re-registration set. The flag MUST NOT be set to the value of 1 if it
was not set to 1 in the corresponding PBU message.</t>
<t>Mobility Options</t>
<t>For descriptions of these options, refer to <xref
target="RFC5213"></xref>. When the bulk registration flag is set to 1
in the PBU message, then the PBAck message MUST also contain the
Mobile Node Group Identifier mobility option. When the Mobile Node
Group Identifier mobility option(s) were included in the PBU message,
the PBAck message echoes back the Mobile Node Group Identifier options
from the PBU message.</t>
</section>
<section title="Mobile Node Group Identifier Option " anchor="mnid_option">
<t>A new option, Mobile Node Group Identifier option is defined for
using it in Proxy Binding Update and Proxy Binding Acknowledgement
messages exchanged between a local mobility anchor and mobile access
gateway. This option is used for carrying the mobile node's group
identifier.</t>
<t>The alignment requirement for this option is 4n.</t>
<figure anchor="GID_option"
title="Mobile Node Group Identifier Option">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Type"><vspace blankLines="0" /><IANA></t>
<t hangText="Length"><vspace blankLines="0" />8-bit unsigned
integer indicating the length in octets of the option, excluding
the type and length fields. The value for this field MUST be set
to 6.</t>
<t hangText="Sub-type"><vspace blankLines="0" />Identifies the
specific group type. This number space will be managed by the
IANA.</t>
<t hangText="Mobile Node Group Identifier ">A 32-bit field
containing the mobile node's group identifier.</t>
</list>The Mobile Node's Group Identifier option reflects the group
affiliation that is local to the specific LMA-MAG pair. The specific
value for the Mobile Node group Identifier is always determined by the
LMA on the PBAck message, and must be used by the MAG on all future
bulk re-registration procedures for that bulk re-registration set.</t>
</section>
</section>
<section title="MAG Operation">
<t>The conceptual Binding Update List entry data structure maintained by
the MAG, described in Section 6.1 of <xref target="RFC5213"></xref>,
MUST be extended to store the mobile node's group identifier.</t>
<t>Bulk re-registration operations are optional to PMIPv6 <xref
target="RFC5213"/>, so the Mobile Node Group Identifier option MAY be used
in the PBU message sent by the MAG to the LMA only when a bulk re-registration
operation (refresh/termination) is intended. When this option is included, the
identifier value in the option MUST be set to the mobile node's group
identifier that was assigned previously by the LMA.</t>
<t>When a new MN attaches to a MAG, the MAG registers the MN with the
LMA by sending the PBU message formatted as described in <xref
target="RFC5213"></xref>. Additionally, the MAG MAY set the bulk
registration flag (B) in the PBU message to 1 to request the LMA to add
the MN to the bulk registration set. The decision to request the bulk
re-registration mode for a MN is a matter of local policy at the MAG and
is outside the scope of this specification.</t>
<t>The MAG SHALL maintain a separate bulk re-registration sets for each
LMA.</t>
<t>The MAG SHALL add the MN to its bulk re-registration set when it
receives a PBAck message with the bulk registration bit set to 1 and if
the corresponding PBU message was requesting the LMA to add the MN to
the bulk re-registration set. The MAG SHALL associate the MN being
registered with the Mobile Node Group Identifier received in the PBAck
message.</t>
<t>When the binding lifetime of any MN contained in the bulk
re-registration set is about to expire, the MAG SHALL request the bulk
re-registration by sending the PBU message containing the Mobile Node
Group Identifier mobility option. The length of the Mobile Node Group
Identifier option may be 0 in which case the MAG is requesting a
refreshment of the binding lifetime for all MN attached to that MAG that
were registered with the B flag set. Alternatively, the MAG MAY include
one or more Mobile Node Group Identifier options containing the values
that were indicated by the LMA in the PBAck messages when the MN was
added to the bulk set. In this case the MAG asks for refreshment of
specific bulk sets indicated by the Mobile Node Group Identifier
options. The MAG SHALL NOT include the MN ID and the HNP options in the
PBU message requesting bulk refreshment.</t>
<t>The MAG MAY trigger a bulk re-registration at any time. The policy
and exact conditions for these additional triggers are outside of scope
of this specification.</t>
<t>When the MAG receives a PBAck message indicating success and which
echoes the Mobile Node Group Identifier options that were included in
the corresponding PBU message, the MAG SHALL update the binding lifetime
of all MNs belonging to the indicated groups to the lifetime value
contained in the PBAck message. If in the case of bulk re-registration
the PBAck message repeatedly indicates an error, the MAG SHALL fall back
to individual re-registration mode.</t>
<t>Instead of maintaining one timer per MN, the MAG MAY start a single
timer per bulk registration set to oversee the binding lifetime of all
MNs that are members of that bulk registration set.</t>
<t>If the MAG sets the bulk re-registration bit to 1 in a PBU message
but the bulk registration bit (B) is set to 0 in a PBAck message, the
MAG SHALL process the PBAck message as per <xref
target="RFC5213"></xref>. In addition, the MAG SHALL infer that the LMA
does not support bulk re-registration procedure. The MAG SHALL switch to
regular, per-MN re-registration mode as described in <xref
target="RFC5213"></xref>. The MAG MAY retry the bulk re-registration
procedure after sufficient time has elapsed from the previous
unsuccessful bulk re-registration. This amount of time SHOULD be
configurable at the MAG.</t>
</section>
<section title="LMA operation">
<t>The conceptual Binding Cache entry data structure maintained by the
LMA, described in Section 5.1 of <xref target="RFC5213"></xref>, MUST be
extended to store the mobile node's group identifier.</t>
<t>The Mobile Node Group Identifier option MAY be used in the PBAck
message sent by the LMA to the MAG. When this option is included, the
identifier value in the option MUST be set to the mobile node's group
identifier, local to the local mobility anchor.</t>
<t>When the LMA receives a PBU message with a bulk registration bit (B)
set to 1, the LMA SHALL first process the PBU message as per <xref
target="RFC5213"></xref>. Upon successful processing of the message, the
LMA SHALL perform additional processing of the PBU message as described
further below for bulk mode re-registrations.</t>
<t>If the bulk re-registration flag in the PBU message is set to 1, the
LMA MAY add the MN(s) indicated in the PBU to the set of MNs
re-registered in a bulk mode, subject to the local policy. The decision
whether to enable bulk re-registration mode is a matter of local policy
at the LMA and is outside the scope of this specification.</t>
<t>If the LMA decides to accept the bulk re-registration mode for the
MN, it SHALL add the MN to a bulk re-registration set. The LMA SHALL
maintain distinct bulk re-registrations set for each MAG and there could
be several such sets per single MAG.</t>
<t>Upon adding the MN to the bulk re-registration set, the LMA SHALL
respond with the PBAck message containing the bulk registration bit set
to 1. The LMA SHALL include the Mobile Node Group Identifier option in
the PBAck message. The Mobile Node Group Identifier is allocated by the
LMA and identifies the particular bulk set to which the MN is
assigned.</t>
<t>The PBU message without the MN ID and HNP options but including the
Mobile Node Group Identifier mobility option is a valid message and
indicates a request for bulk mode re-registration of all MNs that are
members of the indicated bulk re-registration set. There MAY be several
Mobile Node Group Identifier options in the PBU message, in which case
the MAG requests the bulk refreshment of all MNs that are members of the
indicated bulk sets. If the length of the Mobile Node Group Identifier
option is zero, the MAG is requesting a lifetime refreshment of all the
MN attached to the MAG that are members of any bulk set. The LMA SHALL
extend the binding lifetime of all affected MNs attached to the MAG that
sent the bulk PBU.</t>
<t>The LMA SHALL set the binding lifetime of all MNs re-registered in a
bulk mode to expire at the same point in time.</t>
<t>Upon successful processing of bulk mode re-registration request, the
LMA MUST respond with a PBAck message indicating success and echoing the
mobility options received from the PBU. The lifetime in the PBAck
message indicates the time when binding cache entries of affected MNs
will expire.</t>
<t>The LMA MAY reject the request for bulk re-registration. In this case
the LMA MUST NOT update binding cache entries of any MNs and SHALL
respond with PBAck indicating the reason for the rejection in the status
code.</t>
<t>After successfully processing the bulk PBU message, the LMA SHOULD
start a single timer to oversee the binding lifetime of all MNs affected
by this bulk re-registration transaction.</t>
<t>The LMA not supporting this specification ignores the bulk
re-registration bit (B) and the Mobile Node Group Identifier option in a
PBU message and processes the message as per the baseline specification
<xref target="RFC5213"></xref>. In this case the PBAck message sent in
response contains the bulk re-registration bit (B) set to 0.</t>
<t>If the LMA that does not support this specification receives a bulk
PBU message that does not contain any options identifying a particular
MN then the LMA responds with the PBAck message where the status field
contains one of the following error codes:<list>
<t>MISSING_HOME_NETWORK_PREFIX_OPTION</t>
<t>MISSING_MN_IDENTIFIER_OPTION</t>
</list>These error codes are defined in the baseline specification
<xref target="RFC5213"></xref>.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This specification specifies a new flag (B) in the Proxy Binding
Update (PBU) and Proxy Binding Acknowledgement (PBAck) messages of
PMIPv6 <xref target="RFC5213"/>. This flag is defined in sections
<xref target="pbu_message" /> and <xref target="pback_message" />.
IANA is requested to allocate the new flag (B) in the Proxy Binding
Update and Proxy Binging Acknowledgement messages from the <xref
target="RFC5213"/> Proxy Binding Update Flags and the <xref
target="RFC5213"/> proxy Binding Acknowledgment Flags registries.</t>
<t>This specification defines a new Mobility Header option, the Mobile
Node Group Identifier option. This option is described in section <xref
target="GID_option"></xref>. The Type value for this option needs to be
assigned from the same numbering space as allocated for the other
mobility options (as defined in <xref target="RFC3775"></xref>). Also, the
Sub-type field of the Mobile Node Group Identifier option (as defined in
<xref target="mnid_option"/>) must have its own brand-new, unique number
pace allocated and managed by IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The mobile node's identifier is always present in the Proxy Mobile
IPv6 signaling messages and additionally carrying the group identity of
the mobile node introduces similar vulnerabilities. Specifically, it
exposes the group affiliation of the user and may result in compromising
the privacy of the user or the location information.</t>
<t>The Mobile Node Group Identifier option defined in this specification
is for use in Proxy Binding Update and Proxy Binding Acknowledgement
messages. This option is carried like any other mobility header option
as specified in <xref target="RFC3775"></xref> and does not require any
special security considerations.</t>
<t>The bulk re-registration mechanism does not introduce any new
security threat or vulnerability to the PMIPv6 specification.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Jouni Korhonen and Basavaraj Patil for their review and input.</t>
<t>The authors would like to acknowledge the prior discussions on this
topic in netlmm mailing list.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"
type="TXT" />
<format octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML" />
<format octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML" />
</reference>
<reference anchor="RFC3775">
<front>
<title>Mobility Support in IPv6</title>
<author fullname="D. Johnson" initials="D." surname="Johnson">
<organization></organization>
</author>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization></organization>
</author>
<author fullname="J. Arkko" initials="J." surname="Arkko">
<organization></organization>
</author>
<date month="June" year="2004" />
</front>
<seriesInfo name="RFC" value="3775" />
<format octets="393514"
target="ftp://ftp.isi.edu/in-notes/rfc3775.txt" type="TXT" />
</reference>
<reference anchor="RFC5213">
<front>
<title>Proxy Mobile IPv6</title>
<author fullname="S. Gundavelli" initials="S." surname="Gundavelli">
<organization></organization>
</author>
<author fullname="K. Leung" initials="K." surname="Leung">
<organization></organization>
</author>
<author fullname="V. Devarapalli" initials="V."
surname="Devarapalli">
<organization></organization>
</author>
<author fullname="K. Chowdhury" initials="K." surname="Chowdhury">
<organization></organization>
</author>
<author fullname="B. Patil" initials="B." surname="Patil">
<organization></organization>
</author>
<date month="August" year="2008" />
</front>
<seriesInfo name="RFC" value="5213" />
<format octets="226902"
target="ftp://ftp.isi.edu/in-notes/rfc5213.txt" type="TXT" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:59:45 |