idnits 2.17.1 draft-perkins-mobileip-bcastpref-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-03-28) 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. == 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 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. ** 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 167: '...atisfy the request, it MUST reject the...' RFC 2119 keyword, line 174: '... MUST not forward broadcasts to the ...' RFC 2119 keyword, line 176: '..., the home agent MUST keep track of th...' RFC 2119 keyword, line 198: '...d Protocol, the home agent MUST reject...' Miscellaneous warnings: ---------------------------------------------------------------------------- == 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: When a mobile node is attached to its home network, a home agent MUST not forward broadcasts to the mobile node. When a mobile node includes the 'P' flag in the Broadcast Preference extension to a registration request, the home agent MUST keep track of the requested Broadcast Preference(s) for the mobile node until the mobile node clears the information with a new Broadcast Preference extension containing the 'C' flag. In this way, the mobile node may be relieved of the requirement to send in the same list of Broadcast Preference extensions every time it registers at a new care-of address. -- 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 (13 February 1996) is 10271 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force C. Perkins 2 INTERNET DRAFT B. Patel 3 IBM Research 4 13 February 1996 6 Preference for Broadcast Datagram Support with Mobile IP 7 draft-perkins-mobileip-bcastpref-00.txt 9 Status of This Memo 11 This document is a submission to the Mobile-IP Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the mobile-ip@smallworks.com mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at 24 any time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 29 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Abstract 35 This document specifies a new extension to the Registration Request 36 used by mobile nodes with the mobile-IP protocol. The new extension 37 allows the mobile node to select the particular IP broadcasts which 38 the home agent should forward to the mobile node when it attaches to 39 the Internet at a care-of address not on its home network. 41 1. Introduction 43 Mobile-IP [1] allows mobile nodes to move from one point of 44 attachment within the Internet to another, and defines mechanisms 45 by which a home agent on the mobile node's home network can send 46 datagrams to the mobile node. Since the mobile node's IP address 47 makes it seem to other routers as if the mobile node is on the 48 same network as the home agent (i.e., as if the mobile node is on 49 its "home network"), datagrams from other networks destined to the 50 mobile node will be transmitted onto the mobile node's home network, 51 where they can be received by the home agent and encapsulated for 52 delivery to the mobile node's care-of address. The mobile node's 53 care-of address can be an address assigned to one of the mobile 54 node's network interfaces, or it can be an address advertised by a 55 mobility agent near the current whereabouts of the mobile node. Such 56 a mobility agent is called a foreign agent. 58 Assuming that the mobile node is not currently attached to its home 59 network, datagrams destined for the mobile node's home address will 60 be sent to it by the home agent at its care-of address. The mobile 61 node is unlikely to wish to receive all the broadcast packets which 62 it would normally receive on its home network. For instance, when 63 the mobile node is not attached to its home network, it would not 64 have any use for handling ARP packets [2]. However, there are many 65 cases when the mobile node would find certain IP broadcast datagrams 66 useful. 68 The mobile-IP specification specifies the relevant details about 69 how the transmission of broadcast datagrams to the mobile node 70 must occur. However, it is assumed to be a matter for the network 71 administration in charge of the mobile node's home network to 72 configure the mobile node's home agent so that the desired datagrams 73 are transmitted from the home agent to the mobile node. 75 This document specifies an extension to the mobile-IP Registration 76 Request message to allow the mobile node to specify which broadcast 77 datagrams it wishes to receive while it is away from its home 78 network. The mobile node uses this extension during its registration 79 process at its current point of attachment. 81 2. Broadcast Preference Extension 83 The Broadcast Preference extension allows a mobile node to specify 84 at the time it registers its current care-of address which IP 85 broadcast datagrams it wants to receive from its home network (via 86 its home agent). The Broadcast Preference extension may be included 87 several times within a single registration request. Each preference 88 selects a particular kind of broadcast that the mobile node wants 89 to receive. If the mobile node wishes to receive several kinds of 90 broadcast datagrams, it includes several preference extensions. Each 91 Preference Extension specifies conditions on the protocol number and 92 the port number, which must both be satisfied by a broadcast datagram 93 before the home agent should forward the broadcast to the mobile 94 node. 96 DISCUSSION: 97 What other constraints should be considered? 99 0 1 2 3 100 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 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Type | Length |C|P|A|X| rsvd | Protocol | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Port | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 Type 40 109 Length 6 111 C If the 'C' ('Clean') flag is set, the home agent is 112 instructed to eliminate any retained specifications for 113 broadcast datagrams which the mobile node had included 114 in any previous Broadcast Preference extensions. 116 P If the 'P' ('Permanent') flag is set, the home agent is 117 instructed to keep the following broadcast datagrams 118 specification active until the mobile node registers 119 again using the 'C' flag. 121 A If the 'A' ('Additional') flag is set, the home agent 122 is instructed to include this preference for receiving 123 broadcasts along with other preferences previously 124 specified by the mobile node. 126 X If the 'X' ('Exclude') flag is set, the home agent is 127 instructed to exclude this preference for receiving 128 broadcasts from other preferences previously specified 129 by the mobile node. 131 rsvd 0 133 Protocol Broadcasts selected by this Broadcast Preference 134 extension must have the specified Protocol in the 135 protocol field of the IP header of the IP broadcast 136 datagram. If the Protocol field of the Broadcast 137 Preference extension is zero, then no restriction is 138 being placed on that field in the IP header. 140 Port Broadcasts selected by this Broadcast Preference 141 extension must have the specified Port in the 142 appropriate field in the upper-level protocol header 143 which follows the IP IP header of the IP broadcast 144 datagram. If the Port field of the Broadcast 145 Preference extension is zero, then no restriction is 146 being placed on that field in the upper level protocol 147 header. 149 All extensions to the mobile-IP registration request have a type 150 field and a length field, as shown above. 152 If the Port field is nonzero, then the Protocol field must also be 153 nonzero. Also, when the Port field is nonzero, the special value 154 Protocol = 255 is taken to mean both the TCP and UDP protocols. This 155 special value is reserved otherwise, and used in this way will make 156 the common case more convenient where the same port number is used 157 for TCP and for UDP for the same application. Note that the Port 158 field is included for convenience, and technically represents a 159 layering violation. 161 If the mobile node wishes to clear ALL of its Preferences, it sends 162 a Broadcast Preference Extension with the 'C' bit set, and both the 163 Port and the Protocol fields set to all zero. 165 3. Home Agent Considerations 167 If the home agent cannot satisfy the request, it MUST reject the 168 Registration Request by issuing a Registration Reply using the newly 169 defined status code: 171 144 Broadcast Preference Not Supported 173 When a mobile node is attached to its home network, a home agent 174 MUST not forward broadcasts to the mobile node. When a mobile 175 node includes the 'P' flag in the Broadcast Preference extension 176 to a registration request, the home agent MUST keep track of the 177 requested Broadcast Preference(s) for the mobile node until the 178 mobile node clears the information with a new Broadcast Preference 179 extension containing the 'C' flag. In this way, the mobile node 180 may be relieved of the requirement to send in the same list of 181 Broadcast Preference extensions every time it registers at a new 182 care-of address. 184 Extensions with both the 'C' bit and the 'X' bit set are interpreted 185 with a special meaning. When such a message is received by the home 186 agent, the home agent begins sending ALL broadcast datagrams to the 187 mobile node except the ones which are specified by the Protocol and 188 Port fields. Subsequent extensions without the 'C' bit set may 189 exclude further broadcasts by not including the 'C' bit. 191 If the home agent does not implement the protocol specified in the 192 Protocol field of the Broadcast Preference extension, it can still 193 approve the mobile node's request as long as the mobile node did 194 not specify the Port field also. When the Port field is zero, the 195 home agent sends ALL broadcasts with the specified Protocol (or 196 excludes ALL such broadcasts if the 'X' bit is set) to the mobile 197 node. When there is a nonzero Port specified, and the home agent 198 does not implement the requested Protocol, the home agent MUST reject 199 the Registration Request with status code 144. 201 4. OPEN ISSUES 203 - Should the Broadcast Preference Extension provide any means to 204 request that non-IP broadcast packets be forwarded to the mobile 205 node? 207 - Should the home agent be able to report status on each Broadcast 208 Preference Extension individually, instead of accepting 209 Registration Request only if each Extension is acceptable? An 210 alternative would be to have another Extension to Reply messages, 211 enabling the home agent to tell the mobile node exactly which 212 Broadcast Preference Extension was unacceptable to the home 213 agent. 215 References 217 [1] IPv4 Mobility Support. ietf-draft-mobileip-protocol-15.txt - 218 work in progress, February 1996. 220 [2] David C. Plummer. An Ethernet Address Resolution Protocol: 221 Or Converting Network Protocol Addresses to 48.bit Ethernet 222 Addresses for Transmission on Ethernet Hardware. RFC 826, 223 November 1982. 225 Authors' Addresses 227 Questions about this memo can also be directed to: 229 Charles Perkins 230 Room H3-D34 231 T. J. Watson Research Center 232 IBM Corporation 233 30 Saw Mill River Rd. 234 Hawthorne, NY 10532 236 Work: +1-914-784-7350 237 Fax: +1-914-784-6205 238 E-mail: perk@watson.ibm.com 240 Baiju Patel 241 Room H3-D36 242 T. J. Watson Research Center 243 IBM Corporation 244 30 Saw Mill River Rd. 245 Hawthorne, NY 10532 247 Work: +1-914-784-6786 248 Fax: +1-914-784-6205 249 E-mail: baiju@watson.ibm.com