Prefix Delegation for Proxy Mobile IPv6
draft-ietf-netext-pd-pmip-06
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7148.
|
|
|---|---|---|---|
| Authors | Xingyue Zhou , Jouni Korhonen , Carl Williams , Sri Gundavelli , Carlos J. Bernardos | ||
| Last updated | 2013-02-25 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | Basavaraj Patil | ||
| IESG | IESG state | Became RFC 7148 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-netext-pd-pmip-06
Netext WG X. Zhou
Internet-Draft ZTE Corporation
Intended status: Standards Track J. Korhonen
Expires: August 29, 2013 Nokia Siemens Networks
C. Williams
Consultant
S. Gundavelli
Cisco
CJ. Bernardos
UC3M
February 25, 2013
Prefix Delegation for Proxy Mobile IPv6
draft-ietf-netext-pd-pmip-06
Abstract
Proxy Mobile IPv6 enables IP mobility for a host without requiring
its participation in any mobility signaling, being the network
responsible for managing IP mobility on behalf of the host. However,
Proxy Mobile IPv6 does not support assigning a prefix to a router and
managing its IP mobility. This document specifies an extension to
Proxy Mobile IPv6 protocol for supporting network mobility using
DHCPv6-based Prefix Delegation.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 29, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhou, et al. Expires August 29, 2013 [Page 1]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Convention and Terminology . . . . . . . . . . . . . . . . . . 4
3. Message formats . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Delegated Mobile Network Prefix Option . . . . . . . . . . 5
4. DHCPv6 Prefix Delegation Support for Proxy Mobile IPv6 . . . . 7
4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Network Mobility Service . . . . . . . . . . . . . . . . . 8
4.3. Binding association with the delegated prefix . . . . . . 8
4.3.1. Delegating Router Co-located with Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 8
4.3.2. Deletion of the Delegated Prefix in Proxy Mobile
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Delegating Router Co-located with the Local Mobility
Anchor . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4.1. Mobile Router initiated prefix delegation in PMIPv6 . 11
4.4.2. Refreshing the Delegated Prefix in Proxy Mobile
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4.3. Deletion of the Delegated Prefix in Proxy Mobile
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 14
5.1. Extension to Binding Update List Entry Data Structure . . 14
5.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Handover . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 16
6.1. Extension to Binding Cache Entry Data Structure . . . . . 16
6.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Zhou, et al. Expires August 29, 2013 [Page 2]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
1. Introduction
Proxy Mobile IPv6 [RFC5213] enables network-based mobility management
support for an IP host without requiring its participation in any IP
mobility signaling. The mobility elements in the network allow the
IP host to obtain an IPv4 address and/or a set of IPv6 prefix and be
able to obtain IP mobility support for those IP addresses. However,
this network-based mobility management support is specific to an IP
host and currently there is no such network-based mobility management
support for a mobile router with a cluster of IP hosts behind it.
This specification defines extensions to Proxy Mobile IPv6 protocol
for allowing a mobile router to be able to obtain one or more
delegated IPv4/IPv6 prefixes for its inside networks using DHCP
Prefix Delegation extensions [RFC3633]. The mobility entities in the
network will provide network-based mobility management support for
these delegated prefixes just as how that is supported for Home
Network prefixes.
Zhou, et al. Expires August 29, 2013 [Page 3]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
2. Convention and Terminology
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 [RFC2119].
All the mobility related terms used in this document are to be
interpreted as defined in Mobile IPv6 (MIPv6) [RFC6275], Proxy Mobile
IPv6 specifications [RFC5213], [RFC5844], DHCPv6-PD for NEMO
[RFC6276], DHCPv6-PD [RFC3633] Subnet Allocation Option for DHCPv4
[RFC6656] and Mobility Related Terminology [RFC3753]. This document
also provides a context-specific explanation to the following terms
used in this document.
Mobile Router (MR)
Throughout this document, the term mobile router is used to refer
to an IP router whose mobility is managed by the network while
being attached to a Proxy Mobile IPv6 domain. The mobile router
is not required to participate in any IP mobility related
signaling for achieving mobility for an IPv4/IPv6 prefix that is
obtained in that Proxy Mobile IPv6 domain.
Delegated Mobile Network Prefix (DMNP)
The DMNP is an IPv4 or an IPv6 prefix delegated to a mobile router
and advertised in the mobile network. More than one Delegated
Mobile Network Prefix could be assigned to a mobile router. The
DMNP is topologically anchored on the local mobility anchor.
While used by the mobile router, the mobile access gateway and
local mobility anchor provide mobility service to the mobile
router for the DMNP(s).
Zhou, et al. Expires August 29, 2013 [Page 4]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
3. Message formats
This section defines extensions to Proxy Mobile IPv6 [RFC5213]
protocol messages.
3.1. Delegated Mobile Network Prefix Option
A new Delegated Mobile Network Prefix option is defined for use with
the Proxy Binding Update and Proxy Binding Acknowledgment messages
exchanged between a local mobility anchor and a mobile access
gateway. This option is used for exchanging the mobile router's
IPv4/IPv6 delegated mobile network prefix information. There can be
multiple Delegated Mobile Network Prefix options present in the
message.
The Delegated Mobile Network Prefix option has an alignment
requirement of 8n+2. Its format is as follows:
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 |K| Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key Identifier (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
. .
+ IPv4 or IPv6 Delegated Mobile Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
To be assigned by IANA.
Length
8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields.
Key present (K)
Zhou, et al. Expires August 29, 2013 [Page 5]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
If the Key Present bit is set to 1, then it indicates that the GRE
Key Identifier field includes a valide GRE Key. Otherwise, the
value of the GRE Key Identifier field MUST be ignored by the
receiver.
Reserved
This field is unused for now. The value MUST be initialized to 0
by the sender and MUST be ignored by the receiver.
Prefix Length
8-bit unsigned integer indicating the prefix length of the prefix
contained in the option.
Generic Routing Encapsulation (GRE) key tag
A four-byte optional field containing the GRE key tag as specified
in [RFC2890]. If the Key Present flag is set to 0, this field
MUST be initialized to 0 by the sender and MUST be ignored by the
receiver. This option MAY be used by the LMA to provide
differentiated service to different clients attached to the same
mobile router.
The MAG includes the GRE key in the Proxy Binding Update and the
LMA uses that key to mark the downlink mobile network traffic from
the LMA to the MAG.
The LMA includes the GRE key in the Proxy Binding Acknowledgment
and the MAG uses that key to mark the uplink mobile network
traffic from the MAG to the LMA.
Delegated Mobile Network Prefix
Contains a mobile router's 4-byte IPv4 or a 16-byte IPv6 Delegated
Mobile Network Prefix.
Zhou, et al. Expires August 29, 2013 [Page 6]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
4. DHCPv6 Prefix Delegation Support for Proxy Mobile IPv6
4.1. Assumptions
This specification extends Proxy Mobile IPv6 (PMIPv6) to delegate a
mobile network IPv4/IPv6 prefix to a mobile router (MR) for
supporting network mobility. The specification assumes that a mobile
router is an IPv4/IPv6 router without any capability for mobility
management.
The mobile router after its attachment to the network obtains an IPv6
address from its home network prefix (HNP) on its egress interface
facing the MAG. This is as specified in [RFC5213] and [RFC5844].
Subsequently, the DHCPv6-PD procedures get activated for obtaining
the delegated IPv6/IPv4 prefixes for its ingress networks.
The mobile router using the DHCP Prefix Delegation approaches
specified in [RFC3633] and [RFC6656] will obtain the delegated IPv4/
IPv6 prefix from the network. The mobile router forwards outgoing
packets from its mobile network to the mobile access gateway (MAG),
and the MAG delivers the incoming packets to the mobile network
through the MR.
The mobile router must have obtained an IPv6 address from its home
network prefix (HNP) before initiating DHCPv6-PD procedures for
obtaining delegated IPv4 or IPv6 prefixes for its ingress networks.
This IPv6 address is on the interface attached to the MN-MAG access
link as specified in [RFC3633].
The MR (acting as a RR) SHOULD support Prefix Exclude Option for
DHCPv6-PD as described in [RFC6603]. It essentially allows the home
network prefix on the MN-MAG link and the delegated prefix can be
part of the same aggregated block. This simplies address pool
management aspects
This specification supports the following two configuration modes:
1. The delegating router (DR) function, as specified in [RFC3633],
is co-located with the MAG. The DHCP requesting router (RR)
functionality is enabled on the mobile router.
2. The delegating router (DR) function, as specified in [RFC3633],
is co-located with the LMA. A DHCPv6 Relay Agent (DRA) function,
as specified in [RFC3633], is co-located on the mobile access
gateway. The DHCP requesting router (RR), as specified in
[RFC3633] functionality is enabled on the mobile router.
Zhou, et al. Expires August 29, 2013 [Page 7]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
4.2. Network Mobility Service
The network mobility service of a mobile router is indicated by the
policy profile defined in [RFC5213]. During the mobile router's
initial attachment procedure, the mobile access gateway MUST identify
the mobile router and SHOULD acquire the policy profile to determine
whether the network mobility service is offered to the mobile router.
If the network mobility service needs to be offered to the mobile
router, the mobile access gateway MUST set the Mobile Router Flag (R)
when sending the Proxy Binding Update (PBU) message to the local
mobility anchor.
4.3. Binding association with the delegated prefix
4.3.1. Delegating Router Co-located with Mobile Access Gateway
+-----+ +-----+ + ----+
| MR | | MAG | | LMA |
|(RR) | | (DR)| | |
+-----+ +-----+ +-----+
1) |-- MN Attach -----| |
| |<-------- PBU/PBA ------->|
| | |
| |o========================o|
2) | | PMIPv6 tunnel |
| |o========================o|
3) |-- Solicit ------>| |
| for delegated | |
| prefix | |
| | |
4) | |----------PBU------------>|
| | |
5) | |<---------PBA (DMNP)------|
| | |
- -<---+ |
6) |<- Advertise -----| | |
| | | |
7) |-- Request ------>| Optional |
| | | |
- -<---+ |
8) |<-- Reply (DMNP) -| |
| | |
| | |
Figure 1: Prefix Delegation in PMIPv6 when DR co-located with MAG
The steps required to complete the delegation of IPv6 prefix(es) to a
mobile router that is provided with network mobility service are the
Zhou, et al. Expires August 29, 2013 [Page 8]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
following (see Figure 1):
1. MAG after detecting the mobile node's attachment to the access
link initiates the signaling with the LMA.
2. The PMIPv6 tunnel is set up between the MAG and the LMA as
described in [RFC5213]. This requires the MAG to send a regular
PBU to the LMA to register the location of the mobile router and
set-up the bi-directional tunnel. The LMA binds the allocated
home network prefix (HNP) to the Proxy-CoA of the mobile router
(i.e., the address of the mobile access gateway where the MR is
attached to). It is possible that the delegated prefix(es) may
have been assigned to the MAG by the LMA during this procedure of
PMIPv6 tunnel establishment. That is the MAG may include one (or
more) Delegated Mobile Network Prefix (DMNP) mobility options
which MUST be set to the unspecified IPv6 address "::" in the PBU
to request the delegated prefix(es). The LMA assigns a new set
of DMNP(s) in PBA message.
3. The mobile router, acting as a "Requesting Router" as described
in [RFC3633], sends a DHCPv6 SOLICIT message including one or
more IA_PD option(s) to the mobile access gateway (which has a
"DHCPv6 Server" function) to acquire the delegated prefix(es).
4. Upon receiving the DHCPv6 SOLICIT message, the mobile access
gateway sends a proxy binding update (PBU) message to the local
mobility anchor, including one (or more) Delegated Mobile Network
Prefix (DMNP) mobility options. All the considerations from
Section 5.3.1 of [RFC5213] MUST be applied on the encapsulated
Proxy Binding Update message. If the mobile access gateway does
not know the delegated prefix(es), then the delegated mobile
network prefix in the DMNP option(s) MUST be set to the
unspecified IPv6 address "::", or an IPv4 address of 0.0.0.0 with
the prefix length of 0. The local mobility anchor either assigns
the MR a new set of delegated IPv4/IPv6 prefix(es) or returns the
existing one(s) that are associated with that mobility session.
5. On reception of the proxy binding update, the local mobility
anchor returns the assigned prefix(es) in the DMNP option(s)
conveyed in a proxy binding acknowledgment (PBA) message sent to
the mobile access gateway, unless the prefix(es) included in the
PBU was the IPv6 unspecified address "::". The assigned
prefix(es) MUST be the same one(s) which will be assigned via
DHCPv6PD in step 6. The prefix(es) MUST be added to the
delegated prefix(es) in the local mobility anchor binding cache
which is extended as described in Section 6.1. The LMA must set
up forwarding for the delegated prefixes as reachable through the
PMIPv6 tunnel.
Zhou, et al. Expires August 29, 2013 [Page 9]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
6. The delegating router function on the MAG sends the delegated
prefix(es) in one or more IA_PD(s) which were received in the PBA
message in step 5 to the mobile router inside the DHCPv6
ADVERTISE message.
7. The mobile router sends the DHCPv6 REQUEST message with the IA_PD
option(s) received from previous message to the DR function on
the mobile access gateway.
Note: steps 6 to 7 are not present if DHCPv6 Rapid Commit is
used.
8. The DR function on the mobile access gateway responds to the
REQUEST from the mobile router with a DHCPv6 REPLY message. The
MAG sets up the forwarding for the delegated prefixes. The
delegated prefixes are reachable over the MN-MAG interface with
the MR's link-local address, or home address as the next-hop
destination.
4.3.2. Deletion of the Delegated Prefix in Proxy Mobile IPv6
If the lifetime of the delegated prefix (included in the IA_PD Prefix
Option carried by the DHCPv6 Reply message) is set to zero, the
mobile access gateway (which is acting as "Delegating Router") MUST
send a proxy binding update message to remove the selective binding
for that delegated mobile network prefix. If the request is for
remove the delegeted mobile network prefix only, the proxy binding
update message with the lifetime value of (0) MUST NOT include either
IPv6 Home Network Prefix option [RFC5213] or IPv4 Home Address
Request option [RFC5844].
4.4. Delegating Router Co-located with the Local Mobility Anchor
Zhou, et al. Expires August 29, 2013 [Page 10]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
4.4.1. Mobile Router initiated prefix delegation in PMIPv6
+-----+ +-----+ + ----+
| MR | | MAG | | LMA |
|(RR) | |(DRA)| |(DR) |
+-----+ +-----+ +-----+
1) |-- MN Attach -----| |
| |<------ PBU/PBA --------->|
| | |
| |o========================o|
2) | | PMIPv6 tunnel |
| |o========================o|
3) |-- Solicit ------>| |
| for delegated | |
4) | prefix |----------PBU------------>|
| | |
5) | |<---------PBA (DMNP)------|
| | |
6) | |--- Solicit ------------->|
- - - <---+
7) | |<-- Advertise ------------| |
| | | |
8) |<- Advertise -----| | |
| | | Optional
9) |-- Request ------>| | |
| | | |
10) | |--- Request ------------->| |
- - - <---+
11) | |<-- Reply (DMNP) ---------|
| | |
12) |<-- Reply (DMNP) -| |
| | |
Figure 2: Prefix Delegation in PMIPv6 when DR co-located with LMA
The steps required to complete the delegation of IPv6 prefix(es) to a
mobile router that is provided with network mobility service are the
following (see Figure 2):
1. MAG after detecting the mobile node's attachment to the access
link initiates the signaling with the LMA.
2. The PMIPv6 tunnel is set up between the MAG and the LMA as
described in [RFC5213]. This requires the MAG to send a regular
PBU to the LMA to register the location of the mobile router and
set-up the bi-directional tunnel. The LMA binds the allocated
home network prefix (HNP) to the Proxy-CoA of the mobile router
(i.e., the address of the mobile access gateway where the MR is
Zhou, et al. Expires August 29, 2013 [Page 11]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
attached to).
3. The mobile router, acting as a "Requesting Router" as described
in [RFC3633], sends a DHCPv6 SOLICIT message including one or
more IA_PD option(s) to the mobile access gateway (which has a
"DHCPv6 Relay Agent" function) to acquire the delegated
prefix(es).
4. Upon receiving the DHCPv6 SOLICIT message, the mobile access
gateway sends a proxy binding update (PBU) message to the local
mobility anchor, including one (or more) Delegated Mobile
Network Prefix (DMNP) mobility options. All the considerations
from Section 5.3.1 of [RFC5213] MUST be applied on the
encapsulated Proxy Binding Update message. If the mobile access
gateway does not know the delegated prefix(es), then the
delegated mobile network prefix in the DMNP option(s) MUST be
set to the unspecified IPv6 address "::", or an IPv4 address of
0.0.0.0 with the prefix length of 0. The local mobility anchor
either assigns the MR a new set of delegated IPv4/IPv6
prefix(es) or returns the existing one(s) that are associated
with that mobility session.
5. On reception of the proxy binding update, the local mobility
anchor returns the assigned prefix(es) in the DMNP option(s)
conveyed in a proxy binding acknowledgment (PBA) message sent to
the mobile access gateway, unless the prefix(es) included in the
PBU was the IPv6 unspecified address "::". The assigned
prefix(es) MUST be the same one(s) which will be assigned via
DHCPv6PD in step 6. The prefix(es) MUST be added to the
delegated prefix(es) in the local mobility anchor binding cache
which is extended as described in Section 6.1. The LMA must set
up forwarding for the delegated prefixes as reachable through
the PMIPv6 tunnel.
6. The DHCPv6 Relay Agent function on the mobile access gateway
relays the DHCPv6 SOLICIT message to the delegating router (as
described in [RFC3633] ). The delegating router inserts one or
more IA_PD option(s) including the delegated prefix(es) in the
reply message.
Note: steps 6 to 9 are not present if DHCPv6 Rapid Commit is
used.
7. The delegating router sends the delegated prefix(es) in one or
more IA_PD(s) to the mobile access gateway (acting as "DHCPv6
Relay Agent") inside the DHCPv6 ADVERTISE message.
Zhou, et al. Expires August 29, 2013 [Page 12]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
8. The mobile access gateway relays the DHCPv6 ADVERTISE message to
the mobile router.
9. The mobile router sends the DHCPv6 REQUEST message with the
IA_PD option(s) received from previous message to the mobile
access gateway (which is acting as "DHCPv6 Relay Agent").
10. The DRA function on the mobile access gateway relays the DHCPv6
REQUEST message to the DR.
11. The DR function on the local mobility anchor responds to the
REQUEST from the mobile access gateway with a DHCPv6 REPLY
message.
12. The RR function on the mobile router receives one or more IA_PD
prefix(es) in the DHCPv6 REPLY message sent by the mobile access
gateway. The MAG sets up the forwarding for the delegated
prefixes. The delegated prefixes are reachable over the MN-MAG
interface with the MR's link-local address, or home address as
the next-hop destination.
4.4.2. Refreshing the Delegated Prefix in Proxy Mobile IPv6
When the mobile router sends DHCPv6 Renew messages to extend the
lifetime of the delegated prefix, these messages are also intercepted
by the mobile access gateway (acting as "DHCPv6 Relay Agent") and are
relayed to the local mobility anchor (which is acting as "Delegating
Router").
4.4.3. Deletion of the Delegated Prefix in Proxy Mobile IPv6
If the lifetime of the delegated prefix (included in the IA_PD Prefix
Option carried by the DHCPv6 Reply message) is set to zero, the
mobile access gateway (which is acting as "DHCPv6 Relay Agent") MUST
send a proxy binding update message to remove the selective binding
for that delegated mobile network prefix. If the request is for
remove the delegeted mobile network prefix only, the proxy binding
update message with the lifetime value of (0) MUST NOT include either
IPv6 Home Network Prefix option [RFC5213] or IPv4 Home Address
Request option [RFC5844].
Zhou, et al. Expires August 29, 2013 [Page 13]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
5. Mobile Access Gateway Operation
5.1. Extension to Binding Update List Entry Data Structure
In order to support this specification, the conceptual Binding Update
List Entry (BULE) data structure needs to be extended with a new
prefix information field. This field is used to store the delegated
IPv4/IPv6 mobile network prefix assigned to the mobile router, which
is included in the proxy binding acknowledgment.
5.2. Forwarding
Forwarding packets sent to the MR's delegated mobile network prefix:
o On receiving a packet from the bi-directional tunnel established
with the local mobility anchor, the mobile access gateway MUST
first decapsulate the packet (removing the outer header) and then
use the destination address of the (inner) packet to forward it on
the interface through which the destination delegated mobile
network prefix is reachable.
Forwarding packets sent by the mobile router:
o On receiving packets from a mobile router connected to one access
link, the mobile access gateway MUST ensure that there is an
established binding for the mobile router and the local mobility
anchor for the source delegated mobile network prefix before
tunneling the packet to the MR's local mobility anchor.
Other considerations from Section 6.10.5 of [RFC5213] also apply
here.
5.3. Handover
When the mobile router moves from the previously attached mobile
access gateway to the target MAG, the newly attached mobile access
gateway MAY know the delegated mobile network prefix(es) which were
assigned to the mobile router during the previous attachment. It is
out of scope of this specification how the new mobile access gateway
could obtain the previously assigned delegated mobile network
prefix(es) (e.g., from some network element such as the previous
MAG). After moving to the new MAG, a proxy binding update message
including the assigned delegated mobile network prefix(es) (if
available) MUST be sent by the MAG to the LMA. The local mobility
anchor MUST check the delegated mobile network prefix(es) included in
the PBU message and return the same assigned delegated mobile network
prefix(es) in the proxy binding acknowledgment message. If the
previously assigned mobile network prefix(es) are not known by new
Zhou, et al. Expires August 29, 2013 [Page 14]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
MAG, the mobile network prefix(es) MUST be set to unspecified address
"::" and the prefix length MUST be set to 0 in the proxy binding
update message sent by the new mobile access gateway to the local
mobility anchor. In this case, the local mobility anchor MUST return
the same previously assigned mobile network prefix(es) in proxy
binding acknowledgment message.
Zhou, et al. Expires August 29, 2013 [Page 15]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
6. Local Mobility Anchor Operation
6.1. Extension to Binding Cache Entry Data Structure
In order to support this specification, the conceptual Binding Cache
Entry (BCE) data structure needs to be extended with a new prefix
information field. This field is used to store the IPv4/IPv6
delegated mobile network prefix(es) assigned to the mobile router and
included in the proxy binding update (as described in Section 4.2).
6.2. Forwarding
Intercepting packets sent to the MR's delegated mobile network
prefix:
o When the local mobility anchor is serving the mobile router, it
MUST be able to receive/intercept packets destined to the network
behind the mobile router. In order to receive these packets, the
local mobility anchor MUST be the topological anchor of the MR's
delegated mobile network prefix(es).
Forwarding packets to the mobile router:
o On receiving a packet from a correspondent node with the
destination address matching the MR's delegated mobile network
prefix(es), the local mobility anchor MUST forward the packet
through the bi-directional tunnel set up with the mobile router.
Other considerations from Section 5.6.2 of [RFC5213] also apply here.
Zhou, et al. Expires August 29, 2013 [Page 16]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
7. Security Considerations
This document describes extensions to the Proxy Mobile IPv6 protocol
for supporting network mobility using DHCPv6-based Prefix Delegation.
The security considerations for DHCPv6 described in the "Security
Considerations" section of the DHCPv6 base specification [RFC3315],
the "Security Considerations" of the DHCPv6 Prefix Delegation
specification [RFC3633], and the security considerations from the
base Proxy Mobile IPv6 [RFC5213] apply when using the extensions
defined in this document.
The use of DHCPv6, as described in this document, requires message
integrity protection and source authentication. The IPsec security
mechanism mandated by Proxy Mobile IPv6 [RFC5213] MUST be used to
secure the DHCPv6 signaling between the mobile access gateway and the
local mobility anchor. In the following, we describe the Security
Policy Database (SPD) and Security Association Database (SAD) entries
necessary to protect the DHCPv6 signaling. We use the same format
used by [RFC4877]. The SPD and SAD entries are only example
configurations. A particular mobile access gateway implementation
and a local mobility anchor implementation could configure different
SPD and SAD entries as long as they provide the required security of
the DHCPv6 signaling messages.
For the examples described in this document, a mobile access gateway
with address "mag_address_1", and a local mobility anchor with
address "lma_address_1" are assumed.
mobile access gateway SPD-S:
- IF local_address = mag_address_1 &
remote_address = lma_address_1 & proto = UDP &
local_port = any & remote_port = DHCP
Then use SA1 (OUT) and SA2 (IN)
mobile access gateway SAD:
- SA1(OUT, spi_a, lma_address_1, ESP, TRANSPORT):
local_address = mag_address_1 &
remote_address = lma_address_1 &
proto = UDP & remote_port = DHCP
- SA2(IN, spi_b, mag_address_1, ESP, TRANSPORT):
local_address = lma_address_1 &
remote_address = mag_address_1 &
proto = UDP & local_port = DHCP
local mobility anchor SPD-S:
- IF local_address = lma_address_1 &
remote_address = mag_address_1 & proto = UDP &
local_port = DHCP & remote_port = any
Zhou, et al. Expires August 29, 2013 [Page 17]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
Then use SA2 (OUT) and SA1 (IN)
local mobility anchor SAD:
- SA2(OUT, spi_b, mag_address_1, ESP, TRANSPORT):
local_address = lma_address_1 &
remote_address = mag_address_1 &
proto = UDP & local_port = DHCP
- SA1(IN, spi_a, lma_address_1, ESP, TRANSPORT):
local_address = mag_address_1 &
remote_address = lma_address_1 &
proto = UDP & remote_port = DHCP
Zhou, et al. Expires August 29, 2013 [Page 18]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
8. IANA Considerations
This document requires the following IANA action.
o Action-1: This specification defines a new Mobility Header option,
Delegated Mobile Network Prefix option. This mobility option is
described in Section 3.1. 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 [RFC6275].
Zhou, et al. Expires August 29, 2013 [Page 19]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
9. Acknowledgments
The work of Carlos J. Bernardos has also been partially supported by
the European Community's Seventh Framework Programme (FP7-ICT-2009-5)
under grant agreement n. 258053 (MEDIEVAL project) and by the
Ministry of Science and Innovation of Spain under the QUARTET project
(TIN2009-13992-C02-01).
Zhou, et al. Expires August 29, 2013 [Page 20]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6276] Droms, R., Thubert, P., Dupont, F., Haddad, W., and C.
Bernardos, "DHCPv6 Prefix Delegation for Network Mobility
(NEMO)", RFC 6276, July 2011.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012.
10.2. Informative References
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
Zhou, et al. Expires August 29, 2013 [Page 21]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
[RFC6656] Johnson, R., Kinnear, K., and M. Stapp, "Description of
Cisco Systems' Subnet Allocation Option for DHCPv4",
RFC 6656, July 2012.
Zhou, et al. Expires August 29, 2013 [Page 22]
Internet-Draft Prefix Delegation Support for PMIPv6 February 2013
Authors' Addresses
Xingyue Zhou
ZTE Corporation
No.50 Software Avenue, Yuhuatai District
Nanjing
China
Phone: +86-25-8801-4634
Email: zhou.xingyue@zte.com.cn
Jouni Korhonen
Nokia Siemens Networks
Linnoitustie 6
Espoo FIN-02600
Finland
Email: jouni.nospam@gmail.com
Carl Williams
Consultant
San Jose, CA
USA
Email: carlw@mcsr-labs.org
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Zhou, et al. Expires August 29, 2013 [Page 23]