| Distributed Mobility Management (DMM) | J. Korhonen |
| Internet-Draft | Broadcom Corporation |
| Updates: 4862 (if approved) | S. Gundavelli |
| Intended status: Standards Track | Cisco |
| Expires: January 7, 2016 | P. Seite |
| Orange | |
| D. Liu | |
| Alibaba | |
| July 6, 2015 |
IPv6 Prefix Properties
draft-korhonen-dmm-prefix-properties-04.txt
This specification defines an extension to the IPv6 stateless address autoconfiguration procedure. New options with meta data are defined that describe the properties and other prefix class meta data associated with the prefix. The stateless address autoconfiguration procedure and end hosts can make use of the additional properties and class information when selecting source address prefixes for a particular uses and use cases. This specification updates RFC4862.
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 RFC 2119 [RFC2119].
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 January 7, 2016.
Copyright (c) 2015 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 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.
This specification defines a new neighbor discovery protocol message option, the Prefix Information Option with Meta Data (PIOMD), that indicate, for example, the mobility management properties associated to the prefix, and a class value that conveys metadata associated to the prefix with a local administrative domain wide importance. The solution may use of Multiple Provisioning Domains (MPVD) framework [RFC7556] [I-D.ietf-mif-mpvd-ndp-support]. Furthermore, the specification discusses corresponding source address selection hint issues with the IPv6 Socket API and applications in general [I-D.ietf-dmm-ondemand-mobility].
For example, the IPv6 Socket API for Source Address Selection [RFC5014] already covers Mobile IPv6 [RFC6275] and allows selecting between a home address (HoA) and a care-of address (CoA). A mobile node (MN) with a client based mobility IP stack is supposed to know which prefixes are CoA(s) and/or HoA(s). However, this is not the case with network based mobility management where the MN is expected to be agnostic of the mobility support.
The extensions are minimal in a sense that they do not define new functionality, for example, to any existing mobility protocol but instead add an explicit indication of network based mobility knowledge into the IPv6 stateless address autoconfiguration (SLAAC) [RFC4862]. The heavy lifting is mostly on the applications side and on the IP stack providing interface for applications, since they need to make use of the new functionality. The new functionality is achieved by defining a new, backward compatible, IPv6 neighbor discovery protocol options that convey the required prefix related meta data information the SLAAC procedure may take use of.
This would allow for network based mobility solutions, such as Proxy Mobile IPv6 [RFC5213] or GTP [TS.29274] to explicitly indicate that their prefixes have mobility, and therefore, the MN IP stack or specifically applications can make an educated selection between prefixes that have mobility and those that do not. There is also a potential need to extend both [RFC3493] and [RFC5014] in order to provide required hooks into socket APIs.
The underlying assumption is that a MN has multiple prefixes to choose from. Typically this means either the MN has multiple interfaces or an interface has been configured with multiple prefixes. This specification does not make a distinction between these alternatives and does not either make any assumptions how the possible transfer of a prefix is done between interfaces in the case a network based mobility solution is used.
This section discusses the motivations behind adding metadata and other address selection decision making affecting information into IPv6 prefixes. The additional information is conveyed from the network to a end host during the IPv6 address configuration phase. The motivation example taken from and discussed below is from the mobile networks.
IP mobility and its centralized topological anchoring of IP addresses has known issues. For instance, non-optimal routing is a classical example. Another concerns include excessive tunneling, increased signaling due the maintenance of mobility related bindings, aggregation of traffic to centralized mobility anchor gateways and unnecessary IP mobility related state management for IP traffic that does not as such benefit from mobility. In general, it is observed that most applications do not need IP level mobility, and work just fine with "temporary" IP addresses that come and go. However, IP mobility still has its virtues making the applications unaware of mobility, and certain wireless mobile networking architecture make extensive use of network based IP mobility.
In order to overcome some of the above issues, use of local resources and topologically local addressing could be enhanced. In many cases this would lead to use of multiple addresses of which some provide mobility and some do not. However, an end host has to have means to distinguish between addresses that provide mobility, and those that are short lived and usable only within a limited topological area.
[RFC7333] discussed the requirements for distributed mobility management and [RFC7429] describes the gaps from current best practices and the desired approaches for de-centralized mobility management. One approach is using the dynamic anchoring for distributed de-centralized mobility management. The idea is to use the local allocated prefix for any newly initiated 'IP session' and use the previously allocated prefix for the ongoing sessions. This specification can be used to implement the prefix selection for dynamic anchoring. For example, both the locally allocated and the remotely allocated/anchored prefixes can be identified by the prefix property option as described in Section 3.2.
The solution described in this document also shares similar motivations for classifying the prefix as described in [I-D.bhandari-dhc-class-based-prefix]. Some service providers may wish to allocate specific prefixes for some services or type of traffic. In this situation, the end host must be able to classify prefixes according to type of service.
This specification provides tools for extending the IPv6 address management and source address selection so that end hosts (and their applications) can select a proper address for their needs. This specification complements [I-D.bhandari-dhc-class-based-prefix] by providing the SLAAC version of the additional prefix related meta data information delivery compared to the DHCPv6 stateful approach.
This specification defines a new neighbor discovery protocol message option, the Prefix Information Option with Meta Data (PIOMD), to be used in router advertisement messages. The PIOMD is treated as the same as [RFC4861] Prefix Information Option (PIO) except with an addition of new meta data suboptions.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Suboptions :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Prefix Information Option with additional meta data
The PIOMD can coexist with RFC4861 PIO. The prefixes advertised in both PIOMD and PIO can even be the same. It is up to the receiving end host to select the appropriate prefix(es) for configuring its IPv6 addresses. In a case the PIO and the PIOMD share the same prefix, then all the other parameter (like flags and lifetimes) MUST be the same.
Rest of the fields are handled exactly as described in Section 4.6.2. of RFC4861 [RFC4861].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |C| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Generic meta data suboption format
The generic suboption format for the PIO with meta data (PIOMD) is shown in Figure 2. The suboption follows the alignment and length rules familiar from [RFC4861]. On a particular note, the flag 'C' describes whether the suboption is mandatory to understand by the receiver or not. If 'C' is set to zero (0), the receiver can silently discard an unknown suboption and skip to the next suboption. If 'C' is set to one (1), then an unknown suboption causes the receiver to silently discard the entire PIOMT and no further suboptions need to be parsed. There can be multiple instances of the same suboption type in one PIOMD option.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1 |C| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix properties | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Prefix Properties suboption
Figure 3 shows the Prefix Properties suboption. The prefix properties values are defined in Section 6.1. of [I-D.bhandari-dhc-class-based-prefix]. When an end host receives a router advertisement message with a PIOMD and the prefix properties suboption, it can use the suboption information as an additional hint for selecting the prefix for a desired purpose and use case. The prefix properties have global meaning i.e., they have the same treatment and handling cross administrative domains. The value for the 'C' flag SHOULD be one (1). This also implies that if the prefix properties bit vector has a flag bit set, which the receiving end host does not understand and the 'C' flag is also set, then the whole PIOMD option MUST be discarded.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 1 |C| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix class | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Prefix Class suboption
Figure 4 shows the Prefix Class suboption. The prefix class values and usage follow what has been defined in Section 2.3. of [I-D.bhandari-dhc-class-based-prefix]. When an end host receives a router advertisement message with a PIOMD and the prefix class suboption, it can use the suboption information as an additional hint for selecting the prefix for a desired purpose and use case. The prefix class has only local administrative meaning i.e., they are local to the access network and may overlap both semantically and registry wise across different administrative domains. How the boundaries of an administrative domain are determined is outside the scope of this specification. The value for the 'C' flag SHOULD be zero (0).
Future specifications MAY define new suboptions. One potential example could be a suboption to identify the provisioning domain where the configuration information originates.
This specification extends to the [RFC4862] Stateless Address Autoconfiguration (SLAAC). As described in Section 3.1, a new [RFC4861] PIO like option PIOMD can be used to either complement or entirely replace the PIO in a router advertisement. An end host that understands the PIOMD option MUST always prefer a prefix found in the PIOMD over the same prefix found in the PIO option.
The host internal data structures need to be extended with the 'prefix property' and the 'prefix class' information associated to the learned prefix and configured addresses. How this is accomplished is host implementation specific. It is also a host implementation issue how an application can learn or query both properties or class of an address or a prefix. One possibility is to provide such information through the socket API extensions (see discussion in [I-D.ietf-dmm-ondemand-mobility]). Other possibilities include the use of e.g., ioctl() or NetLink [RFC3549] extensions.
The 'prefix property' is only used as a hint. It does not affect the existing [RFC6724] automatically. A specific rule to host's policy table has to be inserted by an application or some daemon process. Alternatively, an application can express its address mobility property preferences through the socket API extensions (see discussion in [I-D.ietf-dmm-ondemand-mobility]), which means the socket library or middleware has to modify [RFC6724] policy table or algorithm.
The 'prefix properties' flags MAY define the prefix preference for an IP stack that understands the extensions defined in this specification. The IP stack SHOULD use the properties preferences to supersede [RFC6724] Source Address Selection Rule 8 when selecting a default source address among multiple choices and an application has not explicitly indicate what kind of source address it prefers.
The 'prefix class' defines an application 'class' the advertised prefix is intended to be used for. The class has only local administrative domain significance. The 'prefix class' can be used, for example, to identify prefixes that are meant to be used reach a voice over IP (VoIP) service or a video streaming application within the local administrative network. A specific application in the end host MAY use this additional class information when enumerating through multiple available addresses and then select a specific address to be used for its purposes.
A network administrator MAY configure routers complying to this specification also send router advertisements with the PIOMD option into every router advertisement that also contains the [RFC4861] PIO option. Since the PIOMD sending router has no prior knowledge whether the end hosts on the link support the PIOMD option, it is strongly RECOMMENDED that both [RFC4861] PIO and the PIOMD are always included in the router advertisement, even if the advertised prefixes were the same. Alternatively (or in addition) multiple provisioning domains [I-D.ietf-mif-mpvd-ndp-support] can be used to separate prefixes advertised using PIOMD options. See Section 6 for further details.
A router can also make use of the 'C' flag handling in the PIOMD suboptions when introducing new functionality into the network. Since it is possible to include multiple suboptions of the same type into the PIOMD option, the router can easily make a difference between e.g., prefix properties that must be understood by the receiver and those that can safely be ignored.
Multiple Provisioning Domains (MPVD) framework [RFC7556] allows grouping network configuration information under an explicitly named provisioning domain (which can be, for example, a Network Access Identifier (NAI) of the mobility service provider [I-D.ietf-mif-mpvd-id]). This would allow network operators to place mobility related configuration information (including prefixes) under specific explicit provisioning domains and non-mobile configuration information into other explicit domain or implicit provisioning domains.
MPVDs are the RECOMMENDED way to deliver PIOMD options. This allows mobile hosts to query for mobility related configuration information and network operators selectively advertise mobility related network configurations. MPVDs also provide adequate security features for mobile hosts to verify the authenticity of the configuration information. However, MPVD does not
Existing Prefix Information Option related security considerations apply as described in [RFC4861] and [RFC4191]. A malicious node on the shared link could include stale metadata in a PIOMD causing the host to learn wrong information regarding the prefix and thus make misguided selection of prefixes on the link. Similarly a malicious middleman on the link could modify or remove metadata in the PIOMD causing misguided selection of prefixes. In order to avoid on-link attacks, SeND [RFC3971] can be used to reject Router Advertisements from potentially malicious nodes and guarantee integrity protection of the Router Advertisements.
If MPVD support for NDP [I-D.ietf-mif-mpvd-ndp-support] is used, then the mobile host can use its security features to verify the authenticity and correctness of the received PIOMD information.
Section 3.1 defines a new IPv6 Neighbor Discovery protocol option type TBD1 for the Prefix Information Option with Meta Data. The type value is defined in the existing 'IPv6 Neighbor Discovery Option Formats' IANA registry.
Section 3.2 defines a new IANA registry for the Prefix Information Option with Meta Data suboptions. The registry allocation policy is Standards Action [RFC5226]. The initial allocations for the prefix properties and prefix class suboptions are listed in Section 3.2.
The authors thank Ole Troan for his feedback and suggestions on this document (the Classed PIO).