idnits 2.17.1 draft-ietf-mobileip-home-addr-alloc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 301 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 66: '... includes the Network Access identifier (NAI) [4] MAY have the Home...' RFC 2119 keyword, line 68: '...ned. The message MAY also have the Hom...' RFC 2119 keyword, line 109: '...m the Home Agent MUST include the Mobi...' RFC 2119 keyword, line 127: '... Mobile Node, it MAY use the NAI in th...' 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.) -- The document date (November 1998) is 9291 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) == Unused Reference: '1' is defined on line 157, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 161, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 164, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 170, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2002 (ref. '2') (Obsoleted by RFC 3220) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-07 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-01 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-01 -- Possible downref: Normative reference to a draft: ref. '6' Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Pat R. Calhoun 2 Category: Standards Track Charles E. Perkins 3 Title: draft-ietf-mobileip-home-addr-alloc-00.txt Sun Laboratories, Inc. 4 Date: November 1998 6 Mobile IP Dynamic Home Address Allocation Extensions 8 Status of this Memo 10 This document is a submission by the Mobile IP Working Group of the 11 Internet Engineering Task Force (IETF). Comments should be submitted 12 to the mobile-ip@smallworks.com mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To view the entire list of current Internet-Drafts, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 29 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 30 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 32 Abstract 34 RFC2002 defines a method for a Mobile Node to be assigned a Home 35 Agent dynamically through the use of a limited broadcast message. 36 However, most corporate networks do not allow such packets to 37 traverse through their firewall, which renders this feature difficult 38 to use. This draft introduces new entity named the Home Domain 39 Allocation Agency (HDAA) that can dynamically assign a Home Address 40 to the Mobile Node. This draft also proposes a method for the HDAA to 41 assign a dynamic Home Agent to the Mobile Node. 43 Table of Contents 45 1.0 Introduction 46 2.0 Mobile IP Registration Extensions 47 2.1 Mobile-Node-NAI Extension 48 3.0 Security Analysis 49 4.0 References 50 5.0 Acknowledgements 51 6.0 Chairs' Addresses 52 7.0 Author's Address 54 1.0 Introduction 56 RFC2002 defines a method for a Mobile Node to be assigned a Home 57 Agent dynamically through the use of a limited broadcast message. 58 However, most corporate networks do not allow such packets to 59 traverse their firewall. The use of the limited broadcast ensured 60 that the Home Agent assigned to the Mobile Node resided on a specific 61 subnet, therefore it was not necessary to assign a dynamic IP Address 62 to the Mobile Node. 64 This draft introduces the Mobile-Node-NAI extension to the 65 Registration Request message from a Mobile Node. A message that 66 includes the Network Access identifier (NAI) [4] MAY have the Home 67 Address field in the Registration Request set to zero (0) to request 68 that one be assigned. The message MAY also have the Home Agent field 69 set to either zero (0) or -1 to request that one be dynamically 70 assigned. The Home Agent field set to 0.0.0.0 indicates that the 71 Mobile Node wishes to have a Home Agent assigned either within the 72 foreign or the home domain. A Home Agent field set to 255.255.255.255 73 indicates that the Mobile Node wishes to have a Home Agent assigned 74 only within its home domain. Upon receipt of this message, the 75 Foreign Agent must forward the request to the HDAA, which is able to 76 assign the Home Address. The domain portion of the NAI is used to 77 identify the Mobile Node's Home Domain, and thus to identify where 78 the Registration Request should be forwarded. The DIAMETER Mobile IP 79 extension [6] defines a method of resolving the Home Address 80 allocator, but this document will refer to a generic method for full 81 generality. 83 In the following figure, we introduce the Home Domain Allocation 84 Agency (HDAA), which assigns a Home Address, and possibly a Home 85 Agent, within the Home Domain. The HDAA does not perform any 86 processing on the Registration Request, but simply forwards the 87 request along with the newly allocated IP address to a Home Agent 88 within the network that is able to handle the request. 90 +------+ 91 | | 92 +---+ HA-1 | 93 +------+ +------+ +------+ | | | 94 | | | | | | | +------+ 95 | MN |-------| FA |-------| HDAA +---+ ... 96 | | | | | | | +------+ 97 +------+ +------+ +------+ | | | 98 +---+ HA-n | 99 | | 100 +------+ 102 Upon receipt of the Registration Request, the Foreign Agent extracts 103 the Mobile Node's NAI and finds the domain name associated with it. 104 The Foreign Agentor its proxy, then finds the HDAA that handles 105 requests for the Mobile Node's domain. The selection of HDAAis 106 outside of the scope of this specification, but is typically set up 107 by service agreements between the foreign and the home domain. 109 The Registration Reply from the Home Agent MUST include the Mobile- 110 Node-NAI for identification at the Foreign Agent. The reply would 111 also include any assigned Home Agent or Home Address. 113 2.0 Mobile IP Registration Extensions 115 This section will define new Mobile IP Registration Extensions that 116 must be used in order to use the functionality described in this 117 document. 119 2.1 Mobile-Node-NAI Extension 121 The Mobile-Node-NAI Extension contains the user or host name 122 following the format defined in [4]. This extension is used to 123 identify a user or host's and can be used to find a Home Agent within 124 the requestor's home network. 126 Since the foreign agent may not be able to use the Home Address in 127 the reply to identify the Mobile Node, it MAY use the NAI in this 128 extension instead. 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Type | Length | MN-NAI.. 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Type 138 TDB 140 Length 142 Must be at least 3 144 Mobile-Node-NAI 146 Contains the username or host name in the format defined in [4]. 148 3.0 Security Considerations 150 This document assumes that the Mobile IP messages are authenticated 151 using a method defined by the Mobile IP protocol. This proposal does 152 require that the Mobile Node's NAI be sent in the clear over the 153 network and may be a security issue. 155 4.0 References 157 [1] P. Calhoun, G. Montenegro, C. Perkins, "Tunnel Establishment 158 Protocol", draft-ietf-mobileip-calhoun-tep-01.txt, 159 Work in Progress, March 1998. 161 [2] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 162 1996. 164 [3] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol", 165 draft-calhoun-diameter-07.txt, Work in Progress, November 1998. 167 [4] B. Aboba. "The Network Access Identifier." Internet-Draft, 168 Work in Progress, August 1997. 170 [5] P. Calhoun, G. Zorn, P. Pan, "DIAMETER Framework", 171 draft-calhoun-diameter-framework-01.txt, Work in Progress, 172 August 1998. 174 [6] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extension", 175 draft-calhoun-diameter-mobileip-01.txt, Work in Progress, 176 November 1998. 178 5.0 Acknowledgements 180 The author would like to thanks Gabriel Montenegro and Vipul Gupta for 181 their useful discussions. 183 6.0 Chairs' Addresses 185 The working group can be contacted via the current chairs: 187 Jim Solomon 188 RedBack Networks 189 1389 Moffett Park Drive 190 Sunnyvale, CA 94089-1134 191 USA 193 Phone: +1 408 548-3583 194 Fax: +1 408 548-3599 195 E-mail: solomon@rback.com 197 Erik Nordmark 198 Sun Microsystems, Inc. 199 901 San Antonio Road 200 Mailstop UMPK17-202 201 Mountain View, California 94303 203 Phone: +1 650 786-5166 204 Fax: +1 650 786-5896 205 E-Mail: erik.nordmark@eng.sun.com 207 7.0 Author's Address 209 Questions about this memo can be directed to: 211 Pat R. Calhoun 212 Technology Development 213 Sun Microsystems, Inc. 214 15 Network Circle 215 Menlo Park, California, 94025 216 USA 218 Phone: 1-650-786-7733 219 Fax: 1-650-786-6445 220 E-mail: pat.calhoun@eng.sun.com 222 Charles E. Perkins 223 Technology Development 224 Sun Microsystems, Inc. 225 15 Network Circle 226 Menlo Park, California, 94025 227 USA 229 Phone: 1-650-786-6464 230 Fax: 1-650-786-6445 231 E-mail: charles.perkins@eng.sun.com