idnits 2.17.1 draft-partha-mobileip-mcastpref-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-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. == 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 157: '...atisfy the request, it MUST reject the...' RFC 2119 keyword, line 164: '... MUST not forward multicasts to the ...' RFC 2119 keyword, line 165: '...ollowing actions MUST be taken by the ...' RFC 2119 keyword, line 174: '..., the home agent MUST respond to the I...' RFC 2119 keyword, line 176: '... The home agent MAY optionally tunnel...' (10 more instances...) 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 multicasts to the mobile node. When a mobile node is away from home, the following actions MUST be taken by the home agent. -- 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 (22 February 1996) is 10291 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' == Outdated reference: A later version (-07) exists of draft-ietf-idmr-igmp-v2-02 -- Possible downref: Normative reference to a draft: ref. '4' -- No information found for draft-ietf-ip4inip4 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force P. Bhattacharya 2 INTERNET DRAFT B. Patel 3 C. Perkins 4 IBM Research 5 22 February 1996 7 Preference for Multicast Support with Mobile IP 8 draft-partha-mobileip-mcastpref-00.txt 10 Status of This Memo 12 This document is a submission to the Mobile-IP Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 to the mobile-ip@smallworks.com mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. 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 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 30 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 This document specifies a new extension to the Registration Request 37 used by mobile nodes with the mobile-IP protocol. The new extension 38 allows the mobile node to select the particular IP multicasts which 39 the home agent or foreign agent should forward to the mobile node 40 when it attaches to the Internet at a care-of address not on its home 41 network. 43 1. Introduction 45 Mobile-IP [1] allows mobile nodes to move from one point of 46 attachment within the Internet to another, and defines mechanisms 47 by which a home agent on the mobile node's home network can send 48 datagrams to the mobile node. Since the mobile node's IP address 49 makes it seem to other routers as if the mobile node is on the 50 same network as the home agent (i.e., as if the mobile node is on 51 its "home network"), datagrams from other networks destined to the 52 mobile node will be transmitted onto the mobile node's home network, 53 where they can be received by the home agent and encapsulated for 54 delivery to the mobile node's care-of address. The mobile node's 55 care-of address can be an address assigned to one of the mobile 56 node's network interfaces, or it can be an address advertised by a 57 mobility agent near the current whereabouts of the mobile node. Such 58 a mobility agent is called a foreign agent. 60 A mobile node on a foreign network may need to send and receive 61 multicast packets either directly from the foreign network or from 62 its home network via its home agent. Depending on the application, 63 a mobile node may wish to have any of the above options on a per 64 multicast address basis. While the Mobile-IP specification specifies 65 relevant details about the transmission and reception of multicast 66 datagrams from its home network, it does not specify how a mobile 67 node can choose these options in a foreign network. 69 This document specifies an extension to the mobile-IP Registration 70 Request message to allow the mobile node to specify its options in 71 sending and receiving multicast datagrams on a per multicast address 72 basis. The mobile node appends the new extension to the Registration 73 Request it sends at its current point of attachment. 75 2. Multicast Preference Extension 77 The Multicast Preference extension allows a mobile node to specify, 78 at the time it registers its current care-of address, send and 79 receive options for various multicast addresses. The Multicast 80 Preference extension may be included several times within a single 81 registration request, once for every multicast address. 83 DISCUSSION: 84 What other constraints should be considered? 86 0 1 2 3 87 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 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+-+-+-+-+-+-+-+-+-+ 89 | Type | Length |C|P|A|XH|XF|RH|RF| rsvd | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+-+-+-+-+-+-+-+-+-+ 91 | Multicast IP address | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 Type 41 96 Length 4 + (4 * number of Multicast IP addresses listed) 98 C If the 'C' ('Clean') flag is set, the mobility agent is 99 instructed to eliminate any retained specifications for 100 multicast datagrams which the mobile node had included 101 in any previous Multicast Preference extensions. 103 P If the 'P' ('Permanent') flag is set, the mobility 104 agent is instructed to keep the following multicast 105 datagrams specification active until the mobile node 106 registers again using the 'C' flag. 108 A If the 'A' ('Additional') flag is set, the mobility 109 agent is instructed to include this preference for 110 receiving multicasts along with other preferences 111 previously specified by the mobile node. 113 If 'A' flag is not set (0), the mobility agent is 114 instructed to delete all non-permanent preferences 115 previously specified by the mobile node before storing 116 this preference. 118 If 'P' flag is set, 'A' flag is ignored. 120 XH If the 'XH' ('Transmit at Home') flag is set, then the 121 mobile node wishes to transmit packets destined to the 122 address specified in the Multicast IP address field, in 123 the mobile node's home network. 125 XF If the 'XH' ('Transmit in Foreign') flag is set, then 126 the mobile node wishes to transmit packets destined 127 to the address specified in the Multicast IP address 128 field, in the mobile node's foreign network. 130 RH If the 'RH' ('Receive from Home') flag is set, then the 131 mobile node wishes to receive packets destined to the 132 address specified in the Multicast IP address field, 133 from the mobile node's home network. 135 RF If the 'RL' ('Receive from Foreign') flag is set, then 136 the mobile node wishes to receive packets destined 137 to the address specified in the Multicast IP address 138 field, in the mobile node's foreign network. 140 rsvd 0 142 Multicast IP addresses Flags and options specified by this 143 Multicast Preference extension apply to the Multicast 144 IP addresses listed in this field. 146 All extensions to the mobile-IP registration request have a type 147 field and a length field, as shown above. The number of Multicast 148 IP addresses listed will determine the length of the Multicast 149 Preference Extension. 151 If the mobile node wishes to clear ALL of its Multicast Preferences, 152 it sends a Multicast Preference Extension with the 'C' bit set, and 153 zero Multicast IP addresses listed. 155 3. Home Agent Considerations 157 If the home agent cannot satisfy the request, it MUST reject the 158 Registration Request by issuing a Registration Reply using the newly 159 defined status code: 161 145 Multicast Preference Not Supported 163 When a mobile node is attached to its home network, a home agent 164 MUST not forward multicasts to the mobile node. When a mobile node 165 is away from home, the following actions MUST be taken by the home 166 agent. 168 - If the 'XH' flag is set, then the home agent should transmit the 169 packets received from the mobile node, on the local network. 171 - If the 'XF' flag is set, no special actions are required from the 172 home agent. 174 - If the 'RH' flag is set, the home agent MUST respond to the IGMP 175 membership queries [2, 3] by including the multicast address 176 in its reports. The home agent MAY optionally tunnel the IGMP 177 membership queries to the mobile host. Also, the home agent MUST 178 tunnel the multicast packets to the mobile host for the specified 179 multicast address. 181 - If the 'RF' flag is set, no special actions are required from the 182 home agent. 184 When a mobile node includes the 'P' flag in the Multicast Preference 185 extension to a registration request, the home agent MUST keep 186 track of the requested Multicast Preference(s) for the mobile node 187 until the mobile node clears the information with a new Multicast 188 Preference extension containing the 'C' flag. In this way, the 189 mobile node may be relieved of the requirement to send in the same 190 list of Multicast Preference extensions every time it registers at a 191 new care-of address. 193 4. Foreign Agent Considerations 195 If the 'XH' flag is set, then the Foreign agent MUST tunnel packets 196 received from the mobile node to the home agent. 198 If the 'XF' flag is set, and the foreign agent receives an 199 IP-within-IP datagram from the mobile node, then the foreign agent 200 MUST decapsulate the datagram, and replace the source address in the 201 multicast datagram with the Care-of-Address and submit the datagram 202 for IP processing. 204 If both 'XH' and 'XF' flags are set, both actions above MUST be 205 performed. 207 If the 'RH' flag is set, then the foreign agent MUST process tunneled 208 datagrams in one of the following ways: 210 - Transmit the multicast datagram from the interface sharing a link 211 with the mobile node, with TTL set to 1. 213 - Encapsulate the multicast datagram within a unicast IP datagram 214 addressed to the mobile node's home address, and submit for IP 215 processing. 217 If the 'RF' flag is set, and the foreign agent is acting as the 218 default router for the mobile node, the foreign agent transmits 219 multicast datagrams with the specified multicast address to the 220 mobile node. 222 5. Mobile Node Considerations 224 If the mobile host is attached to its home network, no special action 225 is required by mobile host. 227 If the mobile host is attached to a foreign network, and the 228 Registration Request with the appended Multicast Preference Extension 229 was accepted by its home agent (and, if applicable, the foreign 230 agent advertising the care-of address used in the Registration), the 231 following actions are required. 233 If 'XH' flag was set, the mobile host MUST encapsulate every 234 multicast datagram within an unicast IP datagram addressed to the 235 home agent. 237 If 'XF' flag was set, it MUST do one of the following: 239 - Encapsulate every multicast datagram within an unicast IP 240 datagram addressed to the foreign agent. 242 - Transmit every multicast datagram with source address set to the 243 care-of address. 245 DISCUSSION: 246 Is this a reasonable way to offload processing from the foreign 247 agent? Should the Preference Extension contain another 248 flag to distinguish the two modes of operation? 250 If 'RH' flag was set, the mobile host MUST decapsulate IP in IP 251 packets [5]. 253 If 'RF' flag was set, the mobile host MUST respond to the IGMP 254 membership queries. 256 6. Related Work 258 This draft specification is related to a companion draft 259 specification for the Broadcast Preference Extension for 260 Mobile-IP [4]. Changes to one document should be considered for 261 their impact on the issues in the other document. 263 References 265 [1] IPv4 Mobility Support. ietf-draft-mobileip-protocol-15.txt - 266 work in progress, February 1996. 268 [2] Steve Deering. Host Extensions for IP Multicasting. RFC 1112, 269 August 1989. 271 [3] W. Fenner. Internet Group Management Protocol, Version 2. 272 draft-ietf-idmr-igmp-v2-02.txt -- work in progress, February 273 1996. 275 [4] B. Patel and C. Perkins. Preference for Broadcast Datagram 276 Support with Mobile IP. draft-perkins-mobileip-bcastpref-00.txt 277 -- work in progress, February 1996. 279 [5] Charles Perkins. IP Encapsulation within IP. 280 draft-ietf-ip4inip4-01.txt -- work in progress, October 1995. 282 Authors' Addresses 284 Questions about this memo can also be directed to: 286 Partha Bhattacharya Baiju Patel 287 Room H3-D40 Room H3-D36 288 T. J. Watson Research Center T. J. Watson Research Center 289 IBM Corporation IBM Corporation 290 Hawthorne, NY 10532 Hawthorne, NY 10532 291 30 Saw Mill River Rd. 30 Saw Mill River Rd. 293 Work: +1-914-784-7981 Work: +1-914-784-6786 294 Fax: +1-914-784-6205 Fax: +1-914-784-6205 295 E-mail: partha@watson.ibm.com E-mail: baiju@watson.ibm.com 297 Charles Perkins 298 Room H3-D34 299 T. J. Watson Research Center 300 IBM Corporation 301 30 Saw Mill River Rd. 302 Hawthorne, NY 10532 304 Work: +1-914-784-7350 305 Fax: +1-914-784-6205 306 E-mail: perk@watson.ibm.com