idnits 2.17.1 draft-moses-dmm-dhcp-ondemand-mobility-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 127 has weird spacing: '...ce-type one ...' -- The document date (June 17, 2015) is 3230 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) == Missing Reference: 'TBD' is mentioned on line 316, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-00 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group D. Moses 3 Internet-Draft Intel 4 Intended status: Standards Track A. Yegin 5 Expires: December 19, 2015 June 17, 2015 7 DHCPv6 Extension for On Demand Mobility exposure 8 draft-moses-dmm-dhcp-ondemand-mobility-01 10 Abstract 12 Applications differ with respect to whether or not they need IP 13 session continuity and/or IP address reachability. Networks 14 providing the same type of service to any mobile host and any 15 application running on the host yields inefficiencies. This document 16 describes extensions to the DHCPv6 protocol to enable mobile hosts to 17 indicate the required mobility service type associated with a 18 requested IP address, and networks to indicate the type of mobility 19 service associated with the allocated IP address in return. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 19, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 57 3. IPv6 Continuity Service Option . . . . . . . . . . . . . . . 3 58 3.1. Source IPv6 Address Type Specification . . . . . . . . . 4 59 3.2. IPv6 Prefix Type Specification . . . . . . . . . . . . . 5 60 4. Anchor Preference Option . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 7.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 [I-D.ietf-dmm-ondemand-mobility] defines different types of mobility- 71 associated services provided by access networks to mobile hosts with 72 regards to maintaining IPv6 address continuity after an event of the 73 host moving to different locations with different points of 74 attachments within the IP network topology. It further specifies 75 means for applications to convey to the IP stack in the mobile host, 76 their requirements regarding these services. 78 This document defines extensions to the DHCPv6 protocol ([RFC3315]) 79 in the form of a new DHCP option that specifies the type of mobility 80 services associated with an IPv6 address. The IP stack in a mobile 81 host uses the DHCP client to communicate the type of mobility service 82 it wishes to receive from the network. The DHCP server in the 83 network uses this option to convey the type of service that is 84 guaranteed with the assigned IPv6 address in return. 86 This new option also extends the ability of mobile routers to specify 87 desired mobility service in a request for IPv6 proxies (as specified 88 in [RFC3633]), and delegating routers to convey the type of mobility 89 service that is committed with the allocated IPv6 proxies in return. 91 In a distributed mobility management environment, there are multiple 92 Mobility Anchors (as specified in [TBD reference to the Distributed 93 Mobility Management architecture RFC]). In some use-cases, mobile 94 hosts may wish to indicate to the network, preference of the serving 95 Mobility Anchor. This document specifies a new DHCPv6 option that is 96 used by DHCPv6 clients to convey this preference. 98 2. Notational Conventions 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. IPv6 Continuity Service Option 106 The IPv6 Continuity Service option is used to specify the type of 107 continuity service associated with a source IPv6 address or IPv6 108 prefix. The IPv6 Continuity Service option must be encapsulated in 109 the IAaddr-options field of the IA Address option when associated 110 with an IPv6 address, and in the IAprefix-options field of the IA_PD 111 prefix option when associated with an IPv6 prefix. 113 The format of the IPv6 Continuity Service option is: 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | OPTION_IPv6_CONTINUITY_SERVICE| option-length | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | service-type | 121 +-+-+-+-+-+-+-+-+ 123 option-code OPTION_IPv6_CONTINUITY_SERVICE (TBD) 125 option-len 1 127 service-type one of the following values: 129 Nomadic - a nomadic address or prefix (1) 131 Sustained - a sustained address or prefix (2) 133 Fixed - a fixed address or prefix (3) 135 Anytype - Anyone of the above (0) 137 This option can appear in one of two contexts: (1) As part of a 138 request to assign a source IPv6 address of the specified mobility 139 service type, and (2) As part of a request to assign an IPv6 prefix 140 of the specified mobility service type. 142 3.1. Source IPv6 Address Type Specification 144 In this context, the IPv6 Continuity Service option is encapsulated 145 in the IAaddr-options field of the IA Address option. 147 When in a message sent from a client to a server, the value of the 148 IPv6 Continuity Service option indicates the type of continuity 149 service required for the IPv6 address requested by the client. 151 When in a message sent from a server to a client, the value of the 152 IPv6 Continuity Service option indicates the type of IP continuity 153 service committed by the network for the associated IPv6 address. 154 The value 'AnyType' cannot appear in a message sent from the server. 156 Once an IPv6 address type was requested and provided, any subsequent 157 messages involving this address (lease renewal - for example) must 158 include the IPv6 Continuity Service option with the same service type 159 that was assigned by the server during the initial allocation. 161 If a server received a request to assign an IPv6 address with a 162 specified IPv6 Continuity service, but cannot fulfill the request, it 163 must reply with the [TBD] status. 165 A server that does not support this option will discard it as well as 166 the IA Address option that had this option encapsulated in one of its 167 IAaddr-options field. 169 If a client does not receive the requested address, it must resent 170 the request without the desired IPv6 Continuity Service option since 171 it is not supported by the server. In that case, the host of the 172 client cannot assume any IP continuity service behaviour for that 173 address. 175 A server must not include the IPv6 Continuity Service option in the 176 IAaddr-options field of an IA Address option, if not specifically 177 requested previously by the client to which it is sending a message. 179 If a client receives an IA Address option from a server with the IPv6 180 Continuity Service option in the IAaddr-options field, without 181 initially requesting a specific service using this option, it must 182 discard the received IPv6 address. 184 If the mobile host has no preference regarding the type of continuity 185 service it uses the 'AnyType' value as the specified type of 186 continuity service. The Server will allocate an IPv6 address with 187 some continuity service and must specify the type in IPv6 Continuity 188 Service option encapsulated in the IAaddr-options field of the IA 189 Address option. The method for selecting the type of continuity 190 service is outside the scope of this specification. 192 3.2. IPv6 Prefix Type Specification 194 In this context, the IPv6 Continuity Service option is encapsulated 195 in the IAprefix-options field of the IA_PD prefix option. 197 When in a message sent from a client to a server, the value of the 198 IPv6 Continuity Service option indicates the type of continuity 199 service required for the IPv6 prefix requested by the client. 201 When in a message sent from a server to a client, the value of the 202 IPv6 Continuity Service option indicates the type of continuity 203 service committed by the network for the associated IPv6 prefix. The 204 value 'AnyType' cannot appear in a message sent from the server. 206 Once an IPv6 prefix type was requested and provided, any subsequent 207 messages involving this prefix (lease renewal - for example) must 208 include the IPv6 Continuity Service option with the same service type 209 that was assigned by the server during the initial allocation. 211 If a server received a request to assign an IPv6 prefix with a 212 specified IPv6 Continuity service, but cannot fulfill the request, it 213 must reply with the [TBD] status. 215 A server that does not support this option will discard it as well as 216 the IA_PD Prefix option that had this option encapsulated in one of 217 its IAprefix-options field. 219 If a client does not receive the requested prefix, it must resent the 220 request without the desired IPv6 Continuity Service option since it 221 is not supported by the server. In that case, the mobile router of 222 the client cannot assume any IP continuity service behaviour for that 223 prefix. 225 A server must not include the IPv6 Continuity Service option in the 226 IAprefix-options field of an IA_PD Prefix option, if not specifically 227 requested previously by the client to which it is sending a message. 229 If a client receives an IA_PD Prefix option from a server with the 230 IPv6 Continuity Service option in the IAprefix-options field, without 231 initially requesting a specific service using this option, it must 232 discard the received IPv6 prefix. 234 If the mobile router has no preference regarding the type of 235 continuity service it uses the 'AnyType' value as the specified type 236 of continuity service. The Server will allocate an IPv6 prefix with 237 some continuity service and must specify the type in IPv6 Continuity 238 Service option encapsulated in the IAprefix-options field of the 239 IA_PD Prefix option. The method for selecting the type of continuity 240 service is outside the scope of this specification. 242 4. Anchor Preference Option 244 In a distributed mobility management environment that deploys 245 multiple Mobility Anchors, each Mobility Anchor may have a set of 246 IPv6 prefixes that is being used when assigning Sustained or Fixed 247 source IPv6 addresses to hosts. 249 The selection of the Mobility Anchor that will serve a mobile host is 250 performed by the network at various events like, the event of initial 251 attachment of a mobile host to a network. 253 The Anchor Preference option enables a host to express its desire to 254 receive a source IPv6 address with a specific IPv6 prefix. This is 255 useful when the mobile host wishes to indicate to the network which 256 Mobility Anchor should be used for anchoring its traffic and ensuring 257 service continuity in the event of handoff between LANs with 258 different IPv6 prefixes. 260 The network MAY respect this request but is not required to do so. 262 The format of the Anchor Preference option is: 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | OPTION_ANCHOR_PREFERENCE | option-length | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | preferred-lifetime | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | prefix-length | | 272 +-+-+-+-+-+-+-+-+ IPv6 prefix | 273 | (16 octets) | 274 | | 275 | | 276 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | | | 278 +-+-+-+-+-+-+-+-+ | 279 | IAanchor_preference-options | 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 option-code OPTION_ANCHOR_PREFERENCE (TBD) 284 option-len 25 + length of anchor_preference-options field 286 preferred-lifetime The preferred lifetime of the IPv6 address whose 287 prefix is requested, expressed in units of seconds 289 prefix-length The length of this prefix in bits 291 IPv6 prefix The requested prefix 293 IAanchor_preference-option Options associated with this request 295 This option is used by the client in a request for a new IPv6 source 296 address. The server replies with an IPv6 address that may or may not 297 have the desired prefix. Subsequent interactions between the client 298 and server regarding this address, must use the the IA address 299 option. 301 An IPv6 prefix is requested only when the mobile host wishes to be 302 anchored by a specific mobility anchor. The client must also 303 indicate the type of mobility service it requires using the IPv6 304 Continuity Service option encapsulated in the IAanchor_preference- 305 options field of the IA Address option. 307 When requesting an IPv6 prefix, only the 'Sustained' and 'fixed' 308 types are legal. 310 The server must assign the IPv6 address of the requested type to the 311 client, even if it does not fulfill the request for the specified 312 prefix. 314 If a server received a request to use a specific IPv6 prefix and an 315 IPv6 address type, but cannot assign an IPv6 address with that 316 specified IPv6 Continuity it must reply with the [TBD] status. 318 A server that does not support this option will discard it. 320 If a client does not receive any address, it must assume that the the 321 option is not supported by the server and use the IA Address option 322 in subsequent requests. 324 5. Security Considerations 326 There are no specific security considerations for this option. 328 6. IANA Considerations 330 TBD 332 7. References 334 7.1. Normative References 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, March 1997. 339 7.2. Informative References 341 [I-D.ietf-dmm-ondemand-mobility] 342 Yegin, A., Kweon, K., Lee, J., Park, J., and D. Moses, "On 343 Demand Mobility Management", draft-ietf-dmm-ondemand- 344 mobility-00 (work in progress), May 2015. 346 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 347 and M. Carney, "Dynamic Host Configuration Protocol for 348 IPv6 (DHCPv6)", RFC 3315, July 2003. 350 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 351 Host Configuration Protocol (DHCP) version 6", RFC 3633, 352 December 2003. 354 Authors' Addresses 356 Danny Moses 357 Intel 358 Petah Tikva 359 Israel 361 Email: danny.moses@intel.com 363 Alper Yegin 364 Istanbul 365 Turkey 367 Email: alper.yegin@yegin.org