Network Working Group Subba Reddy. Kota Internet-Draft Wable. Ranjitsinh Expires: August 31, 2006 Samsung ISO JH. Choi Samsung AIT February 27, 2006 FMIPv6 with LinkID draft-subba-mipshop-fmip-linkid-00.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. This Internet-Draft will expire on August 31, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract FMIPv6 aims to achieve seamless handoff but needs (AP-ID, AR-Info) in PARs to function and can't work if PAR doesn't have an entry for the next AP. In this draft, we present a scheme to dynamically build (AP-ID, AR-Info) tuple in PAR and make FMIPv6 perform even when PAR doesn't have a suitable (AP-ID, AR-Info) tuple by putting LinkID prefix in L2 beacon. Kota, et al. Expires August 31, 2006 [Page 1] Internet-Draft FL February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. New Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. NAR Address Discovery Messages . . . . . . . . . . . . . . 7 4.1.1. NAR Address Discovery Request (NADREQ) . . . . . . . . 7 4.1.2. NAR Address Discovery Reply (NADREP) . . . . . . . . . 8 4.2. FMIPv6 messages with new options . . . . . . . . . . . . . 10 4.2.1. Router Solicitation for Proxy Router Advertisement (RtSolPr) . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Handover Acknowledgement (HAck) . . . . . . . . . . . 10 4.2.3. Fast Binding Update (FBU) . . . . . . . . . . . . . . 10 4.2.4. Fast Binding Acknowledgment (FBack) . . . . . . . . . 11 4.3. New Options . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. Mobility Header Prefix Option . . . . . . . . . . . . 11 4.3.2. Mobility Header IP Address Option . . . . . . . . . . 12 4.3.3. Mobility Header Link-Layer Address Option . . . . . . 13 5. Protocol in Detail . . . . . . . . . . . . . . . . . . . . . . 14 5.1. DNA with LinkID Prefix in L2 beacon . . . . . . . . . . . 14 5.2. Dynamic NAR Address Discovery . . . . . . . . . . . . . . 14 5.3. FMIPv6 with LinkID Procedures . . . . . . . . . . . . . . 15 5.3.1. MN resolving new subnet information . . . . . . . . . 15 5.3.2. Binding Procedure . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Normative References . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Kota, et al. Expires August 31, 2006 [Page 2] Internet-Draft FL February 2006 1. Introduction FMIPv6 [1] protocol is designed to achieve seamless handoff. FMIPv6 relies on (AP-ID, AR-Info) in PARs but doesn't define how it can be built. Also FMIPv6 can't work if PAR doesn't have an entry for the next AP. In this draft, we present a scheme for PAR to dynamically build (AP-ID, AR-Info) tuple, which we call Dynamic NAR Address Discovery. With such a scheme, we can make FMIPv6 function even when PAR doesn't have a suitable (AP-ID, AR-Info) tuple. We propose wireless AP to advertise the LinkID prefix in L2 beacons to allow 1) PAR to acquire NAR Address Information similar to Dynamic Home Agent Address Discovery [4] and 2) MN to perform FMIPv6 procedure even when PAR doesn't have the NAR information. Kota, et al. Expires August 31, 2006 [Page 3] Internet-Draft FL February 2006 2. New Terms Dynamic NAR Address Discovery - A procedure to dynamically discover NAR Address information such as its IP Address and MAC Address. NAR Address Information - NAR global IP and Link Layer addresses on the interface to which anycast address/ LinkID prefix belongs to. NAR anycast address - An IP address formed from LinkID prefix advertised in NAR subnet and a pre-determined interface identifier. This is used in 1. NAR Address Discovery Request message by PAR. 2. HI by PAR, when PAR receives FBU with LinkID prefix and PAR does not have NAR address information. NAR Address Discovery Request (NADREQ) - A message from PAR to discover NAR Address Information. NAR Address Discovery Reply (NADREP) - A message from the NAR in response to NADREQ. Kota, et al. Expires August 31, 2006 [Page 4] Internet-Draft FL February 2006 3. Protocol Overview Dynamic Home Agent Address Discovery in MIPv6 [4] allows an MN to dynamically find out Home Agent address by sending an Home Agent Address Discovery Request message to the Mobile IPv6 Home-Agents anycast address for its home IP subnet prefix. Similarly this draft propose a scheme for a PAR to dynamically find out NAR address by sending an NAR Address Discovery Request (NADREQ) message to the NAR anycast address for the NAR subnet prefix. We make a wireless AP advertise a suitable NAR subnet prefix to provide it to PAR as below. Wireless AP (Access Point) such as 802.11 AP (Access Point) puts the LinkID Prefix information in its beacon message. An MN may scan incoming beacon to retrieve the associated LinkID prefix. With the LinkID Prefix, the MN can perform DNA procedure to determine whether the AP belongs to the same link or not. If the AP belong to the same link, the MN can move to it without performing any L3 handover procedure. Assume the MN receives a LinkID prefix in beacon which belongs to a different link. Then the MN forwards the LinkID prefix to its PAR in a RtSolPr message. Upon receiving the RtSolPr message, if the PAR has an entry for the AP, it follows the standard FMIPv6 procedure to send back PrRtAdv. Even in case the PAR doesn't have an entry for the AP, it can get the necessary information dynamically in a similar way as Home Agent Discovery in [4]. The PAR forms a NAR Anycast Address by combining the LinkID prefix it received in RtSolPr and well-known interface identifier and sends an NADREQ message to the NAR Anycast Address to request NAR information from an NAR. The NAR which receives the NADREQ replies an NADREP with the NAR information. When the NADREP arrives, the PAR forwards the NAR information to the MN in a PrRtAdv. Then the MN can perform standard FMIPv6 procedure. If the MN needs to move to the new AP before receiving PrRtAdv, it forms a new CoA with the LinkID prefix and sends FBU with the NCoA and the LinkID prefix. Upon receiving it, if it has the suitable NAR information, the PAR initiates HI/ HAck exchange in unicast. If it has none, the PAR sends an HI to an NAR anycast address and the NAR that receives the HI replies with HAck with a suitable information. Hence, the MN can Kota, et al. Expires August 31, 2006 [Page 5] Internet-Draft FL February 2006 form an NCoA without PrRtAdv and the PAR can send HI without knowing NAR address. Kota, et al. Expires August 31, 2006 [Page 6] Internet-Draft FL February 2006 4. Message Format 4.1. NAR Address Discovery Messages These messages are ICMPv6 messages and have a common type specified in RFC 4065 [3]. 4.1.1. NAR Address Discovery Request (NADREQ) PAR uses NAR Address Discovery Request message to request the NAR for NAR Address Information. PAR sends the NADREQ to NAR anycast address formed using LinkID prefix advertised in the NAR subnet. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Feilds: Source Address The Global IP address of the PAR. Destination Address NAR anycast address. ICMP Feilds: Type The Experimental Mobility Protocol Type. See RFC 4065 [3]. Code 0. Checksum The ICMPv6 checksum. Kota, et al. Expires August 31, 2006 [Page 7] Internet-Draft FL February 2006 Subtype TBA. Reserved MUST be set to zero by the sender and ignored by the receiver. Identifier MUST be set by the sender so that replies can be matched to this message. Valid Options: Prefix Information Option The prefix of the sender used for autoconfiguring the addresses. This option need not be included if the prefix matches with the prefix of the IP address in the IP Address Option. See New Router Prefix Information Option defined in RFC 4068 [1]. IP Address Option The IP Address of the sender which can be used as new router address by the receiver of this message. See IP Address Option defined in RFC 4068 [1]. Link Layer Address Option The Link Layer Address of the interface to which IP Address Option belongs to. See Link-Layer Address Option defined in RFC 4068 [1]. Sender may include the Prefix Information Option, IP Address Option and Link Layer Address Option, and receiver can store the information. In response to Dynamic NAR Address Discovery Request message, NAR should reply with NAR Address Discovery Reply message. 4.1.2. NAR Address Discovery Reply (NADREP) NAR sends NAR Address Discovery Reply message in response to NAR Address Discovery Request received from PAR. Kota, et al. Expires August 31, 2006 [Page 8] Internet-Draft FL February 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Feilds: Source Address NAR Global IP address. Destination Address Copied from the source address of the NAR Address Discovery Request Message to which this message is a response. ICMP Feilds: Type The Experimental Mobility Protocol Type. See RFC 4065 [3]. Code 0. Checksum The ICMPv6 checksum. Subtype TBA. Reserved MUST be set to zero by the sender and ignored by the receiver. Identifier Copied from the corresponding field in NAR Address Discovery Request Message to which this message is a response. Kota, et al. Expires August 31, 2006 [Page 9] Internet-Draft FL February 2006 Valid Options: IP Address Option The Global IP Address of the NAR interface to which NAR ayncast address (destination address of the NADREQ) belongs to. This option should be present. See IP Address Option defined in RFC 4068 [1]. Link Layer Address Option The Link Layer Address of the interface to which IP Address Option belongs to. This option should be present. See Link-Layer Address Option defined in RFC 4068 [1]. 4.2. FMIPv6 messages with new options Following are the FMIPv6 messages defined in RFC 4068 [1]. These messages carries new options along with the options defined in RFC 4068 [1]. 4.2.1. Router Solicitation for Proxy Router Advertisement (RtSolPr) New Router Prefix Information Option carrying LinkID prefix is included in RtSolPr for each AP-ID for which LinkID prefix is known. This prefix option, if included, should be immediately followed by corresponding New Access Point Link-Layer Address option. See New Router Prefix Information Option defined in RFC 4068 [1]. 4.2.2. Handover Acknowledgement (HAck) HAck should carry New Router IP Address Option and New Router Link- Layer Address Option, if the corresponding received HI is destined to NAR anycast address. New Router IP Address Option carries NAR global IP Address and New Router Link-Layer Address option carries NAR link layer address of the interface to which HI is destined. See IP Address Option and Link-Layer Address Option defined in RFC 4068 [1]. 4.2.3. Fast Binding Update (FBU) Mobility Header Prefix Option (see Section 4.3.1) is included, if the sender knows LinkID of new subnet but does not have the new subnet information and is going to associate with an Access Point in the new subnet. Mobility Header Prefix Option carries the LinkID prefix advertised in the new subnet. Kota, et al. Expires August 31, 2006 [Page 10] Internet-Draft FL February 2006 4.2.4. Fast Binding Acknowledgment (FBack) Mobility Header IP Address Option (see Section 4.3.2) and Mobility Header Link-Layer Address Option(see Section 4.3.3) are included, if the corresponding received HAck contains New Router IP Address Option and New Router Link Layer address Option. The IP Address in Mobility Header IP Address Option and Link Layer address in Mobility Header Link-Layer Address Option are copied respectively from corresponding fields of New Router IP Address Option and New Router Link Layer address Option in HAck. 4.3. New Options 4.3.1. Mobility Header Prefix Option This Option is used to send LinkID prefix (of the new subnet) in the FBU message. This Option has an alignment requirement of 8*n+2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option-Code | Prefix Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA. Length Length of this option in octets not including Type, Length, Option-Code, Prefix Length and Reserved feilds. Option-Code TBA. Kota, et al. Expires August 31, 2006 [Page 11] Internet-Draft FL February 2006 Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. Reserved MUST be set to zero by the sender and ignored by the receiver. Prefix An IP Prefix. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. 4.3.2. Mobility Header IP Address Option This Option is used to send NAR IP Address in the FBack message. This Option has an alignment requirement of 8*n+2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option-Code | Prefix Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA. Length Length of this option in octets not including Type, Length, Option-Code, Prefix Length and Reserved feilds. Kota, et al. Expires August 31, 2006 [Page 12] Internet-Draft FL February 2006 Option-Code TBA. Prefix Length 8-bit unsigned integer. The Length of the IPv6 Address prefix. The value ranges from 0 to 128. Reserved MUST be set to zero by the sender and ignored by the receiver. IPv6 Address The IPv6 Address corresponding to the Option-Code value. 4.3.3. Mobility Header Link-Layer Address Option The MH-LLA Option (see RFC 4068 [1]) with a new Option-Code value can be used to carry NAR Link Layer address in FBack message. Kota, et al. Expires August 31, 2006 [Page 13] Internet-Draft FL February 2006 5. Protocol in Detail 5.1. DNA with LinkID Prefix in L2 beacon A wireless AP such as 802.11 AP may advertise the LinkID prefix in L2 beacon to facilitate FMIPv6 operation. An AP can get a suitable RA as defined in Sec 5.1 'RA Caching' of FRD [7] and extract a LinkID Prefix from the RA because the LinkID is explicitly advertised in any RA. Then the AP puts the LinkID prefix in its beacon message. An MN may scan incoming beacon from the AP to retrieve the LinkID prefix associated with the AP, i.e. the LinkID prefix of the link to which the AP belongs. The MN may perform DNA procedure to determine whether the AP is on the same link or not. Take note that even the AP advertises any prefix, the MN can check for link change if it has the Complete Prefix List [8] If the AP is on the same link, the MN can change its attachment to the AP without performing any L3 handoff procedure because the MN can keep using the existing IP configuration. So when MN moves to the AP on the same link, it only needs to perform L2 handoff procedure and and reduces unnecessary IP signaling messages such as RS/ RA messages. Also when an MN selects the next AP from multiple candidates, it can choose the one on the same link to reduce signaling overhead, in case every other condition is the same. 5.2. Dynamic NAR Address Discovery In some cases, Access Routers (specifically PAR) may not have the (AP-ID, AR-Info) tuple information for the requested Access Point(s) in the RtSolPr. For each such LinkID in RtSolPr, PAR should perform the following procedure to resolve the NAR Address Information of the (AP-ID, AR-Info) tuple before sending PrRtAdv. PAR should not send NADREQ again, if it is already in the process of resolving the same information. Following cases should be considered as PAR is resolving the information for the given LinkID 1. PAR has sent NADREQ to NAR anycast address derived from same LinkID and waiting for response. 2. PAR has sent HI to NAR anycast address derived from same LinkID and waiting for response. Kota, et al. Expires August 31, 2006 [Page 14] Internet-Draft FL February 2006 PAR will form NAR anycast address from LinkID prefix. It sends NAR Address Discovery Request (see Section 4.1.1) to NAR anycast address, requesting NAR Address Information. NAR should send the NAR Address Discovery Reply (Section 4.1.2) with its global unicast IP address and Link Layer address of the interface for which destination address in the NADREQ belongs to, if the NADREQ is valid. PAR should retransmit the NADREQ, if it has not received NADREP within a time period (no less than twice the typical RTT between source and destination, or 100 milliseconds if RTT is not known). PAR may retransmit the NADREQ for a maximum of NAD_RETRIES [TBA]. Retransmissions should follow the exponential backoff algorithm in which timeout period is doubled before each retransmission. PAR may maintain a timer for each (AP-ID, AR-Info) tuple to invalidate the entry after a timeout period. PAR can start Dynamic NAR Address Discovery before the information becomes invalid. PAR can optionally include its address information such as IPv6 address, link layer address and LinkID prefix (if the prefix in IPv6 address is different) in the NADREQ, so that receiver can store this information. 5.3. FMIPv6 with LinkID Procedures 5.3.1. MN resolving new subnet information As per FMIPv6 [1], MN can discover the neighboring access points using link layer mechanisms to resolve the neighboring subnet information by exchanging RtSolPr and PrRtAdv with PAR. While discovering neighboring Access Points or when MN receives beacons from new Access Points, MN compares the LinkID received (if it is present) in the beacons from new access points with its current LinkID. If the MN does not have the (AP-ID, AR-Info) tuple for the corresponding access point(s), it can send RtSolPr (see Section 4.2.1 to resolve one or more AP-IDs. MN should not include the Access Points that belongs to it's current subnet (i.e., LinkID is same) in the RtSolPr. MN should include the LinkIDs in RtSolPr along with AP-IDs, if it receives LinkID in beacons. The LinkID prefix option should be immediately followed by corresponding AP-ID option, if it is present. The format of LinkID prefix option is same as the new router prefix information option of FMIPv6 [1]. The exchange and processing of RtSolPr and PrRtAdv between the MN and PAR will be as per FMIPv6 [1] except including LinkIDs in RtSolPr and Kota, et al. Expires August 31, 2006 [Page 15] Internet-Draft FL February 2006 PAR performing Dynamic NAR Address Discovery (see Section 5.2), if required. 5.3.2. Binding Procedure If the MN has the (AP-ID, AR-Info) tuple before it is going to associate with new access point, it should follow the FMIPv6 [1] procedures. Otherwise, if the LinkID is received in the beacons advertised by the new access point, MN should follow the following procedure. MN should form a prospective NCoA using LinkID prefix and send the FBU (see Section 4.2.3) along with LinkID in Mobility Header Prefix Option (see Section 4.3.1). MN should process any PrRtAdv received after sending FBU. If the MN receives FBack with NAR Address Information, it should store the information. MN should follow the FMIPv6 procedures from this point onwards. MN can use the LinkID prefix information after attaching to new access point, even if the FMIPv6 operation fails. If the PAR receives FBU with LinkID prefix, PAR should check if it has the NAR Address Information corresponding to the LinkID prefix. If the PAR has NAR Address Information, PAR should send PrRtAdv to MN with NAR Address information and send HI to NAR as per FMIPv6 [1]. If the PAR does not have NAR Address Information, it should send HI to NAR Anycast address formed using LinkID prefix. If NAR receives HI destined to its anycast address, it should include NAR Address Information in the response (see Section 4.2.2). After receiving HAck with NAR Address Information, PAR will store that information and send FBack (see Section 4.2.4) to MN (both PCoA and NCoA) with NAR Address Information by including MH IP Address Option (See Section TBF) and MH Link Layer Address Option (See RFC 4068 [1]). NAR should ignore HAck without NAR Address Information received in response to HI sent to NAR anycast address. Retransmissions of HI should be as per FMIPv6 [1]. PAR should not send any PrRtAdv to MN after sending HI to NAR unless MN solicits again. Kota, et al. Expires August 31, 2006 [Page 16] Internet-Draft FL February 2006 6. Security Considerations TBD 7. Normative References [1] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [2] Pentland, B., "Detecting Network Attachment in IPv6 Networks (DNAv6)", draft-pentland-dna-protocol3-00 (work in progress), October 2005. [3] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005. [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Choi, J., "Fast Router Discovery with L2 support", draft-ietf-dna-frd-00 (work in progress), October 2005. [8] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix list based approach", draft-ietf-dna-cpl-02 (work in progress), January 2006. Kota, et al. Expires August 31, 2006 [Page 17] Internet-Draft FL February 2006 Authors' Addresses Subba Reddy Samsung India Software Operations J.P. Techno Park, 3/1, Millers Road Bangalore 560-052 India Phone: +91-80-51197777 Email: subbareddy@samsung.com Wable Samsung India Software Operations J.P. Techno Park, 3/1, Millers Road Bangalore 560-052 India Phone: +91-80-51197777 Email: wable@samsung.com JinHyeock Choi Samsung AIT Communication Lab P.O.Box 111 Suwon 440-600 KOREA Phone: +82 31 280 9233 Email: jinchoe@samsung.com Kota, et al. Expires August 31, 2006 [Page 18] Internet-Draft FL February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 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. Copyright Statement 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kota, et al. Expires August 31, 2006 [Page 19]