NETLMM Working Group G. Velev
Internet-Draft K. Weniger
Intended status: Informational Panasonic
Expires: May 15, 2008 November 12, 2007
Interactions between PMIPv6 and MIPv6: Route Optimization Issues
draft-velev-netlmm-mip-pmip-ro-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The interactions scenarios between Proxy Mobile IPv6 (PMIPv6) and
Mobile IPv6 (MIPv6) protocols are described in [ID-MIP-PMIP]. This
document analyzes these scenarios when route optimization is used.
The analysis results in the identification of possible issues that
should be considered in the design of extensions for Route
Optimization in PMIPv6.
Velev & Weniger Expires May 15, 2008 [Page 1]
Internet-Draft PMIPv6-MIPv6 RO Issues November 2007
Requirements Language
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].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of route optimization . . . . . . . . . . . . . . . . 3
3.1. Route optimization in MIPv6 . . . . . . . . . . . . . . . 3
3.2. Route optimization in PMIPv6 . . . . . . . . . . . . . . . 4
4. Analysis of the scenarios and possible issues . . . . . . . . 5
4.1. Proxy RO in scenario A . . . . . . . . . . . . . . . . . . 5
4.2. Proxy RO in scenario B . . . . . . . . . . . . . . . . . . 7
4.3. Proxy RO in scenario C . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Velev & Weniger Expires May 15, 2008 [Page 2]
Internet-Draft PMIPv6-MIPv6 RO Issues November 2007
1. Introduction
The NETLMM WG is standardizing Proxy Mobile IPv6 (PMIPv6) as the
protocol for network-based localized mobility management. The MIPv6-
PMIPv6 interactions document [ID-MIP-PMIP] captures the issues with
the inter-working between host-based (MIPv6) and network-based
(PMIPv6) mobility and identifies three main scenarios. However, the
document does not consider the cases when a route optimized path is
set up.
In PMIPv6 the mobile access gateway (MAG) manages the mobility-
related registrations with the local mobility agent (LMA) on behalf
of the mobile nodes (MNs) attached to it. According to the base
PMIPv6 specification [ID-PMIPv6] all data packets are bi-
directionally tunneled between MAG and LMA. In some scenarios, e.g.
if the communicating end nodes are located in the same PMIPv6 domain,
it is advantageous to route the packets directly between the MAGs to
which the nodes are attached. The PMIPv6 base spec does not support
route optimization (RO) between different MAGs, but there are
individual proposals (see Section 3.2) for establishing such a route
optimized path. In these proposals, as required by PMIPv6, the MNs
are unaware about the proxy RO set up in PMIPv6 domain between the
MAGs. On the other hand, in MIPv6 the MN itself performs the route
optimization with a CN.
This document provides an analysis of the scenarios and possible
issues when the PMIPv6 and MIPv6 route optimization procedures
interact.
2. Terminology
General mobility terminology can be found in [RFC3753]. Further,
PMIPv6-related terminology used in this document is defined in
[ID-PMIPv6]
3. Overview of route optimization
This section provides an overview of the route optimization
procedures specified for MIPv6 and the general characteristics of a
potential to-be-standardized route optimization procedure for PMIPv6.
3.1. Route optimization in MIPv6
MIPv6 protocol comes with a route optimization scheme that enables a
direct communication between MN and CN, i.e. the data packets are
bypassing the Home Agent. Route optimization requires the mobile
Velev & Weniger Expires May 15, 2008 [Page 3]
Internet-Draft PMIPv6-MIPv6 RO Issues November 2007
node to register its current binding of home address (HoA) to care-
of-address (CoA) at the correspondent node. The CN establishes a
binding cache entry and packets from the CN can be routed directly to
the CoA of the MN.
MPv6 specification [RFC3775] defines the return routability (RR)
procedure that authorizes the BU sent by the MN by the use of a
cryptographic token exchange (keygen tokens). The binding update is
signed by binding management key (Kbm) that is generated based on the
keygen tokens obtained from CN separately for the home address and
care-of-address. The detailed RR and RO procedures are described in
sections 5.2, 6.1, 9.4 and 9.5 in [RFC3775].
3.2. Route optimization in PMIPv6
Route optimization in PMIPv6 (proxy RO) is not in the charter of the
NetLMM working group and is not specified in the PMIPv6 base
specification [ID-PMIPv6]. However, [ID-PMIPv6] describes one case
where the local routing at the MAG is possible. The local routing is
applied when the two communicating mobile nodes are attached to the
same MAG and the MAG's policy in coordination with LMA allows such
routing. In all other attachment constellations the PMIPv6 protocol
mandates reverse tunneling of data packets to the LMA.
However, interest in the area of PMIPv6 RO (henceforth called proxy
RO) exists from various working group members and individual
solutions are already available. In the following, the general
characteristics of possible PMIPv6 RO mechanisms are analyzed.
Subsequently, some individual submissions are briefly presented as
example solutions.
In general, the proxy RO can be categorized in the following cases:
1. Between the MN and the CN's MAG. In this case the RO is
initiated by the MN and the MAG is the endpoint of the route
optimized path. For instance, if MIPv6 RO is used, the MAG
performs the role of MIPv6 CN with respect to RO.
2. Between the MN's MAG and the CN. In this case the MN's MAG
initiates the RO with CN on behalf of the MN and the endpoint of
the route optimized path is MN's MAG instead of MN. For
instance, if MIPv6 RO is used the MAG performs the role of MIPv6
MN with respect to RO.
3. Between MAGs. In this case the MAG, to which the MN is attached,
initiates RO with the CN's MAG and a route optimized path between
both MAGs is established. For instance, if MIPv6 RO is used, the
MN's MAG performs the role of MIPv6 MN with respect to RO and the
Velev & Weniger Expires May 15, 2008 [Page 4]
Internet-Draft PMIPv6-MIPv6 RO Issues November 2007
MAG, to which the CN is attached, performs the role of MIPv6 CN.
Each of the above cases is analyzed in different MIPv6-PMIPv6
interaction scenarios in Section 4.
The document [PMIPv6-RO-RR] describes the applicability of Enhanced
Route Optimization for Mobile IPv6 specified in [RFC4866] for PMIPv6.
The authors describe the applicability of a proxy Return Routability
(RR) procedure performed by the MAG on behalf of the MN. The
document addresses cases 2 and 3 from above.
Another individual approach of RO in PMIPv6 is described in
[PMIPv6-RO-ROA]. This approach assumes that a (pre-established)
route optimization association (ROA) between the MAGs is set up and
they can exchange RO setup messages (similar to binding updates
messages) via LMA or directly among each other. The document
addresses the case 3 (i.e. MAG-MAG RO) from above. This solution is
applicable for proxy RO within one PMIPv6 domain because ROA between
the MAGs must be pre-established.
A further individual solution is described in [PMIPv6-RO-IPv4] that
presents a more general approach and considers a combination of both
individual solutions presented above: either performing a proxy RR
between MAGs or having a Security Association between MAGs for direct
exchange of binding updates.
In general, if a mobile node attached to a MAG in PMIPv6 domain moves
to a new MAG, the old MAG, the new MAG and the LMA should manage the
transition of the RO-related state from the old to the new MAG.
Further the new MAG shall update the BCE in the correspondent node.
These procedures are outside of the scope of this document because it
is not specific to MIPv6-PMIPv6 interactions and should be defined in
a potential to-be-standardized PMIPv6 RO procedure.
4. Analysis of the scenarios and possible issues
The categorization of the MIPv6-PMIPv6 interactions with respect to
RO is based on scenarios A, B and C described in [ID-MIP-PMIP] in
order to achieve compliance between both documents. For each of the
scenarios the cases from Section 3.2 are applied and the resulting
issues are identified.
4.1. Proxy RO in scenario A
In scenario A, PMIPv6 is used as a network-based local mobility
management protocol whereas MIPv6 is used as a global mobility
management protocol. In other words, MIPv6 manages the mobility
Velev & Weniger Expires May 15, 2008 [Page 5]
Internet-Draft PMIPv6-MIPv6 RO Issues November 2007
among different access networks, while the mobility within the access
network is handled by PMIPv6. Furthermore, HA and LMA are not co-
located.
In this scenario the MN uses MIPv6 and registers the IP address
obtained in the PMIPv6 domain as CoA at the HA. A bi-directional
tunnel is set up between the MN and HA. An additional PMIPv6 tunnel
is in use between MAG1 and LMA1. Figure 1 illustrates the
hierarchical application of MIPv6 and PMIPv6 protocols in scenario A.
The CN relies on the PMIPv6 for mobility management, it is attached
to MAG2 and anchored at LMA1, where the MN is anchored too.
+----+
| HA |
+----+
//\
// \
+------------//----\-------------+
( // \ ) Global Mobile IPv6
( // \ ) Domain
+---------//----------\----------+
// \
+------+ +----+
| LMA1 | |LMA2|
+------+ +----+
////\\ \\
+----////--\\----+ +----\\------+
( //// \\ ) ( \\ ) Local Mobility Network
( //// \\ ) ( \\ ) PMIPv6 domain
+-////--------\\-+ +-------\\---+
//// \\ \\
//// \\ \\
//// \\ \\
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
|| | |
[MN] [CN]
Figure 1 - Scenario A
As MIPv6 bidirectional tunnel is set up between MN and HA, the PMIP
entities (MAG1 and LMA1) cannot take any actions with respect to
proxy RO because they do not know the address of the CN. Even if the
CN is attached to the same or neighbour MAG, to which MN is attached,
PMIP entities are unable to discover such a situation. Therefore,
proxy RO initiated by MN's MAG to the CN, i.e. case 2 from
Velev & Weniger Expires May 15, 2008 [Page 6]
Internet-Draft PMIPv6-MIPv6 RO Issues November 2007
Section 3.2, is not possible. The MAG would rather see the HA as CN
and establish an optimized route to the HA, which is of course not
desired. Proxy RO between MAG1 and MAG2 (case 3) has the same
problem as case 2: since a MIPv6 tunnel is set up between MN and HA,
MAG1 cannot discover CN's address and initiate proxy RO.
In contrary to cases 2 and 3, proxy RO between MN and MAG2 (case 1)
is possible. MN initiates a MIPv6 RO with the CN and the MAG2 is
configured to act as proxy CN on behalf CN. The resulting path in
both directions (i.e. MN->CN and CN->MN) would be
MN-MAG1-LMA1-MAG2-CN. Such a situation is comparable to usual PMIPv6
routing, although MIPv6 RO IP header options are present in the data
packets (Routing Header Type 2 and Home Address destination option).
This situation gives opportunity for MAG1 to start proxy RO with CN,
or for a proxy RO between MAG1 and MAG2. A potential to-be-
standardized PMIPv6 RO procedure shall consider the handling of such
a situation, where already MIPv6 RO is running between MN and CN (or
CN's MAG, i.e. MAG2). In summary, proxy PMIPv6 RO from MAG1 to CN
or from MAG1 to MAG2 in scenario A cannot be initiated unless MN
performs MIPv6 RO with CN.
In the following a situation is analyzed, in which the MAG2 initiates
proxy RO with the MN. After such a route optimized path is set up,
the data packets would continue to flow via the HA, i.e. the path
would the same as before the proxy RO. Therefore it is advantageous
if MAG2 does not initiate proxy RO with MN.
4.2. Proxy RO in scenario B
In scenario B some MNs use MIPv6 to manage their movements while
others rely on a PMIPv6 protocol provided by the network. The
configuration of the MAG for support such scenario is described in
[ID-MIP-PMIP] Section 6.14. The mobility anchor for MIPv6 and PMIPv6
is the same entity implementing the functions of both HA and LMA
(below denoted as HA/LMA). For a MN, to which PMIPv6 service is
offered, the HA/LMA is acting as LMA and for a MN, to which MIPv6
service is offered, the HA/LMA is acting as HA.
Figure 2 illustrates scenario B where a MN uses MIPv6 and a CN relies
on PMIPv6 for mobility management. The MN utilizes MIPv6 tunnel to
the HA/LMA via AR whereas a PMIPv6 tunnel is set up for CN between
MAG2 and HA/LMA.
Velev & Weniger Expires May 15, 2008 [Page 7]
Internet-Draft PMIPv6-MIPv6 RO Issues November 2007
+------+
|HA/LMA|
+------+
//\\
+- ---//--\\----+
( // \\ ) Mixed MIPv6 and
( // \\ ) PMIPv6 mobility domain
+--//--------\\-+
// \\
// \\
// \\
+----+ +----+
| AR | |MAG2|
+----+ +----+
|| |
[MN] [CN]
Figure 2 - Scenario B
In scenario B proxy RO (from MN-side) is possible only between MN and
MAG2. The proxy RO cases 2 and 3 from Section 3.2 are not possible
because MN is attached to an AR. If the MN initiates a MIPv6 RO with
CN, MAG2 may respond as proxy on behalf of the CN, which results in
case 1. The RO path is set up between MN and MAG2, which is the
optimal route from MN to CN. Additionally, MAG2 may initiate proxy
RO with the MN in order to achieve route optimized path in direction
from CN to MN. If the RO is performed in both directions, no further
optimizations are needed.
On the other hand, proxy RO can be initiated from CN side. With
regard to Figure 2 this is the case if MAG2 initiates proxy RO with
MN. The resulting route optimized path would be via the MN's HA/LMA,
because MAG2 does not know MN's CoA. Thus, the proxy RO in such a
case does not lead to any path optimization. Therefore it is
beneficial if MAG1 does not initiate proxy RO with MN.
In summary, to achieve the optimal RO path in scenario B between MN
using MIPv6 and CN relying on PMIPv6 service in the same network
domain, first the MN should initiate MIPv6 RO. The network can
assist the MN to initiate MIPv6 RO, as the network entities (most
probably LMA) can discover this constellation.
4.3. Proxy RO in scenario C
In scenario C a MIPv6-capable MN moves between access networks using
different mobility management schemes, i.e. some access networks
support PMIPv6 and others do not. This results in transition between
Velev & Weniger Expires May 15, 2008 [Page 8]
Internet-Draft PMIPv6-MIPv6 RO Issues November 2007
PMIPv6 and MIPv6 mobility management for the particular MN and
requires that LMA and HA functions are located in the same physical
entity. Scenario C is depicted in Figure 4.
+------+
|HA/LMA|-----------------------+
+------+ |
//\\ |
+-------//--\\--------+ |
( // \\ PMIPv6 ) |
( // \\ domain) +--------------+
+----//--------\\-----+ ( Non-PMIPv6 )
// \\ ( domain )
// \\ +--------------+
// \\ |
+----+ +----+ +----+
|MAG1| |MAG2| | AR |
+----+ +----+ +----+
| | |
[MN1] [MN2] ------> (1) |
(2) <------ [MN2]
Figure 3 - Scenario C
In order to anlyze the issues with RO in scenario C, first it is
assumed that MN2 has the role of MN and MN1 has the role of CN.
Further two transition scenarios are investigated denoted by the
arrows (1) and (2) in Figure 3. In transition (1) the MN2 moves from
MAG2 of PMIPv6 domain to an AR of non-PMIPv6 domain, whereas in
transition (2) the MN2 moves from AR to MAG2. At first, transition
(1) is analyzed. If a MN2 is attached to MAG2 and MN1 is attached to
MAG1, a proxy RO path can be set up according to cases 2 (MAG2->MN1)
and case 3 (MAG2->MAG1) from Section 3.2. Cases 1 (MN2->MAG1) is not
possible because the assumption is that MN2 is at the home link
supporting PMIPv6 service, i.e. the MN2 does not have a CoA to
register with the CN. In the following analysis, cases 2 and 3 are
investigated together because the only difference is which entity
(MN1 or MAG1) performs the CN role regarding RO functionality.
Therefore, below CN is indicated as MN1/MAG1.
If the MN2 moves outside the PMIP domain to an AR of a MIPv6 domain,
the MN2 performs MIPv6 registration with the HA/LMA. Since the MN2
is not aware about the proxy RO before the handover, it does not
necessary initiate registration of its CoA to MN1/MAG1. It depends
on the MN2's MIPv6 implementation whether MIPv6 RO is performed. The
steps performed by MAG2, after detection that MN2 is not any longer
Velev & Weniger Expires May 15, 2008 [Page 9]
Internet-Draft PMIPv6-MIPv6 RO Issues November 2007
attached to it, depend on a potential PMIPv6 RO specification. If
MAG2 does not deregister the MN2 with the MN1/MAG1, MN1/MAG1
continues to send packets to MAG2 and this could lead to packet
losses. Therefore a potential PMIPv6 RO protocol shall take care of
this situation. On the other hand, if a mechanism is available in
MAG2 to deregister MN2 with MN1/MAG1, then the proxy RO path is
terminated and data packets are routed via HA/LMA. The change of
route optimized to non-optimized path would result in increased end-
to-end delay and possibly to data packets lost due to transport layer
time out. To avoid this situation, a future protocol mechanism may
help to keep the RO path between the MN2 and MN1 after the MN2 moves
out of the PMIPv6 domain.
The transition (2) from Figure 3 is observed hereby, where the MN2 is
first attached to a MIPv6 domain and later moves to the home link
that supports PMIPv6 service (home PMIPv6 domain). Case 1
(MN2->MAG1) from Section 3.2 is the only possible way of performing
proxy RO before the handover. While attached to the MIPv6 domain, a
RO path between MN2 and MAG1 is set up, i.e. MN2 creates BCE in
MAG1. When the MN2 moves to the home PMIPv6 domain, it performs the
returning home procedure described in [RFC3775], i.e. sends
deregistration BU messages to HA and all CNs, to which a MIPv6 RO has
been set up. Thus, the MN2 deletes the BCE in MAG1 and MAG1 sends
data packets to MN2's HoA, i.e. to HA/LMA. Such a scenario does not
result in data packet losses, however, the MN-CN path after the
handover is not optimized.
In conclusion, the MN2's transition between PMIPv6 and MIPv6 mobility
schemes results in issues that should be considered by a future
protocol mechanisms. The transition from PMIPv6 to non-PMIPv6 domain
may result in packet losses or affect the transport layer application
due to increased end-to-end delay.
The MIPv6 RO procedure [RFC3775] specifies the functionality of a CN,
however, it does not consider mobile CN. In the following a mobile
CN performing PMIPv6-MIPv6 transition in scenario C is analyzed in
order to identify possible issues. In scenarios A and B the mobile
CN does not change the mobility management scheme and therefore such
an analysis is not needed. With respect to Figure 3, the assumption
now is that the MN's role is implemented in MN1 (respectively MAG1)
and CN's role - in MN2 (respectively MAG2). In transition (1) the
MN2 hands over from MAG2 to the AR. Before the handover MAG2
performed the function of CN with respect to RO. Thus, the MN2 sends
data packets to MN1's HoA, but the MAG2 tunnels the packets to MAG1.
After the handover, the MN2 performs MIPv6 registration with HA and
continues to send the data packets to MN1's HoA. The LMA forwards
the data packets to the MAG1 and they are delivered to MN1. So far
data packets are delivered to MN1. However MAG1 would continue to
Velev & Weniger Expires May 15, 2008 [Page 10]
Internet-Draft PMIPv6-MIPv6 RO Issues November 2007
keep the proxy RO path with MAG2, although MN2 is not any longer
attached to MAG2. Such a situation should be considered by the
potential to-be-standardized proxy RO specification.
In transition (2), the MN2 hands over from AR to MAG2. Before the
handover MN2 uses MIPv6 and performs the role of CN. The proxy BCE
in MN2 is created by MAG1. After the handover to MAG2, the MN2 keeps
the proxy BCE, and thus, sends the packets to MN's CoA (e.g. MAG1's
IP address). However, the packets are encapsulated by MAG2 in a
PMIPv6 tunnel to LMA, an thus, the MN1-MN2 path is not optimized.
The result is that RO set up before the handover continues to be
still active, and either MAG1 continues to update the MN2's BCE.
Such a situation is undesired and shall be handled by a to-be-
standardized proxy RO procedure.
To sum up the issues with mobile CN in scenario C, transition (1) may
lead to a situation in which the entity performing the MN's role
(MAG1) continues to perform proxy RO with the MAG2, although MN2 is
not any longer attached to MAG2. On the other hand transition (2)
results in the non-optimal situation of tunneling data packets
between MAG2 and LMA although a BCE exists in MN2 for optimal route
to MN1.
5. Security Considerations
The current document analyzes scenarios and describes issues; it does
not present new protocol design. Therefore this document does not
introduce any security issues in addition to those described in
[ID-PMIPv6] or [RFC3775].
6. References
6.1. Normative References
[ID-PMIPv6]
Gundavelli, S., Ed., "Proxy Mobile IPv6", November 2007,
<draft-ietf-netlmm-proxymip6-07.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Velev & Weniger Expires May 15, 2008 [Page 11]
Internet-Draft PMIPv6-MIPv6 RO Issues November 2007
Home Agents", RFC 3776, June 2004.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", May 2007.
6.2. Informative References
[ID-MIP-PMIP]
Giaretta, G., Ed., "Interactions between PMIPv6 and MIPv6:
scenarios and related issues", August 2007,
<draft-giaretta-netlmm-mip-interactions-01.txt>.
[PMIPv6-RO-IPv4]
Jeong, S. and R. Wakikawa, "Route Optimization for Proxy
Mobile IPv6", July 2007,
<draft-jeong-netlmm-ro-support-for-pmip6-00.txt>.
[PMIPv6-RO-ROA]
Abeille, A. and M. Liebsch, "Route Optimization for Proxy
Mobile IPv6", May 2007,
<draft-abeille-netlmm-proxymip6ro-00.txt>.
[PMIPv6-RO-RR]
Qin, A., Ed., "PMIPv6 Route Optimization Protocol",
February 2007, <draft-qin-mipshop-pmipro-00.txt>.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
Authors' Addresses
Genadi Velev
Panasonic
Monzastr. 4c
Langen 63225
Gemany
Phone:
Email: genadi.velev@eu.panasonic.com
Velev & Weniger Expires May 15, 2008 [Page 12]
Internet-Draft PMIPv6-MIPv6 RO Issues November 2007
Kilian Weniger
Panasonic
Monzastr. 4c
Langen 63225
Gemany
Phone:
Email: kilian.weniger@eu.panasonic.com
Velev & Weniger Expires May 15, 2008 [Page 13]
Internet-Draft PMIPv6-MIPv6 RO Issues November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Velev & Weniger Expires May 15, 2008 [Page 14]