idnits 2.17.1 draft-aravamudhan-mobileip-nai-wn-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 21 has weird spacing: '... It is inapp...' == Line 232 has weird spacing: '...rks.com ema...' -- 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) == Unused Reference: '3' is defined on line 219, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2486 (ref. '1') (Obsoleted by RFC 4282) -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Lachu Aravamudhan 2 INTERNET-DRAFT Mark R. O'Brien 3 Basavaraj Patil 4 Date: October, 1999 Nortel Networks 5 Expires: April, 2000 7 NAI Resolution for Wireless Networks 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 RFC 2486 [1] defines the need of a standardized format for 34 identifying ISP subscribers for dial-up roaming operations. It 35 introduced the Network Access Identifier (NAI) to fulfill this 36 need. The NAI is provided by the mobile node to the dialed ISP 37 during PPP authentication. 39 The ability to resolve an NAI for second and third generation 40 cellular mobile nodes allow traditional cellular service providers 41 to evolve their home cellular networks to provide cellular 42 services, IP packet data services and so on with a single 43 subscription using NAIs. Additionally, this allows cellular 44 provider to evolve their networks to be IP based. 46 Second and third generation cellular mobile nodes must perform a 47 registration and authentication process with their wireless service 48 provider before the mobile node user may initiate other operations 49 (See [1] for examples). These mobile nodes do not support the 50 programming of an NAI nor does the cellular registration message 51 support the transfer of an NAI to the wireless access network. For 52 example, North American cellular networks (e.g. AMPS, TDMA, CDMA) 53 service mobiler nodes that register with a Mobile Identification 54 Number (MIN). The MIN is then associated with a cellular 55 subscriber. MIN is shown here only as an example, the same general 56 idea is applicable to other types of identifiers used in different 57 access network types. For the same reasons stated in [1], it would 58 be convenient if an option was available to provide the wireless 59 subscriber identification in the form of an NAI during the wireless 60 registration and authentication process. This draft proposes a 61 solution to resolve NAIs from traditional mobile node identifiers. 63 1. Introduction 65 RFC 2486 [1] defines the need of a standardized format for 66 identifying ISP subscribers for dial-up roaming operations. It 67 introduced the Network Access Identifier (NAI) which is of the form 68 user@realm to fulfill this need. The NAI is provided by the mobile 69 node to the dialed ISP during PPP authentication. 71 The ability to resolve an NAI for second and third generation 72 cellular mobile nodes allow traditional cellular service providers 73 to evolve their home cellular networks to provide cellular 74 services, IP packet data services and so on with a single 75 subscription using NAIs. Additionally, this allows cellular 76 providers to evolve their networks to be IP based. 78 Second and third generation cellular mobile nodes must perform a 79 registration and authentication process with their wireless service 80 provider before the mobile node user may initiate other operations 81 (See [1] for examples). These mobile nodes do not support the 82 programming of an NAI nor does the cellular registration message 83 support the transfer of an NAI to the wireless access network. For 84 example, North American cellular networks (e.g. AMPS, TDMA, CDMA) 85 service mobile nodes that register with a Mobile Identification 86 Number (MIN). The MIN is then associated with a cellular 87 subscriber. MIN is shown here only as an example, the same general 88 idea is applicable to other types of identifiers used in different 89 access network types. For the same reasons stated in [1], it would 90 be convenient if an option was available to provide the wireless 91 subscriber identification in the form of an NAI during the wireless 92 registration and authentication process. This draft proposes a 93 solution to resolve NAIs from traditional mobile node identifiers. 95 Consider the following scenario to illustrate the NAI resolution 96 required to register and authenticate wireless mobile nodes with 97 their wireless service provider: 99 NAI enabled Wireless Service Provider owns the cellular service for 100 Subscriber A (SUB A). 102 ------------ ------------ ---------------- 103 | SUB A | | | | | 104 | Cellular | | Wireless | | NAI Enabled | 105 | Mobile | | Access | | Wireless Home| 106 | Node | | Network | | Network | 107 ------------ ------------ ---------------- 109 | | | event 110 |)))))))))))))>| | a 111 | |-------------->| b 112 | |<--------------| c 113 |<(((((((((((((| | d 114 | | | 116 a SUB A powers-on his second or third generation cellular mobile 117 node. The act of powering on causes the cellular mobile mode 118 to attempt a wireless registration. The registration message 119 identifies the mobile node by its MIN. 121 b The wireless access network receives the wireless registration 122 message and from this message resolves an NAI based on the 123 MIN sent by the cellular mobile node. The wireless access 124 network sends an appropriate registration message to its NAI 125 enabled home network. 127 c The NAI enabled home network registers and authenticates 128 wireless SUB A and sends an appropriate registration response 129 back to the wireless access network. 131 d The wireless access network receives the registration response 132 from wireless SUB A's home network and sends an appropriate 133 wireless registration return result to SUB A`s cellular 134 mobile node. 136 2. Terminology 138 This document uses the following terminology: 140 MIN Mobile Identification Number: A 10-digit number 141 assigned to the mobile station. 143 3. Specification Language 145 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 147 this document are to be interpreted as described in RFC 2119 [2]. 149 4. NAI Resolution 151 There are many alternatives to resolve an NAI. This draft proposes 152 a method by which an NAI resolution function could be developed in 153 the wireless access network which can be used to map a wireless MNs 154 identification (MIN) to an NAI. 156 The NAI is of the form user@realm. At the wireless access provider, 157 using the wireless registration information, a temporary NAI may be 158 constructed of the form @realm. The IP address corresponding 159 to the realm may then be resolved through DNS or other appropriate 160 mechanisms. That resolution should return the IP address of the 161 realm (i.e. the Service Provider owning the subscriber's wireless 162 service). The temporary NAI, @realm, should then be supplied 163 in the registration message to the wireless service provider 164 identified by that IP address. The wireless service provider should 165 receive the registration message and may decode the "user" 166 component of the temporary NAI to lookup the subscriber's NAI if it 167 is, in fact, different from the temporary NAI. 169 For example, suppose a cellular mobile node sends a registration 170 message to the wireless access network with a MIN of 9726841000. A 171 table resident at wireless access network may be populated with a 172 range of MINs covered by each entry. In this example, each range 173 specifies only the most significant 6 digits and implicitly 174 includes all subscriber numbers (last 4 digits) within the range: 176 MIN RANGE REALM 177 214790 - 214799 abc_company.net 178 972680 - 972689 def_company.net 179 972700 - 972730 hij_company.net 180 In this case "def_company.net" is the ISP for the 9726841000 MIN. 181 The resulting temporary NAI to use for IP address resolution and 182 for routing of registration messages over the Internet would be: 183 9726841000@def_company.net. 185 Table lookups such as these have been widely used in cellular 186 networks since the subscriber/terminal identifiers are: numeric, a 187 maximum of 15 digits, and the leading digits typically defined a 188 geographical region to facilitate routing. Further, ranges of 189 subscriber/terminal identifications were assigned in blocks to 190 service providers in each regions. As shown in the table, 191 def_company.net is assigned all of the subscriber numbers from 192 exchanges 680 though 689 inclusive. This facilitated scalability by 193 alleviating access providers from a requirement of enumerating each 194 MIN in their tables. 196 NOTE: The interface from the wireless access network to the 197 wireless service provider network should use protocols 198 produced by the IETF and is outside of the scope of this 199 document. With the exception of the derivation of an NAI 200 from a MIN, the means by which a cellular registration or 201 authentication message is converted by the wireless 202 access network to the relevant IETF protocol message(s) 203 is outside the scope of this document. 205 5. Acknowledgments 207 The authors would like to thank Emad Qaddoura, Russ Coffin and 208 Rambabu Tummala of Nortel Networks for their review and valuable 209 input. 211 6. References 213 [1] Aboba B., Beadles M., "Network Access Identifier" RFC 2486, 214 January 1999. 216 [2] Bradner S., "Key words for use in RFCs to Indicate Requirement 217 Levels", RFC 2119, March 1997. 219 [3] TIA/TR45.6, PN-4286, "Wireless IP Network Architecture based 220 on IETF Protocols", June 1999 222 7. Authors' Addresses 224 Questions about this document can be directed to: 226 Lachu Aravamudhan Basavaraj Patil 227 Nortel Networks Inc. Nortel Networks Inc. 228 2201 Lakeside Blvd. 2201 Lakeside Blvd. 229 Richardson, TX. 75082-4399 Richardson, TX. 75082-4399 231 Phone: 972-684-4855 Phone: 972-684-1489 232 email: lachu@nortelnetworks.com email: bpatil@nortelnetworks.com 234 Mark O'Brien 235 Nortel Networks Inc. 236 2201 Lakeside Blvd. 237 Richardson, TX. 75082-4399 239 Phone: 972-684-5164 240 email: markob@nortelnetworks.com