Home Network Prefix Renumbering in PMIPv6
draft-ietf-dmm-hnprenum-00

The information below is for an old version of the document
Document Type Active Internet-Draft (dmm WG)
Last updated 2015-12-16
Replaces draft-yan-dmm-hnprenum
Stream IETF
Intended RFC status Proposed Standard
Formats plain text pdf html bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
DMM Working Group                                                 Z. Yan
Internet-Draft                                                     CNNIC
Intended status: Standards Track                                  J. Lee
Expires: June 18, 2016                              Sangmyung University
                                                                  X. Lee
                                                                   CNNIC
                                                       December 17, 2015

               Home Network Prefix Renumbering in PMIPv6
                     draft-ietf-dmm-hnprenum-00.txt

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

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
   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 June 18, 2016.

Yan, et al.               Expires June 18, 2016                 [Page 1]
Internet-Draft           PMIPv6 HNP Renumbering            December 2015

Copyright Notice

   Copyright (c) 2015 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.  Usage scenarios . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  PMIPv6 extensions . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Session connectivity  . . . . . . . . . . . . . . . . . . . .   5
   5.  Message format  . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Other issues  . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Network managers currently prefer Provider Independent (PI)
   addressing for IPv6 to attempt to minimize the need for future
   possible renumbering.  However, 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, we aim to solve the HNP renumbering
   problem when the HNP in PMIPv6 [RFC5213] is not the type of PI.

2.  Usage scenarios

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

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

Yan, et al.               Expires June 18, 2016                 [Page 2]
Internet-Draft           PMIPv6 HNP Renumbering            December 2015

   o  Scenario 2: multiple Local Mobility Anchors (LMAs) may be deployed
Show full document text