One document matched: draft-tsirtsis-netext-controversy-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='../xml2rfc-1.33/rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="no" ?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "../xml2rfc-1.33/rfc2629.dtd" [
<!ENTITY rfc0792 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml'>
<!ENTITY rfc0894 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0894.xml'>
<!ENTITY rfc2004 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2004.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2225 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2225.xml'>
<!ENTITY rfc5226 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
<!ENTITY rfc3344 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3344.xml'>
<!ENTITY rfc3775 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml'>
<!ENTITY rfc4830 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4830.xml'>
<!ENTITY rfc4861 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml'>
<!ENTITY rfc4960 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml'>
<!ENTITY rfc5213 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml'>
]>
<rfc category="info" docName="draft-tsirtsis-netext-controversy-00.txt"
ipr="full3978">
<front>
<title abbrev="NETEXT">Discussion of Controversial PMIP Extensions</title>
<author initials="G." surname="Tsirtsis" fullname="George Tsirtsis">
<organization>Qualcomm</organization>
<address>
<email>tsirtsis@gmail.com</email>
</address>
</author>
<date month="April" year="2009"/>
<abstract>
<t>This document discusses the recent controversy regarding PMIP
extensions for inter-technology handoffs and multihoming. Many
of the arguments presented below have been discussed in NETEXT
BOF and subsequent discussions on the mailing list. They are
written here in an attempt to explain why some of the proposed
PMIP extensions are so controversial.</t>
</abstract>
</front>
<middle>
<section title="Requirements Notation">
<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"/>.</t>
</section>
<section title="Introduction">
<t>This document discusses the recent controversy regarding PMIP
extensions for inter-technology handoffs and multihoming. Many
of the arguments presented below have been discussed in NETEXT
BOF and subsequent discussions on the mailing list. They are
written here in an attempt to explain why some of the proposed
PMIP extensions are so controversial. </t>
<t>Following this introduction, the draft reminds readers of how
interfaces and hosts are normally viewed by network layer
protocols, in <xref target="IFs"/>, something that is important
to keep in mind while reading the rest of the document.</t>
<t>The draft then establishes what is currently wrong with <xref
target="RFC5213"/>, in <xref target="wrong"/>. The draft
specifically argues that:<list>
<t>-PMIPv6 is at best incomplete (and at worst fundamentally
broken) because it relies on parameters not available to
it by itself or by any other IETF defined protocols.
This affects its fundamental operation, in that: <list>
<t>a) for single interface mobile nodes it is only
applicable for some link layers.</t>
<t>b) inter-technology handoffs are broken since the
protocol does not define how a MAG/LMA knows
when two different link layer technologies are
somehow coupled at a given node, nor does it
define how the MAG knows if a MN is reachable
over a particular link layer. </t>
<t>c) The narrow support for multihoming is broken
since the protocol does not define how a MAG/LMA
knows when handoff vs new mobility session is to
be provided to the multiple interfaces.</t>
</list>
</t>
</list>
</t>
<t> The draft continues with outlining the controversial nature of
some of the proposed PMIP extensions, in <xref target="sig"/>.
The arguments presented can be summarized as follows: <list>
<t>a) To fix Inter-technology handoffs and to support
multihoming properly, MN involvement is required.</t>
<t>b) The MN involvement must be at the network layer (or
above), and must be defined by the IETF.</t>
<t>c) The need for (b) breaks the original reason for
defining PMIPv6 in the IETF i.e., a mobility management
protocol that does not require MN involvement.</t>
<t>d) If (c) is ignored, and PMIPv6 extensions are
considered then the following issues arise:<list>
<t>- The definition of an MN-MAG protocol,
essentially turns MAGs into FA-like entities;
but FAs were designed out of MIPv6 for many
reasons. Why do we need FA-like functionality
back and in what form?</t>
<t>- Such a protocol, would bring PMIPv6 in direct
competition with MIPv6, contributing to
undesirable proliferation of redundant tools in
the Internet, which requires justification that
is not currently available.</t>
</list>
</t>
</list>
</t>
<t>The fundamental question then becomes, if MN involvement is
unavoidable, and if such involvement has to be at network layer,
what is the justification for extending PMIPv6, when the whole
premise of PMIPv6 is "no MN involvement", and when MIPv6 fully
defines a protocol implementing these functions *with* MN
involvement?</t>
<t>The draft finally concludes, in <xref target="conc"/>, by first
arguing that the justification for the proposed work on PMIPv6
inter-technology and multihoming support, is nonexistent and
lists specific questions that need to be answered by the various
factions of the NETEXT community supporting this work (<xref
target="just"/>), and by then proposes a way forward for
PMIPv6 work (<xref target="future"/>).</t>
</section>
<section title="The Internet, the Interface, and the Host" anchor="IFs">
<t>This section provides some background on how "hosts" and
"interfaces" are viewed in network layer specifications of the
IETF. This context is important since a lot of the debate around
PMIPv6 centers around the nature, availability and awareness of
these entities at various places in the network e.g., MAGs
according to <xref target="RFC5213"/> have to regularly ask the
question: "Is interface X part of host Y, and associated with
Interface Z (i.e., are interfaces X and Y under the same virtual
interface?"</t>
<t> The Internet at the network layer has no notion of a host. The
end points of the Internet are IP Interfaces, identified by
lower layers as a link layer address (or other low layer
identifier) and by the higher layers by their IP addresses. The
link layer end point associated with a given interface can be
presumed to be on the same or different link with other such end
point interfaces, but it is mostly impossible to tell which of
these link layer end points are grouped under the same interface
and even harder to know which interfaces are grouped inside the
same computer unit (end node or host). Several protocols do that
but always at a higher layer (network or above) and always by
means of explicit signaling; see more on this in <xref
target="compl"/>. </t>
<!-- <t>The Internet is using the network layer as the Inter-networking
layer, which primary job is to offer a uniform base over which a
diverse range of transport protocols and applications have been
developed. The reason this Internetworking layer was successful
is its minimal set of requirements it sets to the lower layers
(e.g., <xref target="RFC0894"/>) combined with the uniform
simplicity it provides to all upper layers.</t> -->
<t> Each of the link layers on top of which IP can operate, in the
end represents an interface connected to a link over which the
Internet Protocol runs.</t>
<t>The basic IETF protocols defined for end node to access router
communications (e.g., <xref target="RFC0792"/> and <xref
target="RFC4861"/>), are link-specific and treat each link
layer end point on a given link, as an independent interface
with no concern of whether two interfaces are part of the same
node or not. For example <xref target="RFC4861"/> says: <list>
<t> " Routers and multihomed hosts have multiple interfaces.
The remainder of this document assumes that all sent and
received Neighbor Discovery messages refer to the
interface of appropriate context.... "</t>
</list>
</t>
<t>Indeed <xref target="RFC4861"/>, in Appendix A, also indicates
that NDP operation for multihomed nodes (on the same link) is
"not straightforward". The RFC discusses various implications of
same-link multihoming with respect to redirect and
load-balancing functions, and places the responsibility for
making this work on the end node which is the only entity that
really knows what interface configuration it has. The RFC of
course has nothing to say about multihomed nodes on different
links, since these are in fact invisible to the network layer.</t>
<t> It is therefore expected that the default behavior of any access
router is to treat each interface attaching to it as a distinct
entity, independent from all other interfaces. This is then, one
of the low level building blocks of the Internet i.e.,
individual, independent from each other, end-Interfaces. </t>
<t>On top of this low level infrastructure of interconnected end
points, however, it is still possible to create more complex
behaviors that are, importantly, explicitly signaled and thus,
do not interfere with the fundamental operation of the Internet
nor do they hinder the operation of simple nodes not equipped to
handle such additional complexity.<list>
<t>And this is where some of the controversy around PMIP
starts. </t>
</list>
</t>
</section>
<section title="What is wrong with PMIP so far" anchor="wrong">
<t>This section ignores any philosophical issue, of which the author
has many, against PMIP, and focuses on specific technical issues
that have to do with <xref target="RFC5213"/>.</t>
<t>Several technical issues are identified in following subsection,
after the following observations: <list>
<t>1) PMIP is at best incomplete (at worst fundamentally
broken), because it relies on information not available
by PMIP itself or any other network layer protocols
defined by the IETF. This is direct result of the 'no MN
involvement" assumption based on which the protocol was
built resulting in not defining an MN-MAG protocol at
the network layer.</t>
<t>2) PMIP for single interface mobiles can work for
specific link layers only i.e., when the link layer used
presents an identifier for the interface e.g., a MAC
address, and when these links allow the MAG to
explicitly identify an interface when it attaches to
them. </t>
<t>3) PMIP's Inter-technology handoff support suffers from
(1), but is also incomplete in the sense that <xref
target="RFC5213"/> does not define when two
different link layer technologies are somehow coupled at
a given node (e.g., under a given virtual interface).
Inter-technology handoff support breaks the
'no-MN-changes' clause of <xref target="RFC4830"/> since
it requires some form of virtual interface support in
the node, even if there is no MN-MAG protocol to be
implemented.</t>
<t>4) PMIP as defined in <xref target="RFC5213"/> supports
multihoming in a very narrow manner as defined in
section 5.4 of the RFC. It requires that, if two
interfaces of the same node attach to the same PMIP
domain there are two options; a) the two interfaces are
under the same mobility session in which case only one
can be used to forward traffic to at any one time, b)
the two interfaces belong to different mobility
sessions, in which case they are treated as interfaces
of different MNs (i.e., each has its own HoA and
associated binding state in the LMA). This is good, but
the PMIP protocol is again incomplete since it does not
define when (a) vs (b) is supposed to happen.</t>
</list>
</t>
<section title="Signaling for Complexity" anchor="compl">
<t>To maintain the Internet's integrity, while allowing for
arbitrarily complex behaviors, the way complexity is added
on top of the rather simple IP layer is by explicit
signaling of additional, more complex protocols. Here are
some relevant examples: <list>
<t>SCTP (<xref target="RFC4960"/>: binds multiple IP
addresses to the same transport layer pipe between
two end nodes</t>
<t>Mobile IP <xref target="RFC3344"/>, <xref
target="RFC3775"/>: binds a stable home address
to one (or more) temporary care-of addresses</t>
</list>
</t>
<t>What is important about these protocols is that they
explicitly signal their intentions.</t>
<t> SCTP is signaled end to end, the routers in the path are
oblivious to it, and the peer end node will accept an SCTP
pipe only if it also supports SCTP. The complexity of
handling multiple IP addresses as part of the same transport
pipe has, therefore, no impact on any node in the Internet
that does not support SCTP.</t>
<t>Even more relevant is the example of Mobile IP. End nodes
using Mobile IP enabled nodes (Mobile Nodes, Home Agents,
CNs, and Foreign Agents in MIPv4), all signal their
capabilities. MNs indeed explicitly signal their desire to
use Mobile IP which can be ignored or rejected automatically
reverting the Mobile Node to operations (with no Mobile IP
support). Thus, again, the Mobile IP family of protocols has
no impact on any node that does not also support Mobile IP.</t>
<t>In contrast, PMIPv6 <xref target="RFC5213"/> operates
differently. Similarly to Mobile IP it binds a stable home
address to one or more temporary MAG addresses. It does
that, however, without the explicit IETF-standardized
involvement of the MN. The next section discusses some
implications of this approach</t>
</section>
<section title="PMIP without Host Signaling">
<t>PMIP was created under the premise of no MN involvement. The
NETLMM charter
(http://www.ietf.org/html.charters/netlmm-charter.html)
clearly indicates: <list>
<t>"This working group is tasked with defining a
network-based local mobility management protocol,
where local IP mobility is handled without
involvement from the mobile node."</t>
</list>
</t>
<t>The "no MN involvement" clause was a fundamental part of
justifying the need for a new WG, since the IETF has already
defined a whole family of mobility management protocol "with
MN involvement", namely <xref target="RFC3344"/> and <xref
target="RFC3775"/> with all their extensions. </t>
<t>Given this "no MN involvement" clause, the solution protocol,
(PMIPv6) has to work within these confines resulting in the
following characteristics:</t>
<t>PMIP and Single-Interface end nodes <list>
<t>A single Interface node can operate in a PMIP domain
without significant problems. This is because when a
single interface is attached to a PMIP domain, the
end node is made to think it is essentially directly
connected to the LMA. If this interface is
disconnected from one MAG and connected to another
MAG, again the same illusion of direct connectivity
to the LMA is preserved.</t>
<t>Still, this only works for link layers that present
an appropriate interface identifier, e.g., a MAC
address. This allows MAGs (or actually LMAs) to
recognise a new link with a given MN as a link of a
given node handing-off from another MAG.</t>
</list>
</t>
<t>PMIP and a Multi-Interface end nodes <list>
<t>According to <xref target="RFC5213"/> a PMIP MAG
somehow has knowledge of whether an interface
connected to it falls under one of the following
categories, expressed in the form of a Handover Hint
defined in section 8.4 of the RFC. <list>
<t>1: Attachment over a new interface</t>
<t> 2: Handoff between two different interfaces
of the mobile node</t>
<t> 3: Handoff between mobile access gateways
for the same interface</t>
<t> 4: Handoff state unknown</t>
<t> 5: Handoff state not changed
(Re-registration) </t>
</list>
</t>
<!-- <t>The effects of getting this wrong are well known
e.g., it could result in allocating the same address
two different interfaces, which would break a number
of host implementations.</t> -->
</list>
</t>
<t> Unfortunately, <xref target="RFC5213"/> does not say how
this information is obtained. Lack of standardized signaling
for the determination of this parameter is causing
significant concerns. The concerns stem from the fact that
this determination will most likely take place according to
some proprietary solution that is not under the control of
the IETF and thus, it's accuracy across multiple link layers
is at best unpredictable. </t>
<t> PMIPv6 <xref target="RFC5213"/> attempts to instruct
implementers to correctly set the Handoff Indication
parameter but the protocol has no internal knowledge of how
to set this value. For example, 3GPP has defined layer 2
procedures (and assume other link layers support the same
layer 2 procedures) for the MN to indicate to the MAG the
Handover Hint. This is perfectly reasonable for a body that,
unlike the IETF, designs full systems and can place
requirement at any layer and entity of that system.</t>
<t>The IETF, however, has no way of ensuring that a MAG
implementation will behave appropriately, independently from
the Link Layer used between MN and MAG. This could easily
result in incompatibilities since each SDO specific system
tends to make assumptions that are not necessarily true, in
the general Internet. </t>
</section>
<section title="PMIP and Virtual Interfaces">
<t>An IP Interface is a software construct and as such can take
many forms. Many IP interfaces have a one to one
relationship with a physical interface e.g., an Ethernet
adaptor.</t>
<t>Almost as often, however, IP Interfaces are virtualized in
some way or another. Examples of such Virtual Interfaces are
IP in IP Tunnels, VPN Tunnels, Mobile IP Interfaces, and
PMIP interfaces.</t>
<t>All of these virtual interfaces, which are so common in IP
networks are either manually configured at the relevant ends
(e.g., IP in IP tunnels) or explicitly signaled by a
protocols e.g., a VPN client may use IKEv2 to established an
IPSEC tunnel, presenting, Mobile IP uses signaling to
establish a home address to care-of address binding etc.</t>
<t>What differentiates PMIP virtual interfaces, is that the
formation of a PMIP Interface is not explicitly communicated
to anyone at the network layer. It is assumed that MAGs
"somehow know" whether a link layer connection from a given
end node is under the same PMIP virtual interface with some
other such link layer connection. This assumption, that a
MAG can somehow know of the existence of a virtual interface
or not, has always been a stretch and a point of contention
in NETLMM WG.</t>
<t>Again, not only the need for virtual interfaces brakes the
'no MN changes' clause of <xref target="RFC4830"/>, but
because of the 'no-MN-invovement' basis for PMIP,the MN can
not indicate at the network layer (or above) exactly which
links/interfaces relate to each other and in what way,
resulting in an incomplete, non-general solution.</t>
</section>
<section title="PMIP and Link Layer Signaling">
<t>It is true that most functions defined at the network layer
can also be defined in some form or another at a lower
layer. So, there is nothing technically strange or difficult
about creating a link layer that supports any number of link
layer protocols, which can be used to allow PMIPv6 to
perform not only inter-technology handoffs, but also
multihoming, flow bindings and most other functions one can
build on top of a mobility protocol.</t>
<t>So, arguments against the idea of relying on link layers for
such triggers are not about the feasibility of such an
approach for a given link layer. Instead they are about how
this works between all the different link layers and node
configurations. For example think of an MN with several
interfaces. <list>
<t>- IF1 and IF2 under PMIP VI1</t>
<t>- IF3 separate</t>
<t>- IF4 and IF4 under PMIP VI2</t>
</list> All the interfaces happen to be connected on the
same PMIP domain. Say IF1 (of VI1) and IF4 (of VI2) are
already connected and now one more IF is getting connected.
When this new IF connects to a MAG, what information does
the MAG have to know which one it is and how it relates to
other IFs?<list>
<t> - A link layer based handover hint by itself is not
enough because it does not tell the MAG whether the
new IF is IF2 (associated with VI1) or IF5
(associated with VI2)</t>
<t> - The MNs authorization Identifier (NAI, IMSI or
whatever) is clearly not enough because again it
does not say whether the new IF is one of the other
VI IFs (IF3, IF5) or the independent IF3. </t>
<t> - The L2 MAC address (if it exist) again does not
provide enough information, since at best it
identifies one interface and not the ones related to
it.</t>
</list>
</t>
<t>It should be clear then that link layer signaling is not
appropriate for such function since it can never provide
information on other links.</t>
<!-- <t>Note that
http://tools.ietf.org/html/draft-devarapalli-netext-multi-interface-support
also identifies these limitations and concludes that MN
involvement is necessary.</t> -->
<!-- <t> We can then summarize with the following:</t>
<t>3) Competition with Network Layer:<list>
<t>In the end, even if such triggers are implemented,
the functionality comes in direct competition to
functionality provided at the network layer by
Mobile IP. The PMIPv6 vs MIPv6 or, proxy vs client
mobility debate has never been about comparing
PMIPv6 with MIPv6. It has always been about
comparing an IETF standardised network layer
protocol MIPv6 with a set of proprietary Link Layer
triggers.</t>
</list>
</t>-->
</section>
</section>
<section title="Why extending PMIP is controversial?" anchor="contr">
<section title="Intertech handoff, Multihoming, and Host Signaling"
anchor="sig">
<t> Part of the work proposed for NETEXT WG, is about a) fixing
inter-technology handoff support <xref target="RFC5213"/>,
which as discussed earlier is broken (or at best incomplete)
and b) extending PMIP to support multihoming. Multihoming in
this context refers to a node with multiple interfaces (of
same or different technology) connected to the Internet.
These interfaces can be connected to the same or different
links, access routers, or even domains. The extensions
proposed would also allow for flow bindings to be used to
direct different flows to different links of the same end
node. </t>
<t>This document concludes that to really support
Inter-technology handoffs and Multihoming, network layer
signaling from the end node is absolutely required. The
following summarizes the reasons for this conclusion.</t>
<t>1) Applicability for ALL link layers: <list>
<t>The IETF is concerned with the Internet as a whole,
which operates over an ever expanding variety of
link layers. Indeed mobility in the Internet means
that any node can move from any link to any other
link. While seamlessness of such movement is not
guaranteed, the network must operate correctly and
provide deterministic behaviors to the end nodes.
This is why common functions, needed over different
link layers, are always defined at the network
layer.</t>
</list>
</t>
<t>2) The impossibility of global knowledge:<list>
<t> a) Inter-technology Handoffs: <list>
<t>It is not possible for a given link layer,
under a given Interface, to know, and to be
able to signal correctly, which other link
layers and interfaces are associated with it
under a PMIPv6 Virtual Interface. This is
because by definition, a link layer has
access only to information of its own layer.
It is also not possible to have
preconfigured knowledge of such
relationships in the network (a.g., AAA)
since the configuration of an end node can
change at any time, without the AAA being
notified (e.g., an device is changed or
upgraded).</t>
<t/>
</list>
</t>
<t> b) Multihoming and Flow Bindings: <list>
<t>The same arguments but even stronger hold in
this case. If neither the link layers nor
the network can not be expected to handle
(a) then they can definitely not handle
multihoming and flow bindings which require
a lot more information regarding application
mix running in the end node and
instantaneous condition of different link
layers available.</t>
<t/>
</list>
</t>
</list>
</t>
<t>It should now be clear that to fix inter-technology handoff
support in <xref target="RFC5213"/> and to extend it further
to support multihoming and flow bindings, a network layer
MN-MAG protocol is required.</t>
</section>
<section title="PMIP with Host Signaling">
<t>If one concludes that host signaling is required for these
advanced features, it then should be reasonable to ask:<list>
<t> "why host signaling is such a controversial issue
for PMIP?" </t>
</list>
</t>
<t>Some proposals, like [draft-krishnan-netlmm-pmip-sel-00],
[draft-larsson-netext-pmipv6-sma-flow-mobility-00], and even
[draft-devarapalli-netext-multi-interface-support], openly
talk about the need for such IETF defined signaling. At
least some, however, in the NETEXT mailing list discussions
present significant resistance in admitting this is
necessary and the NETEXT BOF presentations where at vague
and evasive on the subject.</t>
<t>There are several reasons for this, discussed in the
following subsections.</t>
<section title="Historic Reasons">
<t>The formation of NETLMM WG was strongly resisted by part
of the community (see for example
[draft-soliman-netlmm-harmful]). So much so that the
WG's formation was even the subject of satire and
sarcasm; remember NetLemmings?
[draft-bombadil-netlemmings].</t>
<t> The group was finally formed under the assumption that
it would not introduce any changes to the end nodes.
Indeed the original NETLMM charter
(http://www.ietf.org/html.charters/HISTORY/netlmm-charter.2006-07-24.15.html)
said: <list>
<t>"...no specific mobile node to network protocol
will be required for localized mobility
management itself. " </t>
</list>
</t>
<t>The charter continued saying: <list>
<t>"...The (PMIPv6) protocol itself will be agnostic
with respect to the last hop link layer protocol
between the mobile node and the access
router."</t>
</list>
</t>
</section>
<section title="MAG ... the new FA?">
<t>It is not often expressed explicitly but a PMIP MAG is
very similar to a MIPv4 Foreign Agent (<xref
target="RFC3344"/>, the main functional difference
being that an <xref target="RFC5213"/> compliant MAG
does not operate a PMIP-related protocol with the end
nodes. Instead it relies on "lower layer" triggers for
its operation, and suffers for that, for example by
having to deal with rather complex ordering of PBUs
<xref target="RFC5213"/>, Section 5.5. </t>
<t>Introduction of MN to MAG signaling at the network layer,
would indeed make MAGs even more similar to MIPv4 <xref
target="RFC3344"/> Foreign Agents (FA). This which
would raise two important issues: <list>
<t>During the design of MIPv6, foreign agents were
considered undesirable. Based on this, FAs were
designed out of the MIPv6 protocol. The PMIPv6
community has yet to make a case on why we need
to re-create them now. Some of the reasons FAs
are considered undesirable are: <list>
<t>a)FAs required support from the Access
Networks thus impeding the MN's ability
to move freely without be concerned of
whether or exactly what each access
system supports. </t>
<t>b) FAs are unnecessary in IPv6 since
there is no shortage of address space
(i.e., no need for shared care-of
addresses in MIPv4-FA mode. </t>
<t>c) FAs require a chain of trust between
MNs, FAs, and HAs is increased
complexity compared to the one hop
association of MN-HA in MIPv6.</t>
</list>
</t>
<t>One could, however, make an argument for why
removing FAs from this Mobile IP architecture
was a mistake and we need them back in. Indeed
the introduction of MAGs may point to that
conclusion but this debate has never taken place
in the IETF in these terms.</t>
<t>If the resurrection of FAs in their MAG form can
be argued, however, one should also ask the
question: "If we really need FA-like
functionality in IPv6 mobility management, why
is it not defined as part of the mainstream
MIPv6 solution itself?" <list>
<t>a) On one hand it is rather obvious for
example, that if we incorporate MAGs
into the Mobile IPv6 protocol structure,
we are much more likely to have better
interoperability and handoff between
domains using MAGs and others that do
not.</t>
<t>b) On the other hand, it is not clear
that any of the reasons FAs were
designed out of MIPv6 are no longer
valid and thus the whole endeavor is
questionable.</t>
</list>
</t>
</list>
</t>
</section>
<section title="Proliferation of Redundant Tools">
<t>Once the IETF developed a tool to handle a specific
function e.g., Mobile IP for Mobility, the barrier for
additional tools tackling the same problem space is, and
should be high.</t>
<t>This is both reasonable and necessary to ensure wide
adoption of these tools and it is the reason why it is
not so easy to define a new transport protocol to
replace TCP, or a new Web protocol to replace HTTP. This
does not mean that a new tool is impossible, it is just
a matter of having a high bar for the adoption of such
redundant tools.</t>
<t>During the formation of the NETLMM WG a case was made for
basic PMIPv6, based on the idea that for a single
interface mobility (i.e. intra-technology handovers), it
should be possible to define a mobility management
protocol that, unlike Mobile IP, does not rely on end
node signaling and provides mobility transparently to
the end node IP stack, without any host changes (<xref
target="RFC4830"/>.</t>
<t>As explained in detail in <xref target="sig"/>, these
initial assumptions are not possible for
inter-technology handoffs and multihoming. </t>
<t>It should now be clear that introduction of host
signaling in the PMIP protocol defeats the purpose of
NETLMM/PMIP's existence since that was to provide
mobility transparently to the IP stack of end nodes,
unlike what MIPv6 <xref target="RFC3775"/> provides
based on host signaling. </t>
</section>
</section>
</section>
<section title="Conclusions" anchor="conc">
<section title="Lack of Justification for PMIPv6 Extensions"
anchor="just">
<t>During the NETEXT BOF and subsequent discussions on the
mailing list a lot of time has been expending around the
justification arguments for enhancing PMIPv6 further with
inter-technology and multihoming features.
[draft-jeyatharan-netext-multihoming-ps-01] attempts to
capture such justification but it falls short in the
following respects.</t>
<t>As discussed earlier, the NETLMM WG was established and
PMIPv6 protocol was defined based on the "no MN involvement"
assumption. The "no MN involvement" assumption restricts the
operation of this protocol, and makes advanced features like
multihoming and flow movement seem unreasonable in the
context of such restrictions.</t>
<t>Some in the NETEXT community argue that any required MN
involvement can be done at lower layers. This part of the
community has to address the following issues: <list>
<t>- It is a well understood fact that this is not
possible for all link layers. It is actually not
clear at all which link layers have such capability
and whether the triggers are compatible or
equivalent between different technologies. </t>
<t>- It is important for the integrity of the Internet,
that the IETF defines standardized mechanisms
providing all the necessary parameters for its own
protocols to operate. The author is not aware of any
IETF protocol that this is not currently true. This
does not seem possible when a protocol depends on
external triggers not controlled by any other IETF
protocol.</t>
</list>
</t>
<t>There are at least some in the NETEXT community, however, who
recognize that MN involvement at the network layer is
necessary to make these advanced features work with PMIPv6.
This part of the community has to address a different set of
issues. <list>
<t>- The definition of an MN-MAG network layer protocol,
invalidates the main reason why PMIPv6 was created
in the first place (i.e., mobility management with
no MN involvement). It was always assumed that MIPv6
would then handle any advance functions that require
MN involvement. What is the justification for
changing this assumption? </t>
</list>
</t>
<t>As a conclusion the discussion so far comes down to one
point. What is the justification for extending PMIPv6's
inter-technology and multihoming capabilities? What is
missing from the IETF arsenal of tools to handle such
features? Why are existing tools not sufficient? These are
fundamental questions that MUST be answered before any such
work can be taken on.</t>
</section>
<section title="What should be done with PMIPv6" anchor="future">
<t>A number of extensions proposed in the context for NETEXT WG
are natural to this work and at the time of writing were
approved as part of NETEXT WG Charter, e.g., Bulk
Registrations, LMA Redirection etc. These tasks should
indeed go ahead.</t>
<t>It is the opinion of this author, however, that PMIPv6 and
all its extensions should be limited to single interface
operations, without any inter-technology handoff and without
multihoming support beyond what is already defined in <xref
target="RFC5213"/>.</t>
<t> This document actually explains in earlier sections and in
detail that <xref target="RFC5213"/> includes a number of
features that are incomplete or even broken due to lack of
MN-MAG protocol. <xref target="RFC5213"/> should therefore
be revised, not to add to these features, but to either
change them, so no MN involvement is required, or to remove
them from the RFC altogether. </t>
</section>
</section>
<section title="Security Considerations">
<t>This document does not introduce any Security Considerations </t>
</section>
<section title="IANA Considerations">
<t>This document does not introduce any IANA Considerations</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Marcelo Bagnulo who poked a number of holes on my
original arguments causing me significant pain :-), but in the
end helping me refine and clarify them significantly. Also
thanks to Gerardo Giaretta and Hesham Soliman for useful
comments and suggestions.</t>
<t>Many of the arguments presented below are not solely mine but
have been discussed in the past in NETLMM WG mailing list, and
more recently in NETEXT BOF and subsequent discussions on the
mailing list.</t>
</section>
</middle>
<back>
<references title="Informative References"> &rfc0792; &rfc0894;
&rfc2004; &rfc2119; &rfc2225; &rfc5226;
&rfc3344; &rfc3775; &rfc4830; &rfc4861;
&rfc4960; &rfc5213; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:44:26 |