Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4881

Low-Latency Handoffs in Mobile IPv4

Pages: 64
Experimental
Part 3 of 3 – Pages 46 to 64
First   Prev   None

Top   ToC   RFC4881 - Page 46   prevText

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.
Top   ToC   RFC4881 - Page 47

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.
Top   ToC   RFC4881 - Page 48

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].
Top   ToC   RFC4881 - Page 49

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.
Top   ToC   RFC4881 - Page 50

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.
Top   ToC   RFC4881 - Page 51

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.
Top   ToC   RFC4881 - Page 52

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.
Top   ToC   RFC4881 - Page 53

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
Top   ToC   RFC4881 - Page 54
   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 Address

10.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].
Top   ToC   RFC4881 - Page 55
   Code Values for Mobile IP Handoff Reply Messages

   0          Successful Handoff
   1          Generic Handoff Failure
   2-255      Unallocated

11. 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.
Top   ToC   RFC4881 - Page 56
   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
Top   ToC   RFC4881 - Page 57
   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.
Top   ToC   RFC4881 - Page 58
   [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.
Top   ToC   RFC4881 - Page 59

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.
Top   ToC   RFC4881 - Page 60

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
Top   ToC   RFC4881 - Page 61
   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)
Top   ToC   RFC4881 - Page 62
      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)
Top   ToC   RFC4881 - Page 63

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.com

Editor's Address

Karim El Malki Athonet EMail: karim@athonet.com
Top   ToC   RFC4881 - Page 64
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.