RFC 4881
Low-Latency Handoffs in Mobile IPv4
Pages: 64
Experimental
Experimental
Part 3 of 3 – Pages 46 to 64
9. Generalized Link Layer and IPv4 Address (LLA) Extension
This section defines the Generalized Link Layer and IPv4 Address (LLA) Extension, used by any node that needs to communicate link layer and IPv4 addresses. The format of the extension relies on sub-types, where each sub-type defines its own sub-structure. This document defines six sub-types. Future RFCs should allocate their own sub-type and define their own address formats. 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 | Sub-Type | LLA ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 138 (skippable) [1] - when used in Registration Requests 140 (skippable) [1] - when used in Agent Advertisements Length The length of the Link Layer Address + the one-octet Sub-Type field Sub-Type This field contains the Link Layer sub-type identifier LLA Contains the Link Layer Address In this document, seven sub-types are defined: 1 3GPP2 International Mobile Station Identity and Connection ID [13] 2 3GPP International Mobile Subscriber Identity [15] 3 Ethernet 48-bit MAC address [5] 4 64-bit Global ID, EUI-64 [6] 5 Solicited IPv4 Address 6 Access Point Identifier 7 FA IPv4 Address The following subsections describe the extensions.
9.1. 3GPP2 IMSI Link Layer Address and Connection ID Extension
The IMSI Link Layer Address Extension contains the International Mobile Station Identity (IMSI). 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 | Sub-Type | IMSI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 (skippable) [1] Length The length of the IMSI field + the one-octet Sub-Type field Sub-Type 1 IMSI Contains the IMSI, in the form: <IMSI>:<Connection Id> Where the <IMSI> is an ASCII-based representation of the International Mobile Station Identity, most significant digit first, ":" is ASCII 0x3a, and the Connection ID is the ASCII representation of a small, decimal number used for distinguishing different link-layer connections from the same mobile device.
9.2. 3GPP IMSI Link Layer Address Extension
The IMSI Link Layer Address Extension contains the International Mobile Station Identity. 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 | Sub-Type | IMSI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 (skippable) [1] Length The length of the IMSI field + the one-octet Sub-Type field Sub-Type 2 IMSI Contains the IMSI, a number composed of 15 digits or less, coded as described in [15].
9.3. Ethernet Link Layer Address Extension
The Ethernet Link Layer Address Extension contains the 48-bit Ethernet MAC Address, as defined in [5]. 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 | Sub-Type | MAC ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 (skippable) [1] Length 7 (includes the Sub-Type field) Sub-Type 3 MAC Contains the 48-bit Ethernet MAC Address.
9.4. IEEE 64-Bit Global Identifier (EUI-64) Address Extension
The 64-bit Global Identifier (EUI-64) Address Extension contains the 64-bit address, as defined in [6]. 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 | Sub-Type | MAC ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 (skippable) [1] Length 9 (includes the Sub-Type field) Sub-Type 4 MAC Contains the 64-bit Global Identifier Address.
9.5. Solicited IPv4 Address Extension
The 32-bit Solicited IPv4 Address Extension contains the IPv4 address of the agent (FA) being solicited. This extension MAY be present in an ICMP Agent Solicitation as explained in Section 3.3. 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 | Sub-Type | IPv4 addr ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 5 (skippable) [1] Length 5 (includes the Sub-Type field) Sub-Type 5 IPv4 Address Contains the 32-bit IPv4 Address of the solicited node.
9.6. Access Point Identifier Extension
The 32-bit Access Point Identifier Extension contains an identifier of the access point to which the MN will move. This may be a wireless L2 identifier. The MN is able to solicit an advertisement from the FA servicing a certain access point by using this extension with Agent Solicitations as explained in Section 3.3. 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 | Sub-Type | AP ID... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 6 (skippable) [1] Length 5 (includes the Sub-Type field) Sub-Type 6 AP ID Contains the 32-bit Access Point Identifier.
9.7. FA IPv4 Address Extension
The 32-bit FA IPv4 Address Extension contains the IPv4 address of the agent (FA). This extension MAY be present in a Registration Request message to identify the oFA as explained in Section 5. 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 | Sub-Type | IPv4 addr ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 7 (skippable) [1] Length 5 (includes the Sub-Type field) Sub-Type 7 IPv4 Address Contains the 32-bit IPv4 Address of the FA node.10. IANA Considerations
This document defines one new extension to Mobile IPv4 Control messages and one new extension to Mobile IPv4 Router Discovery messages already maintained by IANA. This document also defines a new Mobile IPv4 Control message type to be used between FAs. To ensure correct interoperation based on this specification, IANA must reserve values in the Mobile IPv4 number space for two new extensions and one new message type. IANA must also manage the numbering spaces created by the two new extensions, the message type, and its associated Code field.10.1. New Extension Values
Section 9 introduces two extensions. Generalized Link Layer and IPv4 Address (LLA) Extension for Router Discovery messages: A new Mobile IPv4 extension that follows after Mobile IPv4 ICMP Router Discovery messages (e.g., Mobile IP Agent Advertisements). The type value of this extension belongs to the
Mobile IPv4 number space for Router Discovery messages maintained by IANA. The value assigned by IANA is 140. This new extension uses the Link Layer and IPv4 Address Identifier (LLA) sub-type numbering space that requires IANA management (see Section 10.2). Generalized Link Layer and IPv4 Address (LLA) Extension for Mobile IP Control messages: A new Mobile IPv4 extension appended to Mobile IP Control messages (e.g., Registration Request). The type value of this extension belongs to the Mobile IPv4 number space for extensions to Mobile IPv4 Control messages maintained by IANA. It MUST be in the skippable (128-255) range as defined in [1]. The value assigned is 138 by IANA. This new extension uses the Link Layer and IP Address Identifier (LLA) sub-type numbering space that requires IANA management (see Section 10.2).10.2. Generalized Link Layer and IP Address Identifier (LLA) Sub-type Values
This section describes the sub-type values that are applicable to both the Generalized LLA Extensions for Mobile IP Control and Router Discovery messages. This specification makes use of the sub-type values 1-7, and all other values other than zero (reserved) are available for assignment via IETF consensus [14]. The seven sub-type values defined in this specification are: 1 3GPP2 International Mobile Station Identity and Connection ID [13] 2 3GPP International Mobile Subscriber Identity [15] 3 Ethernet 48-bit MAC address [5] 4 64-bit Global ID, EUI-64 [6] 5 Solicited IPv4 Address 6 Access Point Identifier 7 FA IPv4 Address10.3. New Message Type and Code
Sections 4.5 and 4.6 define two new Mobile IPv4 message types: Handoff Request and Handoff Reply. These require two type numbers to be assigned by IANA from the Mobile IPv4 Control message type address space. The Handoff Reply message also introduces its own Code field that requires IANA to manage a new Code address space. This specification makes use of the Code values 0-1, where 0 identifies a successful handoff and 1 defines a generic handoff failure. All other values are available for assignment via IETF consensus [14].
Code Values for Mobile IP Handoff Reply Messages 0 Successful Handoff 1 Generic Handoff Failure 2-255 Unallocated11. Security Considerations
For the PRE-REGISTRATION method, as discussed in Section 3.8, the oFA and nFA MUST share a security association to authenticate and integrity protect messages transported between them. In addition, oFA must be authorized to solicit nFA based on the security association. The minimal requirement to establish a security association between FAs is that both FAs support manual pre- configuration of security associations involving shared keys. Other mechanisms to establish security associations using IKE [16] based on shared secrets or public keys may also be used. The inter-FA ICMP messages (solicitations and advertisements) MUST be authenticated and integrity protected using ESP [10]. The default ESP authentication algorithm for use in this specification is HMAC-SHA1-96 [12]. The absence of this security would allow denial-of-service attacks from malicious nodes at any distance from the FA. To secure Registration Request and Reply messages, PRE-REGISTRATION uses the security mechanisms already described in [1] and optionally [11]. POST-REGISTRATION introduces a new change to Mobile IPv4, which is the possibility that an MN may receive packets from an FA with which it has not yet performed a Mobile IPv4 Registration. It is not recommended that the MN drop packets from unknown FAs since it would effectively eliminate the advantages of POST-REGISTRATION. From a security viewpoint, dropping packets from unknown FAs would not provide significant protection for an MN from any attack. This is because any malicious host may use the MN's home address to send packets to the MN through its current known FA; therefore, processing packets received from unknown FAs would not provide worse security than with normal Mobile IPv4. In a similar way to PRE-REGISTRATION, in POST-REGISTRATION, oFA and nFA MUST share a security association required to protect the Handoff Request and Reply messages. The minimal requirement to establish a security association between FAs is that the FAs support manual pre- configuration of security associations involving shared keys. Other mechanisms to establish security associations using IKE [16] based on shared secrets or public keys may also be used. The Handoff Request and Reply messages MUST be authenticated using the FA-FA authentication extension [11] that uses the default algorithm specified in [7]. The absence of this security would allow impersonation attacks and denial-of-service attacks.
The minimal requirement is that all FAs involved in low latency handoffs MUST support manual pre-configuration of peer-to-peer security associations with neighboring FAs, involving shared secrets and are already required to support the default algorithms of [1]. Other mechanisms to establish security associations using IKE [16] based on shared or public keys may also be used. Since the techniques outlined in this document depend on particular L2 information (triggers) to optimize performance, some level of L2 security is assumed. Both PRE- and POST-REGISTRATION techniques depend on L2 triggers, but the L2 security implications are different for the two techniques. In particular, in POST-REGISTRATION, the L2 triggers initiate the establishment of tunnels that route IPv4 packets for the MN to its new location. Therefore, the L2 triggers MUST be secured against any tampering by malicious nodes, either mobile or within the wired network. The L2 addresses or IPv4 addresses for the MN and the FAs that appear in the L2 triggers MUST correspond to the actual nodes that are participating in the handoff. If there is any possibility that tampering may occur, the recipient of an L2 trigger MUST have some way of authenticating the L2 information. Wireless networks that do not provide such features will be subject to impersonation attacks, where malicious nodes could cause FAs to believe that an MN has moved to other service areas or to allow a bogus MN to obtain unauthorized service from an FA prior to performing a Mobile IPv4 Registration. In POST-REGISTRATION, the L2 triggers would typically be sent between a wireless base station and the FA. No standard protocol exists at this time to communicate the L2 trigger information, but it is important that any future protocol used for this purpose provides adequate security. If the wireless base station and FA were integrated, then this security threat would not apply. Also the layer 2 control messages on the wireless link must be secured appropriately to prevent a malicious node from running impersonation attacks and causing unwanted L2 triggers to be generated. Integrity and replay protection would be required to avoid impersonation threats and resource consumption threats where a malicious node replays old messages to cause resource consumption. This depends on the type of L2 security of the wireless link. For example, in cellular technologies, the control messages are secured, although the type of security varies depending on the cellular standard, but this is not typically the case in WLAN IEEE 802.11 networks. In PRE-REGISTRATION, the security of L2 triggers has different implications. The PRE-REGISTRATION technique depends on Mobile IPv4 security between MN and FA, so the same security considerations in [1] apply. Should malicious nodes be able to generate or modify L2
trigger information (i.e., L2-ST or L2-TT), this would cause advertisements to be sent to the MN. They would consume wireless resources and processing in the MN, but would not allow an impersonation attack. In order to prevent such denial-of-service attacks, there should be a limit on the number of advertisements that an FA (oFA) will relay to the MN as a result of the reception of L2 triggers. This number will depend on the L2 technology, and the default limit is 10 per second.12. Acknowledgements
The authors want to thank Lennart Bang, Bryan Hartwell, Joel Hortelius, Gianluca Verin, and Jonathan Wood for valuable comments and suggestions on the whole document. The authors also thank the Mobile IPv4 WG chairs, Phil Roberts and Basavaraj Patil, for their input.13. References
13.1. Normative References
[1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001. [4] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [5] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982. [6] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. [7] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 Challenge/Response Extensions (Revised)", RFC 4721, January 2007.
[8] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991. [9] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [10] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [11] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 Regional Registration", RFC 4857, June 2007. [12] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.13.2. Informative References
[13] TIA/EIA/IS-2000. [14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [15] 3GPP TS 23.003 (www.3gpp.org). [16] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
Appendix A - Gateway Foreign Agents
The Mobile IPv4 Regional Registration specification [11] introduces the Gateway Foreign Agent (GFA), as a mobility agent that two FAs providing service to an MN have in common. Figure A.1 provides an example of an MN's initial registration through the GFA. If this is the first registration message, the message MUST be forwarded to the HA. All packets sent to the MN will be delivered to the GFA, which in turn will forward the packets to the FA servicing the MN. RegReq +-----+ RegReq +----------->| oFA |--------------+ | +-----+ | | v +----+ +-----+ RegReq +----+ | MN | | GFA |<------->| HA | +----+ +-----+ +----+ +-----+ | nFA | +-----+ Figure A.1 - Initial Registrations through GFA If the MN moves to an nFA that is serviced by a GFA common with oFA, the MN MAY issue a Regional Registration Request (see Figure A.2). The Regional Registration message does not need to be forwarded to the HA, since the MN's traffic can still be delivered to the same GFA. This optimized approach effectively reduces the latency involved in the registration process. +-----+ | oFA | +-----+ +----+ +-----+ +----+ | MN | | GFA | | HA | +----+ +-----+ +----+ | ^ | +-----+ | +------------>| nFA |-------------+ RegRegReq +-----+ RegRegReq Figure A.2 - Regional Registration through GFA Note that the GFA may also be the MN's first-hop router.
Appendix B - Low-Latency Handoffs for Multiple-Interface MNs
For MNs that have two wireless network interfaces, either on the same wireless network or on wireless networks having different wireless L2 technologies, the techniques discussed in this document may be unnecessary if the Mobile IPv4 stack on the MN allows switching an IPv4 address binding between interfaces. This Appendix discusses how multiple wireless interfaces can aid low-latency handoff. +------+ +---------+ | HA |--------| (GFA) | +------+ +---------+ / \ ... ... / \ / \ +------+ +------+ | oFA | | nFA | +------+ +------+ | | +------+ +------+ | RN1 | | RN2 | +------+ +------+ +------+ | MN | ---------> +------+ Movement Figure B.1 - Network Model for Mobile IPv4 with Multi-Access Figure B.1 illustrates the normal and hierarchical MIPv4 models. As shown in the figure, assume that the MN is connected to Radio Network 1 (RN1) and is registered with oFA through which it is receiving traffic. Suppose MN enters the coverage area of RN2 and nFA and that it prefers connectivity to this network for reasons beyond the scope of this document (e.g., user preferences, cost, QoS available, etc.). The MN activates the interface to RN2 but continues communicating through RN1. The MN may solicit advertisements from nFA through the interface connected to RN1 to speed up the handoff process, provided there is no TTL restriction, or it can solicit advertisements through the interface connected to RN2 if it has been configured for IPv4 traffic. Once the MN is registered with nFA and is successfully receiving and transmitting through the new network, it tears down the interface to RN1. If the MN has enough time to complete this procedure without incurring degraded service or disconnection, the MN would experience a seamless multi-access handoff, but it may not be possible in all
cases, due to network coverage or for other reasons. Should multiple interface handoff be possible, then the low-latency methods described in this document are not necessary. In order to support the possible failure of the connectivity with the new network (RN2/nFA) in the short period following handoff, the MN may use the S bit in its Mobile IPv4 Registration Request to maintain simultaneous bindings with both its existing (HA or GFA) binding with oFA and a new binding with nFA.Appendix C - PRE-REGISTRATION Message Summary
This appendix contains a quick reference for IPv4 and layer 2 addresses to be used in PRE-REGISTRATION messages. Proxy Router Advertisement (PrRtAdv) This is a standard Router/Agent Advertisement [1] with the following characteristics: Source IPv4 Address: nFA IPv4 Address Source Layer 2 Address: oFA L2 Address Destination IPv4 Address: MN IPv4 Address (from PrRtSol) Destination Layer 2 Address: MN L2 Address (from PrRtSol) LLA Extension (defined in this spec): containing nFA Layer 2 Address. Proxy Router Solicitation (PrRtSol) This is a standard Router/Agent Solicitation [1] with the following characteristics: Source IPv4 Address: MN Address Source Layer 2 Address: MN Address Destination IPv4 Address: oFA Address (from source address of previous Router Advertisement or PrRtAdv) Destination Layer 2 Address: oFA Address (from source address of previous Router Advertisement or PrRtAdv LLA) LLA Extension (defined in this spec): depends on the layer 2 technology (e.g., typically for WLAN, this would be the BSSID of the new WLAN Access Point) Registration Request (as seen on MN-oFA link) This is a Mobile IPv4 Registration Request message [1] with the following characteristics: Source IPv4 Address: MN Address Source Layer 2 Address: MN Address Destination IPv4 Address: nFA Address (from source addr of PrRtAdv)
Destination Layer 2 Address: Default Router (i.e., oFA Address)
LLA Extension (defined in this spec): containing the MN's L2
address that must be used by nFA. This will typically be an
Ethernet MAC address but other types can be used as specified in
Section 9 of this document.
Although this is not mandated, an MN implementation may set the S bit
(see Section 6) in Registration Request messages to improve the
handoff and avoid problems due to failed layer 2 handoffs and layer 2
ping-pong effects between two base stations.
Registration Reply (as seen on oFA-MN link)
This is a Mobile IPv4 Registration Reply message [1] with the
following characteristics:
Source IPv4 Address: nFA Address
Source Layer 2 Address: oFA Address
Destination IPv4 Address: MN Address (from source of Registration
Request)
Destination Layer 2 Address: MN Address (from source of
Registration Request)
Contributing Authors
Pat Calhoun Cisco Systems EMail: pcalhoun@cisco.com Tom Hiller Lucent Technologies EMail: tom.hiller@lucent.com James Kempf NTT DoCoMo USA Labs EMail: kempf@docomolabs-usa.com Peter J. McCann Motorola Labs EMail: pete.mccann@motorola.com Ajoy Singh Motorola EMail: asingh1@email.mot.com Hesham Soliman Elevate Technologies EMail: Hesham@elevatemobile.com Sebastian Thalanany US Cellular EMail: Sebastian.thalanany@uscellular.comEditor's Address
Karim El Malki Athonet EMail: karim@athonet.com
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.