wdiff draft-ietf-dmm-hnprenum-02.txt draft-ietf-dmm-hnprenum-03.txt

DMM Working Group Z. Yan
Internet-Draft CNNIC
Intended status: Standards Track J. Lee
Expires: November 21, 2016 January 2, 2017 Sangmyung University
X. Lee
CNNIC
May 20,
July 1, 2016

Home Network Prefix Renumbering in PMIPv6
draft-ietf-dmm-hnprenum-02
draft-ietf-dmm-hnprenum-03

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 and the MN configures its Home Address (HoA) configuration. with the HNP.
During the movement of the MN, this prefix remains unchanged and in this way
it is unnecessary for the MN HNP is remained unchanged to reconfigure its HoA and reconnect the keep
ongoing communications. communications associated with the HoA. However, the current
PMIPv6 specification does not specify related operations to support the MN to timely
receive and use a new HNP when the allocated an HNP changes.
renumbering is happened. In this
draft, document, a solution to support the
HNP renumbering is proposed, as an update of the PMIPv6
specification.

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 [RFC2119]

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 November 21, 2016. January 2, 2017.

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. Usage scenarios Scenarios . . . . . . . . . . . . . . . . . . . . . . . 2
3. PMIPv6 extensions Extensions . . . . . . . . . . . . . . . . . . . . . . 3
4. Session connectivity Connectivity . . . . . . . . . . . . . . . . . . . . 5
5. Message format Format . . . . . . . . . . . . . . . . . . . . . . . 5 6
6. Other issues Issues . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security considerations Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 6 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 8

1. Introduction

Network managers currently prefer Provider Independent (PI)
addressing for IPv6 to attempt to minimize the need for future
possible renumbering. However, a widespread use of PI addresses may
cause Border Gateway Protocol (BGP) scaling problems. It is thus
desirable to develop tools and practices that may make IPv6 renumbering a
simpler process to reduce demand for IPv6 PI space [RFC6879]. In
this draft, document, we aim to solve the HNP renumbering problem when the
HNP in PMIPv6 [RFC5213] is not the type of PI.

2. Usage scenarios Scenarios

There are a number of reasons why the HNP renumbering support in
PMIPv6 is useful and a few some scenarios are identified below:

o Scenario 1: the HNP set used by a PMIPv6 service provider is
assigned with the HNP
set from the (uplink) by a different Internet Service Provider (ISP), and then
the HNP renumbering may happen if the PMIPv6 service provider
switches to a different ISP.

o Scenario 2: multiple Local Mobility Anchors (LMAs) may be deployed
by the same PMIPv6 service provider, and then each LMA may serve
for a specific HNP set. In this case, the HNP of an MN may change
if the current serving LMA switches to another LMA but without
inheriting the assigned HNP set [RFC6463].

o Scenario 3: the PMIPv6 HNP renumbering may be caused by the re-
building of the network architecture as the companies split,
merge, grow, relocate relocate, or reorganize. For example, the PMIPv6
service provider may reorganize its network topology.

In the scenario 1, we assume that only the HNP is renumbered while
the serving LMA remains unchanged and this is the basic scenario of
considered in this document. In the scenario 2 and scenario 3, more
complex results may be caused, for example, the HNP renumbering may
happen due to the switchover of a serving LMA.

In the Mobile IPv6 (MIPv6) protocol, when the a home network prefix
changes (may also be caused by the above reasons),
changes, the Home Agent (HA) will actively notify the new prefix to the
its MN and then the renumbering of the HoA Home Network Address (HoA) can
be well supported [RFC6275]. While in In the basic PMIPv6, the PMIPv6 binding
is triggered by the a Mobile Access Gateway (MAG), which detected detects the
attachment of the MN. When the HNP
renumbering happens, a A scheme is also needed for the LMA to
immediately initiate the PMIPv6 binding state refreshment. refreshment during the
HNP renumbering process. Although this issue is also discussed mentioned in
Section 6.12 of [RFC5213], the related solution has not been
specified.

3. PMIPv6 extensions Extensions

When the HNP renumbering happens in PMIPv6, the LMA has to notify the a
new HNP to the an MAG and then the MAG has to announce the new HNP to the
attached MN accordingly. Also, the LMA and the MAG must update the
routing states for the prefixes. HNP and the related addresses. To support
this procedure, [RFC7077] can be adopted which specifies asynchronously an
asynchronous update from the LMA to the MAG about the specific session
parameters. This document considers the following two cases:

(1) HNP is renumbered in under 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 |
+-----+ +-----+ +-----+
| | |
| | Allocate new HNP
| | |
| |<------------- UPN ---|
| | |
| Update routing state | |
| | |
|<-----RA/DHCP --------| |
| | |
HoA Configuration
Address configuration | |
| | |
| Update binding&routing states |
| | |
| |--- UNA UPA ------------->|
| | |
| | Update routing state binding&routing states
| | |

Figure 1: Signaling call flow of the HNP renumbering

o When the a PMIPv6 service provider renumbers the HNP set in under the
same LMA, the serving LMA will initiate the HNP renumbering
operation. The LMA allocates a new HNP for the related MN.

o The LMA sends the Update Notification (UPN) message to the MAG to
update the HNP information. If the Dynamic Host Configuration
Protocol (DHCP) is used in PMIPv6 to allocate the HoA, address, the new HNP
should be also notified to the DHCP infrastructure.

o After Once the MAG receives this UPN message, it recognizes that the
related MN has a the new HNP. Then the MAG should notify the MN
about the new HNP with a Router Advertisement (RA) message or
allocate a new address within the new HNP with through a DHCP message.
procedure.

o When After the MN obtains the new HNP information, information through the RA message,
it deletes the old HoA and configures a new HoA with the newly
allocated HNP.

o The When the new HNP is announced or the new address is configured to
the MN successfully, the MAG updates the related binding and
routing states. Then the MAG sends back the Update Notification
Acknowledgement (UNA) (UPA) message to the LMA for the notification of
successful update of the HNP, related binding state, and routing
state. Then the LMA updates the routing and binding information
corresponding to the MN to replace the old HNP with the new one.

(2) HNP renumbering caused by the LMA switchover

Because

Since 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 initiates the re- registration to
the new LMA as specified in [RFC5213]. When the HNP renumbering is
caused in this case, the new HNP information will be is sent by the LMA
during the new binding procedure. Accordingly, the MAG will withdraw withdraws the
old HNP information of the MN and advise announces the new HNP to the MN as like the 3rd Step in Section 3(1).
case of the HNP is renumbered under the same LMA.

4. Session connectivity Connectivity

The 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.

(1) Soft-mode

The LMA will temporarily maintain the state of the old HNP during the
HNP renumbering (after the UNA UPA reception) in order to redirect the
packets to the MN before the MN reconnects the ongoing session and
notifies its new HoA to the Correspondent Node (CN). This mode is
aiming to reduce the packet loss during the HNP renumbering but the
binding state and routing entry corresponding to the old HNP should be marked for
example as transient binding [RFC6058]. This temporary binding
should only be used for the downwards packet transmission and the LMA
should not broadcast stop broadcasting the routing information about the old HNP if it
the old HNP 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 simple. In this mode,
the LMA will delete deletes the binding state of the old HNP after it receives
the UNA UPA message from the MAG and the LMA will silently discard discards the
packets destined to the old HNP.

5. Message format 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
Option [RFC5213] containing the new HNP and the Mobile Node
Identifier option Option [RFC4283] carrying Identifier identifier of MN are contained
as Mobility Options of UPN. The order of HNP Option and Mobile Node
Identifier Option in the UPN message is not mandated in this draft.

(2) UPA message

The MAG sends this message in order to acknowledge that it has
received an UPN message with the (A) flag set and to indicate the
status after processing the message. When the MAG did not
successfully renumber the HNP which is required in the UPN message,
the Status Code of 128 is set in the UPA message and the following
operation of LMA is PMIPv6 service provider specific.

(3) RA Message

When the RA message is used by the MAG to advise the new HNP, two
Prefix Information options Options are contained in the RA message [RFC4861].
In the first Prefix Information option, Option, the old HNP is carried but
both the related Valid Lifetime and Preferred Lifetime are set to 0.
In the second Prefix Information option, Option, the new HNP is carried with
the Valid Lifetime and Preferred Lifetime set to larger than 0.

(3)

(4) DHCP Message

When the DHCP is used in PMIPv6 to configure the HoA addresses for the
MN, a new IPv6 HoA is address(es) (e.g., HoA) will be generated based on the
new HNP. Trigged by the UPN
message, the MAG will request the new HoA from the DHCP server first HNP and then the MAG updates the allocated HoA to the MN through the related DHCP
server-initiated configuration exchange procedure is also triggered by the
reception of UPN message [RFC3315].

6. Other issues Issues

In order to maintain the reachability of the MN, the Domain Name
System (DNS) resource record corresponding to this MN may need to be
updated when the HNP of MN changes [RFC3007]. However, this is out
beyond the scope of this draft. document.

7. Security considerations Considerations

The protection of UPN and UPA messages in this document follows
[RFC5213] and [RFC7077]. This extension causes no further security
problem. The security
considerations in [RFC5213] and [RFC7077] are enough for the basic
operation of this draft.

8. IANA Considerations

This document presents no IANA considerations.

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
<http://www.rfc-editor.org/info/rfc3007>.

[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.

[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, DOI 10.17487/RFC4283, November 2005,
<http://www.rfc-editor.org/info/rfc4283>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.

[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008,
<http://www.rfc-editor.org/info/rfc5213>.

[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <http://www.rfc-editor.org/info/rfc6275>.

[RFC6463] Korhonen, J., Ed., Gundavelli, S., Yokota, H., and X. Cui,
"Runtime Local Mobility Anchor (LMA) Assignment Support
for Proxy Mobile IPv6", RFC 6463, DOI 10.17487/RFC6463,
February 2012, <http://www.rfc-editor.org/info/rfc6463>.

[RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and
J. Korhonen, "Update Notifications for Proxy Mobile IPv6",
RFC 7077, DOI 10.17487/RFC7077, November 2013,
<http://www.rfc-editor.org/info/rfc7077>.

9.2. Informative References

[RFC6058] Liebsch, M., Ed., Muhanna, A., and O. Blume, "Transient
Binding for Proxy Mobile IPv6", RFC 6058,
DOI 10.17487/RFC6058, March 2011,
<http://www.rfc-editor.org/info/rfc6058>.

[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations, and
Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013,
<http://www.rfc-editor.org/info/rfc6879>.

Authors' Addresses

Zhiwei Yan
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing 100190
China

EMail: yan@cnnic.cn

Jong-Hyouk Lee
Sangmyung University
31, Sangmyeongdae-gil, Dongnam-gu
Cheonan 31066
Republic of Korea

EMail: jonghyouk@smu.ac.kr

Xiaodong Lee
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing 100190
China

EMail: xl@cnnic.cn