idnits 2.17.1 draft-gundavelli-netext-mn-groupid-option-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 180 has weird spacing: '...t field conta...' -- The document date (June 02, 2009) is 5441 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: 'RFC-4283' is defined on line 229, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG S. Gundavelli 3 Internet-Draft K. Leung 4 Intended status: Standards Track Cisco 5 Expires: December 4, 2009 B. Patil 6 Nokia 7 D. Premec 8 Nokia Siemens Networks 9 June 02, 2009 11 Mobile Node Group Identifier option 12 draft-gundavelli-netext-mn-groupid-option-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 4, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document specifies a new mobility option for use in Proxy 51 Binding Update and Proxy Binding Acknowledgement messages. This 52 option can be used by the mobility entities in a Proxy Mobile IPv6 53 domain for carrying the group affiliation of a mobile node in any of 54 the mobility signaling messages. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Signaling and other Considerations . . . . . . . . . . . . . . 4 61 4. Mobile Node Group Identifier Option . . . . . . . . . . . . . . 4 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 The Proxy Mobile IPv6 base specification [RFC-5213] uses the mobile 73 node identifier in the mobility signaling messages for identifying 74 the mobile node. However, the signaling messages lack the capability 75 to identify a set of mobile nodes which have a common characteristic. 76 A group identifier associated with a mobile node enables the ability 77 to perform protocol operation on a set of mobile nodes via a single 78 transaction. The group identifier provides a more optimal mechanism 79 for protocol operation which would otherwise require multiple atomic 80 transactions on a per mobile node basis. Following are some of the 81 use-cases where such identifier can be used. 83 o In a blade architecture system running the local mobility anchor 84 service, all the mobile node sessions anchored on a given card can 85 be part of one single group. When there is a failure on a 86 specific card, the local mobility anchor can initiate the 87 revocation signaling to the mobile access gateway by sending a 88 sending a single revocation request carrying the group identifier. 90 o For periodic re-registrations 91 [draft-premec-netlmm-bulk-re-registration], the mobile access 92 gateway may send a single re-registration message for each of the 93 mobile node's groups and perform re-registrations for all the 94 mobile node's that are part of that group. 96 o The mobile access gateway or the local mobility anchor in a proxy 97 mobile IPv6 domain may choose to revoke the registration of mobile 98 node associated with a specific realm. In such cases the mobile 99 access gateway or the local mobility anchor can perform the 100 binding revocation signaling using the group ID associated with a 101 specific set of mobile nodes. 103 This document defines a new mobility option, Mobile Node Group 104 Identifier option, that can be used by a local mobility anchor and a 105 mobile access gateway for exchanging the mobile node's group 106 identifier. 108 2. Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC-2119]. 114 3. Signaling and other Considerations 116 The Mobile Node's Group Identifier option reflects the group 117 affiliation that is local to the local mobility anchor or mobile 118 access gateway, as determined by those respective entities. 120 The conceptual Binding Update List entry data structure maintained by 121 the mobile access gateway, described in Section 6.1 of [RFC-5213], 122 MUST be extended to store the mobile node's group identifier. 124 The Mobile Node Group Identifier option MAY be used in the Proxy 125 Binding Update message sent by the mobile access gateway to the local 126 mobility anchor. When this option is included, the identifier value 127 in the option MUST be set to the mobile node's group identifier, 128 local to the mobile access gateway 130 The conceptual Binding Cache entry data structure maintained by the 131 local mobility anchor, described in Section 5.1 of [RFC-5213], MUST 132 be extended to store the mobile node's group identifier. 134 The Mobile Node Group Identifier option MAY be used in the Proxy 135 Binding Acknowledgement message sent by the local mobility anchor to 136 the mobile access gateway. When this option is included, the 137 identifier value in the option MUST be set to the mobile node's group 138 identifier, local to the local mobility anchor. 140 4. Mobile Node Group Identifier Option 142 A new option, Mobile Node Group Identifier option is defined for 143 using it in Proxy Binding Update and Proxy Binding Acknowledgement 144 messages exchanged between a local mobility anchor and mobile access 145 gateway. This option is used for carrying the mobile node's group 146 identifier. 148 The alignment requirement for this option is 4n. 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Type | Length | Sub-Type | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Mobile Node Group Identifier | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Type 160 162 Length 164 8-bit unsigned integer indicating the length in octets of 165 the option, excluding the type and length fields. The value 166 for this field MUST be set to 6. 168 Sub-Type 170 Identifies the specific group type. This number space will be 171 managed by the IANA. 173 Reserved 175 This field is unused for now. The value MUST be initialized 176 to 0 by the sender and MUST be ignored by the receiver. 178 Mobile Node Group Identifier 180 A 32-bit field containing the mobile node's group identifier. 182 Figure 1: Mobile Node Group Identifier Option 184 5. IANA Considerations 186 This specification defines a new Mobility Header option, the Mobile 187 Node Group Identifier option. This option is described in Section 4. 188 The Type value for this option needs to be assigned from the same 189 numbering space as allocated for the other mobility options, as 190 defined in [RFC-3775]. 192 6. Security Considerations 194 The mobile node's identifier is always present in the Proxy Mobile 195 IPv6 signaling messages and additionally carrying the group identity 196 of the mobile node introduces similar vulnerabilities. Specifically, 197 it exposes the group affiliation of the user and may result in 198 compromising the privacy of the user or the location information. 200 The Mobile Node Group Identifier option defined in this specification 201 is for use in Proxy Binding Update and Proxy Binding Acknowledgement 202 messages. This option is carried like any other mobility header 203 option as specified in [RFC-3775] and does not require any special 204 security considerations. 206 Hence, this specification does not add any new vulnerability to the 207 Proxy Mobile IPv6 protocol. 209 7. Acknowledgements 211 The authors would like to acknowledge the prior discussions on this 212 topic in netlmm mailing list. 214 8. References 216 8.1. Normative References 218 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 222 IPv6", RFC 3775, June 2003. 224 [RFC-5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 225 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 227 8.2. Informative References 229 [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 230 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 231 RFC 4283, November 2005. 233 [draft-premec-netlmm-bulk-re-registration] D. Premec, et. al, "Bulk 234 Re-registration for Proxy Mobile IPv6", July 2008. 236 Authors' Addresses 238 Sri Gundavelli 239 Cisco 240 170 West Tasman Drive 241 San Jose, CA 95134 242 USA 244 Email: sgundave@cisco.com 246 Kent Leung 247 Cisco 248 170 West Tasman Drive 249 San Jose, CA 95134 250 USA 252 Email: kleung@cisco.com 254 Basavaraj Patil 255 Nokia 256 6000 Connection Drive 257 Irving, TX 75039 258 USA 260 Email: basavaraj.patil@nokia.com 262 Domagoj Premec 263 Nokia Siemens Networks 264 Heinzelova 70a 265 10000 ZagrebIrving 266 Croatia 268 Email: domagoj.premec.ext@nsn.com