PMIPv6 CP-UP Split: Separation of Control and User Plane for Proxy Mobile IPv6
A new Proxy Mobile IPv6 option lets the anchor use one address for signaling and another for user traffic.
Wakikawa, R., Pazhyannur, R., Gundavelli, S., and C. Perkins, "Separation of Control and User Plane for Proxy Mobile IPv6", RFC 7389, DOI 10.17487/RFC7389, October 2014, <https://www.rfc-editor.org/info/rfc7389>.
@misc{rfc7389,
series = {Request for Comments},
number = 7389,
howpublished = {RFC 7389},
publisher = {RFC Editor},
doi = {10.17487/RFC7389},
url = {https://www.rfc-editor.org/info/rfc7389},
author = {R. Wakikawa and R. Pazhyannur and S. Gundavelli and C. Perkins},
title = {{Separation of Control and User Plane for Proxy Mobile IPv6}},
pagetotal = 12,
year = 2014,
month = oct,
} RFC text
Contents
Internet Engineering Task Force (IETF) R. Wakikawa
Request for Comments: 7389 Softbank Mobile
Category: Standards Track R. Pazhyannur
ISSN: 2070-1721 S. Gundavelli
Cisco
C. Perkins
Futurewei Inc.
October 2014
Separation of Control and User Plane for Proxy Mobile IPv6
Abstract
This document specifies a method to split the control plane (CP) and
user plane (UP) for a network infrastructure based on Proxy Mobile
IPv6 (PMIPv6). Existing specifications allow a mobile access gateway
(MAG) to separate its control and user plane using the Alternate
Care-of Address mobility option for IPv6 or Alternate IPv4 Care-of
Address option for IPv4. However, the current specification does not
provide any mechanism allowing the local mobility anchor (LMA) to
perform an analogous functional split. To remedy that shortcoming,
this document specifies a mobility option enabling an LMA to provide
an alternate LMA address to be used for the bidirectional user-plane
traffic between the MAG and LMA. With this new option, an LMA will
be able to use an IP address for its user plane that is different
than the IP address used for the control plane.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7389.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
2. Conventions and Terminology .....................................5
2.1. Conventions ................................................5
2.2. Terminology ................................................5
3. Additional Fields in Conceptual Data Structures .................6
4. LMA User-Plane Address Mobility Option ..........................6
5. Protocol Configuration Variable .................................8
6. IANA Considerations .............................................9
7. Security Considerations .........................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Acknowledgements ..................................................12
Authors' Addresses ................................................12
1. Introduction
A Proxy Mobile IPv6 (PMIPv6) infrastructure comprises two primary
entities: LMA (local mobility anchor) and MAG (mobile access
gateway). The interface between the MAG and LMA consists of the
control plane and user plane. The control plane is responsible for
signaling messages between the MAG and LMA, such as the Proxy Binding
Update (PBU) and Proxy Binding Acknowledgement (PBA) messages to
establish a mobility binding. In addition, the control-plane
components in the MAG and LMA are also responsible for setting up and
tearing down a bidirectional tunnel between the MAG and LMA. The
user plane is used for carrying the mobile node's IP traffic between
the MAG and the LMA over the bidirectional tunnel.
Widely deployed mobility management systems for wireless
communications require separation of IP transport for forwarding
user-plane and control-plane traffic. This separation offers more
flexible deployment options for LMA and MAG entities in Proxy Mobile
IPv6, as described in [MOBILE-SEPARATION]. To meet this requirement
would also require that the control-plane functions of the LMA be
addressable at a different IP address than the IP address assigned
for the user plane. However, PMIPv6 does not currently specify a
mechanism for allowing the LMA to separate the control plane from the
user plane. The LMA is currently required to associate the IP
address of the tunnel source with the target IP address for the
control messages received from the MAG.
The control-plane and user-plane components of a MAG or LMA are
typically co-located in the same physical entity. However, there are
situations where it is desirable to have the control and user plane
of a MAG or LMA in separate physical entities. For example, in a
WLAN (Wireless LAN) network, it may be desirable to have the control-
plane component of the MAG reside on the Access Controller (also
sometimes referred to as Wireless LAN Controller (WLC)) while the
user-plane component of the MAG resides on the WLAN Access Point.
This enables all the control-plane messages to the LMA to be
centralized while the user plane would be distributed across the
multiple Access Points. Similarly, there is a need for either the
control-plane or user-plane component of the LMA to be separated
according to different scaling requirements or, in other cases, the
need to centralize the control plane in one geographical location
while distributing the user-plane component across multiple
locations. For example, as illustrated in Figure 1, the LMA and MAG
could have one control session established for PMIPv6 control
signaling while maintaining separate connectivity via Generic Routing
Encapsulation (GRE) or IP-in-IP tunneling for forwarding user-plane
traffic.
MAG LMA
+--------+ +--------+
+------+ | MAG-CP |--------------| LMA-CP | _----_
| MN | | | PMIPv6 | | _( )_
| |---- +--------+ +--------+ ===( Internet )
+------+ : : (_ _)
+--------+ +--------+ '----'
| MAG-UP |--------------| LMA-UP |
| | GRE/IP-in-IP | |
+--------+ /UDP +--------+
MN: Mobile Node
CP: Control Plane
UP: User Plane
Figure 1: Functional Separation of the Control and User Plane
[RFC6463] and [RFC6275] enable separating the control and user plane
in the MAG. In particular, [RFC6463] defines the Alternate IPv4
Care-of Address option, and [RFC6275] defines an Alternate Care-of
Address option for IPv6. The MAG may provide an Alternate Care-of
Address in the PBU, and if the LMA supports this option, then a
bidirectional tunnel is set up between the LMA address and the MAG's
Alternate Care-of Address. However, these documents do not specify a
corresponding option for the LMA to provide an alternate tunnel
endpoint address to the MAG.
This specification therefore defines a new mobility option that
enables a local mobility anchor to provide an alternate LMA address
to be used for the bidirectional tunnel between the MAG and LMA, as
shown in Figure 1.
The LMA control-plane and the LMA user-plane functions are typically
deployed on the same IP node, and in such a scenario, the interface
between these functions is internal to the implementation.
Deployments may also choose to deploy the LMA control-plane and the
LMA user-plane functions on separate IP nodes. In such deployment
models, there needs to be a protocol interface between these two
functions, but that is outside the scope of this document. Possible
options for such an interface include OpenFlow
[OpenFlow-Spec-v1.4.0], Forwarding and Control Element Separation
(ForCES) [RFC5810], use of routing infrastructure [STATELESS-UPLANE],
and vendor-specific approaches. This specification does not mandate
a specific protocol interface and views this interface as a generic
interface relevant more broadly for many other protocol systems in
addition to Proxy Mobile IPv6. When the LMA control-plane and the
LMA user-plane functions are deployed on separate IP nodes, the
requirement related to user-plane address anchoring (specified in
Section 5.6.2 of [RFC5213] and Section 3.1.3 of [RFC5844]) must be
met by the node hosting the LMA user-plane functionality. The LMA
user-plane node must be a topological anchor point for the IP
address/prefixes allocated to the mobile node.
2. Conventions and Terminology
2.1. Conventions
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 RFC 2119 [RFC2119].
2.2. Terminology
3GPP terms can be found in [RFC6459]. Other mobility-related terms
used in this document are to be interpreted as defined in [RFC5213]
and [RFC5844]. Additionally, this document uses the following terms:
IP-in-IP
IP-within-IP Encapsulation [RFC2473] [RFC4213].
GRE
Generic Routing Encapsulation [RFC1701].
UDP Encapsulation
Encapsulation mode based on UDP transport specified in [RFC5844].
LMA Control-Plane Address (LMA-CPA)
The IP address on the LMA that is used for sending and receiving
control-plane traffic from the MAG.
LMA User-Plane Address (LMA-UPA)
The IP address on the LMA that is used for sending and receiving
user-plane traffic from the MAG.
MAG Control-Plane Address (MAG-CPA)
The IP address on the MAG that is used for sending and receiving
control-plane traffic from the LMA.
MAG User-Plane Address (MAG-UPA)
The IP address on the MAG that is used for sending and receiving
user-plane traffic from the LMA. This address is also referred to
as the Alternate Care-of Address.
3. Additional Fields in Conceptual Data Structures
To support the capability specified in this document, the conceptual
Binding Update List entry data structure maintained by the LMA and
the MAG is extended with the following additional fields:
o The IP address of the LMA that carries user-plane traffic.
o The IP address of the LMA that handles control-plane traffic.
4. LMA User-Plane Address Mobility Option
The LMA User-Plane Address mobility option is a new mobility header
option defined for use with PBU and PBA messages exchanged between
the LMA and the MAG. This option is used for notifying the MAG about
the LMA's user-plane IPv6 or IPv4 address. There can be zero, one,
or two instances of the LMA User-Plane Address mobility option
present in the message. When two instances of the option are
present, one instance of the option must be for IPv4 transport, and
the other instance must be for IPv6 transport.
The LMA User-Plane Address mobility option has an alignment
requirement of 8n+2. Its format is as shown in Figure 2:
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
. .
+ LMA User-Plane Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: LMA User-Plane Address Mobility Option Format
Type
59
Length
An 8-bit, unsigned integer indicating the length of the option in
octets, excluding the Type and Length fields.
Reserved
This field is unused in this specification. The value MUST be set
to zero (0) by the sender and MUST be ignored by the receiver.
LMA User-Plane Address
Contains the 32-bit IPv4 address or the 128-bit IPv6 address of
the LMA user plane. When the LMA User-Plane Address mobility
option is included in a PBU message, this field can be a zero-
length field, or it can have a value of ALL_ZERO, with all bits in
the 32-bit IPv4 address or the 128-bit IPv6 address set to zero.
When including the LMA User-Plane Address mobility option in the PBU,
the MAG must apply the following rules:
o When using IPv4 transport for the user plane, the IP address field
in the option MUST be either a zero-length field or a 4-octet
field with ALL_ZERO value.
o When using IPv6 transport for the user plane, the IP address field
in the option MUST be either a zero-length field or a 16-octet
field with ALL_ZERO value.
When the LMA includes the LMA User-Plane Address mobility option in
the PBA, the IP address field in the option MUST be set to the LMA's
IPv4 or IPv6 address carrying user-plane traffic.
o When using IPv4 transport for the user plane, the IP address field
in the option is the IPv4 address carrying user-plane traffic.
o When using IPv6 transport for the user plane, the IP address field
in the option is the IPv6 address carrying user-plane traffic.
The encapsulation mode that will be chosen for the user plane between
the MAG and the LMA has to based on the considerations specified in
[RFC5213] and [RFC5844].
5. Protocol Configuration Variable
This specification defines the following configuration variable,
which must be configurable (e.g., by the system management) on the
LMA and MAG mobility entities. The configured value for this
protocol variable MUST survive server reboots and service restarts
and MUST be the same for every LMA and MAG in the network domain
supporting PMIPv6.
Domain-wide-LMA-UPA-Support
This variable indicates whether or not all the mobility
entities in the PMIPv6 domain support the LMA User-Plane
Address mobility option.
When this variable on the MAG is set to zero (0), the MAG MUST
indicate whether or not it supports this feature by including
the LMA User-Plane Address mobility option in the PBU. If the
option is not present in the PBU, the LMA SHALL disable this
feature for the mobility session corresponding to the PBU.
Setting this variable to one (1) on the MAG indicates that
there is domain-wide support for this feature and the MAG is
not required to include the LMA User-Plane Address mobility
option in the PBA. In this case, the MAG MAY choose not to
include the LMA User-Plane Address mobility option in the PBU.
When this variable on the LMA is set to zero (0), the LMA MUST
NOT include the LMA User-Plane Address mobility option in the
PBA unless the MAG has indicated support for this feature by
including the LMA User-Plane Address mobility option in the PBU
message.
Setting this variable to one (1) on the LMA indicates that
there is domain-wide support for this feature and the LMA
SHOULD choose to include this LMA User-Plane Address mobility
option in the PBA even if the option is not present in the PBU
message.
On both the LMA and the MAG, the default value for this
variable is zero (0). This implies that the default behavior
of a MAG is to include this option in the PBU, and the default
behavior of an LMA is to include this option in a PBA only if
the option is present in the PBU.
6. IANA Considerations
This specification defines a new mobility header option -- the LMA
User-Plane Address mobility option. The format of this option is
described in Section 4. The Type value 59 for this mobility option
has been allocated by IANA in the "Mobility Options" registry at
<http://www.iana.org/assignments/mobility-parameters>.
7. Security Considerations
The Proxy Mobile IPv6 specification [RFC5213] requires the signaling
messages between the MAG and the LMA to be protected using end-to-end
security association(s) offering integrity and data origin
authentication. The Proxy Mobile IPv6 specification also requires
IPsec [RFC4301] to be a mandatory-to-implement security mechanism.
This document specifies an approach where the control-plane and user-
plane functions of the MAG and LMA are separated and hosted on
different IP nodes. In such deployment models, the nodes hosting
those respective control-plane functions still have to meet the
[RFC5213] security requirement listed above; specifically, the Proxy
Mobile IPv6 signaling messages exchanged between these entities MUST
be protected using end-to-end security association(s) offering
integrity and data origin authentication. Furthermore, IPsec is a
mandatory-to-implement security mechanism for the nodes hosting the
control-plane function of the MAG and LMA. Additional documents may
specify alternative security mechanisms for securing Proxy Mobile
IPv6 signaling messages. The mobility entities in a Proxy Mobile
IPv6 domain can enable a specific security mechanism based on either
(1) static configuration or (2) dynamic negotiation (using any
standard security negotiation protocols).
As per the Proxy Mobile IPv6 specification, the use of IPsec for
protecting the mobile node's user-plane traffic is optional. This
specification keeps the same requirement and therefore requires the
nodes hosting the user-plane functions of the MAG and the LMA to have
IPsec as a mandatory-to-implement security mechanism but make the use
of IPsec optional for user-plane traffic protection.
The LMA User-Plane Address mobility option defined in this
specification is for use in PBU and PBA messages. This option is
carried like any other mobility header option as specified in
[RFC5213]. Therefore, it inherits security guidelines from
[RFC5213].
The IP address of the LMA user plane (the LMA-UPA), provided within
the LMA User-Plane Address mobility option, MUST be a valid address
under the administrative control associated with the LMA functional
block.
If the LMA user-plane and the LMA control-plane functions are hosted
in different entities, any control messages between these two
entities containing the LMA User-Plane Address mobility option MUST
be protected using end-to-end security association(s) offering
integrity and data origin authentication.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005,
<http://www.rfc-editor.org/info/rfc4301>.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008,
<http://www.rfc-editor.org/info/rfc5213>.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010,
<http://www.rfc-editor.org/info/rfc5844>.
8.2. Informative References
[MOBILE-SEPARATION]
Wakikawa, R., Matsushima, S., Patil, B., Chen, B.,
Joachimpillai, D., and H. Deng, "Requirements and use
cases for separating control and user planes in mobile
network architectures", Work in Progress,
draft-wakikawa-req-mobile-cp-separation-00, November 2013.
[OpenFlow-Spec-v1.4.0]
Open Networking Foundation, "OpenFlow Switch
Specification, Version 1.4.0", October 2013.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994,
<http://www.rfc-editor.org/info/rfc1701>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998,
<http://www.rfc-editor.org/info/rfc2473>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005,
<http://www.rfc-editor.org/info/rfc4213>.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
Control Element Separation (ForCES) Protocol
Specification", RFC 5810, March 2010,
<http://www.rfc-editor.org/info/rfc5810>.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011,
<http://www.rfc-editor.org/info/rfc6275>.
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, January 2012,
<http://www.rfc-editor.org/info/rfc6459>.
[RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui,
"Runtime Local Mobility Anchor (LMA) Assignment Support
for Proxy Mobile IPv6", RFC 6463, February 2012,
<http://www.rfc-editor.org/info/rfc6463>.
[STATELESS-UPLANE]
Matsushima, S. and R. Wakikawa, "Stateless user-plane
architecture for virtualized EPC (vEPC)", Work in
Progress, draft-matsushima-stateless-uplane-vepc-03,
July 2014.
Acknowledgements
The authors of this document thank the NetExt Working Group for the
valuable feedback on different versions of this specification. In
particular, the authors want to thank John Kaippallimalil, Sridhar
Bhaskaran, Nirav Salot, Bruno Landais, Brian Carpenter, Pete Resnick,
Stephen Farrell, and Brian Haberman for their valuable comments and
suggestions to improve this specification.
Authors' Addresses
Ryuji Wakikawa
Softbank Mobile
1-9-1, Higashi-Shimbashi, Minato-Ku
Tokyo 105-7322
Japan
EMail: ryuji.wakikawa@gmail.com
Rajesh S. Pazhyannur
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States
EMail: rpazhyan@cisco.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States
EMail: sgundave@cisco.com
Charles E. Perkins
Futurewei Inc.
2330 Central Expressway
Santa Clara, CA 95050
United States
EMail: charliep@computer.org
AI ELI5
On this page
§1Why Split the Control and User Plane
A Proxy Mobile IPv6 (PMIPv6) network has two main entities: the local mobility anchor (LMA) and the mobile access gateway (MAG). Between them runs a control plane, which carries signaling such as the Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA) that set up a mobility binding, and a user plane, which carries the mobile node's IP traffic through a bidirectional tunnel.
The RFC says widely deployed mobility systems for wireless communications need separate IP transport for user-plane and control-plane traffic. It gives examples. In a WLAN, the MAG control plane could sit on the Access Controller while the user plane sits on the access points. An LMA's two planes may also need different scaling, or the control plane may be centralized in one place while the user plane is spread across several.
The problem is that PMIPv6 requires the LMA to tie the tunnel source address to the target address of control messages from the MAG. The LMA therefore could not use a separate address for user traffic.
Sometimes the part that makes the plans and the part that carries the traffic should live in different places. Before this RFC, the anchor could only have one address for both jobs.
§2Terminology and Existing MAG-Side Support
The RFC introduces four address names. The LMA Control-Plane Address (LMA-CPA) is used for control traffic with the MAG, and the LMA User-Plane Address (LMA-UPA) is used for user-plane traffic. The MAG has matching MAG-CPA and MAG-UPA addresses; the MAG-UPA is also called the Alternate Care-of Address.
The MAG side was already covered. RFC 6463 defines the Alternate IPv4 Care-of Address option and RFC 6275 defines an Alternate Care-of Address option for IPv6. A MAG can offer one in its PBU, and if the LMA supports it, the tunnel runs between the LMA address and the MAG's alternate address. No matching option let the LMA offer an alternate tunnel endpoint to the MAG.
For bookkeeping, the Binding Update List entry kept by the LMA and MAG gains two fields: the LMA address that carries user-plane traffic and the LMA address that handles control-plane traffic.
The gateway already had a way to say 'send packages to my other door'. The anchor had no way to say the same thing back, and this RFC fixes that.
§3The LMA User-Plane Address Option
The new LMA User-Plane Address mobility option is used in PBU and PBA messages. A message can carry zero, one or two instances. If there are two, one must be for IPv4 transport and the other for IPv6 transport. The option has an alignment requirement of 8n+2.
Its fields are Type (59), Length (the option length in octets, excluding the Type and Length fields), a Reserved field that the sender MUST set to zero and the receiver MUST ignore, and the LMA User-Plane Address itself, which is a 32-bit IPv4 or 128-bit IPv6 address.
In a PBU, the MAG uses the option only to signal support: the address field MUST be either zero-length or all zeros (4 octets for IPv4, 16 octets for IPv6). In a PBA, the LMA MUST put its real IPv4 or IPv6 user-plane address in the field. The choice of encapsulation for the user plane follows RFC 5213 and RFC 5844.
The MAG sends a blank note saying 'I understand this'. The anchor answers with a note that has the real address of its package door.
§4Deciding Whether the Feature Is Used
The RFC defines a configuration variable, Domain-wide-LMA-UPA-Support, which must be configurable on every LMA and MAG, must survive reboots and restarts, and must be the same for every LMA and MAG in the PMIPv6 domain. Its default is zero on both sides.
With the variable at zero on the MAG, the MAG MUST include the option in its PBU to show it supports the feature; if the option is absent, the LMA SHALL disable the feature for that session. With the variable at zero on the LMA, the LMA MUST NOT include the option in the PBA unless the MAG sent it in the PBU.
Setting the variable to one means the whole domain supports the feature. The MAG MAY then leave the option out of its PBU, and the LMA SHOULD include the option in the PBA even if the PBU lacked it.
By default the two sides check with each other first. If everyone in the network already agrees, they can skip the check.
- PBU + LMA User-Plane Address optionAddress field zero-length or all zeros; signals support.
- PBA + LMA User-Plane Address optionAddress field holds the LMA user-plane address.
§5Deployment Notes
The control-plane and user-plane parts of a MAG or LMA are usually in one physical entity, and then the link between them is internal. They can be put on separate IP nodes, but the protocol between those nodes is outside this RFC. The text lists OpenFlow, ForCES, use of routing infrastructure and vendor-specific approaches as possible options without mandating any.
When the LMA planes are on separate nodes, the node hosting the LMA user plane must meet the address anchoring requirement from RFC 5213 and RFC 5844. It must be a topological anchor point for the IP address or prefixes allocated to the mobile node.
The user-plane tunnel may use GRE, IP-in-IP or UDP encapsulation, as in the RFC's Figure 1.
If the two jobs are done by two different machines, those machines need a way to talk. This RFC does not say how, but the package machine must still be the place where the mobile device's address lives.
§6Security and IANA
PMIPv6 signaling between MAG and LMA must be protected with end-to-end security associations giving integrity and data origin authentication, and IPsec is mandatory to implement. Nodes hosting the control-plane functions must still meet this. For the user plane, the nodes must support IPsec but using it to protect user traffic stays optional, as before.
The LMA-UPA in the option MUST be a valid address under the administrative control of the LMA functional block. If the LMA control and user planes are on different entities, control messages between them that carry the option MUST be protected with integrity and data origin authentication.
IANA allocated Type value 59 for the new option in the Mobility Options registry.
The messages still need a lock and a signature, and the anchor may only hand out addresses it really controls.