DMM Working Group D. Moses
Internet-Draft Intel
Intended status: Standards Track A. Yegin
Expires: August 11, 2017 February 7, 2017
DHCPv6 Extension for On Demand Mobility exposure
draft-moses-dmm-dhcp-ondemand-mobility-05
Abstract
Applications differ with respect to whether or not they need IP
session continuity and/or IP address reachability. Networks
providing the same type of service to any mobile host and any
application running on the host yields inefficiencies. This document
describes extensions to the DHCPv6 protocol to enable mobile hosts to
indicate the required mobility service type associated with a
requested IP prefix (or address), and networks to indicate the type
of mobility service associated with the allocated IP prefix (or
address) in return.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 11, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Moses & Yegin Expires August 11, 2017 [Page 1]
Internet-Draft DHCPv6 On-Demand Mobility Extension February 2017
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. IPv6 Continuity Service Option . . . . . . . . . . . . . . . 3
3.1. Source IPv6 Address Type Specification . . . . . . . . . 4
3.2. IPv6 Prefix Type Specification . . . . . . . . . . . . . 5
4. Anchor Preference Option . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
[I-D.ietf-dmm-ondemand-mobility] defines different types of mobility-
associated services provided by access networks to mobile hosts with
regards to maintaining IPv6 prefix (or address) continuity after an
event of the host moving to different locations with different points
of attachments within the IP network topology. It further specifies
means for applications to convey to the IP stack in the mobile host,
their requirements regarding these services.
This document defines extensions to the DHCPv6 protocol ([RFC3315])
in the form of a new DHCP option that specifies the type of mobility
services associated with an IPv6 prefix (or address). The IP stack
in a mobile host uses the DHCP client to communicate the type of
mobility service it wishes to receive from the network. The DHCP
server in the network uses this option to convey the type of service
that is guaranteed with the assigned IPv6 prefix (or address) in
return.
This new option also extends the ability of mobile routers to specify
desired mobility service in a request for IPv6 prefixes (as specified
in [RFC3633]), and delegating routers to convey the type of mobility
service that is committed with the allocated IPv6 prefixes in return.
It is important to note that although this document specifies
extensions to both IPv6 address and IPv6 prefix assignments, host
must follow the recommendations and guidelines listed in [RFC7934]
Moses & Yegin Expires August 11, 2017 [Page 2]
Internet-Draft DHCPv6 On-Demand Mobility Extension February 2017
and attempt to obtain IPv6 prefixes (rather than addresses) from the
network.
In a distributed mobility management environment, there are multiple
Mobility Anchors (as specified in
[I-D.ietf-dmm-distributed-mobility-anchoring]). In some use-cases,
mobile hosts may wish to indicate to the network, their preference of
the serving Mobility Anchor. This document specifies a new DHCPv6
option that is used by DHCPv6 clients to convey this preference.
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. IPv6 Continuity Service Option
The IPv6 Continuity Service option is used to specify the type of
continuity service associated with a source IPv6 address or IPv6
prefix. The IPv6 Continuity Service option must be encapsulated in
the IAaddr-options field of the IA Address option when associated
with an IPv6 address, and in the IAprefix-options field of the IA_PD
prefix option when associated with an IPv6 prefix.
The format of the IPv6 Continuity Service option is:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IPv6_CONTINUITY_SERVICE| option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| service-type |
+-+-+-+-+-+-+-+-+
option-code OPTION_IPv6_CONTINUITY_SERVICE (TBD)
option-len 1
service-type one of the following values:
Non-Persistent - a non-persistent IP address or
prefix (1)
Moses & Yegin Expires August 11, 2017 [Page 3]
Internet-Draft DHCPv6 On-Demand Mobility Extension February 2017
Session-Lasting - a session-lasting IP address or
prefix (2)
Fixed - a fixed IP address or prefix (3)
Anytype - Anyone of the above (0)
The definition of these service types is available in
[I-D.ietf-dmm-ondemand-mobility].
All other values (4-255) are reserved for future usage and should not
be used. If the OPTION_IPv6_CONTINUITY_SERVICE option is received
and its service-type is equal to one of the reserved values, the
option should be ignored.
This option can appear in one of two contexts: (1) As part of a
request to assign a source IPv6 address of the specified mobility
service type, and (2) As part of a request to assign an IPv6 prefix
of the specified mobility service type.
3.1. Source IPv6 Address Type Specification
In this context, the IPv6 Continuity Service option is encapsulated
in the IAaddr-options field of the IA Address option.
When in a message sent from a client to a server, the value of the
IPv6 Continuity Service option indicates the type of continuity
service required for the IPv6 address requested by the client.
When in a message sent from a server to a client, the value of the
IPv6 Continuity Service option indicates the type of IP continuity
service committed by the network for the associated IPv6 address.
The value 'AnyType' can only appear in the message sent from the
client to the server to indicate that the client has no specific
preference. However, it cannot appear in a message sent from the
server.
Once an IPv6 address type was requested and provided, any subsequent
messages involving this address (lease renewal - for example) must
include the IPv6 Continuity Service option with the same service type
that was assigned by the server during the initial allocation.
If a server received a request to assign an IPv6 address with a
specified IPv6 Continuity service, but cannot fulfill the request, it
must reply with the NoAddrsAvail status (refer to section 22.13 -
Status Code Option in [RFC3315].
Moses & Yegin Expires August 11, 2017 [Page 4]
Internet-Draft DHCPv6 On-Demand Mobility Extension February 2017
A server that does not support this option will discard it as well as
the IA Address option that had this option encapsulated in one of its
IAaddr-options field.
If a client does not receive the requested address, it must resend
the request without the desired IPv6 Continuity Service option since
it is not supported by the server. In that case, the host of the
client cannot assume any IP continuity service behaviour for that
address.
A server must not include the IPv6 Continuity Service option in the
IAaddr-options field of an IA Address option, if not specifically
requested previously by the client to which it is sending a message.
If a client receives an IA Address option from a server with the IPv6
Continuity Service option in the IAaddr-options field, without
initially requesting a specific service using this option, it must
discard the received IPv6 address.
If the mobile host has no preference regarding the type of continuity
service it uses the 'AnyType' value as the specified type of
continuity service. The Server will allocate an IPv6 address with
some continuity service and must specify the type in IPv6 Continuity
Service option encapsulated in the IAaddr-options field of the IA
Address option. The method for selecting the type of continuity
service is outside the scope of this specification.
3.2. IPv6 Prefix Type Specification
In this context, the IPv6 Continuity Service option is encapsulated
in the IAprefix-options field of the IA_PD prefix option.
When in a message sent from a client to a server, the value of the
IPv6 Continuity Service option indicates the type of continuity
service required for the IPv6 prefix requested by the client.
When in a message sent from a server to a client, the value of the
IPv6 Continuity Service option indicates the type of continuity
service committed by the network for the associated IPv6 prefix. The
value 'AnyType' can only appear in the message sent from the client
to the server to indicate that the client has no specific preference.
However, it cannot appear in a message sent from the server.
Once an IPv6 prefix type was requested and provided, any subsequent
messages involving this prefix (lease renewal - for example) must
include the IPv6 Continuity Service option with the same service type
that was assigned by the server during the initial allocation.
Moses & Yegin Expires August 11, 2017 [Page 5]
Internet-Draft DHCPv6 On-Demand Mobility Extension February 2017
If a server received a request to assign an IPv6 prefix with a
specified IPv6 Continuity service, but cannot fulfill the request, it
must reply with the NoAddrsAvail status.
A server that does not support this option will discard it as well as
the IA_PD Prefix option that had this option encapsulated in one of
its IAprefix-options field.
If a client does not receive the requested prefix, it must resend the
request without the desired IPv6 Continuity Service option since it
is not supported by the server. In that case, the requesting device
(host or router) cannot assume any IP continuity service behaviour
for that prefix.
A server must not include the IPv6 Continuity Service option in the
IAprefix-options field of an IA_PD Prefix option, if not specifically
requested previously by the client to which it is sending a message.
If a client receives an IA_PD Prefix option from a server with the
IPv6 Continuity Service option in the IAprefix-options field, without
initially requesting a specific service using this option, it must
discard the received IPv6 prefix.
If the mobile device (host or router) has no preference regarding the
type of continuity service it uses the 'AnyType' value as the
specified type of continuity service. The Server will allocate an
IPv6 prefix with some continuity service and must specify the type in
IPv6 Continuity Service option encapsulated in the IAprefix-options
field of the IA_PD Prefix option. The method for selecting the type
of continuity service is outside the scope of this specification.
4. Anchor Preference Option
In a distributed mobility management environment that deploys
multiple Mobility Anchors, each Mobility Anchor may have a set of
IPv6 prefixes that is being used when assigning Session-lasting or
Fixed source IPv6 prefixes (or addresses) to hosts.
The selection of the Mobility Anchor that will serve a mobile host is
performed by the network at various events like, the event of initial
attachment of a mobile host to a network.
The Anchor Preference option enables a host to express its desire to
receive a specific source IPv6 prefix (or a source IP address with
that specifc prefix). This is useful when the mobile host wishes to
indicate to the network which Mobility Anchor should be used for
anchoring its traffic and ensuring service continuity in the event of
handoff between LANs with different IPv6 prefixes.
Moses & Yegin Expires August 11, 2017 [Page 6]
Internet-Draft DHCPv6 On-Demand Mobility Extension February 2017
The network MAY respect this request but is not required to do so.
The format of the Anchor Preference option is:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ANCHOR_PREFERENCE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix6len | ipv6-prefix |
+-+-+-+-+-+-+-+-+ (variable length) |
. .
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAanchor_preference-options |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_ANCHOR_PREFERENCE (TBD)
option-len 5 + length of ipv6-prefix field + length of
anchor_preference-options field
preferred-lifetime The preferred lifetime of the IPv6 address whose
prefix is requested, expressed in units of seconds
prefix-length The length in bits of the ipv6-prefix. Typically
allowed values are 0 to 128.
IPv6 prefix This is a variable length field that specifies the
desired ipv6 prefix. The length is (prefix6len + 7) /
8. This field is padded with 0 bits up to the nearest
octet boundary when prefix6len is not divisible by 8.
IAanchor_preference-option Options associated with this request
An IPv6 prefix (or address) is requested only when the mobile host
wishes to be anchored by a specific mobility anchor. The client must
also indicate the type of mobility service it requires using the IPv6
Continuity Service option encapsulated in the IAanchor_preference-
options field of the IA_PD Prefix Option (or IA Address option - in
the case of requesting an IP address).
When requesting a specific IPv6 prefix, only the 'Session-Lasting'
and 'Fixed' types are legal. Non-Persistent prefixes do not require
anchoring and there is no motivation to request a specific anchor.
Moses & Yegin Expires August 11, 2017 [Page 7]
Internet-Draft DHCPv6 On-Demand Mobility Extension February 2017
If a server received a request to use a specific IPv6 prefix and an
IPv6 Continuity Service type, but cannot assign an IPv6 prefix (or
address) with that specified IPv6 Continuity Service it must reply
with the NoAddrsAvail status.
A server that does not support this option will discard it.
A server is not required to respect the prefix request. It can
assign a different prefix (or address) as long as it fulfills the IP
Continuity Service request.
If a client does not receive any address, it must assume that the the
option is not supported by the server and use the IA Address option
in subsequent requests.
5. Security Considerations
There are no specific security considerations for this option.
6. IANA Considerations
TBD
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References
[I-D.ietf-dmm-distributed-mobility-anchoring]
Chan, A., Wei, X., Lee, J., Jeon, S., Petrescu, A., and F.
Templin, "Distributed Mobility Anchoring", draft-ietf-dmm-
distributed-mobility-anchoring-03 (work in progress),
December 2016.
[I-D.ietf-dmm-ondemand-mobility]
Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S.
Jeon, "On Demand Mobility Management", draft-ietf-dmm-
ondemand-mobility-10 (work in progress), January 2017.
Moses & Yegin Expires August 11, 2017 [Page 8]
Internet-Draft DHCPv6 On-Demand Mobility Extension February 2017
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
DOI 10.17487/RFC3633, December 2003,
<http://www.rfc-editor.org/info/rfc3633>.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016,
<http://www.rfc-editor.org/info/rfc7934>.
Authors' Addresses
Danny Moses
Intel
Petah Tikva
Israel
Email: danny.moses@intel.com
Alper Yegin
Istanbul
Turkey
Email: alper.yegin@yegin.org
Moses & Yegin Expires August 11, 2017 [Page 9]