idnits 2.17.1 draft-mccann-dmm-prefixcost-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 7, 2015) is 3337 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (ref. '5') (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF P. McCann, Ed. 3 Internet-Draft J. Kaippallimalil 4 Intended status: Informational Huawei 5 Expires: September 8, 2015 March 7, 2015 7 Communicating Prefix Cost to Mobile Nodes 8 draft-mccann-dmm-prefixcost-00 10 Abstract 12 In a network implementing Distributed Mobility Management, it has 13 been agreed that Mobile Nodes (MNs) should exhibit agility in their 14 use of IP addresses. For example, an MN might use an old address for 15 ongoing socket connections but use a new, locally assigned address 16 for new socket connections. Determining when to assign a new 17 address, and when to release old addresses, is currently an open 18 problem. Making an optimal decision about address assignment and 19 release must involve a tradeoff in the amount of signaling used to 20 allocate the new addresses, the amount of utility that applications 21 are deriving from the use of a previously assigned address, and the 22 cost of maintaining an address that was assigned at a previous point 23 of attachment. As the MN moves farther and farther from the initial 24 point where an address was assigned, more and more resources are used 25 to redirect packets destined for that IP address to its current 26 location. The MN currently does not know the amount of resources 27 used as this depends on mobility path and internal routing topology 28 of the network(s) which are known only to the network operator. This 29 document provides a mechanism to communicate to the MN the cost of 30 maintaining a given prefix at the MN's current point of attachment so 31 that the MN can make better decisions about when to release old 32 addresses and assign new ones. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 8, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Prefix Cost Sub-option . . . . . . . . . . . . . . . . . . . 4 71 3. Host Considerations . . . . . . . . . . . . . . . . . . . . . 4 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 76 6.2. Informative References . . . . . . . . . . . . . . . . . 6 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 79 1. Introduction 81 Previous discussions on address agility in distributed mobility 82 management have focused on "coloring" prefixes with one of a small 83 number of categories, such as Fixed, Sustained, or Nomadic. The 84 assumption here is that the MN should use a permanent home address 85 for sessions that need a persistent IP address, and a local, 86 ephemeral address for short-lived sessions such as browsing. 87 However, a small set of address categories lacks expressive power and 88 leads to false promises being made to mobile nodes. For example, the 89 concept that a home address can be maintained permanently and offered 90 as an on-link prefix by any access router to which the MN may be 91 attached in future is simply not attainable in the real world. There 92 will always exist some access routers that do not have arrangements 93 in place with the home network to re-route (via tunneling or other 94 mechanisms) the home prefix to the current point of attachment. 96 Conversely, the assumption that a Nomadic prefix will never be 97 available to an MN after it changes its current point of attachment 98 is too limiting. There is no reason why an MN should not be able to 99 keep a prefix that was assigned by a first network after it moves to 100 a second network, provided that measures are put in place to re-route 101 such prefixes to the new attachment point. 103 Rather, this document argues that there is in reality a continuum of 104 cost associated with an address as the MN moves from one attachment 105 point to another or from one network to another. The sources of the 106 cost are the increased latency, network bandwidth, and network state 107 being maintained by a network-based mobility management scheme to 108 route packets destined to the prefix to the MN's current point of 109 attachment. By communicating this cost to the MN every time its 110 attachment point changes, the MN can make intelligent decisions about 111 when to release old addresses and when to acquire new ones. 113 The cost should be communicated to the MN because of several 114 constraints inherent in the problem: 116 (1) The MN is the entity that must make decisions about allocating 117 new addresses and releasing old ones. This is because only the 118 MN has the information about which addresses are still in use by 119 applications or have been registered with other entities such as 120 DNS servers. 122 (2) Only the network has information about the cost of maintaining 123 the prefix in a network-based mobility management scheme, 124 because the MN cannot know the network topology that gives rise 125 to the inefficiencies. 127 If the cost of maintaining a prefix is not made available to the 128 mobile node, it may attempt to infer the cost through heuristic 129 mechanisms. For example, it can measure increased end-to-end latency 130 after a mobility event, and attribute the increased latency to a 131 longer end-to-end path. However, this method does not inform the MN 132 about the network bandwidth being expended or network state being 133 maintained on its behalf. Alternatively, a MN may attempt to count 134 mobility events or run a timer in an attempt to guess at which older 135 prefixes are more costly and in need of being released. However, 136 these methods fail because the number of mobility events is not an 137 indication of how far the MN has moved in a topological sense from 138 its original attachment point which is what gives rise to the costs 139 outlined above. Re-allocating an address upon expiration of a timer 140 may introduce uneccessary and burdensome signaling load on the 141 network and air interface. 143 1.1. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [1]. 149 1.2. Abbreviations 151 MN Mobile Node 152 MPTCP Multi-Path Transmission Control Protocol 153 ND Neighbor Discovery 154 PIO Prefix Information Discovery 155 SeND Secure Neighbor Discovery 157 2. Prefix Cost Sub-option 159 This document defines a prefix cost option to be carried in router 160 advertisements. It is a sub-option that carries meta-data as defined 161 by Korhonen et al. [7] 163 0 1 2 3 164 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | TBD1 | 1 |C| Reserved1 | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Prefix Cost | Reserved2 | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 1: Prefix Cost suboption 173 The prefix cost is carried as a 16-bit, unsigned number in network 174 byte order. An higher number indicates an increased cost. 176 3. Host Considerations 178 Prefix Cost in a Router Advertisement PIO serves as a hint for the MN 179 to use along with application type, MN policy configuration on 180 network cost and available alternative routes to determine the IP 181 addresses and routes used. For example, if the application is 182 downloading a large file, it may want to maintain an IP address and 183 route until the download is complete. On the other hand, some 184 applications may use multiple connections (e.g., with MPTCP) and may 185 not want to maintain an IP address above a configured cost. It could 186 also be the case that the MN maintains the IP address even at high 187 cost if there is no alternative route/address. These decisions are 188 made based on configured policy, and interaction with applications, 189 all of which are internal to the MN and outside the scope of this 190 memo. 192 When the MN is ready to release an IP address, it may send a DHCPv6 193 [5] Release message. The network may also monitor the status of a 194 high cost connection with Neighbor Unreachability Detection (NUD) 195 [2], [6], and determine that an address is not used after the NUD 196 timeout. The network should not continue to advertise this high cost 197 route following the explicit release of the address or NUD timeout. 198 It can initiate the release of network resources dedicated to 199 providing the IP address to the MN. 201 4. Security Considerations 203 Security of the prefix cost option in the PIO needs to be considered. 204 Neighbor Discovery (ND) and Prefix Information Option (PIO) security 205 are described in [2] and [3]. A malicious node on a shared link can 206 advertise a low cost route in the prefix cost option and cause the MN 207 to switch. Alternatively, an incorrect higher cost route in the 208 prefix cost option can result in the suboptimal use of network 209 resources. In order to avoid such on-link attacks, SeND [4] can be 210 used to reject Router Advertisements from nodes whose identities are 211 not validated. 213 5. IANA Considerations 215 This memo defines a new Prefix Information Option (PIO) sub-option in 216 Section 2. 218 6. References 220 6.1. Normative References 222 [1] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, March 1997. 225 [2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 226 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 227 September 2007. 229 [3] Draves, R. and D. Thaler, "Default Router Preferences and 230 More-Specific Routes", RFC 4191, November 2005. 232 [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 233 Neighbor Discovery (SEND)", RFC 3971, March 2005. 235 [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 236 and M. Carney, "Dynamic Host Configuration Protocol for 237 IPv6 (DHCPv6)", RFC 3315, July 2003. 239 [6] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 240 Detection Is Too Impatient", RFC 7048, January 2014. 242 6.2. Informative References 244 [7] Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 245 Liu, "IPv6 Prefix Properties", draft-korhonen-6man-prefix- 246 properties-02 (work in progress), July 2013. 248 Authors' Addresses 250 Peter J. McCann (editor) 251 Huawei 252 400 Crossing Blvd, 2nd Floor 253 Bridgewater, NJ 08807 254 USA 256 Phone: +1 908 541 3563 257 Email: peter.mccann@huawei.com 259 John Kaippallimalil 260 Huawei 261 5340 Legacy Dr., Suite 175 262 Plano, TX 75024 263 USA 265 Email: john.kaippallimalil@huawei.com