idnits 2.17.1 draft-ietf-radius-mobileip-00.txt: ** The Abstract section seems to be numbered 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-26) 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 3 longer pages, the longest (page 2) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** There are 61 instances of too long lines in the document, the longest one being 3 characters 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 14: '...hat other groups MAY also distribute w...' RFC 2119 keyword, line 18: '... and MAY be updated, replaced, o...' RFC 2119 keyword, line 46: '...over a PPP link. It MAY be included in...' RFC 2119 keyword, line 71: '...he Address field MUST contain the valu...' RFC 2119 keyword, line 84: '... care-of-address MUST NOT be assigned....' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...), its areas...' == Line 14 has weird spacing: '... its worki...' == Line 19 has weird spacing: '...afts as refer...' == Line 29 has weird spacing: '... The distr...' == Line 30 has weird spacing: '...t>, and expir...' == (36 more instances...) -- 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 (21 April 1998) is 9502 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) -- Missing reference section? '2' on line 139 looks like a reference -- Missing reference section? '1' on line 137 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft 4 Category: Standards Track 5 6 21 April 1998 8 Support for Mobile IP in RADIUS 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups MAY also distribute work- 15 ing documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and MAY be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as ``work in progress.'' 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 The distribution of this memo is unlimited. It is filed as , and expires October 1, 1998. Please 31 send comments to the authors. 33 2. Abstract 35 RFC 2002 describes the framework for Mobile IP, while RFC 2290 36 describes how a mobile node and a peer negotiate the appropriate use 37 of Mobile IP over a PPP link, through use of the IPCP IP Address and 38 Mobile-IPv4 Configuration Options. This document describes how Mobile 39 IP is supported within RADIUS. 41 3. Mobile-IP-Configuration attribute definition 43 Description 45 This Attribute describes how a mobile node and NAS negotiate the 46 appropriate use of Mobile IP over a PPP link. It MAY be included in 47 Access-Accept or Accounting-Request packets. 49 A summary of the Mobile-IP-Configuration Attribute format is shown 50 below. The fields are transmitted from left to right. 52 0 1 2 3 53 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 2 54 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 55 | Type | Length | Address 56 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 57 | Address (cont) | 58 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 60 Type 62 ? for Mobile-IP-Configuration 64 Length 66 6 68 Address 70 The Address field is four octets. When included in an Access- 71 Accept, the Address field MUST contain the value 0xFFFFFFFF, indi- 72 cating that Mobile-IP is authorized. When included in an Account- 73 ing-Request, the Address field is set to the Home Address supplied 74 by the mobile node. 76 Discussion 78 The purpose of the Mobile-IP-Configuration attribute is to provide 79 the NAS with the information needed to negotiate the appropriate 80 use of Mobile IP over a PPP Link, as described in RFC 2290 [2]. 82 When a Mobile-IP-Configuration attribute is present, the absence of 83 a Framed-IP-Address attribute is interpreted as indicating that a 84 co-located care-of-address MUST NOT be assigned. If a Framed-IP- 85 Address attribute is included along with a Mobile-IP-Configuration 86 attribute, then a co-located care-of-address MAY be assigned by the 87 NAS. A co-located care-of-address may be assigned statically or 88 dynamically. 90 Since the mobile node may not always wish to do mobile IP, inclu- 91 sion of the Mobile-IP-configuration attribute does not imply that 92 the mobile node must use mobile IP. However, when the Mobile-IP- 93 Configuration attribute is omitted, use of Mobile IP is not autho- 94 rized, and MUST NOT be negotiated by the NAS. 96 If the mobile node prefers a co-located care-of-address, this will 97 typically be indicated during PPP IPCP negotiation by setting the 98 IP Address option to zero, and the Mobile-IPv4 Configuration option 99 to the Home Address. If a foreign agent care-of-address is pre- 100 ferred, this will typically be indicated during PPP IPCP negotia- 101 tion by sending only a Mobile-IPv4 Configuration option with the 102 Home Address. 104 As described in [2], if the NAS is not Mobile-IP capable or is not 105 authorized to negotiate Mobile IP (no Mobile-IP-Configuration 106 attribute), then it will respond with a Configure-Reject. If the 107 mobile node has requested a co-located care-of-address, and the NAS 108 can comply (Framed-IP-Address attribute included along with a 109 Mobile-IP-Configuration attribute), the NAS will typically reply 110 with a Configure-NAK including an IP Address Option set to the co- 111 located care-of-address or home address, depending on whether the 112 mobile node is attached via a foreign link or home link. 114 If the NAS only supports a foreign agent care-of-address (Mobile- 115 IP-Configuration attribute but no Framed-IP-Address attribute), it 116 will typically reply with a Configure-NAK including an IP Address 117 Option set to zero. If the mobile node has requested a foreign 118 agent care-of-address, and the NAS can negotiate Mobile-IP (Mobile- 119 IP-Configuration attribute included), then the NAS MUST reply with 120 a Mobile-IPv4 Configuration Option set to the Home Address indi- 121 cated by the mobile node. 123 As noted in [2], the NAS need not know the mobile node's Home 124 Address beforehand in order to decide how to reply. This informa- 125 tion is not useful because if the Home Address expected by the NAS 126 did not match that provided by the mobile node, there would be no 127 way to correct the problem, since a Configure-NAK is undefined for 128 the Mobile-IPv4 Configuration Option in IPCP. 130 4. Acknowledgements 132 Thanks to Jim Solomon of Motorola for useful discussions of this prob- 133 lem space. 135 5. References 137 [1] C. Perkins. "IP Mobility Support." RFC 2002, IBM October 1996. 139 [2] J. Solomon, S. Glass, "Mobile-IPv4 Configuration Option for PPP 140 IPCP." RFC 2290, Motorola, FTP Software, February 1998. 142 6. Authors' Addresses 144 Bernard Aboba 145 Microsoft Corporation 146 One Microsoft Way 147 Redmond, WA 98052 149 Phone: 425-936-6605 150 EMail: bernarda@microsoft.com