diff options
Diffstat (limited to 'doc/rfc/rfc4831.txt')
| -rw-r--r-- | doc/rfc/rfc4831.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc4831.txt b/doc/rfc/rfc4831.txt new file mode 100644 index 0000000..2e97161 --- /dev/null +++ b/doc/rfc/rfc4831.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group J. Kempf, Ed. +Request for Comments: 4831 DoCoMo USA Labs +Category: Informational April 2007 + + + Goals for Network-Based Localized Mobility Management (NETLMM) + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + In this document, design goals for a network-based localized mobility + management (NETLMM) protocol are discussed. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Terminology ................................................2 + 2. NETLMM Functional Architecture ..................................3 + 3. Goals for the NETLMM Protocol ...................................3 + 3.1. Goal 1: Handover Performance Improvement ...................4 + 3.2. Goal 2: Reduction in Handover-Related Signaling Volume .....5 + 3.3. Goal 3: Location Privacy ...................................6 + 3.4. Goal 4: Limit Overhead in the Network ......................7 + 3.5. Goal 5: Simplify Mobile Node Mobility Management + Security by Deriving from IP Network Access and/or IP + Movement Detection Security ................................7 + 3.6. Goal 6: Link Technology Agnostic ...........................8 + 3.7. Goal 7: Support for Unmodified Mobile Nodes ................8 + 3.8. Goal 8: Support for IPv4 and IPv6 ..........................9 + 3.9. Goal 9: Reuse of Existing Protocols Where Sensible ........10 + 3.10. Goal 10: Localized Mobility Management + Independent of Global Mobility Management ................10 + 3.11. Goal 11: Configurable Data Plane Forwarding + between Local Mobility Anchor and Mobile Access Gateway ..11 + 4. Security Considerations ........................................11 + 5. Acknowledgements ...............................................11 + 6. Normative References ...........................................12 + 7. Informative References .........................................12 + 8. Contributors ...................................................13 + + + +Kempf Informational [Page 1] + +RFC 4831 NETLMM Goals April 2007 + + +1. 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 + Wireless LAN (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. They also require specialized and complex security + transactions with the network that may limit deployability. The + conclusion is that a localized mobility management protocol that is + network based and requires 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 describes the functional architecture of NETLMM. + In Section 3, a list of goals that is desirable in the NETLMM + protocol is presented. Section 4 briefly outlines Security + Considerations. More discussion of security can be found in the + threat analysis document [2]. + +1.1. Terminology + + Mobility terminology in this document follows that in RFC 3753 [10] + and in [1]. In addition, the following terms are related to the + functional architecture described in Section 2: + + 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 + + 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 + + + +Kempf Informational [Page 2] + +RFC 4831 NETLMM Goals April 2007 + + + 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. 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. 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, and 3) and limiting the side effects (Goals 4+). + + + + + + + + +Kempf Informational [Page 3] + +RFC 4831 NETLMM Goals April 2007 + + + 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 Quality of Service + (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. Goal 1: Handover Performance Improvement + + 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 Standards Development Organizations (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-layer and link-layer handover + latency is less than 70 ms. + + + + + + + +Kempf Informational [Page 4] + +RFC 4831 NETLMM Goals April 2007 + + +3.2. Goal 2: Reduction in Handover-Related Signaling Volume + + 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 + 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 Detecting Network Attachment (DNA) protocol [5] uses Router + Solicitation/Router Advertisement for this purpose. In addition, + if SEcure Neighbor Discovery (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. Steps 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 + + + +Kempf Informational [Page 5] + +RFC 4831 NETLMM Goals April 2007 + + + used. The result is approximately 18 messages at the IP level, where + the exact number depends on various specific factors, such as whether + or not the mobile node has a router certificate cached 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 capacity for data + traffic. Additionally, 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. Goal 3: Location Privacy + + 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. + + + + +Kempf Informational [Page 6] + +RFC 4831 NETLMM Goals April 2007 + + + 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. Goal 4: Limit Overhead in the Network + + 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 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. Goal 5: Simplify Mobile Node Mobility Management Security by + Deriving from IP Network Access and/or IP Movement Detection + Security + + 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 at + + + +Kempf Informational [Page 7] + +RFC 4831 NETLMM Goals April 2007 + + + the link level. Proper authentication and authorization must be + implemented 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. Goal 6: Link Technology Agnostic + + 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 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 a change in the 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. Goal 7: Support for Unmodified Mobile Nodes + + In the WLAN 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 Host + + + +Kempf Informational [Page 8] + +RFC 4831 NETLMM Goals April 2007 + + + Identity Protocol (HIP) [11] and IKEv2 Mobility and Multihoming + (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 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 a 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 an + interface that can communicate with the network, without requiring + localized mobility management software on the mobile node. + +3.8. Goal 8: Support for IPv4 and IPv6 + + 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. + + + +Kempf Informational [Page 9] + +RFC 4831 NETLMM Goals April 2007 + + +3.9. Goal 9: Reuse of Existing Protocols Where Sensible + + 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 reuse existing protocols where it makes + architectural and engineering sense to do so. However, the design + should not attempt to reuse 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. Reuse 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 reuse an existing global mobility + management protocol should carefully consider whether reusing such a + protocol really meets the needs of the functional architecture for + network-based localized mobility management. The case for reuse is + not so clear in this case, since there is no compelling backward + compatibility argument. + +3.10. Goal 10: Localized Mobility Management Independent of Global + Mobility Management + + 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 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. + + + + + + + + +Kempf Informational [Page 10] + +RFC 4831 NETLMM Goals April 2007 + + +3.11. Goal 11: Configurable Data Plane Forwarding between Local + Mobility Anchor and Mobile Access Gateway + + 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 Encapsulating Security Payload (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 timescale 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. 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. + +5. Acknowledgements + + The authors would like to acknowledge the following people for + particularly diligent reviewing: Vijay Devarapalli, Peter McCann, + Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred Templin. + + + + + + + + + +Kempf Informational [Page 11] + +RFC 4831 NETLMM Goals April 2007 + + +6. Normative References + + [1] Kempf, J., Ed., "Problem Statement for Network-Based Localized + Mobility Management (NETLMM)", RFC 4830, April 2007. + + [2] Vogt, C., and Kempf, J., "Security Threats to Network-Based + Localized Mobility Management (NETLMM)", RFC 4832, April 2007. + +7. Informative References + + [3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure + Neighbor Discovery (SEND)", RFC 3971, March 2005. + + [4] Carpenter, B., "Architectural Principles of the Internet", RFC + 1958, June 1996. + + [5] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment + in IPv6", RFC 4135, August 2005. + + [6] Eronen, P., "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 J. Arkko, "Mobility Support in + IPv6", RFC 3775, June 2004. + + [10] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC + 3753, June 2004. + + [11] Moskowitz, R. and P. Nikander, "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 L. Bellier, + "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC + 4140, August 2005. + + [14] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 + (MLDv2) for IPv6", RFC 3810, June 2004. + + + + + +Kempf Informational [Page 12] + +RFC 4831 NETLMM Goals April 2007 + + +8. Contributors + + 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 + 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 + +Editor's Address + + 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 + + + +Kempf Informational [Page 13] + +RFC 4831 NETLMM Goals April 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Kempf Informational [Page 14] + |