idnits 2.17.1 draft-ietf-mobileip-mn-nai-06.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 an Authors' Addresses Section. ** 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 63: '...de NAI extension MAY set the Home Addr...' RFC 2119 keyword, line 71: '...ld of the option MUST not be zero. Ho...' RFC 2119 keyword, line 86: '...Request, the Home Address field MAY be...' RFC 2119 keyword, line 87: '... Node NAI extension MUST appear in the...' RFC 2119 keyword, line 108: '... agent MUST use the NAI instead in i...' (7 more instances...) -- The abstract seems to indicate that this document updates RFC2290, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [3], but that reference does not seem to mention RFC 2119 either. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The "Mobile-IPv4 Configuration" option to IPCP has been specified in RFC 2290 [9] for proper interaction between a mobile node and a peer, through which the mobile node connects to the network using PPP. According to that specification the Mobile Node's Home Address field of the option MUST not be zero. However, in the context of this draft which allows a mobile node to be identified by its NAI and to obtain an address after the PPP phase of connection establishment, the Home Address field is allowed to be zero while maintaining all other aspects of RFC 2290. Interpretation of various scenarios from RFC 2290 is given in section 4. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 2486 (ref. '1') (Obsoleted by RFC 4282) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-14 == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-08 ** Obsolete normative reference: RFC 2344 (ref. '5') (Obsoleted by RFC 3024) ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '6') ** Obsolete normative reference: RFC 2002 (ref. '7') (Obsoleted by RFC 3220) == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-08 -- Possible downref: Normative reference to a draft: ref. '8' ** Obsolete normative reference: RFC 2462 (ref. '10') (Obsoleted by RFC 4862) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Pat R. Calhoun 2 INTERNET DRAFT Sun Microsystems Laboratories 3 5 January 2000 Charles E. Perkins 4 Nokia Research Center 6 Mobile IP Network Access Identifier Extension for IPv4 7 draft-ietf-mobileip-mn-nai-06.txt 9 Status of This Memo 11 This document is a submission by the mobile-ip Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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 AAA servers are in use within the Internet today to provide 36 authentication and authorization services for dial-up computers. 37 Such services are likely to be equally valuable for mobile nodes 38 using Mobile IP when the nodes are attempting to connect to foreign 39 domains with AAA servers. AAA servers today identify clients by 40 using the Network Access Identifier (NAI). Our proposal defines a way 41 for the mobile node to identify itself, by including the NAI along 42 with the Mobile IP Registration Request. This draft also updates 43 RFC2290 which specifies the Mobile-IPv4 Configuration option for 44 IPCP, by allowing the Mobile Node's Home Address field of this option 45 to be zero. 47 1. Introduction 49 AAA servers are in use within the Internet today to provide 50 authentication and authorization services for dial-up computers. 51 Such services are likely to be equally valuable for mobile nodes 52 using Mobile IP when the nodes are attempting to connect to foreign 53 domains with AAA servers. AAA servers today identify clients 54 by using the Network Access Identifier (NAI) [1]. This document 55 specifies the Mobile Node NAI extension to the Mobile IP Registration 56 Request [7] message from the mobile node. 58 Since the NAI is typically used to uniquely identify the mobile 59 node, the mobile node's home address is not always necessary to 60 provide that function. Thus, it is possible for a mobile node to 61 authenticate itself, and be authorized for connection to the foreign 62 domain, without even having a home address. A message containing 63 the Mobile Node NAI extension MAY set the Home Address field to zero 64 (0) in the Registration Request, to request that a home address be 65 assigned. 67 The "Mobile-IPv4 Configuration" option to IPCP has been specified 68 in RFC 2290 [9] for proper interaction between a mobile node and a 69 peer, through which the mobile node connects to the network using 70 PPP. According to that specification the Mobile Node's Home Address 71 field of the option MUST not be zero. However, in the context of 72 this draft which allows a mobile node to be identified by its NAI and 73 to obtain an address after the PPP phase of connection establishment, 74 the Home Address field is allowed to be zero while maintaining all 75 other aspects of RFC 2290. Interpretation of various scenarios from 76 RFC 2290 is given in section 4. 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [3]. 82 2. Mobile Node NAI Extension 84 The Mobile Node NAI extension, shown in figure 1, contains the user 85 and/or host name following the format defined in [1]. When it is 86 present in the Registration Request, the Home Address field MAY be 87 set to zero (0). The Mobile Node NAI extension MUST appear in the 88 Registration Request before both the Mobile-Home Authentication 89 extension and Mobile-Foreign Authentication extension, if present. 91 0 1 2 3 92 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 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | Type | Length | MN-NAI ... 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 Figure 1: The Mobile Node NAI Extension 99 Type 131 (skippable) [7] 101 Length The length in bytes of the MN-NAI field 103 MN-NAI A string in the NAI format defined in [1]. 105 3. Foreign Agent Considerations 107 If Home Address is zero in the Registration Request, the foreign 108 agent MUST use the NAI instead in its pending registration request 109 records, along with the Identification field as usual. If the 110 foreign agent cannot manage pending registration request records in 111 this way, it MUST return a Registration Reply with Code indicating 112 NONZERO_HOMEADDR_REQD (see section 5). 114 If the mobile node includes the Mobile Node NAI extension in its 115 Registration Request, then the Registration Reply from the home 116 agent MUST include the Mobile Node NAI extension. If not, the 117 foreign agent SHOULD send the Registration Reply to the mobile node, 118 changing the Code to the value MISSING_NAI (see section 5). The 119 Registration Reply MUST include a nonzero Home Agent address and 120 mobile node's Home Address. If not, the foreign agent SHOULD send 121 the Registration Reply to the mobile node, changing the Code to the 122 value MISSING_HOME_AGENT or MISSING_HOMEADDR, respectively (see 123 section 5). 125 4. Interactions with Mobile-IPv4 Configuration Option to IPCP 127 In the Mobile-IPv4 Configuration Option to IPCP [9], the Mobile 128 Node's Home Address field may be zero. In this section, we specify 129 the action to be taken in that case, when the mobile node is using 130 the Mobile Node NAI extension in the Mobile IP Registration Request. 131 Whether or not the IP Address Configuration Option contains a nonzero 132 IP address, the mobile node will subsequently attempt to obtain a 133 home address from the Mobile IP Registration Reply. 135 If the IP Address Configuration Option to IPCP has IP address equal 136 to zero, the PPP peer is expected to allocate and assign a co-located 137 care-of address to the Mobile Node. If, on the other hand, the IP 138 Address Configuration Option to IPCP has a nonzero IP address, the 139 PPP peer is expected to assign that address to the Mobile Node as its 140 co-located care-of address. 142 5. Error Values 144 Each entry in the following table contains the name and value for the 145 Code [7] to be returned in a Registration Reply, and the section in 146 which the error Code is first mentioned in this specification. 148 Error Name Value Section of Document 149 ---------------------- ----- ------------------- 150 NONZERO_HOMEADDR_REQD 96 3 151 MISSING_NAI 97 3 152 MISSING_HOME_AGENT 98 3 153 MISSING_HOMEADDR 99 3 155 6. IANA Considerations 157 The number for the Mobile Node NAI extension is taken from the 158 numbering space defined for Mobile IP registration extensions defined 159 in RFC 2002 [7] as extended in RFC 2356 [6]. The numbering for 160 the extension also SHOULD NOT conflict with values specified in 161 the Internet Draft for Route Optimization [8]. The Code values 162 specified for errors, listed in section 5, MUST NOT conflict with any 163 other code values listed in RFC 2002, RFC 2344 [5], or RFC 2356 [6]. 164 They are to be taken from the space of error values conventionally 165 associated with rejection by the foreign agent (i.e., 64-127). 167 7. Security Considerations 169 Mobile IP registration messages are authenticated, and the 170 authentication verified by the recipient. This proposal does not 171 prohibit the mobile node from sending its NAI in the clear over the 172 network, but that is not expected to be a security issue. 174 8. IPv6 Considerations 176 Supporting NAI-based registrations for Mobile IPv6 [4] is outside 177 the scope of this document. This section contains some ideas how 178 Stateless Address Autoconfiguration [10] and DHCPv6 [2] might be 179 extended to support NAI-based Mobile IPv6 registrations. 181 For mobile nodes using IPv6, there are no commonly deployed 182 mechanisms by which a mobile node may present its credentials, such 183 as exist today with IPv4. Nevertheless, a mobile node using IPv6 184 mobility may wish to specify the domain in which their credentials 185 may be checked, by using a NAI just as this specification proposes 186 for IPv4. In the case of IPv6, however, there is no foreign agent 187 in place to manage the connectivity of the mobile node, and thus to 188 manage the verification of the credentials offered by the mobile 189 node. To identify the HDAF (see appendix A) that has the expected 190 relationship with the mobile node, the NAI would have to be forwarded 191 to a local AAA by the local agent involved with configuring the 192 care-of address of the mobile node. 194 This agent can either be a router sending out Router 195 Advertisements [10], or a DHCPv6 server. In the former case, 196 the router could signal its ability to handle the NAI by attaching 197 some yet to be defined option to the Router Advertisement. In the 198 latter case, for managed links, the mobile node could include a 199 yet to be defined NAI extension in its DHCP Solicitation message. 200 Such an NAI extension and appropriate authentication would also 201 be required on the subsequent DHCP Request sent by the mobile 202 node to the DHCP Server selected on the basis of received DHCP 203 Advertisements. Once a care-of address on the foreign network has 204 been obtained, the mobile node can use regular MIPv6 [4]. 206 9. Acknowledgements 208 The authors would like to thank Gabriel Montenegro and Vipul 209 Gupta for their useful discussions. Thanks to Basaravaj Patil and 210 Pete McCann for text describing actions to be taken when the home 211 address is zero but the mobile node wishes to use the Mobile-IPv4 212 Configuration Option to IPCP defined in RFC 2290. 214 References 216 [1] B. Aboba and M. Beadles. The Network Access Identifier. 217 Request for Comments (Proposed Standard) 2486, Internet 218 Engineering Task Force, January 1999. 220 [2] J. Bound and C. Perkins. Dynamic Host Configuration Protocol 221 for IPv6 (DHCPv6). Internet Draft, Internet Engineering Task 222 Force. 223 draft-ietf-dhc-dhcpv6-14.txt, February 1999. Work in progress. 225 [3] S. Bradner. Key words for use in RFCs to Indicate Requirement 226 Levels. Request for Comments (Best Current Practice) 2119, 227 Internet Engineering Task Force, March 1997. 229 [4] D. Johnson and C. Perkins. Mobility Support in IPv6. 230 draft-ietf-mobileip-ipv6-08.txt, June 1999. (work in progress). 232 [5] G. Montenegro. Reverse Tunneling for Mobile IP. Request for 233 Comments (Proposed Standard) 2344, Internet Engineering Task 234 Force, May 1998. 236 [6] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 237 Mobile IP. Request for Comments (Informational) 2356, Internet 238 Engineering Task Force, June 1998. 240 [7] C. Perkins. IP Mobility Support. Request for Comments 241 (Proposed Standard) 2002, Internet Engineering Task Force, 242 October 1996. 244 [8] C. Perkins and D. Johnson. Route Optimization in Mobile IP. 245 Internet Draft, Internet Engineering Task Force. 246 draft-ietf-mobileip-optim-08.txt, February 1999. Work in 247 progress. 249 [9] J. Solomon and S. Glass. Mobile-IPv4 Configuration Option 250 for PPP IPCP. Request for Comments (Proposed Standard) 2290, 251 Internet Engineering Task Force, February 1998. 253 [10] S. Thomson and T. Narten. IPv6 Stateless Address 254 Autoconfiguration. Request for Comments (Draft Standard) 2462, 255 Internet Engineering Task Force, December 1998. 257 A. Home Domain Allocation Function (HDAF) 259 This appendix introduces a new function named the Home Domain 260 Allocation Function (HDAF) that can dynamically assign a Home Address 261 to the mobile node. 263 Figure 2 illustrates the Home HDAF, which receives messages from 264 foreign agents (e.g., FA) and assigns a Home Address within the Home 265 Domain. The HDAF does not perform any Mobile IP processing on the 266 Registration Request, but simply forwards the request to a Home Agent 267 (HA) within the network that is able to handle the request. 269 +------+ 270 | | 271 +---+ HA-1 | 272 +------+ +------+ +------+ | | | 273 | | | | | | | +------+ 274 | MN |-------| FA |-------| HDAF +---+ ... 275 | | | | | | | +------+ 276 +------+ +------+ +------+ | | | 277 +---+ HA-n | 278 | | 279 +------+ 281 Figure 2: Home Domain Allocator Function (HDAF) 283 Upon receipt of the Registration Request from the mobile node (MN), 284 FA extracts the NAI and finds the domain name associated with it. 285 FA then finds the HDAF that handles requests for the mobile node's 286 domain. The discovery protocol is outside of the scope of this 287 specification. As an example, however, FA might delegate the duty of 288 finding a HDAF to a local AAA server. The local AAA server may also 289 assist FA in the process of verifying the credentials of the mobile 290 node, using protocols not specified in this document. 292 Addresses 294 The working group can be contacted via the current chairs: 296 Basavaraj Patil Phil Roberts 297 Nortel Networks Inc. Motorola 298 2201 Lakeside Blvd. 1501 West Shure Drive 299 Richardson, TX. 75082-4399 Arlington Heights, IL 60004 300 USA USA 302 Phone: +1 972-684-1489 Phone: +1 847-632-3148 303 EMail: bpatil@nortelnetworks.com EMail: QA3445@email.mot.com 305 Questions about this memo can be directed to: 307 Charles E. Perkins Pat R. Calhoun 308 Nokia Research Center Sun Microsystems Laboratories 309 313 Fairchild Drive 15 Network Circle 310 Mountain View, California 94043 Menlo Park, California 94025 311 USA USA 313 Phone: +1-650 625-2986 Phone: +1 650-786-7733 314 EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com 315 Fax: +1 650 625-2502 Fax: +1 650-786-6445