NETLMM Working Group G. Velev Internet-Draft K. Weniger Intended status: Informational Panasonic Expires: May 15, 2008 November 12, 2007 Interactions between PMIPv6 and MIPv6: Route Optimization Issues draft-velev-netlmm-mip-pmip-ro-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The interactions scenarios between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) protocols are described in [ID-MIP-PMIP]. This document analyzes these scenarios when route optimization is used. The analysis results in the identification of possible issues that should be considered in the design of extensions for Route Optimization in PMIPv6. Velev & Weniger Expires May 15, 2008 [Page 1] Internet-Draft PMIPv6-MIPv6 RO Issues November 2007 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 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of route optimization . . . . . . . . . . . . . . . . 3 3.1. Route optimization in MIPv6 . . . . . . . . . . . . . . . 3 3.2. Route optimization in PMIPv6 . . . . . . . . . . . . . . . 4 4. Analysis of the scenarios and possible issues . . . . . . . . 5 4.1. Proxy RO in scenario A . . . . . . . . . . . . . . . . . . 5 4.2. Proxy RO in scenario B . . . . . . . . . . . . . . . . . . 7 4.3. Proxy RO in scenario C . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Velev & Weniger Expires May 15, 2008 [Page 2] Internet-Draft PMIPv6-MIPv6 RO Issues November 2007 1. Introduction The NETLMM WG is standardizing Proxy Mobile IPv6 (PMIPv6) as the protocol for network-based localized mobility management. The MIPv6- PMIPv6 interactions document [ID-MIP-PMIP] captures the issues with the inter-working between host-based (MIPv6) and network-based (PMIPv6) mobility and identifies three main scenarios. However, the document does not consider the cases when a route optimized path is set up. In PMIPv6 the mobile access gateway (MAG) manages the mobility- related registrations with the local mobility agent (LMA) on behalf of the mobile nodes (MNs) attached to it. According to the base PMIPv6 specification [ID-PMIPv6] all data packets are bi- directionally tunneled between MAG and LMA. In some scenarios, e.g. if the communicating end nodes are located in the same PMIPv6 domain, it is advantageous to route the packets directly between the MAGs to which the nodes are attached. The PMIPv6 base spec does not support route optimization (RO) between different MAGs, but there are individual proposals (see Section 3.2) for establishing such a route optimized path. In these proposals, as required by PMIPv6, the MNs are unaware about the proxy RO set up in PMIPv6 domain between the MAGs. On the other hand, in MIPv6 the MN itself performs the route optimization with a CN. This document provides an analysis of the scenarios and possible issues when the PMIPv6 and MIPv6 route optimization procedures interact. 2. Terminology General mobility terminology can be found in [RFC3753]. Further, PMIPv6-related terminology used in this document is defined in [ID-PMIPv6] 3. Overview of route optimization This section provides an overview of the route optimization procedures specified for MIPv6 and the general characteristics of a potential to-be-standardized route optimization procedure for PMIPv6. 3.1. Route optimization in MIPv6 MIPv6 protocol comes with a route optimization scheme that enables a direct communication between MN and CN, i.e. the data packets are bypassing the Home Agent. Route optimization requires the mobile Velev & Weniger Expires May 15, 2008 [Page 3] Internet-Draft PMIPv6-MIPv6 RO Issues November 2007 node to register its current binding of home address (HoA) to care- of-address (CoA) at the correspondent node. The CN establishes a binding cache entry and packets from the CN can be routed directly to the CoA of the MN. MPv6 specification [RFC3775] defines the return routability (RR) procedure that authorizes the BU sent by the MN by the use of a cryptographic token exchange (keygen tokens). The binding update is signed by binding management key (Kbm) that is generated based on the keygen tokens obtained from CN separately for the home address and care-of-address. The detailed RR and RO procedures are described in sections 5.2, 6.1, 9.4 and 9.5 in [RFC3775]. 3.2. Route optimization in PMIPv6 Route optimization in PMIPv6 (proxy RO) is not in the charter of the NetLMM working group and is not specified in the PMIPv6 base specification [ID-PMIPv6]. However, [ID-PMIPv6] describes one case where the local routing at the MAG is possible. The local routing is applied when the two communicating mobile nodes are attached to the same MAG and the MAG's policy in coordination with LMA allows such routing. In all other attachment constellations the PMIPv6 protocol mandates reverse tunneling of data packets to the LMA. However, interest in the area of PMIPv6 RO (henceforth called proxy RO) exists from various working group members and individual solutions are already available. In the following, the general characteristics of possible PMIPv6 RO mechanisms are analyzed. Subsequently, some individual submissions are briefly presented as example solutions. In general, the proxy RO can be categorized in the following cases: 1. Between the MN and the CN's MAG. In this case the RO is initiated by the MN and the MAG is the endpoint of the route optimized path. For instance, if MIPv6 RO is used, the MAG performs the role of MIPv6 CN with respect to RO. 2. Between the MN's MAG and the CN. In this case the MN's MAG initiates the RO with CN on behalf of the MN and the endpoint of the route optimized path is MN's MAG instead of MN. For instance, if MIPv6 RO is used the MAG performs the role of MIPv6 MN with respect to RO. 3. Between MAGs. In this case the MAG, to which the MN is attached, initiates RO with the CN's MAG and a route optimized path between both MAGs is established. For instance, if MIPv6 RO is used, the MN's MAG performs the role of MIPv6 MN with respect to RO and the Velev & Weniger Expires May 15, 2008 [Page 4] Internet-Draft PMIPv6-MIPv6 RO Issues November 2007 MAG, to which the CN is attached, performs the role of MIPv6 CN. Each of the above cases is analyzed in different MIPv6-PMIPv6 interaction scenarios in Section 4. The document [PMIPv6-RO-RR] describes the applicability of Enhanced Route Optimization for Mobile IPv6 specified in [RFC4866] for PMIPv6. The authors describe the applicability of a proxy Return Routability (RR) procedure performed by the MAG on behalf of the MN. The document addresses cases 2 and 3 from above. Another individual approach of RO in PMIPv6 is described in [PMIPv6-RO-ROA]. This approach assumes that a (pre-established) route optimization association (ROA) between the MAGs is set up and they can exchange RO setup messages (similar to binding updates messages) via LMA or directly among each other. The document addresses the case 3 (i.e. MAG-MAG RO) from above. This solution is applicable for proxy RO within one PMIPv6 domain because ROA between the MAGs must be pre-established. A further individual solution is described in [PMIPv6-RO-IPv4] that presents a more general approach and considers a combination of both individual solutions presented above: either performing a proxy RR between MAGs or having a Security Association between MAGs for direct exchange of binding updates. In general, if a mobile node attached to a MAG in PMIPv6 domain moves to a new MAG, the old MAG, the new MAG and the LMA should manage the transition of the RO-related state from the old to the new MAG. Further the new MAG shall update the BCE in the correspondent node. These procedures are outside of the scope of this document because it is not specific to MIPv6-PMIPv6 interactions and should be defined in a potential to-be-standardized PMIPv6 RO procedure. 4. Analysis of the scenarios and possible issues The categorization of the MIPv6-PMIPv6 interactions with respect to RO is based on scenarios A, B and C described in [ID-MIP-PMIP] in order to achieve compliance between both documents. For each of the scenarios the cases from Section 3.2 are applied and the resulting issues are identified. 4.1. Proxy RO in scenario A In scenario A, PMIPv6 is used as a network-based local mobility management protocol whereas MIPv6 is used as a global mobility management protocol. In other words, MIPv6 manages the mobility Velev & Weniger Expires May 15, 2008 [Page 5] Internet-Draft PMIPv6-MIPv6 RO Issues November 2007 among different access networks, while the mobility within the access network is handled by PMIPv6. Furthermore, HA and LMA are not co- located. In this scenario the MN uses MIPv6 and registers the IP address obtained in the PMIPv6 domain as CoA at the HA. A bi-directional tunnel is set up between the MN and HA. An additional PMIPv6 tunnel is in use between MAG1 and LMA1. Figure 1 illustrates the hierarchical application of MIPv6 and PMIPv6 protocols in scenario A. The CN relies on the PMIPv6 for mobility management, it is attached to MAG2 and anchored at LMA1, where the MN is anchored too. +----+ | HA | +----+ //\ // \ +------------//----\-------------+ ( // \ ) Global Mobile IPv6 ( // \ ) Domain +---------//----------\----------+ // \ +------+ +----+ | LMA1 | |LMA2| +------+ +----+ ////\\ \\ +----////--\\----+ +----\\------+ ( //// \\ ) ( \\ ) Local Mobility Network ( //// \\ ) ( \\ ) PMIPv6 domain +-////--------\\-+ +-------\\---+ //// \\ \\ //// \\ \\ //// \\ \\ +----+ +----+ +----+ |MAG1| |MAG2| |MAG3| +----+ +----+ +----+ || | | [MN] [CN] Figure 1 - Scenario A As MIPv6 bidirectional tunnel is set up between MN and HA, the PMIP entities (MAG1 and LMA1) cannot take any actions with respect to proxy RO because they do not know the address of the CN. Even if the CN is attached to the same or neighbour MAG, to which MN is attached, PMIP entities are unable to discover such a situation. Therefore, proxy RO initiated by MN's MAG to the CN, i.e. case 2 from Velev & Weniger Expires May 15, 2008 [Page 6] Internet-Draft PMIPv6-MIPv6 RO Issues November 2007 Section 3.2, is not possible. The MAG would rather see the HA as CN and establish an optimized route to the HA, which is of course not desired. Proxy RO between MAG1 and MAG2 (case 3) has the same problem as case 2: since a MIPv6 tunnel is set up between MN and HA, MAG1 cannot discover CN's address and initiate proxy RO. In contrary to cases 2 and 3, proxy RO between MN and MAG2 (case 1) is possible. MN initiates a MIPv6 RO with the CN and the MAG2 is configured to act as proxy CN on behalf CN. The resulting path in both directions (i.e. MN->CN and CN->MN) would be MN-MAG1-LMA1-MAG2-CN. Such a situation is comparable to usual PMIPv6 routing, although MIPv6 RO IP header options are present in the data packets (Routing Header Type 2 and Home Address destination option). This situation gives opportunity for MAG1 to start proxy RO with CN, or for a proxy RO between MAG1 and MAG2. A potential to-be- standardized PMIPv6 RO procedure shall consider the handling of such a situation, where already MIPv6 RO is running between MN and CN (or CN's MAG, i.e. MAG2). In summary, proxy PMIPv6 RO from MAG1 to CN or from MAG1 to MAG2 in scenario A cannot be initiated unless MN performs MIPv6 RO with CN. In the following a situation is analyzed, in which the MAG2 initiates proxy RO with the MN. After such a route optimized path is set up, the data packets would continue to flow via the HA, i.e. the path would the same as before the proxy RO. Therefore it is advantageous if MAG2 does not initiate proxy RO with MN. 4.2. Proxy RO in scenario B In scenario B some MNs use MIPv6 to manage their movements while others rely on a PMIPv6 protocol provided by the network. The configuration of the MAG for support such scenario is described in [ID-MIP-PMIP] Section 6.14. The mobility anchor for MIPv6 and PMIPv6 is the same entity implementing the functions of both HA and LMA (below denoted as HA/LMA). For a MN, to which PMIPv6 service is offered, the HA/LMA is acting as LMA and for a MN, to which MIPv6 service is offered, the HA/LMA is acting as HA. Figure 2 illustrates scenario B where a MN uses MIPv6 and a CN relies on PMIPv6 for mobility management. The MN utilizes MIPv6 tunnel to the HA/LMA via AR whereas a PMIPv6 tunnel is set up for CN between MAG2 and HA/LMA. Velev & Weniger Expires May 15, 2008 [Page 7] Internet-Draft PMIPv6-MIPv6 RO Issues November 2007 +------+ |HA/LMA| +------+ //\\ +- ---//--\\----+ ( // \\ ) Mixed MIPv6 and ( // \\ ) PMIPv6 mobility domain +--//--------\\-+ // \\ // \\ // \\ +----+ +----+ | AR | |MAG2| +----+ +----+ || | [MN] [CN] Figure 2 - Scenario B In scenario B proxy RO (from MN-side) is possible only between MN and MAG2. The proxy RO cases 2 and 3 from Section 3.2 are not possible because MN is attached to an AR. If the MN initiates a MIPv6 RO with CN, MAG2 may respond as proxy on behalf of the CN, which results in case 1. The RO path is set up between MN and MAG2, which is the optimal route from MN to CN. Additionally, MAG2 may initiate proxy RO with the MN in order to achieve route optimized path in direction from CN to MN. If the RO is performed in both directions, no further optimizations are needed. On the other hand, proxy RO can be initiated from CN side. With regard to Figure 2 this is the case if MAG2 initiates proxy RO with MN. The resulting route optimized path would be via the MN's HA/LMA, because MAG2 does not know MN's CoA. Thus, the proxy RO in such a case does not lead to any path optimization. Therefore it is beneficial if MAG1 does not initiate proxy RO with MN. In summary, to achieve the optimal RO path in scenario B between MN using MIPv6 and CN relying on PMIPv6 service in the same network domain, first the MN should initiate MIPv6 RO. The network can assist the MN to initiate MIPv6 RO, as the network entities (most probably LMA) can discover this constellation. 4.3. Proxy RO in scenario C In scenario C a MIPv6-capable MN moves between access networks using different mobility management schemes, i.e. some access networks support PMIPv6 and others do not. This results in transition between Velev & Weniger Expires May 15, 2008 [Page 8] Internet-Draft PMIPv6-MIPv6 RO Issues November 2007 PMIPv6 and MIPv6 mobility management for the particular MN and requires that LMA and HA functions are located in the same physical entity. Scenario C is depicted in Figure 4. +------+ |HA/LMA|-----------------------+ +------+ | //\\ | +-------//--\\--------+ | ( // \\ PMIPv6 ) | ( // \\ domain) +--------------+ +----//--------\\-----+ ( Non-PMIPv6 ) // \\ ( domain ) // \\ +--------------+ // \\ | +----+ +----+ +----+ |MAG1| |MAG2| | AR | +----+ +----+ +----+ | | | [MN1] [MN2] ------> (1) | (2) <------ [MN2] Figure 3 - Scenario C In order to anlyze the issues with RO in scenario C, first it is assumed that MN2 has the role of MN and MN1 has the role of CN. Further two transition scenarios are investigated denoted by the arrows (1) and (2) in Figure 3. In transition (1) the MN2 moves from MAG2 of PMIPv6 domain to an AR of non-PMIPv6 domain, whereas in transition (2) the MN2 moves from AR to MAG2. At first, transition (1) is analyzed. If a MN2 is attached to MAG2 and MN1 is attached to MAG1, a proxy RO path can be set up according to cases 2 (MAG2->MN1) and case 3 (MAG2->MAG1) from Section 3.2. Cases 1 (MN2->MAG1) is not possible because the assumption is that MN2 is at the home link supporting PMIPv6 service, i.e. the MN2 does not have a CoA to register with the CN. In the following analysis, cases 2 and 3 are investigated together because the only difference is which entity (MN1 or MAG1) performs the CN role regarding RO functionality. Therefore, below CN is indicated as MN1/MAG1. If the MN2 moves outside the PMIP domain to an AR of a MIPv6 domain, the MN2 performs MIPv6 registration with the HA/LMA. Since the MN2 is not aware about the proxy RO before the handover, it does not necessary initiate registration of its CoA to MN1/MAG1. It depends on the MN2's MIPv6 implementation whether MIPv6 RO is performed. The steps performed by MAG2, after detection that MN2 is not any longer Velev & Weniger Expires May 15, 2008 [Page 9] Internet-Draft PMIPv6-MIPv6 RO Issues November 2007 attached to it, depend on a potential PMIPv6 RO specification. If MAG2 does not deregister the MN2 with the MN1/MAG1, MN1/MAG1 continues to send packets to MAG2 and this could lead to packet losses. Therefore a potential PMIPv6 RO protocol shall take care of this situation. On the other hand, if a mechanism is available in MAG2 to deregister MN2 with MN1/MAG1, then the proxy RO path is terminated and data packets are routed via HA/LMA. The change of route optimized to non-optimized path would result in increased end- to-end delay and possibly to data packets lost due to transport layer time out. To avoid this situation, a future protocol mechanism may help to keep the RO path between the MN2 and MN1 after the MN2 moves out of the PMIPv6 domain. The transition (2) from Figure 3 is observed hereby, where the MN2 is first attached to a MIPv6 domain and later moves to the home link that supports PMIPv6 service (home PMIPv6 domain). Case 1 (MN2->MAG1) from Section 3.2 is the only possible way of performing proxy RO before the handover. While attached to the MIPv6 domain, a RO path between MN2 and MAG1 is set up, i.e. MN2 creates BCE in MAG1. When the MN2 moves to the home PMIPv6 domain, it performs the returning home procedure described in [RFC3775], i.e. sends deregistration BU messages to HA and all CNs, to which a MIPv6 RO has been set up. Thus, the MN2 deletes the BCE in MAG1 and MAG1 sends data packets to MN2's HoA, i.e. to HA/LMA. Such a scenario does not result in data packet losses, however, the MN-CN path after the handover is not optimized. In conclusion, the MN2's transition between PMIPv6 and MIPv6 mobility schemes results in issues that should be considered by a future protocol mechanisms. The transition from PMIPv6 to non-PMIPv6 domain may result in packet losses or affect the transport layer application due to increased end-to-end delay. The MIPv6 RO procedure [RFC3775] specifies the functionality of a CN, however, it does not consider mobile CN. In the following a mobile CN performing PMIPv6-MIPv6 transition in scenario C is analyzed in order to identify possible issues. In scenarios A and B the mobile CN does not change the mobility management scheme and therefore such an analysis is not needed. With respect to Figure 3, the assumption now is that the MN's role is implemented in MN1 (respectively MAG1) and CN's role - in MN2 (respectively MAG2). In transition (1) the MN2 hands over from MAG2 to the AR. Before the handover MAG2 performed the function of CN with respect to RO. Thus, the MN2 sends data packets to MN1's HoA, but the MAG2 tunnels the packets to MAG1. After the handover, the MN2 performs MIPv6 registration with HA and continues to send the data packets to MN1's HoA. The LMA forwards the data packets to the MAG1 and they are delivered to MN1. So far data packets are delivered to MN1. However MAG1 would continue to Velev & Weniger Expires May 15, 2008 [Page 10] Internet-Draft PMIPv6-MIPv6 RO Issues November 2007 keep the proxy RO path with MAG2, although MN2 is not any longer attached to MAG2. Such a situation should be considered by the potential to-be-standardized proxy RO specification. In transition (2), the MN2 hands over from AR to MAG2. Before the handover MN2 uses MIPv6 and performs the role of CN. The proxy BCE in MN2 is created by MAG1. After the handover to MAG2, the MN2 keeps the proxy BCE, and thus, sends the packets to MN's CoA (e.g. MAG1's IP address). However, the packets are encapsulated by MAG2 in a PMIPv6 tunnel to LMA, an thus, the MN1-MN2 path is not optimized. The result is that RO set up before the handover continues to be still active, and either MAG1 continues to update the MN2's BCE. Such a situation is undesired and shall be handled by a to-be- standardized proxy RO procedure. To sum up the issues with mobile CN in scenario C, transition (1) may lead to a situation in which the entity performing the MN's role (MAG1) continues to perform proxy RO with the MAG2, although MN2 is not any longer attached to MAG2. On the other hand transition (2) results in the non-optimal situation of tunneling data packets between MAG2 and LMA although a BCE exists in MN2 for optimal route to MN1. 5. Security Considerations The current document analyzes scenarios and describes issues; it does not present new protocol design. Therefore this document does not introduce any security issues in addition to those described in [ID-PMIPv6] or [RFC3775]. 6. References 6.1. Normative References [ID-PMIPv6] Gundavelli, S., Ed., "Proxy Mobile IPv6", November 2007, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Velev & Weniger Expires May 15, 2008 [Page 11] Internet-Draft PMIPv6-MIPv6 RO Issues November 2007 Home Agents", RFC 3776, June 2004. [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", May 2007. 6.2. Informative References [ID-MIP-PMIP] Giaretta, G., Ed., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", August 2007, . [PMIPv6-RO-IPv4] Jeong, S. and R. Wakikawa, "Route Optimization for Proxy Mobile IPv6", July 2007, . [PMIPv6-RO-ROA] Abeille, A. and M. Liebsch, "Route Optimization for Proxy Mobile IPv6", May 2007, . [PMIPv6-RO-RR] Qin, A., Ed., "PMIPv6 Route Optimization Protocol", February 2007, . [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. Authors' Addresses Genadi Velev Panasonic Monzastr. 4c Langen 63225 Gemany Phone: Email: genadi.velev@eu.panasonic.com Velev & Weniger Expires May 15, 2008 [Page 12] Internet-Draft PMIPv6-MIPv6 RO Issues November 2007 Kilian Weniger Panasonic Monzastr. 4c Langen 63225 Gemany Phone: Email: kilian.weniger@eu.panasonic.com Velev & Weniger Expires May 15, 2008 [Page 13] Internet-Draft PMIPv6-MIPv6 RO Issues November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Velev & Weniger Expires May 15, 2008 [Page 14]