One document matched: draft-ietf-netlmm-nohost-req-05.txt
Differences from draft-ietf-netlmm-nohost-req-04.txt
Internet Draft J. Kempf, Editor
Document: draft-ietf-netlmm-nohost-req-05.txt October, 2006
Expires: April, 2007
Goals for Network-based Localized Mobility Management (NETLMM)
(draft-ietf-netlmm-nohost-req-05.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.
Contributors
Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and
Marco Liebsch all contributed major effort to this document. Their
names are not included in the authors' section due to the RFC
Editor's limit of 5 names.
Abstract
In this document, design goals for a network-based localized
mobility management (NETLMM) protocol are discussed.
Table of Contents
1.0 Introduction............................................2
2.0 NETLMM Functional Architecture..........................3
3.0 Goals for the NETLMM Protocol...........................3
4.0 IANA Considerations....................................10
5.0 Security Considerations................................11
Kempf, editor Expires April, 2007 [Page 1]
Internet Draft NETLMM Goals October, 2006
6.0 Acknowledgements.......................................11
7.0 Author's Addresses.....................................11
8.0 Normative References...................................12
9.0 Informative References.................................12
10.0 IPR Statements.........................................13
11.0 Disclaimer of Validity.................................13
12.0 Copyright Notice.......................................13
1.0 Introduction
In [1], the basic problems that occur when a global mobility
protocol is used for managing local mobility are described, and two
currently used approaches to localized mobility management - the
host-based approach that is used by most IETF protocols, and the
proprietary WLAN switch approach used between WLAN switches in
different subnets - are examined. The conclusion from the problem
statement document is that none of the approaches has a complete
solution to the problem. While the WLAN switch approach is most
convenient for network operators and users because it requires no
software on the mobile node other than the standard drivers for
WiFi, the proprietary nature limits interoperability and the
restriction to a single last hop link type and wired backhaul link
type restricts scalability. The IETF host-based protocols require
host software stack changes that may not be compatible with all
global mobility protocols, and also require specialized and complex
security transactions with the network that may limit
deployability. The conclusion was that a localized mobility
management protocol that was network based and required no software
on the host for localized mobility management is desirable.
This document develops a brief functional architecture and detailed
goals for a network-based localized mobility management protocol
(NETLMM). Section 2.0 describes the functional architecture of
NETLMM. In Section 3.0, a list of goals that are desirable in the
NETLMM protocol is presented. Section 4.0 concerns IANA
considerations. Section 5.0 briefly outlines security
considerations. More discussion of security can be found in the
threat analysis document [2].
1.1 Terminology
Mobility terminology in this draft follows that in RFC 3753 [10]
and in [1]. In addition, the following terms are related to the
functional architecture described in Section 2.0:
Localized Mobility Management Domain
An Access Network in the sense defined in [1] in which
mobility is handled by the NETLMM protocol.
Mobile Access Gateway
Kempf, editor Expires April, 2007 [Page 2]
Internet Draft NETLMM Goals October, 2006
A Mobile Access Gateway (MAG) is a functional network
element that terminates a specific edge link and tracks
mobile node IP level mobility between edge links, through
NETLMM signaling with the Localized Mobility Anchor. The MAG
also terminates host routed data traffic from the Localized
Mobility Anchor for mobile nodes currently located within
the edge link under the MAG's control, and forwards data
traffic from mobile nodes on the edge link under its control
to the Localized Mobility Anchor.
Local Mobility Anchor
A Local Mobility Anchor (LMA) is a router that maintains a
collection of host routes and associated forwarding
information for mobile nodes within a localized mobility
management domain under its control. Together with the MAGs
associated with it, the LMA uses the NETLMM protocol to
manage IP node mobility within the localized mobility
management domain. Routing of mobile node data traffic is
anchored at the LMA as the mobile node moves around within
the localized mobility management domain.
2.0 NETLMM Functional Architecture
The NETLMM architecture consists of the following components.
Localized Mobility Anchors (LMAs) within the backbone network
maintain a collection of routes for individual mobile nodes within
the localized mobility management domain. The routes point to the
Mobile Access Gateways (MAGs) managing the links on which the
mobile nodes currently are located. Packets for a mobile node are
routed to and from the mobile node through tunnels between the LMA
and MAG. When a mobile node moves from one link to another, the MAG
sends a route update to the LMA. While some mobile node involvement
is necessary and expected for generic mobility functions such as
movement detection and to inform the MAG about mobile node
movement, no specific mobile node to network protocol will be
required for localized mobility management itself. Host stack
involvement in mobility management is thereby limited to generic
mobility functions at the IP layer, and no specialized localized
mobility management software is required.
3.0 Goals for the NETLMM Protocol
Section 2 of [1] describes three problems with using a global
mobility management protocol for localized mobility management. Any
localized mobility management protocol must naturally address these
three problems. In addition, the side effects of introducing such a
solution into the network need to be limited. In this section, we
address goals for NETLMM including both solving the basic problems
(Goals 1, 2, 3) and limiting the side effects (Goals 4+).
Kempf, editor Expires April, 2007 [Page 3]
Internet Draft NETLMM Goals October, 2006
Some basic goals of all IETF protocols are not discussed in detail
here, but any solution is expected to satisfy them. These goals are
fault tolerance, robustness, interoperability, scalability, and
minimal specialized network equipment. A good discussion of their
applicability to IETF protocols can be found in [4].
Out of scope for the initial goals discussion are QoS and dormant
mode/paging. While these are important functions for mobile nodes,
they are not part of the base localized mobility management
problem. In addition, mobility between localized mobility
management domains is not covered here. It is assumed that this is
covered by the global mobility management protocols.
3.1 Handover Performance Improvement (Goal #1)
Handover packet loss occurs because there is usually latency
between when the link handover starts and when the IP subnet
configuration and global mobility management signaling completes.
During this time the mobile node is unreachable at its former
topological location on the old link where correspondents are
sending packets. Such misrouted packets are dropped. This aspect of
handover performance optimization has been the subject of much
work, both in other SDOs and in the IETF, in order to reduce the
latency in IP handover. Many solutions to this problem have been
proposed at the link layer and at the IP layer. One aspect of this
goal for localized mobility management is that the processing delay
for changing the forwarding after handover must approach as closely
as possible the sum of the delay associated with link layer
handover and the delay required for active IP layer movement
detection, in order to avoid excessive packet loss. Ideally, if
network-side link layer support is available for handling movement
detection prior to link handover or as part of the link handover
process, the routing update should complete within the time
required for link handover. This delay is difficult to quantify,
but for voice traffic, the entire handover delay including Layer 2
handover time and IP handover time should be between 40-70 ms to
avoid any degradation in call quality. Of course, if the link layer
handover latency is too high, sufficient IP layer handover
performance for good real time service cannot be matched.
A goal of the NETLMM protocol - in networks where the link layer
handover latency allows it - is to reduce the amount of latency in
IP handover, so that the combined IP and link layer handover
latency is less than 70 ms.
3.2 Reduction in Handover-related Signaling Volume (Goal #2)
Considering Mobile IPv6 [9] as the global mobility protocol (other
mobility protocols require about the same or somewhat less), if a
mobile node using address autoconfiguration is required to
Kempf, editor Expires April, 2007 [Page 4]
Internet Draft NETLMM Goals October, 2006
reconfigure on every move between links, the following signaling
must be performed:
1) Link layer signaling required for handover and reauthentication.
For example, in 802.11 [7] this is the Reassociate message
together with 802.1x [8] reauthentication using EAP.
2) Active IP level movement detection, including router
reachability. The DNA protocol [5] uses Router
Solicitation/Router Advertisement for this purpose. In addition,
if SEND [3] is used and the mobile node does not have a
certificate cached for the router, the mobile node must use
Certification Path Solicitation/Certification Path Advertisement
to obtain a certification path.
3) Two Multicast Listener Discovery (MLD) [14] REPORT messages, one
for each of the solicited node multicast addresses corresponding
to the link local address and the global address,
4) Two Neighbor Solicitation (NS) messages for duplicate address
detection, one for the link local address and one for the global
address. If the addresses are unique, no response will be
forthcoming.
5) Two NS messages from the router for address resolution of the
link local and global addresses, and two Neighbor Advertisement
messages in response from the mobile node,
6) Binding Update/Binding Acknowledgement between the mobile node
and home agent to update the care of address binding,
7) Return routability signaling between the correspondent node and
mobile node to establish the binding key, consisting of one Home
Test Init/Home Test and Care of Test Init/Care of Test,
8) Binding Update/Binding Acknowledgement between the correspondent
node and mobile node for route optimization.
Note that Steps 1-2 may be necessary even for intra-link mobility,
if the last hop link protocol doesn't provide much help for IP
handover. Step 3-5 will be different if stateful address
configuration is used, since additional messages are required to
obtain the address. Steps 6-8 are only necessary when Mobile IPv6
is used. The result is approximately 18 messages at the IP level,
where the exact number depends on various specific factors such as
whether the mobile node has a router certificate cached or not,
before a mobile node can be ensured that it is established on a
link and has full IP connectivity. In addition to handover related
signaling, if the mobile node performs Mobile IPv6 route
optimization, it may be required to renew its return routability
key periodically (on the order of every 7 minutes) even if it is
not moving, resulting in additional signaling.
The signaling required has a large impact on the performance of
handover, impacting Goal #1. Perhaps more importantly, the
aggregate impact from many mobile nodes of such signaling on
expensive shared links (such as wireless where the capacity of the
link cannot easily be expanded) can result in reduced last hop link
Kempf, editor Expires April, 2007 [Page 5]
Internet Draft NETLMM Goals October, 2006
capacity for data traffic. Additoinally, in links where the end
user is charged for IP traffic, IP signaling is not without cost.
To address the issue of signaling impact described above, the goal
is that handover signaling volume from the mobile node to the
network should be no more than what is needed for the mobile node
to perform secure IP level movement detection, in cases where no
link layer support exists. Furthermore, NETLMM should not introduce
any additional signaling during handover beyond what is required
for IP level movement detection. If link layer support exists for
IP level movement detection, the mobile node may not need to
perform any additional IP level signaling after link layer
handover.
3.3 Location Privacy (Goal #3)
In any IP network, there is a threat that an attacker can determine
the physical location of a network node from the node's topological
location. Depending on how an operator deploys their network, an
operator may choose to assign subnet coverage in a way that is
tightly bound to geography at some timescale or it may choose to
assign it in ways in which the threat of someone finding a node
physically based on its IP address is smaller. Allowing
the L2 attachment and L3 address to be less tightly bound is one
tool for reducing this threat to location privacy.
Mobility introduces an additional threat. An attacker can track a
mobile node's geographical location in real time, if the victim
mobile node must change its IP address as it moves from one subnet
to another through the covered geographical area. If the
granularity of the mapping between the IP subnets and geographical
area is small for the particular link type in use, the attacker can
potentially assemble enough information to find the victim in real
time.
In order to reduce the risk from location privacy compromises as a
result of IP address changes, the goal for NETLMM is to remove the
need to change IP address as a mobile node moves across links in an
access network. Keeping the IP address fixed over a large
geographical region fuzzes out the resolution of the mapping
between the IP subnets and geographical area, regardless of how
small the natural deployment granularity may be. This reduces the
chance that the attacker can deduce the precise geographic location
of the mobile node.
3.4 Limit Overhead in the Network (Goal #4)
Access networks, including both the wired and wireless parts, tend
to have somewhat stronger bandwidth and router processing
constraints than the backbone. In the wired part of the network,
these constraints are a function of the cost of laying fiber or
wiring to the wireless access points in a widely dispersed
Kempf, editor Expires April, 2007 [Page 6]
Internet Draft NETLMM Goals October, 2006
geographic area. In the wireless part of the network, these
constraints are due to the limitation on the number of bits per
Hertz imposed by the physical layer protocol. Therefore, any
solutions for localized mobility management should minimize
overhead within the access network.
3.5 Simplify Mobile Node Mobility Management Security by Deriving from
IP Network Access and/or IP Movement Detection Security (Goal #5)
Localized mobility management protocols that have host involvement
may require an additional security association between the mobile
node and the mobility anchor, and establishing this security
association may require additional signaling between the mobile
node and the mobility anchor (see [13] for an example). The
additional security association requires extra signaling and
therefore extra time to negotiate. Reducing the complexity of
mobile node to network security for localized mobility management
can therefore reduce barriers to deployment and improve
responsiveness. Naturally, such simplification must not come at the
expense of maintaining strong security guarantees for both the
network and mobile node.
In NETLMM, the network (specifically the MAG) derives the
occurrence of a mobility event requiring a routing update for a
mobile node from link layer handover signaling or IP layer movement
detection signaling from the mobile node. This information is used
to update routing for the mobile node at the LMA. The handover or
movement detection signaling must provide the network with proper
authentication and authorization so that the network can
definitively identify the mobile node and determine its
authorization. The authorization may be at the IP level, for
example, using something like SEND [3] to secure IP movement
detection signaling, or it may be at the link level. Proper
authentication and authorization must be implemeted on link layer
handover signaling and/or IP level movement detection signaling in
order for the MAG to securely deduce mobile node movement events.
Security threats to the NETLMM protocol are discussed in [2].
The goal is that security for NETLMM mobile node mobility
management should derive from IP network access and/or IP movement
detection security, such as SEND or network access authentication,
and not require any additional security associations or additional
signaling between the mobile node and the network.
3.6 Link Technology Agnostic (Goal #6)
The number of wireless link technologies available is growing, and
the growth seems unlikely to slow down. Since the standardization
of a wireless link physical and medium access control layers is a
time consuming process, reducing the amount of work necessary to
interface a particular wireless link technology to an IP network is
necessary. When the last hop link is a wireless link, a localized
Kempf, editor Expires April, 2007 [Page 7]
Internet Draft NETLMM Goals October, 2006
mobility management solution should ideally require minimal work to
interface with a new wireless link technology.
In addition, an edge mobility solution should provide support for
multiple wireless link technologies. It is not required that the
localized mobility management solution support handover from one
wireless link technology to another without change in IP address,
but this possibility should not be precluded.
The goal is that the localized mobility management protocol should
not use any wireless link specific information for basic routing
management, though it may be used for other purposes, such as
securely identifying a mobile node.
3.7 Support for Unmodified Mobile Nodes (Goal #7)
In the wireless LAN switching market, no modification of the
software on the mobile node is required to achieve localized
mobility management. Being able to accommodate unmodified mobile
nodes enables a service provider to offer service to as many
customers as possible, the only constraint being that the customer
is authorized for network access.
Another advantage of minimizing mobile node software for localized
mobility management is that multiple global mobility management
protocols can be supported. There are a variety of global mobility
management protocols that might also need support, including
proprietary or link technology-specific protocols needing support
for backward compatibility reasons. Within the Internet, both HIP
[11] and Mobike [6] are likely to need support in addition to
Mobile IPv6 [9], and Mobile IPv4 [12] support may also be
necessary.
Note that this goal does NOT mean that the mobile node has no
software at all associated with mobility. The mobile node must have
some kind of global mobility protocol if it is to move from one
domain of edge mobility support to another and maintain session
continuity, although no global mobility protocol is required if the
mobile node only moves within the coverage area of the localized
mobility management protocol or no session continuity is required
during global movement. Also, if the last hop link is a wireless
link, every wireless link protocol requires handover support on the
mobile node in the physical and medium access control layers,
typically in the wireless interface driver. Information passed from
the medium access control layer to the IP layer on the mobile node
may be necessary to trigger IP signaling for IP handover. Such
movement detection support at the IP level may be required in order
to determine whether the mobile node's default router is still
reachable after the move to a new access point has occurred at the
medium access control layer. Whether or not such support is
required depends on whether the medium access control layer can
Kempf, editor Expires April, 2007 [Page 8]
Internet Draft NETLMM Goals October, 2006
completely hide link movement from the IP layer. For cellular type
wireless link protocols, the mobile node and network undergo an
extensive negotiation at the medium access control layer prior to
handover, so it may be possible to trigger routing update without
any IP protocol involvement. However, for a wireless link protocol
such as IEEE 802.11 [7] in which the decision for handover is
entirely in the hands of the mobile node, IP layer movement
detection signaling from the mobile node may be required to trigger
a routing update.
The goal is that the localized mobility management solution should
be able to support any mobile node that joins the link and that has
a interface that can communicate with the network, without
requiring localized mobility management software on the mobile
node.
3.8 Support for IPv4 and IPv6 (Goal #8)
While most of this document is written with IPv6 in mind, localized
mobility management is a problem in IPv4 networks as well. A
solution for localized mobility that works for both versions of IP
is desirable, though the actual protocol may be slightly different
due to the technical details of how each IP version works. From
Goal #7 (Section 3.7), minimizing mobile node support for localized
mobility means that ideally no IP version-specific changes should
be required on the mobile node for localized mobility, and that
global mobility protocols for both IPv4 and IPv6 should be
supported. Any IP version-specific features should be confined to
the network protocol.
3.9 Re-use of Existing Protocols Where Sensible (Goal #9)
Many existing protocols are available as Internet Standards upon
which the NETLMM protocol can be built. The design of the protocol
should have a goal to re-use existing protocols where it makes
architectural and engineering sense to do so. The design should
not, however, attempt to re-use existing protocols where there is
no real architectural or engineering reason. For example, the suite
of Internet Standards contains several good candidate protocols for
the transport layer, so there is no real need to develop a new
transport protocol specifically for NETLMM. Re-use is clearly a
good engineering decision in this case, since backward
compatibility with existing protocol stacks is important. On the
other hand, the network-based, localized mobility management
functionality being introduced by NETLMM is a new piece of
functionality, and therefore any decision about whether to re-use
an existing global mobility management protocol should carefully
consider whether re-using such a protocol really meets the needs of
the functional architecture for network-based localized mobility
management. The case for re-use is not so clear in this case, since
there is no compelling backward compatibility argument.
Kempf, editor Expires April, 2007 [Page 9]
Internet Draft NETLMM Goals October, 2006
3.10 Localized Mobility Management Independent of Global Mobility
Management (Goal #10)
Localized mobility management should be implementable and
deployable independently of any global mobility management
protocol. This enables the choice of local and global mobility
management to be made independently of particular protocols that
are implemented and deployed to solve the two different sorts of
mobility management problems. The operator can choose a particular
localized mobility management protocol according to the specific
features of their access network. It can subsequently upgrade the
localized mobility management protocol on its own, without even
informing the mobile nodes. Similarly, the mobile nodes can use a
global mobility management protocol that best suits their
requirements, or even not use one at all. Also, a mobile node can
move into a new access network without having to check that it
understands the localized mobility management protocol being used
there.
The goal is that the implementation and deployment of the localized
mobility management protocol should not restrict, or be restricted
by, the choice of global mobility management protocol.
3.11 Configurable Data Plane Forwarding between Local Mobility Anchor
and Mobile Access Gateway (Goal #11)
Different network operators may require different types of
forwarding options between the LMA and the MAGs for mobile node
data plane traffic. An obvious forwarding option that has been used
in past IETF localized mobility management protocols is IP-IP
encapsulation for bidirectional tunneling. The tunnel endpoints are
the LMA and the MAGs. But other options are possible. Some network
deployments may prefer routing-based solutions. Others may require
security tunnels using IPsec ESP encapsulation if part of the
localized mobility management domain runs over a public access
network and the network operator wants to protect the traffic.
A goal of the NETLMM protocol is to allow the forwarding between
the LMA and MAGs to be configurable depending on the particulars of
the network deployment. Configurability is not expected to be
dynamic as in controlled by the arrival of a mobile node; but
rather, configuration is expected to be similar in time scale to
configuration for routing. The NETLMM protocol may designate a
default forwarding mechanism. It is also possible that additional
work may be required to specify the interaction between a
particular forwarding mechanism and the NETLMM protocol, but this
work is not in scope of the NETLMM base protocol.
4.0 IANA Considerations
There are no IANA considerations for this document.
Kempf, editor Expires April, 2007 [Page 10]
Internet Draft NETLMM Goals October, 2006
5.0 Security Considerations
There are two kinds of security issues involved in network-based
localized mobility management: security between the mobile node and
the network, and security between network elements that participate
in the NETLMM protocol. The security-related goals in this
document, described in Section 3.3 and 3.5, focus on the former,
because those are unique to network-based mobility management. The
threat analysis document [2] contains a more detailed discussion of
both kinds of threats, which the protocol design must address.
6.0 Acknowledgements
The authors would like to acknowledge the following for
particularly diligent reviewing: Vijay Devarapalli, Peter McCann,
Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred
Templin.
7.0 Author's Addresses
James Kempf
DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110
USA
Phone: +1 408 451 4711
Email: kempf@docomolabs-usa.com
Kent Leung
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: kleung@cisco.com
Phil Roberts
Motorola Labs
Schaumberg, IL
USA
Email: phil.roberts@motorola.com
Katsutoshi Nishida
NTT DoCoMo Inc.
3-5 Hikarino-oka, Yokosuka-shi
Kanagawa,
Japan
Phone: +81 46 840 3545
Email: nishidak@nttdocomo.co.jp
Gerardo Giaretta
Kempf, editor Expires April, 2007 [Page 11]
Internet Draft NETLMM Goals October, 2006
Telecom Italia Lab
via G. Reiss Romoli, 274
10148 Torino
Italy
Phone: +39 011 2286904
Email: gerardo.giaretta@tilab.com
Marco Liebsch
NEC Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221-90511-46
Email: marco.liebsch@ccrle.nec.de
8.0 Normative References
[1] Kempf, J., editor, "Problem Statement for IP Local Mobility,"
Internet Draft, Work in Progress.
[2] Vogt, C., and Kempf, J., "Security Threats to Network-based
Localized Mobility Management", Internet Draft, Work in
Progress.
9.0 Informative References
[3] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure
Neighbor Discovery (SEND)", RFC 3971, March, 2005.
[4] Carpenter, B., "Architectural Principles of the Internet,"
RFC 1958, June, 1996.
[5] Choi, J, and Daley, G., "Goals of Detecting Network
Attachment in IPv6", Internet Draft, Work in Progress.
[6] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[7] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical
Layer (PHY) specifications", IEEE Std. 802.11, 1999.
[8] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard
802.1x, June, 2001.
[9] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in
IPv6", RFC 3775, June, 2004.
[10] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC
3753, June, 2004.
[11] Moskowitz, R., and Nikander, P., "Host Identity Protocol
(HIP) Architecture", RFC 4423, May, 2006.
[12] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August, 2002.
[13] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L.,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
4140, August, 2005.
[14] Vida, R., and Costa, L., " Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
Kempf, editor Expires April, 2007 [Page 12]
Internet Draft NETLMM Goals October, 2006
10.0 IPR Statements
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.
11.0 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.
12.0 Copyright Notice
Copyright (C) The Internet Society (2006). 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.
Kempf, editor Expires April, 2007 [Page 13] | PAFTECH AB 2003-2026 | 2026-04-23 09:45:21 |