One document matched: draft-damic-netlmm-pmip6-ind-discover-01.txt
Differences from draft-damic-netlmm-pmip6-ind-discover-00.txt
Network Working Group D. Damic
Internet-Draft D. Premec
Intended status: Standards Track B. Patil
Expires: December 21, 2007 M. Sahasrabudhe
Nokia Siemens Networks
June 19, 2007
Proxy Mobile IPv6 indication and discovery
draft-damic-netlmm-pmip6-ind-discover-01.txt
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 December 21, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Proxy Mobile IPv6 is a network-based mobility protocol and is able to
manage the mobility of an IP host as it moves across different points
of attachment within the mobility domain. The IP host whose mobility
is being managed by the network is unaware of the existence of Proxy
Mobile IPv6 in the network or mobility being managed on its behalf.
This draft proposes mechanisms by which the host is informed of proxy
Damic, et al. Expires December 21, 2007 [Page 1]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
mobile IPv6 support in a network that it attaches to as well as the
ability for the host to discover such capability in the attached
network. The ability of the host to discover or be aware of proxy
mobile IPv6 support in the network enables better decision making in
terms of the type of mobility protocol used for IP mobility.
Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 5
4.1. PMIP6 indication in the Router Advertisment . . . . . . . 5
4.2. PMIP6 Care-of Prefix Option . . . . . . . . . . . . . . . 6
4.3. Router Solicitation Mobility Mode Option . . . . . . . . . 8
4.4. DHCPv6 extensions . . . . . . . . . . . . . . . . . . . . 9
4.4.1. Home Network Identifier Option . . . . . . . . . . . . 10
4.4.2. Home Network Information Option . . . . . . . . . . . 11
4.4.3. Note on DHCPv4 . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Damic, et al. Expires December 21, 2007 [Page 2]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
1. Introduction and Scope
Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] is a network-based
mobility management protocol in which the host is not involved in any
signaling to enable IP mobility as it moves and changes its point of
attachment. This feature complements the mobility protocols such as
Mobile IPv6 [RFC3775] in which the host is involved in mobility
management. On the other hand, nodes that are capable for mobility
management themselves (i.e., implement the MIP6 functionality in the
IP stack) might not require such kind of service.
PMIP6 protocol as specified in [I-D.ietf-netlmm-proxymip6] is
applicable within the scope of a single PMIP6 domain. However
deployment scenarios may include a broader scope than a single
domain.
Scenarios where mobility is managed by the network are usually
referred as running in Proxy MIP (PMIP) mode. Analogously, when
mobile nodes manage mobility themselves we are talking about host-
based mobility. There are several scenarios in which host-based
Mobile IP and proxy MIP support co-exist in the same network. For
example:
o Different mobility modes within a single PMIP6 domain:
In case of nomadic users, the network needs to provide mobility
services simultaneously for nodes with and those without the
built-in mobility support. Each mobility mode, either PMIP6 or
host-based MIP6, needs to be individually recognized and
appropriately handled by the network.
o Session continuation accros different domains:
Mobile node roaming in/out of the PMIP6 domain aims to continue
the ongoing session either retaining or substituting the assigned
mobility mode. For example, MN running a MIP6 session in the
network moves to a PMIP6-enabled domain. Depending on the
privileges and policies, the session is either continued using
host-based mobility, or the network takes over the mobility
management and begins handling the MN in the PMIP6 mode.
Existing IPv6 mechanisms, such as Neighbor Discovery protocol (NDP)
or DHCPv6, are currently insufficient for the purpose of mobility
mode detection or capability negotiation. This document proposes
means by which the network can indicate its PMIP6 capabilities and
provide specific configuration parameters to mobile nodes. The
proposal also proposes a method where MN can proactively participate
in mobility management mode selection.
Damic, et al. Expires December 21, 2007 [Page 3]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
PMIP6 prefix
Prefix assigned to the MN while residing within the PMIP6 domain.
Depending on the mobility scope this prefix can be assigned either by
the LMA, or the HA.
On-link prefix
IPv6 prefix available for address autoconfiguration in the local
domain, for example valid within a scope of a single AR/MAG.
3. Problem Statement
In the PMIP6 domain MN may use stateless address autoconfiguration
(SLAAC) or DHCPv6 to configure its addresses. The address
configuration parameters provided to the MN MAY be different in cases
when supporting PMIP6 or host-based MIP6.
In case PMIP is used as a mechanism for global mobility or for
emulating the home link to the MN, the network obtains the home
prefix for the MN and provides the same to the MN. Prefix is
assigned to the MN for the entire session, and must be consistently
advertised throughout the entire PMIP6 domain.
For MIP6 capable nodes it is sufficient to supply any globallly
routable local prefix (address) that MN will use to configure the
care-of address (CoA) on its interface.
The AR or MAG in an access network should be able to interpret the
mobility preference of the host, in case such information is provided
in router solicitation (RS) or a DHCP request. NDP and DHCP messages
as defined today cannot serve as specific PMIP6 mobility triggers.
Furthermore, the profile associated with a user in AAA cannot really
be used as an indication about the mobility protocol for the hosts as
the device and capability may change. For example: information that
subscriber is allowed PMIP6 does not provide indication on what kind
of terminal subscriber is actually using (does it implement MIP6), or
would the MN rather engage the host-based mobility if able to.
Explicit mechanisms and protocol extensions are needed to:
o enable the access network to advertise the PMIP6 feature and
support to the hosts
Damic, et al. Expires December 21, 2007 [Page 4]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
o provide the host with more reliable parameters allowing it to
choose the mobility protocol based on its capabilities or other
criteria
o allow MNs to signal their mobility mode preferences
4. Proposed Solutions
This document proposes extensions to the NDP and DHCP protocols that
may serve as triggers for PMIP6 mobility selection. These extensions
include: a new indication flag in the RA, new options for the Router
Advertisement and Router Solicitation messages, as well as new
options for the related DHCP messages.
4.1. PMIP6 indication in the Router Advertisment
As per [I-D.haberman-ipv6-ra-flags-option] the AR may use a new
option to expand the flags field in the Router Advertisement
messages. In case the access network does support PMIP6, new option
may be used to explicitly indicate this capability. By setting the
"N" flag in the RA flag expansion option, AR advertises support for
network-based mobility management, i.e., PMIP6 capability.
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 |N| Bit fields available ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... for assignment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. RA flag expansion option with a PMIP6 indication
Type
Type - 8-bit identifier of the option type
To be assigned by IANA, as indicated by
[I-D.haberman-ipv6-ra-flags-option]
Length
Length = 1; The length MUST be checked when processing the option
in order to allow for future expansion of this option if the need
arises.
Damic, et al. Expires December 21, 2007 [Page 5]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
Bits
Router Advertisement bit 8 - the "N" flag
To be assigned by IANA. This bit is set by the AR to indicate the
access network supports network-based mobility management, i.e.,
PMIP6.
Other bits are available for further assignment.
4.2. PMIP6 Care-of Prefix Option
The AR can include multiple IPv6 prefixes in a single RA message,
with each prefix contained in an own Prefix Information Option. In
case the access network supports PMIP6, the AR MAY chose to
simultaneoulsy advertise local on-link IPv6 prefixes, as well as
specific PMIP6 prefix. For this specific case, the two different
types of prefixes SHOULD be cleary differentiated.
In the PMIP6 domain, AR may either advertise on-link prefixes or the
PMIP6 prefix within the RA's Prefix Information Option. Assuming MN
is allowed PMIP6 service, the AR SHALL advertise the individually
assigned PMIP6 prefix as default, whereas one or more on-link
prefixes will be included in the new PMIP6 Care-of Prefix option.
Mobile nodes that are capable of processing the new PMIP6 Care-of
Prefix option can use obtained information according to preferences
and internal configuration. If wishing to deploy host-based MIP6, MN
SHOULD use the prefix from the PMIP6 Care-of Prefix option and
autoconfigure MIP6 CoA. Otherwise, MN SHALL configure PMIP6 MN-HoA
from the Prefix Information Option.
Node incapable understanding the new option SHALL ignore it.
Damic, et al. Expires December 21, 2007 [Page 6]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
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 | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ PMIP6 Care-of Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. PMIP6 Care-of Prefix Option
Fields:
Type
8-bit identifier for the PMIP6 Care-of Prefix option (to be
assigned by IANA).
Length 4
Prefix Length
8-bit unsigned integer. The number of leading bits in the Prefix
that are valid. The value ranges from 0 to 128.
Reserved1
6-bit unused field. It MUST be initialized to zero by the sender
and MUST be ignored by the receiver.
Valid Lifetime
32-bit unsigned integer. The length of time in seconds (relative
to the time the packet is sent) that the prefix is valid for the
purpose of on-link determination. A value of all one bits
(0xffffffff) represents infinity. The Valid Lifetime is also used
by [RFC2462].
Damic, et al. Expires December 21, 2007 [Page 7]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
Preferred Lifetime
32-bit unsigned integer. The length of time in seconds (relative
to the time the packet is sent) that addresses generated from the
prefix via stateless address autoconfiguration remain preferred
[RFC2462]. A value of all one bits (0xffffffff) represents
infinity. See [RFC2462].
Reserved2
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
PMIP6 CoA Prefix
An IP address or a prefix of an IP address indicated as the PMIP6
on-link prefix. The Prefix Length field contains the number of
valid leading bits in the prefix. The bits in the prefix after
the prefix length are reserved and MUST be initialized to zero by
the sender and ignored by the receiver. A router SHOULD NOT send
a prefix option for the link-local prefix and a host SHOULD ignore
such a prefix option.
Description:
The PMIP6 Care-of Prefix option provides host with an on-link prefix
for stateless address autoconfiguration.
The PMIP6 Care-of Prefix option appears in Router Advertisement
packets only and MUST be silently ignored for other messages.
4.3. Router Solicitation Mobility Mode Option
Mobile node aware of different mobility modes may wish to explicitly
notify the AR about its PMIP6 capabilities and embedded support. A
new Mobility Mode option in the RS message MAY be used for this
purpose.
Routers in the network not supporting PMIP6 or unable to process this
option SHOULD ignore it. Otherwise the AR MAY acquire the PMIP6
prefix for the mobile node as well as available on-link prefixes, and
supply this information in the responding Router Advertisment using
the appropriate options.
Damic, et al. Expires December 21, 2007 [Page 8]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
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 |P| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pad ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Mobility Mode option for RS
Type
8-bit identifier for the Mobility Mode option (to be assigned by
IANA)
Length
8-bit unsigned integer. The length of the option in octets
(including the type and length fields)
Flags
8-bit field containing flags set by MN to negotiate on the
mobility service type.
The most significant bit in this field is labled as PMIP6 "P"
flag. It is set by MN when explicitly notifiying the network of
existing PMIP6 support.
Reserved
8-bit field reserved for future use.
Pad
Variable-length field. This field is used to align the option
into units of 8 octets.
4.4. DHCPv6 extensions
This section describes how a mobile node can use DHCP [RFC3315] to
detect that it is located in the PMIP domain and to inform the AR of
its preference to use PMIP6 or host-based MIP6 as a mobility
management protocol.
By using DHCP, mobile node and the AR are able to exchange following
information:
Damic, et al. Expires December 21, 2007 [Page 9]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
o AR can let the mobile node know that the access network supports
the PMIP6 protocol
o AR can inform the mobile node of the PMIP6 prefix
o mobile node can inform the AR wheather it should provide a PMIP6
service to it or if the MN prefers to run MIP6 by itself
Draft [I-D.ietf-mip6-hiopt] defines new DHCPv6 options used to
facilitate bootstraping of a MIP6 based mobility service. One of the
options introduced by the draft is a Home Network Identifier option
(OPTION_MIP6-HNID) by which the mobile node can request information
about the home network and indicate its preference for the location
of the HA: in the visited network or in the target network.
4.4.1. Home Network Identifier Option
The Home Network Identifier option is extended with an additional
code to allow the mobile node to explicitely request information
about the availability of the PMIP service at its current point of
attachment.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_MIP6-HNID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id-type | reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Home Network Identifier .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Home Network Identifier option format
option-code
OPTION_MIP6-HNID (TBD)
option-len
Total length of the option in octets
id-type
The type of Home Network Identifier:
Damic, et al. Expires December 21, 2007 [Page 10]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
0 Visited domain (local ASP)
1 The target network
2 No preference
3 PMIP domain
When the mobile node wants to learn if the access network supports
PMIP service, it SHALL include Home Network Option setting the id-
type field to 3. When the id-type is set to 3, the Home Network
Identifier field MAY be set to 0 if the mobile node wants to learn
about the PMIP support in the local domain. Alternatively, if the
mobile node wants to inquire about the support for PMIP service in a
particular network, the mobile node MAY set the Home Network
Identifier field to the network realm as FQDN.
The mobile node can learn information about a particular network type
by sending separate Information Request messages with different id-
types. If the mobile node wants to acquire the information about the
visited network, target network and the PMIP domain in a single
message exchange, it MAY include several Home Network Identifier
options in the reguest message. There may be several Home Network
Identifier options with the id-type 1 and/or 3 in a single message.
4.4.2. Home Network Information Option
Draft [I-D.ietf-mip6-hiopt] defines a new DHCPv6 option Home Network
Information option. This option is used by the DHCP server to convey
to the mobile node information about inquired network(s). The
information provided could be a home subnet prefix (one or more),
home agent address(es) and home agent FQDN(s). There is a separate
suboption for each type of information provided (prefix, home agent
address and home agent FQDN).
If the id-type field of the Home Network Identifier option indicates
the network which is not supported by this access network or if the
mobile node is not authorized for the requested network, the DHCP
server's reponse SHALL include the Home Network Information option
with the option-len set to zero.
If the mobile node inquiered information about the PMIP domain, the
relevant information about the PMIP domain will be provided in the
Home Network Information option. In this case the only relevant
information is prefix. Since in PMIP mode the mobile node does not
interact with the home agent directly, home agent's address and FQDN
SHALL not be provided to the mobile node.
If the access network wants to force the PMIP mode for the mobile
node, it MAY respond to both visited domain and target domain(s)
inquieris with a Home Network Information option containing the
Damic, et al. Expires December 21, 2007 [Page 11]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
0-length data.
4.4.2.1. Avoiding the premature prefix advertisment
When the netlmm domain supports the DHCP extensions specified here,
the AR may want to defer advertisment of the prefix until both the
mobile node and network have exchanged their capabilites and
preferences for a mobility management mode. This can be achived by
setting the 'M' or 'O' flag in Router Advertisment message forcing
the mobile node to use DHCP. In this way the AR can delay the prefix
advertisment until the DHCP exchange is completed.
4.4.2.2. Choosing the PMIP mode
If the client decides that it would use PMIP service offered by the
access network, it SHALL send the (additional) Information Request
message containing Home Network Information sub-option with the Home
Network Information field containing the PMIP network prefix.
4.4.3. Note on DHCPv4
Home Network Identifier option and Home Network Information option
defined for DHCPv6 could be adopted, with some modifications, for
DHCPv4. This would enable the single stack IPv4 host to become aware
of the PMIP service support by the access network. Wheather the
approach of adopting the DHCPv6 options for DHCPv4 is feasible in
this particular case is for futher study.
The IPv4 host would include the Home Network Identifier option,
indicating its preferences, in the DHCPDISCOVER message. DHCPOFFER
message would include Home Network Information option indicating the
network type(s) supported by the access network and authorized for
the mobile node. The mobile node would indicate its choice in the
DHCPREQUEST message by including the Home Network Information option
with the id-type field set to the selected network type.
5. Security Considerations
TBD.
6. IANA Considerations
The following Extension Types MUST be assigned by IANA:
PMIP6 "N" indication flag in RA flags expansion option
PMIP6 Care-of Prefix Option type
Damic, et al. Expires December 21, 2007 [Page 12]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
Mobility Mode Option type
DHCPv6 Home Network Information option type
7. Acknowledgements
TBD.
8. Normative References
[I-D.haberman-ipv6-ra-flags-option]
Haberman, B. and R. Hinden, "IPv6 Router Advertisement
Flags Option", draft-haberman-ipv6-ra-flags-option-01
(work in progress), April 2007.
[I-D.ietf-mip6-hiopt]
Jang, H., "DHCP Option for Home Information Discovery in
MIPv6", draft-ietf-mip6-hiopt-05 (work in progress),
June 2007.
[I-D.ietf-netlmm-proxymip6]
S. Gundavelli et al., "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-00 (work in progress),
April 2007.
[RFC2023] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2023, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Damic, et al. Expires December 21, 2007 [Page 13]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007
Authors' Addresses
Damjan Damic
Nokia Siemens Networks
Zagrebacka 145a
Zagreb 10000
Croatia
Phone: +385 1-6331-337
Email: damjan.damic@siemens.com
Domagoj Premec
Nokia Siemens Networks
Zagrebacka 145a
Zagreb 10000
Croatia
Phone: +385 1-6105-923
Email: domagoj.premec@siemens.com
Basavaraj Patil
Nokia Siemens Networks
6000 Connection Drive
Irving, TX 75039
US
Phone:
Email: basavaraj.patil@nsn.com
Meghana Sahasrabudhe
Nokia Siemens Networks
313 Fairchild Drive
Mountain View, CA 94043
US
Phone:
Email: meghana.sahasrabudhe@nsn.com
Damic, et al. Expires December 21, 2007 [Page 14]
Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 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).
Damic, et al. Expires December 21, 2007 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-24 09:09:00 |