One document matched: draft-korhonen-dmm-prefix-properties-04.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 RFC4862 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.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 RFC6724 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6724.xml'>
<!ENTITY RFC7556 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7556.xml'>
<!ENTITY RFC7333 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7333.xml'>
<!ENTITY RFC7429 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7429.xml'>
<!ENTITY CLASS PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bhandari-dhc-class-based-prefix.xml">
<!ENTITY I-D.ietf-mif-mpvd-id PUBLIC ""
"http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mif-mpvd-id.xml">
<!ENTITY I-D.ietf-mif-mpvd-dhcp PUBLIC ""
"http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mif-mpvd-dhcp-support.xml">
<!ENTITY I-D.ietf-mif-mpvd-ndp PUBLIC ""
"http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mif-mpvd-ndp-support.xml">
<!ENTITY I-D.ietf-dmm-ondemand-mobility PUBLIC ""
"http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dmm-ondemand-mobility.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="4862"
docName="draft-korhonen-dmm-prefix-properties-04.txt">
<front>
<title abbrev="IPv6 Prefix Properties">IPv6 Prefix Properties</title>
<author initials='J.' surname="Korhonen" fullname='Jouni Korhonen'>
<organization abbrev="Broadcom Corporation">Broadcom Corporation</organization>
<address>
<postal>
<street>3151 Zanker Rd.</street>
<code>San Jose</code>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>jouni.nospam@gmail.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>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>Alibaba</organization>
<address>
<email>max.ldp@alibaba-inc.com</email>
</address>
</author>
<date year="2015"/>
<area>Internet</area>
<workgroup>Distributed Mobility Management (DMM)</workgroup>
<abstract>
<t>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.
</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 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 <xref target="RFC7556"/>
<xref target="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
<xref target="I-D.ietf-dmm-ondemand-mobility"/>.
</t>
<t>For example, 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 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) <xref
target="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.
</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 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 <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> 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.
</t>
<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.
</t>
<t><xref target="RFC7333"/> discussed the requirements for distributed
mobility management and <xref target="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 <xref target="suboptions"/>.
</t>
<t>The solution described in this document also shares similar motivations
for classifying the prefix as described in <xref
target="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.
</t>
<t>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 <xref
target="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.
</t>
</section>
<section title="Option Formats" anchor="options">
<section title="Prefix Meta Data" anchor="piomd">
<t>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 <xref target="RFC4861"/> Prefix Information Option (PIO)
except with an addition of new meta data suboptions.
</t>
<t>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.
<figure title="Prefix Information Option with additional meta data" anchor="fig_piomd">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Suboptions :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t><list style="hanging" hangIndent="4">
<t hangText="Type"><vspace blankLines="1"/>
Set to TBD1.
</t>
<t hangText="Length"><vspace blankLines="1"/>
4 if no suboptions are present. Greater than 4 if one or more suboptions
are present.
</t>
<t hangText="Suboptions"><vspace blankLines="1"/>
Zero or more suboptions that describe properties and other meta data
attached to the advertised prefix. See <xref target="suboptions"/> for
description of the meta data suboption format and suboptions already
defined in this specification. The existence of suboptions can be
determined from the length field. If the length is greater than 4, then
at least one suboption MUST be present.
</t>
</list>
</t>
<t>Rest of the fields are handled exactly as described in Section 4.6.2. of
RFC4861 <xref target="RFC4861"/>.
</t>
</section>
<section title="Meta Data Suboptions" anchor="suboptions">
<t>The generic suboption format for the PIO with meta data (PIOMD) is shown in
<xref target="mt_generic"/>. The suboption follows the alignment and
length rules familiar from <xref target="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.
<figure title="Generic meta data suboption format" anchor="mt_generic">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |C| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<!-- ============================================= -->
<t><xref target="mt_properties"/> shows the Prefix Properties suboption.
The prefix properties values are defined in Section 6.1. of
<xref target="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.
<figure title="Prefix Properties suboption" anchor="mt_properties">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1 |C| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix properties | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<!-- ============================================= -->
<t><xref target="mt_class"/> shows the Prefix Class suboption.
The prefix class values and usage follow what has been defined in Section
2.3. of <xref target="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).
<figure title="Prefix Class suboption" anchor="mt_class">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 1 |C| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix class | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>Future specifications MAY define new suboptions. One potential example
could be a suboption to identify the provisioning domain where the
configuration information originates.
</t>
</section>
</section>
<section title="Host Considerations">
<section title="Stateless Address Autoconfiguration Enhancements">
<t>This specification extends to the <xref target="RFC4862"/>
Stateless Address Autoconfiguration (SLAAC). As described in
<xref target="piomd"/>, a new <xref target="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.
</t>
</section>
<section title="Internal Data Structures">
<t>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 <xref target="I-D.ietf-dmm-ondemand-mobility"/>). 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' is only used as
a hint. It does not affect the existing <xref target="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 <xref target="I-D.ietf-dmm-ondemand-mobility"/>),
which means the socket library or middleware has to modify <xref
target="RFC6724"/> policy table or algorithm.
</t>
<t>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 <xref
target="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.
</t>
<t>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.
</t>
</section>
</section>
<section title="Router Considerations">
<t>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 <xref
target="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 <xref target="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 <xref target="I-D.ietf-mif-mpvd-ndp-support"/> can be used to
separate prefixes advertised using PIOMD options. See <xref target="mpvd"/>
for further details.</t>
<t>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. </t>
</section>
<section title="Multiple Provisioning Domain Considerations" anchor="mpvd">
<t>Multiple Provisioning Domains (MPVD) framework <xref target="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 <xref
target="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.
</t>
<t>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
</t>
</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 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
<xref target="RFC3971"/> can be used to reject Router Advertisements from
potentially malicious nodes and guarantee integrity protection of the Router
Advertisements. </t>
<t>If MPVD support for NDP <xref target="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.
</t>
</section>
<section title="IANA Considerations">
<t><xref target="piomd"/> 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.
</t>
<t><xref target="suboptions"/> defines a new IANA registry for the Prefix
Information Option with Meta Data suboptions. The registry allocation policy
is Standards Action <xref target="RFC5226"/>. The initial allocations
for the prefix properties and prefix class suboptions are listed in
<xref target="suboptions"/>.
</t>
</section>
<section title="Acknowledgements">
<t>The authors thank Ole Troan for his feedback and suggestions on this
document (the Classed PIO).
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4861;
&RFC4862;
&RFC6724;
&RFC5226;
&I-D.ietf-mif-mpvd-id;
&I-D.ietf-mif-mpvd-ndp;
</references>
<references title="Informational References">
&I-D.ietf-dmm-ondemand-mobility;
&RFC7556;
&RFC5014;
&RFC3493;
&RFC6275;
&RFC4191;
&RFC3971;
&RFC5213;
&RFC3549;
&RFC7333;
&RFC7429;
&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 09:14:13 |