One document matched: draft-korhonen-dmm-prefix-properties-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC3493 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3493.xml'>
<!ENTITY RFC4861 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml'>
<!ENTITY RFC3484 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml'>
<!ENTITY RFC5014 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5014.xml'>
<!ENTITY RFC6059 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6059.xml'>
<!ENTITY RFC6275 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6275.xml'>
<!ENTITY RFC3971 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml'>
<!ENTITY RFC4191 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4191.xml'>
<!ENTITY RFC3549 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3549.xml'>
<!ENTITY RFC5213 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml'>
<!ENTITY RFC5226 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
<!ENTITY RFC3484BIS PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-rfc3484bis.xml'>
<!ENTITY API PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.liu-dmm-mobility-api.xml'>
<!ENTITY CLASS PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bhandari-dhc-class-based-prefix.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc autobreaks="yes" ?>
<rfc category="std" ipr="trust200902"
updates="4861"
docName="draft-korhonen-dmm-prefix-properties-02.txt">
<front>
<title abbrev="IPv6 Prefix Properties">IPv6 Prefix Mobility Management Properties</title>
<author initials='J.' surname="Korhonen" fullname='Jouni Korhonen'>
<organization abbrev="Nokia Siemens Networks">Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<code>FIN-02600 Espoo</code>
<country>Finland</country>
</postal>
<email>jouni.nospam@gmail.com</email>
</address>
</author>
<author initials="B" surname="Patil" fullname="Basavaraj Patil">
<organization>Nokia</organization>
<address>
<postal>
<street>6021 Connection Drive</street>
<city>Irving,</city>
<code>TX 75039</code>
<country>USA</country>
</postal>
<email>basavaraj.patil@nokia.com</email>
</address>
</author>
<author fullname="Sri Gundavelli" initials="S" surname="Gundavelli">
<organization abbrev="">Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>sgundave@cisco.com</email>
</address>
</author>
<author fullname="Pierrick Seite" initials="P." surname="Seite">
<organization>France Telecom - Orange</organization>
<address>
<postal>
<street>4, rue du Clos Courtel, BP 91226</street>
<city>Cesson-Sevigne</city>
<code>35512</code>
<country>France</country>
</postal>
<email>pierrick.seite@orange.com</email>
</address>
</author>
<author fullname="Dapeng Liu" initials="D." surname="Liu">
<organization>China Mobile</organization>
<address>
<postal>
<street>32 Xuanwumen West Street</street>
<city>Beijng, Xicheng District</city>
<code>100053</code>
<country>China</country>
</postal>
<email>liudapeng@chinamobile.com</email>
</address>
</author>
<date year="2012"/>
<area>Internet</area>
<workgroup>Distributed Mobility Management (DMM)</workgroup>
<abstract>
<t>This specification defines an extension to the IPv6 Neighbor Discovery protocol and its Prefix Information Option. The Prefix Information Option is extended with flag bits that describe the mobility management properties associated to the prefix. This specification updates RFC4861.
</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>This specification defines an extension to the IPv6 Neighbor Discovery
protocol and its Prefix Information Option (PIO) <xref target="RFC4861"/>.
The Prefix Information Option is extended with flag bits that describe the
mobility management properties associated to the prefix, and at the same
time defines corresponding source address selection hint flags to the IPv6
Socket API for Source Address Selection <xref target="RFC5014"/>.
</t>
<t>The IPv6 Socket API for Source Address Selection <xref target="RFC5014"/>
already covers Mobile IPv6 <xref target="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.
</t>
<t>The extensions to <xref target="RFC4861"/> are minimal in a sense that
they do not define new functionality to any existing mobility protocol but
instead add an explicit indication of network based mobility knowledge into
the IPv6 stateless address autoconfiguration (SLAAC).
</t>
<t>This would allow for network based mobility solutions, such as Proxy
Mobile IPv6 <xref target="RFC5213"/> or GTP <xref target="TS.29274"/> to
explicitly indicate that their prefixes have mobility, and therefore, the MN
IP stack can make an educated selection between prefixes that have mobility
and those that do not. There is also a potential need to extend both <xref
target="RFC3493"/> and <xref target="RFC5014"/> in order to provide required
hooks into socket APIs.
</t>
<t>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.
</t>
</section>
<section title="Background and Motivation">
<t>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.
</t>
<t>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. This specification provides extensions to IPv6 address management and source address selection so that end hosts (and their applications) can select a proper address for their needs.
</t>
<t>This specification also shares similar motivations for classifying the
prefix properties as described in <xref target="I-D.bhandari-dhc-class-based-prefix"/>.
</t>
</section>
<section title="Option Formats" anchor="options">
<t>Neighbor Discovery messages include zero or more options, some of
which may appear multiple times in the same message. Options should
be padded when necessary to ensure that they end on their natural
64-bit boundaries. <xref target="pref"/> illustrates a Prefix
Information Option <xref target="RFC4861"/> that is extended with
a mobility and a security property flag bit, and a 'class' describing the
properties of the prefix:
<figure title="Extended Prefix Information Option" anchor="pref">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 | Prefix Length |L|A| Rsvd1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|S| Class | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t><list style="hanging" hangIndent="4">
<t hangText="'M'">1-bit flag describing the mobility properties of the prefix. The following properties are defined:
<list style="hanging">
<t hangText="0">No specific network based mobility property associated to
the prefix.
The prefix is treated according to RFC4861.</t>
<t hangText="1">The prefix provides network based mobility and
may remain unchanged the valid lifetime of the prefix.</t>
</list>
</t>
<t hangText="'S'">1-bit flag providing a hint of the security properties
associated to the used prefix. When set to '0' the prefix is assigned on an
interface whose network connectivity to the first-hop router does
not offer any kind of integrity or confidentiality guarantees.
When set to '1' the prefix is assigned to an interface whose network
connectivity offers some level of integrity or confidentiality guarantees
between the end host and the first-hop router.
For example, the interface could be associated with a VPN.
</t>
<t hangText="'Class'">14 bits of prefix class. The prefix class adds
complementary information to mobility and security properties, as also
described in <xref target="I-D.bhandari-dhc-class-based-prefix"/>. The
value '0' is reserved and stated nothing about the prefix. Unknown Class
is treated as value '0'.
</t>
</list>
</t>
<t>We call the combination of the 'M' flag, the 'S' flag and the 'class' as
the 'prefix property'.
</t>
<t>A common use case is to define the 'M' flag when the 'A'=1 i.e. when
Stateless Address AutoConfiguration (SLAAC) is used. However, it is possible
to associate the 'M' flag also to prefixes when 'A'=0. In cases when there
are multiple learned prefixes with the 'M' flag set to a non-zero value that
can also be aggregated, then the longest prefix takes precedence.
</t>
<t>If the prefix lifetime(s) is set to infinity that does not override the
prefix mobility properties indicated in the 'M' flag. For instance, a prefix
with an infinite lifetime but the 'M' flag set to '0' indicate that the
prefix may change abruptly due a handover at some point of time.
</t>
<t>A combination where all the 'M', 'S', and 'class' are set to zero ('0') is
reserved, and used to indicate that the PIO sender has not implemented the
extension specified in this document or does not want to state anything
regarding the PIO.
</t>
<t>Prefix class values from 8192 to 16367 are vendor specific. Class values
between 16368 and 16383 are reserved for private and experimental use.
</t>
</section>
<section title="Host Considerations">
<section title="Internal Data Structures">
<t>The host internal data structures need to be extended with the 'prefix
property' 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
mobility properties of an address or a prefix. One possibility is to
provide such information through the socket API extensions (see discussion
in <xref target="I-D.liu-dmm-mobility-api"/>). Other possibilities include
the use of e.g., ioctl() or NetLink <xref target="RFC3549"/> extensions.
</t>
</section>
<section title="Default Address Selection">
<t>The 'prefix property' information is only used as a hint.
They do not affect the existing <xref target="I-D.ietf-6man-rfc3484bis"/>
automatically, except for the 'M' flag as described later. 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 <xref target="I-D.liu-dmm-mobility-api"/>),
which means the socket library or middleware has to modify <xref
target="I-D.ietf-6man-rfc3484bis"/> policy table or algorithm.
</t>
<t>The 'M' flag defines the prefix preference for an IP stack that
understands the extensions defined in this specification. The IP stack
SHOULD use the following preferences to supersede <xref
target="I-D.ietf-6man-rfc3484bis"/> 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:
<list style="hanging" hangIndent="4">
<t hangText="0">Default preference.</t>
<t hangText="1">Low preference.</t>
</list>
</t>
</section>
</section>
<section title="Security Considerations">
<t>Existing Prefix Information Option related security considerations
apply as described in <xref target="RFC4861"/> and <xref target="RFC4191"/>.
A malicious node on the shared link could include such 'mobility property' flags in a Prefix Information Option 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 'mobility property' flags in a Prefix Information Option causing misguided selection of prefixes. In order to avoid on-link attacks, SeND <xref target="RFC3971"/> can be used to reject Router Advertisements from potentially malicious nodes and guarantee integrity protection of the Router Advertisements.
</t>
</section>
<section title="IANA Considerations">
<t><xref target="options"/> defines a new flag bits and fields to the IPv6 Neighbor Discovery protocol's Prefix Information Option <xref target="RFC4861"/>.
</t>
<t><xref target="options"/> creates a new 'prefix Class' registry under the
Internet Control Message Protocol version 6 (ICMPv6) Parameters registry.
Value 0 is reserved. Values from 1 to 8191 are allocated according to the
RFC Required policy <xref target="RFC5226"/>. Values between 8192 and 16367
have the First Come First Served allocation policy <xref target="RFC5226"/>.
Finally, values from 16368 to 16383 are reserved for Private Use <xref
target="RFC5226"/>.
</t>
</section>
<!--section title="Acknowledgements">
<t>We ack.
</t>
</section-->
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4861;
&RFC5226;
&RFC3484BIS;
</references>
<references title="Informative References">
&RFC5014;
&RFC3493;
&RFC6275;
&RFC4191;
&RFC3971;
&RFC5213;
&RFC3549;
&API;
&CLASS;
<reference anchor='TS.29274'>
<front>
<title>3GPP Evolved Packet System (EPS);
Evolved General Packet Radio Service (GPRS)
Tunnelling Protocol for Control plane (GTPv2-C)
</title>
<author><organization>3GPP</organization></author>
<date day='22' month='December' year='2010' />
</front>
<seriesInfo name='3GPP TS' value='29.060 8.11.0' />
<format type='HTML' target='http://www.3gpp.org/ftp/Specs/html-info/29060.htm' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:43:06 |