draft-ietf-dmm-hnprenum-00.txt   draft-ietf-dmm-hnprenum-01.txt 
DMM Working Group Z. Yan DMM Working Group Z. Yan
Internet-Draft CNNIC Internet-Draft CNNIC
Intended status: Standards Track J. Lee Intended status: Standards Track J. Lee
Expires: June 18, 2016 Sangmyung University Expires: November 21, 2016 Sangmyung University
X. Lee X. Lee
CNNIC CNNIC
December 17, 2015 May 20, 2016
Home Network Prefix Renumbering in PMIPv6 Home Network Prefix Renumbering in PMIPv6
draft-ietf-dmm-hnprenum-00.txt draft-ietf-dmm-hnprenum-01
Abstract Abstract
In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node
(MN) is assigned with a 64-bit Home Network Prefix (HNP) during its (MN) is assigned with a 64-bit Home Network Prefix (HNP) during its
initial attachment for the Home Address (HoA) configuration. During initial attachment for the Home Address (HoA) configuration. During
the movement of the MN, this prefix remains unchanged and in this way the movement of the MN, this prefix remains unchanged and in this way
it is unnecessary for the MN to reconfigure its HoA and reconnect the it is unnecessary for the MN to reconfigure its HoA and reconnect the
ongoing communications. However, the current protocol (RFC5213) does ongoing communications. However, the current protocol [RFC5213] does
not specify related operations to support the MN to timely receive not specify related operations to support the MN to timely receive
and use a new HNP when the allocated HNP changes. In this draft, a and use a new HNP when the allocated HNP changes. In this draft, a
solution to support the HNP renumbering is proposed, as an update of solution to support the HNP renumbering is proposed, as an update of
RFC5213. [RFC5213].
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 18, 2016. This Internet-Draft will expire on November 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 30 skipping to change at page 3, line 30
due to the switchover of serving LMA. due to the switchover of serving LMA.
In the Mobile IPv6 (MIPv6) protocol, when the home network prefix In the Mobile IPv6 (MIPv6) protocol, when the home network prefix
changes (may also be caused by the above reasons), the Home Agent changes (may also be caused by the above reasons), the Home Agent
(HA) will actively notify the new prefix to the MN and then the (HA) will actively notify the new prefix to the MN and then the
renumbering of the HoA can be well supported [RFC6275]. While in the renumbering of the HoA can be well supported [RFC6275]. While in the
basic PMIPv6, the PMIPv6 binding is triggered by the Mobile Access basic PMIPv6, the PMIPv6 binding is triggered by the Mobile Access
Gateway (MAG), which detected the attachment of the MN. When the HNP Gateway (MAG), which detected the attachment of the MN. When the HNP
renumbering happens, a scheme is also needed for the LMA to renumbering happens, a scheme is also needed for the LMA to
immediately initiate the PMIPv6 binding state refreshment. Although immediately initiate the PMIPv6 binding state refreshment. Although
this issue is also discussed in the [RFC5213] (Section 6.12), the this issue is also discussed in Section 6.12 of [RFC5213], the
related solution has not been specified. related solution has not been specified.
3. PMIPv6 extensions 3. PMIPv6 extensions
When the HNP renumbering happens in PMIPv6, the LMA has to notify the When the HNP renumbering happens in PMIPv6, the LMA has to notify the
new HNP to the MAG and then the MAG has to announce the new HNP to new HNP to the MAG and then the MAG has to announce the new HNP to
the MN accordingly. Also, the LMA and the MAG must update the the MN accordingly. Also, the LMA and the MAG must update the
routing states for the prefixes. To support this procedure, RFC7077 routing states for the prefixes. To support this procedure,
can be adopted which specifies asynchronously update from the LMA to [RFC7077] can be adopted which specifies asynchronously update from
the MAG about the session parameters. This document considers the the LMA to the MAG about the session parameters. This document
following two cases: considers the following two cases:
(1)HNP is renumbered in the same LMA (1) HNP is renumbered in the same LMA
In this case, the LMA remains unchanged as in the scenario 1 and In this case, the LMA remains unchanged as in the scenario 1 and
scenario 3. The operation steps are shown in Figure 1. scenario 3. The operation steps are shown in Figure 1.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| MN | | MAG | | LMA | | MN | | MAG | | LMA |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | |
| | Allocate new HNP | | Allocate new HNP
| | | | | |
skipping to change at page 4, line 24 skipping to change at page 4, line 24
| | | | | |
|<-----RA/DHCP --------| | |<-----RA/DHCP --------| |
| | | | | |
HoA Configuration | | HoA Configuration | |
| | | | | |
| |--- UNA ------------->| | |--- UNA ------------->|
| | | | | |
| | Update routing state | | Update routing state
| | | | | |
Figure 1: Signaling call flow of HNP renumbering Figure 1: Signaling call flow of HNP renumbering
o When the PMIPv6 service provider renumbers the HNP set in the same o When the PMIPv6 service provider renumbers the HNP set in the same
LMA, the serving LMA will initiate the HNP renumbering operation. LMA, the serving LMA will initiate the HNP renumbering operation.
The LMA allocates a new HNP for the related MN. The LMA allocates a new HNP for the related MN.
o The LMA sends the Update Notification (UPN) message to the MAG to o The LMA sends the Update Notification (UPN) message to the MAG to
update the HNP information. If the Dynamic Host Configuration update the HNP information. If the Dynamic Host Configuration
Protocol (DHCP) is used in PMIPv6 to allocate the HoA, the new HNP Protocol (DHCP) is used in PMIPv6 to allocate the HoA, the new HNP
should be also notified to the DHCP infrastructure. should be also notified to the DHCP infrastructure.
skipping to change at page 5, line 8 skipping to change at page 5, line 8
HNP with the new one. HNP with the new one.
(2) HNP renumbering caused by LMA switchover (2) HNP renumbering caused by LMA switchover
Because the HNP is assigned by the LMA, the HNP renumbering may be Because the HNP is assigned by the LMA, the HNP renumbering may be
caused by the LMA switchover, as in the scenario 2 and scenario 3. caused by the LMA switchover, as in the scenario 2 and scenario 3.
The information of LMA is the basic configuration information of MAG. The information of LMA is the basic configuration information of MAG.
When the LMA changes, the related profile should be updated by the When the LMA changes, the related profile should be updated by the
service provider. In this way, the MAG will initiate the re- service provider. In this way, the MAG will initiate the re-
registration to the new LMA as specified in RFC5213. When the HNP registration to the new LMA as specified in [RFC5213]. When the HNP
renumbering is caused in this case, the new HNP information will be renumbering is caused in this case, the new HNP information will be
sent by the LMA during the new binding procedure. Accordingly, the sent by the LMA during the new binding procedure. Accordingly, the
MAG will withdraw the old HNP information of the MN and advise the MAG will withdraw the old HNP information of the MN and advise the
new HNP to the MN as the 3rd Step in Section 3(1). new HNP to the MN as the 3rd Step in Section 3(1).
4. Session connectivity 4. Session connectivity
HNP renumbering may cause the disconnection of the ongoing HNP renumbering may cause the disconnection of the ongoing
communications of the MN. Basically, there are two modes to manage communications of the MN. Basically, there are two modes to manage
the session connectivity during the HNP renumbering. the session connectivity during the HNP renumbering.
(1)Soft-mode (1) Soft-mode
The LMA will temporarily maintain the state of the old HNP during the The LMA will temporarily maintain the state of the old HNP during the
HNP renumbering (after the UNA reception) in order to redirect the HNP renumbering (after the UNA reception) in order to redirect the
packets to the MN before the MN reconnects the ongoing session and packets to the MN before the MN reconnects the ongoing session and
notifies its new HoA to the Correspondent Node (CN). This mode is notifies its new HoA to the Correspondent Node (CN). This mode is
aiming to reduce the packet loss during the HNP renumbering but the aiming to reduce the packet loss during the HNP renumbering but the
binding state and routing entry corresponding to the old HNP should binding state and routing entry corresponding to the old HNP should
be marked for example as transient binding [RFC6058]. This temporary be marked for example as transient binding [RFC6058]. This temporary
binding should only be used for the downwards packet transmission and binding should only be used for the downwards packet transmission and
the LMA should not broadcast the routing information about the old the LMA should not broadcast the routing information about the old
HNP if it is no longer anchored at this LMA. HNP if it is no longer anchored at this LMA.
(2)Hard-mode (2) Hard-mode
If the HNP renumbering happens with the switchover of the LMA, the If the HNP renumbering happens with the switchover of the LMA, the
hard-mode is recommended to keep the protocol simple and efficient.In hard-mode is recommended to keep the protocol simple and efficient.In
this mode, the LMA will delete the state of the old HNP after it this mode, the LMA will delete the state of the old HNP after it
receives the UNA message from MAG and the LMA will silently discard receives the UNA message from MAG and the LMA will silently discard
the packets destinated to the old HNP. the packets destined to the old HNP.
5. Message format 5. Message format
(1)UPN message (1) UPN message
In the UPN message sent from the LMA to the MAG, the notification In the UPN message sent from the LMA to the MAG, the notification
reason is set to 2 (UPDATE-SESSION-PARAMETERS). Besides, the HNP reason is set to 2 (UPDATE-SESSION-PARAMETERS). Besides, the HNP
option containing the new HNP and the Mobile Node Identifier option option containing the new HNP and the Mobile Node Identifier option
carrying Identifier of MN are contained as Mobility Options of UPN. carrying Identifier of MN are contained as Mobility Options of UPN.
(2)RA Message (2) RA Message
When the RA message is used by the MAG to advise the new HNP, two When the RA message is used by the MAG to advise the new HNP, two
Prefix Information options are contained in the RA message [RFC2461]. Prefix Information options are contained in the RA message [RFC2461].
In the first Prefix Information option, the old HNP is carried but In the first Prefix Information option, the old HNP is carried but
both the related Valid Lifetime and Preferred Lifetime are set to 0. both the related Valid Lifetime and Preferred Lifetime are set to 0.
In the second Prefix Information option, the new HNP is carried with In the second Prefix Information option, the new HNP is carried with
the Valid Lifetime and Preferred Lifetime set to larger than 0. the Valid Lifetime and Preferred Lifetime set to larger than 0.
(3)DHCP Message (3) DHCP Message
When the DHCP is used in PMIPv6 to configure the HoA for the MN, a When the DHCP is used in PMIPv6 to configure the HoA for the MN, a
new IPv6 HoA is generated based on the new HNP. Trigged by the UPN new IPv6 HoA is generated based on the new HNP. Trigged by the UPN
message, the MAG will request the new HoA from the DHCP server first message, the MAG will request the new HoA from the DHCP server first
and then the MAG updates the allocated HoA to the MN through the DHCP and then the MAG updates the allocated HoA to the MN through the DHCP
server-initiated configuration exchange [RFC3315]. server-initiated configuration exchange [RFC3315].
6. Other issues 6. Other issues
In order to maintain the reachability of the MN, the Domain Name In order to maintain the reachability of the MN, the Domain Name
 End of changes. 18 change blocks. 
21 lines changed or deleted 21 lines changed or added

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