--- 1/draft-ietf-dmm-hnprenum-00.txt 2016-05-20 19:15:54.726722941 -0700 +++ 2/draft-ietf-dmm-hnprenum-01.txt 2016-05-20 19:15:54.742723341 -0700 @@ -1,34 +1,34 @@ DMM Working Group Z. Yan Internet-Draft CNNIC Intended status: Standards Track J. Lee -Expires: June 18, 2016 Sangmyung University +Expires: November 21, 2016 Sangmyung University X. Lee CNNIC - December 17, 2015 + May 20, 2016 Home Network Prefix Renumbering in PMIPv6 - draft-ietf-dmm-hnprenum-00.txt + draft-ietf-dmm-hnprenum-01 Abstract In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node (MN) is assigned with a 64-bit Home Network Prefix (HNP) during its initial attachment for the Home Address (HoA) configuration. During 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 - 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 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 - RFC5213. + [RFC5213]. Requirements Language 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. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -37,25 +37,25 @@ 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 June 18, 2016. + This Internet-Draft will expire on November 21, 2016. 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. 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 @@ -112,32 +112,32 @@ due to the switchover of serving LMA. In the Mobile IPv6 (MIPv6) protocol, when the home network prefix 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 renumbering of the HoA can be well supported [RFC6275]. While in the basic PMIPv6, the PMIPv6 binding is triggered by the Mobile Access Gateway (MAG), which detected the attachment of the MN. When the HNP renumbering happens, a scheme is also needed for the LMA to 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. 3. PMIPv6 extensions 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 the MN accordingly. Also, the LMA and the MAG must update the - routing states for the prefixes. To support this procedure, RFC7077 - can be adopted which specifies asynchronously update from the LMA to - the MAG about the session parameters. This document considers the - following two cases: + routing states for the prefixes. To support this procedure, + [RFC7077] can be adopted which specifies asynchronously update from + the LMA to the MAG about the session parameters. This document + considers the following two cases: (1)HNP is renumbered in the same LMA In this case, the LMA remains unchanged as in the scenario 1 and scenario 3. The operation steps are shown in Figure 1. +-----+ +-----+ +-----+ | MN | | MAG | | LMA | +-----+ +-----+ +-----+ | | | @@ -182,21 +182,21 @@ HNP with the new one. (2) HNP renumbering caused by LMA switchover 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. The information of LMA is the basic configuration information of MAG. When the LMA changes, the related profile should be updated by the 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 sent by the LMA during the new binding procedure. Accordingly, 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). 4. Session connectivity HNP renumbering may cause the disconnection of the ongoing communications of the MN. Basically, there are two modes to manage the session connectivity during the HNP renumbering. @@ -213,21 +213,21 @@ binding should only be used for the downwards packet transmission and the LMA should not broadcast the routing information about the old HNP if it is no longer anchored at this LMA. (2)Hard-mode If the HNP renumbering happens with the switchover of the LMA, the 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 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 (1)UPN message In the UPN message sent from the LMA to the MAG, the notification reason is set to 2 (UPDATE-SESSION-PARAMETERS). Besides, the HNP option containing the new HNP and the Mobile Node Identifier option carrying Identifier of MN are contained as Mobility Options of UPN.