idnits 2.17.1 draft-perkins-mip4-faerr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 96: '... Error Extension MUST NOT use the care...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (26 January 2004) is 7390 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3344 (ref. '2') (Obsoleted by RFC 5944) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Mobile IP Working Group Charles E. Perkins 3 INTERNET DRAFT Nokia Research Center 4 26 January 2004 6 Foreign Agent Error Extension for Mobile IPv4 7 draft-perkins-mip4-faerr-00.txt 9 Status of This Memo 11 This document is an individual submission to the Internet Engineering 12 Task Force (IETF). Comments should be submitted to the mip4@ietf.org 13 mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at: 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document specifies a new extension for use by Foreign Agents 36 operating Mobile IP for IPv4. The new extension option allows a 37 foreign agent to supply an error code without disturbing the data 38 supplied by the Home Agent within the Registration Reply message. 39 In this way, the mobile node can verify that the Registration 40 Reply message was generated by the Home Agent even in cases where 41 the foreign agent is required by protocol to insert new status 42 information into the Registration Reply message. 44 1. Introduction 46 This document specifies a new non-skippable extension for use 47 by Foreign Agents operating Mobile IP for IPv4 [2]. The new 48 extension option allows a foreign agent to supply an error code 49 without disturbing the data supplied by the Home Agent within the 50 Registration Reply message. In this way, the mobile node can verify 51 that the Registration Reply message was generated by the Home Agent 52 even in cases where the foreign agent is required by protocol to 53 insert new status information into the Registration Reply message. 55 2. Terminology 57 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 [1]. Other 60 terminology is used as already defined in [2]. 62 3. FA Error Extension Format 64 The format of the FA Error Extension conforms to the Short Extension 65 format specified for Mobile IPv4 [2]. The FA Error Extension is not 66 skippable. 68 0 1 2 3 69 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 70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 71 | Type | Length | Sub-Type | Status | 72 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 74 Type 76 78 Length 80 4 82 Sub-Type 84 0 86 Status 88 A status code used by the foreign agent to supply status 89 information to the mobile node. 91 4. Operation and Use of the FA Error Extension 93 The FA Error extension is only valid for use within Mobile IPv4 94 Registration Reply messages. The FA Error Extension is not 95 skippable. A mobile node that cannot correctly interpret the 96 contents of the FA Error Extension MUST NOT use the care-of 97 address provided in the Registration Reply message, until another 98 Registration Request message has been sent and a successful 99 Registration Reply message received. 101 The status codes allowable for use within the FA Error Extension are 102 as follows: 104 64 reason unspecified 105 65 administratively prohibited 106 66 insufficient resources 107 68 home agent failed authentication 108 71 poorly formed Reply 109 77 invalid care-of address 110 78 registration timeout 112 as defined in RFC 3344 [2] for use by the Foreign Agent. Status 113 codes for use with the FA Error extensions must not be differently 114 defined for use in the Code field of Registration Reply messages. 116 When a foreign agent appends a FA Error Extension to the Registration 117 Reply as received from the Home Agent, it has to update the UDP 118 Length field in the UDP header [3] to account for the extra 4 bytes 119 of length. 121 5. IANA Considerations 123 This specification reserves one number for the FA Error extension 124 (see section 3) from the space of numbers for nonskippable mobility 125 extensions (i.e., 0-127) defined in the specification for Mobile 126 IPv4 [2]. 128 This specification also creates a new number space of sub-types for 129 the type number of this extension. Sub-type zero is to be allocated 130 from this number space for the protocol extension specified in this 131 document. Future allocations from this number space require IETF 132 consensus. 134 6. Security Considerations 136 The extension in this document improves the security features 137 of Mobile IPv4 by allowing the mobile node to be assured of the 138 authenticity of the information supplied within a Registration 139 Request. Previously, whenever the foreign agent was required to 140 provide status information to the mobile node, it could only do so 141 by destroying the ability of the mobile device to authenticated the 142 Mobile-Home Authentication Extension data. 144 References 146 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 147 Levels. Request for Comments (Best Current Practice) 2119, 148 Internet Engineering Task Force, March 1997. 150 [2] C. Perkins. IP Mobility Support. Request for Comments (Proposed 151 Standard) 3344, Internet Engineering Task Force, August 2002. 153 [3] J. Postel. User Datagram Protocol. Request for Comments 154 (Standard) 768, Internet Engineering Task Force, August 1980. 156 Author Address 158 Questions about this memo can be directed to the author: 160 Charles E. Perkins 161 Communications Systems Lab 162 Nokia Research Center 163 313 Fairchild Drive 165 Mountain View, California 94043 166 USA 167 Phone: +1-650 625-2986 168 Fax: +1 650 625-2502 169 EMail: charles.perkins@.nokia.com