idnits 2.17.1 draft-ietf-mobileip-mn-nai-02.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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 61: '...de NAI extension MAY have the Home Add...' RFC 2119 keyword, line 68: '...Request, the Home Address field MAY be...' RFC 2119 keyword, line 69: '... Node NAI extension MUST appear in the...' RFC 2119 keyword, line 90: '... agent MUST use the NAI instead in i...' RFC 2119 keyword, line 93: '... this way, it MUST return a Registra...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (-18) exists of draft-calhoun-diameter-07 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-07 ** Obsolete normative reference: RFC 2344 (ref. '5') (Obsoleted by RFC 3024) ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '6') == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-07 -- Possible downref: Normative reference to a draft: ref. '7' ** Obsolete normative reference: RFC 2002 (ref. '8') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2138 (ref. '9') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 1971 (ref. '10') (Obsoleted by RFC 2462) Summary: 12 errors (**), 0 flaws (~~), 6 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 25 May 1999 Charles E. Perkins 4 Sun Microsystems Laboratories 6 Mobile IP Network Access Identifier Extension 7 draft-ietf-mobileip-mn-nai-02.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 31 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 Abstract 36 AAA servers, such as RADIUS and DIAMETER, are in use within the 37 Internet today to provide authentication and authorization services 38 for dial-up computers. Such services are likely to be equally 39 valuable for mobile nodes using Mobile IP when the nodes are 40 attempting to connect to foreign domains with AAA servers. AAA 41 servers today identify clients by using the Network Access Identifier 42 (NAI). Our proposal defines a way for the mobile node to include the 43 NAI along with the Mobile IP Registration Request. 45 1. Introduction 47 AAA servers, such as RADIUS [9] and DIAMETER [3], are in use within 48 the Internet today to provide authentication and authorization 49 services for dial-up computers. Such services are likely to be 50 equally valuable for mobile nodes using Mobile IP when the nodes 51 are attempting to connect to foreign domains with AAA servers. AAA 52 servers today identify clients by using the Network Access Identifier 53 (NAI) [1]. This document specifies the Mobile Node NAI extension to 54 the Mobile IP Registration Request [8] message from the mobile node. 56 Since the NAI is typically used to uniquely identify the mobile 57 node, the mobile node's home address is not always necessary to 58 provide that function. Thus, it is possible for a mobile node to 59 authenticate itself, and be authorized for connection to the foreign 60 domain, without even having a home address. A message containing 61 the Mobile Node NAI extension MAY have the Home Address field in the 62 Registration Request set to zero (0) to request that one be assigned. 64 2. Mobile Node NAI Extension 66 The Mobile Node NAI extension, shown in figure 1, contains the user 67 and/or host name following the format defined in [1]. When it is 68 present in the Registration Request, the Home Address field MAY be 69 set to zero (0). The Mobile Node NAI extension MUST appear in the 70 Registration Request before both the Mobile-Home Authentication 71 extension and Mobile-Foreign Authentication extension, if present. 73 0 1 2 3 74 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 75 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 76 | Type | Length | MN-NAI ... 77 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 79 Figure 1: The Mobile Node NAI Extension 81 Type 131 (skippable) [8] 83 Length The length in bytes of the MN-NAI field 85 MN-NAI A string in the NAI format defined in [1]. 87 3. Foreign Agent Considerations 89 If Home Address is zero in the Registration Request, the foreign 90 agent MUST use the NAI instead in its pending registration request 91 records, along with the Identification field as usual. If the 92 foreign agent cannot manage pending registration request records in 93 this way, it MUST return a Registration Reply with Code indicating 94 UNIQUE_HOMEADDR_REQD (see section 4). 96 If the mobile node includes the Mobile Node NAI extension in its 97 Registration Request, then the Registration Reply from the home 98 agent MUST include the Mobile Node NAI extension. If not, the 99 foreign agent SHOULD send the Registration Reply to the mobile node, 100 changing the Code to the value MISSING_NAI (see section 4). The 101 Registration Reply MUST include a nonzero Home Agent address and 102 mobile node's Home Address. If not, the foreign agent SHOULD send 103 the Registration Reply to the mobile node, changing the Code to the 104 value MISSING_HOME_AGENT or MISSING_HOMEADDR, respectively (see 105 section 4). 107 4. Error Values 109 Each entry in the following table contains the name of Code [8] to 110 be returned in a Registration Reply, the value for the Code, and the 111 section in which the error is first mentioned in this specification. 113 Error Name Value Section 114 ---------------------- ----- --------- 115 UNIQUE_HOMEADDR_REQD 96 3 116 MISSING_NAI 97 3 117 MISSING_HOME_AGENT 98 3 118 MISSING_HOMEADDR 99 3 120 5. IANA Considerations 122 The number for the Mobile Node NAI extension is taken from the 123 numbering space defined for Mobile IP registration extensions defined 124 in RFC 2002 [8] as extended in RFC 2356 [6]. The numbering for 125 the extension also SHOULD NOT conflict with values specified in 126 the Internet Draft for Route Optimization [7]. The Code values 127 specified for errors, listed in section 4, MUST NOT conflict with any 128 other code values listed in RFC 2002, RFC 2344 [5], or RFC 2356 [6]. 129 They are to be taken from the space of error values conventionally 130 associated with rejection by the foreign agent (i.e., 64-127). 132 6. Security Considerations 134 Mobile IP registration messages are authenticated, and the 135 authentication verified by the recipient. This proposal does not 136 prohibit the mobile node from sending its NAI in the clear over the 137 network, but that is not expected to be a security issue. 139 7. IPv6 Considerations 141 Supporting NAI-based registrations for Mobile IPv6 [4] is outside 142 the scope of this document. This section contains some ideas how 143 Stateless Address Autoconfiguration [10] and DHCPv6 [2] might be 144 extended to support NAI-based Mobile IPv6 registrations. 146 For mobile nodes using IPv6, there are no commonly deployed 147 mechanisms by which a mobile node may present its credentials, such 148 as exist today with IPv4. Nevertheless, a mobile node using IPv6 149 mobility may wish to specify the domain in which their credentials 150 may be checked, by using a NAI just as this specification proposes 151 for IPv4. In the case of IPv6, however, there is no foreign agent 152 in place to manage the connectivity of the mobile node, and thus to 153 manage the verification of the credentials offered by the mobile 154 node. To identify the HDAF (see appendix A) that has the expected 155 relationship with the mobile node, the NAI would have to be forwarded 156 to a local AAA by the local agent involved with configuring the 157 care-of address of the mobile node. 159 This agent can either be a router sending out Router 160 Advertisements [10], or a DHCPv6 server. In the former case, 161 the router could signal its ability to handle the NAI by attaching 162 some yet to be defined option to the Router Advertisement. In the 163 latter case, for managed links, the mobile node could include a 164 yet to be defined NAI extension in its DHCP Solicitation message. 165 Such an NAI extension and appropriate authentication would also 166 be required on the subsequent DHCP Request sent by the mobile 167 node to the DHCP Server selected on the basis of received DHCP 168 Advertisements. Once a care-of address on the foreign network has 169 been obtained, the mobile node can use regular MIPv6. 171 8. Acknowledgements 173 The authors would like to thank Gabriel Montenegro and Vipul Gupta 174 for their useful discussions. 176 References 178 [1] B. Aboba and M. Beadles. RFC 2486: The Network Access 179 Identifier, January 1999. Status: PROPOSED STANDARD. 181 [2] J. Bound and C. Perkins. Dynamic Host Configuration Protocol 182 for IPv6. draft-ietf-dhc-dhcpv6-14.txt, February 1999. (work 183 in progress). 185 [3] P. Calhoun and A. Rubens. DIAMETER Base Protocol. 186 draft-calhoun-diameter-07.txt, November 1998. (work in 187 progress). 189 [4] D. Johnson and C. Perkins. Mobility Support in IPv6. 190 draft-ietf-mobileip-ipv6-07.txt, November 1998. (work in 191 progress). 193 [5] G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, May 194 1998. 196 [6] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 197 Mobile IP. RFC 2356, June 1998. 199 [7] Charles E. Perkins and David B. Johnson. Route Optimization in 200 Mobile-IP. draft-ietf-mobileip-optim-07.txt, November 1997. 201 (work in progress). 203 [8] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 204 1996. 206 [9] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 207 Authentication Dial In User Service (RADIUS). RFC 2138, April 208 1997. 210 [10] S. Thomson and T. Narten. RFC 2462: IPv6 stateless address 211 autoconfiguration, December 1998. Obsoletes RFC1971. Status: 212 DRAFT STANDARD. 214 A. Home Domain Allocation Function (HDAF) 216 This appendix introduces a new function named the Home Domain 217 Allocation Function (HDAF) that can dynamically assign a Home Address 218 to the mobile node. 220 Figure 2 illustrates the Home HDAF, which receives messages from 221 foreign agents (e.g., FA) and assigns a Home Address within the Home 222 Domain. The HDAF does not perform any Mobile IP processing on the 223 Registration Request, but simply forwards the request to a Home Agent 224 (HA) within the network that is able to handle the request. 226 +------+ 227 | | 228 +---+ HA-1 | 229 +------+ +------+ +------+ | | | 230 | | | | | | | +------+ 231 | MN |-------| FA |-------| HDAF +---+ ... 232 | | | | | | | +------+ 233 +------+ +------+ +------+ | | | 234 +---+ HA-n | 235 | | 236 +------+ 238 Figure 2: Home Domain Allocator Function (HDAF) 240 Upon receipt of the Registration Request from the mobile node (MN), 241 FA extracts the NAI and finds the domain name associated with it. 242 FA then finds the HDAF that handles requests for the mobile node's 243 domain. The discovery protocol is outside of the scope of this 244 specification. As an example, however, FA might delegate the duty of 245 finding a HDAF to a local AAA server. The local AAA server may also 246 assist FA in the process of verifying the credentials of the mobile 247 node, using protocols not specified in this document. 249 Addresses 251 The working group can be contacted via the current chairs: 253 Erik Nordmark Basavaraj Patil 254 Sun Microsystems, Inc. Nortel Networks Inc. 255 17 Network Circle 2201 Lakeside Blvd. 256 Menlo Park, California 94025 Richardson, TX. 75082-4399 257 USA USA 259 Phone: +1 650 786-5166 +1 972-684-1489 260 Fax: +1 650 786-5896 261 E-mail: nordmark@sun.com bpatil@nortelnetworks.com 263 Questions about this memo can be directed to: 265 Charles E. Perkins Pat R. Calhoun 266 Sun Microsystems Laboratories Sun Microsystems Laboratories 267 15 Network Circle 15 Network Circle 268 Menlo Park, California 94025 Menlo Park, California 94025 269 USA USA 271 Phone: +1-650 786-6464 Phone: +1 650-786-7733 272 EMail: cperkins@eng.sun.com EMail: pcalhoun@eng.sun.com 273 Fax: +1 650 786-6445