idnits 2.17.1 draft-jhlee-dmm-dnpp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4861]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document updates RFC4861, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 5, 2016) is 2940 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7333' is defined on line 204, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Distributed Mobility Management (DMM) J. Lee 3 Internet-Draft Sangmyung University 4 Intended status: Standards Track Z. Yan 5 Expires: October 7, 2016 CNNIC 6 April 5, 2016 8 Deprecated Network Prefix Provision 9 draft-jhlee-dmm-dnpp-01 11 Abstract 13 This document introduces new extensions to router advertisement and 14 router solicitation messages. The extensions are used to provide a 15 mobile node's deprecated network prefix information to an access 16 router. This document updates [RFC4861]. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 7, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Option Formats . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Deprecated Network Prefix Provision in Router 56 Solicitations . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Deprecated Network Prefix Request in Router 58 Advertisements . . . . . . . . . . . . . . . . . . . . . 4 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 6.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 Router advertisement and router solicitation messages defined in 69 [RFC4861] are used during stateless IPv6 autoconfiguration. A mobile 70 node listens for router advertisement messages that are periodically 71 sent by access routers on the local link or are explicitly requested 72 by the mobile node using a router solicitation message. The router 73 advertisement message contains information to allow the mobile node 74 configures a global unicast IPv6 address. The provided information 75 by the router advertisement message is, for instance, network 76 prefix(es), default router address(es), hop limit, etc. 78 The router advertisement message is used by an access router to 79 provide the network prefix information required for stateless IPv6 80 autoconfiguration, whereas the router solicitation message is used by 81 a mobile node to quickly receive the router advertisement message 82 from the access router. In other words, the current specification of 83 Neighbor Discovery for IP version 6 does not specifies how the access 84 router obtains the deprecated network prefix information (e.g., 85 previous network prefix information) from the mobile node keeping 86 deprecated IPv6 address(es) that are for instance global unicast IPv6 87 address(es) generated and used at previous access networks. 89 This document introduces new extensions to router advertisement and 90 router solicitation messages to allow a mobile node provides its 91 deprecated network prefix information to an access router. 93 2. Motivation 95 A mobile node changes its point of attachment from a previous network 96 to a new network while keeping its global unicast IPv6 address for 97 communications with a correspondent node. At the new network the 98 mobile node's global unicast IPv6 address previously configured at 99 the previous network becomes a deprecated address. The mobile node 100 configures a new global unicast IPv6 address at the new network and 101 uses the new address for new communications. The mobile node also 102 may use the deprecated address (i.e., the previously configured 103 address at the previous network) for the communications with the 104 correspondent node. 106 Nowadays ingress filtering is widely used to prevent source address 107 spoofing. In this case, when the mobile node sends packets with the 108 deprecated address as a source address at the new network, the 109 packets will be filtered unless a rule of ingress filtering is 110 updated in advance. 112 An access router at the new network may need to obtain the mobile 113 node's deprecated network prefix information. For instance, the new 114 access router needs to establish a bidirectional tunnel with the 115 previous access router of the mobile node for the communications 116 associated with the deprecated address of the mobile node 117 [Paper-Distributed.Mobility]. 119 3. Option Formats 121 A router solicitation message is extended to include the deprecated 122 network prefix information. A router advertisement message is 123 extended to include a flag that requests the mobile node to send a 124 router solicitation message including the deprecated network prefix 125 information. 127 3.1. Deprecated Network Prefix Provision in Router Solicitations 129 A new flag is defined to indicate that a router solicitation message 130 includes the deprecated network prefix information of a mobile node 131 in the prefix information option. 133 4 5 6 7 8 9 0 1 134 +-+-+-+-+-+-+-+-+ 135 |L|A|D|Reserved1| 136 +-+-+-+-+-+-+-+-+ 138 D: 1-bit "Deprecated network prefix" flag. It indicates that the 139 prefix included in this prefix information option is the deprecated 140 network prefix of the mobile node. 142 When the mobile node wants to send the deprecated prefix to the new 143 access router, the prefix information option is used to carry the 144 deprecated network prefix and the D flag is set to 1. 146 3.2. Deprecated Network Prefix Request in Router Advertisements 148 A new flag is defined to request the deprecated network prefix 149 information in a router solicitation message. 151 8 9 0 1 2 3 4 5 152 +-+-+-+-+-+-+-+-+ 153 |M|O|D|Reserved | 154 +-+-+-+-+-+-+-+-+ 156 D: 1-bit "Deprecated network prefix" flag. It indicates that the 157 deprecated network prefix of the mobile node is needed by an access 158 router. 160 When a mobile node receives the router advertisement message 161 containing the D flag set to 1, the mobile node should respond with a 162 router solicitation message carrying the prefix information option 163 and with D flag set to 1 in the option. In the prefix information 164 option, the deprecated network prefix of the mobile node is 165 contained. 167 After the new access router learns the previous prefix of the 168 specific mobile node, it updates the rule of ingress filter. 169 Afterwards, the D flag in the following router advertisement message 170 sent to this mobile node will be set to 0 and the mobile node will 171 recognize that its previous prefix has been recorded by the access 172 router. Then the mobile node will not feedback with a router 173 solicitation message. 175 This extension is not supported by the access router if the D flag is 176 not included in the router advertisement message and then the mobile 177 node should not send a router solicitation message accordingly. 179 4. Security Considerations 181 TBD 183 5. IANA Considerations 185 TBD 187 6. References 189 6.1. Normative References 191 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 192 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 193 DOI 10.17487/RFC4861, September 2007, 194 . 196 6.2. Informative References 198 [Paper-Distributed.Mobility] 199 Lee, J., Bonnin, J., Seite, P., and H. Chan, "Distributed 200 IP Mobility Management from the Perspective of the IETF: 201 Motivations, Requirements, Approaches, Comparison, and 202 Challenges", IEEE Wireless Communications, October 2013. 204 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 205 Korhonen, "Requirements for Distributed Mobility 206 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 207 . 209 Authors' Addresses 211 Jong-Hyouk Lee 212 Sangmyung University 213 31, Sangmyeongdae-gil, Dongnam-gu 214 Cheonan 31066 215 Republic of Korea 217 Email: jonghyouk@smu.ac.kr 219 Zhiwei Yan 220 CNNIC 221 No.4 South 4th Street, Zhongguancun 222 Beijing 100190 223 China 225 Email: yanzhiwei@cnnic.cn