draft-ietf-dmm-hnprenum-07.txt   rfc8191.txt 
DMM Working Group Z. Yan Internet Engineering Task Force (IETF) Z. Yan
Internet-Draft CNNIC Request for Comments: 8191 CNNIC
Intended status: Standards Track J. Lee Category: Standards Track J. Lee
Expires: September 14, 2017 Sangmyung University ISSN: 2070-1721 Sangmyung University
X. Lee X. Lee
CNNIC CNNIC
March 13, 2017 August 2017
Home Network Prefix Renumbering in PMIPv6 Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6)
draft-ietf-dmm-hnprenum-07
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 Home Network Prefix (HNP) during its initial (MN) is assigned with a Home Network Prefix (HNP) during its initial
attachment and the MN configures its Home Address (HoA) with the HNP. attachment, and the MN configures its Home Address (HoA) with the
During the movement of the MN, the HNP remains unchanged to keep HNP. During the movement of the MN, the HNP remains unchanged to
ongoing communications associated with the HoA. However, the current keep ongoing communications associated with the HoA. However, the
PMIPv6 specification does not specify related operations when an HNP current PMIPv6 specification does not specify related operations when
renumbering has happened (e.g. due to change of service provider, HNP renumbering has occurred (e.g., due to change of service provider
change of site topology, etc.). In this document, a solution to or site topology, etc.). In this document, a solution to support HNP
support the HNP renumbering is proposed, as an optional extension of renumbering is proposed, as an optional extension of the PMIPv6
the PMIPv6 specification. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on September 14, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8191.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. HNP Renumbering Procedure . . . . . . . . . . . . . . . . . . 3 2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3
4. Session Connectivity . . . . . . . . . . . . . . . . . . . . 5 3. HNP Renumbering Procedure . . . . . . . . . . . . . . . . . . 4
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5 4. Session Connectivity . . . . . . . . . . . . . . . . . . . . 6
6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Network managers currently prefer Provider Independent (PI) At the time of writing, network managers prefer Provider-Independent
addressing for IPv6 to attempt to minimize the need for future (PI) addressing for IPv6 to attempt to minimize the need for future
possible renumbering. However, a widespread use of PI addresses will possible renumbering. However, a widespread use of PI addresses will
cause Border Gateway Protocol (BGP) scaling problems [RFC7010]. It cause Border Gateway Protocol (BGP) scaling problems [RFC7010]. It
is thus desirable to develop tools and practices that make IPv6 is thus desirable to develop tools and practices that make IPv6
renumbering a simpler process to reduce demand for IPv6 PI space renumbering a simpler process to reduce demand for IPv6 PI space
[RFC6879]. In this document, we aim to solve the HNP renumbering [RFC6879]. In this document, we aim to support HNP renumbering when
problem when the HNP in PMIPv6 [RFC5213] is a PI prefix. the HNP in PMIPv6 [RFC5213] is not a PI prefix.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Usage Scenarios 2. Usage Scenarios
There are a number of reasons why the HNP renumbering support in There are a number of reasons why HNP renumbering support in PMIPv6
PMIPv6 is useful and some scenarios are identified below: is useful, and some scenarios are identified below:
o Scenario 1: the HNP set used by a PMIPv6 service provider is Scenario 1: the HNP set used by a PMIPv6 service provider is
assigned by a different Internet Service Provider (ISP), and then assigned by a different Internet Service Provider (ISP),
the HNP renumbering MAY happen if the PMIPv6 service provider and then HNP renumbering MAY occur if the PMIPv6 service
switches to a different ISP. provider switches to a different ISP.
o Scenario 2: multiple Local Mobility Anchors (LMAs) MAY be deployed Scenario 2: multiple Local Mobility Anchors (LMAs) MAY be deployed
by the same PMIPv6 service provider, and then each LMA MAY serve by the same PMIPv6 service provider, and then each LMA
for a specific HNP set. In this case, the HNP of an MN MAY change MAY serve for a specific HNP set. In this case, the HNP
if the current serving LMA switches to another LMA but without of an MN MAY change if the serving LMA is changed to
inheriting the assigned HNP set [RFC6463]. another LMA that does not inherit the assigned HNP set
[RFC6463].
o Scenario 3: the PMIPv6 HNP renumbering MAY be caused by the re- Scenario 3: PMIPv6 HNP renumbering MAY be caused by the rebuilding
building of the network architecture as the companies split, of the network architecture as the companies split,
merge, grow, relocate, or reorganize. For example, the PMIPv6 merge, grow, relocate, or reorganize. For example, the
service provider MAY reorganize its network topology. PMIPv6 service provider MAY reorganize its network
topology.
In the scenario 1, we assume that only the HNP is renumbered while In Scenario 1, we assume that only the HNP is renumbered, while the
the serving LMA remains unchanged and this is the basic scenario serving LMA remains unchanged; this is the basic scenario considered
considered in this document. In the scenario 2 and scenario 3, more in this document. In Scenarios 2 and 3, more complex situations MAY
complex results MAY be caused, for example, the HNP renumbering MAY result; for example, HNP renumbering MAY occur due to the switchover
happen due to the switchover of a serving LMA. of a serving LMA.
In the Mobile IPv6 (MIPv6) protocol, when a home network prefix In the Mobile IPv6 (MIPv6) protocol, when an HNP changes, the Home
changes, the Home Agent (HA) will actively notify the new prefix to Agent (HA) will actively notify its MN about the new prefix, and then
its MN and then the renumbering of the Home Network Address (HoA) can the renumbering of the Home Network Address (HoA) can be well
be well supported [RFC6275]. In the basic PMIPv6, the PMIPv6 binding supported [RFC6275]. In basic PMIPv6, the PMIPv6 binding is
is triggered by a Mobile Access Gateway (MAG), which detects the triggered by a Mobile Access Gateway (MAG), which detects the
attachment of the MN. A scheme is also needed for the LMA to attachment of the MN. A scheme is also needed for the LMA to
immediately initiate the PMIPv6 binding state refreshment during the immediately initiate the PMIPv6 binding state refreshment during the
HNP renumbering process. Although this issue is also mentioned in HNP renumbering process. Although this issue is also mentioned in
Section 6.12 of [RFC5213], the related solution has not been Section 6.12 of [RFC5213], the related solution has not been
specified. specified.
3. HNP Renumbering Procedure 3. HNP Renumbering Procedure
When the HNP renumbering happens in PMIPv6, the LMA MUST notify a new When HNP renumbering happens in PMIPv6, the LMA MUST notify the MAG
HNP to the MAG and then the MAG MUST announce the new HNP to the about the new HNP, and then the MAG MUST announce the new HNP to the
attached MN accordingly. Also, the LMA and the MAG MUST update the attached MN accordingly. Also, the LMA and the MAG MUST update the
routing states for the HNP and the related addresses. To support routing states for the HNP and the related addresses. To support
this procedure, [RFC7077] can be adopted which specifies an this procedure, [RFC7077] can be adopted; it specifies an
asynchronous update from the LMA to the MAG about specific session asynchronous update from the LMA to the MAG about specific session
parameters. This document considers the following two cases: parameters. This document considers the following two cases:
(1) HNP is renumbered under the same LMA (1) HNP is renumbered under 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 Scenarios 1 and 3.
scenario 3. The operation steps are shown in Figure 1. The steps are shown in Figure 1.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| MN | | MAG | | LMA | | MN | | MAG | | LMA |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | |
| | Allocate new HNP | | Allocate new HNP
| | | | | |
| |<------------- UPN ---| | |<------------- UPN ---|
| | | | | |
| | | | | |
| | | | | |
|<-----RA/DHCP --------| | |<-----RA/DHCP --------| |
| | | | | |
Address configuration | | Address configuration | |
| | | | | |
| Update binding&routing states | | Update binding & routing states |
| | | | | |
| |--- UPA ------------->| | |--- UPA ------------->|
| | | | | |
| | Update binding&routing states | | Update binding & routing states
| | | | | |
Figure 1: Signaling call flow of the HNP renumbering Figure 1: Signaling Call Flow for HNP Renumbering
o When a PMIPv6 service provider renumbers the HNP set under the o When a PMIPv6 service provider renumbers the HNP set under the
same LMA, the serving LMA SHOULD initiate the HNP renumbering same LMA, the serving LMA SHOULD initiate the HNP renumbering
operation. The LMA allocates a new HNP for the related MN. operation. 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
update the HNP information. If the Dynamic Host Configuration to update the HNP information. If the Dynamic Host
Protocol (DHCP) is used to allocate the address, the new HNP MUST Configuration Protocol (DHCP) is used to allocate the address,
be also notified to the DHCP infrastructure. the DHCP infrastructure MUST also be notified about the new
HNP.
o Once the MAG receives this UPN message, it recognizes that the o Once the MAG receives this UPN message, it recognizes that the
related MN has the new HNP. Then the MAG MUST notify the MN about related MN has the new HNP. Then, the MAG MUST notify the MN
the new HNP with a Router Advertisement (RA) message or allocate a about the new HNP with a Router Advertisement (RA) message or
new address within the new HNP through a DHCP procedure. allocate a new address within the new HNP through a DHCP
procedure.
o After the MN obtains the HNP information through the RA message, o After the MN obtains the HNP information through the RA
it deletes the old HoA and configures a new HoA with the newly message, it deletes the old HoA and configures a new HoA with
allocated HNP. the newly allocated HNP.
o When the new HNP is announced or the new address is configured to o When the new HNP is announced or the new address is configured
the MN successfully, the MAG MUST update the related binding and to the MN successfully, the MAG MUST update the related
routing states. Then the MAG sends back the Update Notification binding and routing states. Then, the MAG sends back the
Acknowledgement (UPA) message to the LMA for the notification of Update Notification Acknowledgement (UPA) message to the LMA
successful update of the HNP, related binding state, and routing for the notification of successful update of the HNP, related
state. Then the LMA updates the routing and binding information binding state, and routing state. Then, the LMA updates the
corresponding to the MN to replace the old HNP with the new one. routing and binding information corresponding to the MN in
order to replace the old HNP with the new one.
(2) HNP renumbering caused by the LMA switchover (2) HNP renumbering is caused by the LMA switchover
Since the HNP is assigned by the LMA, the HNP renumbering MAY be Since the HNP is assigned by the LMA, HNP renumbering MAY be
caused by the LMA switchover, as in the scenario 2 and scenario 3. caused by the LMA switchover, as in Scenarios 2 and 3.
The information of LMA is the basic configuration information of MAG. The LMA information is the basic configuration information of the
When the LMA changes, the related profile SHOULD be updated by the MAG. When the LMA changes, the related profile SHOULD be updated
service provider. In this way, the MAG initiates the registration to by the service provider. In this way, the MAG initiates the
the new LMA as specified in [RFC5213]. When the HNP renumbering is binding registration to the MN's new LMA as specified in
caused in this case, the new HNP information is sent by the LMA [RFC5213]. When HNP renumbering is caused in this case, the new
during the new binding procedure. Accordingly, the MAG withdraws the HNP information is sent by the LMA during the new binding
old HNP of the MN and announces the new HNP to the MN as like the procedure. Accordingly, the MAG withdraws the old HNP of the MN
case of the HNP is renumbered under the same LMA. and announces the new HNP to the MN, similar to the case when the
HNP is renumbered under the same LMA.
4. Session Connectivity 4. Session Connectivity
The 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 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
HNP renumbering (after the UPA reception) in order to redirect the during the HNP renumbering (after the UPA reception) in order to
packets to the MN before the MN reconnects the ongoing session and redirect the packets to the MN before the MN reconnects the
notifies its new HoA to the Correspondent Node (CN). This mode is ongoing session and notifies the Correspondent Node (CN) about
aiming to reduce the packet loss during the HNP renumbering but the its new HoA. This mode is aiming to reduce packet loss during
binding state corresponding to the old HNP should be marked for HNP renumbering, but the binding state corresponding to the old
example as transient binding [RFC6058]. And the LMA MUST stop HNP SHOULD be marked, for example, as transient binding
broadcasting the routing information about the old HNP if the old HNP [RFC6058]. Also, the LMA MUST stop broadcasting the routing
is no longer anchored at this LMA. information about the old HNP if the old HNP 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 HNP renumbering happens with the switchover of the LMA, hard
hard-mode is recommended to keep the protocol simple. In this mode, mode is RECOMMENDED to keep the protocol simple. In this mode,
the LMA deletes the binding state of the old HNP after it receives the LMA deletes the binding state of the old HNP after it
the UPA message from the MAG and the LMA silently discards the receives the UPA message from the MAG, and the LMA silently
packets destined to the old HNP. discards 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
reason is set to 2 (UPDATE-SESSION-PARAMETERS). Besides, the HNP notification reason is set to 2 (UPDATE-SESSION-PARAMETERS).
Option [RFC5213] containing the new HNP and the Mobile Node Besides, the HNP Option [RFC5213] containing the new HNP and the
Identifier Option [RFC4283] carrying identifier of MN are contained Mobile Node Identifier Option [RFC4283] (which identifies the
as Mobility Options of UPN. The order of HNP Option and Mobile Node MN) are contained as Mobility Options of UPN. The order of the
Identifier Option in the UPN message is not mandated here. HNP Option and Mobile Node Identifier Option in the UPN message
is not mandated here.
(2) UPA message (2) UPA message
The MAG sends this message in order to acknowledge that it has 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 received an UPN message with the (A) flag set and to indicate
status after processing the message. When the MAG did not the status after processing the message. If the MAG did not
successfully renumber the HNP which is required in the UPN message, successfully renumber the HNP, which is required in the UPN
the Status Code of 128 is set in the UPA message and the following message, the UPA message has the Status Code set to 128 (FAILED-
operation of LMA is PMIPv6 service provider specific. TO-UPDATE-SESSION-PARAMETERS), and the subsequent operation of
the LMA is PMIPv6 service provider specific.
(3) RA Message (3) 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, it
Prefix Information Options are contained in the RA message [RFC4861] contains two Prefix Information Options [RFC4861] [RFC4862]. In
[RFC4862]. In the first Prefix Information Option, the old HNP is the first Prefix Information Option, the old HNP is carried, and
carried and the related Preferred Lifetime is set to 0. In the the related Preferred Lifetime is set to 0. In the second
second Prefix Information Option, the new HNP is carried with the Prefix Information Option, the new HNP is carried with the Valid
Valid Lifetime and Preferred Lifetime set to larger than 0. Lifetime, and Preferred Lifetime set to larger than 0.
(4) DHCP Message (4) DHCP message
When the DHCP is used in PMIPv6 to configure the addresses for the When the DHCP is used in PMIPv6 to configure the addresses for
MN, new IPv6 address(es) (e.g., HoA) will be generated based on the the MN, new IPv6 address or addresses (e.g., the HoA) will be
new HNP and the related DHCP procedure is also triggered by the generated based on the new HNP, and the related DHCP procedure
reception of UPN message [RFC3315]. is also triggered by the reception of the UPN message [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
System (DNS) resource record corresponding to this MN may need to be System (DNS) resource record corresponding to this MN MAY need to be
updated when the HNP of MN changes [RFC3007]. However, this is updated when the HNP of the MN changes [RFC3007]. However, this is
beyond the scope of this document. beyond the scope of this document.
7. Security Considerations 7. Security Considerations
This document causes no further security problem for the signaling The UPN and UPA messages in this document MUST be protected using
exchanges. The UPN and UPA messages in this document MUST be end-to-end security association(s) offering integrity and data origin
protected using end-to-end security association(s) offering integrity authentication as specified in [RFC5213] and [RFC7077].
and data origin authentication as speficied in [RFC5213] and
[RFC7077].
When the HNP renumbering is triggered, a new HNP SHOULD be allocated When HNP renumbering is triggered, a new HNP SHOULD be allocated to
to the MN. The LMA MUST follow the procedure of PMIPv6 to make sure the MN. The LMA MUST follow the procedure of PMIPv6 to make sure
that only an authorized HNP can be assigned for the MN. In this way, that only an authorized HNP can be assigned for the MN. In this way,
LMA is ready to be the topological anchor point of the new HNP and the LMA is ready to be the topological anchor point of the new HNP,
the new HNP is for that MN's exclusive use. which is for that MN's exclusive use.
[RFC4862] requires an RA to be authenticated for the Valid Lifetime Per [RFC4862], if the Valid Lifetime in a Prefix Information Option
in a Prefix Information Option to be set to less than 2 hours. Thus, is set to less than 2 hours in an unauthenticated RA, it is ignored.
when the old HNP that is being deprecated is included in an RA from Thus, when the old HNP that is being deprecated is included in an RA
the MAG, it will normally be expected that the Valid Lifetime SHOULD from the MAG, the Valid Lifetime SHOULD be set to 2 hours (and the
be set to 2 hours (and the Preferred Lifetime set to 0) for a non- Preferred Lifetime set to 0) for an unauthenticated RA. However, if
authenticated RA. However, if the legality of the signaling messages the legality of the signaling messages exchanged between MAG and MN
exchanged between MAG and MN can be guaranteed, it MAY be acceptable can be guaranteed, it MAY be acceptable to also set the Valid
to also set the Valid Lifetime to 0 for a non-authenticated RA. Lifetime to 0 for an unauthenticated RA.
8. IANA Considerations 8. IANA Considerations
This document presents no IANA considerations. This document does not require any IANA actions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 8, line 24 skipping to change at page 9, line 10
[RFC6463] Korhonen, J., Ed., Gundavelli, S., Yokota, H., and X. Cui, [RFC6463] Korhonen, J., Ed., Gundavelli, S., Yokota, H., and X. Cui,
"Runtime Local Mobility Anchor (LMA) Assignment Support "Runtime Local Mobility Anchor (LMA) Assignment Support
for Proxy Mobile IPv6", RFC 6463, DOI 10.17487/RFC6463, for Proxy Mobile IPv6", RFC 6463, DOI 10.17487/RFC6463,
February 2012, <http://www.rfc-editor.org/info/rfc6463>. February 2012, <http://www.rfc-editor.org/info/rfc6463>.
[RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and [RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and
J. Korhonen, "Update Notifications for Proxy Mobile IPv6", J. Korhonen, "Update Notifications for Proxy Mobile IPv6",
RFC 7077, DOI 10.17487/RFC7077, November 2013, RFC 7077, DOI 10.17487/RFC7077, November 2013,
<http://www.rfc-editor.org/info/rfc7077>. <http://www.rfc-editor.org/info/rfc7077>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[RFC6058] Liebsch, M., Ed., Muhanna, A., and O. Blume, "Transient [RFC6058] Liebsch, M., Ed., Muhanna, A., and O. Blume, "Transient
Binding for Proxy Mobile IPv6", RFC 6058, Binding for Proxy Mobile IPv6", RFC 6058,
DOI 10.17487/RFC6058, March 2011, DOI 10.17487/RFC6058, March 2011,
<http://www.rfc-editor.org/info/rfc6058>. <http://www.rfc-editor.org/info/rfc6058>.
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations, and Network Renumbering Scenarios, Considerations, and
Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013,
<http://www.rfc-editor.org/info/rfc6879>. <http://www.rfc-editor.org/info/rfc6879>.
[RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W.
George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, George, "IPv6 Site Renumbering Gap Analysis", RFC 7010,
DOI 10.17487/RFC7010, September 2013, DOI 10.17487/RFC7010, September 2013,
<http://www.rfc-editor.org/info/rfc7010>. <http://www.rfc-editor.org/info/rfc7010>.
Acknowledgements
The work of Jong-Hyouk Lee was supported by 'The Cross-Ministry Giga
KOREA Project' grant from the Ministry of Science, ICT and Future
Planning, Korea.
Authors' Addresses Authors' Addresses
Zhiwei Yan Zhiwei Yan
CNNIC CNNIC
No.4 South 4th Street, Zhongguancun No.4 South 4th Street, Zhongguancun
Beijing 100190 Beijing 100190
China China
EMail: yan@cnnic.cn Email: yan@cnnic.cn
Jong-Hyouk Lee Jong-Hyouk Lee
Sangmyung University Sangmyung University
31, Sangmyeongdae-gil, Dongnam-gu 31, Sangmyeongdae-gil, Dongnam-gu
Cheonan 31066 Cheonan 31066
Republic of Korea Republic of Korea
EMail: jonghyouk@smu.ac.kr Email: jonghyouk@smu.ac.kr
Xiaodong Lee Xiaodong Lee
CNNIC CNNIC
No.4 South 4th Street, Zhongguancun No.4 South 4th Street, Zhongguancun
Beijing 100190 Beijing 100190
China China
EMail: xl@cnnic.cn Email: xl@cnnic.cn
 End of changes. 56 change blocks. 
179 lines changed or deleted 197 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/