idnits 2.17.1 draft-liu-dmm-mobility-api-02.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 draft header indicates that this document updates RFC5014, but the abstract doesn't seem to mention this, which it should. 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. (Using the creation date from RFC5014, updated by this document, for RFC5378 checks: 2003-02-24) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 06, 2013) is 3816 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 5014 == Outdated reference: A later version (-05) exists of draft-bhandari-dhc-class-based-prefix-04 == Outdated reference: A later version (-09) exists of draft-ietf-dmm-best-practices-gap-analysis-01 -- No information found for draft-korhonen-6man-prfix-properties - is the name correct? == Outdated reference: A later version (-07) exists of draft-seite-dmm-dma-06 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Distributed Mobility Managment Working Group D. Liu 3 Internet-Draft H. Deng 4 Updates: 5014 (if approved) China Mobile 5 Intended status: Standards Track C. Perkins 6 Expires: May 10, 2014 Futurewei 7 November 06, 2013 9 Mobility API Extension for Distributed Mobility Management 10 draft-liu-dmm-mobility-api-02 12 Abstract 14 In order to provide an appropriate level of mobility support that a 15 mobile node may require for proper performance of various 16 applications, it is important to enable applications to select 17 addresses that will be managed properly by the mobility management 18 infrastructure. Previous documents have enabled address selection on 19 the basis of certain characteristics such as randomness, temporary 20 usage, scope of validity, and so on. This document proposes new 21 classes of addresses in addition to those already available, to 22 enable an application to receive certain kinds of mobility support. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 10, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 3. Proposed Extension of RFC 5014 . . . . . . . . . . . . . . . 2 61 4. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 3 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 67 8.2. Informative References . . . . . . . . . . . . . . . . . 4 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 An extension to the socket API (see [RFC5014]) has been specified to 73 allow an application to identify its preference among multiple source 74 addresses. Furthermore, there are proposals 75 ([I-D.draft-korhonen-6man-prfix-properties] and 76 [I-D.draft-bhandari-dhc-class-based-prefix-04]) to extend router 77 advertisement to carry property and class information for the 78 advertised prefixes. Those proposals enable a mobile node to learn 79 the property and class information for the prefix from the router 80 advertisement message. This document proposes an extension to 81 [RFC5014] which would add more prefix classes so that an application 82 could select prefixes with properties that are important for 83 distributed mobility management. 85 2. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 3. Proposed Extension of RFC 5014 92 A socket API extension defined in [RFC5014] is used for IPv6 source 93 address selection. An application can use this API to override the 94 default source address selection mechanism for IPv6. Currently, the 95 following types of source address selection preference are defined in 96 [RFC5014]: 98 IPV6_PREFER_SRC_HOME /* Prefer Home address as source */ 100 IPV6_PREFER_SRC_COA /* Prefer Care-of address as source */ 102 IPV6_PREFER_SRC_TMP /* Prefer Temporary address as source */ 104 IPV6_PREFER_SRC_PUBLIC /* Prefer Public address as source */ 106 IPV6_PREFER_SRC_CGA /* Prefer CGA address as source */ 108 IPV6_PREFER_SRC_NONCGA /* Prefer a non-CGA address as source */ 110 This document proposes the addition of two new flags: 112 IPV6_PREFER_SRC_LOCAL_HNP /* Prefer a local home prefix */ 114 IPV6_PREFER_SRC_REMOTE_HNP /* Prefer a remote home prefix */ 116 The local home prefix may be preferred by applications which are 117 likely to discontinue operations before the device travels to distant 118 networks. On the other hand, a remote home prefix may be more 119 suitable for continued operation over wide areas, but at potentially 120 increased cost for mobiilty management. 122 4. Usage Example 124 This section gives usage examples for the new flags API extension. 126 Relevant distributed mobility management practices are discussed in 127 [I-D.draft-ietf-dmm-best-practices-gap-analysis-01] and 128 [I-D.draft-seite-dmm-dma-06]. The concept of dynamic anchoring 129 concept is introduced, which means that the mobile node can have 130 multiple mobility anchor points. Then, the mobile node can select a 131 locally allocated IP address for newly launched applications for 132 optimized routing. When the application continues communications 133 while the mobile node moves to a new point of attachment, the mobile 134 node can nevertheless stilluse the IP address allocated by previous 135 anchor point for the on going communications. When the application 136 terminates, the mobile node will release the IP address allocated by 137 the previous anchor point. 139 In the dynamic anchoring scenario, the newly started application 140 should use an IP address allocated by the local mobility anchor. The 141 application can use IPV6_PREFER_SRC_LOCAL_HNP flag to select the 142 local allocated IP address. For more long-lived communications, the 143 application can use IPV6_PREFER_SRC_REMOTE_HNP flag to select the 144 home address allocated by the previous mobility anchor to enable 145 session continuity. 147 5. IANA Considerations 149 This document makes no request of IANA. 151 Note to RFC Editor: this section may be removed on publication as an 152 RFC. 154 6. Security Considerations 156 TBD 158 7. Acknowledgements 160 TBD 162 8. References 164 8.1. Normative References 166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 167 Requirement Levels", BCP 14, RFC 2119, March 1997. 169 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 170 Socket API for Source Address Selection", RFC 5014, 171 September 2007. 173 8.2. Informative References 175 [I-D.draft-bhandari-dhc-class-based-prefix-04] 176 , "DHCPv6 class based prefix ", draft-bhandari-dhc-class- 177 based-prefix-04 (work in progress), February 2013. 179 [I-D.draft-ietf-dmm-best-practices-gap-analysis-01] 180 , "Distributed Mobility Management: Current practices and 181 gap analysis ", draft-ietf-dmm-best-practices-gap- 182 analysis-01 (work in progress), June 2013. 184 [I-D.draft-korhonen-6man-prfix-properties] 185 , "IPv6 Prefix Properties", draft-korhonen-6man-prfix- 186 properties (work in progress), February 2013. 188 [I-D.draft-seite-dmm-dma-06] 189 , "Distributed Mobility Anchoring", draft-seite-dmm-dma-06 190 (work in progress), Nov 2013. 192 Authors' Addresses 194 Dapeng Liu 195 China Mobile 196 32 Xuanwumen West Street 197 Beijng, Xicheng District 100053 198 China 200 Phone: +86-13911788933 201 Email: liudapeng@chinamobile.com 203 Hui Deng 204 China Mobile 205 32 Xuanwumen West Street 206 Beijng, Xicheng District 100053 207 China 209 Email: denghui@chinamobile.com 211 Charles E. Perkins 212 Futurewei Inc. 213 2330 Central Expressway 214 Santa Clara, CA 95050 215 USA 217 Phone: +1-408-330-5305 218 Email: charliep@computer.org