idnits 2.17.00 (12 Aug 2021) /tmp/idnits12891/draft-wei-dmm-address-management-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 == Line 253 has weird spacing: '...ss from curre...' -- The document date (October 27, 2014) is 2763 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) ** Downref: Normative reference to an Informational RFC: RFC 7333 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT X. Wei 3 Intended Status: Standards Track Huawei Technologies 4 Expires: April 30, 2015 October 27, 2014 6 IP Address Management in DMM 7 draft-wei-dmm-address-management-00 9 Abstract 11 This document provides an IP address management solution for DMM 12 network. 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright and License Notice 37 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2 IP Address Management . . . . . . . . . . . . . . . . . . . . . 3 55 2.1 All application sessions prefer IP address consistency . . . 3 56 2.2 Address Management model . . . . . . . . . . . . . . . . . 4 57 2.2.1 Design Principles . . . . . . . . . . . . . . . . . . . 4 58 2.2.2 Anchor Deployment . . . . . . . . . . . . . . . . . . . 5 59 2.2.3 Prefix Category . . . . . . . . . . . . . . . . . . . . 5 60 2.2.4 Anchor Action . . . . . . . . . . . . . . . . . . . . . 5 61 2.2.5 IP Address Release . . . . . . . . . . . . . . . . . . . 6 62 3 Source Address selection . . . . . . . . . . . . . . . . . . . . 6 63 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 64 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 65 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.1 Normative References . . . . . . . . . . . . . . . . . . . 7 67 6.2 Informative References . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1 Introduction 72 In DMM scenario, mobility anchors would be deployed in a distributed 73 manner, and as specified in RFC7333 [RFC7333], one of the aims of DMM 74 is to reduce the routing redundancy between mobile node and 75 correspondent node, which means providing a more optimal 76 communication path for application traffic between mobile node and 77 correspondent node. To achieve routing optimization for specific 78 application traffic, the basic idea is to make the traffic using IP 79 address(s) anchored at current anchor, so that downlink traffic from 80 correspondent node to mobile node will go directly to mobile node, 81 but this routing optimization requirement brings a fact that mobile 82 node has to change its IP address as it moving to a new anchor. Some 83 application sessions can cope with the change of IP address either by 84 application layer itself or by the function provided by other layers, 85 e.g. transport layer; but for other application sessions, after IP 86 address changed, the application session would be broken off totally. 87 So it's reasonable to provide different network layer mobility 88 support according to the need of application. This document provides 89 a discussion on IP address management in DMM domain, which gives 90 support to source IP address selection on mobile node side. A brief 91 discussion of how end host chooses to use the IP address provided by 92 network is also involved. Currently, the address management described 93 in this document is not specific to certain DMM framework. 95 1.1 Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2 IP Address Management 103 2.1 All application sessions prefer IP address consistency 105 In IP network, the nature of IP address acting as both "locator" and 106 "identifier" results that the change of "location" would inevitably 107 interrupt continuity of ongoing application session, no matter short- 108 lived or long last one. There are mainly two different technical 109 routes to eliminate the impacts of IP address change on application 110 session continuity, the first one is keeping IP address unchanged 111 during movement of host; the second one is allowing IP address change 112 to happen and then using other methods to make the application 113 session correctly finished, here are some examples of these methods: 115 (1) Deal with IP address change in process of a session Mobility 116 support could be provided by application layer or transport layer. 117 When IP address change happens, specific signaling of application 118 layer or transport layer could be used to add new IP address to the 119 session and at the same time removing old IP address from the 120 session. 122 (2) Restart a new session If there is no specific application layer 123 signaling to deal with the change of IP address, the application 124 could choose to restart a session when it finds the previous session 125 failed. This method would only be used for short-lived session, e.g. 126 DNS query/response session. Although, as discussed above, there are 127 methods to cope with IP address change for application session, but 128 from application's perspective, all these methods will bring in 129 certain amount of "cost", and may import other negative impacts, e.g. 130 signaling latency, packet losing, TCP slow start etc, in order to 131 deal with the impact of IP address change. So we have to say that, 132 all application sessions prefer to not change their IP address, the 133 reason why they provide mechanisms to deal with IP address change is 134 they have to do that, but not they willing to do that. 136 Another issue is that if application wants to make their traffic pass 137 through an optimal path between MN and CN, it has to use an IP 138 address anchored on the optimal path. So in order to get an overall 139 good performance for application, there should be a tradeoff on 140 whether to use a new IP address or not. 142 2.2 Address Management model 144 This sub-section provides a detailed description of suggested address 145 management model to satisfy the requirement of analysis result in 146 sub-section 2.1. 148 2.2.1 Design Principles 150 The following are some design principles considered in design process 151 of the address management model: 153 P1. Network SHOULD provide IP address consistency during the whole 154 session lifetime for application that cannot bear IP address change. 156 P2. Providing opportunity for application session to use the new IP 157 address after mobile node handover to a new anchor, but in order to 158 limit IP address change frequency, application session SHOULD NOT 159 changes its IP address each time after handover to a new anchor. 161 P3. Less IP addresses maintained by mobile node is preferred. 163 P4. Less requirements on mobile node side is preferred. 165 2.2.2 Anchor Deployment 167 Anchors are deployed in a distributed manner, and each one could 168 assign its own prefix to mobile node. 170 Home anchor: A prefix's home anchor refers to the anchor which the 171 prefix belongs to. 173 Foreign anchor: A prefix's foreign anchor refers to all of the other 174 anchors that are not home anchor. 176 Current anchor: The anchor that mobile node currently attaches to. 178 2.2.3 Prefix Category 180 There are two kinds of prefixes: stable prefix and temporary prefix. 181 DMM network will provide mobility support for both of these two kinds 182 of prefix. 184 Stable prefix: Assigned by its home anchor, when mobile node hands 185 over to a foreign anchor the stable prefix will be maintained by 186 foreign anchors as long as the prefix is still being used by 187 application. 189 Temporary prefix: Assigned by its home anchor, temporary prefix 190 usually has different valid lifetime values in home anchor's network 191 and in foreign anchor's network (more shorter in foreign anchor's 192 network), a foreign anchor only provide mobility support for 193 temporary prefix for a specific period of time after which the 194 temporary prefix will become invalid. In DMM domain, the anchors 195 could set the valid lifetime of other anchors' temporary prefix to a 196 predefined value. 198 Each anchor maintains at least one stable prefix and one temporary 199 prefix for mobile node. 201 2.2.4 Anchor Action 203 Anchor advertises its own stable prefix and temporary prefix to the 204 mobile node, and sets them as preferred prefix. If mobile node is 205 hands over to current anchor from a previous anchor if prefix(es) of 206 previous anchor is still used by application session of mobile node, 207 then the current anchor will also advertise these prefixes from 208 previous anchor, but set them as deprecated prefix. Current anchor 209 sets valid lifetime value of temporary prefix of previous anchor to a 210 specific value after which the prefix becomes invalid. When the cost 211 of using previous temporary prefix is beyond a certain threshold 212 (e.g. current anchor is certain hops away from home anchor), current 213 anchor could choose not advertise the temporary prefix to mobile 214 node, and this will let the application session to select a new 215 prefix to reduce routing redundancy. 217 2.2.5 IP Address Release 219 To reduce the number of IP addresses that mobile node must maintains, 220 and contexts that network maintains for mobile node, there should be 221 an effective IP address release mechanism for mobile node. 223 Triggers that could cause IP address to be released: 225 (1) Prefix valid Lifetime expiration. 227 (2) No traffic is transported using the IP address. For example, when 228 mobile node hands over to a new anchor, if there is no traffic 229 transported on previous anchors' prefixes, the prefixes will be seen 230 as invalid in current anchor's network. But there should be a special 231 treatment for MN's public address which can be retrieved by others 232 through DNS (e.g. when MN is a mobile server) , public address is a 233 kind of stable address though current anchor could set it as a 234 deprecated address, but it should not be released even when there is 235 not traffic using it. 237 (3) Mobile node explicitly signals out that it wants to release 238 certain IP address. 240 3 Source Address selection 242 Which IP address could be selected as source address depends on what 243 IP addresses are provided by network. Based on the address management 244 model discussed in this document, there are some simple source 245 address selection criteria: 247 (1) New communication (e.g., the opening of a new TCP connection) 248 should use a preferred address when possible. 250 (2) If an existing app session could cope with IP address changes, it 251 could choose to use temporary address from temporary prefix. In a 252 visit network, when MN's previous temporary address becomes invalid, 253 a new temporary address from current anchor's temporary prefix will 254 be selected. 256 (3) A deprecated stable address should be used only by applications 257 that have been using it and would have difficulty switching to 258 another address without a service disruption. 260 (4) For the session which is initialized by CN, the address in the 261 destination address field of packet from CN will be used as source 262 address of outgoing packets. (This is mainly for the case of using 263 MN's public address) 265 4 Security Considerations 267 TBD. 269 5 IANA Considerations 271 No. 273 6 References 275 6.1 Normative References 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, March 1997. 280 [RFC7333] H. Chan et al., Requirements for Distributed Mobility 281 Management, RFC 7333, August 2014. 283 6.2 Informative References 285 Authors' Addresses 287 Xinpeng Wei 288 Xin-Xi Rd. No. 3, Haidian District, 289 Beijing, 100095, P. R. China 290 E-mail: weixinpeng@huawei.com