DHCPv6 Extension for On Demand Mobility exposureIntelPetah TikvaIsraeldanny.moses@intel.comIntelHillsboroUSAwu-chix.feng@intel.comIstanbulTurkeyalper.yegin@yegin.orgDMM Working GroupApplications 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 and to allow networks to indicate the type of mobility
service associated with the allocated IP prefix in return. defines different types of mobility-associated
services provided by access networks to mobile hosts with regards to maintaining IPv6
prefix continuity after an event of the host moving between 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
() and in the form of a new
DHCP option that specifies the type of mobility services associated with an IPv6 prefix.
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
in return. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 , when, they appear in all capitals,
as shown here.The IPv6 Continuity Service option is used to specify the type of continuity service associated
with a source IPv6 prefix. The IPv6 Continuity Service option MUST be encapsulated in the
IAprefix-options field of the IA_PD prefix option. The format of the IPv6 Continuity Service option is:OPTION_IPv6_CONTINUITY_SERVICE (TBD)1one of the following values:a non-persistent IP prefix (1)a session-lasting IP prefix (2)a fixed IP prefix (3)a graceful-replacement IP prefix (4)Anyone of the above (0)The definition of these service types is available in .All other values (5-255) are reserved for future use. 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.When a message is 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 a message is 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' SHOULD 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 is 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.If a server receives a request to assign an IPv6 prefix with a specified IPv6 Continuity
service, but cannot fulfill the request, it MUST reply with the NoPrefixAvail status.A server that does not support this option will ignore it and respond without taking into
account the desired session continuity service. The response will not include the Continuity
Service option encapsulated in the IAprefix-options field of the IA_PD prefix option.The missing Continuity Service option in the response serves as an indication to the
client that this feature is not supported by the server. It MAY use the allocated prefix
knowing it does not necessarily support the desired Continuity service, or perform any
other action.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. The values to be used in the Preferred-lifetime and Valid-lifetime fields in the IA Prefix
Option are out of the scope of this specification and left to implementation. It is RECOMMENDED
to provide longer lifetime values for Fixed and Session-lasting prefixes compared to the lifetime
values of Non-persistent and Graceful-replacement prefixes because the network has guaranteed
their validity regardless of the link to which the host is attached.For clients using Graceful-replacement services, the network MAY obsolete a Prefix and
allocate a new one from time to time especially in a mobility-related event. On such occasions,
the network SHOULD provide a graceful period (lifetime) in which the obsoleted prefix can
still be used and a new (longer) lifetime with the new prefix.It is NOT RECOMMENDED using 0xFFFFFFFFFF (infinity) values for the lifetime of Fixed
prefixes. Even though they are fixed, it is still safer to Rebind periodically. The lifetime
value can be relatively long to reduce message exchange overhead.Section 18.2 - Client Behavior of specifies
that when a client detects that it may have moved to a new link, it uses Rebind if it has
delegated prefixes. It is worth clarifying that a client does not HAVE to Rebind the prefixes
if they are Fixed or Session-lasting prefixes. There are no specific security considerations for this option.TBD