From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5164.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc5164.txt (limited to 'doc/rfc/rfc5164.txt') diff --git a/doc/rfc/rfc5164.txt b/doc/rfc/rfc5164.txt new file mode 100644 index 0000000..38cca72 --- /dev/null +++ b/doc/rfc/rfc5164.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group T. Melia, Ed. +Request for Comments: 5164 Cisco Systems +Category: Informational March 2008 + + + Mobility Services Transport: Problem Statement + +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. + +Abstract + + There are ongoing activities in the networking community to develop + solutions that aid in IP handover mechanisms between heterogeneous + wired and wireless access systems including, but not limited to, IEEE + 802.21. Intelligent access selection, taking into account link-layer + attributes, requires the delivery of a variety of different + information types to the terminal from different sources within the + network and vice-versa. The protocol requirements for this + signalling have both transport and security issues that must be + considered. The signalling must not be constrained to specific link + types, so there is at least a common component to the signalling + problem, which is within the scope of the IETF. This document + presents a problem statement for this core problem. + + + + + + + + + + + + + + + + + + + + + + + + +Melia, et al. Informational [Page 1] + +RFC 5164 Mobility Services Transport March 2008 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 2.1. Requirements Language ......................................3 + 3. Definition of Mobility Services .................................4 + 4. Deployment Scenarios for MoS ....................................4 + 4.1. End-to-End Signalling and Transport over IP ................5 + 4.2. End-to-End Signalling and Partial Transport over IP ........5 + 4.3. End-to-End Network-to-Network Signalling ...................6 + 5. MoS Transport Protocol Splitting ................................7 + 5.1. Payload Formats and Extensibility Considerations ...........8 + 5.2. Requirements on the Mobility Service Transport Layer .......8 + 6. Security Considerations ........................................11 + 7. Conclusions ....................................................12 + 8. Acknowledgements ...............................................13 + 9. References .....................................................13 + 9.1. Normative References ......................................13 + 9.2. Informative References ....................................13 + Contributors ......................................................14 + +1. Introduction + + This document provides a problem statement for the exchange of + information to support handover in heterogeneous link environments + [1]. This mobility support service allows more sophisticated + handover operations by making available information about network + characteristics, neighboring networks and associated characteristics, + indications that a handover should take place, and suggestions for + suitable target networks to which to handover. The mobility support + services are complementary to IP mobility mechanisms [4], [5], [6], + [7], [8], [9] to enhance the overall performance and usability + perception. + + There are two key attributes to the handover support service problem + for inter-technology handovers: + + 1. The Information: the information elements being exchanged. The + messages could be of a different nature, such as information, + commands to perform an action, or events informing of a change, + potentially being defined following a common structure. + + + + + + + + + + +Melia, et al. Informational [Page 2] + +RFC 5164 Mobility Services Transport March 2008 + + + 2. The Underlying Transport: the transport mechanism to support + exchange of the information elements mentioned above. This + transport mechanism includes information transport, discovery of + peers, and the securing of this information over the network. + + The initial requirement for this protocol comes from the need to + provide a transport for the Media Independent Handover (MIH) protocol + being defined by IEEE 802.21 [1], which is not bound to any specific + link layer and can operate over more that one network-layer hop. The + solution should be flexible to accommodate evolution in the MIH + standard, and should also be applicable for other new mobility + signalling protocols that have similar message patterns and discovery + and transport requirements. + + The structure of this document is as follows. Section 3 defines + Mobility Services. Section 4 provides a simple model for the + protocol entities involved in the signalling and their possible + relationships. Section 5 describes a decomposition of the signalling + problem into service-specific parts and a generic transport part. + Section 5.2 describes more detailed requirements for the transport + component. Section 6 provides security considerations. Section 7 + summarizes the conclusions and open issues. + +2. Terminology + + The following abbreviations are used in the document: + + MIH: Media Independent Handover + + MN: Mobile Node + + NN: Network Node, intended to represent some device in the network + (the location of the node, e.g., in the access network, the home + network is not specified, and for the moment it is assumed that + they can reside anywhere). + + EP: Endpoint, intended to represent the terminating endpoints of + the transport protocol used to support the signalling exchanges + between nodes. + +2.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [2]. + + + + + + +Melia, et al. Informational [Page 3] + +RFC 5164 Mobility Services Transport March 2008 + + +3. Definition of Mobility Services + + As mentioned in the Introduction, mobility (handover) support in + heterogeneous wireless environments requires functional components + located either in the mobile terminal or in the network to exchange + information and eventually to make decisions upon this information + exchange. For instance, traditional host-based handover solutions + could be complemented with more sophisticated network-centric + solutions. Also, neighborhood discovery, potentially a complex + operation in heterogeneous wireless scenarios, can result in a + simpler step if implemented with a unified interface towards the + access network. + + In this document, the different supporting functions for Media + Independent Handover (MIH) management are generally referred to as + Mobility Services (MoS) that have different requirements for the + transport protocol. These requirements and associated + functionalities are the focus of this document. Speaking 802.21 + terminology, MoS can be regarded as Information Services (IS), Event + Services (ES), and Command Service (CS). + +4. Deployment Scenarios for MoS + + The deployment scenarios are outlined in the following sections. + + Note: while MN-to-MN signalling exchanges are theoretically + possible, these are not currently being considered. + + The following scenarios are discussed for understanding the overall + problem of transporting MIH protocol. Although these are all + possible scenarios and MIH services can be delivered through + link-layer specific solutions and/or through a "layer 3 or above" + protocol, this problem statement focuses on the delivery of + information for Mobility Services only for the latter case. + + + + + + + + + + + + + + + + + +Melia, et al. Informational [Page 4] + +RFC 5164 Mobility Services Transport March 2008 + + +4.1. End-to-End Signalling and Transport over IP + + In this case, the end-to-end signalling used to exchange the handover + information elements (the Information Exchange) runs end-to-end + between MN and NN. The underlying transport is also end-to-end. + + +------+ +------+ + | MN | | NN | + | (EP) | | (EP) | + +------+ +------+ + Information Exchange + <------------------------------------> + + /------------------------------------\ + < Transport over IP > + \------------------------------------/ + + Figure 1: End-to-End Signalling and Transport + +4.2. End-to-End Signalling and Partial Transport over IP + + As before, the Information Exchange runs end-to-end between the MN + and the second NN. However, in this scenario, some transport means + other than IP are used from the MN to the first NN, and the transport + over IP is used only between NNs. This is analogous to the use of + EAP end-to-end between Supplicant and Authentication Server, with an + upper-layer multihop protocol, such as Remote Authentication Dial-In + User Service (RADIUS), used as a backhaul transport protocol between + an Access Point and the Authentication Server. + + +------+ +------+ +------+ + | MN | | NN | | NN | + | | | (EP) | | (EP) | + +------+ +------+ +------+ + Information Exchange + <------------------------------------> + + (Transport over /------------------\ + <--------------->< Transport over IP > + e.g. L2) \------------------/ + + Figure 2: Partial Transport + + + + + + + + + +Melia, et al. Informational [Page 5] + +RFC 5164 Mobility Services Transport March 2008 + + +4.3. End-to-End Network-to-Network Signalling + + In this case, NN to NN signalling is envisioned. Such a model should + allow different network components to gather information from each + other. This is useful for instance in conditions where network + components need to make decisions and instruct mobile terminals of + operations to be executed. + + +------+ +------+ + | NN | | NN | + | (EP) | | (EP) | + +------+ +------+ + Information Exchange + -------------------> + <------------------- + + /----------------\ + < Transport > + \----------------/ + + Figure 3: Information Exchange between Different NNs + + Network nodes exchange information about the status of connected + terminals. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Melia, et al. Informational [Page 6] + +RFC 5164 Mobility Services Transport March 2008 + + +5. MoS Transport Protocol Splitting + + Figure 4 shows a model where the Information Exchanges are + implemented by a signalling protocol specific to a particular + mobility service, and these are relayed over a generic transport + layer (the Mobility Service Transport Layer). + + +----------------+ ^ + |Mobility Support| | + | Service 2 | | + +----------------+ | | | Mobility Service + |Mobility Support| +----------------+ | Signaling + | Service 1 | +----------------+ | Layer + | | |Mobility Support| | + +----------------+ | Service 3 | | + | | | + +----------------+ V + ================================================ + +---------------------------------------+ ^ Mobility Service + | Mobility Service Transport Protocol | | Transport + +---------------------------------------+ V Layer + ================================================ + +---------------------------------------+ + | IP | + +---------------------------------------+ + + Figure 4: Handover Services over IP + + The Mobility Service Transport Layer provides certain functionality + (outlined in Section 5.2) to the higher-layer mobility support + services in order to support the exchange of information between + communicating Mobility Service functions. The transport layer + effectively provides a container capability to mobility support + services, as well as any required transport and security operations + required to provide communication, without regard to the protocol + semantics and data carried in the specific Mobility Services. + + The Mobility Support Services themselves may also define certain + protocol exchanges to support the exchange of service-specific + information elements. It is likely that the responsibility for + defining the contents and significance of the information elements is + the responsibility of standards bodies other than the IETF. Example + Mobility Services include the Information Services, Event Services, + and Command Services. + + + + + + + +Melia, et al. Informational [Page 7] + +RFC 5164 Mobility Services Transport March 2008 + + +5.1. Payload Formats and Extensibility Considerations + + The format of the Mobility Service Transport Protocol (MSTP) is as + follows: + + +----------------+----------------------------------------+ + |Mobility Service| Opaque Payload | + |Transport Header| (Mobility Support Service) | + +----------------+----------------------------------------+ + + Figure 5: Protocol Structure + + This figure shows the case for an MIH message that is smaller than + the MTU of the path to the destination. A larger payload may require + the transport protocol to transparently fragment and reassemble the + MIH message. + + The opaque payload encompasses the Mobility Support Service (MSTP) + information that is to be transported. The definition of the + Mobility Service Transport Header is something that is best addressed + within the IETF. MSTP does not inspect the payload, and any required + information will be provided by the MSTP users. + +5.2. Requirements on the Mobility Service Transport Layer + + The following section outlines some of the general transport + requirements that should be supported by the Mobility Service + Transport Protocol. Analysis has suggested that at least the + following need to be taken into account: + + Discovery: MNs need the ability to either discover nodes that + support certain services or discover services provided by a + certain node. The service discovery can be dealt with using + messages as defined in [1]. This section refers to node-discovery + in either scenario. There are no assumptions about the location + of these Mobility Service nodes within the network. Therefore, + the discovery mechanism needs to operate across administrative + boundaries. Issues such as speed of discovery, protection against + spoofing, when discovery needs to take place, and the length of + time over which the discovery information may remain valid; all + need to be considered. Approaches include: + + * Hard coding information into the MN, indicating either the IP + address of the NN, or information about the NN that can be + resolved onto an IP address. The configuration information + could be managed dynamically, but assumes that the NN is + independent of the access network to which the MN is currently + attached. + + + +Melia, et al. Informational [Page 8] + +RFC 5164 Mobility Services Transport March 2008 + + + * Pushing information to the MN, where the information is + delivered to the MN as part of other configuration operations, + for example, via DHCP or Router Discovery exchange. The + benefit of this approach is that no additional exchanges with + the network would be required, but the limitations associated + with modifying these protocols may limit applicability of the + solution. + + * MN dynamically requesting information about a node, which may + require both MN and NN support for a particular service + discovery mechanism. This may require additional support by + the access network (e.g., multicast or anycast) even when it + may not be supporting the service directly itself. + + Numerous directory and configuration services already exist, and + reuse of these mechanisms may be appropriate. There is an open + question about whether multiple methods of discovery would be + needed, and whether NNs would also need to discover other NNs. + The definition of a service also needs to be determined, including + the granularity of the description. For example, IEEE 802.21 + specifies three different types of Mobility Services (Information + Services, Command Services, and Event Services) that can be + located in different portions of the network. An MN could + therefore run a discovery procedure of any service running in the + (home or visited) network or could run a discovery procedure for a + specific service. + + Information from a trusted source: The MN uses the Mobility Service + information to make decisions about what steps to take next. It + is essential that there is some way to ensure that the information + received is from a trustworthy source. This requirement should + reuse trust relationships that have already been established in + the network, for example, on the relationships established by the + Authentication, Authorization, and Accounting (AAA) infrastructure + after a mutual authentication, or on the certificate + infrastructure required to support SEND [10]. Section 6 provides + a more complete analysis. + + Security association management: A common security association + negotiation method, independent of any specific MSTP user, should + be implemented between the endpoints of the MSTP. The solution + must also work in the case of MN mobility. + + Secure delivery: The Mobility Service information must be delivered + securely (integrity and confidentiality) between trusted peers, + where the transport may pass though untrusted intermediate nodes + and networks. The Mobility Service information should also be + protected against replay attacks and denial-of-service attacks. + + + +Melia, et al. Informational [Page 9] + +RFC 5164 Mobility Services Transport March 2008 + + + Low latency: Some of the Mobility Services generate time-sensitive + information. Therefore, there is a need to deliver the + information over quite short timescales, and the required lifetime + of a connection might be quite short-lived. As an example, the + frequency of messages defined in [1] varies according to the MIH + service type. It is expected that Events and Commands messages + arrive at an interval of hundreds of milliseconds in order to + capture quick changes in the environment and/or process handover + commands. On the other hand, Information Service messages are + mainly exchanged each time a new network is visited that may be in + the order of hours or days. For reliable delivery, short-lived + connections could be set up as needed, although there is a + connection setup latency associated with this approach. + Alternatively, a long-lived connection could be used, but this + requires advanced warning of being needed and some way to maintain + the state associated with the connection. It also assumes that + the relationships between devices supporting the mobility service + are fairly stable. Another alternative is connectionless + operation, but this has interactions with other requirements, such + as reliable delivery. + + Reliability: Reliable delivery for some of the Mobility Services may + be essential, but it is difficult to trade this off against the + low latency requirement. It is also quite difficult to design a + robust, high-performance mechanism that can operate in + heterogeneous environments, especially one where the link + characteristics can vary quite dramatically. There are two main + approaches that could be adopted: + + 1. Assume the transport cannot be guaranteed to support reliable + delivery. In this case, the Mobility Support Service itself + will have to provide a reliability mechanism (at the MIH level) + to allow communicating endpoints to acknowledge receipt of + information. + + 2. Assume the underlying transport will provide reliable delivery. + There is no need in this case to provide reliability at the MIH + level. + + Guidelines provided in [3] are being considered while writing this + document. + + Congestion Control: A Mobility Service may wish to transfer small or + large amounts of data, placing different requirements for + congestion control in the transport. As an example, the MIH + message [1] size varies widely from about 30 bytes (for a + broadcast capability discovery request) to be normally less than + 64 KB, but may be greater than 64KB (for an IS MIH_Get_Information + + + +Melia, et al. Informational [Page 10] + +RFC 5164 Mobility Services Transport March 2008 + + + response primitive). A typical MIH message size for the Events + and Commands Services service ranges between 50 to 100 bytes. The + solution should consider different congestion control mechanisms + depending on the amount of data generated by the application (MIH) + as suggested in [3]. + + Fragmentation and reassembly: ES and CS messages are small in + nature, are sent frequently, and may wish trade reliability in + order to satisfy the tight latency requirements. On the other + hand, IS messages are more resilient in terms of latency + constraints, and some long IS messages could exceed the MTU of the + path to the destination. Depending on the choice of the transport + protocol, different fragmentation and reassembly strategies are + required. + + Multihoming: For some Information Services exchanged with the MN, + there is a possibility that the request and response messages + could be carried over two different links. For example, a + handover command request is on the current link while the response + could be delivered on the new link. It is expected that the + transport protocol is capable of receiving information via + multiple links. It is also expected that the MSTP user combines + information belonging to the same session/transaction. When + mobility is applied, the underlying IP mobility mechanism should + provide session continuity when required. + + IPv4 and IPv6 support: The MSTP must support both IPv4 and IPv6 + including NAT traversal for IPv4 networks and firewall + pass-through for IPv4 and IPv6 networks. + +6. Security Considerations + + Network-supported Mobility Services aim at improving decision making + and management of dynamically connected hosts. + + Information Services may not require authorization of the client, but + both Event and Command Services may authenticate message sources, + particularly if they are mobile. Network-side service entities will + typically need to provide proof of authority to serve visiting + devices. Where signalling or radio operations can result from + received messages, significant disruption may result from processing + bogus or modified messages. The effect of processing bogus messages + depends largely upon the content of the message payload, which is + handled by the handover services application. Regardless of the + variation in effect, message delivery mechanisms need to provide + protection against tampering, spoofing, and replay attacks. + + + + + +Melia, et al. Informational [Page 11] + +RFC 5164 Mobility Services Transport March 2008 + + + Sensitive and identifying information about a mobile device may be + exchanged during handover-service message exchange. Since handover + decisions are to be made based upon message exchanges, it may be + possible to trace a user's movement between cells, or predict future + movements, by inspecting handover service messages. In order to + prevent such tracking, message confidentiality and message integrity + should be available. This is particularly important because many + mobile devices are associated with only one user, since divulging of + such information may violate the user's privacy. Additionally, + identifying information may be exchanged during security association + construction. As this information may be used to trace users across + cell boundaries, identity protection should be available, if + possible, when establishing source addresses (SAs). + + In addition, the user should not have to disclose its identity to the + network (anymore than it needed to during authentication) in order to + access the Mobility Support Services. For example, if the local + network is just aware that an anonymous user with a subscription to + "example.com" is accessing the network, the user should not have to + divulge their true identity in order to access the Mobility Support + Services available locally. + + Finally, the NNs themselves will potentially be subject to + denial-of-service attacks from MNs, and these problems will be + exacerbated if operation of the Mobility Service protocols imposes a + heavy computational load on the NNs. The overall design has to + consider at what stage (e.g., discovery, transport layer + establishment, and service-specific protocol exchange) denial-of- + service prevention or mitigation should be built in. + +7. Conclusions + + This document outlined a broad problem statement for the signalling + of information elements across a network to support Mobility + Services. In order to enable this type of signalling service, a need + for a generic transport solution with certain transport and security + properties was outlined. Whilst the motivation for considering this + problem has come from work within IEEE 802.21, a desirable goal is to + ensure that solutions to this problem are applicable to a wider range + of Mobility Services. + + It would be valuable to establish realistic performance goals for the + solution to this common problem (i.e., transport and security + aspects) using experience from previous IETF work in this area and + knowledge about feasible deployment scenarios. This information + could then be used as an input to other standards bodies in assisting + them to design Mobility Services with feasible performance + requirements. + + + +Melia, et al. Informational [Page 12] + +RFC 5164 Mobility Services Transport March 2008 + + + Much of the functionality required for this problem is available from + existing IETF protocols or combination thereof. This document takes + no position on whether an existing protocol can be adapted for the + solution or whether new protocol development is required. In either + case, we believe that the appropriate skills for development of + protocols in this area lie in the IETF. + +8. Acknowledgements + + Thanks to Subir Das, Juan Carlos Zuniga, Robert Hancock, and + Yoshihiro Ohba for their input. Thanks to the IEEE 802.21 chair, + Vivek Gupta, for coordinating the work and supporting the IETF + liaison. Thanks to all IEEE 802.21 WG folks who contributed to this + document indirectly. + +9. References + +9.1. Normative References + + [1] "Draft IEEE Standard for Local and Metropolitan Area Networks: + Media Independent Handover Services", IEEE LAN/MAN Draft IEEE + P802.21/D07.00, July 2007. + + [2] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +9.2. Informative References + + [3] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for + Application Designers", Work in Progress. + + [4] 3GPP, "3GPP system architecture evolution (SAE): Report on + technical options and conclusions", 3GPP TR 23.882 0.10.1, + February 2006. + + [5] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, + August 2002. + + [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in + IPv6", RFC 3775, June 2004. + + [7] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) + Architecture", RFC 4423, May 2006. + + [8] Eronen, P., "IKEv2 Mobility and Multihoming Protocol + (MOBIKE)", RFC 4555, June 2006. + + + + + +Melia, et al. Informational [Page 13] + +RFC 5164 Mobility Services Transport March 2008 + + + [9] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, + July 2005. + + [10] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure + Neighbor Discovery (SEND)", RFC 3971, March 2005. + +Contributors' Addresses + + Eleanor Hepworth + Siemens Roke Manor Research + Roke Manor + Romsey, SO51 5RE + UK + + EMail: eleanor.hepworth@roke.co.uk + + + Srivinas Sreemanthula + Nokia Research Center + 6000 Connection Dr. + Irving, TX 75028 + USA + + EMail: srinivas.sreemanthula@nokia.com + + + Yoshihiro Ohba + Toshiba America Research, Inc. + 1 Telcordia Drive + Piscateway NJ 08854 + USA + + EMail: yohba@tari.toshiba.com + + + Vivek Gupta + Intel Corporation + 2111 NE 25th Avenue + Hillsboro, OR 97124 + USA + + Phone: +1 503 712 1754 + EMail: vivek.g.gupta@intel.com + + + + + + + + +Melia, et al. Informational [Page 14] + +RFC 5164 Mobility Services Transport March 2008 + + + Jouni Korhonen + TeliaSonera Corporation. + P.O.Box 970 + FIN-00051 Sonera + FINLAND + + Phone: +358 40 534 4455 + EMail: jouni.korhonen@teliasonera.com + + + Rui L.A. Aguiar + Instituto de Telecomunicacoes Universidade de Aveiro + Aveiro 3810 + Portugal + + Phone: +351 234 377900 + EMail: ruilaa@det.ua.pt + + + Sam(Zhongqi) Xia + Huawei Technologies Co., Ltd + HuaWei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base + 100085 + Hai-Dian District Beijing, P.R. China + + Phone: +86-10-82836136 + EMail: xiazhongqi@huawei.com + +Authors' Addresses + + Telemaco Melia, Editor + Cisco Systems International Sarl + Avenue des Uttins 5 + 1180 Rolle + Switzerland (FR) + + Phone: +41 21 822718 + EMail: tmelia@cisco.com + + + + + + + + + + + + + +Melia, et al. Informational [Page 15] + +RFC 5164 Mobility Services Transport March 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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. + + + + + + + + + + + + +Melia, et al. Informational [Page 16] + -- cgit v1.2.3