Network Working Group D. Damic Internet-Draft D. Premec Intended status: Standards Track B. Patil Expires: December 21, 2007 M. Sahasrabudhe Nokia Siemens Networks June 19, 2007 Proxy Mobile IPv6 indication and discovery draft-damic-netlmm-pmip6-ind-discover-01.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 December 21, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Proxy Mobile IPv6 is a network-based mobility protocol and is able to manage the mobility of an IP host as it moves across different points of attachment within the mobility domain. The IP host whose mobility is being managed by the network is unaware of the existence of Proxy Mobile IPv6 in the network or mobility being managed on its behalf. This draft proposes mechanisms by which the host is informed of proxy Damic, et al. Expires December 21, 2007 [Page 1] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 mobile IPv6 support in a network that it attaches to as well as the ability for the host to discover such capability in the attached network. The ability of the host to discover or be aware of proxy mobile IPv6 support in the network enables better decision making in terms of the type of mobility protocol used for IP mobility. Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 5 4.1. PMIP6 indication in the Router Advertisment . . . . . . . 5 4.2. PMIP6 Care-of Prefix Option . . . . . . . . . . . . . . . 6 4.3. Router Solicitation Mobility Mode Option . . . . . . . . . 8 4.4. DHCPv6 extensions . . . . . . . . . . . . . . . . . . . . 9 4.4.1. Home Network Identifier Option . . . . . . . . . . . . 10 4.4.2. Home Network Information Option . . . . . . . . . . . 11 4.4.3. Note on DHCPv4 . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Damic, et al. Expires December 21, 2007 [Page 2] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 1. Introduction and Scope Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] is a network-based mobility management protocol in which the host is not involved in any signaling to enable IP mobility as it moves and changes its point of attachment. This feature complements the mobility protocols such as Mobile IPv6 [RFC3775] in which the host is involved in mobility management. On the other hand, nodes that are capable for mobility management themselves (i.e., implement the MIP6 functionality in the IP stack) might not require such kind of service. PMIP6 protocol as specified in [I-D.ietf-netlmm-proxymip6] is applicable within the scope of a single PMIP6 domain. However deployment scenarios may include a broader scope than a single domain. Scenarios where mobility is managed by the network are usually referred as running in Proxy MIP (PMIP) mode. Analogously, when mobile nodes manage mobility themselves we are talking about host- based mobility. There are several scenarios in which host-based Mobile IP and proxy MIP support co-exist in the same network. For example: o Different mobility modes within a single PMIP6 domain: In case of nomadic users, the network needs to provide mobility services simultaneously for nodes with and those without the built-in mobility support. Each mobility mode, either PMIP6 or host-based MIP6, needs to be individually recognized and appropriately handled by the network. o Session continuation accros different domains: Mobile node roaming in/out of the PMIP6 domain aims to continue the ongoing session either retaining or substituting the assigned mobility mode. For example, MN running a MIP6 session in the network moves to a PMIP6-enabled domain. Depending on the privileges and policies, the session is either continued using host-based mobility, or the network takes over the mobility management and begins handling the MN in the PMIP6 mode. Existing IPv6 mechanisms, such as Neighbor Discovery protocol (NDP) or DHCPv6, are currently insufficient for the purpose of mobility mode detection or capability negotiation. This document proposes means by which the network can indicate its PMIP6 capabilities and provide specific configuration parameters to mobile nodes. The proposal also proposes a method where MN can proactively participate in mobility management mode selection. Damic, et al. Expires December 21, 2007 [Page 3] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. PMIP6 prefix Prefix assigned to the MN while residing within the PMIP6 domain. Depending on the mobility scope this prefix can be assigned either by the LMA, or the HA. On-link prefix IPv6 prefix available for address autoconfiguration in the local domain, for example valid within a scope of a single AR/MAG. 3. Problem Statement In the PMIP6 domain MN may use stateless address autoconfiguration (SLAAC) or DHCPv6 to configure its addresses. The address configuration parameters provided to the MN MAY be different in cases when supporting PMIP6 or host-based MIP6. In case PMIP is used as a mechanism for global mobility or for emulating the home link to the MN, the network obtains the home prefix for the MN and provides the same to the MN. Prefix is assigned to the MN for the entire session, and must be consistently advertised throughout the entire PMIP6 domain. For MIP6 capable nodes it is sufficient to supply any globallly routable local prefix (address) that MN will use to configure the care-of address (CoA) on its interface. The AR or MAG in an access network should be able to interpret the mobility preference of the host, in case such information is provided in router solicitation (RS) or a DHCP request. NDP and DHCP messages as defined today cannot serve as specific PMIP6 mobility triggers. Furthermore, the profile associated with a user in AAA cannot really be used as an indication about the mobility protocol for the hosts as the device and capability may change. For example: information that subscriber is allowed PMIP6 does not provide indication on what kind of terminal subscriber is actually using (does it implement MIP6), or would the MN rather engage the host-based mobility if able to. Explicit mechanisms and protocol extensions are needed to: o enable the access network to advertise the PMIP6 feature and support to the hosts Damic, et al. Expires December 21, 2007 [Page 4] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 o provide the host with more reliable parameters allowing it to choose the mobility protocol based on its capabilities or other criteria o allow MNs to signal their mobility mode preferences 4. Proposed Solutions This document proposes extensions to the NDP and DHCP protocols that may serve as triggers for PMIP6 mobility selection. These extensions include: a new indication flag in the RA, new options for the Router Advertisement and Router Solicitation messages, as well as new options for the related DHCP messages. 4.1. PMIP6 indication in the Router Advertisment As per [I-D.haberman-ipv6-ra-flags-option] the AR may use a new option to expand the flags field in the Router Advertisement messages. In case the access network does support PMIP6, new option may be used to explicitly indicate this capability. By setting the "N" flag in the RA flag expansion option, AR advertises support for network-based mobility management, i.e., PMIP6 capability. 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 |N| Bit fields available .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... for assignment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. RA flag expansion option with a PMIP6 indication Type Type - 8-bit identifier of the option type To be assigned by IANA, as indicated by [I-D.haberman-ipv6-ra-flags-option] Length Length = 1; The length MUST be checked when processing the option in order to allow for future expansion of this option if the need arises. Damic, et al. Expires December 21, 2007 [Page 5] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 Bits Router Advertisement bit 8 - the "N" flag To be assigned by IANA. This bit is set by the AR to indicate the access network supports network-based mobility management, i.e., PMIP6. Other bits are available for further assignment. 4.2. PMIP6 Care-of Prefix Option The AR can include multiple IPv6 prefixes in a single RA message, with each prefix contained in an own Prefix Information Option. In case the access network supports PMIP6, the AR MAY chose to simultaneoulsy advertise local on-link IPv6 prefixes, as well as specific PMIP6 prefix. For this specific case, the two different types of prefixes SHOULD be cleary differentiated. In the PMIP6 domain, AR may either advertise on-link prefixes or the PMIP6 prefix within the RA's Prefix Information Option. Assuming MN is allowed PMIP6 service, the AR SHALL advertise the individually assigned PMIP6 prefix as default, whereas one or more on-link prefixes will be included in the new PMIP6 Care-of Prefix option. Mobile nodes that are capable of processing the new PMIP6 Care-of Prefix option can use obtained information according to preferences and internal configuration. If wishing to deploy host-based MIP6, MN SHOULD use the prefix from the PMIP6 Care-of Prefix option and autoconfigure MIP6 CoA. Otherwise, MN SHALL configure PMIP6 MN-HoA from the Prefix Information Option. Node incapable understanding the new option SHALL ignore it. Damic, et al. Expires December 21, 2007 [Page 6] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 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 | Prefix Length | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + PMIP6 Care-of Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. PMIP6 Care-of Prefix Option Fields: Type 8-bit identifier for the PMIP6 Care-of Prefix option (to be assigned by IANA). Length 4 Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. Reserved1 6-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Valid Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for the purpose of on-link determination. A value of all one bits (0xffffffff) represents infinity. The Valid Lifetime is also used by [RFC2462]. Damic, et al. Expires December 21, 2007 [Page 7] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 Preferred Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that addresses generated from the prefix via stateless address autoconfiguration remain preferred [RFC2462]. A value of all one bits (0xffffffff) represents infinity. See [RFC2462]. Reserved2 This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. PMIP6 CoA Prefix An IP address or a prefix of an IP address indicated as the PMIP6 on-link 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. A router SHOULD NOT send a prefix option for the link-local prefix and a host SHOULD ignore such a prefix option. Description: The PMIP6 Care-of Prefix option provides host with an on-link prefix for stateless address autoconfiguration. The PMIP6 Care-of Prefix option appears in Router Advertisement packets only and MUST be silently ignored for other messages. 4.3. Router Solicitation Mobility Mode Option Mobile node aware of different mobility modes may wish to explicitly notify the AR about its PMIP6 capabilities and embedded support. A new Mobility Mode option in the RS message MAY be used for this purpose. Routers in the network not supporting PMIP6 or unable to process this option SHOULD ignore it. Otherwise the AR MAY acquire the PMIP6 prefix for the mobile node as well as available on-link prefixes, and supply this information in the responding Router Advertisment using the appropriate options. Damic, et al. Expires December 21, 2007 [Page 8] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 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 |P| Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Pad ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Mobility Mode option for RS Type 8-bit identifier for the Mobility Mode option (to be assigned by IANA) Length 8-bit unsigned integer. The length of the option in octets (including the type and length fields) Flags 8-bit field containing flags set by MN to negotiate on the mobility service type. The most significant bit in this field is labled as PMIP6 "P" flag. It is set by MN when explicitly notifiying the network of existing PMIP6 support. Reserved 8-bit field reserved for future use. Pad Variable-length field. This field is used to align the option into units of 8 octets. 4.4. DHCPv6 extensions This section describes how a mobile node can use DHCP [RFC3315] to detect that it is located in the PMIP domain and to inform the AR of its preference to use PMIP6 or host-based MIP6 as a mobility management protocol. By using DHCP, mobile node and the AR are able to exchange following information: Damic, et al. Expires December 21, 2007 [Page 9] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 o AR can let the mobile node know that the access network supports the PMIP6 protocol o AR can inform the mobile node of the PMIP6 prefix o mobile node can inform the AR wheather it should provide a PMIP6 service to it or if the MN prefers to run MIP6 by itself Draft [I-D.ietf-mip6-hiopt] defines new DHCPv6 options used to facilitate bootstraping of a MIP6 based mobility service. One of the options introduced by the draft is a Home Network Identifier option (OPTION_MIP6-HNID) by which the mobile node can request information about the home network and indicate its preference for the location of the HA: in the visited network or in the target network. 4.4.1. Home Network Identifier Option The Home Network Identifier option is extended with an additional code to allow the mobile node to explicitely request information about the availability of the PMIP service at its current point of attachment. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_MIP6-HNID | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | id-type | reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . Home Network Identifier . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. Home Network Identifier option format option-code OPTION_MIP6-HNID (TBD) option-len Total length of the option in octets id-type The type of Home Network Identifier: Damic, et al. Expires December 21, 2007 [Page 10] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 0 Visited domain (local ASP) 1 The target network 2 No preference 3 PMIP domain When the mobile node wants to learn if the access network supports PMIP service, it SHALL include Home Network Option setting the id- type field to 3. When the id-type is set to 3, the Home Network Identifier field MAY be set to 0 if the mobile node wants to learn about the PMIP support in the local domain. Alternatively, if the mobile node wants to inquire about the support for PMIP service in a particular network, the mobile node MAY set the Home Network Identifier field to the network realm as FQDN. The mobile node can learn information about a particular network type by sending separate Information Request messages with different id- types. If the mobile node wants to acquire the information about the visited network, target network and the PMIP domain in a single message exchange, it MAY include several Home Network Identifier options in the reguest message. There may be several Home Network Identifier options with the id-type 1 and/or 3 in a single message. 4.4.2. Home Network Information Option Draft [I-D.ietf-mip6-hiopt] defines a new DHCPv6 option Home Network Information option. This option is used by the DHCP server to convey to the mobile node information about inquired network(s). The information provided could be a home subnet prefix (one or more), home agent address(es) and home agent FQDN(s). There is a separate suboption for each type of information provided (prefix, home agent address and home agent FQDN). If the id-type field of the Home Network Identifier option indicates the network which is not supported by this access network or if the mobile node is not authorized for the requested network, the DHCP server's reponse SHALL include the Home Network Information option with the option-len set to zero. If the mobile node inquiered information about the PMIP domain, the relevant information about the PMIP domain will be provided in the Home Network Information option. In this case the only relevant information is prefix. Since in PMIP mode the mobile node does not interact with the home agent directly, home agent's address and FQDN SHALL not be provided to the mobile node. If the access network wants to force the PMIP mode for the mobile node, it MAY respond to both visited domain and target domain(s) inquieris with a Home Network Information option containing the Damic, et al. Expires December 21, 2007 [Page 11] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 0-length data. 4.4.2.1. Avoiding the premature prefix advertisment When the netlmm domain supports the DHCP extensions specified here, the AR may want to defer advertisment of the prefix until both the mobile node and network have exchanged their capabilites and preferences for a mobility management mode. This can be achived by setting the 'M' or 'O' flag in Router Advertisment message forcing the mobile node to use DHCP. In this way the AR can delay the prefix advertisment until the DHCP exchange is completed. 4.4.2.2. Choosing the PMIP mode If the client decides that it would use PMIP service offered by the access network, it SHALL send the (additional) Information Request message containing Home Network Information sub-option with the Home Network Information field containing the PMIP network prefix. 4.4.3. Note on DHCPv4 Home Network Identifier option and Home Network Information option defined for DHCPv6 could be adopted, with some modifications, for DHCPv4. This would enable the single stack IPv4 host to become aware of the PMIP service support by the access network. Wheather the approach of adopting the DHCPv6 options for DHCPv4 is feasible in this particular case is for futher study. The IPv4 host would include the Home Network Identifier option, indicating its preferences, in the DHCPDISCOVER message. DHCPOFFER message would include Home Network Information option indicating the network type(s) supported by the access network and authorized for the mobile node. The mobile node would indicate its choice in the DHCPREQUEST message by including the Home Network Information option with the id-type field set to the selected network type. 5. Security Considerations TBD. 6. IANA Considerations The following Extension Types MUST be assigned by IANA: PMIP6 "N" indication flag in RA flags expansion option PMIP6 Care-of Prefix Option type Damic, et al. Expires December 21, 2007 [Page 12] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 Mobility Mode Option type DHCPv6 Home Network Information option type 7. Acknowledgements TBD. 8. Normative References [I-D.haberman-ipv6-ra-flags-option] Haberman, B. and R. Hinden, "IPv6 Router Advertisement Flags Option", draft-haberman-ipv6-ra-flags-option-01 (work in progress), April 2007. [I-D.ietf-mip6-hiopt] Jang, H., "DHCP Option for Home Information Discovery in MIPv6", draft-ietf-mip6-hiopt-05 (work in progress), June 2007. [I-D.ietf-netlmm-proxymip6] S. Gundavelli et al., "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-00 (work in progress), April 2007. [RFC2023] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2023, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Damic, et al. Expires December 21, 2007 [Page 13] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 Authors' Addresses Damjan Damic Nokia Siemens Networks Zagrebacka 145a Zagreb 10000 Croatia Phone: +385 1-6331-337 Email: damjan.damic@siemens.com Domagoj Premec Nokia Siemens Networks Zagrebacka 145a Zagreb 10000 Croatia Phone: +385 1-6105-923 Email: domagoj.premec@siemens.com Basavaraj Patil Nokia Siemens Networks 6000 Connection Drive Irving, TX 75039 US Phone: Email: basavaraj.patil@nsn.com Meghana Sahasrabudhe Nokia Siemens Networks 313 Fairchild Drive Mountain View, CA 94043 US Phone: Email: meghana.sahasrabudhe@nsn.com Damic, et al. Expires December 21, 2007 [Page 14] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 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). Damic, et al. Expires December 21, 2007 [Page 15]