One document matched: draft-oneill-mobileip-home-address-leasetime-00.txt
Mobile IP Working Group Alan O'Neill
INTERNET-DRAFT Flarion Technologies
Category: Standards Track
June 2004
Mobile IPv4 Home Address Leasetime
draft-oneill-mobileip-home-address-leasetime-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 expires January 9, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
With the introduction of NAIs for identifying Mobile Nodes, RFC
2794 also enabled the Home Agents to be able to assign IP addresses
to the Mobile Nodes during the initial registration. Though the
concept of NAI-based home address assignment is referenced in both
RFC 2794 and RFC 3344, a comprehensive procedure for achieving such
a NAI-based home address assignment has not been outlined. More
particularly, the lifetime of the assigned address is undefined and
the address status when deregistering from the HA, such as when
returning to the home network, is also undefined. This document
first defines a default address lifetime for RFC3344 MIP entities
to resolve this ambiguity. The document then specifies a dynamic
home address leasetime, as well as two new MIP extensions and
associated procedures to facilitate management of a dynamic home
address leasetime between the MN and the HA.
A.W.O’Neill Expires - January, 9, 2005 [Page 1]
Mobile IPv4 Home Address Leasetime July, 2004
Table of Contents
Status of this Memo.................................................1
Abstract............................................................1
Table of Contents...................................................2
1. Problem Statement................................................2
2. Proposed Solution Overview.......................................4
3. Terminology......................................................5
4. Requirements and Scope...........................................5
5. Default and Dynamic Home Address Leasetimes for RFC3344..........6
5.1 Returning Home..................................................6
5.2 MIP Binding Expiry..............................................7
5.3 MIP Binding Deregistration (not at home)........................7
6. MIP based Extensions for Dynamic Home Address Leasetime .........7
6.1 Home Address Lease Request......................................7
6.2 Home Address Lease Grant........................................8
6.3 HALR Protocol Rules.............................................9
6.4 HALG Protocol Rules............................................10
6.5 HA Deregistration Considerations...............................10
7. IANA Considerations.............................................11
7.1 Mobile IP Extension Type and Subtypes..........................11
7.2 Mobile IP Error codes..........................................11
8. Security Considerations.........................................11
9. Backward Compatibility Considerations...........................11
9.1 Legacy Home Agent..............................................11
9.2 Legacy Foreign Agent...........................................12
9.3 Legacy Mobile Node.............................................12
10. Acknowledgements...............................................12
Informative References.............................................12
Authors’ Addresses.................................................12
IPR Statement......................................................13
Copyright Statement................................................13
Disclaimer of Validity.............................................13
Acknowledgement....................................................13
1. Problem Statement
With the introduction of NAIs for identifying Mobile Nodes, RFC
2794 also enabled the Home Agents to be able to assign IP addresses
to the Mobile Nodes during the initial registration. Though the
concept of home address assignment is referenced in both RFC 2794
and RFC 3344, a comprehensive procedure for managing such a home
address assignment has not been outlined. More particularly, the
lifetime of the assigned address is undefined and the address status
when deregistering from the HA, such as when returning to the home
network, is also undefined, as described below.
An RFC 3344 MN can set the home address field to 0.0.0.0 in a
RRQ(0.0.0.0) to request the return of a dynamically assigned home
address to the MN within the RRP. The RRP as presently specified
does not however contain an address lifetime. The lack of an address
A.W.O’Neill Expires - January, 9, 2005 [Page 2]
Mobile IPv4 Home Address Leasetime July, 2004
lifetime in the RRP can be interpreted by the MN as either;
i) implying an infinite home address lifetime (ie static
allocation).
ii) implying a lifetime equal to that of the MIP binding such
that the address is automatically deallocated on the expiry
of that binding whether as a result of lifetime expiry or as
a result of an explicit deallocation.
iii) implying an undefined lifetime such that no assumption on
the lifetime can be made and is to be defined by other
mechanism.
Therefore MIP nodes from different vendors can, and apparently do,
have different views on that lifetime, leading to different and
incompatible processing rules. Further, it is apparent that each of
these interpretations are in themselves also problematic in specific
scenarios such that attempting to simply gain consensus for one of
them is inappropriate. One can consider that the existence of the
multiple interpretations has arisen out of the different
requirements for those specific scenarios.
For example, in case (ii), it is clear that when a MN returns to its
home network and deregisters from the HA then the home address is
lost and can be reallocated by the HA to another node, resulting in
disruption to any ongoing sessions of the MN that continue to employ
that home address on the home network. This interpretation also
fails if a MN wishes to maintain a home address when it deregisters
from the HA for efficiency reasons (going to sleep, disconnecting
from the access network) or as a result of a binding lifetime expiry
following some kind of a failure. This is because by definition the
address is deallocated on binding expiry. If the MN never needs to
return home and never needs to employ the same address across
multiple MIP sessions, and hence during the absence of a MIP binding,
then this interpretation is appropriate.
In case (i), the address has an infinite lifetime and hence the home
address will work when returning home and can be otherwise
maintained across multiple MIP sessions and in the absence of a
binding, but no specification exists to deallocate that address from
the MN and hence efficiently maintain the address block at the HA
using MIP mechanisms. The home address is then in fact a static
address from the perspective of MIP, and dynamic address allocation
is not supported.
In case (iii), manual configuration or additional non-MIP protocol
mechanisms can define the address lifetime that is associated with
the home address that is returned in the RRP. This enables a form
of dynamic address allocation to be supported with specific
constraints. For example, manual configuration of lifetimes is
inefficient for dynamic addressing schemes. It also creates
A.W.O’Neill Expires - January, 9, 2005 [Page 3]
Mobile IPv4 Home Address Leasetime July, 2004
difficulties when the manually configured address lifetime is less
than the MIP binding lifetime because of the resulting protocol
ambiguities and/or impact on ongoing communications with that
address. The MN could alternatively obtain lifetime information from
DHCP following MIP based home address allocation, but then it
would seem much more appropriate to obtain both the address and the
lifetime via DHCP and then register that new home address via MIP
whilst maintaining the address lifetime via DHCP. This is however
typically too time-consuming for fast-moving mobile devices. It can
be seen therefore that this interpretation might be appropriate for
road warrior type applications and for semi-static addresses but is
unlikely to be appropriate for dynamic home address allocation for
such highly mobile devices.
This document first proposes a default interpretation for the
ambiguous address lifetime and associated behaviour in RFC3344, that
will inevitably only be backwards compatible with a subset of
current implementations. This document then specifies additional
protocol mechanisms that the Mobile IP entities in RFC3344 should
follow in order to facilitate dynamic home address lifetimes for MIP
based home address allocation. The approach taken is to ensure that
the address lifetime management is tightly coupled to the home
address allocation by extending MIP mobility signaling and fully
integrating the default and dynamic address leasetimes.
2. Proposed Solution Overview
Firstly, the default interpretation for the home address lifetime in
RFC3344 style home address allocation, for MIP entities that are
compliant with this document, MUST be that the lifetime is equal to
the MIP binding lifetime. This choice is fully defined in section 5
and is preferred because the general model for the overall solution
is that the address lifetime is provided by MIP signaling and hence
is tightly coupled to the address allocation and binding lifetime
signalling. Highly mobile devices that employ licensed cellular
spectrum are less ameniable to both DHCP and MIP based address
lifetime management overheads, and cellular mobile systems typically
employ a virtual home network that the mobile node does not visit
and hence the default lifetime interpretation is at least fully
defined and acceptable for a significant scenario. In addition, road
warrior and enterprise scenarios are more amenable to DHCP based
home address / lifetime allocation, and to the additional cost of
maintaining a non-default dynamic address lifetime due to the less
expensive access bandwidth typically employed in enterprise, fixed
and WLAN access scenarios. Note that this default interpretation
says nothing about MIP entities that are only compliant with RFC3344
and not with this document, which will continue to interpret the
ambiguous home address lifetime in multiple ways at the cost of
interoperability. However, it should be clear that such RFC3344
entities can be viewed as being compatible with this default
interpretation in combination with a configured address leasetime
A.W.O’Neill Expires - January, 9, 2005 [Page 4]
Mobile IPv4 Home Address Leasetime July, 2004
with a value between zero and infinity.
Secondly, a Home Address Leasetime Request (HALR) MIP extension and
associated protocol, is defined to enable a MN to request a dynamic
home address leasetime for an existing, or to be allocated, home
address. The presence of this extension indicates to the FA and the
HA that the MN is capable of home address leasetime management.
Finally, a Home Address Leasetime Grant (HALG) MIP extension and
associated protocol, is defined to enable the HA to communicate a
dynamic home address leasetime to the MN in a RRP when the home
address lifetime needs to be different to the (default) MIP binding
lifetime. The HA can include the HALG in a RRP if the RRQ included a
HALR or if the HA has other state or indication that the MN is
capable of home address leasetime management.
The HALR and HALG extensions and the associated processing rules are
defined in section 6.
The default address lifetime interpretation and the MIP based HALR /
HALG extensions are also applicable to MIP entities that support
NAI-Based Home Address Assignment, that is being developed in
[NAIaddr]. The implications of this document on that work is
included in that document and not further qualified here.
3. Terminology
MN Mobile Node as defined in RFC 3344
HA Home Agent as defined in RFC 3344
FA Foreign Agent as defined in RFC 3344
RRQ Mobile IP Registration Request as defined in RFC 3344
RRP Mobile IP Registration Reply as defined in RFC 3344
HoA MN’s Home Address
RRQ(0.0.0.0) RFC3344 request for dynamic Home Address allocation
RRQ(a.b.c.d) A RRQ containing the current HoA of the MN.
RRQ(HALR) A RRQ containing the HALR extension.
RRP(HALG) A RRP containing the HALG extension.
4. Requirements and Scope
Following are the requirements that the proposed home address
leasetime scheme tries to satisfy.
- Define a default home address leasetime of zero seconds for
RFC3344 MIP entities such that the default address lifetime
is equal to the binding lifetime.
- Specify the HALR and HALG MIP extensions for optional dynamic
home address leasetime agreement.
A.W.O’Neill Expires - January, 9, 2005 [Page 5]
Mobile IPv4 Home Address Leasetime July, 2004
- Specify the HA/FA/MN behavior for the use of the default and
dynamic address leasetimes.
- Specifically outline MIP entity behaviour when the MN returns
home, for MIP based HoA lifetime management.
- A MN that has been assigned the home address and the home
address lifetime by means other than dynamic allocation by the
HA, is outside the scope of this document.
5. Default and Dynamic Home Address Leasetime for RFC3344 MIP Entities
The MIP home address lifetime is defined to be the sum of the
remaining MIP binding lifetime and the remaining portion of the home
address leasetime. This definition simplifies the state machines at
the HA and MN by implicitly ensuring that the binding lifetime can
never be greater than the remaining lifetime of the home address.
This also removes significant motivation for an attacker to attempt
to interfere with the address leasetime parameter within MIP signals
because this can never force the MN into releasing a home address
for a current binding.
The default home address leasetime MUST be zero such that the
default home address lifetime is equal to the MIP binding lifetime.
When a MN deregisters a MIP binding or that binding otherwise
expires, then the MN/FA/HA entities MUST consider that the home
address leasetime has expired. The MN MUST then cease employing that
home address for its communications. The HA MAY then return the home
address to the dynamic home address allocation pool.
The MN MAY acquire a dynamic home address leasetime as a result of
MIP signaling extensions defined in section 6.
The MN and the HA MAY alternatively be configured with a dynamic
home address leasetime that extends the home address ownership
beyond the current MIP binding lifetime (ie to infinity) but such
configuration is outside the scope of this draft.
This specification does not mandate an implementation approach for
the home address lifetime processing and is only concerned with the
observable behaviour. However, as an example, a Home Address Lease
Timer may be considered to start when the binding lifetime expires
or is explicitly cancelled. The home address is considered de-
allocated from the MN when this Lease Timer expires.
5.1 MN Returning Home
RFC3344 specifies that the MN deregisters its MIP binding on
returning to the home network. This can lead to the MN losing its
current home address if the home address lifetime is equal to the
A.W.O’Neill Expires - January, 9, 2005 [Page 6]
Mobile IPv4 Home Address Leasetime July, 2004
remaining binding lifetime (leasetime=0). In such scenarios, the MN
and HA MAY avoid this result by;
i) by using MIP protocol mechanisms to manage a dynamic home
address leasetime, or
ii) by using non-MIP home address management mechanisms which are
outside the scope of this draft.
It should be noted that a MN that is allowed to return to a home
network typically has a close administrative association with the HA
for that home network which should ensure consistent home
address leasetime management on the MN and the HA.
5.2 MIP Binding Expiry
If a MIP binding expires, potentially as a result of a loss of
connectivity or a MIP entity failure, then the dynamically allocated
home address MUST be released. If a dynamic home address leasetime
exists then the home address MUST NOT be released until after the
expiry of this leasetime. This can be used to provide an extended
period for the MN to try to re-establish the MIP session for the
current home address.
5.3 MIP Binding Deregistration (not at home)
If a MIP binding is deregistered, and the HA observes correct
protocol behaviour, then the HA may perceive an opportunity to
reclaim the home address immediately. However, the HA MUST NOT
reclaim the home address until the expiry of the dynamic home
address leasetime to ensure that the HA and the MN remain
synchronised and so that, for example, the user can recover a MIP
session for the current home address when that session was
mistakenly terminated.
6. MIP based Extensions for Dynamic Home Address Leasetime
This section further defines the MIP home address leasetime
feature by providing extensions to RFC3344 to facilitate MIP based
dynamic home address leasetime management.
6.1 Home Address Leasetime Request Extension
This extension is included by the MN to inform the home agent that
it is requesting an address leasetime in addition to a binding
lifetime. This skippable extension follows the short extension
format as defined in [2], where the subtype indicates the specific
address management extension.
A.W.O’Neill Expires - January, 9, 2005 [Page 7]
Mobile IPv4 Home Address Leasetime July, 2004
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 | Sub-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leasetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Address Management Extension (skippable) [2]
Sub-Type 1
Length 4
Reserved Reserved for future use. MUST be set to 0 on
sending and MUST be ignored on reception.
Leasetime The time in seconds, in addition to the current
binding lifetime, that the MN is requesting as the
address leasetime. A value of zero indicates a
request to remove the current leasetime. A value of
0xffff indicates an infinite address leasetime.
A MN can request a leasetime that is greater than
the current leasetime to extend the home address
lifetime.
6.2 Home Address Leasetime Grant Extension
This extension is included by the HA to inform the MN and FA of the
granted address lifetime. This skippable extension follows the short
extension format as defined in [2], where the subtype indicates the
specific address management extension.
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 | Sub-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leasetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Address Management Extension (skippable) [2]
Sub-Type 2
Length 4
Reserved Reserved for future use. MUST be set to 0 on
sending and MUST be ignored on reception.
Leasetime The time in seconds, in addition to the current
A.W.O’Neill Expires - January, 9, 2005 [Page 8]
Mobile IPv4 Home Address Leasetime July, 2004
binding lifetime, that the HA is granting as the
address leasetime. A value of zero indicates
mandatory removal of the current dynamic leasetime.
A value of 0xffff indicates an infinite address
leasetime. A HA can grant a leasetime that is
greater than the current leasetime but not greater
than the requested leasetime in the HALR.
6.3 HALR Protocol Rules
The HALR requests a specific dynamic home address leasetime at
the HA, and can also be used to communicate (as yet unspecified)
flag bits that, for example, can indicate additional MN capabilities
or requirements that refine the request for a dynamic home address
leasetime. The HALR MUST NOT be included by a MN that is otherwise
not capable of managing home address leasetimes as defined by this
specification. The HALR MUST always precede the authorization-
enabling extension between the MN and the HA.
The HALR extension MUST be added by a MN into the RRQ to indicate
compliance with this specification to the HA, and to any FA.
The MN MAY employ the HALR whether or not the FA or HA are known to
support this specification. The FA MAY inspect the requested
leasetime but MUST NOT undertake any new MIP processing as a result
of that value. A HA that does not support this specification will
skip the HALR and not return a HALG to the MN, so indicating its
lack of support to the MN. A HA that receives a HALR from a MN
indicates that the MN is compliant with this specification.
The HALR may be included into a RRQ with home address field equal
to 0.0.0.0, indicating according to RFC3344 that the MN does not
know its home address, and therefore wishes to obtain its home
address from the HA via the RRP.
The HALR can be included into a RRQ with home address field equal
to a previously allocated address RRQ(a.b.c.d), indicating
according to RFC3344, that the MN knows its home address. This
enables the MN to request allocation or modification of an address
leasetime at any stage of the MIP binding lifecycle, and independent
of whether the address was allocated via MIP or other mechanisms.
The requested home address leasetime is a requested absolute
increment on the current binding lifetime of the MN as determined by
the MN and the HA. This means that this leasetime does not need to
be refreshed whilst the MN has a non-zero binding lifetime so
reducing the MIP signaling load. When the MN has an expired or
cancelled binding lifetime then the home address leasetime is
incrementally consumed, and therefore needs to be replenished
periodically to avoid the home address being released. The default
refresh interval is 1/3 of the initial granted leasetime and
independent of the remaining dynamic leasetime.
A.W.O’Neill Expires - January, 9, 2005 [Page 9]
Mobile IPv4 Home Address Leasetime July, 2004
6.4 HALG Protocol Rules
The HALG extension MAY be added by a HA into the RRP to enable the
HA to grant a dynamic home address leasetime to the MN, and can also
be used to communicate (as yet unspecified)
flag bits that, for example, can indicate additional HA capabilities
or conditions that refine the granted home address leasetime. The
granted dynamic address leasetime is for the current home address of
a MN that is associated with the RRQ/RRP. The HALG enables the MN to
generate a home address lifetime which is the sum of the home
address leasetime plus the MIP binding lifetime in the RRP. The
dynamic address leasetime grant extensions avoids the need for
configured leasetimes on MNs.
The HALG MUST NOT be included by a HA if the HA has had no
indication from the MN for this MIP session that the MN is complaint
with this specification. Such indication is given from a previously
received RRQ(HALR).
A compliant HA MUST return a RRP(HALG) on receipt of a RRQ(HALR)
but MAY reduce the requested leasetime based on local policy
information. Specifically, the leasetime MAY be reduced to zero and
MAY be different from the contents of any previously returned
leasetime. A compliant HA MAY also return a RRP(HALG) on receipt
of a RRQ that does not include HALR, provided that a previous
RRQ(HALR) has been received from the MN. Specifically, the HA SHOULD
return RRP(HALG) in response to a RRQ(lifetime=0) or when sending a
RRP(registration revocation).
The HA MAY return the HALG whether or not the FA or MN are known to
support this specification. The FA MAY inspect the granted leasetime
but MUST NOT undertake any new MIP processing as a result of that
value. A MN that does not support this specification will skip any
HALG delivered as a result of a protocol failure.
The HALG does not presently communicate whether the HA supports a
real or virtual home network for the home address of the MN. The
HALG also does not presently communicate the availability of
alternative (i.e. non-MIP based) home address leasetime management
techniques to the use of the HALR/HALG extensions.
6.5 HA Deregistration Considerations
An RFC3344 MN cancels a MIP binding at a HA by sending a
deregistration for the current binding which leads to the removal of
the binding entry at the HA, and the associated dynamic MIP
signaling state used for replay protection and message sequencing.
To enable a MN to be able to maintain a home address after
cancellation of the binding entry, it is clear that home address
state must be independently maintained at the HA. In addition, to
A.W.O’Neill Expires - January, 9, 2005 [Page 10]
Mobile IPv4 Home Address Leasetime July, 2004
enable a MN to use MIP signaling to subsequently, and periodically,
refresh a home address leasetime after binding cancellation, it is
necessary to maintain MIP signaling state after binding cancellation,
whilst active home address leasetime state exists. MIP signaling
state for a MN HoA may be removed only when the MIP home address
lifetime (binding lifetime plus home address leasetime) has expired.
A valid implementation option, for example, is to maintain a binding
entry that includes unexpired home address leasetime information,
but that has an expired binding lifetime.
7. IANA Considerations
7.1 Mobile IP Extension Type and Subtypes
This document introduces the following Mobile IP extension type.
Name : Address Management Extensions
Type Value : TBD
Section : 6
This document also introduces two of the following subtypes for the
above extension type.
Sub-type Name Section
-------- ---- -------
1 Home Address Leasetime Request 6.1
2 Home Address Leasetime Grant 6.2
7.2 Mobile IP Error codes
This document introduces no new error codes that can be returned by
the FA or HA in a Mobile IP Registration Reply.
8. Security Considerations
The above mentioned procedure for home address leasetime management
introduces the HALR and HALG extensions which MUST be protected by
an authorization-enabling extension [2] between the MN and the HA.
Thus, this procedure does not introduce any new security concerns.
9. Backward Compatibility Considerations
9.1 Legacy Home Agent
Upon receiving a RRQ(HALR) from a MN following the procedure
outlined in this document, the legacy HA SHOULD follow the behavior
as per RFC 3344, ignoring the HALR extension which has been defined
in the skippable range of extensions.
A.W.O’Neill Expires - January, 9, 2005 [Page 11]
Mobile IPv4 Home Address Leasetime July, 2004
9.2 Legacy Foreign Agent
For the cases where the RRQ(HALR) is sent by the MN with home
address field set to 0.0.0.0 or a.b.c.d, the behavior of the legacy
FA will be the same as per RFC 3344.
For the cases where the RRP(HALG) is sent by the HA, the behavior
of the legacy FA will be the same as per RFC 3344.
9.3 Legacy Mobile Node
The RRQ behavior of a legacy MN will not be affected, since the new
behavior will be applicable only for RRQs which include the HALR
so indicating compliance with this specification.
The RRP behaviour of a legacy MN is also not affected by the
receipt of an unsolicited HALG as it is only used with a MN that has
indicated compliance with this specification. It is also a skippable
extension and behaviour will progress as per RFC 3344 if incorrectly
sent to a non-compliant MN as a result of a bug, and whilst this
does mean that the MN and HA can have different views on the
lifetime of the home address, it is always assured that the HA has a
greater lifetime than the MN.
10. Acknowledgements
Many thanks to Naveen Paulkandasamy and Kent Leung of Cisco Systems
for review of, and contributions to this document.
Informative References
[1] P. Calhoun and C. Perkins, "Mobile IP Network Access Identifier
Extension for IPv4", RFC 2794, March 2000.
[2] C. Perkins, "IP Mobility Support for IPv4", RFC 3344, August
2002.
[3] Paulkandasamy & Leung, "NAI-Based Home Address Assignment",
draft-paulkandasamy-mobileip-nai-based-home-address-00.txt,
March, 2004.
Authors’ Addresses
Alan O'Neill
Flarion Technologies
a.oneill@flarion.com
A.W.O’Neill Expires - January, 9, 2005 [Page 12]
Mobile IPv4 Home Address Leasetime July, 2004
Intellectual Property Statement
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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Disclaimer of Validity
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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
A.W.O’Neill Expires - January, 9, 2005 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 04:34:39 |