One document matched: draft-korhonen-dmm-prefix-properties-00.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'>
]>
<?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-00.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>
<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). 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). 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>[Discussion: explain the background and subsequently the motivation, which lead to "coloring" prefixes, and what we expect to gain from this extension to IPv6 addressing & neighbor discovery protocol. To be written later.]
</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
flag bits describing the mobility 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| C | Rsvd1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t><list style="hanging" hangIndent="4">
<t hangText="'C'">2-bit flag field describing the mobility properties of the prefix. The following properties are defined:
<list style="hanging">
<t hangText="00">No specific property associated to the prefix.
The prefix is treated according to RFC4861.</t>
<t hangText="01">The prefix provides network based mobility and
will remain unchanged at the valid lifetime of the prefix.</t>
<t hangText="10">The prefix provides network based mobility but
only within a limited area, thus the end host must be prepared
that the prefix may become invalid before the valid or even the preferred lifetime expire.</t>
<t hangText="11">Reserved. Treated as '00' by the receiver.</t>
</list>
</t>
</list>
</t>
<t>A common use case is to define 'C' flags when the 'A'=1 i.e. when Stateless Address AutoConfiguration (SLAAC) is used. However, it is possible to associate 'C' flags also to prefixes when 'A'=0. In cases when there are multiple learned prefixes with 'C' flags set to a non-zero value that can also be aggregated, then the longest prefix takes precedence.
</t>
</section>
<section title="Host Considerations">
<section title="Internal Data Structures">
<t>The host internal data structures need to be extended with 'mobility property' flag 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="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 'mobility property' flags are only used as a hint. They do not affect the existing <xref target="RFC3484"/> 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 <xref target="api"/>), which means the socket library or middleware has to modify <xref target="RFC3484"/> policy table or algorithm.
</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 (2 bit 'C' flag) to the IPv6 Neighbor Discovery protocol's Prefix Information Option <xref target="RFC4861"/>.
</t>
</section>
<!--section title="Acknowledgements">
<t>We ack.
</t>
</section-->
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4861;
&RFC3484;
</references>
<references title="Informative References">
&RFC5014;
&RFC3493;
&RFC6275;
&RFC4191;
&RFC3971;
&RFC5213;
&RFC3549;
<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>
<section title="Additions to the Socket Interface and the Protocol-Independent Nodename Translation" anchor="api">
<t>Following sections are for informational and discussion purposes only.</t>
<t>This specification also describes non-normative extensions to both Socket Interface <xref target="RFC3493"/><xref target="RFC5014"/> and the Protocol-Independent Nodename Translation <xref target="RFC5014"/>. These socket APIs and DNS resolver APIs extension correspond to the Prefix Information option mobility properties flag bit settings.
</t>
<section title="Socket Interface">
<t>This specification extends the socket option IPV6_ADDR_PREFERENCES at the IPPROTO_IPV6 level. The following new flags are defined to query, alter or set the default rule of source address selection rules <xref target="RFC3484"/>. They are also defined as a result of including
the <netinet/in.h> header:
<list style="hanging" hangIndent="24">
<t hangText="IPV6_PREFER_SRC_HNP"> /* Prefer Home Network Prefix derived IPv6 address as source */</t>
<t hangText="IPV6_PREFER_SRC_HNP_TMP"> /* Prefer temoporary Home Network Prefix derived IPv6 address as source */</t>
</list>
</t>
</section>
<section title="Protocol-Independent Nodename Translation">
<t>the Default Address Selection <xref target="RFC3484"/> document
indicates possible implementation strategies for getaddrinfo(). The address selection hint flags for the getaddrinfo() specificed in this document extend the 'int ai_eflags' field in the struct addrinfo <xref target="RFC5014"/><xref target="RFC3493"/>.
</t>
<t>The IPV6 source address preference values (IPV6_PREFER_SRC_HNP and IPV6_PREFER_SRC_HNP_TMP) defined for the IPV6_ADDR_PREFERENCES socket option are also defined as address selection preference flags in <netdb.h> header for the "ai_eflags" extended flag-set field of the addrinfo data structure.
</t>
<t>Similarly to <xref target="RFC5014"/>, if contradictory flags, such as IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_HNP*, are set in ai_eflags, the getaddrinfo() fails
and returns the value EAI_BADEXTFLAGS. This error value MUST be interpreted
into a descriptive text string when passed to the gai_strerror() function <xref target="RFC3493"/>.
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:15:20 |