Network Working Group C. Perkins Request for Comments: 4636 Nokia Research Center Category: Standards Track October 2006 Foreign Agent Error Extension for Mobile IPv4 Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).
AbstractThis document specifies a new extension for use by Foreign Agents operating Mobile IP for IPv4. Currently, a foreign agent cannot supply status information without destroying the ability for a mobile node to verify authentication data supplied by the home agent. The new extension solves this problem by making a better place for the foreign agent to provide its status information to the mobile node.
4]. The new extension option allows a foreign agent to supply an error code without disturbing the data supplied by the Home Agent within the Registration Reply message. In this way, the mobile node can verify that the Registration Reply message was generated by the Home Agent even in cases where the foreign agent is required by protocol to insert new status information into the Registration Reply message. RFC 2119 . Other terminology is used as already defined in . 4]. The FA Error Extension is not skippable. 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 | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 45 Length 2 Sub-Type 0 Status A status code used by the foreign agent to supply status information to the mobile node.
RFC 3344  for use by the Foreign Agent. Status codes for use with the FA Error extensions must not be differently defined for use in the Code field of Registration Reply messages. When a foreign agent appends a FA Error Extension to the Registration Reply as received from the Home Agent, it has to update the UDP Length field in the UDP header  to account for the extra 4 bytes of length. This document updates the Mobile IP base specification  regarding the procedures followed by the foreign agent in the case that the home agent fails authentication. Instead of modifying the "status" field of the Registration Reply to contain the value 68, now the foreign agent should append the Foreign Agent Error Extension containing the status value 68.
2] to the Home Agent if a mobility security association exists between them. For cases when the foreign agent does have the required security association, this way of informing the home agent does not have the vulnerability from detrimental actions by malicious foreign agents, as noted in section 8. section 3) from the space of numbers for non-skippable mobility extensions (i.e., 0-127) defined in the specification for Mobile IPv4 . This specification also creates a new number space of sub-types for the type number of this extension. Sub-type zero is to be allocated from this number space for the protocol extension specified in this document. Similar to the procedures specified for Mobile IP  number spaces, future allocations from this number space require expert review . The status codes that are allowable in the FA Error Extension are a subset of the status codes defined in the specification for Mobile IPv4 . If, in the future, additional status codes are defined for Mobile IPv4, the definition for each new status code must indicate whether the new status code is allowable for use in the FA Error Extension.
failed, when in fact its home agent and a correctly operating foreign agent had both accepted the mobile node's Registration Request. In order to reduce the vulnerability to such maliciously transmitted Registration Reply messages with the unauthenticated extension, the mobile node MAY delay processing of such denied Registration Reply messages for a short while in order to determine whether another successful Registration Reply might be received from the foreign agent.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003.  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.  Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
Full 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. 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. 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 firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).